Jump to content
IGNORED

Harmony Cart 5200?


Dr Manhattan

Recommended Posts

Will there ever be a Harmony Cart for the 5200?

 

I am currently considering buying the Atari Max 5200 flash cart. Unfortunately I've owned flash carts in the past and they seem to have a limited shelf life. (Internal batteries die, carts refuse to flash, etc.) Making matters worse I would probably only get to use my 5200 flash cart twice a year, which worries me even more. (I travel, live in multiple states, etc) I owned a GBA flash cart that died simply from lack of use.

 

I prefer the whole SD card adapter set up you see in the Harmony Cart (and similar carts made for old and new systems like Colecovision and the Nintendo DS.) So I'm hoping the devs behind the Harmony Cart 2600 and the upcoming H2 will eventually consider making one for the 5200. Might as well complete the set. (Hey while you're at it make an R4 style cart for the Atari Lynx...)

 

What do you think my fellow 5200 enthusiasts?

Link to comment
Share on other sites

Considering Atari Max created the USB flash cart, and also the SD card version of the Colecovision flash cart....I'd think he would be the first to tackle an SD card-related 5200 cartridge.

 

Atari Max really makes some impressive products. I especially like their Coleco SD adapter. I wonder why they didn't go the same route on the 5200?

 

I really have to give Harmony cart people credit though, they finally made this stuff affordable. $60 for a bare bones cart is amazing.

Link to comment
Share on other sites

I didn't know the flash carts use batteries. So they can just go bad? I have the AtariMax USB flash cart for the 5200.

Its almost full and has everything I would want on it. The only reason I can see it being flashed again is if the Sinistar and a few conversions ever get released. Of course new homebrews would be great too. I think it has a lifetime warranty but who knows what the situation will be in 10 yrs or more from now.

 

I was going to offer up my SK dipswitch multicart for sale, but now I think it would be a good idea to keep it!

 

**Oh, and the Coleco SD cart is amazing. Only problem with it is that its for the Coleco. 300+ coleco roms later and I only really like a handful of games more than before I had this cart. I really do think it would have been better for me to just get the coleco carts I like than to have purchased this SD cart. Its a great product for an OK system.

Link to comment
Share on other sites

I worked on, then abandoned the 5200 Harmony. The 5200 only has a single cart that needs bankswitching, which greatly simplifies the hardware requirements for a flash cart. And, I believe the market is already saturated, as there are several flash carts and multicarts for the 5200 that can do basically the same thing.

 

I did lay out a board but never had a prototype made.

post-5792-129114890689_thumb.gif

If this project is ever revived, the above board won't be used anyway as newer, better, and cheaper chips are now available. Also, I am not convinced that SD is even necessary for this application as the 5200's library is relatively small. A decent flash chip with good data retention would do the job more effectively, would bring the cost down, and I can find them with up to 16 MB which I'd think would be more than enough space.

  • Like 3
Link to comment
Share on other sites

And, I believe the market is already saturated, as there are several flash carts and multicarts for the 5200 that can do basically the same thing.

 

Is there anyone other than AtariMax making these things? The Atarimax carts seem overpriced for how simple such a device must be inside. Plus, the software is Windows only. I think a sub $100 flash cart for the 5200 that either took SD or acted as a USB mass storage device would be a real winner.

Link to comment
Share on other sites

[quote name='batari' date='Tue Nov 30, 2010 4:04 PM' timestamp='1291151050' post='2147622'If this project is ever revived, the above board won't be used anyway as newer, better, and cheaper chips are now available. Also, I am not convinced that SD is even necessary for this application as the 5200's library is relatively small. A decent flash chip with good data retention would do the job more effectively, would bring the cost down, and I can find them with up to 16 MB which I'd think would be more than enough space.

 

So then really, with my Atarimax flash cart, if it ever stopped reading the roms, just re-flash it and it should be good for that amount of time again?

Link to comment
Share on other sites

I worked on, then abandoned the 5200 Harmony. The 5200 only has a single cart that needs bankswitching, which greatly simplifies the hardware requirements for a flash cart. And, I believe the market is already saturated, as there are several flash carts and multicarts for the 5200 that can do basically the same thing.

 

I did lay out a board but never had a prototype made.

post-5792-129114890689_thumb.gif

If this project is ever revived, the above board won't be used anyway as newer, better, and cheaper chips are now available. Also, I am not convinced that SD is even necessary for this application as the 5200's library is relatively small. A decent flash chip with good data retention would do the job more effectively, would bring the cost down, and I can find them with up to 16 MB which I'd think would be more than enough space.

 

Is the 5200 cart slot technically the same as the 400/800 cart slot? I've opened up my 5200 and the first thing that stands out is the actual cartridge slot inside is a lot smaller than it is on the outside. Is there a Harmony cart for the 400/800? If there is and the slots on both machines are the same, then shouldn't it just be a matter of sticking it in a 5200 cart shell?

Edited by OldAtarian
Link to comment
Share on other sites

Is the 5200 cart slot technically the same as the 400/800 cart slot? I've opened up my 5200 and the first thing that stands out is the actual cartridge slot inside is a lot smaller than it is on the outside. Is there a Harmony cart for the 400/800? If there is and the slots on both machines are the same, then shouldn't it just be a matter of sticking it in a 5200 cart shell?

No, the cartridge port on the 5200 is wider than the A8 port, and the pinout is different. It wouldn't work anyway since the 5200 and A8 have different memory maps.

Edited by ApolloBoy
Link to comment
Share on other sites

I should have a 5200 version of the Colecovision Ultimate SD cart available pretty soon.

 

It will be much more than a basic flash multi-cart though, with specs very close to that of the Colecovision version.

 

I'll probably send out a couple of the prototypes for beta testing soon, I'm working on porting over the menu software as time allows. I may have a few weeks to work on it after the holidays and before spring semester starts.

 

Here is the basic list of features from the Colecovision version, with a few edits to reflect what the 5200 version should be able to do. Most of the hardware stuff was verified working long ago, Bounty Bob, Mega-Cart, 512KB Read/Write access as expanded memory, etc.

 

Pictures attached are of the Rev 2 prototype, which will need to be re-worked at least one more time.

 

Steve

 

Basic Hardware

 

  • 50 MIPS CPU with high speed SD Interface, internal ram and flash memory for cartridge settings.
  • FAT32, FAT16, SD and SDHC Support, no practical limits on number of games stored on each card.
  • 512KBytes of SRAM (Expands 5200 available RAM from 16k to 512k)
  • 128KBytes of Non-Volatile Block Flash for Diagnostic/Boot ROM/Additional Storage/etc
  • Cartridge boot time, from power on to FAT32 display is less than two seconds, with plain english diagnostic messages in case of boot failures.
  • Cartridge load time for a 32K ROM image is around one second.
  • Full Read/Write access to all 512KB+ of memory for games using the new Hybrid bank switching mode.
  • CPU firmware, cartridge boot rom, cartridge hardware logic and menu software are all fully upgradable from the SD card.

 

Basic Menu Operation

 

  • Cartridge will be able to automatically read and display files present on your FAT32 formatted SD card.
  • Menus are created 'on the fly' from the directory structure with optional full or limited long filename sorting.
  • No special menu creation or other PC loading software required.
  • This means no dependence on Windows drivers or software, you can create and load your card from any operating system that can read/write a FAT32 or FAT16 formatted SD or MMC memory card.

 

Media Compatibility

 

  • SD, SDHC, and MMC Card Media
  • FAT16 and FAT32 Filesystem (with full long filename support)

 

More Device Specs

 

  • Supports all currently active cartridge formats, including BBSB, and Mega-Cart games (MULE).
  • New 512KB Hybrid Bank Switching mode allowing new games/applications full Read/Write access to 512KB of RAM. Even the largest 8-bit computer games can now be ported to the 5200.
  • BIOS bypass mode, start any game without the title delay.
  • Programmer API for accessing cartridge services at run time.
  • Programmer API will effectively allow creation of games of true unlimited size, as game banks, level data, save game data, etc can all be dynamically loaded from and saved to SD card in microseconds while the game is running.
  • Cartridge system software loaded dynamically from SD card at power on.
  • One button display of manuals from menu for game under cursor.

post-934-129140331568_thumb.jpg

post-934-129140332026_thumb.jpg

Edited by classics
  • Like 4
Link to comment
Share on other sites

I should have a 5200 version of the Colecovision Ultimate SD cart available pretty soon.

Very cool. To be honest, I was never too excited about a 5200 Harmony - I prefer to target the systems that didn't have any current flash cart.

 

I wonder though, that by allowing flash updates only through SD, the user may not have a simple recovery system should that flash update fail or if flash contents ever get corrupted (such as due to a power cycle at the wrong time) and the cart could be bricked. Could a user recover the cart should something like that happen?

 

I've been struggling with this same issue with H2 - an onboard user-recovery system over USB adds considerable cost. The original H2 prototype didn't have an onboard recovery system (recovery could be done with a separately-sold dongle, by sending the board back to me, or by constructing one's own dongle.) The current prototype has this recovery system onboard but it adds a full 50% to the component cost, and I wonder how important it is if flash corruption may be considered unlikely.

  • Like 1
Link to comment
Share on other sites

I should have a 5200 version of the Colecovision Ultimate SD cart available pretty soon.

I wonder though, that by allowing flash updates only through SD, the user may not have a simple recovery system should that flash update fail or if flash contents ever get corrupted (such as due to a power cycle at the wrong time) and the cart could be bricked. Could a user recover the cart should something like that happen?

 

I've been struggling with this same issue with H2 - an onboard user-recovery system over USB adds considerable cost. The original H2 prototype didn't have an onboard recovery system (recovery could be done with a separately-sold dongle, by sending the board back to me, or by constructing one's own dongle.) The current prototype has this recovery system onboard but it adds a full 50% to the component cost, and I wonder how important it is if flash corruption may be considered unlikely.

 

I suppose it depends on how 'worse' the worse case is.

 

The cpld and flash components can be restored by the onboard CPU, even if they are blank.

 

The firmware for the CPU is partitioned into a boot portion and a run portion. The boot portion does a CRC of the run area before turning over control, if its no good it will try to re-flash it from a recovery file on the SD card.

 

Normally only the run portion of the firmware is erased during a CPU firmware upgrade, so it should be pretty robust.

 

However, if a boot area update were issued and that was interrupted, then the cartridge could be bricked and have to be sent back for programming.

 

With this particular CPU I don't think I can be much more comprehensive without a second external cpu to watchdog the first.

 

Steve

Link to comment
Share on other sites

The firmware for the CPU is partitioned into a boot portion and a run portion.

That's basically how H2 will be structured. The bootloader will be in its own sector normally only read.

However, if a boot area update were issued and that was interrupted, then the cartridge could be bricked and have to be sent back for programming.

That's basically the same concern I have. The way I originally designed H2, I'd do the initial programming using a special dongle or programmer. After that, the bootloader could program itself. However, there is always a chance that the bootloader could corrupt itself during self-programming. I realize that nearly all devices work this way if reflashing bootloaders (not just flash carts, but just about anything such as motherboards, phones, etc) and can be bricked if the update fails for any reason. The question is should I do what everyone else does (i.e. require sending back for repair if bricked) or pull out all of the stops and allow for easy end-user recovery over USB even in the worst possible case, regardless of how unlikely it may be, even though it costs more. Or, just offer the built-in recovery mechanism as an option and only populate the parts needed if the user requests them.
Link to comment
Share on other sites

The question is should I do what everyone else does (i.e. require sending back for repair if bricked) or pull out all of the stops and allow for easy end-user recovery over USB even in the worst possible case, regardless of how unlikely it may be, even though it costs more. Or, just offer the built-in recovery mechanism as an option and only populate the parts needed if the user requests them.

 

Would it be cheaper to use a PIC with enough code space to re-program the ARM to a state where it could then recover itself from USB or SD? The PIC could just monitor the ARM for a keep alive signal and if it didn't see it after 30 seconds of power, it could try using the JTAG interface to reload the boot flash.

 

I suppose it depends on how small of a firmware you can get away with for that device and if a $1 or $2 PIC wold have enough code space to hold it.

 

I haven't seen a lot of firmware corruption with the devices I'm using so personally, I'd skip it if cost is an issue.

 

Steve

Edited by classics
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...