Jump to content
  • entries
    45
  • comments
    10
  • views
    10,353

APX Pascal architecture, part three


Atari_Ace

554 views

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 a few differences worth discussing though.

  • I've split the code into pieces, m6502.pm being generic support for disassembly, pascal.pm being Pascal p-code decompilation and pascal.pl handling working with the PASCAL runtime object from Side 1 of the APX Pascal disk. If you use a perl 5.26 or later you may need to set PERL_USE_UNSAFE_INC=1 in your environment, or add the path with the code to your perl INC path.
  • read_img has been implemented using read_img_core which takes a description of an image. The Dealer Demo version was just a one-off custom piece of code. For apxpascal.pl, the definition is:
  read_img_core(
    $addr, $size, '../pascal.xex',
    [0x06 - 0x3300, 0x3300, 0x59ff],
    [0x06 + 0x3a00 - 0x3300 - 0xa000, 0xa000, 0xbfff]);

which means if you ask for an address between 0x3300 and 0x59ff, start at offset 0x6 of the runtime file. If you ask for an address between 0xa000 and 0xbfff, start at offset 0x706 of the runtime file.

  • The core of the subroutines bytes and words have been factored into bytes_buf and words_buf to allow the code to be used in more cases.
  • Some new options have been added to the core: -str for displaying a string with a known size, -scr for displaying a CR-delimited string.
  • The option -mads, for translating a listing into a MADS compatible source file, is much more sophisticated now. It does some validation of the listing, and converts the listing bytes into a 'check.obx' file. The code is largely the same as the code I've used before when validating OCR's of source code listings (e.g. Atari PILOT or Star Raiders).


The code from $A000 to $BFFF is the runtime and is pure assembly code. I produced it by initially disassembling all the code in that region, and then stitching in corrections where data appeared in the stream (usually by noticing a BRK or .BYTE slip in to the disassembly). The version 0.0 documentation (https://archive.org/details/AtariPascalV0.0Documentation) was then used to help pick some label names for common memory locations. I decided to use IP for the pseudo-PC. The commonly location $CC I suspected matched the TMPBASE label from the documentation. $CA was more-or-less exclusively used for saving and restoring the X-register, so XSAVE seemed a natural label (echoes of the Forth VM there). Finally I concluded DR0 must be $B6 (one of 8 16-bit display registers) and LCLBASE (local base register) $C6. $0600 is clearly used as an evaluation stack, so I used EVALPAGE from the 0.0 documentation. I haven't conclusively identified PRGSP, EVALSP, and LEXLEVEL, nor the many temporaries, and the previous labels could prove erroneous, but this is enough for now to produce a more readable listing.

The code from $3300 to $39FF is a combination of assembly code and p-code. Whenever a JSR $1F06 appears, some number of JMPs before it appear, followed by what appears to be a length and then a sequence of p-code. A single appearance of JSR $1F03 appears to be followed by an address and then a sequence of p-code. So I decompile decode starting 2 bytes after a JSR $1F03 (until seeing opcode $D9) or $1F06 (until seeing opcode $A6). This description is almost certainly incorrect in some fashion, but seems adequate for now to start decompiling the image.

You can find the pascal p-code decompiler in pascal.pm. The decompiler is very simple, it contains a list of p-code instruction lengths. Those that are non-zero are decompiled, the rest are assumed to be errors (not all the values are yet filled in). Negative lengths dump the additional data as words instead of bytes, and opcode $2C is handled as a special case. $2C is clearly a code for a string if you look at examples in the file (e.g. address $3421 contains 0x2c,5,'D:MON'), so clearly a fixed length decompiler isn't going to work for that case.

Using this we obtain snippets of p-code like so:

3410: 4C 13 34          JMP *+3
3413: 20 03 1F          JSR $1F03
3416: 3A 34             .WORD $343A
3418: A2                .BYTE $A2
3419: 21 35             .WORD $3521
341B: FD 09             .BYTE $FD,$09
341D: 25                .BYTE $25
341E: 3A 34             .WORD $343A
3420: F1                .BYTE $F1
3421: 2C                .BYTE $2C
3422: 05 44 3A          .BYTE 5,'D:MON'
3425: 4D 4F 4E
3428: A2                .BYTE $A2
3429: E0 36             .WORD $36E0
342B: 25                .BYTE $25
342C: 3A 34             .WORD $343A
342E: F1                .BYTE $F1
342F: A2                .BYTE $A2
3430: 7D 35             .WORD $357D
3432: 25                .BYTE $25
3433: 3A 34             .WORD $343A
3435: F1                .BYTE $F1
3436: A2                .BYTE $A2
3437: 64 35             .WORD $3564
3439: D9                .BYTE $D9

and so:

36DD: 4C 00 00          JMP $0000
36E0: 4C E3 36          JMP *+3
36E3: 20 06 1F          JSR $1F06
36E6: 56 00             .WORD $56
36E8: A8 00             .BYTE $A8,$00
36EA: D2                .BYTE $D2
36EB: BC 51             .BYTE $BC,$51
36ED: 09 52             .BYTE $09,$52
36EF: 09 54             .BYTE $09,$54
36F1: 01 54             .BYTE $01,$54
36F3: A8 00             .BYTE $A8,$00
36F5: BC 10             .BYTE $BC,$10
36F7: A6                .BYTE $A6

We need to assign identifiers to those opcodes (first bytes) to make this more readable, but we can do that later as we better identify the opcodes.

The current decompilation and the tools are attached to this post. In my next post we'll continue examining the opcodes and improving the listing.

pascal1.zip

0 Comments


Recommended Comments

There are no comments to display.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...