Home

EightyOne dev wiki

WIP V1.3

• The vertical scrollbar shown in the History window is too far over and so only partial visible.
• Memory edits not allowed while the debugger is in free running mode.
• The Memory window now refreshes after an edit is made.
• Bug fix to the ZXpand “read only file” problem where the ROM shadow is disabled after loading.
• Changed how ZXpand ROM overlay works, which fixing a few problems with demos.
• ZXpand banner text changed to "ZXPAND EO x.y" to avoid the user mistaking it for the hardware version.
• T81 format enhanced to tolerate new block types, specifically the block introduced by 81-libretro emulator.
• Inclusion of edition 1 ZX81 ROM. The default ZX81 ROM is still the edition 2.
• Bug fix to the Flash Load mechanism that prevented some programs from loading, e.g. Software Farm's Bouncing Bert.
• The Interface1 RS232 baud rate is now calculated based on machine clock rate rather than hard-coded to 3.5MHz.
• Disassembler now correctly handles instructions above $8000 on a ZX80/81 where bit 6 is set.
• The History window is now refreshed when it gets resized by the user.
• Improved the performance of the History capture feature under the Debug window.
• The Memory window now displays offsets numbers as column headings.
• The Memory window now displayed the address in the status bar when hovering the mouse cursor over the Sinclair characters when in 'Traditional' view mode.
• Bug fix to locked the “Previous/Next Change” buttons within the status bar of the Memory window when resizing the window using the grip control.
• Bug fix to the display of the address in Memory Window when in 'Word' view mode.
• Bug fix to the tape block to a wav file conversion routine that could prevent a valid conversion occurring.
• Bug fix to the number of T-states assumed per frame for the ZX81 and ZX80.
• The Memory and Symbol buttons in the Debug window now toggle the visibility of their respective windows.
• Scrolling mechanism of the Memory window enhanced to provide more logical behaviour.
• Default position of all windows set to be within screen area of 500 x 500 pixels such that all will initially appear within the monitor bounds.
• The Tape Manager inserts a description block with text “Created with EightyOneTZX”. This has been changed to “Created using the EightyOne emulator”.
• File default extension was sometimes .P instead of .O when saving in ZX80 mode.
• Bug fix to grey out the I/O area and Display Generation T-States count within the Debug window while free running.
• Added a feature to the Debug window to allow the user to specify the number of T-states that are expected to have elapsed between consecutive hits of a specified address, useful for verifying timing of flicker-free ZX80 programs.
• Included support for the ZX81 edition 1 ROM floating point hardware fix.
• Splash screen can be disabled with INI option ShowSplash=0
• Warn users when file/memory/snap load/save fails.
• Added 'Gather Windows' option to View menu, centres all open non-modal dialogs.

Outstanding issues

• SuperMicro-FIDE-ZX81 hang-up (after selecting a move, the screen goes black. The program appears to get stuck in a loop.). The issue does not occur on No$zx81. Perhaps caused by a screen update issue or undocumented opcodes not being emulated (which are in use). Beginning to think this is ok but not sure.
• A Reset does not turn off AY sound if it was playing.
  • CR - possibly already fixed as unable to reproduce. Is there a test case?
• T-state count is sometimes incorrect, especially trying to time a video frame (expect 64170, get 63725). The frames counter is reset by the Animation Timer but should be reset upon an OUT ($FF),A.
• I increased the debug history window to 2000 entries. But on my old PC this makes the emulator run very slowly. Even at the original 1000 entries it was slow. Attempt to rewrite the code to improve performance.
• Lock ups can occur while debugging. This seems to happen after a lot of stepping through code, maybe if the Skip INT/NMI boxes are ticked. The emulator gets into a state where it does not respond to the Run button and only by closing the debugger window will the emulator carry on.
• When the emulator starts it shows the screen at 200% and then reverts back to 100% (assuming this was the last saved setting). If the emulator straddles the right side of the screen then it can leave artefacts on the screen.
• The implementation of SPECTRA and Chroma force the display mode such that brightness, contrast and colour cannot be adjusted. In theory this should be allowed but I didn’t fully understand the display drawing mechanism and so went for the simple option of ignoring these options.
• Closing while loading sometimes causes an exception.
• Prevent generation of IF1 output file when configured as non-Spectrum computer.
• If 'Protect ROM from writes' is unchecked, auto-loading of a ZX80 program will crash the ZX80.
• 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.

Feature requests

• Set default placement positions of all dialog windows.
• Auto change to ZX80/81 when auto loading .O/.P files
• When running ZX80, force save to default from .O to .P and vice versa
• 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 bettween the previous and actual instruction.
• 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...
• Debugger window should have 'continuous' mode saved in prefs
• System vars display?

Rejected Items

• [REJECTED] “SuperMicro-FIDE-ZX81” hangs. I found that the program appears to hang after selecting a move (the screen goes black). The program appears to get stuck in a loop, but this issue does not occur with the No$zx81 emulator. It is perhaps caused by a screen update issue or undocumented opcodes not being emulated (which are definitely in use in the program). Eirk Olofsen has done some investigation into this issue and reported “it seems that the strong-and-slow versions are indeed slow! It could be coincidence, but I get valid moves after waiting for a few minutes with smfide1k-zxwhite.p, JSZeddy, sz81 and EightyOne! I suggested sz81 is because it uses the same Z80 emulation as EightyOne. I just tried No$zx81 with the slow version, and it indeed produced a valid move very quickly. When I change the flags of LD A,I in sz81, it still takes the same time to return with the next move. Thinking about what to do next, if I were to do something next, I just checked the emulator options of No$zx81. And I found this one: ‘Delays in FAST mode’ and unchecked it. Now there is a proper delay before returning with a valid move”. GAME SIMPLY TAKES A LONG TIME TO MAKE A MOVE.
• [REJECTED] Norbert Raimund Leisner reported for the program “SuperMicro-FIDE-ZX81”: “After installing and extracting the files of 81 Sinclair emulator (latest edition v1.2) on my Windows 7 SP1 32 bit software, appears indeed a chessboard with the two options (it does not matter if my choice is the slow or fast chess version): smfide1k-zxblack.p is selected * on square e2 a flash is visible including a pawn P on field e4, but I cannot move any pawn or knight. smfide1k-zxwhite.p is selected * on square b5 a flash is visible, but I cannot move any pawn or knight.”. CAN NOT REPRODUCE.

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
• ‘jonesypeter’ on the Sinclair ZX World forum reported that he could not save to the desktop when running on Windows 8. I try to repeat this on Windows 8 and it worked ok for me. It appears to be some kind of permission issue as he could successfully save to other folders. The emulator should not hang if it cannot save but instead should present a warning to the user.
• Add a menu option to force all window dialogs to return to their default locations, or better still make each window check whether it is within the monitor bounds when it gets displayed and to reposition itself so that it becomes visible if required. For example, if using a docked laptop connected to large monitors and window dialogs are placed at extremes, then undocking and reverting to the laptop's built in screen can result in the dialogs be located off-screen. There is then no way to access them to reposition them so that they are visible (apart from editing or deleting the EightyOne.ini configuration file).
• Add a user interface option to allow disabling of the splash screen (the code already supports it so the UI just needs enhancing to expose the feature, perhaps via an Options dialog).
• 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!
• Erik Olofsen (author of the sz81 emulator) reported “if you enable "Beeper Sound" (F4), there is a glitch about every 3 seconds. This glitch is also related to the number of cycles per frame. I believed I would be able to get this right [in sz81] by changing the "207 counter" mechanism and tried to get programs running correctly which show that there is something wrong. For example, do you know the "25thanni" demo? If you run it with a Border Size "Full Frame", you see that the letters of the scrolling text in the bottom fall down at the left edge. When I showed this to Bodo Wenzel, the author, he confirmed it must be a bug in EightyOne. So because the "207 counter" is not implemented correctly, the rowcounter that selects the pixels to be output is not always incremented at the correct time. However, after all my changes to sz81, someone posted a program on the forum that doesn't run correctly on it (I forgot which one exactly). I tried to follow all observations by Grant Searle, so I wonder if the different ULA versions of the ZX81 perhaps behave differently. But there is at least some point where I stopped: the wait circuit. I believe it is necessary to take into account what kind of instruction is being executed when the hardware /WAIT pin is used, to get the number of clock cycles exactly right. Right now, it is right on average in sz81. The sound code gets into trouble if the number of cycles per frame is not constant. So the number of cycles needs to be the time defining measure, even though it is not exactly known due to the wait circuit. A frame cannot be the time defining measure, because the number of cycles is not constant. I believe I moved the "borrow" trick in the EightyOne code to another point, but I would need to check that. However, this is all related to the ZX81... In the EightyOne source, there is a line machine.tperframe=312207 which is certainly wrong. In my source I see I set it to 207310-3 for the ZX80. This confirmed the number on your website [www.fruitcake.plus.com] about flicker free programs. I also seem to remember that when the above variable is adjusted for the ZX80, the pixel generation routine behaved a lot better.” THIS ISSUE IS A CONSEQUENCE OF THE TIMING OF VIDEO FRAME UPDATES. THE NUMBER OF T-STATES ASSUMED FOR THE ZX80/81 HAS NOW BEEN ADDRESSED IN EIGHTYONE.
• 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 'Protect ROM writes' is unchecked, auto-loading of a ZX80 program will crash the ZX80. Is this a bug or does the ZX80 ROM really attempt to overwrite itself?
• 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 a Search facility to the Memory window to allow finding of byte sequences.
• Hovering over a Sinclair character when in ‘Traditional’ view mode in the Memory window could highlight the corresponding byte value, e.g. by drawing a border around it or by changing its colour, etc.
• 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.
• When emulating a ZX80 and a border of zero size has been selected, the right hand column of the display straddles off the screen. The ZX80 display is not aligned horizontally to that of the ZX81, which might be technically correct (must be confirmed). The emulator should take the horizontal shift of the ZX80 into account so that the display is correctly shown.
• Saving a list of ZX81 programs from the Tape Manager as .T81 format inserts the programs blocks back to back, with a trailing “” 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?
• Selecting a new ROM in the Hardware dialog via the “…” button will cause a reset of the emulator computer after the Hardware dialog is closed. But simply overtyping the ROM file name in the Hardware dialog to another valid file name, e.g. “zx81edition2.rom” to “zx81edition1.rom”, and closing the Hardware dialog will not cause the emulated computer to reset.