5 ms·

I used to work with the guy who designed the hardware, Dave Sherman. Man, he had a lot of insider stories about the glory days of Atari! Anyway, there was no d

I used to work with the guy who designed the hardware, Dave Sherman. Man, he had a lot of insider stories about the glory days of Atari! Anyway, there was no depth buffer. As I recall, the geometry was all pre-split in a way such that occlusion could be handled by sorting at the polygon level instead of the pixel level. I also seem to recall the native screen resolution was 256x240, but they used one extra bit per pixel that could be used to stretch a given pixel by 1/2 a pixel resolution, effectively giving 512x240. There were situations where the trick didn't work, but 98% of the time it worked well.

phkahler 7y ago
>> they used one extra bit per pixel that could be used to stretch a given pixel by 1/2 a pixel resolution, effectively giving 512x240 While reading about the reverse engineering by emulator authors. There was an extra bit in the frame buffer that no one seemed to find the use for. That should be reasonably easy to verify from schematics given a heads up. That may also explain why some of the YouTube videos look so bad around the edges compared to the real thing. They are probably recorded from MAME and dont account for that bit if that's really what it does. It also seems like that could only effect the right edges of polygons. There are 2 frame buffers and I believe one is used for scan out and the other is only written to, then they swap roles. So no z-buffer and no reading back pixels.
- MrBuddyCasino 7y ago
  Huh. Seems MAME is using just 265 pixel: https://github.com/mamedev/mame/blob/master/src/mame/drivers/irobot.cpp#L301 https://github.com/mamedev/mame/blob/master/src/mame/drivers...
  - MrBuddyCasino 7y ago
    Made an issue on the MAME tracker: https://github.com/mamedev/mame/issues/6571 https://github.com/mamedev/mame/issues/6571
    - tasty_freeze 7y ago
      I just noticed there were replies to my comment. I did a quick search and found this: http://atarihq.com/danb/IRobot/Video%20hardware%20info.txt http://atarihq.com/danb/IRobot/Video%20hardware%20info.txt It has a bit more detail about the pixel format. Unlike what I said, it was 6b color index and one bit for video timing (what I was calling 1/2 pixel stretch). In essence it conveys whether the right edge of a given scanline is best represented by a transition in the middle of a pixel. That works great for most cases, but would not work well when edges from two different triangles intersection (if they weren't actually sharing the exact same edge, if you know what I mean). This site has schemtics: http://www.ionpool.net/arcade/irobot/manuals.html http://www.ionpool.net/arcade/irobot/manuals.html Page 17 shows the 7th bit, called "RAWHALF", which gets buffered to become "PXSPLIT", and that signal is used to fiddle the clock which is sampling the raw pixel index. I didn't dig enough to know exactly what this means, but that is the place to look.

phkahler 7y ago

>> they used one extra bit per pixel that could be used to stretch a given pixel by 1/2 a pixel resolution, effectively giving 512x240 While reading about the reverse engineering by emulator authors. There was an extra bit in the frame buffer that no one seemed to find the use for. That should be reasonably easy to verify from schematics given a heads up. That may also explain why some of the YouTube videos look so bad around the edges compared to the real thing. They are probably recorded from MAME and dont account for that bit if that's really what it does. It also seems like that could only effect the right edges of polygons. There are 2 frame buffers and I believe one is used for scan out and the other is only written to, then they swap roles. So no z-buffer and no reading back pixels.

MrBuddyCasino 7y ago
Huh. Seems MAME is using just 265 pixel: https://github.com/mamedev/mame/blob/master/src/mame/drivers/irobot.cpp#L301 https://github.com/mamedev/mame/blob/master/src/mame/drivers...
- MrBuddyCasino 7y ago
  Made an issue on the MAME tracker: https://github.com/mamedev/mame/issues/6571 https://github.com/mamedev/mame/issues/6571
  - tasty_freeze 7y ago
    I just noticed there were replies to my comment. I did a quick search and found this: http://atarihq.com/danb/IRobot/Video%20hardware%20info.txt http://atarihq.com/danb/IRobot/Video%20hardware%20info.txt It has a bit more detail about the pixel format. Unlike what I said, it was 6b color index and one bit for video timing (what I was calling 1/2 pixel stretch). In essence it conveys whether the right edge of a given scanline is best represented by a transition in the middle of a pixel. That works great for most cases, but would not work well when edges from two different triangles intersection (if they weren't actually sharing the exact same edge, if you know what I mean). This site has schemtics: http://www.ionpool.net/arcade/irobot/manuals.html http://www.ionpool.net/arcade/irobot/manuals.html Page 17 shows the 7th bit, called "RAWHALF", which gets buffered to become "PXSPLIT", and that signal is used to fiddle the clock which is sampling the raw pixel index. I didn't dig enough to know exactly what this means, but that is the place to look.