New version of Scramble for the beeb Finished

[tricky]

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.

[tricky]

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

[Rich Talbot-Watkins]

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.

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".

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?).

[tricky]

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.

[BigEd]

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.

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

[tricky]

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:

(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".

[Arcadian]

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!

[FourthStone]

Nice little easter egg at the base stage

Looks amazing so far

[tricky]

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

[reenigne]

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.

[Rich Talbot-Watkins]

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.

[tricky]

I have been feeling a bit better yesterday and today, and managed to add bombs to scramble.
I still have to tidy up collision detection or something for bombs and shots, but it's getting there.
The video capture is a bit dodgy as I had to use b-em + VirtualDub on my stuttering PC!

Sorry, don't know how to make the window large enough!
URL:https://youtu.be/5loDzYADxsg View at 720p+ for 50hz.
If you hear the last note of the into tune, it means I just stopped colliding with something (currently includes explosions)!
EDIT: Just shrunk the window, video is full size.

[kieranhj]

Great work Tricky, it looks lovely & smooth! If only you'd been doing these conversions in the 80's you'd have much fame & fortune.

[tricky]

Thanks,
If someone had sehen me a PC, visual studio and a couple of emulators I probably would have
These are on my list of things to do if I ever acquire a time machine.
People might have POPed when they saw your stuff too

[Pablos544]

If someone had sehen me a PC, visual studio and a couple of emulators I probably would have
...

That's an interesting question actually. I'm sure in your case your a gifted talent guy who can garners ingenious solutions no matter what he got however this does cast a larger question in my mind. How come now that Xcode is free, so is Android Development Kit, and these computers exist that give so much power look at tools like Photoshop, Pro Motion, 3DS Max, the code practically knows how to write itself so all you have to do is hook a few things up yet the 80's was flush with Gems like Manic Miner, Killer Gorilla, Rocket Raid, Citadel, Strykers Run, Nemesis, Great Giana Sisters, Elite, Doomdark's Revenge were flush like gravy. All these people had was micros line based text editing and if you were lucky an assembler with all of maybe 12K to around 41K to play with in around total and if you were really lucky a disk drive. So how is it there's only a few quality games? You are truly good sir, I wish I could have met you when I was a teenager I was a very easily put off boy! Seeing you would have made my world go around.

[danielj]

It looks thoroughly beautiful you're a bit of a wizard (but I've said that before, I'm quite sure)!

[tricky]

Gil and I did jeltron with the basic assembler and we did have some funky stuff. Debugging stuff took ages and was mostly pawing over the code until we saw what was wrong.
We also didn't have RichTW to explain vertical rupture, although I did something similar which only worked on a few TVs as it had too many vsyncs.
Before I met Gil, I did know another beeb coder who had ADE/AID?, twin floppies and exmon (or similar). His millipede was the best I have seen on the beeb. But I haven't seen it published and don't have a copy.
Until I found retro software, I never met another beeb coder.

[Rich Talbot-Watkins]

It's amazing to think how we did it back then: armed with just BBC BASIC with its built-in assembler, its clunky line editing, and ingenious ways of working around the memory limits. Matt and I did the first version of Blurp and a few other things like that, although we'd written a ROM which gave us much better line editing in BASIC, which helped enormously. Funnily enough, I also had ADE, and tried using it for one project, but gave up because the source file got too big, and it wouldn't let me pack assembler instructions all on one line for clarity.

These days we can do so much more, with modern PCs able to provide better tools for creating content than ever before, and able to crunch the data in a way that wouldn't even have been possible on a Beeb. Plus the editing environment is so much better. The more I learn about Exile, and how the map was generated, the more amazed I am that this was achieved on a standard Beeb setup.

[tricky]

And we apparently had it good. Some dev's from bitd have said that they cross compiled from the Beeb (mostly spectrum from memory).

[Iapetus]

Amazing work tricky it looks awesome

[tricky]

When I run Scramble on beebem I get the left hand side image and when I run on b-em or jsbeeb I get the right hand side image.
A real 'B' give the correct image as do the two Masters that I have tried using MMC, but the two Masters that I have tried with data centres give the image on the left, but I'm not sure how far off the timing is.
If the VSync timing is off by more than 8 1mhz clocks then the display will be wrong (repeated lines).
I think beebem may be setting the VSync interrupt flag at the beginning of the two scan line vsync period instead of the end, which would account for the timing being two lines out (I think).
Is it possible that the DataCenter is affecting the timing, or have these machines got multi-OS setups that might affect something, or I don't know what else. Interrupts are disabled and I have claimed the NMI (I think), and I can't think of what else might be affecting the timing.
This may be another 6845 difference, I guess I need to investigate further.

I have also attached the latest demo in case anyone is interested in progress or helping debug the timing.
Keys are Z,X,?,@, SPACE bomb and RETURN fire.
Saucers are invisible invincible, as are you.

[GadgetUK164]

Awesome!!!! This is great news!!! =D (The fact you are working on ANOTHER game!!!)

[RobC]

A real 'B' give the correct image as do the two Masters that I have tried using MMC, but the two Masters that I have tried with data centres give the image on the left, but I'm not sure how far off the timing is.

Hi Tricky,

I've just briefly tried this on my Master 128 with DC and it looked fine. I've tried it with and without VideoNuLA and with and without the Pi co-pro and the image was fine in all cases. I loaded it from RAMFS with DTRAP off. I also have a MultiOS installed and ran it under 3.20.

Could it be the type of 6845 that's causing the issue? For reference, mine is a Hitachi HD6845SP.

I have some other Masters so could dig them out and test some more if you want...

[kieranhj]

A real 'B' give the correct image as do the two Masters that I have tried using MMC, but the two Masters that I have tried with data centres give the image on the left, but I'm not sure how far off the timing is.

Could it be the type of 6845 that's causing the issue? For reference, mine is a Hitachi HD6845SP.

I have some other Masters so could dig them out and test some more if you want...

On a related note, all the Masters I’ve seen have a Hitachi HD6845SP in them but Tom Seddon reported to me on Twitter that his Master won’t run the Twisted Brain demo properly and it has a VL68C45S CRTC. Definitely worth checking the part numbers.

[tricky]

Thanks guys, I suspect the various chips can be accommodated, I just need to work out what is going on with each!

I though in general that they kept with the same chip from the same manufacturer for the beeb as its bus was so overloaded (fan out) that it was the easiest way to not break it. I guess repairs over the years could introduce the odd variation, but the 6845 seem to have plenty of each.

I will try and put some tests together to try to find out what is different between the timing and behaviour in the various machines.

If anyone comes across a machine that works sometimes and not others or one that can have something enabled/disabled to fix/break Scramble, I would be eager to hear about it.

[tom_seddon]

Just tried it on my Master 128, with its VL68C45S, and it looks like the left-hand image, with the ship doubled up.

Another odd thing I noticed: when I press Ctrl+Break after running the Scramble demo, the DFS stops working. *DISC doesn't work, and its usual *HELP output doesn't appear (so no DFS and SRAM sections). All back to normal after power cycling.

--Tom

[tricky]

Thanks Tom, I think that I set ESCAPE to reset, if not, I will.
Did you notice if the palette changes at the top and bottom were in the same place as the left or right?

[tom_seddon]

It doesn't quite look exactly like either. Here's a (not very good) video from my phone's (terrible) camera that you might be able to make out: http://ffe3.com/beeb/VID_20180708_214550380.mp4

--Tom

[tricky]

Thanks Tom,
even stranger.
The timing looks to be about 2 scan lines too early as opposed to 2 lines too late on beebem.

[tricky]

No changes to timing, but I have added hitting the saucers and their explosions (this took ~200 bytes).
I think the main TODOs are:
- player lives and deaths
- shot, bomb and explosion sounds
- joystick support
- launching rockets
- killing the base
- fuel!
I have 303 bytes left and some stack space and I may be able to tweak the sprite data a bit, so it isn't looking good for any extras.
Please let me know if I have missed anything.

EDIT: fuel took 84 bytes, including the gauge, refuelling, forcing the player down and stopping the player from shooting, leaving 219 bytes.
EDIT: Adding sfx for shooting and bombing used another 21 bytes and they are silent during the music, leaving 197 bytes.
EDIT: Added killing the boss to start a new loop, I may have to shrink the UI by another char row (512 bytes), 125 bytes left.
EDIT: Did some work on new game/next ship/displaying GAME OVER and ships left, reworked the timer code and shrank the UI. 551 bytes left.
EDIT: Changes in timing code (may be removed) and filling in the stages bar. 475 bytes left