I've been playing around with custom video modes this weekend:

I've found the well documented 'Mode 8' set up for 80x256:

But what I really want is 160 x 128 so I get square pixels - can anybody suggest what I have to do to get that? The memory savings would really be useful!

How about non-integer scalings like 256x192 - but I don't want letter-boxing - I want the pixels to fill the screen (SNES style)?


- PJ

The Beeb has no vertical line doubling, so 160x128 would be massively letterboxed and not even remotely square.


This isn't possible either - the Beeb's pixel clocks are fairly fixed (16, 8, 4, and 2 MHz) so any custom modes like this will have fairly large vertical & horizontal borders.

If you want the smaller modes and are happy to put up with letterboxing, then you need to talk to the CRTC. The two important registers are R1 (horizontal displayed, in bytes per line - default is 80 in modes 0-3 and 40 in modes 4-7), and R6 (vertical displayed, in character lines - 32 in modes 0-6, 25 in mode 7). R2 and R7 are also important, as they control display position.

The basic code, to set up a 256x192 screen (assuming mode 1), is


You will need to have interrupts disabled while doing this.

Unfortunately you can't do what you want to do on a Beeb. The pixels are a fixed size, due to the fixed clock frequencies of the video hardware. It's possible to stretch the screen vertically on some VDUs, by simply reducing the number of lines in the PAL frame, e.g.

to give a 200 line screen which more or less fills the vertical space... but this won't work on all VDUs and will just result in an unsynched rolling display.

But a 256x192 screen is possible, only with a large-ish border. Many of the Ultimate games do this, e.g. Lunar Jetman, Knight Lore, Alien 8. Presumably to get the screen dimensions the same as the Speccy!

Both the previous replies are bang on the money. The Beeb has flexible (up to a point) display hardware, but there are still some severe limitations.

The routines I have used here as my examples exactly duplicate the example given, just in a slightly different format.


The code I use to generate a mono display of 256 * 192, 6144 byte display. (In BeebASM assembler syntax). Could be changed to 'mode 1' to approximate some Spectrum games with a little bit of jiggery pokery. The CRTC registers are massaged to centre the display on the screen, meaning you have now got a wide distracting border around your picture. (Well, it's not that bad really).



Here's a 'widescreen' low res four colour setup for a stalled project of mine. Reducing the screen resolution by so much meant I could have two screen buffers in a 32k Beeb. It initially used a line doubling routine to make the pixels square. (included). Not ideal or optimised, as I would draw the pixels on the odd lines then call the doubler routine. Very slow, as even the un-changed areas on screen are copied.

You will find it quicker for your routines to store the pixel data in consecutive screen addresses when plotting.

Either of these solutions is about the only way you will get a square display in the wide pixel modes with the Beeb hardware.

Unfortunately, this looks severely letterboxed, which is what I was aiming at, but may annoy some!



Up to you to furnish the plotting routines, otherwise you will just have blank black screens which do not help to demonstrate success. Also, you have to alter HIMEM and other system values if working in BASIC... or if your code tanks and the error message is displayed via the OS it will of course 'write' it on screen at TAB(0,0), start address of the originally selected donor mode... Demonstrated by repeated pressing of the <return> key until the screen 'wraparound' occurs and the message is displayed - depending on the number of lines you have taken off the display, you won't see the prompt appear until you have hit the <return> this number of times, very frustrating when the program has found itself in another near infinite loop and you don't get the prompt to appear after a hundred presses :o| (Can be fixed with handy pokes).

Thanks tons for all the examples - that's a great help to hopefully save myself some memory.

Too bad about the scale thing - I guess that's why I've never seen it in an existing game - I think Boffin had a interesting Mode1 variation where it actually had more than 320 pixels across - never saw that in another game...

- PJ

Is there a way to do 200 (high - instead of 256) x 160 (wide) in 8/16 Colours ? and where would it be located in memory ? (same place with 4k free at the end, or 4k higher up in memory ? )

I don't mind if its a little letterboxed... Rich says something about VDU displays rolling at 200 lines though above....

Doing this, I might be able to save some memory (4k) if I get back on track with my Aquarius game in the future. (Use a 16K screen instead of 20K screen and would be the same as the c64 resolution then)

Thanks, Colin

Easy! The below will shrink the screen to 200 lines, and put display start at $4000. This is assuming mode 0/1/2, if you want mode 4/5 then change the last LDA to #0c to put display start at $6000.

Thanks Tom.... That seems to work, mostly, I will have to adjust (suss out !!) my video memory offset now, but it's looking good.... Thanks for the 4K

Right hand side shows the old 20K screen, Left is the 16K and Origonal Games Screen Resolution which now matches the C64... (with a bit of an offset !!)

Right... sussed the Background, next the sprites....

I've added a screen clear too, but used an index for the value, so I can see the screen data area.... hence the 'garbage'

So. Looks spot on now...

Looks promising!

Did you ever finish the C64 version?

Hello Chaps,

So, if I want a 192 x 256 screen in mode 1 I can do this ;-



But how do I know where screen memory starts and how do I centre it on the screen ?

Think you mean

Though line 50 is a bit redundant in this case.

Screen memory starts exactly where it did before - &3000 - as you haven't moved it. CRTC regs 12 and 13 do that, you need to load them like :

Screen position is determined by the sync position registers - 2 for horizontal, 7 for vertical. To centre a 192x256 4 colour screen you need :

It's probably best not to do CRTC programming in BASIC incidentally, but in assembler with interrupts disabled.