Recoding my ZX81-emulator: IM2-table

[Dr beep]

I am recoding (speeding up) my ZX81 emulator for the 48K ZX Spectrum.

I can make it quicker but I can use some info.

1) to keep code smaller I only want to use the IM2 table as if no hardware is attached (FF). Will this do or is due to some hardware a full table needed?

2) The emulator is now fully coded in upper memory (>32k). What are the speedeffects of coding or storing tables in lowermemory (contented memory)? I will need this part of memory but at this moment I can either store tables which are read once on each opcode or screentables and intruptroutine to be executed more times per second. I want the fastest program possible. Loading and saving is stored here too, but that is no issue during emulation.

As for you all... this is the old emulator: https://www.worldofspectrum.org/infosee ... id=0015646

[PROSM]

1) to keep code smaller I only want to use the IM2 table as if no hardware is attached (FF). Will this do or is due to some hardware a full table needed?

It is widely assumed that you can't guarantee what will be on the data bus when the interrupt occurs, so for safety, you'd be best off generating a full table. Since the LSB could be set or reset, you should make each byte the same value, hence your interrupt routine's address should have identical high and low bytes.

2) The emulator is now fully coded in upper memory (>32k). What are the speedeffects of coding or storing tables in lower memory (contented memory)? I will need this part of memory but at this moment I can either store tables which are read once on each opcode or screentables and intruptroutine to be executed more times per second. I want the fastest program possible. Loading and saving is stored here too, but that is no issue during emulation.

When accessing contended memory, the CPU is made to wait whilst the ULA fetches the data it needs (more detail here). If you must use it, then you would be best just storing data there rather than code, as less contended reads will be required, and thus less delay will occur.

If I understand your post correctly, you have the loading and saving code stored in contended memory, but it works correctly. If that's the case, your emulator probably doesn't emulate contended memory, and for the purposes of debugging, you'd be better off trying something like Fuse or Spectaculator.

Bear in mind that you cannot store the IM2 table here, as otherwise ULA snow will result (more information here).

[Dr beep]

1) to keep code smaller I only want to use the IM2 table as if no hardware is attached (FF). Will this do or is due to some hardware a full table needed?

It is widely assumed that you can't guarantee what will be on the data bus when the interrupt occurs, so for safety, you'd be best off generating a full table. Since the LSB could be set or reset, you should make each byte the same value, hence your interrupt routine's address should have identical high and low bytes.

2) The emulator is now fully coded in upper memory (>32k). What are the speedeffects of coding or storing tables in lower memory (contented memory)? I will need this part of memory but at this moment I can either store tables which are read once on each opcode or screentables and intruptroutine to be executed more times per second. I want the fastest program possible. Loading and saving is stored here too, but that is no issue during emulation.

When accessing contended memory, the CPU is made to wait whilst the ULA fetches the data it needs (more detail here). If you must use it, then you would be best just storing data there rather than code, as less contended reads will be required, and thus less delay will occur.

If I understand your post correctly, you have the loading and saving code stored in contended memory, but it works correctly. If that's the case, your emulator probably doesn't emulate contended memory, and for the purposes of debugging, you'd be better off trying something like Fuse or Spectaculator.

Bear in mind that you cannot store the IM2 table here, as otherwise ULA snow will result (more information here).

I have good and bad news.

The bad news.. I made a calculation error.

The good news.. due to the error I assumed I ran out of codeable upper memory where I happen to have 2K remaining.
At this moment I work with an incomplete table, but in the end I might have enough room left for a full table.
At the moment I am speeding up the emulated ROM.