Jump to content
IGNORED

Altirra 2.90 released


phaeron

Recommended Posts

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

 

  • Like 8
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.
  • Like 6
Link to comment
Share on other sites

 

 

 

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 by drac030
Link to comment
Share on other sites

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 by MrFish
  • Like 2
Link to comment
Share on other sites

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 by Madi
Link to comment
Share on other sites

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 by MrFish
  • Like 1
Link to comment
Share on other sites

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 by Keatah
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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 by Mclaneinc
Link to comment
Share on other sites

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 by Madi
  • Like 2
Link to comment
Share on other sites

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 by drac030
  • Like 1
Link to comment
Share on other sites

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

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

×   Your previous content has been restored.   Clear editor

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

Loading...
  • Recently Browsing   0 members

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