Why was dizzy series not on the Beeb

[lushprojects]

You all probably already know this, but RMC published a long(ish) presentation by the Oliver Twins on their history:
https://www.youtube.com/watch?v=FVqfA5cK3z8

I think it's fair to say that they were pretty commercially focussed, which was fits with the idea that they didn't think the Beeb market was worth the effort for their business model.

[picosonic]

You all probably already know this, but RMC published a long(ish) presentation by the Oliver Twins on their history:
https://www.youtube.com/watch?v=FVqfA5cK3z8

I think it's fair to say that they were pretty commercially focussed, which was fits with the idea that they didn't think the Beeb market was worth the effort for their business model.

I was asked by Neil (of RMC) if my BBC Micro port of Dizzy would be ready in time to shown the Oliver twins when they visited the cave to do their talk.

[picosonic]

I've not had a lot of time to progress my Dizzy 3 port lately, but what I have done is decided that I won't be able to fit everything in memory that I want to be able to make it a faithful port. I didn't want to have to do this because I wanted it to run on a stock Beeb.

However I've now switched to using 1 bank of sideways RAM for the level data and strings, previously I had an almost 16kb file which I read chunks in and out to a reserved buffer in RAM as you navigated the rooms.

This was not only a bit slow and clunky, but it also required me to have 919 bytes reserved in RAM to load the data into - enough for the biggest room/strings combination. Ultimately most of this buffer was never used and therefore the space it occupied felt wasted.

I've never done anything with sideways RAM before so it's been a pretty steep learning curve for me, although the documentation on this forum proved invaluable.

So what I've attached to this post is an updated version which uses sideways RAM, please can you test this and let me know if it works ok for you.
It seems to run fine in beebjit / b2 / jsbeeb / beebem - so I'm hopeful that it'll work on a real Beeb too.

These are the results of detecting sideways RAM on a few emulators, in their default configurations, just using FE30 (ROMSEL) and a test write ..

beebjit
- BBC B = No sideways RAM found
- " " when specifying -swram 0 .. -swram 7 = 8 RAM banks (0-7)
- BBC Master 128 = 4 RAM banks (4-7)

jsbeeb
- BBC B = 8 RAM banks (0-7)
- BBC Master 128 = 4 RAM banks (4-7)

beebem
- BBC B = 4 RAM banks (4-7)
- BBC B + = 3 RAM banks (0,1,12)
- BBC B + Integra-B = 3 RAM banks (4-7)
- BBC Master 128 = 4 RAM banks (4-7)

b2
- BBC B = 1 RAM bank (13)
- BBC B + 64k = No sideways RAM found
- BBC B + 128k = 4 RAM banks (0,1,12,13)
- BBC Master 128 = 4 RAM banks (4-7)

If all seems well, I'll look to also move the sprite data to another page of sideways RAM to gain another 7.3kb memory back for code.

Thanks

dizzy3.ssd

Updated Dizzy3 disk image using sideways RAM

(74.75 KiB) Downloaded 44 times

[fizgog]

Looking good

[jms2]

A good decision I think. The main reason not to use sideways ram (not enough people have it to make the game commercially successful) has been removed on both fronts - most users do now have sideways ram, and in any case the game is not commercial anyway! (I assume)

I realise there's also the question of pride in being able to cram it all in, but at the end of the day there has to be a limit.

Good luck with your ongoing efforts!

[tricky]

Romsel is only one way of selecting RAM banks to write to and doesn't include the master, but several people have posted sideways RAM detection code including me, so you can change the detection code later if you want.

[picosonic]

Romsel is only one way of selecting RAM banks to write to and doesn't include the master, but several people have posted sideways RAM detection code including me, so you can change the detection code later if you want.

Yeah I have seen lots of code snippets for sideways RAM switching, but all different. Some have delays, some try multiple methods, some update the OS RAM copy of the ROMSEL value.

So for now I’m just going with what seems to work in all the emulators I’ve tried so far.

Any pointers to more fully featured code to increase compatibility would be greatly appreciated.

I’ve looked at swrtype by Wouter Shoulten, but I’m not sure which mix would give best/simplest compatibility..

http://wouter.bbcmicro.net/bbc/software-whs.html

[picosonic]

The main reason not to use sideways ram (not enough people have it to make the game commercially successful) has been removed on both fronts - most users do now have sideways ram, and in any case the game is not commercial anyway! (I assume)

Definitely not a commercial release, but one which the Oliver twins are aware I’m doing and I have their blessing. They’ve offered to help with assets or anything else I need.

It’s fully open source, project page is here ..

https://github.com/picosonic/D3

[tnash]

Appears to run happily on my B with 32k SWRAM and looks great.

[picosonic]

Appears to run happily on my B with 32k SWRAM and looks great.

Perfect, thanks for trying it out.

[SteveF]

This looks like a really cool project - my grandmother used to love Dizzy on the Spectrum, so this reminds me of her.

Yeah I have seen lots of code snippets for sideways RAM switching, but all different. Some have delays, some try multiple methods, some update the OS RAM copy of the ROMSEL value.

So for now I’m just going with what seems to work in all the emulators I’ve tried so far.

Any pointers to more fully featured code to increase compatibility would be greatly appreciated.

I’ve looked at swrtype by Wouter Shoulten, but I’m not sure which mix would give best/simplest compatibility..

I've used Wouter's swrtype in Ozmoo and it works well. Nowadays I think the vast majority of sideways RAM works via ROMSEL and what I've done is:

• Use Wouter's code to detect all possible types of SWR - he's already written the code, so this doesn't take any extra effort on my part.
• Give a polite message if it detects sideways RAM that doesn't work via ROMSEL but otherwise ignore it.
  • If someone expresses an interest in supporting an alternate style of sideways RAM, I'm willing to have a go at implementing it if they're willing to test. So far this hasn't come up. Most emulators don't support emulating non-ROMSEL sideways RAM, so it's hard to test this without someone who owns real hardware getting involved.
• Do sideways RAM paging in the code via macros so it's easy-ish to switch the way it works if necessary. If it's not performance critical, you could put the paging code in a subroutine, then if you ever want to support multiple types of sideways RAM you could have that subroutine patched during initialisation to do the right thing for the detected sideways RAM type - and to start with you just write ROMSEL code in there and leave it at that.

If you roll your own sideways RAM detection code, there's a chance it will work on an emulator and then fail on real hardware for electronics reasons which I kinda-sorta-vaguely understand ("bus capacitance"). Ask me how I know...

Edit: But this is all relatively easy to tweak during a final polishing stage of development, so please don't let it distract you from the much cooler process of actually implementing the game!

[picosonic]

This looks like a really cool project - my grandmother used to love Dizzy on the Spectrum, so this reminds me of her.

Exactly the same for me, my grandmother had a Spectrum which is where I played Dizzy, she had most of the Spectrum Dizzy games but 3 was my favourite.

Do sideways RAM paging in the code via macros so it's easy-ish to switch the way it works if necessary. If it's not performance critical, you could put the paging code in a subroutine, then if you ever want to support multiple types of sideways RAM you could have that subroutine patched during initialisation to do the right thing for the detected sideways RAM type - and to start with you just write ROMSEL code in there and leave it at that.

Yep, I've done it in a MACRO for that very reason. Because I use the OS for some stuff (at the moment), I'm using SEI and CLI in the MACRO, so I need to be really careful it doesn't get nested.

It will work on an emulator and then fail on real hardware for electronics reasons which I kinda-sorta-vaguely understand ("bus capacitance"). Ask me how I know...

Go on then, have you had experience of this? Do tell.

Edit: But this is all relatively easy to tweak during a final polishing stage of development, so please don't let it distract you from the much cooler process of actually implementing the game!

Yep totally agree, this first implementation of SWRAM use is rough and just enough to get me back to gamedev rather than memory and disc origami.

[picosonic]

The sideways RAM I have on my Beeb is via the Watford Electronics ROM/RAM board.

It would seem that the SWRAM needs to be selected via standard ROMSEL, then you also need to write (any value) to &FF30+slot

Wouter reported not to have tested these boards yet. But there is code in swrtype to detect these boards.

Interesting that you can also make the RAM on these boards read only.

General information from WE ROM/RAM manual

[SteveF]

It will work on an emulator and then fail on real hardware for electronics reasons which I kinda-sorta-vaguely understand ("bus capacitance"). Ask me how I know...

Go on then, have you had experience of this? Do tell.

Well, in my experience, what happens if that the process goes something like:

• Aha, this is an interesting little problem. Not rocket science, but interesting.
• I'll just loop over all 16 possible banks, page them in in turn and try modifying them to see if they're RAM.
• The binary version in the ROM header looks like a good thing to modify as it has little effect, so if the user happens to press BREAK before we can revert our trial modification, any ROM images in sideways RAM banks won't be significantly corrupted. I'm so smart thinking of these little details!
• My code is working well in this emulator! I was even thorough enough to try different arrangements of sideways RAM banks and it works great!
• Oh, someone has tried it on real hardware and it doesn't work. I can probably fix this...
• OK, I've fixed it. I have no way to test it works but I'll push the change out and see what happens. It can't be that hard, can it?
• It does seem to work. But I no longer trust it not to go wrong on someone else's machine. I'm going to get bug reports caused by my code trying to use sideways RAM that it thinks exists when it doesn't, and I'm going to go nuts trying to track it down.
• Wouter has this code which looks like it was actually given some real testing on more real hardware BITD than I'm ever going to get my hands on. Let's just use that.

The sideways RAM I have on my Beeb is via the Watford Electronics ROM/RAM board.

That's the one I had BITD, actually. It was a bit of a nuisance as hardly any commercial software actually supported it, although stuff that only needed one 16K bank like Exile did generally kinda-sorta work, perhaps with a bit of poking at &FF3x before loading it to make the RAM writable, at least that's how I remember it. It'll be interesting to see if Wouter's code does work on that.

Yep, I've done it in a MACRO for that very reason. Because I use the OS for some stuff (at the moment), I'm using SEI and CLI in the MACRO, so I need to be really careful it doesn't get nested.

Could you do "php:sei" to disable and "plp" to enable in a nesting-safe way? Not an option if you need to return values in the other flags though, of course.

[tricky]

It will be basic that you are pushing out and only you will be calling the OS, so I would expect you can just select what you want as long as you update the ram copy for the OS. You might need to check the ram copy before you use it.
I'm sure jgh or someone else will know.
My code is in my games that use sideways ram, so astro blaster, newer moon patrol demos, warlords and the b-type demo uses two banks.
It supports all the types of swarm that I know of and i have had no reported failures.
If you only need to load into swram and not write to it once you have finished loading, it doesn't matter which sorry it is.
If you check for the earlier solidisk expansions, it will break the next mmfs access, but this can be worked around by adding an on error to retry.
I think only the B+64 swram is less than 16k, but if there is something else that doesn't mirror the ram, it might be worth testing at the last address you need to use.
Sorry, sick today so rambling.
Anyway, just go with what you have and maybe change later if you want.
PS I did find something that woter's code doesn't support but if have to recheck to be sure.

[picosonic]

I’ve changed the code to just set the ROMSEL and RAM copy that I detected SW RAM in, this seems to work just as well.

Since the OS isn’t switching to look for call handlers because I’m not making OS calls and not using BASIC.

But I did notice that the OS routine to read data from paged ROMS doesn’t even use SEI and CLI.

OSRDRM code, from OS 1.20

[tricky]

It doesn't have to as long as everything in interiors does and restores back to the ram copy.

[picosonic]

It doesn't have to as long as everything in interiors does and restores back to the ram copy.

Makes sense, I just wondered if a mis-timed interrupt could mess things up without SEI/CLI.

Also I stumbled across a disc I was given a while back, which I had imaged, which contained some SWR code on it.
Wondered if anyone recognised it? Perhaps Solidisk related?

It contains a file called Printer which appears to be "Printer Buffer (c) Solidisk 1984 by M Dove"

SWR menu

[tricky]

Yes, looks like the solidisk menu for loading and saving ROMs as well as launching apps. They had quite a large catalog although I never bothered to get them.

[picosonic]

I've made a few updates to Dizzy since last posting, too numerous to mention, just wanted to post the updated version here.

Still very much a WIP, but would appreciate any feedback on my progress.

dizzy3.ssd

Dizzy 3

(76.75 KiB) Downloaded 51 times

[jms2]

The graphics are very impressive - it looks like it's coming together very nicely!

I assume its intentional at this stage that Dizzy keeps spinning around spontaneously?

[picosonic]

The graphics are very impressive - it looks like it's coming together very nicely!

Thanks, it is using the original levels and sprites so should look most like the CPC version.

I’m thinking of moving the main character sprites to a second SWRAM bank to gain an extra 7k. Not that I’m running low on space yet but don’t want to be looking over my shoulder as it creeps up on me. I’m assuming most people will have at least 2 SWRAM banks available. Then when I get to the optimisation stage I might be able to claw a load back.

I assume it’s intentional at this stage that Dizzy keeps spinning around spontaneously?

Yep, just testing animation sequences. I haven’t done proper character movement yet as I need to navigate quickly to test out new bits of code. I did have a debug key mapped which I can try things out with.

I’m concentrating on the collision detection and object interactions (using proximity boxes) as you pick up/put down and interact with objects and other characters.

[Cybershark]

Coming along in leaps and bounds!

This is great, being able to almost properly move around between the screens! Nice to see the hazards implemented too. One thing I note is that the frame rate drops dramatically on the screens with water on.

Would be cool if you can add a little more colour to the game, with a palette swap for the status panel - switch up the green text for cyan or magenta maybe? But obviously not a deal-breaker as far as gameplay goes

[picosonic]

Coming along in leaps and bounds!

Thanks. It feels like slow progress, despite having loads I know I have left to do, I can see some light at the end of the tunnel

Nice to see the hazards implemented too. One thing I note is that the frame rate drops dramatically on the screens with water on.

I think I need to limit the frequency of drawing of Fire and Water update animations. It’s on my todo list.

Would be cool if you can add a little more colour to the game, with a palette swap for the status panel - switch up the green text for cyan or magenta maybe?

I do have a plan to change palette part way down screen, although initially just for the treasure island pic you get if you press RETURN whilst under the painting in the castle So that Dizzy can have red gloves on.

I’m initially aiming for the graphics to be the equivalent of what you got on the CPC version of the game. Although I’m open to having enhanced versions when I come to the optimisation stage.

I’ve already got the loader speech, treasure island Dizzy painting and music from the AtariST version. So it’s a bit of a mish mash. But hopefully will end up feeling like a version which could have been released back in 1989 with the other platforms.

[thecellartroll]

I just discovered this and tried it on my BBC B with 32K SWRAM today. Very cool

[picosonic]

Quick end of year update for Dizzy 3 port to Beeb..

Added picking up and interacting with objects, switches, machines and npcs.

Added interacting with other Yolk Folk chat and giving/receiving objects.

Added instructions to loader.

Updated to use second page of SWR, so now 32kb required to run.

Plus as posted earlier in this thread, the treasure island picture now uses 5 colours in mode 1!

Treasure island loader

Loads and loads of other small changes, fixes and tidy ups.

And, here's the updated disk image..enjoy!

dizzy3.ssd

Dizzy 3 SSD

(83.25 KiB) Downloaded 39 times

[picosonic]

I just discovered this and tried it on my BBC B with 32K SWRAM today. Very cool

Thanks for trying it, glad you like it.

[Cybershark]

So many projects get lost along the wayside, so it's fantastic to see that work continues on this one

[thecellartroll]

Quick end of year update for Dizzy 3 port to Beeb..

Wow! It is almost a full Dizzy game now. Tested interactions like the picture, feeding the bread to the rat and dying by burning on my BBC B. Looking good

[picosonic]

Wow! It is almost a full Dizzy game now. Tested interactions like the picture, feeding the bread to the rat and dying by burning on my BBC B. Looking good

Thanks for trying out the updated version.

I’ve got an issues tracker/todo list going at my project source repository. Please feel free to submit any issues I might have missed.

https://github.com/picosonic/D3/issues

Still very much a WIP, but most of the main game elements are there, except the character movements/animations. So it should be completable if you were to follow a walkthrough.