Another Home-Brew - Z180

General "chat", not necessarily MTX related
Bill B
Posts: 294
Joined: 26 Jan 2014 16:31

Re: Another Home-Brew - Z180

Post by 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.
Attachments
Z180_EC_Util_CPLD_v7.zip
CPLD VHD for Peripherals board
(1.91 KiB) Downloaded 27 times
Bill B
Posts: 294
Joined: 26 Jan 2014 16:31

Re: Another Home-Brew - Z180

Post by 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 :roll:

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
Posts: 294
Joined: 26 Jan 2014 16:31

Re: Another Home-Brew - Z180

Post by Bill B »

20201229_160008.jpg
20201229_160008.jpg (827.5 KiB) Viewed 1014 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.
Attachments
Z180_EC_Util_CPLD_v8.zip
Revised VHD for CPLD
(1.94 KiB) Downloaded 19 times
Martin A
Posts: 483
Joined: 09 Nov 2013 21:03

Re: Another Home-Brew - Z180

Post by 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
Posts: 294
Joined: 26 Jan 2014 16:31

Re: Another Home-Brew - Z180

Post by 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
Posts: 294
Joined: 26 Jan 2014 16:31

Re: Another Home-Brew - Z180

Post by 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
Posts: 294
Joined: 26 Jan 2014 16:31

Re: Another Home-Brew - Z180

Post by Bill B »

My cheap logic analyser has arrived and is proving illuminating:
Screenshot from 2021-01-10 11-13-48.png
Screenshot from 2021-01-10 11-13-48.png (13.21 KiB) Viewed 750 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
Screenshot from 2021-01-10 11-18-20.png (13.02 KiB) Viewed 750 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
Posts: 294
Joined: 26 Jan 2014 16:31

Re: Another Home-Brew - Z180

Post by Bill B »

Screenshot from 2021-01-10 14-19-30.png
Screenshot from 2021-01-10 14-19-30.png (68.11 KiB) Viewed 748 times
Progress :D

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.
Attachments
Z180_EC_Util_CPLD_v9.zip
Revised VHD for Peripherals Board CPLD
(1.97 KiB) Downloaded 18 times
Martin A
Posts: 483
Joined: 09 Nov 2013 21:03

Re: Another Home-Brew - Z180

Post by 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
Posts: 294
Joined: 26 Jan 2014 16:31

Re: Another Home-Brew - Z180

Post by 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.
Post Reply