A78 header changes

[Ecernosoft]

On 4/4/2010 at 5:30 PM, GroovyBee said:

 

What else needs supporting besides 8K/16K/RoF at $4000?

We could support RAM at $8000-$8FFF, $A000-$AFFF, $C000-$CFFF, and $E000-$EFFF for a graphics RAM mod. (I'd love that!!!)

[Eagle]

Quote

; _Cartridge Type A_
	; bit 7 ; POKEY @ $0800 - $080F
	; bit 6 ; EXRAM/M2 (halt banked RAM)
	; bit 5 ; BANKSET
	; bit 4 ; SOUPER
	; bit 3 ; YM2151 @ $0461 - $0462
	; bit 2 ; POKEY @ $0440 - $044F
	; bit 1 ; ABSOLUTE
	; bit 0 ; ACTIVISION
	; _Cartridge Type B_
	; bit 7 ; EXRAM/A8 (mirror RAM)
	; bit 6 ; POKEY @ $0450 - $045F
	; bit 5 ; EXRAM/X2 (hotspot banked RAM)
	; bit 4 ; EXFIX (2nd last bank @ $4000)
	; bit 3 ; EXROM (ROM @ $4000)
	; bit 2 ; EXRAM (RAM @ $4000)
	; bit 1 ; SUPERGAME
	; bit 0 ; POKEY @ $4000 - $7FFF

 

@RevEng because we have pokey at $800 (bit7) can we have dual pokey at $810 as well?

For example:

When bit 2 ($440) and bit 7 ($800) is set then second Pokey will be on $810

When bit 2 ($440) and bit 6 ($450) is set then second Pokey will be on $440

I think that will be easier then extra bit for $810?

What you think? 

Edited August 5, 2022 by Eagle

[RevEng]

Here's the way I see the address space going forward... 

• The $8xx address range is specifically for non-pass-thru devices with limited decoding logic available. (like concerto)
• The $4xx address range is devices capable of fine address decoding, pass-thru or otherwise. (like DF, XM, etc)

Along those lines, our current bitfield mix and match approach is best left to the $4xx range. I think $8xx will need to be more mapperish. e.g. "dual chip" hokey solutions at 800 will likely use internal chip registers to switch between the two virtual devices, rather than unique addresses for each.

[Eagle]

@RevEng I'm asking because DF update is on his way

We can use bit 2 ($440) as dual pokey bit and then users will decide how to use.

[RevEng]

The benefit to your suggestion is we don't need to allocate another bit, which is good because we're presently out of bits.

The drawback to your suggestion is we're taking clarity - a bit specifically meaning pokey@440 - and taking it away, while adding a bit more complexity to the header parser. The header format should document existing hardware, so this suggestion also has the side-effect of implying that second pokey@4xxx is a valid thing.

 

I'd rather see us get that benefit by moving to the v4 header spec, where we'll have bits'a'plenty.

[Eagle]

Thanks.

Let's stick with one Pokey$800 in this header.

 

[rj1307]

I do not know if I am writing in the correct thread, please transfer if necessary.  

I have some comments regarding placing a POKEY in the $ 0800- $ 080F area. I ran POKEY at these addresses on DragonFly (friend @Eagle created a test file), everything works fine but only on the PAL console. There is a problem on NTSC consoles. There is a black screen, the Atari logo is not showing (of course the signature is correct).

 

Please take a look at the picture below:

 

The logic analyzer showed that when starting the NTSC console, the address $ 080x appears on the address bus, which causes the Pokey chip to start, but at the same time the RAM memory is running. I marked it with red arrows.
While it is not a problem when the processor writes to this address, but at the moment of reading there is a conflict on the data bus and the console "goes into the bushes" or goes into A2600 mode, as shown in the photo below (green arrow):

 

If I disable the Pokey chip or physically pull it out of DragonFly, the file starts.

If I understand correctly, it is related to the encryption (decoding) in NTSC consoles.🤔

 

The photo below shows how the console behaves with the POKEY chip turned off:

 

The only way for the file to run and the Pokey to run is to block the POKEY chip from being read, write only. But such a solution blocks the possibility of using a pseudorandom number generator.

 

 

 

[RevEng]

Yeah, for pokey@800 boot you need some special handing, and ignore reads until the bios has handed off. Here's what I wrote to @batari back in April...

Quote

After digging into it, it looks like the NTSC bios writes to $1Fxx through $18xx (with indirect addressing) and checks the same locations for the stored value. (each page is tested for values F, 69, AA, 55, FF, 0). The commented source refers to it as a comprehensive ram test, but I suspect it's also meant to be a ram/2600-rom conflict test.

 

I can see where the above test is conflicting with the 8xx-Fxx mirroring for pokey@800 with the cart port not seeing A12.

[rj1307]

Is the jump to the $ FFFC- $ FFFD reset vector after the BIOS check? Is this the right time to enable the POKEY readout?

[RevEng]

1 hour ago, rj1307 said:

Is the jump to the $ FFFC- $ FFFD reset vector after the BIOS check? Is this the right time to enable the POKEY readout?

I believe that should work. When the cart device sees $FFFC/D access, you're guaranteed that the BIOS is banked out - that will happen only when the encryption check is running out of ram, which is after the ram testing I referenced above which runs out of the bios ROM.

[rj1307]

Thanks, I'll try to use it.

[rj1307]

@RevEng, unfortunately it doesn't work that way   
Please take a look at the picture:

 

The red box on the left is the reference to the address $80x, which is the test you wrote about earlier. The yellow frame is a reference to the cartridge. The green arrow is a double jump to the reset vector (6us interval), the blue arrow on the right is the reference to the $80x address again, so after the reset!

Below, I have enlarged this area (blue arrow):

 

This is again a conflict with RAM.

 

Has the HOKEY $800 been tested on a real NTSC console? If so and working properly, what is the procedure for enabling Pokey? But this question is probably for @batari 

 

 

 

 

 

 

 

 

 

 

[Ecernosoft]

On 8/5/2022 at 4:02 PM, Eagle said:

 

@RevEng because we have pokey at $800 (bit7) can we have dual pokey at $810 as well?

For example:

When bit 2 ($440) and bit 7 ($800) is set then second Pokey will be on $810

When bit 2 ($440) and bit 6 ($450) is set then second Pokey will be on $440

I think that will be easier then extra bit for $810?

What you think? 

What about External MARIA at $200-$23F? (No DMA, only disables VRAM in DMA period)

and then have 4K at $4000-$4FFF for DLL / DL space, and then 4K at $8000-$8FFF, $A000-$AFFF, $C000-$CFFF, and $e000-$EFFF? Then have Paged ROM at $9000-$9FFF, $B000-$BFFF, and $C000-$CFFF? That would leave fixed ROM at $5000-$7FFF, and $F000-$FFFF. Maybe add 4 bytes for a controllable IRQ and NMI point in the $FFF8 space? That would be ultimate Atari (Maybe call it MEGA) by setting a byte to 1? (IDK where header space ends in newest header)

[SainT]

I'm just adding Covox for the 7800GD -- the V3.1 header adds most flags for audio, but does not include Covox or the SN76489 used in @Eagle's board. I'd like to be able to mark this hardware as present. Any thoughts? Stealing one of the remaining reserved bytes ($3D?) for Covox and SN76489 use would be one option.

 

Or a completely different V4 header which sanitizes everything would also be helpful, but obviously more work.

[+karri]

58 minutes ago, SainT said:

I'm just adding Covox for the 7800GD -- the V3.1 header adds most flags for audio, but does not include Covox or the SN76489

@Eagle created a very flexible banking system. I am totally in love with the capabilities of it.

Do you have plans to also emulate the SN76489 also?

 

I have no clue of how to set the header. Currently I only burn 512k binaries for developing Wizzy.

Perhaps the SN cart will be supported by emulators at some point in time...

 

 

[SainT]

2 minutes ago, karri said:

@Eagle created a very flexible banking system. I am totally in love with the capabilities of it.

Do you have plans to also emulate the SN76489 also?

 

I have no clue of how to set the header. Currently I only burn 512k binaries for developing Wizzy.

Perhaps the SN cart will be supported by emulators at some point in time...

 

 

If I have room in the FPGA for the SN76489 and I can find a suitable implementation, I will add it along with the banking scheme used. There's not a huge amount of space left now, so it will depend on how complex the SN PSG is.

[+karri]

33 minutes ago, SainT said:

If I have room in the FPGA for the SN76489 and I can find a suitable implementation, I will add it along with the banking scheme used. There's not a huge amount of space left now, so it will depend on how complex the SN PSG is.

From a programmers point of view the importance of SN cart emulation is:
1) map any 4k block of the cart space to $d000 by writing the block number to $d000 ( a generic window for accessing data on the cart )

2) flip 16k RAM into $4000 by writing 0 or 1 to $ffff (32k of RAM as bank 0, bank 1)

3) map 4k blocks to $a000, $c000 and $e000 also

4) SN76489 (if the cart already has POKEY I can use that)

5) flip graphics in banks $a000, $c000 and $e000 (I can save flipped and unflipped versions on the cart. So this is just a space saver)

6) COVOX (just a gimmic)

 

But it would be kind of cute to be able to release binary copies of Wizzy that could be run on this.

[Eagle]

At first there was an idea that SN76489 would be in a new header.

But then we added banking, 2x16KB ram, A8/A9 mirror ram, FlipX, Covox and now SN Cart needs at least 10 bits in the new header, or just one for SN Cart.

 

SN Cart documentation below:

https://home.mycloud.com/action/share/d61dc26f-b802-4648-900b-dcc49a4f7c38

 

And you can find some test ROMs in my topic in programming forum

If you need some examples just let me know.

[SainT]

5 minutes ago, Eagle said:

At first there was an idea that SN76489 would be in a new header.

But then we added banking, 2x16KB ram, A8/A9 mirror ram, FlipX, Covox and now SN Cart needs at least 10 bits in the new header, or just one for SN Cart.

 

SN Cart documentation below:

https://home.mycloud.com/action/share/d61dc26f-b802-4648-900b-dcc49a4f7c38

 

And you can find some test ROMs in my topic in programming forum

If you need some examples just let me know.

That's great, thanks. Covox and SN PSG are separate devices which seem sensible (or at least possible) to split out as separate bits, but the rest of the banking and everything else makes sense to me to just have as another mapper.

[Eagle]

Ok. I will not overcomplicate  

I can help from software side but if you will have any questions about hardware you can ask @rj1307 

 

[SainT]

I have a proposition for a V4 format, re-purposing the current type bytes and adding an additional audio mapper byte. The idea here is to allow for easy expandability and flexibility but also limit which features are valid and applicable at a per mapper level to clarify what is possible and therefore should be supported by devices.

 

Type Re-Purposing

 

Byte(s)	Size	Contents
$35	1	Mapper (Byte Value) $00 : Linear $01 : SuperGame $02 : Activision $03 : F18 Hornet $04 : Rescue on Fractalus $05 : Souper $06 : Bankset Linear $07 : Bankset SuperGame
$36	1	Mapper Specific Options (Bit Values) (Linear ROM) 0: RAM @4000   (SuperGame) Bits 0-2: 0 : No extra features              1 : High ROM @4000              2 : Additional ROM @4000              3 : 16K RAM @4000              4 : 32K RAM @4000 (BANKED)   (Bankset Linear) Bit 0: 32K RAM @4000   (Bankset SuperGame) Bits 0-2: 0 : No extra features              1 : High ROM @4000              2 : 32K RAM @4000 (BANKSET)

 

The first type byte specifies the overall bank mapping scheme, the second specifies mapper specific settings. I have split the bankset features out into separate mappers here as to remove redundancy of things like additional ROM and 16K non-bankset ROM being a possible permutation -- unless this is actually desired. Where features are mutually exclusive they are stored as an option index as opposed to a bit selection -- ie. "Bits 0-2" above defines 3 bits starting at 0 and has the possible option index listed. Options which are independent are stored as single bits to show if they are enabled.

 

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.

 

SuperGame

Size is again implicit from the payload. There will be some limitations depending on available memory of the device implementing the mapper. For instance the 7800GD has 1MB of memory, so a 1MB SuperGame image cannot have additional RAM or ROM.

 

Options for this mapper include standard SuperGame options for fixed banks and RAM, including the 32K banked RAM.

 

Bankset Linear

The same as Linear ROM but with separate banking scheme for Maria. The RAM selection for this mapper is 32K bankset style RAM only.

 

Bankset SuperGame

The same as SuperGame but with separate banking scheme for Maria. Options for extra ROM and non-bankset RAM have been removed deliberately, but the second fixed ROM remains. The RAM option is only for 32K bankset style RAM.

 

Other Mappers

Retail game specific mappers, operation as expected.

 

Audio Mapper

 

$3D

1

Audio Mapper (Bitmap) Bit: 5 : ADPCM    @ ? Bit: 4 : COVOX    @ $0430 - $043F Bit: 0-3 : 0 : POKEY @440               1 : POKEY @450               2 : DUAL POKEY @440/450               3 : POKEY @800               4 : POKEY @810               5 : DUAL POKEY @800/810               6 : POKEY @4000               7 : YM2151 @460               8 : SN76489 @?

 

This takes one of the currently reserved bytes at $3D.

 

As the low memory audio mappers are independent of the overall bank mapping scheme these are applied at a global level. The interrupt requests for each audio device are unchanged at $3E as the V3.1 specification.

 

If any audio device is enabled and overlapping an area of ROM (POKEY @4000 most notably) then the device will operate in write only mode.

 

Future expansions for this block will include SN76489 and ADPCM (streamed ADPCM audio in the same vein as how I handle BupChip for Rikki and Vikki but with a simplified interface in low memory), so the Audio Mapper settings may need to overflow into $3C in time.

 

There is the question on whether YM2151, POKEY and SN76489 would need enabling at the same time? It seems these should probably be mutually exclusive, however the COVOX and ADPCM are more likely an add-on for samples / background audio with other audio devices used for sound effects. ADPCM may be relegated to a mutually exclusive option if TIA is suitable for effects only. Modified audio selection to reflect this.

 

 

Thoughts on this appreciated, I will be moving to using the V4 format for future expansion with the 7800GD and would like to agree on something we can all use.

Edited February 8, 2023 by SainT
POKEY mapping changed

[RevEng]

My own view is that having a v4 header shouldn't be an automatic fail when running against an emulator or cart that only has support for v3 or ealier. If the hardware chosen doesn't work on the old emulator, fine. But with your proposal a v4 rom with pokey@450 set (or ym2151, or pokey@800, ...) will fail when run with older emulators. This will cause homebrew authors to pick between v3 and v4 header roms, and realistically, they won't pick and will just release both kinds when users complain that prosystem, bupsystem, or whatever, won't run their game.

 

My preference is to have the v4 header bytes set in parallel with the existing v3 bytes. If the emulator isn't v4 compatible, it will go ahead and parse the v3 features instead. If the rom author knows that the game won't run in older stuff lacking special hardware under v4, then they can scuttle those v3 bytes. If the target hardware is available in both headers, the author can give valid v3 info in addition to the v4.

[SainT]

It’s always a problem when moving from one version to another and radically changing things. 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. In situations where the V3 header cannot replicate the V4 settings then that’s fine, the device running the ROM would need to be updated to run the newer settings anyway.

 

(which is what you said except specifying where to put the V4 info…)

 

Any thoughts on the co-existence of different audio devices or specific options for RAM, etc, for mappers?

Edited February 8, 2023 by SainT

[RevEng]

Yep, I agree with storing the new bytes in the "cart data starts here" area.

 

The overwhelming consensus in the thread was to allow mix-and-match hardware selection, even when a physical mapper format doesn't exist - the main idea being that developers wanted to experiment, with the understanding that a particular combination may not have a real mapper format, nor would every emulator or cart be beholden to allowing all mixes. With that in mind, audio devices would all need to co-exist as bitfield options, rather than an index value. Perhaps we can group devices by address, and use an index in that case, but I haven't really thought that through.

[SainT]

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?

 

And the only other thing I've limited use of (ie. not included in the above) is the fractalus style RAM mapper, but that can be included easily for sake of flexibility in experimentation.

 

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