Accessing alphadata tables when bankswitching

[+TwentySixHundred]

Hi guys, i have been trying to access alphadata tables for screen transitions and obviously no issue when those tables are stored in the same bank. When storing them in another bank - reading - returning to engine bank, the data is lost and the tiles are jumbled up. I have suspicion savescreen only remembers the data till the bank is switched? Which then leads me to think in order to retrieve that data it would need to be stored in RAM? Is my suspicion correct or is there a trick to retrieving alpha data from another bank then plotting the tilemap in the engine bank?

 

I was thinking you could jump to a label in another bank then clearscreen - plotmap - savescreen then returning to engine bank however no luck there. Also tried some other variations of this method without any success so far. Im sure there has to be a simple way to retrieve that data

[RevEng]

The alphadata needs to be visible to Maria when it's the time to render them on the screen. If you store your character data in a non-permanent bank and switch away during the visible screen (where much of your 7800basic game will run) then you will likely corrupt the character display.

 

There's a few common solutions to this:

• store your character data in a permanent bank (last bank in rom sizes that are multiples of 128k. first+last bank in rom sizes that are multiples of 144k)
• store your character data in the same bank as your main loop.
• copy your character data to ram, and plot that instead. (as you worked out)
• keep a copy of the character data in the exact same place in both banks you're switching between. (possible, but not always practical)
• wait for the visible screen to complete before bankswitching by using the "drawwait" command (hugely wasteful of available CPU time, so really only useful for non-main-loop situations)

 

The reason that clearscreen+plotmap+savescreen doesn't work to fix the issue, is that those are all commands that just prepare display objects in advance of maria drawing the visible screen. They don't actually render the characters on the screen at the time you issue those commands; Maria has no framebuffer, so it needs to be able to fetch that object data at the exact moment in time the beam is drawing the scanlines where your object should be. (i.e. Maria is racing the beam)

[+SmittyB]

Savescreen doesn't store the data that's been drawn, it saves the instructions on how to draw it.

When you give the name of your data to a plot function your actually saying "draw stuff at this address" and that address is what's saved, but when you change banks the values at that address won't be the same values they were before so when the screen is drawn it won't draw what you're expecting.

 

You can either duplicate the data so it's at the same address in the bank you're in when the screen draws (not easy), have the data in the bank it's going to be drawn in and use that for the plot command, or have the data in a location accessible for both banks (either ROM or RAM).

 

 

RevEng beat me to the punch. Next time.....

[RevEng]

4 minutes ago, SmittyB said:

RevEng beat me to the punch. Next time.....

there's different emphasis in our replies, so both are helpful. ?

[+TwentySixHundred]

Cheers guys yeah both explanations are indeed helpful for getting a full understanding as to what is going on. Obviously very different to how bB handles stored data (with DPC+ anyway). So im still trying to wrap my head around the different modes and how to access stored data correctly.

 

Yes i had also forgot to mention i worked out that storing the data in a persistent bank for example the last bank did work. Although with a large ROM i was hoping to get a little greedy, and utilize the other remaining non persistent banks as mass storage for character data. So from what i understand to achieve this i would need to use the store-in-RAM method. The only other method i could think of (not really ideal) would be to have the engine in each bank and fill the rest of the bank with character data ect.

 

Im thinking converting and storing the alpha data into RAM then extracting when in the main engine bank wouldn't be all that straight forward either. I mean there is no shortage of RAM so that's a good thing, however im still thinking about how to tackle that method and if it would be a viable option.

 

Also thanks for explaining how the savescreen function works, makes alot more sense now ?

Edited August 7, 2020 by TwentySixHundred

[+SmittyB]

As far as the 7800 is concerned there's not a lot of difference between ROM and RAM so if you have enough RAM free you can copy your text from one bank into RAM and possibly just use the location in RAM on your plot command. I've not used alphadata much so I don't know if 7800BASIC will allow that.

[RevEng]

[edit - this time SmittyB beat me to it.   alphadata can be easily copied to ram in 7800basic, as can pretty much any data type, as long as you know the size of the data. character plotting routines can be pointed to memory instead of rom.]

 

1 hour ago, TwentySixHundred said:

The only other method i could think of (not really ideal) would be to have the engine in each bank and fill the rest of the bank with character data ect.

 

Just wanted to point out that some duplication of data and/or code in different banks is common practice, and pretty much the nature of the beast. I get that it feels wasteful, but often enough the duplication allows you to reduce the complexity of your code, making the trade-off worth it.

 

Heads up that copying a rom table to ram can be done pretty easily with the "memcpy". In the samples directory "ramcharmap" has example code that loads different character level data to a ram-based character buffer.

 

The bankswitching constraints are actually not very different from vanilla bB, but for sure different than the DPC+ bankswitching you're used to. DPC+ has ARM-based RAM that's used for update of display objects, and can be accessed from any bank.

[+TwentySixHundred]

Once again thanks guys, this is exactly what i was looking for Just need to work out exactly what im doing with memcpy and memset. I will have a good look at the ramcharmap sample tomorrow with a fresh set of eyes. I remember skim reading those functions in the guide but it kinda went over my head as a novice to 7800basic.

 

Yeah come to speak of it i did duplicate the engine into separate banks with Bass Fishing for simplicity and more cycles as i had an overcycle issue at one point. Just made things easier to maintain and optimize however id probably rewrite the whole engine if i were to touch it again lol.

 

@RevEng That is correct, i got really comfortable with DPC+ and all its ARM goodies.

 

Personally i would like to use the RAM method and have a single engine {mainloop}. Thanks for the help ill get some sleep and look at storing data into RAM tomorrow. Never hurts to learn something new ?

[+TwentySixHundred]

Well, after breaking down the ramcharmap sample and help from you guys explaining how storing data into RAM works, we're cooking with gas I had to rewrite the example into what would work with my game engine and bankswitching scheme but it works flawless!

 

Only issue and not really an issue is i need to re-initialize the includes for tallsprites after bankswitching. However this routine is only ever called once during screen transitions so nothing too major. Im yet to see if i need to re-initialize the color pallets (thinking i don't), although at this moment im re-initializng them anyway.

 

This is exactly what i was after and had pictured in my head as an ideal method for retrieving charmap data in non persistent banks. Thanking you both for taking the time to explain how it works, much appreciated ?

 

Now i have 29 remaining banks to fill with charmaps ?

 

Edit: Maybe if i move the game engine back to bank1 rather then 2 (by DPC+ habit) i may not have to re-initialize those tallsprites after bankswitching ? Either way i got plenty of ROM to spare.

Edited August 8, 2020 by TwentySixHundred