Jump to content
IGNORED

A78 header changes


GroovyBee

Recommended Posts

2 hours ago, TailChao said:

I think it's a good idea to borrow the fallback behavior from the iNES -> NES 2.0 transition, where if a cartridge doesn't need any of the new header format's features it can still load in older emulators. So what's everyone doing?

Yes please -- if there is a way to have emulators not *require* an update, that is clearly the best.

 

For 7800 in Argon, we're using MAME with enhancements. So if someone updates MAME, we would have eventually picked it up, but think of other emulators that may not be able to be easily updated (for example, baked into someones firmware).

 

 

Link to comment
Share on other sites

On 3/7/2022 at 4:36 PM, RevEng said:

FWIW, I don't think a field addition should be done *without* increasing the version byte. So reserving bits to indicate the presence of new field isn't necessary, and honestly not a versioning alternative I want to take on, because then the header parsers need to follow some chain of breadcrumbs whenever you decide to introduce a new field. I agree there's an argument to be made that banksets (or anything else new) doesn't need to go in cart-type, since the implementation hasn't yet been made public, and what we're proposing is deprecating cart-type with the new mapper word.

 

[edit reply to your edit comment ;) I'm not talking about doing away with the cart-type word. It would still exist in the new version header; it would just be ignored by newer emulators and flash carts that understand the new header version.]

 

 

I felt like an entirely new format was a bigger sell but if you and @batari and @TailChao are on board, it is certainly fine with me.

 

I think my main thing is I don't want us to crash into the 16-bit brick wall that is quickly approaching. I guess it won't be the end of the world if we do crash into it. But with a new mapper and a new sound chip being added, it feels like a good time to plot a course around it.

 

I wrote most of this before @TailChao's comment #74.

 

I propose the new format have 3 variables to replace the current cart type field:

  1. $40-$41: bankswitching scheme (current possibilities: none, Atari SuperGame, Activision, Absolute, SOUPER, bankset)
  2. $42-$43: behavior of $4000-$7FFF (current possibilities: none, POKEY, 16K of ROM, Bank 6, 16K of RAM, Fractalus-style mirrored RAM, SOUPER RAM)
  3. $44-$45: behavior of $04xx (current possibilities: none, POKEY@450, 2xPOKEY, YM2151, Covox, SN76489)

Each of those to be indexed, not bitmapped. For existing capabilities there will be a clear map from the existing cart type bits to the new values. The important difference is that the new scheme provides a lot of headroom.

 

New headers should continue to populate the existing cart type field where possible for compatibility.

 

The number of combinations that don't make sense is much smaller but still non-zero (e.g. Absolute bankswitching with Bank 6 at $4000). I don't see this as a big problem. Just have the specification for Bank 6 at $4000 stipulate that its behavior is undefined unless paired with a bankswitching scheme that has a bank 6.

 

 

Link to comment
Share on other sites

I'm going to start off by saying that I'm very glad we have a conversation going on with header stakeholders. I often have opinions on how things should be, and talk plainly about those opinions, but that in no way should be taken as not valuing other opinions, or not being open to other possibilities. I am also open to plainly being told I'm wrong. (hopefully with the reasons provided. :))

 

With that... I think extra fields with optional features is just recreating the bitfield mess, albeit to a lesser degree (as you acknowledge, Pat) While the mapper-index-only approach is very expansive, it's strength is that it defines hardware that exists unambiguously, and because of that it's simple for an implementation to parse - an array of features indexed by the mapper, or a large case statement is all you need. Extra features fields put us back into possibly non-existing hardware combinations (Activision+Mirror Ram for example, but there are less obvious ones too) along with the header-parser needing to ferret out stuff that can't be supported. Non-existing hardware isn't the case with TailChao's proposal of features, since he specifies it as mapper-specific flags, but here we're still complicating the parser.

 

The Extended Descriptors proposal makes sense to me, though I think to go all the way we need some mechanism to make a distinction between cart-rom and non-cart-rom data. (like tracklists)

Link to comment
Share on other sites

1 hour ago, Pat Brady said:

I think my main thing is I don't want us to crash into the 16-bit brick wall that is quickly approaching. I guess it won't be the end of the world if we do crash into it. But with a new mapper and a new sound chip being added, it feels like a good time to plot a course around it.

Thing is that's only one wall, there's lots more.

 

 

1 hour ago, Pat Brady said:

I propose the new format have 3 variables to replace the current cart type field:

  1. $40-$41: bankswitching scheme (current possibilities: none, Atari SuperGame, Activision, Absolute, SOUPER, bankset)
  2. $42-$43: behavior of $4000-$7FFF (current possibilities: none, POKEY, 16K of ROM, Bank 6, 16K of RAM, Fractalus-style mirrored RAM, SOUPER RAM)
  3. $44-$45: behavior of $04xx (current possibilities: none, POKEY@450, 2xPOKEY, YM2151, Covox, SN76489)

Each of those to be indexed, not bitmapped. For existing capabilities there will be a clear map from the existing cart type bits to the new values. The important difference is that the new scheme provides a lot of headroom.

Using the $4000 - $7FFF and $04xx regions' behavior as global options is going to run into the same issue with the current format. Not all cartridges are actually able to support certain configurations and having these as bitfields for really overloaded ones like SUPER (or say - if that's forked into DRAGONFLY, which seems to be adding support for all the sound chips ever designed) makes sense looking forward.

 

Let's look at the current distribution of cartridge designs and their pertinent optional features...

 

  • 16K - 32K (ROM ONLY)
    • EXRAM @ $4000
      2KB - 16KB SRAM
    • EXRAM/A8 ('Mirror RAM') @ $4000
      2KB - 8KB SRAM
    • POKEY @ $4000
  • 48K (ROM ONLY)
  • SUPER
    • EXFIX @ $4000
      [LAST BANK - 1]
    • EXRAM @ $4000
      2KB - 16KB SRAM
    • EXROM @ $4000
      16KB ROM (for 144KB cartridges)
    • POKEY @ $4000
    • POKEY @ $0450 - $045F (migratory chip from XBoard / XM)
    • POKEY @ $0440 - $044F (...)
    • YM2151 @ $0461 - $0462
    • COVOX
    • DCSG / SN76489
    • SAA1099
    • YM2413
    • PC-SPEAKER
    • FARTS
  • SOUPER
    • CoreTone / BupChip
  • ABSOLUTE
  • ACTIVISION

 

So I don't think it makes sense for, say - Mirror RAM to even be considered an option for ACTIVISION cartridges which have a completely different layout. If you want to handle worst case, I'm probably not the only one who'd design convoluted mappers like this.

 

One thing I've seen in the emulation of other platforms is the ability to "insert" passthrough cartridges during the loading process. The equivalent here would be to have the A78 format support a High Score Cartridge, which you can load and then insert a game into rather than using the "drop each device on the bus" setup we have now. This is far easier from a software maintenance / organization angle and better replicates what the hardware is actually doing.

 

 

29 minutes ago, RevEng said:

Extra features fields put us back into possibly non-existing hardware combinations (Activision+Mirror Ram for example, but there are less obvious ones too) along with the header-parser needing to ferret out stuff that can't be supported. Non-existing hardware isn't the case with TailChao's proposal of features, since he specifies it as mapper-specific flags, but here we're still complicating the parser.

lmao, I was typing the above as your reply showed up and somehow we landed on the same example.

 

Here's the thing with the ROM parser though, I don't think using mapper-specific fields makes it all that convoluted. Again, I didn't fork from MAME so I don't have the same architectural baggage. But I think a setup like...

class Cartridge {
	public:
		Cartridge(void){ };
		virtual ~Cartridge(void){ };

		virtual bool open_cdf(char *pszBase, FILE *pCDF) = 0;
		virtual bool open_a78(FILE *pA78, uint8_t *pHeader, uint32_t uiLen) = 0;
		virtual bool open_bin(FILE *pBIN) = 0;
		virtual void close(void) = 0;

		void connect(Sally *pSally, Maria *pMaria) { ... };
		virtual void reset(void) = 0;
		virtual void run(uint32_t uiMCLK, uint32_t uiPHI2) = 0;

		virtual uint8_t read(bool bMaria, uint16_t usAddress, uint8_t ucLast) = 0;
		virtual void write(uint16_t usAddress, uint8_t ucData) = 0;
		...
};

...is pretty straightforward in terms of bringing up a particular mapper with more than one loading format. Each mapper type should be responsible for managing its own dependencies - not one monolith loader.

 

 

29 minutes ago, RevEng said:

The Extended Descriptors proposal makes sense to me, though I think to go all the way we need some mechanism to make a distinction between cart-rom and non-cart-rom data. (like tracklists)

Right, but this should be all mapper-pertinent too - I'm just dedicating a larger segment for that type of data (i.e. you have one segment of feature bitfields and then a larger segment of - when certain bitfields are set - extra data for them). I don't think Banksets is going to use a BupChip.

Link to comment
Share on other sites

1 hour ago, RevEng said:

With that... I think extra fields with optional features is just recreating the bitfield mess, albeit to a lesser degree (as you acknowledge, Pat) While the mapper-index-only approach is very expansive, it's strength is that it defines hardware that exists unambiguously, and because of that it's simple for an implementation to parse - an array of features indexed by the mapper, or a large case statement is all you need. Extra features fields put us back into possibly non-existing hardware combinations (Activision+Mirror Ram for example, but there are less obvious ones too) along with the header-parser needing to ferret out stuff that can't be supported. Non-existing hardware isn't the case with TailChao's proposal of features, since he specifies it as mapper-specific flags, but here we're still complicating the parser.

 

So, for Activision+Mirror RAM — that's something that doesn't exist, and probably never will. But what I'm saying is: we don't need to even think in terms of the possible combinations. It's much easier to just think about each of the 3 aspects individually. Any list of combinations will ultimately map back to values for the 3 aspects anyway.

 

My particular case is a 32K ROM that needs cart RAM. I believe that is a completely reasonable thing to do, 32K ROM is universally supported, cart RAM is universally supported, and the cart type bitmap even allows cart RAM to be specified independently. But this combination not universally supported, because some implementations apparently parse the cart type bitmap back to a list of known existing hardware, and the list of known existing hardware does not include 32K+RAM. So now any implementation that keeps such a list of known hardware combinations needs to be updated for this new combination, and meanwhile I distribute 2 different versions of my ROM.

 

There's no need for the parser to ferret out stuff that can't be supported, or things that are not clearly defined (e.g. SOUPER RAM with anything other than SOUPER bankswitching). Just document that the behavior of Bank 6@$4000 is undefined unless paired with a bankswitching scheme that has a bank 6, and the behavior of SOUPER RAM is undefined unless paired with SOUPER bankswitching.

 

On the other hand, if we go down the path of explicitly listing every allowed combination, then any time somebody uses any new combination, then every emulator and every flashcart will need to be updated. Even if they already support all of the features used.

 

EDIT: I'm going to work up an in-between proposal.

Link to comment
Share on other sites

38 minutes ago, TailChao said:

Let's look at the current distribution of cartridge designs and their pertinent optional features...

 

  • 16K - 32K (ROM ONLY)
    • EXRAM @ $4000
      2KB - 16KB SRAM
    • EXRAM/A8 ('Mirror RAM') @ $4000
      2KB - 8KB SRAM
    • POKEY @ $4000
  • 48K (ROM ONLY)
  • SUPER
    • EXFIX @ $4000
      [LAST BANK - 1]
    • EXRAM @ $4000
      2KB - 16KB SRAM
    • EXROM @ $4000
      16KB ROM (for 144KB cartridges)
    • POKEY @ $4000
    • POKEY @ $0450 - $045F (migratory chip from XBoard / XM)
    • POKEY @ $0440 - $044F (...)
    • YM2151 @ $0461 - $0462
    • COVOX
    • DCSG / SN76489
    • SAA1099
    • YM2413
    • PC-SPEAKER
    • FARTS
  • SOUPER
    • CoreTone / BupChip
  • ABSOLUTE
  • ACTIVISION

 

You list 16K-32K with EXRAM@$4000 as a possibility. Well, thank you for including that, and thankfully a7800 and apparently Dragonfly support it, but not everything does.

 

AFAIK there's not much activity on Absolute and Activision bankswitching. So I don't particularly care what happens to those. SOUPER is currently used only for R&V, and from what you've described, it was sort of designed around what R&V needed. So it seems reasonable for it to remain as a single configuration too.

 

We do know that bankset is coming and will likely use many of the same variations as SUPER.

 

48K can be seen as a 32K cart with EXROM @ $4000.

 

So here's an updated proposal: have 2 bytes to specify mapping type (we already agreed on that). Have another 4 bytes for mapper-specific options. For 16-32K, SUPER, and bankset, the mapper-specific options will be divided into 2 fields as I described above (2 bytes for what's at $4000, 2 bytes for what's at $04x0), and these options will be consistent across those 3 mapper types.

 

EDIT: this way I get what I want, which is to not have to worry about whether my combination of features that work together is in somebody else's list of blessed combinations, and you get what you want, which I think is to avoid the possibility of specifying combinations that don't make sense.

  • Like 1
Link to comment
Share on other sites

2 minutes ago, Pat Brady said:

You list 16K-32K with EXRAM@$4000 as a possibility. Well, thank you for including that, and thankfully a7800 and apparently Dragonfly support it, but not everything does.

This was also used by Bob's old Defender demo. I'm not sure why you'd need to make multiple binaries with different headers though - if an emulator doesn't allow a mapperless game with EXRAM you should be able to tag it as a SUPER Cartridge with EXRAM. There shouldn't be a lower bound on ROM size, and if there is - that's a loader fault.

 

 

2 minutes ago, Pat Brady said:

SOUPER is currently used only for R&V, and from what you've described, it was sort of designed around what R&V needed. So it seems reasonable for it to remain as a single configuration too.

It was designed for that game's needs, yes - but putting my own bias aside, I think it's still the best general purpose extension to Atari's mapping setup. You have far more flexibility than what's been proposed so far in Banksets - for both the game software and manufacturing. But adopting it requires going pure assembly, only one flavor of audio expansion is (formally) supported, and there's no broad emulation outside of BupSystem and the MiSTer.

 

But will it ever be extended?

 

No, probably not. If I were to come back to the hardware it'd be with a finalized version of PMC1, which I wouldn't expect to see any adoption of either.

 

 

2 minutes ago, Pat Brady said:

48K can be seen as a 32K cart with EXROM @ $4000.

That's also how they're manufactured - a 16KB and 32KB ROM with different chipselect polarities.

 

 

27 minutes ago, Pat Brady said:

On the other hand, if we go down the path of explicitly listing every allowed combination, then any time somebody uses any new combination, then every emulator and every flashcart will need to be updated. Even if they already support all of the features used.

I don't really see this as an issue, since anything we're adding should probably fall under the domain of not existing or not being fully supported already. Most of the cartridge flavors' feature sets outside of dumping entire audio chips on the bus aren't incredibly complex to implement either.

  • Like 1
Link to comment
Share on other sites

OH NO - BONUS CONTENT!

 

The current format has had fixed sizes for expansion memory on the cartridge since day one, usually to fill an entire segment. This isn't actually faithful to the manufactured ROM Only and SUPER boards which have a range of sizes (2KB, 8KB, 32KB with half disabled).

 

So another thing to keep in mind, as this has hit other formats - do we care about these things?

Is the goal to just get the game to work (which is understandable, all things considered) or accurately describe what's in the plastic shell?

  • Like 1
Link to comment
Share on other sites

1 minute ago, TailChao said:

This was also used by Bob's old Defender demo. I'm not sure why you'd need to make multiple binaries with different headers though - if an emulator doesn't allow a mapperless game with EXRAM you should be able to tag it as a SUPER Cartridge with EXRAM. There shouldn't be a lower bound on ROM size, and if there is - that's a loader fault.

 

It's been a while, but IIRC I tried that, and eventually gave up and started making ROMs padded out to 128k. Apparently even 64K+EXRAM does not work because that is also not in the list of things that exist.

 

1 minute ago, TailChao said:

I don't really see this as an issue, since anything we're adding should probably fall under the domain of not existing or not being fully supported already. Most of the cartridge flavors' feature sets outside of dumping entire audio chips on the bus aren't incredibly complex to implement either.

 

Another example would be a 48K ROM with POKEY@$0450. Or a 32K ROM with YM2151. Those are trivial to implement (assuming POKEY@$0450 and YM2151 are already supported) but are not in the list of things that currently exist. I just see no reason to actively prevent them from working.

 

My updated proposal (bottom of post #82) differs from your proposal in only 2 ways:

1. Enhancements for SUPER also apply to 32K (and to bankset)

2. Enhancements for SUPER/32K/bankset are formulated in terms of what happens at $4000 and what happens at $04x0, and those are independent

 

2 minutes ago, TailChao said:

The current format has had fixed sizes for expansion memory on the cartridge since day one, usually to fill an entire segment. This isn't actually faithful to the manufactured ROM Only and SUPER boards which have a range of sizes (2KB, 8KB, 32KB with half disabled).

 

So another thing to keep in mind, as this has hit other formats - do we care about these things?

Is the goal to just get the game to work (which is understandable, all things considered) or accurately describe what's in the plastic shell?

 

I've put a fair bit of effort into cutting my EXRAM usage down to 8K. My thinking was: this is an arcade game from 1981, and even 8K of RAM on the cart would have been lavish for such a game during the 7800's lifespan. Or more philosophically: use what I need, don't use what I don't need.

 

But I do not need a bit in the header that says "this game uses 8K of RAM but not 16K." Even to me, who cares about this stuff, the purpose of the header is only to make the game work on emulators and flashcarts.

  • Like 1
Link to comment
Share on other sites

1 hour ago, Pat Brady said:

EDIT: this way I get what I want, which is to not have to worry about whether my combination of features that work together is in somebody else's list of blessed combinations, and you get what you want, which I think is to avoid the possibility of specifying combinations that don't make sense.

"combinations that don't make sense" could be something more subtle than Activision+Mirror Ram. (too funny that both Tailchao and I latched on the most ridiculous example) If someone decides they want 128k banksets with bank6@4000 and pokey@450, it seems reasonable enough. But doing that would exceed the logic elements the mapper hardware was designed with. (not to mention a new board would be required). An curated exhaustive mapper list would prevent that problem.

 

Yes, the list requires curation, with the associated lag behind that. But I believe in a first pass we can cover all of the valid hardware combinations available to homebrewers presently. Then if someone decides they need more power, and expands our 128k bankset hardware example with a larger PLD, a new mapper is born. The new mapper calls out that there was some hardware update, which makes any failures more obvious.

 

54 minutes ago, TailChao said:

This isn't actually faithful to the manufactured ROM Only and SUPER boards which have a range of sizes (2KB, 8KB, 32KB with half disabled).

 

So another thing to keep in mind, as this has hit other formats - do we care about these things?

Is the goal to just get the game to work (which is understandable, all things considered) or accurately describe what's in the plastic shell?

Yes, absolutely the header should document exactly what's in the shell. Implementations can choose what's trivial to them, but (thinking of Pat's example of RAM that he just replied with) a game going off the rails will have symptoms different depending on the hardware layout. If emulation isn't accurate here, it blunts the ability to track down the cause of the problem in the debugger.

Link to comment
Share on other sites

12 minutes ago, Pat Brady said:

It's been a while, but IIRC I tried that, and eventually gave up and started making ROMs padded out to 128k. Apparently even 64K+EXRAM does not work because that is also not in the list of things that exist.

Tower Toppler is 64KB + 8KB RAM.   The Concerto cart and the archaic ProSystem emulator have issues with 64 KB ROM images, which the workaround is to pad the image to 128KB.  The correct dump works fine elsewhere.

  • Like 1
Link to comment
Share on other sites

6 minutes ago, Pat Brady said:

It's been a while, but IIRC I tried that, and eventually gave up and started making ROMs padded out to 128k. Apparently even 64K+EXRAM does not work because that is also not in the list of things that exist.

Which emulators did this fail in?

 

 

Quote

Another example would be a 48K ROM with POKEY@$0450. Or a 32K ROM with YM2151. Those are trivial to implement (assuming POKEY@$0450 and YM2151 are already supported) but are not in the list of things that currently exist. I just see no reason to actively prevent them from working.

 

My updated proposal (bottom of post #82) differs from your proposal in only 2 ways:

1. Enhancements for SUPER also apply to 32K (and to bankset)

2. Enhancements for SUPER/32K/bankset are formulated in terms of what happens at $4000 and what happens at $04x0, and those are independent

Here's the thing though - both of those, outside of banksets, could be described with the current format. There's just been a lot of ambiguity regarding exactly what is allowed, and where.

 

Still talking about the old format here - I'd draw the line at allowing multiple devices to be assigned to the same address. The arrangement that always bothered me was putting both a POKEY and ROM / RAM @ $4000, as you could feasibly control a POKEY through a write-only fallthrough, but it does have readable registers (i.e. RAND which is used for presence detection) and this configuration was never documented clearly.

 

 

Quote

But I do not need a bit in the header that says "this game uses 8K of RAM but not 16K." Even to me, who cares about this stuff, the purpose of the header is only to make the game work on emulators and flashcarts.

18 minutes ago, RevEng said:

Yes, absolutely the header should document exactly what's in the shell. Implementations can choose what's trivial to them, but (thinking of Pat's example of RAM that he just replied with) a game going off the rails will have symptoms different depending on the hardware. If emulation isn't accurate here, it blunts the ability to track down the cause of the problem in the debugger.

 

2043216764_APointinEveryDirection.jpg.52a13f9c89c352aa742b19b633012696.jpg

 

So I went with the latter, more thorough method when implementing BupSystem's cartridge types and the *.cdf loader, as historically there were issues on other platforms where a particular game writes to a mirrored address (i.e. 8KB SRAM in a 16KB segment) and requires that write to impact multiple locations in order to run correctly.

 

While there is always going to be some new thing that'll be difficult to shove in an existing format, I think being thorough for each cartridge variety isn't a big deal for an emulation perspective - look at the quantity of mappers and data formats the average NES emulator author has to deal with.

 

 

18 minutes ago, RevEng said:

Yes, the list requires curation, with the associated lag behind that. But I believe in a first pass we can cover all of the valid hardware combinations available to homebrewers presently. Then if someone decides they need more power, and expands our 128k bankset hardware example with a larger PLD, a new mapper is born. The new mapper calls out that there was some hardware update, which makes any failures more obvious.

Agreed.

 

I think this is really a two step process of first clarifying what the existing format's nuances are and then formalizing its replacement. Allowing a fallback to the old header, as it exists today on 7800.8bitdev, then only using the new header and features when they're required, already clears up a huge amount of headache.

Link to comment
Share on other sites

13 minutes ago, RevEng said:

If someone decides they want 128k banksets with bank6@4000 and pokey@450, it seems reasonable enough. But it exceeds the logic requirements the mapper hardware was designed with.

 

Interesting point.

 

13 minutes ago, RevEng said:

But I believe in a first pass we can cover all of the valid hardware combinations available to homebrewers presently.

 

I still suggest *representing* them as I described (which is also the least error-prone for implementors, 2 small lists of possibilities instead of one huge one that then has to be decoded into those same 2 values). You can curate a list of combinations that work — or a list of combinations that do not, whichever is easiest.

 

13 minutes ago, RevEng said:

Yes, absolutely the header should document exactly what's in the shell. Implementations can choose what's trivial to them, but (thinking of Pat's example of RAM that he just replied with) a game going off the rails will have symptoms different depending on the hardware layout. If emulation isn't accurate here, it blunts the ability to track down the cause of the problem in the debugger.

 

Good point. TBH that's pretty far down the list of niceties I'd like to see in a7800. But, it certainly wouldn't hurt to add that piece of information. With the structure I proposed, 8K EXRAM is just one entry in the "what's at $4000" enumeration.

 

2 minutes ago, Trebor said:

Tower Toppler is 64KB + 8KB RAM.

 

I didn't say it doesn't exist, I said it's not in the list of things that exist. ;)

Link to comment
Share on other sites

19 hours ago, Pat Brady said:

I didn't say it doesn't exist, I said it's not in the list of things that exist. ;)

 

19 hours ago, Pat Brady said:

It's been a while, but IIRC I tried that, and eventually gave up and started making ROMs padded out to 128k. Apparently even 64K+EXRAM does not work because that is also not in the list of things that exist.

The full statement made is it does not work because that is also not in the list of things that exist. 

 

It works fine (at least) under A7800/MAME, MiSTer, Dragonfly, BupSystem, while being a "64K+EXRAM" image.    Don't want there to be a misunderstanding that such a ROM does not work, when it actually does work fine with the exception of the aforementioned issues under Concerto and the long outdated ProSystem emulator. :)

 

  • Like 1
Link to comment
Share on other sites

Okay, so...

21 hours ago, TailChao said:

I think this is really a two step process of first clarifying what the existing format's nuances are...

...after seeing every emulator handle this in slightly different ways, I'm gonna take a swing at it. If y'all can help fill in some of the blanks it'd be appreciated - then we'll have something a little clearer which will at least live in the thread and can maybe be dumped in the a7800.8bitdev wiki later.

 

Let's break the Cartridge Type word into bitfields, anything with a (!) tag is a mapper...

[0] : bPOKEY_4000
[1] : bSUPER            <- (!)
[2] : bEXRAM
[3] : bEXROM            <- (SUPER Secondary ROM @ $4000)
[4] : bEXFIX            <- (SUPER Last Bank - 1 @ $4000)
[5] : bVERSA            <- (?)
[6] : bPOKEY_0450
[7] : bEXRAM_A8         <- ('Mirror RAM')

[8] : bACTIVISION       <- (!)
[9] : bABSOLUTE         <- (!)
[A] : bPOKEY_0440
[B] : bYM2151
[C] : bSOUPER           <- (!)
[D] : bBANKSET          <- (!)
[E] : '0'               <- (Reserved for Future Mischief)
[F] : '0'               <- ...

We have bSUPER, bACTIVISION, bABSOLUTE, bSOUPER, and bBANKSET as our mutually exclusive mapper fields. Good so far, but let's look at some of the feature bits...

 

  • [5] is usually tagged as SuperGame Banked RAM but I've only seen it included as part of the VersaBoard, where one of the paging bits is repurposed as a 16KB RAM Bank. Did Atari actually manufacture boards with this capability or is it purely an aftermarket thing? It's not in the bankswitching guide and would conflict with large (1 - 4MB) games using the SUPER design.
     
  • [4] is usually tagged as Bank 6 at $4000 but this makes no sense for anything larger or smaller than 128KB. I've been calling it EXFIX and assigning it to LAST BANK - 1. It's also one of the flags which was added to the header format later on, and because of this - it's (understandably) cleared in most ROM sets outside of Trebor's ProPack. It'll also cause a lot of games to fail if incorrect, and nothing depends upon it being deallocated aside from a device which can conflict with it like the XBoard or XM.

    So I think the thorough way to handle this is - if the VERSION field is < 2, assume SUPER cartridges have an EXFIX segment mapped in if there's nothing else already there (i.e. EXROM or EXRAM).
     
  • [3] is more straightforward, as a secondary ROM mapped at $4000. The only additional clarification here is that (I think) it should be allowed for any size SUPER cartridge - not just the usual 144KB target.

 

Assuming we've got a valid, up to date header, here's some broken C for a rough parse and feature tree...

if(bBANKSET && no_other_mapper_bits_set())
{
	// BANKSET
	// (!) RevEng & Batari should fill this in.
}
else if(bSOUPER && no_other_mapper_bits_set())
{
	// SOUPER
	// No feature bits supported.
}
else if(bABSOLUTE && no_other_mapper_bits_set())
{
	// ABSOLUTE
	// No feature bits supported.
}
else if(bACTIVISION && no_other_mapper_bits_set())
{
	// ACTIVISION
	// No feature bits supported.
}
else if(bVERSA && no_other_mapper_bits_set())
{
	// VERSABOARD
	// Not sure if this needs to be its own thing, lemme know.
	// If so, it's a more constrained SUPER field (512KB ROM, EXRAM PAGE in Bit 5) but is at least clear.
}
else if(bSUPER && no_other_mapper_bits_set())
{
	// SUPER
	// This is hella overloaded, and the 'sprit of the format' is to allow every flag to be set.
	// These are usually {bPOKEY_4000, bEXRAM, bEXROM, bEXFIX, bPOKEY_0450, bPOKEY_0440, and bYM2151}
	// In that case, we just need clarity on how to handle multiple devices assigned to the same region.

	// (!) If we're going by 'maximum mischief' - the ROM can be up to 4MB, why not, let's do it.
	// (!) bEXRAM, bEXROM, and bEXFIX are mutually exclusive, you need to pick ONE.

	if(bPOKEY_4000 && (bEXRAM || bEXROM || bEXFIX))
	{
		// Pokey @ $4000 can conflict with EXRAM, EXROM, or EXFIX, if it's spun up with any
		// of those make it write only.
	}
	else if(bPOKEY_4000)
	{
		// Pokey @ $4000 is readable.
	}

	// Not sure if EXRAM_A8 should be supported here?
	// Nothing uses it...
}
else if(no_mapper_bits_set())
{
	// 16KB - 48KB cartridge
	// I think the following should be allowed here...
	// {bPOKEY_4000, bEXRAM, bEXRAM_A8, bPOKEY_0450, bPOKEY_0440, and bYM2151}

	if(32KB >= size)
	{
		// (!) bEXRAM and bEXRAM_A8 are mutually exclusive, pick ONE.

		// This has some of the same issues as SUPER, albeit without paging since
		// you can assign both EXRAM and a POKEY to the same segment @ $4000, so...

		if(bPOKEY_4000 && (bEXRAM || bEXRAM_A8))
		{
			// Pokey @ $4000 is write only.
		}
		else if(bPOKEY_4000)
		{
			// Pokey @ $4000 is readable.
		}
	}
	if(48KB == size)
	{
		// Only a POKEY @ $4000 is allowed here, with the usual caveat of...
		if(bPOKEY_4000)
		{
			// Write only Pokey @ $4000
		}
	}
}

 

This make sense so far?

 

 

EDIT : MORE BONUS CONTENT ?!

 

The XM Bit has been loitering in $3F for awhile, and there's partial support for it in a7800 and the MiSTer. But I think the following needs to be addressed...

  • Nothing (released, or at least that I know of) is using the RAM Expansion features inherited from the XBoard.
  • Is it redundant with all the sound chips which can be mapped in the $04xx region?
  • Is this ever going to ship?
Edited by TailChao
Link to comment
Share on other sites

Some ROM's use POKEY and XM interrupts, it would be handy to have an "external audio interrupt" flag. It could just be global and refer to any audio hardware present rather than specific YM / POKEY IRQ.

 

At the moment I just hack this in -- I have been wondering how to handle this for the 7800GD in terms of persisting it, so standardising would be helpful to all! :)

  • Like 1
Link to comment
Share on other sites

10 hours ago, TailChao said:

Okay, so...

...after seeing every emulator handle this in slightly different ways, I'm gonna take a swing at it. If y'all can help fill in some of the blanks it'd be appreciated - then we'll have something a little clearer which will at least live in the thread and can maybe be dumped in the a7800.8bitdev wiki later.

 

I started a good faith effort to help on this, but I'm reluctant to even put a mix and match rule list. With Fred's guidance I put together a strict list of bankset mappers from the start - I want those to be the menu and not other possible mixes because some mixes will involve redesign and sourcing larger less cost-effective logic, with Fred's time in that endeavour being the resource I most want to preserve. (If there's a pressing need for moar powah, I'm positive Fred would be happy to oblige with another design, and a new mapper. I just want the process undertaken with intention.)

 

TBH I suspect there may be a similar dynamic at play with all of the rest of the formats and the mixing and matching, where software people are unintentionally making more work on the hardware side.

 

The main rules of bankset are similar to what you've provided for non-banked and supergame. If rom is present at 4000 and you want pokey, it's a write-only pokey. If ram is present at 4000 and you want pokey, you get a pokey@450. bank6@4000 is only available for 128K, and not 128K+POKEY@4000 because there aren't sufficient logic gates in the mapper implementation.

 

Also it should be noted that banksets is a sort of meta bit, because you still pick supergame (or not) as the underlying scheme. Also, we use the versa bankswitchram bit, since the ram is banked by halt.
 

Quote

EDIT : MORE BONUS CONTENT ?!

 

The XM Bit has been loitering in $3F for awhile, and there's partial support for it in a7800 and the MiSTer. But I think the following needs to be addressed...

  • Nothing (released, or at least that I know of) is using the RAM Expansion features inherited from the XBoard.
  • Is it redundant with all the sound chips which can be mapped in the $04xx region?
  • Is this ever going to ship?
  • My understanding is the same.
  • Redundant in the context of the header? No, because there are control registers you need to twiddle to activate those XM sound chips.
  • Magic 8 Ball says "Don't count on it."
9 hours ago, SainT said:

Some ROM's use POKEY and XM interrupts, it would be handy to have an "external audio interrupt" flag. It could just be global and refer to any audio hardware present rather than specific YM / POKEY IRQ.

 

At the moment I just hack this in -- I have been wondering how to handle this for the 7800GD in terms of persisting it, so standardising would be helpful to all! :)

Makes perfect sense to me. I think we do probably need to flag it for particular devices, or even particular mappers.

  • Like 1
Link to comment
Share on other sites

@TailChao:

SUPER + EXRAM_A8: AFAIK this has not been used, but it seems both useful and easily implementable. I vote to handle it.

SUPER (or no mapper) + POKEY@$4000 + anything else at $4000: AFAIK this has also not been used, and with the availability of POKEY@$0450, why would anybody do this? Especially EXRAM. IMO POKEY@$4000 should be mutually exclusive with anything else @$4000 in the same way that the various mappers are mutually exclusive.

 

32 minutes ago, RevEng said:

I started a good faith effort to help on this, but I'm reluctant to even put a mix and match rule list. With Fred's guidance I put together a strict list of bankset mappers from the start - I want those to be the menu and not other possible mixes because some mixes will involve redesign and sourcing larger less cost-effective logic, with Fred's time in that endeavour being the resource I most want to preserve. (If there's a pressing need for moar powah, I'm positive Fred would be happy to oblige with another design, and a new mapper. I just want the process undertaken with intention.)

 

TBH I suspect there may be a similar dynamic at play with all of the rest of the formats and the mixing and matching, where people are unintentionally making more work on the hardware side.

 

I appreciate this. It makes complete sense. I am surprised that the amount of logic required for other configurations affects the cost. Not questioning or doubting you at all. It's just not what I would have guessed.

 

I predict the 4 128K options will be popular.

  • Like 1
Link to comment
Share on other sites

4 hours ago, RevEng said:

I started a good faith effort to help on this, but I'm reluctant to even put a mix and match rule list. With Fred's guidance I put together a strict list of bankset mappers from the start - I want those to be the menu and not other possible mixes because some mixes will involve redesign and sourcing larger less cost-effective logic, with Fred's time in that endeavour being the resource I most want to preserve. (If there's a pressing need for moar powah, I'm positive Fred would be happy to oblige with another design, and a new mapper. I just want the process undertaken with intention.)

Documentation is always appreciated, thanks. But a few inevitable nitpicks from my inner fillyjonk...

  • You're using 2x(SIZE) and (SIZE) interchangeably. If a 2x128KB Bankset cartridge is a 256KB ROM where Sally is fixed to one half, and Maria to the other - it's a 256KB ROM.
  • I'm not really sure why you'd want a 52KB format which overlaps with the High Score Cartridge.

 

 

Quote

TBH I suspect there may be a similar dynamic at play with all of the rest of the formats and the mixing and matching, where software people are unintentionally making more work on the hardware side.

Yes and no. If we're talking about the headers for other platforms and how they've been abused, it's usually just "ROM GETS BIGGER" and that's not too much of a hassle. Sometimes a coprocessor is dropped in games it was never intended for - and then you get the chaotic ending where a flash cartridge developer goes "lol ok" and makes it work.

 

I guess a parallel here would be the 1MB+ audio streaming demos in the SUPER format - you can't buy a standalone board with that capacity, but it's not totally impossible to make. Flash cartridges with access to larger FPGAs and pools of memory make that even easier.

 

A common strategy for emulator authors in this regard is to extend a format to the largest possible size both its architecture and registers could feasibly hold. So for SUPER you'd always allocate 4MB (256 x 16KB) and mirror the binary within that. SOUPER would still be fixed to 512KB despite also having 16KB paging - as it's limited by Maria's bank size (256 x 2KB). This helps situations where someone inevitably needs more now and the software's maintainer has long since decided living in a van with a dog is far more rewarding than writing emulators.

 

 

Quote

Also it should be noted that banksets is a sort of meta bit, because you still pick supergame (or not) as the underlying scheme. Also, we use the versa bankswitchram bit, since the ram is banked by halt.

I'm not really fond of this.

 

If I understand the VersaBoard implementation correctly, the Banked RAM Bit ( [5], eh - let's call it EXRAM/X2 instead of Versa RAM, that was the old BupSystem documentation name and makes a little more sense as... ) is controlled by Bit 5 of the mapping register. So it's %..RBBBBB where R is the RAM bank @ $4000 - $7FFF and BBBBB is the ROM bank @ $8000 - $BFFF. That's a totally different scheme than what you're using for Banksets.

 

Given the other restrictions you've pointed out, and that whether paging is allowed can be determined by binary size - I think it should be its own exclusive mapper alongside SUPER, SOUPER, ABSOLUTE, and ACTIVISION. Don't fret - it's a promotion!

 

Also, now that I've read the VersaBoard implementation a few times - I think the EXRAM/X2 feature should be exclusive to SUPER cartridges 512KB or less. It doesn't need to be its own category, but it does need that restriction, and only makes sense for the SUPER format. Was anything ever released which used the feature?

 

 

13 hours ago, SainT said:

Some ROM's use POKEY and XM interrupts, it would be handy to have an "external audio interrupt" flag. It could just be global and refer to any audio hardware present rather than specific YM / POKEY IRQ.

 

At the moment I just hack this in -- I have been wondering how to handle this for the 7800GD in terms of persisting it, so standardising would be helpful to all! :)

Quote

Makes perfect sense to me. I think we do probably need to flag it for particular devices, or even particular mappers.

I completely forgot about these in the DragonFly - it might be best to wait until its audio options stabilize a little and then make it an entire cartridge / mapper type in the new, way cooler format.

 

 

3 hours ago, Pat Brady said:

SUPER + EXRAM_A8: AFAIK this has not been used, but it seems both useful and easily implementable. I vote to handle it.

That's fine, I'm in.

 

 

Quote

SUPER (or no mapper) + POKEY@$4000 + anything else at $4000: AFAIK this has also not been used, and with the availability of POKEY@$0450, why would anybody do this? Especially EXRAM. IMO POKEY@$4000 should be mutually exclusive with anything else @$4000 in the same way that the various mappers are mutually exclusive.

I totally agree - but this is baggage we inherited from ProSystem, some developers latched on to, and now we're stuck with it. The new 48KB Bankset + POKEY @ $4000 is also using the same scheme. Hiding POKEYs all over the address space is just tradition.

 

 

Quote

I appreciate this. It makes complete sense. I am surprised that the amount of logic required for other configurations affects the cost. Not questioning or doubting you at all. It's just not what I would have guessed.

Picking up an HDL like Verilog and trying to design your own custom hardware is something I highly recommend. Worst case you figure out how easy it is, design lots of neato junk, then use none of it.

 

 

EDIT : There's just a couple more things to nail down in the existing format and then we can talk new stuff, but I want to rewind about twelve years since this is a bit poignant...

On 4/6/2010 at 6:25 PM, DanBoris said:

I don't have an objection to including simple header features when a game is actually going to be released that needs it, but I don't like the idea of having "infinitely configurable" hardware defined in the headers. You are talking about adding bits for flexible memory, but what if I want the flexibility to put a POKEY anywhere in memory I want it, or maybe two POKEYS, etc, where would you draw the line. The header could end up getting very complex.

 

I think the emulator authors can build that kind of flexibility into the emulator so developers can play with various configurations that a cart might support, and then add it to the header when they have settled on the scheme they want to use.

Edited by TailChao
  • Like 1
Link to comment
Share on other sites

5 hours ago, RevEng said:

 

I started a good faith effort to help on this, but I'm reluctant to even put a mix and match rule list. With Fred's guidance I put together a strict list of bankset mappers from the start - I want those to be the menu and not other possible mixes because some mixes will involve redesign and sourcing larger less cost-effective logic, with Fred's time in that endeavour being the resource I most want to preserve. (If there's a pressing need for moar powah, I'm positive Fred would be happy to oblige with another design, and a new mapper. I just want the process undertaken with intention.)

 

TBH I suspect there may be a similar dynamic at play with all of the rest of the formats and the mixing and matching, where software people are unintentionally making more work on the hardware side.

 

The main rules of bankset are similar to what you've provided for non-banked and supergame. If rom is present at 4000 and you want pokey, it's a write-only pokey. If ram is present at 4000 and you want pokey, you get a pokey@450. bank6@4000 is only available for 128K, and not 128K+POKEY@4000 because there aren't sufficient logic gates in the mapper implementation.

 

Also it should be noted that banksets is a sort of meta bit, because you still pick supergame (or not) as the underlying scheme. Also, we use the versa bankswitchram bit, since the ram is banked by halt.
 

  • My understanding is the same.
  • Redundant in the context of the header? No, because there are control registers you need to twiddle to activate those XM sound chips.
  • Magic 8 Ball says "Don't count on it."

Makes perfect sense to me. I think we do probably need to flag it for particular devices, or even particular mappers.

Yes, I would prefer that a solution isn't born out of all of the theoretical mapper combinations we can create given the resources of an emulator or unfettered access to powerful hardware (such as a flashcart.)


Everything I do on AtariAge is done for the benefit of the homebrewing hobby, and to me that means being able to release your game on a standalone cartridge. To me, allowing any combination, no matter how strange, only creates a situation where it may be impractical to actually release a game, and for no good reason.

 

A perfect example of this is the POKEY @$0450 which became the de facto standard after the XM used it. It was never intended for standalone cartridge hardware, and my opinion is that the address decoding is unnecessarily strict for that application. If I had any say I would have pushed something else that isn't such a resource hog, as the design space for homebrew cartridge hardware favors TTL and SPLD chips. Because of POKEY @0450 being a thing, my own homebrew boards are limited in their abilities, and for no good reason, I feel.

 

There's nothing we can do about this now, of course, but we can control the future somewhat, and if we can direct programmers to make more sensible choices from a hardware perspective without limiting things much, being able to release games on cartridge becomes a lot more practical. A sensible list of mappers can help that along.

 

 

 

Link to comment
Share on other sites

As a newbie on 7800 I should perhaps be silent. But there is one scenario in Wizzy that is really cool on the Lynx large flash chips.

 

When the flash gets really large, like 2MB the RAM is still small. So it starts making sense to page in animations on demand.

 

If I have one hero I could use banks at $8000 for animating different thing like:

- witch on foot (idle, run, attack, die in 4 directions)

- witch on broom

- witch as a barbarian

- witch as an mage

Only one of these need to be in memory at a time.

 

A similar bank setup would be cool for enemies. Perhaps at $C000

- tiles of the level

- spider animations

- bat

- zombie

- non-player characters

 

There seems to be techniques to have banks seen with different content for the display engine and the CPU.

 

How do you create assemble the ROM files to create an image in this case?

 

First all the banks seen by the CPU, then the banks seen by the display?

 

Or interlaced banks like:

CPU bank 0, display bank 0, CPU bank1, display bank1?

 

I did understand that the CPU and display banks switch at the same time.

Link to comment
Share on other sites

3 hours ago, TailChao said:

I totally agree - but this is baggage we inherited from ProSystem, some developers latched on to, and now we're stuck with it. The new 48KB Bankset + POKEY @ $4000 is also using the same scheme. Hiding POKEYs all over the address space is just tradition.

 

LOL

 

And I had just looked at the list of bankset formats and specifically looked at which ones map POKEY where and still didn't notice that 2x48K put POKEY at $4000 and it has the words "write-only" protruding out the right hand side.

 

3 hours ago, TailChao said:

Picking up an HDL like Verilog and trying to design your own custom hardware is something I highly recommend. Worst case you figure out how easy it is, design lots of neato junk, then use none of it.  

 

Don't really need more projects but will keep this in mind. I know Verilog, but have never done PCB layout and lack expertise in components.

 

1 hour ago, batari said:

Everything I do on AtariAge is done for the benefit of the homebrewing hobby, and to me that means being able to release your game on a standalone cartridge. To me, allowing any combination, no matter how strange, only creates a situation where it may be impractical to actually release a game, and for no good reason.

 

I would hope that a programmer would not choose a strange combination unless there is a good reason for it. And IMO documentation (and ideally a warning in the header generator and/or an emulator) is sufficient for this issue.

 

In my case, my format is unusual but not difficult (32K ROM+8K RAM). If it ever gets a cart release, it may be on a standard SuperCart board, maybe with a 128K ROM and a 16K RAM, just because that's more common in 2022. But for emulation and flashcarts, I believe the 32K image should work, even though that hardware doesn't currently exist.

 

In the example @RevEng gave above, Bankset with Bank 6@$4000 and POKEY@$0450, just document that the currently available board can't do that. If a programmer chooses that combination anyway without actually needing that combination, to me that's a bad programming decision on par with "I refuse to turn DMA on."

 

On the other hand if a programmer does need that combination, then it's best that emulators and flashcarts support it. That way programming can happen in parallel with hardware development. (FWIW my hunch is that Bankset will drastically reduce the need for Bank 6@$4000.)

 

With all that said…

 

1 hour ago, batari said:

A perfect example of this is the POKEY @$0450 which became the de facto standard after the XM used it. It was never intended for standalone cartridge hardware, and my opinion is that the address decoding is unnecessarily strict for that application. If I had any say I would have pushed something else that isn't such a resource hog, as the design space for homebrew cartridge hardware favors TTL and SPLD chips. Because of POKEY @0450 being a thing, my own homebrew boards are limited in their abilities, and for no good reason, I feel.

 

There's nothing we can do about this now, of course, but we can control the future somewhat, and if we can direct programmers to make more sensible choices from a hardware perspective without limiting things much, being able to release games on cartridge becomes a lot more practical. A sensible list of mappers can help that along.

 

Programmers use POKEY@$0450 because that's what's available, no other reason. POKEY@$4000 is fine, unless ROM or RAM is there. If you have a better idea, and it's supported in emulators and flashcarts, I expect programmers will be interested.

 

And in particular, if possible and @RevEng and @mksmith are willing: move the bankset POKEY to somewhere better! Now is the time to do that.

 

BTW — I don't think I've formally asked: please add support for 32K+RAM@$4000 to the next Concerto firmware.

Link to comment
Share on other sites

Since you all are talking about figuring out better ways to do ROM mappers, I'm going to throw out something I've been thinking about.  It would be nice if there was a bank-switching scheme that supported swapping out smaller bank sizes like 2k/4k... because that would be really handy when using holey DMA.

 

Here's an example scheme geared toward 16-line holey DMA (since that's what I'm most familiar with using):

 

$4000..$7FFF 16k RAM, Pokey, or ROM (optional options)

$8000..$BFFF 16k swappable region

$C000..$CFFF - 4k swappable region (could be used as sprite graphics)

$D000..$DFFF - 4k swappable region (could be data or code)

$E000..$EFFF - 4k swappable region (could be used as background graphics)

$F000..$FFFF - 4k static region (non-swappable) - potential location for bank-switch registers

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