In looking over the ACE of Columbus disks, I originally thought disk acec027b.atr had some problems, but it turned out, it simply had something I hadn't seen before, a DOS 1.0 file on a DOS 2.0 disk. You can see this by using the -dir command we wrote in the past.
00 42 039 004 DOS SYS
01 42 014 043 INFOBITSBAS
02 40 080 085 STING
03 42 150 165 MALAGUEN
04 42 092 315 FLIGHT
05 42 069 416 ELEPHANT
06 42 185 485 QUEST 32K
07 42 031 670 TARGETS BAS
08 42 017 701 ENEMY BAS
09 42 010 05
In my initial examination of the ACE of Columbus disk archive, I was able to fix acec068b.atr by borrowing a couple of sectors from acec016a.atr. This restored a Rubik's cube program, but if you compare the two files, they aren't the same.
As discussed in the past, BASIC files start with 14 bytes of pointers, then the variable names, then the variable values, then the lines of code. In this case, the variable values are different, which is fine, those all get cleared when the program runs a
Back in the 1980's, hundreds of Atari user groups formed throughout the United States. One of them, The Atari Computer Enthusiasts of Columbus, Ohio preserved the majority of their newsletters (which you can find on archive.org) and their "Disks of the Month" (342 images which you can find on the Pooldisk under the directory ACE). Just like the Bellcom archive I've been digging into, the preservation of some of the disks wasn't perfect. So let's spot a few corrupted images and see what we can do
Bellcom disk D068_A is the first disk in the Bellcom archive I've examined where the damage is substantial. This is the first disk of a four disk graphical adventure from Germany, "The Nephew". The Bellcom catalog exclaims: "I had this unique game translated into English because I knew you’d want it." All the sectors from 952 up are empty, except for 1024 (where the DOS 2.5 is partially stored), but the directory shows that at least two files (ROLLE, HINTS.BAS) should have data there. So let's s
At this point I've fixed a lot of Bellcom disks, and now find the remaining ones are going to have to wait until I find another source of the damaged content, or some manual work on my part.
Disk 397 is a good example of the latter. It is missing sector 228, which is the first sector of AUTORUN.BAS, which turns out to be the Autocrostics program, which is also archived on the Pooldisk as UMICH\CIS\CROSTI.ATR, sector 214. So using the tools developed so far, we copy over the sector and fix t
Today's blog entry is going to be a bit dull, since it's just all the easy to fix Bellcom disks. No new Perl code is needed, these can all be fixed with the techniques described in past entries. In fact all of them involve just patching a single sector from another disk. The hardest part was finding the disks with equivalent content, but I've written before on how binary grep for content.
Disk 670: Sector 113 empty, damaging WRITER.OBJ (Antic Writer). Patch sector from ANTIC\87_JUL.ATR, se
After the epic efforts to restore GIRL6 in the last two posts, I thought I'd tackle the remaining damaged pictures in the Bellcom archive. We start with disk 450, which has the title screen from Zaxxon ripped from the game, but unfortunately the first sector of the MicroPainter picture is gone. No problem, we can rip the 125 bytes from the game again.
I found similar byte patterns in the disk "Zaxxon (19xx)(Datasoft).atr" in my collection, so I just need to adapt the copy sector tools to pu
In the last post we partially restored the first sector of Girl6.pic by splicing in some data into the RLE stream to represent 160 zero bytes. But we have a slightly different version of the picture, so in principle we can completely restore the picture from that and some ingenuity.
First, let's expand out the first column of GIRLJ.PIC (our more complete picture) and see what it looks like.
0 00 00 00 00 aa aa aa aa-aa 9a 7a ae a9 a9 a6 a9 ..........z.....
10 a5 a9 aa aa
Poking around the Bellcom archive, we come across disk 481.atr, which contains a number of pictures. GIRL6.PIC is damaged, the first sector is all zeros, so let's see how far we can get in fixing it today.
Usually, we find an undamaged version of the file and patch in the missing sector, but in this case, that plan goes immediately awry. Looking through the file I pick out the sequence UPDQTP to search for, and find a match in the PoolDisk archive D:\SEX\DIGIGIRL.ATR, file GIRLJ.PIC startin
In earlier posts I explained how data is organized on a DOS 2.0/2.5 disk, but didn't provide any code specific to the directories and files (other than link_data). This post remedies that, in part to fill in those gaps, and in part because I'm going to fix some disks that require a bit more effort than just copying a sector or two from another disk.
Let's start with a helper function
sub toascii {
my ($val) = @_;
$val =~ tr/\x00-\x1f\x60\x7b\x7d\x7e\x80-\x9a\x9c-\x9f\xff/./;
$va
Now, that we have a tool to patch sectors and fix links we can incrementally improve the archive, usually by copying a single sector from a donor disk to the damaged disk. After fixing about a dozen disks I started looking at disk 349, in which the file DISCOM32.COM was shorter than the number of sectors in the directory. What was going on? According to the directory the file started at sector 13 and was 105 sectors long. The next file started at sector 118, so you'd expect this file would
In my last post I fixed a couple of Bellcom disks by copying missing sectors from another disk, and then "fix[ing] the sector links". This post is going to discuss that, and modify our copy tool to do it automatically.
As explained earlier, the last three bytes of a DOS 2.0/2.5 file contains file metadata, specifically the file index, the next sector, and the number of bytes. When a sector is dropped and you find a replacement on another disk, two of these three values are unlikely to be wh
This post is about the Bellcom disks, a large collection of largely public domain software sold out of Canada by Don Bell back in the late 1980s and early 1990s. I became interested in this collection when I downloaded the ABBUC "Atari Pooldisk Two" (it's on archive.org, e.g. https://archive.org/details/cdrom_PoolDisk_Too_disc2, although I believe that's actually disk 1). It was the largest set of disks on that CD (967 images), and contained quite an assortment of software for the Atari. It was
I started this blog by fixing up a relatively obscure Atari title (The ABC of CPR). I could fix it because there were several different archives containing purportedly the same data, and since the most common problem with old disks is a bad sector which translates to an empty/dropped sector in an ATR archive, we could see the blank sectors and conclude fixes were needed. So how do we find some (ideally all) disks with dropped sectors in a large archive. Well, it falls out of trying to build
So we've managed to write a simple tool that can dump and patch sectors for standard 90K disks. What about dual and double density disks?
A little bit of history first. The Atari computers first disk drive, the 810, was capable of supporting 18 128-byte sectors per track, leading to 720 sectors on a 40 track disk, or 90K. To get more data onto a disk, you can change the sector size, the number of sectors per track, or the number of tracks. When the 815 drive was designed, it changed the sec
In the last blog entry, I presented a little bit of Perl code to hex dump disk contents, and promised to extend that to allow disk patching. So here we go.
sub write_file {
my ($file, $buff) = @_;
open my $fhw, '>', $file or return;
binmode $fhw;
print $fhw $buff;
close $fhw;
}
The first routine we'll need is something to write a file. Here's a completely generic routine that will write a buffer to a file. So our strategy will be read_file, change the buffer, and then inv
In my blog entry on the ABC of CPR, I found issues with all the (known to me) images of the disks by cross comparing the contents of the disk images. In this entry, I walk through how to generate such dumps using a utility in the Perl language.
Perl has fallen in popularity over the years, which is a bit sad, as it still has a lot to recommend it. It still probably has the best text handling facilities of any language, can handle binary data with ease, and has an simple object model that I'
In this blog I hope to spend time dissecting and rebuilding various software artifacts for the 8-bit Atari. My first entry is The ABC of CPR, an Edunetics title you can find at http://www.atarimania.com/game-atari-400-800-xl-xe-abc-of-cpr-_12807.html. I decided to look at this because I found the same/similar disks in the DGS and Page 6 public domain disk archives, and I was curious if there were any differences. All the images differ from each other in various ways (seen by hex dumping the d
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord