z80-retro / 2063-z80 Goto Github PK

U3.1 and U3.30 are NC pins on the SST39SF010. On the larger versions of that FLASH family, they would need to be pulled low. On UV EPROMs they might need other settings. By disconnecting them it will be easier to mod the board to suit any such need without changing anything when using a SST39SF010.

It is unlikely that thermal reliefs on the inner layers are useful.
The thinking here is that the power inlet is better off without thermals on inner layers.

While my board has been running fine at 10MHZ, the timing on FLASH_MREQ is too tight to meet the official worst-case specification... even with the 55ns version of the FLASH.

The solution if you run into trouble is to run the main clock at 8MHZ. I will change the design to officially run at 8.

On the YouTube comments: https://www.youtube.com/watch?v=w5LYCHml4A8

Torshak observed:
As always, great and very helpfull video.
I have a observation regarding memory access time though. I am trying to read Z80 opcode fetch timings, and I don't think you have entire 150ns. Yes, you have 1.5 periods, but... MREQ signal does not fall together with clock falling egde but it takes it up to 55 ns. Then Z80 expects data to be stable 25 ns before rising edge of the clock. (all timings for 10Mhz version) so you are left with 70ns, and that's wihtout glue logic. Of course this is almost the absolute worst scenario. Unless I am reading it wrong... which would not be the first time ;)

Then I replied with this:
BLAST IT ALL!!!! I was looking at a page of the datasheet that included a wait-state in the diagram! It looks like the 55 and 25 numbers are right for the 10MHZ Z80.. The FLASH that I used has a 70ns access time (and the RAM is 55). Revising my understanding and NOT including a stinking wait-state the tightest memory cycle duration is 150ns - 55ns - 25ns = 70ns.
Fortunately, the SRAM has no decoding per-se and the OE to DATA time is 30ns (which is fine with the extra U10 27ns delay.)
The FLASH is a bit more of a problem. FLASH_MREQ can be delayed by U10 by up to 27ns.
I hang my head in shame!
Luckily, at 8MHZ, we see 125*1.5 - 60 - 30 = 97.5nsec
The worst-case FLASH_MREQ time (delayed by 27ns) is then 70.5nsec :-D
I think I will /officially/ slow the main clk to 8MHZ and observe that I have been living on the edge by overclocking mine at 10!

Add a jumper & pullup on the FLASH A16 pin to allow alternate BOOT images.
Note that this is only useful when using a stand-alone FLASH programmer as the in-circuit programmer design will not work when A16(, A17 or A18) is high.

I've flashed several files to the retro board with no problems.

Last time I tried to flash something to the board I get:
"Product ID: 0x20, 0x20"
"Invalid FLASH signature: 0x2020 != 0xbfb5"

What is the best method to determine if the problem is with the Raspberry PI, Programming Board or the Retro Board?

Add terminating resistors to the clock signal traces to reduce overshoot & ringing.

Due to the galactic parts-shortage, Digikey, Mouser, and Newark are all on backorder for the Hirose DM3D-SF SD card socket in the Rev 3 design.

If a Rev4 board is produced, adjust the footprint to allow for an alternate socket (such as the Molex 1051620001) to be used.
[It looks like the Molex could be made to fit on the same pads IFF the keep-out areas are increased and a second card-det landing is added.]

I have a RS232 terminal, but a friend building the board does not and doesn't even have a serial port on her computer. The design doesn't expose an easy way to connect a 5v Tx/Rx for a FTDI->USB connection.

I doubt there's space to add that to the board (maybe above the printer connection?), but something that is working for us is a RS232 voltage -> 5v converter (we're using https://www.amazon.com/gp/product/B07LBDZ9WG/). This can be connected to a standard FTDI USB cable.

Hello again,

Slowly getting together the parts for my Z80 Retro, but so far I still have not managed to find the 10 MHz crystal oscillator. It seems every time I check Digikey they are out of stock. However I do happen to have some 5 MHz oscillators left over from another project, and was wondering if I could use one of those instead, until such time as I am able to finally find the 10 MHz part. Aside from the system running at half the speed, would a slower clock cause any other negative effects (parts of the system to be unstable / not work, etc.)?

The /PRN_LF signal is intended to be manually changed under software control only.
I ran out of space on the PCB and decided to use an output pin on the SIO as a general-purpose port. It will work if the intent is to drive the pin low. But it will not work as expected when driving it high.

Z80 Family CPU Peripherals User Manual UM008101-0601 says this on page 212:

RTSA, RTSB Request To Send (outputs, active Low). When the /RTS bit is set, the RTS output goes Low. When the RTS bit is reset in the Asynchronous mode, the output goes High after the transmitter is empty.

Therefore, driving the pin low will work as expected.

To drive it high an a Rev 3 board, there are two options:

1. Cut the track on J7 pin 14 and wire it to +5v (which is a better hard-wired default than low)
2. Cut the track on U10 pin 13 and add a wire to connect it to U5, pin 25 /DTRB (which is a GP output pin)

In Rev 4, I will re-route this pin to U5, pin 25 (option 2 above)

Any reason in particular you chose 0603 parts for C17 and C24, yet went with an 0805 for C18? I, uh, may have accidentally lost the 0603 parts I ordered (tiny little buggers....and slippery too) and rather than wait for another Digikey order, I decided to try and shoehorn an 0805 part (which I had on hand) in place, and it fits!

Also, C18 is listed on the BOM as a polarized capacitor, and to my knowledge, SMD ceramic caps are unpolarized. Mistake, or is there some weird polarized SMD ceramic capacitor that I am unaware of?

John, the silks on 2063.4.3 say AS6C1008 (1MB) instead of AS6C4008 (4MB) as the part number for the RAM chip. This can be (is?) kinda confusing.
The typo is also present in the 3D model picture in the main project page; noticed this while browsing parts to place an order.

On the other hand, the part itself is an AS6C4008 when checking the part's properties in KiCAD's PCB and schematic editors. Looks like just the silks are the only ones affected.

Marcelo.

After doing some testing with a range of USB power supplies/chargers I have noticed that one of mine will ramp up the voltage slow enough to prevent the /RESET signal from remaining asserted long enough to properly start the Z80.

This has no impact on the ability to use the reset button.

To 'fix' this, I changed C20 to .47uF. This will keep the /RESET signal asserted five times longer after initial power-up and "works for me" on all the USB power supplies that I have around to test with.

Increasing the size of C20 is OK within reason. Keep in mind that the reset-button (S1) shorts out C20 to reset the system. The switch will not last very long if C20 is large! I'd advise not using anything more than 1uF for C20.

A Raspberry PI project?
As you cannot seem to Communicate with z80 Repo, without one.
Compile the Files, without one
Program the flash, without one
Create as SD card image, without one
Please for us that use the Precious Pi’s we have running Infrastructure e.g., Home Assistant an MQTT Server etc.
Can you just run MAKE and zip the resulting files. and end the frustration.
So many of us who have Device programmers and dormant z80 retro’s running nop loop tests can join in the fun too.
Please Help us.
Many thanks.

tests/hello_ctc2a.asm contains a comment that references the wrong section in the manual.

Line 79 Reads
ld a,11000100b ; wr4 = /64 N1 (see UM008101-0601, pdf page 262)
I believe it should be changed to
ld a,11000100b ; wr4 = /64 N1 (see UM008101-0601, page 286-287, [pdf page 306-307])

Ref : In the video "Z80 Retro #16 - Board Testing Pt. VI (Interrupts) at 1:12:30
https://youtu.be/WmhSJg9fJ9U?list=PL3by7evD3F51Cf9QnsAEdgSQ4cz7HQZX5&t=4350

Thanks for creating this series! I'm enjoying following along slowly.

The board silkscreen on U11 is '00 (suggesting a 74HCT00) --- however, the schematic/values/BOM suggests that is a 74HCT132.

Is this just a mislabel on the board? Or am I misunderstanding something significant?

The purpose of this issue is to document a suggestion by John on Discord to allow better fit of daughter cards such as 2068-Z80-TMS9118 and 2065-Z80-programmer.

Currently through hole caps on 2063-Z80 are blocking daughter cards from using the standoff hole in the front right location on daughter cards.

How to address this issue:

• Remove the following capacitors and place surface mount replacements on the bottom side of the 2063-Z80 board.
• This solution has been tested with 0603 and 0805 capacitors on the bottom side of the board. These surface mount capacitors fit nicely across the through hole pads.
• Locations are :
  - 0.1uF C2, C4, C8
  - 0.47uF C1, C11, C12

It would be nice if the Schematic and README files could document this change.

C1, C11, C12 (not C2) around U12 ICL3232CPZ on the 2063-Z80-4.4.0 board changed from 0.1uF to 0.47uF on the schematic and BOM but this is not indicated in the notes on the github page for this version of board, or in the schematic delta/diff file, or in the accompanying video about the changes. It would be nice to update documentation.

I would guess this change is to match the datasheet values for 5.0V operation.

Thanks

Michael Neukam proposed a re-consideration of routing U3 pin-30 (a no-connect in the Retro design) to better address the needs of 28-pin EPROMs.
It appears that the best option would be either a 3-pn header o some solder-jumpers so that pin 30 could be easily connected to either GND or +5V.