Intellivision cart flasher

mr_me · October 28, 2018

Even with one single memory map for everyone, the economics don't justify having a custom ic manufactured.

intvnut · October 28, 2018

Part of the reason I went with a self contained microcontroller based solution is that it's getting harder to source 5V EPROM and flash parts. Combine that with the cost of having multiple devices on the board (and corresponding yield fallout). The fewer soldered pins on the board, the higher the yield. JLP is down to a single chip: the microcontroller.

With JLP04, I think I'm actually well under 1% yield fallout finally. In fact, I may be at around 0.2%, if my mental math is correct. With LTO Flash it was a bit over 1%. And, those boards were noticeably more expensive to boot. It doesn't sound like much, but it adds up. I don't really like sending $100s out the door.

My current manufacturing flow for JLP requires me to run a game executable through a preprocessing step that formats it for the firmware, and then assembles and links it against the firmware. This then gets converted to a HEX file that gets programmed onto a master board. When it goes well, the mastering process takes 15 minutes or so. When it goes poorly (and it does go poorly occasionally), it can take me a few hours until I figure out what's gone wrong, and then patch things up. As I've said previously, my mastering tools are not very refined at this point. Also, I'm in the unenviable state that I can't really rebuild them at the moment—the system they were developed on died, and took some code with it—and so I'm stuck with the executables I built 5 or 6 years ago, until I figure out how to recreate them.

Once I have a master, then programming multiple boards goes very quickly. It's around 15 seconds per board, plus or minus a few seconds depending on game size. I could make it go faster, but I can't get boards out of the anti-static bags faster than that. The long pole is really inserting and removing the boards from the programmer.

Once all the boards are programmed, then I give a brief power-up test in an Intellivision, to ensure each board resets to the game properly. In early versions of the JLP firmware, you sometimes needed to hit reset on the console. (I did a study vs. a Mattel cart, and both JLP and the Mattel cart had similar rates of "needing to hit reset.") Current JLP firmware—basically anything 2012 and newer—aggressively detects this and tries to kick the machine out of its zombie state. Of course, it doesn't seem to help the TutorVision units that still need you to hit reset anyway.

What I'm working on is a more turnkey approach, where there's a baseline firmware in the JLP board (providing a floor of functionality similar to 5-11under's CPLD), and providing a bin2jlp utility that would take a game and format it to load onto the JLP board. Alongside that I'd offer an adaptor that would let you use an LTO Flash!, or an adaptor of your own design, to load the formatted file onto a board. I'll make the protocol straightforward and will document it, in case anyone's concerned that I'm using LTO Flash! as a programming pod.

I'm basically in the position of recreating my firmware build flow from scratch. I did a lot of cleanup on my firmware tree when I created LTO Flash!, and so the new JLP firmware will inherit much of this.

Assuming I can get to that point, I want to just put the boards, shells, and screws out there as a kit, so I really am out of the loop on further cartridge production. I know it's taking a long time, but at least I have managed to ship a few of my projects, and have assisted several others shipping theirs. Good engineering takes time.

Edited October 28, 2018 by intvnut