Altirra 4.10 released

[phaeron]

22 minutes ago, fox said:

Can Altirra emulate the PAL color delay line? Numen looks washed out of colors.

If you look closely at an APAC or TIP picture on a CRT screen, the "gray" GRAPHICS 9 lines are not displayed as gray, but are colored from the GRAPHICS 11 line above.

Yes, the PAL delay line is emulated. It isn't always enabled for PAL systems, you need to enable one of the PAL artifacting modes.

[woj]

I guess the default answer to the following question is no, but I need to ask nevertheless - is there a simple way (one byte / bit look up, for example) to detect that my program is running on Altirra rather than on the real hardware?

[phaeron]

1 hour ago, woj said:

I guess the default answer to the following question is no, but I need to ask nevertheless - is there a simple way (one byte / bit look up, for example) to detect that my program is running on Altirra rather than on the real hardware?

Nope, as you've guessed, Altirra deliberately doesn't do this by default -- because a reliably detectable difference is a bug.

[oo7]

Is there a setting for setting file>boot image to always open the same specific path?

 

i seem to think there was but cant find it.

 

 

[phaeron]

14 hours ago, oo7 said:

Is there a setting for setting file>boot image to always open the same specific path?

 

i seem to think there was but cant find it.

Don't think so, the behavior is hardcoded.

 

Altirra overrides the default behavior of the OS file dialog: it simply opens to the last path used for that command. Many paths leading to a file dialog have a unique tag, but a few of them use a shared tag for common requests like "select disk image". The part that's overridden and disabled is the default behavior to automatically switch to Documents if there isn't a file with a matching type in the current directory, which is annoying.

 

[oo7]

10 minutes ago, phaeron said:

Don't think so, the behavior is hardcoded.

 

Altirra overrides the default behavior of the OS file dialog: it simply opens to the last path used for that command. Many paths leading to a file dialog have a unique tag, but a few of them use a shared tag for common requests like "select disk image". The part that's overridden and disabled is the default behavior to automatically switch to Documents if there isn't a file with a matching type in the current directory, which is annoying.

 

Would it be possible that one day you maybe include the option to allow to set boot image to a specific path?

 

 

 

[jenorton]

Doesn't Altirra boot the last booted image on startup, or, couldn't you make a shortcut or batch that would refference the image you want?

[jenorton]

Wouldn't it be possible to detect the custom OS that comes with Altirra?  It wouldn't be a fool-proof way to detect Altirra, but, I don't know how that would work.

[oo7]

5 hours ago, jenorton said:

Doesn't Altirra boot the last booted image on startup, or, couldn't you make a shortcut or batch that would refference the image you want?

I want it to be able to poubt to a specific path each time you select boot image rather than last path. To be. Specific I want this feature not for me but for someone else really. Just thought ide ask in case it was pissible to get it. Its for someone alot less savvy. With all the other emulators for that person this helped. 
 

not a biggie already have a solution for them but to be honest i was just using that idea to make sure its simple when im not around

[phaeron]

15 hours ago, jenorton said:

Wouldn't it be possible to detect the custom OS that comes with Altirra?  It wouldn't be a fool-proof way to detect Altirra, but, I don't know how that would work.

Detecting AltirraOS isn't the same as detecting Altirra, as Altirra is often used with other OSes including the stock OS. No one should need to detect AltirraOS except for diagnostic purposes, if they're properly using the public OS interfaces documented by Atari.

 

There are, in general, few legitimate reasons for detecting either Altirra or AltirraOS, and I would ask that people generally don't try to do so.

 

[flashjazzcat]

And detecting Altirra OS certainly doesn't imply that one is running on an emulator anyway, since Altirra OS runs perfectly well on a real Atari.

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.20-test19.zip
https://www.virtualdub.org/beta/Altirra-4.20-test19-src.7z

• Fixes the tape auto-BASIC boot: fixed detection to allow for BASIC programs that have the rev. B padding bug, and added support for booting tapes that require RUN "C" to boot.
• ATX disk image loader now allows null dwords at the end of the file.
• Fixed VBXE P/M priority bugs on right side when emulating 1.26 core, due to not clearing the full priority buffer on lines with no P/M graphics.
• Fixed a crash in the tape code after recording a performance analyzer trace with a tape mounted.
• Fixed performance analyzer reporting an error when saving a trace if the history window had been moved to view a later part of the trace.
• Revised trace save format: removed unnecessary complicated multi-stripe system, optimized codec/decoder, and compacted cycle counters. This is a hard format break.

The story behind the RUN "C" change: there are some BASIC tape loaders that are protected with a zero-length immediate line. This caused a lock-up when the emulator tried to boot the tape with CLOAD followed by RUN, because the RUN statement would lock up the interpreter. Problem is, RUN "C" doesn't work on other tapes because it uses long IRGs instead of short IRGs, and there's no CRUN command. So what Altirra does now is that it uploads a small patch to temporarily shim the C‍: device so that RUN "C" uses short IRGs and both kinds of tapes work.

 

[Mclaneinc]

As anyone who has followed Altirra from its very beginning will know, it was just meant as a pet project for Avery, a proof of concept I think was his term back then. Well, look at it now, as an example of emulation of a series of machines, it's just incredible. Then when you look at the actual Atari emulation side, that is also beyond amazing. His multi level knowledge just stuns me, audio, video, system structure etc etc, all so detailed. OK, he works in 'the industry' as he has said, and the stuff he works on do take up pretty much all of his time, so to be giving us Altirra, I just want to say thank you again...

[oo7]

Altirra is crazy good.

 

 

atari 8 bit users are lucky we got this so lucky

Edited July 22, 2023 by oo7

[kenp]

I'm going to ask another likely dumb question while I'm reading and trying to catch up.  But, I'm beginning to think I'll never really catch up on all the things that have been going on.

 

Can you run more than one instance of the Altirra emulator on a single Windows PC?  I had this odd vision of running several copies of the Altirra at the same time to see how different options behaved and maybe to simulate a small network of 8-bit machines in one current PC machine.  ( i did search this Altirra thread for the term multiple instances but didn't come up with a citation. )

 

(I did find the source for the FujiNET PC software so that might need to have multiple instances running as well.)

[scotty]

[+gnusto]

2 hours ago, kenp said:

Can you run more than one instance of the Altirra emulator on a single Windows PC?

Tools/Options/Startup, uncheck Reuse program instance

[kenp]

8 hours ago, gnusto said:

Tools/Options/Startup, uncheck Reuse program instance

Very good.  Thanks.

[mirao]

12 hours ago, kenp said:

Can you run more than one instance of the Altirra emulator on a single Windows PC?  I had this odd vision of running several copies of the Altirra at the same time to see how different options behaved and maybe to simulate a small network of 8-bit machines in one current PC machine.  ( i did search this Altirra thread for the term multiple instances but didn't come up with a citation. )

Yes, similar way I tested a network in MIDI Maze, with multiple Altirra instances on one host: 

 

[woj]

On 7/19/2023 at 9:53 PM, phaeron said:

Detecting AltirraOS isn't the same as detecting Altirra, as Altirra is often used with other OSes including the stock OS. No one should need to detect AltirraOS except for diagnostic purposes, if they're properly using the public OS interfaces documented by Atari.

 

There are, in general, few legitimate reasons for detecting either Altirra or AltirraOS, and I would ask that people generally don't try to do so.

 

With your latest test versions of Altirra my reason for detecting the emulator vanished (it was about the order of interlace fields as was discussed earlier). However, the question itself remained in my head and I was thinking this, it would have worked for my purpose - what about detecting the built-in Altirra XEX loader? Would that have a unique signature of some sort? Or lack thereof?

[+gnusto]

15 minutes ago, woj said:

Would that have a unique signature of some sort? Or lack thereof?

If it did Phaeron would then just update it so it didn't. I'm pretty sure that would be the case for anything you could do along this line of thinking - given that the goal of the emulator is accuracy, hosted programs shouldn't be aware of the emulated environment. It should behave exactly as the hardware would, that's the point.

[woj]

11 minutes ago, gnusto said:

If it did Phaeron would then just update it so it didn't. I'm pretty sure that would be the case for anything you could do along this line of thinking - given that the goal of the emulator is accuracy, hosted programs shouldn't be aware of the emulated environment. It should behave exactly as the hardware would, that's the point.

But nothing prevents me (morally I mean) from legitimately checking what kind of DOS or loader is running that pushes my program into memory, no?

[+gnusto]

3 hours ago, woj said:

But nothing prevents me (morally I mean) from legitimately checking what kind of DOS or loader is running that pushes my program into memory, no?

Other than the fact he's specifically asked that people not do this, so whether that's a moral problem or not is subjective I suppose.

I don't mean to put words in Phaerons mouth but I believe the logic here is he doesn't want any software to have to react to the emulator in any way, or do anything other than it would have to on real hardware. If it has to, then that's likely a fault in Altirra itself that should just be fixed, not dealt with in the Atari code.

[phaeron]

8 hours ago, woj said:

But nothing prevents me (morally I mean) from legitimately checking what kind of DOS or loader is running that pushes my program into memory, no?

Nope... although to be pedantic, such a check already kind of has a moral assessment attached to it by calling it legitimate. The best argument that I have against this is that this kind of check will just cause more trouble than it's worth.

 

Let's start with why you would want to do such a check. Is it to detect a bug? Well, that's often difficult if not impossible. Testing the chipset output often requires finicky cycle-precise code, and some outputs like GTIA priority output cannot be tested at all since there is no feedback path to the 6502. So already in a lot of cases you're already in trouble because testing for the emulator is not the same as testing for the bug. Furthermore, the check may give false positives -- which means that you're now also breaking real hardware.

 

Say, for instance, that you try to detect Altirra by the EXE loader. What would you test? You could try to test MEMLO, because no DOS is going to be able to load an an executable with MEMLO=$0700, right? Well, except some SIO2PC based loaders, or a boot menu DOS. Oops. Plus Altirra now has an EXE loading mode where it waits for DOS to boot and then kicks off the EXE loader when it detects the type 3 poll. Try to detect if SIO was used? Altirra simulates a lot of that, plus now you just broke MaxFlash and SIDE3 cartridges as well as IDE hard disks. Check uninitialized memory under the ROM? Breaks depending on the brand of RAM chips in the machine (yes, this has happened).

 

Emulators also improve over time. The Ilusia demo says "this demo only works on real hardware", but modern emulators have been able to run it for a while now. Unfortunately, a lot of myths still persist about what emulators don't support. Your case actually was an emulation bug, of course, for which I'm thankful you reported it in detail. But if you had tried to do something based on emulation detection, that check would have become outdated and incorrect pretty quickly, which then would have been a headache for me even after fixing the bug.

 

In some cases, people have asked for this kind of detection because they want to actually take advantage of the emulator. But that's a mistake, because in most cases emulators aren't trying to provide a new computer model, they're trying to imitate existing ones. Writing directly for the emulator doesn't have much point, you might as well just port the program to C++ and run it native. It doesn't make sense for emulators to provide their own unique features that require software to be written specifically for them -- it's far more useful to instead emulate expansions that already exist (e.g. VideoBoard XE) or to extend interfaces that software already generally supports, such as new CIO device handlers (H:) or adding extended memory through PORTB.

 

[+Larry]

My ultimate goal is to get a MyIDE-II cart working with a non-Incognito 800 with real hardware.  I have successfully gotten a MyIDE-II working with Altirra (XE) as a first step.  But I am hung up trying to copy files from a 20,000 sector DD ATR to the hard drive image on the the MyIDE-II.  Is there a way to mount large ATR's in Altirra?  On real hardware, I make periodic sector copy backups of my hard drives to APE ATR's.  But I see no way to mount/use a large ATR in Altirra. (?)

Thanks.