ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Where does it generate that code?
That appears to be startup code. I would not expect the startup code to be generated when compiling a .c file and I thought you were providing your own startup code, not linking in the standard startup module for .com files.
Code:
_TEXT segment byte public 'CODE'
extrn DGROUP@:word
_TEXT ends
I think that means DGROUP@ is a location in the _TEXT segment containing the value DGROUP (meaning I was wrong earlier to guess it was just another name for DGROUP).
The correct value of DGROUP for tiny model is actually the value of the cs register. So you could add that to your startup module.
I don't understand how the declaration of _main and jmp _main you quoted in your startup module could be correct, so I'm just quoting that part back to you as you gave it to me, so I can show you where the change I'm suggesting fits in:
I gave you a URL for some tasm doc Yesterday in post #38 of this thread.
I got directly to that copy from a google search on a specific detail from this thread. But you might find a better version by going up one level in that URL to the containing directory: http://www.bitsavers.org/pdf/borland/
Which link? A link directly to the pdf file or the link to the directory above the pdf?
Your browser may hang for a long time on a blank screen if you click directly on one of those pdf files. Then it should eventually show you contents.
It may be more effective to right click on the pdf link and select to save the pdf to your own system. Then you get a progress indication of how slowly it is arriving and you can use it once it is saved.
Edit: I just remembered that link acted differently for me in Firefox in Linux than it did in Firefox in Windows. In Linux, the pdf reader popped up behind the browser window so the browser tab stayed blank and Firefox continued to work well in other tabs I was using. By the time I noticed the pdf window behind the browser window the contents were already there (maybe you didn't notice a pdf window behind the broswer window). In windows, clicking the link froze the whole Firefox (all tabs) on a blank tab until the whole file was downloaded then it embedded a pdf viewer in place of the blank tab and all the other tabs unfroze. I guess the pdf viewer is integrated with Firefox differently on my two systems. Neither behavior is great. If I knew in advance this pdf was difficult I would have used the right click/save method.
i got it to assemble, compile & link into a reguler .com file in the tiny model but still
garbadge where its suppose to be a string
In post #15 you had a disassembly of the whole thing. There are some parts of that which I would want to look at the cumulative changes from everything you've done so far. You could post the key parts or the whole thing, whichever is more convenient for you.
The startup code at offset 0300 is importantant. Yesterday you needed to disassemble that seperately, because the main disassembly had it as data.
That include the jmp to _main, which yesterday was loc_EBF
The code it jumps to is also important. Yesterday loc_EBF wasn't labeled but was disassembled as
Code:
push bp
mov bp, sp
sub sp, 2
push si
push di
mov al, ds:byte_C60
mov [bp-2], al
...
Somewhere soon after that, I'd expect to see the code that does the broken reference to the data, but in Yesterday's version I don't see that.
The first function in the disassembly yesterday (sub_309) had a data reference (word_C5A) that could be checked against the disassembly near location C5A to see that the code was not correctly linked for tiny memory model. Anything similar to that (both reference and vicinity of referenced location) should be enough now to see if the code is compiled and linked correctly for tiny model.
;
; Boot-n-Load
;
; Bootable floppy. BIOS loads one sector, executes it. The
; executable loads the next level of code.
;
; To build & use (DOS Batch file):
;
;; ;; NASM16 -f bin -o bnl1.bin -l bnl1.lst bnl1.asm
;; ;; NASM16 -f bin -o bnl2.bin -l bnl2.lst bnl2.asm
;; ;; copy /b bnl1.bin+bnl2.bin bnl.bin
;; ;; rawrite2 -f bnl.bin -d A -n
;
LEVEL2_SEG equ 0x9000
LEVEL2_OFF equ 0x0100;0x0000
[BITS 16]
[ORG 0]
BnL_start:
;
; We know the absolute address, but some BIOSes use different
; SEG:OFF combos. This makes sure we are using offsets that agree
; with our ORG statement
;
jmp 0x07c0:BnL_Go
BnL_HelloMsg:
db 'BnL ver 0.1',0x0d,0x0a,0
BnL_Go:
mov ax, cs
mov es, ax
mov ds, ax
;
; Set up a stack
;
cli
mov sp, 0xffff
mov ax, LEVEL2_SEG
mov ss, ax
sti
mov si, BnL_HelloMsg ; Print msg
BnL_SayHello:
lodsb ; AL=memory contents at DS:SI
cmp al, 0 ; If AL=0 then done talking
je BnL_ResetDisk ; go on to next step
mov ah, 0x0E ; Print AL
mov bx, 7 ; text attribute/colour
int 10h ; BIOS Print Char
jmp BnL_SayHello ; Print next character
;
; Load the next piece of code from sector 2, 3...
;
BnL_ResetDisk:
mov ax, 0
int 0x13 ;
jc BnL_ResetDisk
BnL_Reload:
mov ax, LEVEL2_SEG
mov es, ax ; SEgment address for destination
mov ah, 02 ; BIOS Int 13h func: Read disk
mov al, 9 ; sector count
mov bx, LEVEL2_OFF ; Address OFFSET for destination (ES:BX --> dest)
mov ch, 0 ; Disk cylinder
mov cl, 2 ; Sector (numbered from 1)
mov dh, 0 ; Head
mov dl, 0 ; Drive
int 0x13
jc BnL_Reload
jmp LEVEL2_SEG:LEVEL2_OFF
TIMES 510-($-$$) db 0x90
dw 0AA55h
;
;=========================================================================
; The following code is loaded from disk sector(s) following
; the sector 1 code loaded and invoked by the BIOS.
; We jump to this code from the bootstrap loader above.
;
;
; mov ax, cs
; mov es, ax
; mov ds, ax
;
; mov si, BnL2_HelloMsg
;BnL2_SayHello:
; lodsb ; AL=memory contents at DS:SI
;
; cmp al, 0 ; If AL=0 then done talking
; je BnL2_Go ; go on to next step
;
; mov ah, 0x0E ; Print AL
; mov bx, 7 ; text attribute/colour
; int 10h ; BIOS Print Char
;
; jmp BnL2_SayHello ; Print next character
;
;
;BnL2_Go:
; jmp $
;
;BnL2_HelloMsg:
; db 'Now using level2 code', 0
;
;times 1022-($-$$) db 0xff
;dw 0AA55h
Those bits of source code are interesting, but I don't know what your tool chain is turning them into. So I wanted to see the disassembly of certain parts.
For example, you have the two line
extrn _main:far
and
jmp _main
I can't imagine how the tool chain could turn that into something correct. Yesterday you showed what should have been the disassembly of that and it was
Code:
seg000:0306 jmp loc_EBF
but that is not a far jmp.
At my suggestion, you added the line
mov DGROUP@,ax
After compiling and linking that instruction may indicate whether the tiny memory model and offset of 0x100 have been dealt with correctly by your build process. But I need to see the disassembly for that.
Similarly, I would like to see the disassembly of
kernel_print("Hey!");
All dissasemblies of course should be from the final output of the build process, the kernel.out file that you actually test on diskette.
Notice that it is 13h, but should have been 113h. That tells me the offset of 0x100 that seems to be implicit in the way you load and run this code is not taken into account by the way you link the code.
I also see that you are disassembling this section at offset 0100, but in your kernel.out file it should have been at offset 0300.
We see the same off by 0x100 error in the line
Code:
seg000:0E37 mov ax, 0D69h
The actual data is at 0E69h
If the tool chain isn't applying the 0x100 offset, maybe the cleanest approach is to change the boot code to not introduce that offset, which I think would be accomplished by changing LEVEL2_OFF back to 0000. That would mean the code can no longer be debugged as a .com, but I'm not sure that will matter for long.
If you want to keep LEVEL2_OFF equal to 0x100 and adjust the code to work right in a debugger as a .com file, I'm not certain of the rules in tasm, but I think adding the line
org 0100h
right before START: might fix it.
Also, I see the jmp at seg000:0110 is a correct near jmp even though you declared it far. I don't know why tasm and/or tlink fixes that apparent error in the source code, but I guess that bit works no matter how wrong it looks to me.
Reread my post. I think you read it while I was editing it (I often press Submit Reply on a half written post and then finish it with Edit. Maybe that's a bad habit, but it's what I'm used to.)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
