NASM - The Netwide Assembler
NASM Forum => Example Code => Topic started by: Deskman243 on June 26, 2023, 01:55:17 PM
-
Good day everyone
I have noticed an increase of subjects on section use for NASM files. Coincidentally I've been mostly researching this as a quintiessential proof of concept program. For an overview we know that NASM offers a variety of file output options.
Previously I posted about the distinctions between making binary these file configurations. In this case I'm looking at the corresponding linux file commands for .bin files.
I have two types of model designs for review .
As a proof of concept here is the main design of a common linker path. The inferences here are majorly between the image preparation slightly changing the commands that can be observed from the figures below. Right now my question is about an adjustment for making these paths.
(1) File.img <= CAT file commands <= .bin files <= optional LD file commands <= optional elf type objects <= NASM assembling
(2) File.img <= DD file commands <= .bin files <= optional LD file commands <= optional elf type objects <= NASM assembling
Here are the corresponding build files.
(1) run2.sh
nasm -f bin -g -o boot2.bin boot2.asm
nasm -f elf -g stage1.asm -o stage1.o
nasm -f elf -g stage2.asm -o stage2.o
nasm -f elf -g stage3.asm -o stage3.o
nasm -f bin -g test2.asm -o test2.bin
nasm -f bin -g test3.asm -o test3.bin
nasm -f elf -g test2.asm -o test_2.o
nasm -f elf -g test3.asm -o test_3.o
nasm -f bin -g stage2.asm -o stage_2.bin
ld -g -m elf_i386 -Ttext 0x7e00 stage1.o -o stage1.bin --oformat binary
ld -g -m elf_i386 -Ttext 0x8000 stage2.o -o stage2.bin --oformat binary
ld -g -m elf_i386 -Ttext 0x8400 stage3.o -o stage3.bin --oformat binary
ld -g -m elf_i386 -Ttext 0xe600 test_2.o -o test_2.bin --oformat binary
dd if=/dev/zero of=os.bin bs=512 count=2828
cat boot2.bin \
stage1.bin \
stage2.bin \
stage3.bin \
test_2.bin \
test4.bin \
os.bin>os.img
rm -rf *\.bin
qemu-system-i386 -fda os.img
(2) Makefile
FILES =boot.o
FILES2 =stage3.o printstr.o
PROCURE = rm -rf
all: boot.bin stage1.bin test1.bin stage2.bin
dd if=boot.bin of=os.img bs=512 count=66 conv=notrunc
dd if=stage1.bin of=os.img bs=512 seek=1 conv=notrunc
dd if=test1.bin of=os.img bs=512 seek=10 conv=notrunc
dd if=stage2.bin of=os.img bs=512 seek=18 conv=notrunc
truncate -s 1M os.img
boot.o: boot4.asm
nasm -f elf -g -o boot.o boot4.asm
stage1.o: stage1.asm
nasm -f elf -g stage1.asm -o stage1.o
test1.o: test1.asm
nasm -f elf -g test1.asm -o test1.o
stage2.o: stage2.asm
nasm -f elf -g stage2.asm -o stage2.o
test2.bin: test2.asm
nasm -f bin -g test2.asm -o test2.bin
boot.bin: $(FILES)
ld -T link.ld $(FILES) -o boot.bin
stage1.bin: stage1.o
ld -g -m elf_i386 -T link2.ld stage1.o -o stage1.bin --oformat binary
stage2.bin: stage2.o
ld -g -m elf_i386 -T link4.ld stage2.o -o stage2.bin --oformat binary
test1.bin: test1.o
ld -g -m elf_i386 -Ttext 0x9000 test1.o -o test1.bin --oformat binary
clean:
$(PROCURE) *\.o
$(PROCURE) *\.bin
$(PROCURE) os.img
Right now I'm trying to test the first program pathing however I have one major contestion. The "optional" part was for a graphical file that is very large. In fact I could only keep these file sizes when I use LD. However when I try to include other files past this I get weird readings from the file segments. Currently I'm trying to adjust a bug I found in my previous post concerning the path of the program here
Disk_Read(boot.asm) => Jump_From_Gate(Stage1.asm)
=>Jump_Into_BIOS16_Segment(Stage2.asm @ 0x8000)
=>test2.asm(data number fill pad @ 0x8200)
=>Stage3_Addressment( @ 0x8400)
If anyone else has found a similar thing I would be really happy to review this further. Otherwise I'll be available to correspond whenever I get these designs checked out.
Cheers!
-
Revision 1
Here's a copy of the full source code for reference
-
"xrm rfx" looks like a very dangerous command to me!
What's the story?
Frank
fbkotler
pig's tail
myfairpoint
dot
net
-
Good news everyone
I got a patch in practice for the previous models. Apparently the BIOS Disk_Read functions coincidentally change addresses for the files larger than 512b. This takes care of the "optional" part of the model. I'll be adding a new revision once I pass the first round of test files.
"xrm rfx" looks like a very dangerous command to me!
What's the story?
Frank
fbkotler
pig's tail
myfairpoint
dot
net
Would you care to clarify this reference because I don't have any clue haha
-
Hi Deskman.
Perhaps I am confused. No, I am definitely confused!
The referenced "dangerous command", or something like it. will delete everything on your system. It makes me inclined to ban you and your dog and the girl you took to the prom - forever! However I know you to be a legitimate poster... I hope... so I'm confused.
Further... "-f bin" makes sense, but "-g" doesn't do anything useful... I'm pretty sure.
"-f elf" does not make sense to me in this context... but you seem to use it successfully... I don't know how... So I'm confused on that, too.
You don't have to straighten me out. I can stay confused. But I got an email that this post had been "reported" which brought it to my attention. You might want to clarify that "dangerous command for me, at least.
Good luck, in any case!
Best,
Frank
-
I apologize if the above seems "confrontational". Not intended. Perhaps I'm confusing you as well...
Best,
Frank
-
Don't worry I know that being a regular on forums is not as easy as most people would like. I myself struggle whenever I try to reference my previous posts. I'm happy to say that this time was pretty self-referential where I'm managing to quote from the main article.
For instance right now I'm improving the new round of tests by comparing between the two previous version models. To show this I'd like to add a new review by looking at the current state and outlines here now.
Source Design 2
To surmize I have managed to add improvements for the main contestion of the original's "optional" parts. From the original pathing we may observe
(1) File.img <= CAT file commands <= .bin files <= optional LD file commands <= optional elf type objects <= NASM assembling
To restate here the contestion was for the size in use of the previous binary files. The new adjustments take care of these binary files by correlating the values from the disk_read function more appropriately. Basically the variables at hand are between the AL and CL components of the BIOS function. Where AL = section_size and CL=section_segment_number represented by the code snippet below.
mov bx,0x0000_8000
mov cl,3
mov bx,msgString
mov bx,0x0000_8000
mov cl,3
mov al,2
call read_section
mov cx,0x800
mov es,cx
mov bx,0
mov cx,00000h
mov cl,3
;mov bx,0x0000_8000
mov al,2
call read_section
Consequentally instead of merely counting the parts I compensate for this by adjusting the value of CL to the corresponding value of AL. To illustrate this here is a new outline of path
Disk_Read(boot.asm) => Jump_From_Gate(Stage1.asm)
=>Jump_Into_BIOS16_Segment(Stage2.asm @ 0x8000) <CL=3 AL=2>
=>Stage3_Addressment( @ 0x8400) <CL=3+1 - AL-1=5>
The main inference being that CL is dependent on the values put into AL (CL=previous CL +1 + AL-1).
Amazingly this was not the case in the 2nd design where the boot file's disk_read was simplified to a single function
[BITS 16]
;[ORG 0x7c00]
section .text
_prep_module:
xor ax,ax
mov ds,ax
mov es,ax
mov ss,ax
mov sp,0x7C00
DriveIdPrep:
mov [DriveId],dl
mov ah,0x41
mov bx,0x55aa
int 0x13
; jc CheckPrep
cmp bx,0xaa55
; jne CheckPrep
SizeFunction:
mov bx,0x0000_7E00
mov cl,2
mov ah,0x02
; mov al,1
; mov al,12h
mov al,65
mov ch,0
mov dh,0
int 0x13
; jc ReadCheck
mov dl,[DriveId]
mov cx,0x1000
mov es,cx
mov bx,0x0000_0000
;mov bx,0x0000_D000
mov cl,3
mov bx,0x0000_0000
mov cl,3
mov al,1
call read_section
;mov cx,0xD00
mov cx,0x1000
mov es,cx
mov bx,0
;mov al,1
mov cl,3
mov al,1
call read_section
mov cx,0
mov es,cx
.move1:
jmp 0x7e00
Source Design 3
However for the purposes of the article it is pertinent to restate that the objective here is to make a conventional design of the BIOS .In conclusion the problem in the 2nd design is that build commands referencing anything beyond the disk_read function is still in testing. What else is now similarly in the Source Design 2 reference the disk_read function reads the incomplete check whenever I read anything beyond CL=0x24 passed the stage3.asm section. I'm convinced this is just a settings configuration in the BIOS however I still have to test that meanwhile again I'm happy to post the new source code and continue this conversation any further and I'm sorry for any discrepancies I make in these long form posts.
-
Hi Deskman.
I see the file asking us to let you change files , Don't know how.
Just post the new files..,
Best
Frank
[
-
Yes please, just make a new post with updated sources
-
Sorry the current sources are online now. Please let me know if there's anything else I can assist in.