Re: Assemblers for the ZX80
Posted: Fri Jun 25, 2021 6:37 pm
Understood Paul many thanks.
Discussion forums for users of the Sinclair 8-bit range of computers - ZX80, ZX81, ZX Spectrum, Z88, clones...
https://www.sinclairzxworld.com/
Right, that explains it. I knew about the collapsed display file - maybe not in those exact words, I knew at least that only the squares that actually had something printed in them were stored in it while in 1K mode.1024MAK wrote: ↑Fri Jun 25, 2021 3:27 pm If there is not much RAM available, a ZX81 will use a collapsed display file (D_FILE). Hence a 1K ZX81 and a 2K TS1000 both use a collapsed display file. But with 4K bytes or more, these machines use a fully expanded display file. See also this post.
This web page is a reasonable summary of the memory map. As you should be able to see, the display file (D_FILE) gets saved to tape as well as the BASIC program and the variables for the program.
I've had a quick look over it, found the bits about the OLD ROM and it already looks like the example you've put below with DIM O(5) is the method it says there. It looks good - presumably as variables are saved to tape, they won't be overwritten when the program is loaded, so all the bits of BASIC that put the machine code there in the first place can be erased, leaving just the DIM statement, and there should be a separate warning to type RANDOMISE USR(address) instead of RUN. Am I right?1024MAK wrote: ↑Fri Jun 25, 2021 3:27 pm In terms of where and how to store machine code on a ZX80, this chapter is well worth a read (or a re-read if you have already read it).
Code: Select all
1 REM - T0
POKE 16431,201 (changes the final zero to an unprintable character which appears as ?)
PRINT USR(16427)
Is there, anywhere, a complete list of bytes that cannot be poked into a REM statement - so I could still have this option if I made sure none of them were there?Paul wrote: ↑Fri Jun 25, 2021 5:56 pm REM lines can be used without any problem on the ZX80.
You just can't poke whatever you want into them.
The ZX81 has two bytes line length after the line number which makes it possible to jump over the REM line to the next line before continuing to interpret the contents.
The ZX80 does not have the line length and therefore needs to look through every byte of the REM line in order to find the beginning of the next line and can be misled by the contents of a machine code program inside the REM statement which causes crashes.
I tried this on my ZX81 emulation and it didn't work so I guess this only works on a ZX80?TMD2003 wrote: ↑Fri Jul 02, 2021 8:16 pm INCIDENTALLY: I found and noted a crude way to check the memory available on a ZX80, seeing as there appears not to be a way to PEEK RAMTOP and STKEND (are these even used on a ZX80?)This returns -31713 for a 1K machine and -16353 for 16K.Code: Select all
1 REM - T0 POKE 16431,201 (changes the final zero to an unprintable character which appears as ?) PRINT USR(16427)
That’s as I understand it (although I do have a working ZX80 plus a clone, I’ve never actually tried saving any machine code to tape using a real machine or on an emulator, instead I’ve only used an emulator to save via a snapshot ).TMD2003 wrote: ↑Fri Jul 02, 2021 8:16 pm I've had a quick look over it, found the bits about the OLD ROM and it already looks like the example you've put below with DIM O(5) is the method it says there. It looks good - presumably as variables are saved to tape, they won't be overwritten when the program is loaded, so all the bits of BASIC that put the machine code there in the first place can be erased, leaving just the DIM statement, and there should be a separate warning to type RANDOMISE USR(address) instead of RUN. Am I right?
The code at address 0 is the reset / startup code. If this is executed the machine will reset, as after storing values in registers HL and A it jumps to the RAM fill routine. So I don’t think the running program will actually jump to this address. The carry flag must end up set so the CALL is skipped. I think the CALL is just ‘filler’. I’m not sure why this was done though.TMD2003 wrote: ↑Fri Jul 02, 2021 8:16 pm INCIDENTALLY: I found and noted a crude way to check the memory available on a ZX80, seeing as there appears not to be a way to PEEK RAMTOP and STKEND (are these even used on a ZX80?)This returns -31713 for a 1K machine and -16353 for 16K.Code: Select all
1 REM - T0 POKE 16431,201 (changes the final zero to an unprintable character which appears as ?) PRINT USR(16427)
So I tried to disassemble it and I get:
call c,0 (the printed-from-the-keyboard dash is 220 rather than 18)
add hl,sp
ret
What is going on here? On EightyOne's debugger I can't scroll up and down on the debugger screen and see what's in the ROM at address 0.
Code: Select all
1 REM 5 T0
POKE 16431,201 (changes the final zero to an unprintable character which appears as ?)
PRINT USR(16427)
Code: Select all
1 REM 5 T0
3 PRINT USR(16427)-(PEEK(16396) + 256 * PEEK(16397))
POKE 16431,201 (changes the final zero to an unprintable character which appears as ?)
I discovered that writing a double EOL ($76) at the end of a basic line the ZX80 will stop to visualize the rest of the program.Paul wrote: ↑Sun Jun 20, 2021 7:34 am A REM line doesn't work on a ZX80 because too many codes make the ZX80 crash when they are LISTed (automatically)
Please have a look at "mastering machine code" for details.
Please consider using ZX-IDE for development or at least some memory expansion while development.
Otherwise only POKE without help of routines will result in enough RAM to be free for program after finishing.
Gggggyyyyaaaaaaaaaaaaaah!