Jump to content


Channel F road test and timing question

7 replies to this topic

#1 Kurt_Woloch OFFLINE  



  • 1,303 posts

Posted Fri Apr 27, 2018 11:01 AM

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.


Attached File  game.asm   12.63KB   18 downloads

Attached File  game.bin   2KB   14 downloads


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?

#2 atari2600land OFFLINE  


    Channel F Viewer

  • 11,210 posts
  • Location:Salem, Oregon

Posted Fri Apr 27, 2018 3:31 PM

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.

#3 Kurt_Woloch OFFLINE  



  • Topic Starter
  • 1,303 posts

Posted Sun Apr 29, 2018 2:38 PM

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.




Attached File  game.bin   2KB   11 downloads


Attached File  game.asm   19.92KB   9 downloads

#4 Kurt_Woloch OFFLINE  



  • Topic Starter
  • 1,303 posts

Posted Mon Apr 30, 2018 2:25 PM

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.

Attached Thumbnails

  • 0031.png

Attached Files

Edited by Kurt_Woloch, Mon Apr 30, 2018 2:26 PM.

#5 carlsson OFFLINE  


    Metagalactic Mule

  • 6,796 posts
  • Location:Västerås, Sweden

Posted Mon Apr 30, 2018 3:57 PM

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.

#6 Kurt_Woloch OFFLINE  



  • Topic Starter
  • 1,303 posts

Posted Tue May 1, 2018 1:33 AM

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. ;-)

Attached Files

Edited by Kurt_Woloch, Tue May 1, 2018 1:34 AM.

#7 atari2600land OFFLINE  


    Channel F Viewer

  • 11,210 posts
  • Location:Salem, Oregon

Posted Thu Jun 14, 2018 4:51 AM

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

#8 Mikebloke OFFLINE  


    Space Invader

  • 14 posts

Posted Today, 2:10 AM

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.

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users