.BIN Repository - Images for cartridges that require "burning" - (NO LONGER UPDATED OR SUPPORTED)

[+Ksarul]

Here's something that might come in handy if anyone ever needs Supercart boards again. I don't plan on doing another run of these, so here are the files to make your own.

ti_SuperCart_v10aExpressPCB.zip

ti_SuperCart_v10aGerbers.zip

[+Ksarul]

Here are the UberGROM files from Gazoo and others.

XB3 Suite 2014-07-11.zip

Extended Basic Fun-2015-04-13.zip

XBN v27 suite 061315.zip

ck-multi1v1-binonly.zip

plato_and_rpi_relocated.zip

rxb2015e.zip

3 XBs.zip

SXB Suite 2014-07-11.zip

[+OLD CS1]

I am behind on everything in this realm. Is the UberGROM the only flash-programmable cartridge board right now? I am wanting to make carts for my projects without having to burn EPROMs.

[Tursi]

UberGROM is only for the GROM side. The ROM side still requires an EPROM programmer.

[Omega-TI]

Is the UberGROM the only flash-programmable cartridge board right now? I am wanting to make carts for my projects without having to burn EPROMs.

 

I see Tursi already covered the important item, so I'll get the next part. Yes, EPROMS suck, but EEPROMS a super easy to re-use.

 

If you have access to a pre-made images, burning them can be pretty simple. For about the cost of two cartridge boards (pretty inexpensive), you can purchase a little burner that will have you all ready to go. I have a blog entry on the subject << HERE >> for more details if you think you might want to learn more.

[ckoba]

(snip)

2048K Games 1

1024K Games 3 (Why 3? Because at some point I will also break up the 2048K Games cartridge to make a version for 1024K Games 1 and 2, just to make identical sets).

Has anyone successfully built and run programs from the 2048k image linked here?

 

I have went through the ritual of obtaining an adapter for the 866 to program 27C160s from eBay (it's basically an Amiga Kickstart burning adapter), breaking the image into four 512k chunks, and programming each quarter of the EPROM as if it were a 27C4096.

 

The menu comes up (albeit the font is a bit corrupted), but programs don't launch correctly. The 1024k image seems fine, burned the same way (but only toggling A18 instead of A18/A19 during burn)

 

Before I go tearing apart the adapter, I'd just like to know if anyone has succeeded and if so what was their burn procedure (which quarter went into which part of the EPROM)

 

Thanks ...

 

Edit: 160, not 180. And purposefully grounding the 8/16 select on pin 32 has no effect. Some games that come up are missing letters ... have I hit a 8/16 issue?

Edited April 26, 2016 by ckoba

[+Ksarul]

If the procedure works for the 1024K image using a 27C800, it is definitely an issue with the 27C160 chip. I have between 50 and 100 of them laying around the house that do all kinds of crazy things when you use them in 8-bit mode. Nearly half of all the chips I've purchased (from multiple sources all over the world) had problems shifting properly. The only ones I found that worked consistently were from a seller in Bulgaria, but I bought up her entire stock and used them in the initial runs of the cartridge. Arcadeshopper may have found a source that works as well--maybe he'll chime in here. Recently, I tried using 29F1615s instead and I haven't had any problems with those yet. I've burned nearly 100 copies of the 2048K image (it has been a popular cartridge) using either my Advin U-84 Plus or my Topwin 3000 programmer. Both of these will program 16-bit chips directly.

[ckoba]

If the procedure works for the 1024K image using a 27C800, it is definitely an issue with the 27C160 chip.

Understood. I'll get ahold of a couple of 29F1615 (difficulty: China-sourced); if you've had 100% success, then I might get lucky and get a device or two that actually works.

 

Thanks for the response. I'd re-burned the four chips I had in every permutation of A18 and A19 that I could come up with, and the blasted thing still wasn't working. The only thing that clued me in was one of of the few carts that loaded was missing every other character from the splash screen.

 

A suggestion for a future revision of this board: how about using four square 49F040s instead of a single 27C160? Footprint would be about the same, socket would be through-hole, !CS off of A18 and A19, and they'd be programmable by mere mortals ...

Edited April 26, 2016 by ckoba

[ckoba]

For what it's worth ...

 

... the powerup trickery in Gazoo's XB27 Suite interferes in certain aspects with IM's forthcoming 9640MENU if 9640MENU itself is called via a powerup.

 

While we're working through the issues, I've stepped back to Gazoo's "Extended Basic Fun" three-in-one UberGROM image so that I can continue using (and reporting bugs on) 9640MENU.

 

However, as with many things Gazoo did, the "Extended Basic Fun" image was a bit eccentric. Although it presents as a normal UberGROM cartridge, the recovery is turned off, and attempts to YLOAD gromcfg to take a look inside bluescreened.

 

In the interest of openness, I've slightly repackaged this image. I got into gromcfg via 9640MENU, saved the GROMs to file via ctrl-S, and reloaded into an UberGROM prepared with the latest available version of Tursi's GROM Simulator (with recovery turned on).

 

A tarball containing the images needed to replicate this is at https://www.disavowed.jp/ti/ubergrom/xbfun-ck.tar.xz

 

This tarball contains XBfun.mpj (the all-in-one project file for TL866 users to correctly program the 1284), 512k.bin (the EPROM image for the 49F040), and xbfun-g.tfi (the GROM dump intended for reload on real iron via gromcfg, in TIFILES format).

 

I hope this helps someone else out ...

[+Ksarul]

Nice analysis! I'm glad someone understands what Gazoo did well enough to troubleshoot his UberGROM images.

[ckoba]

Nice analysis! I'm glad someone understands what Gazoo did well enough to troubleshoot his UberGROM images.

*chuckle* I got very very lucky with this one -- I think if I hadn't had the HRD+ with 9640MENU able to run an EA5 program before control passed to the cartridge, I would not have succeeded.

 

I would very much like to rework his red/yellow board images so that they can be used with Tursi's Multicart menu (mostly because there's a lot of overlap between the various images he released, and I'd personally like to consolidate cartridges). Two things are stopping me:

 

* 16k+ bank-switched images don't appear to play nicely with Multicart without changes in the image code to select the right 8k EPROM bank, and

* Lack of time to reverse-engineer this. My plate is very full; I fixed the XB stuff because I needed to, not because I wanted to

 

Did no-one inherit Gazoo's notes on how he created his cartridge files? I can reverse-engineer what he did (I think, maybe, I understand how he handled multi-bank carts), but I'm not sure it's the most effective use of my time right now.

[+Ksarul]

Except for what you see in the various cartridge building threads, Gazoo didn't make a lot of notes on how he built them. I spent a full day going through all of his computer stuff at his wife's request to save as much as I could. Some data that we haven't seen elsewhare may have been on the HRD 4000 that died during transport, but he was very good at backing up his data--and there wasn't a lot of that type of info in his backups. The source code for his cartridge menu software is in the 512K cartridge thread, as he was teaching several folks how to build those images (between the Games 5 and Games 6 cartridges, IIRC). On the GPL side, he tended to write his code with a hex editor, typing in the object code directly. He was one of the few folks around (and still active in the community) who had a really good grasp of GPL (Rich is another, and Davvel is busy learning it).

[ckoba]

That's really too bad, and I (at least) am taking it as an object lesson in continuity planning -- commit code (source, not binary) publicly and often.

 

I'll go through the 512k cart thread and glean what I can. Thanks for the pointer.

Edited April 27, 2016 by ckoba

[Omega-TI]

Curious, are changes being considered to Gazoo's legacy work, specifically his XB2.7S cartridge? If so, will any planned update(s) still retain 100% backwards compatibility with all existing software?

 

In the active community there are a substantial number of his carts in use, so *IF* any alteration is planned, I think any software variants uploaded or disseminated in any form should clearly be marked stating that it's a derivative work, or given a different name.

 

For me personally, I'm not necessarily opposed to such a thing, because I'll always hold on to my original Gazoo cartridge, but as things evolve and change like they always do, getting another cartridge looks to be the best solution from my end.

[ckoba]

Curious, are changes being considered to Gazoo's legacy work, specifically his XB2.7S cartridge? If so, will any planned update(s) still retain 100% backwards compatibility with all existing software?

 

In the active community there are a substantial number of his carts in use, so *IF* any alteration is planned, I think any software variants uploaded or disseminated in any form should clearly be marked stating that it's a derivative work, or given a different name.

 

For me personally, I'm not necessarily opposed to such a thing, because I'll always hold on to my original Gazoo cartridge, but as things evolve and change like they always do, getting another cartridge looks to be the best solution from my end.

I'm not planning on touching (or even looking too closely at) XB27S. Nor did I mention modifying it anywhere in my post; I said it was having problems coexisting with a certain hardware setup and I had to discontinue using it for the time being.

 

Gazoo did some very unholy things with the powerup hooks, and they conflict with IM's 9640MENU *if* 9640MENU is also called via a powerup hook (for instance, from a Horizon RAMdisk).

 

I can't speak for the intentions of others; I merely "fixed" Gazoo's XB27/XB256/XB-TML image (aka "Extended BASIC Fun") so that it acted like a real UberGROM cartridge. "Real" UberGROM, in this case, means "using Tursi's released UberGROM AVR code". So the recovery-via-spacebar is back, as well as any fixes to the GROM emulation that Tursi made after Gazoo released the initial image. It can now be built the way at least one of the designers of the UberGROM intended: on real hardware, using gromcfg.

 

I expect that three, maybe four people use this image, no code changes were made, and therefore no regression should have occurred.

 

XB27S IMO is great for people who want damned near everything on a single cartridge, and I used it daily myself until it became untenable. We're working through the issues, and I may return to XB27S if/when they are resolved. For the time being, I'm using the other XB compilation. I saw that it didn't conform to the recommended UberGROM setup, I fixed it, it worked, I published it, that's the end of it. Use it or no; your choice.

 

Your takeaway from this thould be "XB27S is incompatible with certain software or hardware in certain situations". If you're an affected user, you'd know it by now. If you're not affected, don't worry about it.

Edited April 27, 2016 by ckoba

[Omega-TI]

Hey Chris,

Excellent work restoring Tursi's recovery feature! Yes, I totally agree, Gazoo did do a few unholy things when he was weaving his otherwise impressive magic. I've read about the HRD problem before, and that, IMHO would make great fix for those who need it, especially since the cartridge currently interferes with the proper operation of that legacy device.

 

Now me, I'm actually HOPING for a specific change in the XB2.7S code... if it can be pulled off. The BOOT/MENU loader routine in the XB2.7S cartridge, from what I understand is limits to 6K of the theoretical 8K that could be used. Can you imagine what a person like InsaneMultitasker could pull off with an additional 2K in his 9640 Menu System?

[ckoba]

Hey Chris,

Excellent work restoring Tursi's recovery feature! Yes, I totally agree, Gazoo did do a few unholy things when he was weaving his otherwise impressive magic. I've read about the HRD problem before, and that, IMHO would make great fix for those who need it, especially since the cartridge currently interferes with the proper operation of that legacy device.

 

Now me, I'm actually HOPING for a specific change in the XB2.7S code... if it can be pulled off. The BOOT/MENU loader routine in the XB2.7S cartridge, from what I understand is limits to 6K of the theoretical 8K that could be used. Can you imagine what a person like InsaneMultitasker could pull off with an additional 2K in his 9640 Menu System?

I suspect the HRD won't be a "legacy device" for much longer, if certain people have their way

 

I have no doubt that XB27 can handle 8k for BOOT/MENU and is artificially limited. I'm also scared to analyze the damned thing beyond "yeah, it's got a GROM labelled MENU that wants to be the first powerup routine run" and "merciful Allah, anything that isn't GROM/ROM is just copying EA5 programs into >A000 and executing it?"

 

And that's as deep as I want to go into XB27S. Because if I go further, it'll mean tearing the whole thing apart and doing it "properly" (where "properly" means "using Tursi's Multicart program to activate EVERYTHING, including the RAM trampoline gunk", which I frankly don't have time for).

 

Others can feel free to dissect XB27S. I don't need 97% of what's on there, and what I do need is either on HxC, HRD, another cartridge compilation, or a combination of all three, so I'm not missing anything by not using it.

 

So it goes. If I need to use other stuff, find it slightly broken, I'll fix it and publish it -- but I'm not going out of my way to wreak havoc on the status quo, no fear.

Edited April 27, 2016 by ckoba

[Omega-TI]

I suspect the HRD won't be a "legacy device" for much longer, if certain people have their way

 

Yeah, ain't it great!

 

I have no doubt that XB27 can handle 8k for BOOT/MENU and is artificially limited.

 

 

I'm hoping that's the case!

 

 

 

If I need to use other stuff, find it slightly broken, I'll fix it and publish it -- but I'm not going out of my way to wreak havoc on the status quo, no fear.

 

No fear here Chris, I'm looking forward to see what you do in the coming years. Besides, every time someone like you, Tursi, InsaneMulttasker and others come out with your stuff, you also give us all a little bit more insight and understanding into this great little computer.

[ckoba]

For what it's worth, I put together a .mpj for the TL866 that preps the 1284 as an UberGROM without messing around with the various fuses. Per Gazoo's PDF, the procedure is to set the fuses twice ... and you apparently are expected to see errors.

 

... well, that doesn't appear to be necessary. My TL866CS was cross-flashed to a TL866A per instructions elsewhere on the forum, which may or may not have something to do with it, but flashing with this .prj throws no errors during the burn process and the result is a working UberGROM 1284.

 

Anyway, the compressed .mpj is at https://www.disavowed.jp/ti/ubergrom/UberGROM.mpj.xz

 

(My previous process involved avrdude and the ISP header. I finally gave in and switched to the 866 -- y'all win.)

[+InsaneMultitasker]

he BOOT/MENU loader routine in the XB2.7S cartridge, from what I understand is limits to 6K of the theoretical 8K that could be used.

 

 

The limitation is certainly artificial. Because BOOT is compiled into two sections, Gazoo split and reserved what seemed like a logical size per file. I believe the current limitation is 6144 bytes (6K) per segment.

 

The total volatile RAM (accessed as 'GRAM') available is 15K. Some of that memory is reserved for the loader routine. It isn't clear to me how the rest of the RAM is being used, if at all. I thought Gazoo sent me the BOOT loader source although my attempts to locate it have not been fruitful.

 

Sadly, the code to these cartridge compilations is either lost or (most likely) residing in MESS folders on his PC.

 

I doubt we have much chance, if any, of ever retrieving those files.

 

 

I have no doubt that XB27 can handle 8k for BOOT/MENU and is artificially limited. I'm also scared to analyze the damned thing beyond "yeah, it's got a GROM labelled MENU that wants to be the first powerup routine run"

Oh! Oh! Dare I spoil some of the mystery ?!?

[ckoba]

Oh! Oh! Dare I spoil some of the mystery ?!?

I'm aquiver with antici ...

[+OLD CS1]

[+Ksarul]

Lots of Rocky Horror fans here, it seems. . .

 

. . .pation.

[budz2355]

I'm not planning on touching (or even looking too closely at) XB27S. Nor did I mention modifying it anywhere in my post; I said it was having problems coexisting with a certain hardware setup and I had to discontinue using it for the time being.

 

Gazoo did some very unholy things with the powerup hooks, and they conflict with IM's 9640MENU *if* 9640MENU is also called via a powerup hook (for instance, from a Horizon RAMdisk).

 

I can't speak for the intentions of others; I merely "fixed" Gazoo's XB27/XB256/XB-TML image (aka "Extended BASIC Fun") so that it acted like a real UberGROM cartridge. "Real" UberGROM, in this case, means "using Tursi's released UberGROM AVR code". So the recovery-via-spacebar is back, as well as any fixes to the GROM emulation that Tursi made after Gazoo released the initial image. It can now be built the way at least one of the designers of the UberGROM intended: on real hardware, using gromcfg.

 

I expect that three, maybe four people use this image, no code changes were made, and therefore no regression should have occurred.

 

XB27S IMO is great for people who want damned near everything on a single cartridge, and I used it daily myself until it became untenable. We're working through the issues, and I may return to XB27S if/when they are resolved. For the time being, I'm using the other XB compilation. I saw that it didn't conform to the recommended UberGROM setup, I fixed it, it worked, I published it, that's the end of it. Use it or no; your choice.

 

Your takeaway from this thould be "XB27S is incompatible with certain software or hardware in certain situations". If you're an affected user, you'd know it by now. If you're not affected, don't worry about it.

 

Wow so I was wondering WHY I could not get DSK1.LOADLEG to load Legends (TI RPG) from BOOT, but when I simply go into XB 2.7 prompt, type in: OLD DSK1.LOADLEG and then RUN it works just fine. But when I go into BOOT and make option C say DSK1.LOADLEG my screen goes crazy and it shows a bunch of random colors and characters and then freezes. I also tried using X DSK1.LOADLEG from Omega's guide, but this must be for an older version of BOOT that I am using. I am also running BOOT off of my Horizon RAMdisk. I assume you just answered my questions without even asking it? ...but I must ask I suppose, is there anyway for me to get around this?

[ckoba]

Wow so I was wondering WHY I could not get DSK1.LOADLEG to load Legends (TI RPG) from BOOT, but when I simply go into XB 2.7 prompt, type in: OLD DSK1.LOADLEG and then RUN it works just fine. But when I go into BOOT and make option C say DSK1.LOADLEG my screen goes crazy and it shows a bunch of random colors and characters and then freezes. I also tried using X DSK1.LOADLEG from Omega's guide, but this must be for an older version of BOOT that I am using. I am also running BOOT off of my Horizon RAMdisk. I assume you just answered my questions without even asking it? ...but I must ask I suppose, is there anyway for me to get around this?

Same problem. IM has a good writeup on the issue at http://atariage.com/forums/topic/222710-horizon-ramdisk-ros-and-cfg/?p=3501704

 

Effective summary is that XB27S sets the banks to 0 during its own powerup vector, running MENU via HRD keeps that powerup from happening, with end result being that the banks are set to random values. You've seen the effect.

 

This also happens with Telco. My interim fix is to use a different Extended BASIC cartridge (in my case, "Extended BASIC Fun").

 

IM will incorporate a workaround into ROS sometime in the future. For the time being, I recommend loading your program directly via XB. This is an XB27S-specific issue; this is not an UberGROM issue.