Cloning a Tandy TRS-80 Model 1

[Rick-S]

GK,

Any updates on this project or did it get put on the back burner for now?  I'm just curious.

[GK]

Sorry for the lack of updates - I've just been too busy with too many other things or not particularly motivated & only just got back onto the electronics bench again the other day. I have the breadboard prototype disassembled now and a couple of boards are out for production. Maybe some proper progress again in a week or two.

Hi GK,

I came across your TRS-80 Model I development post in my search for a graphics font. Impressive work indeed.

I was wondering if you would be able to share a copy of the graphics character "rom". I saw you posted a hex file of the standard character set but you advised that the graphics character set is "generated". Would you still be able to do a dump of this character set and share it? Alternatively, if thise is generated by Z80 code, would you mind sharing the code?

I have found heaps of trs-80 font resources on the net but they are all font conversions to ttf or similiar. It's seems nearly impossible to get these back to a bit map rom.

Thanks for your time.

I'm chasing these to add a graphics character set for 128 to 256 character modification:

https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:vdu:start
https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:vdu:fonts

Regards Phillip

Not sure if you're still tuning in, or if the file is really of much use to you, but attached is the graphics character section of the character ROM binary file, as described way back in reply #15. It's a .bin file but I had to relabel it .txt so that the forum would let me upload it.

[Rick-S]

Sorry for the lack of updates - I've just been too busy with too many other things or not particularly motivated & only just got back onto the electronics bench again the other day. I have the breadboard prototype disassembled now and a couple of boards are out for production. Maybe some proper progress again in a week or two.

No problem, I fully understand how interest shifts from one thing to another.   Will you make the boards or board files available once you have them proven out?   Thank you for the update, and looking forward to seeing your production boards up and running.

[GK]

The intent is to publish the project and all of the Gerber files, ROM images, etc, on my website as I did with my PET2001 clone. That alone is for the most part a thankless enough endeavor and I'm not going to be supplying actual boards or any form of kit.
 

[Rick-S]

That is great.  I am excited to know you will make the files available.  Thank you so much for all your endeavors to promote this hobby and to revive these old machines with a modern build.

[GK]

I've made a start on the video generator board. The rest of the parts required are scheduled to arrive tomorrow. Now that I have the board in front of me it's apparent that the ground plane cross hatching would have needed to be a few times coarser to give the board that kind of vague retro feel that I was seeking.

The two 90 degree potentiometers on the left hand side of the board are the vertical and horizontal raster positioning controls. Annoying, although limited stock is still available, the pot model I selected has since gone obsolete. I'll have to modify the layout for new pots before providing the Gerber files.

[GK]

Here is the completed CPLD matrix decoder logic for the PS/2 keyboard interface. Did it in the graphical entry method instead of AHDL just for kicks. I have both Quartus II and the old Baseline 10.2 software (as shown), but for simple CPLD logic design and simulation I much prefer to still use the latter - it's just so much nicer to use than the bloated Quartus suite with all of its stupid million warning messages on every compile for a whole host of crap I don't need and am not interest in, the comparatively crappy pin assignment editor, etc, etc.

Anyway, the whole thing *just* fits into 64 macro cells, so I can put it into a relatively small and budget part; namely an EPM7064AETC44.

https://au.mouser.com/ProductDetail/Intel-Altera/EPM7064AETC44-10N?qs=sGAEpiMZZMuJNuO2s1hGZPESq8W5eU3HqWG75xdVK0Q%3D

Stepping over to the dark side here as this is a 2.5V - 3.3V part, but the options are limited here because the old 5V variants of these CPLDs are rapidly becoming unobtainable now. Fortunately EPM7064AE inputs are always 5V tolerant, regardless of the core and VCCIO supply voltage and the output levels are TTL-compatible on a 3V3 VCCIO.

Each of the 52 bits of the shift register represents the status of one keyboard key, so this completely solves the problem of supporting multiple simultaneous key presses, as discussed earlier in the thread. There are logically only 52 out of the 53 actual keys because two of those 53 are the left and right shift keys, which were just wired in parallel and not differentiated. The serial data output pin is provided as a diagnostic aid only.

[kizmit99]

It makes me happy to see you back on this 

Unless I'm missing something, isn't your keyboard decoder going to suffer from a storm of glitches as the PIC changes the keys pressed?
I think you need another set of registers (following the shift-register outputs) that will present the new keyboard state to the decoder array as one atomic change.

Question for you -- have you tried generating a <shift>+@ with your keyboard design?  I've discovered that I have an issue with that style of key combination and I'm curious whether yours has the same problem.

The basic issue is when I try to type a shifted version of a key that on the original keyboard was not shifted, but on the PS/2 keyboard is shifted.
The "@" key on the original keyboard was its own key, on the PS/2 keyboard you have to type <shift>-2 to get "@" (so the shift key is overridden back to off in this case), but on the original keyboard I could type <SHIFT>+@ and both keys are asserted.  With my approach (and I suspect yours) it becomes an unachievable combination.

I was considering implementing something along the lines of: If BOTH shift keys are held down this is an indication that <SHIFT> should be asserted even if the key-mapping indicates it should be overridden to not-asserted (but continue to assert the key that the mapping otherwise expressed).  I haven't tried this approach yet, and I'm not sure it would be very intuitive even if I did implement it.  I'm hoping a simpler cleaner approach surfaces eventually...

[GK]

It makes me happy to see you back on this  :-+

It's nice to see that someone is paying attention to the finer details :)

The current scheme is to quickly load the shift register after being triggered by the rising edge of !KEYBOARD, before the next polling interval, so to avoid any shift register activity while the keyboard is being scanned. If I could fit an additional 52 DFFs into the CPLD I'd much prefer to do it that way, but a barely have enough room for even a few more basic gates.

I can't remember the finer details off the top of my head right now, but I'm pretty sure my keyboard interface code can handle the situation you describe. In my PET clone both shift and the key mapped to @ have to be asserted simultaneously to give one of the graphics characters.

The video generator is now up and running - just giving a random garble of screen characters from the random RAM contents at the moment as there is no processing system connected. The next step is to get back to the breadboard with a Z80 plugged into it and have the system back up and running again, but with much, much less rats nest and, hopefully, rock-solid stability. I still want to do a little more circuit design verification/testing with something more manageable before committing to the final motherboard PCB layout.

[wilfred]

If you use a cpld that's fine. But it will limit access to people who want to go to the effort of programming them. An Arduino would be accessible to more people.

Still an interesting project.

[kizmit99]

The current scheme is to quickly load the shift register after being triggered by the rising edge of !KEYBOARD, before the next polling interval, so to avoid any shift register activity while the keyboard is being scanned.

Ah - tricky...  I assume you've done the calcs to verify the PIC (I think that's what you were using for the PS/2 interface) can detect the rising edge and perform the 52 shifts before the Z80 can get back around to checking the keyboard again?  That just seems like it would require a lot of cycles, and I've found that the Z80 (even at 1MHz) can execute quite a few instructions in the time it takes a small microcontroller to respond to an interrupt and start bit-banging.

I can't remember the finer details off the top of my head right now, but I'm pretty sure my keyboard interface code can handle the situation you describe. In my PET clone both shift and the key mapped to @ have to be asserted simultaneously to give one of the graphics characters.

Once you get this all hooked up again, I'd really appreciate if you would take a quick look.  Thanks in advance!

[GK]

That just seems like it would require a lot of cycles, and I've found that the Z80 (even at 1MHz) can execute quite a few instructions in the time it takes a small microcontroller to respond to an interrupt and start bit-banging.

Yes, that is true, but there is heaps of time between keyboard polls, so it isn't an issue. Anyway, there is another alternative that will (should) fit into the CPLD. I can delete the entire shift register and replace it with a parallel-input register/latch. I have enough I/O pins left over to delete the serial interface and replace it with an 8-bit, addressable interface for programming. Not as elegant as a simple serial uC interface, but it does away with having to monitor & sync to !KEYBOARD. I'm busy with the breadboard right now, but I think I'll give this a whirl after.

[GK]

Just, finally, plugged in the last wire not more than 20 minutes ago. Double checked, crossed fingers, plugged in power lead................... So satisfying to see the screen go blank momentarily and the READY prompt appear.

Running bare bones ATM with no I/O, apart from the video display. Next up is get my prototype keyboard interface soldered up on perfboard. I have a bunch of old 5V EPM7064 CPLDs here in the 44 pin PLCC package, which are easy to prototype-build with. It's bedtime again now though.

[GK]

The video board schematic.

[GK]

That just seems like it would require a lot of cycles, and I've found that the Z80 (even at 1MHz) can execute quite a few instructions in the time it takes a small microcontroller to respond to an interrupt and start bit-banging.

Yes, that is true, but there is heaps of time between keyboard polls, so it isn't an issue. Anyway, there is another alternative that will (should) fit into the CPLD. I can delete the entire shift register and replace it with a parallel-input register/latch. I have enough I/O pins left over to delete the serial interface and replace it with an 8-bit, addressable interface for programming. Not as elegant as a simple serial uC interface, but it does away with having to monitor & sync to !KEYBOARD. I'm busy with the breadboard right now, but I think I'll give this a whirl after.

Okay, I managed to get the parallel register version to fit into 64 macro cells, but, again, only just and the uC programming interface is a little more primitive as I couldn't fit in any address decoding. The 52-bit "key status" register is programmed in 8-bit chunks (from inputs D[7..0]) with individual strobe/latch input pins (STROBE[6..0]) for each chunk. That gives a 15-line uC interface for programming. A 3-to-7 line decoder for strobe addressing just takes up too much additional logic.

In AHDL this time:

Code: [Select]

TITLE "Keyboard matrix decoder";
% Tandy TRS-80 Model 1 %

SUBDESIGN MATRIX
(
D[7..0] : INPUT; -- Key status register data inputs
STROBE[6..0]         : INPUT; -- Key status register latch control inputs

ADDRESS[7..0]         : INPUT; -- Address bus inputs
DATA[7..0] : OUTPUT;                -- Data bus outputs
KEYBOARD : INPUT; -- Output enable for data bus outputs (active low; Hi-Z when high)
)

VARIABLE

KEY[51..0] : LATCH;         -- 52-bit key-status register
Q[7..0] : NODE;         -- Working node for data bus outputs
TRIBUS[7..0]         : TRI_STATE_NODE;         -- Tri-state node for data bus outputs

BEGIN

% Connect tri-state data bus outputs to !KEYBOARD %

TRIBUS[0] = TRI(Q[0], !KEYBOARD);
TRIBUS[1] = TRI(Q[1], !KEYBOARD);
TRIBUS[2] = TRI(Q[2], !KEYBOARD);
TRIBUS[3] = TRI(Q[3], !KEYBOARD);
TRIBUS[4] = TRI(Q[4], !KEYBOARD);
TRIBUS[5] = TRI(Q[5], !KEYBOARD);
TRIBUS[6] = TRI(Q[6], !KEYBOARD);
TRIBUS[7] = TRI(Q[7], !KEYBOARD);

DATA[7..0] = TRIBUS[7..0];

% Key matrix %

Q[0] = ADDRESS[0] & KEY[0] # ADDRESS[1] & KEY[8]  # ADDRESS[2] & KEY[16] # ADDRESS[3] & KEY[24] # ADDRESS[4] & KEY[27] # ADDRESS[5] & KEY[35] # ADDRESS[6] & KEY[43] # ADDRESS[7] & KEY[51];
Q[1] = ADDRESS[0] & KEY[1] # ADDRESS[1] & KEY[9]  # ADDRESS[2] & KEY[17] # ADDRESS[3] & KEY[25] # ADDRESS[4] & KEY[28] # ADDRESS[5] & KEY[36] # ADDRESS[6] & KEY[44];
Q[2] = ADDRESS[0] & KEY[2] # ADDRESS[1] & KEY[10] # ADDRESS[2] & KEY[18] # ADDRESS[3] & KEY[26] # ADDRESS[4] & KEY[29] # ADDRESS[5] & KEY[37] # ADDRESS[6] & KEY[45];
Q[3] = ADDRESS[0] & KEY[3] # ADDRESS[1] & KEY[11] # ADDRESS[2] & KEY[19] #                        ADDRESS[4] & KEY[30] # ADDRESS[5] & KEY[38] # ADDRESS[6] & KEY[46];
Q[4] = ADDRESS[0] & KEY[4] # ADDRESS[1] & KEY[12] # ADDRESS[2] & KEY[20] #                        ADDRESS[4] & KEY[31] # ADDRESS[5] & KEY[39] # ADDRESS[6] & KEY[47];
Q[5] = ADDRESS[0] & KEY[5] # ADDRESS[1] & KEY[13] # ADDRESS[2] & KEY[21] #      ADDRESS[4] & KEY[32] # ADDRESS[5] & KEY[40] # ADDRESS[6] & KEY[48];
Q[6] = ADDRESS[0] & KEY[6] # ADDRESS[1] & KEY[14] # ADDRESS[2] & KEY[22] #                        ADDRESS[4] & KEY[33] # ADDRESS[5] & KEY[41] # ADDRESS[6] & KEY[49];
Q[7] = ADDRESS[0] & KEY[7] # ADDRESS[1] & KEY[15] # ADDRESS[2] & KEY[23] #                        ADDRESS[4] & KEY[34] # ADDRESS[5] & KEY[42] # ADDRESS[6] & KEY[50];

% 52-bit key status latch strobe and data input connections %

KEY[7..0].D = D[7..0];
KEY[7..0].ENA = STROBE[0];

KEY[15..8].D = D[7..0];
KEY[15..8].ENA = STROBE[1];

KEY[23..16].D = D[7..0];
KEY[23..16].ENA = STROBE[2];

KEY[31..24].D = D[7..0];
KEY[31..24].ENA = STROBE[3];

KEY[39..32].D = D[7..0];
KEY[39..32].ENA = STROBE[4];

KEY[47..40].D = D[7..0];
KEY[47..40].ENA = STROBE[5];

KEY[51..48].D = D[3..0];
KEY[51..48].ENA = STROBE[6];

END;


[kizmit99]

Parallel loading of the state registers should prevent you from getting spurious key-presses at the Z80 side, even if you happen to change just as the Z80 is scanning, since from it's perspective it would just be the same as the person typing (which is obviously async to the scanning).

To me, it seems an almost perfect interface from the PIC would be 6 'address' lines, a single state line, then a strobe to load the state of a single register at a time.  It would only be 8 lines, and in most cases the PIC would only need to modify a single key-state bit at a time anyway (sometimes 2 or 3, but mostly just one key going up or down).  I'm not familiar with your CPLD, but since you couldn't fit an extra 3:8 decoder into it, I suspect it would support the ability to individually address each state-bit either (effectively a 128bit LUT in front of each register).

[GK]

  I'm not familiar with your CPLD, but since you couldn't fit an extra 3:8 decoder into it, I suspect it would support the ability to individually address each state-bit either (effectively a 128bit LUT in front of each register).

Not even close unfortunately. The 3-7 line decode alone bumped the compile from 64 macro cells to 69. These CPLDs are just really inefficient at LUTs. Anyway, the design is now complete and I think I'm happy with it. Like I did with my PET clone, I've designed the keyboard interface as a stand-alone PCB which could interface a PS/2 keyboard to any TRS-80 model 1, not just my clone and the motherboard itself will be compatible with an original keyboard (not that I have an original keyboard).

The fitter didn't give me the luxury of assigning my own pinout to a useful degree due to the fact that the whole thing is such a tight fit, so the CPLD "wiring" is a bit of a jumbled mess with a more or less random pin assignment. Who said you cant have power planes with just 2 layers? 

[German_EE]

I guess that this will be a US layout PS2 to Tandy interface?

[GK]

I guess that this will be a US layout PS2 to Tandy interface?

I don't think that it should make any difference as far as the PS/2 serial protocol is concerned 

[German_EE]

Well, just as an example, shift-9 produces a ) and shift-3 gets me a § on my German keyboard but on the International US layout shift-9 produces ( and shift-3 is #.

This could get confusing.

[GK]

Well, just as an example, shift-9 produces a ) and shift-3 gets me a § on my German keyboard but on the International US layout shift-9 produces ( and shift-3 is #.

This could get confusing.

AFAIK the make and break codes sent by the keyboard are standardized to the characters, not the character positions on the keys.

[GK]

Phew! One marathon weekend session and the motherboard is done (pending checking/tweaking).

[GK]

Schematics...........

[Rick-S]

Wow, beautiful.  Thank you so much for all you do for the community.  You have an amazing amount of patience to do what you do.  I'm in awe 

[GK]

No worries 

Sat back to review the final design and made a few tweaks and error corrections. That PNP in the power supply labeled 2N3055 should be MJ2955. The TO-3 pass transistor / hybrid regulator for the +5V rail is just a homage to an old-school computer regulator. Aavid-brand TO-3 heatsink part #506007B00000G looks just like the heatsink originally used in the TRS-80 too.

I also deleted the two 74HCT00 NAND gate ICs on page 2, which multiplex the chip-select lines from the address decoder ROM for user-selection of BASIC Level 1 or Level 2 and 16k or 48k of RAM. I can instead achieve the same function just by page addressing the address decoder ROM from the switch inputs instead.

Also added a TVS diode across the contacts of the tape drive motor switching relay.