Jump to content
  • entries
    42
  • comments
    8
  • views
    8,528

About this blog

Atari 8-bit Software under the Microscope

Entries in this blog

 

APX Deep Blue C, where's my 8080?

Continuing our exploration of Atari 8-bit languages and virtual machines, we come to APX20166 Deep Blue C.  Reverse engineering here is fairly simple as the entire source code for the runtime and compiler was published as an additional product, APX20179 Deep Blue Secrets.  I'm going to only use that as a reference and proceed to produce a listing of the runtime via disassembly for a few reasons.  First, it's always nice to have both the source code and the actual assembly output together.  Secon

Atari_Ace

Atari_Ace

 

Beneath Apple Manor

I was reading Dungeon Hacks, by David L. Craddock, the other day and found a short reference to the Atari 8-bit in the chapter on the first Rogue-like, Beneath Apple Manor: For Beneath Apple Manor Special Edition , I reverse engineered the 6502 runtime environment for the Galfo Integer BASIC compiler and ported it to 8086 machines (IBM PC). Bob Christiansen of Quality Software also ported it to the Atari. I did not write Ali Baba --Bob might have--but it was in integer BASIC too I think, s

Atari_Ace

Atari_Ace

 

APX Pascal Architecture, part four

The last blog entry introduced the tools I'm using to explore the Pascal runtime, and included a preliminary (i.e. rough) disassembly. Now we'll start refining that disassembly and start discussing more of the opcodes. Firstly, the last listing was erroneous around $B959 to $B991. There are strings there I somehow missed when spot checking the disassembly, so I've fixed up that part of the disassembly. There were also a couple of missing $9B's as well after strings, and the p-code disassemb

Atari_Ace

Atari_Ace

 

APX Pascal architecture, part three

In the last couple of posts we explored some of the APX Pascal architecture, showing bits of disassembly of the runtime, but I neglected to include the tools I used to extract those bits. This post aims to remedy that, and produce a first draft listing of the APX Pascal runtime. The runtime disassembly was done using similar perl code as I developed in the Dealer Demo Forth deconstruction blog posts last year, so refer to those if you want a discussion on how this disassembler works. There's

Atari_Ace

Atari_Ace

 

APX Pascal Architecture, part two

In the last post, we worked through layers of the APX Pascal runtime to find the main interpreter loop, which in fact resides entirely in page zero. In this post, we're going to dig into some of the opcodes to get a flavor for the runtime implementation. As we discussed last time, the each opcode is represented by a JMP value in a 512-byte table that is copied into $1D00 when the runtime starts. If you peruse though the table, the most common JMP target is $B9B5, in 81 entries. This is the

Atari_Ace

Atari_Ace

 

APX Pascal Architecture, part one

Bill Lange has been blogging about Atari Pascal since early February at https://insideataripascal.blogspot.com/, so here's my own small contribution after spending an afternoon poking around in APX Pascal and looking for the core interpreter. If we look at the PASCAL runtime on the APX Pascal disk, it's a simple enough image. It loads itself from disk to $3300-$59ff and then starts running from $3300. So what does that initial bootstrap code do? Here's the preamble: ​3300: A2 00

Atari_Ace

Atari_Ace

 

An Early Atari Computer Technical Demo

As originally conceived, Atari computers were going to be a platform where the technical secrets were held closely, allowing Atari to reap easy profits by providing software that third parties would be hard to match. At least, that was the theory. But the technical secrets were not going to remain secret forever, and as Atari was slow to provide the software to drive sales of the computers, it made more and more sense to abandon that strategy and open the platform to more developers. Atari ev

Atari_Ace

Atari_Ace

 

Dealer Demo, part 11: One Assembler to Rule them All

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 *+2154C: B4 00 LDY 0,X154E: 98

Atari_Ace

Atari_Ace

 

Dealer Demo, part 10: A complete kernel

OK, let's finish off the kernel of Dealer Demo. The next chunk is the COLD start routine, starting at $1C84, which is implemented as a primitive. Following that are a variety of standard Forth words dealing with mathematical operations and buffer and screen management. This leads up to TCIOV, a Dealer Demo primitive to invoke CIO routines. After the implementations of EMIT and KEY (labeled XEMIT and XKEY), we add a primitive BLKIO for invoking the disk handler, some SIO DCB constants (DCDNO

Atari_Ace

Atari_Ace

 

Dealer Demo, part 9: Strings are things

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 ($buff,

Atari_Ace

Atari_Ace

 

Dealer Demo, part 8: Who compiles the compiler?

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

Atari_Ace

Atari_Ace

 

Dealer Demo, part 7: Forward is the new Back

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 w

Atari_Ace

Atari_Ace

 

Dealer Demo, part 6: Less is More

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 Yes10BC 0< L619 ZLESS Yes10CE U< L1246 ULESS No10EB < 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, the motivat

Atari_Ace

Atari_Ace

 

Dealer Demo, part 5: More Forth for you

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 shor

Atari_Ace

Atari_Ace

 

Dealer Demo, part 4: Some Forth at last

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 NOP0D01: 4C 8D 1C JMP $1C8D0D04: EA NOP0D05: 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 start r

Atari_Ace

Atari_Ace

 

Dealer Demo, part 3: Dealing with symbols

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 $val < 10;

Atari_Ace

Atari_Ace

 

Dealer Demo part 2, Let's make a disassembler!

So to decompile the Dealer Demo, we need to start by peeking at the boot sectors to see how it starts. 000010: SECTOR: 001: FILE: 0 ff 01 80 04 c0 e4 a9 f4-d0 06 00 0d 01 00 80 00 ................ 10 85 f0 a9 52 8d 02 03 ad-8c 04 8d 0a 03 ad 8d 04 ...R.........… The first six bytes of the boot sector describes the boot sequence. The first byte is a flag byte (0xff) and the second byte is the number of sectors to load (DBSECT), in this case one. The third and fourth byte are whe

Atari_Ace

Atari_Ace

 

A Forth Bestiary, part 1, the Dealer Demo

I'm going to take a break from fixing disks images for now and instead talk about the language Forth. Forth grew out of the programming work by Charles Moore in the late 1960s. By the late 1970s interest in it was such that a group of enthusiasts banded together to program it for the microcomputers that were then becoming available. They formed the Forth Interest Group (or FIG) and placed several implementations of the language in the public domain. The implementation for the 6502 was done

Atari_Ace

Atari_Ace

 

Some S.C.A.T. disk fixes

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: Sector 17 empty (

Atari_Ace

Atari_Ace

 

The U.K. Atari Computer Owners Club Newsletter, or an issue with issuu

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

Atari_Ace

Atari_Ace

 

Page 6 Issue Disk 78B, What the 0x82?

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

Atari_Ace

Atari_Ace

 

Page 6 Issue Disk 55A, restoring the MENU

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. 642-67

Atari_Ace

Atari_Ace

 

DOS 1.0 files, they're out there

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 SYS01 42 014 043 INFOBITSBAS02 40 080 085 STING03 42 150 165 MALAGUEN04 42 092 315 FLIGHT05 42 069 416 ELEPHANT06 42 185 485 QUEST 32K07 42 031 670 TARGETS BAS08 42 017 701 ENEMY BAS09 42 010 057 INFOBITSTXT

Atari_Ace

Atari_Ace

 

ACEC Disk 016A, or one byte isn't as good as another

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 an

Atari_Ace

Atari_Ace

 

The ACE of Columbus D.O.M. archive, part 1

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

Atari_Ace

Atari_Ace

×
×
  • Create New...