Hello

I come from the c64 scene although I like to program for any 6502 based machine, and so I have tried my hands at other computers such like the atari xl, atari 7800 and oric.

The BBC micro is an interesting beast and I have been wanting to code a game for it.

I have been looking for information about the hardware etc and there are lots of stuff in the internet, now the problem is to sift through it and there are it seems a number of different BBC models...

In the game I have in mind, I am hoping to have a screen of 144x256 pixels(mode 2) and the sprites would be 12x24 pixels, four of them. Double buffered. Would this be possible, what BBC model would be the best, at least a 128k one no? Is the cpu able to manage these sprites?

Which books would you recommend to start coding for this machine, I already have experience with 6502 assembly, so perhaps more about the video chip, memory handling, disk operation....

For example I was looking how to change the video mode using machine code but couldn't find how to do it.

BTW I am using Swift(great stuff) along with Ophis... Any suggestions on other tools essential in your opinion to my aim?

I think is is all for now...

Thanks

Welcome


That's 36k just for the screens, so not going to work on a 32k Model B - a Master 128 might be possible (no idea how you'd go about it, though!). Might be easier to do without the double buffering...



My game, Mixed Grill March, has two 16 x 24 sprites plotted every frame (at the full 50Hz), plus a load of other animation going on, and still has a bit of spare time left, so that should be do-able.

The CPU can't help you with anything graphics-wise. You've got to manually plot everything to screen memory



If you're familiar with 6502, that's half the battle. I'd look into how the screen memory works next and experiment with plotting something. The BBC advanced user guide is pretty good.


This is really simple, just a few lines - copying from the sample code on the site (the BBC manual will tell you what address OSWRCH is):


Good luck! It's quite hard work, but worthwhile when you get something up and running...

Thank you so much for this.

I will now be playing with this stuff and see what I come up with and then check the options. My project might be a bit ambitious for a first try but who knows...

You will be able to double-buffer that mode on a Master 128. The Master gives two memory banks at $3000-$7fff, the usual screen addresses on the Beeb. You can select the banks for CPU and video accesses separately.

The B+ also gives you two banks, but CPU and video access are tied together, so you can't access the alternate buffer without also displaying it. It's an uncommon machine though, so I wouldn't bother with it.

If you want to run on a standard 32k machine then you'll need to drop the double buffer. As Jools said, your sprite requirements should be doable, though you might have to play with the timing a bit.

Screen memory layout is essentially the same as the C64's bitmap mode.

Think you for your input Tomw.

I am checking the options, and it seems to me that the 32k machine would be too tight for this. As I would have only ~14K free for code, gfx and music...

If you can get away with only 4 colours in the game, you can drop screen usage down to 10K at 160 x 256 (8K if you're prepared to loose some sideways resolution).

There are some tricks to perform palette switching so it looks like they're more than 4 colours.

Isn't there a way to configure the display to have a width of 144 pixels? saving some ram thus?

In mode 2 (16 colours) :



In mode 5 (4 colours) :



This only saves 512 bytes in mode 2, and 256 bytes in mode 5.

Thank you TomW, this is nice, although I must confess I thought I would save a bit more mem. I Presume that in the same way we can have a wider display than the normal 160 pixels too?

Can we have a display wither than the 160 pixels on mode 2? On the Ams CPC is possible so I am asking, I would need 42 chars across if possible.

Yeah, use the above but adjust the values (and also move the video start address).

In mode 2 (start at $2c00) :



In mode 5 (start at $5600) :

Thank you so much Tom

On the Electron changing the screen size is not possible I presume? I have been checking the advanced guide(where I could only find that we can change the screen address in 64 byte steps or something but no other info but I browsed it quite quickly so I might have missed something important about this) and on the net, I read somewhere that it doesn't have the 6845 CRTC. Is this correct? Ta.

The BBC game is coming along(Swift if awesome), nothing to show yet but soon perhaps, and I have started to think about Electron and Atom versions of the game too. If I could reduce the Electron screen to 32x24 chars it would be great, if not well, I would have to work with what there is available.

The Atom, I have found very little info, I only have the Atomic Theory book. It is a quite interesting little machine.

The Electron indeed does not have a 6845 CRTC. The ULA has a fixed screen size and hardware scrolling is in useless 64 byte steps. Plus it's only 1 MHz in modes 4-6 and ~600 kHz in modes 0-3.

Thanks Tom, I am somewhat shocked in knowing that the Electron runs at 600khz on modes 0-3..... This makes things more difficult and I didn't want to use expansions. So the Electron version of the game would go more on par with the Atom's one than the bbc's.

Uff real life got in the way but I haven't forgotten about my BBC/Acorn projects.

Can someone tell me how many cycles are there per frame on the BBC micro?

Can over scan screens be double buffered(24kb)?

Usually the display runs at 50Hz so each frame is 20mS. For a normal mode 2, each scanline is 64uS and I think there are 312 lines. See page 360 of the Advanced User Guide for more details.


I assume you're using a Master 128, in which case the machine will only page in 20KB (between 0x3000 and 0x7fff) when you switch between the normal and shadow screen banks.

The way the screen-wrap around works prevents using memory above 0x8000.

You could use the vertical rupture technique (described in the sample code section) to page in two different 4KB blocks from below 0x3000. However, you may end up having to waste some memory if the join between the 4KB and 20KB doesn't happen at the end of a line.

If this is the case, you could try using more than one rupture - depending on your screen dimensions, this could recover some of the wasted memory at the expense of a more complicated screen memory layout.

You can set the screen start address to 0x2000 easily, but for the shadow bank the first 4k will be in one of the OS private areas; I think 0xd000-0xdfff.

Thank you Robc and TomW.

That's the idea I had about the shadow bank: 20k.