FASM - Boot sector on USB don't work - usb

in first, sorry for my bad english, i'm french.
At the moment, i learn asm with fasm to test boot sector programming.
I have make a simple boot program, i have compiled it and i write boot.bin in first sector of my usb.
But when i boot on my PC or in virtualbox, drive isn't found....
Boot sector code:
;=======================================================================
; a simpliest 1.44 bootable image by shoorick ;)
;=======================================================================
_bs equ 512
_st equ 18
_hd equ 2
_tr equ 80
;=======================================================================
org 7C00h
jmp start
nop
;=====================================================
db "HE-HE OS"; ; 8
dw _bs ; b/s
db 1 ; s/c
dw 1 ; rs
db 2 ; fats
dw 224 ; rde
dw 2880 ; as
db 0F0h ; media
dw 9 ; s/fat
dw _st ; s/t
dw _hd ; h
dd 0 ; hs
dd 0 ; --
db 0 ; drv
db 0 ; --
db 29h ; ebr
dd 0 ; sn
db "NO NAME "; ; 11
db "FAT12 "; ; 8
;=====================================================
start:
mov ax,cs
mov ds,ax
mov cx,count
mov si,hello
mov bx,7
mov ah,0Eh
##:
lodsb
int 10h
loop #B
xor ah,ah
int 16h
int 19h
hello db "Hi! This is disk-invalid!"
count = $ - hello
;=======================================================================
rb 7E00h-2-$
db 055h,0AAh
;=======================================================================
This code is provide by examples of fasm's website.

there are couple of reasons why a bootloader wont work:
the bootloader is not in the first sector of the USB/Floppy/etc.
the bootloader is not EXACTLY 512 bytes long
you are missing the 0xAA55 signature at the last 2 bytes of the bootloader
in your example i assume you have the wrong bootloader size ( it is not 512 bytes )
try replacing
rb 7E00h-2-$
db 055h,0AAh
with
TIMES 510-($-$$) DB 0
DW 0xAA55
this ensures that your file is exactly 512 bytes long and that is has the required bootloader signature

Related

in z/OS Assembler, can I read a JCL input stream twice?

Is there a way to read a z/OS JCL input stream more than once? (one that comes from a //SYSIN DD *). I know I could cache the stream the first time I read it, and then read from the cached data, but I'm not interested in that solution.
Note: the language is Assembler
Depends on the language. This answer provides an example in HLASM and a reference to the 'C' Language reference at the end.
For Assembler you'll need to REWIND when you CLOSE the DCB. See the label at FINISH to see how this is done.
There may be other ways but this worked for me on z/OS 2.4
PRINT NOGEN
* ------------------------------------------------------------------- *
* *
* SYSIN2 *
* *
* #author Hogstrom *
* *
* Test to see if one can re-read SYSIN more than one time. *
* *
* ------------------------------------------------------------------- *
R0 EQU 0
R1 EQU 1
R2 EQU 2
R3 EQU 3 * Number of times to loop
R4 EQU 4
R5 EQU 5
R6 EQU 6
R7 EQU 7
R8 EQU 8
R9 EQU 9
R10 EQU 10
R11 EQU 11
R12 EQU 12 * Base Register
R13 EQU 13
R14 EQU 14
R15 EQU 15
*
SYSIN2 CSECT
STM R14,R12,12(R13)
LR R12,R15
USING SYSIN2,12
*
ST R13,SaveArea+4
LA R0,SaveArea
ST R0,8(R13)
LA R13,SaveArea
*
OPEN (SYSIN,(INPUT))
OPEN (SYSOUT,(OUTPUT))
LA R3,3 Number of times to read SYSIN
*
GETAGAIN DS 0H
GET SYSIN,INREC Read the next rec
PUT SYSOUT,INREC Write that bad boy out
B GETAGAIN
FINISH DS 0H Invoked at End of Data of SYSIN
CLOSE (SYSIN,REWIND) Close SYSIN and rewind
OPEN (SYSIN,(INPUT)) Open it up again
BCT R3,GETAGAIN Repeat the madness
*
CLOSE SYSIN
CLOSE SYSOUT
*
L R13,SaveArea+4
LM R14,R12,12(R13)
XR R15,R15
BR R14
*
SYSIN DCB DSORG=PS,MACRF=(GM),DDNAME=SYSIN,EODAD=FINISH, *
RECFM=FB,LRECL=80,BLKSIZE=0
SYSOUT DCB DSORG=PS,MACRF=(PM),DDNAME=SYSOUT, *
RECFM=FBA,LRECL=133,BLKSIZE=0
*
INREC DC CL132' '
SaveArea DS 18F
LTORG
END
Assemble the above and execute this JCL
//SYSIN2 JOB (CCCCCCCC),'HOGSTROM',
// MSGLEVEL=(1,1),
// MSGCLASS=O,
// CLASS=A,
// NOTIFY=&SYSUID
//*
//STEP1 EXEC PGM=SYSIN2
//STEPLIB DD DSN=USER1.TEST.LOADLIB,DISP=SHR
//*
//SYSIN DD *
REC 1 OF 3
REC 2 OF 3
REC 3 OF 3
/*
//SYSOUT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
And you'll get this output
You'll see the same SYSIN data repeated three times.
For a 'C' program this reference in the IBM documentation for the C Compiler provides some hints about rewinding.
To open an in-stream data set, call the fopen() or freopen() library
function and specify the ddname of the data set. You can open an
in-stream data set only for reading. Specifying any of the update,
write, or append modes fails. Once you have opened an in-stream data
set, you cannot acquire or change the file position except by
rewinding. This means that calls to the fseek(), ftell(), fgetpos(),
and fsetpos() for in-stream data sets fail. Calling rewind() causes
z/OS XL C/C++ to reopen the file, leaving the file position at the
beginning.
What you're looking for is possible but the implementation is language dependent.

why the number of vector of INT0 is 1 not 2 as datasheet?

I am using an ATmega32 to do interrupt
when i trying to do driver of external interrupt 0 , faced me a problem
Interrupt Vectors Table in ATmega32
Interrupt Vectors code in ISR(vector)
In iom32.h code , we see that ((INT0_vect " _VECTOR(1) ")) it's number 1 but in data sheet we see that the number is 2 , why ?
The datasheet starts numbering with the reset vector. But there is no need for an explicit define (like RESET_vect) for the reset vector, since it will not be used in conjunction with ISR(). So in the header/AVRGCC implementation it is omitted.
If you compile this
ISR(INT0_vect) { }
and look at the interrupt vector table
00000000 <__vectors>:
0: 0c 94 46 00 jmp 0x8c ; 0x8c <__ctors_end>
4: 0c 94 5f 00 jmp 0xbe ; 0xbe <__vector_1>
you can see that __vector_1 is placed at byte address 4, which corresponds to the word address 2 from the data sheet.

Format of 64 bit symbol table entry in ELF

So I am trying to learn about the ELF by taking a close look how everything relates and can't understand why the symbol table entries are the size they are.
When I run readelf -W -S tiny.o I get:
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 0] NULL 0000000000000000 000000 000000 00 0 0 0
[ 1] .bss NOBITS 0000000000000000 000200 000001 00 WA 0 0 4
[ 2] .text PROGBITS 0000000000000000 000200 00002a 00 AX 0 0 16
[ 3] .shstrtab STRTAB 0000000000000000 000230 000031 00 0 0 1
[ 4] .symtab SYMTAB 0000000000000000 000270 000090 18 5 5 4
[ 5] .strtab STRTAB 0000000000000000 000300 000015 00 0 0 1
[ 6] .rela.text RELA 0000000000000000 000320 000030 18 4 2 4
Which shows the symbol table having 0x18 or 24 bytes per entry and a total size of (0x300-0x270) or 0x90 giving us 6 entries.
This matches with what readelf -W -s tiny.o says:
Symbol table '.symtab' contains 6 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FILE LOCAL DEFAULT ABS tiny.asm
2: 0000000000000000 0 SECTION LOCAL DEFAULT 1
3: 0000000000000000 0 SECTION LOCAL DEFAULT 2
4: 0000000000000000 0 NOTYPE LOCAL DEFAULT 1 str
5: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 2 _start
So clearly the 24 bytes size is correct, but that would correspond to a 32 bit table entry as decribed in this 32 bit spec.
Given that I am on a 64 bit system and the ELF file is 64 bit I would expect the entry to be as decribed in this 64 bit spec.
Upon looking at a hex dump of the file, I found that the layout of the fields in the file seems to be according to this 64 bit pattern.
So then why is the ELF file seemingly using undersized symbol table entries despite using the 64 bit layout and being a 64 bit file?
So then why is the ELF file seemingly using undersized symbol table entries
What makes you believe they are undersized?
In Elf64_Sym, we have:
int st_name
char st_info
char st_other
short st_shndx
<--- 8 bytes
long st_value
<--- 8 bytes
long st_size
<--- 8 bytes.
That's 24 bytes total, exactly as you'd expect.
To convince yourself that everything is in order, compile this program:
#include <elf.h>
#include <stdio.h>
int main()
{
Elf64_Sym s64;
Elf32_Sym s32;
printf("%zu %zu\n", sizeof(s32), sizeof(s64));
return 0;
}
Running it produces 16 24. You can also run it under GDB, and look at offsets of various fields, e.g.
(gdb) p (char*)&s64.st_value - (char*)&s64
$1 = 8
(gdb) p (char*)&s64.st_size - (char*)&s64
$2 = 16

Code Warrior Assembly code

I need some advice with a small program for school. If you could just point me in the right direction I would really appreciate it. I am using CodeWarrior coding in assembly language for the TWR-S12G128 Processor Module. My goal is to get the LEDs turn on and off with a delay of 1 second. Here is what my code looks like:
LDS #$4000 ; Initializing SP
LDAA #$FF
STAA DDRA ; Defines Port A as output
Back LDAA #$FF
STAA PORTA ; Turning all LEDs ON
JSR Delay
LDAA #$00
STAA PORTA ; Turning all LEDs OFF
JSR Delay
BSR Back
Delay PSHX ; 2-clock cycle
PSHY ; 2
LDY #20 ; 2-clock cycle
LOOP1 LDX #$FFFF ; 2
LOOP2 DEX ; 1-clock cycle
NOP ; 1-clock cycle
BNE LOOP2 ; 3-clock cycles/last cycle is 1
DEY ; 1
BNE $FF ; 3-clock cycles/last cycle is 1
PULY LOOP1 ; 3-clock cycle
PULX ; 3-clock cycle
RTS ; 5-clock cycle
There error that I am getting is :
Error : A2400: End of Line expected
main.asm line 58
Project: Project_4.mcp, Target: Standard, Source File: main.asm
Error : Compile failed
Project: Project_4.mcp, Target: Standard, Source File: main.asm
I don't know a great deal about the Freescale architecture but it's very unusual for any architecture to combine a pull instruction with a label.
The bne $ff is also unusual since that does normally specify a label.
I would be thinking that those two instructions should be more along the lines of:
bne loop1
puly
That makes more sense in that the pull instruction loses the label and the nested loops are properly constructed.
The $FF on the BNE line is not proper. I think it's a typo. I just worked this out with my professor a few hours ago. Here is the code that will give you the 1 second delay and continuously cycle the 4 LEDs on and off:
ABSENTRY Entry ; Application entry point
RAMStart EQU $2000
ROMStart EQU $C000
ORG RAMStart
; Insert here your data definition.
PTT EQU $240
DDRT EQU $242
; code section
ORG ROMStart
Entry:
_Startup:
LDS #$4000
Back LDAA #$FF
STAA DDRT
LDAA #$FF
STAA PTT
JSR Delay
LDAA #$00
STAA PTT
JSR Delay
BSR Back
Delay PSHX ; 2-clock cycle
PSHY ; 2
LDY #20 ; 2-clock cycle
LOOP1 LDX #$FFFF ; 2
LOOP2 DEX ; 1-clock cycle
NOP ; 1-clock cycle
BNE LOOP2 ; 3-clock cycles/last cycle is 1
DEY ; 1
BNE LOOP1 ; 3-clock cycles/last cycle is 1
PULY ; 3-clock cycle
PULX ; 3-clock cycle
RTS ; 5-clock cycle
ORG $FFFE
DC.W Entry ; Reset Vector
If someone would be so kind as to help me with the math. I get the 65,535 * 20 for the loops, but with the 6.25MHz clock, I end up getting .209 secs as the final amount for the delay, but I know it's suppose to be 1 sec. What am I not seeing?

how to create two separate segments in Global Descriptor Table

I have gone through the basics of Global Descriptor Table (GDT) and i have successfully written a "GDT.inc" using asm , so that we can easily include it in our bootloader. As a baby step i have configured the Code Descriptor and Data Descriptor to read and write from the first byte to byte 0xFFFFFFFF in memory (any portion in memory)
; null descriptor
dd 0 ; null descriptor--just fill 8 bytes with zero
dd 0
; code descriptor: ; code descriptor. Right after null descriptor
dw 0FFFFh ; limit low
dw 0 ; base low
db 0 ; base middle
db 10011010b ; access
db 11001111b ; granularity
db 0 ; base high
; data descriptor: ; data descriptor
dw 0FFFFh ; limit low (Same as code)
dw 0 ; base low
db 0 ; base middle
db 10010010b ; access
db 11001111b ; granularity
db 0 ; base high
Now my purpose is to create two separate regions using GDT .For example , first 512B as one region and next 512B as another region and leaving the space left as unused.
What can i do for that ?
you can just change where your base address & limit registers .
so in the example you gave
for code descriptor
.base = 0x0
.limit = 0x200 //512 byte
for data descriptor
.base = 0x200
.limit = 0x200
then you have the rest of your memory after the 1 KB empty
you can check "http://wiki.osdev.org/GDT_Tutorial" for more explanation