Spectrum memory.
ZXNet echo conference «real.speccy»
Greetings, Kirill!
IM>> In this case, IMHO, it is better to make two bytes per jar at once. What IM>> only the system program could change the second byte. KF> It’s hardly worth doing full protection on the ztnik. KF> Well, if there are 16 bits at the RAM output, then you can make 512kb of “virtual” This is already a complete garden. It’s easier to make several jars of this 16-bit memory, say 256 pieces for 256 tasks and switch tasks via the system port. The scheme is simpler, and the result is better, because you don’t have to rewrite a bunch of bytes IM>> But this thing stupidly hangs on DI HALT, because only cops KF> After all, after the cycle of writing to memory in the current command there will definitely be no more IM>> I already tried to do something similar. Just caught the cop, KF>What does the prefix have to do with it? And the question seems to be not when to give NMI IM>> Switching cans is not difficult to organize. We just need to accurately IM>> IMHO, there may be a glitch similar to the definition of interrupts by ld IM>> And it’s too late to catch address 0066, because the word is written in front of it in IM>> Now, this is bad. If the program works with the stack differently, then One page is substituted. The PC is written to it. It doesn't matter where. From there, everything will still be rewritten into system RAM. 4k(16k) of temporary memory is not a pity for clear task switching. In Sprinter, page 255 has long been reserved for such matters. It is always busy Wow! The Protoss are attacking my Zerlings! It's time to get going. Ivan. - Divorce the scheme, big and small... [Sprinter-II] [Forth-CPU] [ZX] ... ivan...@mail.ru * http://st-rektal.chat.ru * http://www.atlant.ru/peters
IM>> would be
KF> Then either 2 RAM chips, or more other 16-bit memory
KF> or you need a register and sequential reading of 2 addresses. The last
KF> option is probably the best.
Possibly. Especially if you remember that the RAM needs to be addressed sequentially, first by RAS, then by CAS. 7 addresses and no
register, and two eighths of the bits read sequentially should be used
for read only signs, etc.
KF> How can you distinguish a system program from a non-system one?
It is important to separate (to mask a record, for example). And the system, say,
works only in TR-DOS.
If the circuit is simple, then it can be done. But it’s definitely not worth turning back.
KF> memory with protection, and the rest for the system, but also with the ability
KF> to connect anywhere in the RAM with 4kb pages. And if the output from
KF> of the first RAM is applied to the input of the second, then a “virtual” memory
KF> is obtained - two different programs can thinkthat they are accessing the same
KF> address, but in fact the physical memory address will be different.
when switching tasks.
IM>> end up there.
KF> Why?
If DI HALT worked, that scheme will not be able to issue an NMI because that
there are no cycles not M1.
KF> cycles of reading the COP. And if there is a KOP after the recording, then this is
KF> the next command. Well, the processor should react to NMI just after
KF> completion of the current command. What could be wrong here? In
KF> the stack of the interrupted program is written by the PC, it starts reading the COP and the bank must be
KF> switched immediately.
Here it doesn’t even matter whether writing to memory or reading. It is important that the cycle is not M1.
But, as I wrote, this is hanging on DI HALT. I already checked...
IM>> determined whether there was a prefix or not, if not a prefix, then you can give
IM>> NMI and the next cop will be at 0066... But, it didn’t work.. :(
KF>, but when to switch the bank.
If not a prefix, then this is the last command code. So I tried to catch him.
IM>> determine the moment when the Z80 went into NMI. And for him it is defined
IM>> not exactly.
KF> Or rather, it will not be defined at all.
This is the problem.
IM>> a,r The processor catches NMI, goes to interruption either on the next
IM>> command, or after one...
KF> I don’t believe that after one!
Then, I don’t understand why my circuit was buggy...
IM>> stack...
KF> And it’s wrong -- at the moment of NMI arrival the processor could execute the program in that place
KF>.
At address 0066? It's almost impossible. In BASIC no one goes there themselves unless they want NMI, and even more so in TR-DOS. And in the zero bank of RAM you can
agree. Besides, even if NMI works because of this, the program
will not become any worse.
IM>> it will be bad. You need to catch the moment when the PC starts writing to the stack
IM>> and substitute the page.
KF>And the value of SP is unknown and it will write the PC anywhere...
KF> It is more logical to save the status of the interrupted program on its stack.
KF> And if the program does not have a stack, then to hell with it, this is an incorrect
KF> program.
anyone and anything can be written on it. Convenient temporary buffer for data.