Home

EightyOne dev wiki

WIP V1.7

Outstanding Issues

• The following issue was reported in a discussion group and needs to be checked to determine if it is still applicable: "Sometimes when you load a ROM the keyboard changes even though I have chosen ZX81 (I consider this a bug)". It was reported here: http://compgroups.net/comp.sys.sinclair/8kb-roms-for-zx81/1228997#sthash.I5aTrNys.dpuf
• A Reset does not always turn off AY sound if it was playing. This does not always occur and so appears to be an intermittent issue.
• Timing of video frame updates does not occur accurately. The Animation Timer is used to determine when to update the display but this is not synchronised with when the ZX80/81 display generation. As well as inaccurate emulation, the T-state count shown on the Debug window does not display up to the expected the video frame count (expected to reach 64170 for the ZX81 but only gets up to 63725). The display should be updated and the frames counter reset when a VSync pulse is generated rather than when the Animation Timer fires. However, to accurately detect a VSync pulse requires finding a duration between an IN A,($FE) and OUT ($FF),A that is at least 3 scan lines wide. In theory this could be as low as 2.5 scan line duration but the lowest duration that Chroma supports is 3 scan lines and hence this is also the duration that is generated by “Against The Elements”. Flicker-free games for the ZX80 often produce a longer VSync duration, e.g. up to a duration of 20 scan lines, and compensate for this by reducing the number of visible scan lines by an equivalent amount. However, the worst case display routine so far identified (which many modern TVs do not like) is “QS Defenda” which generates a VSync pulse that spans 50 scan lines, but this is in addition to the normal number of visible scan lines!
• Lock ups can occur while debugging. This seems to happen after a lot of stepping through code, generally when the ‘Skip NMI’ and ‘Skip INT’ options are both ticked. The emulator gets into a state where it does not respond to the ‘Run’ button and can only be recovered by closing the Debug window, which causes the emulator to continue execution. It might be a side effect of the interaction to the ‘Continuous’ option.
• When the emulator starts it briefly shows the screen at 200% before setting it to the size it was last used at. This is visually unappealing. And if the emulator straddles the right side of the screen when at 200% then reverts to 100%, artefacts can be left on the screen.
• The implementation of SPECTRA and Chroma force the display mode settings to prevent adjustment of the brightness, contrast and colour controls. In theory adjustment to these should be allowed but I didn’t fully understand the display drawing mechanism and so went for the simple option of disabling these options.
• Closing while loading a program is in progress can sometimes cause an exception to be thrown.
• When double clicking a .O, .P or .P81 file and if EightyOne is configured as the default application to handle such files then EightyOne is launched and will automatically attempt to load the file. However, it would be good if EightyOne identified the intended machine type (for unambiguous file types) and automatically selected it before attempting to perform the load. Loading a program by a drag/drop operation or selection from the Tape or Wave Manager windows should not cause EightyOne to automatically switch machine type.
• When the machine type is a Spectrum and Interface 1 is enabled and RS232 output configured to a file, each time EightyOne starts up then the RS232 output file is written. Switching to a non-Spectrum machine type will not prevent the RS232 output file being written at start up. A check needs to be added so that the file is only written if a Spectrum machine type is active.
• If Hardware settings are changed, i.e. machine type, then another tab switched to and changes made then a reset to the new machine does not occur.
• Allow a program to ‘break’ (just as if it had hit a breakpoint) if ‘Protect ROM writes’ is unchecked and an attempt to write to the ROM occurs.
• ‘Stefano’ on the Sinclair ZX World forum posted “When displaying the disassembled code would be nice to see the source line also. This can be surrogated at least loading the lst file and displaying the string on the right of the address for each address. For complex routines this is really useful! An optional addition would be to highlight in some way when a jump is executed (and flow then go to another address) maybe drawing a little line between the previous and actual instruction”. I am not sure if he is referring to C source lines that he would like to see.
• ‘Stefano’ on Sinclair ZX World forum posted “Step over recursive routines. In this moment it works setting a break on the next instruction, but for a recursive routine this means it will stop not at the (top) level you wanted but at the first exit of the innermost call. As you can imagine if the recursive routine explore a big tree as in my case you cannot manage this manually.”
• Add support for the Chroma RS232 socket, i.e. similar functionality to that supported for the Interface 1 RS232 socket.
• Add support for the Spectrum 128’s RS232 socket, i.e. similar functionality to that supported for the Interface 1 RS232 socket.
• Add emulation of the Spectrum 128/+2 keypad. A window could display a graphic of the keypad and allow clicking on virtual buttons.
• The Wav Manager cannot correctly load high speed custom cassette formats, e.g. JRS Software’s “FastLoader System” and RL’s “Cassette Routine”. I suspected it could be that the accuracy of the timing of the recorded waveform is not good enough, but sampling at a higher rate did not appear to improve the ability to load such files.
• Saving to the Tape Manager from RL’s “Cassette Routine” results in an incorrect sized entry for the normal speed ZX81 saved program and an invalid entry for the high speed custom data block that follows it.
• Add a facility to check if selected hardware configuration options could exist in reality, i.e. do the real interfaces provide a through expansion bus. Not sure how practical this would be given the manner in which EightyOne handles facilities on a feature level rather than a peripheral level.
• Save the 'Continuous', ‘Skip NMI’ and ‘Skip INT’ settings in the Debug window to the EightyOne.ini configuration file so that they are restored when EightyOne is next started.
• Enhance the History capture mechanism to omit interrupt routines if ‘Skip NMI’ and ‘Skip INT’ options are ticked.
• Allow the user to set the buffer size for the History capture mechanism.
• The QL emulation appears to be incomplete and non-working. Cesar Hernandez (author of the ZEsarUX emulator) tried to re-use the QL implementation from EightyOne in ZEsarUX but gave up and switched to an alternate 68k emulator stack. He has reported this using this he achieved working basic QL functionality. Consider hiding the QL selection in the Hardware window until the emulation is working to avoid user confusion.
• Saving a list of ZX81 programs from the Tape Manager as .T81 format inserts the programs blocks back to back, with a trailing “Silence” block. Having a Silence block at the end seems pointless. Determine whether the Silence block can be safely omitted and prevent it being output if so.
• If emulation is paused via the Debug window and the border size is changed then the display becomes blank. Can this be redrawn easily?
• Enhance the disassembler to support the RST 28 floating point calculator.
• In "large" frame mode when emulating a Spectrum, a black area appears at the top of the screen. If this represents the vertical sync period then it should be 'above' the screen and so not visible.
• Reported by Moggy on Sinclair ZX World forum "When using the H4th/TreeForth ROM if the 'MEM .' command is invoked it reports remaining RAM as 31344 whereas it should be 14976" (http://www.sinclairzxworld.com/viewtopic.php?f=3&t=1781&start=50#p26290)