Altirra 3.90 released

[Mazzspeed]

1 hour ago, MrFish said:

That must be what I'm thinking about.

 

A certain individual here has a modified ROM that uses keyboard shortcuts to enable/disable DMA. The same individual that believes everyone here runs their A8 with the screen off.

Edited July 25, 2021 by Mazzspeed

[phaeron]

5 hours ago, drac030 said:

Just out of curiosity: when I enable "Fast boot", what do I get over not having enabled it?

Fast boot does two things: it speeds up the memory clear and checksum routines in the OS, and it installs an SIO hook to do an immediate return on access to nonexistent disk and type 3 poll devices. Eliminating both of these days, combined with SIO patch, makes many programs start instantly. You may not have noticed it because there are several ways it which it can be partially or completely disabled: if it can't locate a standard memory clear or checksum routine, or if SIOV is not used for disk access. Booting a custom OS into SDX in particular will show less effect unless OS-level SIO is enabled. It also tends to be a no-op when full disk drive devices are used because the Auto power-on delay will force an additional delay on startup anyway so the drive firmware can init in time.

 

The SIO patch override function forces the first disk access to a drive to bypass the fast boot hook to detect if anything is intercepting the request. It's better to use the PBI device mode when possible since that allows the emulator hook to be properly placed at low priority, but IIRC there were issues with PBI priorities in SDX -- I think PBI.SYS might interpret PBI priorities backwards from the XL/XE OS.

 

[.mad.]

Found a game that crashes in Altirra.

Tusker (Mirage)

crashes when you press START (F2).

 

Could be a bad crack with protection check missed.

If it does not crash on first game start, it will 100% crash after a few goes.

TUSKER - UNPROTECTED.zip

Tusker.xex

[Mclaneinc]

Tried all the images I have and one Xex did go black screen on the playfield but not the status area..

 

Tried the rest numerous times and no problems..

 

Make sure fast boot is off....As for why the other one went black screen, no idea, could be one of those weird ones where it depends on the way the ram is configured..

 

Will keep trying to see it there's a common pointer..

 

The xex I have seems to be the most problematic, but it is a compacted trainer (depending on who did the packing you can get problems there..). Try the one I've put up..

 

Nope, that crashes straight a game over here, boots and plays everytime but the second you lose your life and game over hitting F2 causes a crash..

 

One for Avery (or any other tech heads)

 

Try this one .mad, got past the game over every time so far...

 

Tusker (1993)(Mirage)(PL)[p].atx

 

For Avery etc, the version that kept crashing was Tusker (1993)(Mirage Software)(PL)[cr CSS].atr  crc A9B23F19

Edited July 28, 2021 by Mclaneinc

[+DjayBee]

1 hour ago, Mclaneinc said:

For Avery etc, the version that kept crashing was Tusker (1993)(Mirage Software)(PL)[cr CSS].atr  crc A9B23F19

This is my crack.

I needed several tries until it crashed, even with the protected disk but IMHO this is not a crash of Altirra but a plain crash of the emulated Atari. It fires DLIs while executing DLIs.

Btw.: The annoying music is worth every crash.

 

This is the moment of crash:

Edited July 28, 2021 by DjayBee

[Mclaneinc]

Ha ha...Nice one Djaybee

[oo7]

Is it possible to set up altirra to auto use recommended cart type when loading cart dumps?

[Keatah]

..maybe something like: Using suggested type in 10 seconds unless manually selected otherwise. And of course that feature would be on/off switchable.

 

..or switch to "manual" selection w/infinite wait time till you make a selection once you press the down arrow key to indicate this intention.

Edited July 29, 2021 by Keatah

[oo7]

2 minutes ago, Keatah said:

..maybe something like: Using suggested type in 10 seconds unless manually selected otherwise. And of course that feature would be on/off switchable.

 

That would be nice.

[phaeron]

Sorry, it's intentional that the emulator doesn't attempt to auto-guess. When the heuristic misses and the cartridge type is wrong, the result is usually a crash, but sometimes a more subtle failure like Basic XL locking up on certain commands. I don't want auto-accept in this dialog because then people will blame the emulator whenever the wrong cart mapper is used.

 

 

[oo7]

1 hour ago, phaeron said:

Sorry, it's intentional that the emulator doesn't attempt to auto-guess. When the heuristic misses and the cartridge type is wrong, the result is usually a crash, but sometimes a more subtle failure like Basic XL locking up on certain commands. I don't want auto-accept in this dialog because then people will blame the emulator whenever the wrong cart mapper is used.

 

After reading this post I agree.

 

Thanks very much for the reply.

1 hour ago, phaeron said:

 

 

[Keatah]

Maybe whatever cartridge/rom you're trying to run can be recontainerized or "converted" as in this example. One asks for a mapper, the other one does not.

images.zip

 

..which by the way I'm not sure how the one that doesn't need a mapper selection was made. I'm certain the one that does is just a cart dump. Explanations are welcome.

Edited July 29, 2021 by Keatah

[ilmenit]

11 hours ago, DjayBee said:

This is the moment of crash:

Btw, I just wanted to say that I LOVE the history and general debugging capabilities of Altirra. It's mindblowing how good it is for finding issues and bugs. Recently I did some development for other 8bit platforms and not having Altirra I felt like without an arm.

[oo7]

14 hours ago, Keatah said:

Maybe whatever cartridge/rom you're trying to run can be recontainerized or "converted" as in this example. One asks for a mapper, the other one does not.

images.zip 13.58 kB · 5 downloads

 

..which by the way I'm not sure how the one that doesn't need a mapper selection was made. I'm certain the one that does is just a cart dump. Explanations are welcome.

Wait! I though all cart dumps did this. Am I incorrect?? 

 

Im setting this up for an older person with a little front end and dumps of a handful of carts they owned on original hardware.

 

Using cart dumps to be for sure 100% the same as what they own.

 

In this case its for someone whos 600xl died a few weeks ago, older not very savy with todays computers and trying to give them a way to still enjoy their old titles that they have been playing since the 80s

[+MrFish]

15 hours ago, Keatah said:

Maybe whatever cartridge/rom you're trying to run can be recontainerized or "converted" as in this example. One asks for a mapper, the other one does not.

images.zip 13.58 kB · 6 downloads

 

..which by the way I'm not sure how the one that doesn't need a mapper selection was made. I'm certain the one that does is just a cart dump. Explanations are welcome.

 

The file without an extension is a binary executable in disguise.

 

[oo7]

5 hours ago, MrFish said:

 

The file without an extension is a binary executable in disguise.

 

That is what i thought. An xex.

 

Anyway this being said i was overthinking and asking for an unnecessary feature. I was just trying to make things simple for someone i introduced to this who actually doesnt find it difficult anyway. Its a very old atarian that just lost his system and i was just looking at getting his fave carts running on his home pc. Only step left is atari joysticks to pc for him. I think i will handle that by putting a wireless cbox controller in hid dead xl case and soldering two db9 to it and in place of the joystick ports, he will still have the 600 xl on display it will be his wireless atari joystick adapter.

[Keatah]

6 hours ago, MrFish said:

The file without an extension is a binary executable in disguise.

I'm expert in Apple II file formats and operations. But not Atari 8-bit.

 

But. Is there a way, utility, or procedure, to go back and forth, or one way, between a binary executable and a rom dump like in the zip file examples?

[+MrFish]

5 hours ago, Keatah said:

I'm expert in Apple II file formats and operations. But not Atari 8-bit.

I'm no expert either, but it's obviously not a CAR file because it's too big. A CAR file will be exactly 16 bytes bigger than the corresponding raw ROM/BIN dump -- which is the size of a CAR file header. So, the next best guess is XEX, since an ATR would be much bigger (the file's only 8,320 bytes).

 

5 hours ago, Keatah said:

But. Is there a way, utility, or procedure, to go back and forth, or one way, between a binary executable and a rom dump like in the zip file examples?

Here's the reference doc for the CAR file type; even though it's main point is definition of this file type, it contains info about all the cart types that CAR files reference too; a good place to start.

 

CAR File Format (12-2017).txt

 

Edited July 30, 2021 by MrFish

[vitoco]

Hi!

 

I use Altirra in a Win10 notebook with 2 extra monitors attached, one HDMI and one VGA, so I can span debug windows through all the screens. Nice!

 

I use Altirra's main window in the HDMI screen, but I'm facing a new problem since I added an USB docking unit and attached the HDMI screen to that unit: I get a grey screen instead of the emulated one. If I move the window to another screen, I get the emulated one. If I move the window to a mid point, I can get a working half in one monitor and a grey half in the other.

 

BTW, the debug windows work as usual on every monitor. It is just the main window the one that does not display the emulated screen in that HDMI one through the USB device.

 

[vitoco]

On 7/28/2021 at 11:22 PM, Keatah said:

Maybe whatever cartridge/rom you're trying to run can be recontainerized or "converted" as in this example. One asks for a mapper, the other one does not.

images.zip 13.58 kB · 17 downloads

 

..which by the way I'm not sure how the one that doesn't need a mapper selection was made. I'm certain the one that does is just a cart dump. Explanations are welcome.

The "StarRaiders.bin" file is just 8K of ROM data that it should be loaded at $A000.

 

The "STARRAID" file is a corrupted XEX file that loads the same 8K of ROM data at $6000 of the RAM, then it loads a 52 byte assembler routine at $0600 which moves the data from $6000 to RAM at $8000 and then runs the game. I meant "corrupted" because there is a row of 60 bytes with the value $44 at the end of the file, which it is loaded at $4444 12 times. Fortunately, that memory location it is not used during the load, so the ROM data is not touched.

 

[phaeron]

5 hours ago, vitoco said:

I use Altirra in a Win10 notebook with 2 extra monitors attached, one HDMI and one VGA, so I can span debug windows through all the screens. Nice!

 

I use Altirra's main window in the HDMI screen, but I'm facing a new problem since I added an USB docking unit and attached the HDMI screen to that unit: I get a grey screen instead of the emulated one. If I move the window to another screen, I get the emulated one. If I move the window to a mid point, I can get a working half in one monitor and a grey half in the other.

 

BTW, the debug windows work as usual on every monitor. It is just the main window the one that does not display the emulated screen in that HDMI one through the USB device.

Things get pretty complicated and weird with multi-mon on Windows. The display pane uses optimizations that other panes don't, since it's really really important for that pane to be hardware accelerated.

 

First, for historical reasons Altirra clips Direct3D 9 windows to the monitor that contains the majority of the window so that drawing only occurs to one monitor + adapter. This is to work around some bad behavior that could happen with the 3D present spanning two monitors. The minor issue is an expensive CPU copy of the frame to the second monitor, eating a large part of one CPU core and potentially even dropping <60 fps. The more serious issue is some GPU drivers or hardware actually locking up for seconds at a time on a cross-monitor Present(). A lot of this used to happen with older video cards using XPDM drivers, but there are still quite a lot of bugs I've encountered in newer WDDM-based setups. Because of this clipping, you will see the blank window on the minor monitor covered by the window.

 

Second, things get extra strange with monitors attached to USB docks because frequently those do not actually have a direct connection to the GPU. If the dock connects by USB-C, then it may have a direct video connection. I use a setup like this with Thunderbolt 3 and the external monitors are driven directly by the GPU just like the built-in panel. However, some other USB-C connections, and especially USB 3.0/3.1 connections, are likely to be using DisplayLink instead. These are weird indirect displays that only have a framebuffer and are dependent upon the host GPU for 3D acceleration, copying the frame from the GPU to the DisplayLink adapter. This can do weird things to the display topology and I don't know what the adapter/monitor setup looks like since I don't have one to test against. I wouldn't be surprised if these are exposed to applications in an odd way that prevents Altirra from seeing the 3D acceleration capability. Two things you can try: (1) enable Direct3D 11 in Options, which will also enable use of the newer DXGI infrastructure that is more likely to handle such weirdness, and (2) enable the HOSTDISP logging channel in the debugger (lfe hostdisp) to see if the display layer is running into errors trying to set up 3D acceleration on that monitor+adapter.

 

[vitoco]

11 hours ago, phaeron said:

(1) enable Direct3D 11 in Options, which will also enable use of the newer DXGI infrastructure that is more likely to handle such weirdness

This solved my problem. Thanks!!!

 

[evilmoo]

14 hours ago, phaeron said:

Things get pretty complicated and weird with multi-mon on Windows.

Thank you for taking the time to explain these oddities and nuances.  I really enjoy reading about them.

[massiverobot]

@phaeron - just wanted to say thanks for releasing an ARM verison of Altirra. Works great on Windows10 ARM running in Parallels on MacOSX on M1 ARM chip.

 

 

[+skr]

x64-Version works just well with Wine64, too.