How should I pass values to openSCAD in command line? - command-line

I want to apply a certain modification on a bunch of stl files. So I wrote an openSCAD program and wanted to script from the command line, but it doesn't work and I can't figure out why.
According to the man page, I thought the following command would work but it doesn't (Ah, also I use an appimage version of openSCAD (for in case it would be important):
OpenSCAD-2021.01-x86_64.AppImage -o [OUTPUT FILE NAME] 'myscript.scad' -D filename=[INPUT FILE NAME]
However, it appears, the -D options doesn't do what I expect. So I made a little test script:
echo ("START");
filename1="cube.stl";
echo(filename1=filename1, filename2=filename2);
minkowski() {
import(filename1);
sphere(r=1, $fn=24);
}
translate([30, 0, 0])
minkowski() {
import(filename2);
sphere(r=1, $fn=24);
}
If I test myscript.scad with the gui version of openSCAD, it gives the following result (which is expected):
Compiling design (CSG Tree generation)...
ECHO: "START"
WARNING: Ignoring unknown variable 'filename2' in file test.scad, line 5
ECHO: filename1 = "cube.stl", filename2 = undef
WARNING: Ignoring unknown variable 'filename2' in file test.scad, line 14
Compiling design (CSG Products generation)...
ERROR: Unsupported file format while trying to import file '""', import() at line 14
Geometries in cache: 5
Geometry cache size in bytes: 128056
CGAL Polyhedrons in cache: 0
CGAL cache size in bytes: 0
Compiling design (CSG Products normalization)...
Normalized tree has 2 elements!
Compile and preview finished.
Total rendering time: 0:00:00.177
However, if I test it in command line, no value is initialized, and by the way, I have no idea what are both those warning on line 19 and 20 while my scad file only has 16 lines:
MyPrompt> ./OpenSCAD-2021.01-x86_64.AppImage -o 'test.stl' 'test.scad' -D filename1=cube.stl -D filename2=cube.stl
WARNING: Ignoring unknown variable 'cube' in file test.scad, line 19
WARNING: Ignoring unknown variable 'cube' in file test.scad, line 20
ECHO: "START"
ECHO: filename1 = undef, filename2 = undef
ERROR: Unsupported file format while trying to import file '""', import() at line 8
Geometries in cache: 4
Geometry cache size in bytes: 118112
CGAL Polyhedrons in cache: 1
CGAL cache size in bytes: 1362752
Total rendering time: 0:00:00.854
Top level object is a 3D object:
Simple: yes
Vertices: 576
Halfedges: 3168
Edges: 1584
Halffacets: 2024
Facets: 1012
Volumes: 3
For reference the cube.stl was made with the cube(); command and contains:
00000000 4f 70 65 6e 53 43 41 44 20 4d 6f 64 65 6c 0a 00 |OpenSCAD Model..|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000050 0c 00 00 00 00 00 00 80 00 00 00 00 00 00 80 3f |...............?|
00000060 00 00 00 00 00 00 80 3f 00 00 80 3f 00 00 80 3f |.......?...?...?|
*
00000080 00 00 80 3f 00 00 00 00 00 00 00 00 00 00 00 00 |...?............|
00000090 80 3f 00 00 80 3f 00 00 00 00 00 00 80 3f 00 00 |.?...?.......?..|
000000a0 00 00 00 00 80 3f 00 00 80 3f 00 00 00 00 00 00 |.....?...?......|
000000b0 00 00 00 00 80 3f 00 00 00 00 00 00 00 00 00 00 |.....?..........|
000000c0 00 00 80 bf 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000d0 00 00 80 3f 00 00 80 3f 00 00 00 00 00 00 80 3f |...?...?.......?|
000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 |................|
000000f0 00 00 00 00 80 bf 00 00 80 3f 00 00 80 3f 00 00 |.........?...?..|
00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000110 00 00 00 00 80 3f 00 00 00 00 00 00 00 00 00 00 |.....?..........|
00000120 00 00 80 bf 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000130 00 00 00 00 00 00 80 3f 00 00 00 00 00 00 80 3f |.......?.......?|
00000140 00 00 00 00 00 00 00 00 00 00 80 3f 00 00 00 00 |...........?....|
00000150 00 00 00 00 80 bf 00 00 00 80 00 00 80 3f 00 00 |.............?..|
00000160 00 00 00 00 80 3f 00 00 00 00 00 00 00 00 00 00 |.....?..........|
*
00000180 00 00 80 3f 00 00 00 80 00 00 00 00 00 00 80 3f |...?...........?|
00000190 00 00 00 00 00 00 80 3f 00 00 80 3f 00 00 80 3f |.......?...?...?|
*
000001b0 00 00 00 00 80 3f 00 00 00 00 00 00 00 00 00 00 |.....?..........|
000001c0 80 3f 00 00 80 3f 00 00 00 00 00 00 80 3f 00 00 |.?...?.......?..|
000001d0 00 00 00 00 80 3f 00 00 80 3f 00 00 00 00 00 00 |.....?...?......|
000001e0 00 00 00 00 00 00 00 00 00 00 80 3f 00 00 00 80 |...........?....|
000001f0 00 00 80 3f 00 00 80 3f 00 00 00 00 00 00 00 00 |...?...?........|
00000200 00 00 80 3f 00 00 80 3f 00 00 80 3f 00 00 80 3f |...?...?...?...?|
00000210 00 00 80 3f 00 00 00 00 00 00 00 00 80 3f 00 00 |...?.........?..|
00000220 00 00 00 00 00 00 00 00 80 3f 00 00 80 3f 00 00 |.........?...?..|
00000230 80 3f 00 00 80 3f 00 00 00 00 00 00 00 00 00 00 |.?...?..........|
00000240 80 3f 00 00 00 00 00 00 00 00 80 bf 00 00 00 00 |.?..............|
00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000260 00 00 00 00 00 00 80 3f 00 00 80 3f 00 00 00 00 |.......?...?....|
00000270 00 00 80 3f 00 00 00 00 00 00 00 00 80 bf 00 00 |...?............|
00000280 00 80 00 00 00 00 00 00 00 00 00 00 80 3f 00 00 |.............?..|
00000290 80 3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |.?..............|
000002a0 00 00 00 00 00 00 00 00 80 3f 00 00 |.........?..|

Ok, Got it :
The problem comes from the fact that openSCAD wants to receive string with the quotation marks. However, the shell will try to eat them. So, the correct calling syntax will be :
MyPrompt> ./Téléchargements/OpenSCAD-2021.01-x86_64.AppImage -o 'test.stl' 'test.scad' -D filename1='"cube.stl"' -D filename2='"cube.stl"'
ECHO: "START"
ECHO: filename1 = "cube.stl", filename2 = "cube.stl"
Geometries in cache: 4
Geometry cache size in bytes: 136832
CGAL Polyhedrons in cache: 1
CGAL cache size in bytes: 1524416
Total rendering time: 0:00:01.021
Top level object is a 3D object:
Simple: yes
Vertices: 672
Halfedges: 3536
Edges: 1768
Halffacets: 2200
Facets: 1100
Volumes: 3
This also explains the warnings, because it wasn't try to interpret cube.stl as a string, but as a variable name in dot notation (so the main variable name was indeed cube).

Related

Why does GNU ld include a section that does not appear in the linker script?

I'm trying to create a minimal C example on a boot sector for educational purposes.
However, I noticed that my example was not being recognized as a boot sector because he magic 0x55aa bytes were not present as the 511th and 512th bytes.
Then, I investigated further, and it seems that this is because the .eh_frame section was getting included in the image, even though it was never mentioned in the linker script.
Why is that?
The exact setup is present here and reproduced below
build.sh:
as -ggdb3 -o entry.o entry.S
gcc -c -ggdb3 -nostartfiles -nostdlib -o main.o main.c
ld -o main.elf -T linker.ld entry.o main.o
ld --oformat binary -o main.img -T linker.ld entry.o main.o
qemu-system-x86_64 -hda main.img
linker.ld
ENTRY(mystart)
SECTIONS
{
.text : {
entry.o(.text)
*(.text)
*(.rodata)
*(.data)
/**(.eh_frame)*/
. = 0x1FE;
SHORT(0xAA55)
}
/* Reserve 16 MiB of stack. */
__stack_bottom = .;
. = . + 0x1000000;
__stack_top = .;
}
entry.S:
.text
.global mystart
mystart:
mov %rsp, __stack_top
call main
jmp .
main.c:
void main(void) {
while (1);
}
If I uncomment the .eh_frame frame above, then it gets included at the specified location, and things work, although it is not ideal and I would rather ignore that section completely.
But why does it try to include the .eh_frame in the final image if I never mention it?
I found out about .eh_frame by doing:
hd main.img
which gives:
00000000 14 00 00 00 00 00 00 00 01 7a 52 00 01 78 10 01 |.........zR..x..|
00000010 1b 0c 07 08 90 01 00 00 1c 00 00 00 1c 00 00 00 |................|
00000020 27 00 00 00 06 00 00 00 00 41 0e 10 86 02 43 0d |'........A....C.|
00000030 06 00 00 00 00 00 00 00 48 89 24 25 38 02 00 01 |........H.$%8...|
00000040 e8 02 00 00 00 eb fe 55 48 89 e5 eb fe 66 2e 0f |.......UH....f..|
00000050 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 |.......f........|
00000060 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 |.f.........f....|
00000070 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 |.....f.........f|
00000080 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 |.........f......|
00000090 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f |...f.........f..|
000000a0 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 |.......f........|
000000b0 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 |.f.........f....|
000000c0 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 |.....f.........f|
000000d0 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 |.........f......|
000000e0 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f |...f.........f..|
000000f0 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 |.......f........|
00000100 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 |.f.........f....|
00000110 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 |.....f.........f|
00000120 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 |.........f......|
00000130 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f |...f.........f..|
00000140 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 |.......f........|
00000150 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 |.f.........f....|
00000160 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 |.....f.........f|
00000170 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 |.........f......|
00000180 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f |...f.........f..|
00000190 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 |.......f........|
000001a0 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 |.f.........f....|
000001b0 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 |.....f.........f|
000001c0 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 |.........f......|
000001d0 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f |...f.........f..|
000001e0 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 |.......f........|
000001f0 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 |.f.........f....|
00000200 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 |.....f.........f|
00000210 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 |.........f......|
00000220 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 0f 1f |...f.........f..|
00000230 84 00 00 00 00 00 55 aa |......U.|
00000238
and then:
objdump -D main.o
which contains:
Disassembly of section .eh_frame:
0000000000000000 <.eh_frame>:
0: 14 00 adc $0x0,%al
2: 00 00 add %al,(%rax)
4: 00 00 add %al,(%rax)
6: 00 00 add %al,(%rax)
8: 01 7a 52 add %edi,0x52(%rdx)
b: 00 01 add %al,(%rcx)
d: 78 10 js 1f <.eh_frame+0x1f>
f: 01 1b add %ebx,(%rbx)
11: 0c 07 or $0x7,%al
13: 08 90 01 00 00 1c or %dl,0x1c000001(%rax)
19: 00 00 add %al,(%rax)
1b: 00 1c 00 add %bl,(%rax,%rax,1)
1e: 00 00 add %al,(%rax)
20: 00 00 add %al,(%rax)
22: 00 00 add %al,(%rax)
24: 06 (bad)
25: 00 00 add %al,(%rax)
27: 00 00 add %al,(%rax)
29: 41 0e rex.B (bad)
2b: 10 86 02 43 0d 06 adc %al,0x60d4302(%rsi)
31: 00 00 add %al,(%rax)
33: 00 00 add %al,(%rax)
35: 00 00 add %al,(%rax)
...
so we can see that in the hd main.img, the first bytes are exactly the same as those in .eh_frame, and the image size is 512 + sizeof(.eh_frame) instead of the expected 512.
Tested on Ubuntu 18.04, GCC 7.3.0, binutils 2.30.

Device::HID read barcode scanner convert binary to Ascii

I try to read barcode form scanner. I had got data from scanner and the format is binary. How do I conert binary to Ascii string?
The barcode type is code 39.
A1234 => [Barcode SCANNRT] => [perl] => binary => ?? A1234 ???
use Device::HID;
use Data::Hexdumper qw(hexdump);
my $dev = Device::HID->new(vendor => 0x04b4, product => 0x0100) or die "No such device !\n";
$dev->timeout = 0.1; # seconds (=100 ms)
my $buf;
my $len=128;
while(defined(my $in = $dev->read_data($buf, $len))){
if ($in == 0) {
next;
}
print hexdump(
data => $buf, # what to dump
suppress_warnings => false,
space_as_space=> true,
);
}
The input "A1234" binary output. How to convert to sting "A1234".
0x0000 : 02 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 1E 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 1F 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 : .. .............
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 21 00 00 00 00 00 00 00 00 00 00 00 00 00 : ..!.............
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 00 : ..(.............
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
I change code to get hexadecimal for each package.
use Device::HID;
use Data::Hexdumper qw(hexdump);
my $dev = Device::HID->new(vendor => 0x04b4, product => 0x0100) or die "No such device !\n";
$dev->timeout = 0.1; # seconds (=100 ms)
my $buf;
my $len=128;
my $i=0;
while(defined(my $in = $dev->read_data($buf, $len))){
if ($in == 0) {
next;
}
$i++;
my $hex = unpack( 'H*', $buf );
print sprintf("%02d",$i)." => $hex\n";
}
The out is hexadecimal. I change code to output hexadecimal. I received 12 package.
How to convert to string 'A1234' ?
01 => 0200040000000000
02 => 0000000000000000
03 => 00001e0000000000
04 => 0000000000000000
05 => 00001f0000000000
06 => 0000000000000000
07 => 0000200000000000
08 => 0000000000000000
09 => 0000210000000000
10 => 0000000000000000
11 => 0000280000000000
12 => 0000000000000000
Split into 8 byte chunks (for your device, it depends on the device descriptor). Column 0 is control key (2nd bit indicates the shift key is pressed), column 2 is the usage code as per section 10 (page 53) of the USB HID Usage Tables doc:
https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf
If the key is a 0, then just ignore it.
So this input:
0x0000 : 02 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 1E 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 1F 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
becomes:
02 04 (shift + a) = "A"
00 00 (ignore)
00 1E (1) = "1"
00 00 (ignore)
00 00 (ignore)
00 00 (ignore)
00 1F (2) = "2"
00 00 (ignore)
...and so on.

How is this real number encoded?

Number in HEX is: 3EB8 EDFE 19FE
I know it means 16.131 in DEC, but I don't know how it's encoded.
I checked if it's BCD, IEE 754 or integer, but none of those worked.
EDIT: It's from Parkin Elmer Clarus 400 chromatograph. This data contains time in minutes.
EDIT2: Here is part of parsed data, I only have one example:
Peak Component Time Area ISTD Resp ISTD Component glycerol
# Name [min] [uV*sec] Ratio Name Amount
4 glicerol 3,823 52377,25 0,316 butanotriol 0,0159
5 butanotriol 5,267 165539,60 1,000 ----------
suma mono 16,131 2086652,93 0,489 mono C19 0,4887
And here are corespodning parts of raw data:
67 6C 69 63 65 72 6F 6C FF FF FF FF 00 00 00 04 glicerol˙˙˙˙....
00 00 00 00 00 00 00 00 00 00 00 00 86 95 E6 F4 ............†•ćô
3F 40 7E AD 2D CE E1 7C 3F 90 47 23 62 CD D1 20 ?#~.-Îá|?.G#bÍŃ
3F 24 AB 9A DF CC 8E 91 3F D4 3F F2 F7 93 40 52
3F C9 6F 26 00 00 00 00 00 00 00 00 74 CB ED 69
40 0A 5A BC 13 46 09 AC 41 54 1A F3 A6 C3 FE 05
C0 A1 AB 83 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 0F 3B
00 00 0F 6D 00 00 0F D3 00 4A 28 80 00 7D BD 1A
00 4A 7E 4C 26 4A 16 A5 40 73 80 A7 00 00 00 00
40 73 C0 00 4B 83 8C 12 40 74 42 C7 CB 2C BB 1F
41 04 35 1C EA 62 D1 6A 40 DE 7D C4 00 00 00 00
00 00 00 07 00 00 00 80 00 00 00 67 00 00 00 81
00 00 00 00 00 00 00 78 00 00 00 00 00 00 00 00
00 00 00 0B 62 75 74 61 6E 6F 74 72 69 6F 6C 00 ....butanotriol.
FF FF FF FF FF FF FF FF 00 00 00 01 00 00 00 00 ˙˙˙˙˙˙˙˙........
00 00 00 00 8A 95 47 69 3F 5A 10 F0 00 00 00 00 ....Š•Gi?Z.đ....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
3F F0 00 00 00 00 00 00 3F F0 00 00 00 00 00 00 ?đ......?đ......
00 00 00 00 A0 E8 FC 91 40 12 27 A5 BD 8C D6 B0
41 50 62 7A 34 5A FA AA 40 9C 49 2B 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 16 7C 00 00 16 E8 00 00 16 ED
00 4D 8C D8 03 B4 0E 0F 03 9D 5F AA C2 8F 5C 29
40 7C C8 F5 71 CB 11 FD 40 7D 53 58 56 D6 7F A3
40 7D 5A 4B EA 10 78 82 41 41 1C 1A 6D 3D 44 F7
41 1F E5 8C 00 00 00 01 00 00 00 02 00 00 00 6E
00 00 00 64 00 00 00 6F 00 00 00 00 00 00 00 72
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF
FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00
88 30 F9 69 3F 96 12 04 84 DC 1A D0 40 01 F0 DF
47 2F E1 08 3F 96 C8 38 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CD CA D9 96 40 1A F5 01 D4 4E 32 45 C1 78 D2 E7
74 5D 17 46 40 F0 7E 09 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 16 ED 00 00 16 F6 00 00 16 FA 03 9D 5F AA
03 F4 EA 71 03 E0 F9 FB 56 D6 7F A3 40 7D 5A 4B
88 CF 98 C1 40 7D 65 32 7A 5F 43 F9 40 7D 6A EC
E1 92 F1 30 41 21 24 D6 52 75 CC 80 41 21 20 40
00 00 00 01 00 00 00 02 00 00 00 6E 00 00 00 64
00 00 00 6F 00 00 00 00 00 00 00 72 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
73 75 6D 61 20 6D 6F 6E 6F 00 00 00 00 00 00 02 suma mono.......
00 00 00 01 51 EB 85 1F 40 8E 3E B8 ED FE 19 FE ....Që….#Ž>¸íţ.ţ
41 3F D6 FC F1 41 FD 57 41 18 42 2A 4A C8 FD 16 A?ÖüńAýWA.B*JČý.
41 3B 96 32 3C 2C 44 95 41 13 F2 D1 FF FF FF FF A;–2<,D•A.ňŃ˙˙˙˙
00 00 00 1E 00 00 00 02 69 85 75 9B 3F 94 89 17 ........i…u›?”‰.
08 08 4F F0 3F DF 47 16 39 EC E5 8C 3F 73 DB DD ..Ođ?ßG.9ěĺŚ?sŰÝ
08 08 4F EF 3F DF 47 16 08 08 4F F0 3F DF 47 16 ..Oď?ßG...Ođ?ßG.
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

What are the three 255's before the image in a monochrome .bmp?

I'm trying to figure out bitmap formatting for a project I'm working on, but there's one thing I don't really get. In this .bmp:
00000000 42 4d aa 00 00 00 00 00 00 00 82 00 00 00 6c 00 |BM............l.|
00000010 00 00 0a 00 00 00 0a 00 00 00 01 00 01 00 00 00 |................|
00000020 00 00 28 00 00 00 13 0b 00 00 13 0b 00 00 02 00 |..(.............|
00000030 00 00 02 00 00 00 42 47 52 73 00 00 00 00 00 00 |......BGRs......|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000060 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 |................|
00000070 00 00 00 00 00 00 00 00 00 00 ff ff ff 00 00 00 |................|
00000080 00 00 ff c0 00 00 ff c0 00 00 ff c0 00 00 ff c0 |................|
*
000000a0 00 00 ff c0 00 00 aa 80 00 00 |..........|
000000aa
what are the three 256's at offset 122 (line 7). I assume they're some sort of color indicators, but I'm not sure.
This is the image I'm using.
The top part of your hex dump is a "BITMAPINFO structure" (https://msdn.microsoft.com/en-us/library/dd183375(v=vs.85).aspx). This is immediately followed by a color index array bmiColors (although its length may be 0, and you should check this in the BITMAPINFO data).
Although some say that
[t]hough seemingly a simple format, it is complicated by its many different versions, lack of an official specification, lack of any version control process, and ambiguities and contradictions in the documentation.
(http://fileformats.archiveteam.org/wiki/BMP)
you don't actually need to understand each single byte. The various structures either have a fixed size (the initial BITMAPFILEHEADER for example), or have their length as its first value.
A line by line annotation of most well-documented parts:
-------- BITMAPFILEHEADER
00000000 42 4d file type identifier
00000002 aa 00 00 00 size in bytes of the entire file
00000006 00 00 (reserved and must be 0)
00000008 00 00 (reserved and must be 0)
0000000A 82 00 00 00 offset from the beginning of the BITMAPFILEHEADER structure to the bitmap bits
-------- BITMAPINFOHEADER
0000000E 6c 00 00 00 BITMAPINFOHEADER structure size
00000012 0a 00 00 00 image width in pixels
00000016 0a 00 00 00 image height in pixels
0000001A 01 00 number of planes
0000001C 01 00 number of bits per pixel
0000001E 00 00 00 00 compression
00000022 28 00 00 00 size in bytes of image data
00000026 13 0b 00 00 horizontal resolution in pixels-per-meter
0000002A 13 0b 00 00 vertical resolution in pixels-per-meter
0000002E 02 00 00 00 number of colors in the color table that are actually used by the bitmap
00000032 02 00 00 00 number of color indexes that are required ("important")
........ badly documented stuff ........
00000036 42 47 52 73 00 00 00 00 00 00
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000060 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00
00000070 00 00 00 00 00 00 00 00 00 00
-------- end of BITMAPINFOHEADER
-------- bmiColors array
0000007A ff ff ff 00 color table entry #0
0000007E 00 00 00 00 color table entry #1
-------- Image data
00000082 ff c0 00 00 ff c0 00 00 ff c0 00 00 ff c0
000000a0 00 00 ff c0 00 00 aa 80 00 00
The "number of bits per pixel" at 0000001C is 1:
"1 = The bitmap is monochrome, and the bmiColors member of BITMAPINFO contains two entries. Each bit in the bitmap array represents a pixel. If the bit is clear, the pixel is displayed with the color of the first entry in the bmiColors table; if the bit is set, the pixel has the color of the second entry in the table."
(https://msdn.microsoft.com/en-us/library/dd183376(v=vs.85).aspx)
and the number of colors in the array is reported to be 2. So the bmiColors array contains 2 elements in Microsoft's RGBQUAD format, with values in the odd order Blue, Green, Red, and Reserved.
In short: in your image, a pixel value of 0 (a 0 bit in a monochrome image) is FFFFFF: white, and a pixel value of 1 is 000000: black.

How to solve "Error 13 while loading file" when using Qemu?

I write the following bytes into a file named disk.img
FA 8D 36 1B 7C E8 01 00 F4 AC 3C 00 74 0C B4 0E
BB 07 00 B9 01 00 CD 10 EB EF C3 4D 61 79 20 74
68 65 20 66 6F 72 63 65 20 62 65 20 77 69 74 68
20 79 6F 75 21 0D 0A 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
..enough zero to make the size of file 512bytes.
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
The above bytes are proper instructions and magic number that should work when loading into the boot sector. But after I executed "qemu-X86_64 disk.img", error happens.
Error -13 while loading disk.img
Does anyone know how to solve the problem or what is the reason that might lead to this error?
Thank you!
I don't know if you can fill an image with just anything and expect it to work just because you have 55 AA in the correct place. Since you seem to be writing a bootloader make sure your code thinks it is executing at the correct place. It should be in offset 0x7C00 (if I remember this correctly, double check that). You set it by writing the line [org 0x7C00] at the top of your assembly file.
Also I'm not sure you can have only a 512 byte file. Try to make the disk image bigger than that using something like dd if=/dev/zero of=disk.img bs=512 count=2000 and then just copy your bootloader to the first part of the disk using dd again.
Also, you should use the -hda or -fda tags, so it would be qemu -hda disk.img. -hda means hard drive image, and -fda means floppy disk image.