Sinclair ZX80 / ZX81 / Z88 Forums

Hi,
Just one byte to change… offset 4.

Any reason why RAM check can't go to FFFF?

Hi Martin,

Yes…
The A15 address bit is use in the Hardware process (display).
And the D_file can't be updated ( read error ) up to $BFFF !

Upper memory can be use as a DATA room, but the PC (CPU Pointer) can't reach this location.

$7FFF= "0111 1111 1111 1111"
$BFFF= "‭1011 1111 1111 1111"
B15 and B14 = >> PC error/display error.‬

It's a good raison.

But this is only a limit for ML. Basic should have no problem using all memory, right?

This modification will be to set the RAMTOP, so you don’t need to set it yourself with POKE/NEW, right?

Why not test the full RAM, to get RAMTOP set right from the start.

But this is only a limit for ML. Basic should have no problem using all memory, right?

No, the Basic program is not "Read only" data base !
The D_File en the Vars had to be reach by the PC's CPU pointer… and the stack room above the Ram_top … too!

This modification will be to set the RAMTOP, so you don’t need to set it yourself with POKE/NEW, right?

Yes, it's already done in the boot sequence.

Why not test the full RAM, to get RAMTOP set right from the start.

If the basic d'ont reach the "dead zone", the CPU Always use the stack process (Push and Pop), in the Basic monitor and can't access to the A15 & A14 room, without destroy the display process (From the ULA).

On an imperfect emulator, you are able to set the Ram_top at $FFFF, but in the true live… the hardware will give an address conflict.

If you look at chapter 27, you will see the memory map of the areas of the RAM (link). Keep in mind this memory map is assuming that RAM is between 1K byte and 16K bytes.

Any area where the CPU tries to directly execute code where A15 of the address is 1 (so above 0x7FFF) will result in the ULA thinking it is an attempt to display the screen, hence most bytes read from memory will be intercepted by the ULA and it will instead override the actual read data and send the NOP op-code to the Z80 CPU.

The CPU can read memory above 0x7FFF (e.g. by using LD). It just can’t execute code above this address. See here.

Mark

Hi,

this memory map is assuming that RAM is between 1K byte and 16K bytes.

Yes, it's true.

Sinclair NEVER assume to build a memory pack up to 16kb.
Memotech had to remap the memory decoder…

Sincair's desire was to clamp down the zx81 to 16kb, due to hardware build-in conflicts.

I think we misunderstand each other.

I asked: Why not set the RAMTOP to FFFF?

Because this memory will be fine for all except executing ML.

I assume Basic lines can be there, and I assume Basic Vars can be there. Only problem will be if D-File is on top of the $8000 address.

Reading zxdocs I see what you say. Basic Vars can be above $C000, but Basic code cannot because the D-file has to be below.

48K RAM
RAM is located at 4000h-FFFFh, same restrictions as for 32K RAM apply. The memory at C000h-FFFFh can be used as data storage only, but not for machine code execution, and not for video data 'execution'.
When patching the RAMTOP value use the maximum of FFFFh (indicating 48K minus one byte), as video memory must be below C000h, BASIC program code is restricted to less than 32K as well, BASIC variables may use the additional memory though.
Some 16K expansions can be combined with 32K expansions to gain a total of 48K RAM.

But why still not set RAMTOP to $FFFF if I want to load a program with a lot of data?

Does setting RAMTOP to $0000 work as well on a real ZX81?