TailChao Posted December 11, 2018 Share Posted December 11, 2018 (edited) Oh, hello there. Welcome to BupSystem. BupSystem is an Atari 7800 ProSystem emulator originally written to assist in the development and distribution of Rikki & Vikki. Currently it's closed source and only available for Microsoft Windows. Emulated Hardware Sally, Maria (NTSC or PAL), TIA, RIOT, and the BIOS Mappers : 16K, 32K, 48K, SUPER, SOUPER, ABSOLUTE, and ACTIVISION Expansion Modules : XBoard Cartridge Audio : Pokey, BupChip YIQ Color Generation One and Two Button Joysticks Light Pens and Light Guns Minimum Requirements 1.2GHz Intel Pentium III 256MB RAM Microsoft Windows 95 + DirectX 7.0 DirectDraw or Direct3D Compatible Graphics Accelerator DirectSound Compatible Audio Device The newest version is BupSystem 0.9.6.4. You can download older versions from the BupSystem Webpage. Grocery List for Future Versions These things may happen eventually Core - Sally, Mappers, and Other Hardware Customizable Open Bus Behavior Customizable RAM Initialization Patterns Concept of Input Devices (or just "Devices") which can be plugged into either controller port. Video - Maria and TIA Full recheck of Maria's rendering behavior and timing with the actual hardware TIA Video generation isn't supported, not sure if or when I want to deal with this Audio - TIA, Pokey, and BupChip Better resampling algorithms and possibly adjustable chip volumes Pokey behavior needs to be more thoroughly confirmed Conveniences BEAD (*.b78) Dispatch Support Compressed File (*.zip and maybe *.7z) Support Fast Forwarding Quick Saves Quick Screenshots Customizable Overscan Optional automatic region switching when loading *.a78 cartridges. Video Filters Sharp Scaling (enlarge using nearest then reduce with bilinear) Television (NTSC / PAL) Full Hardware Documentation in HTML Help Article detailing the ProSystem's development and commercial life in HTML Help Extras BupSystem BIOS Implemented Changes for the Next Version (0.9.7.0) These will be included in the next release. Added Nothing yet. Cleanup Nope. NOTICE REGARDING WINDOWS DEFENDER AND HTML HELP If you try to view BupSystem's HTML Help (F1) and are presented with blank pages, you may have to unblock BupSystem.chm (Properties -> Unblock). @Trebor's Suggested Palette Adjustments for 0.9.6.x These parameters are available in the Color Dialog (Options -> Maria -> Adjust Color... or F4) Quote Brightness = 100% - 105% Contrast = 105% - 110% Hue = -23% thru -30% for PAL Hue = -9% thru -16% for NTSC Saturation = 60% - 80% Warmth = 29% Factory (Cool) Warmth = 36% Ideal (Warm) Warmth = 43% Common (Hot) ...As always, YMMV. More information can be found in the included help file, and from you! If you have any bug reports, feature requests, or are just a happy BupSystem user - let me know! Edited March 10, 2022 by TailChao 14 Quote Link to comment Share on other sites More sharing options...
Trebor Posted December 16, 2018 Share Posted December 16, 2018 Hey TailChao, Very nice progress with the BupSystem emulator. Ran some NTSC testing and provided the results below that hopefully will be found useful and aid in its development. Off the bat, there are some things to consider:1. Overall Timing/MARIA Issues - See 7800 Test ROM captures in spoiler.2. Game Specific Timing/MARIA Issues (Kung Fu Master, Scrapyard Dog).3. Game Visibility Issues (Choplifter, Midnight Mutants, Commando, Tank Command, Galaga, Donkey Kong Jr, Food Fight).4. RIOT/Controller emulation issue(s): One-On-One Basketball - Cannot shoot the ball or call timeouts. No button response in-game.5. POKEY @450 missing sound (Donkey Kong PK & Bentley Bear's Crystal Quest are silent).6. Official Diagnostic Test ROM failure. Here are more specifics on the above points:1. Overall Timing/MARIA Issues. The Test ROM is pretty self explanatory when launched. Just press right to ascend through the testing. The aforementioned link also provides excellent technical facts respecting the 7800 hardware is not already known. Screen captures of how BupSystem performs currently is contained in the spoiler below: Note: Tests 11 & 12 cannot be properly vetted through a screenshot. Rest assured, BupSystem does pass those two test. 2. Game Specific Timing/MARIA Issues. No show stoppers here, but in harmony with the timing issues demonstrated above, there are real world/practical application circumstances worth considering. Kung-Fu Master & Scrapydog are the most notable occurrences. See spoiler below. 3. Game Visibility Issues. Similar to its contemporaries, 8 scanlines off the top and bottom of the display should be accounted for (240-->224), to avoid unintended viewing of areas not meant to be seen or impossible to see under the average CRT display. Whether available as a toggle (Recommend default on) or permanent coded, it ideally should be in place. Spoiler below provides some highlights of the undesirable viewings of a full 240 lines as currently provisioned under BupSystem. 4. RIOT/Controller emulation issue(s): One-On-One Basketball - Cannot shoot the ball or call timeouts. No button response in-game. Memory fails me as to why exactly or what, but I remember this impacting what is now the A7800 emulator several years ago. The available source code can perhaps be leveraged for assistance, as overall it contains some excellent notes and details surrounding emulation of the 7800 ProSystem. 5. POKEY @450 missing sound (I.E. Donkey Kong PK & Bentley Bear's Crystal Quest are silent). Again, leveraging the available source code mentioned in point 4 perhaps may assist, if needed. 6. Official Diagnostic Test ROM failure. A thorough analysis and breakdown of the ROM is provided online. When functioning properly, a screen that is hard to miss is seen after the ROM has been running for ~10 seconds. Currently, BupSystem just remains at a blank screen indefinitely. Nonetheless, looking forward to future developments, in which hopefully, open source and other platforms may be under consideration. 1 Quote Link to comment Share on other sites More sharing options...
TailChao Posted December 17, 2018 Author Share Posted December 17, 2018 (edited) Ah, thanks for the tests! Looks like you're running BupSystem with Coarse Rendering Enabled (Options -> Maria (Video) -> Coarse Rendering) and No BIOS. These cause some of the inaccuracies you're experiencing but also a few are my fault. I'll go into detail below... 1) Overall Timing/MARIA Issues Coarse Rendering only allows Maria register and configuration changes per-scanline rather than per-pixel which leads to the issues here. Disabling it will make most of the tests look as they do on the hardware with the exception of some being a few clocks off. 2) Game Specific Timing/MARIA Issues - (Kung Fu Master, Scrapyard Dog) Same as above, these issues show up if Coarse Rendering is enabled. Scrapyard Dog still might not be totally correct though, I need to confirm some of Maria's fetch behaviors on the first few lines with a logic analyzer before I go back to these. 3) Game Visibility Issues - (Choplifter, Midnight Mutants, Commando, Tank Command, Galaga, Donkey Kong Jr, Food Fight) My decision to show overscan was intentional so I can ensure the garbage matches the hardware and also whatever I'm developing doesn't show garbage. I'll consider allowing the user to disable overscan as you described since... yeah it's kinda gross. 4) RIOT/Controller emulation issue(s) - (One-On-One Basketball) This is actually caused by the game not properly initializing the RIOT and relying on the BIOS to do so. If you run the BIOS before hand the game's controls will (magically) work. Ninja Golf has a similar issue where it needs the BIOS to initialize a few things or one of the channels for its title music will be silent. 5) POKEY @450 - missing sound (Donkey Kong PK & Bentley Bear's Crystal Quest are silent) Yeah, BupSystem doesn't officially support this type of cartridge yet. But you can play these games with POKEY sound if you enable XBoard emulation. See Options -> Advanced in HTML Help (Help -> Contents or F1). 6) Official Diagnostic Test ROM failure. Now this one is going to take awhile because it relies on TIA video emulation working, which I'm not ready to dive into yet. I'd like to get Maria 100% right first. Addendum : Looks like I should probably default to "accurate" rather than "fast" . Edited December 17, 2018 by TailChao 4 Quote Link to comment Share on other sites More sharing options...
Trebor Posted December 22, 2018 Share Posted December 22, 2018 Hi TailChao, Forgot to follow-up; thank you for your response here, it served as a jog of my memory. I tried the advice of changing the default emulator settings, modifying Course Rendering off-unchecked and BIOS on-enabled. It creates a flickering scanline glitch under Karateka, on the right side of the screen where the red ground should end, above the enemy's life meter. Coarse Rendering off has no visibly evident impact on the Scrapyard Dog graphic issue. The results are the same as when Coarse Rendering is on. Commando experiences infrequent but noticeable corruption across the last scanline of letters under game difficulty and number of players selection at the title screen. A flash of white is seen. This occurs regardless of BIOS or/and Course Rendering settings. Having the BIOS enabled-on did not fix the issue with One-On-One Basketball. The same no button response in-game remains. A portion of the title screen music is confirmed missing with Ninja Golf, so there may be some sort of disconnect between the BIOS being recognized and utilized despite being present and enabled. It does not matter, the combination of Coarse Rendering being on or off, and whether the BIOS is enabled or disabled, Beef Drop runs incorrectly at a very fast speed. FailSafe has scanline glitching, regardless of settings, at the bottom of the status area towards the top of the screen: Coarse Rendering off-unchecked, it occupies ~1/4 width of the display on the right. Coarse Rendering on-checked, it takes up the entire width of the display. Coarse Rendering off creates scanline corruption between the fuel line and playfield of Scramble, while reverting back to Coarse Rendering on removes it. The tip on enabling POKEY @450 support is appreciated. Unfortunately though, POKEY sound emulation has issues. Donkey Kong PK/XM experiences some of the worst; especially during the "How High Can You Get?" screens. Bentley Bear's Crystal Quest demonstrates an annoying high pitch ring consistently heard while the music is playing. Definitely recommend going with accurate over fast. Without the BIOS present/enabled, the WIP Bullet Festival goes corrupt. From title screen onward into gameplay, all graphics are corrupted throughout the game. Saving a few seconds having the BIOS disabled is not worth misleading and inaccurate results. Quote Link to comment Share on other sites More sharing options...
TailChao Posted December 23, 2018 Author Share Posted December 23, 2018 (edited) Forgot to follow-up; thank you for your response here, it served as a jog of my memory. No problem, thanks for all these tests . Looks like there's definitely something off with Maria's timing, particularly when software sets up a DLI in its first DLL. This I'll need to trace manually and it'll take awhile to confirm what's going on. I do recall Xenophobe in particular is super fussy about the behavior here. The tip on enabling POKEY @450 support is appreciated. Unfortunately though, POKEY sound emulation has issues. Donkey Kong PK/XM experiences some of the worst; especially during the "How High Can You Get?" screens. Bentley Bear's Crystal Quest demonstrates an annoying high pitch ring consistently heard while the music is playing. Yeah, there's definitely lots to do with the POKEY core. Some of the distortion is from aliasing since BupSystem's audio is (as of writing) nearest-neightbor resampled. In particular, Bentley Bear's Crystal Quest sets the frequency registers to an extremely low divisor (and therefore a very high frequency) which averages down and becomes inaudible on the real thing. Definitely recommend going with accurate over fast. Without the BIOS present/enabled, the WIP Bullet Festival goes corrupt. From title screen onward into gameplay, all graphics are corrupted throughout the game. Saving a few seconds having the BIOS disabled is not worth misleading and inaccurate results. Agreed. Addendum : I do want to point out that lots of software relies on the BIOS to initialize registers and memory, far more than I expected. As a developer, I want to make sure I'm not doing this and so in a few cases BupSystem is much less forgiving than the real hardware. I've noticed some titles will function differently when run after the "Atari Rainbow" or Asteroids BIOSes. A user-controlled option to start in a completely scrambled state or with "BIOS Residue" would probably be best. Edited December 23, 2018 by TailChao 2 Quote Link to comment Share on other sites More sharing options...
TailChao Posted January 20, 2019 Author Share Posted January 20, 2019 Hardware safari, here's a scope capture of Maria taking and releasing the bus. HALTn lowers around 28 ticks @ 7.16MHz into each line, slightly after PHI2 has fallen. Sally will still be driving the bus for the first tick of PHI2 and by the second falling edge she'll have given it up to Maria. R/W will stay high whenever Maria has the bus. 5 Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 20, 2019 Share Posted January 20, 2019 Very nice. The 28 MARIA cycles matches the 7 6502 cycles mentioned in the Software Guide. Given how much correcting the guide has needed, it's nice to get confirmation here, and a visual on PHI2. 2 Quote Link to comment Share on other sites More sharing options...
TailChao Posted January 20, 2019 Author Share Posted January 20, 2019 (edited) More safari time, here's the Maria Diagnostic screen in Rikki & Vikki. You can access this by switching the Right Difficulty Switch to the Right and entering R-U-D-D-L-D-U-U on Player 2's Joystick during the PenguiNet Screen. Or at least you'll be able to when the cartridges ship out. There's some notes regarding this in the Compatibility section of BupSystem's HTML Help, but I think they should be duplicated and expanded upon here. ; Because the manual doesn't really say much about how Maria reads from ; $0000 - $17FF and there's some argument as to how long a frame actually is. ; ; Maria Diagnostic ; MSTAT : [VBL] [ACT] [VBIAS] [ABIAS] ; ; [$0000 - $007F] ; [$0080 - $00FF] ; [$1000 - $107F] ; [$1080 - $10FF] ; ; VBL : VBL Line Count ; ACT : Active Line Count ; *VBIAS : MSTAT Alignment in VBL -> Active ; *ABIAS : MSTAT Alignment in Active -> VBL ; ; * Only available in TST_MARIA_EXTENDED. Here's what's going on to get VBL, ACT, VBIAS, and ABIAS : INI_MarDiag: SUBROUTINE ;------------------------------------------------------------------------------- LDA #<USR_MarDiag STA GLO_UserRoutine + LO LDA #>USR_MarDiag STA GLO_UserRoutine + HI LDA #BANK_SUBSYS STA GLO_UserRoutine + BANK ; LDA #0 ; STA TST_MSTAT_VBL ; STA TST_MSTAT_ACT LDA #$FF STA TST_MSTAT_VBIAS STA TST_MSTAT_ABIAS LDA #(CTRL_DMA_OFF | CTRL_CW_2B | CTRL_BC_BLK | CTRL_RM_320BD) STA CTRL .stallActive BIT MSTAT ; Wait through all of active scan... bpl .stallActive .stallVBL BIT MSTAT ; ...and VBL. This way we're ensured to be bmi .stallVBL ; aligned with the first active line. .countActive ; ++++ COUNT ACTIVE SCANLINES ++++ INC TST_MSTAT_ACT STA WSYNC BIT MSTAT bpl .countActive .countVBL ; /\/ COUNT VBL SCANLINES /\/ INC TST_MSTAT_VBL STA WSYNC BIT MSTAT bmi .countVBL #if TST_MARIA_EXTENDED ;--------------------------------------- LDY #0 .alignActive ; ++++ FIND MSTAT ACTIVE -> VBL ALIGNMENT ++++ INY STA WSYNC BIT MSTAT bpl .alignActive_o1 LDA #1 STA TST_MSTAT_ABIAS jmp .doneActive .alignActive_o1 BIT MSTAT bpl .alignActive_o2 LDA #2 STA TST_MSTAT_ABIAS jmp .doneActive .alignActive_o2 BIT MSTAT bpl .alignActive_o3 LDA #3 STA TST_MSTAT_ABIAS jmp .doneActive .alignActive_o3 BIT MSTAT bpl .alignActive_o4 LDA #4 STA TST_MSTAT_ABIAS jmp .doneActive .alignActive_o4 CPY TST_MSTAT_ACT bcc .alignActive .doneActive LDY #0 .alignVBL ; /\/ FIND MSTAT VBL -> ACTIVE ALIGNMENT /\/ INY STA WSYNC BIT MSTAT bmi .alignVBL_o1 LDA #1 STA TST_MSTAT_VBIAS jmp .doneVBL .alignVBL_o1 BIT MSTAT bmi .alignVBL_o2 LDA #2 STA TST_MSTAT_VBIAS jmp .doneVBL .alignVBL_o2 BIT MSTAT bmi .alignVBL_o3 LDA #3 STA TST_MSTAT_VBIAS jmp .doneVBL .alignVBL_o3 BIT MSTAT bmi .alignVBL_o4 LDA #4 STA TST_MSTAT_VBIAS jmp .doneVBL .alignVBL_o4 CPY TST_MSTAT_VBL bcc .alignVBL .doneVBL ;--------------------------------------- #endif ; | ; V .exitStall ; ---- DONE WITH TEST, DISPLAY BACK ON ---- BIT MSTAT bpl .exitStall LDA #(CTRL_DMA_EN | CTRL_CW_2B | CTRL_BC_BLK | CTRL_RM_320BD) STA CTRL LDA #DPAL_BACK ; ---- PALETTE SETUP ---- STA mBACKGRND LDA #$06 STA mP0C1 LDA #$0B STA mP0C2 LDA #DPAL_P0C3 STA mP0C3 rts There's a few interesting things here, in particular we can see noise when Maria reads her own palette registers. It also appears MSTAT's state changes within a scanline rather than at its start or end, which has been nudging me towards the assumption that all Maria's operations and updates are aligned with her DMA start point. Any reads from RIOT or the TIA are pretty chaotic, which does make sense since Maria's access timings are way out of their spec. Very nice. The 28 MARIA cycles matches the 7 6502 cycles mentioned in the Software Guide. Given how much correcting the guide has needed, it's nice to get confirmation here, and a visual on PHI2. A few years ago nichtsnutz posted a logic analyzer capture of the same behavior, but it's good to have the scope version too since the reads of several lines are visually mashed together. Much of GCC's original guide I wouldn't consider wrong, but rather it's not clear about what why the variations in timing are there and what happens with them. For example, the remark about Maria's DMA kicking off 8 Sally cycles into a scanline has some validity since Sally always runs for at least one cycle after HALTn lowers. Addendum : I do want to confirm what's going on with Maria's palette registers, though. The guide says they can be read only in certain addressing modes but I couldn't get stable data out of them in any addressing mode. Edited January 20, 2019 by TailChao 6 Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 20, 2019 Share Posted January 20, 2019 Much of GCC's original guide I wouldn't consider wrong, but rather it's not clear about what why the variations in timing are there and what happens with them. For example, the remark about Maria's DMA kicking off 8 Sally cycles into a scanline has some validity since Sally always runs for at least one cycle after HALTn lowers. Addendum : I do want to confirm what's going on with Maria's palette registers, though. The guide says they can be read only in certain addressing modes but I couldn't get stable data out of them in any addressing mode. I would agree with what you say about the GCC guide. There are bits of context that are missing for a lot of the statements. Reading from the palette registers doesn't work, as you've observed. Atari may have based that on the earlier MARIA design, and never updated it. The GCC guide says explicitly that they're write-only. A while back I updated the online version of the 7800 software guide to match that. 3 Quote Link to comment Share on other sites More sharing options...
TailChao Posted January 21, 2019 Author Share Posted January 21, 2019 Reading from the palette registers doesn't work, as you've observed. Atari may have based that on the earlier MARIA design, and never updated it. The GCC guide says explicitly that they're write-only. A while back I updated the online version of the 7800 software guide to match that.Ah, thanks! I didn't know the GCC guide had a different opinion. Now there's one more thing thing to fix in the next version of BupSystem. 3 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 27, 2019 Share Posted January 27, 2019 Does the emu support a proper debugger? And command line support? Quote Link to comment Share on other sites More sharing options...
TailChao Posted January 27, 2019 Author Share Posted January 27, 2019 Does the emu support a proper debugger? And command line support? Unfortunately, no debugger (yet). Regarding command line support, if you mean loading a cartridge from the command line then yes. The syntax is BupSystem [cartridge] where [cartridge] can be an *.a78, *.cdf, or *.bin file. HTML Help has some more info on each of these formats and their restrictions. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 27, 2019 Share Posted January 27, 2019 Without debugger hard for dev. as I realized that bank switching with mad gone code and stores at 8000-bfff Thanks to a7800 and watchpoints easy to track down. Quote Link to comment Share on other sites More sharing options...
TailChao Posted April 24, 2019 Author Share Posted April 24, 2019 Had some time to look into this again : 4. RIOT/Controller emulation issue(s): One-On-One Basketball - Cannot shoot the ball or call timeouts. No button response in-game... Memory fails me as to why exactly or what, but I remember this impacting what is now the A7800 emulator several years ago. I've confirmed this wasn't caused by my RIOT emulation, but rather the input block and input merging feature. Report 06060 on MAME Testers does cover some of the mischief One-on-One Basketball is doing, but I'd like to expand upon it. Games are expected to do the following initialization procedure before reading input : Write $14 to SWBCNT.This sets both PB2 and PB4 into output mode and allows enabling or disabling transistors Q6 and Q5, respectively. These are part of the stronger pullup section used for driving two-button inputs. Set SWCHB to one of the values below depending upon the current input configuration or requirements.$00 : Both Player 1 and Player 2 are using ProLines.$04 : Player 1 is using a Single Button Joystick, Player 2 is using a ProLine.$10 - Player 1 is using a ProLine, Player 2 is using a Single Button Joystick.$14 - Both Player 1 and Player 2 are using Single Button Joysticks. The state of SWCHB may be altered during play if more elaborate input handling is desired by the software. What's happening here is One-on-One Basketball sets SWBCNT to $14 but never writes anything to SWCHB. As SWCHB's output state after reset is $FF, this leaves transistors Q6 and Q5 off - the game is running in single button mode. It also reads from INPT4 while in the menu but uses INPT0 - 3 when on the court. Basically, the game is relying not only on the default state of SWCHB's outputs - but also on the ProLine's electrical behavior of pulling down INPT4 when INPT0 - 1 are yanked up during a button press when Q6 is off. In short, One-on-One Basketball is extremely lucky that its input works at all. So how does this affect BupSystem? The issue was in its input merging feature - originally BupSystem only allowed the Left Trigger, Right Trigger, and VCS / Single Button Joystick Trigger to be treated as separate inputs as they are in hardware. Later on I added input merging (enabled by default) which makes the Left or Right Triggers register a press on the Single Button Joystick Trigger when Q6 or Q5 are disabled, a little closer to how the ProLine works - but not close enough. If a ProLine is connected to a controller port while its two-button pullup transistor is disabled, pressing the Left or Right Trigger will pull Pin 6 down and raise either Pin 9 or 5 depending upon which button was pressed. BupSystem's input merger was only lowering Pin 6. So if you absolutely must play One-on-One Basketball in the current version of BupSystem, disable input merging ([input] -> merge=n, see Advanced Options in HTML Help) - and please don't write your own 7800 software this way. Quote Link to comment Share on other sites More sharing options...
TailChao Posted April 25, 2019 Author Share Posted April 25, 2019 While the input problems with One-on-One Basketball above weren't caused by an issue with BupSystem's implementation of RIOT... It does not matter, the combination of Coarse Rendering being on or off, and whether the BIOS is enabled or disabled, Beef Drop runs incorrectly at a very fast speed. ...this was! Looks like Beef Drop is using the RIOT's timer for a couple delays and BupSystem's implementation had the down counter stop after the second underflow instead of continuing to decrement. This will be corrected in the next version along with proper implementation of the PA7 edge detection feature. 1 Quote Link to comment Share on other sites More sharing options...
swapd0 Posted April 29, 2019 Share Posted April 29, 2019 Could it be possible to port SOUPER mapper code and BupBoop + CoreTone to a7800 emulator? It's open source and it's avaliable for Linux and Mac... Quote Link to comment Share on other sites More sharing options...
TailChao Posted April 29, 2019 Author Share Posted April 29, 2019 Could it be possible to port SOUPER mapper code and BupBoop + CoreTone to a7800 emulator? It's open source and it's avaliable for Linux and Mac...Sure, but I can't be the one to implement this feature with my current schedule. The *.A78 format will also have to be updated with a new mapper type for SOUPER and specification for where the (optional) audio data is located. Quote Link to comment Share on other sites More sharing options...
TailChao Posted May 25, 2019 Author Share Posted May 25, 2019 Ran into a bit of cartridge confusion, if any other developers skimming this have some insight or opinions it'd be appreciated. SUPER Cartridge - EXFIX Bank @ $4000 - $7FFFIn the current version of BupSystem (0.9.5.4) this is always present and set to the 16KB page before the last. I was adding support for not mapping anything here, for clarity and in case some software wanted to use the XBoard's RAM in this region without bus fights. While updating my *.a78 header parser based upon the development wiki's specification, I noticed most of the ROMs available (including the ones available on AtariAge and in Trebor's most recent pack) don't have this bit tagged properly. For example, Xenophobe has $02 here rather than $12 and it won't boot without the EXFIX Bank mapped in. It looks like this bit was defined way after the initial *.a78 header specification - so should it actually be respected at all? I have no problem assuming an EXFIX Bank is always there for *.a78 files, but would like to be consistent with what others are doing. Absolute and Activision MappersThe available documentation for these is extremely sparse, I've found a few posts around here indicating more thorough reverse engineering was done but no pertinent notes. Does the Absolute mapper actually support selecting anything other than banks $01 or $02 in $4000 - $7FFF? Is it "one indexed" because it's actually using Bit 0 and the page order is inverted? Was the Activision mapper designed for anything other than 128KB games, are there unused address lines? Bla bla bla. If need be I can find two cartridges to reverse engineer but want to confirm this hasn't already been done. Quote Link to comment Share on other sites More sharing options...
RevEng Posted May 29, 2019 Share Posted May 29, 2019 The header bit in question doesn't appear to be implemented in MAME or a7800. I "allocated" that bit based on a request from the person re-implementing the mapper code, but it appears it wasn't used in the end. Generally speaking, MAME and a7800 parse the header bits, but then do a sanity check for the resulting config. Trebor does a good job of ensuring the header bits document the hardware, but this one snuck by him because the ROMs still ran in emulation. In this case, if there's nothing else @4k, like RAM or pokey, I'd enable the ROM bank there. Here are the MAME source notes for Activision mappers. Not sure if it's definitive... Carts with Activision bankswitch: 128K games. 8 x 16K banks (0-7) to be mapped at 0xa000-0xdfff. Bank is selected depending on the address written in 0xff80-0xff87. The rest of the memory is as follows: 0x4000-0x5fff second 8kb of bank 6 0x6000-0x7fff first 8kb of bank 6 0x8000-0x9fff second 8kb of bank 7 0xe000-0xffff first 8kb of bank 7 GAMES: Double Dragon, Rampage. And the same for Absolute... Carts with Absolute bankswitch: 64K games. Lower 32K are 2 banks of 16K to be mapped in 0x4000-0x7fff, depending on the value written at 0x8000. Higher 32K are fixed in 0x8000-0xffff GAMES: F-18 Hornet Quote Link to comment Share on other sites More sharing options...
TailChao Posted May 29, 2019 Author Share Posted May 29, 2019 The header bit in question doesn't appear to be implemented in MAME or a7800. I "allocated" that bit based on a request from the person re-implementing the mapper code, but it appears it wasn't used in the end.Ah, makes sense. Thanks! I'll keep the current *.a78 parsing behavior of putting the EXFIX bank @ $4000 - $7FFF if EXRAM or a Pokey hasn't already been mapped in. If having this area empty is required, the user can write a *.cdf. Here are the MAME source notes for Activision mappers. Not sure if it's definitive...Yeah - there's definitely edge cases missing from both of these, I'll pick up a copy of F-18 Hornet and one of the Activision cartridges to investigate. Should be able to get the Absolute mapper more thoroughly checked by the next version, the Activision one may take longer. 1 Quote Link to comment Share on other sites More sharing options...
TailChao Posted June 15, 2019 Author Share Posted June 15, 2019 (edited) ...and another one. Donkey Kong PK/XM experiences some of the worst; especially during the "How High Can You Get?" screens. Bentley Bear's Crystal Quest demonstrates an annoying high pitch ring consistently heard while the music is playing. This ended up to be an issue with my implementation of channel pairing, among other things. Pokey is currently getting a complete overhaul - and while the next revision probably won't be perfect, so far it's significantly improved. Addendum : A couple new sliders in the Color Adjustments dialog. The YIQ formula still needs to be nudged here and there, but I've refactored most of the render path so that's less of a fuss to deal with later on. Edited June 15, 2019 by TailChao 2 Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted June 18, 2019 Share Posted June 18, 2019 Feature request: ability to make a screenshot using two blended frames. In my Sky Scraper 2115 game demo, I used a graphics page flipping technique to display 10 color per character cell in 160A mode to cut down on DMA usage. This requires flipping between two character fonts every frame, and interlacing to avoid full frame flickering. The ability to make a blended screenshot would be useful here. Quote Link to comment Share on other sites More sharing options...
TailChao Posted June 19, 2019 Author Share Posted June 19, 2019 17 hours ago, Synthpopalooza said: Feature request: ability to make a screenshot using two blended frames. I can add this, but I think it should be part of a display filter rather than a screenshot export mode. This way you'd be able to configure phosphor decay and view the effects without having to take a bunch of screenshots. At the moment refactoring BupSystem's core for long term maintenance and improving accuracy are the priorities, so features like this won't be able to go in until later. But getting more filters in there (especially a CRT filter) has been frequently requested. 1 Quote Link to comment Share on other sites More sharing options...
TailChao Posted August 1, 2019 Author Share Posted August 1, 2019 It's time for BupSystem v0.9.6.0 What's Changed in This Version? Added EMPTY cartridge support. RIOT edge detection on PA7 support. VCS compatible memory map support via INPTCTRL's MEN bit. TIA INPT0 - INPT3 ground path and INPT4 - INPT5 latch support. EXRAM sizing support for 32K and SUPER cartridges. Unmapped $4000 - $7FFF region support for SUPER cartridges. Brightness and Contrast sliders to the Color Dialog. Graphics API (GAPI) abstraction layer and NULL Render Path. Drag 'n Drop loading support for cartridges and snapshots. Upgraded to JoyFish v0.8.6.0. Cleanup Default settings now favor accuracy rather than performance. Disabling EXT only held A15 and A14 low on cartridge accesses rather than A15, A14, and A12. Maria's palette registers aren't readable, no matter which addressing mode you use. Input merging feature now allows the Left or Right Triggers to be read in single button mode, this more closely replicates the behavior of a ProLine controller. RIOT's timer was stopping after its second underflow instead of continuing to decrement. Sally's ABS,X and ABS,Y reads now perform dummy accesses on page boundaries. Sally's ABS,X and ABS,Y writes are now five cycles long and perform dummy accesses, these previously had identical timing to reads. XBoard is now installed by default, but will remain “asleep” until XCTRL is written to. Overhauled Pokey's audio implementation, still not perfect but significantly less bad. Reduced the maximum size of ABSOLUTE cartridges to 64KB. Many of the new, friendlier, features here will be included in Rikki & Vikki’s fall update. So this can be considered a beta or preview of sorts. As usual, more information is available in the included HTML Help file. While Pokey's accuracy has improved, there’s still some issues which I'll address later... Donkey Kong XM (v12) writes $00 to SKCTL (@ $045F), which would place the XBoard's Pokey in a reset state - then never releases it by enabling SKCTL_KEYSCAN and SKCTL_DEBOUNCE ($03). If I ignore this write the audio driver appears to run and make appropriate game noises, but this doesn't line up with the hardware documentation I've read. Bentley Bear's Crystal Quest still has some stray tones in the music, but now they're low pitched. I watched the audio driver and saw long periods where AUDCX == $AV (where V > 0), AUDFX == $00, AUDCTL == $00. This would be inaudible on the hardware as the signal is lowpassed, and might be why the stray bloops are wandering in. I didn’t have time to thoroughly reverse engineer the ABSOLUTE (F-18 Hornet) or ACTIVISION (Double Dragon and Rampage) cartridges. Once I’ve traced either of these back I’ll post the results here. What’s next, or what might be next... The 7800 I’ve used for development is completely ravaged after patching and testing all of Rikki & Vikki‘s cartridges. I’ll be doing repairs on this before proceeding. If anyone has a working cartridge slot to donate it’d be extremely helpful. Reverse engineering the ABSOLUTE and ACTIVISION cartridges will likely be first. Thorough characterization of Maria’s timing and her interaction with Sally is a high priority but will take a significant amount of time. Audio modules need better resampling, most of Pokey’s issues are likely caused by this. Many audio drivers set extremely high frequencies and expect them to be attenuated. Support for more input devices (joysticks, etc) is a given. If you have a controller or adapter which behaves erratically with the software, please let me know. Better disconnected joystick hinting is a planned feature of JoyFish v0.8.6.1 - such that the software will be able to tell which specific device is missing. Right now it can do this with XInput devices, but will have to keep a log for DirectInput ones. 2 Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted August 1, 2019 Share Posted August 1, 2019 I am helping Trebor improve A7800 emulation of POKEY with test examples. That thread may be of help to you too. 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.