Sprint 2 arcade hardware

Discussion of development of software for any "obsolete" computer or video game system.
Post Reply
lidnariq
Posts: 8704
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Sprint 2 arcade hardware

Post by lidnariq » Wed May 25, 2016 2:50 pm

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
Attachments
sprint2notes.txt
(10.57 KiB) Downloaded 385 times
sfxtool.zip
(12 KiB) Downloaded 348 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 346 times
Last edited by lidnariq on Fri May 27, 2016 7:19 pm, edited 1 time in total.

ccovell
Posts: 1005
Joined: Sun Mar 19, 2006 9:44 pm
Location: Japan
Contact:

Re: Sprint 2 arcade hardware

Post by ccovell » Wed May 25, 2016 4:26 pm

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.)

lidnariq
Posts: 8704
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Sprint 2 arcade hardware

Post by lidnariq » Wed May 25, 2016 5:06 pm

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"

lidnariq
Posts: 8704
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Sprint 2 arcade hardware

Post by lidnariq » Fri May 27, 2016 4:03 pm

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

AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: Sprint 2 arcade hardware

Post by AWJ » Fri May 27, 2016 4:04 pm

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.

tepples
Posts: 21720
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Sprint 2 arcade hardware

Post by tepples » Wed Jul 18, 2018 10:29 am

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.

Post Reply