Altirra 3.90 released

[Synthpopalooza]

In the process of going through my note tables for Distortion A SKCTL 1.79 modes, and marking frequencies not working in Altirra 4.0.  This may be a useful reference point for debugging.

[phaeron]

6 hours ago, Synthpopalooza said:

In the process of going through my note tables for Distortion A SKCTL 1.79 modes, and marking frequencies not working in Altirra 4.0.  This may be a useful reference point for debugging.

Thanks, but I don't need more reference points, I just need to debug on the actual hardware. No need to clutter this thread with more reports of the same issue, please.

 

[oo7]

On 8/21/2021 at 2:51 PM, phaeron said:

Thanks, but I don't need more reference points, I just need to debug on the actual hardware. No need to clutter this thread with more reports of the same issue, please.

 

If this bug occurs on real hardware too a more simple fix would be enable and disable pokeymax to maintain real hardware accuracy. Unless you add enable disable pokeymax and enable pokemax fix option so that tou have real world behaviour one and two plus enhanced.

 

just thinking out loud. 

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.00-test38.zip
https://www.virtualdub.org/beta/Altirra-4.00-test38-src.7z

• Fixed errors when switching to exclusive full screen mode in D3D9 mode with hardware accelerated bloom enabled. (There was a surface not being released on D3D reset, leading to D3DERR_INVALIDCALL.)
• Fixed a stack overflow crash that could occur when switching between pane layouts, such as entering or exiting the debugger, on a multi-mon system with different DPI scales on each monitor.
• Added a configvar for the target frame rate in warp mode, previously hardcoded at 1/15 frames displayed.
• The .basic_dumpline debugger command now adds the $ or ( suffix for string and array variables when it synthesizes variable names due to a corrupted VNT. That is, you will now see _V9C$ instead of _V9C.
• Added new experimental peak-to-peak and duty cycle balanced turbo tape decoding modes. The balanced duty cycle modes are intended to improve decoding for loaders that are highly sensitive to pulse widths, which is a problem when decoding tapes distorted by audio enhancement. However, it's a more heavy-handed in the changes that it makes to the tape signal, so YMMV.
• Added an option to hold the tape data line across the start of vertical blank. This is a workaround for a bug in the Atari OS C: handler that causes it to occasionally screw up when measuring the baud rate and blow the tape load -- the SKSTAT bit is held across the danger period where RTCLOK+VCOUNT is ambiguous.
• The Phoenix 8K cartridge type can now be used with 2K and 4K images, which are auto-mirrored to 8K like with the standard 8K type.

Also in this version is the main thing I've been working on, the ability to check for updates online. This is only a manual check for now as I haven't added the logic to auto-check on startup, but Help > Check for Updates will now fetch an update feed to check if there is a newer release (test or stable, depending on which type of build you are running). Quite a lot was involved here including signing certificates (yuck) and the Windows CryptAPI/CNG/WinINet APIs (double yuck), but hopefully once it's all working smoothing it'll be a more convenient way for people to find out about updates. Note that the update mechanism only shows when a new build is available, it doesn't download or install it.

 

The underlying notification mechanism uses a subset of RSS 2.0. I haven't decided how widely to publicize this, but you can subscribe to it in a regular feed reader:

https://www.virtualdub.org/feeds/altirra-update-dev.xml

 

Note that there is a chicken-and-egg problem in that for the test releases, the link in the update feed is the AtariAge post announcing the new release. This means that you'll always hear about it here first, because I can't get the link for the feed update until the post has been made!

 

1 hour ago, oo7 said:

If this bug occurs on real hardware too a more simple fix would be enable and disable pokeymax to maintain real hardware accuracy. Unless you add enable disable pokeymax and enable pokemax fix option so that tou have real world behaviour one and two plus enhanced.

 

just thinking out loud. 

Pokeymax has nothing to do with Altirra and it's not a matter of disabling something to fix the bug, it's the opposite where something new has to be implemented. That the two might have the same bug here is coincidental.

[Synthpopalooza]

If it helps, I did some experimenting, and found out that on some notes in the 1.79 two tone mode, the beginnings of the sawtooth ranges are off by 1, which is why we're getting some of the missed notes.  Add 1 to the frequency in the first channel, and it bumps it back to the beginning of the range and plays correctly.  So it could be the timers being out of sync, as you suggested.

[Keatah]

Feature Suggestion:

 

Please make this online update check optional with an enable/disable switch someplace. I know of (and don't use) a few emulators that enforce this check. They will not start unless successfully connecting to a remote server.

 

 

[patjomki]

On 8/21/2021 at 3:52 AM, phaeron said:

Not currently. I have a Sophia 2 and know how it works, but it is not currently emulated.

 

I see.

 

As Sophia 2 does not add too much functionality I hope you find the time to add Sophia 2 support to Altirra.

[Mclaneinc]

1 hour ago, patjomki said:

 

I see.

 

As Sophia 2 does not add too much functionality I hope you find the time to add Sophia 2 support to Altirra.

To be fair, it's more or less added, setting the display to point with no filters or artifacting gives an ultra clear display..

[oo7]

7 hours ago, phaeron said:

https://www.virtualdub.org/beta/Altirra-4.00-test38.zip
https://www.virtualdub.org/beta/Altirra-4.00-test38-src.7z

• Fixed errors when switching to exclusive full screen mode in D3D9 mode with hardware accelerated bloom enabled. (There was a surface not being released on D3D reset, leading to D3DERR_INVALIDCALL.)
• Fixed a stack overflow crash that could occur when switching between pane layouts, such as entering or exiting the debugger, on a multi-mon system with different DPI scales on each monitor.
• Added a configvar for the target frame rate in warp mode, previously hardcoded at 1/15 frames displayed.
• The .basic_dumpline debugger command now adds the $ or ( suffix for string and array variables when it synthesizes variable names due to a corrupted VNT. That is, you will now see _V9C$ instead of _V9C.
• Added new experimental peak-to-peak and duty cycle balanced turbo tape decoding modes. The balanced duty cycle modes are intended to improve decoding for loaders that are highly sensitive to pulse widths, which is a problem when decoding tapes distorted by audio enhancement. However, it's a more heavy-handed in the changes that it makes to the tape signal, so YMMV.
• Added an option to hold the tape data line across the start of vertical blank. This is a workaround for a bug in the Atari OS ? handler that causes it to occasionally screw up when measuring the baud rate and blow the tape load -- the SKSTAT bit is held across the danger period where RTCLOK+VCOUNT is ambiguous.
• The Phoenix 8K cartridge type can now be used with 2K and 4K images, which are auto-mirrored to 8K like with the standard 8K type.

Also in this version is the main thing I've been working on, the ability to check for updates online. This is only a manual check for now as I haven't added the logic to auto-check on startup, but Help > Check for Updates will now fetch an update feed to check if there is a newer release (test or stable, depending on which type of build you are running). Quite a lot was involved here including signing certificates (yuck) and the Windows CryptAPI/CNG/WinINet APIs (double yuck), but hopefully once it's all working smoothing it'll be a more convenient way for people to find out about updates. Note that the update mechanism only shows when a new build is available, it doesn't download or install it.

 

The underlying notification mechanism uses a subset of RSS 2.0. I haven't decided how widely to publicize this, but you can subscribe to it in a regular feed reader:

https://www.virtualdub.org/feeds/altirra-update-dev.xml

 

Note that there is a chicken-and-egg problem in that for the test releases, the link in the update feed is the AtariAge post announcing the new release. This means that you'll always hear about it here first, because I can't get the link for the feed update until the post has been made!

 

Pokeymax has nothing to do with Altirra and it's not a matter of disabling something to fix the bug, it's the opposite where something new has to be implemented. That the two might have the same bug here is coincidental.

Thanks very much for the update and the explaining.

 

 

Ive been detached from the A8 way too long. Got lots to learn.

 

[Mclaneinc]

Well as you know, just ask, anyone in here who has the answer will normally jump to help..

[patjomki]

1 hour ago, Mclaneinc said:

To be fair, it's more or less added, setting the display to point with no filters or artifacting gives an ultra clear display..

 

Actually I especially meant these two of the additional features that enhance the ATARI graphics capabilities:

 

HIRESBC: This flag, if set, enables bi-color high resolution graphics. The color of the graphics pixels is determined by the COLPF1 register, while the color of the playfield is determined by the COLPF2 register

LUM0EN: This flag, if set, enables 16 levels of luminance for all graphics modes.

[Mclaneinc]

 

Ah, in this case only Avery knows

 

To be honest, although I have a Sophia 2 I'd not referenced those abilities

[+Stephen]

1 hour ago, patjomki said:

 

Actually I especially meant these two of the additional features that enhance the ATARI graphics capabilities:

 

HIRESBC: This flag, if set, enables bi-color high resolution graphics. The color of the graphics pixels is determined by the COLPF1 register, while the color of the playfield is determined by the COLPF2 register

LUM0EN: This flag, if set, enables 16 levels of luminance for all graphics modes.

You can experiment with these features by emulating VBXE for now as that's where they originated.

[Synthpopalooza]

There's also the GTIA Graphics 10 shift toggle in Sophia.  If set every VBLANK, for example, you can get 160x192x45 colors.

[phaeron]

20 hours ago, Keatah said:

Feature Suggestion:

 

Please make this online update check optional with an enable/disable switch someplace. I know of (and don't use) a few emulators that enforce this check. They will not start unless successfully connecting to a remote server.

To be clear, I have zero intention of ever making network access a requirement for the emulator, because I hate both that and managing live ops.

 

The auto-update check, when implemented, will probably be opt-in, with the opt-in at the end of the setup process. I don't have much issue with a background auto-update check, but I have less confidence in the stability of the WinINet APIs I'm using to download the feed (fragile API), and I don't want to DoS my website by accident.

 

The RSS feed is also signed, so in the event that I lose control of virtualdub.org or the feed download is corrupted/replaced, existing builds of the emulator will reject it prior to parsing and just say that it can't retrieve the feed. Then you just go get the latest version yourself as usual.

 

[patjomki]

On 8/23/2021 at 3:22 PM, Stephen said:

You can experiment with these features by emulating VBXE for now as that's where they originated.

 

Well, programming seems to be different. Anyway, sophias features are so interesting I am going to start a new thread in the programming section immediately.

On 8/24/2021 at 3:35 AM, Synthpopalooza said:

There's also the GTIA Graphics 10 shift toggle in Sophia.  If set every VBLANK, for example, you can get 160x192x45 colors.

 

No way! This is incredible. ?

[tane]

On 8/23/2021 at 10:40 PM, phaeron said:

making network access

Feature: What about support to Kaillera for online players in a network game?

 

 

The only information related was asked before years ago in this forum:

https://atariage.com/forums/topic/273633-altirra-300-released/?do=findComment&comment=4060815

 

[phaeron]

1 hour ago, tane said:

Feature: What about support to Kaillera for online players in a network game?

 

 

The only information related was asked before years ago in this forum:

https://atariage.com/forums/topic/273633-altirra-300-released/?do=findComment&comment=4060815

 

Can't, 32-bit binary-only library with incompatible license (actually, seems to have no license, which is even worse).

[drpeter]

21 hours ago, patjomki said:

 

 

  On 8/24/2021 at 2:35 AM, Synthpopalooza said:

There's also the GTIA Graphics 10 shift toggle in Sophia.  If set every VBLANK, for example, you can get 160x192x45 colors.

 

No way! This is incredible. ?

 

You only get 160x192x45 colours sort of, unfortunately, there are significant restrictions in both how the pixels and the colours can be formatted.

 

In a similar sense, but in a different way, that you can get 192x240 x 128 colours, with restrictions, in wide playfield mode of ANTIC mode E (Graphics 15) using display list interrupts or a screen kernel.

Edited August 26, 2021 by drpeter

[FULS]

On 8/22/2021 at 11:27 PM, phaeron said:

https://www.virtualdub.org/beta/Altirra-4.00-test38.zip
https://www.virtualdub.org/beta/Altirra-4.00-test38-src.7z

 

• Fixed a stack overflow crash that could occur when switching between pane layouts, such as entering or exiting the debugger, on a multi-mon system with different DPI scales on each monitor.

 

phaeron,

Thanks for this fix!

Every time I would enter into the debugger it would crash. Did not know what was causing the problem. I thought is was just me or my computer having the problem.

Since Altirra 3.0 debugger worked, I just used that ver. for awhile. How did you find this bug? Has anyone else encountered this?

Again, I'm so grateful you fixed this.

[ilmenit]

22 hours ago, phaeron said:

Can't, 32-bit binary-only library with incompatible license (actually, seems to have no license, which is even worse).

Not only closed source and without a license but also quite dead and exploitable.

[phaeron]

3 hours ago, FULS said:

phaeron,

Thanks for this fix!

Every time I would enter into the debugger it would crash. Did not know what was causing the problem. I thought is was just me or my computer having the problem.

Since Altirra 3.0 debugger worked, I just used that ver. for awhile. How did you find this bug? Has anyone else encountered this?

Again, I'm so grateful you fixed this.

Bug report sent by email which noted that downgrading Altirra's DPI awareness in compatibility options fixed it, which was enough to determine the steps to repro locally.

[patjomki]

On 8/26/2021 at 5:48 PM, drpeter said:

 

You only get 160x192x45 colours sort of, unfortunately, there are significant restrictions in both how the pixels and the colours can be formatted.

 

In a similar sense, but in a different way, that you can get 192x240 x 128 colours, with restrictions, in wide playfield mode of ANTIC mode E (Graphics 15) using display list interrupts or a screen kernel.

 

Damn. I thought that there were more than 5 colours possible in one scanline (apart from midscreen colour change in a dli). But I think we should continue in this thead:

 

 

[drac030]

Feature request. Could the 65C816 emulation optionally be stopped on the following conditions:

 

1) when the code jumps from the mapped RAM/ROM to the middle of nothing (e.g. to the addresses over $3FFFFF when only 4 MB RAM is mapped),

2) when the code jumps into the I/O area $D000-$D7FF;

3) when an instruction is trying to cross the 16 MB boundary (e.g. LDA $FFFFFF,X with X>0),

4) when an instruction is trying to reach into unmapped area (e.g. LDA $800000 when only 4 MB is mapped),

5) when the PC wraps around at a 64k boundary,

6) when the stack wraps around at $0100 and $01FF in emulation mode,

7) when the stack wraps around at $0000 or overlaps with I/O area in native mode,

VIII) when the stack grows down to the zero page in native mode.

 

I think the numbers 1 and 2 would be the most useful. The number 2 might also prove useful in 6502 mode. Thanks in advance.

Edited August 28, 2021 by drac030
added 1

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.00-test39.zip
https://www.virtualdub.org/beta/Altirra-4.00-test39-src.7z

• Added 1050 rev. E to firmware detect list.
• Fixed lack of word wrap in update dialog.
• Audio monitor now dims channels that have been toggled off.
• Fixed extraneous audio pulses in two-tone mode when timer underflow occurred on the same cycle as the timer 1+2 resync.
• Added .vbxe_pal debugger command.
• Fixed a tiny amount of aliasing leakage in audio output (32-bit x86 only).

Regarding the two-tone audio issue -- I tested timer 1+2 two-tone timing against the actual hardware and 3.90+ is correct, with 3.20 being off by two cycles. The actual issue was a corner case in where a resync 1+2 tones signal on the same cycle where an underflow happens causes the output pulse to be suppressed, which wasn't happening and resulting in a pure tone instead of a complex tone. This case wasn't being hit in 3.20 for the pitches involved due to the two cycle difference in period.

 

As this is the first test release after the addition of the Check for Updates feature, it'll be interesting to see how well it works. The feed won't be updated until about 10 minutes after this post lands, since I have to update the feed with the link to this post.

 

21 hours ago, drac030 said:

Feature request. Could the 65C816 emulation optionally be stopped on the following conditions:

 

1) when the code jumps from the mapped RAM/ROM to the middle of nothing (e.g. to the addresses over $3FFFFF when only 4 MB RAM is mapped),

2) when the code jumps into the I/O area $D000-$D7FF;

3) when an instruction is trying to cross the 16 MB boundary (e.g. LDA $FFFFFF,X with X>0),

4) when an instruction is trying to reach into unmapped area (e.g. LDA $800000 when only 4 MB is mapped),

5) when the PC wraps around at a 64k boundary,

6) when the stack wraps around at $0100 and $01FF in emulation mode,

7) when the stack wraps around at $0000 or overlaps with I/O area in native mode,

VIII) when the stack grows down to the zero page in native mode.

 

I think the numbers 1 and 2 would be the most useful. The number 2 might also prove useful in 6502 mode. Thanks in advance.

Too much to add to the core, but I could add these to the verifier, which has a more granular UI anyway.

 

#1 and #4 may be tricky or slow as it's not easy to check for 'unmapped' -- open bus reads are actually another kind of mapped, plus the debugger will insert memory layers.

 

I'm curious about #3. Is 16MB wrapping really an issue? SBC $FFFFFF,X I could see as it's $FF FF FF FF and probably a bogus insn, but LDA $FFFFFF,X only when wrapping?