Altirra 4.10 released

[Keatah]

Working ok in Win10. Looks like a WINE issue.

[phaeron]

1 hour ago, mirao said:

Hi,

I can see a new menu item "View => Calibrate..." since 4.10.
When I click on it, Altirra crashes a few seconds later. I'm attaching a crash dump from latest 4.2.0

My environment is Ubuntu 22.10, wine-7.0

AltirraCrash.mdmp 1.16 MB · 0 downloads

So... I can reproduce this and will fix it, but it means that you're running without any graphics acceleration (GDI). You really want to fix that if you can, because running without Direct3D means both poor performance and low-quality visuals.

[mirao]

57 minutes ago, phaeron said:

So... I can reproduce this and will fix it, but it means that you're running without any graphics acceleration (GDI). You really want to fix that if you can, because running without Direct3D means both poor performance and low-quality visuals.

I know. DX9/DX11 doesn't work for me since I upgraded Ubuntu to 22.04 => 22.10 and so far haven't found any solution: 

Actually I don't know what the option "Calibrate..." is good for, just hit it and wanted to report that it crashes in my env.

[mirao]

I noticed a crash when converting unformatted disk. Tested with 4.01/4.10/4.20, all the versions are affected.

1. File => Disk drives
2. D1 => New disk
3. Keep default values, i.e. "Single density", "unformatted"
4. D1 => Convert filesystem => Select any format (e.g. DOS 1.0)
5. Altirra will crash in a few seconds instead of formatting of an empty disk to the selected format

Used SW:

Ubuntu 22.10, wine 7.0, Altirra 4.20-test9

AltirraCrash.mdmp

[+Stephen]

37 minutes ago, mirao said:

I noticed a crash when converting unformatted disk. Tested with 4.01/4.10/4.20, all the versions are affected.

1. File => Disk drives
2. D1 => New disk
3. Keep default values, i.e. "Single density", "unformatted"
4. D1 => Convert filesystem => Select any format (e.g. DOS 1.0)
5. Altirra will crash in a few seconds instead of formatting of an empty disk to the selected format

Used SW:

Ubuntu 22.10, wine 7.0, Altirra 4.20-test9

AltirraCrash.mdmp 1.16 MB · 0 downloads

Confirmed running natively on Windows 11:

---------------------------
Altirra Program Failure
---------------------------
A fatal error has occurred in the emulator. (Could not write AltirraCrash.mdmp!)

Exception code: C0000005  PC: 00007FF7`1136505F (ExeBase+003E505F)

 

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.20-test10.zip
https://www.virtualdub.org/beta/Altirra-4.20-test10-src.7z

• Fixed crash when converting disk with unknown or unsupported filesystem.
• Fixed crash when opening Calibrate screen with hardware acceleration disabled or unavailable.
• Added support for the Stack Lightpen.
• Input mapping dialog is now resizable.

 

[yetanothertroll]

On 4/14/2023 at 11:57 AM, yetanothertroll said:

Great work! However, I seem to have run into an issue that might be with the cassette emulator or maybe how the cassette and diskette drives might conflict in how they use the POKEY. The TL;DR is that writing to the cassette while also doing diskette I/O corrupts the cassette.

[snip snip]

It looks like the problem only occurs if after opening the simulated tape drive "C: for writing, at least one full block isn't written out ASAP before any diskette I/O happens, then very strange things happen to the tape. I've attached some sample .cas files. "cat before 4.cas" shows a normal tape. "cat after 4.cas" shows what happens when I tried to add another file to the tape with data copied from diskette. The ending block of the first file on the tape appears to be clobbered as well. "cat after 5.cas" is another example of a corrupted tape. However, in each case, if the .CAS file is opened in Windows Notepad or some such, the data are actually all there, and programs running in Altirra actually can retrieve it if you play games with the tape position, the pause button, and a stopwatch. Again, I'm not sure if this is happening because Altirra is faithfully emulating Atari's bugs as well as the features 😄

cat before 4.cas cat after 4.cas cat after 5.cas

[phaeron]

1 hour ago, yetanothertroll said:

It looks like the problem only occurs if after opening the simulated tape drive "C: for writing, at least one full block isn't written out ASAP before any diskette I/O happens, then very strange things happen to the tape.

I'm not sure that the C‍: handler actually supports this scenario. When I try it, it leaves the motor running indefinitely, which means that anything sent on the SIO bus will be recorded as long as Record is depressed on the tape deck. This causes commands to the disk drive to be recorded onto the tape, which then fouls the load due to false start bits. Page 73 of the Atari Operating System Manual actually warns about this, which implies that it is actually what's expected to happen:

 

Quote

There is a potential problem with the cassette in that when the cassette is opened for writing, the motor keeps running until the first record (128 data bytes) is written. If 128 data bytes are written or the cassette is closed within about 30 seconds of the OPEN, and no other serial bus I/O is performed, then there is no problem. However, if those conditions are not met, some noise will be written to the tape prior to the first record and an error will occur when that tape file is read later. If lengthy delays are anticipated between the time the cassette file is opened and the time that the first cassette record (128 data bytes) is written, then a dummy record should be written as part of the file; typically 128 bytes of some innocuous data would be written, such as all zeros, all $FFs, or all blanks ($20).

 

The reason for this problem is that the C‍: handler doesn't have false start bit or false sync byte protection, and so it is dependent upon a clean mark tone running up to the sync bytes at the start of the block. Since the Cassette Handler starts writing out the leader as soon as the C‍: device is opened, it has to leave the motor running and continue to write mark tone until the first block is written, since attempting to stop the motor would write noise. If it delayed writing the leader until the first block was also ready to write, as it does for subsequent blocks, then this would not have been an issue. But it would have caused an unexpected 30 second wait in the middle of a write, which also would have been awkward.

[yetanothertroll]

16 hours ago, phaeron said:

I'm not sure that the C‍: handler actually supports this scenario. When I try it, it leaves the motor running indefinitely, which means that anything sent on the SIO bus will be recorded as long as Record is depressed on the tape deck. This causes commands to the disk drive to be recorded onto the tape, which then fouls the load due to false start bits. Page 73 of the Atari Operating System Manual actually warns about this, which implies that it is actually what's expected to happen:

 

 

The reason for this problem is that the C‍: handler doesn't have false start bit or false sync byte protection, and so it is dependent upon a clean mark tone running up to the sync bytes at the start of the block. Since the Cassette Handler starts writing out the leader as soon as the C‍: device is opened, it has to leave the motor running and continue to write mark tone until the first block is written, since attempting to stop the motor would write noise. If it delayed writing the leader until the first block was also ready to write, as it does for subsequent blocks, then this would not have been an issue. But it would have caused an unexpected 30 second wait in the middle of a write, which also would have been awkward.

Alternatively, one could begin processing and buffering the output, and only when either processing's done or there's at least a full block in the program's buffer, only then does it open "C: and begin writing. Then we can add the two buzzes and waiting for the user to press a key to the already awkward 30 second wait in the middle or even at the end of the program. Well, thanks for the food for thought and additional 200+ pages of bedtime reading lol

 

EDIT: I wanted to clarify that it would be the user program buffering its own output in user space and delaying opening "C: until it had at least a block ready to pass to the OS. If like me you try writing fiddly file management utilities in Logo, you deserve what you get. 😄

Edited April 18, 2023 by yetanothertroll
A little more clarity please

[mirao]

What's purpose of the arrows in Disassembly view in debugger?

I thought that they could navigate between addresses in the drop down menu. But nothing happens if I click to any of them.

[phaeron]

8 hours ago, mirao said:

What's purpose of the arrows in Disassembly view in debugger?

I thought that they could navigate between addresses in the drop down menu. But nothing happens if I click to any of them.

Go forward and go back. They're most useful when clicking on addresses in the disassembly -- you can jump to the target of a JSR instruction and then click the left arrow to go back to the caller.

[yetanothertroll]

Altirra 4.10 doesn't appear to like Windows 10 tablets' on-screen touch keyboards, at least not the arrow keys on the regular or "full" keyboards or the "full" keyboard's Del key. Backspace worked just fine. Is it a scan code issue such that the on screen keyboard gives different scan codes for some keys than a physical or Bluetooth keyboard? How would I go about checking this and perhaps reporting back to you what the scan codes turn out to be?

 

I was using Altirra/x64 4.10: OS-B NTSC / 48K running on Windows 10 22H2 64-bit ver 10.0.19045.2728. Altirra's keyboard mappings are the default, the first-time setup was for the "authentic" experience, and the system profile is for the original 800.

 

Thanks!

[phaeron]

3 hours ago, yetanothertroll said:

Altirra 4.10 doesn't appear to like Windows 10 tablets' on-screen touch keyboards, at least not the arrow keys on the regular or "full" keyboards or the "full" keyboard's Del key. Backspace worked just fine. Is it a scan code issue such that the on screen keyboard gives different scan codes for some keys than a physical or Bluetooth keyboard? How would I go about checking this and perhaps reporting back to you what the scan codes turn out to be?

 

I was using Altirra/x64 4.10: OS-B NTSC / 48K running on Windows 10 22H2 64-bit ver 10.0.19045.2728. Altirra's keyboard mappings are the default, the first-time setup was for the "authentic" experience, and the system profile is for the original 800.

Reproduced -- this is a bug in the Windows 10 touch keyboard, specifically the UWP version. The old osk.exe works fine, but the UWP version sends the wrong input codes for the arrow keys.

 

This is what Altirra receives from a keyboard:

HOSTKEYS: Received host vkey down: VK=$25 LP=014B0001 MOD=...-... (current key mask: 0000000000000040)
HOSTKEYS: Received host vkey up:   VK=$25 LP=C14B0001 (current key mask: 0000000000000000)
HOSTKEYS: Received host char up:          LP=C14B0001 (current key mask: 0000000000000000)

 

This is what osk.exe sends:

HOSTKEYS: Received host vkey down: VK=$25 LP=014B0001 MOD=...-... (current key mask: 0000000000000040)
HOSTKEYS: Received host vkey up:   VK=$25 LP=C14B0001 (current key mask: 0000000000000000)
HOSTKEYS: Received host char up:          LP=C14B0001 (current key mask: 0000000000000000)

 

This is what the touch keyboard sends:

HOSTKEYS: Received host vkey down: VK=$25 LP=00000001 MOD=...-... (current key mask: 0000000000000000)
HOSTKEYS: Received host vkey up:   VK=$25 LP=C0000001 (current key mask: 0000000000000000)
HOSTKEYS: Received host char up:          LP=C0000001 (current key mask: 0000000000000000)

 

The LP values are the lParam values received in the WM_KEYDOWN message. The scancode in bits 16-23 is zero instead of $4B like it's supposed to be, but the critical issue is bit 24 being 0, the extended key code. That bit is needed to distinguish some keys from the keypad and the touch keyboard is not setting it properly.

 

Altirra is not the only program affected, this also broke Windows Terminal:

https://github.com/microsoft/terminal/issues/7495

 

Since nothing ever gets fixed in Windows, I guess I'll have to work around this as always. Arrow keys I should be able to, but some other keys like Del will be problematic because they share the same scan code and virtual key code with equivalent keys on the numpad, depending on num lock state.

 

[yetanothertroll]

3 minutes ago, phaeron said:

[elided]

 

Since nothing ever gets fixed in Windows, I guess I'll have to work around this as always. Arrow keys I should be able to, but some other keys like Del will be problematic because they share the same scan code and virtual key code with equivalent keys on the numpad, depending on num lock state.

 

Dang. smdh It's probably even more broken in Lose 11 like just about everything else

[Tigerduck]

Hi, using Altirra 4.10 with 2 Joysticks I found a strange behavior.

 

Testing a 2 Player game for the ABBUC Magazin, I connected two Sub 9 Joysticks via an USB-Joystick converter to the PC.

 

Everything worked fine, except the fire button on Joystick 2. I verifed this with a little basic program to see the value of STRIG(1) and is 0, if the button was pressed or not...

 

Tried this with ATARI800 Emulator, same configuration, button value is 1 when pressed...

 

Here are the settings for Altirra:

 

Is this a bug of Altirra, or is the bug sitting in front of the PC?

 

 

[yetanothertroll]

Did the format of .CAS files change a little between 4.01 and 4.10? There appear to be some NULs scattered about in the data blocks that weren't there before. Maybe the header or footer is a little different, since the new NULs do seem to be about 128 bytes apart.

[phaeron]

13 hours ago, Tigerduck said:

Hi, using Altirra 4.10 with 2 Joysticks I found a strange behavior.

 

Testing a 2 Player game for the ABBUC Magazin, I connected two Sub 9 Joysticks via an USB-Joystick converter to the PC.

 

Everything worked fine, except the fire button on Joystick 2. I verifed this with a little basic program to see the value of STRIG(1) and is 0, if the button was pressed or not...

Seems to work here. Check if the emulator sees the button press on joystick 2 when you edit the input map and tell it to Rebind one of the button bindings. Since the two controllers are the same, I'd expect the buttons to come through.

 

Do the controller axes work on the second gamepad, by the way? One thing about your setup is that you have two of the exact same joystick -- which I wonder might be related.

 

1 hour ago, yetanothertroll said:

Did the format of .CAS files change a little between 4.01 and 4.10? There appear to be some NULs scattered about in the data blocks that weren't there before. Maybe the header or footer is a little different, since the new NULs do seem to be about 128 bytes apart.

4.10 has some improvements to the CAS saving routines to improve roundtripping -- what you are probably seeing is additional 'fsk' blocks written to emit sub-1ms gaps.

[Tigerduck]

Thank you phareon for the fast reply,

 

rebind was the way to go! Now it works as it should.

 

 

[mirao]

A triviality: A help in debugger shows the "wx" command twice:

[Wrathchild]

so good they named it twice  

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.20-test11.zip
https://www.virtualdub.org/beta/Altirra-4.20-test11-src.7z

• Fixed the "use long path names" setting not saving on the H: device.
• Added devices: SIDE 3.1, SuperSALT test assembly.
• Added cartridge types: JRC 64K with non-interleaved (linear) layout, MDDOS, COS 32K, and Pronto.
• Fixed a couple of recently introduced crashes related to device changes.
• Fixed an issue with MidiMate's clock being too fast when used for synchronous receive.
• MidiMate MIDI output is now reset on cold reset.
• Improved .pia command output in the debugger, fixed duplicate 'wx' help entry, and fixed silly "Play" for Record in the perf analyzer.

There is a known issue where attempting to run CPS SuperSALT with the test assembly in 800 mode will result in one test failure on POKEY from the I/O test. This is due to some weird behavior in the test that I can't figure out. The issue is that the test assembly hardwires controller ports 1 and 3 together and one of the joystick lines to joystick 1 trigger input, and it sets PORTB to output mode pulling all lines up while checking the joystick trigger, which is pulled up when it expects it to be low. This gets flagged as paddle A input stuck at +5V since the test assembly also hardwires paddle A input to the same joystick line, but the code in question is special-cased to test only trigger 0 and flag just that one paddle line. The other strange thing is that this part of the test code also leaves the SIO command line floating as an input when it is normally used as an output to enable the ADC output on the joystick lines, but that should be getting pulled up on the computer side.

 

[mirao]

What I like on the Disassembly view in the debugger is that I can use e.g.

dw vvblki

(implemented in 4.10)

But the same thing isn't possible in the Memory view. E.g. if I want to see a display list content using

dw sdlstl

it doesn't work. At first I have to find a value of sdlstl and then enter "HIGH" and "LO" bytes to get appropriate content.
Is it possible to unify it with the Disassembly view?

One more thing: I noticed that the Memory view doesn't store previously entered addresses, therefore they are not visible in a drop down menu.

It works well in the Disassembly view:

BTW editing of memory content in the Memory view is great feature and allows quick testing of change of value without interrupting of app and using debug console. Thanks for it!

 

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.20-test12.zip
https://www.virtualdub.org/beta/Altirra-4.20-test12-src.7z

• MidiMate device now exposes a serial port that can be connected to serial devices.
• Parallel port file writer generalized so it can also attach to and log data from serial ports.
• Added networked serial port device that connects to a serial port and transfers data over TCP/IP.
• Added serial port splitter to allow two different serial port devices to independently handle the input and output halves of a serial connection.

If you're suspicious at this point of the specific devices added here, you're correct, this is for MIDImaze:

 

A lot of this was work to write a new generalized socket service in the emulator to make it easier to implement network connected devices. Which means that there are now four socket worker classes in the emulator, but the plan is to get that eventually down to one to end the madness.

 

For two nodes, the MidiMate device needs to have a networked serial port device attached, with one listening on a TCP port while the other connects to it. The connecting side will keep trying to reconnect every few seconds.

 

For three or more nodes, the computers need to be linked in a loop from MIDI in to MIDI out line per the MIDImaze directions. This requires using the network splitter so the input and output directions use separate TCP connections. Input doesn't need to be listen and output doesn't need to be connect, but each connection between nodes needs connect on one side and listen on the other.

A limitation of the current setup is that anything that pauses the emulator will cause the game to drop, because the emulation being paused will prevent MIDImaze from communicating and the game times out after a fraction of a second.

 

As for MIDImaze's multiplayer protocol itself, it appears to be lockstep with transferring input, so its data transfer requirements are minimal (as would be needed at 300 baud).

 

[Mclaneinc]

Well done Avery for breaking the fourth wall barrier and now communicating directly with the audience inside the emulator. Midimaze up and really working as meant...

[mirao]

16 hours ago, phaeron said:

For three or more nodes, the computers need to be linked in a loop from MIDI in to MIDI out line per the MIDImaze directions. This requires using the network splitter so the input and output directions use separate TCP connections. Input doesn't need to be listen and output doesn't need to be connect, but each connection between nodes needs connect on one side and listen on the other.

Nice, two nodes setup works for me.

But unable to get working three nodes. I have exactly the same loop setup as on your screenshots and I use listening on "localhost" on three Altirra instances (ports 9001, 9002 and 9003 on the same real machine where the emulators are running). There is no error in Devices. But MIDI Maze shows me only "This is a slave machine" in all three instances.
Am I missing something?