The Ultimate Intellivision Flashback

[Byte Knight]

Update - David Harley, creator of the Ultimate PC Interface, updated his firmware and hackfile to add pause, reset, and exit functions directly from the controller - no keyboard needed! The combination of keys 4-Clear pauses the game (screen stays on), 5-0 resets the game, and 6-Enter exits the emulator and brings you back to the front-end. He's also got the combination 1-9 pausing and blanking the screen working.

 

All that's left now is to try and stuff everything into a Flashback or Intellivision II case...

 

I'll post a video of the emulator in action soon.

Edited November 23, 2014 by Byte Knight

[pimpmaul69]

Update - David Harley, creator of the Ultimate PC Interface, updated his firmware and hackfile (files below) to add pause, reset, and exit functions directly from the controller - no keyboard needed! The combination of keys 4-Clear pauses the game (screen stays on), 5-0 resets the game, and 6-Enter exits the emulator and brings you back to the front-end. He's also got the combination 1-9 pausing and blanking the screen working.

 

All that's left now is to try and stuff everything into a Flashback or Intellivision II case...

 

I'll post a video of the emulator in action soon.

suhweeet!! That means i dont have to add my ipac into the mix which now eliminates the need for a usb hub. So i think i am just going to add a usb port to the back of it. I think i will keep the sd card internal and use the usb port to use a hub to plug in keyboard and thumb drive when i need to add games to the sd card

Edit: i dont need to use a hub as the mac keyboard i use has a usb port on it. Yay one less thing i need.

Edited November 13, 2014 by pimpmaul69

[+Rick Reynolds]

I spent just a little time looking at the inside of the flashback case and how I might put the pi into it. If I wanted to expose several of the pi ports to the outside of the unit, I'll need extensions of some kind for several of these:

 

HDMI

RCA plugs

SD card slot

USB port

Network port

 

I'm not sure I plan to use the network port, but the other ports seem like they would be pretty handy to have right on the outside of the case. I'm pretty confident I could hack the RCA plugs with parts from a Radio Shack, but I'm not sure about the others.

 

For example, does anyone make a SD card "extension" which would pretty much be a SD-card like plug on one and and an SD-card slot on the other? How about something similar for HDMI?

 

This just isn't something I've hobbied much in before. If such products are out there, I'd appreciate a pointer.

[Byte Knight]

Here's what I've got so far:

 

• I used the existing switch and power supply from the Flashback. I soldered a mini-USB wire to the existing ribbon cable to power the Pi.

 

 

• I had to break out the Dremel and modify the UPCI Player2 port to fit. I'll eventually glue these in place so the controllers can plug directly into these ports.

 

 

• Here's how I have the Pi situated. I used the Dremel and made an opening for the HDMI cable and a slot for the SD card to fit through. The only issue is that there's not enough room for the power connection next to the SD card, so I'll have to finagle something... The UPCI PCB is in the upper right corner. I'll likely have to shorten up the USB cable and the UPCI controller cables to get everything to fit.

 

 

You could also leave the back panel of the Flashback out for cable connections. The back just pulls right out, and nobody would probably even notice...

[+Rick Reynolds]

Looks good. I like the idea of putting a USB connector onto the existing power board. Keep us updated!

[intvnut]

 

When trying to tell different models of joystick apart:

In general, don't rely on joystick name strings in USB (or Bluetooth). These are intended as human-readable strings, not as programmatic strings. These can vary for a single joystick model (ex: a joystick that can be renamed by the user). Alternatively, the same name can be used across different models and even different manufacturers (ex: some joysticks out there have a name of "joystick" or "").

Instead, you should rely on the VID and PID of the joystick, which respectively are the Vendor ID and Product ID. Vendor IDs (VIDs) are uniquely assigned by the USB-IF and the Bluetooth SIG to each implementing company. Bluetooth adds one more field to indicate whether the VID is from the USB table of vendors or the Bluetooth table of vendors.

 

When trying to tell different instances of the same model apart (ex: telling each UPCI apart):

If the USB device implements a serial number, then use this. This is a string that is defined by the implementing company (i.e. each vendor defines their own set of serial numbers and can overlap with other vendors). At the USB protocol level, it is implemented similar to how device name strings are implemented. However, not every USB device, especially joysticks, implements USB serial numbers. Since the UPCI is still actively getting firmware updates, then I recommend contacting the creator to see if he's willing to add serial number support.

Bluetooth devices can have serial numbers as well but I don't remember that part of the spec clearly. However, it is common for Bluetooth devices to be uniquely identified by their Bluetooth MAC address. However, there is an option in Bluetooth for a device to randomize its Bluetooth MAC to avoid privacy issues. Fortunately for you, this feature is not commonly used.

 

 

I honestly don't know how much of this information is available to jzIntv. I'm accessing the joystick through SDL 1.2, and all it offers is "SDL_JoystickName" for identifying a joystick. No PID, VID or serial number information. I'm at the mercy of SDL in terms of how joysticks get assigned to joystick numbers in SDL also.

 

My musing on teaching jzIntv to read name strings was based on the fact that I have nothing else to go on with the limited SDL 1.2 joystick API. If I did add some sort of name match, then to distinguish two UPCIs, I'd need the serial number in the name string.

 

You can see my analog joystick control in all of its (lack of) splendor here.

 

One shortcoming: If a single "joystick" has multiple distinct analog controllers, it appears I don't let you bind multiple pairs of axes to different Intellivision controllers.

 

I currently do not have the time or motivation to fix that shortcoming, or even hardware to test with. But, as always, patches are welcome!

[gozar]

Hmm... I can get a B+ for a bit cheaper. Do you think there are differences that matter?

 

Maybe there are - I see it has 2 more USB ports and no RCA output (only HDMI).

 

You're using the regular B, correct? 2 USB ports, 512 MB, RCA + HDMI video out.

The B+ does have composite out, they moved it to the headphone jack (it has composite and audio in the jack). The micro SD card won't be any different than a regular SD card.

[+BBWW]

I already want one of these but will die trying to build it. You guys are crazy fun.

[pimpmaul69]

I already want one of these but will die trying to build it. You guys are crazy fun.

when i order the parts on december 1 i will post pics of my version. I am going a completely different route on how im gonna mod mine. It will give people different ideas on how to mod the guts and how it will work best for them. Still using the same 2 devices inside. Just gonna be modified way different.

[+Lathe26]

I honestly don't know how much of this information is available to jzIntv. I'm accessing the joystick through SDL 1.2, and all it offers is "SDL_JoystickName" for identifying a joystick. No PID, VID or serial number information. I'm at the mercy of SDL in terms of how joysticks get assigned to joystick numbers in SDL also.

 

My musing on teaching jzIntv to read name strings was based on the fact that I have nothing else to go on with the limited SDL 1.2 joystick API. If I did add some sort of name match, then to distinguish two UPCIs, I'd need the serial number in the name string.

 

You can see my analog joystick control in all of its (lack of) splendor here.

 

One shortcoming: If a single "joystick" has multiple distinct analog controllers, it appears I don't let you bind multiple pairs of axes to different Intellivision controllers.

 

I currently do not have the time or motivation to fix that shortcoming, or even hardware to test with. But, as always, patches are welcome!

 

I see what you mean. It seems like SDL does a great job at providing cross-platform support, providing cross-technology support (USB, Bluetooth, old-school 15-pin analog, maybe XID, etc), and in simplifying common compatibility problems with joysticks. However, it suffers the common problem that most such APIs run into: lowest common denominator.

 

I guess there are 6 options I can think of:

• Hope that SDL_JoystickName contains VID & PID as part of the name. Note that non-USB and non-Bluetooth joysticks won't have VID or PID (ex: old-school 15-pin analog).
• Switch to an alternative API similar to SDL but with more features (and maybe more complicated).
• Use the native APIs on each platform. This gives you a lot of control, but at the expense of complexity.
• Look at SDL 2.0 and see if it has the necessary improvements (at a glance, looks like 'no')
• Since SDL is open source, add your own methods to get the VID and PID (if available) from a joystick index. This code will be platform-specific but is limited to just this part of the code.
• Don't change your code.

[intvnut]

 

 

I see what you mean. It seems like SDL does a great job at providing cross-platform support, providing cross-technology support (USB, Bluetooth, old-school 15-pin analog, maybe XID, etc), and in simplifying common compatibility problems with joysticks. However, it suffers the common problem that most such APIs run into: lowest common denominator.

 

I guess there are 6 options I can think of:

• Hope that SDL_JoystickName contains VID & PID as part of the name. Note that non-USB and non-Bluetooth joysticks won't have VID or PID (ex: old-school 15-pin analog).
• Switch to an alternative API similar to SDL but with more features (and maybe more complicated).
• Use the native APIs on each platform. This gives you a lot of control, but at the expense of complexity.
• Look at SDL 2.0 and see if it has the necessary improvements (at a glance, looks like 'no')
• Since SDL is open source, add your own methods to get the VID and PID (if available) from a joystick index. This code will be platform-specific but is limited to just this part of the code.
• Don't change your code.

 

Well, absent any help from the peanut gallery on the first 5 options (ie. patch submissions to make it work), I'm going to stick with option 6 for now: "Don't change [my] code." Maybe after I get LTO Flash! in the can and shipped I can entertain deeper modifications.

 

My long term goal is to rewrite jzIntv in C++11 / C++14 as a set of classes with better defined interfaces and better encapsulation away from SDL. This will make it easier for folks to take jzIntv's core and wrap a different platform's APIs around it for native builds, while still offering an SDL build.

 

The current code base is almost two decades old, and, to put it politely, it has accumulated a fair bit of technical debt. Plus, I think I may actually be a better programmer now than I was when I first graduated college. Not necessarily the case, but I hope it's true for my sake.

 

One reason I've shunned native APIs is that they're moving targets, and I usually don't have the tools, time or patience to chase those targets. SDL, on the other hand, has been stable for most of jzIntv's existence. The biggest upset to the codebase (aside from moving from early Allegro to SDL 0.10) was moving from SDL 0.10 to SDL 1.2, and that was actually pretty painless. That said, jzIntv has been built with native APIs. Tim Lindner did a native MacOS 9 port years ago. ("MacOS 9" should give you an idea of how long ago that was!)

 

If I ever do get around to rewriting the jzIntv core as a C++ library, then whoever has the latest TurboXMetroVisualCodeWorksEclipseWarriorStudio.NET for their platform should be able to add a few classes to bridge the core code to their platform with native APIs, all encapsulated appropriately.

Edited November 20, 2014 by intvnut

[+Lathe26]

 

Well, absent any help from the peanut gallery on the first 5 options (ie. patch submissions to make it work), I'm going to stick with option 6 for now: "Don't change [my] code." Maybe after I get LTO Flash! in the can and shipped I can entertain deeper modifications.

 

My long term goal is to rewrite jzIntv in C++11 / C++14 as a set of classes with better defined interfaces and better encapsulation away from SDL. This will make it easier for folks to take jzIntv's core and wrap a different platform's APIs around it for native builds, while still offering an SDL build.

 

The current code base is almost two decades old, and, to put it politely, it has accumulated a fair bit of technical debt. Plus, I think I may actually be a better programmer now than I was when I first graduated college. Not necessarily the case, but I hope it's true for my sake.

 

One reason I've shunned native APIs is that they're moving targets, and I usually don't have the tools, time or patience to chase those targets. SDL, on the other hand, has been stable for most of jzIntv's existence. The biggest upset to the codebase (aside from moving from early Allegro to SDL 0.10) was moving from SDL 0.10 to SDL 1.2, and that was actually pretty painless. That said, jzIntv has been built with native APIs. Tim Lindner did a native MacOS 9 port years ago. ("MacOS 9" should give you an idea of how long ago that was!)

 

If I ever do get around to rewriting the jzIntv core as a C++ library, then whoever has the latest TurboXMetroVisualCodeWorksEclipseWarriorStudio.NET for their platform should be able to add a few classes to bridge the core code to their platform with native APIs, all encapsulated appropriately.

 

I agree and was expecting "don't change your code" to be the most likely answer. Most of the other choices involve more time and effort. Personally, I'd rather see time spent on new hardware projects, any SDK-1600 improvements you have in mind, and perhaps even new games.

 

Overall, jzintv works very well. Yeah, there will always be moments of "it would be cool if it did..." but there is only so much time in the day to write and maintain code (an issue I'm running into with my own Android app).

[intvnut]

 

I agree and was expecting "don't change your code" to be the most likely answer. Most of the other choices involve more time and effort. Personally, I'd rather see time spent on new hardware projects, any SDK-1600 improvements you have in mind, and perhaps even new games.

 

Overall, jzintv works very well. Yeah, there will always be moments of "it would be cool if it did..." but there is only so much time in the day to write and maintain code (an issue I'm running into with my own Android app).

 

I'm just more surprised no one jumped on my TurboXMetroVisualCodeWorksEclipseWarriorStudio.NET joke, or suggested that I missed the word "Builder" or "++" or "#" or something else.

Edited November 22, 2014 by intvnut

[+Gunoz]

 

I'm just more surprised no one jumped on my TurboXMetroVisualCodeWorksEclipseWarriorStudio.NET joke, or suggested that I missed the word "Builder" or "++" or "#" or something else.

 

I was too depressed realizing how old I am that I've used every compiler you mentioned.

[+intvsteve]

 

I'm just more surprised no one jumped on my TurboXMetroVisualCodeWorksEclipseWarriorStudio.NET joke, or suggested that I missed the word "Builder" or "++" or "#" or something else.

What!? No Watcom? Need to backport so that 32-bit code can run in Win16 you know!

Edited November 22, 2014 by intvsteve

[+Lathe26]

 

I'm just more surprised no one jumped on my TurboXMetroVisualCodeWorksEclipseWarriorStudio.NET joke, or suggested that I missed the word "Builder" or "++" or "#" or something else.

 

I got a good laugh out of it.

 

What, no Borland?

[intvnut]

 

I got a good laugh out of it.

 

What, no Borland?

 

I already gave them a shout out w/ Turbo. (The first compiler of there's I ever used was Turbo Pascal 3.)

[+Lathe26]

 

I already gave them a shout out w/ Turbo. (The first compiler of there's I ever used was Turbo Pascal 3.)

 

I didn't even realize Borland did Turbo Pascal, which is odd since that is the tool we used in college for 1st semester programming (1 semester of Pascal, never used it since). I think it was distributed without the box packaging so the name didn't stand out.

 

I was reminiscing for Borland C++ for Windows that with its OWL library (their answer to Microsoft's MFC). I still remember the OWL class diagram poster; it was big and reddish-orange with a Great Horned Owl swooping down with the talons extended.

[+intvsteve]

 

I didn't even realize Borland did Turbo Pascal, which is odd since that is the tool we used in college for 1st semester programming (1 semester of Pascal, never used it since). I think it was distributed without the box packaging so the name didn't stand out.

 

I was reminiscing for Borland C++ for Windows that with its OWL library (their answer to Microsoft's MFC). I still remember the OWL class diagram poster; it was big and reddish-orange with a Great Horned Owl swooping down with the talons extended.

Yeah! I might still have two of those... 3.0 and 4.1 I think... The 4.1 had the gigantic box with several linear feet of manuals, IIRC.

[Byte Knight]

David Harley updated the firmware for the UPCI and it should be available on his site soon. The pause, reset, and exit functions could be accidentally triggered when pushing a keypad button and disc at the same time. Yes, I know you're not supposed to hit both the keypad and disc at the same time, but it sometimes just happens with games like World Championship Baseball. The new firmware requires that you hold down the combination keys (4-C for pause, 5-0 for reset, 6-E for exit) to trigger the function, and helps prevent the functions from being accidentally triggered. So, the software part of the project is now working beautifully, including being able to play games in full screen HD. And, the sounds are nearly perfect with jzintv as far as I can tell. The buzz is back! I'm still planning on posting some video of everything in action...

Edited November 23, 2014 by Byte Knight

[Byte Knight]

Here's what my final layout will look like. I ended up getting a Pi B+ because the micro USB power port has been moved next to the HDMI port which provides better access in the Flashback shell. I plan to use a right-angle micro USB for the power cord so it doesn't stick out the back. I shortened up the UPCI USB cord (only 4 wires in it) and you certainly could shorten up the UPCI controller cables, but there's a ton of wires in each of them. Maybe Nurmix could take on another project! I'm going to leave the rear panel off so I can still have access to the Ethernet port for when I need to put more homebrew games on it. It may look ugly on the inside, but everything fits...

 

[Byte Knight]

And here's a demo video of the software side of things. Sorry for the monotone voice - Plimpton I'm not...

 

[pimpmaul69]

And here's a demo video of the software side of things. Sorry for the monotone voice - Plimpton I'm not...

 

so whats with the inty 1 curly controller?

[mthompson]

Great watching the progress on this. I'm interested in giving it a go if some kind of shopping list and software resources become available. I've got a Flashback and UPCI and would need to pick up a Raspberry Pi and whatever else is needed.

[Byte Knight]

so whats with the inty 1 curly controller?

 

David hasn't released a firmware update for the UPCI that defaults to the Flashback controller yet, but it's in the works...