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 12.63KB 19 downloads
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?