ijor
-
Content Count
2,621 -
Joined
-
Days Won
2
Posts posted by ijor
-
-
10 minutes ago, phaeron said:Sure the timing information in this disk image is correct? The sectors on track 0 only have timing values up to $2D78 (11640), which is only up to half what ATX images normally use for a full revolution.
Oops, you are right! I will post a fixed image later. Sorry about that.
-
Thanks again everybody for the help and contribution.
-
1
-
-
Attached an ATX image of disk 1 of Atari Accountant. This is a software designed for the Atari 815 disk drive and it is the only known copy protected title in double density.
Note that this is a reconstructed image; we don't have a full image of the original disks. Please see this for more information about how the data was recovered:
https://atariwiki.org/wiki/Wiki.jsp?page=The Atari Accountant Series
Note also that we don't know the exact copy protection that was present on the original disk. We only know that the software attempts to read a specific sector and expects the drive to return an error. I just crafted an image with a track layout that would produce that behavior.
The 815 drive, contrary to any other Atari 8-bit drive doesn't invert the disk data. But in this image the data is inverted so that it could be run on other Atari double density drives such as the Us Doubler.
The software requires Basic and I've been told it also requires OS-B. I didn't test it thoroughly, only confirmed that the copy protection check passes and the software loads correctly.
For running under emulation it requires Altirra version 4.00-test16 or later and with current versions it might also require to enable the config option "image.disk.atx.full_sector_support". This option will probably not be required in future versions.
Edit: The image posted at this post has been deleted because it was built with wrong sector timing. An updated image was posted below at post #6 in this thread:
Thanks to @jaybird3rd for allowing this edition.
-
3
-
-
We implemented the following additions and enhancements to the ATX file format.
- Define additional densities at the file header
- Implement recording bitrate at the track header
- Support full content for long sectors
- Support double density, double sided and other densities
Include in the attached zip file is a short document and an updated .H header file. I wanted to polish a bit more the document and build some few more samples but currently I'm short of time. I decided it's better not to wait and post an update if necessary.
Thanks to Phaeron and other people for their invaluable contribution.
-
8
-
On 9/25/2020 at 8:45 AM, ebiguy said:Maybe you can tell me which free creator signature we should use for RespeQt once you have all the signatures from the other tools.
The field is 16 bits so as you could imagine most values are still free. You might want to choose two letters that resemble the RespeQt name somehow?
-
1
-
-
10 hours ago, djmat56 said:I too would be interested in hearing if anyone has used a greaseweazle. Thinking of getting one. What 5.25 drives are recommended?
For the greaseweazle, you may want to check this thread:
For the disk drive, if you are planning to write back images, it is better to use an older 48 tpi drive (40 tracks) and not a 96 tpi one (80 tracks).
-
1
-
-
6 hours ago, Nezgar said:Without listening, re single density boot sectors, maybe he's mis-attributing the format behaviour of the 1050 Duplicator...
I doubt it. But even then, it still wouldn't make much sense because he claims that he had to modify DOS for that reason ... listen to the interview, it's worth
-
On 9/15/2020 at 4:47 AM, Nezgar said:This is further evidence that Percom never had their hands on an 815 as an example, otherwise they may have mirrored the 815's 16:1 interleave, and non-inverted sectors for DD operation for compatibility...
Did you hear to the Atari podcast interview with Charles Marslett who wrote the Percom firmware? If I understand correctly, according to him Percom did have a prototype and a copy of the DD DOS. Actually he mentions that the whole idea of Percom developing a DD drive was precisely because Atari killed their own DD project. Mr Marslett also mentions an issue with the boot sectors being single density that doesn't make much sense to me, but otherwise he seem to remember things quite well.
-
1
-
-
On 9/16/2020 at 5:22 AM, phaeron said:Yeah, I'm basically ignoring this since the backing store is decoded data, so you can freely exchange disk images with the other drive types in ways that wouldn't work with a real 815. However, I don't think anyone has use for ATRs that have inverted data.
Beg to differ but, personally I would like this to be configurable. I do realize the convenience of sharing ATR images with the other Atari drives. But, IMHO, this makes the emulation less accurate. A disk that works on the USD should not work in the 815 and vice versa. Conceivable, somebody could make a program to convert 815 disks by inverting the data, and this would fail under emulation. I agree that these are extreme cases and you can say I'm playing the devil's advocate. A slightly (just slightly) more realistic case, though, would be when dumping a real 815 disk to ATR. Or writing back an ATR to use on a real 815 drive. It would fail in both cases with this scheme.
Again, this is very exotic I can perfectly understand that the whole thing might not be worth to implement a configuration option. I just thought I should mention the issue.
-
On 9/23/2020 at 10:01 AM, moonlight_mile said:I attached the jumper settings for the st and pc from the manual. I am thinking I probably should use the pc settings. What do you think?
Probably yes. ST drives normally are jumpered as drive B. You probably need, at least, to change the jumpers for drive A.
-
I'm implementing this shortly. In the meantime, I would like to compile a list of all the ATX image creators.
So everybody that implements a tool that creates ATX images, please record your creator signature here. Remember that this is a 16-bit field in the ATX file header. I'll include the list when publishing the new track definitions for the new enhancements. Thanks.
-
2
-
-
It is not fixed at the hardware. It all depends on the firmware and we have more than one, now. I don't remember the details in each version, and later versions are highly configurable, so they might even allow you to configure the exact behavior.
-
It is perfectly possible to use a Gotek or a PC drive externally. The main, perhaps only, problem, is how to adapt the custom ST external floppy connector and powering. You can build your own cables. Or as many do, just adapt a 314 case and reuse the 314 cabling and power. You can even just drop the Gotek inside the 314 without doing any modification if you want.
-
I'm implementing a few enhancements to the ATX file format. One of them is potentially a bit delicate in terms of backwards compatibility. Especially now that there are several implementations in embedded SIO2XX hardware where changes are not as easy to implement. So I would like some feedback from the developers before establishing the final format.
One of the copy protections used on the Atari is so called big or long sectors. Sectors on a single density track normally have a size of 128 bytes. Long sectors are formatted with a physical size of 256 bytes, or sometimes more. The drive doesn't expect this and produces an error (the exact behavior depends on the firmware) and this can be verified by the protection check. ATX images already specify this type of error, but they don't include the full data of the sector beyond the first 128 bytes. In most cases the full content of a long sector is not important because the computer normally can only access the first 128 bytes. But there are a couple of cases that the full content is relevant and then the idea to extend the format to support including the full sector data.
There are a couple of ways to implement this that I am considering. The simplest way would be simply to include the full content at the normal sector data location in the track record. ATX images already support recording the exact physical size of long sectors, and that can be easily extended to signal that the full content is stored. The problem with this method is that, conceivable, it might break backwards compatibility with software that expects that data for every sector would always be 128 bytes. I'm not concerted about older software not being able to access the full sector data. That of course can't be helped. My concern is older software being confused by the larger track data record and not being able to process the track correctly at all.
The other way is to implement a new out of band chunk and store the full sector data (or the rest of the sector data) in that new chunk. This probably would have a lower risk of breaking backwards compatibility. But out of band processing is always a bit of a PITA, and this is definitely not the most efficient method.
The other enhancements would be to optionally store the recorded bitrate and support for higher densities. These are simpler to implement, at least from the compatibility point of view.
-
1
-
-
13 hours ago, Jeffrey Worley said:All double-density Atari disks have three single-density sectors as the first on the disk, whatever the disk format is afterwards, single or double.
Actually no. On almost all cases all the sectors on double density disks have a size of 256 bytes. The drive firmware does treat the three first sectors as single density for the purpose of transmitting the sector to or from the computer, but that is another matter.
The only exception that I know are disks formatted with the Duplicator that format those sectors at 128 bytes, and that make those disks incompatible with some other double density drives.
-
23 hours ago, djglish said:I do want to take an internal drive from one computer and use it as an external drive for another computer. Good to hear that it should be an easy thing to do. Now to figure out how to bring the cable out of the case.
Again, the "easy" way, at least electronically, to do that is not to bring the cable outside, but to use the external connector. If you want to use the internal cable, which might be easier mechanically, then unless it's an STE, it requires some modification to the motherboard because the drive B select signal is not present in the internal cable.
-
If I understand correctly, you want to take the internal drive from one computer and use it as the external one on another, right?
If so there is no need to change any jumpers or straps, you "just" connect it to the external connector. The external connector is already wired for the correct drive selection.
If you want to use the internal cable instead of the external connector, say, using some kind of splitter, then it depends on the exact computer model. The main difference is that the STE cable carries both select signals, but the ST one does not, at least not by default.
-
6 minutes ago, Suffolk said:Castle Wolfenstein starts to load correctly for about 5 seconds, then settles into the slow 'beep' and boot error. Beyond CW does a little better and sounds like a normal boot for about 10 seconds, then it get stuck. I hear the head moving and I'll hear it boot a little, then eventually just stops and the drive goes quiet...no constant boot error like CW.
There is probably nothing you can do. Some disks can be cleaned, if that is the problem, but I suspect it's not the case here. This two titles are known to be among those that often the disk surface deteriorates. In such a case it is even better not to keep trying or you might completely destroy them.
It is possible that's not the case, and it's "just" magnetic corruption instead. If so it should be possible to rewrite the faulty sectors or tracks. But that might require some knowledge. And honestly, many of us dislike the idea of writing over original disks.
Any reason why you want to use these two copies? You can download images and write them to blank disks. Just leave the originals, even when not working, as collectibles.
-
3 hours ago, drac030 said:If I calculate correctly, slowing the rotation down to 288 rpm gains 250 bytes per track in MFM. But yes, there is probably a good reason why they (or anyone?) did not use floppies with even less rotations per minute.
At 288 you are already using a density 4% out of the nominal value. You would need to reach close to 10% higher density to gain just one extra sector. And MFM is more error prone than FM. The same RPM and density that might more or less work at single density might be much less reliable at MFM.
3 hours ago, drac030 said:This could probably be solvable by slowing the rotation down only in the new density (MFM). I doubt though if such a drive could be cheap.
Yes, it could be an acceptable solution to that particular problem. And actually it might be affordable. Several enhanced Atari drives have two, or even more, pots for changing the RPM speed. This was used to copy some copy protections with more than 19 sectors. But then how much cheaper, if at all, that would be than adding 128 bytes of RAM for using "true" double density.
-
1 hour ago, drac030 said:What if they clocked FDC faster or slowed down the rotation speed (yet more)? Are there any bad side effects of slow rotation speed, like too great bit density, ...
Yes, that would increase the actual flux magnetic linear density and it would certainly affect reliability. Of course, a very small increase in the density probably wouldn't be so bad, but then you won't gain too much either.
There is also an issue of backwards compatibility. Altering the angular recorded density (FDC clock and RPM) would make less reliable to access old disks recorded with the original 810 bitrate and also the other way around, accessing "new" disks with an old drive. Again, the bigger the difference between the original and the new density, the less reliable the backwards compatibility would be.
Finally, there is an issue of breaking copy protections. As we know from the XF-551, some protections break just as a consequence of the disk rotating at a faster RPM altering the whole timing; even when the effective magnetic density is the same.
It is just a guess, but it is possible that maximum backwards compatibility with the 810 was very important for Atari. I understand that one of the things that killed the 815 project, besides perhaps the cost, was that it was completely incompatible with older disks.
-
I guess the main reason was, cheapness indeed. A big question is this was an internal Atari design or if it was designed by Tandon.
5 hours ago, thorfdbg said:Frankly, I doubt this. The format, and that is the sector size and the number of sectors per track, is up to the floppy controller chip, and its specification were "out of reach" for Atari to change.
The FDC doesn't impose any strict limit on the number of sectors per track. Some sector numbers in the $F5-$FF range are "problematic" (you can read and write them, but you can't format them) but otherwise you could have up to 256 sectors per track, if you insist. Of course, you need enough space on the track to fit all those sectors. The FDC also sets the minimum overhead per sector. But still you have some degree of freedom and as we already know, i.e., it is perfectly possible to fit 19 sectors per track on single density and surely more than 26 on enhanced density. It might be considered less reliable, though.
-
On 9/6/2020 at 8:36 PM, phaeron said:It might be safe to de-energize the phases by setting D2-D5 to inputs, in which case those bits could freely be written in the output register.
If that would be safe it would be ideal because then no table would be required at all, and transmission could be easily performed at even just 6 cycles per bit. But I'm not completely sure it is safe. Have you seen any 1050 firmware that puts those signals in input mode?
I was trying to dig all the RIOT datasheets available. And it is not clear what is the exact behavior of the ports. Specifically, I don't know for sure if there is a pullup active when the signals are on input mode. Contrast with the PIA datasheets that do explicitly specify the pull up on PORTA but not on PORTB. If RIOT behaves like PIA, then the inputs on PORTB would be on high impedance. And as far as I can see at the 1050 schematics there aren't any external pullups at the board level neither for any of these signals. The signals are not connected directly to the stepper. They go through high current drivers that, again, as far as I can see on the datasheet, don't have internal pullups either.
So, this could mean that setting the signals as input might leave the input to the drivers floating and they might have unpredictable output behaviour. May be somebody with more knowledge of this kind of stuff can confirm this.
4 hours ago, E474 said:Presumably the Happy would store the current value of these 4 bits in a variable somewhere, and then use them when it was transferring data to the 8-bit, so it should be in the code starting at $F000 (see https://github.com/e474/DUMP1050/wiki/Atari-Magazin-Happy-Programming-Course-Article-1) in the Happy ROM. I had thought the simplest way to handle high speed transfers would be to read from the track buffer (assuming it could co-exist with the 2K LUT and uploaded code), and use the Happy subroutines to read sectors and tracks into the Happy RAM. I think that is still a valid approach, provided I can dig out where the bit pattern is stored.
Not too difficult to find where the stepper phase is stored, but you don't actually need it. You can read the current state directly from the RIOT register.
I think that a single density track buffer would likely fit in RAM, but obviously a double density one will not. You have slightly less than 6K because the Happy ROM uses a couple of RAM pages for data and code.
-
21 hours ago, jamm said:Moscow 1993 (1994)(Sikor Soft)(PL)[!].atx
QuoteThis is an enhanced density disk that for some reason was included in the torrent missing the MFM flag. It does work for me if I set the flag, at least it loads. Note that what it matters is the MFM flag at the track header.
I did check, and none of the tracks have the MFM flag set.
Yes, may be I didn't explain myself correctly. The tracks indeed don't have the MFM flag set, and that is a mistake. If you set the flag on all the tracks, then it loads. At least it does to me.
On 9/6/2020 at 9:44 PM, jamm said:There are several cases where the UNKNOWN_SKEW (0x0100) flag is set on tracks. What does this really indicate (i.e. how should that be handled, if at all)? Ignoring it seems to have no negative repercussions.
Forgot to answer this one. It indicates that the skew alignment (alignment between the tracks) is unknown. This could be for several reasons, such as because it was processed by hardware or software that can't measure the skew alignment. There is nothing you can do about that, it just an informational flag.
-
2 hours ago, jamm said:As part of the work done to add ATX support to FujiNet, I wrote a little ATX parser/analyzer program...
Most of this is my fault. And most of it, for historical reasons. Take in mind that the earlier ATX images and tools were created many years ago. Among other things, this was years before the advent of the Kryoflux and the SCP. And it was done mostly for personal backup, not for actual preservation purposes at that time.
2 hours ago, jamm said:Also, can someone provide a list of what programs are responsible for each of the "creator" codes found in the ATX headers?
We need to create a new "official" database of creators. The only ones I know so far besides my own tools are Phaerons's ones. As you might have read on some other threads, we are adding some new extensions to the specs, so that would be a good opportunity to address a full list of creators as well. Btw, please keep in mind that the creator field is 16 bits.
2 hours ago, jamm said:ATX Header End Field and Host Records
Creator 0x10 (ATX_CR_WH2PC) adds a HOST record at the end of every file.I used this record for remote debugging purposes when people used the legacy Vapi imaging tools on a Happy or similar enhancement. Ignore this record. In general, you should ignore any record you don't know.
2 hours ago, jamm said:There are a couple of instances of images with creator ID 0x01 (ATX_CR_FX8) where the ATX 'end' field off by 8 bytes.
That seems to be a bug on some versions of the tools.
2 hours ago, jamm said:Bad Angular Position Values
I'll need to check that.
2 hours ago, jamm said:There are several instances of images with creator ID 0x01 (ATX_CR_FX8) where sectors are marked with bit #2 (0x02).
This is the DRQ bit of the FDC status register. Most bits on the sector header status are the corresponding ones on the FDC status register. Some tools set this bit for "big sectors" together with the DATA LOST bit, because some Atari drives will have this bit set on the status register when reading such a sector. The actual behavior depends on the exact drive and firmware.
2 hours ago, jamm said:There are a couple of instances of images with creator ID 0x01 (ATX_CR_FX8) where sectors have an invalid sector number.
Some tools encode sectors with invalid sector number if they are present on the disk. You should normally ignore them.
2 hours ago, jamm said:Max + Magic World (1997)(Sikor Soft)(PL)(Side B)(Magic Word).atx
- Track 37: Sector numbers between 19 and 26
- Track 38: Sector numbers between 19 and 26
Those tracks are FM (single density) and the sectors you see are still present on those tracks.
2 hours ago, jamm said:Moscow 1993 (1994)(Sikor Soft)(PL)[!].atx
- Most tracks have sector numbers greater than 18. Maybe this one simply has the wrong density header value and should be marked as "ENHANCED DENSITY". I tried changing just the density header value, but it still wouldn't load in Altirra.
This is an enhanced density disk that for some reason was included in the torrent missing the MFM flag. It does work for me if I set the flag, at least it loads. Note that what it matters is the MFM flag at the track header.
-
1
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
ATX file format additions and enhacements
in Atari 8-Bit Computers
Posted · Edited by ijor
That image I posted earlier has bad sectors timing. It worked emulating a US Doubler, which is what I tested, but as Phaeron explained it fails if emulating an 815. Attached fixed image. May be a moderator can give me permission to edit post #2?
AtariAccountant-Atx-FixedTiming.zip
Attached also an image of the Archiver Editor by Spartan for the Happy 810. One of the very few titles that requires full data stored for long sectors. For testing on Altirra enable Happy 810 full disk drive emulation. Again, it requires Altirra version 4.00-test16 or later and and might also require the config option "image.disk.atx.full_sector_support".
ArchiverHappy810-Atx.zip