Simple DIY I/O Cart

Page 2/2
1 |

By zPasi

Champion (357)

zPasi's picture

07-03-2019, 20:50

This is ver 0.1, no guarantees! Smile

link

Edit: as a link, an image tag didn't seem to work.

By zPasi

Champion (357)

zPasi's picture

07-03-2019, 20:54

NYYRIKKI wrote:

BTW if you want to see 8255 implementation on a cartridge, take a look ie. BEER IDE that implements IDE-bus with this chip... or Sony HBI-55 that is very similar device, but connects the GPIO pins to SRAM chip instead of IDE-device... I remember there was also very detailed article of building EPROM programmer using 8255 in MSX MAGAZINE issues 07/1990 - 02/1991

Thanks!

By Wlcracks

Champion (316)

Wlcracks's picture

08-03-2019, 07:26

Cool thanks!

By zPasi

Champion (357)

zPasi's picture

16-04-2019, 21:27

Even more scary looking circuit!

Video tells more than 1024 words: video

This is basically the same circuit, but now there is an Arduino after that 373 buffer / latch chip!

The Arduino gets the same LE (latch enable) signal than the 373. There is a FALLING type pin interrupt in the Arduino code, so the Ardu gets the latched value right after the 373 has stored it. I'm not sure if the Arduino could manage even without the latch, may test that later on.

Then there is an LED display where the Ardu writes to what it is getting from the MSX. Some double-triggering occurs, I will test with a Schmitt trigger when I have the time.

By RetroTechie

Paragon (1563)

RetroTechie's picture

17-04-2019, 17:13

A 82(C)55 or similar chip has the advantage that its I/O pins have a programmable direction (input or output). Useful when you don't know in advance whether you'll use lots of outputs + few inputs, just a few outputs + lots of inputs, or in between. Discrete latches fix that in advance, but are simpler from programming point of view (and cheaper). So it depends on intended usage.

Bi-directional transfer using latches / bus buffers etc is possible, but then complexity of the circuit will quickly balloon to the point where eg. a 8255 is easier.

I'd suggest to include a so-called magnitude comparator (eg. a 74HCT688) in the address decoding. That way, you can use some jumpers / DIP switches to move around the I/O address as desired. Perhaps even to in-use I/O addresses (write-only!), allowing you to 'snoop' on values written to other MSX peripherals.

By zPasi

Champion (357)

zPasi's picture

17-04-2019, 21:21

RetroTechie wrote:

Bi-directional transfer using latches / bus buffers etc is possible, but then complexity of the circuit will quickly balloon to the point where eg. a 8255 is easier.

I'm a little concerned of availability of that (obsolete?) chip. I do have one of them, but what if I'll want to build 10 boards, or 100? Probably still available on eBay and AliExpress, but how about after 5 - 10 years?

Quote:

I'd suggest to include a so-called magnitude comparator (eg. a 74HCT688) in the address decoding. That way, you can use some jumpers / DIP switches to move around the I/O address as desired. Perhaps even to in-use I/O addresses (write-only!), allowing you to 'snoop' on values written to other MSX peripherals.

I've got the same idea, comparators and DIP switches. That 74HCT688 seems like a good choice. Thanks!

By zPasi

Champion (357)

zPasi's picture

18-04-2019, 12:10

Made some more testing. Turns out that a Schmitt trigger is not necessary: changed pin interrupt mode from FALLING to RISING, that was enough to get rid of the double-triggering.

The circuit is built so that the LE signal goes high when data is ready, and then the 373 latches it. In falling edge the arduino should be able to read the data from the 373. And it does, but double-triggering occurs. I guess the falling edge just is too loose or something.

The 16 MHz 'duino is fast enough even for fast OUTI loop! Of course only that far when my ring buffer (on the 'duino side) is not overflooding. If I was building a disk interface or something, some protocol with a "wait" signal would be required.

Page 2/2
1 |