This is a spin off thread from my c64 sprites.....

This is probably really really messy... (and I'm not sure what I'm doing)...

I've loaded my graphics data into $3000 >

I then run my machine code which starts at $2000, which copies this data down to $0400 to $1fff - This is sprite graphic data.... and then I clear the screen memory.... Mode 2 ($3000-$7fff)

Now I can happily run through the memory ($0400 to $1fff) plotting the data to the screen... It seems to work OK....and is not getting currupted from what I can see initially.....

Is this a good approach..? ( I'm not intending to be running BBC basic, doing sound using bbc rom routines, Disk loading etc).... It's a 'one shot load and run' and ideally I want to disable all 'housekeeping' so I can grab the machine by the balls so to speak.... utilising as much memory as I can muster.... ( I guess I can also open up Zero Page a fair bit too ?)

If its not a good idea... can you guys suggest GOOD memory real-estate to use please ?

Cheers, Colin

Hi Colin,

If you intend to let the OS in for anything at all, take a look at the thread in 'Programming discussion' called something like "Memory from &E00 to &1900", where I put a list of all the OS-safe memory areas you can use.

If you intend to shut the OS out completely, and reconfigure all the hardware your own way, then you can pretty much use EVERY BYTE of RAM, with the following exceptions:

$FC is corrupted by the OS IRQ entry point.
$204 and $205 are the IRQ jump vector, so you'll need to keep those for that purpose.
$258 should contain 2 and $287 should contain anything but $4C for a clean restart when Break is pressed.
$D00 should contain an RTI instruction as it's the NMI entry point.

Other than that, go wild

Of course in Mode 2, $3000-$8000 is screen memory. If you read up on the CRTC registers, you'll see that you can configure the screen dimensions on the Beeb, making them smaller and thus freeing up a little extra memory - this is fairly common practice, as a 20k screen is a LOT!

When loading the game, you'll have to load the executable to a higher address (anywhere above &1200 should be safe for any filesystem), and then, at its entry point, have a bit of stub code (which is discarded once run) which relocates it to the 'correct' address before JMPing to the correct place. I put my hardware configuration in this entry code too, so that it's discarded afterwards and doesn't take up valuable bytes! For safety, select the tape filing system before obliterating OS memory, and also make sure that interrupts are disabled, or being handled by your own code which doesn't return control to the OS.

Edit to say: $100...$1FF is the 6502 stack - but of course you can use as much of this as you dare too. I have LDX #31:TXS at the top of my code, which gives me 32 bytes of stack - doesn't sound much, but I tend not to use the stack for much, only JSRs and interrupts. If I want to preserve registers, I tend to use zp, or even self modify a LDA #xx at the end of the routine. Then I can use from $120 onwards for code. Also, in a 'debug build' in the main loop I check locations $1FE and $1FF contain what they should, so I can catch any stack overflows - but so far, I've never had a problem.

Thanks for the info.....

So... I guess there may be a way to make the screen 320 x 200 - 16 colours (like the c64 res ? ) and use 16K instead of 20K... so it would start at $4000 instead of $3000 is that right ? - I'm all ears here, lol....

Cheers, Colin

Yeah, more or less!

In Mode 2, of course, it's gonna be 160x200... If you do this, then you have a slightly-less-than-16k screen which starts at $4180 ($8000 - 25 * 80 * 8), but feel free to start it at $4000 if you wish.

Next, you'll have to read up on the 6845 CRTC! All the info's in the Advanced User Guide. It contains a number of registers - you write value b to register a like this:

The ones you'll be interested in modifying from standard Mode 2 are:

R6 - number of displayed character rows (change to 25)
R7 - vsync position (probably change to about 31, to recentre the screen)
R12, R13 - address of the top left of the screen, divided by 8 (in order to relocate the screen to $4000 or $4180, as you wish)

Then, there's cosmetic stuff like:
R10 - turn the cursor off
R8 - turn interlace off

It doesn't sound as if you're going to need hardware scrolling facilities (where you change the start-of-screen address each frame to shift it by character block amounts), but if you were to need that, then there's some other jiggery-pokery you need to do to tell the address generator that you're using a 16k screen (so that it wraps back to $4000 instead of $3000 when it gets to $8000). More on that if you need it!

If you want more details, give us a shout

Being a bit lazy, I position my screen buffer down in the middle of the $200 page and put all my executable code after the screen buffer. So there's no copy down step, loading is safe with all normal filing systems, but I do end up using all the memory I free by locking out the OS.

That's on the Electron, but I assume there's no lower bound on screen addresses on the BBC either?

Ahh... never thought of that! The main reason to put the screen buffer in high RAM on the Beeb is so that you can benefit from the hardware address wrap-around if you want to do hardware scrolling. But if you're maintaining a static screen address, then I guess there's no reason why you shouldn't put it anywhere you want!

Having thought about it a bit further, I guess I could have my code load so that the initialisation stuff is positioned at the end of where the framebuffer will be, so I do end up reclaiming that once-only code, once again without expending very much effort on the issue. I guess I'll just make my call to my ClearScreen routine the very last init thing I do and ensure that the opcode immediately after it is just after my screen area.

As I'm sure you're aware, hardware scrolling is essentially crippled on the Electron (addresses can be set to the nearest 64 bytes only, so it's an 8 column horizontal scroll minimum), so that's not really a consideration. But I guess it does make me incompatible with turbo board addons, since they shift the low 8kb out of the ULA's address space so that it can give a full 2Mhz to the CPU.