MESS and Multi GROM port

[Asmusr]

No, unfortunately not, as 379i does not define a grom_socket. (Also see ninerpedia for a complete list.) Would clearly require a new type.

 

Is it a single ROM circuit on the board? In that case we should also plan for a single ROM dump file.

 

Any progress on defining an RPK type for the new cartridges? I'm not asking for an implementation in MESS at this point, just the specs so I can implement it in my own emulator.

[+mizapf]

Not yet ... sorry, I can't afford enough time right now. I still got some open projects to finish.

[+Ksarul]

Here's a schematic of the ÜberGROM board, Michael. The 512K cartridge board works exactly like the ROM side of this board, as it uses the same bank-switching circuits (it just uses a DIP chip instead of a PLCC chip, and it can be downshifted to sizes as small as 8K).

UberGROM-4 (Final).pdf

[+mizapf]

Hi Jim,

 

thanks for the schematics. So the contents of the ÜberGROM are stored as one big file for the Flash ROM? Can you send me a sample content file?

 

What is the Atmega's task? Bank selection or more?

 

BTW - just my impression - I'm getting slightly dizzy when looking on the schematics because of those semicircles ... you're using junctions points already, so maybe the semicircles could be left away, or rendered much smaller. In the way as shown here, I find it pretty hard to follow lines.

[+Ksarul]

The Atmega actually has the GROM files (120K of GROM) and the logic to emulate the TI GROM addressing. The bank switching for the 29F040 is accomplished using the 74LS378 chip. It extends the ROM banking to 64 8K banks, using non-inverted addressing (the Guidry 64K carts use inverted addressing to allow you to compare/contrast the file types). Any of the game images Gazoo put up here will run on the ROM side of the ÜberGROM (and don't need the Atmel at all). Only the various XB cart images need the Atmel, as they use both ROM and GROM.

[Tursi]

There are no umlauts in UberGROM.

[Asmusr]

There are no umlauts in UberGROM.

 

If we would try to make the RPK file the standard, would you be willing to support it in Classic99?

[Tursi]

I consider it a good standard. It has been on my list for a long time.

 

That said, I wasn't planning on having every type be defined by Mizapf before using it (since Classic99 has many formats that MESS does not), I was planning on using X- tags for my extensions until others decided what was standard.

 

That said, I'm not super fond of the standard that a format defines what kinds of chips to expect -- can't presence in the config file mean presence, and absence means absence (rather than needing a table of cartridge types AND a table of files in the same file?)

 

But whatever, that's what people are using. It's XML, I can support it but still support whatever I need.

[+mizapf]

There are no umlauts in UberGROM.

 

I didn't start with that. See http://en.wikipedia.org/wiki/%C3%9Cber

 

For those who don't have "ü", just ignore the umlaut dots (as it is done usually, anyway ).

 

This reminds me of the film "Brüno" with Sacha Baron Cohen (did not see it, though). He was reported being surprised when he heard people in German-speaking countries pronouncing it, which did not sound like "Broono" as intended. The umlaut was meant to add a European/German look, but it actually changed the way people read it, because "u" and "ü" sound strongly different.

[+mizapf]

As for the RPK format, I have a another suggestion.

 

If we're really considering a standard format, we should probably think about using the ZIP format. The RPK format is still in MESS because I declined to take it out again, contrary to the positions of other devs who favor a common format in MAME/MESS. Accordingly, the TI family is the only part in MESS actually able to process it. I don't believe that RPK will be taken out in foreseeable future, but on the other hand, if the RPK file format ever turns out to block some further development, I'll be in a weak position.

 

The ZIP format simply uses ZIP files to pack the *.bin dumps. For instance, exbasic.zip contains the files "phm3026c.bin", "phm3026d.bin", and "phm3026g.bin". The XML files inside the RPKs are linked to one big XML document, the "software list", as a separate file. The only downside (which I already pointed out to the others, but of no avail) is that you must not rename the ZIP file (which is still limited to 8 characters), and you must not rename the included files either.

 

So if that were a format to support in different emulators, it would simply mean to support ZIP archives of cartridge dumps. The way how the contents are interpreted can still be in an emulator-dependent way, so Classic99 could use an own spec file which does not even need to be XML.

[Tursi]

Regarding "uber", I don't really care. But it's not German, so it doesn't have to follow Wikipedia.

 

Regarding cartridge format: I am (as usual) not really in favor of new formats but if a new one took over before I got around to it, I'd probably implement it.

 

As for the simplification, though, simply having three files doesn't tell you enough about where to load them, and the name-based system that Classic99 uses for guessing (which is just an extension of V9T9's system) is not good enough for all cartridges. So having a separate configuration file included in the archive solves that issue.

 

It's nice that the XML is extensible, meaning we could take RPK and add more descriptions (I know there is some) and even pictures and manuals later. Ideally it'd be nice to just spec out a simpler (fewer files, fewer sections), more flexible (no reliance on pre-defined PCB layouts) XML format and move forward that way. If we could build one as a group that'd be nice!

 

Basically, all I'd like to see is a simple nearly-flat structure, with elements like so:

 

Cart group to define the cartridge.

Summary group to summarize the cartridge (name, manufacturer, release date, known issues, etc)

Manual group to define the manual (link to a PDF in the archive)

Images group to define images (Cover, screenshot, again, link to PNGs in the archive)

 

(I'd like to declare images as PNG and manuals as PDF since both are well supported and well known formats that should last.)

 

Defining the cartridges will take a little work, because we need to decide what goes into them. IMO a cartridge should be feasible to make for any installable software (ie: including side port, OS overrides, etc). So the OS itself could be defined as a cartridge.

 

As a quick over view, my first stab would look something like this:

 

GROM: each entry should define the GROM base, size of the data, and address of the data, and whether it is ROM or RAM. For RAM, a file reference is optional. (The UberGROM would be a different device type and I'm not addressing it in this first pass). So for instance, a normal 1-GROM cartridge would be base 0x9800, 6k in size and loaded at 0x6000. We might also want to support a wildcard for GROM Base since many (like the console GROMs or E/A) will respond at all bases.

 

CPU Memory: each entry should define the load address, data size, paging method, page size, and whether it is RAM or ROM. This should allow max flex. For instance, a 16k AtariSoft cart would have load address 0x6000, data size 16k, paging method of 74LS379, and page size of 8k. The paging schemes I'm aware of would be 74LS379 (inverted write), 74LS378 (non-inverted write), CRU (superSpace), MBX (MBX!), and I think that covers it for the most part..?

 

Classic99 has a lot of other options, but they don't necessarily represent reality as much as ways to make cartridge entries do extra work automatically... the above would cover all the cartridges I can think of and most of the system itself. Defining the ROMs in each ROM rather than in a separate PCB entry leaves it flexible to new designs. (Hell, the above would simplify Classic99's loader too, though I'd have to change the memory handler a little to be more flexible).

 

CRCs could be included for each of the files too, I would suggest in the same entry. We might need flags on both memories as well for whether they are DSR paged (I'm thinking DSR ROMs and pCode).

 

Anyway, kind of hijacking the thread. I guess if we want to talk about this we should move to a new thread.

[+mizapf]

Regarding "über", it is German ... and please, if you borrow words, return them in proper shape when you don't need them anymore.

 

OK then, back to the topic.

 

Actually, while it sound attractive, I think it is not that important to have a common cartridge format for the emulators, except for ease of archiving. As for usage, the number of existing cartridges does not grow, so at some point everyone has all cartridges. We put them on whtech with a notice which emulator takes which format. The only exception are these novel cartridges with bank switching, including the ÜberGROM, but even there, I don't expect too many new editions. If we have a new one, it is pretty simple to pack a new RPK for MESS or to mount it in Classic99.

 

My concern is that we now start long discussions about a suitable format for all emulators, but MESS is not my emulator, so I'd not be well advised to ignore some possibly already existing approaches, ending up in arguments between me and the rest of the MESS devs.

 

For now, one simple way that I see is that the ZIP format would certainly allow to pack metadata into the archive, including the manual, pictures etc., also a XML description like the layout.xml or meta-inf.xml, so this would not bother anyone else. We could end up in ZIP files that could be used in any of our emulations, and we would just have to agree on a file name that suits the softlist definition in MESS. Maybe I can convince the other to finally extend the 8 characters limit some day.

 

As for your suggestions on GROM, ROM etc. this sounds quite reasonable, but you are packing a lot of things into it that is actually a part of the cartridge board, not of the memories. Sounds a bit like a declarative approach to describe a complete cartridge, which would imply considerable changes inside the emulations. On the other hand, we'd not be forced to really support everything in every emulator, so if I, for instance, could not make use of that description in MESS, I'd just fall back to implement the logic. So that is not impossible. Let's keep it on our agenda.

[Tursi]

Regarding "über", it is German ... and please, if you borrow words, return them in proper shape when you don't need them anymore.

"über" is German. "uber" is English. As for the care and feeding of borrowed words, you'll have to talk to the maintainers of Language for that.

 

http://dictionary.reference.com/browse/uber?s=t

 

Can we drop this now?

 

My only comment on the discussion, then, is:

 

As for your suggestions on GROM, ROM etc. this sounds quite reasonable, but you are packing a lot of things into it that is actually a part of the cartridge board, not of the memories. Sounds a bit like a declarative approach to describe a complete cartridge

Yes. Because the file is a representation of a cartridge, not a representation of a handful of unassociated chips.

 

We don't have to settle it now, of course. We don't really have to settle it every, things are not horrible as they stand. But once again you and I stand on opposite views of the purpose of emulation. The truth is I can't do much about it right now anyway, so it's just testing the waters more than anything else.

Edited November 9, 2014 by Tursi

[Gazoo]

I don't care about arguing about what exactly the definition is for a cartridge, I just want to see one that works.

 

It would certainly be wonderful if the ubergrom cartridge device could be added to the MESS emulation, mostly because it would save me a step in the development process. I currently have to assemble my code with MESS because writing to disk is not implemented in Classic99, then use Classic99 to test the cartridge because the ubergrom cart is not supported in MESS.

 

It would be great if you 2 guys could put aside your differences and get together to make both things work on both systems.

 

Gazoo

[+mizapf]

Hi Gazoo,

 

I put the request for ÜberGROM on my list; I'll see whether I can do it within the next few weeks. Can't promise earlier, sorry. By the way, Ksarul named it, if I remember correctly, but this is, admittedly, really a non-problem.

 

Tursi and I don't have so bad differences, just different approaches for emulation. This may mean that we achieve only a limited level of interoperability, but I think we already have a good interchange with TIFILES.

 

My problem is that I have the giant MAME/MESS oil tanker behind me with 49 active contributors at this time, so my agility concerning new formats and suggestions is somewhat limited. But I can try to give it some impulses to the right direction.

[Tursi]

Classic99 writes to disk folders just fine. Just move away from disk images and embrace unlimited disk space.

 

The differences in MESS and Classic99 are not because we have differences with each other, only because we have different goals for our work.

 

By the way, Ksarul named it

Are you just having a go at me on purpose? I'm talking about the GROM, which I first named UberGROM in early 2013 when I released the first video of the code working: https://www.youtube.com/watch?v=CvI05cSEaB4

 

If you were involved back then (and you claim to remember!), do let me know what step I'm forgetting, because although I did originally name it 'GROM+' in my first documentation, I don't recall anyone else suggesting "UberGROM".

[+mizapf]

Tursi,

 

please allow me a short, final comment.

 

1. I did not introduce the writing "ÜberGROM". If you search the forum (unfortunately, the search function does not like umlaute), you can see that "ÜberGROM" has been used at least since April; see http://atariage.com/forums/topic/224389-currently-sold-supported-hardware-for-the-ti-994a/?p=2978195

 

2. As Ksarul was actively discussing in that and other threads I came to believe he was the one who conceived it. I said "if I remember correctly", so this seemed to be wrong. Sorry. If he had been the inventor of that term, the way I wrote it would have simply meant to follow his way, and all others writing "UberGROM" simply lacked the proper key on the keyboard.

 

3. As you obviously created that name, and you prefer "UberGROM", then I'll write "UberGROM".

 

If you agree we'll stop this discussion here.