16K memory question

[ketmar]

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?

[catmeows]

also, as we don't have fast memory in 16K, it means that IM2 is out of the question, right?

No. You can point I reg to ROM.

[ketmar]

also, as we don't have fast memory in 16K, it means that IM2 is out of the question, right?

No. You can point I reg to ROM.

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]

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?

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

[ketmar]

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 RAM chips are fitted (*) AND the memory is fully decoded.

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]

No. You can point I reg to ROM.

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.

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

[XTM]

There goes your multicolour routine out the window, eh?

[catmeows]

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.

[Nienn Heskil]

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.

[ketmar]

There goes your multicolour routine out the window, eh? ;)

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]

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

[catmeows]

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.

[ketmar]

[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! ;-)