Z80 Homebrew Computer - fault finding

[C]

If you want to achieve an 80's tech SBC you can.
I have an 80-s tech computer. It has a parallel printer port, some serial ports, floppy disk drive bus ports & a SCSI port. 
Great software & hardware is what makes a great computer.

Buffer
Think of a serial or parallel printer. For some compute tasks the Z80 can generate characters much faster then the printer can print. But for some programs or places in a program the Z80 is slower then printer.
So before talking electronics lets look at this problem. A buffer in printer can help here. A buffer in Computer can help. But this is not a free change. One software error and you have printer printing a low of garbage. A good setup looks at all the problems created when a buffer is added and has ways to the best it can to reduce or fix the problem. When Printing garbage you want to stop the print & clear the buffers. The point I am trying to make is adding something like a buffer is not free and needs more control options. Most improvements are the same, gain something & loose something.

Hardware handshake
Look at serial ports. One big difference between a nano and your Z80 SIO is that your SIO can use RTS & CTS to stop receiving more characters, This is simple. For software, the common method is XON & XOFF. This requires transmitting these characters before characters in the buffer when needed, more complicated. A lot of nano programs only work because the PC only sends a small amount of characters before waiting for a response from nano.

So best choice is to have hardware that will handle speed difference between the two ends. This does not prevent using the other two ways above. You could have all three working.

Speed difference
Now You caught that a nano will be slow to respond. You might not have caught that even a PC will be slow to respond. The way to handle this is to shift to a request & response method.
So at low level you want hardware that can send & receive with out loss and a higher level doing requests with delayed response

9-bit data
Now you have already seen the hints of what is needed, you are missing details. For Z80, you need to keep it simple or you loose a lot of computing time. When you look at the connection of SIO to Z80, what are you seeing?
Each SIO port is using two addresses. One for command/status & second for data. You have 9-bits to/from the SIO so that you have 8-bit transparent data &  8-bit transparent command/status.
To have a remote SIO, you need to send/receive this 9-bit data. For a picture think of this.
Your Z80 is going to use a SIO attached to a second Z80.
Your Z80 using the serial port of the nano.
You have already been using something like this. On PC's, they have stopped using direct connected serial ports and are using USB connected serial ports. The PC is remote controlling the USB device that acts like a serial port. An as you can see if done right, you can have many. To have many, you need more bits so you can select which device should work with the 9-bit data.

So far we have buffers, 9-bit data & handshake signals for flow control.
You need a send path and a receive path.

Here it might be good to say that a 8-bit asynchronous serial interface is not a good choice to send this 9-bit data. You only have one choice of adding software on both ends of connection to get the needed 9-bit transparent data. A big software overhead for Z80.

Now lets go back an look at SCSI. First versions were very simple.
Back in the day a SCSI hard drive controller could normally attach to 4-hard drives.
A SCSI bus could connect 8 devices with one being my old computer. So my old computer could connect to 28 hard drives. But notice a SCSI bus connects to devices. You could have a device that was a hard drive & floppy drive controller.
All kinds of things could be connected to the SCSI bus, drives, scanners, printers, terminal servers and more. in addition you could have a 8 device network.
 
Now you might like to know that first SCSI hard drive controllers used a Z80 on controller board.
My Z80 uses 2 x 74xx273, 2 x 74xx240, 1 x 74xx132, 1 x 74xx74 & 2 x 74xx06 for SCSI interface. The boot rom is 512x8

So what makes SCSI so powerful of an interface?
It is an open collector bus(74xx06). This lets many devices use same signal line at same time. All devices would wait for the slowest device when needed.
The C/D signal could be thought of as the 9-bit from above.
Has handshake signals for speed difference between devices.
Has I/O signal for bus direction.
Has additional signals to handle problems and errors.
A total of 9 signals in addition to 8 for data.

Now one trick my Z80 uses is that it actually sends 9-bits with each z80 out instruction. A0 becomes the 9th bit(C/D). This makes software simpler and also data faster on the bus. Using a PIO would be a little slower.

When sending a SCSI command it is specifying WHO, WHAT WHERE, This is a request.
This is just a stream of bytes with C/D set for control.
You could think of Packets.
For ethernet, you have a known packet starting point, so you can assume that first bytes are control. The control bytes can then specify if more control bytes follow and where and how much data is in packet.
For HDLC, SDLC you have a unique frame start bit sequence which again gives you a packet.
For CAN bus you also have a unique packet start bit sequence.
Do I need to state that USB is packets also.

A packet is just a stream of bytes and is not normally hard to add more bytes to control part of packet.

So by coping SCSI bus and ideas you have something to follow to make a powerful interface to your Z80 <-> nano while handling problems.
Both nano & Z80 can use interface status to decide when other end is ready so no Z80 wait states are needed. Both can continue to run instructions while waiting.

You can expand adding more Z80's, NANO's or other to SCSI bus. 

Now the software side.
Back in the old days to read/write storage you needed to specify what drive, what track, what side, what sector. Each of these was a register in the controller, each had an IO address. For SCSI this becomes a byte stream. Instead of writing to an Output port you write each byte of data in a specific memory location that will be part of the command stream. When this array of data is ready you just copy the bytes to SCSI port.
Today with smarter drives it's what drive & what logical block address.
SCSI used logical blocks for storage from the start.

As with many things, there are many ways of doing things. If you understand the concepts, then you have more options.
I showed one way to have 16k blocks of memory. There is a thread that uses fast ram that can be better if you understand concept. A few address lines becomes many.

Keep looking for basic concepts to build with.

Will stop here, Ask questions.

[nockieboy]

Okay, so I've caved in to the idea of adding an Arduino Nano to the SBC, with the intention of using it to provide I²C and SPI buses to the Z80.

Currently, the Nano is providing a 4 Mhz clock (8 MHz selectable by pulling D12 on the Nano high) and is linked to the Z80's ~RESET line, so it can pulse it during startup and save me a button press when turning the SBC on. 

I'm now trying to work out how to create a meaningful interface with the Z80, bearing in the mind the Nano is restricted on the number of pins it has.  Initially I thought I could just link up the Z80's data bus to the Nano, but only certain pins can be used as a 'port', which is clearly the preferred method to read and write an entire byte to the bus as efficiently as possible, but using a 'port' isn't really an option due to pin feature constraints, such as the Nano appears to only have one pin which will take interrupts - and that's the serial Rx pin, which I need to communicate with the Nano directly.

So, I'm now considering using an 8-bit bi-directional shift register (CD74HCT299E) to take the 8-bit data bus contents and pass it to the Nano via a serial connection, taking up only 3 pins instead of 8.  It will also be used to pass data from the Nano back onto the Z80's data bus.

I'm thinking of using an IO select line from the '138, almost as a 'chip select' for the Nano, but also connected to the '299 to latch the data on the bus and, when the Nano is ready, to pass the data over via the serial connection.  I'm supposing I'll need another connection between the '299 and the Nano as a 'DATA_RDY' to control communication over the internal serial connection.

So.. in theory, I could pass data to the Nano via an IO call.  Not sure how I'd get data back though - unless I connect the Nano to the Z80's interrupt circuit and see if I can get the data onto the bus that way, ready to be read by the Z80's interrupt routine.  Or I suppose I could use WAIT states to let the Nano pause the Z80 while it gets the data ready on the bus?

Hmm.. not sure of the best approach, or even if I've considered all the possibilities.  Any thoughts?

[C]

With you currently building on breadboard, how about stupid simple to start with with the idea of later improving it.

You said you have a Z80 PIO, why not connect that for Z80 side. Note that PIO has a full duplex mode if that works better..
This lets you learn some about PIO software interface also. Look some at how you are writing your software. It is possible to have one software driver to control/use many SIO's for example. Same can be done for CTC & PIO in some cases.

On nano side, you could use pins or SPI. I would guess both. Would need some parallel in serial out & serial in parallel out shift registers.

After you have simple connection to PIO then look at other signals that exist on parallel scsi to add to make connection better.
 

[nockieboy]

Ah okay so stick with running the Nano through the PIO (via the '299 shift register obviously).

Another thought occurs - I (currently) have a spare serial port on the SIO. This is eventually intended for use with the keyboard/monitor circuit (as detailed in Grant's designs) but I'm wondering if it'd be easier at the moment to just connect the Nano up to the spare serial port and communicate with the Z80 that way?

Aside from using the spare serial port that I'll eventually need later for other IO (aforementioned keyboard and monitor), I'd like to include some DMA capability in the Nano too if at all possible. This would make connection via the PIO or SIO impossible though...

[C]

Ah okay so stick with running the Nano through the PIO (via the '299 shift register obviously).

To make it easy, you need more then 8-bits.
If you are using 8-bit shift registers then you need to use two to get bits needed to separate what is passing over connection to keep software simple and fast. 

Another thought occurs - I (currently) have a spare serial port on the SIO. This is eventually intended for use with the keyboard/monitor circuit (as detailed in Grant's designs) but I'm wondering if it'd be easier at the moment to just connect the Nano up to the spare serial port and communicate with the Z80 that way?

A usart or SIO is not a great interface between computers. You have a lot of different types of 8-bit data.
Read past posts.

Between two Z80 SIO's if you use HDLC then it's good. HDLC is a synchronous mode with packets.
Between nano's or other micro-controllers you could use 9-bit mode asynchronous. 
SIO & windows do not like 9-bit mode asynchronous.

Need to look at how fast the Z80 can read or write the data. The more computing you do the slower it gets.

Aside from using the spare serial port that I'll eventually need later for other IO (aforementioned keyboard and monitor), I'd like to include some DMA capability in the Nano too if at all possible. This would make connection via the PIO or SIO impossible though...

Z80 DMA controller can work with PIO & SIO

[nockieboy]

So I've got a '299 to try to interface with the Nano now - I'm hoping that it's going to be possible this way rather than having two 8-bit shift registers; I'm trying to minimise space so I'd like to use the 299 if at all possible, plus I don't have both types of serial shift register (SIPO/PISO) in separate packages.

What I'd like to be able to do:

    * interface the Arduino Nano to the Z80 SBC via the 74HCT299 (and PIO if necessary)
    * enable the Nano to read a byte from the data bus via a Z80 OUT instruction, and
    * place a byte onto the data bus in response to a Z80 IN instruction

That's the minimum I'd like to achieve - I can build it up from there to send sequences of bytes etc later.

What have I tried so far?

I've connected the '138 IO mapper to an interrupt-enabled digital pin on the Nano so that any IN/OUT commands from the Z80 to the 28-2F address space pulls the Nano's pin low and triggers the interrupt on a falling edge, so I can see when the Nano is being addressed in the IO space.  I've also connected up A0 to another digital pin and have tried reading it to see if I can get a 0 or a 1 when I'm doing an OUT 28 or OUT 29 instruction.  The results are inconsistent - obviously because of the delay between the interrupt firing and the digitalRead instruction grabbing the data from A0 is much longer than the Z80 is keeping the address bus stable for the OUT instruction.

Now what I'm thinking is that if I link that same select line to the '299 via an inverter, I can use the select signal (transitioning to HIGH after the inverter) as a clock pulse to cause the '299 to latch the data bus contents and start sending the data to the Nano via the serial connection (pins DS0 & DS7 on the '299) whilst the Z80 carries on with executing further instructions.



Now I know very little about the '299 and the image above shows how far I've gotten with developing the interface. 

In fairness I'm a bit lost in it all. I've taken a look at the datasheet for the 299 and am trying to work out how to control it via the Nano, but I'm struggling with the whole concept currently, not to mention the problems that the timings are causing (although the Nano is running at 16MHz, it's clearly not quick enough to sample the data bus at the right time without using WAIT states.)

I'm going to go do some research on the PIO as I think maybe that could help with the timing/sampling issue.  Just can't believe no-one has done this sort of thing before and not documented how to do it - I've searched high and low online and cannot find anything that explains in a way that is helpful to me.  If anyone can point me in the right direction, that'd be appreciated.


   

[nockieboy]

You know what, for simplicity I think I'm just going to use the second SIO serial port to connect to the Nano.  Just requires a couple of wires and the software will be simplicity itself...

[C]

You know what, for simplicity I think I'm just going to use the second SIO serial port to connect to the Nano.  Just requires a couple of wires and the software will be simplicity itself...

Yes simple to start with but then you get in a big mess when you start trying to use it for more then just one stream of data and even one stream of data is a problem if you do not use the hardware handshake of serial port.