A78 header changes

[RevEng]

14 minutes ago, SainT said:

Gotcha, I'm assuming allowing 4 POKEY's would be a little pointless, however. So up to two POKEY's simultaneously and then the other audio devices as well? And forgive my ignorance, but what is the advantage of having the POKEY mapped at 800/810 rather than 440/450?

@800 is meant to be a loose-decoding location, with mirrors up to and including @FFF. The idea is that inexpensive PLDs can serve. @440/@450/etc. is used by devices capable of tighter decoding, esp. pass-though capable devices. Historically we had a problem with loose-decoding pokey@450 clashing with XM registers.

 

14 minutes ago, SainT said:

I'm trying hard to sanitise things such that it isn't just a massive mux with hugely redundant / invalid combinations.

Yeah, validation is the challenge with the mix'n'match. I'm not championing the approach here, just going with the flow. I wanted to have a more rigid mapper-based approach, where parser would just read in an index to a mapper->device table, and platform authors wouldn't have to worry about invalid combinations. But everybody else wanted the flexibility of mix'n'match. 🤷

[+Pat Brady]

Thanks for picking this up. I like the approach. I have a few quibbles.

12 hours ago, SainT said:

Linear ROM

Size is implicit from the payload size upto 52KB. If RAM is enabled the maximum loaded ROM size will be 32K regardless of payload size.

Probably not a huge deal, but my preference would be for size to be implicit even if RAM is enabled. For example, 40K ROM + 8K RAM seems like a useful configuration that doesn't seem difficult to implement.

 

9 hours ago, RevEng said:

My preference is to have the v4 header bytes set in parallel with the existing v3 bytes.

 

Strongly agree with this.

 

8 hours ago, SainT said:

Another possibility, which was actually suggested by Tailchao, is to have the V4 header data in the ‘cart data starts here’ section and the V3 header bytes would replicate the V4 setup as closely as possible.

 

We're really only replacing the cart type bytes, right? I have no love for ACTUAL CART DATA STARTS HERE, but IIRC a few existing implementations do look for it. Why not put the V4 stuff at $40? And maybe deprecate ACTUAL CART DATA STARTS HERE, so that V4 readers know to ignore it.

 

Gonna respond separately about the audio stuff.

[+Pat Brady]

9 hours ago, SainT said:

Gotcha, I'm assuming allowing 4 POKEY's would be a little pointless, however. So up to two POKEY's simultaneously and then the other audio devices as well?

...

I'm trying hard to sanitise things such that it isn't just a massive mux with hugely redundant / invalid combinations.

 

It's important to recognize that you do not have to implement everything that the header can represent. That's true whether the header represents devices as bitfields or enumerations.

 

There are a few demos that use 2xPOKEY@$440. Nothing uses any other 2xPOKEY configurations, or more than 2 POKEYs, AFAIK.

 

From reading your posts earlier I infer that you may have to choose between a second POKEY and a first SN76489. If that's the choice, there's not really a right or wrong answer. If you do choose 2xPOKEY, limit it to @$440. Forgive me if I'm off-base here — my hardware design experience is limited and distant — but I don't think you need a massive mux. Each address can only correspond to one device and only the 1st POKEY might be at multiple addresses ($450, $800, $4000). (You could map them differently, the only important thing is that $450 goes to one and $440 goes to the other.)

 

For a microcontroller-based carts, the limitations might be different.

 

Don't spend any resources on POKEY@$810 in any case. No released software uses it, and any future software that needs 2xPOKEY should use the existing $440 mapping. I don't believe it needs to be in the header either.

 

I argued for bitfields earlier, but not in the context of POKEY mappings. If enumerating the POKEY possibilities (none; @$4000; @$800; @$450; @$400+@$450) would make it easier to implement, then let's do that.

[SainT]

Here's my next stab at a V4 header. The existing header is maintained in its entirety including the "ACTUAL DATA STARTS HERE" text (just for safety sake on breaking existing implementations). The bytes from $40-45 in the reserved area are used as the new (additional) header information when the version number is set to 4. This only pertains to mapper information and does not attempt to change how the other hint fields work or are used. I'm not sure if we want to sanitise this data as well, but in my usecase I don't use any of this anyway, so it's not of concern to me.

 

The key difference between my previous proposal and this one is that it entirely maintains the ethos of "pick and mix" while cleaning up the bit explosion which made maintenance and expansion an absolute pain in the ass. Anything that can be represented in the V3 header (which is valid) can be represented in the V4 header. I have included a map of how the two headers interchange below.

 

New Header Information

 

Byte(s)	Size	Contents
$40	1	Mapper (Byte) $00 : Linear $01 : SuperGame $02 : Activision $03 : Absolute $04 : Souper
$41	1	Mapper Specific Options Linear Bit    7 : Bankset ROM Bits 0-1 : Option at @4000  0 : None  1 : 16K RAM  2 : 8K EXRAM/A8  3 : 32K EXRAM/M2   SuperGame Bit    7 : Bankset ROM Bits 0-2 : Option at @4000  0 : None  1 : 16K RAM  2 : 8K EXRAM/A8  3 : 32K EXRAM/M2  4 : EXROM  5 : EXFIX  6 : 32K EXRAM/X2
$42-3	2	Audio Mapper Big endian 16bit field   Bit:    5 : ADPCM Audio Stream @420 Bit:    4 : COVOX @430 Bit:    3 : YM2151 @460 Bits: 0-2 : POKEY  0 : NONE  1 : POKEY @440  2 : POKEY @450  3 : DUAL POKEY @440/450  4 : POKEY @800  5 : POKEY @4000
$44-5	2	Interrupt Enable Big endian 16bit field   Bit 2: YM2151 Bit 1: POKEY 2 Bit 0: POKEY 1

 

Mapper Options

Bit 7 has been used for bankset enable in the linear and supergame mappers to allow easy expansion of the @4000 field. I would suggest any single bits like this go from top down if an enumerated field is used in the low bits.

 

Audio Mapper

I've increased this field to 16bits, we should not overflow this in the foreseeable future. The existing individual POKEY enable bits have been condensed to an enumeration based on actual sensible use cases. This field could be increased to 4 bits if any more addressing options are considered valuable, although I don't see this should be required. All audio devices can be enabled concurrently.

 

Interrupt Enable

Interrupt enable has also been simplified to match what is possible. Each POKEY has a bit for IRQ enable, in the case of a single POKEY being present, bit 0 is used. Plenty of space for future interrupt sources if required.

 

SuperGame 1MB + RAM

To make 1MB SuperGame a little more flexible for devices with 1MB of RAM (7800GD, DF, etc) then if 16K RAM is specified for a 1MB SuperGame and bank 62 is empty (all set to the same value) then this bank will be mapped to 4000 and used as additional RAM. If the bank is not empty then the mapper should be considered as invalid.

 

Header Interchange

This is how the current (valid) V3.1 header mapper flags would be mapped to the V4 header format. A black square represents a selected option. Green squares represent a possible option based on the mapper type and a red square an invalid option for the current mapper type. All valid combinations are represented below.

 

 

Edited June 8, 2023 by SainT
Missed EXRAM/X2, added.

[SainT]

6 hours ago, Pat Brady said:

Probably not a huge deal, but my preference would be for size to be implicit even if RAM is enabled. For example, 40K ROM + 8K RAM seems like a useful configuration that doesn't seem difficult to implement.

 

If you want a variable amount of RAM one possible option is that you specify 16K RAM @4000 and then if the ROM image overlaps the RAM area it is pre-populated with the ROM data. That way you could have as little or as much RAM @4000, although you'd have to be careful not to overwrite it, as it really would be RAM.

 

It is possible to write protect the area and treat it as actual ROM, however this would be down to the individual implementation (in particular for hardware) as it does require more address decoding. If it was an option that already existed, or everyone would use, I'd be happy to implement it, but if it's a single use case then the pre-populated RAM option would serve well.

[SainT]

One question on the POKEY @800 -- is there even any point in this existing at all anymore? I understand the original purpose was to allow easier address decoding, but as it then requires that the (NTSC) console is already booted before being enabled (or having write only access) due to address decoding conflicts then this requires more effort to implement than just decoding @440.

 

It's not a problem to leave it in place, and I already have it functioning on the 7800GD, but I get the impression now this is a feature which has been newly implemented and is essentially flawed and encouraging it's further use by including it in the V4 header is not necessarily a good thing?

[RevEng]

There are minimal workarounds to the NTSC bios conflict, and I'm told even with the workarounds it's still a win. Presently we have an implementation (petscii robots) so I don't think it should be removed.

 

No issues or suggestions for the v4 layout. Great job!

[SainT]

10 minutes ago, RevEng said:

There are minimal workarounds to the NTSC bios conflict, and I'm told even with the workarounds it's still a win. Presently we have an implementation (petscii robots) so I don't think it should be removed.

 

No issues or suggestions for the v4 layout. Great job!

Ok, no problem at all, I thought I'd mention it!

 

Glad the new layout looks sensible, I'll implement this for the 7800GD. Would you like me to update the 7800header code to deal with the V4 header, or would you prefer to do that?

 

I think this is the right place --

https://github.com/7800-devtools/7800basic/blob/master/7800header.c

 

Not sure if you'd want a V3/V4 option on there for compatibility? Especially given currently there is no added functionality bar the COVOX bit.

 

@Pat Bradydoes that look ok to you as well? This really shouldn't hamper anyone and leaves plenty of scope for whatever extensions are to come.

Edited February 9, 2023 by SainT

[RevEng]

Yeah, I'd prefer to implement it, just because of 7800header being integrated into 7800basic. I think the default behaviour should be to generate both v3/v4, and issue a warning on output for options that won't work in v3, along with giving an option to scuttle the v3 header.

 

I think we should let the proposal settle here for a day or two, to allow for any objections or suggestions from others.

[SainT]

Perfect! Sorry if I'm being impetuous, I'm tying up lots of lose ends here ready for release and this is something which has been on my mind for many months. It's nice to see a solution in sight! 😆

 

I'll get the my side of things working and ready, I'll be using this new layout verbatim as an agnostic way of dealing with mappers in the debug API side of things as well.

[+Pat Brady]

Looks great to me, including your idea to allow implementations to preload ROM into RAM in certain unusual cases.

 

Only thing I'll add is that single POKEY@$440 is not necessary AFAIK, though it doesn't hurt anything.

 

I have one other thought, purely about documentation. @RevEng mentioned a while back that some implementations of POKEY@$450 mirror it to some or all otherwise-unused addresses in the $400-$4FF space. From a software standpoint, this is fine: if I don't declare in the header what I want at, say, $440, then I don't care what's there. In C/C++ terminology they would say something like "behavior of unmapped regions is undefined." Should we add some language like that, so that implementors know they can mirror, and developers know not to rely on anything there?

 

EDIT: thanks again to both of you.

[SainT]

1 hour ago, Pat Brady said:

I have one other thought, purely about documentation. @RevEng mentioned a while back that some implementations of POKEY@$450 mirror it to some or all otherwise-unused addresses in the $400-$4FF space. From a software standpoint, this is fine: if I don't declare in the header what I want at, say, $440, then I don't care what's there. In C/C++ terminology they would say something like "behavior of unmapped regions is undefined." Should we add some language like that, so that implementors know they can mirror, and developers know not to rely on anything there?

From my perspective the regions in which things are mapped are well defined, ie. 44x or 45x for POKEY, there will be no mirroring and these addresses must be used to access the hardware. So in my case at least I can guarantee that areas which are not declared as containing functionality will still be well defined and empty.

 

In some other physical cart hardware (I’m thinking more of single game carts here) they may perform partial address decoding to save on logic required to map peripherals into memory. In this case the areas outside of what you are expecting may give unexpected (mirrored) behaviour.

 

So essentially, as long as your code only uses the addresses defined by the header as containing functionality you will be fine, and anyone implementing hardware which is only going to be used by a specific subset of header combinations can take some liberties with address decoding if required. I believe this is what you were saying.

 

In general though, I’m not sure this needs to be spelled out, as if your code is writing to the wrong address you won’t get the functionality you would be expecting, at least from emulators and existing hardware supporting such devices. And the only case you would likely be writing to an odd unmapped address is if there was a bug in your code, in which case you would be unaware of it anyway!

Edited February 9, 2023 by SainT

[+karri]

Once you get the header updated I will try to get it into the atari7800 implementation in cc65 as well. I may be the only user of it today. But who knows if someone else gets into writing apps in C for the 7800.

[SainT]

A78 V4 header support has been added to the 7800GD, so ready and waiting.

[RevEng]

I'm working on the updated 7800header release.

[RevEng]

I'm mostly finished the 7800header updates, and I'm just running through some testing. I wanted to raise a couple of things.

 

First, the v4 audio header allows for selection from pokey addresses, but no mixture of pokey addresses (e.g. no combined pokey@4000+pokey@450) , save pokey@440+pokey@450. I'm good with this, and I think it's a sensible limitation from an implementer's perspective. In fact, I'd like to enforce this in the 7800header v3 header fields too, so a particular set sequence won't create differing v3 and v4 fields. (except when v4 hardware isn't present in v3 fields, of course) But I wanted to raise it here in case anybody felt strongly.

 

Second, we have v4 interrupt bits referring to pokey1 and pokey2. I've taken the pokey1 IRQ to be a reference to pokey@4000, pokey@800, or pokey@450, since we have single-pokey hardware using these addresses. I've taken the pokey2 IRQ to only ever reference pokey@440, since it's the only secondary pokey allowed for v4. If this is fine with everybody, we should make this part of the v4 spec.

[RevEng]

Ok, I've published the updated 7800header in a new 7800AsmDevKit release.

 

When I get a chance I'll update the assembly source code header to v4 also, and advise here.

[SainT]

16 hours ago, RevEng said:

I'm mostly finished the 7800header updates, and I'm just running through some testing. I wanted to raise a couple of things.

 

First, the v4 audio header allows for selection from pokey addresses, but no mixture of pokey addresses (e.g. no combined pokey@4000+pokey@450) , save pokey@440+pokey@450. I'm good with this, and I think it's a sensible limitation from an implementer's perspective. In fact, I'd like to enforce this in the 7800header v3 header fields too, so a particular set sequence won't create differing v3 and v4 fields. (except when v4 hardware isn't present in v3 fields, of course) But I wanted to raise it here in case anybody felt strongly.

 

Second, we have v4 interrupt bits referring to pokey1 and pokey2. I've taken the pokey1 IRQ to be a reference to pokey@4000, pokey@800, or pokey@450, since we have single-pokey hardware using these addresses. I've taken the pokey2 IRQ to only ever reference pokey@440, since it's the only secondary pokey allowed for v4. If this is fine with everybody, we should make this part of the v4 spec.

 

Yep, that's all good! I had the pokey1 irq referring to the lowest address, but if we want to standardise pokey@450 as the main and @440 as secondary, that's fine with me. I'll update my code appropriately.

 

Fantastic, pleased to see this getting added!

[RevEng]

3 hours ago, RevEng said:

When I get a chance I'll update the assembly source code header to v4 also, and advise here.

This is done.

 

The last bit of work on my end is the header entry update at the wiki, but I will have to let that one slide for a bit.

[Ecernosoft]

On 4/6/2010 at 2:34 PM, GroovyBee said:

 

Its ideal for Beeb ports. Typically Beeb games are 16K or less (it depends on the graphics mode used in the original). The port of Beeb Tempest now uses the new header format. If I do any other Beeb ports they'll most likely use the new header format too.

 

In my opinion continually forcing homebrew developers to use the "old" cart models is going to hamper development on the system.

 

 

I have lots of plans for the 7800 some of which will most likely need header file changes to correctly configure the emulator.

We can have a "special" bit when set, swaps out lesser used features (Souper, Bankset, EXROM to name a few) for......... other lesser used featues. Like, how about 4 4K banks between $8000-$BFFF? Easy to implement in hardware. Just check if bits 15 and 14 read "10" and if they do, use bits 13 & 12 to choose which banking register to use/write to. 

If this becomes a thing I'll use it in The legend of Nyomi .... .... if that ever becomes a thing on 7800...

 

It's supposed to stand beside the PC version, and I might even make a 2600 version using the ICT2 engine + an enhanced kernal and F16 bankswitching.

[+splendidnut]

@Ecernosoft --- WHY did you reference a 13 year old post?  We're way past that point now with the new header format.

 

See post above for an idea of how the new header format works:

https://forums.atariage.com/topic/160424-a78-header-changes/?do=findComment&comment=5205445

 

[+Muddyfunster]

Just now, splendidnut said:

@Ecernosoft --- WHY did you reference a 13 year old post?  We're way past that point now with the new header format.

Beat me to it  

[+karri]

If I understand this new v4 header correctly then the SN card that has 4K banks needs a new mapper like:

$40 Mapper byte could contain $05 nameofthenewdesign

$41 Mapper specific options could contain $83 (bankset + 2 x 16K RAM @4000)

$42,43 would contain a new bit for SN76489 and the COVOX bit, perhaps $0018

 

I did implement the new v4 header for my cc65 environment.

There is no hurry for me to use this header for anything as I am developing by flashing ROMs today.

But I believe the header i heading in a good direction. Thanks!

[SainT]

Yes, exactly. Although I don’t know whether bankset, etc, are suitable with Eagle’s stuff and the 4K mapping, etc, but the gist of it is right.

[SainT]

Added a minor update to the V4 header above regarding how to interpret specific header combinations when resources are limited to increase flexibility --

 

SuperGame 1MB + RAM

To make 1MB SuperGame a little more flexible for devices with 1MB of RAM (7800GD, DF, etc) then if 16K RAM is specified for a 1MB SuperGame and bank 62 is empty (all set to the same value) then this bank will be mapped to 4000 and used as additional RAM. If the bank is not empty then the mapper should be considered as invalid.

 

Thanks to @playsoft for a version of BadApple 7800 which conforms to this and is running nicely on the 7800GD.

Edited April 6, 2023 by SainT