intvnut

I know I'm replying to an ancient thread, but I figured I'd throw my 2 cents in. Just for the record, I have the T-Card Schematics here, (thanks to William Moeller) though you'll have to view them in a DOS-based editor that will show you the IBM Extended ASCII. I've also recently posted a simplistic design. It really isn't too hard to interface to the Intellivision. It's more complicated than *just* hooking up a bunch of wires, sure, but it isn't rocket surgery. Two 8-bit latches for the address, and a small bit of logic to decode address and bus. For all the homebrews I've released, I've used a design Chad Schell did for me that involves a single CPLD and a single EPROM. The logic in the CPLD isn't terribly complex. The design is limited to 16K words (which is plenty for the vast majority of games) only by the number of I/Os on the CPLD. You could go larger with one more I/O bit.

BTW, although I wouldn't actually build such a board myself, since I'd rather do stuff with microcontrollers to emulate ROMs, it wouldn't be hard to breadboard up an EPROM-based board that emulates a cartridge similarly to how a T-Card does it, using a bunch of 2732 EPROMs to do it. Note that you'll want an external 5v supply if you go above about 16K x 16 (8 EPROMs), since this old tech draws a fair bit of current and the Intellivision's power supply apparently isn't up to it. (I've seen some of Mattel's protos for their larger games and they have a supplemental power connector.) High level parts list: 2 8-bit latches (74LS373 seems appropriate here) 2 2732 EPROMs for every 4K words of game image 4 to 16 decoder with active-low outputs (74LS154 seems appropriate here) 3 to 8 decoder with active low outputs (74LS138 seems appropriate here) A 74LS00 quad 2-input NAND gate The basic idea is as follows: Split the EPROMs into two data buses, one for DB0 through DB7 and one for DB8 through DB15. For the low bus, connect all the D0s for all the EPROMs together and connect that to the Intellivision's DB0. Likewise for D1 going to DB1, etc. up through DB7. For the high bus, connect all the D0s together and connect that to the Intellivision's DB8. Likewise for D1 going to DB9 up through D7 going to DB15. Now connect all the EPROMs' A0 thru A11 together into a bus, and route that to the outputs of the latches. Connect A0 - A7 to the output of one latch, and A8 through A11 to the lower four bits of the other latch. Connect the Intellivision's DB0 - DB7 to the inputs of the latch you connected A0 - A7 to. Connect the Intellivision's DB8 - DB15 to the input of the latch you connected A8 through A11 to. Now you're most of the way there: You can drive out a 16 bit piece of data on the bus, and you can provide 12 bits of address to each of the EPROMs. Now you just need the control and decode logic. For address decode, connect the 4-to-16 decoder's inputs to the upper four outputs of the second latch. This will decode your ROMs into 4K pages of memory. Next, wire outputs that correspond to your memory map to the ~CS inputs on pairs of EPROMs that will serve up that address range. For example, suppose you are setting things up for a 16K game with ROM at $5xxx, $6xxx, $Dxxx and $Fxxx. Connect the "5" output to the ~CS inputs of one pair, the "6" output to the ~CS inputs of another pair, and so on. By "pair", I mean one EPROM on the "low" bus, and one EPROM on the "high" bus. For bus decode, you need to generate two things: A latch enable that tells the latches when to capture an address, and an output enable that tells the selected EPROM to assert its data on the bus. The 74LS138 computes most of this. The rest will need some NAND gates. Connect BDIR, BC2 and BC1 to the C, B and A inputs of the 3-to-8 decoder. Now the 8 outputs of the 3-to-8 decoder correspond to this truth table: BUS PHASES BDIR BC2 BC1 . .NAME . .DESCRIPTION ---- --- --- . .---- . .-------------------------------------------- . 0 . 0 . 0 . . NACT . .No ACTion . 0 . 0 . 1 . . ADAR . .Addressed Data to Address Register (DTB+BAR) . 0 . 1 . 0 . . IAB . . Interrupt Address to Bus (ignored) . 0 . 1 . 1 . . DTB . . Data To Bus . 1 . 0 . 0 . . BAR . . Bus to Address Register . 1 . 0 . 1 . . DW . . .Data Write (ignored) . 1 . 1 . 0 . . DWS . . Data Write Strobe (ignored) . 1 . 1 . 1 . . INTAK . INTerrupt AcKnowledge . .(Alias for BAR, ignored) You can ignore INTAK: The console never generates it externally. And since this is EPROM only, we can ignore DW and DWS. We can also ignore IAB since that's handled by the Intellivision's EXEC. Connect output #1 (ADAR) and #3 (DTB) to the inputs of one NAND gate. Route this output to both inputs of another NAND. This will give you your ~OE signal to route to all the EPROMs. Truth table: ~ADAR .~DTB .OE . ~OE ----- .---- .--- .--- . 0 . . .0 . .1 . .0 . (can't happen) . 0 . . .1 . .1 . .0 . 1 . . .0 . .1 . .0 . 1 . . .1 . .0 . .1 Connect output #1 (ADAR) and #4 (BAR) to the inputs of another NAND gate. This will give your "G" input to the octal latches (74LS373). Truth table: ~ADAR .~BAR . G ----- .---- .--- . 0 . . .0 . .1 . 0 . . .1 . .1 . 1 . . .0 . .1 . 1 . . .1 . .0 And then hook up all your power, ground, etc. On the 74LS138 and 74LS154, make sure to hook up your enables, too. And for good measure, you might want to sprinkle some .1uF capacitors around between power and ground to keep your power supplies clean. Put one near each of the pairs of EPROMs, since they'll be switching onto the buses and will have nice current spikes to go with it. To connect to the actual Intellivision, one way to do it would be to take an existing board, desolder the ROM, and solder in wires to bring to your breadboard. Or, if you prefer, get some ribbon cable and some IDC connectors, which is what I did. In my case, rather than desolder, I popped the SBP-640 out of a spare Intellivoice. I can give you its pinout if you need it. I *think* that should give you a working EPROM board. You'll need a few breadboards and plenty of wires. :-) I just came up with this circuit off the top of my head, based on what I remember of these components. There may be a couple minor gotchas in there, but they shouldn't be too major. Mea culpa. If somebody decides to build one of these, I can tell you how to split a ROM image up so that you can program it properly across all these EPROMs.

The Intellivision has a time-multiplexed 16-bit bus. You'll need either 2 8-bit or 1 16-bit EPROM, since the CP-1600 opcodes and all the original games are 10 bits wide. (The existing homebrews use a single 27C1024. Most homebrews also use the full 16-bit bus width.) You also need some logic to decode the bus controls and to latch and decode the address. You can do this with discrete TTL (like the old T-Cards did), or the modern way in a CPLD. Note that unlike the Atari, you can't easily take an existing game, desolder the ROM and solder in an EPROM in its place. (Well, the Atari also needs an inverter for the chip-select, but that's fairly minor.) The Intellivision used custom GI ROMs that did their own bus decoding and address latching/decoding. There were no EPROM versions of these. You have to build it yourself. Nobody that I know sells blank, ready to go boards. All the homebrews I know about use the same design, and have been fabbed as demand requires.

The three main things are needing wider-than-8 EPROM (easily solved with a x16 EPROM such as the 27C1024), self-decoding of the address, and latching the address appropriately. There's sufficient technical detail on IntelliWiki that if you're at all motivated you can figure it out. Oh, and the data bus is a full 16 bits. It's just that the CPU is architected so that you can get by with 10-bit wide ROMs if you need to. This was a cost saving measure that made sense in 1980 but not so much today. Modern homebrews use all 16 bits since there's no sense wasting that space (since there's no x10 EPROMs but there are x16 and 2x8). Also, 16 bit ROMs confer a moderate speed advantage. Space Patrol relies on the greater density and improved performance heavily. The big thing that holds most people back is the fact they can't just desolder a ROM from an old common and solder a new one in, and nobody's made their designs public. (Although, a trace of Mattel's T-Card is floating around.) This means starting "from scratch" which seems to scare folks off, though really all the information you need is available readily these days. I guess there's the small matter of making your own board, too. Doug Parsons etched his own based on the TCard design. All the carts I've produced were professionally fabbed. FWIW, the largest homebrews already shipped are 16Kx16. We're working on larger games and I have a higher capacity board design in the pipeline. I suggest if you're really bored, though, writing something like bAtari BASIC for Intellivision might bring a few more homebrewers to the Intellivision table.

I don't think GPL is suitable for some 2600 asm. If homebrewers want to GPL their game logic, that's fine. The problem comes when they try to GPL kernel or kernel setup code. Unfortunately, GPL in part of an application makes the whole app GPL. These little ROMs don't have a strong notion of dynamic linking to system libraries. The closest you'll get is calling a ROM that is built into the unit, such as the EXEC on the Intellivision. I've actually started to go back and re-mark all my library code as being public domain. Really, I think I want to mark as much code as possible as public domain. What value do I derive by keeping, say, controller scanning and decoding logic out of the public domain? Now the core game logic of Space Patrol itself is something different, but most of the infrastructure should be free for the taking. Things are perhaps different in the Intellivision world, since pretty much all the existing homebrew games are from-scratch works, or at least not hacks of existing game carts. The simpler architecture does not require as much baseline cleverness to get started. Intellivision games often do not have a notion of a "kernel" like the Atari games do. When they do, it's really just a big "blast the GRAM and STIC" loop in the ISR--somewhat of an inversion from what you need to do on the 2600. An aside, since I'm the Intellivision person at the Atari party: My understanding of 2600 programming--and you can correct me if I'm wrong--is that you implement most of your game logic in the vertical retrace interval, and spend the bulk of active display chasing the refresh, filling a line buffer up with graphics to display ahead of the actual refresh. Writing to WSYNC stalls the CPU until the next scanline, allowing you some flexibility in your timing, so that you're synchronous to horizontal retrace even if you're not pixel synchronous. Thus, games tend to adopt a kernel/logic structure, where the kernel focuses just on display, and the logic outside the kernel implements the rest of the game. This is, of course, a simplification over what's possible, such as going half-res vertically or otherwise allowing certain rows to repeat to implement other logic during active display. Did I roughly capture the paradigm? On Intellivision, it's somewhat reversed: Certain registers and RAM (the STIC and the GRAM) are only available during vertical retrace. The STIC, whose registers control sprite positions, contain collision information, etc. is available for about 2000 cycles after the retrace interrupt, and the GRAM is available for about 3800 cycles. Thus, games like Space Patrol also end up with a sort-of kernel/logic structure, where there's a big "blast the hardware" loop in the interrupt handler, and the rest of the logic is outside that. The difference is that the game logic happens during active display and the "kernel-like" bit happens during vertical retrace. The other big difference is that the Intellivision programming is only ever synchronous to the retrace interrupt, and never to something as fine grain as a scanline. This makes it easier to program at a corresponding loss of flexibility. You realize, of course, that the traditional BSD licenses are even more permissive about others taking your work and profiting from it, right? For many years, the TCP/IP stack and tools that Microsoft shipped (back in the Win3.1 days) was pulled directly from the BSD source tree. I guess my point in saying I'm GPLing Space Patrol is more that I'm inviting others to come and build off of what I've written--including taking pieces and using them to make unrelated games. I should also add in there that if there's some piece that looks like it's more infrastructure than game, I'd be open to putting it in the public domain, since there's a dearth of quality, unencumbered code out there for Intellivision. It sounds like the situation on the 2600 side of things is simply murky with so many games being hacks of existing code or otherwise derived from proprietary sources. The sales situation also seems to be rather different on the 2600 side vs. the Intellivision side. On the Intellivision side, it's much harder to make cartridges, so in practice, I'm the only person who does any more. For their releases, the IntelligentVision guys licensed the design I commissioned and use, but they're no longer making releases. Nothing stops others from making cartridges, but since it's not as simple as soldering an EPROM on a readily available blank (purchasable here in the AA store!) or desoldering a ROM from an existing board and soldering in an EPROM + inverter, no so many people are interested. The thing that gets me is that on the 2600 side, it seems to be fairly easy to sell just a cartridge. When I release a game, it's a cartridge, a manual, overlays and a box. Every release has had all the elements. Perhaps that's also a big factor?

Arnauld Chevallier wrote a GUI front end for it once upon a time. Here's an excerpt from an email from him: Also, even without that GUI, you can set up "shortcuts" to jzIntv to launch individual games in jzIntv on the Windows desktop or in a folder. Just do "New Shortcut", and then right click and edit the properties to set up the flags for that game. Yes, that's one shortcut per game, but it does work.

Cool! FWIW, jzIntv should port fairly easily also if there's an SDL port to Xbox. I don't own an Xbox, otherwise I would try myself.

Which Xbox Intellivision emulator would this be? Since you say you'll be working on it to fix bugs, I assume you're not talking about the Intellivision Lives! release. As for save states--I'm not sure. jzIntv doesn't, and this is probably the single biggest feature it's lacking. INTVPC (the DOS emulator on the original Intellivision Lives! CD) does support save/restore. Not sure about Nostalgia or Bliss.

I find that rather hard to believe myself, having compared game play on various emulators to playing on an actual Intellivision. Now if they're saying only a couple of games NEED a 16 way controller (Vectron being 1 I know of off the top of my head), yes I know that's true. But I can't believe only 1 or 2 actually use the 16 way controller. I could be wrong but I don't believe that, just from my own experience.... There are a fair number of games that keep you on a grid (PacMan, Lock'n'Chase, Night Stalker, Checkers, etc.) and so only give you 4 directions to move in. But pretty much all the sports titles or anything that lets you move freely (eg. Utopia) rather than constraining you to a grid will make use of 16 direction input even if they don't *need* it.

I can speak for jzIntv: If you use an analog joystick it will decode the analog X/Y into a proper 16-direction map. It also does fairly sophisticated autoranging and autozeroing. I'm rather proud of it, if you can't tell. :-) It's very configurable. I don't know if any other emulators support analog.

If you don't mind not having a GUI, jzIntv will use anything that looks like a standard joystick. It also works with Joe Fisher's Classic Game Controller interface and Retrobox-adapted joysticks.

One final followup: I was sent these blurry photos. If you squint, you can make out 9.3VAC 1.0 AMP AC, particularly in the second photo. I didn't take these photos. Enjoy.

My understanding is that they're identical save for the color of the plastic. They're identical and cheap to the point that ECS cassette tapes recorded on a PAL setup won't work on an NTSC setup, not because the ECSes are different, but because it gets its clock from the color burst in the main unit, and doesn't bother to change the divisor to match. Had each been tailored to its respective market, the PAL version would use different divisors than the NTSC version, or they would have sprung for a dedicated oscillator. All the ECS has is a second PSG chip, a 12K x 10 paged ROM, 2K x 8 of RAM and a UART with simple modem functionality to allow it to save on cassettes. There's nothing in there to change for PAL. What about the power requirements? I have the power supply from a US unit, but I don't want to fry my PAL ECS if it is expecting a different voltage/current. Tempest Ok, I just got the following message from a friend with access to the European ECS's power pack: So, it appears it's a similar voltage spec. In this case, 9.3V vs 10V. I don't believe the 0.7V makes a difference, since you're likely to see a much wider swing just based on whether your home's voltage is 110V or 120V. These are simple AC to AC transformers, not regulated power supplies. I leave that decision in your hands though, since it's your unit. The 8-bit NES uses a 9V AC adaptor, so if its connectors match and you feel safer with the lower voltage, you might consider giving that a whirl. (I think the connectors do match, because I seem to recall using my ECS transformer with the NES, since I can't find the NES's transformer. How ironic!)

Just a quick update: One of the people I wrote to with a European ECS wrote back to say he uses his with a universal power adaptor set to 12V. He doesn't have the original power pack, but he's going to ask some friends that do to check theirs.

My understanding is that they're identical save for the color of the plastic. They're identical and cheap to the point that ECS cassette tapes recorded on a PAL setup won't work on an NTSC setup, not because the ECSes are different, but because it gets its clock from the color burst in the main unit, and doesn't bother to change the divisor to match. Had each been tailored to its respective market, the PAL version would use different divisors than the NTSC version, or they would have sprung for a dedicated oscillator. All the ECS has is a second PSG chip, a 12K x 10 paged ROM, 2K x 8 of RAM and a UART with simple modem functionality to allow it to save on cassettes. There's nothing in there to change for PAL. What about the power requirements? I have the power supply from a US unit, but I don't want to fry my PAL ECS if it is expecting a different voltage/current. Tempest They should take around the same input voltage. The ECS units have their own power rectifier and regulator, and therefore only need an approximate voltage in order to function. As long as you have a ~10V AC power supply you should be in good shape. You *don't* want to use the European transformer that's meant for 240V, since it'll only feed the unit ~5V when driven from US's 120V feeds, and that's not enough to drive the voltage regulators. Anyway, just in case, I've emailed three different people that I'm pretty sure have European ECS units to ask them what the output voltage is on their European power packs. Presumably it's around 10V, but it wouldn't hurt to have them check. I'd be surprised if it's something different. Everything I've read, including the BSR's site, indicates that the brown ECS /only/ differs in the color of the plastic and the default transformer it's shipped with.

Throwing my $0.02 in, since I've released a couple homebrews myself... I think a big part of it depends on what the total homebrew package is itself. With exception to my very first release (the original 4-Tris and directly related PhillyClassic 4-Tris), the homebrew releases I've participated in (either directly or indirectly as in the case of IntelligentVision) have been high quality releases with nice boxes, overlays, labels, manuals and so on. The entire package is something quite beyond the game itself, and having a release that aspires to high production values is worth quite a bit more than the game itself. The original 4-Tris release fell short on the box front, but then at the time I didn't even know if I'd sell a single cart. :-) I was already on the hook for over $1500, and that release broke even. Since then, others have made more than that in the collector market on my work. I don't get to see any of that money, but I don't really do this to make profit. I'm a big fan of play testing, but not so much for full public development. This could be in part because I'm a fairly good programmer myself, I take strong ownership of my code during its development and tweaking, and there isn't as large a development community for Intellivision. My most recent release, Space Patrol, saw significant contributions from both David Harley (level development) and Arnauld Chevallier (music engine). It also saw extensive playtesting from a private set of playtesters including myself. My rule was that if *I* didn't enjoy playing it, I wouldn't ship it. I still pop it in just for the fun of blowing up a few aliens. :-) If *I* am not sick of it yet, that's a good sign. If I find the game to be a bore, then I won't ship it. As for releasing a ROM, I go back and forth on this. For 4-Tris, there was a ROM out there before it was clear I could even make carts. I don't think it hurt sales, and I think it probably helped. 4-Tris is perhaps a special case: It was the *first* complete homebrew release for Intellivision. For Space Patrol, I released a teaser edition for people to try-before-buying. Since it doesn't have the complete levels, there's still something left to be discovered in the final cart. I will be releasing the full levels at some point. The main reason I haven't yet is that I've been too busy to make the release. It's not as simple as putting the ROM out there, because when I release it, I will be releasing the full code under the GNU GPL, and will remove the "LTO splash" and any easter egg that might be in there... *hint* I think this approach is attractive, because it gives the best of all worlds: A thoroughly playtested game with high code quality, an available ROM with source for hacking, and a cartridge release that's still unique and special. Combine this with high production values on the cart release and I think it's a winning formula. Arnauld's last homebrew release, Stonix, did something similar. There was a public beta that demonstrated most of the gameplay and functionality. Separately, there was the full cartridge release. Behind the scenes, the game was extensively playtested by a core group feeding back to Arnauld. Development consisted of a core team (Arnauld and David) dedicated to a high quality release. I don't know offhand if Arnauld ever published a full game ROM. I have the full ROM, but that's because I programmed the EPROM chips that went on the boards. I kinda sorta needed it. I'm not sure what the release strategy will be for Arnauld's next title. That's up to him really. I personally would like to release a teaser that has part of the game available to play while carts are still on sale, and then release the full ROM afterwards. That's ultimately his decision. Now, if you're just programming EPROMs and slapping them on boards to sell a homebrew title, I think the situation changes dramatically. There's a lot of work that goes into a full homebrew release, but anyone with an EPROM burner can burn an EPROM and shove it onto a board. Whether you do that yourself or you pay someone a few $ to do it, I see it as worlds apart from what I do when I make a full release. I also don't see the point when we have products like the Cuttle Cart if you just want to play on the real hardware. If someone wants to take one of my GPLed games and go through the headache, heartache, sweat and tears of putting together a full release with artwork, manuals, boxes, etc. and make a couple $ of it, I can't and won't stop them. It's a time consuming process that doesn't have very high returns. What meager profits result don't even come close to minimum wage for the time and effort involved with the shipping, coordination, etc. It's a labor of love bringing these games out. There are some that will profit-take on eBay making a few hundred dollars here or there, but even then, it's not that much money compared to the time and effort. As for my own Left Turn Only label? What "profits" I got there from Space Patrol and 4-Tris (and I do put "profit" in quotes) go into paying for the next titles, so it doesn't go on my credit card again. It's how I make my hobby cost neutral. The SP and 4T release had me on the hook for far, far more than $1500 this time.

My understanding is that they're identical save for the color of the plastic. They're identical and cheap to the point that ECS cassette tapes recorded on a PAL setup won't work on an NTSC setup, not because the ECSes are different, but because it gets its clock from the color burst in the main unit, and doesn't bother to change the divisor to match. Had each been tailored to its respective market, the PAL version would use different divisors than the NTSC version, or they would have sprung for a dedicated oscillator. All the ECS has is a second PSG chip, a 12K x 10 paged ROM, 2K x 8 of RAM and a UART with simple modem functionality to allow it to save on cassettes. There's nothing in there to change for PAL.

you talked about continuing an homebrew game?... you should contact the author before starting, even if the game is not original. I guess it also depends on what license the original was released under. I've released a number of what can at best be called "protogames," such as "Tag Along Todd" under the GNU General Public License. Anyone can take any of these at any time and change them into whatever they want at any time, so long as if they release the result, they too release it under the GPL. In fact, David Harley took Tag Along Todd 2 and put much more of a game around it. He didn't need to ask for permission. He was able to just go do it. Of course, I think I may be a tad unique in this regard in the homebrew community. *sigh* FWIW, Space Patrol's teaser edition source is out there and it's GPL. I will eventually release the full level data GPL, though I'll keep the LTO splash and any easter eggs private. :-)

Oh, and here's pics of my whale. Neat! I never knew it started up with a menu like that before. Do you have any reviews or info on the games themselves? There's a video on youtube that appears to be a demo that shows some of the keyboard games, but not too much. Tempest My Keyboards' tape drive is non-functional, so I don't dare put any tapes in it. The video on YouTube, if it's the one I'm thinking of, is the demo tape I saw at CGE2K7.

Oh, and here's pics of my whale.

Actually, I own one, and know a handful of other owners. Frank Palazzolo and I have actually done a fair bit of reverse engineering work on the Keyboard and Frank's dumped a number of the tapes. (Frank's done the lion's share of the reverse engineering. I've mainly poured through the 6502 disassemblies and worked out some of the higher level state machines.) He has a partially completed MESS driver for it too that he's written. So, it could be possible to review all the completed Keyboard games at some point. That would be incredible and much needed! Even knowing basic things like construction quality, features, etc., from actual hands-on use and seeing one photographed for real, rather than from marketing slicks, would go a long, long way. BTW, see my edited post above for tech links. As for construction quality, the unit mostly seems solid, but I've only ever seen one working tape drive, and that was in the Intellivision Productions booth at CGE2K7. And "working" is somewhat generous. It was flaky. The unit still has an ineffable "toy" quality. For example, keypresses all have a stupid little ASCII-code dependent chirp played for them that makes it just sound and feel like a children's toy.

Actually, I own one, and know a handful of other owners. Frank Palazzolo and I have actually done a fair bit of reverse engineering work on the Keyboard and Frank's dumped a number of the tapes. Frank's done the lion's share of the reverse engineering. I've mainly poured through the 6502 disassemblies and worked out some of the initial low-level stuff and higher level state machines. Frank nailed the tape drive low-level stuff which was the truly tough nut to crack. Frank has a partially completed MESS driver for it too that he's written. So, it could be possible to review all the completed Keyboard games at some point. Here's some tech info in the form of commented disassemblies that we've compiled: 6502 disassembly CP-1600 disassembly More notes on 6502 code More notes on CP-1600 code Also missing from this summary: There's a TMS9927 based character buffer starting at $B800, configured for 40x24 display. It has hardware scroll based on rotating the line assignments. Scrolling is triggered through a memory mapped strobe, documented in the notes above.

I don't think there's a compatibility problem with the PAL Intellivision. I just tried an experiment in an emulator and it seemed to work fine. If it's getting to the title screen but not much further, then maybe one of the upper address/data pins is dirty. Judging by the memory map, I'd suggest giving extra attention to DB10 through DB13 when cleaning the card edge. The following diagram should help: This is the bottom (aka solder side) view.

There are a couple game elements that are scaled back from the arcade because of system limitations. I really pushed the Intellivision to its limits with this title, using every available cycle. The limitations are actually common among some of the Atarisoft Moon Patrols, too: 1. No upward/downward slopes. The rolling boulders just roll along a flat plane. 2. Only one boulder size. 3. No "tiny rocks." 4. The forward-shooting bullet doesn't "explode." 2, 3, and 4 go together. In the arcade version, there were very tiny rolling boulders and very tiny static rocks that could only be shot if you timed your forward bullet perfectly, so it'd explode at the end of its range and take it out. The other option was to jump these tiny obstructions. These were absent from some of the home translations, and that includes Space Patrol. This does make the game slightly easier in the Moon levels. (Moon corresponds to the arcade version.) Space Patrol makes up for this by adding completely new worlds--Mars, Pluto and Mercury--that add game elements that are more suitable for the Intellivision. Mars adds a mine-laying smuggler, whereas Pluto adds one that shoots at you. Mercury adds underground stages with deadly falling stalactites. All three stages make the existing bad guys more aggressive, too, providing a wide range of game play beyond what the arcade offers.

Lee, It's odd it doesn't work for you with the Intellivoice. I did test it with an Intellivoice and ECS attached, and I checked again just now that it works. (My main development rig was a Sears unit + ECS + Intellivoice, visible here in this mad scientist picture of my next hardware project: http://spatula-city.org/~im14u2c/images/JL...01032008143.jpg ) It doesn't make use of the Intellivoice, so you're not missing anything by not connecting it. That said, if you think the board may be faulty for some reason, I'd be open to swapping it. Please let me know. --Joe