• Please review our updated Terms and Rules here

Entering code past 16k

I think there is something wrong with the emulator.

Your values don't match what is described here.
 
Last edited:
That is the conclusion I am coming to also.

I suppose it depends upon HOW the emulator works and whether they are using the original ROM code, a butchered variant of the original ROM code, or something completely different.

If the latter, then anything is possible - especially if taking the emulator out of the scope of the original functional specification or testing.

Dave
 
I just tested EightyOne 1.41. With the 48K RAM Pack and zx81.edition3.rom, after a fresh boot D_FILE is 16509 and VARS is 17302, both as expected. I'm not sure why OP has different values.
 
AaronL said:
I meant that the contents of the D_FILE on a new machine is empty. The address of the D_FILE is 32064 when starting ZX812 with a 48k RAMpack on EightyOne.

I've given up on this, to be honest, and have concluded it's simply not possible to code in basic on a ZX81 past 16k of code. Haven't abandoned the project. Have started it totally from scratch with the intention to fit a more limited version of it within 16k. Thanks for everyone's help, but unless someone can provide a snapshot of a ZX81 machine on EightyOne with code activated beyond 16k, I'm not going to pursue this as I'm spending more time trying to activate code beyond 16k than coding. Coding is my love and this is taking me away from that. I'm done trying.
Click to expand...

Is it that the memory is completely inaccessible (or the contents unreliable) or just that it's out of reach for BASIC?

IDK much about the implementation on various systems, but I don't think plain or barely modified MS BASIC for an 8-bit can access any memory above 32K using POKE/PEEK. It may also not be written to look for or use any above that point. --- Assembly language routines might be fine as long as the entry point and any returned data is accessible?

Tangentially, and this part is pure conjecture, I have no idea how EightyOne handles it's memory space.

Does it implement any memory configuration or arrangement for the ZX81 other than the base 1K or a 16K/32K/48K memory pack ?
^ The 16K memory pack (and probably the others as well) completely disables the "on-board" RAM.
^ The 16K (?) of ROM also will occupy a portion of the memory space at least some of the time.
 
Last edited:
Istarian said:
DK much about the implementation on various systems, but I don't think plain or barely modified MS BASIC for an 8-bit can access any memory above 32K using POKE/PEEK. It may also not be written to look for or use any above that point.
Click to expand...

FWIW, Sinclair BASIC is not based on Microsoft code at all. And regarding the 32K thing, the PEEK/POKE problem is mostly specific to descendants of the original 8080 Altair BASIC (Level II BASIC for the TRS-80 is the prime example), but this problem doesn't actually prevent you from peeking or poking above the 32K mark, you just need to be sneaky about it. (These basics only have one form of integer representation, 16 bit *signed* in two's complement representation, meaning numbers run from -32768 to 32767. So to POKE positions above 32767 you essentially need to invert the number so the bit pattern matches what you want; -32768 is binary 1000000000000, so start there for position 32768, and then add the number above that you want to it. The very top of 64K is thus "POKE -1")

COLOR BASIC, IE, Microsoft 6809 BASIC, accepts positive numbers above 32768, so again, not all versions of 8 bit MS BASIC have this issue.
 
I think it was only the first 8080 MS basics that needed to use -ve numbers for >32k. The first PET Basic disabled peeks above $C000 to prevent users looking at Microsoft's secret ROM code!
 
You must log in or register to reply here.
Back
Top