TailChao Posted April 10, 2020 Author Share Posted April 10, 2020 (edited) Meanwhile, in other hardware configurations not used by the commercial library - EXRAM is now supported for 32KB cartridges in both A78 and CDF format. In previous implementations only EXRAM/A8 (used by 'Rescue on Fractalus') was allowed for this cartridge type. As with BupSystem's SUPER implementation - declaring your software in a CDF allows specifying the EXRAM size from 2KB - 16KB while A78's are always assumed to have the full 16KB. This at least allows @PacManPlus's old Defender demo to load albeit with a bunch of garbage in overscan. Addendum : Does any other software use this configuration, or is Defender the only one? Edited April 10, 2020 by TailChao Quote Link to comment Share on other sites More sharing options...
PacManPlus Posted April 11, 2020 Share Posted April 11, 2020 Wow. I need to revisit that. I use $6000-$7FFF for RAM... Is that screenshot PAL? If so, then it's not detecting the number of PAL scan lines correctly. (It's supposed to auto-detect) Anyway, at this point I think when I do go back to it, I may restart it - as I want to use 320B mode for the entire game. Quote Link to comment Share on other sites More sharing options...
TailChao Posted April 11, 2020 Author Share Posted April 11, 2020 16 minutes ago, PacManPlus said: Wow. I need to revisit that. I use $6000-$7FFF for RAM... Is that screenshot PAL? If so, then it's not detecting the number of PAL scan lines correctly. (It's supposed to auto-detect) Nope, that's NTSC. I investigated a little more this morning and found the game would run properly if all RAM (both in the cartridge and console) was initialized to zero. However, it wouldn't run at all if the NTSC (Atari Rainbow) BIOS was executed first. Using the PAL (Asteroids) BIOS would result in the game starting, but still with garbage. I'm not sure why the NTSC BIOS execution handoff isn't working, but there's definitely an initialization problem here. Quote Link to comment Share on other sites More sharing options...
+Mitch Posted April 11, 2020 Share Posted April 11, 2020 I don't think the game has a proper signature, so it doesn't work with the standard NTSC BIOS. Mitch Quote Link to comment Share on other sites More sharing options...
TailChao Posted April 11, 2020 Author Share Posted April 11, 2020 10 minutes ago, Mitch said: I don't think the game has a proper signature, so it doesn't work with the standard NTSC BIOS. Bruce Tomlin's 7800sign agrees with you, so another mystery solved. Quote Link to comment Share on other sites More sharing options...
PacManPlus Posted April 11, 2020 Share Posted April 11, 2020 (edited) 2 hours ago, TailChao said: Nope, that's NTSC. I investigated a little more this morning and found the game would run properly if all RAM (both in the cartridge and console) was initialized to zero. That's weird, as I have a routine that I put in every game that zeros out RAM before I even do anything else.... EDIT - I just realized that I put the DL & DLL in the $6000 area RAM in this game only... which doesn't get zeroed out... makes sense now. Edited April 11, 2020 by PacManPlus Quote Link to comment Share on other sites More sharing options...
TailChao Posted April 12, 2020 Author Share Posted April 12, 2020 17 hours ago, PacManPlus said: I just realized that I put the DL & DLL in the $6000 area RAM in this game only... which doesn't get zeroed out... makes sense now. Okay, good to confirm it. This is one of the reasons I'd like to get configurable RAM reset patterns in there eventually. As of writing it's fixed to a very rude pattern which may be familiar to 3DO programmers - but allowing for all zero, all high, or something which approximates the hardware would be nice. In other news, I've implemented everything in the most recent PMC1 feature set aside from the actual SPI devices which can be connected to it. The BupChip commands have also been added and are slightly changed from SOUPER's to allow for 128 music tracks instead of 32. Depending upon how thoroughly this gets vetted prior to release it may be a "secret feature" but it's at least included. Quote Link to comment Share on other sites More sharing options...
TailChao Posted April 20, 2020 Author Share Posted April 20, 2020 The "eventually whenever" feature of supporting all SOUPER variants (SOUPER, SUBPAR, and SUBLET) found its "whenever" last Saturday. Both SOUPER and SUBPAR are pretty close to what was already implemented in 0.9.6.1, but SUBLET's flash programming features are all there - and it has an SST39SF040 attached! Which means... ...this is the first time I've seen the FoxBIOS (manufacturing test program) update an R12 build of Rikki & Vikki to R14 on Windows. Any cartridge which has a Flash ROM attached won't push written changes to the ROM upon removal of the cartridge or closure of the program, this is intended to protect the original data. However, the changes will be pushed in save states. When I add support for EEPROM or NVRAM devices in the next whenever, these will have their contents pushed to disk. 3 Quote Link to comment Share on other sites More sharing options...
TailChao Posted April 26, 2020 Author Share Posted April 26, 2020 Cross posting from twitter-twatter, but draft PMC1 support is all set for v0.9.6.2 - including some SPI Devices. As noted previously, this may remain a secret feature if I don't verify everything in hardware prior to release. But this is also the last new feature I wanted to include. You'll be able to instantiate a PMC1 cartridge by writing a CDF, here's an example with two SPI Devices attached... ProSystem ; Platform PMC1 ; Mapper THE 100 MEGA SHOCK ; Title Primary.bin ; Binary SPI DEVICE (S25FL128P) ; SPI Device A Resources.bin ; Secondary Flash ROM SPI DEVICE (M95512) ; SPI Device B Save.eep ; EEPROM Save Data CORETONE ; Uses BupChip Samples.smp ; Sample Package Macros.ins ; Instrument Set Track_0.mus ; Music Tracks Track_1.mus ; | ... ; V The Primary ROM on all PMC1 cartridges is assumed to be an AS29CF160T, you can unlock and write to this but the changes won't be pushed to the original file. SPI Device support is limited to the S25FL128P (16MB Flash) and M95512 (64KB EEPROM), you can attach them however you like in the two device slots as shown above. Devices are always attached in incrementing slots (A, B, ...). Using the SPI DEVICE (EMPTY) keyword will leave a slot open - and both can be left unoccupied by leaving out the SPI DEVICE definitions. Same for CORETONE, it can be excluded if unused - as in SOUPER cartridges. Going to take a break for awhile before packing this version up, but it's nice to have all the additions checked off. Quote Link to comment Share on other sites More sharing options...
TailChao Posted May 2, 2020 Author Share Posted May 2, 2020 (edited) Oh hey, it's BupSystem v0.9.6.2 What's new in this version? Added Upgraded to Visual C++ 6.0 SP5 + Processor Pack. Optimization now favors Pentium Pro. EXRAM support for 32K cartridges. SUBPAR and SUBLET variants of SOUPER cartridges. SST39SF040 (512KB NOR Flash) for SUBLET cartridges. Cartridge type guessing when loading Binary Files (*.bin). Sorted history of recently played cartridges and persistent file filters. Execution pause, resume, and frame step. Menu item icons. Cleanup Sally's clock multiplier was accidentally grouped with save state data. Rendering is now skipped when a cartridge isn't running. Moved console region selection into its own menu. Changed default cartridge format to Atari 7800 File (*.a78). Most improvements were in the interface or under the hood, getting Flash ROM (!) support in there is a big deal and there were several other alterations pertaining to long term maintenance and simplifying new mapper development. The Visual C++ 6.0 SP5 + Processor Pack upgrade was quite nice, despite the executable growing by several tens of kilobytes (oh my!) it actually runs faster - did exactly what it said on the tin. Draft PMC1 support is included (basically everything from the previous posts), but as of writing isn't documented - I'd like to wait until the hardware has been verified and released before "formally" adding it. But you're welcome to give it a try! What's next? I'd like to finish PMC1 support by the end of this year, then go back to analyzing Maria's timing and try and get this downpat and thoroughly documented. The two actually go together well since the PMC1 is designed to be more observant of Maria's bus activity than SOUPER was. As of writing, most of my reverse engineering efforts are going towards other hardware. Everything else, sometime whenever later... no idea... bla bla. Edited May 2, 2020 by TailChao 7 Quote Link to comment Share on other sites More sharing options...
TailChao Posted May 7, 2020 Author Share Posted May 7, 2020 ...and what would new features be without new mistakes. Just found out I was drawing the menu item icons out of spec, which worked for classic Windows but resulted in broken alpha on anything which supports Aero and has it enabled (Vista+). So I'm gonna toss together two sets of icons for both scenarios (you can even be extremely rude and change it while BupSystem is running). If you do heavy customization of your Windows themes or use a really crazy DPI setting the icons may be disabled to prevent distortion of the images. Also added some more warning prompts before erasing the cartridge history, etc. Thought I was gonna get to take like a year off from wedge development, but I'll try and put together a new build for 6/5/2020. As usual, any other reports (especially for the interface) would be appreciated. 4 Quote Link to comment Share on other sites More sharing options...
AW127 Posted May 10, 2020 Share Posted May 10, 2020 (edited) Tested around for one hour today with version 0.9.6.2 and so far, everything seems to work great. I have some questions/suggestions. Not sure if they can be realized technically but i want to ask at least. (1) would it be technically feasible, that "BupSystem" identifies a game-rom in the moment it loads, if it's PAL or NTSC and then switches automatically in the correct console-type (NTSC/PAL) without that the user must do anything? (2) and would it be, additionally to point (1), also feasible, that "BupSystem" then also switches in two different fullscreen-videomodes, depending if its a PAL or a NTSC rom? And these fullscreen-resolutions, the user had chosen before in the emulator-menue. I ask because of that - some users have a monitor which can handle 50Hz modes (for example my "BenQ BL912" flatscreen monitor can) and such a 50Hz mode is ideal for PAL games, cause the run with 50FPS and then the scrolling looks very smooth in games which scrolls. And for NTSC games a standard 60Hz fullscreen-mode is ideal, cause they run with 60FPS. Superb would be, if "BupSystem" would have a video-menue, in which the user could assign a fullscreen-resolution together with a Hz-value for using with PAL-games (for example 720x576 - 50Hz) and a fullscreen-resolution together with Hz-value for using with NTSC-games (for example 1280x1024 - 60Hz). The emulator could show different choosable fullscreen-resolutions (together with the Hz-values) in a list and the user can choose one for PAL-roms and one for NTSC-roms. When now a user loads a PAL-rom of a game in BupSystem, the emulator should automatically switch to the correct console-speed (50Hz) and when the user then switches to fullscreen, "Bupsystem" should automatically use, what the user has assigned before in video-menue, like for example "720x576 - 50Hz" as the fullscreen-resolution for this PAL-rom. Same thing when a NTSC-rom is loaded, then the emulator should automatically choose the NTSC console-speed (60Hz) and for fullscreen then the resolution 1280x1024 - 60Hz (or whatever the user has set before for NTSC-roms in the video-menue of the emulator). And when users don't have a monitor that can do 50Hz, then it's also not a problem, cause they can choose for example a 75Hz or 60Hz fullscreen-mode for PAL-roms too then. The only disadvantage those users then would have is, that in games that scrolls, this scrolling then is not as smooth as in a 50Hz fullscreen-mode, but speed runs correct anyway, cause BupSystem has chosen the correct console-type before. In games which dont scroll at all, the difference is only minimal anyway. What you think about these two points, "TailChao"? At the moment, "BupSystem" always uses exactly that resolution and Hz-value for the fullscreen, which the user had chosen in his Windows, in the moment, before starting the emulator. By default the most users will have some kind of resolution with 60Hz and "BupSystem" then also uses this 60Hz for his fullscreen-mode. Perfect for NTSC games, not really perfect for PAL games. Therefore i make it this way since some months - when i know before, that i want to play a PAL game in BupSystem, i switch to a 50Hz resolution before in my Windows and only then start the emulator. Then i have a 50Hz fullscreen-mode in the emulator too for this game. For easy and fast switching from 60Hz to 50Hz and back in Windows, i have made me two links with icons in the Windows-taskbar for which i use the tool NirCMD. It's a commandline-tool and you can make commandos in these links like for example "nircmdc.exe setdisplay 1280 1024 32 60" in the 60Hz icon and "nircmdc.exe setdisplay 1280 1024 32 50" in the 50Hz icon. Then only one mouse-click on my 50Hz icon in the taskbar switches to "1280x1024 - 50Hz" resolution and one mouse-click on my 60Hz icon switches back to "1280x1024 - 60Hz" resolution in Windows. I have alot emulators of various retro-systems on my PC and i use these two icons often for those emulators, which allows not directly in their emu-menue, to assign fullscreen-resolutions together with Hz-values and use always that resolution+Hz-value instead, in which Windows operating-system run in the moment. I can even switch the Hz now, when an emulator is running in window-mode and when switching to fullscreen then again, the emulator takes the new Hz, to which i had switched before in Windows with one of my two NirCMD-taskbar-icons. So, even though this works good, of course the best thing would be, if any emulator could do this by it's own. Therefore my two suggestions and the question, if you think, that something like this, is technically feasible for BupSystem or not? Would be great. Edited May 10, 2020 by AW127 Quote Link to comment Share on other sites More sharing options...
TailChao Posted May 10, 2020 Author Share Posted May 10, 2020 7 hours ago, AW127 said: (1) would it be technically feasible, that "BupSystem" identifies a game-rom in the moment it loads, if it's PAL or NTSC and then switches automatically in the correct console-type (NTSC/PAL) without that the user must do anything? This is feasible, but is in the same category as overscan where I'm only going to add the behavior when it's fully user configurable. So I can't nudge this into 0.9.6.3 but it will be added to the first post's grocery list. Whenever the advanced options dialog shows up it'll be in there - with the asterisk that only *.a78 format cartridges will support automatic region selection. 7 hours ago, AW127 said: (2) and would it be, additionally to point (1), also feasible, that "BupSystem" then also switches in two different fullscreen-videomodes, depending if its a PAL or a NTSC rom? And these fullscreen-resolutions, the user had chosen before in the emulator-menue. I ask because of that - some users have a monitor which can handle 50Hz modes (for example my "BenQ BL912" flatscreen monitor can) and such a 50Hz mode is ideal for PAL games, cause the run with 50FPS and then the scrolling looks very smooth in games which scrolls. And for NTSC games a standard 60Hz fullscreen-mode is ideal, cause they run with 60FPS. Ah, you mean different Full Screen Exclusive modes. The requirement for these has (mostly) been eliminated through things like NVIDIA's G-Sync, which now supports Borderless Windowed programs like BupSystem. I'll confirm it actually syncs for PAL / 50Hz when I have access to a friend's (better) PC next weekend - we tested it in NTSC / 60Hz and it works great. Quote Link to comment Share on other sites More sharing options...
AW127 Posted May 10, 2020 Share Posted May 10, 2020 (edited) 7 hours ago, TailChao said: This is feasible, but is in the same category as overscan where I'm only going to add the behavior when it's fully user configurable. So I can't nudge this into 0.9.6.3 but it will be added to the first post's grocery list. Whenever the advanced options dialog shows up it'll be in there - with the asterisk that only *.a78 format cartridges will support automatic region selection. Ah, okay. But it sounds like there is a chance that this will probably come one day. Would definitely be great . 7 hours ago, TailChao said: Ah, you mean different Full Screen Exclusive modes. Exactly. 7 hours ago, TailChao said: The requirement for these has (mostly) been eliminated through things like NVIDIA's G-Sync, which now supports Borderless Windowed programs like BupSystem. I'll confirm it actually syncs for PAL / 50Hz when I have access to a friend's (better) PC next weekend - we tested it in NTSC / 60Hz and it works great. My experience is that by far not all people have a monitor which has G-Sync or Free-Sync and especially for those users, it is great, when an emulator offers the possibility, to choose a resolution plus a Hz-value to it directly in the emu-menue. Nothing would be lost for users with G-Sync monitors, when additionally, such a "choose fullscreen-resolution" function would be included in a new video-menue in "BupSystem". I like those functions alot and find them senseful. The user assigns one time a resolution+Hz for PAL-roms and one time for NTSC-roms and "BupSystem" then should use these two fullscreen-modes then in the future. And when a user don't assign resolutions in these new fields, then "BupSystem" should handle it like it does in the past. This then is the mode for users of G-Sync monitors, they simply don't need to assign resolutions then in the video-settings and then BupSystem handles it like it does always. For those users nothing would change at all. What you think about it? It would be better for users without a G-Sync compatible monitor, than always switching the Hz-value in Windows, before starting "BupSystem", even when my two mentioned NirCMD-links in the taskbar makes theHz-switching much easier than going all the time into the monitor-settings of Windows and change the Hz-value there. But when "BupSystem" could do it by his own, it would be even better. Edited May 10, 2020 by AW127 Quote Link to comment Share on other sites More sharing options...
TailChao Posted May 11, 2020 Author Share Posted May 11, 2020 16 hours ago, AW127 said: Ah, okay. But it sounds like there is a chance that this will probably come one day. Would definitely be great . That's going to be the case with most improvements or new features. I'd like for most requests to go in - as long as they don't conflict with what's already there and (in this case) be configurable. It's really a question of when. 16 hours ago, AW127 said: What you think about it? It would be better for users without a G-Sync compatible monitor, than always switching the Hz-value in Windows, before starting "BupSystem", even when my two mentioned NirCMD-links in the taskbar makes theHz-switching much easier than going all the time into the monitor-settings of Windows and change the Hz-value there. But when "BupSystem" could do it by his own, it would be even better. I'll look into it, since having this as part of my render library would be nice. But it's a low priority. I did get the autohiding menu in Full Screen Mode working as part of 0.9.6.3, which would be a prerequisite for this feature. 1 Quote Link to comment Share on other sites More sharing options...
TailChao Posted May 27, 2020 Author Share Posted May 27, 2020 Oh hey, it's BupSystem v0.9.6.3 "But wait, I thought you said this wasn't going to be released until 6/5?!" you shriek, or fervently type. "Software can only be late, what is this nonsense?!" Ah, well for one I ran out of small things I wanted to patch. The second reason is that today marks four years since BupSystem's first (albeit secret at the time) release - so let's celebrate by pushing this build now. Anyway... What's new in this version? Added Separate menu item icons for Aero themes. Support for using the menu in Full Screen Mode. Optional confirmation when erasing the cartridge history. Multiple file support for Drag 'n Drop. Cleanup All menu item icons redrawn in monochrome. Custom images are a little more considerate of system metrics. Disabled menu items could still be triggered in Full Screen Mode using their accelerator keys. Adjustments in the Color Dialog are now shown whether or not a cartridge is loaded. Disabled mouse cursor autohiding while the Color Dialog is visible. Corrected longstanding GDI Resource leaks in the Input and Joystick Disconnected Dialogs. While there's still a long way to go in terms of accuracy and other improvements, I feel what's here is enough to justify a long hiatus from the platform. 5 Quote Link to comment Share on other sites More sharing options...
TailChao Posted September 29, 2020 Author Share Posted September 29, 2020 There's a palette caching issue in v0.9.6.3 - changing the console region between PAL and NTSC won't force a palette recalculation, as observed by @Turbo Laser Lynx. A temporary workaround is to open the Color Dialog by navigating to Options -> Maria (Video) -> Adjust Color... (F4) and clicking [Default] or twiddling with the sliders. Restarting the program will also force the palette to be recalculated. 5 Quote Link to comment Share on other sites More sharing options...
+TwentySixHundred Posted October 16, 2020 Share Posted October 16, 2020 Thanks i had been using A7800 for awhile now. However i have heard/read alot of good things about Bup and noticed it has recent updates. From what i hear it's fairly on par with A7800 in terms of accuracy ? Works great with my homebrew and is nice that pokey is supported especially with bankswitched ROMs (helps motivation with testing one my older projects). Thanks for the continues development of Bup and im looking forward to future releases ? Quote Link to comment Share on other sites More sharing options...
TailChao Posted October 17, 2020 Author Share Posted October 17, 2020 Hah, well I dunno if five months ago counts as a 'recent' update but I'm glad you're enjoying it. I do want to be clear that BupSystem's development is still on hiatus, so I'm still keeping track of any issues noticed in v0.9.6.3 but they're not necessarily going to be addressed soon... possibly never. Regarding accuracy - some of Maria's timing stuff is definitely off and so is a bunch of POKEY's behavior. I'd definitely recommend sticking with A7800 if you're doing anything serious with POKEY or the XM's features. The only things BupSystem "leads" in are support for SOUPER, PMC1, and the BupChip. 1 Quote Link to comment Share on other sites More sharing options...
+TwentySixHundred Posted October 17, 2020 Share Posted October 17, 2020 Ah ok i see, yeah i usually like to use a couple accurate emulators in a rolling dev stage. A7800 is great and i feel friendly competition among authors drives for more accurate emulation. The GUI's ease of use reminds me of other standalone emulators such as Fusion ect. It's all good whatever direction you take. I will be keeping an eye out as to where this project leads ? Quote Link to comment Share on other sites More sharing options...
legolas119 Posted October 17, 2020 Share Posted October 17, 2020 Hi all, i just discovered this emulator and i want to use it to discover atari 7800 games. But unfortunately if i try every rom, i always have this issue: does I need the bios? If so, i downloaded the pal and NTSC bios file but i don't know which is the right folder where I have to put them... thank you! Quote Link to comment Share on other sites More sharing options...
TailChao Posted October 18, 2020 Author Share Posted October 18, 2020 22 hours ago, TwentySixHundred said: The GUI's ease of use reminds me of other standalone emulators such as Fusion ect. Yeah, that sort of setup has always been my preference. Adding in luxurious debugging features like nocash's work would be ideal, but no idea if that'll ever happen. 19 hours ago, legolas119 said: i just discovered this emulator and i want to use it to discover atari 7800 games. But unfortunately if i try every rom, i always have this issue: does I need the bios? If so, i downloaded the pal and NTSC bios file but i don't know which is the right folder where I have to put them... This seems to have already been addressed here, and (generally) I cannot help you find ROMs - you're all on your own for that. However, I do want to point out that many "goodsets" for the 7800 aren't actually that good. Faulty headers, missing Pokey bits, etc. The PROPack by @Trebor is properly curated and checked - if that doesn't work then it's definitely my fault! 3 Quote Link to comment Share on other sites More sharing options...
Cyprian Posted December 17, 2020 Share Posted December 17, 2020 (edited) I've just found that a nice emulator. Would be possible to add an option for screen scan-lines? Edited December 17, 2020 by Cyprian_K Quote Link to comment Share on other sites More sharing options...
AW127 Posted December 17, 2020 Share Posted December 17, 2020 Just now, Cyprian_K said: I've just found that a nice emulator. Would be possible to add an option for screen scan-lines? I've just found that a nice emulator. Would be possible to add an option for screen scan-lines? Not a bad idea. Not a bad idea. Quote Link to comment Share on other sites More sharing options...
Cyprian Posted December 17, 2020 Share Posted December 17, 2020 @AW127 hehe, AA forum did me a trick ( I wasn't logged in when I posted it) And also would be cool to have build in debugger. 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.