3 ms·

You know reading this caused some forgotten neuron in my brain to fire. When I was reverse engineering the thing, I seem to remember there being a bit related

You know reading this caused some forgotten neuron in my brain to fire. When I was reverse engineering the thing, I seem to remember there being a bit related to color/shading that I couldn't figure out what it did (I could see that it was being used). The system had a 64 color palette. The software broke that up into 8 sub-palettes to give you for 8 main colors with 8 shades each (0-7 first color, 8-15 second color, etc.) Polygons could call out colors directly using full palette index. Most polygons "faked" shading, they really just specified different shades of the same color for effect. For example, the dodecahedron / meteors in the space waves aren't real-time shaded, just colored to look that way. However the hardware could do shading, which cost an expensive dot product. So it was used sparingly. To do shading, the polygon used a 3 bit color "index" to call out one of the 8 sub-pallets. Then you add an offset of 0-7 based on the dot product of the normal vector to apply shading (I used 8 x dot product to get you an offset from 0 to 7.9999). I recall there being an extra bit there (4 bits instead of 3) but couldn't figure out what that last bit was for (it seemed like a "1/2 bit" to me). It looked like it was being used, but didn't make sense, so I stripped it off, and it didn't seem to affect anything so I forgot about it... till now. If I'm remembering correctly, this might literally be a "1/2 step" to add between shades? That can't be right can it? Another way I read what you wrote is that it could be considered an "anti-aliasing" bit to do some alpha blending at the edge of a polygon to fake higher resolution? Maybe that's a better way to read it? My memory is probably not 100% here... Would love to hear more.

tasty_freeze 4y ago
I don't think it was for antialiasing (to interpolate between shades at adjacent pixels), it affected the horizontal timing. I don't recall the actual resolution, but say it was 256 pixels per scan line. If the color for pixel 100 was index 5 and for pixel 101 it was index 3, the straight forward way would be to send the right RGB phase for whatever index color was throughout the interval pixel 100 and then send the right RGB phase for whatever was the right color for pixel 101. The half bit modified the timing to delay the transition from pixel 100 to pixel 101, somewhat doubling the horizontal resolution. It made polygon edges less chunky. Or another way to conceptualize it: each row had 512 pixels, but memory for only 256 pixels. By default each memory location would be used to fill in the color for pixels X and X+1. But the half bit would modify it to say whether the transition should be shifted out one more pixel. If the transition was from red to blue, the default way would be to generate four pixels out (R, R, B, B), but if the half bit was set, the video generator would output (R, R, R, B).
- lordfrito 4y ago
  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. [1] https://imgur.com/a/FFVxjQg https://imgur.com/a/FFVxjQg
  - phkahler 4y ago
    >> 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?

tasty_freeze 4y ago

I don't think it was for antialiasing (to interpolate between shades at adjacent pixels), it affected the horizontal timing. I don't recall the actual resolution, but say it was 256 pixels per scan line. If the color for pixel 100 was index 5 and for pixel 101 it was index 3, the straight forward way would be to send the right RGB phase for whatever index color was throughout the interval pixel 100 and then send the right RGB phase for whatever was the right color for pixel 101. The half bit modified the timing to delay the transition from pixel 100 to pixel 101, somewhat doubling the horizontal resolution. It made polygon edges less chunky. Or another way to conceptualize it: each row had 512 pixels, but memory for only 256 pixels. By default each memory location would be used to fill in the color for pixels X and X+1. But the half bit would modify it to say whether the transition should be shifted out one more pixel. If the transition was from red to blue, the default way would be to generate four pixels out (R, R, B, B), but if the half bit was set, the video generator would output (R, R, R, B).

lordfrito 4y ago
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. [1] https://imgur.com/a/FFVxjQg https://imgur.com/a/FFVxjQg
- phkahler 4y ago
  >> 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?