MultiCart menu Software

[Tursi]

I know somewhere we had a thread for this, but I can't find it, so, new thread.

 

In prep for the upcoming cartridge, I updated the Multicart Menu to also work with GROM programs:

 

 

Source and notes included.

 

Multicart.zip

[Tursi]

This is as good a place as any to blog, I suppose. I figured I'd do a simple presentation this year of the new cart and some of the things that it can do. We'll see how far I get with the two days I have left.

 

Since everyone likes Multicarts (and they are a quick proof of concept), that was where I started. In addition to the above changes to the Multicart menu, I also chose and built some test ROMs.

 

For the GROM side, I chose RXB 2012 (to prove it can be made into a cart), Parsec, Editor/Assembler Complete (my E/A hack), and a GPL-loaded copy of my GROM configuration tool. This totals the full 120k of available GROM space.

 

For the ROM side, I have the Multicart menu, Mr Chin, two of my music demos (Axel F and Chuck Rock), and of course the ROM files for Parsec (one bank) and RXB (two banks). This totals only 128k of the 512k ROM available on the new cart, but I needed to make sure I had the parts on hand.

 

First I needed to lay out the files. I started with RXB. I placed its GROMs in the first 5 slots of the GROM chip, and its ROM pages in the top two pages of the ROM chip. I did this because it does ROM bank select using >6000 and >6002 -- and this means I didn't have to find its paging code and patch it. The GROM code can sit in any slot, since the AVR emulation allows mapping any slot to any GROM address.

 

I placed Parsec next, there are three slots to the GROM, and only one bank of ROM code. The Editor/Assembler Complete module uses four slots of GROM, and I've reserved the last three for my GROM Configuration tool. The configuration tool is a ROM program, but I will use the GPL loader just to pad it out.

 

For Mr Chin, "AxelF", and "Chuck Rock", I created 379-style loaders using Classic99. RamusM's observations that the 379-cart builder was broken was indeed accurate - that will be fixed in the next release. Finally, I placed the multicart as the first bank in the ROM.

 

I set up the GROM so that each program lived at >6000 in GROM space, as it must, and on a different GROM port. Then came the fun stuff.

 

One of the long-standing concerns with the old multi-carts was that of what bank was active on power up. The multicart menu had to be placed in the powerup bank, which, while deterministic, was not predictable before the first time the cart was used. Furthermore, after a cartridge was selected, the bank was essentially locked until a power cycle reset it. GROM allows us a power-up initialization routine, so the first thing I did was implement one in the first GROM. RXB had some extra space near the end that I used to add this code as a powerup:

 

ST @>601E,>00
DST *>8372,*>8373
DECT @>8372
RTN

The ST is all that's needed to select the ROM bank, and this guarantees that on every reboot the multicart page is selected before the main menu is built. (The rest of the code is for popping the GPL stack and returning).

 

Of course, the ROM page is going to matter to RXB, REA (part of the same set), and Parsec, as well. So for each of those, I did a small patch to their startup routine to set the valid ROM page, and then jump to the original entry point. For example, for RXB:

 

ST @>6000,>00
BR @>6372

It wasn't hard to find a few spare bytes for these in each one. Parsec doesn't page at all, so as long as the correct ROM is there, it works.

 

On my first test run of this, I found that Parsec doesn't work when not at the default GROM base of >9800. Rather than patch it, which I don't have time for, I placed it at >9800 and moved RXB to >9804. RXB behaves itself and works fine there (as does Editor/Assembler at >9808). This worked fine.

 

For the ROMs, less work was required. RXB was placed at the top of the ROM, so putting the two banks in the right order was the only task there. Parsec only needed the right bank paged in before the GROM started, as noted above. And for Mr Chin, AxelF and Chuck Rock, the 379 loaders all assumed that they "owned" the cart, so the loader code was patched for their actual banks, manually. (The 379 loader is very fast, I note.. I never used it much before. All the copy code runs in scratchpad, and it's CPU->CPU, but I was still surprised. )

 

So that was what I did last night. Tonight I upgraded the Multicart menu to support GROMs. This was reasonably straight-forward. I added a new search loop that checked all GROMs (including the console GROMs) and the first 16 bases, and added any found programs to the list. This causes a slight waste of processing since we know that the console GROMs will appear one every base and TI BASIC will be tested 16 times, but the impact was too small to worry about optimizing. It turns out that launching GPL if you don't need to come back is very simple -- if you haven't broken the GPL workspace, anyway. All you have to do is switch the workspace to >83E0, load the GROM base into R13, load the GPL address into R6, and branch to >0060. This starts the GPL interpreter with the addresses loaded. This does assume that the GPL parts of scratchpad are intact, but seems to work fine here.

 

Next task is construction.. then if I have time, goodies.

[+acadiel]

Dude, I can't wait to see this in person!

 

You rock!

 

 

[RXB]

I know somewhere we had a thread for this, but I can't find it, so, new thread.

 

In prep for the upcoming cartridge, I updated the Multicart Menu to also work with GROM programs:

 

multigrom.jpg

 

Source and notes included.

 

Multicart.zip

 

OMG cool waited years for this to happen!

[+Ksarul]

Excellent! It looks like this one is finally reaching completion (does the 379 cart builder work with the 378 cartridges too, or will it need a modification for that?). I only ask because the most recent boards you have are 378-based on the ROM side. . .

[Tursi]

Are they? I didn't think we had settled. The 379 builder expects that the inverted line is used for address line select (such that toggling >6000 gives you the highest addressed bank in the ROM). Looks like the 377 and 378 drop the inverted outputs (I really wish we'd just done that in the first place... ) So.. no, as it stands, the builder would copy the data from the wrong banks and the result would fail. I'll have to add inverted and non-inverted versions, and the cartridge builder will have to know what they are using.

[Tursi]

Last night I was tied up until after 11pm, so didn't get much time, but I attempted to implement autostart. Using Thierry's page as my guide, I implemented the "translation" hook to start up the cartridge.

 

Unfortunately, this hook runs /before/ the power-up routines, making it not only unsuitable but non-functional (because the ROM page select didn't happen). I sent a note off to Thierry so he can update his docs, and moved it into the powerup routine.

 

The ROM starts, of course, but I was not able to clean up the GROM interpreter so that launching GROM apps from the menu still worked (I would probably need to properly finish the inventory). Since I don't have time for that, I'm going to just cheat a bit. My main reason for auto-start was because the program selection menu was kind of ugly, showing the multicart, whatever GROM was active, and Review Module Library. With everything in the Multicart menu, that's all I really want to show up. So I am going to just cheat - I will hack the headers of the GROMs so that they don't show titles to the console anymore, and modify my multicart menu slightly to recognize the hacked headers as valid. That will allow you to "hide" titles from the console and still have them show in the menu with a simple tweak.

 

I'm down to the wire, so I probably won't be able to show off any of the GROM's I/O capability, like I hoped to. With 4 analog inputs and four digital I/O pins, plus a UART, you can actually do quite a bit. But tonight will have to be dedicated to getting the files into a physical cartridge so I can demo the concept, at least. YouTube will have to cover the rest, eventually. Besides, I'll keep my demo short so we can hang out after it.

[Tursi]

For my last day, I attempted to finalize the software, and clean up the menus. I wanted only the multicart to show on the TI's menu, but still be able to see all the entries on the Multicart menu. I added a couple more hide options, and after some frustrating fatigue-related issues, got that working.

 

Then it was time to program the chips. I repeated the 128k 4 times to get a 512k ROM, and programmed the flash chip for that. (I only had a 379 decoder chip, rather than the 378 needed for 512k). To program the AVR, I converted a hex file dump to binary using objcopy - a GNU tool - and then patched the 112k of GROM I had into it (I didn't need the last 8k bank).

 

Having built the cartridge, I ran into a problem - booting it was unreliable. When it did boot -- at least on my system - it worked quite well. Unfortunately it failed completely at the faire.

 

My supposition is that it's a power issue, since it works reliably in my dev board with external power. I have a couple of ways to prove then, and a couple of ideas for countering it. Stand by. I'll YouTube when it works.

[+InsaneMultitasker]

Having built the cartridge, I ran into a problem - booting it was unreliable. When it did boot -- at least on my system - it worked quite well. Unfortunately it failed completely at the faire.

 

My supposition is that it's a power issue, since it works reliably in my dev board with external power. I have a couple of ways to prove then, and a couple of ideas for countering it. Stand by. I'll YouTube when it works.

Now now, Tursi. Your booting worked exactly as should be expected -during- a Chicago TI Faire. Upon your return home, you will find that all hardware and software gremlins have mysteriously disappeared. It is a phenomena to be embraced and cherished by all who attempt hardware or software feats during this special time of the year.

[+acadiel]

Now now, Tursi. Your booting worked exactly as should be expected -during- a Chicago TI Faire. Upon your return home, you will find that all hardware and software gremlins have mysteriously disappeared. It is a phenomena to be embraced and cherished by all who attempt hardware or software feats during this special time of the year.

 

Yes. I likewise had a cart (that I've never had a problem with) fail at the Faire. I cleaned the contacts of the 49F040 (they had oxidized) and it booted right back up. So, when we use Ksarul's stock of 49F040's, we need to make sure to drag them over a piece of sandpaper before programming/installing them.

[+acadiel]

For my last day, I attempted to finalize the software, and clean up the menus. I wanted only the multicart to show on the TI's menu, but still be able to see all the entries on the Multicart menu. I added a couple more hide options, and after some frustrating fatigue-related issues, got that working.

 

Then it was time to program the chips. I repeated the 128k 4 times to get a 512k ROM, and programmed the flash chip for that. (I only had a 379 decoder chip, rather than the 378 needed for 512k). To program the AVR, I converted a hex file dump to binary using objcopy - a GNU tool - and then patched the 112k of GROM I had into it (I didn't need the last 8k bank).

 

Having built the cartridge, I ran into a problem - booting it was unreliable. When it did boot -- at least on my system - it worked quite well. Unfortunately it failed completely at the faire.

 

My supposition is that it's a power issue, since it works reliably in my dev board with external power. I have a couple of ways to prove then, and a couple of ideas for countering it. Stand by. I'll YouTube when it works.

 

I can vouch that I did, in fact, see RXB working once at the Faire in cart format, before the cart went on the fritz.

 

Tursi, I'd be curious if you did a byte compare on your 1284 and F040 and see if either/or got corrupted, since they refused to work in my board as well.

(You did have a hacked 379 though.... and I had the 378 in mine.)

[Tursi]

My ROM definitely wouldn't work with the 378, because my banks would be in the wrong place, and without my GROM powerup link, the wrong bank would be visible in either case. (I did /not/ lay out my ROM to assume the powerup bank, that's the joy of having the GROM side. ) the GROM should work, of course.

 

I'm not going to bother testing for corruption until I see it fail under known circumstances, ie: external power. But we definitely need to know if corruption can occur that easily.