search

Dotneteer / spectnetide

ZX Spectrum IDE with Visual Studio 2017 and 2019 integration
MIT License
206 stars 27 forks source link

Strange problem with address 0x5c3b #221

Closed hadmir closed 3 years ago

hadmir commented 3 years ago

I encountered strange problem with address 0x5c3b (23611), which is ROM variables section. I filled some memory right after video RAM with my own bytes:

.org 16384 + 6144 + 768      
loop 50
        db something, something else, ....
endl

but address 0x5c3b is overwritten by emulator to value 0x18, even if I stopped on breakpoint on my very first instruction (which is "DI"), so nothing could write to memory "in the mean time". Any idea?

gusmanb commented 3 years ago

I tried it and can't reproduce:

.model Spectrum48
.org 16384 + 6144 + 768      
loop 50
      db 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA
endl
di

If you put a breakpoint on the DI instruction you will see the memory is filled with 0xAA, inluded the 0x5C3B address.

As you are messing with the basic vars section I think that an interrupt is happening before you really hit the breakpoint and the keyboard routine is updating the FLAGS var (0x5C3B).

hadmir commented 3 years ago

It seems to me that between emulator loads my program into memory and first instruction of my code interrupt can happen, right? I am not sure if it is a bug, if I load program from tape starting from 16384 + 6144 + 768, all the way to 65535, and then start it on 30000, for example, I don't know is it safe from ROM interrupts or not.

gusmanb commented 3 years ago

Well, if you load from tape, yes, an interrupt can happen after the data is loaded and before your code starts, that will happen also in the real machine.

If you really must use that memory zone you are going to need to disable interrupts and/or create your own custom interrupt handler routine. I would recommend to first load the handler routine, enable it and after that load the rest of the code, that will ensure no ROM interrupt code is executed and nothing messes up your data (even if you disable the INT a call to a ROM routine may re-enable it).

But, said that, the best would be to avoid that memory zone, unless you run out of memory there is no need to use it (and also, remember that low memory is contended memory, so its slower than high memory).