expansion board: zx-pico-io

[dr beep]

In my ZX81 emulator i have 2 spots for load and save where I go to my own loader/saver. the source is available.

Which emulator is that? Got a URL?

https://sinclairzxworld.com/viewtopic.p ... 313#p46313

My current USR invoked code is successfully loading most .p files I've tried so far, but there are some that I have loaded via the tape interface that fail to correctly load this way, making me think I may be missing a step. Would be very handy to see a known-working implementation.

after loading you exit through a displayfile routine or......
you drop SP until at #556 and decrease frames by 1.
Last step is needed since I code opcodes in frames that use that trick.

If you can load my latest supershogun you can load everything.

https://sinclairzxworld.com/viewtopic.p ... 909#p47909

page 84 for the loader

[swetland]

https://sinclairzxworld.com/viewtopic.p ... 313#p46313

Thanks!

after loading you exit through a displayfile routine or......
you drop SP until at #556 and decrease frames by 1.

I've been doing

Code: Select all

RST $08
DB $FF 

which seems to cleanly reset to the top of stack, etc and then fall into the display path.

Last step is needed since I code opcodes in frames that use that trick.

If you can load my latest supershogun you can load everything.
https://sinclairzxworld.com/viewtopic.p ... 909#p47909

The fixed-for-16K-machines version works fine, as far as I can tell.

Your LR1 works great, but LR2 has problems.
(obtained via this post: https://sinclairzxworld.com/viewtopic.p ... 710#p46710)

LR2 is slow to respond to input, the bad guys leave trails of Os on the display, and the screen starts blinking, etc. Something's not happy.

[dr beep]

Have you tested LR2 on an emulator?
Running fine by me.

[swetland]

It works fine in emulation.

After my last round of cleanup LR2 now works on the ZX81+38 loaded via the zx-pico-io... though I'm not 100% sure why. A couple other programs that failed to load also work now, so I'm suspecting the earlier code wasn't always getting the entire program copied over. The updated transport is more robust.

I've ditched the "run a loader program off the io board" approach as I'm definitely moving to IO ports for the next board spin. I should be able to use any two IO ports in the 0xnF range (one control, one data transfer). I've got a modified ROM with 163 bytes free from disabling the printer code (COPY/LPRINT/LLIST) and COPY is "load program from IO board" and "LLIST" is "CALL 0x2000" at the moment (.p files are loaded at 0x4009 and raw binaries at 0x2000).

[swetland]

Got as much mileage as I could out of the original v1.1 PCBs.

Send out new v2.0 ZX-PICO-IO designs for fab today.

Featuring:
- right-side-up connectors
- IOPORT rather than memory mapped interface
(hw address decoder matches on IORQ + A0..A3 HIGH + nRD or nWR, PICO sees A4..A7 for further decoding/routing)
- PICO can now assert nRESET
- Pin assignments improved to allow some firmware optimizations
- board size slightly reduced

[swetland]

Got the version 2 PCBs back yesterday and the new io-port based design works great. (Currently using port 0x1F for control, 0x0F for data, but I can match any port with the least significant four bits high). The new feature (reset Z80 from the io board) works as well.





The colorful 3 wire cable is the SWD debugger for programming and debugging the pico and the grayscale 3 wire cable is serial <-> USB for more debug chatter. Scope is watching nRD and OUT_DIR to check that timing is reasonable (we have about 800ns in which to get a response out to a read and the firmware is doing it in about 300ns which isn't horrible).

[Paul]

300ns Sounds reasonable to be able to use the Pico RAM as ZX81 Memory Expansion.
Do you think this might work?
My Idea is having the Pico to supply the Zeddy memory and have it doing SD Card reading and writing directly from Pico memory for loading, saving, supplying alternative ROMs etc.

[swetland]

300ns Sounds reasonable to be able to use the Pico RAM as ZX81 Memory Expansion.
Do you think this might work?
My Idea is having the Pico to supply the Zeddy memory and have it doing SD Card reading and writing directly from Pico memory for loading, saving, supplying alternative ROMs etc.

My original implementation was memory-mapped and while it does take some effort -- I had to run the core1 code from sram and used a hand coded assembly routine to service the z80 bus interface -- it is definitely doable.

The biggest issue you'll face is the pico only has 25 total GPIOs -- you could use some external logic to decode nMREQ / nRD / nWR and the top 2-3 address bits into a pair of RD/WR signals to the pico alongside 8 data lines and 13-15 address lines.

Alternatively you could multiplex D0..D7 and A0..A7 -- capture A0..A15 when nRD or nWR plus nMREQ are asserted, then tri-state the level shifter on A0-A7 and activate the level shifter on D0..D7 to capture (write) or generate (read) the data bus. Which probably makes timing even tighter.

I'd be tempted to use a small FPGA -- like a Lattice ICE40UP5K (39 IOs and 128KB of spram) -- it could front-end the Z80 bus, and provide a high-speed SPI interface to the pico.

A related project of interest: a RP2040 based EPROM emulator: https://github.com/mengstr/Rom2k40