UberGROM GROM+ROM: what am I missing?

[+mizapf]

If you have a Plato cartridge, could you possibly take a photo from the board so we can see what's inside?

[Flottmann1]

here Pics from the Plato Module

 

 

 

[+arcadeshopper]

here's the csave results

platocart.dsk

[+mizapf]

Cool, thanks, I'm going to test that. If it works, I'll invalidate the current Plato dump in MESS and upload the new cartridge to Whtech (if that's OK for you).

[+Ksarul]

As noted, ISTR that there were a few bytes of this one that had to be changed for 9938 devices. . .

[+mizapf]

Yes, maybe, and if so, we can still create another cartridge including that fix. It's just important for archival purpose that we have a genuine dump.

 

By the way, if that was fixed, how was it included back in cartridges? Or was it only relevant for dump files to be loaded by EA5 or so?

[+Ksarul]

There were several cartridges that crashed when a 9938 was used. TI users had yo use a GRAM device with a modified file set, as did Geneve users. There was no way to modify the physical cartridges, so those without access to some form of GRAM were pretty much out of luck back then if they were using an 80-column device.

[ckoba]

it also has the beginnings of patches for RPI and Plato both.

It looks like you nailed all of the glitches in RPI -- I performed the walkthrough at http://videogamehouse.net/gamemain/cartsnr/rpiratesisle/solution.txt a little while ago and there were no glitches whatsoever. Save and restore were also tested with no issues.

 

I already had Plato pretty much ready to go (those autostart cartridges are nasty until one learns how to turn them back without messing about at >7800), and it's passed a basic test of the German course.

 

Attached are modified binaries, along with python patch scripts that will relocate the binaries to any combination of GROM and ROM banks for use in a multicart. These scripts can be run against either the enclosed binaries or the binaries in an RPK.

 

These can be used in classic99 with the following classic99.ini snippet:

 

[usercart8]

name="whacko"

rom0=8|0000|2000|C:\Program Files\classic99\MODS\multimenu106C.bin

rom1=8|2000|2000|C:\Program Files\classic99\MODS\phm3122c.bin

rom2=8|4000|2000|C:\Program Files\classic99\MODS\phm3189c.bin

rom3=8|7e000|2000|C:\Program Files\classic99\MODS\multimenu106C.bin

rom4=G2|6000|8000|C:\Program Files\classic99\MODS\phm3122g.bin

rom5=G3|6000|A000|C:\Program Files\classic99\MODS\phm3189g.bin

 

(make very certain that the multimenu is in twice, at both the bottom and top of the 512k cart space. classic99 so perfectly emulates the hardware that it has the '378 come up in a random state )

 

I'll be putting together another UberGROM multicart when I find enough GROM+ROM modules to fill up the GROM side of things, but I can cross these two off my list.

 

Cheers

plato_and_rpi_relocated.zip

Edited February 7, 2016 by ckoba

[Tursi]

Nice!

 

Regarding the 378 emulation in Classic99, it's not random, it does fix to the "last" bank on bank-switched ROMs (which that is varies depending on whether it's based on the 74LS378 or 74LS379)... but like the real hardware it doesn't change banks on soft reset, leaving whatever the software set. So even placing the menu at top and bottom isn't a guarantee.

 

But because you have GROM available, you can use a GROM to start the multicart instead. Previously I'd used a GROM powerup routine to set the ROM bank and just let the ROM header take over, but for my last example I created a GROM that explicitly starts the multicart menu from GPL.

 

I really like your trick for avoiding the bases issue (simply ignoring the first two bases), but it should be safe to drop this header GROM in just for the sake of the menu. It also requires a patched multimenu that doesn't ALSO have a header, of course. But with this method no matter the reset, the multicart menu will be guaranteed to re-appear. You don't need to duplicate the menu, either, it just needs to be in the bank toggled by >6000 (which is the first bank on the 512k/378 carts).

 

I haven't updated the download yet because the GROM code needs to be a little smarter - it needs to read the boot address out of the ROM's header. Right now it just assumes it knows the boot address so the GROM version is tied to the ROM version. I made it live at >8000 instead of >6000 to copy your trick at avoiding the module library feature.

 

multimenu_gromboot.zip

 

On the ROM side, the only change is the removal of the link to the program list. Otherwise it would show up twice.

 

The GROM side just has a little program similar to this:

 

 all >20             clear the screen
 st C>6000,>00       write >00 to >6000 to select first ROM bank
 dst C>8300,>6A9A    store the assembly address at >8300 (manually copied from ROM header)
 xml >F0             execute assembly, address at >8300 (never returns)

[ckoba]

I really like your trick for avoiding the bases issue (simply ignoring the first two bases), but it should be safe to drop this header GROM in just for the sake of the menu. It also requires a patched multimenu that doesn't ALSO have a header, of course. But with this method no matter the reset, the multicart menu will be guaranteed to re-appear. You don't need to duplicate the menu, either, it just needs to be in the bank toggled by >6000 (which is the first bank on the 512k/378 carts).

Oh, thanks for that. It seemed the obviously right thing to do -- if the TI module scanner isn't handling the bases correctly, it's better to just use the multicart menu. There's more available bases than there are slots, after all, so it's not as if we were going to run out of bases.

 

On the subject of starting the cartridge menu from the GROM side of things ... I'm ambivalent. It might solve an issue I'm seeing now with TEII, where the loader's scanner is getting confused by a couple of AA01s in cart space that don't have real headers. I'll give it a shot and report results when I'm done.

 

While I'm at it ... may I re-open a bug report? I still have that problem where I'm seeing the hold-space-for-recovery data in the viewer for GROM slots 0 through, oh, seven or eight I think.

 

I'm sort of a stickler for building these carts the old-fashioned way, so my method is to prep the Atmel via the TL866, have an (emulated) floppy with the 8k GROM images ready, then insert the cartridge with the space bar held down. Hit "3" to run GROMCFG and we're good to go ...

 

... except the (expletive deleted) viewer for the lower slots keeps showing the data for the Atmel recovery bootstrap. Obviously loading images into the viewer, and burning them thereby, works just fine -- but I'm doing it blind, because the viewer continues to show the recovery bootloader code for that slot.

 

You won't see this in classic99, because you're never going to invoke the recovery. It's only on real hardware that this happens. And hopefully it isn't just me

 

Would this be classified as a "works as intended", "can't fix", or "fixable bug"?

[ckoba]

On the subject of starting the cartridge menu from the GROM side of things ... I'm ambivalent.

Upon reflection, I'm not ambivalent. I like it. It takes the non-deterministic-between-prod-run '378 powerup behavior out of the equation entirely.

 

One request: please don't deprecate the standalone (ROM-based) multimenu in favor of this. On the off chance that we manage to pack a cart with 15 valid GROM slots, we'd need the menu to be AA01 because we'd be full up on GROM ...

[Tursi]

No, it's not deprecating the ROM-only version, just providing an alternate for cases where it can be done. (the header difference is only two bytes ).

 

As for your bug report -- what you are doing isn't "old fashioned" but the only approach I support. However, it's obviously not behaving in a very useful manner... when I implemented it I just had it override the basics because it was meant solely as an emergency recovery, not so much for configuration. I probably just need to add a way to turn off the override that GROMCFG can trigger so it goes away after you're loaded. That, unfortunately, may take until Summer since I can't work on much right now.

[Tursi]

Also, the menu can NEVER be "AA01" because then it can't find itself on the cart and will crash. It uses AA71 instead. The second byte is arbitrarily defined as 'version' and is meaningless to the console. But you won't run out of GROM slots -- there are 16 bases and 5 slots per base - that's 80 slots. And if you somehow filled them all (not enough flash today, but with a different AVR maybe), you only need 32 bytes or so to insert this header. There's going to be that much free in at least ONE of the GROMs.

 

it's always doable!

Edited February 8, 2016 by Tursi

[+Ksarul]

Looking at this one, did we ever make this into a standard UberGROM image, Tursi?

[Tursi]

I don't see that I was working on anything here... what were we going to do?

[+acadiel]

Hey, Tursi - I'd like to load an UberGROM image into Classic99. Some questions for you -

 

1) I'm a little unclear on the syntax of the [usercart0] stanza for this. Can you please provide an example?

 

Say, I have Tutankham -

 

512K EPROM - tutrom.bin

128K Ubergrom binary - tutgrom.bin

4K EEPROM - tuteeprom.bin

 

2) When I map this, I'm guessing the type of "U" is needed, bu there's also an EEPROM as well at the same time. How is this reconciled?

 

3) Can we maybe show in the section 10.2 of the manual how to map a blank UberGROM as an example?

 

4) Is there a "save UberGROM image" option somewhere in Classic99? I thought I saw that functionality mentioned somewhere.

 

Thanks, Tursi!

[Tursi]

CPU ROM - 8 or 9 depending on your bank order (as normal)

UberGROM - U

UG EEPROM - T

 

Page 45 of the manual.

 

Not being able to test anything, it should be something like this:

 

[userCart0]

Name=Tut Ubergrom

ROM0=8|0000|80000|c:\path\tutrom.bin

ROM1=U|0000|1E000|C:\path\tutgrom.bin

ROM2=T|0000|1000|C:\path\tuteeprom.bin

 

 

Since there's only 120k of GROM space, I assume Tut isn't really 128k. If it is, then you are working with an image that has the AVR code appended, which is not something I support. That said, it should be at the end of the file so just tell Classic99 it's 120k in size and it will truncate the file for you on loading. (If I did it right it will anyway.) I suspect what you've got there is mostly empty space that somebody padded up so they could write a raw AVR.

 

For the only save I've ever discussed, you need to build the image in GROMCFG. You might be able to build it in Classic99.ini first as above but I've never tried that - if it works GROMCFG (which you'll need a way to load) should get the setup out of the EEPROM settings. Since you need a U in there somewhere to turn on the emulation it's worth a try. (To load it from inside the computer, you'd need to split the GROM into 8k chunks). GROMCFG can then save out the single file to disk. This file's only good for loading to UberGROMs though, there's no automatic load in Classic99 at this time - this is because we can already load standard GROM programs in emulation.

[globeron]

Via Ebay     

* TI-99 UberGrom + TL866 programmer + chips (49F040 flash ROM) + Atmel 1284p 

(Atmel AT49F040-90JC 4 MB 512K x 8 CMOS Flash Memory) / Atmel ATMEGA1248P

 

This version of the board does not have in-system programming capability for the 29F040/49F040 flash chips (on the ROM side), but it is possible to program the Atmel1284P (GROM side) in-system (with Tursi's program)

 

https://www.ebay.com/itm/404526231216

 

 

You can swap the chips, or re-program chips with the TL866 programmer  

 

*  Currently Installed in the module is the Education Software Software  

    (video - https://youtu.be/JAo8FWfFmSE)

 

* Additional chips with  XBsuite 2.7 installed  (swap the chips in the module, then you have XB.27)

   Example video: https://youtu.be/99EhDIhLtrM  and  https://youtu.be/SVCmvWH7Yjo

  (note if you have a Speech Synthesizer you can upgrade the XB27 to support Speech at Startup by Gazoo/Tursi.

https://forums.atariage.com/topic/229718-extended-basic-v27-suite-cartridge/?do=findComment&comment=3270711

  

* TL866 Programmer to be used on a PC to re-program the chips for any UberGrom purpose

See also:  https://forums.atariage.com/topic/305712-the-mega-ubergrom-thread-start-here/

 

(or built a 2048K Games 1 module if I am correct - https://forums.atariage.com/topic/231451-2048k-cartridge/)

Edited October 1, 2023 by globeron