expansion board: zx-pico-io
Re: expansion board: zx-pico-io
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...
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...
Re: expansion board: zx-pico-io
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 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...
Code: Select all
// install:
0xFD, 0x21, 0x00, 0x30, // LD IY, $3000
0x21, 0x00, 0x20, // LD HL, $2000
0x3E, 0x00, // LD A, 0
0xFD, 0x77, 0x02, // LD (IY+2), A ; rewind to first byte
// loop:
0xFD, 0x77, 0x01, // LD (IY+1), A ; request next byte
0xFD, 0x46, 0x00, // LD B,(IY+0) ; read next byte
0x70, // LD (HL),B
0x23, // INC HL
0xFD, 0xBE, 0x01, // CP (IY+1) ; check more data flag
0x20, 0xF3, // JR NZ, loop
// done:
0xFD, 0x21, 0x00, 0x40, // LD IY,$4000
0xC9, // RET
Re: expansion board: zx-pico-io
I believe IY is used by the interrupt that draws the screen. So programs using IY can only run in FAST mode.
Re: expansion board: zx-pico-io
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.
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.
Code: Select all
0xCD, 0x23, 0x0F, // CALL $0F23 ; FAST
0x21, 0x09, 0x40, // LD HL, $4009
0x3E, 0x00, // LD A, 0
0xFD, 0x77, 0xC2, // LD (IY-62), A ; rewind to first byte
// loop:
0xFD, 0x77, 0xC1, // LD (IY-63), A ; request next byte
0xFD, 0x46, 0xC0, // LD B,(IY-64) ; read next byte
0x70, // LD (HL),B
0x23, // INC HL
0xFD, 0xBE, 0xC1, // CP (IY-63) ; check more data flag
0x20, 0xF3, // JR NZ, loop
// done:
0xCF, 0xFF, // RST $08 $FF ; ERROR RESTART
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.
- 1024MAK
- Posts: 5332
- Joined: Mon Sep 26, 2011 10:56 am
- Location: Looking forward to summer in Somerset, UK...
Re: expansion board: zx-pico-io
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
Mark
ZX81 Variations
ZX81 Chip Pin-outs
ZX81 Video Transistor Amp
Standby alert
There are four lights!
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
Autumn is here. Bye bye summer 2024...
ZX81 Chip Pin-outs
ZX81 Video Transistor Amp
Standby alert
There are four lights!
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
Autumn is here. Bye bye summer 2024...
Re: expansion board: zx-pico-io
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...
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...
Re: expansion board: zx-pico-io
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.
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.
Re: expansion board: zx-pico-io
In my ZX81 emulator i have 2 spots for load and save where I go to my own loader/saver. the source is available.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.
Re: expansion board: zx-pico-io
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.
Re: expansion board: zx-pico-io
https://sinclairzxworld.com/viewtopic.p ... 313#p46313
after loading you exit through a displayfile routine or......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.
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