After a week off work, and therefore the commute & programming time, I got back to looking at PoP today. It took a while to remember where I'd got up to but managed to make some small progress by the time I got home. The attached screenshot looks like the earlier one but with a couple of important changes - firstly it's in 280x192 resolution as I had to make a custom shrunk version of the MODE 4 screen mode to save memory (yes, things are getting that tight) and secondly there is a gate instead of a wall in the top left cell where the game starts. This is because the screen is being rendered as part of the main game loop, so is using all of the correct level information, rather than as a direct call to "plot screen X".
It crashes immediately afterwards trying to render the player, of course, but it is still progress.
I'll write out today's dev diary and then see if I can fill in the blanks for the last few I didn't post before the break.
Today's quandary was all about memory usage (I think this will be an ongoing theme...) I continued to stub out functions with RTS calls in the jump table in an attempt to get the main loop running. At some point memory was getting trampled unexpectedly so I needed to debug with b-em's handy watch memory write feature. I realised that now I was loading all the different sprites into different SWRAM banks I needed a way to switch between them when appropriate, otherwise I'll be reading garbage instead of the sprite pointer table. Fortunately POP already had the concept of banks for sprites, as on the Apple II these reside in both main & aux RAM. I borrowed the BANK ZP variable for my own Beeb plot function and changed the existing sprite bank table with SWRAM slot numbers.
I next realised that the level "blueprints" are quite liberally and freely accessed across the code, so my plan to keep these in the same SWRAM bank as the background sprites wasn't going to work easily, as I would need to manually page this bank in for all the places it is used. This could be done (and might have to be) but I am trying to mess with the original code as little as possible for the time being until I have to resort to serious Beeb specific optimisations. The level blueprints are &900 bytes (2304 bytes) which turned out to be too much to find in lower memory space.
After some deliberating I decided to keep ploughing ahead, so knocked up a quick set of CRTC variables to shrink the MODE 4 screen to 280x192, which saved me enough RAM to store these lower down. I am going to have to make a big move to using SHADOW RAM at some point in the near future but I am trying to put it off for as long as possible to keep things simple!
Finally, I ported the function to add moveable objects to the display list, as this seemed to be a good step forward and resulted in the gate appearing in its correct position.
Currently the code is reaching about the 2nd function call inside the main Kid routine. There are about another 16 to stub or port but I believe this will result in the final set of data tables which represent all of the animation sequences & loops etc. getting pulled in. This may again necessitate some refactoring or memory tinkering but I will deal with that when I come to it.