Altirra 3.90 released

[Mclaneinc]

Just went to play with the Speedy 1050 device and it said it was missing firmware which I checked and the right file that has previously been on was selected (speedy 1.33n.bin) so I removed it and re added it and its still the same. I presume I've missed an update where a new rom is used or is this a bug...

 

Betting me...

 

Thank you...

[phaeron]

6 hours ago, Mclaneinc said:

Just went to play with the Speedy 1050 device and it said it was missing firmware which I checked and the right file that has previously been on was selected (speedy 1.33n.bin) so I removed it and re added it and its still the same. I presume I've missed an update where a new rom is used or is this a bug...

Sure it got added as a Speedy 1050 firmware? There's no autodetect for Speedy 1050 firmware, so the firmware manager may have added it as an XL/XE kernel unless you overrode the type.

[Mclaneinc]

As far as the rom, the speedy 1.33n, its deffo in the right place and nowhere else in the firmware manager...I even reset the settings and started from scratch making sure it was added as a speedy 1050 rom but still got the same complaint of missing firmware even if set as the default for that rom. Now I took down another rom classed as speedy and it does work although disk master 1050 throws up the same error when booted but I believe there's an issue with that utility anyway.

 

I'm just wondering why that initial rom that others as well as me have used in that position suddenly at least for me says its not right...Wrong rom all along? corrupted?

 

I checked a couple of peoples rom posts with pics of the firmware manager and all have this rom in that Speedy 1050 position.

Speedy1.33n.rom

[Mclaneinc]

Thanks to a kind user who noticed the rom is basically blank I will now look at my back up rar and check its ok, so thanks for the reply Avery and to Good Byte for checking the rom, consider it a closed case...

 

Better check my other roms, I know I'm virus and malware free but something has happened..

 

Edit: All my backups have the exact same dead rom in them....Looks like it wasn't right from the beginning..Odd...Maybe its the first time I played with the Speedy 1050 so only noticed (with help) this issue now..

 

I have a rom that seems to work, its named Speedy 1050 v1.0 (16.10.1986) (corrected) crc 6CB4457D, is this the right rom, got it from the 1050 upgrades thread.

Edited August 21, 2020 by Mclaneinc

[drac030]

4.00-beta6: not everything feels quite okay with the "full" Turbo 1050 and Turbo 1050 II emulation. To setup it, I have used the ROMs from the posts 117 and 118 here:

I attached T1050_1 as firmware to 1050 Turbo, and T10502A, T10502B and Nezgar's image as firmware to 1050 Turbo II. I have attached the Turbo II device and selected the B ROM as default for it.

 

Initially it did not work (SIO timeouts, no transmission), but when I changed File->Disk drives->1050 Turbo to "Generic", it started working and worked seemingly okay until I closed the emulator. After restarting it however I could not access the attached DD disk image, no sector was responding except the first three, and even in these, sectors 1 and 2 showed the same contents (which properly belongs to sector 1).

 

After closer inspection I saw that the ATR disk image has improper size: it was too short by 384 bytes. To be sure, I did the full formatting before, and this probably was when the ATR file characteristics changed.

 

I closed the emulator, copied over a "good" disk image onto that ATR, then reopened the emulator. But then no sector could be accessed: at an attempt to access all react with error 139. It behaves as such until now, i.e. no matter what I try, the disk image is unreadable.

 

Until it worked, I also tried SD and MD disk images, but the results were seemingly not any better. Generally, before it completely stopped working, the behaviour was so inconsistent that it is even difficult to write down "steps to reproduce", because even the same steps seemed to lead to various results.

 

After detaching the device everything goes back to normal.

 

Also, in the thread linked above there is a test version of TOPDRV.SYS, the 1050 Turbo "driver" for SpartaDOS X. I was able to test that it worked with the Turbo II "full" emulation (before the emulated device stopped working at all, that is), but it definitely does not work with the generic 1050 Turbo emulation available in File->Disk drives.

 

 

 

Edited August 21, 2020 by drac030

[phaeron]

13 hours ago, drac030 said:

4.00-beta6: not everything feels quite okay with the "full" Turbo 1050 and Turbo 1050 II emulation. To setup it, I have used the ROMs from the posts 117 and 118 here:

I attached T1050_1 as firmware to 1050 Turbo, and T10502A, T10502B and Nezgar's image as firmware to 1050 Turbo II. I have attached the Turbo II device and selected the B ROM as default for it.

 

Initially it did not work (SIO timeouts, no transmission), but when I changed File->Disk drives->1050 Turbo to "Generic", it started working and worked seemingly okay until I closed the emulator. After restarting it however I could not access the attached DD disk image, no sector was responding except the first three, and even in these, sectors 1 and 2 showed the same contents (which properly belongs to sector 1).

 

After closer inspection I saw that the ATR disk image has improper size: it was too short by 384 bytes. To be sure, I did the full formatting before, and this probably was when the ATR file characteristics changed.

 

I closed the emulator, copied over a "good" disk image onto that ATR, then reopened the emulator. But then no sector could be accessed: at an attempt to access all react with error 139. It behaves as such until now, i.e. no matter what I try, the disk image is unreadable.

 

Until it worked, I also tried SD and MD disk images, but the results were seemingly not any better. Generally, before it completely stopped working, the behaviour was so inconsistent that it is even difficult to write down "steps to reproduce", because even the same steps seemed to lead to various results.

 

After detaching the device everything goes back to normal.

 

Also, in the thread linked above there is a test version of TOPDRV.SYS, the 1050 Turbo "driver" for SpartaDOS X. I was able to test that it worked with the Turbo II "full" emulation (before the emulated device stopped working at all, that is), but it definitely does not work with the generic 1050 Turbo emulation available in File->Disk drives.

Thanks for the report. There are a few issues here, so let's take them one by one:

 

First, the ATR issue. There's a bug in the ATR writer that manifests with full disk drive emulators in double density -- the format operation causes the internal disk storage to hold a full 256 bytes for the boot sectors, which the writer doesn't handle. I have a fix for this already in flight for the next test release but it's mixed in with some other 8" disk support updates I need to clean up.

 

Second, there is an unknown issue preventing the emulated 1050 Turbo from detecting density consistently on startup, the real-world equivalent of powering on the drive with a disk already inserted. If you swap the disk manually after reset such that the firmware sees a disk change, then it does switch densities correctly. I don't know what's causing this yet; unfortunately I don't have a 1050 Turbo to verify against, so I might need to spend some time disassembling the firmware.

 

Now, as for the issue with TOPDRV.SYS, it's an issue with the standard disk emulator's ACK-to-Complete timing and the speed of the OS SIO routines. TOPDRV.SYS uses a speed change hack on top of the standard OS ROM SIO routines, which are rather slow to reconfigure between ACK and Complete. The official SIO specification says that the min time between the end of the ACK and the start of Complete is 250us, but the stock SIO routine relies on the reception time of the following byte and requires quite a bit longer than this if you speed up the transfer rate, so when Altirra sends the Complete byte 250us later at high speed for the read PERCOM block command, SIO is still setting up the transfer when it arrives. The AltirraOS SIO routines are quicker to turn around and can deal with this, but obviously we can't rely on that. I'll need to spend some time recalibrating this based on the times that various firmwares take to respond to the PERCOM commands -- for the 1050 Turbo at least, the command execution delay is closer to 900us.

 

[Rybags]

ed - just realised I was replying to something about 4 pages back.

 

On 7/23/2020 at 4:52 PM, ilmenit said:

In Altirra you can select random memory pattern in configuration. Is there an option to select random pokey initialization so "lda $D20A" will return different value each time executable file is loaded directly?

 

On real hw in theory a Rom based autostart like cartridge should see the same RANDOM sequence, as you'd expect on an injected execuatable on emulator.

 

On real hw a SIO, and possibly even IDE type loaded autoboot program should see sufficient jitter (especially rotating disk) such that the odds of the same RANDOM sequence are no different as if a user promt initiated it.

Edited August 22, 2020 by Rybags

[drac030]

8 hours ago, phaeron said:

Second, there is an unknown issue preventing the emulated 1050 Turbo from detecting density consistently on startup, the real-world equivalent of powering on the drive with a disk already inserted. If you swap the disk manually after reset such that the firmware sees a disk change, then it does switch densities correctly. I don't know what's causing this yet; unfortunately I don't have a 1050 Turbo to verify against, so I might need to spend some time disassembling the firmware.

You are right, starting Altirra without a disk image in D1, then inserting one fixes the issue.

 

As for the real hardware, before I got my first harddisk around 1995, I had used a Top Drive 1050 very intensively, but at the other hand I probably never powered the drive on with the disk inserted and the door closed...

[phaeron]

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

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

 

• ATR loader now recognizes 8" disk geometries with 77 tracks. These now get set up with 26 sectors/track and with an appropriate interleave for the ATR8000 (the only currently emulated drive type that legitimately supports 8" drives).
• Percom RFD-40S1 double-clock mode is now also supported, though it doesn't work well with the stock firmware. 8" mode can be set through the PERCOM block, but the firmware doesn't know how to format a disk at 360 RPM.
• Added support for the Happy 810 Autospeed mod, with the ability to slow the down to 285 RPM.
• The .disktrack debugger command now handles tracks with more than 18 sectors/track.
• Fixed a bug in the ATR writer that produced corrupted disk images when formatting a double-density disk with a full drive emulator. This happened because the boot sectors are physically 256 bytes on disk, but the ATR writer didn't properly handle these when trimming them to 128 bytes for the file output.
• Fixed a bug with full drive emulators where sometimes the last write to a disk wouldn't trigger the auto-flush, so the disk would stay in modified state until another write had occurred.
• Fixed corruption of the first byte sent by a 810 or 1050 based full-drive emulator after cold reset, due to the power-up state being wrong -- the output is actually low on reset.
• Recalibrated the delay timings in the standard disk emulator for the Status and Read PERCOM Block commands, which were too low for some of the third-party drives. In particular, this fixes TOPDRV.SYS.
• Fixed regression with the interrupt/proceed cassette turbo modes not working.

 

[drac030]

16 hours ago, phaeron said:

Recalibrated the delay timings in the standard disk emulator for the Status and Read PERCOM Block commands, which were too low for some of the third-party drives. In particular, this fixes TOPDRV.SYS.

I removed the 1050 Turbo II device and set File->Disk drives with a DD image and 1050 Turbo. Unfortunately, after loading TOPDRV.SYS, the drive stops responding (timeouts, no transmission).

[phaeron]

4 hours ago, drac030 said:

I removed the 1050 Turbo II device and set File->Disk drives with a DD image and 1050 Turbo. Unfortunately, after loading TOPDRV.SYS, the drive stops responding (timeouts, no transmission).

Apologies, try now:

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

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

• Fixed new status/read-PERCOM timing not working with accurate disk timing disabled (warp-rotation mode).
• Added option to Disk Drives menu to locate the mounted disk image file in Windows Explorer.
• Added warning when adding a firmware image file that is blank.

 

[ldelsarte]

16 hours ago, phaeron said:

Apologies, try now:

 

Really, I don't think the community will feel betrayed when I say that we're all VERY grateful for what you're doing for us.

Thank YOU for this latest update of Altirra. You should not apologize at all.

I'm so happy I can get new versions of Altirra. I would be happy to pay for them if it was possible (you know that, we had this conversation before).

[drac030]

19 hours ago, phaeron said:

Apologies, try now:

It is better now: it reads in turbo mode, but does not write nor format (in std mode no problem).

 

While we are at it, could I have a request, that floppy images formatted with 512 bytes per sector ("DD 512" in SDX Formatter menu) returned the PERCOM data as for a floppy disk (i.e. with the actual number of tracks etc.) instead of behaving like harddisks (where numtrk = 1). I reformatted an ATR from DD to DD 512 and was unable to format it back...

 

I also noticed two odd things about PCLink:

 

a) its directories are sorted (which is probably a good thing), but they are sorted in reverse alphabetical order: last files first, directories last. Is this intended or is there some misconfiguration at my side?

 

b) the time/date stamps, while accessing PC-side files from the Atari side, are lost, as on the pic.

 

 

[flashjazzcat]

Now that I'm using a single 4K monitor rather than dual 1080p screens, I like to place Altirra on the upper-right quarter of the desktop, usually with the debugger open. I'm having two problems:

• The emulator does not remember its main window position when closed and reopened
• The emulator changes its main window position after a full-screen open/close (with Alt+Enter)

With the old setup, Altirra was always maximised on the right hand monitor and when I opened it or cycled full-screen mode, there were no problems at all.

 

I went into regedit (I don't run Altirra in portable mode) and deleted the 'Window Placement' key, but the issue persists. Perhaps there's something obvious I've overlooked? Any suggestions appreciated. Running 4.00-test9 as of this evening.

[Krakerman]

I keep getting every other time I launch a game struck on grey screen exit and re-launch and works just fine.

[phaeron]

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

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

• Increased write complete delay for standard disk emulator with accurate timing off.
• Fixed reversed PCLink directory sort order.

11 hours ago, drac030 said:

While we are at it, could I have a request, that floppy images formatted with 512 bytes per sector ("DD 512" in SDX Formatter menu) returned the PERCOM data as for a floppy disk (i.e. with the actual number of tracks etc.) instead of behaving like harddisks (where numtrk = 1). I reformatted an ATR from DD to DD 512 and was unable to format it back...

There are a couple of problems with doing this: there is no physical geometry to model this after since no Atari-compatible disk drives used 512 bytes per sector, and it would prevent using the built-in disk support to simulate the same geometry as a hard disk partition. I want to say that there was something that also required such disks to be flagged as hard drives but I can't remember off-hand. Also, this seems to be a SpartaDOS X specific issue as its formatter is what is preventing the re-format, not the disk drive.

 

Would it work to put in a reformat option in the Disk Drives dialog to re-format the disk in place, basically New Disk but without removing the file link?

 

11 hours ago, drac030 said:

I also noticed two odd things about PCLink:

 

a) its directories are sorted (which is probably a good thing), but they are sorted in reverse alphabetical order: last files first, directories last. Is this intended or is there some misconfiguration at my side?

Sorting is intended for determinism, the reverse sort order is not and was due to a change to allow seeking in directories. Fixed in -test10.

 

11 hours ago, drac030 said:

b) the time/date stamps, while accessing PC-side files from the Atari side, are lost, as on the pic.

This is intended, Windows Explorer shows the last modified timestamp by default whereas the emulator's PCLink handler returns the creation timestamp, per the SDFS directory entry spec.

 

9 hours ago, flashjazzcat said:

Now that I'm using a single 4K monitor rather than dual 1080p screens, I like to place Altirra on the upper-right quarter of the desktop, usually with the debugger open. I'm having two problems:

• The emulator does not remember its main window position when closed and reopened
• The emulator changes its main window position after a full-screen open/close (with Alt+Enter)

With the old setup, Altirra was always maximised on the right hand monitor and when I opened it or cycled full-screen mode, there were no problems at all.

 

I went into regedit (I don't run Altirra in portable mode) and deleted the 'Window Placement' key, but the issue persists. Perhaps there's something obvious I've overlooked? Any suggestions appreciated. Running 4.00-test9 as of this evening.

This sounds like it might be related to high DPI since that would be most likely to change with a larger monitor. Check Settings > Display > Scale and layout in Windows and see if the display is set above 100%. If so, reset it temporarily to 100% and then log out and back in, and see if the behavior is different. Altirra should be high DPI agnostic and I haven't been able to reproduce this, but that kind of issue might explain this kind of behavior.

 

Also, if you are launching Altirra from a batch file or shortcut, make sure that the program is not being forced to launch maximized/minimized. This will bypass the window position restore code.

 

2 hours ago, Krakerman said:

I keep getting every other time I launch a game struck on grey screen exit and re-launch and works just fine.

Is this a problem that only started occurring with recent versions and wasn't occurring previously?

 

This sounds like a display driver problem. Go to Options > Display and toggle DirectX 11 support, and see if that makes a difference.

 

[+Nezgar]

On 8/22/2020 at 6:36 PM, phaeron said:

Added support for the Happy 810 Autospeed mod, with the ability to slow the down to 285 RPM.

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, and the super archiver had 4 speeds. Also we currently have no documentation the autospeed mod. Is that all that's needed to write the max extra sectors possible by the happy 5.x software, I presume from your reverse engineering?

 

On 8/22/2020 at 12:30 AM, phaeron said:

unfortunately I don't have a 1050 Turbo to verify against, so I might need to spend some time disassembling the firmware.

I would be happy to loan you my 1050 turbo replica (v II apparently) if it helps. PM if interested.

[phaeron]

1 hour 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, and the super archiver had 4 speeds. Also we currently have no documentation the autospeed mod. Is that all that's needed to write the max extra sectors possible by the happy 5.x software, I presume from your reverse engineering?

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. The hardware interface to the autospeed mod is pretty simple, it's just toggled via RIOT port A bit 5. This is also why it's incompatible with the fast/slow switch, which for some reason connects PA3 and PA5 together.

 

The FDC emulation code does now also take RPM into account when computing the number of bits that can fit on a track during a format operation. This reveals that the PERCOM RFD doesn't actually support 8" operation, because while the firmware can be convinced to turn on high density mode through the PERCOM block, it doesn't know how to lay out a track for 360 RPM and overruns the track, while the ATR8000 does use a different track layout.

 

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.

 

1 hour ago, Nezgar said:

I would be happy to loan you my 1050 turbo replica (v II apparently) if it helps. PM if interested.

Thanks, but not necessary and I wouldn't want to put it at risk. The only verification needed is that powering up the drive with a enhanced or double density disk reads properly in SpartaDOS X without having to swap the disk afterward. (Do this with an unimportant disk, in case the drive erases part of the disk on power-up.) Beyond that, having the actual drive wouldn't help as I don't have the equipment to record an execution trace of the drive CPU.

 

[+DjayBee]

2 hours ago, Nezgar said:

May I ask how you came up with 285 RPM?

After my vacation I have to try something else with my 810 and will report its actual slow RPM. 

[flashjazzcat]

4 hours ago, phaeron said:

Check Settings > Display > Scale and layout in Windows and see if the display is set above 100%. If so, reset it temporarily to 100% and then log out and back in, and see if the behavior is different. Altirra should be high DPI agnostic and I haven't been able to reproduce this, but that kind of issue might explain this kind of behavior.

I'm running the 32" display at 100 per cent scaling (perfectly readable, surprisingly), so it appears it's not a high DPI/scaling issue.

4 hours ago, phaeron said:

Also, if you are launching Altirra from a batch file or shortcut, make sure that the program is not being forced to launch maximized/minimized. This will bypass the window position restore code.

Double checked the shortcut and tried launching the emulator by double-clicking the EXE. So we can discount the shortcut by the looks of it.

 

I do have PowerToys installed, so I tried using FancyZones to Shift-drag Altirra into the top right corner. This appeared to fix the issue of the application not opening at the previous size/position. I then turned off FancyZones; Altirra kept opening at the top-right corner and restoring from full-screen to the same position (top right but slightly inset from the edges of the screen), but when I Window-snapped it to the corner, closed it and re-opened it, it moved to the centre of the screen again.

 

It seems to me that the problem is intermittent and the behaviour somewhat unpredictable. If I Window-Snap Altirra to the top right corner, close it, then re-open it, it usually re-opens in the same place (since the one-time FancyZones drop) but with 25 pixels of padding or so around all sides and a slightly reduced window size (FancyZones is still turned off). I wonder if it's something about Window-Snap that it doesn't like; it will NEVER re-open flush against the top-right corner of the screen, but at least I managed to coax it into roughly the correct position.

 

EDIT: Uninstalled PowerToys completely, rebooted, and tried again. Window-snapped Altirra to the top right corner, closed it, opened it. It went to the middle of the screen. Tried again, and this time Altirra opened at the top-right but with the 25px or so padding and a slightly reduced window size. Eventually I carefully manually positioned Altirra exactly in the top-right corner, flush with the edge of the screen, and this time the size and position appears to stick.

 

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.

Edited August 25, 2020 by flashjazzcat

[Krakerman]

Yes but I want to use dx9 still for my special Altirra launcher that I am coding for LaunchBox/BigBox as dx9 allows gui's on top of the games in fullscreen where as dx11 does not.

Edited August 25, 2020 by Krakerman

[drac030]

10 hours ago, phaeron said:

there is no physical geometry to model this after since no Atari-compatible disk drives used 512 bytes per sector

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".

 

10 hours ago, phaeron said:

Also, this seems to be a SpartaDOS X specific issue as its formatter is what is preventing the re-format, not the disk drive.

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).

 

10 hours ago, phaeron said:

Would it work to put in a reformat option in the Disk Drives dialog to re-format the disk in place, basically New Disk but without removing the file link?

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...

 

10 hours ago, phaeron said:

This is intended, Windows Explorer shows the last modified timestamp by default whereas the emulator's PCLink handler returns the creation timestamp, per the SDFS directory entry spec.

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?

 

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).

 

Minor stuff:

 

in the debugger, the "Verifier->Undocumented OS entry" gets incorrectly (IMHO) triggered on the entry to $d805 in a PBI ROM.

 

EDIT:

 

the PCLink sorting issue is indeed fixed, thank you. The File->Disk drives->1050 Turbo now (with the presence of TOPDRV.SYS in the memory) can correctly write files to the image. It cannot format though (error 140).

 

Edited August 25, 2020 by drac030

[Estece]

AltirraCrash.mdmp

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 ?

[lemiel]

LDW/CA with TOMS Turbo Drive also supports 180k SS 512 bytes format. 

TOMS drives extensions were presented in commercials and descriptions in magazines as possible solution to be used for swaping data with PCs that way.

 

Edit: I didn't tried to use that possibility and do not checked if SDX 4.22 Formatter allowed that. There were some tools on TOMS system disk allowing that cooperation. Probably written in Action! or TB XL. Do not remember now and being on holidays trip so could not check that now.

 

Edit2: Did not Happy Warp also supports that PC format to SWAP disks?

Edited August 25, 2020 by lemiel
Typo in addendum, add. 2

[drac030]

11 minutes ago, lemiel said:

do not checked if SDX 4.22 Formatter allowed that

SDX 4.22 (or 4.2 in general) formatter does not, but SDX 4.4 formatter does.