sjasmplus
sjasmplus copied to clipboard
device ZXSPECTRUM128 fake sysvars look insufficient
The 128 device is using same fake sysvars as 48, from 0x5C00 up. The 0x5Bxx sysvars are left zeroed.
This seems problematic as for example BANK 0x5B5C should contain ROM number and that's usually 0x10 value to have 48 ROM, while 0x00 is 128 editor ROM.
Also tests/macro_examples/sj_sysvars.i.asm has only zx48 sysvars.
TODO: get actually some simple docs about the extended 128 sysvars, as I didn't find anything simple to check. The 0x5B5C is at least mentioned here: https://worldofspectrum.org/faq/reference/128kreference.htm
- need to remove sysvars from all machines (sjasm not for spectrum only)
- add function sysvars %machine% (spectrum1024 using to build spectrum48 software spectrum128 for spectrum1024 hardware not need sysvars at all)
- all real device modes like ZXSPECTRUM** must be deprecated
or need new devices without sysvars but with savesna %)
@NEO-SPECTRUMAN
or need new devices without sysvars but with savesna %)
DEVICE ZXSPECTRUM48
DS 0x10000, 0 ; erase whole virtual 64ki memory (sysvars, fake CLS, ...)
ORG $8000
ret
SAVESNA "test.sna",$8000
:rofl: :facepalm:
The 128 device is using same fake sysvars as 48, from 0x5C00 up.
I do not think this is a bug, it is rather a "feature". The described setup is typically referred to as "USR 0", which is the easiest way to get 128K configuration with paging enabled, yet only 48K BASIC operational. One literally types USR 0 in 128K BASIC and presses a return key. This configuration is easier to work with, precisely because BASIC does not touch pages, so you can do whatever you like, even in pure BASIC.
Fundamentally, the choice between configurations with 128K BASIC enabled or disabled is the choice of preferred system environment. If you add to this the fact that some people might prefer active (or inactive) TR-DOS, you are literally opening a can of worms. I do not mean that there should not be an explicit control over the environment. Someone might need 128K BASIC operational, someone else might need 48K BASIC operational, TR-DOS, Microdrive also move things around, so correspond to different memory layouts. Because supporting all these configurations would be a nightmare, I actually think that the current default is, in many ways, the safest default to use (for DEVICE ZXSPECTRUM128K). It is definitely not a bug.
The easiest solution that should probably be sufficient for pretty much everyone would be to create a small library that can reset the emulated memory, similar to what you showed above, but with ready-made profiles for several common configurations.