Mclaneinc Posted November 3, 2017 Share Posted November 3, 2017 I dunno, seems like it'd be pretty cool if you could remove the Rapidus in real life and still have a 65C816.... Lol.....Yes indeed, and thanks to you those not in real life can have a nice 65C816 any time their heart desires You know me Avery, not trying to influence the emulator, just trying to save people asking how to remove the 65C816 that suddenly is there after having a play around....There's still a lot of people who are menu nervous that are worried about changing stuff. Quote Link to comment Share on other sites More sharing options...
Brentarian Posted November 3, 2017 Share Posted November 3, 2017 Antonia emulation in Altirra would be awesome. 3 Quote Link to comment Share on other sites More sharing options...
drac030 Posted November 3, 2017 Share Posted November 3, 2017 I dunno, seems like it'd be pretty cool if you could remove the Rapidus in real life and still have a 65C816.... Well, it may be difficult to implement in the emulator, but in real life it is a pretty cool extension board: no new motherboard needed, no chips reseated, it just goes into the CPU socket plus you have to add three wires, and that is all. Moreover, the CPU does not get interrupted by Antic, when executing code in FastRAM, so you can f.e. easily have both the display enabled and pretty much undisturbed sample replay, which is not the case on the default Altirra emulation (I mean the 65C816 turbo mode). But, having said that, I must also say that the exact emulation of the Rapidus board is IMHO not really needed unless someone wants to use its very specific features (such as the 16 MB banked SD-RAM). The generic Altirra emulation (65C816 + 21 MHz + 4 MB high RAM) seems in most cases good enough to test programs. Of course, I appreciate the now improved debugger support. 1 Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted November 4, 2017 Share Posted November 4, 2017 I would like to see an emulation of Sophia ... I.e. independently programmable text color in Antic 2, 16 lumas in non GTIA mode, and no Graphics 10 shift. 2 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 4, 2017 Share Posted November 4, 2017 Incognito (v.1) emulation would still be useful... especially for making screen grabs for the BIOS manual. 5 Quote Link to comment Share on other sites More sharing options...
phaeron Posted November 6, 2017 Author Share Posted November 6, 2017 http://www.virtualdub.org/beta/Altirra-2.99-test17.zip http://www.virtualdub.org/beta/Altirra-2.99-test17-src.zip Figured out what Microsoft did with their "fullscreen optimizations" in Windows 10 version 1709 (Fall Creators Update) and got a workaround in so that D3D9 exclusive fullscreen should work again. Needless to say that's a few hours of my life I wish I could get back. Fixed 400/800 mode crash with Rapidus, which is nonsensical but shouldn't crash. CPU mode setting is now split so that the UI option is disabled when Rapidus is active and the original mode is restored when the device is removed. 8 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted November 6, 2017 Share Posted November 6, 2017 Hi Avery, sorry to be a pain but now if you use Rapidus and then remove it you get a crash.. I clearer my settings just in case and it still did it...It also set the machine to XL NTSC when restarted where it was PAL and turned the PAL artifacting off, I presume these are the defaults because it didn't get a chance to save its settings? Using registry (also tried ini just in case) AltirraCrash.zip Quote Link to comment Share on other sites More sharing options...
serj Posted November 6, 2017 Share Posted November 6, 2017 I confirm, an error if to delete from adjustments rapidus. a small request. Avery, please, add an option to settings of the emulator:the window of the emulator is over all windows. Quote Link to comment Share on other sites More sharing options...
phaeron Posted November 7, 2017 Author Share Posted November 7, 2017 Try now: http://www.virtualdub.org/beta/Altirra-2.99-test18.zip http://www.virtualdub.org/beta/Altirra-2.99-test18-src.zip The issue was that pulling Rapidus at the wrong times left the CPU core trying to run '816 microcode on the 6502. This stems from an issue in the device framework with devices not being able to signal that they need the computer power cycled when added or removed, so right now mucking around with the devices causes them to be hotplugged. As usual, no smoke or smells are emulated... but generally not the cleanest experience. I changed the CPU to force a warm reset there so at least the CPU core won't go off into the weeds. Regarding requests: Sophia: Decline, too much of a moving target right now with changes/bugfixes and not documented well. Incognito: Maybe later, have to see whether I have enough docs. The "800 masquerading as XL" is also a PITA to deal with internally. Topmost: Decline for now. 6 Quote Link to comment Share on other sites More sharing options...
Keatah Posted November 7, 2017 Share Posted November 7, 2017 Well dammit! I want some fire and brimstone! Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted November 7, 2017 Share Posted November 7, 2017 Thanks Avery, we do appreciate the non burning carcass of a machine although for an April Fool a touch of emulated smoke etc might be a nice ruse Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted November 7, 2017 Share Posted November 7, 2017 Avery, no crash, all good..Thank you.. Quote Link to comment Share on other sites More sharing options...
drac030 Posted November 7, 2017 Share Posted November 7, 2017 (edited) Enabling Rapidus OS seems to crash in emulation unless you have the same OS flashed to Rapidus and the base machine -- from what I can tell the firmware is trying to do a hot swap of the OS. I must say I do not quite get this comment. The config menu only changes the contents of the EEPROM. Later (in the PBI #0 module) the new settings are applied to the board's registers, and if the OS bit has changed, a cold boot should be forced. Everything that should happen with interrupts disabled, so switching OS-es should not cause any problems. And I have never noticed it did on the real hardware. Edited November 7, 2017 by drac030 Quote Link to comment Share on other sites More sharing options...
+MrFish Posted November 7, 2017 Share Posted November 7, 2017 (edited) I've got a reproducible example now of "Warp Speed" mode getting locked and unchangeable (other than restarting Altirra). In NTSC: 1. boot the attached XEX below 2. hold down F1 until the crash dialogue appears 3. let go of F1 4. from the crash dialogue, select "Restart" After that, Warp Speed will remain active and cannot be turned off. You can select and unselect, and the checkmark will be applied and removed, but no change will happen regarding Warp Speed of emulation. Rampage NTSC.xex Edited November 7, 2017 by MrFish 2 Quote Link to comment Share on other sites More sharing options...
Madi Posted November 7, 2017 Share Posted November 7, 2017 (edited) I've got a reproducible example now of "Warp Speed" mode getting locked and unchangeable (other than restarting Altirra). True. Also, Warp Speed persists even if Altirra is Cold Started, changed memory config, or any option that usually triggers Cold start. The Wrap speed never go away unless Altirra is turned off. madi Edited November 7, 2017 by Madi Quote Link to comment Share on other sites More sharing options...
+MrFish Posted November 7, 2017 Share Posted November 7, 2017 (edited) True. Also, Warp Speed persists even if Altirra is Cold Started, changed memory config, or any option that usually triggers Cold start. The Wrap speed never go away unless Altirra is turned off. Yes, that's what I meant when I said "restarting Altirra", not merely restarting the Atari system/emulation, but quiting and restarting Altirra itself. Edited November 7, 2017 by MrFish 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 7, 2017 Share Posted November 7, 2017 I wonder if having the debugger open 100 per cent of the time makes any difference, since I can't reproduce this. Quote Link to comment Share on other sites More sharing options...
Keatah Posted November 7, 2017 Share Posted November 7, 2017 (edited) I don't have that warp-speed problem. Mostly. While the checkmark in the drop-down doesn't toggle it after doing the procedure in post #341, hitting F1 *will* restore the functionality of the checkmark. No need to restart/reload the emu. I think this has been this way for many versions and isn't anything new. Edited November 7, 2017 by Keatah Quote Link to comment Share on other sites More sharing options...
+MrFish Posted November 7, 2017 Share Posted November 7, 2017 I don't have that warp-speed problem. Mostly. While the checkmark in the drop-down doesn't toggle it after doing the procedure in post #341, hitting F1 *will* restore the functionality of the checkmark. Yeah, you're right; I hadn't checked that. Most times, before, <F1> would also have no effect. But in this particular case it does. The problem exhibited obviously needs to be addressed, though. Quote Link to comment Share on other sites More sharing options...
+MrFish Posted November 8, 2017 Share Posted November 8, 2017 I think this has been this way for many versions and isn't anything new. I mentioned in my first post about the problem that's it's been occurring for quite some time. Quote Link to comment Share on other sites More sharing options...
phaeron Posted November 8, 2017 Author Share Posted November 8, 2017 The F1 key sticking if the window loses focus is a known issue and not one that's hard to recover from. I'm much more interested in the case where you can't recover from that state, as that wouldn't have the same cause. I must say I do not quite get this comment. The config menu only changes the contents of the EEPROM. Later (in the PBI #0 module) the new settings are applied to the board's registers, and if the OS bit has changed, a cold boot should be forced. Everything that should happen with interrupts disabled, so switching OS-es should not cause any problems. And I have never noticed it did on the real hardware. Yes, it shouldn't. What I'm seeing in emulation is the firmware jumping through INTINV to reinitialize the interrupt vectors instead of doing a full cold boot of the OS. I haven't looked into it more deeply to figure out what's going on. Note this quote from the original specification, however (https://bitbucket.org/laoo/ptb/wiki/Memory%20map): The copy of the OS ROM should be identical as installed in the atari as the content of the flash can be instantaneously mapped through MCR to bank 00 in place of the original ROM as the accesses to the FLASH does not incur synchronization to the atari clock and permit the processor to work at much higher speed. I wasn't aware that this requirement had been lifted. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted November 8, 2017 Share Posted November 8, 2017 (edited) Avery, is it me or on version 18 you no longer get crash dialogues..The NTSC rampage should show a crash dialogue when it hits demo round 2 but you visually see its died but no crash dialogue? I've tried LOADS of stuff and there's not been one crash dialogue where I usually got one...By product, it also fixes the F1 warp issue, as its not showing the crash dialogue the speed returns to normal when you let go... No crash dialogue tried with and without warp speeding it... Edited November 8, 2017 by Mclaneinc Quote Link to comment Share on other sites More sharing options...
Madi Posted November 8, 2017 Share Posted November 8, 2017 (edited) Avery, is it me or on version 18 you no longer get crash dialogues..The NTSC rampage should show a crash dialogue when it hits demo round 2 but you visually see its died but no crash dialogue? I've tried LOADS of stuff and there's not been one crash dialogue where I usually got one...By product, it also fixes the F1 warp issue, as its not showing the crash dialogue the speed returns to normal when you let go... No crash dialogue tried with and without warp speeding it... The crash dialogue is still there. (test 18) Be sure that the "Enable Debugger" option is not checked. (the crash dialogue doesn't show if debugger is enabled". Confirmed: The F1 issue is fixed. madi Edited November 8, 2017 by Madi 2 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted November 8, 2017 Share Posted November 8, 2017 Odd, Debugger definitely not enabled...Reset the settings and suddenly got the crash screen back????? Weird... Quote Link to comment Share on other sites More sharing options...
drac030 Posted November 8, 2017 Share Posted November 8, 2017 (edited) Yes, it shouldn't. What I'm seeing in emulation is the firmware jumping through INTINV to reinitialize the interrupt vectors instead of doing a full cold boot of the OS. I haven't looked into it more deeply to figure out what's going on. The exit through INTINV is supposed to occur only when the OS-es have not been swapped, i.e. the corresponding bit in the MCR did not change. By the way, that call does not really "reinitialize interrupt vectors", it just (re)enables the NMI. Note this quote from the original specification, however (https://bitbucket.org/laoo/ptb/wiki/Memory%20map): I wasn't aware that this requirement had been lifted. Technically it is correct, *if* you want hotswapping, you have to keep one ROM to be an exact copy of the other. Because of the way the board works, it would have to be an ordinary 6502 OS (but not XL OS, which is lacking the 65C816 interrupt services).. But as the FastROM is not really that fast (IIRC it does not run at 20 MHz, it is 10 or 6.66 MHz), this is not a very attractive approach. It is much better to have an 65C816 OS in the FastROM, and keep the XL OS as an alternative in the motherboard ROM. Besides, the "original specification" refers mostly to early prototypes. They were lacking the configuration menu, the board was entirely configured using POKEs at SDX CP prompt. One then could think OS hotswapping to be an attractive feature. Edited November 8, 2017 by drac030 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.