Sideways RAM question

bbc micro/electron/atom/risc os coding queries and routines
Post Reply
Naomasa298
Posts: 179
Joined: Sat Feb 16, 2013 12:49 pm
Contact:

Sideways RAM question

Post by Naomasa298 » Fri May 22, 2020 12:07 pm

I had a brilliant idea. I could put my sprite code in sideways RAM, to save working space in main memory.

Except.. it could potentially need to access data in banks other than its own. Which made me wonder - what would happen if you had a copy of the same code sitting at the same address in each bank, then switched banks in the middle of running the code. Would the code simply continue to run properly? I'm assuming the execution address wouldn't reset upon switching a bank out.

This is not the strategy I would use, of course. I'd just have the calling code work out which bank it needs to switch in and call the copy of the code in that bank, but could it be useful for a bit of code that needed to access more than 16k of data?

User avatar
Pernod
Posts: 1965
Joined: Fri Jun 08, 2012 11:01 pm
Location: Croydon, UK
Contact:

Re: Sideways RAM question

Post by Pernod » Fri May 22, 2020 12:25 pm

Naomasa298 wrote:
Fri May 22, 2020 12:07 pm
Which made me wonder - what would happen if you had a copy of the same code sitting at the same address in each bank, then switched banks in the middle of running the code. Would the code simply continue to run properly? I'm assuming the execution address wouldn't reset upon switching a bank out.
The CPU doesn't know you've switched banks, all it cares about is that valid code exists at the program counter. If the code is identical in each bank then execution will continue as expected.

This method was used by Computer Concepts and others with the Inter series ROMs where a 32K (or larger) ROM was banked into a single sideways ROM bank. Each bank would contain a common piece of code that performed the switching.
- Nigel

BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
davidb
Posts: 2725
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Sideways RAM question

Post by davidb » Fri May 22, 2020 1:04 pm

I used this in one of the ROM variants in the Mega Games Cartridge, where banks of 16K ROM are paged in under the running program. The trick is to have a routine at a fixed place in the ROM that performs the bank switch, and ensure that it is at the same place in all ROMs.

User avatar
Andrew_Waite
Posts: 222
Joined: Tue Aug 30, 2016 3:58 pm
Contact:

Re: Sideways RAM question

Post by Andrew_Waite » Fri May 22, 2020 1:37 pm

My games for the BBC Master, Planet Nubium and Nubium 2, keep the guardian sprite bitmaps and blitting code in SWRAM Bank 7, with the location in screen memory of each sprite in a parameter block in main memory, just below screen memory.

To draw the sprite in PN1 a CALL is made from the BASIC part of the main game loop to an assembler routine in main memory which performs the bank switch and JSRs to the sprite blitting routine. Afterwards the BASIC ROM is bank switched back into the CPU's memory map. The routine blits 8 sprites in parallel, and the blitting routine is executed twice in PN2 as the maximum number of guardians is increased from 8 to 16.

The contents of SWRAM Bank 7 can be seen visually. After pressing ESCAPE during either game type "*SRREAD 3000+4000 8000 7". The sprite bitmaps can then be seen taking up most of the screen, with a thin stripe of code below the bitmaps. This code differs between the two games as PN2 uses a faster routine with self modifying code.
Attachments
111.png

Naomasa298
Posts: 179
Joined: Sat Feb 16, 2013 12:49 pm
Contact:

Re: Sideways RAM question

Post by Naomasa298 » Fri May 22, 2020 2:09 pm

Andrew_Waite wrote:
Fri May 22, 2020 1:37 pm
My games for the BBC Master, Planet Nubium and Nubium 2, keep the guardian sprite bitmaps and blitting code in SWRAM Bank 7, with the location in screen memory of each sprite in a parameter block in main memory, just below screen memory.

To draw the sprite in PN1 a CALL is made from the BASIC part of the main game loop to an assembler routine in main memory which performs the bank switch and JSRs to the sprite blitting routine. Afterwards the BASIC ROM is bank switched back into the CPU's memory map. The routine blits 8 sprites in parallel, and the blitting routine is executed twice in PN2 as the maximum number of guardians is increased from 8 to 16.

The contents of SWRAM Bank 7 can be seen visually. After pressing ESCAPE during either game type "*SRREAD 3000+4000 8000 7". The sprite bitmaps can then be seen taking up most of the screen, with a thin stripe of code below the bitmaps. This code differs between the two games as PN2 uses a faster routine with self modifying code.
My code keeps the address of each sprite in a table at the start of the sprite data area. It's called with the sprite number and the address of the sprite area as a parameter - the plan is to pass either the address (for sprites stored in main memory) or the number of the bank to the mediating BASIC routine, which will then decide which version of the code to call. I'll have three different routines - compressed with no mask in main memory, uncompressed with optional mask in sideways ram and sprites for text.

Speed isn't too much of an issue because I'm not writing a fast moving game, so my routines probably aren't as optimised as they could be. I've managed to save a few cycles here and there but nothing amazing.

Post Reply

Return to “programming”