A78 header changes

[RevEng]

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

5 hours ago, TailChao said:

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

To me you're saying it only makes sense to put Petscii Robots and the Pokey@800 solution on the back foot, as we now need to all come to a consensus on v4 first, implement v4, and hope enough implementors to take up both banksets/pokey@800 *and* v4 header parsing in sufficient time. Implementing banksets or pokey@800 genuinely isn't much more work than a copy+paste and a little modify, but the latter is going to to require a bit more considered thought.

 

If we were out of cart-type bits, or if I saw value in those upper bits being held back as versioning breadcrums, I'd accede. IMO providing three independent versioning mechanisms within the header is the wrong approach. Do implementers need to validate all of these version sources, some of them, or take their pick? Which of these is three version mechanisms is authoritative? When we go to v5, do we now up-rev all three of these version information sources? Do we add a few more breadcrumbs to make the v4 to v5 version change more obvious?

 

4 hours ago, splendidnut said:

Throwing out some of my own thoughts:

[...]

Thoughts?

We've talked about mappers - I'm all for them - but there's a proviso. What you've listed isn't quite 1:1 to the mapper concept, as those reference specific target hardware. What you've listed is a series of general bankswitch schemes, and cart-independent features (which @Pat Brady suggested a while back) To underline the distinction - there are now 3 or 4 supergame implementations (without counting flash carts) - the original ones by atari, a couple of the cpuwiz boards, and new batari's. There's probably a few more variations within those board sets, but it's good enough for illustration. You may think this isn't an important distinction, but there differences in implementation behaviour - e.g. a cpuwiz board will have pokey@450 with mirrors every $10 bytes that follow. Other pokey@450 implementations may or may not have this behaviour... certainly DF cart doesn't. If someone enables the pokey@450 feature with supergame bankswitching, which behaviour should the emulator take on?

 

At least to me, a mapper documents a hardware implementation exactly. I'm actually in the camp that even adding other common cart peripherals - pokey, rom at particular locations - should necessitate a new mapper index. They're indexes, so being expansive here doesn't have a large cost. But I'm completely fine with TailChao's suggestion of a mapper-specific set of board hardware options, because it doesn't degrade the descriptive precision.

 

If an implementer doesn't want the added precision of each target board within their implementation, it's easy to downgrade the precision by lumping the mappers together by bankswitch scheme, within the implementation parser.

 

So we have a clash of ideas as to what v4 should look like - bankswitching schemes with mix and match add-ons, as you've suggested, or highly specific mappers. (with or without generic add-ons. I still argue that non-mapper-specific add-ons is low-precision, making the higher precision of mappers pointless). There's nothing wrong with either approach, but there are pros and cons either way. We've gone over those earlier, before we moved on to immediate v3 header discussion, so you can go back a few pages if you're interested.

 

[+splendidnut]

I was just throwing out an idea of expanding a bit beyond mappers as I'd like to see a separation between bankswitching/RAM and extra audio (or other) hardware.  And since I'm not seeing a lot of examples being thrown out there, I thought I would put one out there.

 

If what I proposed is ultimately not possible due to the programmer/hardware developer shenanigans, then probably a simple mapper number/table is the way to go.

[+batari]

8 hours ago, TailChao said:

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

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.

Sure, you could theoretically use an 8k SRAM, if you can find one at all.

 

In practice there are probably two orders of magnitude more 32k chips on the market (if not more than that) and almost certainly for a significantly lower price than any 8k chip you will ever find. I have actually never even seen an 8k chip for sale anywhere but I would imagine that if you could even find them, they would start at an order of magnitude more than the cheapest 32k chip.

 

Banksets was thought of partially in response to this supply quirk, as even 16k SRAM leaves half unused, and it's a great way to take advantage of the capacity that is already there, basically for free.

 

I currently have over 1,500 32k SRAM chips on hand and could find tens of thousands (if not hundreds of thousands) more pretty easily if I wanted to.

[+batari]

In case it wasn't clear, my vote would be to relegate the EXRAM/A8 to its former obscurity rather than bring it to the forefront, particularly if it is only used in a single prototype and nowhere else.

[RevEng]

To clarify your clarification, what action are you voting for? Are you thinking removal from the header, active discouragement of it's usage, or ...?

 

The feature has a lot of utility for ram-based bitmaps, it's just that homebrewers haven't moved into ram-based bitmaps significantly yet, but I don't think that's a forever and ever state. It's perfectly fine to not support the feature with your designs. I'm not sure there's justification to discourage it beyond that.

[TailChao]

17 hours ago, RevEng said:

To me you're saying it only makes sense to put Petscii Robots and the Pokey@800 solution on the back foot, as we now need to all come to a consensus on v4 first, implement v4, and hope enough implementors to take up both banksets/pokey@800 *and* v4 header parsing in sufficient time. Implementing banksets or pokey@800 genuinely isn't much more work than a copy+paste and a little modify, but the latter is going to to require a bit more considered thought.

I'm lost on the version numbering - I thought v3 is going to be the last of the "old world" header (which we're figuring out now) and v4 is going to be the first "new world" format with the cool extensions. But anyway...

 

 

17 hours ago, RevEng said:

If we were out of cart-type bits, or if I saw value in those upper bits being held back as versioning breadcrums, I'd accede.

Sure, looking at the BANKSET specification it’s essentially adding three features on top of Atari’s traditional FLAT and SUPER schemes…

 

• ROM Doubler - Upper ROM address is chosen based upon the current bus master.
• 2x16KB EXRAM Paging - Upper RAM address is chosen based upon the current bus master and access range.
• …and now the ability to map a POKEY @ $0800.

 

When this discussion started, I assumed you had already finalized the board’s design and manufactured cartridges. But if you’re willing to drop a new POKEY on a whim, let me suggest one other feature - allowing the 2x16KB EXRAM paging you’ve designed to be used with a traditional SUPER cartridge, without the ROM Doubler.

 

In the current SUPER + BANKSET configuration, Sally and Maria are both stuck on the same offset from their half of the ROM in $8000 - $BFFF as their index is a shared register. So you still have the same resource contention issues except now Sally can’t read any of Maria’s ROM. If you’re using Holey DMA that’s going to manifest as several lost KB per page, and while you could carefully interleave assets to get around this, it’s just as bad as interleaving code. If the format expands to a 2x256KB or 2x512KB version later, that’s a lot of dead space.

 

Because of this, I think being able to pair large SUPER cartridges (256KB, 512KB, 1MB+?) with the 2x16KB EXRAM paging scheme designed for BANKSET is a good option to have available - so why not break it off into its own bit to allow that? You lose the separate fixed bank for Maria, but still get to keep her EXRAM page and load textures into it.

 

Oh right, we’re running out of them - individually, all of these would fill the existing bitfields.

 

As a compromise, since the POKEY @ $0800 seems to be desired immediately - why not do this for the last call of the old world header?

Bit 15 : EXTEND / ESCAPE (‘0’ == Old World Header, ‘1’ == New World / Extended Header)
Bit 14 : Reserved (Set to ‘0’)
Bit 13 : POKEY @ $0800 - $080F
Bit 12 : SOUPER
Bit 11 : YM2151 @ $0461 - $0462
...

 

Then add the POKEY into the IRQ table...

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

 

While this is going to make more work now, as we'll have to define the new header format before BANKSETs and its EXRAM paging scheme are in - it fits in with the current header's pattern of feature bits which can be exclusive but are not contextual (quirks aside).

 

 

Regarding the suggested three prong version number, string, and escape bit change to differentiate the old and new world formats - they're just for clarity.

 

Having an escape bit in the cartridge type field allows fallback behavior if the game doesn’t need the new whizbang stuff, and reusing the old fields, that’s the minimum. The extended string just makes it easier to be absolutely sure, as does the version bump.

 

 

17 hours ago, RevEng said:

At least to me, a mapper documents a hardware implementation exactly. I'm actually in the camp that even adding other common cart peripherals - pokey, rom at particular locations - should necessitate a new mapper index. They're indexes, so being expansive here doesn't have a large cost. But I'm completely fine with TailChao's suggestion of a mapper-specific set of board hardware options, because it doesn't degrade the descriptive precision.

Yeah, there’s essentially been two routes of stacking features on Atari’s cartridge designs or making an entirely new mapper. So if you were to categorize it by mapper and features, there’s less mappers than you have fingers but all of the feature variation is on Atari’s mapper. How many more are going to be stuffed into it?

 

I think the biggest difficulty is predicting what people will make and trying to accommodate that - the audio chips at $04xx weren’t intended for cartridges but here they are. The BupChip is designed to work exclusively with SOUPER, but you can also dump a POKEY @ $0800 for nearly any mapper.

 

So maybe we need three sections…

• Mapper (index, 16-Bit)
• Mapper Features (bitfield, 32 or 48-Bit?)
• Generic / Shared Features (bitfield, 64-Bit Do the Math!)

…with a really big chunk of space at the end in case the last two need more info. Going with the 16/48/64 setup would align nicely to 16-Bytes.

 

 

17 hours ago, RevEng said:

To underline the distinction - there are now 3 or 4 supergame implementations (without counting flash carts) - the original ones by atari, a couple of the cpuwiz boards, and new batari's. There's probably a few more variations within those board sets, but it's good enough for illustration. You may think this isn't an important distinction, but there differences in implementation behaviour - e.g. a cpuwiz board will have pokey@450 with mirrors every $10 bytes that follow. Other pokey@450 implementations may or may not have this behaviour... certainly DF cart doesn't. If someone enables the pokey@450 feature with supergame bankswitching, which behaviour should the emulator take on?

Again, we’re not on the new format yet - but if you want to go the extra mile and add fine detail, then take over all of $40 - $7F and ditch the ACTUAL CART DATA STARTS HERE string. That way you can be more specific, and I do totally agree with nudging the format in that direction.

 

But trying to document the original hardware exactly within a header format like this is probably futile - it might be best to have something like XML for preservation, and this header is just “good enough for playing games” but also “good enough to handle most of the future stuff”. Which is still difficult to do well!

 

 

9 hours ago, batari said:

In case it wasn't clear, my vote would be to relegate the EXRAM/A8 to its former obscurity rather than bring it to the forefront, particularly if it is only used in a single prototype and nowhere else.

1 hour ago, RevEng said:

To clarify your clarification, what action are you voting for? Are you thinking removal from the header, active discouragement of it's usage, or ...?

 

The feature has a lot of utility for ram-based bitmaps, it's just that homebrewers haven't moved into ram-based bitmaps significantly yet, but I don't think that's a forever and ever state. It's perfectly fine to not support the feature with your designs. I'm not sure there's justification to discourage it beyond that.

Yeah, I don't think we should be removing or repurposing any bits in the original header. Again, the spirit of the format has ended up with a thousand features which can be attached to Atari's FLAT and SUPER schemes. It's better to just accommodate that trend rather than make it more convoluted.

[RevEng]

1 hour ago, TailChao said:

I'm lost on the version numbering - I thought v3 is going to be the last of the "old world" header (which we're figuring out now) and v4 is going to be the first "new world" format with the cool extensions. But anyway...

Yes, my response was to the comments that we should remove the already allocated banksets from a v3 header, and stop allocating bits entirely in the v3 header, so that we can have version breadcrumb bits.

 

While we're on the subject, we shouldn't add the new IRQ field without a version bump. IMO field additions require that. So either IRQ should wait for v4, or v5 will be the new mythical mapper header version number. I don't see a rush for the IRQ field, so my vote is that it can wait until the actual v4.

 

Quote

Sure, looking at the BANKSET specification it’s essentially adding three features on top of Atari’s traditional FLAT and SUPER schemes…

 

• ROM Doubler - Upper ROM address is chosen based upon the current bus master.
• 2x16KB EXRAM Paging - Upper RAM address is chosen based upon the current bus master and access range.
• …and now the ability to map a POKEY @ $0800.

 

When this discussion started, I assumed you had already finalized the board’s design and manufactured cartridges. But if you’re willing to drop a new POKEY on a whim, let me suggest one other feature - allowing the 2x16KB EXRAM paging you’ve designed to be used with a traditional SUPER cartridge, without the ROM Doubler.

I think a non-banksets idea can be tabled until banksets is released some day, unless someone else wants to run with it. I have zero interest in expanding my plate beyond banksets at this point, with the header negotiation, testing, documentation, emulator updates, and 7800basic support involved.

 

Just so we're clear on what the bankset proto is, since proto is an ambiguous term. We have bankset PCBs in hand and running, which are perfect. The pokey change will require logic changes and a bit of minor routing, so we're looking at a board revision here.

 

Other parts of the debate aside, presenting a required finish-line of "cartridges must be manufactured" as justification to remove banksets from v3 doesn't hold sway with me. We've never held other projects to this same standard, so it shouldn't be the justification for removing my allocation. If "must be manufactured" is a newly proposed standard, then I strongly vote "no". A running cart pcb, intent to produce, and a complete game that uses it, is more than enough for me.

 

Quote

Because of this, I think being able to pair large SUPER cartridges (256KB, 512KB, 1MB+?) with the 2x16KB EXRAM paging scheme designed for BANKSET is a good option to have available - so why not break it off into its own bit to allow that? You lose the separate fixed bank for Maria, but still get to keep her EXRAM page and load textures into it.

 If that's justification for bumping banksets out of the legacy header, I don't agree. The legacy header can keep the current usage, and that new semantic can be added to the new header fields.

 

Quote

Regarding the suggested three prong version number, string, and escape bit change to differentiate the old and new world formats - they're just for clarity.

 

Having an escape bit in the cartridge type field allows fallback behavior if the game doesn’t need the new whizbang stuff, and reusing the old fields, that’s the minimum. The extended string just makes it easier to be absolutely sure, as does the version bump.

To recognise the extended string or upper bits as a version flag, the implementation needs to be coded precisely for that recognition. ("hmm, the upper cart-type bits are set, so this must be a v4 header!") The implementation could also equally be coded to check the version via... the version byte. In distributing your version hints in several places, you're opening the door to implementations ignoring the lactual version byte, which should be the authoritative source of header version. I don't see that as clarity at all.

 

Having reasonable bits in the cartridge type field alone allows for fallback behavior. You don't need extra bits for that. If an implementation doesn't understand v4 (or whatever) headers, it will read the cartridge type. If the implementation does support v4 headers, it will preferentially use the new fields. Saving top bits as version flags gets you nothing.

 

Quote

But trying to document the original hardware exactly within a header format like this is probably futile - it might be best to have something like XML for preservation, and this header is just “good enough for playing games” but also “good enough to handle most of the future stuff”. Which is still difficult to do well!

For what it's worth, I've personally decided to give up on the specific mappers argument, since it's extra work for me, and nobody else seems to value the specificity. We can have bankswitch types and mix-and-match feature fields. People can call those bankswitch-types mappers if they prefer.

 

[TailChao]

Quote

While we're on the subject, we shouldn't add the new IRQ field without a version bump. IMO field additions require that. So either IRQ should wait for v4, or v5 will be the new mythical mapper header version number. I don't see a rush for the IRQ field, so my vote is that it can wait until the actual v4.

The IRQ field was intended for the DragonFly and 7800GD, which have this feature and it's in active use. I ran the change by both SainT and Rafal and it's already gone through, sorry about that .

 

 

Quote

I think a non-banksets idea can be tabled until banksets is released some day, unless someone else wants to run with it. I have zero interest in expanding my plate beyond banksets at this point, with the header negotiation, testing, documentation, emulator updates, and 7800basic support involved.

That's fine - again, I just want to make sure the old format makes sense before it's closed. If you want to discard the EXTEND / ESCAPE bit and do detection in another way, I'd really like...

 

Bit 15 : POKEY @ $0800 - $080F
Bit 14 : EXRAM/M2 (Bankset's EXRAM)
Bit 13 : BANKSET (Specifically the ROM Doubling behavior)
Bit 12 : SOUPER
Bit 11 : YM2151 @ $0461 - $0462
...

...and to allow the IRQ field in $3E to be populated as before.

 

This is going to prevent a lot of headache later.

 

 

Quote

Other parts of the debate aside, presenting a required finish-line of "cartridges must be manufactured" as justification to remove banksets from v3 doesn't hold sway with me. We've never held other projects to this same standard, so it shouldn't be the justification for removing my allocation. If "must be manufactured" is a newly proposed standard, then I strongly vote "no". A running cart pcb, intent to produce, and a complete game that uses it, is more than enough for me.

I made this point moreso because you're still moving things around, not because the cartridges weren't manufactured. No worries.

Edited March 15, 2022 by TailChao

[RevEng]

1 hour ago, TailChao said:

The IRQ field was intended for the DragonFly and 7800GD, which have this feature and it's in active use. I ran the change by both SainT and Rafal and it's already gone through, sorry about that .

All good. I should have thought of it when it was first mentioned, but I'm fine with the outcome. I guess the folks that need to interact with the new field will need to deal with FF/00 as possible unused byte defaults.

 

Quote

 

That's fine - again, I just want to make sure the old format makes sense before it's closed. If you want to discard the EXTEND / ESCAPE bit and do detection in another way, I'd really like...

 

Bit 15 : POKEY @ $0800 - $080F
Bit 14 : EXRAM/M2 (Bankset's EXRAM)
Bit 13 : BANKSET (Specifically the ROM Doubling behavior)
Bit 12 : SOUPER
Bit 11 : YM2151 @ $0461 - $0462
...

...and to allow the IRQ field in $3E to be populated as before.

 

This is going to prevent a lot of headache later.

I'm good with all of that. Assuming there's no objection in the next while, I'll go forward on my end with that, and we can close the door on v3.

[+Pat Brady]

4 minutes ago, RevEng said:

I'm good with all of that. Assuming there's no objection in the next while, I'll go forward on my end with that, and we can close the door on v3.

 

Have you heard from @Eagle? Their SN76489 project exists (at least as a prototype), they already asked for a carttype bit, and they were told they could have it — which was the catalyst for this entire discussion. I think it would be uncool to now yank that away from them and instead give that bit to EXRAM/M2-without-bankset (which AFAIK currently has neither an implementation nor an application) without their consent.

 

If @Eagle does not consent, then I suggest using those last two bits for SN76489 and POKEY@$0800, and deferring EXRAM/M2-without-bankset to v4 headers.

 

Other than that, no objections from me.

[TailChao]

6 minutes ago, RevEng said:

I'm good with all of that. Assuming there's no objection in the next while, I'll go forward on my end with that, and we can close the door on v3.

 

SOLD TO AN AMERICAN!

 

So the cartridge type bytes in $35 - $36 are...

 

With the IRQ Routing in $3E as...

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

 

Whee ~ I'm free! Free as a boid! I...

2 minutes ago, Pat Brady said:

Their SN76489 project exists (at least as a prototype), they already asked for a carttype bit, and they were told they could have it — which was the catalyst for this entire discussion. I think it would be uncool to now yank that away from them and instead give that bit to EXRAM/M2-without-bankset (which AFAIK currently has neither an implementation nor an application) without their consent.

...uh oh.

 

I spoke with @rj1307 about moving this design to the next version header, as it seems to also encompass a new mapper - and he seemed okay with that. So yeah, let's make both him and @Eagle sign off on this first but I think we're good?

[+batari]

5 hours ago, RevEng said:

To clarify your clarification, what action are you voting for? Are you thinking removal from the header, active discouragement of it's usage, or ...?

 

The feature has a lot of utility for ram-based bitmaps, it's just that homebrewers haven't moved into ram-based bitmaps significantly yet, but I don't think that's a forever and ever state. It's perfectly fine to not support the feature with your designs. I'm not sure there's justification to discourage it beyond that.

You can do bitmaps without it, of course. So my understanding is the utility of EXRAM/A8 is for slightly faster storage of data for half-resolution bitmaps which seems to be a pretty specific application rather than something with broad general appeal. And now that I am thinking about it, couldn't a carefully-crafted DLL do the same thing without EXRAM/A8? Correct me if I am wrong, I am not an expert with 7800 graphics.

 

I personally think the scheme was devised as a clever way to use 8k RAM in a 16k space at a time when 8k RAM chips were probably significantly cheaper, but that is no longer the case.

 

If a prototype supports it, I would not remove the bit as it deserves to be supported. What I would vote for is to not document it as an option for general use in any other scheme as being on par with the other schemes that are actually used, but not disallow it either.

[+Pat Brady]

13 minutes ago, TailChao said:

So yeah, let's make both him and @Eagle sign off on this first but I think we're good?

 

If it's fine with them, it's fine with me.

[RevEng]

10 minutes ago, batari said:

You can do bitmaps without it, of course. So my understanding is the utility of EXRAM/A8 is for slightly faster storage of data for half-resolution bitmaps which seems to be a pretty specific application rather than something with broad general appeal. And now that I am thinking about it, couldn't a carefully-crafted DLL do the same thing without EXRAM/A8? Correct me if I am wrong, I am not an expert with 7800 graphics.

Single line DLLs could let you duplicate lines, but you don't have enough to cover a screen due to the DLL only being allowed to cross one page. So a cockpit view might work, but no-go for Tempest or whatever unless you're going to shrink the vertical area even more. The only other option would be to effectively scroll the display objects every other line, which means you need to dedicate most of the visible cycles to that endeavour.

[+batari]

12 minutes ago, RevEng said:

Single line DLLs could let you duplicate lines, but you don't have enough to cover a screen due to the DLL only being allowed to cross one page. So a cockpit view might work, but no-go for Tempest or whatever unless you're going to shrink the vertical area even more. The only other option would be to effectively scroll the display objects every other line, which means you need to dedicate most of the visible cycles to that endeavour.

I see. Regardless, I still suspect there is a way. A lot of systems back then don't have 1:1 bitmaps either, the Apple II has a weird memory layout and the C64 needs to use the character set to simulate one, and programmers still figured things out. So couldn't that same idea be used here?

[RevEng]

Are you sure about c64 lacking a bitmap mode? I haven't owned one, but I thought it was just Pet and Vic20 in that character-only Commodore boat.

 

I honestly don't see anyone willingly taking on character based bitmaps for vector-like game display, on a system that can actually display bitmaps. 256 character indexes means you don't have arbitrary line display, and either need to do slow computation and character redefinition to deal with line intersections, or put up with a bunch of glitching.

 

[+batari]

11 hours ago, RevEng said:

Are you sure about c64 lacking a bitmap mode? I haven't owned one, but I thought it was just Pet and Vic20 in that character-only Commodore boat.

 

I honestly don't see anyone willingly taking on character based bitmaps for vector-like game display, on a system that can actually display bitmaps. 256 character indexes means you don't have arbitrary line display, and either need to do slow computation and character redefinition to deal with line intersections, or put up with a bunch of glitching.

 

"Bitmap" on the C64 only means you can control every pixel on the screen with a bit in memory. The organization of the bits themselves is more like a character map than a bitmap because they are in 8x8 tiles. It is not what we normally think of as a bitmap.

 

That said, EXRAM/A8 is less convenient than a normal 7800 bitmap because every other page is mirrored. I wonder if the inconvenience of only being able to use every other page in memory would outweigh any loss in having to perform two identical writes (on normal EXRAM.) If so then EXRAM/A8 is merely a line-doubling gimmick that was created only to leverage 8k RAM chips that were likely cheaper than 16k at the time, and we don't need that.

 

I am not trying to be argumentative, but more saying I am not impressed enough by the benefits of EXRAM/A8 to push it forward as a possible feature on every mapper. I am sure there is something better out there to push forward. Like, EXRAM/X2 was mentioned, which seems to me would be worth adding to the various boards wherever possible, particularly because all RAM chips nowadays are 32k anyway and we might as well use the resources available to make better games.

[RevEng]

Yes, there are other solutions we can think of that fit different shaped problems, and we should spend our hobby-time budget wisely. I don't think anyone is personally spending time creating anything around EXRAM/A8 right now, but if a developer wants to explore it, I don't think they need to be steered away either. 

 

If there's no advantage to using EXRAM/A8, then any concern over it's usage is self-resolving. The first person to try it in earnest will find it provides no benefit (A/B testing is easy here) and they'll proceed with the full vertical resolution and full amount of cart ram. 

 

Since the consensus is to move forward with v4 headers sharing similar mix-and-match to previous header versions, I don't see the need to treat EXRAM/A8 differently than we did before, whether we're talking about in-header usage, or documentation of same. The bits are there to enable or disable as the developer likes. It's up to them to figure out which bits suit their use case; sharp edges associated with any particular choice is on them too. (like using a feature that has no hardware support presently)

 

[TailChao]

6 hours ago, batari said:

If so then EXRAM/A8 is merely a line-doubling gimmick that was created only to leverage 8k RAM chips that were likely cheaper than 16k at the time, and we don't need that.

It really wasn't though, the Rescue on Fractalus prototype only had 2KB of SRAM onboard and 16KB SRAMs aren't common outside of niche applications like high speed cache. We won't have a definitive answer unless someone from LucasArts steps forward, but if I had to guess - it was probably done to simplify porting the game from the Atari 800, and for the performance reasons already described.

 

 

2 hours ago, RevEng said:

The bits are there to enable or disable as the developer likes. It's up to them to figure out which bits suit their use case; sharp edges associated with any particular choice is on them too. (like using a feature that has no hardware support presently)

This.

 

It's the header's job to give an emulator enough information about a cartridge's hardware so that its software can run correctly. Because of how Atari's cartridges were designed and extended, we ended up with the ability to stack features when parsing the header. That doesn't affect anything outside of trying to structure the software in a flexible way (so we don't have to keep rewriting it with each new feature drop) and making sure future versions of the header follow that spirit / intent.

 

We're talking about developing for hardware that's nearly forty years old. If someone wants to stuff weird feature combinations into the header and write their games based upon the resulting "cartridge" - that's on them. The on-rails experience in 7800basic mostly shields you from such mischief anyway.

[RevEng]

I've taken a pass at the updated v3 header, and taken the opportunity to move it to github. In addition to allowing for better collaboration or forking, it just makes sense to put it somewhere more central than a forum post...

 

https://github.com/7800-devtools/a78_asm_header/blob/main/a78header.asm

 

...I've labelled it 3.1, with the intention that (moving forward) using previously reserved bits in existing fields and adding indexes to existing fields will only require a minor version bump, as those are least likely to break a parser. Other updates will require a major version change. That process is up for discussion, of course.

 

Here's the list of stuff I did that was outside of the scope of the conversation here, in the interest of full transparency:

• You now just need to include the header first thing after your ROM ORG, not modify ROMTOP within the file.
• Added a changeble .ROMSIZE constant, which is pulled apart to provide the rom size bytes. (the old header hardcoded the size)
• Changed all bitfield byte values into binary representation.
• Added some controller type indexes to match what I've been using in 7800basic. Previously I had missed allocating a couple of controller port device indexes...
  • device 10 is AtariVox/SaveKey, as 7800basic uses the controller port switching command to enable/disable them. Since these aren't controllers, in the interest of clarity, I changed the field description from "controller # type" to "controller # device type". Some may view this as duplication of the save device byte, but the device location-neutral information in that byte is problematic, and adding extra bits for port-specification opens us up to port conflicts. IMO the controller bytes is the right place to specify anything that goes in the ports.
  • device 11 is the SNES2ATARI adapter device, which exists already in 2 different prototypes, and the interface was finalised months ago.
• I changed the XM byte to "slot passthrough device" and made it a bitfield. Even if we're not going to get rid of the entry, we can at least keep the byte useful. (IMO this should normally require a major version change, but we can just hold off on any actual new passthrough bit allocations until v4)
• save device was explicitly made a bitfield. previously it was ambiguous.

 

I made the changes with the understanding that discussion here might undo any one of them, or all of them, but discussion is easier with an example in front of you. Also, recall that discussion should be within the scope of the v3 header. (The proposed v4 header will add in new bank-scheme filed and cart-hardware fields, and deprecate the cart-type bytes)

 

[edit] Also, @TailChao you mentioned that TV Type should have an "autodetect" field. I'm open to the change, but I'm just trying to better understand the usage... what would the emulator setup differently here, if autodetect is selected?

 

[TailChao]

Usual fillyjonkian nitpick, which is actually a typo you inherited from me (!) The YM2151 in the External IRQ field should be "YM2151 @ $0461" not "YM2151 @ $0460". It might be best to copy the full address ranges over from the cartridge type comments (i.e. "YM2151 @ $0461 - $0462") so they'll match.

 

Otherwise looks good to me, and thanks for formally adopting the feature names! I'll put together my writeup of the different schemes and parsing recommendations for the Old World Header and put it up (maybe next week ?) in a separate thread.

 

1 hour ago, RevEng said:

[edit] Also, @TailChao you mentioned that TV Type should have an "autodetect" field. I'm open to the change, but I'm just trying to better understand the usage... what would the emulator setup differently here, if autodetect is selected?

I thought about this for a bit, and seem to have misunderstood the intent of the TV Type field and also Controller Type. They're not a "supported" field but a "hint" field.

 

So a game can work in both regions, but is tagged for the "intended" one - otherwise the composite blending flag would make no sense, and stuff like the controller type being an index would make negative sense. So just leave it alone.

[RevEng]

Thanks for the catch!

12 minutes ago, TailChao said:

I thought about this for a bit, and seem to have misunderstood the intent of the TV Type field and also Controller Type. They're not a "supported" field but a "hint" field.

Yes, entirely how I've understood them too.

 

[RevEng]

Ok, nobody screamed, so I've released the v3.1 header.

 

I also updated the 7800header tool in the 7800 Asm Dev Kit package, though I didn't incorporate the new field names in the tool yet, as that will open up 7800basic changes I'm not ready to tackle right now.

[DanBoris]

On 3/21/2022 at 5:56 PM, RevEng said:

Ok, nobody screamed, so I've released the v3.1 header.

 

I also updated the 7800header tool in the 7800 Asm Dev Kit package, though I didn't incorporate the new field names in the tool yet, as that will open up 7800basic changes I'm not ready to tackle right now.

 

[Scott Savage]

On 4/1/2016 at 8:13 PM, RevEng said:

Doesn't seem that far fetched to me. The PIC 18Fxxxx series matches the +V, ground, Vout and RX lines on the Speakjet. The Soundgin and Speakjet were both developed by Scott Savage (of OOPic fame), and the Soundgin is known to be a PIC18F1320. I'd be surprised if the Speakjet wasn't the same.

The two are the same internal engine. The difference lays in the interface.  One is a speech synth that can do some canned sounds.  One is a sound synth that can do voice.