DigicoolThings Forum

Editor wrote: ↑Wed May 29, 2024 7:58 pm

lenzjo wrote: ↑Wed May 29, 2024 12:02 pm I'm using an ATtiny 26 to decode the PS/2 to a parallel output with handshaking. It's not my design it's from here. I thought about using discrete TTL after seeing Ben Eater's version. But then he had look-up tables to translate the key presses to ascii. Didn't really like that, and so started looking around for a better solution and found Darryl's answer to it. I'm not proud, why re-invent the wheel especially as I haven't the time to learn AVR assembly when 6809 is already giving me a headache

It sounds like we've gone down the almost the same design thinking path! I don't mind writing the 6809 code, but it was more the revelation that this function (PS/2 down/up scan codes to ASCII translation), doesn't really belong on out "retro true" recreations!

Although I enjoy microcontroller programming, and have quite a few lying around, I also don't believe in re-inventing the wheel. Especially if it takes your focus away from the core project at hand. I also rationalised, by noting that a "modern" PS/2 Keyboard already has a microcontroller in it, so effectively we are just translating with another microcontroller, so that the "real" Retro Keyboard input starts at the ASCII parallel (or serial) input port!

I landed on a similar, but AVR based, Go4Retro PS/2 Encoder

lenzjo wrote: ↑Wed May 29, 2024 12:02 pm I was thinking to hook it up to a 6522 for the handshaking and it can generate an interrupt for each key press. This will be part of a "system i/o" card which will also tentatively have an SCC2691 ACIA as it can go to 6Mhz. The 6522 has a couple of timers so it can also replace the 6840.

Yes. I was then also at the same point of deciding how best to implement the interrupt driven support. First thinking I'd design a simple TTL based interrupt latch and tri-state buffer to read in and clear the interrupt latch.
Then, I decided that for the PCB real estate used, I may as well just use a DIL40 parallel I/O chip (i.e. PIA, on the basis of a Parallel ASCII keyboard input, like I used in the old days with a MM5740 Keyboard Encoder).

However, where I ended up was thinking along the lines of a MC6821 PIA (noting that we don't need a VIA / timer for a keyboard interface).
This approach also means we can insert a currently in production WDC W65C21N PIA, which is actually good for up to 14MHz, is plug-in compatible with the MC6821 PIA, and therefore well matched for both the 6809 CPU Card and the 6502 CPU Card (with a faster WDC W65C02 CPU).

Where I'm currently at (as of last night), is thinking that if I have a dual 8 port PIA, on a PS/2 + CF Card, do I interface the CF through port B, or does that just give no real advantage? The jury is still out on this, as I look into further.

On a related note, I intentionaly didn't use the 6522 VIA on my initial Motorola I/O Card, fundamentally because it was intended to be a true Motorola based I/O Card, hence the 6821, 6840, and 6850. My intention was to eventualy make a similar WDC / MOS based I/O Card which instead features a 6522 VIA and a 6551 ACIA.

I think I recognise my lot in life now, it's to cheer you guys on!

Editor wrote: ↑Wed May 29, 2024 7:58 pm Where I'm currently at (as of last night), is thinking that if I have a dual 8 port PIA, on a PS/2 + CF Card, do I interface the CF through port B, or does that just give no real advantage? The jury is still out on this, as I look into further.

Not that a mouse or trackball really fits in with retro computers, but how hard would it be to amalgamate as many forms of input on the one interface card (i.e. kb & mouse, maybe even some kind of supplemental data I/O for robotics/electronics projects) and separate out mass storage options for it's own card? A CF Card is definitely a win for peeps like me of course, so happy to concede the point if I don't know what I'm talking about here...

Also curious, would such a solution still support a ps/2 keyboard (and mouse) interface and/or headers? Inquiring minds, and all that... I guess it totally shows I don't know what you're all discussing here, doesn't it...?

Oh, I only just noticed this thread. So I've been playing with using a microSD interface which I noticed at one stage was available for a revamped version of the SWTPC 6809 that built by Corsham Tech and attached to their 6821-based parallel board (much like the MECB I/O card) and connected to an Arduino to do much of the grunt work. Unfortunately the owner of the company passed away and so none of these devices are available anymore. However, I found a circuit diagram and board online (https://github.com/eduardocasino/sd-car ... /tree/main) but it relied on SMD - which I dread using (my eye-sight just can't deal with it). The design itself is quite simple and I noted that many of the SMD bits were not really needed if off-the-shelf modules are used. So I took a somewhat lazy approach by replacing the microSD part of the interface to one of these: https://core-electronics.com.au/microsd ... board.html and the optional RTC with one of these: https://core-electronics.com.au/adafrui ... akout.html. This actually avoided any additional electronics (apart from the LEDs and associated resistors which I just used standard flavours of and a 4-pin DIP switch). Everything else was literally just a (alert messy) wiring exercise (with a bit of changing to match the pin assignment of the MECB parallel I/O port as opposed to the Corsham parallel I/O card).

So far I have only built a prototype of this just to make sure the simplified interface works and that seemed to be the case and was able to boot up FLEX from a 32 GB microSD that I had. The software on the Arduino (which was thankfully made publicly available by Corsham Tech: https://github.com/CorshamTech/SD-drive) allows many disk images to be stored on the card and there is a simple configuration file that can be used to select which disk image to use (the DIP switch can also be used to select an alternate set of disk images). The software also deals with the ejection/insertion of the card, reading of the RTC and also reading of the option switch setting.

I would really love to have a board made for this but I haven't used PCB layout software for decades so I need time to look into it (I have made a simple circuit diagram of the new wiring in KiCAD though). If I do get to that stage I would like to keep the original DIL header socket but also add an additional one for the MECB (just to make it backward compatible with the original Corsham design).

Seeing the above discussion, it also makes me realise that it should be possible (I think) to make a PS/2 keyboard interface as well. I have seen this done with Arduino's before (e.g. https://www.instructables.com/Connect-P ... o-Arduino/) and assuming the appropriate pins are still available the key-press could be sent via the same parallel interface that is used to pass the RTC, option setting and microSD data status and data transfer (the protocol is relatively simple and I believe it should be possible to extend for this purpose). Doing so could kill three birds with one stone (not that I have anything against birds).

epaell wrote: ↑Wed Jun 26, 2024 11:56 pm Oh, I only just noticed this thread. So I've been playing with using a microSD interface which I noticed at one stage was available for a revamped version of the SWTPC 6809 that built by Corsham Tech and attached to their 6821-based parallel board (much like the MECB I/O card) and connected to an Arduino to do much of the grunt work. Unfortunately the owner of the company passed away and so none of these devices are available anymore. However, I found a circuit diagram and board online (https://github.com/eduardocasino/sd-car ... /tree/main) but it relied on SMD - which I dread using (my eye-sight just can't deal with it). The design itself is quite simple and I noted that many of the SMD bits were not really needed if off-the-shelf modules are used. So I took a somewhat lazy approach by replacing the microSD part of the interface to one of these: https://core-electronics.com.au/microsd ... board.html and the optional RTC with one of these: https://core-electronics.com.au/adafrui ... akout.html. This actually avoided any additional electronics (apart from the LEDs and associated resistors which I just used standard flavours of and a 4-pin DIP switch). Everything else was literally just a (alert messy) wiring exercise (with a bit of changing to match the pin assignment of the MECB parallel I/O port as opposed to the Corsham parallel I/O card).

So far I have only built a prototype of this just to make sure the simplified interface works and that seemed to be the case and was able to boot up FLEX from a 32 GB microSD that I had. The software on the Arduino (which was thankfully made publicly available by Corsham Tech: https://github.com/CorshamTech/SD-drive) allows many disk images to be stored on the card and there is a simple configuration file that can be used to select which disk image to use (the DIP switch can also be used to select an alternate set of disk images). The software also deals with the ejection/insertion of the card, reading of the RTC and also reading of the option switch setting.

I would really love to have a board made for this but I haven't used PCB layout software for decades so I need time to look into it (I have made a simple circuit diagram of the new wiring in KiCAD though). If I do get to that stage I would like to keep the original DIL header socket but also add an additional one for the MECB (just to make it backward compatible with the original Corsham design).

Keep going @epaell, don't stop now!!

epaell wrote: ↑Wed Jun 26, 2024 11:56 pm Seeing the above discussion, it also makes me realise that it should be possible (I think) to make a PS/2 keyboard interface as well. I have seen this done with Arduino's before (e.g. https://www.instructables.com/Connect-P ... o-Arduino/) and assuming the appropriate pins are still available the key-press could be sent via the same parallel interface that is used to pass the RTC, option setting and microSD data status and data transfer (the protocol is relatively simple and I believe it should be possible to extend for this purpose). Doing so could kill three birds with one stone (not that I have anything against birds).

If you manage to pull off a cunning stunt like that, might I put in a request for a set of ps/2 internal headers in your design as well?