About a month ago, Hackaday had an article about some really old arcade hardware. One of the earliest microprocessor-based ones, with clear heritage from the older digital-logic-only boards that preceded it.
In the intervening time I've been stupidly obsessed with it, because it's so familiar and yet so alien:
* One of the first 6502-based arcade machines (late 1976) (←edit)
* A sprite system similar to the C64's
* A dual-ported video memory system similar to the VIC-20 and C64
* Predating the VIC-20 by 4 years (and the C64 by 6 years)
* The same nominal resolution (and pixel aspect) as the NES
* About as much available-for-CPU RAM as the 2600
I initially started porting a specific deliberately disowned project by tepples to it, but between deciding that I Was Not Going To Release It (that would be horribly rude), and the UI (and MAME UI) impedance mismatch, I decided it wasn't any fun anymore.
So I made a simple sound-effect tool instead.
The hardware actually has 1 KiB of RAM, of which 7/8ths is used for the nametable = screen memory. Another 15 bytes are used for the various sprites and other control registers. The remaining 113 bytes are all that's easily used by the CPU for whatever not-directly-visible state exists.
MAME's emulation is (of course) kinda lackluster.
Attached are:
* My (somewhat meandering) notes about the hardware, and MAME's emulation of same
* My source code for my sound effect generator (h/t Shirtu for NESst)
* A pre-compiled build of the sound effect generator so that you can just run it
Sound effect editor UI:
Right steering wheel / MAME left/right - move left/right
Left steering wheel / MAME d g - move up/down
Either gas pedal / MAME lctrl a - play
Gearshifts / MAME z x c v q w e r - edit item under cursor
Track select / MAME spacebar - clear current item under cursor
Either start button / MAME 1 2 - clear current row under cursor
Sprint 2 arcade hardware
Sprint 2 arcade hardware
- Attachments
-
- sprint2notes.txt
- (10.57 KiB) Downloaded 522 times
-
- sfxtool.zip
- (12 KiB) Downloaded 469 times
-
- sprint2a.zip
- The filename is the only way you get MAME to run it correctly, this is 100% original-to-me code and data
- (2.93 KiB) Downloaded 472 times
Last edited by lidnariq on Fri May 27, 2016 7:19 pm, edited 1 time in total.
Re: Sprint 2 arcade hardware
Cool stuff. I'll watch the video and read the docs. I love examining old, old hardware too, and seeing how clever things were implemented.
I _suppose_ the advantage of having the BG map in limited RAM is being able to check quickly for collisions... but using 7/8 of the RAM for that seems wasteful. Then, on the other hand, the BG has to be somewhere on a RAM chip on the board, so I guess it makes sense to consolidate needed RAM into a single chip. (Sorry, just thinking to myself.)
I _suppose_ the advantage of having the BG map in limited RAM is being able to check quickly for collisions... but using 7/8 of the RAM for that seems wasteful. Then, on the other hand, the BG has to be somewhere on a RAM chip on the board, so I guess it makes sense to consolidate needed RAM into a single chip. (Sorry, just thinking to myself.)
Re: Sprint 2 arcade hardware
I think that had it actually been done entirely in discrete logic, they'd have just played the tracks out of ROM, instead of copying and unpacking the 4 bits-per-tile into the nametable.
I think the big reason they switched to (comparatively) lots of RAM for the tile map with a CPU is that it makes the state machine that renders the screen a lot simpler. You don't need to say "oh, it's scanlines 0-7, I should maybe display the message about coins; now it's scanlines 8-23, should I display the score; now it's scanlines 24-63, should I display the message or the track"
I think the big reason they switched to (comparatively) lots of RAM for the tile map with a CPU is that it makes the state machine that renders the screen a lot simpler. You don't need to say "oh, it's scanlines 0-7, I should maybe display the message about coins; now it's scanlines 8-23, should I display the score; now it's scanlines 24-63, should I display the message or the track"
Re: Sprint 2 arcade hardware
Oh, I forgot the other major thing I wanted to mention.
The hardware was used in a bunch of different games, not just Sprint 2 and its direct derivatives.
Over the following several years, Atari (and its subsidiary Kee Games) produced at least another nine games that used closely-related hardware:
* Basketball
* Boxer (prototype only, according to MAME)
* Canyon Bomber
* Dominos
* Flyball
* Minigolf (prototype only, according to MAME)
* Subs
* Super Breakout
* Ultra Tank
The hardware was used in a bunch of different games, not just Sprint 2 and its direct derivatives.
Over the following several years, Atari (and its subsidiary Kee Games) produced at least another nine games that used closely-related hardware:
* Basketball
* Boxer (prototype only, according to MAME)
* Canyon Bomber
* Dominos
* Flyball
* Minigolf (prototype only, according to MAME)
* Subs
* Super Breakout
* Ultra Tank
Re: Sprint 2 arcade hardware
A lot of early arcade games had really long hblank periods--a 67%/33% active/hblank ratio was absolutely typical. The hardware needed that much time to prepare the sprites.
I remember that the operators manual for one of the first arcade games to use a 320 pixel horizontal resolution (I think it might have been Gradius 2?) warned that when you were converting a cabinet from another game, you would most likely have to adjust the monitor to keep the picture from spilling off the edges.
I remember that the operators manual for one of the first arcade games to use a 320 pixel horizontal resolution (I think it might have been Gradius 2?) warned that when you were converting a cabinet from another game, you would most likely have to adjust the monitor to keep the picture from spilling off the edges.
Re: Sprint 2 arcade hardware
To put it into perspective:AWJ wrote:A lot of early arcade games had really long hblank periods--a 67%/33% active/hblank ratio was absolutely typical. The hardware needed that much time to prepare the sprites.
- NES, Super NES, and everything else using TMS9918 timing (5.37 MHz, 256 of 341-342 px/line): 25% hblank
- Atari/CGA (3.58 MHz, 160 of 228 px/line, or 7.16 MHz, 320 of 456 px/line): 30% hblank
- Apple II (7.16 MHz, 280 of 456 px/line): 38% hblank
- Commodore 64 and Apple IIGS (8.18 MHz, 320 of 520 px/line): 38% hblank
- Tandy Color Computer (7.16 MHz, 256 of 456 px/line): 44% hblank
- Game Boy (4.194 MHz, 160 of 456 px/line): It's complicated. It renders into a line buffer in the LCD driver and can be as fast as 176/456 or much longer than that depending on exactly where sprites and the left side of the window are positioned.
- Game Boy Advance (4.194 MHz, 240 of 308 px/line): 22% hblank