Boriel ZX Basic compiler - a text-thirsty idea needing memory

[PeteProdge]

As I never really progressed out of BASIC on the Speccy, aside from a few experiments, if I'm to write my first game I think Boriel ZX Basic compiler is the way to go. Something I can comprehend, with the luxury of quick tests and save states in a modern computing environment.

Anyway, I'm fully aware of the Spectrum's memory limitations, particularly on text. Quiz games tend to repeat questions if you play them for more than an hour.

I'm aware of the tricks you can do to be economical on words, like setting a numerical token (0-255) for the 256 most common words ("the", "what", "when", "how", "where", etc...). I'm still astounded how Scrabble did it!

I'd like to know if Boriel ZX Basic is prepared to utilise all of the 128K memory (yeah, I'm prepared to make it a 128K-only game, I want the widest possible variety of questions/answers).

[Alessandro]

Answer 1: As of now, ZX Basic cannot address the whole 128 and later models memory. A possible workaround would be to divide your program in several parts to recall when needed, even better as compressed data. Also, you must store the variables in a safe area under the first byte of each part so that each of them "knows" where to read and modify them. I did all of the above for Ad Lunam Plus.

Answer 2: Another suggestion, based on my personal experience with Italia 1944, would be to store text in string groups and compress them, then recall them when needed, printing them with the ROM routine and eschewing the PRINT command altogether. It can be labourious but it saves a lot of RAM indeed.

[PeteProdge]

Ah, that's disappointing to learn, but thanks for your detailed reply.

Still grateful that ZX Basic exists, of course.

[Alessandro]

You can also ask Jose himself on the ZX Basic forum for more insight:

https://www.boriel.com/forum/

[textvoyage]

Hello
I've thought about storing large amounts of data in 128 mode with Boriel... using the 128 RAM disc and a 128 BASIC program to access the files saved on there, copying the data into the Spectrum's RAM then jumping back into the Boriel code. Never tried it though!

[PeteProdge]

Hello
I've thought about storing large amounts of data in 128 mode with Boriel... using the 128 RAM disc and a 128 BASIC program to access the files saved on there, copying the data into the Spectrum's RAM then jumping back into the Boriel code. Never tried it though!

I used to do that in 128 BASIC.

Code: Select all

LOAD ! "thing" CODE 40000

Fine on my grey +2, but it would be incompatible with the +2A and the +3, which needed to be:

Code: Select all

LOAD "m:thing" CODE 40000

If I find a way to do this with Boriel ZX Basic (and, if necessary, a bit of external work), then I will likely proceed with my quiz game idea. If not, well, there's not much longevity in it in the parameters of 48K.

[Alessandro]

The RAM disk can only be accessed via 128 BASIC. In my experience, it is not a good idea to use it - file allocation is not contiguous, meaning that some space will be wasted. Moreover, the syntax is different for the 128/+2 and +2A/+3, so that unless you employ a trick Einar taught me in order to identify the machine the program is running on (*), whenever you need to access the files stored in the RAM disk, you will need to write two different versions of the BASIC RAM disk management program.

Again, it would be much better to store the different parts across RAM banks (preferably in compressed form in order to save space) and recall them when needed.

(*) From 128 BASIC or +3 BASIC, PEEK the value stored in the ROM at 2899. If it is 159, the machine is a 128/+2, whereas if it is 126 it is a +2A/+3.

[textvoyage]

Ooh a bit painful, I didn't know about the 128/+2 and 2A/3 differences, just needs an IF statement and an extra line of BASIC though
Also If your Boriel code starts from 40010,in your Boriel section you could poke 40009 with a file number then peek it from 128K basic, e.g. LOAD ! "file"+STR$ PEEK 40009
I didn't know about memory wastage on the RAM disc either, would be interesting to look at its limitations and see if you can make the best of the situation

[PeteProdge]

Ooh a bit painful, I didn't know about the 128/+2 and 2A/3 differences, just needs an IF statement and an extra line of BASIC though
Also If your Boriel code starts from 40010,in your Boriel section you could poke 40009 with a file number then peek it from 128K basic, e.g. LOAD ! "file"+STR$ PEEK 40009

Having never made anything of any worth in machine code, I can't say I've ever seriously taken advantage of the 128K memory before. I know on 48K and 128K machines you can easily read/write the standard 49152 bytes of RAM, but I've sadly never got my head round the 'paging' system the 128K uses for accessing the 114,688 bytes of RAM. I know you can't access it all at once, I think it's something like bringing in a chunk of it at a time - making a 'call' on it when needed.

I very much doubt the 128/+3 BASIC RAM disc is the way forward. I'm trying to avoid BASIC (yeah, I know, that's rich when I'm coding in another BASIC language) and have this feel as much like a machine code game as possible. I don't want it to have that compiled basic feel, even though it will be exactly that.

Of course, I'm hoping someone more knowledgeable on this matter in this forum (literally everyone else, really) can point me in the right direction. And yeah, I've probably made a few errors in my opening paragraph too.

[AndyC]

In very simple terms, paging lets you change which 16K block of RAM the Z80 "sees" from addresses #C000 to #FFFF. So you can access any part of the full 128K by swapping in and out a chunk at a time.

If you want to access the full 128K it's far easier to get your head around memory paging than trying to faff about with the RAMdisk, if only to avoid all the complex mess between models (although contention differences can add their own complications anyway)

[PeteProdge]

In very simple terms, paging lets you change which 16K block of RAM the Z80 "sees" from addresses #C000 to #FFFF. So you can access any part of the full 128K by swapping in and out a chunk at a time.

If you want to access the full 128K it's far easier to get your head around memory paging than trying to faff about with the RAMdisk, if only to avoid all the complex mess between models (although contention differences can add their own complications anyway)

So, as a massive oversimplification and being heavily optimistic...

You stick your game engine (and overall graphics and sound) into #5B00 to #C000.

If you have six levels, then the map data and level-specific graphics/sound for any of them fits into #C000 to #FFFF, you just page that in when needed.

Is that kind of right?

[catmeows]

Yes, you got it right and as AndyC says it is probably the most sane way to exploit extra memory.

[Alessandro]

You stick your game engine (and overall graphics and sound) into #5B00 to #C000.

And variables data and the heap, the buffer area (especially needed if you use many PRINT instructions) as well, since you will need them for each part. The heap is placed at the start of the code before the variables area. If you compile with the --mmap memory.txt option, the MEMORY.TXT file will show you the detailed memory usage for your program. You can set the heap size in bytes with the --heap-size option. Also see:

https://zxbasic.readthedocs.io/en/docs/ ... ne_Options

[AndyC]

Yeah, that's the basic idea. As long as you keep a good eye on what is currently visible (classic mistakes being paging out the stack or interrupt vectors for example) then you're all good.

A lot of "real" 128 games just use the extra RAM as storage space and essentially "LOAD" the data out of the extra banks and into the usual 48K space, copying blocks via temporary buffers, since this can then be easily adapted to being a 48K multiload arrangement (just LOADing from tape instead).

[TMD2003]

I used to do that in 128 BASIC.

Code: Select all

LOAD ! "thing" CODE 40000

Fine on my grey +2, but it would be incompatible with the +2A and the +3, which needed to be:

Code: Select all

LOAD "m:thing" CODE 40000

If I find a way to do this with Boriel ZX Basic (and, if necessary, a bit of external work), then I will likely proceed with my quiz game idea. If not, well, there's not much longevity in it in the parameters of 48K.

This thread's already gone past the point of discussion, but I'd second what Alessandro said about PEEKing an address in the ROM that's different between the two +2s. It's a technique I used to make the tape version of the recent Ring Of The Inka remix (which, for some bizarre reason, has escaped being put on ZXDB but is available via the 2021 CSSCGC site) - as the game made full use of the readily-available 48K but still had to load all the screens from somewhere if it wasn't the microdrive, the RAM disc was the obvious choice, hence the tape version was limited to 128K machines. The initial loader program checks what model is being used with two PEEKs:

(I've removed the VALs from the lines in the actual program so it makes a bit more sense...)

30 IF PEEK 23611=204 THEN GO TO 900
- PEEK 23611 is 204 for a 16K/48K model, or any 128K model in 48 BASIC mode; if it finds this value, the routine at 900 will tell you you've used the wrong machine, then stop. PEEKing the same address on any 128K model in 128/+3 BASIC returns 221.

50 IF PEEK 2899=159 THEN SAVE !"s" CODE 16384,4096
55 IF PEEK 2899=159 THEN SAVE "m:s" CODE 16384,4096
- There were three such instances of these lines in the loader, each involving loading something from tape (in this case, the loading screen that only fills two-thirds of the screen so doesn't need the full 6912 bytes) and dumping it to the RAM disc for later use. I'm 99% sure I heard about these PEEKs from Alessandro some years ago, not just on this thread, and probably not even on this forum, so these are the values I've always used. The upshot of the SAVE ! syntax from the 128K/+2 is that the program must be written on this model because the +3 BASIC editor on the black-cased ROM 4.1 models will reject it - but it can be saved to tape and reloaded on those models and it should work as intended.

Of course, all this will be completely irrelevant if Boriel BASIC can't handle the SAVE ! syntax...

[Einar Saukas]

It's a technique I used to make the tape version of the recent Ring Of The Inka remix (which, for some bizarre reason, has escaped being put on ZXDB

This one?

https://spectrumcomputing.co.uk/entry/3 ... ve_Edition

[TMD2003]

This one?
https://spectrumcomputing.co.uk/entry/3 ... ve_Edition

Yes, that one - I referred specifically to the microdrive version being the only format hosted. This was always Volker's intended method of delivery, I will admit, but I went to a fair bit of trouble getting the tape version to work correctly (I've still got all the background programs stashed away alongside it) with Volker's full support for doing so, and there's three disc versions as well (DSK, MGT, TRD).

[Alessandro]

This thread's already gone past the point of discussion, but I'd second what Alessandro said about PEEKing an address in the ROM that's different between the two +2s.

In fact I stated that it was Einar who taught me it

[TMD2003]

What goes around comes around...

Since then, I've dug through a whole load of different ROMs seeing what differences there were. I really should publish my findings - somebody, somewhere, will want to know how to tell the difference between a Toastrack and a +2, and the answer lies in the copyright message in 48 BASIC.

PEEK 5440 = 83 on 16K, 48K, + or 128K (CHR$ 83 = S)
PEEK 5440 = 65 on +2, +2A, +3 (CHR$ 65 = A)

PEEK 2899 has three different values - 165 for the 48K, 159 for the 128K/+2, 126 for the +2A/+3. I'm sure one of my 2020 CSSCGC games fell foul of that when I'd put a detector in the loader that checked to see if the value was 159 and if it wasn't, it'd stop - but it was designed to weed out 48K models, not the black Amstrads as well...

I can't edit the post above - this is what it should have said (and does, if you MERGE the Ring Of The Inka initial loader):

50 IF PEEK 2899=159 THEN SAVE !"s" CODE 16384,4096
55 IF PEEK 2899=126 THEN SAVE "m:s" CODE 16384,4096

[+3code]

https://spectrumcomputing.co.uk/list?group_id=2074

Oh, my awesome Fishing Simulator isn't here, now I will cry 8~(

[TMD2003]

About half the games from last year still need to be added.

[Jbizzel]

Could you do it as a multi loader game?

You could poke some values into memory with the first load, and then the second loader would only load if it finds the value you poked? Pass the scores this was too?

[PeteProdge]

Could you do it as a multi loader game?

You could poke some values into memory with the first load, and then the second loader would only load if it finds the value you poked? Pass the scores this was too?

Noo! It's a relatively easy game to progress through, could take around 15 mins and really, doesn't need five multiloads breaking that up!

Mind you, I am looking at a totally different game idea and I don't think it'll need a multiload. My New Year's Resolution was to write and publish an original ZX Spectrum game and although I've started late, last night I spent a couple of hours on a main sprite and its animation... which is looking really good (and I say that as a pessimist about my 8-bit artwork skills). Once I've made a very basic game engine I'm pleased with, I'll start a new thread here about this upcoming game, it's very much NOT the one I started this thread about.

Fingers crossed, should be out by the end of the year.