A78 header changes

[+batari]

2 hours ago, RevEng said:

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)

 

The only reason that unused areas are filled with $FF is because that is the default value of an erased UV EPROM, and EPROM burners can skip over these areas for faster burning. Other than that there is no reason those areas can't be filled with whatever, if I am understanding the request right.

[RevEng]

14 hours ago, batari said:

The only reason that unused areas are filled with $FF is because that is the default value of an erased UV EPROM, and EPROM burners can skip over these areas for faster burning. Other than that there is no reason those areas can't be filled with whatever, if I am understanding the request right.

Ah, nice context for the default fill value.

 

For sure we can change it. I just looked and the "official" assembly header I've been updating and republishing in this thread is using ORG without a fill value to skip those bytes, so it's to blame. The only reason why it's showing up in a minority of Trebor's roms (25) is he's using the 7800header tool, which has zeroed the bytes.

 

When I update the assembly header for TailChao's interrupt field, I'll ensure it uses zero fill for org.

 

[TailChao]

15 hours ago, Pat Brady said:

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.

I think being permissive to the point of allowing most configurations as long as they don't conflict in an impossible way (i.e. both EXRAM and EXROM in a SUPER cartridge) is the way to go with the current header - from the perspective of writing a software emulator, implementing a MiSTer core, or designing a flash cartridge. It's up to developers to figure out what they want.

 

Allowing any of the sound chips in the $04xx region for use with the ACTIVISION mapper won't break anything and makes it easier to manage, so why not? A warning in the documentation is fine, but the software shouldn't bark at you.

 

 

15 hours ago, RevEng said:

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)

Yep, I'm aware of that. I think there's an easier workaround - only enable the interrupt lines if the pertinent chip is also instantiated, the cartridge type bytes are usually clean. There's already a few other quirks involved in parsing and this one is no biggie.

 

Addendum : Or, if being thorough, also require the version field to be $03 or greater. But in any case yeah, I agree - this is better applied as a pack cleanup job.

 

 

Quote

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.

Having collaborated with developers from this community, and not noticing any issues, I'm a little confused here.

 

I think it's best if I step out after we close the current header definition and let y'all figure out what to do for the next revision. I'm not the right person to make decisions for a community driven format here.

Edited March 13, 2022 by TailChao

[TailChao]

To make sure I don't stray too far while writing, here's how I'd like to break out header fields...

 

Features

• EXFIX
  LAST 16KB ROM BANK - 1 @ $4000 - $7FFF (implied for SUPER Cartridge layout)
   
• EXRAM
  16KB SRAM @ $4000 - $7FFF
   
• EXRAM/X2
  32KB SRAM arranged as 2x16KB
  • Page is controlled by Bit 5 of the mapping register in SUPER + EXRAM/X2 cartridges, this is only allowed for binaries 512KB or less (1).
  • Page is controlled by access region and bus master (Sally or Maria) in BANKSET + EXRAM/X2 (+ SUPER) cartridges (2).
     
• EXROM
  16KB ROM @ $4000 - $7FFF
  Secondary ROM which is added to the start of the binary payload, and followed by the Primary ROM.
   
• EXRAM/A8 (or MIRROR RAM)
  8KB SRAM @ $4000 - $7FFF
  The attached SRAM has address lines A8 - A13 shifted up by one (SRAM A8 -> SLOT A9, SRAM A9 -> SLOT A10, ... SRAM A13 -> SLOT A14), this has the effect of doubling up raster lines when Maria fetches graphics.
   
• LAAB (or Lower Address Audio Block)
  The terrible trio of...
  POKEY @ $0450 - $045F
  POKEY @ $0440 - $044F
  YM2151 @ $0461 - $0462
  ...while we can still refer to the chips individually, I'd rather group all of the audio accessories living in this segment now (and any which may be added later) under one banner.

 

 

Cartridge Type Hierarchy

• FLAT (16KB - 52KB)
  • 16KB, 32KB
    • EXRAM or EXRAM/A8
    • + POKEY @ $4000 (3)
    • + LAAB
    • + BANKSET
      • EXRAM/X2 (2)
  • 48KB, 52KB
    • + POKEY @ $4000 (3)
    • + LAAB
    • + BANKSET
• SUPER
  • EXFIX or EXRAM or EXRAM/A8 or EXRAM/X2 (1) or EXROM
  • + POKEY @ $4000 (3)
  • + LAAB
  • + BANKSET
    • EXRAM/X2 (2)
• SOUPER
  • + LAAB
• ABSOLUTE
  • + LAAB
• ACTIVISION
  • + LAAB
     

Where or implies "pick one or none", + means the features can be stacked, and issue (3) is forcing a POKEY @ $4000 - $7FFF to be write only if it conflicts with anything else spun up in that region. I'm going to go out on a limb and say it's probably okay to allow any members of the LAAB to be assigned to any cartridge.

 

I don't think allowing EXROM for a 32KB cartridge makes sense, since we have the 48KB size for that. There would also be some special case requirements when BANKSET'ing FLAT or SUPER cartridges - EXROM is out. The above should safely cover what's in the ProPack now and, while allowing really crazy stuff to be used, is simpler to manage (in my opinion) from a software perspective.

 

Make sense so far?

Edited March 13, 2022 by TailChao

[RevEng]

Makes sense to me.

 

No additions, but somewhat related, or at least impacting... the pokey@800 work is underway, for banksets, supergame, and concerto. Since this thread was the impetus for the pokey@800 change, It seems natural we should discuss if pokey@800 gets a bit in the current scheme, or if it has to wait for the upgraded header. Seeing that we have some disagreement on the way forward with v4 headers, I'd personally prefer to squeeze it in now, so I can update a7800 for all of it.

[+Pat Brady]

57 minutes ago, RevEng said:

No additions, but somewhat related, or at least impacting... the pokey@800 work is underway, for banksets, supergame, and concerto.

??

 

Looking forward to seeing what this enables.

57 minutes ago, RevEng said:

Since this thread was the impetus for the pokey@800 change, It seems natural we should discuss if pokey@800 gets a bit in the current scheme, or if it has to wait for the upgraded header. Seeing that we have some disagreement on the way forward with v4 headers, I'd personally prefer to squeeze it in now, so I can update a7800 for all of it.

FWIW my feeling is that we're approaching agreement on the v4 stuff.

 

But, I know that you've got a game that's nearly ready to go, and if I was in that situation I would not want to delay it for committee deliberations.

 

I think the best way to go is: use bit 14 for @Eagle's SN76489 project (which was the impetus for this entire discussion), bit 15 for POKEY@$0800, and specify $FFFF as the warning signal. Based on @TailChao's analysis, which determined that some readers mask the high bits, $FFFF seems like a better warning signal than $8000 anyway.

 

The other option I thought of was to repurpose bit 10 under circumstances where POKEY@$0440 doesn't make sense. But this adds more complexity.

 

Semi-related: is there a stand-alone board that provides POKEY@$0450?

[RevEng]

14 minutes ago, Pat Brady said:

I think the best way to go is: use bit 14 for @Eagle's SN76489 project (which was the impetus for this entire discussion), bit 15 for POKEY@$0800, and specify $FFFF as the warning signal. Based on @TailChao's analysis, which determined that some readers mask the high bits, $FFFF seems like a better warning signal than $8000 anyway.

Works for me!

 

14 minutes ago, Pat Brady said:

Semi-related: is there a stand-alone board that provides POKEY@$0450?

cpuwiz's versa boards do. I believe there are new designs that will cover the same formats. Regardless of where we wind up with mappers, we need to document what the available homebrew boards and their capabilities are.

[+batari]

OK, so I want to talk about EXRAM/A8. I don't recall ever seeing mention of this before, and I want some things clarified.

 

The description: "EXRAM/A8 (or MIRROR RAM)
8KB SRAM @ $4000 - $7FFF
The attached SRAM has address lines A8 - A13 shifted up by one (SRAM A8 -> SLOT A9, SRAM A9 -> SLOT A10, ... SRAM A13 -> SLOT A14), this has the effect of doubling up raster lines when Maria fetches graphics."

 

So I want to ensure I am understanding this right. So the 8k RAM in 16k space is hardwired? That is, there is not some logic in the mapper itself to enable/disable A8 pass-through to mirror or not mirror the RAM?

 

That brings up the question: if the mapper treats it as hardwired, why not just use normal RAM and copy the data twice? Just do two writes, one with A8=0 and another with A8=1 during the setup of the DLL, then we don't need to worry about special hardware or designing it into a board (which would either waste logic or otherwise be inelegant: i.e. jumpers.)

 

I mean, I am all for hardware that expands the capabilities of the system beyond to something that is not really possible in ordinary hardware, but it seems all this does is save a few cycles in a copy-to-RAM loop. In that regard, I don't really get why that is so useful, much less useful enough to make it a nascent feature in every possible combination of mappers.

 

That is, unless I am missing something - if so please help me to understand what I am missing.

[+batari]

4 hours ago, Pat Brady said:

 

Semi-related: is there a stand-alone board that provides POKEY@$0450?

Yes, I have designed several, and one of them requires it (because $0800 is used for something else).

 

If someone really needs $0450 for whatever reason, I suppose it can be accommodated.

[TailChao]

11 hours ago, RevEng said:

No additions, but somewhat related, or at least impacting... the pokey@800 work is underway, for banksets, supergame, and concerto. Since this thread was the impetus for the pokey@800 change, It seems natural we should discuss if pokey@800 gets a bit in the current scheme, or if it has to wait for the upgraded header. Seeing that we have some disagreement on the way forward with v4 headers, I'd personally prefer to squeeze it in now, so I can update a7800 for all of it.

7 hours ago, Pat Brady said:

I think the best way to go is: use bit 14 for @Eagle's SN76489 project (which was the impetus for this entire discussion), bit 15 for POKEY@$0800, and specify $FFFF as the warning signal. Based on @TailChao's analysis, which determined that some readers mask the high bits, $FFFF seems like a better warning signal than $8000 anyway.

If possible, I'd prefer we allocate the last two bits as...

• Bit 15 : ESCAPE (new or extended header indicator)
• Bit 14 : POKEY @ $0800 - $080F
   

Where the ESCAPE indicates this is going to use the extended (future) format, and then you all can figure out exactly how that will work. While I was originally pushing for a value like $C000 or $8000 - after looking at hundreds of these files it might be better to allow existing fields like the lower address audio block to be carried forward.

 

The SN76489 based cartridge seems to also have a mapper attached, so that might be better to nudge it in after the pivot (and its design is finalized).

 

 

3 hours ago, batari said:

So I want to ensure I am understanding this right. So the 8k RAM in 16k space is hardwired? That is, there is not some logic in the mapper itself to enable/disable A8 pass-through to mirror or not mirror the RAM?

That's correct, it was a hardwired configuration used by the prototype of Rescue on Fractalus.

 

3 hours ago, batari said:

I mean, I am all for hardware that expands the capabilities of the system beyond to something that is not really possible in ordinary hardware, but it seems all this does is save a few cycles in a copy-to-RAM loop. In that regard, I don't really get why that is so useful, much less useful enough to make it a nascent feature in every possible combination of mappers.

I don't care for it either - but it exists and some interest has been expressed, so it may as well get tossed in the compatibility list.

[RevEng]

The main point of mirror ram is to cut down on the number of expensive pixel-update operations on a ram-backed bitmap, like the main game view in Rescue on Fractalus. In a ram-based bitmap game with a decent amount of screen draw, cpu will almost certainly be a bottleneck on the frame rate, with pixel updates being the main consumer. In this context, mirror ram is very useful.

 

[edit] Think of Maria's goofy graphics layout requirements and non power-of-two screen width, and how that might make the second pixel memory update less than trivial.

[TailChao]

While I fear this may send the thread spiraling off topic again, I cannot resist the cycle count bait...

19 minutes ago, RevEng said:

The main point of mirror ram is to cut down on the number of expensive pixel-update operations on a ram-backed bitmap, like the main game view in Rescue on Fractalus. In a ram-based bitmap game with a decent amount of screen draw, cpu will almost certainly be a bottleneck on the frame rate, with pixel updates being the main consumer. In this context, mirror ram is very useful.

 

[edit] Think of Maria's goofy graphics layout requirements and non power-of-two screen width, and how that might make the second pixel memory update less than trivial.

Exactly, yes. If there's a happy accident involved, it's that you can actually buy 8KB SRAMs to fill the $4000 - $7FFF segment instead of using a 32KB chip with half of its capacity disabled.

 

Regarding Maria's graphics layout - while it's a little weird, looking at the entire address space as a big texture with really coarse U,V coordinate granularity makes a lot more sense. So when you're software rendering a giant texture, only having to do every other line is a nice perk and most players won't notice the halved vertical resolution in the 160x modes.

[RevEng]

44 minutes ago, TailChao said:

Where the ESCAPE indicates this is going to use the extended (future) format, and then you all can figure out exactly how that will work. While I was originally pushing for a value like $C000 or $8000 - after looking at hundreds of these files it might be better to allow existing fields like the lower address audio block to be carried forward.

 

The SN76489 based cartridge seems to also have a mapper attached, so that might be better to nudge it in after the pivot (and its design is finalized).

Yeah, forgot about the compatibility issue with FFFF as a flag on my last reply.

 

I'm up for SN76489 being pushed, but I'd like to hear from @Eagle that he's good with it, since I'd be taking his bit.

[+Pat Brady]

4 hours ago, batari said:

Yes, I have designed several, and one of them requires it (because $0800 is used for something else).

 

If someone really needs $0450 for whatever reason, I suppose it can be accommodated.

 

I was just curious whether a board that can host Popeye or Pengo/Penta is something that exists, and about the urgency of switching new SuperGame homebrews (with ROM or RAM at $4000) from POKEY@$0450 to POKEY@$0800.

 

 

1 hour ago, RevEng said:

The main point of mirror ram is to cut down on the number of expensive pixel-update operations on a ram-backed bitmap, like the main game view in Rescue on Fractalus. In a ram-based bitmap game with a decent amount of screen draw, cpu will almost certainly be a bottleneck on the frame rate, with pixel updates being the main consumer. In this context, mirror ram is very useful.

 

[edit] Think of Maria's goofy graphics layout requirements and non power-of-two screen width, and how that might make the second pixel memory update less than trivial.

 

Right. I recently changed my game to use a RAM buffer for the primary enemy, and I was shocked at how many SALLY cycles it takes just to clear my relatively small buffer.

 

(I also use RAM buffers for playfield, but the big updates to that don't have to meet screen timing.)

 

 

1 hour ago, TailChao said:

If possible, I'd prefer we allocate the last two bits as...

• Bit 15 : ESCAPE (new or extended header indicator)
• Bit 14 : POKEY @ $0800 - $080F
   

Where the ESCAPE indicates this is going to use the extended (future) format, and then you all can figure out exactly how that will work. While I was originally pushing for a value like $C000 or $8000 - after looking at hundreds of these files it might be better to allow existing fields like the lower address audio block to be carried forward.

 

I'm a bit confused here. Bit 15 is $8000.

 

 

31 minutes ago, RevEng said:

Yeah, forgot about the compatibility issue with FFFF as a flag on my last reply.

 

I'm up for SN76489 being pushed, but I'd like to hear from @Eagle that he's good with it, since I'd be taking his bit.

 

I don't have an iguana in this fight — deferring SN76489 is totally fine with me if it's fine with @Eagle — but what's the compatibility issue with $FFFF?
 

[RevEng]

2 minutes ago, Pat Brady said:

I don't have an iguana in this fight — deferring SN76489 is totally fine with me if it's fine with @Eagle — but what's the compatibility issue with $FFFF?

If we use FFFF as a flag to indicate a new header is present, it breaks backward compatibility for older emulators. That's fine if the header asks for new hardware the emulator doesn't support anyway, but less than ideal if the emulator is capable of providing the hardware requested.

 

Faced with that choice, a dev will avoid using the new format unless their hand is forced. This will make adoption of the new header a niche thing. That's fine if the goal is to only be a field extension (and cleanup) of the old scheme, but it's not good if the goal is to define specific mappers to simplify things for implementors.

[+splendidnut]

My suggestion would be to NOT reserve any more bits in the bit field and actually make a more robust header scheme first.  It doesn't make any sense to me to add to the legacy format when you're on the verge of essentially deprecating it.

 

But, you can take my suggestion with a grain of salt since I don't really have skin in the game yet.

[+Pat Brady]

Just now, RevEng said:

If we use FFFF as a flag to indicate a new header is present, it breaks backward compatibility for older emulators. That's fine if the header asks for new hardware the emulator doesn't support anyway, but less than ideal if the emulator is capable of providing the hardware requested.

 

Oh. I was thinking to use FFFF only when the new headers are necessary (i.e. older emulators should not attempt to run this program), not whenever they are present.

[TailChao]

16 minutes ago, splendidnut said:

My suggestion would be to NOT reserve any more bits in the bit field and actually make a more robust header scheme first.  It doesn't make any sense to me to add to the legacy format when you're on the verge of essentially deprecating it.

 

But, you can take my suggestion with a grain of salt since I don't really have skin in the game yet.

Nah, I agree here - the line should be drawn firmly and soon. I'd like to at least reserve the upper bit as an escape code though.

 

@RevEng - Is PETSCII Robots's board configuration already prototyped or manufactured in one of the BANKSET arrangements you've published? Or are you thinking of moving the POKEY to $0800 for all of them now. If it's the former, I think we should leave Bit 14 empty (reserved as zero) and that'll draw the line in the old world header's capabilities.

Edited March 14, 2022 by TailChao

[RevEng]

4 minutes ago, TailChao said:

Nah, I agree here - the line should be drawn firmly and soon. I'd like to at least reserve the upper bit as an escape code though.

 

@RevEng - Is PETSCII Robots's board configuration already prototyped or manufactured in one of the BANKSET arrangements you've published? Or are you thinking of moving the POKEY to $0800 for all of them. If it's the latter, I think we should leave Bit 14 empty (reserved as zero) and that'll draw the line in the old world header.

Yes - it's already prototyped and running on real hardware for a month or two now - pokey@800 will replace pokey@450 in the original list. I believe we're still keeping the ones with pokey@4000 instead of moving them to pokey@800 (less decoding work), but I'll ask @batari to confirm.

[TailChao]

2 minutes ago, RevEng said:

Yes - it's already prototyped and running on real hardware for a month or two now - pokey@800 will replace pokey@450 in the original list. I believe we're still keeping the ones with pokey@4000 instead of moving them to pokey@800 (less decoding work), but I'll ask @batari to confirm.

lmao, I had former and latter backward but you get the idea.

 

No offense - if the BANKSETs format is still not firmly defined and you're removing the POKEY @ $0450 - $045F configuration, then I'd vote to bump it to the new header format after you've finalized the design and shipped the game.

[RevEng]

It's been defined and implemented for months, with the pokey location being the only change. After making the point that Activision+pokey@450 should be a valid combination in the current header, I don't see where you're making the leap that a pokey location change disqualifies my current bit allocation due to non-implementation.

 

[TailChao]

27 minutes ago, RevEng said:

It's been defined and implemented for months, with the pokey location being the only change. After making the point that Activision+pokey@450 should be a valid combination in the current header, I don't see where you're making the leap that a pokey location change disqualifies my current bit allocation due to non-implementation.

It's moreso that we'll have to allocate another bit for the POKEY, and I kinda agree with @splendidnut to cut the format specification now - not to exclude your hardware for not existing. It's certainly not stopping it.

 

Again, you're the one primarily driving this bus - so do what you want, I'm just writing a manual. But I don't think deferring this to the extended header is going to affect the game's development or anyone else's work.

 

EDIT : Upon further thought - this would also allow the BANKSETs unique RAM paging to be its own field instead of special casing EXRAM/X2.

Edited March 14, 2022 by TailChao

[+splendidnut]

Throwing out some of my own thoughts:

 

Cartridges can contain 3 or 4 categories of things:  ROM, RAM, Audio Hardware, and other (HighScoreCart, New Input Device, Wifi?)

 

I've been trying to think of ways to nicely describe the miscellaneous ROM/RAM configurations, like having them separated out into different fields... But I almost think it would be best to just have a numbered list of mappers, ala NES.  And use a 16-bit value in the header as an index into that list which should allow vast future expansion.  Keeps things simple.  I'm not sure if it's necessary to overly complicate things here. 

 

//  cartridgeMemoryMapper - 16-bit value

//   0..15 = ROM only (no-bankswitching) 0=16kb, 1=32kb, 2=48k, etc.

//    16    = supergame

//    17    = supergame with RAM at $4000

//    18    = activision

//    19    = absolute

//    20    = souper

//    21    = banksets

//    22    = Eagle's new format...

//   .... etc    

 

For Audio and other devices, I'm thinking of an array of values as enumerations into another mapping table, so that you could specify multiple devices in a cart.

 

//  cartridgeDevice[8]  - 8-bit value (or more)

//     0 = none

//     1 = pokey @ $450

//     2 = pokey @ $800

//     3 = pokey @ $4000

//     4 = ym2151 @ $460

//     5  = BupChip

//     6  = SN76489 @ ....

//    ... etc

//     78 = WiFi?

 

Emulators could get away with having a table with all of the mappings ... BUT, I'm not sure if that's the best way for the hardware implementation (Multicarts).

 

Thoughts?

[+batari]

4 hours ago, Pat Brady said:

I was just curious whether a board that can host Popeye or Pengo/Penta is something that exists, and about the urgency of switching new SuperGame homebrews (with ROM or RAM at $4000) from POKEY@$0450 to POKEY@$0800.

Boards do exist that support 144k with a POKEY at $0450, so yes, these games can be accommodated if necessary. The boards do not exist in large numbers but they can be produced on demand. If there is a change to $0800, though, I would redesign boards and likely I'll be able to support larger game sizes with the same logic, or support the same game sizes with lower-cost parts. I don't think it's a big deal to change the POKEY location in source and rebuild. For testing I have done it without source at all, with only binary hacking - so even in the worst case where the change can't be made at the source level, I can still often make the change.

[+batari]

4 hours ago, RevEng said:

Yes - it's already prototyped and running on real hardware for a month or two now - pokey@800 will replace pokey@450 in the original list. I believe we're still keeping the ones with pokey@4000 instead of moving them to pokey@800 (less decoding work), but I'll ask @batari to confirm.

Yes, there is value with being able to design a board with a TTL chip rather than a PLD, and POKEY @4000. Even with a 48k game and write-only POKEY under the EXROM, this may all be decoded with the single TTL chip.

 

As far as banksets go, I'm also working on a TTL-based 32k/48k board for that, even if this turns out to be an academic exercise (I would say that once you hit 3 TTL chips you may as well just use a PLD.)