16K memory question
16K memory question
i never had a real hardware, so i am interested: what is the result of reading from addresses [#8000..#ffff] there? is it a stable #ff (or some other value), is it wrapped, or is it totally random?
also, as we don't have fast memory in 16K, it means that IM2 is out of the question, right?
also, as we don't have fast memory in 16K, it means that IM2 is out of the question, right?
Re: 16K memory question
sure. but considering unstable bus, we need 257 equal bytes in ROM. i'm using this trick for #FF-filled ROM part in 48K, but for 16K it seems to be impossible (to use #FF). hence was my question about reading of higher memory in 16K.
- 1024MAK
- Bugaboo
- Posts: 3123
- Joined: Wed Nov 15, 2017 2:52 pm
- Location: Sunny Somerset in the U.K. in Europe
Re: 16K memory question
If the ULA is not in the process of reading screen data, a read from non-existent memory will give a value of 255 due to the data bus pull-up resistors.
If the ULA is in the process of reading screen data from the ‘lower’ RAM, the value returned will be the same as the byte read by the ULA.
In other words, the same effect when reading the I/O floating bus.
Note: this only applies in systems like a 16k ZX Spectrum where no physical ‘upper’ RAM chips are fitted (*) AND the memory is fully decoded. In a ZX81, because of partial memory decoding you will always read from a memory chip even in the apparently unused/empty areas of memory (unless an expansion alters the memory decoding).
(*) Some machines that appear to be 16k models have been found to be 48k models with partially non-functional upper RAM.
Mark
Last edited by 1024MAK on Sun Jul 05, 2020 11:08 am, edited 1 time in total.
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.
“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: 16K memory question
thank you alot! that was exactly what i wanted to know. (note about ZX81 was interesting too, thanks.)
so, no IM2, and i can't even rely on stable values from "missing" RAM. now i am sad ketmar.
p.s.: setting I to higher memory seems possible, but #FF opcode is not that useful. ;-)
- 1024MAK
- Bugaboo
- Posts: 3123
- Joined: Wed Nov 15, 2017 2:52 pm
- Location: Sunny Somerset in the U.K. in Europe
Re: 16K memory question
If the ULA does not consider the interrupt vector address to be contended and if there are no expansions fitted (or only expansions that do correctly decode I/O accesses), when reading the low byte from the bus for the interrupt vector address, the Z80 will read 255 due to the data bus pull-up resistors.
So the I register should point somewhere in ROM or in a 48k machine to upper RAM.
If pointing to ROM, the vector will be 0x00FF to 0x3FFF. There are only nine useable / practical vector addresses where the resulting destination goes somewhere useful. And of these, some are in the system variables area, or where parts of the BASIC system lives (if your are using BASIC or some of the ROM routines).
The biggest problem is most joystick interfaces use minimalist I/O decoding and will respond to the interrupt acknowledge signal from the Z80 thinking that the Z80 is doing a I/O read access So they will then put data on the data bus that the Z80 then reads as the interrupt vector
Mark
Last edited by 1024MAK on Sun Jul 05, 2020 11:07 am, edited 1 time in total.
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.
“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: 16K memory question
There goes your multicolour routine out the window, eh?
Re: 16K memory question
As long you assume there is no *evil device* connected, you can just look for usable vectors at adresses #xxFF. There was thread or two on WOS discussing this approach and I believe this demo https://spectrumcomputing.co.uk/entry/2 ... er_Forever does exactly that.
Proud owner of Didaktik M
-
- Microbot
- Posts: 132
- Joined: Tue Jun 09, 2020 6:14 am
- Contact:
Re: 16K memory question
Might be a little tricky, but see if you can set I to (#40..#7F) only during the lower border, and after there has been an interrupt, change it to point to ROM. Will probably work (if your project allows that).
Otherwise, I guess it mainly depends on how badly you need it. It's not as if your game would just stop working altogether with the ROM method, only with certain broken peripherals attached. AFAIK, 16K's are quite rare in the wild, and on models with more RAM it becomes a non-issue.
Otherwise, I guess it mainly depends on how badly you need it. It's not as if your game would just stop working altogether with the ROM method, only with certain broken peripherals attached. AFAIK, 16K's are quite rare in the wild, and on models with more RAM it becomes a non-issue.
Re: 16K memory question
not really a fan of multicolors. ;-) but i need IM2 for proper "multitasking" and other syncing. also, ROM IM routine eats too many t-states, and i need to keep IY and some BASIC sysvars in place (may be moved, but still...). this all makes proper scroller hard (if not impossible). especially considering that all memory is contended.
for simple vsync i can use floating bus. but this is not enogh. alas...
[mention]catmeows[/mention], [mention]Nienn Heskil[/mention] alas, i can't assume anything (it was a try for 16K compo, and it doesn't guarantee the exact config), so it can be any 16K. and i need IM2 for scheduling, the whole idea was to avoid explicit checks as much as possible, and let interrupt handler do it for me. sighs.
anyway, the original idea doesn't seem to work. i'll prolly try something else then. i am a little sad, because for 48K the idea is too simplistic and doesn't worth implementing.
- 1024MAK
- Bugaboo
- Posts: 3123
- Joined: Wed Nov 15, 2017 2:52 pm
- Location: Sunny Somerset in the U.K. in Europe
Re: 16K memory question
The interrupt to the Z80 occurs at 50Hz (for PAL systems) and is generated by the ULA from the video timing chain inside the ULA. So it is synchronised with a particular part of the ULA screen timing. But there is a very slight delay before the Z80 processes the interrupt, hence the actual time seen by the Z80 may vary by an instruction cycle (early or late). The actual timing is also said to vary slightly depending on ULA temperature (but it may also be affected by Z80 chip temperature).
Mark
Mark
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.
“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: 16K memory question
I think you can always provide 16K wild version with option to generate proper table on 48K. I will create16K compo FAQ when I will be back by my desktop on Monday. But please consider granted that whatever works on plain ZX 16K is within rules.
Proud owner of Didaktik M
Re: 16K memory question
[mention]1024MAK[/mention] yeah, i know, i researched it for ZXEmuT. yet ZXEmuT never emulated 16K, so there wasn't any real need to learn 16K details. the idea was to use IM2 to interrupt game logic when it's time to refresh the screen, so i could skip checks in playsim code, and simply let it process as much simulation as it can, then render new game state, and continue with playsim processing loop as if nothing happened.
[mention]catmeows[/mention] thanks. i'm still in a little trouble (because i forgot to subtract screen$ from 16K, so i was sure that i have much more free RAM), but if i can get away with two-byte interrupt table, then not all hope is lost! ;-)
[mention]catmeows[/mention] thanks. i'm still in a little trouble (because i forgot to subtract screen$ from 16K, so i was sure that i have much more free RAM), but if i can get away with two-byte interrupt table, then not all hope is lost! ;-)