Image Map Image Map
Results 1 to 8 of 8

Thread: Disassembling

  1. #1
    Join Date
    Apr 2015
    Location
    Morisset, NSW Australia
    Posts
    217

    Default Disassembling

    My ultimate goal here is to restore an old AH game where the image on the 500-baud tape (from a still shrink-wrapped box) is bad. How bad? All the upward pulses are weak and some up/down pairs are completely below the 0 voltage. It's not too bad; only one block gives a checksum error (though I could be "lucky" and errors in other blocks are cancelling out to return the right checksum value . . . ) , but the result is a non-useable game. Along the way it's a way to better understand Z80 machine code, various file formats, etc. The full sequence should be:

    1. Record audio from tape
    2. Convert audio to .CAS file
    3. Convert .CAS into form suitable for disassembler
    4. Disassemble
    5. Read through disassembled code and work out program logic
    6. Psychiatric treatment
    7. Locate corrupted logic, correct
    8. Generated fixed .CAS, .CMD, ...
    9. Play


    The point for this thread is 4 - "Disassemble". I wrote my own utility to parse a CAS file and convert it to a straight binary image. I guess I could have used trld, but I didn't for the following reasons:
    • Extra learning for myself
    • I'm sorta over compiled languages for this type of work, Python is easier to use cross-platform
    • I only spotted trld after the fact.


    At this stage I'm using a known "good" CAS file - PYRMD - to concentrate on the disassembly. A quick manual comparison of the CAS contents and the binary image looks good. So then, I run it through a disassembler. And . . . bother. The basic disassembling appears to work. This is true for z80dasm and yazd. However neither picks up data. I would expect/hope/want sections like "I SEE NO . HERE..YOU AREN'T CARRYING IT" to end up as DEFM statements. Which they aren't. AFAIK no format from that era has anything like different sections for program/data. So am I being wildly optimistic about what a disassembler is going to be able to achieve on binary images? It's one thing to spot text blocks in a binary editor, it's another to spot long blocks of data (which the program I'm ultimately working has in spades). Anyone want to suggest a better disassembler?

    All help appreciated.

    PJH

  2. #2

    Default

    PJH,
    I've got a copy of PYRMD.CAS and PYRMD1.CAS in case you are needing them.
    Perhaps they will save you some time. I just don't know if they are valid.

    Larry

    PYRYMD.zip

  3. #3
    Join Date
    Apr 2015
    Location
    Morisset, NSW Australia
    Posts
    217

    Default

    Quote Originally Posted by ldkraemer View Post
    PJH,
    I've got a copy of PYRMD.CAS and PYRMD1.CAS in case you are needing them.
    Perhaps they will save you some time. I just don't know if they are valid.

    Larry
    Thanks Larry but I've already got them. And given they load and run (either in XTRS or "played" into a real machine) I'm counting them as good. That's why I started with them - the "get from CAS to disassembled code" is going to be fun enough first time without having to worry as to whether the starting image is bad.

    PJH

  4. #4
    Join Date
    Apr 2015
    Location
    Morisset, NSW Australia
    Posts
    217

    Default

    Quote Originally Posted by pjhacnau View Post
    The full sequence should be:

    1. Record audio from tape
    2. Convert audio to .CAS file
    3. Convert .CAS into form suitable for disassembler
    4. Disassemble
    5. Read through disassembled code and work out program logic
    6. Psychiatric treatment
    7. Locate corrupted logic, correct
    8. Generated fixed .CAS, .CMD, ...
    9. Play
    Note I do have a fall-back option. I have yet to check fully but I'm hoping that there is only one block which has a checksum error in it - so the fallback would be trying to locate the error in 256 bytes of disassembly rather than going the whole-of-program approach. But the masochist in me would really like to understand the whole program.

    PJH

  5. #5
    Join Date
    Apr 2015
    Location
    Morisset, NSW Australia
    Posts
    217

    Default

    Quote Originally Posted by pjhacnau View Post
    Note I do have a fall-back option. I have yet to check fully but I'm hoping that there is only one block which has a checksum error in it - so the fallback would be trying to locate the error in 256 bytes of disassembly rather than going the whole-of-program approach.
    OK so now I have checked and it's 3 blocks of 91 have a bad checksum. And I'd still prefer to discover how (if it's possible) to do a good disassembly.

    PJH

  6. #6
    Join Date
    Jul 2009
    Location
    Curwensville, PA
    Posts
    480

    Default

    Have you tried using a hex editor to isolate the data blocks?

    Kipp
    Looking for: Altair 8800, Ithaca Intersystems boards, software, manuals. and Jade bus probe card.

  7. #7

    Default

    Quote Originally Posted by pjhacnau View Post
    At this stage I'm using a known "good" CAS file - PYRMD - to concentrate on the disassembly. A quick manual comparison of the CAS contents and the binary image looks good. So then, I run it through a disassembler. And . . . bother. The basic disassembling appears to work. This is true for z80dasm and yazd. However neither picks up data. I would expect/hope/want sections like "I SEE NO . HERE..YOU AREN'T CARRYING IT" to end up as DEFM statements. Which they aren't. AFAIK no format from that era has anything like different sections for program/data. So am I being wildly optimistic about what a disassembler is going to be able to achieve on binary images? It's one thing to spot text blocks in a binary editor, it's another to spot long blocks of data (which the program I'm ultimately working has in spades). Anyone want to suggest a better disassembler?
    Don't expect to see many raw strings in Robert Arnstein games (Pyramid 2000, Raaka-Tu, some others). Most of it is packed, for space reasons. However, if I recall correctly, at least in Pyramid, the command verbs are in plaintext (except for the last character which has its high bit set, the same trick used by Microsoft BASIC to mark the ends of the tokens).

    See http://computerarcheology.com/CoCo/Pyramid/ for more.

  8. #8
    Join Date
    Apr 2015
    Location
    Morisset, NSW Australia
    Posts
    217

    Default

    Quote Originally Posted by Satyr Icon View Post
    Don't expect to see many raw strings in Robert Arnstein games (Pyramid 2000, Raaka-Tu, some others). Most of it is packed, for space reasons. However, if I recall correctly, at least in Pyramid, the command verbs are in plaintext (except for the last character which has its high bit set, the same trick used by Microsoft BASIC to mark the ends of the tokens).

    See http://computerarcheology.com/CoCo/Pyramid/ for more.
    Thanks for that - a quick check showed up the Z80 disassembly in there as well - which means I have an "answer sheet" to compare what I work out (before moving on to the main project where - AFAIK - no such thing exists).

    Meanwhile further reading/thinking got me to the conclusion I'm asking far too much of a straight disassembler; I'm now working with Radare 2 which is a reverse engineering tool. While there's still a lot of manual analysis to do the auto-analysis it does gets you a lot further down the path.

    PJH

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •