Jump to content
IGNORED

A78 header changes


GroovyBee

Recommended Posts

Does the AtariVOX ship with the EEPROM already programmed with some phrases? I didn't see a way to read out the current EEPROM contents from a quick look at the pdf so it would be 'impossible' to properly emulate it in MAME

 

The EEPROM is socketed and can be read with a universal programmer, or a Microchip specific programmer. Or you could rig up a little Arduino interface to the EEPROM and read it that way. ;)

Link to comment
Share on other sites

Still crawling around the .a78 header.. does anyone have a concise doc for the header mod mentioned here for HSC? http://atariage.com/forums/topic/199637-work-in-progress-bentley-bear-crystal-quest/page-32?do=findComment&comment=2864640

I don't think Trebor was describing a header mod there. He's advising of older HSC handling code in MESS, I think. There's just the one HSC bit in byte 58. I'm not aware of any other HSC support in the header.

 

 

The EEPROM is socketed and can be read with a universal programmer, or a Microchip specific programmer. Or you could rig up a little Arduino interface to the EEPROM and read it that way. ;)

Cowering is talking about the EEPROM area in the PIC (I'm assuming a custom PIC is what Speakjet is. It's never been officially confirmed) vs the stand-alone EEPROM chip in the Atarivox.
Link to comment
Share on other sites

 

Cowering is talking about the EEPROM area in the PIC (I'm assuming a custom PIC is what Speakjet is. It's never been officially confirmed) vs the stand-alone EEPROM chip in the Atarivox.

 

I doubt it, since there is a real PIC on the board, that is the surface mount chip I keep soldering onto the PCB for the store. Reminds me, I need to find some time to build some more.

IMG_1164.JPG

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

I don't think Trebor was describing a header mod there. He's advising of older HSC handling code in MESS, I think. There's just the one HSC bit in byte 58. I'm not aware of any other HSC support in the header.

 

 

Cowering is talking about the EEPROM area in the PIC (I'm assuming a custom PIC is what Speakjet is. It's never been officially confirmed) vs the stand-alone EEPROM chip in the Atarivox.

 

I was kinda talking about both :) I have not gotten deep enough into the AtariVOX to see that it had external EEPROM as well as internal EEPROM on the Speech chip. If the Speech EEPROM can be read out, that would work perfectly with MESS' slot system as slots can have ROM/RAM nowadays. Trebor's wording led me to believe Prosystem could get the HSC data from somewhere, it just didn't write it back to a permanent diskfile. If MESS did this, it would store the data in a file that was local to the slot, so that any other game you loaded with HSC in the slot would see a consistent set of data.. This is great when you are playing hacks of the same game... you get to keep the highest score of all of them (sneaky huh)

Link to comment
Share on other sites

Sneaky indeed!

 

The speakjet (speech data) EEPROM can only be written to, AFAIK.

 

The Atarivox external (game save) EEPROM is shipped uninitialized, with all bytes containing 0xff.

 

I'm not a Prosystem emulator user, but if I recall correctly, the HSC emulation is broken or incomplete, which I think is what Trebor was referring to. (I'm sure some Prosystem user will correct me if I have that wrong)

Link to comment
Share on other sites

I don't think Trebor was describing a header mod there...

 

Correct.

 

...Trebor's wording led me to believe Prosystem could get the HSC data from somewhere, it just didn't write it back to a permanent diskfile...

 

The condition of whether HSC support 'works' under ProSystem has nothing to do with the header; rather, whether the data is present in the game ROM file it is running.

 

Some older/demo builds of Donkey Kong PK/XM contains HSC data already present, being included in the distributed game ROM file. ProSystem reads (only) that data.*

 

*EDIT: It is elaborated in more detail by a post from tep392 on how HSC provisioning is handled under the ProSystem emulator (Main piece pasted below for convenience)...

 

"...Since prosystem incorrectly treats everything up to $4000 as continuous ram, I simply copied a 2k saved RAM binary to $1000 and copied the HSC ROM to $3000. I did this by assembling my code with the binary data in an unused ROM bank. When the game is being initialized, I switch to that bank and copy the binary data to RAM. It then looks to prosystem like the HSC is present. The only drawback is that I can't easily save the HSC data before exiting Prosystem. I have to use a save state and hex editor to get the HSC data back into a binary file..."

 

Regarding MESS from a few years back, the way HSC support worked was improperly including it as part of the base console's functionality and performing read/writes to a "NVRAM" file to the address space where HSC data is stored ($3000-$3fff).

 

HSC support was properly re-written by etabeta to reflect actual hardware performance and behavior, removing support from the base console, and adding slots to the system's cartridge port; reading/writing data to the aforementioned address space, only when utilizing either hsc or xm as slot devices. Separate files are maintained for each device, storing data according to the HSC value assigned.

 

'Slotification' is needed for the controller ports though. Currently, only joysticks-pads are supported. Paddles and Light Gun support (Which the a2600 and Atari 8-bit drivers would also benefit from) is not present.

 

As a side note, the Atari Light Gun utilizes Cathode Ray Timing - similar to a Vectrex Light Pen. That same method is utilized for the SMS Light Phaser and SNES Super Scope; both of which are already supported in MAME. Further along those lines, the Light Pen has already been hooked up to vcs_ctrl, as well as mentioned under the video, machine, and driver for the Vectrex.

 

Technically, anything under 'vcs_ctrl' - including the paddles, wheel, keypad, etc., all can connect to the 7800. Of those, the paddles and light(gun) are the only ones utilized by 7800 games. Three original retail titles: Barnyard Blaster, Meltdown, and Sentinel, require Light Gun support. Consequently, they are all unplayable under MAME as a result. A few other games on the 7800 allow Light Gun support as optional.

Link to comment
Share on other sites

Between my AtariVox and AtariVox+, when powering up, the original kind of "sings" AtariVox, with Vox a higher note.

The AtariVox+ "speaks" it more, with emphasis on "tar".

 

Also, not to bring up paid-for hardware that hasn't shipped, but for facts on the start-up speech, I remember something about the ones that were to be built-in to the never-completed Anniversary 7800's - they were programmed to say something different at start-up.

Link to comment
Share on other sites

 

Also, not to bring up paid-for hardware that hasn't shipped, but for facts on the start-up speech, I remember something about the ones that were to be built-in to the never-completed Anniversary 7800's - they were programmed to say something different at start-up.

Ya I believe it was (sŭk′ər)

  • Like 1
Link to comment
Share on other sites

  • 7 months later...

Heads-up that I've grabbed bit 7 of the A78 header byte 53, to represent "mram at $4000". This is to support correct emulation of the hardware used in the Rescue on Fractalus proto. "mram" stands for Mirror RAM - the proto doesn't use one of the address lines to intentionally create mirrors of even RAM pages at odd RAM page locations.

 

The header byte 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

bit 7 - mram at $4000

 

The 7800 header with updated comments is attached. [edit - removed. an updated header has been posted to this thread, below]

 

 

I've also updated the 7800 header utility in the 7800 Assembly Dev Kit

  • Like 3
Link to comment
Share on other sites

  • 4 years later...
On 1/21/2021 at 8:43 PM, RevEng said:

I've allocated some extra bits to represent hardware (pokey@440, ym2151@461/462) that has been implemented in the dragonfly cart.

Thanks Rev!

 

Dual/Stereo Pokey is implemented in Argon (thanks to @ZihuaCode!)

 

We plan to add YM support once we find (or create) a license compatible (ie, non GPL) implementation.

  • Like 3
Link to comment
Share on other sites

  • 1 year later...
  • 2 weeks later...
1 hour ago, TailChao said:

Investment in sparsely used or never shipped hardware designs.

 

 

That's totally fine.

 

Edit : In the spirit of also being totally clear - I wholeheartedly agree that a pivot into a new header space for adding new cartridges as they're designed is a good move. Look at that big honkin' ACTUAL CART DATA STARTS HERE string we don't really need.

 

My points of caution are just to not allocate things on a whim, that the most popular emulator is forked from MAME so it's easy to "try before you buy", and to learn from other communities which went through the same homegrown hardware pains.

 

I totally agree with all of this, and I in turn want to clarify that while I used AY-3-8910 as an example of something that might be coming in the future, I am not proposing to actually define such a cart type until somebody actually uses it. It was just an example (admittedly, one that I would like to see) but the real point was that SN76489 is probably not going to be the last audio chip to ever be put in a 7800 cart. Especially since "audio chip," in this context, is fungible with "software running on a microcontroller that's already on the board."

 

47 minutes ago, RevEng said:

I appreciate the suggestion, though I think we don't need to dedicate bits for what amounts to a look-elsewhere sign. We can increment the version byte in the header instead, and just define an additional word or two. (though come to think, perhaps the new word can contain mapper indexes instead, which take precedence with platforms that support the new header version, and the original format word be the nearest approximation for old emulators, if possible. But this is a conversation for another thread.)

 

Compared to defining bit 13 as banksets and bit 14 for SN76489, what I'm proposing actually saves a bit in the cart-type field, and, I believe, will be compatible with all in-the-wild .a78 files.

 

I don't know the implications of updating the version byte.

 

Mapper indexes (and audio chip indexes) was what I had in mind, though I realize I didn't explicitly say so.

 

Slightly swamped right now but I'll write it up more formally later this week.

 

EDIT: I don't mean to be dismissive of the version byte idea. It wouldn't surprise me if you do know what all of the actively-supported flash carts do with it. I just feel like re-using bits that are already (or soon to be) allocated is less risky. I might be wrong of course.

Link to comment
Share on other sites

1 hour ago, Pat Brady said:

I don't know the implications of updating the version byte.

No implications. I increased the version to "3" about a year ago, to support a TV-type update I made to provide a hint to emulators that the game uses composite artifacting. 7800basic and the assembly header were updated at that time, and there have been no issues with emulators. Previously GroovyBee incremented the version to "2". The old stuff just ignores the version byte.

 

FWIW, I don't think a field addition should be done *without* increasing the version byte. So reserving bits to indicate the presence of new field isn't necessary, and honestly not a versioning alternative I want to take on, because then the header parsers need to follow some chain of breadcrumbs whenever you decide to introduce a new field. I agree there's an argument to be made that banksets (or anything else new) doesn't need to go in cart-type, since the implementation hasn't yet been made public, and what we're proposing is deprecating cart-type with the new mapper word.

 

[edit reply to your edit comment ;) I'm not talking about doing away with the cart-type word. It would still exist in the new version header; it would just be ignored by newer emulators and flash carts that understand the new header version.]

 

  • Like 1
Link to comment
Share on other sites

I agree with the earlier proposition that the header moves toward mapper-type indexes, rather than device-bitfield indexes.

 

I would not add any new bitfields at this point, but instead, perhaps keep the legacy bitfields, but if they are $FFFF then use the index instead, or something. I'd use two bytes for the index in case over 256 mappers are needed (seems unlikely, but who knows.)

 

The only part I'd want to enforce is the index should grow in order (i.e., 0, 1, 2, 3,...) and not simply allow whatever number someone wants to use within the range 0-65535. It is far easier from a programming perspective use an ordered list.

  • Like 1
Link to comment
Share on other sites

Yeah, agreed on all counts, except for the legacy cart-type bitfield flag of $FFFF. That means to use the mapper field, you'd need to give up compatibility with older emulators, which would be a non-starter for adoption by most devs. I think if the version flag of the header is  4 or greater, it just means the mapper definition is guaranteed to be valid, and should always be used instead of the bitfield.

 

If someone wants to exclusively use the old cart-type field, then they can just use an older version header. It was always my intent for version 4 to have a decently populated cart-type bitfield (where possible) to allow compatibility. 

 

$FFFF or Pat's high bit could be used to indicate "legacy support impossible", but IMO anything that understands this would also be able to parse the mapper index anyway, and shouldn't be using cart-type in that case.

  • Like 1
Link to comment
Share on other sites

I think it's a good idea to borrow the fallback behavior from the iNES -> NES 2.0 transition, where if a cartridge doesn't need any of the new header format's features it can still load in older emulators. So what's everyone doing?

 

  • ProSystem 1.3
    • Doesn't check version byte.
    • Doesn't confirm presence of ACTUAL CART DATA STARTS HERE string.
    • Defaults to rom only / mapperless if it doesn't understand the cartridge type field, does a straight comparison with the fields (no masking).
       
  • MAME 0.241
    • A whole lot to read...
    • Doesn't (seem to) check the version byte.
    • Doesn't (seem to) confirm presence of ACTUAL CART DATA STARTS HERE string.
    • Puts an awful lot of effort into figuring out intent in the header fields, but if ((TYPE & 0xFF00) > 0x0300) it'll give up and cry "please contact MAMEdevs". Not sure if the intent was supposed to be > $0200 here?
       
  • A7800
    • Similar to MAME (obviously).
    • I guess the intent in validate_header was ((TYPE & 0xFF00) > 0x0200), since it was changed to that here, lol.
       
  • BupSystem 0.9.6.4 (parsing behavior documented in HTML Help)
    • Doesn't check version byte.
    • Requires ACTUAL CART DATA STARTS HERE string.
    • Masks cartridge type with $138F before evaluating what it might be.
       

One unified behavior among all the above is comparing the first string to "ATARI7800" rather than "ATARI7800       " so the trailing spaces are fair game for new flags or an extended key.

 

13 hours ago, RevEng said:

$FFFF or Pat's high bit could be used to indicate "legacy support impossible", but IMO anything that understands this would also be able to parse the mapper index anyway, and shouldn't be using cart-type in that case.

Given the above - I'd recommend using $C000 here, extending the "ATARI7800" key to "ATARI7800X" or similar and replacing its pad spaces with zeroes, and bumping the version. This'll fail as a mapperless / rom only cartridge for the emulators which do aggressive masking and report an error with the rest. It's also make a clear distinction between the header variations and still allow fallbacks.

 

 

15 hours ago, batari said:

I agree with the earlier proposition that the header moves toward mapper-type indexes, rather than device-bitfield indexes.

 

I would not add any new bitfields at this point, but instead, perhaps keep the legacy bitfields, but if they are $FFFF then use the index instead, or something. I'd use two bytes for the index in case over 256 mappers are needed (seems unlikely, but who knows.)

Maybe take this even further given the broad variety of components which can be shoved in a cartridge.

 

$40 - $41 : Cartridge Mapper ( index )

$42 - $43 : Features ( flags specific to each mapper, things like the presence of a battery backed memory or a simple sound chip )

$44 - $5F : Extended Descriptors ( for features which need long pointers, i.e. track counts and table offsets for the BupChip or if someone makes a GTMP3 style cartridge with an MP3 decoder )

 

I don't foresee much adoption of my own hardware here, but it's probably good to be prepared if that happens.

 

Ah also, the TV-Type field should allow for multiregion software. That's been a thing for several whiles.

  • Like 1
Link to comment
Share on other sites

Whoops, I left out EMU7800!

  • Also only checks the first nine characters of the ATARI7800 key.
  • Reads ACTUAL CART DATA STARTS HERE, but doesn't explicitly require its presence.
  • If (TYPE & 0xFF00) > 0x0200 it'll assume mapperless, and guess by size - sizes larger than 48KB it'll report an error.

 

While we're at it, let's read some Verilog in Kitrinx's MiSTer Core!

  • No string checks - but this could be in a separate loader stage.
  • Cartridge type is evaluated by set bits, with the priority of ACTIVISION (8) > ABSOLUTE (9) > SOUPER (12) > SUPER (1) > ROM ONLY.
     

So I think the above still holds up.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...