A78 header changes

[DanBoris]

I don't have an objection to including simple header features when a game is actually going to be released that needs it, but I don't like the idea of having "infinitely configurable" hardware defined in the headers. You are talking about adding bits for flexible memory, but what if I want the flexibility to put a POKEY anywhere in memory I want it, or maybe two POKEYS, etc, where would you draw the line. The header could end up getting very complex.

 

I think the emulator authors can build that kind of flexibility into the emulator so developers can play with various configurations that a cart might support, and then add it to the header when they have settled on the scheme they want to use.

 

Dan

 

 

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.

[GroovyBee]

I think the emulator authors can build that kind of flexibility into the emulator so developers can play with various configurations that a cart might support, and then add it to the header when they have settled on the scheme they want to use.

 

In practice change requests only work if the emulator is actively developed. ProSystem v1.x isn't actively developed at the moment . Its only being ported across to other platforms e.g. Wii, PSP etc. I made some suggestions in May last year for some changes that I'd find useful (and maybe other programmers would too) and I eventually gave up and implemented them myself in a personal version of the source code. I'm not blaming anybody because real life gets in the way and projects fall by the wayside.

 

I'm going to be producing two builds of the emulator. One for developers that will have some simple debugging facilities like the ability to display the number of MARIA cycles per zone, logging/capturing writes to specific areas of memory, displaying memory, a debug port etc. The other version will not have those features enabled and will be for mainstream use.

[krewat]

I love this solution. Given that there is active development in the Atari 7800 realm, and that it is very possible to put real actual RAM at these addresses in a real active cartridge, AND I can actually see a reason to have so much RAM available, AND that it's not necessarily a "super cart" that would get RAM at $4000, I think this solution is perfect. (run on sentence much?)

 

ESPECIALLY as it only affects .a78 rom images, specific to the Atari 7800, and no other machine.

[DanBoris]

Ok, I'm just giving my opinion as the original creator of the header format. I am not going to try to stop anyone from doing this if they really want to.

 

As for an emulator with a debugger, I have always wanted to take EMU7800 (http://emu7800.sourceforge.net/) and combine it with all the debugging capabilities of my 6502SIM simulator to make a really nice emulator for developers. Unfortunately it's one of those project I just never seem to get around to doing .

 

Dan

 

 

 

In practice change requests only work if the emulator is actively developed. ProSystem v1.x isn't actively developed at the moment . Its only being ported across to other platforms e.g. Wii, PSP etc. I made some suggestions in May last year for some changes that I'd find useful (and maybe other programmers would too) and I eventually gave up and implemented them myself in a personal version of the source code. I'm not blaming anybody because real life gets in the way and projects fall by the wayside.

 

I'm going to be producing two builds of the emulator. One for developers that will have some simple debugging facilities like the ability to display the number of MARIA cycles per zone, logging/capturing writes to specific areas of memory, displaying memory, a debug port etc. The other version will not have those features enabled and will be for mainstream use.

[gdement]

I made some suggestions in May last year for some changes that I'd find useful (and maybe other programmers would too) and I eventually gave up and implemented them myself in a personal version of the source code. I'm not blaming anybody because real life gets in the way and projects fall by the wayside.

Sorry that I didn't get those changes done. I really did intend to do them, but as time dragged on, at some point I should have made a firm decision to either get 'er DONE, or else let you know it wasn't happening. I should have kept in better communication about that.

 

I'm going to be producing two builds of the emulator. One for developers that will have some simple debugging facilities like the ability to display the number of MARIA cycles per zone, logging/capturing writes to specific areas of memory, displaying memory, a debug port etc. The other version will not have those features enabled and will be for mainstream use.

2 builds would work, but any reason why these features couldn't just be enabled using a flag in the .ini configuration?

[GroovyBee]

2 builds would work, but any reason why these features couldn't just be enabled using a flag in the .ini configuration?

 

Basically the code isn't there to be enabled. ProSystem can now build release, debug and debug developer versions of the code.

[GroovyBee]

In order to support Curt's expansion module I'm also proposing the following for V2 of the a78 header :-

 

Byte index 63 - Expansion module

0x00 - No expansion module (default on all currently released games).

0x01 - Expansion module required.

0x02 to 0x80 - To be defined.

 

Whatever hardware specification the expansion module ends up at with regards to RAM, POKEY or feature XYZ, ProSystem will support it. Games will have to enable the features they are interested in, exactly like they would do on real hardware.

 

Would support for dual POKEY be of interest? By that I mean one in the cart and one in the expansion module? Or maybe even two in the expansion module.

[Bruce Tomlin]

Obviously some addresses would clash with the 7800's internal RAM. To map the RAM you want you just logical OR the values above together. So in Arts example of RAM at $4000 to $5FFF he'd need the following :-

 

00000000 01111111 10000000 00000000

Or you could just re-use the bits referring to standard RAM (as well as the $0000 block) for another feature.

[RevEng]

Heads-up that I used bit 5 of byte 53 (cart type) to flag support for supergame banked ram support in MESS 0.153, per CPUWIZ board designs with this feature. (bit 5 of the normal $8000 hotspot range determines the active ram bank)

 

So the updated fields for cart type would be...

 

bit 0 = pokey cart

bit 1 = supergame bank switched

bit 2 = supergame ram at $4000

bit 3 = rom at $4000

bit 4 = bank 6 at $4000

bit 5 = supergame banked ram

[RevEng]

I've grabbed bit 6 of cart-type/53 for pokey@$450. If a game is flagged for XM/Xboard, then this bit won't need to be set. Its meant to be used in case the game is targeting versaboard+pokey or some other non-XM/Xboard solution that doesn't have XCTRL, but does have pokey @$450.

 

Among other 7800 emulation improvements, the SVN version of MESS has support for this bit thanks to etabeta. It provides another way for homebrew authors to test out their game in various configurations.

 

So 53 now looks like...

 

bit 0 - pokey at $4000

bit 1 - supergame bank switched

bit 2 - supergame ram at $4000

bit 3 - rom at $4000

bit 4 - bank 6 at $4000

bit 5 - supergame banked ram

bit 6 - pokey at $450

 

The 7800 header with updated comments is attached.

a78header.asm

[+xucaen]

(posted to wrong thread)

[Cowering]

Resurrecting this topic!

 

I'm updating my Good7800 tool after too many years of spending all my time cataloguing Mario hacks. Trying to reconcile what MAME uses for header info versus the 'common' header info found at http://7800.8bitdev.org/index.php/A78_Header_Specificationversus actual 'in the wild' .a78 headers has given me the following questions that I hope the experts can answer!

 

1. MAME wants the pokey@450 flag to be bit 3 of byte 53, but it is normally listed at bit six of byte 54. Which is correct? A7800header.exe uses the former. I can easily update MAME if it is wrong. Never mind, the code is right, the comment describing it was wrong

 

2. Byte 57 is NTSC/PAL. Should PAL always be just 1, or is #$ff also a flag for PAL? Are there any other possibilities? I don't know 7800 well enough to guess about things like SECAM or PAL variants like Brazil had.

 

3. The above mentioned webpage does not list any meanings for bits 8-15. Is this simply because no one would make homebrew using Absolute or Activision mappers?

 

4. Is it an error to declare the header to be version 2, but to not have byte 63 set to nonzero? Am I missing another changed part of the header?

 

5. MAME uses bit 0 of byte 53 as 'normal cart' and bits 1 and 2 to be Absolute/Activision mappers. Some F18 Hornet .a78 files set this value to 3. Is this an error, or just someone's way of saying "This is an Absolute mapper with no other special flags that would be found in byte 54"?

 

6. Is having the Savekey and HSC bits set at once considered a header error?

 

7. Some headers look right only if you use little endian to interpret bytes 53 and 54. Is there a header tool that is known to mess this up?

 

Thanks so much for any clarifications.

 

Cow

Edited March 19, 2016 by Cowering

[RevEng]

Hi Cowering,

 

I'm the author of the wiki you referenced, 7800basic, and 7800header. Before I get to answers, there are a couple things worth noting first...

• Some wild headers have contradictory or wrong information.
• The header is emulation tool. MAME is the only active emulator that supports certain new hardware, like XM and Pokey@450. For such new hardware, MAME is the reference implementation.
• The header uses bit fields, rather than byte values, even though it's ambiguous in some cases since there are less than 4 possible values.

2. Byte 57 is NTSC/PAL. Should PAL always be just 1, or is #$ff also a flag for PAL? Are there any other possibilities? I don't know 7800 well enough to guess about things like SECAM or PAL variants like Brazil had.

There are only NTSC and PAL 7800 consoles. If bit 0 is set, then the game should be considered PAL by the emulator.

 

 

3. The above mentioned webpage does not list any meanings for bits 8-15. Is this simply because no one would make homebrew using Absolute or Activision mappers?

Yes, the wiki was populated from a homebrew POV, and there are presently no homebrew cart boards supporting these formats. The wiki entry should be updated to include those for accuracy, at some point.

 

 

4. Is it an error to declare the header to be version 2, but to not have byte 63 set to nonzero? Am I missing another changed part of the header?

No. At present some wild homebrew headers and the 7800header utility still use a version of "1". None of the emulators respect this byte, so its a bit of a moot point. GroovyBee's version of ProSystem mentioned in this thread was his personal version that he never shared publicly, so it's not a consideration.

 

IMO there's no practical value to up-reving the version for XM and the save device bytes. XM enabled games can (sometimes) run on non-XM hardware, so even if old emulators did respect the value, its a questionable case. Same with save devices.

 

 

5. MAME uses bit 0 of byte 53 as 'normal cart' and bits 1 and 2 to be Absolute/Activision mappers. Some F18 Hornet .a78 files set this value to 3. Is this an error, or just someone's way of saying "This is an Absolute mapper with no other special flags that would be found in byte 54"?

There's no special meaning. I'd consider 3 a bad header, since it indicates both formats.

 

Also are you sure about bit 0 of 53 meaning normal for MAME, or is that a comment error? Bit 0=1 should be Activision, bit 1=1 should be Absolute. All bits clear would be appropriate for "normal", or more accurately "non-activision and non-absolute".

 

 

6. Is having the Savekey and HSC bits set at once considered a header error?

No, they're independent devices that can co-exist. One goes in the cart slot, the other in the joystick port. Some newer homebrews support both.

 

 

7. Some headers look right only if you use little endian to interpret bytes 53 and 54. Is there a header tool that is known to mess this up?

Just to be clear, 54 is the byte with Pokey and Supergame info, 53 is the byte with Activision+Absolute bits. Anything flipping that is definitely a bad header. I'm not sure if there are old utilities that do that, but it's quite possible.

 

Some of these might fall through the cracks, since some older emulators use a rom database instead of respecting the header.

 

(I just noticed a 7800header bug though. The Activision and Absolute bits were swapped. I'll put a new version out, hopefully soon.[edit - done])

[Cowering]

Thanks for the fast reply. I am using the code from the function a78_cart_slot_device::validate_header() in MAME to determine good/bad headers. Since I'm a MAMEdev, anything that is decided to not match 'real' headers is easily fixed or faked.

 

To confirm.. this code from MAME is right? (mapper is (53*256)+54)

 

if ((mapper & 0xff00) == 0x0100)
m_type = A78_ACTIVISION;
else if ((mapper & 0xff00) == 0x0200)
m_type = A78_ABSOLUTE;

 

If I see absolute/activision mapper, I should regard all byte54 except for POKEY bits as invalid, true? I've not studied the MAME code for 7800 in 4-5 years and don't know if Supergame can be shared with the other two.

 

I'm going to all this trouble because there are a huge number of .bin only homebrews and I'd really rather not have to guess their info. MAME has a software list system, but it does not list homebrew, only originally issued carts. You have to laboriously add your homebrew, with checksum to the file for every rev as the CRC32 changes. When all files have the right header things are just smoother for the user.

 

BTW, if there is no controller listed for either port in the header, is it proper to assign a joystick to port 1 and nothing to port 2?

 

Can I guess that the prototypes that were obviously only programmed by US/NTSC programmers are flagged as PAL in .a78 header to keep from checking for their missing signatures on NTSC console?

 

Probably just another documentation error in MAME.. the mapper byte that our comment lists as 'normal' is probably meant to say 0 for the whole byte. It only makes sense regarding the code I pasted if the values are bit#s and not values. Sometimes binary is a bitch.

 

I see that i2c is supported in MAME. I'll try and hook it up if I have time for Savekey if etabeta does not beat me to it . I am pretty sure the full docs for AtariVOX are available. Maybe both can be added at once!

[RevEng]

Not a problem. Glad to help with your good work!

 

To confirm.. this code from MAME is right? (mapper is (53*256)+54)

 

if ((mapper & 0xff00) == 0x0100)

m_type = A78_ACTIVISION;

else if ((mapper & 0xff00) == 0x0200)

m_type = A78_ABSOLUTE;

 

If I see absolute/activision mapper, I should regard all byte54 except for POKEY bits as invalid, true? I've not studied the MAME code for 7800 in 4-5 years and don't know if Supergame can be shared with the other two.

The code is right, and your supposition is true. Both of these formats cover 0x4000, so the only hardware in byte54 that could possibly coexist is POKEY@450.

 

 

BTW, if there is no controller listed for either port in the header, is it proper to assign a joystick to port 1 and nothing to port 2?

I think that's a good idea. TBH, in the absence of any info from 55+56 (or 58=savekey), it would be better to assume both ports were joysticks. Certainly it wouldn't break anything.

 

Can I guess that the prototypes that were obviously only programmed by US/NTSC programmers are flagged as PAL in .a78 header to keep from checking for their missing signatures on NTSC console?

Well, the A78 header wouldn't be used by the console, since its a construct for emulators that gets added on to the ROMs. An NTSC console would boot the game based on it's region byte and signature.

 

So I'm not sure why those protos have headers flagged for PAL.

 

 

I see that i2c is supported in MAME. I'll try and hook it up if I have time for Savekey if etabeta does not beat me to it . I am pretty sure the full docs for AtariVOX are available. Maybe both can be added at once!

The SaveKey is literally a clone of the AtariVox eeprom circuit, so implement one and you have both.

 

There are a number of developers that would seriously appreciate that work. If you need any info, just shout!

[+Mitch]

Can I guess that the prototypes that were obviously only programmed by US/NTSC programmers are flagged as PAL in .a78 header to keep from checking for their missing signatures on NTSC console?

 

 

Do you mind mentioning which protos you are referring to?

 

Mitch

[Cowering]

 

Do you mind mentioning which protos you are referring to?

 

Mitch

 

I'll try and get a list, I'm not at my main computer right now.

[Cowering]

RevEng,

 

thanks again for clarifications. All the .a78 files I have from the wild either have #$00 or #$ff in byte 58 (except for a pit fighter with a #$9d, but that is just from sloppiness I think). Seems that Savekey and HSC can both be detected through software. Perhaps no one is using the proper flag in the header.

 

Can you name an A7800 game with Savekey support?

 

Cow

[Cowering]

 

I'll try and get a list, I'm not at my main computer right now.

 

An old list on my phone says that crc32 729DD769 (.bin) is one such file. I have it listed as a Diagnostic cart. I also have it flagged as not running in MESS in NTSC or PAL mode.

[Trebor]

Can you name an A7800 game with Savekey support?

 

b*nQ & Dungeon Stalker

 

 

An old list on my phone says that crc32 729DD769 (.bin) is one such file. I have it listed as a Diagnostic cart. I also have it flagged as not running in MESS in NTSC or PAL mode.

 

Circa Spring 2014 (MESS 0.153 cycle) the Diagnostic Cart started working under MESS.

[Cowering]

 

b*nQ & Dungeon Stalker

 

 

 

Circa Spring 2014 (MESS 0.153 cycle) the Diagnostic Cart started working under MESS.

 

Can you list the softlist entry in MESS for this working Diag Cart, or it's CRC32? I am currently trying to find the original forum entries for each ROM so that people who only want the latest version can use them without having upto 20 old versions. I can also use those original posts to verify what header the original author wanted. Some are clearly 'wrong', in that things like reserved bytes (although never specified) should be set to 0 or that the cartname field should also zero terminate so that 'simple' software readers can print that name without a parser. It is common practice to zero these fields to help future header expansions, but I am not sure I want to start making new versions of headers if all current emulators can decode the 'bad' ones.

 

I know nothing of the CC2 since Schell's site is dead. Is there a menu inside it that lets you specify NTSC/PAL or does it have it's own internal database for retail games? Perhaps a database on disk came with it??

 

Cow

[Trebor]

Can you list the softlist entry in MESS for this working Diag Cart, or it's CRC32?

 

I don't utilize the MAME(MESS) internal database. I always - unless specifically asked to test - use *.78 files in a separate directory. I've attached bonQ, Dungeon Stalker, and the Diagnostic Cart with their respective *.a78 files which run as expected under MAME, as well as the corresponding header stripped *.bin files. The resulting CRC32 on the Diagnostic Cart is A1EAA7C1.

 

bonQ.zipDungeonStalker.zipDiagnosticTestCart.zip

 

Two notes: 1. Dungeon Stalker utilizes both the Savekey and(or) HSC/XM for high score saving. So, if you launch 7800 emulation with the XM attached under MAME, while running Dungeon Stalker, you will see and be able to save high scores. 2. After the initial BIOS/Atari 7800 splash-rainbow bars screen, the screen goes blank for ~10 seconds when running the Diagnostic cart. Then you'll receive the color calibration page. This is normal and functions exactly the same under real hardware.

 

I am currently trying to find the original forum entries for each ROM so that people who only want the latest version can use them without having upto 20 old versions. I can also use those original posts to verify what header the original author wanted. Some are clearly 'wrong', in that things like reserved bytes (although never specified) should be set to 0 or that the cartname field should also zero terminate so that 'simple' software readers can print that name without a parser. It is common practice to zero these fields to help future header expansions, but I am not sure I want to start making new versions of headers if all current emulators can decode the 'bad' ones.

 

Respecting 'latest' ROMs/(original) forum entries for homebrews (and hacks), please see this thread.

 

 

I know nothing of the CC2 since Schell's site is dead. Is there a menu inside it that lets you specify NTSC/PAL or does it have it's own internal database for retail games? Perhaps a database on disk came with it??

 

For CC2 related material, you may be interested in this attachment:

 

Cuttle Cart 2.zip

 

I archived everything I could find some time ago. It includes source code and how the ROM(s database) is stored. I posted this archive on another thread too sometime in the last year.

 

If you're looking for something more streamlined in covering the CC2, below in the "Spoiler" is the tech doc for the CC2...

 

 

 

Cuttle Cart 2 Technical Specs
Copyright 2004 - Chad Schell

The Cuttle Cart 2 consists of three primary chips:

PSD - The boot controller, 256K of Primary Flash RAM, 32K of Second Flash RAM,
and 4K of NVRAM.  This chip controls the CC2 at boot up, and handles such
tasks as communicating with the MMC and programming the FPGA.

FPGA - The reconfigurable bankswitching controller.  Also used to implement
the serial port for serial communications.

512K SRAM - General purpose

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
PSD:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

This section describes the aspects of the PSD.  These are non-volatile and
non-reprogrammable features and mappings.

PSD Control Registers:  These registers allow access to the FPGA, MMC, and 
memory control registers.  The registers are available from $0600-$06FF or
when the csiop_cs input signal is pulled low.  The $0600-$06FF mode is the 
default boot up mode.  csiop_cs is an FPGA generated signal that allows the 
registers to be made available in any desired memory location $xx00-$xxFF.  
(Obviously the location must be chosen so as not to conflict with other active 
devices.)

All register locations are an offset into the active Register Window.

MMC/FPGA - Offset $20
Writing to this address communicates with either the MMC or the FPGA.  (They
are seleted by chip select bits in other registers.)

Writing to this address activates a byte exchange. The value
written to the register is transfered into the MMC or FPGA.  

The FPGA is write only, but the MMC simultaneously transmits a byte that is
stored in this register after the transfer is completed.  The value is held
in the register and can be read at any time prior to the next write to this
register.  

Note that MMC/FPGA communications require 8 6502 clock cycles to complete.  No
reads or writes to this register should be performed within 8 clock cycles of
writing to it.

Page Register - Offset $E0
Used to select which Flash RAM pages are active, to
control handshaking between the FPGA and the Boot Controller, and to enable
the NVRAM.

Bits 0-3:  Bank Selection
Bit 4: HSC_EN		Enables HSC section of NVRAM - Active High
Bit 5: NVRAM_EN		Enables Remainder of NVRAM (user settings) - 
			Active High
Bit 6: FPGA_CS		Enables FPGA programming clk - Active High
Bit 7: FPGA_GO		Transfer CC2 Control from PSD to FPGA - Active High

The PSD communicates with the CC2 by means of three multipurpose IO registers,
B, C, and D.  These registers are accessed and controlled by Direction, 
Drive Select, Input, and Output Registers.

Here is a list of the signals connected on each port, and the type of signal.
Only ports labeled I, O, or I/O should be modified by the user in code running
on the 6502.

PSD B Register:
Bit #		Signal		Type:		Notes:
0		MMC_OUT		Input Reg	Output from MMC to PSD
1		FPGA_REQ	Logic In	Used by FPGA to access PSD 
						after FPGA_GO is High
2		CSIOP_CS	Logic In	PSD Registers Respond to all 
						addresses when Low
3		FPGA_CLK	Comb O		= MMC_CLK & FPGA_CS
4		FPGA_PROGRAM	I/O
5		FPGA_INIT	I/O		Must be set to Open Collector 
						in input mode
6		FPGA_DONE	I
7		MMC_IN_OUT	Output Reg	Output from PSD to MMC

PSD C Register:
Bit #		Signal		Direction	Notes:
0		TMS		X		JTAG
1		TCK		X		JTAG
2		VSTBY		X		Battery Power
3		-		X
4		MMC_CS_OUT	O		Active Low
5		TDI		X		JTAG
6		TDO		X		JTAG
7		MMC_CLK_OUT	Clk Out		Runs for 8 cycles after MMC Reg
						written

PSD D Register:
Bit #		Signal		Direction	Notes:
0		FPGA_GO		Chip Select	Active High, Controlled by 
						FPGA_GO in Page Register
						(Must be set to output in 
						direction register)
1		RAM_CE		O		Active Low
2		POKEY_CS	O		Active High

PSD I/O Register Offsets used by CC2:
Register Name		Offset
Input B			$01
Output B		$05
Output C		$12
Output D		$13
Direction B		$07
Drive Select B		$09
Direction C		$14
Direction D		$15

PSD Power Management Register - Offset $b0
Used to set the PSD into low power mode by disabling it's TURBO bit.
7800 is so slow that TURBO is NOT necessary.

PSD Memory System
The PSD provides the CC2 with FLASH ROM and NVRAM.  The addressing schemes for
these memories is fixed at prodution time and cannot be altered.

4K of Battery Backed Ram:
2K Used for High Score Cart Emulation:
Located from $1000-$17FF if HSC_EN & fpga_req & csiop_cs

2K used for storing user settings:
Located from $800-$FFF if NVRAM_EN & fpga_req & csiop_cs

256K Primary Flash RAM:  
Split into 8 pages of 32K each.
Atari address lines A0-A14 are attached directly to A0-A14 of the flash RAM.
So when less than 32K of a page is mapped into Atari address space, 
the portion of the page available is determined by A0-A14.

In the table below Page # refers to the physical Flash RAM page.  Address range
refers to the address in the Atari memory map at which the page is available.
Bank Selection refers to that must be set in the Bank Selection bits of the 
PSD Page Register.  Additional Enables are additional conditions which must
be met for the page to be active.  See elsewhere in this manual for a
description of these signals.

Page #		Address Range	Bank Selection	Additional Enables
0		$8000-$FFFF	0		!FPGA_GO & !emg_boot & csiop_cs
0		$8000-$FFFF	1		!FPGA_GO & emg_boot & csiop_cs
Note: Page 0 is the boot page.  The menu mode is contained in this page.

1		$8000-$FFFF	1		!FPGA_GO & !emg_boot & csiop_cs
1		$8000-$FFFF	2		!FPGA_GO & emg_boot & csiop_cs
Note:  Page 1 contains the dev mode code.

Note:  Pages 2-7 are currently unused.
2		$8000-$FFFF	2		!FPGA_GO & !emg_boot & csiop_cs
2		$8000-$FFFF	3		!FPGA_GO & emg_boot & csiop_cs
2		$3000-$3FFF	9		!FPGA_GO & !emg_boot & csiop_cs

3		$8000-$FFFF	3		!FPGA_GO & !emg_boot & csiop_cs
3		$8000-$FFFF	4		!FPGA_GO & emg_boot & csiop_cs
3		$4000-$7FFF	10		!FPGA_GO & !emg_boot & csiop_cs

4		$8000-$FFFF	4		!FPGA_GO & !emg_boot & csiop_cs
4		$8000-$FFFF	5		!FPGA_GO & emg_boot & csiop_cs
4		$3000-$3FFF	11		!emg_boot & fpga_req & csiop_cs

5		$8000-$FFFF	5		!FPGA_GO & !emg_boot & csiop_cs
5		$8000-$FFFF	6		!FPGA_GO & emg_boot & csiop_cs
5		$4000-$7FFF	12		!emg_boot & fpga_req & csiop_cs

6		$8000-$FFFF	6		!FPGA_GO & !emg_boot & csiop_cs
6		$8000-$FFFF	7		!FPGA_GO & emg_boot & csiop_cs
6		$8000-$FFFF	13		!emg_boot & fpga_req & csiop_cs

7		$8000-$FFFF	7		!FPGA_GO & !emg_boot & csiop_cs
7		$8000-$FFFF	8		!FPGA_GO & emg_boot & csiop_cs

32K Secondary Flash RAM:
The emergency boot system RAM.  Accessible as follows:
Page #		Address Range	Bank Selection	Additional Enables
0		$8000-$FFFF	0		!FPGA_GO & emg_boot & csiop_cs
8		$8000-$FFFF	1		!FPGA_GO & !emg_boot & csiop_cs

The code and data stored in the FLASH RAM (both primary and secondary) is 
field upgradable.  (The OS can be updated by the end user.)

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
FPGA:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

The FPGA is the primary mechanism of provided flexibility in the CC2.  It has 
complete control over access to the 512K of general purpose SRAM.  While the 
PSD is running things (OS mode) the FPGA acts as a slave to the PSD, providing
access to the SRAM for loading games as well as serial port functionality. 
This is accomplished through a default FPGA configuration that is stored in the
PSD flash RAM as part of the OS code.

In order to run a game, the PSD reprograms the FPGA with the appropriate 
bankswitching code and then hands control over the FPGA.  Once the FPGA has 
control, it can still access the PSD and the MMC (by going through the PSD.)

This section will NOT cover the various game bankswitching methods, but will 
describe the default FPGA OS mode, and the communication/handoff methods 
between the FPGA and the PSD.

What the FPGA Controls:
SRAM Address Lines A0-A18.
SRAM CE  (PSD also controls SRAM CE - both must be enabled to use SRAM)
SRAM OE	- SRAM output enable
SRAM WE - SRAM write enable
SERIAL_OUT - Output pin on Audio Jack (nominally used for serial comms)
POKEY CE (PSD also controls POKEY CE - both must be enabled to use POKEY)
FPGA_REQ (Requests access to PSD NVRAM after FPGA has control)
CSIOP_CS (Requests access to PSD Control Registers after FPGA has control)
DATA Output - FPGA can put data on the bus.  (Doesn't control the data bus 
	though, must make sure to avoid contention with other parts.)
IRQ - 7800 Interrupt Request Line

What the FPGA can read:
SERIAL_IN - Input pin on Audio Jack (nominally used for serial comms)
POKEY_IRQ - Interrupt Requests from POKEY
7800 Address Lines A0-A15 - 7800 Address Bus
7800 Data Lines D0-D7 - 7800 Data Bus
7800 Clk2 - 7800 Clock
7800 R/W - 7800 R/W line
7800 HALT - Input from 7800 that says CPU is halted
FPGA_GO - PSD signal that FPGA is in control


Programming the FPGA:
The FPGA in the CC2 is an SRAM based FPGA.  There is no limit to the number of 
times it can be reprogrammed, but it does not retain any programming once power
has been removed from the CC2.

The FPGA must be programmed by the PSD.  The PSD does this initially from code 
stored in the PSD's FLASH RAM as part of the boot up sequence.  When a game is 
ready to be run the PSD reprograms the FPGA with code stored in a bankswitching
file located on the MMC.

Specific details of the programming protocol are not provided in this guide.
See the OS source code for details.

Handing control over to the FPGA:
To hand control over the FPGA, a section of source code must run from outside
the PSD, typically from RAM inside the 7800 itself.  (Running from CC2 SRAM
would require careful logic in the bankswitching code.)

Control is handed off by setting the FPGA_GO bit in the PSD Page Register.
Once this bit is set high, PSD FLASH RAM will no long respond to any addresses,
so all OS code will no longer be accessible to the 7800.  PSD NVRAM will
respond if the appropriate HSC_EN or NVRAM_EN bits are also set in the PSG Page
Register.   The MMC and FPGA CS bits should be disabled before handing control
over to the FPGA.

Accessing the PSD and MMC after the FPGA has control:
The FPGA can still access the PSD after the FPGA_GO bit has been set.  NVRAM 
can be accessed if HSC_EN or NVRAM_EN have been set in the PSD Page Register by
setting the FPGA_REQ bit high.  See the PSD memory section for details on the
addresses where these two memory sections are available.

The PSD control registers can be accessed by setting the CSIOP_CS line low.
This will make the control registers active REGARDLESS of the address.

In order to have access to any of these control lines, the logic for setting 
them must be built into the bankswitching method programmed into the FPGA.
This is how CSIOP_CS can be used safely.  The FPGA logic will limit the address
range during which CSIOP_CS is low.

Default FPGA Mode (OS Mode):
This section presents the details of the default OS mode programmed into the
FPGA at boot time.

SRAM Access:
SRAM responds to read/write access in two windows in the 7800 address map:
$4000-$7FFF	Used for loading game code
$3800-$3FFF	Used to shadow the screen font

The SRAM in the $4000-$7FFF window is accessed in banks of 16K, where the 16K
bank in use is selected by writing the bank number to $0510.  Valid bank
numbers are from 0 to 32.

The SRAM in the $3800-$3FFF window always points to the last 2K of the SRAM.
This window exists to create a shadow copy of the onscreen FONT.
Unfortunately the 7800 does NOT properly control the clock line during DMA
transfers (the data is being fetched faster than the clock).  The PSD requires
a proper clock to line function correctly, so FONT retrieval from the PSD does
not function will on some 7800s, resulting in a lot of video noise and a
generally ugly (but otherwise harmless) display.  The snow would appear when
the TIA was accessed to read the console and joystick buttons.

To fix this problem the FONT was shadowed to the general SRAM which does not
require the clock for read access.

Note that SRAM access is controlled by both the FPGA and the PSD.  In order to
access the SRAM the RAM_CE bit on the PSD must be set low.  (This is always
true, be sure to set RAM_CE low before running a game!!!)

POKEY Access:
The POKEY responds to the address range $0500 $050F.  

Note that POKEY access is controlled by both the FPGA and the PSD.  In order to
access the POKEY the POKEY_CS bit on the PSD must be set high.  (This is always
true, be sure to set the POKEY_CS high before running a game that uses the
POKEY!!!  It it always safe to set it high before running any game as the FPGA
will still control whether or not it is used.)

Serial Port:
The FPGA in OS mode emulates an RS-232 serial port.  It provides a 16 byte
circular RX buffer and a 1 byte TX Buffer (in addition to the shift register of
data currently being transmitted).

Serial Port Addresses:
Serial Baud	$0511	Write a timer value to this address to set the baud
			rate.  Writing to this port also clears both TX and RX
			buffers and the serial status register. Any bytes
			currently being transmitted or received will be
			dropped.  (In other words it resets the serial port.)

	Here are suggested baud rate timer values:
	Baud Rate		NTSC Timer Value	PAL Timer Value
	9600			186			185
	14400			124			123
	19200			93			92
	38400			46			46
	57600			30			30
	115200			15			15

Serial Data	$0512	Write this address to transmit a byte.  If the TX
			buffer is full the write will be ignored and the
			TX_OVERFLOW bit will be set.  The bit currently in
			the TX buffer will be transmitted normally.

			Read this address to receive first byte off RX Buffer.
			
Serial Status	$0513	Read this to receive the serial status byte
			Write any value to it to clear the ERROR bits.  (But
			not the ready bits.)

The format of the status byte is as follows:

Bit #	Name			Description:
0	-			Always 0
1	-			Always 0
2	-			Always 0
3	Frame Error		An RX frame error occurred
4	RX Overflow Error	The RX buffer is has overflowed.  The oldest 16
				bytes are in the buffer.  The newest data has
				been dropped.
5	TX Overflow Error	An attempt was made to overwrite the full TX
				Buffer.
6	TX Buffer Full		The TX buffer is full (Don't write to it!)
7	RX Data Ready		A byte is ready for reading.

To use the serial port, set the baud rate and then monitor the status byte.
When RX Data Ready is set, read the byte and process it.  If you are
transmitting, wait until TX Buffer Full goes low before writing a new byte into
the TX Buffer.  Because the TX buffer is separate from theTX shift register it
is possible to maintain an continuous serial TX stream.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
SRAM:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

The SRAM is simply 512K of general purpose SRAM. It is controlled predominately
by the FPGA.  See the FPGA section for details.


XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
POKEY:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

The CC2 has a POKEY socket onboard.  A POKEY can be installed to provide 
POKEY sounds to games that use it.  Access to the POKEY is controlled
predominately by the FPGA.  See the FPGA section for details.


XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
MMC:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

The MMC is used to store game, bankswitching, and startup code data.
The MMC is controlled entirely by the PSD.

Currently the CC2 OS provides READ ONLY access to FAT16 formatted MMCs.  Write
access is possible if the proper FAT routines are created.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Game Start Sequence:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Starting game requires three files off the MMC, and three steps.

Step 1:
Read the game binary off the MMC and load it into the CC2 SRAM.

Step 2:
Read the FPGA bankswitching configuration file off the MMC and configure the
FPGA.  This must be done second as the ability to write to SRAM will now be
in game mode instead of OS mode.

Step 3:
Read the startup code file off the MMC into 7800 RAM.  This code should handles
the change of control from the PSD to the FPGA.  Once loaded jump to this code
and run it.

 

 

[Cowering]

 

Two notes: 1. Dungeon Stalker utilizes both the Savekey and(or) HSC/XM for high score saving. So, if you launch 7800 emulation with the XM attached under MAME, while running Dungeon Stalker, you will see and be able to save high scores. 2. After the initial BIOS/Atari 7800 splash-rainbow bars screen, the screen goes blank for ~10 seconds when running the Diagnostic cart. Then you'll receive the color calibration page. This is normal and functions exactly the same under real hardware.

 

 

Ah.. I was not waiting long enough for diag cart! I'll try DS later this week. Thanks

 

Cow

[Cowering]

I've about got everything straightened out now. All the 'fixes' I would make to a header are already done by MAME so I'll just leave 99% of them alone.

 

I did find that on the 7800 emulation page I am listed as 'Matt Cowering'.. no clue who that is as my name is not 'Matt'

 

Does anyone have a tech manual for the speech chip in AtariVox? the Savekey part looks straightforward enough to code but the speech chip is something altogether different.

[Trebor]

I've about got everything straightened out now. All the 'fixes' I would make to a header are already done by MAME so I'll just leave 99% of them alone.

 

I did find that on the 7800 emulation page I am listed as 'Matt Cowering'.. no clue who that is as my name is not 'Matt'

 

Does anyone have a tech manual for the speech chip in AtariVox? the Savekey part looks straightforward enough to code but the speech chip is something altogether different.

 

Hope the attached helps:

 

speakjetusermanual_Rev1_0.pdf

speakjetusermanual_Rev1_1.pdf

 

Rev 1.1 is from Sept 2004, slightly newer than the one at the below linked site (Jul 2004 - Rev 1.0).

 

Product and more documents are here.