TRS-80 Compatible Clone

A TRS-80 using more modern parts

Similar projects worth following
This project needs to be fleshed out to see what is wanted. I am guessing that it will be something that can run with the original ROM's or perhaps modified ROM's so that it can use an SD card instead of FDD.

Nothing is set in stone so add your requests in the comments or request to join as a team member. I don't really want to do this completely by myself as I am more interested in designing the hardware than actually using it.

Latest Updates:

Sunday 24 April -

Project log added.


This is just an 'idea' of the parts and I am sure things will change.

  • Z80 CPU, probably NMOS
  • ROM - probably FLASH, perhaps large so as to use as FDD replacement.
  • RAM - Just SRAM too easy, but still with RAS CAS on expansion connector.
  • CPLD - Glue logic / video. Xilinx XC9572XL (easy to solder) or Altera EPM750 (cheaper to program).
  • OP-Amp - for cassette port filtering.
  • 7805 V Reg - and we're done! (The rest is connectors).

Some thoughts -

The Video is not standard but close enough to NTSC to work, also needs a PAL variant - set with jumper.

Two approaches:

  1. 100% hardware compatibility, hard to do and many extra parts like character ROM, more expensive.
  2. Hardware compatible on expansion Bus (and I/O) connectors only. Saves some corners like only one FLASH for ROM (no separate Char ROM) and only one (S)RAM chip, saves PCB board space which is cheaper to make by time division multiplexing of the system bus at a higher rate than CPU access. Would also get rid of screen flicker (mostly).


SRAM available in 32kB, 128kB, 256kB or 512kB in DIP packages.

Perhaps the 128kB chip as it is still cheaper than a combination of two chips.

FLASH available in 128kB and 512kB in DIP packages.

Perhaps the 512kB FLASH as it's still a 32Pin and may serve as a emulated FDD. Who knows ...

I can't get any of the above here in my country so I will have to work with adaptors.

I don't have any clue as to where I can get such a weird crystal (10.6445MHz). The dot clock seems to come from this (will confirm) also divided by 6 for CPU clock.

So I am thinking of going with:

32 Pin DIP socket for FLASH and SRAM anything from 64kB to 512kB will fit in the socket if you can find it - probably 128kB SRAM and 512kB or 64kB FLASH.

40 Pin DIP socket for the CPU. The NMOS 10MHz version is still available in DIP.

44 Pin DIP for the CPLD. The actual chip is QFP44 Pin so it will sit in a 'standard' QFP to DIP adaptor and have a funky pinout.

Next Steps:

Do a pin count on the expansion bus to see if a 44 Pin CPLD will cut it. If 'YES' then design prototype PCB or (god forbid) try to bread board it.

If 'NO' then try to work out how I am going to mix 0.1" spacing, single sided PCB and a QFP100 chip in the same space.

(NOTE: The NMOS and CMOS versions handle OUT(port), register differently, one puts 0xFF on the upper Address bus and the other puts 0x00 on same. Will this effect operation ?) ie are the ports mapped to an 8 bit address space or a 16 bit address space.

Video and Graphics:

The screen is 63x16 Char cells or 128x48 Graphic cells.

One Char is 7x5px in a 12x6px cell

One Graphic is 3x4px in a 12x6px cell

Total resolution is 384px by 192px, that is 2 horizontal px to every vertical px and has to be converted to an aspect ration from 2:1 to 4:3

For VGA the closest matches are:-

800x600 :- 384x2 => 768 (of 800), 192x3 => 576 (of 600)

Clock frequencies for the above VGA format are 40MHz (60Hz refresh, 628 Lines/Frame) and 50MHz (72Hz refresh, 666 Lines/Frame)

768x576 :- 384x2 => 768 (of 768), 192x3 => 576 (of 576)

Clock frequency for the above VGA format is 34.96MHz (60Hz refresh, 592 Lines/Frame)

NTSC is 525 Lines/Frame??? Anyone help? I have PAL here.

It looks like there are four desired standards: NTSC Composite, PAL Composite and VGA and the original. (I can't fit all four into the smaller CPLD).

I am going to proto with 50 MHz first because the development board has a 50 MHz oscillator. This means the closest match for CPU clock is 50 / 28 MHz or 1.7857 MHz.

  • Getting back to it.

    Hacker40404/24/2016 at 05:08 0 comments

    I have been away for a while. In that time I have started using a different computer. I don't know how much is recoverable from the old one.

    I now have the Altera and Xilinx platforms on my laptop.

    I re-did some of the VHDL. I found that the character ROM is too larg to fit into the CPLD chip I am using (EPM240) so that will make the timing difficult.

    Anyway I have been playing and here is a pic of the start of the TRS-80 screen layout. Each character cell is a different color -

    Here is what the development board looks like now - the Z80 isn't wired yet. I am actually using this for two projects as only the VHDL and ROMs are different.

    I am considering switching to PCB modules (single sided with links on the other side) that plug into a backplane so I can do this stage by stage. Wire Wrap is so slow.

  • More timing problems

    Hacker40410/07/2015 at 06:13 0 comments

    It'll be easy they said!

    I spent many hours using WaveDrom as a visualising tool for the timing. At the end of this many hours, I decided to split the diagram into several parts. I discovered that the "Save As" function does not change the default file name so the original file is overwritten when you close WaveDrom!!! Much frustration. I lost everything except the above.

    Anyway this CPU is *not* the easiest chip to bus time share with. As you can see from the Op-Code fetch above, it wants the Address bus just about all the time.

    It also has two different SRAM Read timings, one for op-code fetch and another for normal access.

    One other notable feature is the very wide data out write window.

    There is also one other 'problem': I want to be able to write to the FLASH (ROM) from the CPU. I will mention what is a problem with that later.

    Here's what I came up with and they're just thoughts now that I have lost the diagrams that I made.

    Because of the two different read cycles and data in windows, I will buffer reads to a local register (in the CPLD) so the CPU can grab the data when it is ready. Even though the read data-in windows are completely different, the control signals /MREQ /RD start off almost exactly the same way. Each T cycle will be divided up into 3,4 or 6 sections and the read will happen the earliest and read later by the CPU when it is ready.

    A Write (to RAM or FLASH) won't need buffering as the data out window is so long. There is one problem though. The write control window is longer than one T cycle. This means a second write to the same location may occur. If this were to happen then the CPU couldn't write to FLASH as it has 'write protection' that requires a specific sequence if write to effect one byte update.

    So in total - there should be at least 4 time slots -

    1) CPU Read - RAM or FLASH

    2) Graphics Read - RAM (Character ASCII number)

    3) Graphics READ - FLASH (Character Pixel map - one line)

    4) CPU Write - RAM or FLASH

    There will be 6 CPU T cycles to one screen character.

    The screen dot clock will run at 25 MHz

    The CPU clock will be 2.083 MHz

    Now I have to make sub timing diagrams for these processes and then I can write it to HDL.

    These timing windows won't actually fit together so I will also buffer the data for pixels and have it one character late so they transfer at the very start of the next T cycle. This will mean I have to adjust the Graphics timing to pre-compensate for this.

    OK, next step is to go and redo and finish the timing diagrams that I lost.

    One drawback that is likely from all of this is that each unit will most probably have to be programmed specificity for the video standard it uses: PAL, NTSC, VGA, because all of these standards are not going to fit in a CPLD together.

  • A Wire-Wrap test bed.

    Hacker40410/03/2015 at 05:54 0 comments

    OK, this log will take a couple of days to get through.

    I have work out the timing which is complex. The original TRS-80 had separate Character ROM and separate Video RAM.

    I intend to use only one ROM (FLASH) chip and one (S)RAM chip. So the FLASH will have both the system ROM and the character pixels and needs to be accessed by both the video generator and the Z80. Like wise the RAM will have both the system RAM and the Video RAM and needs to be access but both the Z80 and Video generator.

    To further complicate the matter the Video generator need to first access RAM to get the character number and then access the ROM to get the pixel arrangement that has to go to the screen.

    And if that all isn't enough ... in the original TRS-80, the Z80 had access priority and this caused some screen flicker with video access. As this build will have only one RAM chip then this flicker would happen whenever ANY RAM is accessed ie not just Video RAM. On top of that the same would happen with conflicts of access to the ROM for both the CPU and the Video characters.

    So I have to solve this by timing it out so that access to both RAM and ROM doesn't clash which will be hard to do with Video clocking out pixels at 25MHz (HSVGA) and a CPU running an irregular access pattern at a base clock about 2MHz.

    For a test bed for this part of the project I have decided to go with Wire-Wrap after someone mentioned that Wire-Wrap will fit normal pin headers. I order a wire-wrap tool for about $35. I still had wire-wrap wire as I use that for repairing PCBs.

    Finding wire-wrap sockets is too hard now and I have a lot of breakout boards that wont fit standard sockets anyway so I decide to use ZIF sockets as they're as cheap as wire-wrap sockets anyway.

    Here is what I have put together so far -



    I started some wire-wrapping and it seems to go ok.

    The Z80 pictured is a fake from China (ebay) you can tell by the color and brightness of the printing on top. It marked as a 10MHz chip but it's probably just a Z80, Z80A or Z80B. It will probably work fine at ~ 2MHz.

    I decided to use a EPM240 CPLD as it has enough logic for this part easily. Problem is that it only has 80 IO. So roughly 40 IO for the Z80, 35 IO for the RAM/ROM and 3 or so for VGA.

    That means that there is basically no IO pins left for the expansion port keyboard cassette etc. So I make have to tack another board on to the right of this one later.

    OK ... I am off to some VHDL and hope to be back in a couple of days.

  • Started VHLD Module for Video

    Hacker40406/10/2015 at 09:07 0 comments

    I have been spending some time with a timing rendering Application (WaveDrom).

    Here is a basic idea of the timing of the pixel renderer -

    It is not very accurate as I can't seem to get it to do what I want yet but it does give a basic idea of where I am heading.

    It looks like the memory access time will be over 80nS which is great as the FLASH is 70nS.

    I am trying to separate the dot rendering part of the VHDL from the timing part so that I can use jumpers to select the output format: NTSC, PAL or VGA.

    This approach will waste some registers for timing but there should be more than enough in the chip I am using.

  • VHDL Started

    Hacker40406/02/2015 at 10:06 2 comments

    Or do you prefer Green?

    This is a direct dump from ROM to the screen. Most of the image is the TRS-80 BASIC ROMs.

    Then there are the characters. The characters sit in 8x16 memory cells so not all of them fit on the screen because they need to go into a 6x12 cell for on-screen.

    The bright area after the characters is blank ROM (FLASH).

    The BASIC ROMs are occupying 12kB and after that the character ROM occupies 4kB so they fit neatly together into a 16kB block.

    There is some ghosting because of timing issues. The VHDL is just something quick and dirty so that I can see roughly what it will look like. All the issues will be fixed when I properly time out (synchronise) the code.

    So tomorrow I will completely re-write the VHDL. At the moment it doesn't even have a shift register. It is doing a full 128 ROM reads per character. ie reading each byte 8 times to put out a single dot each time.

    Some curious things - the 70nS FLASH works fine even down to 40nS access times but gives up the ghost at 20nS (not surprisingly). The 25nS SRAM works fine at 20nS. I couldn't test it any faster because the source clock is 50MHz.

    Oh yes, one other thing. The descenders ... well ... descend! Have a look.

  • Finally I Have a Character ROM Code

    Hacker40405/31/2015 at 12:10 1 comment

    Here's what it looks like -

    The above is what it will look like on a standard 4:3 screen. The character are double spaced both horizontally and vertically.

    I modified the characters so that the descenders drop further -

    Below is a render of what it looks like in ROM (when it gets there).

    And the code - Javascript format as I used Javascript to render it.

    Read more »

  • One Day Nothing Achieved

    Hacker40405/31/2015 at 08:04 1 comment

    Well today has been a day of frustration.

    I started by picking up the Xilinx board to use as a FLASH programmer. I did have it working at one stage and then started to upgrade the Arduino code to add features.

    I couldn't get the code to work no matter what I tried. I then checked the VHDL, the connections between the Arduino and the FPGA and the constraints but no good.

    It turned out that the cheap ZIF socket that I got from China was the issue. The pins recede into the housing when you go to plug it into a socket. I soldered pin headers to it - fixed.

    Since then (the rest of the day) I have been head down in Hex trying to nut out a character ROM.

    I have a ROM (that doesn't include graphics) but it doesn't have the proper descenders on lower case. It is also in a 7 x 8 matrix when it should be 5x7. The actual char cell is 5x7 character in a 6x12 cell. I can add graphics easily so that is not an issue.

    I spent hours searching the net for a character ROM image. I found heaps of 8x8 and 8x12 fonts made for a modern systems like windows but not the original. I downloaded several emulators but they all use an 8x12 font and not 6x12.

    In reality I can just make the cells 8x8 or 8x12 in hardware but I want to stay with the original specs.

    I want to make the cells 6x12 just like the original with 5x8 or 5x9 characters (with descenders) and 6x12 graphics. I also want to just put the graphics in ROM with the characters rather than worry about different timings for ROM characters and combinational logic for graphics.

    The solution is to get the facts from the source so I need to know the part number of the chip that generated the characters with descenders and just look up the spec sheet! But dammit, I don't even know the part number.

    Now rolling head on keyboard ...klklklklklklklklklklklkliopreeee b,kero

  • Adding FLASH and SRAM

    Hacker40405/28/2015 at 22:58 2 comments

    There are some slight differences in the layouts of 32 Pin DIP SRAM and FLASH.

    Most of the differences are not a problem. For SRAM it doesn't matter if you mix up the Address or Data pins as long as Address and Data pins are grouped separately. ie It doesn't where the data goes as long as it comes back from the same place. So I ignored most of that and just assumed the Address pinout of the FLASH because that does matter.

    Apart from that there is the issue of /WE and one address pin being swapped comaring SRAM and FLASH. I could have just swapped these pins on the SRAM board but I left it as an exercise in VHDL to fix it with code.

    I decide to connect all the pins except /CE in parallel to save pins on the CPLD.

    The SRAM is 512KBytes 25nS and the FLASH is 70nS.

    Here are the equivalent PCB layouts (FLASH on left, SRAM on right) -

    And dreaded Vero layout (SRAM on left, FLASH on right) -

    They all connect together this way -

    Assembling the bits -

    To program the FLASH I will be using a stack made in a similar way. It connects to an Arduino.

    The programmer was made for a 64KB FLASH so I have to go and rewrite the Arduino code and VHDL (It's a Xilinx chip) so that it can program larger FLASH - up to 512KB.

    Then I have to write the VHDL for the Altera development board - I haven't even started this yet.

    Next steps are - Write VHDL for VGA output. Dual port the FLASH and SRAM with the CPU bus having priority (like it was in the TRS80). Add the CPU and see the 'READY>' prompt (milestone 1 - Level Up).

    Then convert to time division bus multiplexing. After that I can start to worry about I/O such as keyboard and the dreaded pin count. Will it fit in a 100 Pin CPLD???

    OK, I am off to do what I enjoy more and play with some code.

  • Preparing for Breadboarding

    Hacker40405/27/2015 at 09:30 0 comments

    I decided to make another 'stack' with 'duino like plugin shield boards because I want to use this same prototyping platform for anther project as well and that project requires SRAM access up to 50MHz.

    The general idea is to have half the CPLD boards pins go to the breadboard for slow bus speeds and the other half stack on top for the faster buses. I'm not confident at all the the higher speed buses will work on a breadboard.

    So here is the start - the CPLD plugged into a breadboard.

    Here's the bottom of the board -

    I have put dual row pin header sockets on the top and a single rows of pins on the bottom for the breadboard. I also modified it to send 5V to the plugin boards instead if 3V3.

    After I test that it works, I will swap the 50MHz oscillator over for a 100MHz oscillator.

    I don't have any DIP SRAM so I bent the pins of a SOP chip in, to fit it on a TSOP to DIP adaptor -

    Next I have to put SRAM and FLASH onto some boards made from Vero that plug into the top of the CPLD board.

    The SRAM is 128KB.

    I have to dual port both the SRAM and FLASH. The SRAM needs dual porting because it has the video RAM in it and the the FLASH need dual porting because it has the character ROM in it ... to save chip count. This is going to be a challenge for me as I am a beginner at VHDL and the Z80 is non-synchronous.

View all 9 project logs

Enjoy this project?



sitehounder wrote 01/16/2019 at 07:15 point

Judging from how old the last post on this page is, it could be that this project has died... however...

I was reading about the problem you encountered with the video needing access to the RAM (and ROM) at the same time as the CPU. Not a problem on the real hardware as they were separate because the RAM chips were so small. A solution used long past for such problems was dual ported RAM, but I don't know if that is still a thing.

An alternate approach might be to "dual port" standard RAM by running it at double speed big problem back then, not a problem now). First cycle is access by the CPU, second cycle is access by video generator, repeat. All handled through the CPLD/FPGA (it may just need to handle chip selects and not the full A & D bus). I really think you should upgrade the chip to the 100qfp though, you said already that the 44 pinner was too small for what you had and there was no room for tape IO etc. You don't want to go budget on such a cool design!

Great project. I'd like to see it live.

  Are you sure? yes | no

ziggurat29 wrote 01/16/2019 at 17:38 point

It was a slight problem on the actual hardware:  it caused visible artifacts on the screen while you were actively doing video I/O.  The CPU took access to the static memory bus away from the rasterizer, leaving random sections of raster lines blanked while the CPU was reading or writing to the video RAM.  The effect was mostly a slight annoyance (and jealousy of other branded machines which did not exhibit this defect).
Your 'ddr interleaved access' idea is an interesting work around.

  Are you sure? yes | no

sitehounder wrote 01/16/2019 at 20:02 point

Back in the day I did write some machine (assembly) programs for the model 1 (it got me into computers!). I faintly recall some mode where you could tell the unit to either allow the CPU priority access to the video RAM (which would leave quite significant blank streaks on the display), or let the video have priority (in which case there were no streaks). The most obvious case where this happened was the game "cosmic fighter". Maybe it was not the case at all and something else did it? Too long ago!

But besides that, I assume this project is still ticking along, even if just slowly? There seems to be a surprising growth in communities of TRS-80 enthusiasts restoring old machines. I think that people are now retiring and getting a lot more spare time, so interest is rebuilding. Emulators are nice and all, but not quite the same as "genuine" hardware - whether that be the real deal, or a hardware emulator using modern electronics as you are doing. For example, getting a genuine (and working) TRS-80 monitor is not easy, but a flat panel VGA screen is so common people throw them out.

People are also so used to instant access now, even me, and loading stuff from disk (or cassette!!) takes so long in comparison. The FreHD is a really cool gadget! Shame the Catweasle is no longer a product - getting a second hand one is proving to be difficult, and expensive! I have a lot of old floppies to transcribe.

  Are you sure? yes | no

yeti wrote 01/16/2019 at 20:29 point

There were some more or less simple mods to stop the Z80s on conflicting access to the video RAM but the speed penalty was noticeable most where it did hurt most: Fast games.

Occasional video glitches while coding were no topic and so I never added such a modification to my TRS-80 Model 1 clone.

I don't remember ways to achieve this without hardware mods on a Model 1 (or on an EG3003). Maybe later versions could do this?

  Are you sure? yes | no

ziggurat29 wrote 01/16/2019 at 23:31 point

@sitehounder: 'catweasle' -- now that's a name that I've not heard in a long time.  w.r.t. floppies:  I think the guys that run the TRS-80 sites (e.g. Ira Goldklang and others) really want old floppies/cassettes to image to disk images, so they might be able to help with that.
Also, be aware that I am not affiliated with this particular project -- I just replied because your post showed up in my feed.
@yeti I can't imagine how to do it on a Model I without some hardware mod:  e.g. using the BUSRQ to suspend the processor.  Seems like it would be a lot of work with little payoff, but you know how we liked to take the soldering iron to our boxes back in the day...

  Are you sure? yes | no

sitehounder wrote 01/20/2019 at 09:39 point

I've only started getting interested in TRS-80 stuff again recently - after giving my old, virtually dead, model 1 to a collector & electronics enthusiast. After seeing his progress, I am now all enthused again!

I saw Iras' offer to receive old disks & tapes, but I'm not real keen sending my floppies halfway around the world, and I now have absolutely no doubt that my assumed 'dead' machine will live another day. It is likely I will be able to borrow it back for a couple of weeks to do some transcribing... yet to see.

As a matter of interest, check out discovered about an hour ago...

  Are you sure? yes | no

ziggurat29 wrote 01/20/2019 at 17:19 point

I get it with respect to sending your floppies.  It will be interesting to hear if you manage to recover data from them.  There's a huge archive of software (somewhat ironically on a site billed as a 'humongous CP/M archive') which might be useful if your software is damaged, though that won't help for your personal data, of course.
Fascinating find on the eev blog.

  Are you sure? yes | no

Hacker404 wrote 12/10/2023 at 18:32 point

yes, an these access artefacts were very noticeable with rapid ASM access to screen RAM on the original.

  Are you sure? yes | no

Hacker404 wrote 09/05/2022 at 11:02 point

I love how you ended your comment. It's a bit ironic that it wasn't the project that died but instead it was me. Well almost - they can re-start a heart but unfortunately by that stage I had suffered multiple organ failure so I have spent the last 6 years combatting health issues including extensive neural damage and other partially functioning organs and less one lung and a number of smaller dead parts now removed.

I hope to get bach to this project one day which is rather optimistic at this stage. My health is like a yo-yo and I have very little mobility and my cognitive function is still a bit away from something of this complexity.

But for now I started a retro-computer kit Southern-Cross (like a TEC-1) in an effort to stimulate and try and reactivate the old neural paths.

So no promises for now. On any given day my SPO2 can drop from 94 to 70 so there is still  a battle ahead of me. (70% SPO2 is really bad!)

Ironically, I came here looking for my own code! I have to program an EEPROM for the Souther Cross SBC and I used to use an ATMEG Arduino. I have found the programming adaptor but I don't have the code.

And from memory I was going to time divide the access to SRAM, so not really duel porting. And EPM570 would be better because I like to put everything though the CPLD and then the rest is code. But probably doable with a EPM240 - the TRS 80 wasn't a complex machine - I wasn't planning on building an expansion ports and FDDs. Just maybe some DOM Disk On Module IDE device or a CF card using a uC to emulate it back to cassette in some way.

  Are you sure? yes | no

Hacker404 wrote 12/10/2023 at 19:00 point

Well it was more me that died lol. Cancer and then a long time in hospital and I have a reprieve for a while now but very poor mobility and respiratory function and I suffered multiple organ failure eventually including my heart in ICU so now I can't do much else. I have spent 2 years trying to put the workshop back together (everything is slow now as I have very poor fine motor skills on the left side - it's a challenge to type now) and it appears that I may be moving again soon.

But I came back here (I haven't been an active member for about 7 years) and I came back looking for pinout I made of the EPM CPLD board. I have the original in this project right in front of me now. I just ordered 20 boards for wire wrap and I want to see how to work with the dual rows of pins on the CPLD board and I see I designed for both SRAM and FLASH to work on the inner pins - terrific - that problem was solved and I probably have a stripboard for it here some where - I should just add the largest 32 pin SRAM I can find and a 512kB FLASH as that would cover most projects and save me worrying about the second row of pins. I am going to make some changes so that the EPM240 and EPM570 are interchangeable. I have another project of adding VGA to a Southern Cross SBC - I don't know how far I will go with this one. At most VGA out, PS/2 keyboard and cassette emulation to the existing FLASH or MP3 recorder (in .wav format) or CF Card. I wont be adding the expansion port or floppy controllers a I may nor even fit the above into a CPLD - I would have to go to a Cyclone FPGA and all 3v3 which is a whole lot of voltage buffers for the Z80.

So no promises, I can't promises anymore but we will see what happens. I have lost all the original code.

As for dual porting well I will just do time division access as the VGA access is regular and fast so I will just add a address and read/write buffer for the Z80. If the VGA is running ate 50/25/12.5MHz then that is plenty of opportunities for a slower Z80 to access SRAM/FLASH. It's easy to get 10ns SRAM but FLASH doesn't go below about 55ns without spending money. I'll have to split both between VGA and CPU if the characters are in FLASH or just get a second 512kB Flash for 2kB of character ROM lol.

  Are you sure? yes | no

ziggurat29 wrote 12/10/2023 at 20:46 point

god bless you in your recovery. Coincidentally, my own trs-80 related project was to keep me busy while convalescing from some cancer surgery of my own back in the day.
"I have lost all the original code." -- there's this thing called 'github'; you should check it out, lol ;) and the price is right
"As for dual porting..." -- somewhat interesting (or maybe not) was in my MCU based emulator, the hardware output was super solid because it was hardware driven (timer INTs triggering DMA feeding SPI). What was challenging for me was to "feed the beast" in a timely manner where it counted. Later someone piqued my interest in emulating the HRG mod, and I had to do some compute in software of the pixel stream. A straightforward implementation was not possible, but I wound up buffering the raster lines, and then doing partial computations during the blanking interval to get at least the front part of the line ready for DMA, and then incrementally compute the other parts before the DMA caught up to needing them in the buffer.
OK that tale is probably not so interesting to others to hear, but I did get a rush out of getting it working and stabilized. It opened up some nifty capabilities, like 'porting' FS1 to HRG. (a bit less impressive to play than one might imagine, but the lines are much crisper in HRG)
Anyway, best wishes in your recovery/acclimation, and may your projects keep you sane!

  Are you sure? yes | no

Errol Rosser wrote 09/29/2016 at 14:11 point

 RE: The NMOS and CMOS versions handle OUT(port), register differently -
The Model I did use the ports mapped to an 8 bit address space. The Z80 documentation specifies only A0 to A7 during an Input or Output cycle, leaving A8 to A15 undefined.

If you need more technical info on the TRS-80 range or Z80 have a look at what we have on our user group website's on-line library (

  Are you sure? yes | no

Hacker404 wrote 09/29/2016 at 22:26 point

The Z80 has both 16 bit and 8 bit IO. The OUT (c),n OUT(c),r instruction places the 'b' register on the other 8 address bits. 

From memory most of the other port instructions are only 8 bits and the difference between NMOS and CMOS is that one put '00000000' on the other 8 bits of the address bus and the other outputs '11111111'. 

This becomes a problem because by convention IO is gennerally mapped to the FFxx range and some programmers have assumed that they can use an 8 bit IO because (on one version) the default for the other 8-bits is 'FF'

Thanks for the heads up on the 8-bit only TRS-80 IO. I was not aware of that.

  Are you sure? yes | no

Errol Rosser wrote 09/30/2016 at 00:14 point

Your project is titled "TRS-80 Compatible Clone", so I provided details that are specific to the TRS-80 Model I operation. It use the D3 opcode for OUT functions and DB opcode for IN functions ( OUT n, A and IN A, n ). In both cases - from the Zilog Z80 Technical manual - " the I/O device address n appears in the lower half of the address bus (A O -A 7 ) while the accumulator content (the A register) is transferred in the upper half of the address bus".

While the  Z80 does support 16 bit I/O (using register Indirect mode), the TRS-80 Model I does not use this feature.

The only I/O used in a standard Model I is the control of the 32/64 character mode and Cassette read/write

  Are you sure? yes | no

ziggurat29 wrote 09/30/2016 at 00:46 point

@Errol Rosser: and UART (ports 0xe8-0xeb).  I believe hard disk used (0xc0-cf (I never had one)).  And of course sundry non-RS add-ons used various ports.  Sorry, pedantic, I know.  Couldn't resist since I am in the midst of serial port emulation, so those are fresh in my memory.

(why does this site only all two replies deep? formatting?  technical limitation?)

  Are you sure? yes | no

Errol Rosser wrote 09/30/2016 at 08:01 point

@ziggurat29: Being VERY pedantic, the standard Model I did not have a serial port (with UART) OR an Expansion Interface to put it in. Nor did it have a hard disk interface. See the picture at the top of the page.

Anyway, a quick disassembly of the LDOS RS232 and RSHard drivers indicate that I/O to those devices was done using 8 Bit I/O (OUT n, A and IN A, n )

  Are you sure? yes | no

ziggurat29 wrote 10/01/2016 at 02:26 point

Haha yes touche -- quite right of course considering the keyboard unit only, that only the one IO port is used (I tend to assume that "of course you would want the EI, too"; but yes in a hardware reconstruction project like this it makes sense to just emulate the keyboard unit since you could use, say, the FreHD to provide the other stuff).

Re the 16-bit IO on the Z80 -- I had always assumed that behaviour was undocumented, but I find myself right now staring at a User Manual from Zilog that clearly documents it.  Huh.  Well, it is "Copyright ©2016 Zilog, Inc.", so maybe they simply got around to documenting it eventually.  But it's a bit hard to take the 16-bit IO addressing seriously, though.  First, the instruction mnemonic is e.g. "OUT (C), r".  Wouldn't that more sensibly be "OUT (BC), r" if that was how God -- er, Faggin -- intended it?  And then "OUT (n), A", puts... A! on the high bits of the address bus, instead of 'B' as with the others.  Lastly, the block IO I can only imagine would be quite 'amusing' in a hardware system designed around 16-bit IO addressing, since B is used as the counter variable, and each access would be 256 ports apart, haha.  Because of these things, I always presumed the 16-bit behaviour was more just an artifact of silicon implementation convenience, rather than conscientious design intent, and that other silicon vendors preserved it out of fear of some incompatibility issue.  Word-on-the-streets is that the Amstrad used the 16-bit IO, but I never actually had one of those.

Anyway, "whatever", but now I do wish I had a 70s-era Zilog datasheet to see what was actually documented back in the day.  I have a copy of Zaks from that era, but I can't consider that normative (and anyway, I think it's boxed up right now.  It used to be in the bathroom which I re-floored earlier in the year, but it's clearly not there now.)

  Are you sure? yes | no

Hacker404 wrote 10/01/2016 at 03:25 point

I Just had a look at Zaks and it documents putting B on A8-15 with a OTDR. 

The OUT (n),A is that way because the other half of 'A' is 'F' ... AF BC DE HL SP PC IX IY IM/R - last being interrupt mode and refresh register but most of that wasn't documented. 

Back in the day I didn't have a assembler so I printed out tables that went from mnemonic to hex. There were 4 sheets of 16x16 tables and they made it obvious why in some cases you get the 16 bit address space. They also made it obvious what all the undocumented instructions were. Sheet 1) was all the 8 bit mnemonics except CB DD FD and they were the three other sheets. 

There were also lots of undocumented 16 Bit IO instructions and that's probably what you are remembering. As for why - well it simply was easier to let the 16 bit IO work the way it does as there is already a 16 bit bus from register pairs to the address bus for instructions like LD (HL),n. The exception is the Flag register because of timing issues as it is set last as the result of the preceding instruction. 

There was also some fully weird stuff. The CB DD FD instructions made prior changes and then the following bit in some cases was the 8 bit instruction like with offsets. It was possible to use them in unintended ways to make several pre-changes by linking them together but I never fully worked that out. some of the results were uninterpretable.

  Are you sure? yes | no

Hacker404 wrote 09/29/2016 at 23:38 point


I just looked at the site you mentioned. I am too far away to be a member (QLD) but I spent about 8-10 years working for a hosting provider as a web developer (mostly server side). 

I had a look at the forum because I am too far away to be an actual member and thought I could join in that way. 

Perhaps my other skills may be useful. The forum is using file based data storage and I assume that because there is no MySQL or similar database facility?? Hosting is dirt cheap now even with all the bells and whistles. 

It took me back to see that most of the HTML is hand written. That must have been a huge effort. I cheat - takes me about 20 minutes to install a pre-made module like a cms or forum.

  Are you sure? yes | no

Errol Rosser wrote 09/30/2016 at 00:27 point

Maybe you have an old version of the Membership web page in your browser cache - we have recently updated the membership to allow "Online Only" members at a reduced membership rate.

Yes, the pages are hand crafted, then implemented with a scripted page writer. I can write HTML a lot faster than the learning curve on the "fancy" web page design programs, plus I don't get the huge amount of overhead in the web page code.

In case you didn't look at the online library page, here is the current summary of the 70+ GB already up there

Magazines - 1,945 from 46 series - 236,556 pages (47.5 GB)
Exchange Newsletters - 5,965 from 126 clubs - 90,107 pages (12.4 GB)
Hardware - 642 manuals, 330 pictures (drives, TRS-80s, printers) - 33,790 pages (2.6 GB)
Books - 488 (Programming techniques, BASIC programs, ROM info) - 94,166 pages (7.5 GB)
Software - 1,026 manuals, 784 images (Business, Games, Utilities) - 79,500+ pages (4.5 GB)

  Are you sure? yes | no

Bart Hemstra wrote 05/20/2015 at 10:33 point

The Model I runs on 1.774 Mhz where the Model III runs on 2.03 Mhz. The speed increase is about 13% which is no problem for most applications but games and sound might suffer a bit. For me no problem.

  Are you sure? yes | no

Bart Hemstra wrote 05/06/2015 at 09:57 point

The odd descenders on the lowercase character set are correct. These were used on the first releases of the Model 1. The Model 3 and later had true descenders. 

I see you are in Australia; you could ask Ian (from the FreHD) to do the programming of the 27xxx eprom, he has the equipment.

  Are you sure? yes | no

Hacker404 wrote 05/05/2015 at 09:13 point

I found this Character ROM on the net. It said it' for a TRS-80 but doesn't say which model. 

Is it the right one? I have rendered it in the same scale as the screen. 

Is there one with proper decenders on the lower case?

  Are you sure? yes | no

ziggurat29 wrote 07/24/2016 at 00:02 point

It largely looks good in the 0x20-0x7f range.  0x00-0x1f are not correct, they should be a repeat of 0x40-5f.  And of course you don't show the graphics chars 0x80-0xbf (and 0xc0-0xff repeats them), but maybe you're going to do them in logic, like the original hardware, rather than CG ROM.  All this of course assuming you have full 8-bits of video memory.

OK, descenders.  The ones depicted are correct for the MCM6670, which came in the original units before the lower-case mod.  (I think there was also a buggy earlier one where the 'a' was up one line.)  The mod also replaced that part with the MCM6673, which was a little bit more pleasing (one pixel of descender).  Later units (like mine), came with the '73 installed oob even without the lower case mod, so upgrading it myself simply consisted of buying a piece of static ram with minor surgery (a $USD 98 savings).

(I'd post a bitmap of the '73 CG ROM results, but I can't see how.)

  Are you sure? yes | no

Hacker404 wrote 05/04/2015 at 05:21 point


WTF is a 10.6445 MHz crystal for. CPU runs at 10.6645 / 6 => 1.77408333... MHz

  Are you sure? yes | no

Bart Hemstra wrote 05/03/2015 at 19:06 point

Pin headers sound like a great idea, as the card edge connectors are indeed very unreliable. It would be great to be able to connect to the Expansion Interface or the FreHD Harddisk emulator. 

VGA is great, together with composite. What about a small add-on board with the DIN-connectors for those who want to use an old M1 shell? The main PCB is smaller, cheaper and for many it doesn't really matter. 

I'll send a picture of the keyboard connector, and the schematics of the keyboard PCB (it has some chips on it). 

I'll also send a description of the character set, and the wat graphics are represented in the character rom. Compatibility on that level will be appreciated! I'll also upload a ROM-image which supports autoboot for a harddisk. It's 100% compatible with the M1 but enables booting from HD, thus no Expansion Interface of floppy disk is needed.

I see you have found most of the important information already, maybe a detailed memory map wil help in the process. 

Just need to find out how to upload these items, or how to send them!

(NB: cheap and small is good! A maxed out M1 is perfect, waisting 16K is no problem as it keeps the costs down)

  Are you sure? yes | no

Hacker404 wrote 05/02/2015 at 22:01 point

I haven't printed out the schematics yet. I will do that today. I looks like there are some PCB traces cut according to the schematics. They're in the area of RAM / ROM addressing. 

There are 2 dip switch / jumper blocks. It looks like they're for RAM / ROM size / config. I would really like to do away with these because using 16 pins for dip switches is a waist of pins on the CPLD. I was thinking to use just  the maximum config - 48k RAM and 12k ROM, implemented in lager single chips ie 64k SRAM and waist the extra 16k that way I can keep the chip count down making the actual PCB cheaper to make. 

About CPLD, it's just all the extra chips that aren't RAM/ROM/CPU/OP-Amps that are crammed into one chip but they're not all connected, the connections are done with a program instead of traces on a circuit board.

There are two problems with CPLDs:

1) There not 5 Volt (but some will work with 5 Volt) ... 

2) They're in square packages with pins close together so they are hard to solder. 

... I can put the CPLD on an adaptor board if need be, that way if soldering it is stuffed up then you throw it in the bin and start over without having to worry about the rest of the circuit / parts. 

I had two CPLD candidates in mind:

1) Xilinx XC9572XL, about $10 - $15, 44 pin package with pins 0.8mm apart (72 Macrocells) but the programmer is $30 to $50. I may not be able to fit a VGA out in 72 Macro's but I can try. (I have a programmers for both Xilinx and Altera). 

2) Altera EMP240, about $5, 100 pin package with pins 0.5mm apart (180 Macrocells), the programmer is only about $5

0.8mm and 0.5mm might not sound like much difference but it is significantly harder to solder 0.5mm

I can program a small number of CPLD's to post out just for members here but I don't want it to be something that is ongoing.


I want to replace the IDC edge connector(s) with Pin Headers. You can still get IDC pin header connectors so there is not much difference. Edge connectors were incredibly unreliable.

DIN is fine for the final version, perhaps dual footprint so either can be used ... 

For Proto:

VGA - DB15HD Female

Power - Barrel connector

Composite Video - RCA connector

Tape - RCA or 3.5mm

Keyboard - unsure 2x8 Pin header?

About keyboard - I don't have one so I will use a standard PC keyboard and take the electronics out leaving the moving parts and matrix membrain. I don't know how well the resistive membrain will work with the CPLD (or even if at all). I can remove the extra keys and blank them off with a cover but I don't know yet what to do with the 'clear' key. 

Generally I am thinking - minimum component count - small - cheap. Cheap is important for me as I am disabled and have no income.

  Are you sure? yes | no

Hacker404 wrote 05/02/2015 at 22:01 point

PS: These are all just ideas, I would like to know what others think. 

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates