Altirra 4.00 released

[baktra]

Hello 

@phaeron

would you consider modifying the H: host device emulation to support long file names (not just 8.3)?

Would anyone else use such enhancement?

 

[Mclaneinc]

17 hours ago, Wilheim said:

I just dug up some floppies I had on the ceiling, and I found this piece of software I'm embarassed to show. Anyway, I found that it behaves differently on real hardware vs Altirra.

 

It's supposed to show a "swing effect" at the top of the screen (GUILLERMO FUENZALIDA) with colored fonts, but for some reason it doesn't show up on Altirra. What could be the reason?

ZUPPER.xex 10.76 kB · 14 downloads

If you RESET it then you get the right effect..

[Wilheim]

3 hours ago, Mclaneinc said:

If you RESET it then you get the right effect..

Thank you. I’m just noting something that behaves differently between real hardware and the emulator, and that is when it loads.

[Mclaneinc]

Yeah I know, just wanted you to be able to see it properly..

 

Another one down to odd programming..

 

 

Edited November 16, 2021 by Mclaneinc

[phaeron]

2 hours ago, Wilheim said:

Thank you. I’m just noting something that behaves differently between real hardware and the emulator, and that is when it loads.

It's not really a real hardware vs. emulator issue, as there is no guarantee on the real hardware either as to when in the frame the executable run vector is invoked. The most common way timing gets synchronized in this manner is if the executable is set up to load such that a XL/XE type 3 poll occurs after the last segment load but before run, in which case this will tend to fail at predicable timing around VBI due to the SIO command timeout. But there's no guarantee that this will occur, between the plethora of DOSes/loaders and storage devices that can be used.

 

[Wilheim]

2 hours ago, Mclaneinc said:

Yeah I know, just wanted you to be able to see it properly..

 

Another one down to odd programming..

 

 

Yeah, I programmed it in a time when there was a lack a documentation, tools and/or standards on my country. I did it mainly by intuition.

I can fix the binary it to make it work properly, but I raised the observation just in case it's worth to take action or not on it.

 

EDIT: fixed. Attached now

Zupper Ñoss v2.xex

Edited November 16, 2021 by Wilheim

[mrtwo]

I can't wait to try version 4!  Than you @phaeron!

[Mclaneinc]

13 hours ago, Wilheim said:

Yeah, I programmed it in a time when there was a lack a documentation, tools and/or standards on my country. I did it mainly by intuition.

I can fix the binary it to make it work properly, but I raised the observation just in case it's worth to take action or not on it.

 

EDIT: fixed. Attached now

Zupper Ñoss v2.xex 12.25 kB · 8 downloads

Well you did a good job, you created a mini game back then, and with little or no documentation I have to applaud your work. The nearest I ever got to a game was a smooth scrolling playfield with a couple of crude static PM's on.

[atarixle]

Sophia II is capable of displaying 16 colors (in DLI, seems like the OS is cropping off the first bit when copying the color value from the shadow register into the hardware register), and separate colors for background and foreground. Will Altirra emulate this anytime soon? (No, VBXE emulation is not doing this)

Edited November 17, 2021 by atarixle

[phaeron]

8 hours ago, atarixle said:

Sophia II is capable of displaying 16 colors (in DLI, seems like the OS is cropping off the first bit when copying the color value from the shadow register into the hardware register), and separate colors for background and foreground. Will Altirra emulate this anytime soon? (No, VBXE emulation is not doing this)

The OS does clear the LSB, yes. It's due to the attract routines still using a mask of $FE when attract mode is disabled.

 

I don't have current plans to emulate Sophia II, sorry. It's a bit involved due to the extra control registers and display features, so not a quick add.

 

VBXE can do what you've described above, it requires setting the XCOLOR bit. Sophia II has the same requirement, it shouldn't be enabling those features unless you set the bit in the hidden control register.

 

[atarixle]

One more tiny question: How do I do this?

[flashjazzcat]

On 11/14/2021 at 12:41 AM, phaeron said:

The device tree now better preserves selection when adding or removing devices.

Thanks for this; really improves usability here.

 

Completely missed this whole release last weekend...

[Teapot]

I downloaded the 2021-10-02 reference manual and noticed the written page numbers in the TOC aren't correct while navigation by clicking is.

 

Also, chapters 2 and 3 are swapped.

[GeoMan]

Just a quick question: what value i have to set for <mapper> with /cartmapper for "5200 64K cartridge"?

 

 

[Mclaneinc]

Avery / anyone, in configure system / audio, what does the second row of audio channels with the R next mean, I feel I should know but there's no mention in the manual..

[+MrFish]

34 minutes ago, Mclaneinc said:

Avery / anyone, in configure system / audio, what does the second row of audio channels with the R next mean, I feel I should know but there's no mention in the manual..

 

"Right" channel, I guess; for when you have stereo POKEY's.

 

[phaeron]

19 hours ago, Teapot said:

I downloaded the 2021-10-02 reference manual and noticed the written page numbers in the TOC aren't correct while navigation by clicking is.

 

Also, chapters 2 and 3 are swapped.

Ah, looks like I need to force update the Table of Contents field. For some reason LibreOffice Writer doesn't do this automatically (tempted to try to find another editor).

 

58 minutes ago, MrFish said:

"Right" channel, I guess; for when you have stereo POKEY's.

Yes, it mutes channels on the secondary POKEY.

[lemiel]

22 hours ago, phaeron said:

Ah, looks like I need to force update the Table of Contents field. For some reason LibreOffice Writer doesn't do this automatically

Microsoft Word also. You have to run it manually. Probably same action in Writer.

[phaeron]

On 11/16/2021 at 6:12 AM, baktra said:

would you consider modifying the H: host device emulation to support long file names (not just 8.3)?

Would anyone else use such enhancement?

Could, though it would also impact the listing mode. Do you have an existing model for this, like another CIO-based interface or H: implementation you've used? I'd want to aim for an existing standard if possible than make something different.

 

On 11/18/2021 at 3:07 AM, atarixle said:

One more tiny question: How do I do this?

You'll want to read through the VideoBoard XE programmer's manual, which explains this option in detail. What you need to do is set the XCOLOR bit in the VIDEO_CONTROL register, which is normally at VBXEBase + $40. This only works for the full FX core, not the GTIA core.

 

On 11/20/2021 at 8:04 AM, GeoMan said:

Just a quick question: what value i have to set for <mapper> with /cartmapper for "5200 64K cartridge"?

Unfortunately, you can't, as this only allows targeting cartridge mapping modes that have assigned codes in the .CAR format. If the mode you're trying to use doesn't have a prefixed number in the cartridge mapping mode dialog, you can't select it via either /cartmapper or a .CAR file.

Edited November 21, 2021 by phaeron

[baktra]

9 minutes ago, phaeron said:

Could, though it would also impact the listing mode. Do you have an existing model for this, like another CIO-based interface or H: implementation you've used? I'd want to aim for an existing standard if possible than make something different.

Thanks for response. For long names, I am using H: device implementation from the atari800 emulator.

https://github.com/atari800/atari800/blob/master/src/devices.c, most of the implementation is in functions named devices_h<whatever>.

 

My personal use case is rather peculiar one - automatic copying of files from emulated tape - WAV file holding Turbo 2000 records  to a H: device, with preserving file names (the names can be up to 20 characters long). Altirra has actually very good signal filters for turbo records.

 

I believe that the 'general public' would benefit from such enhancement too for less peculiar use cases, but what do I know.

[oo7]

On 11/13/2021 at 7:41 PM, phaeron said:

Version 4.00 of my emulator Altirra is out at the usual place:

https://www.virtualdub.org/altirra.html

 

As usual, thanks to everyone who tried the releases or just chimed in on just about anything during the 4.00-test series. Never thought I'd been working on it this long, but here's the highlights (it's been about a year since 3.90):

 

• Tape: New turbo support, tape editor, and support for loading raw tapes directly from .flac files.
• Disk: Atari 815 emulation, 8" disk geometry support, Disk Explorer can now access files in Indus CP/M images, many full disk drive emulation fixes.
• Display: Palette solver, monochrome mode, HDR display support, ANTIC fixes.
• Sound: Improved audio filtering, automatic output switching when using WASAPI output, POKEY fixes.
• Input: Preset template generator for making input maps, low-latency paddle option, retuned trackball speeds, 5200 fixes.
• Devices: Percom AT88-SPD, SIDE 3, 1090 80-column board, Bit 3, virtual FAT16/FAT32/SDFS hard disk; modem, XEP80 and Rapidus fixes.
• UI: Improved dark mode theme support.
• Debugger: Memory window upgraded with variable width, type, and graphics decoding support; improved speed, more banked cartridge debugging support, improved 65C816 native mode support, more timestamped logging options, and more verifier options.

 

As usual, 4.00 final is essentially the same as 4.00-test43, except for version number changes and using the release check-update channel. (Previous thread for 3.90/4.00-test)

 

Note that starting with 4.00, Altirra requires at least Windows 7. For Windows XP and Vista users, there is also a 3.91 maintenance release at the above link, which contains backported changes from 4.00 of critical bug fixes and the latest version of AltirraOS.

 

And, per tradition, starting off the 4.10-test series:

 

https://www.virtualdub.org/beta/Altirra-4.10-test1.zip
https://www.virtualdub.org/beta/Altirra-4.10-test1-src.7z

 

• The device tree now better preserves selection when adding or removing devices.
• AltirraOS updated to 3.32 with fixes for a couple of compatibility issues with the math pack, so B-Graph and House of Usher now work.
• Fixes to the docking UI to reduce glitching when switching layouts or toggling full screen mode, due to panes becoming visible too soon and drawing in weird places before being moved to their final location.
• Fixed a few timing bugs in the standard disk emulator. 810s now produce the head bump sound, the timeout was too short for Record Not Found (RNF) errors, and with long retries the idle timeout was sometimes kicking in too soon. Happy 810 and 1050 now have retuned receive rates.
• The standard disk emulator now attempts to emulate track buffering for the Happy 810, 1050, and Speedy 1050 profiles, where the drive will burst transmit sectors from memory after reading in new tracks. This makes timing closer to the default modes for those drives. The Happy 1050 commands for toggling track buffering are now also support.

 

Why drop OpenGL? That would of gave the emulator longer life. If d3d 9 qnd 11 become obsulete

[Mclaneinc]

Where does it say he's dropping OGL?

 

Have you been snorting pepsi again? 

[flashjazzcat]

27 minutes ago, Mclaneinc said:

Have you been snorting pepsi again? 

Perhaps he opened the display options dialog and noticed the OpenGL option is missing.

[Mclaneinc]

24 minutes ago, flashjazzcat said:

Perhaps he opened the display options dialog and noticed the OpenGL option is missing.

Yep you got me Jon, initially I was just joking re quoting all that with no reference to OGL but yes, I had forgotten it was no longer supported, but I have a good reason, the last time I looked in display settings was when 3.91 was released, and it was still in that, so that stuck in my head as being part of it. I can't say I go in to that part of Altirra very often, that and sound once set I rarely go back.

 

That's my story and I'm sticking to it

[phaeron]

14 hours ago, oo7 said:

Why drop OpenGL? That would of gave the emulator longer life. If d3d 9 qnd 11 become obsulete

No, it wouldn't, especially for a Windows application. All accelerated graphics in current versions of Windows are based on Direct3D 11, and OpenGL does not have the longevity you think it does.

 

OpenGL support in Windows is hit or miss. Windows itself only supports an ancient version of OpenGL (1.1), with the rest being exposed directly by the graphics vendors. NVIDIA is by far the best in this regard; ATI is usually behind in stability and support, while Intel's GL driver is slow and has had some major bugs -- like Inkscape taking a minute to compile shaders on start and then opening stretched. GL support over Remote Desktop is even more hit or miss with it often not being supported, with NVIDIA being the notable exception with the RDP enable in their drivers. Windows on ARM does not support accelerated OpenGL at all, with it only being enabled recently by Microsoft with an OpenGL-to-D3D12 translator instead of actual support to get Photoshop acceleration working.

 

Beyond that, GL mainly has best support on desktop Linux. Mobile is primarily OpenGL ES, not OpenGL, and is gradually moving towards Vulkan. Apple's OpenGL implementation was never very good and is now deprecated in favor of Metal, and when Apple deprecates something, they mean it, with about a 90% chance of removal. WebGL was based on GLES instead of regular OpenGL and on Windows is universally emulated on top of D3D11 through ANGLE by all major browsers. And if anyone told you that a game consoles used OpenGL, they don't know what they're talking about.

 

OpenGL itself is rather old and complex, being based on old API paradigms. It had some significant performance advantages over Direct3D 9 and somewhat over 11, but has problems of its own like excessive state binding. Practical applications built on OpenGL need to use extensions out the wazoo. It's been eclipsed by OpenGL ES for older platforms that need a lighter weight API and by Mantle-inspired APIs like Direct3D 12, Metal, and Vulkan for speed. The result is that industry investment has been moving away from regular OpenGL.

 

Finally, Altirra's OpenGL implementation was very dated. It was based on OpenGL 2.0 with some old extensions and didn't support any of the screen effects or many of the fast color conversion paths. It also didn't use GLSL and couldn't run under OpenGL 3 core profile. Practically, there would have been only two advantages to updating it: (1) accessing Direct3D 11 class features on Windows XP, which was moot as 4.00 dropped XP support and Altirra doesn't use many D3D11-class features, and (2) being able to run with 3D acceleration on WINE in a Linux VM that had working OpenGL but broken D3D acceleration, which was very rare. Neither were compelling enough to warrant trying to update the ball of duct tape and baling wire that was the OpenGL rendering path.