New version of Scramble for the beeb Finished

[guddler]

Just a heads up that neither RC3 or RC4 are remotely working for me under BeebEm Mac. Now, it's possible that it's something I've done to BeebEm since I've been working on it but I don't think so as I just downloaded the last version before I went anywhere near it and it still doesn't work. I probably need to capture a video of what it does as it's not desperately easy to explain! Needless to say it's all over the place.

Now the only reason I tried it in BeebEm is that it does nothing for me on my Master. After the key selection screen I just get a black screen. Again, not sure if I'm doing something wrong here. I'll see if I can work out which was the last version that worked for me as I haven't tried them all lately.

[guddler]

Something fishy going on here at my end because the version that I posted as working doesn't work for me any longer. I'll try and have a look later - need to get outside for now but I suspect it might be MOS related as I've changed the dual MOS that I'm using since last time

[paulv]

It seems to be working fine on my Visual Studio build of B-em although my arcade gaming skills are and have been so poor that I don't even get past the entry to the first "cave" section.

Paul

[tricky]

I confess, I only tried it on the compact and B.
If beebem timing is correct on Mac, the non-beebem should be OK, but if it is off in a different way, it won't work, this usually shows as a black screen or pairs of repeated rows.

[guddler]

I got it to work (on real hardware - Master 128, not BeebEm).

I was previously transferring the SSD over UPURS to a floppy. This was very, very quick implying the disk image was very short. When I gave up on this and put the SSD onto USB and imported the SSD from USB to RamFS drive 0 it worked. Is there anything clever / unusual about the SSD?

[tricky]

It is just what comes out of beebasm. I can't remember if it is padded or just as big as is needed. The file Scrambl can be loaded into sideways ram and used as a ROM (with default keys). If it is in slot 0 (back slot on a master) it will auto boot turning your beeb into a dedicated scramble machine

[MartinB]

I've been discussing this with Martin (guddler) in the UPURS thread and I'm happy that the ssd image is fine and that it is transferring to floppy correctly. On my Model B though, I'm also seeing random occasions when I just get a blank screen after pressing Return on the initial loading screen.

[tricky]

... On my Model B though, I'm also seeing random occasions when I just get a blank screen after pressing Return on the initial loading screen.

I did have that issue on a previous version after I swapped to a VLSI compatible way to set up, but I can't see how that could still happen.
Do you get any flickering at the top of the screen, which would show my timing is off?

[BigEd]

(This is the part of the Wires? thread - sort of sounds like uninitialised values, or accidentally shared workspace, kind of thing to me.)

[MartinB]

Do you get any flickering at the top of the screen, which would show my timing is off?

No, no artefacts whatsoever - it's impressively rock-steady once running and plays absolutely fine. Do note that I'm only seeing the 'crash' very very rarely so this is something super-subtle - if it was me, I wouldn't even worry about it. Maybe see if other Martin could try and reproduce it again it to be sure that I'm not a spurious red-herring.

....sort of sounds like uninitialised values, or accidentally shared workspace, kind of thing to me.

Yes, good point Ed - I'll have a play with that thought later, maybe tricky is using a location or two that UPURS also uses and he doesn't initialise them.


.

[tricky]

Hey, what are you saying about my coding!

From the "Wires? Pah....." - UPURS thread:

There was an issue on earlier versions of Scramble, where it could end up never hitting a vsync, or at least no where near what is needed to be reliable.
Once synced, everything is fine and it never got out of sync again.
For RC3, I changed the way that Scramble starts up, waiting for the correct point in the frame to guarantee a safe transition into Scramble MODE.
I have only tried a few dozen times, but can't reproduce the black screen on B, Master or Compact (B+ is poorly).
The beebem version I think can produce a blank screen (on HW), but it if ever didn't it would look very wrong, so I doubt that is the answer.
There may be something that I have missed or broken, but it is very hard to tell on HW without an instruction log that contains the H and V sync pulses!
The code sets a mode equivalent to MODE 1 that will sync very quickly, then decompresses Scramble to 19K which should be long enough for the HW to have synced. After decompressing, it changes to MODE Scramble and starts the game.

If you find a machine that fails often and have time to test, please change to MODE 1, run the code from line 350 of LOADER to set the keys (you can customise them if you like) and then *SCRAMBL. If this always works, it suggests that the new mode hasn't synchronised by then and that I need to wait longer or find a way to make it sync more quickly.

I'll re-post this in the Scramble thread as it doesn't look at all related to UPURS.

The problem with being tricky with the video chip, repeatedly changing where vsync happens or how long the frame is is that you can end up never being on the correct line for a vsync. Hoglet spotted an instance of this which caused the vsyncs to be 6 or 7 frames apart. The problem is that if you are on line 5 and vsync is on line 7, but before it gets there you change to 2 line modes, the "current line" will keep counting until it wraps (usually 127 or 255 depending on the 6845 register). If this wrapping happens when you think you are part way through the next screen, you will again miss the vsync and repeat.

If the registers could be read, it would be easy to get it right, but I don't think any of the versions in beebs have the appropriate registers readable, hence changing to a MODE that will sync, waiting a while, then waiting for vsync, then waiting a specific time to get to ROW 0 and continuing from there!

[tricky]

I've just noticed that I did remove the RTI from &D00, so an MNI would hit a BRK!

What I do is:
In LOADER, set the keys in &80..&85 then *Scrambl
or in ROM set the keys in &80..&85 then JMP to Scrambl

In Scrambl:
Set top of stack to a lower value to allow a bit more room for game code (just moved this for RC5)
OSBYTE to get OS (maybe should be get machine type), PHA (store on stack).
OSBYTE to CLAIM NMI (this got stuck in a loop on some machines).
SEI to stop interrupts.
Turn off all VIA interrupt generation.
Wait for VSYNC.
Setup a MODE 1 equivalent of Scramble.
Set all colours to black.
Silence all sound.
Decompress Scrambl to RAM from part way through the stack in to screen memory.
DOH! I just overwritten the OS version that I put on the stack, no wonder the joystick broke!
PLA (retrieve OS ver from stack) and store at &0000
copy key mapping from &80..&85 to &1..&6
Set top of stack to a lower value to allow a bit more room for game code
JMP to init code in decompressed game code (in what will be screen memory).

In initialisation code (in screen memory):
decompress the status bar and fuel gauge lines (yes they are "double" compressed).
Zero &7..&FF (no uninitialised variable here )
setup sound.
setup joystick (using result of OS query - don't know what dual OSs do here).
set address &0 to 0 (needed to do a BIT against 0 later to save some bytes!).
Init display (as described in earlier post).
JMP to start_new_game code.

The only remaining issue apart from beebem is there is probably a row of screen corruption on VLSI machines, which I can hopefully remove at ABUG.

Tested on B, Master, Compact, b-em (windows), beebem (beebem version on windows) and jsbeeb (in firefox).
Joystick is enabled by pressing fire and will then work with keys or joystick after that.

[MartinB]

Hey, what are you saying about my coding!

Ha! No room to talk on my part! I’m a self-confessed pathological location-trampler so I was just getting in first....

I’ll give RC5 a whirl later ( ...and there’s no need to thank me and t’other Martin for helping you to find these bugs... )

[BigEd]

Set top of stack to a lower value to allow a bit more room for game code

Oh joy! I'd never thought of that! Using the bottom of page 1 for data, yes. But using the top of page 1 for code - splendid!

[guddler]

I don't know if there was anything any different in RC5 in relation to my non-start issue but it behaves exactly the same for me. Ignoring RamFS I just tried a bunch of times to UPURS it to DFS disk and could never get past the blank screen. Copied it to USB stick directly then imported to RamFS and it worked first time.

Is this likely to be my combination of machine (master), config, MOS, add-ons, etc.? I could easily be doing something dumb as I'm not overly clued up when it comes to memory and workspace areas that could be getting overwritten and all that jazz.

Stuff that may or may not be relevant:

Master 128
Internal Pi Tube (co'd as NOTUBE)
Booting to mode 7
Dual MOS, 3.5 selected (tried 3.2 also)*

ROMS:
F Terminal 01
E View 07
D ADFS 53 (IDE Patched)
C Basic 07
B MMC DFS 5A (Unplugged as don't have MMC)
A Viewsheet 03 unplugged
9 DFS 95
8 RamFS 10

* As far as I know the Dual MOS is invisible to the system as the desired bank of the EPROM is hardware selected with the switches.

Note also that I have tried other combinations of just about everything listed that I can think of.

[guddler]

I don't know if there was anything any different in RC5 in relation to my non-start issue but it behaves exactly the same for me. Ignoring RamFS I just tried a bunch of times to UPURS it to DFS disk and could never get past the blank screen. Copied it to USB stick directly then imported to RamFS and it worked first time.

Is this likely to be my combination of machine (master), config, MOS, add-ons, etc.? I could easily be doing something dumb as I'm not overly clued up when it comes to memory and workspace areas that could be getting overwritten and all that jazz.

Stuff that may or may not be relevant:

Master 128
Internal Pi Tube (co'd as NOTUBE)
Booting to mode 7
Dual MOS, 3.5 selected (tried 3.2 also)*

ROMS:
F Terminal 01
E View 07
D ADFS 53 (IDE Patched)
C Basic 07
B MMC DFS 5A (Unplugged as don't have MMC)
A Viewsheet 03 unplugged
9 DFS 95
8 RamFS 10

* As far as I know the Dual MOS is invisible to the system as the desired bank of the EPROM is hardware selected with the switches.

Note also that I have tried other combinations of just about everything listed that I can think of.

[EDIT] PS: Quite happy to admit defeat and just say that it doesn't work for me if people don't want to get bogged down here! From my point of view I purely want to know if I'm doing something wrong or there is something wrong with my setup. I am simply trying to get to a point where I don't end up removing the lid of the machine multiple times a day and can actually settle down and start using it.

[guddler]

Not sure which thread to post this into now

I am 99% sure that this has nothing to do with Scramble code.

If I write the SSD that I manually copied to USB to floppy it works flawlessly. Every time.

If I subsequently UPURS the SSD to floppy it also works fine. Presumably this overrides only the bytes on the floppy it is sent over UPURS leaving the rest intact.

If I format the floppy and UPURS the SSD to floppy it is back to not working again.

In my very simplistic mind that suggests to me that something about my setup (probably not UPURS itself) is not finalising the floppy correctly. I'm going to see if now exporting the failing floppy to USB reveals anything in a hex viewer on the PC (Mac)

[tricky]

With regard to stack usage, why not do both
There are 50+ bytes near the bottom that survive everything I have tried and I rarely use much actual stack in my games .
Centipede uses &111..&16F inclusive for its High Score table, which is saved after a reboot, so it should be safe to start the stack from about &180 and still use &100..&110 for variables or even &110, once I have control .

There are no boot changes in RC5.
There are two things that I can think of:
1. there is an NMI causing the game to "crash" - does the startup music play?
2. I don't turn off shadow mode, so if the default is shadow enabled, you may never see the graphics! - try MODE 1 before launching.

I do appreciate all the effort everyone puts into trying to debug my games.
I do most of my development on emulators for the debugging support, but do test on some hardware.

[guddler]

OK, found the problem and its disk related so I'll post in the Wires thread.

As you were then

[tricky]

Here is a version to "hide" the VLSI corruption, as I don't have a VLSI 6845, I can't be sure it will do the job!
Richard
PS It should be OK on anything except BeebEm, but I haven't tested it yet (haven't unpacked from ABUG yet!).

[tricky]

Aparently this doesn't wo on VLSI, but I should have a working machine soon (not VLSI) so at least I can do basic testing!

[tricky]

I've got a new capture setup so thought I would post Scramble on a real beeb with commentary.

https://youtu.be/MeoxDQOS-iM best watched in 720p on a 50Hz monitor.

[davidb]

It was interesting to hear about the techniques used to draw the landscape. It reminded me of the ways I tried to plot background tiles in Castle Raider. I went for flexibility over speed in the end.

[tricky]

I think that was the right choice for your game which is a great original.
I knew exactly what was required at the start and wanted 50fps flicker free over flexibility.

[davidb]

Thanks! I think 50 frames per second is definitely worth aiming for on the Beeb.

[rmbrowngr]

Truly stunning. Such smooth scrolling like all your games.

Could the same be done on an Electron considering its more restricted timings?

[tricky]

I don't know the Elk, but I doubt it as some frames use about 3/4 of the CPU time.
It could take less time overall as I use a lot of time while the raster beam is on-screen to setup the code to draw the landscape as quickly as possible.
You would probably end up with tearing in the landscape - it shouldn't flicker though, so you could probably have a simple ground + sprites.

[bteamfox]

Hi Richard,

I am fairly new to this site and the BBC. I have been thoroughly enjoying playing Scramble even though I am terrible at it. This may already be know but if you run out of Lives and a Bomb is falling you return to the game screen and a continuous note of the bomb falling is played. I think it happens a lot to me as I am always pressing fire and bomb simultaneously, yep I’m a button masher.

I would like to take this opportunity to thank you for all the hard work you have put in to giving us so many great game remakes. They are so much better in my opinion then the original BBC versions not that I am trying to belittle the work of the original authors. It’s just to see a game on the Beeb like Frogger running so smoothly with so much on screen and flicker free is amazing to me, having been a teen in the 80’s and playing the games at the time, fast forward 40 years and seeing the same hardware playing the game’s smoother and flicker free is such a joy. Scrambles scrolling again wow! Astro Blaster is my favourite so far, the speech, I had to buy sideways ram just so I could enjoy the speech, brilliant! Although I am not a programmer I do understand the lack of memory is a problem for the BBC and it nice to see someone making use of sideways ram in the modern time to help with that. I thought Pac-Man was clever the way you used dithering to make the colour’s, again brilliant version. I have seen the r-type scrolling demo on YouTube and I really hope we get a game similar to r-type, it looks so good, E-type lol.

One other thing I do miss not having high scores save to disc and I know it’s not something you care much about as it’s not ‘Tricky’ enough for you plus the save and load routine’s take up valuable memory but would it be possible to write a high score save and load routine that sat in Rom or sideways ram. So when the game over screen is displayed or the title screen, we could press Ctrl+S or Ctrl+L to save or reload the current games high score to, or from disc. Is that something that is possible or am I talking rubbish, it was just a thought. Anyway thanks again for all the wonderful games and please, I really hope you will keep writing games for the BBC B.

[lovebug]

watched the whole video, clever stuff

very well done tricky

[tricky]

Thanks, people enjoying them is half the reward after doing the tricky bits
Carnival and Centipede do have high score saves, at least on a model B. These have them because the arcade games feature their high score tables.
Most of my games don't have room to have a high score table.

I think that the scramble noise was known, but maybe not the cause. I thought that I put a catch-all in, I'll have to check.