New version of Scramble for the beeb (going well)

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

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

Post by 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: 2441
Joined: Tue Jun 21, 2011 8:25 am
Contact:

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

Post by 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 14 times

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

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

Post by 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: 2441
Joined: Tue Jun 21, 2011 8:25 am
Contact:

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

Post by 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.

User avatar
BigEd
Posts: 1819
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

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

Post by BigEd » Fri May 25, 2018 11:03 am

tricky wrote:Visual 6502 have a 6845 in their queue but haven't started decapping it yet.
I did ping the list: it doesn't sound like there's any activity on the 6845.
Rich Talbot-Watkins wrote:Incidentally, this documentation has the following snippet about different CRTC types...
As a possibly useful addition to that, André has pointed out his page
http://www.6502.org/users/andre/hwinfo/crtc/index.html

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

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

Post by tricky » Sat May 26, 2018 7:05 pm

I'm "on holiday", but aparently that doesn't mean I get to do what I want ;)
Still, I sneaked off and tidied up what I was doing at Revival:
screenshot.png
(double size, but only 3K as a .PNG)
The image attached doesn't work on a real Master, or BeebEm as the timing is a little tight (beebem is way off afaik).
On jsbeeb and a real beeb, there is a nasty noise instead of the startup tune - I didn't tidy it up that much!
Keys: Z,X,/,* and RETURN to fire with the attached .ssd.
There is a little splash of colour by the high-score if you would be colliding with something and the explosions aren't 100%.
There is 2.75KB left, with the border a little squashed as in the screenshot, so it definitly looks "doable".
Attachments
Scramble.zip
(9.54 KiB) Downloaded 33 times

User avatar
Arcadian
Site Admin
Posts: 2932
Joined: Fri Nov 24, 2000 12:16 pm
Contact:

Re: New version of Scramble for the beeb (going well)

Post by Arcadian » Sat May 26, 2018 10:21 pm

Was proper gutted after tonight's football result but getting to see this astonishing Scramble build - that is now playable - has cheered me up a bit! :) Thanks Tricky! :)
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk

Image
ABug SOUTH (Hampshire) (1-3 June 2018)

User avatar
FourthStone
Posts: 514
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia
Contact:

Re: New version of Scramble for the beeb (going well)

Post by FourthStone » Sun May 27, 2018 12:22 am

Nice little easter egg at the base stage =D>

Looks amazing so far :D

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

Re: New version of Scramble for the beeb (going well)

Post by tricky » Sun May 27, 2018 4:49 am

Thanks both of you, and we'll done for "playing" to the end :)

reenigne
Posts: 7
Joined: Thu May 24, 2018 11:31 am
Contact:

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

Post by reenigne » Sun Jun 03, 2018 9:47 pm

Rich Talbot-Watkins wrote:
Mon May 14, 2018 7:51 pm
So far the observed behaviour seems to be: "Set R4 before the final scanline of the frame for its new value to be noticed".
That seems right to me, given the results of my own experiment with the Motorola 6845 ("type 2" in the CPC parlance) on my CGA card. I can't find the exact details of what I'm thinking of right now, but I noticed that certain register values take effect at points in the line/frame earlier than you might expect (at the end of the visible area, or at the start or end of the sync pulse). I think the reason for this is to avoid "too much happening at once" in what would otherwise be the obvious place for things to happen (row 0, scanline 0 within the row, or character 0) which could cause flip-flops to be set and reset in the same cycle and could lead to unpredictable behaviour.

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

Re: New version of Scramble for the beeb (going well)

Post by Rich Talbot-Watkins » Mon Jun 04, 2018 9:29 am

Yeah, that was my take on it as well (the "race conditions" I speculated about above).

I wouldn't be surprised if every register which holds "value minus 1" is matched to the internal counter early, and the results latched until the following time round. But it still doesn't quite explain some other behaviour Kieran was seeing in this thread.

Post Reply