Altirra 2.90 released

[Keatah]

I wonder if toggling the "reuse instance" option would help?

[baktra]

I wonder if toggling the "reuse instance" option would help?

I don't believe so. This option is in effect when Altirra is already running and you try running it again.

 

I would suspect graphics card drivers. When running Altirra for the first time, I would try selecting different graphics API before closing it. Tools/Options/Display. You can begin with deselecting Direct 3D. Then close Altirra and try running it again.

[Kyle22]

Have you updated your graphics card/chip drivers?

 

Do NOT just search for the drivers. You will get plenty of malware sites. If the driver comes from hp.com, dell.com, or a legit site, that's good, but stay away from driverguide.com and places that want to install their own driver tool.

 

I use drp.su with generally good results. Just make sure to select expert mode and UN-select all applications that you don't want.

[Keatah]

If it's on by default, maybe turn it off. The reuse instance..

[phaeron]

I know what's causing the debugger crash and will fix it in the next test release. It's caused by a bug in the command alias handling.

 

Computer hard failing: OS, driver, or hardware issue. Make sure you have all outstanding fixes for XPSP3 installed, and besides graphics drivers, check your sound drivers. It won't be the reuse instance option as that's still entirely in unprivileged code.

[antrykot]

Hi,

I've also encountered a crash in the debugger.

I have a code like this

        org $2000
main
        lda #$66
;##TRACE "a=%02x" (a)
        rts

        run main

So I compile it, load it into Altirra, it is executed, the trace is printed and everything is fine,
but then I go to the disassembly window, click on the highlighted line (the rts instruction at $2002), press F9, and this is what happens:

---------------------------
Altirra Program Failure
---------------------------
A fatal error has occurred in the emulator. A minidump file called AltirraCrash.mdmp has been written for diagnostic purposes.
Exception code: 80000001 PC: 005ab570

 

I am using 32-bit Windows XP SP3.

 

 

Another thing I've found, the NOP zp (opcode $04) takes 4 cycles to execute in the emulator, it should take 3.

Edited October 20, 2017 by antrykot

[baktra]

I know what's causing the debugger crash and will fix it in the next test release. It's caused by a bug in the command alias handling.

 

Computer hard failing: OS, driver, or hardware issue. Make sure you have all outstanding fixes for XPSP3 installed, and besides graphics drivers, check your sound drivers. It won't be the reuse instance option as that's still entirely in unprivileged code.

 

Another possibility would be running the DXDIAG and trying all the tests (sound and graphics) offered. I believe that DX 9 diag still includes the tests.

Edited October 20, 2017 by baktra

[Keatah]

Run memtest.

[phaeron]

http://www.virtualdub.org/beta/Altirra-2.99-test14.zip

http://www.virtualdub.org/beta/Altirra-2.99-test14-src.zip

 

Fixes debugger alias and toggle breakpoint crashes, fixed $04 opcode to be 3 cycles, fixed a DirectSound initialization issue that didn't seem to be causing functional issues but was triggering warnings, fixed an occasional pause in emulation when switching from PAL to NTSC.

 

Compatibility note: if you've upgraded to Windows 10 Fall Creator's Update, full screen mode may fail to work in all versions. From what I can tell, Microsoft broke some methods of doing full screen mode in D3D9 with their "fullscreen optimizations," and I'll have to make some major changes to the display code to work around their breakage. I've verified this on two independent systems, one with an Intel graphics card and another with NVIDIA, so it's not a driver problem. To work around it, either enable D3D11 mode or check the "disable fullscreen optimizations" compatibility option on the program's Compatibility property tab in Explorer.

 

 

 

 

[+DrVenkman]

http://www.virtualdub.org/beta/Altirra-2.99-test14.zip

http://www.virtualdub.org/beta/Altirra-2.99-test14-src.zip

 

Fixes debugger alias and toggle breakpoint crashes, fixed $04 opcode to be 3 cycles, fixed a DirectSound initialization issue that didn't seem to be causing functional issues but was triggering warnings, fixed an occasional pause in emulation when switching from PAL to NTSC.

 

Compatibility note: if you've upgraded to Windows 10 Fall Creator's Update, full screen mode may fail to work in all versions. From what I can tell, Microsoft broke some methods of doing full screen mode in D3D9 with their "fullscreen optimizations," and I'll have to make some major changes to the display code to work around their breakage. I've verified this on two independent systems, one with an Intel graphics card and another with NVIDIA, so it's not a driver problem. To work around it, either enable D3D11 mode or check the "disable fullscreen optimizations" compatibility option on the program's Compatibility property tab in Explorer.

 

 

In both Altirra 2.99-test 13 and -test 14, and using Direct3D 11, full-screen works fine for me on the latest Windows update (Build 17017.rs_prerelease.171010-1400). However, in some prior Windows builds, my combination of hardware (Intel Integrated and GTX1070 graphics), I've had to switch to OpenGL to get things to work properly.

[phaeron]

 

In both Altirra 2.99-test 13 and -test 14, and using Direct3D 11, full-screen works fine for me on the latest Windows update (Build 17017.rs_prerelease.171010-1400). However, in some prior Windows builds, my combination of hardware (Intel Integrated and GTX1070 graphics), I've had to switch to OpenGL to get things to work properly.

 

You're running prerelease Insider builds -- released Fall Creator's Update is 16299.19, while 17017 is from the Insider preview line. All bets are off in that case as I've seen even worse breakage in those builds in the past, such as all windowed-mode presentation being broken, and more recently device clipping not working.

[tschak909]

I got off the Insider train, as it turned my laptop into a lobotomized mess, in slow motion.

 

-Thom

[+wood_jl]

Thank you, phaeron, for your hard work and dedication to our favorite antique computer. Even on weak-ass computers like my Atom-powered netbook, your emulator functions perfectly and A8 games are great!

[xxl]

Fixes debugger alias and toggle breakpoint crashes, fixed $04 opcode to be 3 cycles,

 

 

code $BB - LAS Q,Y not LAS Q

 

in Altirra Hardware Reference page 23

 

unstable codes: wrong mnemonics and adresing: $BB (LAS Q,Y), $9F (SHA Q,Y)

[phaeron]

http://www.virtualdub.org/beta/Altirra-2.99-test15.zip

http://www.virtualdub.org/beta/Altirra-2.99-test15-src.zip

 

Adds preliminary Rapidus emulation. Some caveats:

• The emulator has bootstrap firmware built-in, but it simply boots in 65C816 mode and has no menu support.
• Flashing is supported (SST39SF040, 4K sectors). There are four components to flash: the 6502 New Device firmware, the boot firmware, the core firmware, and the 65C816 OS.
• Speed is approximate. The 65C816 runs at 11x synchronous (19.7MHz) and SDRAM wait states are not emulated.
• Supported hardware features: 6502/65C816 switching, SRAM overlay in bank 0, SRAM write-through, flash OS mapping, page zero mirroring into bank 1, $FF:D000-D7FF mirroring, EEPROM access.
• Not supported hardware features: fast IO cycles, U1MB compatibility mode, fast self test, high fast RAM mirroring, USB serial, SDRAM caching.
• The emulation also requires the 65C816 PBI firmware, which unfortunately is not readily available since it is built into the FPGA core. If you have the 2K image, it has an additional firmware slot.
• The real Rapidus firmware can be used but currently the menu options will not work, for unknown reasons. The most likely reason is the the missing 65C816 PBI firmware; the bootstrap firmware allows the menu to display and the system to boot but it appears that part of the configuration logic is also supposed to be in that firmware.

This involved a fairly heavy rewrite of the memory handling code, so there may be regressions. Other changes:

• C++ compiler updated to VS2017 15.4.2.
• Memory access expressions (db addr) and memory access breakpoints are now supported above bank 0.
• The u (unassemble) command now supports 65C816 M/X/E flag prediction like the Disassembly window and has mode override switches.
• Added bta (set tracepoint on memory access) debugger command to make it easier to trace reads/writes.
• Fixed a bug where held keys wouldn't be recognized immediately in raw key mode when exiting POKEY initialization mode (this affected the inverse key shortcut for entering the Rapidus menu).

 

[a8isa1]

 

Compatibility note:

...full screen mode may fail to work

...To work around it, either enable D3D11 mode

...

 

I just wanted to mention this tip fixed a funky issue I had while running Altirra under wine under the live distro, Knoppix.

 

When using D3D9 mode and trying to select fullscreen mode in Altirra (by pressing ALT+ENTER) the GUI (LXDE I think) goes non-responsive. There's a windowed view of Altirra, without a frame, sitting over the desktop and also a fullscreen view of Altirra. I can ALT+TAB to either one but in neither view does Altirra respond, not to keystrokes or mouse clicks. I can't switch to any other window. I just get bounced back to one of the Altirra views. I have to switch sessions and kill the Altirra process in order to get control back at the GUI.

 

In D3D11 mode everything works as one might expect. I can ALT+ENTER between fullscreen and windowed modes of Altirra.

Edited November 1, 2017 by a8isa1

[Mclaneinc]

Hi, getting a crash if I choose Rapidus and then swap to 400 mode later...Also, a minor niggle, once Rapidus has been enabled it does not mater if you disable it as the CPU will stay as an 816 rather than swap back to a default 6502..

 

Ok for avid users like me to just swap the cpu back but might affect others...Would prefer if it did a reset and a swap back for me though?

 

I imagine the 400 crash is a compatibility issue if the 816 is left on? Must be the 400 does not like Rapidus

AltirraCrash.zip

Edited November 1, 2017 by Mclaneinc

[flashjazzcat]

Also, a minor niggle, once Rapidus has been enabled it does not mater if you disable it as the CPU will stay as an 816 rather than swap back to a default 6502..

 

If I'm reading you right, this accurately reflects real hardware behaviour.

[Mclaneinc]

If I'm reading you right, this accurately reflects real hardware behaviour.

 

Not sure I get it, if under the emulator I disable Rapidus in the devices menu then surely it should turn the XL mode back to a default CPU of a standard XL, instead its holding on to the 816 and the only way to get it back to a basic 6502 is to go to CPU options and change it. Also, if I make a profile for a Rapidus machine and then go to the default profile for an XL it still keeps the 816..

 

Again, its a mere tiny thing but make you adjust more settings to return to a bog standard XL ie it should be treated as a separate machine which for testing purposes is handy to be able to swap machine types fully on the fly.

 

Most folk will boot up a set profile / configuration, because I test and retest I use different machine profiles all the time..

[flashjazzcat]

Yeah I misread you. Reverting the CPU to 6502 in the Rapidus setup menu doesn't get rid of the 65C816 until you power cycle, but I see that this has nothing to do with what you observed in the emulator.

[phaeron]

Yes, the Rapidus emulation code currently changes the main CPU setting. Little bit of polish needed.

 

The real problem is getting the menu options to actually work. As far as I can tell, the current public register documentation is out of date -- there are contradictions between the docs and the actual hardware/firmware, such as the position of the 6502 flash window enable bit. More importantly, the menu has an option for staying in 6502 mode, but the EEPROM that holds that setting isn't read until the computer is already in 65C816 mode and according to the docs the '816 doesn't have access to the FPGA config register to revert back to the 6502. There also isn't any code writing to the MCR/CMCR based on EEPROM settings, though that might be due to the missing '816 PBI firmware. One consequence of this is that the system will boot the '816 on the motherboard OS at 1.79MHz instead of the flash OS at 20MHz.

 

Another issue I noticed is that the version of the 6502 PBI firmware that I had checks for any key being held to bypass the '816 boot instead of a specific key. That makes the menu harder to enter, which requires holding down Inverse after the core load and before the OS invokes the '816 PBI code.

[drac030]

The menu settings are controlled by the PBI #0 module (check PM), without it the configuration will not work.

 

Also, the Rapidus does not really "stay" in the 6502 mode. When the "Classic" mode is selected and the machine is rebooted, the system starts in 65C816 mode first, then (again, by the PBI #0 code) the 65C816 is halted and the 6502 gets a reset signal and is started.

[Mclaneinc]

My comments were not directed at the Rapidus mode, I've no real knowledge of the mod apart from the fact its an accelerator that swaps the 6502 at 1.79 to a 65C816 at around 20mhz, all my point was that if I then decide not to use the Rapidus and just want a normal XL / XE, that the 65C816 remains enabled. Again, this isn't me trying to swap it out INSIDE the Rapidus emulation, I'm talking about the Rapidus device totally removed / disabled via the devices menu and it still leaving the 65C816 enabled which is not what an unmodded XL has...I repeat, I'm not trying to disable the faster CPU within Rapidus mode, I'm talking about the XL emulation reverting to a standard XL when the Rapidus is removed inside Altirra and reverting the machine back to a vanilla machine.

 

I just think that when you remove the Rapidus from the emulated hardware it should reset back to a bog standard 6502 at the normal speed as part of the disabling..

 

Think of it this way, imagine I have real hardware and purchased the Rapidus, installed it, played with it and found for some reason I didn't like it. I then remove the whole mod, change the XL back to factory condition with the stock CPU just like it was before I put the rapidus in, that's where altirra is not doing it as you would imagine if you removed the mod, the emulation still boots up with the 65C816 enabled as if you had not uninstalled the mod.

 

Its a minor niggle that seems to have caused a little confusion

Edited November 2, 2017 by Mclaneinc

[flashjazzcat]

Also, the Rapidus does not really "stay" in the 6502 mode. When the "Classic" mode is selected and the machine is rebooted, the system starts in 65C816 mode first, then (again, by the PBI #0 code) the 65C816 is halted and the 6502 gets a reset signal and is started.

This makes sense, and explains the odd CPU frequency result in the U1MB BIOS (which tests the CPU before the OS initialises PBI #0). Sending the GND connection on the 3-way header high (thereby turning off PBI device 0) still necessitates a power cycle before things return to normal, as I recall.

[phaeron]

I dunno, seems like it'd be pretty cool if you could remove the Rapidus in real life and still have a 65C816....

 

Update:

http://www.virtualdub.org/beta/Altirra-2.99-test16.zip

http://www.virtualdub.org/beta/Altirra-2.99-test16-src.zip

 

• Implemented two undocumented registers needed for the 6502C and SDRAM 4K options to work (though the latter has no effect). Note that all of the menu options are still unoperational unless you have the firmware dump of the 16-bit PBI ROM, until I figure out a solution for the bootstrap one. Pulling it out of the FPGA core isn't really an option....
• Fixed Rapidus flash residing on the chip bus instead of the fast bus.... though that may be too fast, if I'm reading the specs on the flash chip correctly.
• Fixed bugs with the page 0 mirroring option which could cause a crash if you did enough cold resets with it on.
• Fixed several bugs with bogus symbol decoding in disassembly above bank 0, notably JMP/JSR instructions still showing bank 0 OS symbols and other indirect jumps using the wrong banks (0/PBK/DBK depending on addressing mode).
• Unassemble (u) command now decodes symbols by default like the Disassembly pane unless -n is specified.
• Added some support for having debug symbols in bank 1+.
• Added an explicit Copy menu command to the console log window. Never minded its absence since I always use Ctrl+C instead. That keyboard shortcut also works in the disassembly view, but I couldn't trivially add a menu option there due to the way that the right-click currently clears the selection.

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. CPU mode staying stuck is not fixed yet.