32 kb ROM patch.
32 kb ROM patch.
Hi,
Just one byte to change… offset 4.
Just one byte to change… offset 4.
Xavier ...on the Facebook groupe : "Zx81 France"(fr)
Re: 32 kb ROM patch.
Any reason why RAM check can't go to FFFF?
Re: 32 kb ROM patch.
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.
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.
Xavier ...on the Facebook groupe : "Zx81 France"(fr)
Re: 32 kb ROM patch.
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.
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.
Re: 32 kb ROM patch.
No, the Basic program is not "Read only" data base !But this is only a limit for ML. Basic should have no problem using all memory, right?
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!
Yes, it's already done in the boot sequence.This modification will be to set the RAMTOP, so you don’t need to set it yourself with POKE/NEW, right?
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).Why not test the full RAM, to get RAMTOP set right from the start.
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.
Xavier ...on the Facebook groupe : "Zx81 France"(fr)
- 1024MAK
- Posts: 5118
- Joined: Mon Sep 26, 2011 10:56 am
- Location: Looking forward to summer in Somerset, UK...
Re: 32 kb ROM patch.
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
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
ZX81 Variations
ZX81 Chip Pin-outs
ZX81 Video Transistor Buffer Amp
Standby alert
There are four lights!
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
Looking forward to summer later in the year.
ZX81 Chip Pin-outs
ZX81 Video Transistor Buffer Amp
Standby alert
There are four lights!
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
Looking forward to summer later in the year.
Re: 32 kb ROM patch.
Hi,
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.
Yes, it's true.this memory map is assuming that RAM is between 1K byte and 16K bytes.
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.
Xavier ...on the Facebook groupe : "Zx81 France"(fr)
Re: 32 kb ROM patch.
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.
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.
Re: 32 kb ROM patch.
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.
But why still not set RAMTOP to $FFFF if I want to load a program with a lot of data?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.
Re: 32 kb ROM patch.
Does setting RAMTOP to $0000 work as well on a real ZX81?