Altirra 3.90 released

[phaeron]

4 hours ago, drac030 said:

There are Atari drives which support this geometry: the TOMS 710/720 drives and the LDW/CA with TOMS Multi Drive extension (maybe TOMS Turbo Drive also, I am not sure). The latter (IIRC) is able to format in 180k (40 tracks, 1 side, 9 sectors per track, 512 bytes per sector MFM), the two former ones also 360k (40 tracks, 2 sides, 9 sectors per track, 512 bytes per sector MFM) and 720k (80 tracks, 2 sides, 9 sectors per track, 512 bytes per sector MFM). They called it "Atari ST density".

OK, I can add mappings to map floppy-size 512b geometries then.

 

4 hours ago, drac030 said:

The formatter (correctly IMHO) assumes that numtrk = 1 is a signal that the device does not support the format command (because it is a ramdisk or a hard disk partition) nor the PERCOM-write command (because the device is not configurable).

 

That certainly is a good idea, but IMHO the more rational behaviour of the simulated device woudl be great too. For example, if I reformat a DD floppy in TOMS Multi Drive into 180k "Atari ST" format, I am perfectly able to format it back to DD, it does not all of sudden start pretending to be a hard disk...

I'm constrained by what I can do here because there is no universal Atari disk image format that stores geometry information. The standard disk emulator isn't constrained to only supporting floppy disks as people use it all the time for hard disk geometry, such as 16MB/32MB disks.

 

4 hours ago, drac030 said:

So, per my picture attached to the post #213, you are saying that for example the file FSTRUCT.ARC, created 24 August 2020, was last modified 4 April 2016 and all is correct here?

It's possible, especially when extracting from archives. I can't speak for the state of your filesystem, but there is no actual requirement in Windows that the creation and last modified dates be sorted in any order as they can both be manually set.

 

4 hours ago, drac030 said:

And by the way, the SDFS directory entry shows the last modification time, and not the creation time (opening a file read/write updates its timestamp).

That would make more sense, but Chapter 7 of the SpartaDOS X User Guide documents the last six bytes of the SDFS directory entry as the creation time so that's what Altirra currently uses in its PCLink and virtual SDFS implementations. I can certainly change it to modification time if that is in error.

 

[ijor]

13 hours ago, phaeron said:

Unfortunately, there's not much else that can be done with this in emulation, because there isn't a disk image format that can properly store the track besides one of the raw flux formats, which is way too annoying to use in emulation. The majority of the disk formats don't store geometry and ATX can't encode speed variations.

 

If you look at atxfile.h, you will see that there was always a field, called "rate", reserved at the track header specifically for that purpose. We never used it because we never had a real need for it. But might be about time. If you want we can easily formally specify it:

 

struct ATX_TRACKHEADER
{
	ulong next;
	ushort type;
	ushort pad0;

	uchar track;
	uchar pad1;
	ushort nheaders;
	ushort rate;
...

 

rate:

two bytes, small endian. Defines the relation between the bitrate and RPM at which the track was recorded. It is expressed in bytes per track. An FM (single density) track recorded at nominal bitrate at 288 RPM would have the value 3255. An MFM track (either medium or double density) would have the value 6510. The field is optional and should be left at zero if not exactly known. If the field is blank it should be interpreted as the track was recorded at nominal bitrate and RPM.

 

We can change the name to bytesPerTrack, which might be more intuitive, if you insist. But rate was the original name.

Edited August 25, 2020 by ijor

[ijor]

13 hours ago, phaeron said:

15 hours ago, Nezgar said:

Neat! May I ask how you came up with 285 RPM? It doesn't 'seem' slow enough to me - not that I have anything to support that claim, only that one drive I have with a manual switch brings it down to about 266RPM ...

It's just a number I found somewhere, I probably need to make it configurable and do some tests to see how far down a real FDC can stay in sync.

 

I'm not 100% sure, but I think that Nezgar is right and the "standard" (if there is such a thing) for slow speed mods is around 266 RPM. Certainly 285 is way too fast.

[baktra]

I am happy for turbo tape systems - "Proceed sense" - Turbo 6000 and "Interrupt sense" - Rambit TT working again. I intend to update TS page with a small section listing emulators and their versions with turbo tape support.

[phaeron]

14 hours ago, Estece said:

AltirraCrash.mdmp 55.81 kB · 1 download

Altirra64 4.00-test9

Win 7 sp1 x64.

Moving memory, console, history and watches window with debugger enabled.

I was trying to have console and history at top on memory and watches widow but it crashed.

Thanks for memory variable row size feature.

How to clear watches attached to main display screen ?

 

I can't reproduce the crash, so if you have an idea of what the steps are to trigger it I'd be interested.

 

There is currently no menu command to clear the on-screen watches. Use the debugger command "wc *" to do so.

 

9 hours ago, ijor said:

 

If you look at atxfile.h, you will see that there was always a field, called "rate", reserved at the track header specifically for that purpose. We never used it because we never had a real need for it. But might be about time. If you want we can easily formally specify it:

 

rate:

two bytes, small endian. Defines the relation between the bitrate and RPM at which the track was recorded. It is expressed in bytes per track. An FM (single density) track recorded at nominal bitrate at 288 RPM would have the value 3255. An MFM track (either medium or double density) would have the value 6510. The field is optional and should be left at zero if not exactly known. If the field is blank it should be interpreted as the track was recorded at nominal bitrate and RPM.

 

We can change the name to bytesPerTrack, which might be more intuitive, if you insist. But rate was the original name.

This seems fine to me, and would work to encode high-density or 8" as well. I would also like to see support in the format for encoding double-sided formats and larger sectors with full contents.

[drac030]

19 hours ago, phaeron said:

OK, I can add mappings to map floppy-size 512b geometries then.

Thank you very much in advance.

 

19 hours ago, phaeron said:

I'm constrained by what I can do here because there is no universal Atari disk image format that stores geometry information. The standard disk emulator isn't constrained to only supporting floppy disks as people use it all the time for hard disk geometry, such as 16MB/32MB disks.

I do realize this and floppy emulators suffer similar problems. But, since Atari disks are accessed by logical sector numbers, and not by physcal sector number / track number, it is not so important that the disk returns the same geometry it was formatted with, as long as the capacity is the same and numtrk correctly signalizes either floppy disk (= formattable) or hard disk / ramdisk (= unformattable).

 

I guess that it is a failry safe assumption, that, say, if the image is both <= 1440k AND the number of sectors is divisible by 18 for 128/256-byte sectors, or by 9 for 512-byte sectors, this is a floppy image and numtrk should be either 40 or 80. With the special case of 1050 medium density, and with the possible support for 35- or 77-track images. Everything else (> 1440k) is a harddisk.

 

19 hours ago, phaeron said:

It's possible, especially when extracting from archives. I can't speak for the state of your filesystem, but there is no actual requirement in Windows that the creation and last modified dates be sorted in any order as they can both be manually set.

That particular ARC file was created on Atari (the day indicated by the datestamp on the Windows side), copied to an Unix box using PCLink and SIO2BSD (as the server), then copied via FTP from that Unix box onto a Windows box. The timestap has been preserved all the way, just to be changed into the current one in the very last step, copying Windows->Altirra using PCLink and Altirra as the PCLink server.

 

So how can I copy the file in the last step preserving its timestamp? Because if I (conversely) need it updated, I can always use COPY /D.

 

19 hours ago, phaeron said:

Chapter 7 of the SpartaDOS X User Guide documents the last six bytes of the SDFS directory entry as the creation time so that's what Altirra currently uses in its PCLink and virtual SDFS implementations

It is misdocumented then. The files have modification times, it is the directories which have creation times.

[lemiel]

3 hours ago, drac030 said:

The files have modification times, it is the directories which have creation times.

Change name of directory is then recreating them with new creation time? Just to be sure.

[phaeron]

http://www.virtualdub.org/beta/Altirra-4.00-test11.zip

http://www.virtualdub.org/beta/Altirra-4.00-test11-src.zip

• "Disk is not supported" warning now displays the geometry of the unsupported disk.
• Floppy disk controller emulation now supports formatting 512 byte sector geometries for full disk emulators. In particular, the TOMS Turbo Drive can now format in DD 512 mode.
• High density / 8" timing is now tracked as part of disk geometry.
• 512 byte sector geometries are now supported in ATR images. Standard PC 160K/180K/360K/720K/1.2M/1.44M geometries are supported, and anything up to 1.44M is mapped to floppy geometry with 1:1 interleave.
• Happy 810 autospeed mod RPM is now adjustable.
• Virtual SDFS and PCLink handlers now consistently use creation date for directories and last modified date for files.

 

On 8/25/2020 at 3:07 AM, flashjazzcat said:

Looks like the mistake I was making here was assuming that the Window-snapped position will stick: it doesn't. This isn't an Altirra problem but appears to apply to other applications too. I guess it's a non-issue in that case.

Yeah, this is an annoying issue in Windows. When Microsoft implemented aero snap for Windows 7, they hacked it into the window manager and didn't expose APIs for it and the standard SetWindowPlacement/RestoreWindowPlacement() APIs don't deal with it. I might be able to tweak the logic to save and restore the snapped position, but it isn't possible to restore both the snapped and unsnapped sizes.

 

[drac030]

23 hours ago, lemiel said:

Change name of directory is then recreating them with new creation time?

Oops, never saw that! It is probably a bug in the rename procedure in SPARTA.SYS. I will see if it is easily fixable.

 

@phaeron Now everything seems to work perfectly, thank you. I noticed, though, one more issue in the debugger: in 65C816 mode, when the code is running in the memory past the first 64k, and I hit F8, the Disassembly window shows the PC position with the highest 8 bits zeroed. For example, the break address is $3FF9A0, but the disassembly is shown from $00F9A0.

[lemiel]

36 minutes ago, drac030 said:

Oops, never saw that! It is probably a bug in the rename procedure in SPARTA.SYS. I will see if it is easily fixable.

I do not know if it is bug or not, just guessing hypotetical case.

 

Edit: Because there is no modification date written.

Edited August 27, 2020 by lemiel
Add

[drac030]

Anyway, directories are not recreated when renaming them, otherwise you would not be able to rename a non-empty directory. Timestamps in directories are not updated when the contents of the directory is updated, but I will have to look at this more closely, it seems.

[Krakerman]

Any plans to add multiple save state slots to Altirra per game?

[Jacques]

Not sure if it has been reported already, but on Altirra 3.90 I can't make 1050 Turbo I/II to work on original ROMs by B. Engl.
 

[Mclaneinc]

7 hours ago, Krakerman said:

Any plans to add multiple save state slots to Altirra per game?

You have that already in all honesty, do a proper save state and give each one a new name, I know its not as simple as the simple save state but it does the same thing..

[Krakerman]

If you any of you guys use LaunchBox/BigBox frontend I created a launcher for Altirra so you can launch your games using that frontend.

 

https://forums.launchbox-app.com/topic/56899-slingshot-launcher/?tab=comments#comment-361237

[leech]

29 minutes ago, Krakerman said:

If you any of you guys use LaunchBox/BigBox frontend I created a launcher for Altirra so you can launch your games using that frontend.

 

https://forums.launchbox-app.com/topic/56899-slingshot-launcher/?tab=comments#comment-361237

Awesome, they're actually working on wrapping Launchbox through wine for Linux, still waiting for it to import my mame collection though.

[phaeron]

On 8/29/2020 at 4:30 AM, Jacques said:

Not sure if it has been reported already, but on Altirra 3.90 I can't make 1050 Turbo I/II to work on original ROMs by B. Engl.

1050 Turbo is tricky because the different versions have incompatible banking schemes and ROM images are confusingly named. You can't mix them across versions.

 

This image works with Altirra for 1050 Turbo emulation:

• T1050_1.8KB [CRC32 D481747E]

There is an issue with density detection on power-up with this firmware that I haven't debugged yet, however. You may be unable to read double density disks with this drive without ejecting and reinserting the disk and then resetting only the computer.

 

These images work with Altirra for 1050 Turbo II emulation:

• turbo1050-34.rom [CRC32 55DFC9AC]
• turbo1050-35.rom [CRC32 4A69312B]

 

[Jacques]

On 8/30/2020 at 9:28 PM, phaeron said:

There is an issue with density detection on power-up with this firmware that I haven't debugged yet, however. You may be unable to read double density disks with this drive without ejecting and reinserting the disk and then resetting only the computer.

 

Thank you again, I gave it a shot once more, and managed to successfully run both 1050 Turbo I & II. And indeed the only issue I experienced is a need to re-attach disk image: both for DD, but also for ED (e.g. Stunt Car Racer).

I've tested 1050 Turbo/Top Drive SpartaDOS X driver from @trub and @drac030 which works without any problem too, so emulation is good.

If only density detection issue could be resolved in next releases, would be great

[phaeron]

16 hours ago, Jacques said:

 

Thank you again, I gave it a shot once more, and managed to successfully run both 1050 Turbo I & II. And indeed the only issue I experienced is a need to re-attach disk image: both for DD, but also for ED (e.g. Stunt Car Racer).

I've tested 1050 Turbo/Top Drive SpartaDOS X driver from @trub and @drac030 which works without any problem too, so emulation is good.

If only density detection issue could be resolved in next releases, would be great

 

I have the 1050 Turbo firmware partially disassembled and it looks like this might be a legit bug in the firmware, as the initial state of the tracking flag is 'not ready = 0' which means that it doesn't do density detection if there is already a disk in the drive. First time I've seen code storing state in the data direction registers, that was an amusing hack. Might need to do a workaround hack like toggling Not Ready until Read Address is issued.

 

[ijor]

Some minor error feedback to the Altirra Hardware Reference Manual. Hope it is the right place. Sorry if there is a dedicated thread, I couldn't find it.

Quote

Table 44: 1050 RIOT I/O port assignments

...

PB7 Output SIO data input (device to computer)

PB0 Input   SIO command

Signals are swapped at PB0 & PB7.

[phaeron]

http://www.virtualdub.org/beta/Altirra-4.00-test12.zip

http://www.virtualdub.org/beta/Altirra-4.00-test12-src.zip

• Fixed regression in 810/1050 full drive emulators where non-Happy810 drives ran at 265 RPM.
• Frame PC bank is now set correctly when hitting a breakpoint in 65C816 mode.
• Added 1050 turbo II ROMs to the autodetect list.
• Happy 810 autospeed RPM now updates immediately when changed while drive is in optional speed mode.
• Fixed a bug with the caret sometimes jumping to a weird position when expanding a JMP/JSR target in the Disassembly window.

1 hour ago, ijor said:

Some minor error feedback to the Altirra Hardware Reference Manual. Hope it is the right place. Sorry if there is a dedicated thread, I couldn't find it.

Signals are swapped at PB0 & PB7.

Thanks, you're correct. I have this already fixed locally but haven't published a new version in a while. I usually use this thread for it:

 

 

[drac030]

5 hours ago, phaeron said:

Frame PC bank is now set correctly when hitting a breakpoint in 65C816 mode.

This works now, thank you. In meantime I noticed another issue in the debugger in 65C816 mode:

 

 

The console window shows that the instruction LDA ($02,S),Y will  reference the address $000118 and fetch $00 from there. But in fact, since B=1, it will reference $010118 and fetch $9B, as it really happens in next step.

[phaeron]

http://www.virtualdub.org/beta/Altirra-4.00-test13.zip

http://www.virtualdub.org/beta/Altirra-4.00-test13-src.zip

• 65C816 execution history now contains effective addresses for indexed and indirect modes. (This doesn't fix the case in the console window yet, which uses current state instead of history state.)
• Added workaround for 1050 Turbo power-up density detection bug: when a power-up occurs with a disk already in the drive, the emulator toggles Not Ready until the firmware notices the disk.
• Performance analyzer now supports dark mode.
• Fixed a redraw issue and potential crash with the ANTIC display list (DL) timeline in traces. This typically manifested as it not drawing at some zoom levels.
• Improved performance of the video trace timeline by caching the bitmaps and fixing a bug that caused an overly expensive downscaling filter to be used.
• Added an awful hack to try to work around the problems in Wine64 on macOS: specifying /macwine64hack on the command-line will try to work around the broken GS: selector that only works for gs:[30h] and gs:[58h] offsets and causes newer Visual C++ runtimes to crash, by patching the CRT to go through the TEB->Self pointer instead. If this works then it can be made a bit more automatic.

 

[Mr Robot]

Thank you!

 

Here's the terminal output

 

Spoiler

Quote

» ChoccyBook:Altirra-4.00-test13 >wine64 Altirra64.exe /macwine64hack
0009:fixme:esync:do_esync eventfd not supported on this platform.
000b:fixme:esync:do_esync eventfd not supported on this platform.
000b:fixme:winediag:__wine_start_process Wine Staging 5.7 is a testing version containing experimental patches.
000b:fixme:winediag:__wine_start_process Please mention your exact version when filing bug reports on winehq.org.
000d:fixme:esync:do_esync eventfd not supported on this platform.
000f:fixme:esync:do_esync eventfd not supported on this platform.
0012:fixme:esync:do_esync eventfd not supported on this platform.
0014:fixme:esync:do_esync eventfd not supported on this platform.
001b:fixme:esync:do_esync eventfd not supported on this platform.
001d:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\wineusb": c0000142
000f:fixme:service:scmdatabase_autostart_services Auto-start service L"wineusb" failed to start: 1114
0022:fixme:esync:do_esync eventfd not supported on this platform.
002f:fixme:esync:do_esync eventfd not supported on this platform.
0009:fixme:uxtheme:BufferedPaintInit Stub ()
0009:fixme:win:RegisterTouchWindow (0x10064 00000000): stub
0009:fixme:win:UnregisterTouchWindow (0x10064): stub
0009:fixme:win:SetGestureConfig (0x10064 00000000 1 0x21e530 12): stub
0035:fixme:coreaudio:ca_channel_layout_to_channel_mask Unhandled channel 0xffffffff
0035:fixme:coreaudio:ca_channel_layout_to_channel_mask Unhandled channel 0xffffffff
0035:fixme:coreaudio:ca_channel_layout_to_channel_mask Unhandled channel 0xffffffff
0035:fixme:coreaudio:ca_channel_layout_to_channel_mask Unhandled channel 0xffffffff
0009:fixme:win:RegisterTouchWindow (0x100c4 00000000): stub
0009:fixme:win:UnregisterTouchWindow (0x100c4): stub
0009:fixme:win:SetGestureConfig (0x100c4 00000000 1 0x21e3c0 12): stub
0038:fixme:kernelbase:AppPolicyGetThreadInitializationType FFFFFFFFFFFFFFFA, 00000000022DFD90
0009:fixme:win:RegisterTouchWindow (0x100d2 00000000): stub
0009:fixme:win:RegisterTouchWindow (0x100d4 00000000): stub
0009:fixme:win:RegisterTouchWindow (0x100ca 00000000): stub
0009:fixme:win:UnregisterTouchWindow (0x100ca): stub
0009:fixme:win:RegisterTouchWindow (0x200d4 00000000): stub
0009:fixme:commdlg:IServiceProvider_fnQueryService Interface {e07010ec-bc17-44c0-97b0-46c7c95b9edc} requested from unknown service {e07010ec-bc17-44c0-97b0-46c7c95b9edc}
0009:fixme:shell:ViewModeToListStyle ViewMode 0 not implemented
0009:fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x27e5be0 (2, 1026, a003, 0, 0x21a020)
0009:fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x27e5be0 (2, 1026, a004, 0, 0x21a020)
0009:fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x27e5be0 (2, 1025, a003, 1, 0x21a020)
0009:fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x27e5be0 (2, 1025, a004, 1, 0x21a020)
0009:fixme:nstc:NSTC2_fnSetControlStyle2 mask & style (0x00000004) contains unsupported style(s): 0x00000004
0009:fixme:shell:SHGetStockIconInfo Couldn`t find SIID 79, returning default values (IDI_SHELL_FILE)
0009:fixme:shell:SHGetStockIconInfo Couldn`t find SIID 78, returning default values (IDI_SHELL_FILE)
0009:fixme:uxtheme:BufferedPaintUnInit Stub ()
0009:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000021FCD0

 

 

 

[phaeron]

http://www.virtualdub.org/beta/Altirra-4.00-test14.zip

http://www.virtualdub.org/beta/Altirra-4.00-test14-src.zip

• Fixes to effective address computations for non-history based disassemblies.
• Initial read-only emulation for the Atari 815 disk drive.

For those who don't know, the Atari 815 is an odd duck. It has two drive mechanisms and is the only Atari 8-bit disk drive I know of that has no floppy drive controller chip. Instead, Atari opted to brute force it with a 2MHz 6507 (faster than the computer!), 4K of ROM, three 6532 RIOT chips (mislabeled as PIAs), a MC6852 Synchronous Serial Data Adapter (a.k.a. overgrown shift register), and a data separator made out of miscellaneous logic. It is also the only disk drive that cannot read a single density disk, with its hardware and firmware limited to MFM. It also cannot read enhanced density -- the hardware is capable of doing so, but we'll give the designers a pass for not supporting a format that didn't exist yet. The 815 does support code upload, and a couple of the extra commands are suspiciously similar to ones in the 810 revision E firmware, which implies a relationship between the two. No support for high-speed, sadly, even with the 4K ROM and 2MHz CPU -- and with hardware support for another 2K ROM expansion this drive could have done a lot.

 

As the 815 has no FDC, the firmware itself reads and writes raw MFM data, including scanning for sector headers. The emulator has to synthesize a raw MFM track to support this and without the FDC doesn't know what sectors the firmware is trying to access, so currently the emulation is read-only and only shows track numbers instead of sector numbers. The hardware strips MFM clock bits on read but requires the firmware to encode to MFM and calculate CRC-16s in software. It's surprisingly capable of doing this with the 2MHz CPU and the drive formats with a 16:1 interleave, slightly faster than US Doubler standard interleave. The one sub-par thing I've found is sync -- instead of just waiting for the $4489 pattern to appear, the 815 has to use a two-step process to detect the $44 and then check the $89. This means that it will miss the sync when a pattern like $44489 shows up and makes the drive unusually dependent upon the $00 bytes before the sync. The drive also doesn't report errors the same way as an FDC, although this is hard for me to test as ATX doesn't support double density disks yet and there aren't really any copy protected double density disks anyway.

 

The 815 seems to be format compatible with other double density drives, including the three boot sector convention -- which is interesting, considering when this drive was made (1980-1981?). It's also the only drive to implement the mysterious Read Spin, Motor On, and Verify Sector commands documented in the Atari Operating System Manual that no other drive implements.

 

You'll need the 4K firmware to make this work, combining the two 2K ROM images. I've opted for a format where the A107 chip is first and the A106 chip is second, which matches the canonical order in the address space ($0800-17FF). For convenience, it is attached. All copies of the 815 firmware that I have found, including those from Bob Woolley, are the same, with A107 CRC32 32BD3CFD, A106 CRC32 C13657E0, combined CRC32 1527D542. Some dumps come with an extra 6-byte Atari executable header that must be removed.

 

 

atari815.rom