[Updated] RetroVM 1.0.4 with Recreated ZX Spectrum support.

edited November 2015 in Emulators
A new version available the change log:

- Recreated ZX Spectrum "game mode" keyboard support.
- Fix a bug with multiples machines running in parallel.
- Code clean. Executable size decreased.

You can download as usual from the webpage: retrovirtualmachine.org

Enjoy!!!
Post edited by rich_chandler on
---
retrovirtualmachine.org - Emulator for OS X.
Thanked by 1TomD

Comments

  • I can't edit the tittle but...

    v1.0.4 released

    The caps key not working in v1.0.3 fixed... Sorry
    ---
    retrovirtualmachine.org - Emulator for OS X.
  • jcgamestoy wrote: »
    A new version available the change log:

    - Recreated ZX Spectrum "game mode" keyboard support.
    - Fix a bug with multiples machines running in parallel.
    - Code clean. Executable size decreased.

    You can download as usual from the webpage: retrovirtualmachine.org

    Enjoy!!!

    Interested to know what Recreated ZX Spectrum "game mode" keyboard support is?

    TomD
  • The recreated ZX Spectrum keyboard has two modes of operation.

    In the first it simulates a pc keyboard.

    In the second each key works independently... is documented here:

    sinclair.recreatedzxspectrum.com/downloads/ZX%20Keyboard%20Technical%20Document%202015_05_13.pdf

    Anyway the documentation uses a "character" aproach if you don't want to have problem with the regional layouts, is better to use a "scancode" aproach as I do.
    ---
    retrovirtualmachine.org - Emulator for OS X.
  • Ok thanks

    While on the subject of keyboards, although I'm not totally sure this is worth investigating, while bug fixing my new game I found an interesting outcome of a key read routine that most emulators show, including this one, but isn't replicated on real hardware. Basically a bug in my game caused the key reads not to be interpreted into ascii correctly during the redefine key routine. The routine uses a key scan which figures out which key was pressed and then looks up the ascii char in the ROM table. It needed an interrupt to occur to work as the ascii conversion was part of my interrupt code and unfortunately was missing a halt statement to make sure the interrupt was called. I didn't pick this up, however, as I was play testing using this emulator (and FUSE) and the code seemed to work fine and the key read correctly. Running on real hardware and ZX Spin (via wine) the bug showed with the ascii char missing. If you are interested I can send you a tap file which has the bug. You can also read about it in the forum here worldofspectrum.org/forums/discussion/51508/new-game-the-order-of-mazes/p1

    TomD
  • TomD wrote: »
    Ok thanks

    While on the subject of keyboards, although I'm not totally sure this is worth investigating, while bug fixing my new game I found an interesting outcome of a key read routine that most emulators show, including this one, but isn't replicated on real hardware. Basically a bug in my game caused the key reads not to be interpreted into ascii correctly during the redefine key routine. The routine uses a key scan which figures out which key was pressed and then looks up the ascii char in the ROM table. It needed an interrupt to occur to work as the ascii conversion was part of my interrupt code and unfortunately was missing a halt statement to make sure the interrupt was called. I didn't pick this up, however, as I was play testing using this emulator (and FUSE) and the code seemed to work fine and the key read correctly. Running on real hardware and ZX Spin (via wine) the bug showed with the ascii char missing. If you are interested I can send you a tap file which has the bug. You can also read about it in the forum here worldofspectrum.org/forums/discussion/51508/new-game-the-order-of-mazes/p1

    TomD

    Very interesting but i don't understand it well.

    Can you sent to me the asm code of the keyboard scan rutine. I'm sure that the interrupt is ok in my emu, Maybe is a problem related to when the keys are sended to the emulation layer.

    Please send me the tap and the code (if you can) and i will investigate it.
    ---
    retrovirtualmachine.org - Emulator for OS X.
  • I've uploaded the bug version here as a snapshot tomdalby.com/theorder/keyboard_bug.szx. I can't seem to figure out how to load these into your emulator so have also uploaded a tape file tomdalby.com/theorder/keyboard_bug.tap. To get to the bug you need to pick 1 for Keyboard and then Y for redefine. Once at the redefine part on a real spectrum any key you press will give the same result SS (which is basically saying you've pressed a non-ascii key [<32] like symbol shift). In this Emulator and some of the others (Fuse) it picks up the correct ascii code when it seems it shouldn't. The Emulators I've seen which work as per the real hardware are ZX Spin and SpecEmu.

    The redefine routine scans the keyboard to figure out if a key was pressed:
    ;;
    ;; scan keyboard
    		ld bc,$7ffe		; 10t - start searching keyboard for press, b=half row
    _rjky020:	in a,(c) 		; 12t - b=$7f,c=$fe
    		and %00011111 		; 7t - only interested in last 5 bits
    		cp %00011111 		; 7t - if all 5 bits are 1 then nothing pressed
    		jr nz,_rjky030 		; 12/7t - if no key pressed try next part of the keyboard
    		rrc b 			; 8t - rotate through b to scan all keyboard (01111111 -> 10111111)
    		jr _rjky020		; 12t - just keep going till a key is pressed
    

    Once you press a key it moves to a routine which displays the ascii equivalent to screen. This is the part that needs the interrupt to run to get the correct ascii code as it is the interrupt routine that converts key press to ascii and loads it to a mem location (as per the ROM routine). Adding a halt just before this part of the code fixes the bug in the game but the interesting part is why does it work in the Emulator before adding a halt, maybe they key press is buffered somehow?

    TomD
  • Well analizing it i see were the bug is but is very difficult to fix.

    I will try to explain what is happening with me bad english (sorry).

    In a real spectrum the key press may happen in any moment (in any t state of the frame) you rutine exit when a key es pressed and I presume you look to the variable where the rom store the char. as the interruption has not been fired yet there is no char stored.

    In my emu (and in others) The keyboard state is not changed at all between a frame. In other words from the start to the end of a frame the value of the port 0xfe for the keyboard is the same. Then, you rutine is in sync with the last key captured by the int runtine, and is not needed to wait to the next int.

    It is very difficult to fix it because in an emulated system. We would need to capture the keystrokes in real time, and in a modern processor one frame is emulated very quickly, and if we look the keyboard state only when the frame is processed we can miss some keystrokes.

    I hope you have understood me more or less
    ---
    retrovirtualmachine.org - Emulator for OS X.
    Thanked by 1Hikaru
  • RVM don't support the SZX format (yet) but you can import or export snapshots in Z80 or SNA format from the snapshot manager.
    ---
    retrovirtualmachine.org - Emulator for OS X.
  • jcgamestoy wrote: »
    Well analizing it i see were the bug is but is very difficult to fix.

    I will try to explain what is happening with me bad english (sorry).

    In a real spectrum the key press may happen in any moment (in any t state of the frame) you rutine exit when a key es pressed and I presume you look to the variable where the rom store the char. as the interruption has not been fired yet there is no char stored.

    In my emu (and in others) The keyboard state is not changed at all between a frame. In other words from the start to the end of a frame the value of the port 0xfe for the keyboard is the same. Then, you rutine is in sync with the last key captured by the int runtine, and is not needed to wait to the next int.

    It is very difficult to fix it because in an emulated system. We would need to capture the keystrokes in real time, and in a modern processor one frame is emulated very quickly, and if we look the keyboard state only when the frame is processed we can miss some keystrokes.

    I hope you have understood me more or less

    Definitely makes sense and an interesting insight into how these emulators are coded.

    Thanks

    TomD
  • FWIW, SpecEmu reads the PC keyboard state at the beginning of each frame but the emulated machine won't see any change until the midpoint of the frame. So if the keyscan routine runs in the second half of a frame then the same key states will be seen during the next interrupt.
  • JSpeccy updates the Spectrum keyboard map in real time, asynchronously with every key press/release. The only one limitation is that a USB keyboard is polled between 10 and 16 milliseconds (the USB keyboard driver dictates the read frequency).

    But on a real Spectrum +2B, SS is printed on screen....
    Thanked by 1Einar Saukas
  • Woody wrote: »
    FWIW, SpecEmu reads the PC keyboard state at the beginning of each frame but the emulated machine won't see any change until the midpoint of the frame. So if the keyscan routine runs in the second half of a frame then the same key states will be seen during the next interrupt.

    I like a lot your approach, may be i will fix it next week.

    Thanks.
    ---
    retrovirtualmachine.org - Emulator for OS X.
Sign In or Register to comment.