I'm thinking of writing a version of Rally-X for the BBC.

Here is a proof of concept, it will only work on BEm, I have fudged a few bits and not set up timers to blank the top and bottom of the screen, so you will see extra bits at the top and bottom. I plan to put the radar etc at the bottom, as putting it at the side isn't practical on a BBC (except, I have just had an idea how to do it!).

I have only spent about 8 hours on it so far (mostly ripping out Carnivale) and would like some feedback about whether people would like to see it or maybe suggest something else.

There is an initial scroll, then the cursor keys can be used to scroll around.

It looks good so far. I don't know if it helps, but the maze scenery can be solid colour tiles apart from the edges. At the edge of the playing field there are decorated tiles, of course.

That looks like a good start, I'm not familiar with Rally-x so I looked it up on youtube. Is there anything like it already on the beeb? If not then I'd definitely go ahead with it.

This could actually be a good starting point for a conversion of one of my favourite games on the C64 - Paradroid.

I have made quite a few compromises to get the performance and memory that I think I will need to run in mode 1 with 2 pixel scrolling at 50Hz (thanks RichTW).

I was planning on not having the border "trees", but having the players car move from the centre to the edge of the screen when there was no more "map" to scroll.

I may find more time and more memory when I get closer to finishing, but things will be extremely tight (take a look at RichTech) to maintain mode 1, 2 pixel scrolling at 50Hz.

I don't remember anything like Rally-X on the beeb (same reason I tried Carnival).

RichTech (if it is ever released) could be more what you are looking for. To get the mode 1, 2 pixel scrolling, you need 50 Hz and that game looks like it might just have too much going on, although it does seem to only use half of the screen, so it might be OK.

Never seen this game at the arcade (or Mame - though I probably have it).. nor seen it as a clone on home micros.

My thought is it is a good candidate for this reason and also - importantly! - looks like it would be fun to play.

And blimey! You don't hang around Nice work so far.

Your scrolling looks really smooth.

I think the closest we got was perhaps some type-ins. Seem to recall one in the EU which maybe didn't even work on the Beeb.


If it's something you feel like pursuing then you should go for it!

I think Road Runner is probably the closest thing to a BBC Rally-X, though it's only two-way scrolling.

OK, getting the timing right for vertical rupture is as hard as I remember it! and having to get the horizontal half character working is also a pain!

This demo only "works" on B-Em as BeebEm (doesn't seem to implement it) and JSBeeb (seems to try to scale the screen) don't seem to have the half pixel sideways scroll working properly.

The dash at the bottom is only a mock up, I am thinking of mode swapping to mode 2 as that will make things much more colourful - I could maybe do the whole game in mode 2 if someone made some cars that looked OK on it

EDIT: tweaked the colours / map

Use the cursor keys to move around - it stops at the edge of the map.

Some how, I have broken the map drawing a bit getting the mode working, probably got a carry gone wild!

EDIT: new .ssd with new dash

If anyone can try it on a real beeb, please let me know if it looks correct.
If not, a photo would help.

Just had a try on B-Em.

The scrolling is wonderful!

Don't have a real Beeb to hand at the moment though unfortunately!

Fixed that map drawing bug, but spotted another one - but I can't reproduce it.

If anyone can, please post a screenshot and a short description, preferably not "I was just scrolling around"
Slight update to dash

For those that like stat's, or are curious as to how I plan to draw all the sprites necessary, doing the vertical scroll takes between 24 and 28 scan lines, while the horizontal is 20 half the time and 44 the other.
So, I have about 60 scan lines before the top of the map, if I sort the sprites I hope to race the raster beam and get all the sprites drawn before it catches me.
If I get tight, I will skip updating the radar on the expensive horizontal frames (you will never notice ).
I should probably write and time a sprite drawing routine to see how long it will take
Memory, well, it is already looking tight!
16KB for the screen (shame only 13 of it is visible!)
2.5KB for the dash (not including drawing it)
1KB per map (I think there were eight in the original)
2KB code to draw map, read kbd and control scrolling

On my Beeb, up-down scrolliing is very smooth. Left-right scrolling shows a little bit of jerkyness in comparison.

Also the bottom of the display is off the bottom of the screen and there's a large area of black space at the top of the screen. Almost as if you've done a *TV255 or similar.

Thanks sweh.
I was afraid of something like that. This is the first time I have tried the half char horizontal scroll and wondered if I had misses something.
The vertical timing is also very sensattive on the emulators, so I was worried it might not work on real hardware. The top eight scan lines are blank, but the other 31 character rows should have been OK.

EDIT: The horizontal is likely monitor/TV specific, so it might still be "correct" code.

This one should have solid timing, but is probably still off the bottom of the screen.
The emulators are a bit too generous on vsync timing, so I probably need a datacentre or another mmc for my spare beeb.

I didn't really spot any difference between the two.

FWIW, my Beeb is connected via a DVS204 to an oldish 19" LED monitor. It's possible this combination is causing judder. However when I scroll up and down I can follow the individual blocks and it looks smooth, the blocks remain distinct. But if I scroll left-right then the blocks merge into each other.

And, yes, it's still off the bottom of the screen

I managed to find my spare beeb and hook it up to a video capture card.
It looks like for it to work on my video capture card, I need to reduce the h-sync from 8 to 2 - at least on the composite output (the demo goes from 8 to 9).
This brings back memories of the 80's, which I had forgotten about and even denied!

I should try to explain what I was trying to do and why it is significant on the beeb.

The significance of getting this working, is that it allows very smooth horizontal hardware scrolling, desirable for many games.

The "tricky" part of this demo is to achieve hardware horizontal scrolling at a finer resolution than the hardware can do - sounds impossible - that was what I concluded in the 80s; but apparently someone has it working on a 8bit micro with the same video chip as the beeb.

The Idea is to draw the screen for one frame, then adjust the sync pulse width, which tricks the TV into shifting the whole image over 2 mode 1 pixels for the next frame, then shift it back and do a hardware scroll of 4 mode 1 pixels in the third frame, giving the illusion of 2 pixel scrolling. (Well, if you clear and re-draw the sides each frame, it works and that is what I do here).

OK, took a while, but now I have both of my beebs set up, no disks yet, so can only really use 1 (the one with an mmc) and I can only display them on one cheap old LCD TV (RF or Composite) and one TV Capture card (Composite 25fps).

On the TV composite sync width makes no difference until the picture disappears.
On the TV RF, I can get some success, but the TV is very sensitive and easily changes colour / brightness / breaks up.

On the Capture card, I can get just the right amount of adjustment and it looks like it might be working quite well, but it is a little hard to judge as it captures at 25Hz. There are minor artefacts as the top few scan lines of the 1UP 2UP row spring back a little, blurring them - I have a cunning plan to minimise that, but won't bother doing any more investigation unless I can expect a better proportion of compatibility.

[flash=]WARNING[/flash] Please read the warning at the bottom before using this test on real hardware [flash=]WARNING[/flash]

The image attached has been modified to allow dynamic adjustment of the horizontal sync pulse widths for "left", "right" and to a small degree the position of the dashboard.

The keys are QWERTYU to adjust the position when displaying an image that needs to be shifted left (U is default, Y works for B-Em, the closer to Q, the more exotic the sync pulse width).
The next row ASDFGHJ adjust the position for the other frames that need to be shifted right (A is default and works for B-Em).
The bottom row ZXCVBNM adjusts the position of the dashboard but on my TV only makes a tiny difference - see my next comment (V is default).

I would suggest starting with B-Em, to see what happens. It shifts by two mode 1 pixels per change, where as my TV seem to be non-linear with nearly no shifting around the default UAV.

[flash=]WARNING[/flash] I don't know if there can be any damage to video equipment from this technique (I suspect not for small changes). Perhaps a more electronically competent person could tell us. [flash=]WARNING[/flash]
EDIT: I don't believe this will harm analogue equipment and digital will probably ignore it.

Top row didn't seem to make any difference.
Middle row appeared to move by 1 pixel max... until I pressed H and lost sync.
Bottom row moved the dashboard by 1 pixel... I noticed the letters (eg in '1 Up") were slightly slanted at some settings. "D" and "N" appeared to give best straight lines.

(Some of this might have been the DVS204 correcting the Hsync timings).

I'm not at my been, but one of the top/middle rows moves the odd scrolled frames and the other row the even scrolled frames, so you need to move thee map sideways to see the effects of the sync widths.
I wrote this and I kept on getting confused.

The hope is that between the two adjustments they total two pixels..

You are probably doing right and it just won't work on your setup.

Thanks for a all the effort.

I guesss i will have to try a different game ... 1942 maybe