Altirra Question

[TGB1718]

I have some .ATR images from way back that I created from original disks using SIO2PC (file date is 2010) although

the original disks are from the 80's.

 

The disks I have problems with are High Speed US doubler. I have read that Altirra can load these types of disks.

They are using SpartaDOS.

 

When I try to load some of the images under Altirra, it reads the first 3 sectors which loads the high speed driver, then hangs.

 

I know the images are fine as I can load them into my 130XE using Respqt on a Pi and from my recently built SDrive-Max.

 

I have set the emulaton to US-Doubler, Happy, 1050 Turbo and even standard 1050, but nothing works.

 

Any ideas what I'm doing wrong/missing ?

[Mclaneinc]

Have you checked that you have the right firmware for the fully emulated drives?

 

You might want to post an example atr you are having issues with, I'm sure there's a simple fix..

Edited May 3, 2019 by Mclaneinc

[TGB1718]

Not sure what you mean ? I don't see any options to change the drive firmware, only what drive emulation to select

[Mclaneinc]

Ah, you are using the settings in the file / disk drives menu and not an in built device emulation of a real drive...

 

Post an image, I'll look at it right now..Also, what version of Altirra...

Edited May 3, 2019 by Mclaneinc

[TGB1718]

Altirra 2.81

 

[Mclaneinc]

Yeah, sorry, wrong image type, I meant an atr image file

 

And I can't stress how much its worth going up to the latest beta, Avery packs in TONS of new features and fixes in the beta updates and the are incredibly stable, its rare we need a fix that we notice, its usually new features or emulation upgrades.

 

There also has been LOTS of drive related changes since that version...Seriously, pick up the latest beta from the 2.90 thread....You won't regret it...

Edited May 3, 2019 by Mclaneinc

[scotty]

Mclaneinc is right. Grab the latest Beta. Under 'Configure System', this is where you want to configure your drive. Look at all the options!!! Avery = Santa Claus!

 

[Mclaneinc]

Avery is Santa Claus?

 

So its him and his mates that leave reindeer crap on my roof every year!!!

 

Cleaning bill on the way!!

[TGB1718]

Thanks, will upgrade and try again, will try not to step in reindeer crap as I go

[Mclaneinc]

If you get no joy then post one of the non working (In Altirra) files and I'm sure it would be sorted or at least an explanation..

 

Here's hoping that it now works and do have a dig around in the new beta, its MAJORLY different....

 

If you need any tips then post up and one of us will be able to help...

[phaeron]

While upgrading to a newer version is a good idea, it shouldn't be necessary for this as Altirra has supported high-speed US Doubler for a long time, even without full drive emulation. I don't recommend using the full drive emulation modes in the picture above unless it is needed and it is not needed for high-speed operation.

 

A more likely reason for this issue is the high speed driver on those disks having a hardcoded dependency on the Atari XL/XE OS. Altirra defaults to its own built-in OS until you set up the ROM images to use (since they can't be distributed with the emulator). Having a high-speed loader within the boot sectors is a bit weird, though -- I had thought most or all versions of SpartaDOS had US Doubler support built in, and the versions I have don't switch to high speed until after about a dozen sectors.

[TGB1718]

There is a possibility that they are not SpartaDOS, I used to 'tinker' with most DOS's to see if they could operate at high speed too,

I did manage this with SmartDos and possibly others, so it may be my boot code is fouling things up.

 

Unfortunately I have lost most of the code I wrote due to a lot of my floppys degrading so badly they are unreadable.

 

I'll try your reccomendation and use a 'real' ROM

[Mclaneinc]

I should have asked that question re what OS firmware you were using, its a standard check that I forgot, hopefully now Avery has pointed the way your images / atrs will now work...

 

There's places to get the OS's like Xformer that have them but if you run out of places give me a PM.

 

Have fun

 

Paul..

 

PS, you might want to ask if anyone could look at those unreadable disks to see if they could be tinkered back to life....We have some extremely clever tinkerers in here

Edited May 4, 2019 by Mclaneinc

[TGB1718]

Still unable to get any to work, however using SDrive and my 1050 I managed to load a few of the .atr's they are a mixture of OS/A+ V2 and

SpartaDOS v1.1.

 

The common factor for both type is that they have been formatted with 'Sector Scew' for high speed.

 

I used a SpartaDOSXL ATR, booted from it and was able to browse the disks, I had to use a real floppy as for some

reason COPY to the SDrive kept failing from these ATR's, once on the real floppy I was able to create a blank ATR on

the SDrive and copy the files to it.

 

The ATR I created works with Altirra, I'm pretty sure Altirra should be able to read these ATR's but I'm stumped.

 

I have tried the OS firmware and the 1050 Happy firmware, but neither work.

 

The reason I think it's the Sector Scew is the OS/A+ disks do not load the fast SIO routines on boot, they have been formatted

using SpartaDOS then OS/A+ installed later, when I used these in the past, I wrote a high speed SIO driver,

so after booting an OS/A+ disk, I typed "FAST" and it loaded my routine (FAST.COM) and installed to fast SIO driver.

 

Finding some real gems I had forgotten about on these disks.

 

Think I might have been the first person to write a program to copy SS/DD disks on a 130XE in 2 passes on a single drive system.

I did it for a friend who had to create lots of copies of data disks and couldn't find anything commercially and was fed up with all the disk swaps.

I found the source for this (happy days)

[phaeron]

If you have a sample image, I could take a look at it and try to figure out what's going on. The sector skew shouldn't matter, because the ATR format doesn't encode sector timing at all, it only encodes sectors according to logical sector number. This is actually a problem when emulating accurate rotational timings as such a disk will read way too slow unless it's fixed up to use the correct sector skew. That doesn't affect whether it works at all, though, unless the fast sector read routine is busted and has a timeout that's way too short.

[Mclaneinc]

TGB1718, if you are worried about the content on the image, I say this as I asked for an image to test a couple of times, then PM it to Phaeron directly..

 

To be honest there's probably nothing on any disks that could stun anyone after all this time unless its personal data etc which is totally private..

[TGB1718]

Here is one of the images, I believe this one is OS/A+ and has no files other than DOS.

The reason I didn't post one before is I didn't know whats on the disks, I used to write

all my correspondance using AtariWriter and wasn't sure if that was one of my data disks.

OSAplus.ATR

[Mclaneinc]

You will get your proper answer now from Phaeron....Doing the same thing here with what I've thrown at it so far....I'll keep trying other things just in case..

[flashjazzcat]

I wonder if this has something to do with padding after the boot sectors, since it does work with RespeQt but crashes (in different ways) in Altirra and when booted from my SIDE loader. In Altirra, the loader jumps into empty RAM, and my loader results in the OS crashing after jumping through DOSVEC (which points to uninitialised RAM).

[flashjazzcat]

Yes: boot sector padding detection is causing this, and somehow RespeQt is somewhat more tolerant of this ATR's quirks than either the emulator or my PBI BIOS.

 

After mounting the ATR with the SIDE loader, I noticed that the ATR padding flag in the partition table in RAM corresponding to the image was set. Clearing it allowed the ATR to boot normally from the FAT host partition.

 

Opening the ATR up in a hex editor reveals that there is of course no padding after the single-density boot sectors, so it's apparent that the paragraph count coupled with the overall file size of the ATR is fooling us into believing that there are 384 bytes of empty space after the third boor sector. Will have a closer look at why later on.

[flashjazzcat]

Changing the paragraph count from $002D00 to $002CF8 fixes the image in both Altirra and my PBI BIOS. It would be nice not to have to edit the image header, though. RespeQt (which handles the image OK) checks for padding based on the actual length of the file (in comparison to the stated number of 16-byte paragraphs), whereas my implementation (which doesn't actually have access to the file size) calculates the number of DD sectors and then subtracts their footprint plus the footprint of the SD boot sectors from the paragraph count. I can't find Altirra's ATR parser in the sources, so I'm not sure how Avery goes about things, nor even whether the problem there has the exact same cause.

[flashjazzcat]

Hmmm... let me revise my stance on this. On closer inspection, RespeQt handles the problem ATR by virtue of not dealing with padding following the boot sectors of DD ATRs at all. I finally found an ATR with padding here and found it to work perfectly well with Altirra and my PBI BIOS. It fails to boot in RespeQt, meanwhile.

 

So: padding detection in my firmware definitely causes incompatibility with this odd (no padding) ATR, but I can't say for sure whether the same thing is happening in Altirra. If I had to choose, I think I would prefer to continue handling the more common padded ATRs (never having encountered an ATR with the odd characteristics of the one posted in this thread).

[_The Doctor__]

I wonder how both will act with real hardware being written out to real floppies and different hard disks. A posting of each/ padded and not padded /and I might even see how ape deals with each as well. A simple yes worked or no it didn't sort of affair.

[flashjazzcat]

No need to wonder. If the padding in the ATR is misinterpreted as sector data, junk will be written out to a real disk if you copy the content. If there's no padding or the padding is properly handled, everything will work fine.

 

This disk has padding after the boot sectors:

 

OS A+ 4.1.atr

[phaeron]

Cursed time zones, fjc got in first.

 

Altirra's ATR parser is in diskimage.cpp, specifically the LoadATR() function. It tries to deal with three different ways of encoding boot sectors in a double-density disk image, all unfortunately seen in the wild:

1. 3 x 128 bytes
2. First 128 bytes of 3 x 256 bytes
3. 3 x 128 bytes, then 384 unused bytes

#1 is distinguished from #2 and #3 by the paragraph count, which fails in this case because the paragraph count is too high and specifies 720 full-sized sectors. File size wouldn't help here as it matches the paragraph count. Which means that there is no definitive way of distinguishing this disk encoding from #2 or #3.

 

So yeah, probably not something that can be automatically detected, and would prefer not to support it to try to stick to the three types already seen more commonly. For existing disks with this issue, reducing the paragraph count in the header and dropping the last 384 bytes should correct the disk image to the most common form. Paragraph count should be $2CE8, though, not $2CF8 -- 720 * 256 - 3 * 128 = 183936 ($2CE80).