• Please review our updated Terms and Rules here

NABUduino: a PCB for SD cards, PS/2 mice, and tinkering.

bdurbrow

Member
Joined
Dec 7, 2022
Messages
15
I have designed a PCB for putting an Arduino Nano on the NABU's expansion bus. It aims to provide several functions:

* An SD card interface, with the Arduino handling the FAT formatting of the SD card; and making blocks available to the NABU's CPU from within raw disk images - I figure that a modification to the boot ROM of the NABU will be needed as well as a simple BIOS for CP/M.

* A PS/2 mouse port. I added this because I'd like to build a paint program.

• Prototyping area for tinkering. I laid out a perf-board style area with breadboard style bus routing for power (5v & 12v) and ground lines; and there's also 8 unused pins on the Arduino Nano that can be used to shuttle signals to/from the NABU.

As my NABU hasn't arrived yet, I've been working from just the technical documentation available online; so this is totally preliminary... but, after I get it minimally tested (basically, no magic blue smoke escapes and I can send/receive data to/from the card) I intend to release the Gerbers on GitHub so that anybody can make one.

All the chips used are common, ubiquitous logic ICs, and available from the usual sources (DigiKey, Mouser, etc). Other parts needed are easy to source from eBay: female SIP sockets, DIP sockets, an Arduino Nano (or clone), some decoupling capacitors for the logic ICs (the PCB has pads for 5mm lead-spacing caps and is marked for 1uf - but any ceramic capacitor in that range will do), and a bussed resistor pack to keep the data bus on the NABUduino side from floating.

The bus interface implements two write registers and three read registers (as viewed from the perspective of the Z80). The address line mapping on the board puts these at offsets 0x08, 0x09, and for the read-only register 0x0A. The intent is that the high byte register be used as the command opcode or result status, and the low byte register be used as the arguments (or data) for a command. The read-only register exposes a couple of flip-flops that are used to synchronise the transfer of data between the Z80 and the Arduino (the bits get set when one side writes data to a register and cleared when the other side reads it, allowing the next byte to be sent). The low-byte registers' read and write signals also can be connected to the interrupt-capable pins of the Arduino with a pair of jumpers - although I anticipate that usually they would be connected; I did leave the option to disconnect that so that one or both interrupts could be used for something else.

Also, one of the Arduino pins is connected to the INT line on the NABU expansion interface, should one need to interrupt the Z80 for any reason.

There are several unused gates in the logic ICs on the board (two SR flip-flops, three inverters, and two OR gates); I tied the inputs to the gates to ground thru some easy-to-cut 0.01" traces; and also added pads adjacent to the chip to allow adding jumper wires to use the gates, if desired. Also, the unused address decode lines are also routed to pads, so that additional registers or other functions could be added in the prototyping areas.

The board is 85 x 165 millimeters, so it should fit nicely in the case of the NABU, only occupying one slot's worth of space. Not having a machine on hand to measure, however, does mean that I will still need to add mounting holes somewhere on the board - currently you'd have to depend on the female socket for the expansion header to hold the board... clearly not ideal if you want to have anything else in the machine besides a single NABUduino board.


NABUduino screenshot.jpg
 
This is another case, like the ROM emulator, that I'm very much interested in testing in my various evolutions of NABU PCs.
 
There is a paint program called PAINT POT. I think I may have the source for it. Giving it mouse support would be ACE!
 
I changed the synchronization mechanism a little bit tonight; and ended up adding a chip (74hc125), using an inverter gate that was previously unused, and using an extra couple of pins on the Arduino... however, it'll be easier to program. Instead of having an interrupt on the Arduino trying to manage buffering and sync with the Z80; I'm just going to poll the flip-flop's state thru Arduino pins D4 and D16. The Z80 side of things remains the same, however.

Unused Arduino pins are now A4/D18, A5/D19, A6, A7, D2, and D3 - the latter two being the Arduino's external interrupt pins. There's also two unused tri-state buffer gates from a 74hc125 now available for tinkering.
 
I'm not very well-versed on buffers, but I'm trying to make my own design to interface an ESP32 with a Z80 that's sort of based on this Z80 interface for SD cards (and SPI) so I'll need to learn a lot more about them quickly.

Why did you use the 74125 instead of the (to me) more common 74245?
 
Several reasons; which may not apply to your design.

1) At the time it was cheaper. FWIW, right this second Digikey has over 12k of them in stock; and mouser has over 3.8k of them.

2) It's smaller and when I added the sync flop flop & its bus interface (the 74xxx125 in question) I was running out of board space in that area (using a '245 would have required moving some stuff around).

3) It's more flexible, as it's gates' enable pins are independent. This principally applies to the unused gates in the package, so that they are available for tinkering in the prototyping area.


The interface that I have used is as complex as it is because I wanted the Arduino side to be completely asynchronous (as I don't have an SPI controller available - that got used by the SD card) and I wanted to have flow control be separate from the data channel. Also, the interface is expandable to handle extra hardware in the prototyping area.

It's possible to implement a much simpler design if you are willing to forgo expandability, some data/control separation, and if you have a SPI controller on the microcontroller available. If you are willing to do the SPI clock generation mostly in software, you can get it down to just a couple of chips.


As for my board; it's soldered together, and the software for an initial test is 98% done... I hope to have some results tomorrow or the next day. This, of course, assumes that another tree doesn't get blown down....
 
Version 1.0b is now at JLC being manufactured; along with a couple of other boards.

* Fixed a missing trace for the power connection to the prototyping areas.
* Added indications to the prototyping areas of what pads were bussed together.
* Switched to 74hct165 shift registers to eliminate a timing issue (the 74hct165 has asynchronous parallel load).
 
Will this be able to coexist with the floppy controller project?
A different adapter board would need to be made; as the standard one for the floppy controller occupies all four slots. When they did the floppy controller board, they reorganized the signals on the 30 pin connector; consequently you can't just plug a NABUduino into the floppy adapter's 30 pin connector.

If you want, I can cook one up; it's a really simple board.
 
I'm about to send 1.0c off to JLC; the difference being that I added a diode so that the Arduino doesn't try to back-feed the NABU 5v power from the USB connection when the NABU's power is turned off.

1.0b - what's in the NABU right this second - works OK, but I had to bodge in that diode onto the Arduino itself and the result is a bit ugly. The new revision of the board just puts pads for that on the board itself.

This should be the final revision of the board; after I do a final test of 1.0c I'll post Gerbers on GitHub.
 
It needs to be 5v compatible (so, ATMega328 or LGT8F328P) with the standard Nano pinout.

I've been using these of late:

That's an Amazon link, but they can also be found elsewhere (eBay, etc).

They're relatively cheap, currently available, and run twice as fast as a standard ATMega328 (so, 32Mhz instead of 16Mhz).

This is the Arduino core that I've been using:
 
OK, the board files are now up on GitHub, along with a simple demo program that demonstrates the mouse. Not currently implemented in the firmware or demo program is the SD card; that will be coming as soon as I get it done.

 
Thank you very much for the nabuDUINO package, @bdurbrow . I quickly checked the contents and put it with the wrapped NABUs. I'll be pulling it out to try in a few weeks, when I plan to do the repair cycle on a couple of my crankier NPCs.
 
Oh, good - it arrived.

I'm hoping to get some time this weekend to work on the SD card support for it...
 
Back
Top