Altirra 3.20 released

[Faicuai]

Well, have been working for sometime on this, and here's the list of three bugs (not sure if they have been already corrected or not):

 

1. Floating Point Package CONFLICT / CRASH (v3.17): when running attached FP-profiler that I have finally completed, TurboBasic, as well as Basic++ crash with v3.17 FP-package, with error "11 Overflow at line 8x"... This, however, does NOT happen with Atari Basic, Basic XL, Altirra Basic, etc.  Worth looking at it, pretty strange. Here's the FP-index tool written in Basic, so you can test on your end:  fptest34.bas    fptest34.lst           
2. Unaccounted RAM on 800/Incognito 52K mode: Altirra OS/800 (3.17) fails to recognize (maybe during OS start / sizing) RAM in the region $C000 to $CFFF. Therefore, all apps. that (correctly) interrogate OS for memory-size, lose access to it (still physically present, though).
3. Protection-crash not being reproduced on Emulator (but appears on actual HW): during final development of new intro-title of revised Bruce Lee, we noticed that the following (and many other) versions consistently crashed on HW, but never did on emulator. Hope you can reproduce on your end (please, note that this is not the final version, as some code was stripped out of it, to avoid this issue):  BruceLee-RC9-New Title Screen.xex   

 

Hope these would be not so difficult to track down. As usual, thanks for your f-amazing work!

Cheers!

Edited August 30, 2019 by Faicuai

[phaeron]

2 hours ago, Faicuai said:

Well, have been working for sometime on this, and here's the list of three bugs (not sure if they have been already corrected or not):

 

1. Floating Point Package CONFLICT / CRASH (v3.17): when running attached FP-profiler that I have finally completed, TurboBasic, as well as Basic++ crash with v3.17 FP-package, with error "11 Overflow at line 8x"... This, however, does NOT happen with Atari Basic, Basic XL, Altirra Basic, etc.  Worth looking at it, pretty strange. Here's the FP-index tool written in Basic, so you can test on your end:  fptest34.bas    fptest34.lst           

Basic++ is failing because it is calling into an undocumented internal routine in the math pack at $DBEB to do a digit shift. This is the only program I've seen use this entry point and there isn't a good precedent or justification for using it in such relatively new software, so I won't be supporting this.

 

Turbo-Basic XL is failing because it is using internal constants from the Atari math pack for the EXP10 function. Normally this isn't an issue because they're internal to the math pack's EXP10 implementation, but the problem is that TBXL has half of the guts of EXP10 reimplemented but still uses the constant tables. If it were just a matter of shifting the constant tables that might be OK, but as it turns out my math pack doesn't even use the same polynomial expansion form that the Atari math pack does, so I don't even have those constants. TBXL is too common to ignore so I'll try to think if there is a way to support this. Can't guarantee anything though, as it has to be reasonably independent -- need to double-check what the common 10^x approximations of the time were.

2 hours ago, Faicuai said:

1. Unaccounted RAM on 800/Incognito 52K mode: Altirra OS/800 (3.17) fails to recognize (maybe during OS start / sizing) RAM in the region $C000 to $CFFF. Therefore, all apps. that (correctly) interrogate OS for memory-size, lose access to it (still physically present, though).

AltirraOS intentionally has a hard stop in its memory routine at $C000. I might be able to raise that to $D000, but would need to check that it'd be reliable with the weird open bus behavior of that model.

2 hours ago, Faicuai said:

1. Protection-crash not being reproduced on Emulator (but appears on actual HW): during final development of new intro-title of revised Bruce Lee, we noticed that the following (and many other) versions consistently crashed on HW, but never did on emulator. Hope you can reproduce on your end (please, note that this is not the final version, as some code was stripped out of it, to avoid this issue):  BruceLee-RC9-New Title Screen.xex   

Check your memory clear settings, this crashes reliably for me in emulation as long as the memory clear setting is set to default. It runs if the memory is set to clear.

[phaeron]

18 hours ago, JAC! said:

I cannot manage to get Altirra 3.20-test24 to load the ".lst" and ".lab" file automatically upon start/entering the debugger when I boot an ".atr".

I works when I load the both files manually via ".loadsym".

Is that a limitation of using an ATR?

Symbols are automatically loaded only for executable programs and cartridges, not for media. Media's trickier because the load process tends to be more complex and you can also rotate the disks around, makes it harder to manage the auto-unload.

[Faicuai]

59 minutes ago, phaeron said:

Basic++ is failing because it is calling into an undocumented internal routine in the math pack at $DBEB to do a digit shift. This is the only program I've seen use this entry point and there isn't a good precedent or justification for using it in such relatively new software, so I won't be supporting this.

 

Turbo-Basic XL is failing because it is using internal constants from the Atari math pack for the EXP10 function. Normally this isn't an issue because they're internal to the math pack's EXP10 implementation, but the problem is that TBXL has half of the guts of EXP10 reimplemented but still uses the constant tables. If it were just a matter of shifting the constant tables that might be OK, but as it turns out my math pack doesn't even use the same polynomial expansion form that the Atari math pack does, so I don't even have those constants. TBXL is too common to ignore so I'll try to think if there is a way to support this. Can't guarantee anything though, as it has to be reasonably independent -- need to double-check what the common 10^x approximations of the time were.

AltirraOS intentionally has a hard stop in its memory routine at $C000. I might be able to raise that to $D000, but would need to check that it'd be reliable with the weird open bus behavior of that model.

Check your memory clear settings, this crashes reliably for me in emulation as long as the memory clear setting is set to default. It runs if the memory is set to clear.

Thanks!!

 

Seems like the reason TBxl fails serves to explains why it may also have problems with Newell's FPP (have not yet them reproduced the issue, but just learned about it recently).

 

With respect to $C000, consider that both OS.b and OSN-6.01 fully supports $C000 as RAM, and size it accordingly. In my humble opinion, scanning / sizing $C000-$CFFF as RAM (if available) would be a mandatory functional requirement to ensure compatibility purposes in Colleen / 800 mode.

 

Thanks for the memory-clear reminder. That surely solves other issues, too... ?

[+JAC!]

16 hours ago, phaeron said:

Symbols are automatically loaded only for executable programs and cartridges, not for media. Media's trickier because the load process tends to be more complex and you can also rotate the disks around, makes it harder to manage the auto-unload.

Is there a way to force it "semi manually" using the .atdbg file? or the command line?

 

EDIT:  I changed to 3.20 final and activate the 3 options in the preferences. Programmer mode, so to say. Unforatuntely even with this settings it does not work when booting an ATR. Would be great if that worked in a future version. Booting an ATR should not be handled too differently from loading an XEX or Powering.up a cartridge, if possible.

Edited August 30, 2019 by JAC!
Change to 3.20 and tested again

[Mclaneinc]

I rarely do screen shots from emulators but I just tried on Altirra using the save frame mode and what I get as a screen shot is not the same ratio as the screen I'm looking at, if I try the true aspect its still 'off'...

 

What is the way to get what is in the window looking right in the screen shot..

 

I can use the clipping tool but I'm sure its just something I'm doing wrong in Altirra..

 

TIA...

[Bikerbob]

Just wanted to post a thanks.

 

This is very cool, I really had not done much with Altirra since back early 2.1 erra, I am playing with 3.9 now.. wow.. so much you can do. I really love my real hardware.. but testing some hardware setups or programs etc.. (I am playing with BBSs) SO MUCH easier in Altirra.. super cool.

 

I find it interesting that EMU on Atari 8-bit is SOO MUCH futher along than the ST..   When dealing with BBS stuff the 850 is in there.. with a modem device already setup for telnet emu.. fantastic!!  Cannot do that with STEEM or Hatari.

 

I am sure its in the docs, but when I want to save a "SYSTEM" config I have.. I use profiles?  

 

Also looking at firmwares etc.. and devices and being able to EMU my real hardware system .. I cannot seem to get the system to boot with a U1mb and a Side2 (even if no cf device has been configed)  I am not positive but I thought in the U1MB firmware if I did not have a PBI device setup I could still use the SIDE2 as a loader.. just not a HDD.. but any combo of U1mb and Side2 is not working.. Note I have loaded the latest Flashjazz firmware in the devices.  Ultimatefirmware for the U1mb 512k and Side2oss (allowing oss cart images?) for the side2.

 

James

[flashjazzcat]

27 minutes ago, Bikerbob said:

but any combo of U1mb and Side2 is not working

Not working how? If the system is locking up, try disabling SDX on the U1MB if you simultaneously have SDX enabled on the SIDE cart (System->Console Switches->Enable Cart SDX).

 

There's really zero advantage to not using the PBI feature of the U1MB, but in any case: disabling the PBI HDD and SDX of the U1MB will definitely allow you to boot the SIDE cart in either mode.

 

Edited August 30, 2019 by flashjazzcat

[+Stephen]

2 hours ago, Mclaneinc said:

I rarely do screen shots from emulators but I just tried on Altirra using the save frame mode and what I get as a screen shot is not the same ratio as the screen I'm looking at, if I try the true aspect its still 'off'...

 

What is the way to get what is in the window looking right in the screen shot..

 

I can use the clipping tool but I'm sure its just something I'm doing wrong in Altirra..

 

TIA...

Pretty sure that is determined with Interlace on vs off (one essentially doubles the height of the screenshot).

[Mclaneinc]

Ah, I'll have a play, not using interlace as standard.. Ta muchly..

[Mclaneinc]

Bang on Stephen...very much appreciated...

[phaeron]

http://www.virtualdub.org/beta/Altirra-3.90-test9.zip

http://www.virtualdub.org/beta/Altirra-3.90-test9-src.zip

 

Rework of video recording engine. Now supports using Media Foundation for recording video directly into Windows Media Video and Audio (WMV7/WMV9) or H.264/AAC. This requires Windows 7 or later, Windows 10 recommended due to improved H.264 encoder. The video recorder also now has options for correcting aspect ratio and targeting standard frame sizes, so you can have the emulator rescale NTSC artifacted video to square pixels and then rescale to 480p or 720p with sharp bilinear. Note that encoding to H.264 can require a lot of CPU, especially since currently the software encoding is used due to a color conversion issue with hardware encoding (very slow NV12 converter in msvproc.dll). A quad-core is recommended for 720p. There may also be Rec. 601 vs. Rec. 709 color issues, so double-check videos uploaded to YouTube, etc. before going live. I may try doing the YUV conversion in the emulator to bypass the Media Foundation YUV handling problems but this is something for another day. WMV7/9 is there as a fallback in case H.264 isn't suitable for some reason but on all systems I've tried it is slower than H.264 encoding. ZMBV is still recommended if you're planning to do post-editing on the video.

 

POKEY audio rendering path has also been tweaked, thanks to this new toy:

 

 

Recorded some waveforms from tap points in the audio circuit and recalibrated the emulator's non-linear output path. The raw output curve is now a bit more aggressive (1-exp(-2.9*i)) and the exponential decay curves have been made shallower (tau=2.6ms, 24.7ms). Amplifier saturation is now emulated at high dynamic volume levels. Also, fixed a bug where volume would double whenever the emulator switched from mono to stereo mixing due to a device needing stereo mixing.

 

Regarding aspect ratio of screenshots, you should be getting the correct aspect ratio when copying or saving a screenshot with the true aspect ratio option. This includes artifacting and (non-)interlacing. It will not match your screen, however, if you have the display stretching mode overridden to Fit to Window or Square Pixels, which causes the display to use a different (inaccurate) pixel aspect ratio.

[scotty]

Thank you as always Avery.

 

[Faicuai]

2 hours ago, phaeron said:

http://www.virtualdub.org/beta/Altirra-3.90-test9.zip

http://www.virtualdub.org/beta/Altirra-3.90-test9-src.zip

 

Rework of video recording engine. Now supports using Media Foundation for recording video directly into Windows Media Video and Audio (WMV7/WMV9) or H.264/AAC. This requires Windows 7 or later, Windows 10 recommended due to improved H.264 encoder. The video recorder also now has options for correcting aspect ratio and targeting standard frame sizes, so you can have the emulator rescale NTSC artifacted video to square pixels and then rescale to 480p or 720p with sharp bilinear. Note that encoding to H.264 can require a lot of CPU, especially since currently the software encoding is used due to a color conversion issue with hardware encoding (very slow NV12 converter in msvproc.dll). A quad-core is recommended for 720p. There may also be Rec. 601 vs. Rec. 709 color issues, so double-check videos uploaded to YouTube, etc. before going live. I may try doing the YUV conversion in the emulator to bypass the Media Foundation YUV handling problems but this is something for another day. WMV7/9 is there as a fallback in case H.264 isn't suitable for some reason but on all systems I've tried it is slower than H.264 encoding. ZMBV is still recommended if you're planning to do post-editing on the video.

 

POKEY audio rendering path has also been tweaked, thanks to this new toy:

 

 

Recorded some waveforms from tap points in the audio circuit and recalibrated the emulator's non-linear output path. The raw output curve is now a bit more aggressive (1-exp(-2.9*i)) and the exponential decay curves have been made shallower (tau=2.6ms, 24.7ms). Amplifier saturation is now emulated at high dynamic volume levels. Also, fixed a bug where volume would double whenever the emulator switched from mono to stereo mixing due to a device needing stereo mixing.

 

Regarding aspect ratio of screenshots, you should be getting the correct aspect ratio when copying or saving a screenshot with the true aspect ratio option. This includes artifacting and (non-)interlacing. It will not match your screen, however, if you have the display stretching mode overridden to Fit to Window or Square Pixels, which causes the display to use a different (inaccurate) pixel aspect ratio.

 

Any way local HW-based H.264 & H.265 encoders could be used or specified, instead of SW-based encoding?

 

I would like to take advantage of the Nvidia P4000 encoders that I have running on my workstation... Even 4:4:4 chroma sub-sampling is supported on H.264 on that config...

 

BTW, a big THANKS for enforcing true-aspect-ratio on frame-grabs!!!

Edited September 3, 2019 by Faicuai

[dmsc]

Hi!

3 hours ago, phaeron said:

POKEY audio rendering path has also been tweaked, thanks to this new toy:

 

Good!! I have the same besides my 800XL    I suppose you already upgraded firmware and unlocked the extras...

 

Have Fun!

 

[Mclaneinc]

I was indeed using square pixels but in my defense I did it because you said it was best for duplicating a PAL display   (You did say it many many versions ago so things may have changed since   )

 

Btw, Nice toy!!

 

Thanks as always Avery...

[Mclaneinc]

Found the culprit (probably the wrong word), scanlines, if that is on the saved frame looks wrong which I can understand why...Actual screenwise it looks great, just on the saved frames...Now I know I can save stuff perfectly..

[phaeron]

On 9/2/2019 at 8:26 PM, Faicuai said:

Any way local HW-based H.264 & H.265 encoders could be used or specified, instead of SW-based encoding?

 

I would like to take advantage of the Nvidia P4000 encoders that I have running on my workstation... Even 4:4:4 chroma sub-sampling is supported on H.264 on that config...

Not yet, there are Media Foundation bugs I need to work around. Right now, the emulator is passing RGB32 to the pipeline, because I didn't want to deal with the mess of YUV formats in Windows. Unfortunately, there is a performance problem in Microsoft's color conversion code that causes this to be slower with a hardware encoder, because the RGB32-to-NV12 conversion is unvectorized and three times slower than the RGB32-to-YV12 converter. So in order to fix this, I need to rework the video recorder to convert RGB32 > YUV 4:4:4, resample, convert to YUV 4:2:2, and then pass that to Media Foundation. As it turns out, I need to look into this anyway because the MS converter is also not setting the color matrix properties, which then invites the Rec. 601 vs. 709 issue. The thing is, part of the reason I wrote Altirra is to get away from this stuff....

 

23 hours ago, dmsc said:

Good!! I have the same besides my 800XL    I suppose you already upgraded firmware and unlocked the extras...

Mine was new enough that everything was already pre-unlocked. Just ran it as it came -- UI's intuitive enough that I figured out most things quickly. The one thing that's been a bit annoying is that I haven't found a fine horizontal adjustment yet. Maybe I should probably read the manual at some point.

 

The other problem is that measuring a running 800XL is a bit like open-heart surgery, with probes sticking out of the patient and the keyboard propped up on a couple of pens. The probes that came with the unit don't have plastic in the right places to safely probe IC pins, so currently I've been hooking to discrete components instead. Need to get a chip test clip or something. At least probing two-tone mode next should be easier as that's all digital domain, instead of me measuring analog signals blindly with barely an idea of how op-amps work.

 

[Bikerbob]

Ok to post questions here? Trying to run BBCS II - BBS program.. set device to 850 with modem.. to receive calls on port 9000- which is the port that is set in the router etc..

 

This is what happens when I call - the program does not look like it has responded.. but since the Altirra is locked up.. not crashed.. I am not sure what happened.. ideas??

 

 

Had someone else call same thing. The issue is not on connect, but I would assume it would see port 9000, when you are connecting.. the client gets nothing on their end. If they disconnect.. THAT LOCKS UP THE EMU.

 

 

 

James

Edited September 4, 2019 by Bikerbob

[Faicuai]

19 hours ago, phaeron said:

Not yet, there are Media Foundation bugs I need to work around. Right now, the emulator is passing RGB32 to the pipeline, because I didn't want to deal with the mess of YUV formats in Windows. Unfortunately, there is a performance problem in Microsoft's color conversion code that causes this to be slower with a hardware encoder, because the RGB32-to-NV12 conversion is unvectorized and three times slower than the RGB32-to-YV12 converter. So in order to fix this, I need to rework the video recorder to convert RGB32 > YUV 4:4:4, resample, convert to YUV 4:2:2, and then pass that to Media Foundation. As it turns out, I need to look into this anyway because the MS converter is also not setting the color matrix properties, which then invites the Rec. 601 vs. 709 issue. The thing is, part of the reason I wrote Altirra is to get away from this stuff....

 

(...)

 

 

Thanks, I can see how the color-space conversion drama is playing out on that pipeline.

 

The only thing that I can't yet understand is why you need to convert from YUV 4:4:4 to YUV 4:2:2.... is that because the H.264 SW encoder reported by Media Foundation (and available to everyone, I suppose) does NOT handle 4:4:4 color sampling?

 

In any case, could you make these two options (YUV 4:4:4 and YUV 4:2:2) available to the end-user as check-boxes, and always defaulting 4:2:2 for everyone's convenience?

Edited September 5, 2019 by Faicuai

[+Stephen]

On 9/2/2019 at 9:12 PM, phaeron said:

POKEY audio rendering path has also been tweaked, thanks to this new toy:

 

 

Damn you - seems they are breeding.  Look what followed my home tonight (gotta compensate my probes and learn to focus a camera):

[_The Doctor__]

you should pm the exact disk images as you have the board set up to phaeron... there is no way for him to know what's going on if he can't look at it live, he could only guess based on what he gets told...

[Mclaneinc]

Small bug / feature..

 

Altirra latest beta isn't seeing images in the users downloads dir, the explorer or the load image see's nothing in there but folders, pop the same files on to the c drive or elsewhere and it picks them up again. Oddly though, if you command line it to the file it will run it. Pretty sure its that old Windows protected folders thing.

Edited September 7, 2019 by Mclaneinc

[solaris104]

On 8/29/2019 at 8:05 AM, phaeron said:

Added the JRC 64K + RAM cartridge type. Cart type 160 is not supported for this, has to be selected manually.

Thank you very much ?

[phaeron]

http://www.virtualdub.org/beta/Altirra-3.90-test10.zip

http://www.virtualdub.org/beta/Altirra-3.90-test10-src.zip

 

Enables support for hardware H.264 encoders in Media Foundation and adds support for YUV conversion within the emulator to bypass the slow stock color space converter. The resampler/conversion routines have been further optimized and the pipeline is now YUV-conversion > upsampling > chroma subsampling, and a faster sample/buffer allocator has been added. Combined with hardware encoding when available, this should significantly reduce CPU usage during encoding. Use the x64 (AMD64) build for best results as the image processing routines run faster in 64-bit. On my XPS 13 potato, this gets 720p60 encoding below 40% of a CPU core.
 

Unfortunately, Media Foundation does not have built-in support for setting the color space properties on the H.264 stream. The emulator always uses BT.709 matrix coefficients when encoding WMV7/9 or H.264, which should be a bit more consistent than previously when msvproc.dll might have used BT.601 for some resolutions. H.264 is still recommended over WMV7/9, with WMV9 being particularly slow -- the profiler shows some unexpectedly poor motion prediction routines. Might be your only option if you are trying to use this on Vista, however.

 

AltirraOS has been revved to 3.22, raises the memory check limit from 48K to 52K on the 800 version.

 

On 9/4/2019 at 2:26 PM, Bikerbob said:

Ok to post questions here? Trying to run BBCS II - BBS program.. set device to 850 with modem.. to receive calls on port 9000- which is the port that is set in the router etc..

 

This is what happens when I call - the program does not look like it has responded.. but since the Altirra is locked up.. not crashed.. I am not sure what happened.. ideas??

 

Had someone else call same thing. The issue is not on connect, but I would assume it would see port 9000, when you are connecting.. the client gets nothing on their end. If they disconnect.. THAT LOCKS UP THE EMU.

Odd. You're getting to the point where the networking code is establishing the connection but not the emulated modem 'connecting', i.e. ATA or ATS0=1 auto-answer completing to CONNECT. The emulator's not supposed to lock up since networking is asynchronous on a worker thread, but I can't tell where it might be jamming up just yet. I would try a localhost connection with a plain terminal emulator first to see if you can get an incoming connection to work. BobTerm is a good one to use, just change the translation mode from Atari to Ascii and enter plain Hayes compatible modem commands.

 

On 9/4/2019 at 4:31 PM, Faicuai said:

Thanks, I can see how the color-space conversion drama is playing out on that pipeline.

 

The only thing that I can't yet understand is why you need to convert from YUV 4:4:4 to YUV 4:2:2.... is that because the H.264 SW encoder reported by Media Foundation (and available to everyone, I suppose) does NOT handle 4:4:4 color sampling?

 

In any case, could you make these two options (YUV 4:4:4 and YUV 4:2:2) available to the end-user as check-boxes, and always defaulting 4:2:2 for everyone's convenience?

The Media Foundation encoder only supports 4:2:2 and 4:2:0, it does not support 4:4:4. Even in that case, I'm not inclined to support chroma subsampling formats other than the most common as it would unnecessarily increase the complexity of this feature. 4:2:0 is the common format for streaming video and the upload format recommended by YouTube, and for hardware encoding support. Those who have stricter requirements on their video encoding can capture video at the raw size to one of the lossless formats and post-process it. This won't be as convenient for everyone, but the point is not to spend too much effort on the video recorder. Already spent more time than I had planned on a spur of the moment feature, but at least video recording in 3.90-test10+ should be much more accessible than in 3.20, given video players unfortunately still shipping a broken ZMBV decoder.

 

On 9/7/2019 at 6:50 AM, Mclaneinc said:

Altirra latest beta isn't seeing images in the users downloads dir, the explorer or the load image see's nothing in there but folders, pop the same files on to the c drive or elsewhere and it picks them up again. Oddly though, if you command line it to the file it will run it. Pretty sure its that old Windows protected folders thing.

Shouldn't be that as neither System Protection nor Controlled Folder Access prevent a program from seeing the files, only writing to them. Having CFA enabled, for example, lets a program see the files but causes the Save As dialog to report "file not found" when you try to save into Documents (which they still haven't fixed despite me reporting it years ago, argh). Do you see the files if you change the file filter to All Files?