Altirra 4.20 released

[phaeron]

28 minutes ago, yetanothertroll said:

ABBUC's software contest signup page lists a bunch of ways emulators including Altirra don't work the same as real hardware, especially PAL. How many of these might still be relevant in current versions?

 

https://abbuc.de/aktivitaten/software-competition/

Some of it still applies, but a lot of it isn't "real hardware". It's based on the executable loader used. You will still see failures on real hardware if you don't follow some of these guidelines, depending on how the executable is loaded. Some if not all of these come from JAC!, who has had a lot of experience debugging and fixing these issues in the compilations.

 

To go into detail:

 

Uninitialized memory -- emulated for along time in Altirra, which has default to a DRAM fill pattern forever, though it has options for cleared and random for debugging. But this is still a way to get into trouble, as the executable loader as well may or may not touch areas of memory. One loader used to write to location 0, which broke any program that used LDA 0 instead of LDA #0.

 

Dirty screen switch -- emulated for a long time but the problem is that it depends on the loader. Different executable loaders will start the program at different timing and thus may or may not show a dirty screen switch problem. Multi-stage loads can show problems with bad screen switches that only show up depending on load timing, so those especially do need to be tested against an actual SIO disk load, emulation or not. (One issue is that SIO disables stage 2 VBLANK via CRITIC, which may prevent a screen switch from showing up before the disk load starts.)

 

Initializing audio registers -- emulated for a long time in Altirra, but it's indeed a big problem. It tends to be less of an issue with cartridge or PBI-based storage, but in particular loading off of floppy disk will usually leave channels 3+4 disabled unless you explicitly re-enable them via SKCTL. This used to be a big problem as emulators didn't emulate asynchronous receive mode. Altirra's executable loader also resets the audio channels to match what SIO does, so you will see this problem in emulation if you are not clearing SKCTL properly on startup.

 

High volume distortion -- can still be an issue. Altirra does emulate non-linear saturation by default, but it's possible for this effect to sound differently on different Ataris as it's an analog effect, and I'm not sure how well the original RMT output plugins handled this. POKEY replacements can also sound differently at high overall volume levels.

 

NTSC vs. PAL -- this is mostly handled now. Both Altirra and Atari800 now switch color generation strategies as well as aspect ratio between NTSC and PAL and this is generally more understood than it used to be.

 

Executable memory range -- this still applies and is a big cause of failure even on real hardware. You can still get in trouble with this even if you have never used an emulator, because you use a cart-based or SIO2PC-based loader that can handle MEMLO down to $0700 or so, and then your program blows up on a menu DOS that needs a bit more memory than that, especially for high-speed SIO. This is one of the biggest reasons I see for bogus "not emulated properly" reports. No, the emulator cannot possibly reproduce all possible ways that your program could fail on any executable loader or DOS out there.

 

PAL colors -- can have endless arguments about colors in general. Recent versions of Altirra have a PAL palette that's been calibrated from screenshots taken from actual PAL machines, so it's closer than it used to be. But even though it has less of an effect than on NTSC, PAL machines have color pots and can differ in colors too. I'm not sure what the reference to Project M 2.0 is because even with a retuned palette I can't see how the door colors would be red/green/blue as reported -- one of the door colors in P-M 2.0 PAL is hue 1, for instance.

 

Disk load timing -- this can still be an issue if you don't test with the accurate disk timing setting on. Usually not an issue with executable loads, but more of an issue with a custom DOS. One particular custom DOS had a bug in its early versions where it set DTIMLO far too low, meaning that it could never load from an actual disk drive. But Altirra will reproduce this will accurate disk timing enabled + SIO patch disabled.

 

[+yetanothertroll]

I've seen some of these issues with Atari/LCSI Logo. The .car seems to be the only dump that works properly. Other cart dumps and the .atr versions do weird things with the TOOT sound command's second channel, which combines POKEY channels 3+4, and exhibit math glitches that only seem to show up with a bignum package I was noodling around with of all things. Maybe there's a LDA 0 lurking in the math code?

[phaeron]

22 minutes ago, yetanothertroll said:

I've seen some of these issues with Atari/LCSI Logo. The .car seems to be the only dump that works properly. Other cart dumps and the .atr versions do weird things with the TOOT sound command's second channel, which combines POKEY channels 3+4, and exhibit math glitches that only seem to show up with a bignum package I was noodling around with of all things. Maybe there's a LDA 0 lurking in the math code?

No, it's simpler than that, it looks like there are at least two versions of Logo and one of them just doesn't reset AUDCTL. It does reset SKCTL, so it's not the locked channels 3+4 problem.

 

[NRV]

2 hours ago, phaeron said:

PAL colors -- can have endless arguments about colors in general. Recent versions of Altirra have a PAL palette that's been calibrated from screenshots taken from actual PAL machines, so it's closer than it used to be. But even though it has less of an effect than on NTSC, PAL machines have color pots and can differ in colors too. I'm not sure what the reference to Project M 2.0 is because even with a retuned palette I can't see how the door colors would be red/green/blue as reported -- one of the door colors in P-M 2.0 PAL is hue 1, for instance.

 

That's weird.. I mean the hue 1 thing. I suppose you could say the intention was red, blue, cyan for the doors.

 

TabTexDefColorOverride        ; 23 definitions
; use this color byte (2 pixels) for all the texture rows
.if .def PAL_VERSION
    .byte $22,$88,$99            ; doors
    .byte $11,$33,$88,$99        ; metal walls
    .byte $00,$22,$88            ; dark normal bricks
    .byte $00,$22,$88            ; light normal bricks
    .byte $22,$33,$44,$66,$77    ; color bricks

    .byte $00,$00        ; plain rows
    .byte $11            ; animated lum plain row
    .byte $00,$99        ; columns special textures
.else
    .byte $33,$99,$AA            ; doors
    .byte $22,$44,$99,$AA        ; metal walls
    .byte $00,$33,$99            ; dark normal bricks
    .byte $00,$33,$99            ; light normal bricks
    .byte $33,$44,$55,$77,$88    ; color bricks

    .byte $00,$00        ; plain rows
    .byte $22            ; animated lum plain row
    .byte $00,$AA        ; columns special textures
.endif

 

[phaeron]

On 7/22/2024 at 10:19 PM, NRV said:

That's weird.. I mean the hue 1 thing. I suppose you could say the intention was red, blue, cyan for the doors.

Sorry, I mixed it up with the metal walls. You're right, the doors are hue 2 while the metal wall is hue 1. But the other two colors being only one hue apart... that's a lot closer than blue/green.

 

The thing about hue 2 it's usually more of a orange-peach color that I've seen in most PAL palette images, and only turns red on the low end when negative color gamut clipping occurs:

 

P-M interleaves luma 0 chroma lines with luma-only lines, so when blending chroma in U/V space I'd expect this to produce a peach-ish color instead of red given the base colors. I could see a more red color occurring if the blending was done in clipped RGB space, but that seems less correct or practical for displays and would distort APAC image colors. Colors can vary slightly between even/odd lines, but generally not that much on hue 1.

 

Anyone got a real-world PAL display screenshot of one of the reddish doors, like the one to the right of the first door?

[+Philsan]

PAL 800XL + 1084ST monitor with luma chroma cable

 

[phaeron]

6 hours ago, Philsan said:

PAL 800XL + 1084ST monitor with luma chroma cable

Thanks, very helpful. Can you get screenshots of the 256 color palette and GR.0 screen? I'm particularly interested in how your computer's palette matches to others I've seen and how bluish or greenish the GR.0 screen is.

 

One thing that's odd is that it looks like the APAC title screen has a color clock offset between GR.9 and GR.11. That usually only occurs when GR.10 is involved.

[NRV]

3 hours ago, phaeron said:

One thing that's odd is that it looks like the APAC title screen has a color clock offset between GR.9 and GR.11. That usually only occurs when GR.10 is involved.

Yep, I was trying to understand why it looked kind of wrong.. but is my idea, or is mostly with the dark blues?. The hand and the head look right it seems.

 

[phaeron]

42 minutes ago, NRV said:

Yep, I was trying to understand why it looked kind of wrong.. but is my idea, or is mostly with the dark blues?. The hand and the head look right it seems.

This may be due to an issue I hadn't even thought of before.

 

PAL is designed around averaging the chroma from adjacent lines to cancel phase errors. This is done in many displays with a delay line. In modern displays, this is trivially done digitally, but in older displays, it was done with an analog delay line. This delay line is calibrated for the broadcast line length of 64us.

 

Problem is, the Atari's video output is not broadcast standard, and its line is 64.28us instead of 64.0us -- too long by half a machine cycle, or a lores pixel. Which means that the analog delay line in turn begins repeating the chroma from the previous line also a lores pixel too early -- which might explain the effect that we're seeing in the APAC picture.

 

There's another ramification of this, though. The analog delay line stores the quadrature modulated signal, not demodulated U/V. This means that the delay also results in a phase shift that must be taken into account. From references that I've found, the decoder normally takes this into account by rescaling the U and V signals after combining the delayed and undelayed signals. But the differing line length also results in another phase delay, which potentially screws up this matrixing, and potentially results in a change in saturation for some hues. I wonder if this is the reason I've been seeing intensely vibrant blues in some PAL display pictures.

 

[patjomki]

3 hours ago, phaeron said:

Problem is, the Atari's video output

 

BTW, because the is no native Sophia2 support in Altirra: Is it possible that user can insert Sophia2 functionality with the custom devices feature provided by Altirra?

[+Philsan]

[phaeron]

4 hours ago, patjomki said:

BTW, because the is no native Sophia2 support in Altirra: Is it possible that user can insert Sophia2 functionality with the custom devices feature provided by Altirra?

Unfortunately no, this is lower level than custom devices can support. I haven't forgotten about this request yet, have to do some research.

[phaeron]

Experiment with skewing the delay line timing. It reproduces the ragged edges, but there's some stuff going on in some of the brick interiors that I can't figure out. There probably a more complex comb filter involved.

 

It's also interesting that this is done with L/C input where it isn't really needed. With regular composite it'd probably be difficult to see this effect.

 

[oo7]

@phaeron my siblings and i grew up around both pal and ntsc machines.

 

i have a small feature request that would make life easy for our family setup and figured Ide ask in case it was a ok idea that you may decided to possibly implement.

 

most ntsc software runs best at ntsc and some pal titles will run best at pal. My current solution on our setups for the less technical family members is two installs with two separate software folders.

 

if there was a way for altirra to know what to run in pal and what in ntsc it would be nice. Either by adding pal or ntsc to file name or even having altirra remember the specific setting for a specific file loaded. Is there currently a way to do this that we are overlooking or would you be able to implement something?

 

for one family member we set up retroarch with a800 core and its able to load each program in pal or ntsc as set however altirra is a much better experience for emulating this platform by far and i would really like to use just altirra at this point.

 

anyway just a small request to make that possible if thats ok and doable.

 

Edited July 29 by oo7

[+gnusto]

1 hour ago, oo7 said:

even having altirra remember the specific setting for a specific file loaded

You can do this currently with the Compatibility Database feature (under the Tools menu). For a given file hash it lets you save settings that you use with that file (although not all settings, PAL and NTSC are in there, but not for instance different color maps).

However one wonderful aspect of Altirra is that pretty much everything is controllable with command line flags, so you can switch PAL/NTSC, memory, OS, etc all transparent to the user as the game launches. To get all the command line switches, invoke Altirra with a /? e.g. "Altirra64.exe /?" and a dialog box with all the options will pop up, click in that and ctrl-a to select then paste it somewhere to read at your leisure.

Building some kind of automated feature here would be a nightmare unless Phaeron can be a lot more clever than I am thinking about it (admittedly, he's a clever dude). There are so many edge cases.

There were games written in PAL that were released in NTSC and vice versa, so that's how people played them. Whether it was "right" or not that was their experience and they'll think it inaccurate to have the wrong timing. In the end most software will work interchangeably between PAL/NTSC - exceptions that actually break are rare - so it's very unclear which is the "right" version.

There are also games that switch between PAL and NTSC palettes and display lists - although these are all newer ones. Picking one mode would limit the extra work the authors put in to the title.

 

[oo7]

21 minutes ago, gnusto said:

You can do this currently with the Compatibility Database feature (under the Tools menu). For a given file hash it lets you save settings that you use with that file (although not all settings, PAL and NTSC are in there, but not for instance different color maps).

However one wonderful aspect of Altirra is that pretty much everything is controllable with command line flags, so you can switch PAL/NTSC, memory, OS, etc all transparent to the user as the game launches. To get all the command line switches, invoke Altirra with a /? e.g. "Altirra64.exe /?" and a dialog box with all the options will pop up, click in that and ctrl-a to select then paste it somewhere to read at your leisure.

Building some kind of automated feature here would be a nightmare unless Phaeron can be a lot more clever than I am thinking about it (admittedly, he's a clever dude). There are so many edge cases.

There were games written in PAL that were released in NTSC and vice versa, so that's how people played them. Whether it was "right" or not that was their experience and they'll think it inaccurate to have the wrong timing. In the end most software will work interchangeably between PAL/NTSC - exceptions that actually break are rare - so it's very unclear which is the "right" version.

There are also games that switch between PAL and NTSC palettes and display lists - although these are all newer ones. Picking one mode would limit the extra work the authors put in to the title.

 

Ok so what i need is already there it seems need to test it out. Im only running a hand-full of titles that need to switch to pal and sounds like i can make it switch using the compatibility database. Thanks.

 

i dont need altirra to auto detect or anything i just needed a way to tell it to boot a handfull of titles in pal rather than ntsc.

 

there are some pal titles that really break on ntsc. And running titles as intended is better if you lived in both regions and want things to run as close to original as they did for that nostalgia feeling.

 

with real hardware i can not get this close to the best of both worlds in one.

 

the compatibility database option is exactly what i was after.

Edited July 29 by oo7

[oo7]

Cant figure this out. How does one use this compatibility database to make a specific file boot as ntsc or pal vs setting?

[oo7]

@phaeron would it be possible to get you to add a full screen osd of ntsc or pal?

[phaeron]

19 hours ago, oo7 said:

Cant figure this out. How does one use this compatibility database to make a specific file boot as ntsc or pal vs setting?

You need to:

• Create a new compatibility database
• Add a new title
• Add an alias for the title, which sets one or more disk image signatures to match the tile
• Add the NTSC/PAL tag to the title
• Compile the database
• Set the compiled database as the external database in Tools > Options

18 hours ago, oo7 said:

@phaeron would it be possible to get you to add a full screen osd of ntsc or pal?

I'm not sure what you mean, could you go into more detail?

[oo7]

3 hours ago, phaeron said:

You need to:

• Create a new compatibility database
• Add a new title
• Add an alias for the title, which sets one or more disk image signatures to match the tile
• Add the NTSC/PAL tag to the title
• Compile the database
• Set the compiled database as the external database in Tools > Options

I'm not sure what you mean, could you go into more detail?

Thank you, this will solve my issue. I was asking for a osd indication of machine mode but I wasnt thinking as display fps would achieve enough anyway.

 

thanks for explaining database. I was doing everything but not adding the tag. Will test when I get home.

[oo7]

@phaeron ok so I got this to work thank you.

 

this is kinda cumbersome though, you would literally have to add all titles if you had a database and only 3 titles needed a different setting. Would be more practical if after switching to an override the next altirra run would return to your usual settings.

 

not complaining, just suggesting.

 

truly dont want to come across negative. Altirra to me is a god send and the most complete emulator I have ever used.

 

its also allowed me to have what i consider a perfect ntsc and perfect pal experience all in one. I prefer it over the real hardware for myself so thank you.

[phaeron]

14 hours ago, oo7 said:

this is kinda cumbersome though, you would literally have to add all titles if you had a database and only 3 titles needed a different setting. Would be more practical if after switching to an override the next altirra run would return to your usual settings.

Yeah, it's really meant just for flagging "this title won't work unless you change this setting", not to enforce "best" settings for each title.

 

One idea that I had was to add a mode where every Boot Image command would automatically create a child profile specifically for that image -- if you booted Numen, it would create a Numen profile if that didn't already exist, and then switch to it. This would naturally allow newly seen images to reset to the base profile, and also allow for saving image-specific settings like working disks. But it hasn't materialized yet as it'd take some thought and upgrades to the profile system.

 

[+gnusto]

On 7/30/2024 at 5:42 AM, oo7 said:

@phaeron ok so I got this to work thank you.

 

this is kinda cumbersome though, you would literally have to add all titles if you had a database and only 3 titles needed a different setting. Would be more practical if after switching to an override the next altirra run would return to your usual settings.

 

not complaining, just suggesting.

 

truly dont want to come across negative. Altirra to me is a god send and the most complete emulator I have ever used.

 

its also allowed me to have what i consider a perfect ntsc and perfect pal experience all in one. I prefer it over the real hardware for myself so thank you.

Still easy to accomplish. Create Altirra settings that cover the most number of your titles, and then for one-offs use command line settings with /tempprofile, which will not change any of the settings you already have established in Altirra. So the next time you launch it, it's back to normal.

Here's a command line for instance to launch the a8p version of Ali-Baba (note it's long because of reading the file from within a zip):

Altirra64.exe /tempprofile /fastboot /ntsc /artifact:none /hardware:800 /kernel:osb /memsize:48K /burstio /siopatch /noaccuratedisk /nobasic /disk "zip://../../Games/Atari 800/a8preservation-230517/Ali Baba and the Forty Thieves (1982)(Quality Software)(US)[disk].zip!Ali Baba and the Forty Thieves (1982)(Quality Software)(US)[OS-B].atx"

You can either have the command lines on shortcuts (if it's only a few games) or whatever is your front-end.
 

[+yetanothertroll]

There may be a bug in the .CAS handler when reading absurdly long (over four hours) tapes. Sometimes the inter-block gap decides to be more like indefinite instead of a few seconds and the read fails with a timeout error. It appears to help a bit when one tape is done, to stop and rewind the tape and unload it before loading another, or maybe it doesn't. The tapes are built in Altirra 4.21 x64 running OS-B and BASIC C, bog standard 600 baud. Attached are some example tapes, ~430KB each. Writing tapes much longer than these using OS-B and BASIC-C also fails hard, resulting in a corrupt .CAS file.

 

The first screenshot is of a failed read, and the second is of a successful read of the same tape after using the cargo cult ritual above and the quickie Atari BASIC program I whipped up to investigate the issue. Yes, that ATASCII 0 is supposed to be on the tape. While these are data sets in Atari Statistics I CX4103's "database" format, I'm not actually using them with Atari's statistics program. 😄 No hurry with this, maybe look into it when you're really bored

 

RndReal 30K 3-5.cas RndReal 30K 0-2.cas

[phaeron]

3 hours ago, yetanothertroll said:

There may be a bug in the .CAS handler when reading absurdly long (over four hours) tapes. Sometimes the inter-block gap decides to be more like indefinite instead of a few seconds and the read fails with a timeout error. It appears to help a bit when one tape is done, to stop and rewind the tape and unload it before loading another, or maybe it doesn't. The tapes are built in Altirra 4.21 x64 running OS-B and BASIC C, bog standard 600 baud. Attached are some example tapes, ~430KB each. Writing tapes much longer than these using OS-B and BASIC-C also fails hard, resulting in a corrupt .CAS file.

 

The first screenshot is of a failed read, and the second is of a successful read of the same tape after using the cargo cult ritual above and the quickie Atari BASIC program I whipped up to investigate the issue. Yes, that ATASCII 0 is supposed to be on the tape. While these are data sets in Atari Statistics I CX4103's "database" format, I'm not actually using them with Atari's statistics program. 😄 No hurry with this, maybe look into it when you're really bored

You're hitting a bug in the Atari OS. The cassette handler has an issue where there is a small chance with every block that it will miscompute the baud rate, causing the next block read to fail. The chance for this in NTSC is about 1-in-3000. Which doesn't sound so bad, until you realize that this snowballs -- it's a 5% total chance to fail with 150 blocks and a 15% chance to fail with 500.

 

The issue is also known in PAL land as well:

http://www.atari.org.pl/forum/viewtopic.php?id=9188

 

The cause of the issue is a timing bug in the OS code that measures the baud rate: it tries to take before and after timestamps as pairs of (RTCLOK, VCOUNT) values, but has an issue with ambiguous timestamps around the vertical blank interrupt (VCOUNT=124). If the start or the end of the block sync falls within this window, POKEY is configured with an erroneous baud rate and the read fails. This affects all versions of the Atari OS.

 

There are a few ways to work around this. SIO 😄 patch in an emulator will avoid it, and I also put in extra logic in AltirraOS's cassette handler to avoid it. But Altirra also has a hack option to make the Atari OS work:

 

This option fudges the SIO input bit in SKSTAT around the VBI when the cassette is active to prevent the Atari OS from seeing a transition in the vulnerable timing window.

 

Edited August 4 by phaeron
bad math