Running L/M in the high memory area (48-64KB)
Re: Running L/M in the high memory area (48-64KB)
* You can run code between 32 - 48k if you have a small modification to the machine. This is known as the 'M1NOT' mod. You can google it.
* You cannot ever run code between 48 - 64k as the hardware design of the machine forbids it. It is the image generation hardware that imposes this restriction.
C
* You cannot ever run code between 48 - 64k as the hardware design of the machine forbids it. It is the image generation hardware that imposes this restriction.
C
- RetroTechie
- Posts: 379
- Joined: Tue Nov 01, 2011 12:16 am
- Location: Hengelo, NL
- Contact:
Re: Running L/M in the high memory area (48-64KB)
The ZX81 ULA uses a special type of Z80 instruction fetches (M1 cycle) to detect when data should be written to the screen. Specifically: Z80 instruction fetches in 8000-FFFFh area (A15 = 1), where bit 6 of the opcode is 0, and Z80 /Halt signal is inactive. Whenever such an instruction fetch occurs, the ULA forces the Z80 to execute a "NOP" instruction, the original opcode is used as a partial memory address (usually pointing to ROM), and the data from there is shifted as pixels to the screen. This is called "DFILE execution", and in SLOW mode it's what the Z80 is doing roughly 3/4 of the time.
That distinction between 0000-7FFFh and 8000-FFFFh (Z80 A15) is used to decide between "normal Z80 code execution" and "write data to the screen". Read: those 2 things can never occur simultaneous. Either the Z80 is executing regular code (and the screen goes blank, as in top/bottom/border), OR screen data is produced (and the Z80 executes NOPs).
The A15 = 1 condition means you can't execute regular code in 8000-FFFFh, because of how the ULA reacts to that. For 8000-BFFFh, this restriction is not necessary, hence the "/M1 not" fix so you can run code if there's RAM there. Doing something similar for C000-FFFFh range however, would disable all screen output (as Mark said). Therefore:
That distinction between 0000-7FFFh and 8000-FFFFh (Z80 A15) is used to decide between "normal Z80 code execution" and "write data to the screen". Read: those 2 things can never occur simultaneous. Either the Z80 is executing regular code (and the screen goes blank, as in top/bottom/border), OR screen data is produced (and the Z80 executes NOPs).
The A15 = 1 condition means you can't execute regular code in 8000-FFFFh, because of how the ULA reacts to that. For 8000-BFFFh, this restriction is not necessary, hence the "/M1 not" fix so you can run code if there's RAM there. Doing something similar for C000-FFFFh range however, would disable all screen output (as Mark said). Therefore:
WILL NOT WORK, PERIOD. 2 options remain:user@lab1 wrote:The purpose is to avoid the use of memory below the address C000...
- Modify a ZX81's hardware such that screen output is still produced even if you execute regular code in C000-FFFFh area. Read: largely duplicate ULA function, and probably rewrite a good bit of ROM code too. Resulting machine would not be a ZX81 anymore, and probably fail to run a lot of ZX81 software. If this is your goal: get a ZX Spectrum. Or MSX, or Amstrad CPC, whatever.
- In theory: limit yourself to opcodes that have bit 6 = 1 (any value for operands / data should be okay). Hard to write useful code that way, but would be interesting to see if that works (both for real ZX81's, and emulators).
Re: Running L/M in the high memory area (48-64KB)
Well - if Mic can wait a little bit, he may use my new RAM extension for existing ZX81 hardware. This technic is proofed with my new ZXmore design where it is possible to run any code in $0000-$FFFF. This feature works with standard text display only (no HRG) and allows to use the whole area for program or data. The DFILE is no longer mirrored - it is switches during video execution period. So you have additional 16k of memory between $C000-$FFF to use for drivers or something. This interface will contain parts of ZXmore's hardware and available in about two month - something like that.sirmorris wrote:* You cannot ever run code between 48 - 64k as the hardware design of the machine forbids it. It is the image generation hardware that imposes this restriction.
Re: Running L/M in the high memory area (48-64KB)
You never cease to amaze me, Karl!
Re: Running L/M in the high memory area (48-64KB)
Never say never, with enough i imagination anything is possible,
Karl, so is it like an automatic page switch during video generation?
Karl, so is it like an automatic page switch during video generation?
what's that Smell.... smells like fresh flux and solder fumes...
- 1024MAK
- Posts: 5118
- Joined: Mon Sep 26, 2011 10:56 am
- Location: Looking forward to summer in Somerset, UK...
Re: Running L/M in the high memory area (48-64KB)
The ZX81 was designed as a simple machine. As part of this, it has incomplete address decoding. So a standard unmodified ZX81 has echoes of the 8k ROM and the 1k RAM.user@lab1 wrote:Thanks for your answers...
My idea is simply to load M/C at any point between the addresses C000 and FFFF, then run it directly with a command like: "RAND USR address" or "PRINT USR address", without first having to move everything in the low memory. For example: load the part in M/C of a turboloader in high memory and run it when I need it. The purpose is to avoid the use of memory below the address C000...Mark, what do you mean? can you be more specific?It is possible to modify a ZX81 so that M/C can be run in the 48k to 64k area, but if this is done, there will be no screen display (as in standard ZX81 display)...
An echo is where the same memory can be seen by the CPU at more than one (or indeed multiple) addresses.
Even when a 16k RAM pack is connected, this RAM is echoed in the upper half of the memory map.
The hardware (the ULA) takes advantage of this so that the Z80 CPU can be used to help generate the screen display (along with the ULA).
Now, there is no need for the ROM to be seen by the CPU anywhere except in the 0000 to 1FFF area. But as the Z80 has to process the screen, the RAM echo of 4000 - 7FFF at C000 - FFFF has to stay. However, extra hardware can select extra RAM (for use only as a data storage area) to be mapped in this area when the Z80 is not executing code in this area.
Code: Select all
A15 A14
0 0 0000 - 1FFF ROM
0 0 2000 - 3FFF normally an echo of 0000 - 1FFF ROM, but can be extra ROM or RAM (area not used by ZX BASIC)
0 1 4000 - 7FFF 16k RAM
1 0 8000 - 9FFF normally an echo of 0000 - 1FFF ROM, but can be RAM
1 0 A000 - BFFF normally an echo of 2000 - 3FFF ROM, but can be RAM
1 1 C000 - FFFF an an echo of 4000 - 7FFF RAM. For Z80 program execution has to stay as an echo of 4000 - 7FFF
RAM. But extra RAM can be mapped here to hold data. Any data.
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: Running L/M in the high memory area (48-64KB)
Yes - there is a flipflop indicating video execution which overdrives A15 and set it to low - so no mirroring is necessary.Andy Rea wrote:Never say never, with enough i imagination anything is possible,
Karl, so is it like an automatic page switch during video generation?
Out of video execution A15 is switched to A15 and allows data access and program execution as well.
This technique can not 100% transferred to an original ULA but can be modified to overdrive the ULA when not executing video by manipulating D6 at the right time. I didn't realize now but found this technique used from the Memotech HRG interface - so would say it is possible in general.
Re: Running L/M in the high memory area (48-64KB)
Thanks for the detailed informations, the behavior of the memory area located between C000 and FFFF for me is always been unclear.
But I think to wait that Karl (Pokemon) terms the development of its memory expansion.
If it works like ZX81XRAM, will certainly be a very interesting object...
Mic.
I want to use this area of memory, only for resident utility and driver and leave the 32k below available for the basic programs.One question though: why would you want/'need' to do this anyway? Up to 32K machine code not enough?
But I think to wait that Karl (Pokemon) terms the development of its memory expansion.
If it works like ZX81XRAM, will certainly be a very interesting object...
Mic.
Re: Running L/M in the high memory area (48-64KB)
But this does not work with a big BASIC program, which has its DFILE above 32K: there no mirroring is necessary, but A15 must stay HIGH to allow access to the DFILE!PokeMon wrote:Yes - there is a flipflop indicating video execution which overdrives A15 and set it to low - so no mirroring is necessary.Andy Rea wrote:Never say never, with enough i imagination anything is possible,
Karl, so is it like an automatic page switch during video generation?
Siggi
My ZX81 web-server: online since 2007, running since dec. 2020 using ZeddyNet hardware
http://zx81.ddns.net/ZxTeaM
http://zx81.ddns.net/ZxTeaM
Re: Running L/M in the high memory area (48-64KB)
Yes - you can not have all.
Basic with 32k is possible but then you won't have more than 32k at all ($4000-$BFFF).
This is a configuration option. 32k programs are not very common - so this has to be selected in the control image.
Anyway it is possible to start 2 different ZX81 sessions concurrently, one with 32k BASIC and one with 16k BASIC and additional 32k for data and drivers.
Basic with 32k is possible but then you won't have more than 32k at all ($4000-$BFFF).
This is a configuration option. 32k programs are not very common - so this has to be selected in the control image.
Anyway it is possible to start 2 different ZX81 sessions concurrently, one with 32k BASIC and one with 16k BASIC and additional 32k for data and drivers.