Cowering Posted March 30, 2016 Share Posted March 30, 2016 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 Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 30, 2016 Share Posted March 30, 2016 Just the boot-up phrase is programmed. It says "atarivox" on power-up. This isn't strictly necessary, but we can reach out to Richard H for this data when the rest of the emulation is roughed in. Quote Link to comment Share on other sites More sharing options...
Cowering Posted March 31, 2016 Share Posted March 31, 2016 That will be good, as I emailed tech support for SpeakJet chip, and EEPROM is write-only Quote Link to comment Share on other sites More sharing options...
Cowering Posted April 1, 2016 Share Posted April 1, 2016 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 Quote Link to comment Share on other sites More sharing options...
CPUWIZ Posted April 1, 2016 Share Posted April 1, 2016 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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 1, 2016 Share Posted April 1, 2016 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=2864640I 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. Quote Link to comment Share on other sites More sharing options...
CPUWIZ Posted April 1, 2016 Share Posted April 1, 2016 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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 2, 2016 Share Posted April 2, 2016 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. Quote Link to comment Share on other sites More sharing options...
CPUWIZ Posted April 2, 2016 Share Posted April 2, 2016 If that is really the case, they are criminals for selling the chips at this price. Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 2, 2016 Share Posted April 2, 2016 I tend to agree. Makes me want to revisit that old AVR Vox code I half-finished years ago. Quote Link to comment Share on other sites More sharing options...
Cowering Posted April 2, 2016 Share Posted April 2, 2016 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) Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 2, 2016 Share Posted April 2, 2016 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) Quote Link to comment Share on other sites More sharing options...
Trebor Posted April 2, 2016 Share Posted April 2, 2016 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. Quote Link to comment Share on other sites More sharing options...
iesposta Posted April 2, 2016 Share Posted April 2, 2016 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. Quote Link to comment Share on other sites More sharing options...
Jinks Posted April 3, 2016 Share Posted April 3, 2016 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) 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted November 19, 2016 Share Posted November 19, 2016 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 3 Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 22, 2021 Share Posted January 22, 2021 I've allocated some extra bits to represent hardware (pokey@440, ym2151@461/462) that has been implemented in the dragonfly cart. The new header asm is attached. a78header.asm 7800header and the docs at 7800.8bitdev.org have been updated. 4 2 Quote Link to comment Share on other sites More sharing options...
+bhall408 Posted January 23, 2021 Share Posted January 23, 2021 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. 3 Quote Link to comment Share on other sites More sharing options...
RevEng Posted February 23, 2022 Share Posted February 23, 2022 Heads-up that I've allocated an a78 header bit for banksets. I've also updated the a78 header description and the 7800header tool (found in the 7800AsmDevKit) at http://7800.8bitdev.org/. An updated assembly a78 header is attached to this post. a78header.asm 3 Quote Link to comment Share on other sites More sharing options...
Pat Brady Posted March 7, 2022 Share Posted March 7, 2022 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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 7, 2022 Share Posted March 7, 2022 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.] 1 Quote Link to comment Share on other sites More sharing options...
+batari Posted March 8, 2022 Share Posted March 8, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 8, 2022 Share Posted March 8, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
TailChao Posted March 8, 2022 Share Posted March 8, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
TailChao Posted March 8, 2022 Share Posted March 8, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.