Lyra 3 Accepts 1 key entry then stops working

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.

    I'm having a strange issue where the Lyra 3 is refusing to accept more than 1 key within a game.

    The game might be to blame, but a real amiga keyboard works fine so I figured this was worth bringing up.


    The game in question is 'The Lost Vikings'

    To play the game, I am required to press the DELETE and HELP keys, as well as S E and whatever else....


    I find that after I press 1 single key, the Lyra 3 will no longer accept any more keys.


    When it's in this state about all I can seem to do is Ctrl - Amiga - Amiga and the amiga will reboot after about 20 seconds instead of it's usual quick reboot.


    I am running into this with the Lyra 3 both on the Amiga 3000 as well as the Amiga 2000.

    The game is being run as booted from floppy disk.

    Quote from lowlevel

    When it's in this state about all I can seem to do is Ctrl - Amiga - Amiga and the amiga will reboot after about 20 seconds instead of it's usual quick reboot.

    This indicates that the keyboard didn't get a proper ACK from the computer. Lyra3 implements the full "reset warning" sequence that Commodore has specified, and that means it sends the "reset warning" key code and waits for up to 10 seconds before it actually gives the reset.


    My best guess is that the ACK pulse that the game is sending is too short, but I'd have to measure that. The fact that it works with one type of keybaord doesn't mean that other Amiga keyboard types are also working: There are at least three, and the difference is exactly on the ACK pulse.


    Got to see if that game is in the loads of disks that piled up here over the years (yes, I do keep disks that come with used-purchases).


    Jens

    I'll have to check how short the pulse really is. The way that Lyra3 works is that it samples all sides (both Amiga- and PC keyboard side) at a fixed frequency, and if the pulse is shorter than this sample frequency, there is no way that this can be fixed on the Lyra side.


    Jens

    I've found that the game is actually available for free, not an illegal download. Now I just have to go through the process of writing it to a floppy disk...


    Jens

    Reproduced it on an A2000/68030/25MHz (A2630).


    This is actually a spec violation in the game itself. The keyboard spec (see hardware reference manual) demands that the ACK pulse is at least 85 microseconds long, but it actually is shorter than 6 microseconds. What I see is that Keyrah goes into out-of-sync condition, and starts sending single bits after the timeout. However, it gets an ACK pulse right after the first bit of the re-sync procedure, which is plain wrong: It should wait for 8 pulses, as it has sent an ACK pulse already.


    Lyra3 doesn't care, as it assumes the computer has missed a bit somewhere, so from it's point of view, the sync is re-established and it then transmits the "lost sync" code. However, that gets garbled by yet another 6-microsecond ACK pulse that doesn't belong there (0xF9 is turned into the unused code 0xFF), which in turn leads to another out-of-sync condition, as this is never properly ACK'd. The fact that the MCU didn't crash is supported by the possibility that you can still issue a reset with CTRL-A-A (or the equivalenton your PC keyboard), so all code is still running. It's just that the protocol is violated on the Amiga side.


    This is broken on at least two levels in this particular game.


    It may be resolved with an edge detection outside the sample windows (which is then caught by the sampling routine), but I didn't use that for a reason: It's not as noise-tolerant as the sampling approach. Also, the code was developed on a 40-pin variant of this MCU, and I need to check if the edge detection feature is actually available on the pin that I've used on the 8-pin MCU of the final product. Then there's the problem of code space: Out of the 4k available code space, there's 61 bytes free. Not sure if that's enough to generate an alternative code path for ACK detection.


    I need some time to dive into the old source code (last change December 17th, 2014). I've put this on the Todo-list. I can't promise when I get to this.


    Jens