Image Map Image Map
Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15

Thread: ibm pc-dos assembler programming question

  1. #11
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    34,387
    Blog Entries
    18

    Default

    One thing that seems to have hit the bit bucket over the years are the automated source code conversion routines from x80 to 8086. There were several--and some vendors wrote their own in-house. One of the claims made by Intel (or at least their marketing people to OEMs) was that 8086 code occupied less space that 8080 code doing the same thing. I decided to call BS on that claim and submitted a 3000 or so line test program written for the ISIS-II assembler. I challenged the local Intel sales office to substantiate their two claims that (1) 8086 programs occupied less code space/memory than 8080 ones and (2) the automated conversion tools would produce a consistently usable result. So I was invited to the sales office for a test, so long as a brought my sample code with me. The ground rules were pretty loose; basically, no self-modifying code that had to produce an easily verifiable result when executed and no macros.

    So one morning, I showed up with my ISIS-II 8" SSSD disk with my test program. Since I was working on a floating-point BCD math project, I took that code, with a bit of wrapper that produced output. We verified that the native 8080 code ran on an MDS--and then we were off to the races. I think the migration program was called CONV80; but it's been a few years. At any rate, my code was fed into the conversion program with the "strict" conversion option enabled. The MDS churned on it for one hour, two hours....well, then it was lunchtime, so I was treated to lunch at a local watering hole (Coleman Still?) and we returned to the sales office--the MDS was still churning. 5:00 rolled around and I agreed to leave my code with the marketers who were to get back to me the next day.

    Next day was silent. About a week passed before I got a call saying that they finally got my code converted and it ran. The resulting object was almost three times the size of the original 8080 object. When I pointed out that this didn't augur well for the pile of 8080 code we'd already accumulated, there was some grudging agreement.

    We eventually ended up rewriting the bulk of the code in "C". Automated conversion was simply not the panacea that Intel promised. I know that Sorcim wrote their own converter, since they used their own assembler. Conversion of SuperCalc was, as I recall, a lot of work.

  2. #12
    Join Date
    May 2009
    Location
    Connecticut
    Posts
    4,730
    Blog Entries
    1

    Default

    The formal description of the CALL 5 interface can be found on page 1-28 of the Microsoft Programmers Reference Manual for MSDOS 2.0 under the heading CP/M(R)-Compatible Calling Sequence. Takes up about a third of a page.

    Strange that it got a printed description after it was obsoleted.

  3. #13

    Default

    Quote Originally Posted by Chuck(G) View Post
    One thing that seems to have hit the bit bucket over the years are the automated source code conversion routines from x80 to 8086. There were several--and some vendors wrote their own in-house.
    XLT86 from Digital Research is what I remember. They were trying very hard to get programs running on CP/M-86.

    http://en.wikibedia.ru/wiki/XLAT86

  4. #14
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    34,387
    Blog Entries
    18

    Default

    Intel had CONV86 It and others mentioned here

    (strangely, yours truly is mentioned in the footnotes )

    Was there ever an Intel utility to convert 8008 to 8080 source?

  5. #15

    Default

    Quote Originally Posted by VileR View Post
    You didn't specify which version of MASM you're using, but I don't think the versions that were any good actually run on DOS 1.10. The earlier ones are known for the rich biodiversity of their bugs.

    There are other assemblers that can directly output .COM executables, but again, I'm not sure whether any of them would run on DOS 1.x...
    Im using MASM version 1.0.

    So one way I discovered from Resman's wikipedia link is that, when the program is run as an EXE, DS holds the PSP segment, so its as "simple" as pushing DS to the stack, then pushing a 0 (word), then at the end of the program doing a far ret. That should jump to PSP:0. The first part of the PSP is an int 20. Looking at the PSP, I see a call instruction at PSP:5 that was mentioned earlier.

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
  •