Author Topic: Example code for NASM on MS-DOS on an IBM ThinkPad  (Read 16958 times)

Offline MosaicDawn

  • Jr. Member
  • *
  • Posts: 6
Example code for NASM on MS-DOS on an IBM ThinkPad
« on: February 25, 2011, 07:40:10 PM »
I've done some tiny bit of asm for windows in MASM but other than that I'm a complete beginner to this and I couldn't find any or at least any working example programs for it. Thins like input, output, maybe pixel colors.
Is there any on here?
(also I hope I'm not posting in the wrong board)

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: Example code for NASM on MS-DOS on an IBM ThinkPad
« Reply #1 on: February 25, 2011, 09:58:34 PM »
No clue. Googling for "IBM ThinkPad assembly" gets me instructions to put the thing together, not "assembly as we know it".

As a naive first ASSumption, I suppose if it's running dos, we program it like dos...

Code: [Select]
; nasm -f bin -o myfile.com myfile.asm

org 100h

mov dx, msg
mov ah, 9
int 21h

ret

msg db "Hello ThinkPad!$"

I have no idea whether that'll work or not. Dos doesn't know much about pixel colors, for that we'd normally use bios interrupts. Does this thing have a "pc-like bios"? We may be able to write "direct to screen", too - 0B800:0000 for text mode, 0A000:0000 for graphics modes... IF this thing is sufficiently pc-like...

My problem is that I don't know what a ThinkPad "is". Google is being unusually unhelpful. Maybe I'm not asking the right questions. I may be able to get back to ya with more information... or maybe you can help me get "oriented"...

If a ThinkPad runs an x86-family CPU (which seems to be the case), we ought to be able to help you program it, although you might get more information from a "ThinkPad board", if any... Stay tuned! :)

Best,
Frank


Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: Example code for NASM on MS-DOS on an IBM ThinkPad
« Reply #2 on: February 25, 2011, 11:01:47 PM »
Apparently the "800 series" uses POWERPC architecture. Nasm won't work on that. Probably won't run dos, either, so it probably isn't what you've got. Other than that, it seems like a normal notebook, except it looks like a "traditional Japanese lunchbox". What a feature! Should program pretty "normally". Let us know how it works out!

Best,
Frank


Offline MosaicDawn

  • Jr. Member
  • *
  • Posts: 6
Re: Example code for NASM on MS-DOS on an IBM ThinkPad
« Reply #3 on: February 26, 2011, 01:52:09 AM »
No clue. Googling for "IBM ThinkPad assembly" gets me instructions to put the thing together, not "assembly as we know it".

As a naive first ASSumption, I suppose if it's running dos, we program it like dos...

Code: [Select]
; nasm -f bin -o myfile.com myfile.asm

org 100h

mov dx, msg
mov ah, 9
int 21h

ret

msg db "Hello ThinkPad!$"

I have no idea whether that'll work or not. Dos doesn't know much about pixel colors, for that we'd normally use bios interrupts. Does this thing have a "pc-like bios"? We may be able to write "direct to screen", too - 0B800:0000 for text mode, 0A000:0000 for graphics modes... IF this thing is sufficiently pc-like...

My problem is that I don't know what a ThinkPad "is". Google is being unusually unhelpful. Maybe I'm not asking the right questions. I may be able to get back to ya with more information... or maybe you can help me get "oriented"...

If a ThinkPad runs an x86-family CPU (which seems to be the case), we ought to be able to help you program it, although you might get more information from a "ThinkPad board", if any... Stay tuned! :)

Best,
Frank



That worked like a charm!
The only thing I found that worked previously was some 10h thing that let me print one char so I tried to do some macro thing with a loop...

And I dunno the specifics, I just made C:\ an MS-DOS boot disk and dumped DOS on it without installing it. Everything seems to work fine.
It had Windows 2000 installed on it previously.
« Last Edit: February 26, 2011, 02:29:20 AM by MosaicDawn »

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: Example code for NASM on MS-DOS on an IBM ThinkPad
« Reply #4 on: February 26, 2011, 03:53:08 AM »
Ah. Upgraded it to dos, eh? :)

That int 10h is the video bios interrupt - can use it to set video modes, text colors, cursor position, etc. int 16h is the bios keyboard interrupt... See Ralf Brown's Interrupt List for all the gory details of these and others...

Code: [Select]
org 100h

section .data
               ; message in char,attrib,char,attrib... format
    msg1 db 'M',01h,'a',02h,'n',03h,'y',04h,' ',05h,'T',06h
         db 'h',07h,'a',08h,'n',09h,'k',0Ah,'s',0Bh,' ',0Ch
         db 't',0Dh,'o',0Eh,' ',0Fh,'R',01h,'a',02h,'l',03h
         db 'f',04h,' ',05h,'B',06h,'r',07h,'o',08h,'w',09h
         db 'n',0Ah,'!',0Bh      ; no need to terminate...
    msg1len dw $-msg1            ; let the assembler count 'em!

section .text

    mov ax, 3         ; reset video mode to 3 (cheesy CLS)
    int 10h           ; call bios video services
domore:
    mov bp, msg1      ; point to string
    mov cx, [msg1len] ; length of string - chars + attributes
    shr cx, 1         ; div by two to get char-only len for the call
    mov dh, 0Bh       ; row
    mov dl, 01Ah      ; column
    mov bh, 0         ; video page "usually" (?) zero
                      ; don't care what BL is for this AL
    mov ah, 13h       ; write string in ES:BP at DH,DL (row,column)
    mov al, 2         ; char, attr,... format - no cursor update
                      ; 3 - char,attrib - update  cursor
                      ; 1 - attrib in BL - update cursor
                      ; 0 - attrib in BL - no update
    int 10h           ; call video services (AT+,EGA+ ???)
                      ; rather than alter the pallette, we just
    mov bx, msg1      ; change the colors in the string, and
    mov cx, [msg1len] ; reprint it (no cursor update :) ! )
    shr cx, 1         ; number of colors
morecolors:
    inc bx            ; skip over character
    mov al,[bx]       ; get current color
    inc al            ; bump it
    cmp al, 10h       ; we only change low nibble - high nibble
    jnz colorok       ; is background (bit 7 set - FG blinks)
    mov al, 1         ; we don't want color zero (black), or we
colorok:              ; could just "or al,0Fh"
    mov [bx], al      ; stuff it back in the string
    inc bx            ; point to next character
    loop morecolors   ; do 'em all
    mov cx, 2         ; BIOS is "slow", but we still
    call DELAYCX      ; need some delay
    mov ah, 1         ; check keyboard status
    int 16h
    jz domore         ; no key hit - do it again
    mov ah, 0         ; get the key off the buffer
    int 16h
                      ; could clearscreen again here, but
exit:                 ; naw, let's leave it...
    mov ah, 4Ch       ; scram
    int 21h

;----------------------------------------------------------
; twiddle thumbs for cx/18.2 seconds
DELAYCX
        push ax
        push bx
        push ds
        mov bx, 40h        ; BIOS data segment
        mov ds, bx
        mov bx, 6Ch        ; BIOS timer, 40:6C
        mov ax, [bx]
        add ax, cx
DelayLoop:
        cmp ax, [bx]        ; Is it the same?
        jnc DelayLoop       ; No, try again.
        pop ds              ; Restore registers and exit.
        pop bx
        pop ax
        ret
;------------------------------------------------------------------

What do you want to make it do?

Best,
Frank


Offline MosaicDawn

  • Jr. Member
  • *
  • Posts: 6
Re: Example code for NASM on MS-DOS on an IBM ThinkPad
« Reply #5 on: February 26, 2011, 09:35:15 AM »
Yes, performance increased drastically.
Oh, that figures why I somehow set the screen either larger or more to the top left corner when I changed something when messing with 10h

And those colors are beautiful ; ~ ;

And I think I want to make it do pretty much that - pretty color things.
And also some hardware stuff, like detecting multiple keys at once, because none of C's getch() functions are capable of doing that.
And also some regular input would be nice.

« Last Edit: February 26, 2011, 09:38:05 AM by MosaicDawn »

Offline MosaicDawn

  • Jr. Member
  • *
  • Posts: 6
Re: Example code for NASM on MS-DOS on an IBM ThinkPad
« Reply #6 on: February 27, 2011, 02:54:23 PM »
Oh and, uh, I have this problem. It's not really a problem, but still.

The computer doesn't use all of the screen, instead it uses just part of it.
Is there a way to make it use all of the screen with the resolution still being 320x200?

The picture is of what I mean


Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: Example code for NASM on MS-DOS on an IBM ThinkPad
« Reply #7 on: March 06, 2011, 12:39:28 PM »
Hi MosaicDawn,

Sorry for the delay. I don't have a good answer to your question. Sounds like a "Windows problem" to me, but you say...

Quote
And I dunno the specifics, I just made C:\ an MS-DOS boot disk and dumped DOS on it without installing it. Everything seems to work fine.
It had Windows 2000 installed on it previously.

I'm not clear exactly what you did. Simply copying the files over probably won't get you from Windows to dos. You'd know it if you were still booting Windows, of course. Possible you're still running Windows, but booting directly to a "dos box", do you suppose? Does anything interesting happen if you type "exit"?

As of Win98, "msdos.sys" was a text file. It had attributes of "system", "hidden", and "readonly" - "dir" wouldn't show it, but "dir /a" would. If you did "attrib -s -h -r msdos.sys", you could edit it. Change "GUI=1" to "GUI=0" (put the attributes back, if you like), and it would boot into dos - real dos! I'm pretty sure that won't work with Win2k. An alternative was in the shutdown menu - "restart in dos mode". This looked a lot like dos, but if you typed "exit", you'd find yourself back in Windows. Not real dos! Things are different in Win2k, but I wonder if there's an analogous situation you could be in?

In a "dos box", you could toggle between "full screen" and "windowed mode" with a keystroke... "alt-enter", I think, or maybe "control-enter"... or "alt-esc"? Try 'em all! :) I understand that in more recent versions of Windows, this no longer works. I understand that you can still get full-screen if you go into "control panel", "add or remove hardware"(?), and disable the graphics driver(?). I don't think I'd recommend you do that, unless you're willing to "reinstall system" if it goes horribly wrong...

But you intend to be running dos (right?). In that case, 320 x 200 should take up all of your screen, as soon as you switch to mode 13h. I've never owned a laptop, but I hear they're likely to have slightly non-standard graphics. Is your "dos prompt" full screen? If it is, and this "windowed" effect only appears when you switch to mode 13h, that may be "just the way it is" on that machine. Pity - nice moire pattern! If you ask for a higher resolution mode, does it get bigger? (try mode 11h, say?) If so, maybe you can adjust your code to a screen size you like. Shouldn't have to. It should work. I really don't know what you've run up against.

To get back to an earlier question, you should be able to do "regular input" with dos int 21h/0Ah (or int 21h ax=0C0Ah - flushes the input buffer first). This requires a "special" buffer (in dx) - the first byte must be the maximum number of bytes to accept (important!), the second byte is filled in with the number of bytes actually read when the int returns (can be useful, or you can ignore it), the actual input starts at "buffer + 2" (make sure you've left enough room for the "max" you said!) . You could use the "file read" subfunction (ah=3Ah??? lookitup) with the "handle" in bx set to STDIN (zero), too.

Handling multiple keys at the same time is more "interesting"... When a key is pressed, an interrupt is generated. When the key is released, another interrupt is generated. These are handled by the int 9 (IRQ 1) handler (usually). This code reads the "scancode" from the port (port 60h?). The "release" scancode has the high bit set, and is ignored... except for shift, alt, control (others? guess not). In these cases, the "up" or "down" state is kept track of by a bit in the "keyboard status word" in the "Bios Data Area" (segment 40h). To handle multiple keys, you'd need to replace the int 9 handler with one modified to keep track of the up/down state of all the keys - or the ones you were interested in. Not a real "new newbie" project, but when you're reasonably confident with "regular programs" you could give it a shot. Do you really have something useful to do with multiple keystrokes?

I think I've got an example int 9 handler, if you really want to get into that. Instead, I'll attach a couple of "256 byte demos" (not mine - don't ask me to explain 'em) for your viewing pleasure, at whatever size. :)

Best,
Frank


Offline Keith Kanios

  • Full Member
  • **
  • Posts: 383
  • Country: us
    • Personal Homepage
Re: Example code for NASM on MS-DOS on an IBM ThinkPad
« Reply #8 on: March 06, 2011, 09:16:57 PM »
In that case, 320 x 200 should take up all of your screen, as soon as you switch to mode 13h. I've never owned a laptop, but I hear they're likely to have slightly non-standard graphics.

Some laptops have LCD screens that don't scale... anything outside of their "optimal" resolution are not handled adequately.

Offline MosaicDawn

  • Jr. Member
  • *
  • Posts: 6
Re: Example code for NASM on MS-DOS on an IBM ThinkPad
« Reply #9 on: March 07, 2011, 02:56:29 PM »
Hi MosaicDawn,

Sorry for the delay. I don't have a good answer to your question. Sounds like a "Windows problem" to me, but you say...

Quote
And I dunno the specifics, I just made C:\ an MS-DOS boot disk and dumped DOS on it without installing it. Everything seems to work fine.
It had Windows 2000 installed on it previously.

I'm not clear exactly what you did. Simply copying the files over probably won't get you from Windows to dos. You'd know it if you were still booting Windows, of course. Possible you're still running Windows, but booting directly to a "dos box", do you suppose? Does anything interesting happen if you type "exit"?
No, I formatted the disk, then I plugged it into my computer via some HDD-USB cable and then used a utility that makes usb devices into boot disks and made it into an MS-DOS boot disk.
Nothing happens when I type "exit" it's the actual thing.
But you intend to be running dos (right?). In that case, 320 x 200 should take up all of your screen, as soon as you switch to mode 13h. I've never owned a laptop, but I hear they're likely to have slightly non-standard graphics. Is your "dos prompt" full screen? If it is, and this "windowed" effect only appears when you switch to mode 13h, that may be "just the way it is" on that machine. Pity - nice moire pattern! If you ask for a higher resolution mode, does it get bigger? (try mode 11h, say?) If so, maybe you can adjust your code to a screen size you like. Shouldn't have to. It should work. I really don't know what you've run up against.
I will try  switching around the modes.
1h - Text's height is compressed
2h - regular typing
3h - regular typing
4h - small resolution, letters are huge
5h - same
6h - Text's width is compressed
7h - Black and white
8h - Nothing
9h - Nothing
10h - Letters are smaller
11h - Letters are smaller
12h - Letters smaller, but less than in previous modes
13h - Huge letters
In some modes when I come back from DOS's editor, the screen hasn't cleared and there's strange colors and old text is still there.

I like the pattern too. It's animated. I made it in C by making a VGA example into a header and using it's PIXEL[x,y] function to loop through all the pixels and setting their colors as  ( x * x ) + (y * y ) and then looping that and in each cycle adding the loop count to that number. It looks really nice.

Thank you for the input info, I'll try messing around with it and see what I can do c:

EDIT: I did the osk.asm thing, it's incredible!
Also, could you code up a quick example on the input thing? :Uc
« Last Edit: March 07, 2011, 04:11:19 PM by MosaicDawn »