Sinclair ZX80 / ZX81 / Z88 Forums

I'm building a little multi-purpose IO board to go along with the ZX81+38 I assembled... after a couple setbacks (I foolishly checked my header orientation vs the schematic, not the layout of the ZX81+38 and thus got it backwards -- addressed by inverting the header but also causing the board to face the wrong way, etc...) I've got the rpi pico's second core happily emulating a bank of 16 registers at 0xF000 (the 125MHz M0+ can keep up with multicycle 3.25MHz Z80 IO pretty easily even with a naive C implementation).

Anyway, I've run into a curious thing... at boot and then repeating every few minutes, I get reads happening (I believe from FFFF down to F000, but I don't have a probe on the entire address bus) every 20ms (so presumably part of video scanout?). Whatever's reading does not seem to care what data it gets from me (yay), but it means some ideas I had to allow the Z80 to treat an address as a FIFO port, reading a series of bytes will break if the ROM is going to periodically read from it too.

So any ideas what causes this and if it's in any way avoidable?

I'm using decode logic that treats A12..A15 == 0xF && nMREQ == 0 && nRD == 0 as a read access.
I believe nRFSH is asserted instead for refresh accesses, so it's not that.


Some bringup/debug photos:

Nooooooo !

Don't use the top memory to set you IO target! (CPU stacks or move the RAM_TOP in the ROM, and display stuff)


For 64kb users...

Just use the RW=0 on the memory bottom, you can't erase the ZX81 ROM...

Archives:

In a Sinclair ZX81, as the ULA only uses address line A14 (and the Z80 CPU control line /MREQ) to decode the control signals for the ROM and RAM, both are only partially decoded. See more details here.

Addresses below 7FFF are used as normal. However, the display system (which uses the Z80 to read the data from the display file in RAM) reads from addresses with A15 set to high, so addresses above C000. The exact address depends on the address in memory of where the display file is.

Although clones often have more extensive address decoding (because they have more RAM), the display system still requires that the Z80 reads from addresses above C000 and that this ‘shadows’ the RAM below 7FFF.

If you want to have memory mapped I/O, It should be in an area that is outside the C000 to FFFF area. I can’t remember how the ZX81+38 does it’s decoding, but with a Sinclair ZX81, you also have to prevent the internal ROM or RAM from responding by holding the relevant /ROMCS or /RAMCS line high during the time your I/O is being addressed.

Mark

And if you use ROM Address range keep in mind that at least the lowest 5 Bytes are written to by the calculator.
And there are poke cards for memory mapping in the following bytes so my advice:
Keep clear of the lowest 64 Bytes of the ROM in order to be on the safe side. And definitely disable the ROM by applying 5V to the !ROMCS line
Maybe you also tell us why you decided to use memory mapped instead of IO mapped?

Excellent. Good to realize my approach is fundamentally flawed before I do another board spin!

The ZX81+38 with 8K ROM / 32K RAM decodes memory this way: I was under the impression that top-of-ram ended up at 0x7FFF if 16K (the max scanned for?) is detected starting at 0x4000 and didn't realize the BASIC ROM made use of mirrors up at top-of-address-space. For display purposes I was under the impression the ROM (mirrored at 0x8000) and RAM (mirrored at 0xC000) were used -- though I'm not sure how this changes in high res modes...

I was thinking memory mapped would be simpler to interact with from BASIC which has PEEK/POKE but no primitives for IO access, and decoding for Fxxx and suppressing nRAMCS was simple enough.

IO is starting to look a bit more appealing, though that also seems to be a partially decoded space -- based on this document (https://problemkaputt.de/zxdocs.htm#zx80zx81iomap) it seems that I need to at a minimum:
1. avoid using ports where A0==0 (would interfere with keyboard)
2. avoid ports 0xFD and 0xFE which disable/enable the NMI generator
3. cannot access during display generation (probably not much of an issue)

Or maybe using memory space at 0x2000 or 0x3000 which is normally a mirror of the ROM on 1K or 16K ZX81s, iiuc.

Schematic for the current version of the PCB:

This thread on the German forum has a PDF with port numbers to avoid, as they are used by someone else.

https://forum.tlienhard.com/phpBB3/viewtopic.php?t=2327

Awesome project! A couple of days ago I was thinking of interfacing a Pico to a ZX81 so it is great to see someone is already doing it. For myself I decided to look into using a Teensy 3.5 which is 5V tolerant and is a bit more powerful than the pico. Please keep us updated on your progress since it'll be helpful for anyone interfacing to the ZX81.

I'm kicking myself for not thinking of this first:

https://twitter.com/matseng/status/1554534431523741697

Soon happy enough with the layout for my RP2040-based EPROM emulator to send for some PCBs. Managed to fit everything on the top. Almost the same size as 28-pin EPROM, just a couple of millimeter longer to fit the two 3-pin headers. Having 4 layers and 125/125um tracks is nice.

I used an AT28C256 EEPROM for my ZX81+38's ROM which cost like $12-13 nowadays (and required an adapter board to create a DIP28 from a SOIC28 package). THE RP2040 and related bits are inexpensive enough that depending how much PCB fab costs, the price would be comparable.

I was regretting not hanging on to my old DATAMAN D4 EPROM Emulator, but it turns out one can build one for a fraction of the cost...

(This doesn't replace the IO project, but basically takes advantage of the same fact -- that the 125MHz M0+ on the Pico has 38 cycles of clock for every one cycle of the ZX81 -- to make it pretty simple to emulate a memory device)

Two years ago the German team connected a Raspberry PI to a ZX81, and attached a webcam to the Pi. The image was shown Live on the ZX81 with WRX graphics.

There are I/O devices that are memory mapped for the ZX81. Typically they either use 0x2000 to 3FFF and override the ROM by taking /ROMCS high, or use 0x8000 to BFFF and override the ROM or RAM as appropriate. Although in some, they did not realise that they had to use /ROMCS or /RAMCS…

Yes, the ZX81 ROM code only recognises a maximum of 16K RAM. But a user can POKE a different value in, then do a NEW. Then BASIC can use more than 16K bytes (although there are restrictions).

Mark