Sinclair ZX80 / ZX81 / Z88 Forums

I'm half-sure I've seen it mentioned here before, but it's best to ask the experts...

Seeing as I am trying to encourage machine code programming on the 1K ZX80, I figured I should try it myself. However, there's a potential problem - generating the REM statement in the first place. It's arduous enough trying to type out the entire 1 REM XXXXXXXXXX... and so on until the memory's all but full, but if I want to venture further into a 3K, 4K, 8K, 16K ZX80 just to have more room to move, that REM statement is going to be utterly enormous.

I know I've seen some kind of BAS2P program out there somewhere to transform PC text files saved as .BAS to a ZX81 .P file (or .81), but does such a thing exist for the ZX80 to turn .BAS into .O (or .80) files? That way, I can make a text file that consists of:

1 REM XXXXXXXXXX...
2 RANDOMISE USR (16427)

...and I can do so with as many Xs as I need, which are easily adjustable.

And, hopefully this isn't a noobish question: if the machine code program consists of multiple routines broken up by RETs, can they be held in multiple REM statements, provided the 2 REM..., 3 REM..., 4 REM... etc is accounted for?

How did ZX81 machine code programmers do it in t'old days, especially those who used every single byte available on the wobbly RAM pack?

I dare to say that development was often done on a different machine and then only tested on a ZX81.

Before using the PC I did that on the ZX Spectrum for the ZX81 and as for my current optimized 1K code I can't code that on a ZX81 since it doesn't use a REM-line or start to MC on the mormal BASIC program positions.

I think most programming started with a hex loader. A good place to start is Mastering Machine Code on Your ZX81 or ZX80, chapter 2. This chapter explains how to enter programs even on 1k. In this book, ZX80 is referred to as the "OLD ROM".

I thought of a hex loader initially, mainly because I remember this one from Sinclair Programs back in the day:
https://archive.org/details/sinclair-pr ... ew=theater

That starts with the 1 REM XXXXXX... line that I'm trying to auto-generate (seeing as it might be 700 Xs long at worst). I notice it says "don't use the number 118 in the code or it'll do all sorts of weird things", which I looked up and found it was the HALT instruction that Toni Baker has declared absolutely verboten.

I've typed in both, minus the REM line, and I find the Sinclair Programs hex loader takes up 135 bytes, and Toni Baker's is 154 bytes but will store the machine code somewhere I wasn't expecting. I'm tempted to stick with the Sinclair Programs version, mainly because it's storing the machine code where I expect it to be.

Maybe I should just crank EightyOne up to maximum speed and fill the REM statement manually after all...

EDIT: 384 Xs and there's only two lines of the BASIC hex loader left on the screen...

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.

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)

Right! The things I didn't know about the ZX80 are many (mainly because I never owned one back in the day, or now).

I'm determined to make a ZX80 do something with 1K of machine code, mainly because that's all most initial users would ever have had to play with. What I've found on the ZX81, at least the EightyOne emulation of it, is that the exact same 1K-suitable BASIC program typed in on a 16K machine, when saved, will require more bytes - so if I'm writing for the 1K ZX81 I have to keep it in 1K mode, no matter how many pitfalls there may be along the way. Why is this - was that the way the original hardware worked, or is it a quirk of EightyOne?

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.

Is this only 1k that causes the crash as I have seen quite a few ZX80 programs, using many REM lines, with no problem?

TMD2003 wrote: ↑Fri Jun 25, 2021 12:52 pm What I've found on the ZX81, at least the EightyOne emulation of it, is that the exact same 1K-suitable BASIC program typed in on a 16K machine, when saved, will require more bytes - so if I'm writing for the 1K ZX81 I have to keep it in 1K mode, no matter how many pitfalls there may be along the way. Why is this - was that the way the original hardware worked, or is it a quirk of EightyOne?

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.

According to the linked to web page, the ZX80 does not save its display file (D_FILE / VRAM) to tape (link).

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).

Mark

Mark

Moggy wrote: ↑Fri Jun 25, 2021 1:14 pm Is this only 1k that causes the crash as I have seen quite a few ZX80 programs, using many REM lines, with no problem?

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.