Snuggsy187
commented
2 months ago Hi Thomas, Many thanks for the heads up,
I used to handle FE05 writes differently until I was made aware of a problem running some of my stuff with ElkSD128. Having fixed the ElkSD128 issue, I may well have broke this on standard Electron hardware. I'll definitely fire up my vanilla Electron and see what it makes of these changes (which I should have done in the first place !)
I've only developed and tested Knight Lore on Elkulator so far.
Again, many thanks, Snuggsy
On Fri, Aug 2, 2024 at 2:17 AM Thomas Harte @.***> wrote:
I notice that leading up to the title screen the following values are written to FE05:
fe05: 08 fe05: 0c fe05: 0b fe05: 0c fe05: 0b
Which would leave ROM $b, i.e. BASIC paged. Following that the interrupt responses look like:
fe05: 18 fe05: 28 fe05: 18 fe05: 28 ...etc...
With 18 being a response to end-of-display and 28 being a response to the real-time-clock, i.e. middle-of-frame. At the same time you seem to be attempting to poll the keyboard for the space bar, but cf https://stardot.org.uk/forums/viewtopic.php?p=405686&sid=ae1a9a45e9ac88d91e6cc170c7b2d196#p405686 :
I was debugging under Mame and committed the grave sin of not checking against real hardware...
I wrote a little test program that sets the first four bytes of banks #0 and #1 https://github.com/Snuggsy187/Electron-KnightLore/issues/1 to AAAA and BBBB respectively. I left bank #1 https://github.com/Snuggsy187/Electron-KnightLore/issues/1 (BBBB) paged in, caught the first IRQ that occurred, and wrote &F0 to SHEILA &FE05 to clear all interrupts. I then read the first four bytes of whatever bank was now paged in.
Guess what I got back?
- Real Electron: BBBB (bank #1 https://github.com/Snuggsy187/Electron-KnightLore/issues/1)
The general conclusion being that if any of the top four bits written to FE05 are set then the bottom four are ignored.
So, the game's sequence (if I've captured it correctly) of:
fe05: 08 fe05: 0c fe05: 0b fe05: 0c fe05: 0b
fe05: 18 fe05: 28 fe05: 18 fe05: 28 ...etc...
Will at no point page the keyboard in, leaving you unable to proceed beyond the title screen.
Notably Elkulator emulates this incorrectly https://github.com/dmcoles/elkulator/blob/17b17e7d298975a2c10852b22b9e2d5afc3ca1e5/src/ula.c#L225 .
So, obvious questions:
- have I even captured the activity to FE05 correctly?
- has your code been verified on real hardware?
— Reply to this email directly, view it on GitHub https://github.com/Snuggsy187/Electron-KnightLore/issues/1, or unsubscribe https://github.com/notifications/unsubscribe-auth/API5CE4M42KMDBEBDF5VPNDZPLMZFAVCNFSM6AAAAABL3TNHZWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGQ2DGNZXGYYTONQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I notice that leading up to the title screen the following values are written to FE05:
Which would leave ROM $b, i.e. BASIC paged. Following that the interrupt responses look like:
With
18being a response to end-of-display and28being a response to the real-time-clock, i.e. middle-of-frame. At the same time you seem to be attempting to poll the keyboard for the space bar, but cf https://stardot.org.uk/forums/viewtopic.php?p=405686&sid=ae1a9a45e9ac88d91e6cc170c7b2d196#p405686 :The general conclusion being that if any of the top four bits written to FE05 are set then the bottom four are ignored.
So, the game's sequence (if I've captured it correctly) of:
Will at no point page the keyboard in, leaving you unable to proceed beyond the title screen.
Notably Elkulator emulates this incorrectly. As does ElkJS.
So, obvious questions: