Jump to content
IGNORED

A78 header changes


GroovyBee

Recommended Posts

53 minutes ago, splendidnut said:

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

This is almost exactly what I’m trying to do now with @rj1307 for SN cart ;) (with one extra feature)

edit: but only for $Axxx and $Exxx

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

Quote

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?

It depends...

  • Bankset uses the former setup (half code / half texture areas of ROM).
  • SOUPER allows graphics to be located anywhere in ROM on a 2KB boundary, or EXRAM on a 4KB boundary.
  • I'm sure someone will make the interleaved one later.
     
Quote

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

This, in my opinion, was the biggest problem with Atari's stock mapper and why I ended up designing my own hardware. Drawing a firm line between Sally and Maria's dependencies makes all resource management easier - then your software can have more time to run a physics engine instead of worrying about whatever Maria is doing.

 

 

Quote

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.

Even older, this is XBoard baggage - which is also the only context that choice of address makes sense.

 

 

2 hours ago, splendidnut said:

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.

These already exist as SOUPER and the unreleased PMC1, albeit the pages are strictly for Maria so you don't have to worry about contention. The former allows you to access texture data anywhere ROM as 2 x 2KB Pages, or in EXRAM in 4KB chunks. The latter is more of the same ramped up to a scale of too much and tosses in another paging method to make managing Display Lists (and also scrolling) easier - but is also a little closer to your layout.

 

So it's totally doable, but why not take it further and give Maria her own pages entirely!

 

 

1 hour ago, Eagle said:

This is almost exactly what I’m trying to do now with @rj1307 for SN cart ;) (with one extra feature)

edit: but only for $Axxx and $Exxx

Heh, that new header format is gonna have to start with more mapper extensions than the old one closed with.

 

...

 

I'm not sure artificially limiting hardware by an arbitrary "authenticity" metric is really the right way to go. We have standards like MSU1 for other consoles and they'll inevitably end up here, it should be up to each game's developers to pick what's right for their project. That said - I'd rather something only be integrated in a header format if it's actually been used and shipped in scale.

 

What would be nice is if there was a forward thinking, uniform standard for expansion hardware - or at least a semicompatible one as with the Game Boy's MBCx series. But I don't see that happening, since we're all going in different directions. So the least we can do is thoroughly document them all, and divide them up for use in a less chaotic way.

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

 

9 hours ago, TailChao said:

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.

 

Thanks for the heads-up. I added the 2x to the text that was missing it... Right now I've just been throwing things into that entry as they occur, but I need to go over it for consistency.

 

I prefer the 2x notation because it emphasises the nature of the rom. I'm told that 6502 coders can multiply by 2 easily. ;)

 

IMO the hi score cart not meaningfully existing in real hardware puts it into second-class status. Curt did a release of these, but due to a design flaw they don't actually retain the hi-scores for any length of time. A non-HSC compatible rom isn't a bad trade off for 52k contiguous rom. (though I agree with Pat that the 2x128K variants are where the action is at)

 

Quote

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.

 

 

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!

Yes, for sure I was generalising the meaning of the EXRAM/X2 bit, since implementation header parsers need to work in a particular context anyway. I think we've pretty much lost the battle for the current implementation of cart-type referring to a particular implementation of a feature, and the parser needs to be context-aware anyway. But if people don't agree, I will gladly grab another bit in cart-type for halt-banked ram.

 

With your size logic, we don't need a SUPER bit either, and can detect SUPER based on size. But the bit adds simplicity to the header parser. IMO it does much the same for header parsers for banksets. Not as much simplicity as the proposed mapper approach would, of course.

 

12 hours ago, Pat Brady said:

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.

Originally to @TailChao, but since banksets uses this I feel compelled to reply. To figure out if a destination is somewhere in the range of $4000-$7FFF you only need to monitor+act on 2 address lines. (+1 for the write line, in this scenario) To do the same for 400-4FF (I don't particularly care for sharing address space with the 480-4FF with RIOT ram, but ignoring that for now) and avoid bus conflict with other devices, you're involving at least 5 address lines. (more if you wish to avoid future XMish devices that may be listening at 4xx locations. Of course, said future devices may be incompatible with pokey@450 carts anyway, if they always listen to 450, without XMish control registers.)

 

IMO I'd rather use those logic elements on other features, or minimise the cart design cost. The RNG in POKEY isn't a particularly compelling feature to gain. Auto-detection and failback to TIA audio is nice, but I'm not seeing a whole lot of that going on. With the rise of POKEY replacement solutions, I see it becoming even less common.

 

On your later reply, the main problem is any lower address is going to require similar amounts of decoding. Sticking a POKEY at HSC addresses would be more frugal for gates, but problematic for obvious reasons. Upper addresses might be up for game (e.g. write to $C000-$FFFF for pokey) but won't be universal either. e.g. Banksets uses that range so Sally can write to Maria's RAM.

 

I don't think there is a universal mix-and-match solution here for Pokey outside of 4000 that doesn't have design cost or other trade-offs similar to POKEY@450. (though would love to hear @batari's thoughts)

 

5 hours ago, karri said:

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.

The limitation with this proposal is you would need to bank them all together, so all of the animations would be limited to the same rate, frame-count, and repeating requirements.

 

Also, there are sharp rocks ahead - don't rely on graphics immediately at $8000 for sprites. The Maria DMA memory holes don't extend to below $8000, so non-zone aligned vertical offsets for sprite objects will reveal whatever below $8000, which is either floating bus or something else you don't want displayed. So I'd recommend sticking characters/tiles in this area, if any graphics are going there.

 

5 hours ago, karri said:

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.

Souper or Banksets have this design. (Souper allows for different banks to be active for Sally & Maria)

 

In the case of Banksets, yes, the image seen by Sally goes first, then the image seen by Maria.

 

If Banksets is something you want to explore, I'd recommend holding off for at least a couple weeks. Presently the only emulation support is via pre-release a7800. I'm in the process of getting test roms finished for the emulation/cart devs (nearly there) and formalising an a7800 release. (still some work to do)

 

2 hours ago, Eagle said:

This is almost exactly what I’m trying to do now with @rj1307 for SN cart ;) (with one extra feature)

edit: but only for $Axxx and $Exxx

Loving the innovation :thumbsup:

 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, TailChao said:

I'm not sure artificially limiting hardware by an arbitrary "authenticity" metric is really the right way to go. We have standards like MSU1 for other consoles and they'll inevitably end up here, it should be up to each game's developers to pick what's right for their project. That said - I'd rather something only be integrated in a header format if it's actually been used and shipped in scale.

 

This seems to be the big area of disagreement now.

 

I'm apparently falling on the end of being more permissive. It's mostly based on my observation that flashcart firmware does not get updated very often. If emulators are restrictive, no big deal: a7800 is open source, any developer can patch in whatever they need whenever they need it. But if flashcarts are restrictive then it is a big barrier.

 

To be clear, I am talking about combinations of features that are already supported. I am not asking anybody to code up some fantasy mapper or sound chip.

 

Quote

Originally to @TailChao, but since banksets uses this I feel compelled to reply. To figure out if a destination is somewhere in the range of $4000-$7FFF you only need to monitor+act on 2 address lines. (+1 for the write line, in this scenario) To do the same for 400-4FF (I don't particularly care for sharing address space with the 480-4FF with RIOT ram, but ignoring that for now) and avoid bus conflict with other devices, you're involving at least 5 address lines. (more if you wish to avoid future XMish devices that may be listening at 4xx locations. Of course, said future devices may be incompatible with pokey@450 carts anyway, if they always listen to 450, without XMish control registers.)

 

IMO I'd rather use those logic elements on other features, or minimise the cart design cost. The RNG in POKEY isn't a particularly compelling feature to gain. Auto-detection and failback to TIA audio is nice, but I'm not seeing a whole lot of that going on. With the rise of POKEY replacement solutions, I see it becoming even less common.

 

OK, point taken.

 

Quote

On your later reply, the main problem is any lower address is going to require similar amounts of decoding. Sticking a POKEY at HSC addresses would be more frugal for gates, but problematic for obvious reasons. Upper addresses might be up for game (e.g. write to $C000-$FFFF for pokey) but won't be universal either. e.g. Banksets uses that range so Sally can write to Maria's RAM.

 

I don't think there is a universal mix-and-match solution here for Pokey outside of 4000 that doesn't have design cost or other trade-offs similar to POKEY@450. (though would love to hear @batari's thoughts)

 

Well, following your logic above, if you mirror the whatever-it-is, you can save some lines. For example POKEY@$0400 with 7 mirrors up to $047F would save 3 address lines. Is there anything between $0800 and $0FFF? Giving that entire chunk to a POKEY would save another 2 lines. (Since there is precedent for 2xPOKEY it might be best to split that area into two; that would still save 4 lines compared to $0450.)

 

Anyway, I don't know if that's what @batari had in mind but he certainly seemed to have something in mind. I hope he proposes it.

Link to comment
Share on other sites

Quote

IMO the hi score cart not meaningfully existing in real hardware puts it into second-class status. Curt did a release of these, but due to a design flaw they don't actually retain the hi-scores for any length of time. A non-HSC compatible rom isn't a bad trade off for 52k contiguous rom. (though I agree with Pat that the 2x128K variants are where the action is at)

Right, and I also agree with Pat on the 2x128K / 256KB versions being the most appealing - so why not limit it to those four?

 

You can buy 256KB SST39SF020As on Mouser for ~ $1.70 in low quantities, cheaper in bulk, and peanuts if you go on a component safari. It'd be less hassle to have one generic design, with an upper bound like 2x128KB, than to support numerous smaller sizes where the gains of using the mapper aren't as high. Swap out the 256KB Flash for a 128KB one (like an SST39SF010A) and there's your lower tier option - no changes necessary except moving an address line to shift Sally and Maria's partitioning, you can even have a jumper on the board for that.

 

 

Quote

Yes, for sure I was generalising the meaning of the EXRAM/X2 bit, since implementation header parsers need to work in a particular context anyway. I think we've pretty much lost the battle for the current implementation of cart-type referring to a particular implementation of a feature, and the parser needs to be context-aware anyway. But if people don't agree, I will gladly grab another bit in cart-type for halt-banked ram.

I don't think we need to grab another bit, just formalize how the current ones are allocated. We can be more granular in the mythical, future header format.

 

Allocating Banksets as an exclusive mapper type with support for the EXRAM (Bit 2), EXFIX (Bit 4), POKEY @ $0450 (Bit 6), and POKEY @ $4000 (Bit 0) is a little more clear to me - and I think the EXRAM field meaning something else in this context is okay. If the available ROM sizes are restricted as I described above, then you could always assume paging is available and there's no contention with the SUPER field.

 

 

Quote

IMO I'd rather use those logic elements on other features, or minimise the cart design cost.

One feature I'm not seeing a lot of (and you may want to consider for future designs) is support for reprogramming or reflashing the cartridge in-system or at least from its edge. If you're manufacturing hundreds of boards this is kinda a big deal.

Link to comment
Share on other sites

4 hours ago, TailChao said:

Right, and I also agree with Pat on the 2x128K / 256KB versions being the most appealing - so why not limit it to those four?

For pretty much the same reasons why we we have homebrew boards for flat roms (32k, 48k) and homebrew boards for supergame, instead of funnelling every design into supergame. Sometimes the segmentation introduced by bankswitching isn't desirable, but a nice flat space is.

 

Quote

You can buy 256KB SST39SF020As on Mouser for ~ $1.70 in low quantities, cheaper in bulk, and peanuts if you go on a component safari. It'd be less hassle to have one generic design, with an upper bound like 2x128KB, than to support numerous smaller sizes where the gains of using the mapper aren't as high. Swap out the 256KB Flash for a 128KB one (like an SST39SF010A) and there's your lower tier option - no changes necessary except moving an address line to shift Sally and Maria's partitioning, you can even have a jumper on the board for that.

I'll leave this to @batari since it's not my lane.

 

4 hours ago, Pat Brady said:

This seems to be the big area of disagreement now.

 

I'm apparently falling on the end of being more permissive. It's mostly based on my observation that flashcart firmware does not get updated very often. If emulators are restrictive, no big deal: a7800 is open source, any developer can patch in whatever they need whenever they need it. But if flashcarts are restrictive then it is a big barrier.

 

To be clear, I am talking about combinations of features that are already supported. I am not asking anybody to code up some fantasy mapper or sound chip.

With current hardware combinations and flash carts, it's always an option to use the current version header, and mix and match to your delight. (as far as the flash cart supports the combination selected, anyway)

 

I think we're going to be talking in circles on this one. I'm desiring mappers with completely defined hardware for each, based on actual implementations, you're desiring general bankswitch schemes (un-bitfielded), with mix and match of the hardware options. The two approaches aren't compatible, and we both just disagree on which has the better cost/benefit.

 

Link to comment
Share on other sites

8 hours ago, Pat Brady said:

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.

Address decoding down to 16 bytes wastes logic unnecessarily on standalone cartridge hardware. It's great for a something like the XM where you have plenty of hardware to play with and lots of control registers scattered about, but that level of decoding is completely unnecessary for homebrew cartridge hardware.

 

POKEY at $800-$FFF, on the other hand, for example (and, there are other options than this), is far more simple to decode and conflicts with nothing that I am aware of. If programmers had chosen that instead as the standard, I could create much more powerful and capable hardware with homebrew-friendly parts.

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

While it's true that HDLs aren't exceedingly difficult to learn, the problem isn't that people aren't learning HDLs. It's that once you enter the realm of CPLDs and FPGAs, you are also leaving the realm of homebrew-friendly mappers.

 

In the past when you could still get 5v, PLCC CPLDs with through-hole PLCC sockets, one could argue that this thought was still workable. But now those old 5v CPLDs (not to mention, the tools to program them) are very difficult, nay impossible to find.

 

Now for anything beyond SPLDs and TTL parts, you need SMT stuff, mostly BGA (or fine-pitch LQFP or HVN if you are lucky) and you need level converters because nothing is 5v-tolerant anymore. This all just compounds together to not just increase the price of homebrew parts but put them even more out of reach for the typical hobbyist. Plus, CPLDs and FPGAs are currently a part of the silicon shortage, while SPLDs and TTL parts are in no major shortage and will continue to be available for decades to come.

  • Like 1
Link to comment
Share on other sites

5 hours ago, TailChao said:

Right, and I also agree with Pat on the 2x128K / 256KB versions being the most appealing - so why not limit it to those four?

 

You can buy 256KB SST39SF020As on Mouser for ~ $1.70 in low quantities, cheaper in bulk, and peanuts if you go on a component safari. It'd be less hassle to have one generic design, with an upper bound like 2x128KB, than to support numerous smaller sizes where the gains of using the mapper aren't as high. Swap out the 256KB Flash for a 128KB one (like an SST39SF010A) and there's your lower tier option - no changes necessary except moving an address line to shift Sally and Maria's partitioning, you can even have a jumper on the board for that.

 

One feature I'm not seeing a lot of (and you may want to consider for future designs) is support for reprogramming or reflashing the cartridge in-system or at least from its edge. If you're manufacturing hundreds of boards this is kinda a big deal.

I am aware that SMT parts like that are available but once you get there, you are in the realm of professional assembly. Plus I disagree with the notion that it's necessarily wise to design one board for everything with SMT parts. For either, you have to buy everything ahead of time and hope and pray it will be adopted, or else you just wasted thousands of dollars. The boards I am designing can be built in any quantity you want without requiring giant investments from anyone, and that is very appealing to the homebrew crowd.

  • Like 1
Link to comment
Share on other sites

19 minutes ago, RevEng said:

With current hardware combinations and flash carts, it's always an option to use the current version header, and mix and match to your delight. (as far as the flash cart supports the combination selected, anyway)

 

Yes, with the current combinations. But new features are being added frequently.

 

19 minutes ago, RevEng said:

I think we're going to be talking in circles on this one. I'm desiring mappers with completely defined hardware for each, based on actual implementations, you're desiring general bankswitch schemes (un-bitfielded), with mix and match of the hardware options. The two approaches aren't compatible, and we both just disagree on which has the better cost/benefit.

 

I don't think that's fair. I've taken feedback from you and @TailChao and updated my proposal accordingly. In particular, my last update (post #89) specifically allows you to list the currently valid combinations. It's really not very far at all from what I think you had in mind.

 

18 minutes ago, batari said:

POKEY at $800-$FFF, on the other hand, for example (and, there are other options than this), is far more simple to decode and conflicts with nothing that I am aware of. If programmers had chosen that instead as the standard, I could create much more powerful and capable hardware with homebrew-friendly parts.

 

First of all, thank you for providing Concerto. It may not have come through in my comments, but having a Concerto has been a huge boon for me as a developer and also very nice as a player.

 

The situation with POKEY@$0450 (as opposed to somewhere else) is chicken and egg. Programmers use $0450 because that's what's supported. Provide POKEY@$0800 (or wherever you want) on Concerto, one of us will add it to a7800, and we'll start using it. And, if it's not too late, and if @RevEng and @mksmith are on board, do it now, before banksets are released into the wild. Especially if that means you can do more other stuff on the bankset board!

Link to comment
Share on other sites

I don't think anyone is going to budge on which hardware design is best hardware design, so I'll step out of that. Let your soldering irons run free, unhindered. Huff massive quantities of flux.

 

 

But we also lost track of how to decode the header format as it stands today - despair.

 

Since my last proposal went unacknowledged - I'll assume Banksets is still a meta bit and none of the original template has changed, so it's treated as more of a shift key on the traditional flat mapping and SUPER paged schemes. To confirm...

  • EXRAM/X2 flag (Bit 5) when used in conjunction with BANKSET (Bit 13) still enables the Bankset's unique EXRAM scheme.
  • Does the payload size still reflect the true binary size? So 256KB ($40000) for a 2x128KB setup?
  • Payload sizes aren't rounded, so a 2x52KB setup is 104KB ($1A000)?
Link to comment
Share on other sites

...and a few more non-bankset things, as I'm forgetful.

 

  • Are we in agreement that EXFIX (Bit 4) is always going to be assigned to the LAST BANK - 1 (so page $1E in a 512KB ROM) and not locked to Bank 6 regardless of the cartridge size?
     
  • When either POKEYs or the YM2151 are placed in the $04xx region using Bit 11, 10, or 6 - these do not have any of the locking mechanisms as in the XBoard or XM's XCTRL register at $0470. It's implied these are in the cartridge and directly mapped.

    I'm okay with allowing three Pokeys in the cartridge, one more in the XM, and another two an XBoard to be a valid emulatable configuration. But I need to know that's what's implied.
     
  • Outside of the Cartridge Type field for a moment - the XM Bit @ $3F implies "compatible with" rather than "requires".
Link to comment
Share on other sites

2 hours ago, Pat Brady said:

The situation with POKEY@$0450 (as opposed to somewhere else) is chicken and egg. Programmers use $0450 because that's what's supported. Provide POKEY@$0800 (or wherever you want) on Concerto, one of us will add it to a7800, and we'll start using it. And, if it's not too late, and if @RevEng and @mksmith are on board, do it now, before banksets are released into the wild. Especially if that means you can do more other stuff on the bankset board!

 

Apologies if this sounded pushy. It just seemed like @batari wants to do this but thought programmers particularly want $0450. And I should also not speak for other developers, but my expectation is that most will use whatever address works.

Link to comment
Share on other sites

 

3 hours ago, Pat Brady said:

I don't think that's fair. I've taken feedback from you and @TailChao and updated my proposal accordingly. In particular, my last update (post #89) specifically allows you to list the currently valid combinations. It's really not very far at all from what I think you had in mind.

It wasn't a judgement on you, or my thinking you have lack of willingness to compromise, just a meta statement of where I see the discussion at. If anything I'm the unreasonable holdout there, as I don't see the point of doing mappers with the ability to specify additional hardware that isn't actually part of the mapper. Without that guarantee of 1:1 mapping to real hardware implementations, there's little point in chasing all of the detail for mappers. It's wasted effort, like working out calculations to 8 decimal places, when 2 decimal places represents your actual accuracy.

 

Quote

The situation with POKEY@$0450 (as opposed to somewhere else) is chicken and egg. Programmers use $0450 because that's what's supported. Provide POKEY@$0800 (or wherever you want) on Concerto, one of us will add it to a7800, and we'll start using it. And, if it's not too late, and if @RevEng and @mksmith are on board, do it now, before banksets are released into the wild. Especially if that means you can do more other stuff on the bankset board!

I'm happy to oblige on the software end of pokey@anywhere. Whatever works best for Fred. Holding on to the banksets test roms and emulation work for now, until a decision is made here.

 

1 hour ago, TailChao said:

But we also lost track of how to decode the header format as it stands today - despair.

 

Since my last proposal went unacknowledged - I'll assume Banksets is still a meta bit and none of the original template has changed, so it's treated as more of a shift key on the traditional flat mapping and SUPER paged schemes. To confirm...

  • EXRAM/X2 flag (Bit 5) when used in conjunction with BANKSET (Bit 13) still enables the Bankset's unique EXRAM scheme.
  • Does the payload size still reflect the true binary size? So 256KB ($40000) for a 2x128KB setup?
  • Payload sizes aren't rounded, so a 2x52KB setup is 104KB ($1A000)?

Nah, I just had a massive post last time, and I missed replying specifically to it. I don't have strong feelings either way on using SUPER as a flag, or size indicating an underlying SUPER scheme. My original thinking to use the super bit was to leave open the possibility that other bank schemes could be bankset'ized in the future. Should that unlikely day come we'll can just call it something else, and allocate another bank scheme or mapper. (which of those, depends on where the new header discussion has wound up.)

 

On the points raised...

  • yep
  • aye
  • correct, for the rom within the a78 file.
    Not what you asked, but just for completeness - the raw rom going on the eprom needs to be padded out so each bankset is the nearest power-of-two size. (ie. 2x64k) This is the same way we deal with plain 48k roms today. Because of this requirement, I think for non-power-of-two banksets and 48k roms, I'm going to update 7800basic to drop 3 files (a78, bin, pad) instead of the current 2 (a78, bin).

[edit - more points incoming as I was replying... :) ]

 

  • yes, complete agreement
  • yes, agreed. If someone wants the rom to use non-cart hardware pokeys (some kind of XMish thing) the a78 header for that rom shouldn't specify pokey bits.
  • yes, I don't believe anybody would argue with that. XM enhanced games were always a planned thing.

 

  • Like 2
Link to comment
Share on other sites

2 minutes ago, Pat Brady said:

Apologies if this sounded pushy. It just seemed like @batari wants to do this but thought programmers particularly want $0450. And I should also not speak for other developers, but my expectation is that most will use whatever address works.

No bad feels here, bud. :) 

  • Like 1
Link to comment
Share on other sites

Quote

I don't have strong feelings either way on using SUPER as a flag, or size indicating an underlying SUPER scheme. My original thinking to use the super bit was to leave open the possibility that other bank schemes could be bankset'ized in the future. Should that unlikely day come we'll can just call it something else, and allocate another bank scheme or mapper. (which of those, depends on where the new header discussion has wound up.)

It makes sense as an extension to the available flat and SUPER schemes (with the exception of special casing the EXRAM/X2 field) since it really is just doubling the ROM sizes and sticking Maria's fetches in the upper half.

 

I'll update my documentation for the rest of the header's fields over the next few days, in case y'all decide POKEYs are going to move. If that's the case, it'd be nice if the new POKEY could use Bit 14 of the cartridge type field, instead of special casing a pre-existing one. Then we'd still have Bit 15 left as an escape.

 

I still think the three prong approach to flagging a header as in the new format is best, so...

  • Cartridge Type @ $35 - $36 == $8000, closer to @Pat Brady's suggestion in case we end up needing Bit 14.
  • "ATARI7800" Magic Text @ $01 - $09 is extended to "ATARI7800-EX" @ $01 - $0C, the region from $0D - $10 is zeroed instead of being padded with spaces (conveniently four bytes).
  • Version Number @ $00 is increased to $04.

...which leaves little room for collision and is easy to discern in a pinch.

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

On 3/11/2022 at 1:22 AM, TailChao said:

 

 

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

 

Yeah, as the inventor of this header I wanted to keep it under control back then. It's no longer a battle I wish to fight. :)

  • Like 2
Link to comment
Share on other sites

23 hours ago, TailChao said:
On 3/11/2022 at 7:38 AM, splendidnut said:

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.

These already exist as SOUPER and the unreleased PMC1, albeit the pages are strictly for Maria so you don't have to worry about contention. The former allows you to access texture data anywhere ROM as 2 x 2KB Pages, or in EXRAM in 4KB chunks. The latter is more of the same ramped up to a scale of too much and tosses in another paging method to make managing Display Lists (and also scrolling) easier - but is also a little closer to your layout.

 

So it's totally doable, but why not take it further and give Maria her own pages entirely!

Sure, but my intention was to point out an example scheme that was general enough to be easily implementable on hardware and software...without going overboard in the memory mapping category, which you could argue my example still does.  I think having a simple/robust 4k switchable would be beneficial, hopefully to more than just me.  I'd also like something that could easily run on the Concerto cart as that's the development cart I have on hand... and the most likely target hardware for eventual release in the AtariAge store.

 

I'm just trying to plan ahead for

 

which would benefit greatly from having the ability to swap 4k ROM banks... both from a code and from a data perspective.

  • Like 1
Link to comment
Share on other sites

2 hours ago, DanBoris said:

Yeah, as the inventor of this header I wanted to keep it under control back then. It's no longer a battle I wish to fight. :)

Haha, totally understood.

 

33 minutes ago, splendidnut said:

I think having a simple/robust 4k switchable would be beneficial, hopefully to more than just me.  I'd also like something that could easily run on the Concerto cart as that's the development cart I have on hand... and the most likely target hardware for eventual release in the AtariAge store.

It's your call - I don't want to speak for distribution requirements as mine were completely different than nearly every other release here. I think playing in software emulation or on the MiSTer has the broadest audience. But generally if you're going to spin new mapping hardware it's better to look as far forward as possible, so you only have to design it once. Then you just bump the numbers later.

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

38 minutes ago, splendidnut said:

At the end of the day, it's just food for thought.  Beggars can't be choosers.

 

Though now I'm tempted to start hacking away at A7800 to play around with it... there goes my weekend :)

Replace A7800 with ProSystem and that's how I drafted my own junk. Sorry to keep pushing SOUPER but it's already had several years of existing and is supported in the MiSTer and also in the upcoming 7800GD. So it's a tested, stable, permissively open source choice and I stand behind it.

 

 

Yo @RevEng, since we're integrating banksets as part of the last call for the old header format - can I steal byte $3E for an IRQ routing field?

Bit 7 - 4 : Reserved, set to zero
Bit 3 : YM2151 @ $0460
Bit 2 : POKEY @ $0440
Bit 1 : POKEY @ $0450
Bit 0 : POKEY @ $4000

SET ('1') indicates the device has its IRQ pin routed to the cartridge's edge.
CLEAR ('0') means the IRQ pin isn't connected.

 

If IRQs are routed for multiple devices (i.e. both POKEY @ $4000 and the YM2151 @ $0460) they'll be logically AND'ed together, so the IRQ line will stay low if any of the possible four devices is pulling on it.

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

Rad.

 

I guess I wasn't clear enough earlier, but I'm writing an entirely new guide targeting emulator authors and flash cartridge developers based upon BupSystem's HTML Help and will paste it in here. Just try and establish some sort of standard as to what the terminology is for each feature, what should be reasonably permitted, and the quirks required for dealing with the header's growing pains over years - as the current resources are scattered and desynchronized. Then we'll have a bookend before the new header shows up.

 

But if you want to duplicate it that's cool. My big concern right now is whether y'all are going to drop another POKEY @ $0800 before the gate closes.

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

21 hours ago, TailChao said:

I don't think anyone is going to budge on which hardware design is best hardware design, so I'll step out of that. Let your soldering irons run free, unhindered. Huff massive quantities of flux.

This isn't about what is "best" but what is practical and available, and the discussion of that, I feel, is positively important.

 

Any combination put forward should have a board available that supports it, a game that already supports it, or a board could be made in theory at a homebrew-friendly cost.

 

Allowing every combination under the sun is really pointless. New mappers should be co-designed with the homebrew hardware that supports them. Allowing arbitratry mappers without a physical board could make it impossible or impractical to release a game. Invariably such formats usually end up dead in the water when nobody adopts them, but even if they do, the result may be to force someone's hand into a digital-only release. My opinion is if things get to that point, we have really gone off into the weeds, like some in the NES crowd are doing, and I don't want to follow that lead.

3 hours ago, TailChao said:

Replace A7800 with ProSystem and that's how I drafted my own junk. Sorry to keep pushing SOUPER but it's already had several years of existing and is supported in the MiSTer and also in the upcoming 7800GD. So it's a tested, stable, permissively open source choice and I stand behind it.

In my opinion, support on emulators, third-party hardware or flashcarts is not a path to adoption by itself. What I believe the homebrew community is ultimately about is releasing actual cartridges that work on real hardware (am I wrong?) I don't believe I have ever seen a case where support of a modern mapper in emulators, third-party hardware and flashcarts has directly led to the production of a low-cost (ideally under $15, maybe $20 max) homebrew board. I have only ever seen it work the other way - someone has to spend thousands producing a low-cost board with no expecation of profit and hope to break even.

 

While I think Souper and its variants are great, without a low-cost board that is available for an actual game release (preferably through AtariAge), history has shown that few are willing to adopt any new format. It's the chicken-and-egg problem that has come up so many times before in the 2600 arena. Open-sourcing hasn't been enough in the past for something to truly take off. Homebrewers do not seem willing to spend a thousand hours on a game unless they are certain their game can see the light of day on a cart, and nobody is willing to mass-produce hardware that has no software to release. The only way I have ever seen costly hardware used was when it was produced by the same team or person working on a game, and then it only saw the light of day with that one game.

 

That said, I may be willing to make a Souper/Sublet/Subpar board for AtariAge for no profit to me, but I am not going to spend a second on that unless a game already exists that AtariAge can actually release, as I am busy enough and don't want to waste my time. I suppose something could happen in that regard if you were willing to license Rikki and Vikki to AtariAge. If you would be willing to do that, I am sure it would make many people happy (save for the eBay scalpers) and could be the path to adoption of the format.

  • Like 2
Link to comment
Share on other sites

1 hour ago, batari said:

Any combination put forward should have a board available that supports it, a game that already supports it, or a board could be made in theory at a homebrew-friendly cost.

 

As the (only?) person who's been banging the drum for supporting things that don't currently exist in hardware form, I want to explicitly endorse this definition. My intent was never to enable emulation of implausible hardware. This is a good balance.

 

And for the combinations in the 2nd and 3rd categories: I am totally on board with emulator and/or header-generator warnings. Alert developers that they need to do the boards (or get somebody else to) without blocking development.

Link to comment
Share on other sites

8 hours ago, TailChao said:

Yo @RevEng, since we're integrating banksets as part of the last call for the old header format - can I steal byte $3E for an IRQ routing field?

Heads-up that some homebrews have unused bytes set to $FF, including $3E. $FF is dasm's default fill, so this probably wasn't an intentional choice.

 

One of those $3E reserved bits could be checked for "1" as n ignore flg, but instead I'm just inclined to just consider it a header error, and ask @Trebor to clean these up in his pack. (the $FF bytes are there from the original authors. Trebor uses 7800header whenever he modifies or fixes a header, and it sets unused bytes to $00)

 

  • Like 1
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...