Executing code in extended memory

[Rishi]

Hi i've been testing a few things regarding my extended memory, and since i was planning to create a toolkit in there i've been trying to run USR routines from there. actually i just created the basic "Copy Bytes"

LD DE,Dest
LD HL,Source
LD BE,Bytes
LDIR
RET

and it does work if i put that in a REM statement, or above RAMTOP .
when i tried to executed from above 48K i got an error, and when i tried using JP NN Jumping to it it also didn't seem to work.
is it true to say that any code needs to be executed from below 16K ?
I guess that will make programming a little more complex but at least as much fun, i recon i could first copy the routine into that area and then execute, hence minimizing the use of normal memory space.

[PokeMon]

Yes - that's normal.
It is the video logic with the ULA which interpretes code with A15 set or above $8000 or in a M1NOT modified ZX81 above $C000 as video code.
In fact all code with bit 6 reset will not be executed or executed as NOP.

So the JP or RET instruction should work anyway as these are execute with bit 6 set while the others in that example are not executed.
If it is executed as NOP the following data byte maybe interpreted as instruction which maybe could give unpredicted results.
There maybe a clever workaround by writing the necessary code only in that way that there is no instruction with bit 6 reset is used.
Not sure if this is possible but maybe worth a try. JP cc,nnnn is possible for example so you could rewrite your LDIR.
It is not easy setting up registers but possible with some instructions like LD dd,(nn) or LD r,(HL) or so.
This would by a nice game.

[IanB]

I wonder if there was a better engineering solution to "Jim Westwood's Problem" for the same price in 1981 that could have been achieved. For instance, not limiting memory to 16k, allowing code execution in all the side screen margins, etc.

[PokeMon]

Yes this can be done but is more complicated to modify in existing ZX81.
My new system ZXmore has this option which allows code execution everywhere in memory.
The restrictions for ZX81 or TS1000 came mostly to achieve a cheap and basic computer.

[dr beep]

Yes this can be done but is more complicated to modify in existing ZX81.
My new system ZXmore has this option which allows code execution everywhere in memory.
The restrictions for ZX81 or TS1000 came mostly to achieve a cheap and basic computer.

Which made my famous 48K bug in some 1K hires games. Commands like JP NN in my hires games read the JP from 'high' memory, but the NN from real high memory and that had no correct value. So to make these games work I had to LDIR the complete game from #4000 to #c000.

[Rishi]

Not using half the instructions in the instruction set can for sure be an interesting game, but i think i'll go for first copying executable code into an executable area and then executing it and then removing it. I was first thinking of using a RAMTOP section that i could expand to fit the necessary code, now i recon i'll use the spare section. If parts would be incorporated into a program it can be added to a REM line, and the part doing the copying and sorting out any non relatives jumps and executing and checking if there is enough space left in memory, can be above RAMTOP, but that shouldn't have to be very big. Like that i can use/make almost 16K of USR routines at almost no Program Memory expense. I recon putting it in the spare temporarily save me the hassle of cleaning it up, copy there and use once. Any Data can stay above 48K, and for larger routines there may even be the option of carving it up into pieces to fit it into memory before executing, but that will require careful programming and fortunately most routines will be small.

[IanB]

If you're not using BASIC, I don't see much point in fiddling about with RAMTOP. You can just use the memory as you like above the display file so far as I can tell as a flat memory space (up to the 16K barrier anyway). You can even have multiple display files come to that, or a "long" display file you can scroll through just by changing D_FILE; wish I'd known that trick back in 1981/2

[Rishi]

I'm going from the point of view some BASIC might be used, and variables may still be in memory, programmers tools may also use some parts, for instance the RENUM routine in the Arctic Toolkit uses the Gosub stack, also some of these use calls to ROM routines, i don't want to get into trouble if they use the STKBOT.

[PokeMon]

If you don't need much space you may copy the code into the printer buffer which isn't used by the system when not printing.
Not 100% sure if this stays there all the time. This is 33 byte free area in the system variables and always there at that location.
You can have 32 byte more using MEMBOT but this is destroyed somewhen from system but maybe temporary available when your ASM code is executed.

When creating code you have to be sure it is relocatable if you use absolute addresses - that's one more important thing.

[IanB]

Come to think of it, if you've got more than 16K I presume you could just move the whole Display File up above 16K, and have another 793 bytes available for program code