New version of Scramble for the beeb (just starting)

new games to be launched and discussed here
User avatar
tricky
Posts: 2372
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: New version of Scramble for the beeb (just starting)

Postby tricky » Mon May 14, 2018 2:52 pm

Visual 6502 have a 6845 in their queue but haven't started decapping it yet.
I don't think Frogger set it near the beginning of the line, but scramble may be seeing it around the end of the horizontal display.

User avatar
tricky
Posts: 2372
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: New version of Scramble for the beeb (just starting)

Postby tricky » Mon May 14, 2018 7:17 pm

Moving R4=0 to the previous scan line (6) fixes the issue, but as far as I can tell, anywhere on the last line (7) causes the problem.
What makes this hard to understand, is that even only doing it on the first row (not every interrupt) doesn't work, but does set the rows per frame to 0.
So, it seems setting R4 before the end of the first row somehow breaks the comparison with 11 much later, but not the 1 row per frame rows.
I have added another interrupt at the end of scan line 3 to set R4=0, which pays for itself because the other interrupts can be shorter.
I have also found a timing issue with beebem. It did match to within 2 1MHz cycles, but after adding the extra interrupt, it is now off by 256 1MHz cycles (and isn't fixed by making it not a multiple of 256). b-em is 1Mhz cycle different to my ModelB. jsbeeb works fine.
So, it works, but now not with beebem!
I have attached the version with the extra interrupt, just in case anyone wants to try it on real hardware.

Off to check a theory about beebem vsync interrupts... ...theory disproved :(
Attachments
Scramble.zip
(7.88 KiB) Downloaded 7 times

User avatar
Rich Talbot-Watkins
Posts: 1229
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: New version of Scramble for the beeb (just starting)

Postby Rich Talbot-Watkins » Mon May 14, 2018 7:51 pm

BeebEm doesn't model any of this really accurately though (unless it's changed massively since I last used it). I don't even think it has a cycle-exact model for emulating CPU and video concurrently.

tricky wrote:Moving R4=0 to the previous scan line (6) fixes the issue, but as far as I can tell, anywhere on the last line (7) causes the problem.

So, setting R4=0 on scanline 6 works. But setting it anywhere on scanline 7 doesn't work. So this lends some credence to the idea that the CRTC is maybe already latching the results for 'end of frame' at the start of the final scanline, perhaps. So far the observed behaviour seems to be: "Set R4 before the final scanline of the frame for its new value to be noticed".

tricky wrote:What makes this hard to understand, is that even only doing it on the first row (not every interrupt) doesn't work, but does set the rows per frame to 0.

In what way doesn't it work? You mean it still rolls? You should presumably only be needing to set R4 twice: once at some point in the first visible row, and then again in the last visible row. Again, if we go by the same rule, you'd need to set R4=11 before scanline 7 of the last visible row, otherwise it'd already decide to end the frame there, as if R4 were still 0. Maybe that's the problem you're seeing. It'd effectively add an entire extra row, leaving a PAL frame of 40 rows.

Now, the next thing is, is there some similar weird behaviour to do with when R12/R13 are set, which would explain both Kieran's issue in his WIP demo, and the Frogger issue that we were seeing on someone's Master (was it jbnbeeb?).

User avatar
tricky
Posts: 2372
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: New version of Scramble for the beeb (just starting)

Postby tricky » Mon May 14, 2018 9:37 pm

Scan line 6 works, 7 doesn't as it messes up the vsync by seemingly adding a whole 127 row frame (until the counter wraps).
It looked like when it didn't work, that it still had 1 line frames, but it could be that the 127 rows vere just blank and the correct images was only showing some of the time.
Jbnbeeb's master was one of the few with the corrupt last line, we'll have to see if it happens with scramble.