• Please review our updated Terms and Rules here

„Below the root” hangs on IBM portable 5155

Wow. This pc booter from this link, which I have posted before, does not work for me, so I understand that you have any other?

I grabbed the booter image from that Retrograde site.

There's one way that my 5155 has been modified from stock: it has an AMD P8088-1 installed. (The original CPU has been lost in the sands of time long before I acquired the machine.) Unlikely to make a difference, but I suppose we're at the point where that should be mentioned.
 
For me, both files and 3 different programs for diskette images give the same effect. (or rather the lack of it). Weird.

 
For me, both files and 3 different programs for diskette images give the same effect. (or rather the lack of it). Weird.

Do you have any other XT keyboards that you could test with?

I also found that I could get the DOS version of the game to stay at the (K)eyboard/(J)oystick screen if I simply unplugged the 5155 keyboard shortly after typing LOADER.COM and pressing ENTER.
 
I came back to the topic after a long time.

I managed to sell 5155 and after some time I bought two more following the spirit of nostalgia.
Imagine my surprise when both of my ibm portables started BTR without any problem.
I was happy and did not pursue the topic.

I was even more surprised when after some time it turned out that the game freezes again.
This bothered me so I loaded (loader.com) the DOS version of BTR into debug and traced what the program was doing.

First, it loads 3 files into memory, sets int63h (i/o calls redirect?) and transfers control to belowroot.exe.
And that's where EVIL happens.
The program calls int 11h ( bios config ) and TESTs the presence of game port. If it finds it, it skips several instructions that clear several bytes in memory.

In my case, the bit indicating the presence of the game port was ON although the game port was not physically present.

Of course, I thought about what I had changed in the configuration since the game was working. Well - I took out the game port card. (I don't have a joystick yet)

So I put the game port into the computer. And here I was surprised for the third time. It turned out that the bios says that there is no game port (zeroed bit).

I fired up the btr and it worked. Conclusion (wrong as it later turned out) - This bit works inversely ( 0 - game port present. )

After exiting the game surprise #4: The bit is on again.
I launched the game - it works.
At this point, I was numb!

Conclusion 1 : If there is NO game port on your computer and for some reason the game port bit is ON then the game crashes.
Conclusion 2 : If there IS a game port on your computer, it doesn't matter if the bit is on or off. Game works ( with keyboard )

I thought I'd check.
The jump instruction in the absence of a game port BYPASS a piece of code. So it is enough to replace two 751B bytes (1B jump) into two NOPs. - the game starts (with the keyboard) and seems to work without a problem.

Quick solution:
1. open 'btroot.exe' in hex editor.
2. search for '751B' ( first occurrence ! )
3. replace with '9090'
4. save the file.

The solution is dirty and I still don't know why Bios once claims that there is a game port and the second time that it does not exist, although the fact is that it does not exist.

Maybe someone can educate me on this topic.

I think it might have something to do with the keyboard. If there is no gameport and the game hangs then
after a soft reset, the keyboard "goes crazy" (the screen prints several characters after one press)
 
Last edited:
I wrote a simple patch for 5155 if you wish.
Put it in the directory with btroot.exe and run it.

Code:
    .model    tiny
    .code 
    org 100h
start:    jmp    begin

fname    db    'btroot.exe', 0
newval    db    90h,90h
handle    dw    ?
errcode    db    ?
errmsg    db    'error 0x','$'
sucmsg    db    'File sucessfully patched!','$'

begin:    mov    ax,3D02h        ; open file
    lea    dx,fname
    int    21h
    jc    errors
    mov    handle,ax

    mov    ax,4200h        ; move pointer
    mov    bx,handle
    mov    cx,0h
    mov    dx,20DAh
    int    21h
    jc    errors 

    mov    ah, 40h
    mov    bx,handle
    mov    cx,02h
    lea    dx,newval 
    int    21h
    jc    errors

    mov    ah,3Eh            ; close file
    mov    bx,handle
    int    21h
    jc    errors
      
    mov    ah,09h
    lea    dx,sucmsg
    int    21h

fine:    ret                ; 0 to IP from stack ( int 20 )

print_byte_hex    proc    near
    push    cx
    push    dx
    mov    dh,dl            ; copy byte 
    mov    cx,4
    shr    dl,cl            ; first digit
    call    print_digit
    xchg    dl,dh
    and    dl,0Fh            ; second one
    call    print_digit
    pop    dx
    pop    cx
    ret
print_byte_hex    endp
print_digit    proc    near
    cmp    dl,0Ah
    jae    letter
    or    dl,30h
    jmp    print 
letter:    add    dl,'A' - 0Ah
print:    mov    ah,02h
    int    21h
    ret
print_digit    endp

errors:    mov    errcode,al
    mov    ah,09h
    lea    dx,errmsg
    int    21h
    mov    dl,errcode
    call    print_byte_hex 
    jmp    fine

    end    start
 

Attachments

  • 55patch.zip
    1.8 KB · Views: 2
Last edited:
The program calls int 11h ( bios config ) and TESTs the presence of game port. If it finds it, it skips several instructions that clear several bytes in memory.

In my case, the bit indicating the presence of the game port was ON although the game port was not physically present.
That would be bit 12 in the BIOS equipment flag.
After some research (see [here]), I came to the conclusion that bit 12 should not be relied on.
 
I came to the conclusion that bit 12 should not be relied on.
Yeah. It makes sense. Some sources (e.g. this) describe bits 12 and 13 as 'reserved' without any reference to game port or modem.
Looks like the 'mystery' has been solved. :)
 
Back
Top