Altirra 2.70 released

[Kyle22]

Hi. I just upgraded from 2.80t11 to t13. Where did my HDD go? I had been emulating a U1MB with SIDE2, and I used to be able to specify my HDD image under the "system" menu heading. I see now I need to add SIDE2 as a cartridge based "device", which I did, but I see no way to put in settings for it to specify what HDD image file should be associated with it. All I get is a blank black scree for quite some time, before SDX finally shows up with its default built in config.sys active. My HDD is no where to be found. What do I need to do to get it back?

 

That's strange... My hard drive is still perfectly functional after the latest update to Altirra. SDX came up just as always, and I had a C:> prompt.

 

 

 

 

 

I'm using a Corvus, and it was already in "Devices", so nothing changed there.

 

Edited February 8, 2016 by Kyle22

[fujidude]

 

That's strange... My hard drive is still perfectly functional after the latest update to Altirra. SDX came up just as always, and I had a C:> prompt.

 

 

 

 

 

I'm using a Corvus, and it was already in "Devices", so nothing changed there.

 

As you say, you were using Corvus. I was using SIDE2. I didn't have any firmware for the SIDE2 setup, but it wasn't necessary when using a SIDE off of a U1MB. I thought the move of SIDE/SIDE2 to devices and it being made a cartridge type of device was the problem. So I configured Altirra with an appropriate SIDE2 ROM image in the firmware section but it made no difference either.

[Kyle22]

Yeah, I know... Just having a little fun.

[phaeron]

You need to select the SIDE device, click Add to add a hard disk to it, then edit the settings on the hard disk. The dialog to do this will automatically be displayed when the hard disk is added.

 

Update:

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

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

 

Adds Synchromesh/SuperSynchromesh emulation support when Indus GT emulation mode is enabled. Previously the SuperSynchromesh speed was supported, but now the code upload commands are spoofed so that the GTSYNC.COM and INDUS.SYS utilities will actually be able to detect 1.20 firmware and "upload" code, selecting either the 38K or 68K baud speeds. The $A1 and $A3 format commands have been corrected for Synchromesh mode, and a workaround has also been added to allow Synchromesh sector writes to work (SuperSynchromesh writes were not affected).

 

[fujidude]

 

You need to select the SIDE device, click Add to add a hard disk to it, then edit the settings on the hard disk. The dialog to do this will automatically be displayed when the hard disk is added.

 

Thanks! That worked. I never realized that the add button changed its function depending on the context.

[morelenmir]

You need to select the SIDE device, click Add to add a hard disk to it, then edit the settings on the hard disk. The dialog to do this will automatically be displayed when the hard disk is added.

 

Update:

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

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

 

Adds Synchromesh/SuperSynchromesh emulation support when Indus GT emulation mode is enabled. Previously the SuperSynchromesh speed was supported, but now the code upload commands are spoofed so that the GTSYNC.COM and INDUS.SYS utilities will actually be able to detect 1.20 firmware and "upload" code, selecting either the 38K or 68K baud speeds. The $A1 and $A3 format commands have been corrected for Synchromesh mode, and a workaround has also been added to allow Synchromesh sector writes to work (SuperSynchromesh writes were not affected).

 

 

It is really nice to see you taking another look at the disk drive emulation features of Altirra again. Many, many thanks for this Phaeron.

 

Does the XF551 emulation also offer Synchromesh mode? This is something I have become very interested in lately given my renewed use of DOS XE.

 

One feature closely related to this that might be handy is to have the current data transfer rate of the active SIO devices displayed somewhere in the interface. I guess that might be quite wasteful of the host processor cycles though.

[morelenmir]

Possible bug here when using the newest version, released today.

 

I create a 65/130XE machine, using 128k memory, the XL/XE OS ver.3 firmware, Atari BASIC rev 3 and boot with the DOS XE master *.ATR in D1:. I then use the 'File->Disk Drives...' dialogue to create a new, ss-sd virtual image in D2:, without saving it and therefore accessed via the 'VRW' mode; all functioning in 'XF551' emulation. From the 'Ready' prompt inside the simulation I then shell up to DOS XE and enter the 'File Access Menu'. I then go to the 'Initialize Disk' sub-menu and tell it to format D2:. It automatically identifies the 'disk' in that position as an 'AT810' and asks for a type-in confirmation of this, which I give - again the virtual image is ss-sd. The final step is to press 'START' to begin the format. At this point the simulation seems to give a few of the expected beeps, but then freezes in to a crash. A soft reset via 'RESET'/F5 gives either a black screen or the Altirra crash dialogue. A cold reset will reboot the simulation as expected.

 

Update:

 

Further experimentation shows the same crash if the identical setup and process is attempted with an ss-ed/'AT1050' image. However if an ss-dd/'SSDD' image is used the failure occurs inside the simulation, reporting 'ERROR #173' without causing a crash.

 

In all these cases; ss-sd, ss-ed, ss-dd the same error also occurs if I actually name and save the new image before attempting to format it.

 

The only time an error doesn't occur is if I create an ds-dd (either VRW or saved) image which is then correctly recognized by DOS XE as of type 'XF551'. In this case the simulation will perform the format successfully after typing in confirmation and pressing 'START'.

[fujidude]

I'm not sure what the DOS-XE format procedure does to a disk, but if it simply tells the drive to set up the tracks and sectors, then there is no need as an .ATR is inherently "formatted" that way. If it is also setting up a file system on the disk then of course it needs to happen.

[fujidude]

One feature closely related to this that might be handy is to have the current data transfer rate of the active SIO devices displayed somewhere in the interface. I guess that might be quite wasteful of the host processor cycles though.

 

Hehe. Wasteful? Is it wasteful to drop a penny under a grate and opt to just leave it be? I suspect modern computers would hardly notice such a feature being added. I guess I'm saying I think that is a handy suggestion you made, and your own efforts to argue against it are inconsequential.

[morelenmir]

I'm not sure what the DOS-XE format procedure does to a disk, but if it simply tells the drive to set up the tracks and sectors, then there is no need as an .ATR is inherently "formatted" that way. If it is also setting up a file system on the disk then of course it needs to happen.

 

It does seem to write some content after a - brief in Altirra's case - scan of the surface. I'm guessing it records potential bad sectors along with initializing the folder tree given you can nest directories in this DOS.

 

In regards the virtual disk problem I encountered earlier - I seem to have got to the bottom of it. The *.ATR which claimed to be a 'DOS XE Master Disk' was not. A prior user had run the 'setup.com' app so as to look for only one physical drive, therefore when DOS XE was asked to work with D2: it failed on all manipulations; formatting, copying, the works. I guess he did it to save memory as I beleive DOS XE is considered generally to be very memory-hungry. Another pass with 'setup.com' to read acknowledge 4 physical drives and all is well. Annoyingly he must then have uploaded his custom setup as a pristine copy of the original distribution. Nevermind; I guess this happened long ago and when you consider all the virtual hands these disk images have passed through by now such things are bound to happen.

 

 

Hehe. Wasteful? Is it wasteful to drop a penny under a grate and opt to just leave it be? I suspect modern computers would hardly notice such a feature being added. I guess I'm saying I think that is a handy suggestion you made, and your own efforts to argue against it are inconsequential.

 

I guess you are right fujidude! The speed of modern computers is an order - several orders - of magnitude faster than the originals, although I do believe latency begins to become important when Altirra runs as a cycle-exact emulator. If it did happen that a SIO throughput meter was untenable then a simple indicator to show when Synchromesh/Super-Synchromesh was active would be very interesting too.

[lemiel]

Avery thank you for clarifying XF-551/Synchromesh modes and their emulation.Similar credits to Draco030.

[phaeron]

Update:

http://www.virtualdub.org/beta/Altirra-2.80-test15.zip

http://www.virtualdub.org/beta/Altirra-2.80-test15-src.zip

 

A bunch of changes that are a bit hastily tested, but should be of some interest:

• Flash DQ2 and DQ6 toggle bits are now emulated during multiple sector erase operations. This fixes a failure I saw with one of the newer DLT flashers while trying to update SIDE2 firmware, caused by the flasher thinking that the sector erase operation had already completed.
• Fixed crash when mounting an invalid hard disk. Also removed the Eject button, since this doesn't make sense anymore with the separated devices.
• Fixed a bug with the VHD module constantly rewriting the block bitmap after extending the file.
• The Disk Explorer wasn't bumping the volume sequence number on an SDFS volume after renaming a file. Took a while to figure out why a renamed file wasn't showing up in UFLASH....
• MMU is now forcibly reset when switching from 800 to XL/XE mode. Previously, if you had accidentally run a program that tried to disable the OS in 400/800 mode, and then switched to XL/XE mode, the kernel ROM would be erroneously disabled unless you did a warm reset.
• Fixed yet another bug in XF551 Set PERCOM Block command, which interfered with SSDD mode. I'll get it right eventually... there are only 12 bytes....

 

Does the XF551 emulation also offer Synchromesh mode? This is something I have become very interested in lately given my renewed use of DOS XE.

XF551 high speed mode is not Synchromesh, but yes, Altirra does emulate high-speed mode. This only works in the XF551 emulation mode, which enables quite a lot of XF551 specific behaviors (different format timeout, partial PERCOM block parsing, high bit commands, $A1 format, 300RPM timing).

One feature closely related to this that might be handy is to have the current data transfer rate of the active SIO devices displayed somewhere in the interface. I guess that might be quite wasteful of the host processor cycles though.

 

Well, there's only going to be one active device at a time... and to be honest it's not difficult to tell what speed the drive is running at. It's either going to be high speed or not, the high speed is determined by the drive mode, high speed loads much faster, and you can even hear the difference.

 

[mr-atari]

A bunch of changes that are a bit hastily tested, but should be of some interest:

• Fixed crash when mounting an invalid hard disk. Also removed the Eject button, since this doesn't make sense anymore with the separated devices.

 

Hmm, ok, that is a pitty.

I use it for MyIDE-][ to switch "cf-cards" or to run the system without medium.

So for now, I guess better to stay on test11? (before the new HD-interfacing)

 

Grtz,

Sijmen.

[flashjazzcat]

On a related topic:

 

 

• SIDE 2 CompactFlash removal detection is now emulated.

 

How do I trigger this? If I eject the HDD in test 13 (the first with the new device mappings), the SIDE loader just reports a disk read error.

[morelenmir]

Update:

http://www.virtualdub.org/beta/Altirra-2.80-test15.zip

http://www.virtualdub.org/beta/Altirra-2.80-test15-src.zip

 

A bunch of changes that are a bit hastily tested, but should be of some interest:

• Flash DQ2 and DQ6 toggle bits are now emulated during multiple sector erase operations. This fixes a failure I saw with one of the newer DLT flashers while trying to update SIDE2 firmware, caused by the flasher thinking that the sector erase operation had already completed.
• Fixed crash when mounting an invalid hard disk. Also removed the Eject button, since this doesn't make sense anymore with the separated devices.
• Fixed a bug with the VHD module constantly rewriting the block bitmap after extending the file.
• The Disk Explorer wasn't bumping the volume sequence number on an SDFS volume after renaming a file. Took a while to figure out why a renamed file wasn't showing up in UFLASH....
• MMU is now forcibly reset when switching from 800 to XL/XE mode. Previously, if you had accidentally run a program that tried to disable the OS in 400/800 mode, and then switched to XL/XE mode, the kernel ROM would be erroneously disabled unless you did a warm reset.
• Fixed yet another bug in XF551 Set PERCOM Block command, which interfered with SSDD mode. I'll get it right eventually... there are only 12 bytes....

 

 

XF551 high speed mode is not Synchromesh, but yes, Altirra does emulate high-speed mode. This only works in the XF551 emulation mode, which enables quite a lot of XF551 specific behaviors (different format timeout, partial PERCOM block parsing, high bit commands, $A1 format, 300RPM timing).

 

 

Well, there's only going to be one active device at a time... and to be honest it's not difficult to tell what speed the drive is running at. It's either going to be high speed or not, the high speed is determined by the drive mode, high speed loads much faster, and you can even hear the difference.

 

 

For some reason I have had that in my head since discussing the SIO2SD - that XF551 operated in Sycnhromesh!!! Weird!!! Not to mention stupid of me.

 

I don't usually run with the sound un-muted unless playing a game, so I miss the beep tell. Still, switching it back on I can hear that the tone is higher if the drive is emulating the XF551 and working with a DSDD/'XF551' formatted disk under DOS XE. Presumably this is 'Hyperspeed'/'fast-mode'whatever-it's-called doing its thing?

[morelenmir]

I don't know how practical this would prove to implement, but is there any possibility that Altirra could periodically save its state?

 

I may be the only person who does this, but after losing my physical Atari recently I have been using Altirra to enter type-in listings from magazines and books. I greatly enjoy this; there is something a little like doing a jigsaw puzzle about the activity I find, calming and helpful for stress. Just as with a real 400 or 800 though, when your book drops forward off the case and activates the cartridge door release there are very few things as stressful as losing all the typing you have spent the last 2+ hours inputting! I just encountered a similar problem when my machine crashed after typing in a little over 8k of listing... Annoying doesn't begin to cover it! If a recent state-save could have been reloaded that would have proved helpful to say the least and very beneficial to my rapidly thinning scalp!!!

 

Perhaps a setting could be turned on and off along with an auto-save interval so the feature was not running all the time - it would have little application to most situations like playing games after all. However I dare say Altirra would need to make a snapshot of too many pieces of data every time for this to be doable, but who knows - maybe?

[snicklin]

I don't know how practical this would prove to implement, but is there any possibility that Altirra could periodically save its state?

 

I may be the only person who does this, but after losing my physical Atari recently I have been using Altirra to enter type-in listings from magazines and books. I greatly enjoy this; there is something a little like doing a jigsaw puzzle about the activity I find, calming and helpful for stress. Just as with a real 400 or 800 though, when your book drops forward off the case and activates the cartridge door release there are very few things as stressful as losing all the typing you have spent the last 2+ hours inputting! I just encountered a similar problem when my machine crashed after typing in a little over 8k of listing... Annoying doesn't begin to cover it! If a recent state-save could have been reloaded that would have proved helpful to say the least and very beneficial to my rapidly thinning scalp!!!

 

Perhaps a setting could be turned on and off along with an auto-save interval so the feature was not running all the time - it would have little application to most situations like playing games after all. However I dare say Altirra would need to make a snapshot of too many pieces of data every time for this to be doable, but who knows - maybe?

 

Interesting idea. I can see that in your case that this would be a very good feature and I suspect that it wouldn't be too difficult to implement. It does however beg the question of why you're doing type-in listings. Aren't they all available somewhere and if not, why not?

 

As for the feature, perhaps it could keep a snapshot every X minutes (which you define) and then how many old snapshots are kept (user defined also) and then activate it (not on by default). You'd need more than just the last snapshot in-case an error occurred before the last snapshot.

[phaeron]

Hmm, ok, that is a pitty.

I use it for MyIDE-][ to switch "cf-cards" or to run the system without medium.

So for now, I guess better to stay on test11? (before the new HD-interfacing)

 

You can still do this. It's just done by adding and removing the hard disk sub-entry in the devices tree.

[flashjazzcat]

The new device setup is awesome. Now we can have IDE Plus 2.0 and Ultimate/SIDE HDD both at once:

 

[Heaven/TQA]

Phaeron... I just spotted sio2sd device... but how to use that?

[morelenmir]

Phaeron... I just spotted sio2sd device... but how to use that?

 

I am pretty sure in the past Phaeron said it was just a stub with enough functionality to allow the SIO2SD 'configurator' to run and believe that a device was present. It doesn't currently do anything - although that could well have changed since last September.

 

Another question to Phaeron! Is the host device access meant to work in Atari DOS 2.5? I find it will list a proper disk directory if I choose Option A and direct it to 'H1:'. However, if via Option C I try to copy all the files from D2: to H1: I receive 'Error 150'. According to the excellent Page6 article on Atari error codes this is an RS232-C device error. It would be handy if this process were possible as it would allow batch copying of files from a disk (image) formatted in one version of DOS to another via a host device intermediary - assuming they both use CIO disk access. At least that is what I am trying to use it for.

[flashjazzcat]

I think MyDOS and DOS 2.5 fail to handle "foreign" device names during copy operations. You can get around this easily in Altirra with "Mount as D:" in the host device dialogue. Then you can refer to host volumes as "Dn:".

[morelenmir]

I think MyDOS and DOS 2.5 fail to handle "foreign" device names during copy operations. You can get around this easily in Altirra with "Mount as D:" in the host device dialogue. Then you can refer to host volumes as "Dn:".

 

Many thanks FJC!!! That works a treat. I always wondered what that setting was for - now it makes sense.

[Atari_Ace]

I've been playing around with the In-Store Demonstration cartridge in Altirra (examining how the Forth kernel is implemented) and discovered a possible bug in Altirra's OS emulation. A few minutes into the demonstration the screen "Your Atari Personal Computer System Can Help You Acquire and Transmit Information" appears. It vertically scrolls some text, which works fine with the XL/XE os, but gets garbled with the AltirraOS (XL/XE and HLE) with version 2.80-test15.

 

 

[morelenmir]

Obviously it is not easy to reproduce here, but I find that the inverse clear screen character - an inverse-video left-bending thick arrow - is not being produced properly. It should appear with the "ESC Ctrl+2" key combination, but does not. Instead you get a solid bar. The normal version of this character does work properly via 'ESC Ctrl+Clear' or on the PC keyboard 'ESC Ctrl+Home'.

 

I have tried all the three different keyboard combinations with both the official 800XL and 130XE firmware. Is this a bug or have I missed something?