Altirra 4.00 released

[Mclaneinc]

Avery, I ask this simply because it seems to be the go to display mode to add on, I'm talking Vulkan. Is it any use as I know nothing really about it other than every 3D emu seems to have it now..

[baktra]

In most cases and if possible, it is a wise choice to streamline the code by removing support for outdated or problematic libraries. I am wondering, when I deselect both Direct3D 9 and Direct3D 11, what Altirra uses for drawing? GDI? 

 

Vulkan is more viable and up-to-date technology these days. However, can Altirra (2D software and Windows-only) really benefit from using it?

 

If there is something I would give the OpenGL a credit for, it is accessibility to the beginners. If you needed introduction to the world of 3D programming, OpenGL was a library of choice. No heavyweight SDKs to install, just several dozen of lines of code and your first 3D cube was on screen (if you didn't to forget to add the ambient light :-))

[phaeron]

1 hour ago, Mclaneinc said:

Avery, I ask this simply because it seems to be the go to display mode to add on, I'm talking Vulkan. Is it any use as I know nothing really about it other than every 3D emu seems to have it now..

Vulkan can enable both higher performance and better functionality. It's one of the newer APIs designed for modern GPUs that are designed to take large batches of drawing commands with less CPU overhead.

 

The catch is that this depends on both the program and the graphics driver being well optimized for Vulkan. This isn't always the case and so it's possible to see Vulkan being slower -- or more buggy. For one of the games I play, the advice is as follows:

• If you are having performance or stability problems with DirectX 11, switch to Vulkan.
• If you are having performance or stability problems with Vulkan, switch to DirectX 11.

When it works out well, Vulkan can be a lot faster -- like 30%+ faster. When it doesn't work out well, you can get some really gnarly graphical bugs.

 

50 minutes ago, baktra said:

In most cases and if possible, it is a wise choice to streamline the code by removing support for outdated or problematic libraries. I am wondering, when I deselect both Direct3D 9 and Direct3D 11, what Altirra uses for drawing? GDI? 

Yes, Altirra has a fall back all the way to GDI and it is always enabled. Thus, it will run even if there is no graphics accelerator all, though with poor performance, some functions disabled, and others using software rendering.

 

50 minutes ago, baktra said:

Vulkan is more viable and up-to-date technology these days. However, can Altirra (2D software and Windows-only) really benefit from using it?

Not much, since Altirra does very few draw calls. But it also doesn't run much else in normal configuration, so there are potentially some power efficiency gains to be made by using Vulkan or DirectX 12. There are also some interesting features that can be unlocked by using Vulkan that aren't available in Direct3D, such as low-latency triple buffering.

 

The main reason I haven't looked into Direct3D 12 or Vulkan, besides the work involved, is that the last time I profiled the graphics pipeline it looked like the final Present() call was a large portion of the display load. Present() is the final call that pushes the rendered frame to the display. This work is largely common across all graphics APIs on Windows, so if most of the work is in Present(), then it's unlikely that D3D12/Vulkan would help much. IIRC, there are also some other limitations with Remote Desktop and other scenarios that are fine with D3D9/11 but not necessarily supported with the pedal-to-the-metal APIs.

 

The actual drawing itself wouldn't be any more efficient under Vulkan, since it's just big quads with relatively standard shaders. The one case that does matter in this regard (fill rate) is D3D9 vs. D3D11. One of the reasons that Altirra still supports and defaults to Direct3D 9 is that it is needed to access half float in pixel shaders on Windows 7, since minimal precision in D3D11 requires Windows 8. Some integrated graphics chips can render up to twice as fast with half precision.

 

50 minutes ago, baktra said:

If there is something I would give the OpenGL a credit for, it is accessibility to the beginners. If you needed introduction to the world of 3D programming, OpenGL was a library of choice. No heavyweight SDKs to install, just several dozen of lines of code and your first 3D cube was on screen (if you didn't to forget to add the ambient light :-))

OpenGL was more accessible to beginners. It's been a long time since glBegin()/glEnd() was the recommended way to render graphics. Now you're expected to set up vertex and fragment programs and source geometry from buffers like in most other APIs. This is a lot more work for a simple quad. There are also more than enough gotchas in the fixed function pipeline that it's better to start with shaders to begin with than to learn FF and then shaders.

 

It's also unfortunately more of a pain to use GL on Windows. The OS still ships ancient OpenGL 1.1 bindings, so in practice it's mandatory to do either a ton of dynamic bindings via GetProcAddress() or leveraging a library like GLEW to handle it. That's on top of the other work needed to bootstrap OpenGL, such as creating a window and setting up the GL context with a compatible pixel format.

 

The overarching issue is the annoying notion that standardized accelerated 2D APIs aren't needed because 3D APIs exist. The result is that simple operations like drawing a circle require a daunting amount of setup for someone not using a canned engine or UI library. Direct2D might have been a decent solution for this on Windows except that it's surprisingly poorly designed.

 

[scitari]

Huge thank you for Altirra and this new version 4.00!!! I greatly appreciate all your hard work. 

 

I was curious to try out the 815 drive and was able to add it from the Configure System menu. However, I noticed the 815 option was missing from Disk Drives emulation list under the File menu. Was this an oversight or is there a reason it can't be added from here? I assume it is because the RPMs can be set using one of the other drives. Maybe it should be there for completeness? Thanks again!

[Mclaneinc]

 

Not sure why there's no emulated device, but as it hardware emulated, I don't think it needs a software version.

 

Edit: Wow, that 815 is a weird old drive, just read a thread on here about it. 2 drives in one and totally non-compatible with standard drive types..What an odd choice by Atari, I'd presume that is why it's not software emulated as well.

Edited November 27, 2021 by Mclaneinc

[phaeron]

2 hours ago, scitari said:

I was curious to try out the 815 drive and was able to add it from the Configure System menu. However, I noticed the 815 option was missing from Disk Drives emulation list under the File menu. Was this an oversight or is there a reason it can't be added from here? I assume it is because the RPMs can be set using one of the other drives. Maybe it should be there for completeness? Thanks again!

Well, the first issue is that the 815 is extremely rare, so the only way to see its behavior was to add full drive emulation for it first. But beyond that, the 815 is an odd drive to emulate -- for the most part it's just a double-density only drive that's slower and has more bugs than other double-density capable drives. Not sure it's worth the effort to implement all of the 815's unique quirks into the standard drive emulator. Most of the other standard drive emulation profiles are just tweaks to timing and command set.

 

[reifsnyderb]

phaeron, In addition to thanking you for Altirra, I'd like to mention that your Hardware Manual is really top-notch.  Thank you!

[phaeron]

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

• Debugger: Fixed cycle counting error that caused negative unhalted cycle counts in the profiler around WSYNC writes.
• Devices: 850 bootstrap relocator length padded to same length as original hardware to fix compatibility issues with hardcoded loaders, particularly Bobterm.
• Devices: NVRAM is now stored into profiles and has its own profile category.
• Display: Added workaround for crash in Intel Iris Xe graphics driver in D3D11 mode. (min16float4 interpolator copied to min16float4 output -> crash, thanks Intel.)
• Display: Additional precision improvements in high artifacting algorithms.
• Display: Added support for using the system-wide SDR intensity value in HDR mode.
• HDevice: Added long filename mode.

[davor]

3 hours ago, phaeron said:

• Display: Additional precision improvements in high artifacting algorithms.

A very minor issue: The AltirraOS XL/XE boot screen (the Amiga-like "waiting for disk" screen), enabling artifacting, the text looks too blurry.

 

Sorry for being so picky... your software is really well designed.

[mr-atari]

Just a short question:

Did you fix/found the ATBasic bug when during open/put routine the disk is full and a DIR on a next disk (to see it's content) writes the remaining data out?

Grtz!

[baktra]

I am grateful for the H: device enhancement. COPY T2/H works with it like charm.

I will try more usage scenarios.

[phaeron]

12 hours ago, mr-atari said:

Did you fix/found the ATBasic bug when during open/put routine the disk is full and a DIR on a next disk (to see it's content) writes the remaining data out?

Have a fix pending, but it needs testing.

 

[Keatah]

Someone sent me a 4k savestate file. How (if possible) can I determine what os/kernal file I need to use? And what the configuration/model of the machine is?

 

I haven't used savestates much in Altirra. And when I do they're in my environment, so they work.

[phaeron]

4 hours ago, Keatah said:

Someone sent me a 4k savestate file. How (if possible) can I determine what os/kernal file I need to use? And what the configuration/model of the machine is?

 

I haven't used savestates much in Altirra. And when I do they're in my environment, so they work.

If it's from a recent version that uses the new save state format (*.atstate2), rename the file to .zip and extract savestate.json. There will be an ATSaveStateFirmwareReference object in it containing the original firmware path and CRC32.

[ggn]

Hi @phaeron,

 

When I try to boot Flop #66 with drive emulation level "XF551" and all SIO d: patches off, as well as d: burst I/O off, something seems to be going wrong in Altirra. The loading becomes erratic, freezing at random points, then continuing, while the sector counter goes all over the place. Eventually the emulated machine crashes without even turning the palette black. Just to be sure, I tried this with 4.10-test2 and it still doesn't work.

 

I just tested this on a real XF551 attached to an 800XL, the loading there happens just fine and I get to the intro and the rest just fine.

 

Link to Flop #66:

 

 

Regards.

[R0ger]

I doubt it's Altirra issue. Does it work on real hardware with same speed settings ?

[snicklin]

@phaeron A question for you, when people say that they've had problems with Altirra, would it be easier if they also sent a config file or a crash file or something else to you to show the precise nature of their issue? This isn't aimed at anyone in particular, but they may have setting X or Y for one part of the system, but they haven't mentioned maybe that they're on PAL or NTSC or could have a different memory setting. It must make it really difficult for you to debug.

[_The Doctor__]

quoting      'I just tested this on a real XF551 attached to an 800XL, the loading there happens just fine and I get to the intro and the rest just fine.

 

sounds like it works on real hardware...

 

what speed is it loading with on the real hardware... is it sounding the same in Altirra speed etc...? accurate emulation selected with XF551 full emulation device and your firmware/rom installed in altirra?

Edited December 5, 2021 by _The Doctor__

[phaeron]

8 hours ago, ggn said:

When I try to boot Flop #66 with drive emulation level "XF551" and all SIO d: patches off, as well as d: burst I/O off, something seems to be going wrong in Altirra. The loading becomes erratic, freezing at random points, then continuing, while the sector counter goes all over the place. Eventually the emulated machine crashes without even turning the palette black. Just to be sure, I tried this with 4.10-test2 and it still doesn't work.

It looks like the XF551 high speed loader on this disk is sensitive to C/E-to-data timings -- it uses the hack of changing the serial port speed from the serial ISR in the middle of the stock OS SIO routines, which are a bit slow at revectoring from C/E byte to the read buffer. I'll try retuning the C/E delay for the XF551 profile of the standard disk emulator.

 

[Frozone212]

would you consider a built in assembler to save having to download one each time?

[ggn]

9 hours ago, R0ger said:

I doubt it's Altirra issue. Does it work on real hardware with same speed settings ?

Yes, tried that last night.

[R0ger]

18 hours ago, ggn said:

Yes, tried that last night.

Interesting. I had some trouble debugging the code to run properly at different speed settings .. but of course I didn't test all options.

I totally didn't grasp some of the issues .. I think there are some collisions between Antic DMA and loading .. and during some phases of the boot there is actually text screen mode with badlines and all .. so I actually would expect trouble. I wouldn't be surprised if it is actually FLOP problem.

But if it works on real HW .. well Phareon is in for a ride

 

[phaeron]

23 hours ago, Frozone212 said:

would you consider a built in assembler to save having to download one each time?

Uh, not really -- it's something you only need to do once. For really short asm fragments, there's a miniassembler built into the debugger:

Altirra:0> a 600
0600: A9 00          lda #0
0602: A2 0F          ldx #$0F
0604:                loop:
0604: 8D 1A D0       sta colbk
0607: 8D 0A D4       sta wsync
060A: 8E 1A D0       stx colbk
060D: 8D 0A D4       sta wsync
0610: 4C 04 06       jmp loop
0613: end

For longer programs, well... you need to go get a real assembler. I have thought about writing a full assembler, but not for inclusion with the emulator. There are lots of variations on the assembler, and it would be difficult to write one that would accommodate all of the different flavors of ATasm, CA65, MADS, MAC/65, etc. Plus, it'd be awkward to have an assembler tied to the emulator such that upgrading one would require upgrading the other.

 

The recommended flow for using Altirra to debug or test assembly code is to run the assembler of your choice and then tell Altirra to restart with the new code. This is done by running altirra.exe in single instance mode or with the /si flag (/si = single instance), which causes it to restart the emulation while booting the executable, reusing the current instance of the emulator.

 

The reason I've wanted to write an assembler is to make it easier to write and maintain some of the 6502 code that is built into the emulator itself. That code is currently assembled using MADS, but there are some limitations with that assembler, particularly when generating relocatable code. Writing a multi-pass MADS-compatible assembler is not simple, though, so I haven't gotten anywhere on it.

 

[oo7]

nevermind was my own issue.

Edited December 6, 2021 by oo7
error

[Wrathchild]

On 12/4/2021 at 10:51 PM, snicklin said:

would it be easier if they also sent a config file or a crash file or something else to you to show the precise nature of their issue?