New version of Scramble for the beeb Finished

[Arcadian]

Nice, just wrote it to floppy and tried it up here in Glasgow on the Beeb next to the 'Phoenix' beeb (which has proved really popular!)

[tricky]

Glad it works.
How is your event going?
Looks a bit quiet

[Arcadian]

Ah, I took that during a break, sell-out session this afternoon!

[tricky]

Is it just the picture, or is there a problem with scramble?

[Arcadian]

It's just the photo (screen appears rather over-exposed), it's looking and running fine

[VectorEyes]

Hello!

I just wanted to mention that I was looking at the internals of my two Masters today and one of them had a Hitachi HD6845SP, but the other had a Toshiba part! The markings on the chip were:

TOSHIBA
TC8505AP
JAPAN 9303EAI

It's a very late Master, one of the ones with a Cherry keyboard. If you'd like help testing Scramble on it I'm happy to give it a go, although I'm still waiting for my Gotek to arrive, and that Master doesn't (yet) have any other means of mounting discs, so it might be a few weeks before I can do any testing (sorry!)

[tricky]

Yes please, I would still like more data points for what is causing the incompatibilities.
The hot weather has stalled development, but i'm down to < 300 bytes, so is probably close!

I hope you have more luck with your GOTEK than I have had with mine over the weekend.
viewtopic.php?f=3&t=15411

[tricky]

I have a quick timing hack for Scramble to make it work with BeebEm.
The fix is to delay the setting of registers by five scan lines and four micro seconds!
This leaves the palette change at the top of the screen off by one scan line, but everything else seems fine.
I very much doubt that this will make it work on the couple of Masters where the timing is off, but I would like anyone with a master where the previous versions didn't work to give it a try please, just in case!

[billcarr2005]

Crashed!
(on BeebEM 4.14, but in BBC Model B mode)

[tricky]

Oh, I've just realised I am on 4.0.3, probably just a different offset though.

[tricky]

Sorry Bill, was that on the second loop?
If so, that is currently expected

Sorry, in another conversation I said that, but not in this one
I have just added starting the second loop and haven't reset everything properly yet.

This was just about timing so that the first loop doesn't have the seeing double/not seeing anything timing issue with beebEm.
PS I have tried all the versions of BeebEm that I have and all seem fine with this version until they crash on the second loop!

[tricky]

OK, I think I have found the off by N scan lines in BeebEm vs B-Em/HW/jsbeeb.
If my screen setup code sets vtot to a value less than it's currently at, it looks like it starts a new frame immediately instead of allowing the 6845 to wrap around and catch it next time...

This is sounding familiar!
I think someone has already reported this, but in the form of it does a >= check rather than an ==.

Anyway, I have a fix, which is to catch it on row 0 when setting vtot to 0 so that it doesn't abort early, but there is something else off!

[tricky]

I have tweaked the timing, such that BeebEm resets maintaining the line within a character and hence keeps the timing compatible.
The timing is pretty close to the edge on the Model B (occasional flickering at the top), but I can easily even things up when I have some more time to test.

Please try the attached .ssd on any hardware/emulators you have time for and let me know if anything is still off.

I don't know if the BeebEm change might also affect the couple of misbehaving Masters in a positive way

Have fun.

I haven't touched the code to do with running out of fuel or looping, so they will still cause crashes, think of it as a time limited demo

Sorry, wrong attachment!

ScrambleTiming-19.ssd is the version that I expect to work, the others have adjusted timing.
-15 and -24 are right on the edge for b-em and one is probably just off the edge for a Model B.
If -19 has any flickering or any other issues, please try the others and let me know which work/don't work.

[tricky]

One of my beebs gives occasional corruption on the score line with -19 (centre of the safe zone!) but is fine on -17 or -22 before giving frequent corruption on -15 and -22.
I don't understand the -19 flicker, but as the value should be fine from -16 to 21, I'm sure there will be a few values that work for everyone.

[tricky]

I had a quick look at the crash and it isn't the looping code, it's because I up'd the number of saucers and fireballs, but missed something.
So no crash now, but I think I am going to need extra digits on the score.

[tom_seddon]

Tried all 5 new Scramble versions on my VL68C45 M128, but no noticeable improvement over the video I posted the other week.

The different versions all looked the same to me, but it's possible there's some subtlety I've missed. I'll take a proper set of videos at some point this week and upload them to YouTube. With luck I'll be able to find my proper camera, so the quality might be better than last time...

--Tom

[tricky]

Thanks Tim, I think that confirms that it isn't a timing difference, but is something that that 6845 doesn't like.
Does that machine also show two scan lines of what looks like corruption at the bottom of my frogger game?
I would like to finish the game first, but now I have upgraded the timing code, I should be able to easily work around whatever the incompatibility is.

[hoglet]

For reference, here is a copy of the VL68C45 datasheet:

VL68C45.pdf

(1.04 MiB) Downloaded 127 times

At the end is a comparison table with the other 6845 makes.

[leenew]

I have tried the "Twisted Brain" demo and get glitches in 2 sections.
I have tried Scramble19 on my beeb and it works but I occasionally get rogue pixels on screen.

EDITED TO SHOW RESULTS OF OTHER VERSIONS...
I get the following results on my Beeb:
Scramble 15 is corrupted on my beeb at the top of the screen.
Scramble17 seems perfect on my beeb.
Scramble19 seems perfect on my beeb but I did encounter a rogue pixel on one play.
Scramble22 seems perfect on my beeb.
Scramble24 seems perfect on my beeb.

I get the following results on my VL68C45 Master:
Scramble 15 total black screen with corruption at the bottom
Scramble17 total black screen with corruption at the bottom
Scramble19 total black screen with corruption at the bottom
Scramble22 total black screen with corruption at the bottom
Scramble24 total black screen with corruption at the bottom

I will test the other versions soon and add to this post. - DONE!

Am I to surmise that the VL68C45 is less desirable than the beeb-identical H6845SP??

Lee.

[tricky]

...Am I to surmise that the VL68C45 is less desirable than the beeb-identical H6845SP??...

It does seem a departure from the rest of the beeb chips (ULA bugs aside) where they seemed to try to stick with a known working solution

I am happy to support it, and I suspect others here are too. It would just be much easier if we understood the difference(s).

[tricky]

The rogue pixels are probably from explosions that intersect the players ship on their first frame - it's on the secret to fix list

I have implemented the VSync timed code, but unfortunatly beebem is exactly one scan line out from b-em/a real beeb.
I don't know if this will work for the VL68C45 and I'm a little reluctant to just keep putting up versions hoping that one will.

Arcadian, do you have a beeb you could lend me at Cambridge that Scramble doesn't work on if I haven't sorted it by then?

If everyone isn't bored by now, here are some more versions using fractionally different timing offsets from VSync.
I'm only really interested to see if one (probably 89) will work for the VL68C45, but here is what I expect to work:

beeb: 85..92
b-em: 86..92
beebem:-150..-153 (haven't included 151/2)

So the sweet spot is probably 89, but as I say, beebem is one scan-line (64us) off.

PS I would still like to know the SCORE for the VL68C45 from the previous post.

[Arcadian]

Can't make Cambridge sorry Richard!

[tom_seddon]

I briefly tried all of the new versions... I think... hopefully I didn't miss one out. I let each one run until the score got to about 150.

83-86: basically good, but not perfect. Play area looks fine, but there's a character row of crap at the bottom of the screen, and the top row of the screen (SCORE/HIGH) flickers to a greater or lesser extent, seemingly dependent on how much stuff is on screen.

87-93: better. There's the character row of crap at the bottom, but nothing obvious apart from that. No score row flicker.

150, 153: pretty much the same as the video I posted the other week.

--Tom

P.S. even when it looks wrong, it still looks good! I've been trying this stuff out on my Master+CRT, and the 50Hz shines through no matter what ;)

[tricky]

Thanks Tom, I can force the display off after the fuel guage or you could stick some electricians tape over the bottom of your screen

This would leave beebem as the outlier, until I can try a few more options.

This also looks like the problem that I had with frogger, but that didn't seem to throw the timing off. I don't know if this is now 39 rows on that chip, so that will need further investigation.

[tricky]

I ran out of memory and have been packing code between the GFX that are spaced to maximise drawing efficiency.

To find the gaps and fill them, I used these patterns:

A MACRO to wrap ALIGN so that I could easily get a list of gaps to be filled.

Code: Select all

MACRO LOG_ALIGN al
  IF (al - (P% MOD al)) MOD al > 16 ;; numbers below 16 will not be listed
    PRINT "LOG: Skipping",al - (P% AND (al - 1)),"at",~P%
  ENDIF
  ALIGN al
ENDMACRO

A log after each "function" to display its size.

Code: Select all

.rand \\ returns rand in A C=? X=X Y=Y
{
	lda last_rand
	asl a
	asl a
	clc
	adc last_rand
	clc
	adc #&45
	sta last_rand
	EOR &FE44
	rts
}
PRINT "LOG: .rand",(P%-rand)

A log after each INCLUDE to display its size.

Code: Select all

.score_digits : INCLUDE "gfx\digits.equb"
PRINT "LOG: digits",(P%-score_digits)

The LOG: bit is because I capture the output of beebasm and use it for meta data.
I fail the build if I find any "ERROR:" in the output, but only after assembly, so that I can get context for the error.

This functionality to dump a "symbol table" and wasted memory report could easily be added to beebasm with a command line option.
The "function" and INCLUDE identification would rely on a scope starting at a label, which wouldn't be 100%, but a great start.

Continuing from my memory usage log:
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
EDIT: Added launching rockets and the associated graphics (I should have been able to share some of these). 3 bytes left.
EDIT: packed code and data between the sprites as above. 1014 bytes left.

[gtoal]

Sorry I didn't know about this remake earlier - just heard about it today. Probably of no help at this late stage but I would have offered some resources - myself and another Scratch coder have both implemented versions of RocketRaid and Scramble in Scratch, and the graphics are easy to extract from the implementations by pressing 'see inside'...

https://scratch.mit.edu/projects/156708703/
https://scratch.mit.edu/projects/21406819/

If nothing else, you can have some fun playing them

Great to see some remakes for the Beeb underway.

Graham

[tricky]

Thanks, I'll give them a try and it will be good to see if I have missed anything as my game is based on playing, not code.
I usually start one of my ports by playing MAME and seeing what graphics and sound I can reuse.
With Scramble, I have tweaked the graphics to be either more efficient or more animated.
...
I like your ports, RocketRaid is easier to control with the mouse, but the collision and bombing are a little off.
Scramble is excellent, but I think the shots can pass through objects.

The arcade version's land is built out of 8 pixel wide chunks, so you could display it as vertical blocks, 29 for the floor and another 29 when there is a ceiling, assuming you can clip them, if not, another large black one should do the trick
...
I guess you just have one large bitmap for the land and that it is the destructible objects that are causing so many sprites.


I've added the rest of the code for launching and managing rockets in the air. 844 bytes left.
You still can't shoot the launched rockets and I have introduced a crash on levels 2 and 3 that aren't supposed to have launching rockets!

[tricky]

Updated game-play video.

URL:https://youtu.be/GXcpbVAGm9w View at 720p+ for 50hz.
My PC stutters a bit, but beeb is silky smooth

[leenew]

This is looking superb!
Tricky, is there any room to get any noise on sound channel 0 when the meteors ase flying past?

Lee.

[tricky]

After fixing my crash bug (I had removed an RTS!) I have 842 bytes left.
Adding meteor sounds would be quite easy and channel 0 is free as long as you aren't exploding something

I just hadn't realised that there was sound there!
Did I miss any other sounds?

I've been thinking about difficulty and apart from the arcade difficulties that I know of:
- max 1 or 3 rockets flying at the same time.
- fuel draining slow or fast (4 or 6 for me).
I was thinking of adding:
- extra flying saucers: 4..6
- extra meteors: 4..6

I'm trying to think what would make a good difficulty ramp.
Which order should things be increased and how many should be increased per loop?

If the difficulty didn't change during the game, it could just be easy:1,4,4,4 medium:2,5,5,5 hard:3,6,6,6 but I want it to increase per loop.
I know this is bad game design, but with limited memory, it has to be something fairly small to implement.