New version of Scramble for the beeb (going well)

new games to be launched and discussed here
User avatar
guddler
Posts: 515
Joined: Sat Apr 04, 2009 9:43 am
Location: W.Somerset
Contact:

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

Post by guddler » Sat Oct 20, 2018 12:59 pm

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.

User avatar
guddler
Posts: 515
Joined: Sat Apr 04, 2009 9:43 am
Location: W.Somerset
Contact:

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

Post by guddler » Sat Oct 20, 2018 1:10 pm

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

User avatar
paulv
Posts: 3716
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

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

Post by paulv » Sat Oct 20, 2018 5:00 pm

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

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

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

Post by tricky » Sat Oct 20, 2018 5:55 pm

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.

User avatar
guddler
Posts: 515
Joined: Sat Apr 04, 2009 9:43 am
Location: W.Somerset
Contact:

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

Post by guddler » Sat Oct 20, 2018 7:41 pm

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?
Last edited by guddler on Sat Oct 20, 2018 9:16 pm, edited 1 time in total.

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

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

Post by tricky » Sun Oct 21, 2018 8:15 am

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 ;)

User avatar
MartinB
Posts: 4980
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

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

Post by MartinB » Sun Oct 21, 2018 8:27 am

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.

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

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

Post by tricky » Sun Oct 21, 2018 8:45 am

MartinB wrote:
Sun Oct 21, 2018 8:27 am
... 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?

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

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

Post by BigEd » Sun Oct 21, 2018 8:49 am

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

User avatar
MartinB
Posts: 4980
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

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

Post by MartinB » Sun Oct 21, 2018 8:57 am

tricky wrote: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.

Ed wrote:....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.


.
Last edited by MartinB on Sun Oct 21, 2018 9:03 am, edited 2 times in total.

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

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

Post by tricky » Sun Oct 21, 2018 9:55 am

Hey, what are you saying about my coding! :lol:

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!

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

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

Post by tricky » Sun Oct 21, 2018 11:00 am

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.
splash_screen.png
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.
Attachments
ScrambleRC5.zip
(28.26 KiB) Downloaded 18 times
Last edited by tricky on Sun Oct 21, 2018 11:03 am, edited 1 time in total.

User avatar
MartinB
Posts: 4980
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

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

Post by MartinB » Sun Oct 21, 2018 11:27 am

tricky wrote:Hey, what are you saying about my coding! :lol:
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... :lol: )

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

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

Post by BigEd » Sun Oct 21, 2018 11:37 am

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!

User avatar
guddler
Posts: 515
Joined: Sat Apr 04, 2009 9:43 am
Location: W.Somerset
Contact:

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

Post by guddler » Sun Oct 21, 2018 11:43 am

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.

User avatar
guddler
Posts: 515
Joined: Sat Apr 04, 2009 9:43 am
Location: W.Somerset
Contact:

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

Post by guddler » Sun Oct 21, 2018 11:46 am

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.

User avatar
guddler
Posts: 515
Joined: Sat Apr 04, 2009 9:43 am
Location: W.Somerset
Contact:

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

Post by guddler » Sun Oct 21, 2018 12:03 pm

Not sure which thread to post this into now :lol:

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)

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

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

Post by tricky » Sun Oct 21, 2018 12:04 pm

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. =D>
I do most of my development on emulators for the debugging support, but do test on some hardware.

User avatar
guddler
Posts: 515
Joined: Sat Apr 04, 2009 9:43 am
Location: W.Somerset
Contact:

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

Post by guddler » Sun Oct 21, 2018 12:15 pm

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

As you were then #-o #-o

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

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

Post by tricky » Mon Nov 12, 2018 5:33 pm

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!).
Attachments
ScrambleVLSI.zip
(14.15 KiB) Downloaded 8 times
Last edited by tricky on Mon Nov 12, 2018 5:34 pm, edited 1 time in total.

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

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

Post by tricky » Tue Nov 13, 2018 6:39 pm

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!

Post Reply