OK so I did some digging into the schematics.
Posted relevant parts of schematics here [1]
Yeah it totally jibes with what you said above.
The rasterizer outputs what looks to be 10 bits of horizontal position (for the pixel being written I'm assuming). Since screen is only 256 pixels wide, this would imply that there are fractional horizontal bits here. The rasterizer keeps track of fractional bits to compute sloping (jaggies)... so the fractional bit implies the pixel being written fills up more than 1/2 of the next pixel.
Video memory is 7-bits per pixel. 6 bits are for 64 color palette index. The fractional 1/2 pixel bit (after some AND/OR/XORing) is stored as the 7th bit of the pixel. Indicates its a "wide" pixel.
Later, when video memory is being read/scanned to the monitor, the buffer holding the 6-bit color to output is sometimes latched a half clock cycle later. The half clock cycle delay is the 7th bit stored in the video memory, the 1/2 bit.
So yeah.. you're essentially delaying the latching of the next color if the pixel is "wider". It makes sense to think of the additional bit as a width bit.
This is a crazy way of doubling resolution... instead of needing double the screen buffer memory, you add 1 bit to indicate the pixel is wider. The caveat is you really don't have true double resolution, you can't have a single pixel at half resolution. You only get pixels of normal width, or 1.5 pixel width. Still that's amazing!
It should be possible to see this artifacting on a real game. Since the alphanumerics overlay is scanned at normal pixel size, if there is a half pixel in the bitmap, the overlay should sometimes not appear aligned to the background. Paul, you might be able to see this on your machine. If you play around in doodle city, you can move polygons where they're behind the alpha overlay, slight movements might show the half pixel in relation to the overlay.
>> The caveat is you really don't have true double resolution...
And only on the right side of a polygon. If video RAM is cleared to 0-black, there would be no "wide" background pixels, only wide polygon pixels and they're extended to the right only.
I will look at Doodle City and try to move things under the text overlay.
Also, what is that big chip in the linked schematic doing? HPOS6-15? PADD0-PADD10. It has a 5MHz clock (the dot clock) but that FF has a different clock which might be 10MHz?
The big chip (ICY) is the custom rasterizer ASIC. Basically a very primitive GPU, maybe the first? I don't know the internals (I'm told they're floating around) but I know what it does.
Yes that chip has a different clock, as its writing pixels to the frame buffer. The monitor always displays the other buffer not being written to, so the rasterizer does not need to be sync'd to the monitor pixel clock (which has overscan areas etc.), therefore the rasterizer can fill pixels at a different speed. My guess is that they couldn't run the ICY faster than the 5MHz, because I'm sure they wanted to run it as fast as possible!
Essentially the chip takes the display list, which is a bunch of instructions for DOTs / VECTORs / POLYGONs, and draws them to the frame buffer pixel by pixel. Starts at the top of the display list (address zero), goes instruction by instruction filling pixels until list end is reached. Note the START and HALT signals coming from the main 6809 CPU telling the chip there is work to do. When you "HIT A BLACK HOLE" everything is halted and the CPU tries to recover things.
Commands generally look like this (this is a major oversimplification so don't take this as 1:1 with the real hardware)
CMD_TYPE COLOR XLEFT XRIGHT YTOP SLOPELEFT SLOPERIGHT NUMSCANLINES
Where CMD_TYPE is [dot/vector/polygon], COLOR is the palette index, and coordinates are in 16-bit with fixed precision slopes.
The chip fills pixels from left poly edge to right edge, when it reaches the end it adjusts the left/right edges and adds 1 to the scanline, eventually stopping when all scanlines are drawn.
As I said I know the internals are floating around, and I know of at least 1 project attempting to duplicate the ICY on a daughterboard. ICYs are 40 years old and are starting to die and there is no replacement.
Yeah it totally jibes with what you said above.
The rasterizer outputs what looks to be 10 bits of horizontal position (for the pixel being written I'm assuming). Since screen is only 256 pixels wide, this would imply that there are fractional horizontal bits here. The rasterizer keeps track of fractional bits to compute sloping (jaggies)... so the fractional bit implies the pixel being written fills up more than 1/2 of the next pixel.
Video memory is 7-bits per pixel. 6 bits are for 64 color palette index. The fractional 1/2 pixel bit (after some AND/OR/XORing) is stored as the 7th bit of the pixel. Indicates its a "wide" pixel.
Later, when video memory is being read/scanned to the monitor, the buffer holding the 6-bit color to output is sometimes latched a half clock cycle later. The half clock cycle delay is the 7th bit stored in the video memory, the 1/2 bit.
So yeah.. you're essentially delaying the latching of the next color if the pixel is "wider". It makes sense to think of the additional bit as a width bit. This is a crazy way of doubling resolution... instead of needing double the screen buffer memory, you add 1 bit to indicate the pixel is wider. The caveat is you really don't have true double resolution, you can't have a single pixel at half resolution. You only get pixels of normal width, or 1.5 pixel width. Still that's amazing!
It should be possible to see this artifacting on a real game. Since the alphanumerics overlay is scanned at normal pixel size, if there is a half pixel in the bitmap, the overlay should sometimes not appear aligned to the background. Paul, you might be able to see this on your machine. If you play around in doodle city, you can move polygons where they're behind the alpha overlay, slight movements might show the half pixel in relation to the overlay.
[1] https://imgur.com/a/FFVxjQg