Recently I've been reading the Tyne & Wear Atari User's Group Newsletters which I mostly got from atarimania.com. They are missing a couple of issues, so I was relieved to find another set of scans at at https://www.strotmann.de/~cas/Infothek/ to fill in the gaps. Yay!
Anyhow, there is a long series in that newsletter by Keith Mayhew called "Cracking the Code", which teaches assembly language. I'm always an advocate for more assembly tutorials, and this one apparently is a reprint from
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
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
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
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
The Suburban Chicago Atarians (S.C.A.T.) is represented on the Pooldisk with a couple hundred disks from their public domain library. As with much of the Pooldisk, there is some identifiable bitrot in a small number of the disks. In particular, checking the file integrity found four disks with simple single empty sector in the chain.
039.atr: Sector 217 empty (CREAPCAV.BAS). I found this game also on Thumpnugget's ANTIC disk archive, so we'll use that to fix it.
056.atr: Se
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
Another badly damaged Page 6 issue disk is 78B. I first noticed the VTOC and directory sectors had damage. A very peculiar damage, the 2nd byte of each sector was always 0x82. In fact, for the entire disk, the 2nd byte of every sector is 0x82. This disk is not in a happy place. Still, we can (mostly?) fix this. Fixing the VTOC sector and the directory is easy enough. Fixing the DOS and DUP files is easy, we can find the correct bytes on almost any other Page 6 issue disk. Fixing some o
The Page 6 Issue Disks are an excellent collection of Atari software you can find at http://page6.org. The integrity of the disks is generally good, but I've found some disks with issues. Issue Disk 55A in particular is badly damaged, but we can try to at least partly fix it.
Sectors 232-235 and 642-706 are marked in the VTOC as free (and are empty on the disk), but they shouldn't be, and this damages some of the files:
232-235: INTRO.DAT. Let's just fix the sector links for now.
The Internet Archive is a treasure for old computer enthusiasts. Archivists have been uploading old computer newsletters there for years which provide a vivid view of what it was like to be an Atari enthusiast when Atari was still a going concern. Thanks to the archive, I've been able to read such excellent old newsletters as the MACE Journal, SLCC Journal, Current Notes, and dozens of others.
The archive itself though has some quirky behaviors. When you upload content, it examine
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
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
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
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
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
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
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"
We continue with decompiling Dealer Demo at $175D, seeing -TRAILING, (.") (PDOTQ), and then a handful of words leading to the word ERROR which decompiles incorrectly.
Looking closely, we see that the .WORD PDOTQ precedes strings in the listing, which are represented as a count, followed by the string contents. The code to decompile such a string manually is easy to implement, since we built most of the infrastructure already to decompile Forth name fields, namely:
sub cstr_buf {
my
We pick up decompiling again at $148C, where we find 1+ (ONEP). It is followed by 2+ (TWOP), HERE, ALLOT, , (COMMA), C, (CCOMM), - (SUB), = (EQUAL), > (GREAT), ROT, SPACE and -DUP (DDUP). All of these are identical to the fig-Forth listing, which implements these as colon-definitions, which is expected. Although SUB, EQUAL and ROT are sometimes rewritten as primitives to speed up Forth (cf. val-Forth), optimizing these was not done in this Forth.
TRAVERSE is the next word in the listing
Thus far in disassembling the Dealer Demo, we've run across primitive definitions that have a PFA of .WORD *+2 and then some 6502 assembly code. There were two exceptions I didn't draw attention to at the time, the word 'I' and the word 'DROP'. DROP's PFA was simply ".WORD POP", in other words it took advantage of the fact the POP falls into NEXT, so the semantics of DROP could use that routine directly. I's PFA was similarly ".WORD R+2", in other words it had the same implementation as the word
We resume our disassembly of the Dealer Demo and find the next four Forth words, 0= and 0<, and then unexpectedly U< and <.
-def WORD NFA PFA same as fig-Forth?
10A7 0= L605 ZEQU Yes
10BC 0< L619 ZLESS Yes
10CE U< L1246 ULESS No
10EB < L1254 LESS No
I say unexpectedly, because U< and < in fig-Forth are defined much later, and U< is not a primitive, it is a combination of '-' (subtraction) and 0<. That said, t
In the last post I explained how the NEXT routine uses IP and W to JMP from word to word, but otherwise neglected to explain the Forth environment. Let's remedy that.
Forth contains two stacks, a data stack and a return stack.
The 6502 stack pointer indexes the return stack in page one. Saving and restoring the interpreter pointer is done here when Forth 'subroutines' are entered and exited, in a fashion analogous to JSR and RTS for the 6502. The routine SEMIS which we'll disassemble s
So we spent the last two posts working on tooling to reverse engineer the Dealer Demo, and got the bootloader disassembled for study. Now we can start disassembling the Forth kernel. Let's start with "-dis d00 8":
0D00: EA ORIG NOP
0D01: 4C 8D 1C JMP $1C8D
0D04: EA NOP
0D05: 4C A1 1C JMP $1CA1
Looking at the fig-Forth listing, this looks like the start of the kernel. 1C8D will be COLD+2, the cold start routine, and 1CA1 will be WARM, the warm
The last post walked through how to implement the basics of a disassembler, but we omitted several features to simplify the initial presentation. So let's fill in the omissions.
The main omission is the lack of a symbol table. I included a $names hash to hold the symbols and used it where needed, but there was no code to populate it. So let's fix that.
sub open_lst {
open my $fh, '<', 'dealerdemo.lst' or die;
$fh;
}
sub set_name {
my ($label, $val, $type) = @_;
return if $
We've now reached a compact bit of code in the Dealer Demo that provides an assembler to Forth. And the assembler in Forth is a thing of beauty indeed. Written by Bill Ragsdale (as was most of the Forth kernel), it provides an assembler that can produce surprisingly readable code without the use of labels. In essence it implements high-level assembler:
Recall TRAVERSE. In traditional assembler, it was written as:
154A: 4C 15 TRAV .WORD *+2
154C: B4 00 LDY 0,X
154E:
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord