Sinclair ZX80 / ZX81 / Z88 Forums

So I believe trying to be cute and *execute* code from my IO device (a small stub that'd copy a larger piece out) was what really got me in trouble. The mechanism that NOP-izes most instruction fetches when A15 is high appears to work as "normal" on the zx81+38.

Moving the address matching from 0xFnnn to 0x3nnn improved things, but we still seem to go off the rails when trying to execute code from that region.

Both a simple BASIC program and an assembly subroutine are about to copy 1KB of data from the IO port (poke 0x3001,1 to ask for the next byte, peek 0x3000 to grab it) to SRAM at 0x2000 without issue. So the general mechanics of interacting with the PICO seem good.

I'm kicking myself for giving away my old HP1670E logic analyzer (who needs 96 channels at 100MHz in this day and age of high speed serial busses?!) because right now it'd be awesome to take a full picture of the bus activity on this critter...

Okay, so it gets weirder...

I can execute the code from the IO device at 0x3002 *if* the machine is in FAST mode, but things fall over in SLOW mode.

The same code (listed below) runs correctly out of regular SRAM (in SLOW or FAST mode)

Currently I'm copying the data to 0x2000 which is SRAM in this machine, because I haven't entirely worked out how to exit from a USR call into BASIC where I've overwritten BASIC's global state with a new program... burning one bridge at a time here...

I believe IY is used by the interrupt that draws the screen. So programs using IY can only run in FAST mode.

From what I've read (including looking through ROM listings), it seems like I, IX, and the shadow registers all must be left alone to avoid interactions with the display interrupts. IY seems like it should be safe if restored to $4000 (which BASIC expects) before you return, but I may be missing something.

To rule that out, though, since I can hit my memory window indexing backwards from $4000, I just used the value already in there, and thanks to this thread (viewtopic.php?p=13110#p13110) I've learned RST $08 can be used to 'exit' a USR routine cleanly.
I've successfully run a little "plot a sinewave" BASIC program (1181 bytes) from the IO expander with just: PRINT USR 12290

It takes a couple tries before it works, and then it keeps working, which smells like a problem with the pico firmware.

I do think I may shift to IO ports instead because losing the whole 4K bank at 0x3000 is unfortunate and my plan is to patch the ROM to support load/save from the io expander, at which point being able to invoke it via USR ceases to be an issue.

IX is definitely used by the display routine / video generation and should be avoided unless the machine code is running in FAST mode. See also this topic.

Mark

Thanks! That's a helpful thread.

IY is clearly also a hazard, but provided I have SRAM "below" 0x4000, I can use negative indexing to access it, or I can use the print buffer as scratch space, or I can mirror the few variables the display routine needs if I move IY somewhere, so there are some options available.

Z80 assembly has some weird tradeoffs even before ZX81 architectural quirks -- index register ops being 19 clocks being one of them...

The remaining issue was indeed related to the PICO -- by default the firmware runs from SPI flash, XIP, and until the cache warms up it was failing to react to the bus quickly enough. Adjusting things to ensure the critical code and data was in SRAM and things work correctly from power up.

And I'm now able to load, say, LodeRunner with my zx-io-pico board just a liiitle bit faster than from tape:

https://www.youtube.com/watch?v=oBuhZpXLjIA

Need to tidy things up and wire up USB so I can push new programs to the board "live" instead of by rebuilding its firmware, and then look into patching the ZX81 ROM to wire LOAD/SAVE up directly, etc.

swetland wrote: ↑Tue Aug 16, 2022 1:03 am The remaining issue was indeed related to the PICO -- by default the firmware runs from SPI flash, XIP, and until the cache warms up it was failing to react to the bus quickly enough. Adjusting things to ensure the critical code and data was in SRAM and things work correctly from power up.

And I'm now able to load, say, LodeRunner with my zx-io-pico board just a liiitle bit faster than from tape:

https://www.youtube.com/watch?v=oBuhZpXLjIA

Need to tidy things up and wire up USB so I can push new programs to the board "live" instead of by rebuilding its firmware, and then look into patching the ZX81 ROM to wire LOAD/SAVE up directly, etc.

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

dr beep wrote: ↑Tue Aug 16, 2022 9:38 pm 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?

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.

swetland wrote: ↑Tue Aug 16, 2022 10:07 pm

dr beep wrote: ↑Tue Aug 16, 2022 9:38 pm 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