News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

ML problems with BIOS code

Started by nicu, March 21, 2012, 09:05:39 PM

Previous topic - Next topic

nicu

I found a bug in MASM32 latest version11, trying to assemble the PC XT BIOS (80186 code).
There is a macro used for code positioning (something like ORG, but it fills with a custom value the gap between the last assembled code and the new code position):


ENTRY   macro   x
        pad     =BANNER - $ + x - 0E000h
        if pad LT 0
        .err
        %out    'No room for ENTRY point'
        endif
        if pad GT 0
        db      pad DUP(0FFh)
        endif
endm


and an example of usage:

code    SEGMENT
        ORG     0E000h

BANNER  db      '  Generic Turbo XT Bios 1987',CR,LF
        db      '      for 8088 or V20 cpu',CR,LF
        db      '         (c)Anonymous',CR,LF
        db      LF,0

LPTRS   dw      03BCh,0378h,0278h               ; Possible line printer ports

        ENTRY   0E05Bh                          ; IBM restart entry point

COLD:   MOV     AX,40h                          ; Entered by POWER_ON/RESET




It is called in many places inside this code segment, and beginning with the second usage, the "pad" value computed inside the macro (wrongly) becomes negative, determining it to throw the error message. It seems there is something wrong with the $ value used in this macro. I can provide the entire .asm file if needed.



dedndave

haven't seen that for a while   :P
i think i have a bios somewhere named turbo xt

but, i don't think this is a masm32 package bug
rather, it is a ms masm bug with the $ operator

nicu

You right, it is ml.exe which is called to assemble the code.

dedndave

there was a related thread about a month or two ago
i cannot find it because i can't think of a good search term
searching for "$" doesn't help much - lol

clive

You might also want to consider if the source expects MASM 5.x, in which case running MASM 6.xx with the -Zm option might be the way to go.

Either way you might do better using a contemporaneous assembler. ie MASM 3.0 or 4.0
It could be a random act of randomness. Those happen a lot as well.