Channel F road test and timing question

[Kurt_Woloch]

Hi everyone! In another thread, I've posted a programming test of mine for the Channel F which basically draws a road with meadow on the left and right (stylized).

 

Meanwhile I've developed it a bit further, and now the road is animated. Still no game or sound though, and you'll have to wait about 10 seconds until the road starts moving. What I'm thinking of is some sort of 3D car racing game resembling Pole Position.

 

 

I've attached the current binary, as well as the current version of the source code which assembles in DASM.

 

game.asm

game.bin

 

As you can see, I've taken a slightly different approach to the usual Channel F games which all work by drawing tiles or sprites on screen and erasing them again. In contrast to that, I'm drawing the road line-by-line, starting at the bottom up to the horizon. What I'm planning is to draw the sprites along with the background, that is, before each pixel gets drawn, it's decided whether it belongs to a sprite or to the background.

 

The reasoning behind this is that on the Channel F, there needs to be a delay between two pixel writes, so the CPU, instead of wasting time, might as well spend the time figuring out what the next pixel will be. Right now there still is a delay loop after each pixel because drawing the road alone doesn't eat enough time.

 

The question is, how much time do we need in between writes? I tried to figure it out by the delay loops normally used, and my guess is that the system is able to write one pixel for each on-screen scanline to RAM, that is, about every 64 microseconds, or in other words, there is a "window" every 64 yS where a pixel will be written to RAM if it has been strobed by then. The question now is what's affected by the delay. I guess the delay is there so that the necessary data stays on the ports for long enough after the CPU has strobed the write. This would mean that after strobing the write, 64 yS should pass before any data on the port gets changed. Or is this not the case, and there is some data being latched so after strobing the write, you can already change the data as long as you don't strobe another write?

 

It has been written in the Veswiki that if you write the pixels too fast, gaps may occur. But how fast is too fast? And which timing counts?

 

I've just timed the drawchar routine in the BIOS which is basically used to draw everything there, and according to the MESS debugger, at least 246 cycles pass from one write to the next, while a scanline takes roughly 458 cycles, so that would be closer to two writes per scanline... if the debugger is right. However, according to the debugger, there are 4 times as many cycles needed as is given in the opcode table in the Veswiki, which is understandable to me. I guess the cycles in the MAME debugger relate to clock cycles with the clock being 2 MHz for the early PAL machine, while the opcode table refers to machine cycles being 4 times as long (otherwise there couldn't be half-cycles needed by some instructions). This would mean that actually, the 246 cycles from one write to the next would be 123 microseconds. From the strobe off to the next port write, there's a time span of 192 cycles, which would be 96 microseconds or 1.5 scanlines. The delay loop alone wastes 80 cycles or 40 microseconds. In contrast to that, my road drawing code currently spends about 218 cycles (109 microseconds) per pixel, but has the port writes as close to each other as possible so that there are still 166 cycles or 83 microseconds from releasing the strobe to the next setting of data.

 

Does anyone have any data about this?

[+atari2600land]

I don't have any idea about your questions, but I do have a comment on the game:

Nice job! Perhaps you could use the blue color and make the sky blue as opposed to it just being the same color as the road, like in Killer Heads of Lettuce. This would, probably, make the game be set at night.

[Kurt_Woloch]

Here's another iteration of my test code. I figured that it wouldn't take much more time to have the track also bend up- and downwards instead of only left and right. I've also somewhat swapped directions, so now the curves and slopes go into the same directions as on the original track, and also occur at roughly the same point, though some curves don't look as sharp as they should, while some hills are vastly exxagerated compared to the real world. Oh, there's now also some piece of sky, but this should definitely get more refined.

 

 

game.bin

 

game.asm

[Kurt_Woloch]

Here's another iteration... this time I refined the sequence of curves and slopes a bit, and the player car is now visible at the bottom of the screen.

game.asm

game.bin

Edited April 30, 2018 by Kurt_Woloch

[carlsson]

It looks great, but is it as slow as it runs in emulation on my PC? Like one frame per second or so? I'm not expecting a power house from the F8, but I wonder if it would be playable in the end or just an exciting demo of programming techniques.

[Kurt_Woloch]

OK, I tried to squeeze out a bit of speed now, by shaving off a few pixels on the left (and adding one to the right to fill the previously visible gap). The sky drawing routine is still preliminary, so that also may take away more time than necessary for what's actually being displayed.

I've now timed the routines I have and found that I'm already taking far more than the (probably) 64 yS which the ports have to be left alone after the "strobe" before changing any output value, so I eliminated the delay loop during road drawing and shortened it during sky drawing, which should speed up things a bit.

 

Still there's not too much you can do... there needs to be this delay between writing of each pixel, and there's no way to get around that other than updating a smaller area of the screen in general. But that would take some logic to figure out what has actually been changed and what stays the same (and doesn't need to be overwritten). And this would need more complicated code, and also more RAM. Right now, I'm only operating on the 64 registers built into the CPU because the stock Channel F doesn't have more readable RAM than that. This means only storing what's absolutely necessary. For instance, the displacement value of each row (which makes up the curving of the road) is only calculated for this row and then discarded once the row has been drawn. But this doesn't matter as long as I'm overwriting the graphics with the next frame anyway.

 

The slowness also comes from the fact that on the Channel F you have to write the screen pixel per pixel, and you don't have hardware sprites. On other 8-bit computers and consoles with games like this, typically some trickery is being done like simply manipulating the display list for each scanline so that the graphics don't have to be written to a bitmap, and the road objects are displayed by hardware sprites, at least some of them. Thus you can find a pretty fast version of Pole Position on the C-64 (but the curving of the road doesn't look pretty there) and the Atari 800. Even better is "Street Surfer" by Mastertronic on the C-64, which to me seems to have the fastest road drawing code which still gives a reasonable 3D impression. On the other hand, have you seen the TI-99 version of Pole Position by Atarisoft? Here, while the player car moves smoothly left and right, the enemy cars and center line only update at about 4 fps, and the curving of the road itself often falls down to 1 FPS as well. And on the Channel F, to update all the visible area of the screen you need at least 0.4 seconds, and there's no way around that other than only changing the pallettes of the lines. But to make up for that, you get a nice overscan picture because the Channel F's video memory covers all the area the beam can display.

 

Personally, I'm aiming at about 2 FPS. Whether the game is playable at the rate remains to be seen...

 

Anyway, here's an updated version which runs a bit faster.

game.bin

game.asm

Edited May 1, 2018 by Kurt_Woloch

[+atari2600land]

Whatever happened to this and the other guy who said he was going to program a Channel F game?

[Mikebloke]

Ramadan. It took everything out of me this year so I did zero programming. Looking into it again from next week.

 

Impressed by what Kurt has done though, I'm in awe at what they achieved in so little time.

[Kurt_Woloch]

Whatever happened to this and the other guy who said he was going to program a Channel F game?

Well, I considered how to go on with this. From Carlsson's comment about the framerate, it's clear that the framerate it currently runs at is a bit slow for a racing game, so I considered what to do with it, or if it really makes sense to go on with it. One solution might be to revert back to the version that only has a flat road, guaranteeing that the road doesn't stretch into the upper half of the screen, slowing down the drawing of the street even more. Then there was even more to come, like enemy cars on the road and scrolling mountains in the background... for which I was considering how to do them and how to encode them in ROM. I took a look at how the original track in the configuration I used looks like... basically, the closest thing I could find is this:

 

 

The road curving and rising/lowering data is already taken from there, so that the road goes left, right, up and down at roughly the same points, but the amount by which it does so isn't consistent with the original track, especially the up/down movement looks greatly exxagerated. And then there's the question what to do with the mountain background... the way it presents itself in the video, it could go up very high at times.`And, as I said, the question is how to encode this in a meaningful way while still getting a good framerate. I compared this with what Namco did when they designed the arcade game "Pole Position"... it's also based on this track configuration, but they clearly made some compromises, for instance the first right curve is not nearly as sharp as the hairpin curve later on, while it seems to be as sharp on the original track. Also, of course, they didn't do any up/down movement. And there are no visible trees at all. Also, the scrolling background doesn't actually look too much like the original... it doesn't even properly wrap around so if you've completed a round, you're looking at a different point in the background than when you started!

 

Finally I decided that in order to achieve a decent framerate, the code would have to be redesigned so that not all of the road has to be redrawn in each frame, but that would make it much more complicated, and it's the question if this is doable with only 64 bytes of RAM (the F8's registers).

 

Anyway, the last posting was done on May 1th, and after that I decided that if it's that difficult to achieve a better framerate, there are probably more important projects to follow that I had. The weather also got warmer, so I can do more things outside now, like going swimming with my father, who is now alone after he lost his wife. Keep in mind that between each iteration I posted here, there were still 2 to 4 hours of coding going on on my part. And I did this basically as a bit of relief after all the work was done concerning the death of my mother on March 10th... but, alas, I couldn't sustain it.

 

Sorry...

[e5frog]

Missed this one, now following Kurt... 

 

I had the same idea after seeing Antarctic Adventure for the NES, thinking it might be possible on the Channel F. 

What if you just draw lines and not solid green areas. 

 

If you want something to work on all consoles the Luxor V.E.S. sets the limit, it runs at 2MHz and shuffles code faster than the other machines, if delay is long enough for it it will work on the other machines as well. 

 

No need to limit yourself to the registers, you have configured RAM (unfortunately) in MESS/MAME $2800-$2FFF, adding RAM on a real cartridge "anywhere" is also possible. 
Of course it would be impressive to keep to the common specs, I'm impressed with what atari2600land has made. 

[e5frog]

This "Drag files here to attach" works, most of the times. 
If you have written a bunch of text, drop a file and it instead of getting attached - the browser opens the image file... and you try to use the "back" button... and see your text is gone. That's annoying.
 

It's possible to plot en entire screen in about 1.2s, so 2500 pixels in 0.5s, a pixel plot cycle in multiblit is 24 cycles, that's from the added delay start until you're back on the delay start routine. 

 

Perhaps going for just dots would save some resources, if you could draw just two pixels on each side, not that it would look as nice. 

Here's the image I tried posting.  

Lines over track could scroll to make it feel more like moving (max two pixel plots in palette column(s)).

 

 

Edited August 4, 2019 by e5frog