Page 1 of 1

Sprint 2 arcade hardware

Posted: Wed May 25, 2016 2:50 pm
by lidnariq
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

Re: Sprint 2 arcade hardware

Posted: Wed May 25, 2016 4:26 pm
by ccovell
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.)

Re: Sprint 2 arcade hardware

Posted: Wed May 25, 2016 5:06 pm
by lidnariq
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"

Re: Sprint 2 arcade hardware

Posted: Fri May 27, 2016 4:03 pm
by lidnariq
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

Re: Sprint 2 arcade hardware

Posted: Fri May 27, 2016 4:04 pm
by AWJ
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.

Re: Sprint 2 arcade hardware

Posted: Wed Jul 18, 2018 10:29 am
by tepples
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.
To put it into perspective:
  • 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
Even platforms without sprites (CGA, Apple II, Apple IIGS, CoCo) had long hblank time in order to allow a large safe area for the less precise calibration of 1970s TVs.