Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

431 Excellent

About Atari_Ace

  • Rank

Contact / Social Media

Profile Information

  • Custom Status
  • Gender
  • Location
    Tucson, AZ
  • Interests
    Atari 8-bit, Biking
  • Currently Playing
    Halo Collection

Recent Profile Visitors

10,711 profile views
  1. I took a look. Sector 15 should be the last sector of the file MENU, but it links to sector 16 which is the next file AMAKER.APR. If you make sector 15 contain a single byte (0x16), MENU then becomes a valid BASIC program. The only other metadata issue appears to be that when a copy of INSIGHT.APR was deleted from sectors 23-34, the VTOC wasn't cleared, but that's a common issue on old disks. So here's the "fixed" atr. Compute_disk_1988_April_f1.atr
  2. Thanks for these, I've updated the listings. As I expected, it was in code without checksums. Colon/semicolon and period/comma errors, I should have guessed.
  3. Please send me any errors you spot. I validate the code against the "Program Perfect" codes if they are there, but that checksum is fairly weak, and not all the code has checksums. I generally start from the OCR's and clean them up. The OCRs of the listings are generally terrible, but the article text OCR are usually pretty good. I find the work relaxing, and don't mind the time spent doing them.
  4. Cool, this archive has a set of Tyne & Wear (TWAUG) newsletter disks. All the copies of those newsletters I've found on the internet before seem to come from the same source and some of the disks are clearly damaged. For instance, issue 2 has severe 0x82 byte corruption and is essentially unusable. In the past I'd started the process of repairing the damage, but with hundreds of sectors to fix and no other source for some of the content, it was unlikely I'd ever be able to completely repair the disks. Imagine my delight when I noticed that OHAUG260A,B is that newsletter, and it doesn't have 0x82 byte corruptions. In fact, using "cmp -l" I can verify the only differences in the files are the byte 0x82 corruptions. The other two disks in the TWAUG collection I know have problems are 16B and 19A, and the OHAUG copies of those are identical to the ones previously archived, so no help there.
  5. Perhaps we can recover some of the bad sectors with a different drive, but probably not, and unless the disk contents are unusual it's probably not worth the effort. I updated my disk parser to look for and do some basic analysis of PrintShop disks (there were quite a few in this collection) and I found at least a couple that have issues. OHAUG323A.atr: Sector 371 should be a directory sector, but it seems to be another random sector. I reconstructed the 4 directory entries with placeholder names for now. OHAUG591A.atr: The last couple of directory sectors (392, 393) look corrupted. The end of the sectors look like DOS files. Since the data is mostly zeros, most of these entries should be ignored by PrintShop, but I just had to zero one additional byte to make the directory consistent. I don't see any PrintShop files after the last valid entry, so I don't think anything was lost, but I should look more closely at this disk later. The issues I'm seeing are common in all user group disk archives. The fast hardware disk copiers had a bug that wrote 0x82 to the 3rd byte in a sector if some sequence of operations was done, and disks formats fade with time. I'll post my fixed disks and my notes after I've had more time to examine the disks.
  6. Awesome! More disks than Bellcom, this is going to be a treasure trove. I made a first pass through the files looking for metadata corruption or other errors to look into later (repairing disk collections is an occasional hobby of mine): At least 40 disks have byte 0x82 at sector offset 0x02 corruption in the DOS directories/vtoc, which are usually repairable. There are some disks though that are full of those errors and will likely be hard to fix (e.g. OHAUG238A.atr, OHAUG491A.atr, OHAUG596B.atr, OHAUG615B.atr have >100 sectors damaged). Another 35+ disks have empty sectors inside files, which will require tracking down another source for the files. An example is OHAUG015A.atr, which is blank starting at sector 599, even though the disk looks like it should be nearly full. The zeroed files are common ANALOG games, so easy to replace in this case. 8 disks have duplicates in the collection. Half of these are side A and B are the same (OHAUG058A,B; OHAUG585A,B; OHAUG685A,B; OHAUG686A,B), so they might have been archived incorrectly. I only spotted one truncated disk, OHAUG563B.atr should have been a 130K disk. It was probably duplicated incorrectly, I've seen this error in other user group archives occasionally. This collection is going to keep me busy for awhile. Hopefully it will help restore files in other user group archives.
  7. From the Bellcom 1992 catalog (on archive.org): ■ D-83 PEDROKKO #6 Side 1 contains additional voice excerpts from the Teenage Mutant Ninja Turtles series, while side 2 contains larger “scenes” created using Turtles sound track samples. (Side 2 requires 130XE and player from #D-78) If you just want to browse what's in the Bellcom collection, start with the catalogs.
  8. The Games in Basic disks appear to be compressed binary blobs with no structure (zipping the atrs strongly hints that they've already been compressed). Now I'm curious what created those disks.
  9. There may not have been a July 1991 issue. The June 1991 issue I bought at a bookstore had a little circular "July 1991" sticker over the date on the cover (which fell off at some point, but I can still see the discoloration over the date).
  10. Thanks Farb, very much appreciated. Here are three additional dat files that aren't in that collection. a8preservation-extra.zip
  11. Yes, I'm asking for the file metadata rather than the files, which typically was included as .dat file with entries like so: game ( name "Mr. Do! (1984)(Datasoft)(US)[disk]" description "Mr. Do! (1984)(Datasoft)(US)[disk]" rom ( name "Mr. Do! (1984)(Datasoft)(US)[!].atx" size 63496 crc 5ca7b209 md5 1407cf37bcfb4fcf4cdf53c578698b48 sha1 343e81cd9f2cbdadea46c3a8edfa755719867146 ) ) Perhaps recent releases have dropped that file, but earlier releases had it.
  12. Can someone post the "Atari 8bit Preserved Software yyyy-mm-dd.dat" file for these releases in addition to the giant archive? I've given up on downloading these giant archives (too much content I either already have or am not interested in), but I do try to update the names of my existing files to match the preservation project when I have a chance. Older releases usually had the dat file which contained all the file metadata, so you could validate your files. I tried poking around the website but could only find metadata for individual items. Perhaps if I had an account it might expose something, but I'm not going to speculatively create an account to find out.
  13. I blogged a few years ago about getting DOS2 directories from atr images to illustrate how to build your own tools using perl for working with disk images: Extracting data from DOS 2.0/2.5 disks - Atari_Ace's Blog - AtariAge Forums To accomplish what you ask, you can use that little prototype tool and do: for %i in (*.atr) do perl atr.pl -dir %i It's not a turnkey solution of course, but you can adapt it to do what you want if you have a little programming knowledge. If you're more specific about what you want for the output, I can modify it to your requirements.
  14. Recently I've been reading old ACE Eugene newsletters, as Kay Savetz posted a whole slew of them to archive.org. When I read them, I take the opportunity to clean up the OCR of the issue as well so I can search it in the future. For program listings, the OCR's tend to be terrible, so I prefer to find the listing on a PD disk if I can, and insert that into the OCR listing instead. So I was reading the November 1983, issue, which has a copy of Stan Ockers "Cannibals and Missionaries". I searched for a copy on a disk and found one on the ABBUC disk 454 side B, which I believe I obtained from the Pooldisk Too. It's a saved BASIC copy, so I use the tools I've discussed previously in this blog to extract the file from the disk and parse the BASIC into a listing. Unfortunately, the parse failed, the image is corrupt, so it needs some attention. The first problem is the parser finds a line that has a zero length declared, so it loops on itself forever. Actually, it would have except that my parser sees the line numbers aren't increasing and aborts the parse at that point. The line with this error is the last line, 32768, or the immediate line [not quite, see addenda below]. I put in the correct length ($12 instead of $00) and my parser now outputs a listing. The listing however, doesn't look right. All the variables seem to be wrong, with FOR loops over string variables and other odd anomalies. So I examine the variable names and I can see the names go immediate wrong, with the first two variables names being "CHR$(27)" and "$". Looking at the listing, I know the first variable should be A$, so that I guess that the first value should instead be 'A' and then all the variables after that will shift down by one slot. This does indeed seem to fix the listing, and I now can run the program from the disk. So two byte changes and the listing is restored. There may be more "bit rot" on this disk, but here's the "fixed" version for anyone who wants it. Addenda I probably should have examined the rest of the disk, as two more BASIC files have similar changes (SMOKEY and MELTDOWN), suggesting this is a deliberate change to inhibit listing the programs. Another common trait shared by these three files is that the last line is actually a valid line number (32767), not 32768 as you'd typically see for a SAVE'd BASIC file. MELTDOWN is further protected by having the entire variable name table overwritten with $9B, rather than just the first value, so it can't be so easily restored. In addition, it has an extra 16 bytes of garbage data at the end. Anyhow, I've made similar small adjustments to the other two programs to make them more easily examinable for now. I'll have to investigate how common this type of listing protection is. 454_b.atr
  15. This disk is interesting, in that most of the files on the disk have different index number in the file links than the entry in the directory. The directory is in alphabetic order currently, so it looks like some tool went through and shuffled the directory order without adjusting the link data in the files. For instance, the README.1ST file should be the first file according to the file contents, but it is currently the 42nd entry in the directory. I've gone and changed the directory so that the file links match the directory entries which should be closer to the original disk from C&T. pd401.zip
  • Create New...