Another Home-Brew - Z180

[Bill B]

It looks like Martin's suggestion is workable, just:

Code: Select all

Flow Status	Successful - Sat Dec 12 11:50:20 2020
Quartus II 64-Bit Version	13.0.1 Build 232 06/12/2013 SP 1 SJ Web Edition
Revision Name	Z180_EC_Util_CPLD
Top-level Entity Name	Z180_EC_Util_CPLD
Family	MAX7000S
Device	EPM7032SLC44-10
Timing Models	Final
Total macrocells	32 / 32 ( 100 % )
Total pins	35 / 36 ( 97 % )

My previous design had one spare macrocell.

The corresponding VHD is attached.

[Bill B]

So, ever optimistic, I wrote some Z180 code to test reading and writing an SD card. Of course it does not work, fails on the first step of initialising the card

So back to trying baby steps. Remove the SD card adaptor, and link the MISO input to the MOSI output. This should resulting in receiving whatever byte is transmitted. That does not work either The resulting input does depend upon what byte is transmitted, not always 0xFF, although that is the most common result. I have yet to work out what the relationship is.

I think my next step has to be to breadboard just the CPLD, and hook all the inputs and outputs to an RPi so that I can test systematically with complete control over each input.

It is perhaps interesting that Andy's VHDL for Rememoriser contains the following somewhat cryptic comment:

Code: Select all

-- Important: the process clocked on clk_50mhz that reads in bits can not be
-- sure that the newly arrived byte will be latched on the next cpu_clk.
-- Note that the CPU won't come and sample it that quickly anyway.
-- However, TimeQuest whinges about negative slack on setup, and I think that
-- Quartus's attempts to make the timings work here, breaks other timings.
-- By latching di in a process here, we somehow prevent this problem.
-- Some TimeQuest configuration of multi-cycles might also help.

My VHDL also generates timing warnings in Quartus. So far I have just ignored them. Perhaps I need to spend more time understanding this program.

[Bill B]

20201229_160008.jpg (827.5 KiB) Viewed 25843 times

Progress is proving painfully slow

• Testing the CPLD using an RPi to bit-bash inputs and monitor outputs (illustrated) led to the discovery of one logic error and one typo in the VHD for the CPLD.
• Corrected the VHD, reprogrammed the CPLD and tested again. Looked OK.
• Tested with Z180 board. Failed to initialise SD card.
• Tested the SD card interface using RPi to bit-bash SPI connection to confirm details of protocol. Able to initialise the SD Card and read sectors.
• Breadboard CPLD connected to the SD Card. Used RPi to bit-bash a (slow) emulation of the Z180 interface to the CPLD. Still able to initialise the SD card and read sectors.
• Tested with Z180 board. Still failing to initialise SD card.

I think my next step is to see whether a Propeller chip is fast enough to monitor the communication with the SD card when it is being driven by the CPLD in the Z180 board.

[Martin A]

Have you got one of these https://www.amazon.co.uk/Hobby-Componen ... 00DAYAREW/ in any shape or form ?

It might help you work out what's going on. It uses the open source PulseView software so should work with Linux.

[Bill B]

No, don't have any form of logic analyser. Only an ancient two channel scope full of lots of glowing tubes.

I have in the past used PiScope and connected RPi GPIO via voltage dividers. However that has a maximum sample rate of 1MHz, which is not fast enough for this application.

Also see previous posts for the amount of luck I had with the USB Blaster clone I purchased from Hobby Components.

[Bill B]

No, Propeller chip is not fast enough

I might have been able to do something with my Teensy 3.5, but instead have ordered the cheaper version of Martin's suggestion.

[Bill B]

My cheap logic analyser has arrived and is proving illuminating:

Screenshot from 2021-01-10 11-13-48.png (13.21 KiB) Viewed 25579 times

It appears to show that I am frequently, but not always, getting a spurious ninth pulse at the end of a low speed SPI byte.

Zooming in shows that the "ninth pulse" is not a single pulse, but a burst of eight pulses at high speed.

Screenshot from 2021-01-10 11-18-20.png (13.02 KiB) Viewed 25579 times

Coming at the end of the intended low speed SPI transaction, it is presumably occurring when the Z180 is reading the result from the shift register in the CPLD. The way the CPLD is designed, reading the shift register using Z180 port 0x49 is supposed to trigger a high speed SPI transaction, while reading the register using port 0x48 should not.

The CPLD was working when tested using an RPi to emulate the Z180. But that was slow, in particular the port address was set up well before RD and IORQ went low, and maintained until well after RD and IORQ went high.

So my guess is that a timing issue is resulting in a false triggering of a high speed SPI transfer. I will have to review the VHD to see whether there is anything I can do about that. It will not be easy given that the current design has the CPLD almost 100% committed.

The issue only seems to occur when reading the receive shift register, not when writing the transmit shift register. Again, a write to port 0x49 should trigger a high speed transfer, while a write to 0x48 should not. Now the WR pulse occurs later in an I/O cycle than the RD pulse. This suggests that the timing issue is at the beginning of the read cycle, not the end.

[Bill B]

Screenshot from 2021-01-10 14-19-30.png (68.11 KiB) Viewed 25577 times

Progress

Having modified the VHD to only test for I/O to port 0x49 on the rising edge of PHI, the spurious fast pulses have gone away, and the SD card is responding to the Z180.

I now need to write lots of code to make use of it.

[Martin A]

Are you running your Z180 in HD64180 I/O mode or Z80 compatible I/O mode ?

If the IOC bit in the operatiom mode control register (Bit 5 of &3E) is cleared, and it's det by default , *IORQ and *RD are delayed to the rising edge of T2 just like *WR and the Z80 way of things.

[Bill B]

Spoke too soon

I have fixed low speed mode, but broken high speed, it is triggering too soon. I will have to see what, if anything, I can do about that.