Electronics > Projects, Designs, and Technical Stuff
Cloning a Tandy TRS-80 Model 1
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:
--- Quote from: kizmit99 on June 30, 2019, 04:03:23 pm ---It makes me happy to see you back on this :-+
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version