Jump to content
Omega-TI

Uber Cart Technical Inquiry

Recommended Posts

It's been recently pointed out to me that there is 15K of GRAM that can be exploited in the Uber Carts (like the XB 2.7s cart). If this memory is used, the contents of this space will be lost when the computer is power cycled.

 

My questions are:

 

1) What is the power requirement necessary to maintain this memory?

2) If the power requirement is low enough, could the cartridge be retro-modded to include a CR2032 for possibly six months of program maintenance?

3) Not being familiar with the design, would it only require something simple like cutting a trace or adding a diode and the battery, or would it require more extensive surgery?

 

The possibilities of this are rather exciting, sort of a 'Mini P-GRAM' for the masses.

 

What would you stuff into this space?

 

Share this post


Link to post
Share on other sites

There is very little space left in the case with the chips already in it. You wouldn't be maintaining a low-power RAM here either--the chip you're trying to power is the Atmel1284. I would NOT recommend trying to power it with a 3V battery. I have to look at the data sheet later, but I'm pretty sure the results would be nothing like you are hoping for. . .

Share this post


Link to post
Share on other sites

You have 120k of non-volatile GROM and another 4k of non-volatile EEPROM accessible as GROM --- why are you concerned about preserving the 15k RAM space??

 

/Technically/, you just need to keep the AVR alive, but there's no power management active, so you have to power all the peripherals and the CPU program - a cell battery probably isn't going to give you 6 months. (I worked out the estimated current draw once, but I don't remember anymore).

 

It will run fine off 3v although the clock is configured to be running on 5v. The battery /will/ run it. I just don't think you'll get six months.

 

But again, it doesn't make sense to need to do that - what would you like to accomplish? There's probably another way.

Share this post


Link to post
Share on other sites

There is very little space left in the case with the chips already in it. You wouldn't be maintaining a low-power RAM here either--the chip you're trying to power is the Atmel1284. I would NOT recommend trying to power it with a 3V battery. I have to look at the data sheet later, but I'm pretty sure the results would be nothing like you are hoping for. . .

 

Bummer.... that just blows.

Oh well, loading a program once per session is not that big of a deal, considering how fast one could return back to return to it.

 

Maybe someday those extra large cartridges cases will finally come to fruition... with space for a power outlet facing backwards from the top of the case where the power cord would lay over the vents.

Share this post


Link to post
Share on other sites

 

It will run fine off 3v although the clock is configured to be running on 5v. The battery /will/ run it. I just don't think you'll get six months.

 

But again, it doesn't make sense to need to do that - what would you like to accomplish? There's probably another way.

 

Another guy came up with a fantastic idea.... stuffing BOOT in there. He said that if this could be pulled off, it would lose memory after the computer was shut down, so naturally I'm already putting the cart before the horse and thinking about how to keep the memory active.

 

An INSTANT loading of BOOT on power up would just be too awesome, it would be almost like having a Gram Cracker or P-GRAM card.

Share this post


Link to post
Share on other sites

Hmm Boot incorrectly starts XB and you can test this to see I am right about the Random number generator and pointers not being set at all or incorrectly.

 

I have had many arguments on this one but it still is true that Boot and FW both use a really random GROM address to start execution at.

 

These loaders did not use the Miller Graphics recommended way to start a XB program just to save a few bytes, thus compromised the accuracy on purpose.

Share this post


Link to post
Share on other sites

Hi Rich,

I'm no where near your level of understanding (and never will be) when it comes to the minutiae of how everything works under the TI's floor boards. When it comes to programs, my criteria are really quite simple:

 

1) Is it cool?

2) Is it useful / does it do what I want it to do?

3) Does it actually work?

4) Can I get my hands on a copy?

 

Beyond the criteria I listed, I'm unable to get interested in the fact that 30 years ago some programmers didn't do things the way one company recommended things be done. For better or worse, I'm just happy if it works! :grin:

Share this post


Link to post
Share on other sites

Why not just store BOOT in the ROM side? Is there really not 8k of program you'd be willing to replace?

Share this post


Link to post
Share on other sites

Why not just store BOOT in the ROM side? Is there really not 8k of program you'd be willing to replace?

 

IIRC, BOOT saves it's settings in itself, if it was in ROM there would be no way to update the menu every time you added or removed a program.

Share this post


Link to post
Share on other sites

GRAMDISK the very first version of a Boot like utility was the forerunner of BOOT from Miller Graphics.

 

The GRAMKRACKER had a utility from Miller Graphics to replace a GRAM with MENU and you could write to it as it used GRAM not GROM.

 

I think this later became MENU and also came with the PGRAM and worked with the GRAMULATOR too.

 

OPA also wrote a version like this in the SOB board that came with the TIM card. (9958 VDP chip 192K VDP memory)

 

GRAM is much better then ROM as it is rewritable and has 40K of space vs ROM that only has 8K at a time and is complicated as hell to switch.

Share this post


Link to post
Share on other sites

 

IIRC, BOOT saves it's settings in itself, if it was in ROM there would be no way to update the menu every time you added or removed a program.

 

Right... but isn't it a disk-based program? Simply storing it in GRAM won't fix that problem - you still need to rewrite the save code. If you have to do that anyway, 8k is a safe block size on the AVR's flash to rewrite, and the interface to it is relatively simple (not /quite/ as simple as GRAM, but simpler than disk). My only recommendation would be that it only re-write itself when changes are made, to reduce flash wear, and that should be fine.

 

Do we have source? I can provide a block of sample code that would re-write an 8k block from RAM.

Share this post


Link to post
Share on other sites

(I guess I should be clear... I'm talking about the AVR in all my discussions, not the flash chip.. so when I've said 'ROM' in this discussion, I guess I meant "GROM", which is stored on the AVR flash.)

Share this post


Link to post
Share on other sites

You could put the AVR into the console, using a solution similar to the Zenoboard. You could put it on a PEB board too, for that matter--so you have two possible alternate solutions to the position problem.

  • Like 1

Share this post


Link to post
Share on other sites

Just out of curiosity....

 

Must the grom/avr reside in a cartridge?

Could its functionality be moved into the console to free its dependency on the cartridge?

 

 

You could put the AVR into the console, using a solution similar to the Zenoboard. You could put it on a PEB board too, for that matter--so you have two possible alternate solutions to the position problem.

 

I'm assuming that the 15K would no longer have be a limit then? Theoretically nearly the whole AVR could be used to store USER MODIFIABLE goodies?

 

I'm thinking the average person could easily solder to this....

$T2eC16ZHJIQE9qUHuEt2BRukpph0jw~~60_1.JP

 

...and possibly even to one of these...

A-865.jpg

... mounted on the case to supply backup power from a wall wart.

 

This would open up a new realm of possibilities...

Share this post


Link to post
Share on other sites

My initial tests with the emulation was using it to replace the console GROMs for the MPD. :)

 

 

I've been looking at the cartridge 90 degree connector, as I have a whole box of them. ;) But there is very little clearance around them, you'd have to cut plastic too.

Edited by Tursi
  • Like 2

Share this post


Link to post
Share on other sites

I've been looking at the cartridge 90 degree connector, as I have a whole box of them. ;) But there is very little clearance around them, you'd have to cut plastic too.

 

Yeah, I was thinking that too. With 128K of space available on the AVR, a mini-widows type GUI could actually become a viable possibility. Different sections and features could be added one at a time, as developed, over months or years. That would certainly keep things fresh and exciting.

Share this post


Link to post
Share on other sites

Hmm Boot incorrectly starts XB and you can test this to see I am right about the Random number generator and pointers not being set at all or incorrectly.

 

I have had many arguments on this one but it still is true that Boot and FW both use a really random GROM address to start execution at.

 

These loaders did not use the Miller Graphics recommended way to start a XB program just to save a few bytes, thus compromised the accuracy on purpose.

 

You keep harping on this point, Rich. Unfortunately, everyone's experience is that BOOT works fine on loading XB programs. The only problem I've ever encountered was when I was trying earlier versions of RXB with BOOT. BOOT would just refuse to load ANY XB program when RXB was the active version of XB. Fortunately, you've recently fixed the bug in RXB that was causing this and it works correctly now. Thanks for that!

 

The so called 'problem' you describe has never manifested itself other than the example I've provided above. I've been using BOOT for about 25 years and have never encountered the problem you describe. I'll let you know if I ever find an XB program that doesn't correctly load through BOOT with XB versions other than RXB, but it hasn't happened yet. :)

 

Gazoo

Share this post


Link to post
Share on other sites

 

You keep harping on this point, Rich. Unfortunately, everyone's experience is that BOOT works fine on loading XB programs. The only problem I've ever encountered was when I was trying earlier versions of RXB with BOOT. BOOT would just refuse to load ANY XB program when RXB was the active version of XB. Fortunately, you've recently fixed the bug in RXB that was causing this and it works correctly now. Thanks for that!

 

The so called 'problem' you describe has never manifested itself other than the example I've provided above. I've been using BOOT for about 25 years and have never encountered the problem you describe. I'll let you know if I ever find an XB program that doesn't correctly load through BOOT with XB versions other than RXB, but it hasn't happened yet. :)

 

Gazoo

Yes. Continuing to throw the Virgin off into the Volcano continues even though we forgot long ago why we need to do it.

 

I suppose the Random numbers not be properly initialized is not an issue as RXB has a faster different Random Number Generator now.

(Only RXB has this feature.)

 

And when someone proposes a standard it would be nice to use that standard.

 

Today it may not matter so much as we are so few so I guess it does not matter anymore.

 

(Any you have creates a very impressive array of carts.)

Edited by RXB

Share this post


Link to post
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...