Jump to content

Photo

UberGROM GROM+ROM: what am I missing?


66 replies to this topic

#51 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,423 posts
  • Location:Germany

Posted Sun Jan 31, 2016 5:19 AM

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



#52 Flottmann1 OFFLINE  

Flottmann1

    Chopper Commander

  • 119 posts

Posted Sun Jan 31, 2016 8:17 AM

here Pics from the Plato Module

 

P1170024_2160x1620.jpg

 

P1170023_2160x1620.jpg

 

P1170017_2160x1620.jpg



#53 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 3,949 posts
  • Location:Portland, Oregon USA

Posted Sun Jan 31, 2016 4:08 PM

here's the csave results

Attached Files



#54 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,423 posts
  • Location:Germany

Posted Sun Jan 31, 2016 4:45 PM

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).



#55 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,917 posts

Posted Sun Jan 31, 2016 4:48 PM

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



#56 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,423 posts
  • Location:Germany

Posted Sun Jan 31, 2016 4:55 PM

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?



#57 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,917 posts

Posted Sun Jan 31, 2016 6:43 PM

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.



#58 ckoba OFFLINE  

ckoba

    Moonsweeper

  • Topic Starter
  • 271 posts

Posted Sun Feb 7, 2016 1:19 AM

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://videogamehous...le/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 icon_smile.gif )

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 icon_smile.gif

Attached Files


Edited by ckoba, Sun Feb 7, 2016 1:21 AM.


#59 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,353 posts
  • HarmlessLion
  • Location:BUR

Posted Sun Feb 7, 2016 7:15 AM

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.

Attached File  multimenu_gromboot.zip   2.79KB   19 downloads

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)


#60 ckoba OFFLINE  

ckoba

    Moonsweeper

  • Topic Starter
  • 271 posts

Posted Sun Feb 7, 2016 7:58 AM

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 icon_smile.gif

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

#61 ckoba OFFLINE  

ckoba

    Moonsweeper

  • Topic Starter
  • 271 posts

Posted Sun Feb 7, 2016 8:08 AM

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 ...

#62 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,353 posts
  • HarmlessLion
  • Location:BUR

Posted Sun Feb 7, 2016 8:12 PM

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.



#63 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,353 posts
  • HarmlessLion
  • Location:BUR

Posted Sun Feb 7, 2016 8:16 PM

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 by Tursi, Sun Feb 7, 2016 8:17 PM.


#64 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,917 posts

Posted Thu Feb 8, 2018 8:40 PM

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



#65 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,353 posts
  • HarmlessLion
  • Location:BUR

Posted Fri Feb 9, 2018 3:35 PM

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



#66 acadiel OFFLINE  

acadiel

    Stargunner

  • 1,445 posts
  • www.hexbus.com
  • Location:USA

Posted Tue Mar 13, 2018 3:45 PM

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!



#67 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,353 posts
  • HarmlessLion
  • Location:BUR

Posted Wed Mar 14, 2018 12:42 PM

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. :)






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users