Altirra 4.00 released

[Mclaneinc]

Oh come on, where's the fun in that

 

Avery just loves the old, I don't know what I did, I can't remember what the program was but can you fix it..

[+MrFish]

@phaeron

Can you provide a little information about the Atari OS-B (NTSC) ROM that gets labelled as "patched" in the Firmware Manager? 

Thanks

 

[+DjayBee]

AFAIK it's the one coming with PC Xformer

[+MrFish]

3 hours ago, DjayBee said:

AFAIK it's the one coming with PC Xformer

OK, that's a start. I wonder what they did to it though.

 

It looks like it has only 17 bytes that are different from Atari's original OS-B (NTSC) ROM.

 

[Mclaneinc]

Someone did say what the patch was for, I keep hearing CIO in my head, but I know that Avery does know what the patch was for as he's mentioned it in the past..

[atarixle]

On 11/26/2021 at 9:08 PM, phaeron said:

(2) being able to run with 3D acceleration on WINE in a Linux VM ...

On my Intel Core 2 Duo Laptops, Altirra in WINE runs slow, no matter what system renders the output, or what GPU I use. Strangely, on Windows it runs quite well on the very same machine. That's why I tried ReactOS in a VM, and when I set the VM output scale to 2x, then I have Altirra in 2x with the performance of Altirra 1x. But actually it is not worth the effort because ReactOS itself is a pain.

[phaeron]

17 hours ago, MrFish said:

@phaeron

Can you provide a little information about the Atari OS-B (NTSC) ROM that gets labelled as "patched" in the Firmware Manager?

 

4 hours ago, atarixle said:

On my Intel Core 2 Duo Laptops, Altirra in WINE runs slow, no matter what system renders the output, or what GPU I use. Strangely, on Windows it runs quite well on the very same machine. That's why I tried ReactOS in a VM, and when I set the VM output scale to 2x, then I have Altirra in 2x with the performance of Altirra 1x. But actually it is not worth the effort because ReactOS itself is a pain.

Most of the time when I see this, it's because the WINE environment doesn't support DirectX 9 acceleration. Run altirra /startuplog:hostdisp, and you should see something like this in the console:

[ 0.154] HOSTDISP: VideoDisplay/DX9: Successfully created Direct3D 9 device.
[ 0.154] HOSTDISP: Device: igdumdim64.dll (Intel(R) Iris(R) Xe Graphics)
[ 0.154] HOSTDISP: DeviceCaps: VS3.0, PS3.0, MaxTex 8192x8192, ReadScanline Yes, HWVP

If you see "llvmpipe" appear as the graphics device instead, you are running in 3D software rendering, which will be very slow as the CPU is used to emulate a GPU. Altirra won't detect this, as WINE presents it to the Win32 side as a hardware accelerated device.

 

Unfortunately, Core 2 Duos are already just barely on the low end of being able to support proper 3D acceleration in Altirra. You likely have somewhere between a GMA 900 to GMA X3000 graphics core, which means barely DX9 pixel shader 2.0 and possibly not even hardware vertex shaders. Which is fine when you're running on Windows, but when trying to run it on WINE, that means you need OpenGL support high enough to emulate Direct3D. Which is difficult when those parts barely support even OpenGL 1.4-1.5, and certainly not Vulkan.

 

There are two things you can try. The first is to back down to Altirra 3.91 to see if either its OpenGL or DirectDraw modes might perform better. The other thing you can try is to just reduce the graphics settings to lighten the load, if you are indeed running on llvmpipe, is to change the stretching mode from Sharp Bilinear to Bilinear. This uses a cheaper pixel shader for the largest amount of drawing on the screen, though it's still likely too slow to do full screen.

 

[atarixle]

This is what I get on a MacBook3,1 Intel Core 2 Duo with X3100 graphics (debian 11, just wine (wine64) installed):

[ 0.725] HOSTDISP: VideoDisplay: Current monitor update: 0000000000000000 -> 0000000000000001.
[ 0.744] Initiating cold reset
[ 0.749] Initializing full screen mode
[ 0.750] Running main loop
[ 0.838] HOSTDISP: VideoDisplay: Monitor switch detected -- reinitializing display.

Setting older Atlirra versions to OpenGL hasn't been helpful either.

But as long as we have atari800 as a linux native, it is fine to keep Altirra (wine) just as a backup for the latest demos. And I really thank so much you for explaining so many insights about Altirra and the accelerated output handlings.

Setting the graphics to the minimum, and zooming in via compiz is a pretty good way to watch the 2nd life demo (Silly Venture 2019).

The good side is that Altirra (wine) runs pretty good on my 2012 Intel i5 netbook, and on the one other slightly newer PCs.

 

EDIT:

Setting to DX9 shows me this:

[830.986] HOSTDISP: VideoDisplay/DX9: Successfully created Direct3D 9 device.
[830.989] HOSTDISP: Device: igdumd32.dll (Mobile Intel(R) 965 Express Chipset Family)
[830.989] HOSTDISP: DeviceCaps: VS3.0, PS3.0, MaxTex 8192x8192, ReadScanline No, HWVP
[830.990] HOSTDISP: VideoDisplay/DX9: Init successful on adapter 0 (\\.\DISPLAY1 / igdumd32.dll), monitor 0000000000000001.
[830.996] HOSTDISP: VideoDisplay/DX9: Init successful for 336x240 source image (Pal8 -> XRGB8888); monitor=0000000000000001

And this is what I get when switching to DX11:

0038:err:d3d:wined3d_debug_callback 0xd84d20: "GL_INVALID_ENUM in glBindBufferARB(target GL_UNIFORM_BUFFER)".
0038:err:d3d:wined3d_buffer_gl_create_buffer_object Failed to bind the BO with error GL_INVALID_ENUM (0x500).
0038:err:d3d:wined3d_buffer_gl_create_buffer_object Failed to create a buffer object. Continuing, but performance issues may occur.
0038:err:d3d:wined3d_cs_exec_update_sub_resource Failed to load buffer location.
0038:err:d3d:wined3d_debug_callback 0xd84d20: "GL_INVALID_ENUM in glBindBufferARB(target GL_UNIFORM_BUFFER)".
0038:err:d3d:wined3d_buffer_gl_create_buffer_object Failed to bind the BO with error GL_INVALID_ENUM (0x500).
0038:err:d3d:wined3d_buffer_gl_create_buffer_object Failed to create a buffer object. Continuing, but performance issues may occur.
0038:err:d3d:wined3d_cs_exec_update_sub_resource Failed to load buffer location.
0038:err:d3d:wined3d_cs_exec_update_sub_resource Failed to load buffer location.

 

Edited December 11, 2021 by atarixle

[phaeron]

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

• VFS: Fixed off-by-one error when accessing files on a DOS 2 image using the atfs:// prefix.
• ATBasic: IOCB#7 is now automatically closed on I/O errors to avoid SAVE files being kept open for write.
• Disk: Retuned XF551 high speed C/E to data frame delay based on firmware timings.
• Additions: Fixed incorrect device ID in loadexe.xex.
• HLE: "Disk boot" program load mode now simulates an SDFS disk to trigger the EXE load under SDX.

 

3 hours ago, atarixle said:

This is what I get on a MacBook3,1 Intel Core 2 Duo with X3100 graphics (debian 11, just wine (wine64) installed)

Hardware-wise, 965G/X3100 should be enough to run everything on that display (1280x800), as the lower end 945G can.

 

Software-wise, it definitely looks like something is busted in WineD3D with this configuration. The reported DX9 caps are correct for that hardware, but it shouldn't be running slow with a relatively simple display config at full-screen.

 

The warnings you're getting in DX11 mode are from WINE and indicate that that mode is not likely to work at all. Altirra actually runs DX11 in the 9_1 feature profile, so it should be able to run even DX11 on that hardware, but it looks like WINE is trying to use DX11-class features and failing. This will break the display as Altirra has no idea this is happening and can't drop to DX9 in response.

 

[atarixle]

Very same machine, but Mac OS X Lion, Altirra (32 Bit) runs in wineskin winery 1.7 (last known to me working on Lion), 49.xx FPS, 32% CPU utilizing DX9 in the Tools-Settings.

Unfortunately, there is no downloadable wineskin 1.7 anymore for this old setup.

[DFELD2005]

QUESTIONS ABOUT CHEAT FILE FORMATS

Altirra is able to Load a cheat file in the a8t format and the atcheats format.

Altirra is able to Save a cheat file in the atcheats format.

Can Altirra export a cheat file in the a8t format?

 

Atari800Win (v4.1) is able to Load a cheat file in the a8t format.

Atari800Win (v4.1) cannot import a cheat file in the atcheats format.

Is there any software to interconvert these two formats so these two emulators can share cheat information?

 

THANK YOU

[Mclaneinc]

 

Just a quick no and no

 

Just remember that Atari800Win stopped being updated many years ago, the difference between Altirra, and it is immense, sure Win will play a lot of stuff but not always in the right way but it's stable enough to be ok much of the time.

[phaeron]

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

• Fixed crash with loading some FLAC files.
• Accelerated C: loads now properly leave tape running after block load. This fixes some tape loaders that mix C: loads and custom tape routines.
• Fixed regression with FSK pulse blocks in .CAS files being loaded as turbo data instead.
• Improved frame rate stability with windowed vsync in D3D11 mode on Win8.1+.
• /startuplog: now allows disabling log channels and blocks Ctrl+C.
• C: patch can now load blocks longer than 30 seconds. (There are tapes with single blocks that are minutes long.)
• Tape editor: fixed draw tool with waveform displayed, SIO capture option now shows enabled state, accelerated C: loads show sync bytes, and block checksum status displays more reliably during live captures.

The tape editor now also has a feature where it will attempt to identify the position of a bit error in an SIO data capture, by highlighting it in purple:

 

 

Sadly, unlike a CRC, it isn't possible with the SIO checksum to identify which bit is likely to be bad since the SIO checksum is just a simple sum of all bytes. However, what is possible is to check whether the computed and recorded checksums differ by the value of a single bit. The tape editor now does this, and highlights the bit position in purple. This narrows down the bit error to a specific bit position among all of the bytes in the record, and helps guide manual repairs to the bitstream.

 

[Luke210]

There is something wrong with monitor mode, only "amber phosphor" is working (?).

[Mclaneinc]

All four monitor phosphor modes working here on beta 4

[Luke210]

No if You choose to emulate VBXE (maybe it's intended?).

[Mclaneinc]

Pass, didn't try VBXE..Will try now.. But there are somethings in the display department that get turned off in VBXE (artifacting etc)

 

Can confirm only Amber, but no idea if it's meant?

Edited December 20, 2021 by Mclaneinc

[glurk]

Posting here so as to not start a new topic for one question.  Using the Stella 2600 emu, you can press Alt/L and get a scanline count.  How the heck can I do this in Altirra?  I know about .dumpdlist to show the display list, but it does not give a count.  I'm sure it CAN do it, I just can't figure out how.

 

[phaeron]

3 hours ago, Luke210 said:

There is something wrong with monitor mode, only "amber phosphor" is working (?).

Confirmed for VBXE, fix queued for next test release.

 

48 minutes ago, glurk said:

Posting here so as to not start a new topic for one question.  Using the Stella 2600 emu, you can press Alt/L and get a scanline count.  How the heck can I do this in Altirra?  I know about .dumpdlist to show the display list, but it does not give a count.  I'm sure it CAN do it, I just can't figure out how.

There is no equivalent to Alt+L in 800 emulators because it isn't needed. On the 2600, the program is responsible for vertical timing and thus checks are necessary to ensure that the sync signals occur at the right intervals to avoid a rolling display or lack of display at all. On the 800, this isn't possible because ANTIC controls vertical timing. Regardless of the display list or whatever the program does, the display list is limited to 240 scanlines and the frame is always 262 or 312 scanlines.

 

As for .dumpdlist, it isn't possible to statically determine the height of the display list when vertical scrolling is involved, since the height will vary dynamically based on the setting of the VSCROL register. Beyond that, it isn't something I've ever needed since the display height is something you normally take into account when the display list is created, and it is relatively simple to compute it. If you go over the limit, the result is typically rather blatant glitching. But I could be convinced otherwise.

 

[glurk]

@phaeron I'll just ask you directly.  I'm working on a 2600->8bit port, which is a subject you certainly know well   And I was trying to make everything scan-line-number precise.  But there seems to be an approx.  6<->11 scanline difference between Stella and the A8.  And I'm just trying to figure out why that is...

 

EDIT TO ADD: My thinking is that it's probably an "off by 8" difference between TIA and ANTIC due to some hardware difference that I'm unaware of.  As to where the scanline count begins.  Or perhaps I'm mistaken...

Edited December 21, 2021 by glurk

[_The Doctor__]

None the less, it's useful to see the count during free form programming when working in/with multiple target and sources... 2600 to NTSC or PAL 8 bit etc...

[phaeron]

1 hour ago, glurk said:

@phaeron I'll just ask you directly.  I'm working on a 2600->8bit port, which is a subject you certainly know well   And I was trying to make everything scan-line-number precise.  But there seems to be an approx.  6<->11 scanline difference between Stella and the A8.  And I'm just trying to figure out why that is...

 

EDIT TO ADD: My thinking is that it's probably an "off by 8" difference between TIA and ANTIC due to some hardware difference that I'm unaware of.  As to where the scanline count begins.  Or perhaps I'm mistaken...

There is a more basic misconception here, which is that there isn't anything to compare between TIA and ANTIC for scanline numbering in the first place. TIA has no notion of vertical positioning or scanline numbers whatsoever. It has no vertical counter and no P/M graphics DMA, and vertical timing is entirely under program control. Any scanline numbers you're seeing in a 2600 emulator are solely from that emulator; unlike ANTIC, which has specific numbering schemes in VCOUNT and in P/M graphics addressing, there is nothing in the 2600 hardware to suggest any sort of canonical scanline numbering, much less one that would match ANTIC. Thus, there is no reason to expect that scanline numbers would match between Stella's debugger and ANTIC or Altirra's debugger, no matter how meticulous the port.

 

The other place you might get this kind of error is if you try hooking up the 2600 game's vertical blank routine to ANTIC's VBI. This is wrong for many reasons, one being that 2600 games typically start vertical blank earlier than ANTIC does. Another reason is that positioning relative to vertical sync is what matters, not vertical blank. If you really wanted to exactly match the original game's positioning, you would need to count scanlines from VSYNC start/end to the display kernel and compare that against ANTIC's vsync timing. But that assumes that there is value to matching the original game's vertical centering, which there really isn't. It's easier just to make the new display list / kernel where it looks best than meticulously counting RIOT/6507 cycles and STA WSYNCs between VSYNC and the original display kernel.

 

Scanline numbers also appear in sprite positioning, but that typically needs to be redone from scratch anyway as sprites are moved from the display kernel to P/M DMA. Any vertical positions in the game code will be relative to the display kernel instead of any global scanline numbering, and they may even be the wrong sign for the kernel's convenience, and on top of that there are often additional +1/+2 adjustments due to VDELAY shenanigans. In most cases it's easier just to port over the graphics and then tweak an offset until they're back in the right place relative to the playfield.

 

[_The Doctor__]

okay but we still do all of that counting by hand (in our head and design) and then can get an idea from there between the two. It's not that it matches up in the programming exact in that but we still can count the scanlines and frame it from there to what we are going to do on our target... if it's of no use to you it's understood and we can still use pencil and paper to do so... it's a matter of convenience and speed I guess, as it can give a hint to whats left to work with.

[glurk]

I completely do "get" what's being said.  And I am using offsets to correct things.  But if you have a canonical / "perfectly written" 2600 game with 262 scanlines, 131 is dead-center.  And that position surely corresponds to some ANTIC scanline.  So I guess my question is, which ANTIC scanline # is dead center?

 

I do apologize if I'm being daft here, I'm just trying to find some numerical way to get this correct.  Because right now, I'm turning on scanline visualization, staring at the screen, and COUNTING them.  And it kinda sucks...

[phaeron]

19 minutes ago, glurk said:

I completely do "get" what's being said.  And I am using offsets to correct things.  But if you have a canonical / "perfectly written" 2600 game with 262 scanlines, 131 is dead-center.  And that position surely corresponds to some ANTIC scanline.  So I guess my question is, which ANTIC scanline # is dead center?

 

I do apologize if I'm being daft here, I'm just trying to find some numerical way to get this correct.  Because right now, I'm turning on scanline visualization, staring at the screen, and COUNTING them.  And it kinda sucks...

ANTIC visible display range is 8-247 (240 scanlines), of which the OS uses 192 with 24 blank lines of padding at the top. Thus, to match the OS's screen centering, you'd want the halfway point of your display to be at scanline #128, or 120 scans past the start of the display list (which always starts at 8).