Auto Boot Sector Code

[elliot]

Was there ever any formal method to roll out code to the boot sector of a floppy?

I disassembled some boot sectors and played around with them (but it was very low level, HEX level stuff), I would push them back to the floppy using something like KnifeST.

Was there ever a way to assemble code in say Devpac with the target being Boot Sector? How would you push to a floppy?

[saulot]

Well I haven't seen anything 'formal'. I've got one sample, but comments are are in polish (I could translate it, I wrote it like 21 years ago ). I can send you if you are interested. In one source you have bootsector code of your program and small routine which writes it to a bootsector(calculates crc etc). There are limitations of course in program size(510 bytes).
Bootsector is written via flopwr()..

[metalages]

In devpack you have to assemble as a program. Ensure it does not exceed 510 bytes.
I think the code need to be pc relative code.

Compute the last word in order to have the checksum of the content of the bootsector to be $1234 (it tells the OS that the bootsector is executable)
Write the resulting content in the bootsector of the floppy. In my toolchain, this job is assumed by the tool composing the floppy image https://github.com/jhubrt/demOS/tree/ma ... OLS/IMAGER

I have a boot sector .S code there https://github.com/jhubrt/demOS/blob/ma ... BOOTSTRA.S
It loads a program from the floppy using xbios, then unpack (arj4), then run the program prividing him something like a fake basepage
(the program I run is compiled with Pure C).

[joska]

Was there ever a way to assemble code in say Devpac with the target being Boot Sector? How would you push to a floppy?

Unfortunately I think the sources are lost, but back when I did this (for some reason I loved to create those annoying "This disk is virus free" bootsectors in the late 80's) I did it like this (pseudocode):

Code: Select all

read bootsector to buffer
copy code to free area in the bootsector buffer
write offset to code in the first word in the bootsector buffer
calculate checksum and write to last word in the buffer
write buffer to bootsector
end

code:
	pc relative bootsector code.

So both the code that wrote the bootsector and the bootsector code itself is in the same program. I used Devpac and wrote everything in assembler, but using e.g. PureC instead would work fine. It would still be sensible to write the bootsector code itself in assembly though, as space is very limited.

If the disk doesn't have to be readable by GEMDOS you can use the entire bootsector (except for the first and last word) for your code. In my case I just wanted to show off by displaying some "hardcore" message when booting an otherwise ordinary disk, so the code has to be located in the free area in the bootsector. You can find more information on how this works here: https://info-coach.fr/atari/software/FD-Soft.php

[Mug UK]

I always used the same shell that a mate wrote way back in the midsts of 1988 and then I improved as I added more features to it.

I used Devpac to test out the bootsector code and making sure it was assembling OK and under the size (I think I kept mine to less than 488 bytes).

Once happy, I copied the installer code to a new file name and then inserted the working code at the end. This assembled a program that allowed the user to install the bootsector to disk A or disk B.

There's loads of olde worlde examples in this single .ZIP file, most of them include the installer routine.

[simonsunnyboy]

Ages ago I got a sample code by Grazey/PHF which implements a shell to apply a given bootsector.
It should be good enough to show the principles.

Code: Select all

	; bootsector example derived from Grazey/PHF
	; write your own bootcode between bootcode and bootcode_end

gemdos equ 1
xbios equ 14
bios equ 13

text

; init program
go:	move.l sp,a5
	lea stackend,sp

; calculate program and data size for TOS - to free unused space
	movea.l 4(a5),a5	; a5 points 100bytes below program start
	move.l $c(a5),d0
	add.l $14(a5),d0
	add.l $1c(a5),d0
	add.l #$100,d0
	move.l d0,-(sp)
	move.l a5,-(sp)
	move.w #0,-(sp)
	move.w #$4a,-(sp)
	trap #gemdos		; SETBLOCK Gemdos
	add.l #12,sp		; correct stack
	tst.l d0
	bne exit		; error occured? -> go to error
	
; -------------------------
; main program entry point:
; -------------------------
main:

	pea my_palette
	move.w #$26,-(sp)
	trap #xbios
	addq.l #6,sp


; print banner...
	pea banner
	move.w #9,-(sp)
	trap #gemdos
	addq.l #6,sp

; wait for keypress 'w' or 'q'
press_w:
	move.w #8,-(sp)
	trap #gemdos
	addq.l #2,sp
	
	; w pressed? - then write the bootblock...
	cmpi #'w',d0
	beq read_boot
	cmpi #'W',d0
	beq read_boot
	; Q pressed? - then terminate program...
	cmpi #'q',d0
	beq exit
	cmpi #'Q',d0
	beq exit
	cmpi #'t',d0
	beq testboot
	cmpi #'T',d0
	beq testboot
	
	; neither w nor q? - then get another keypress	
	bra press_w

; read old bootblock from disk including BPB
read_boot:
	moveq.w #8,d0
	bsr rw_boot


;  transfer bootcode to buffer...
transfer_boot:
off:	equ $1a
	move.l #bootcode,a0
	move.w #(bootcode_end-bootcode)/2,d0
	move.l #boots+off+2,a1
.loop	move.w (a0)+,(a1)+
	dbf d0,.loop
	move.w #$6000+off,boots
	
; calculate checksum to make bootcode executable on disk...	
make_exec:
	move.l #$00000001ffffffff,-(sp)
	move.l #-1,-(sp)
	move.l #boots,-(sp)
	move.w #18,-(sp)
	trap #14
	lea.l 14(sp),sp		
	move.w d0,checksum


; write bootcode to disk....
write_boot:
	moveq.w #9,d0
	bsr rw_boot
	
	
	; and return to program start....
	jmp main
	
	; test bootcode routine
testboot:
	; run bootsector routine in supervisor
	pea bootcode
	move.w #$26,-(sp)
	trap #xbios
	addq.l #6,sp
	
	move.w #8,-(sp)
	trap #gemdos
	addq.l #2,sp
	jmp main
		
	
; terminate program properly and return to desktop or shell...	
exit:	clr.l -(sp)
	trap #gemdos	; TERM PROCESS Gemdos

;------------------------
; SUBROUTINES/ FUNCTIONS
;------------------------

; subroutine reads and writes bootcode from disk
; to/from buffer
rw_boot:
	move.w #1,-(sp)
	move.l #0,-(sp)
	move.w #1,-(sp)
	move.w #0,-(sp)
	clr.l -(sp)
	move.l #boots,-(sp)
	move.w d0,-(sp)
	trap #14
	lea.l 20(sp),sp
	rts
	
	; gets called in SUPER
my_palette:
	move.w #$777,$FFFF8240.w
	move.w #$000,$FFFF825E.w
	rts

;-----------------------------------
data
; initialisierte Daten hier...
banner: dc.b 27,"b",15,27,"E",27,"p"
	dc.b "-------------------",13,10
	dc.b "Bootblock installer",13,10
	dc.b "-------------------",13,10
	dc.b 13,10
	dc.b 13,10,13,10
	dc.b 13,10,10
	dc.b "Please insert your disk in drive A and",13,10
	dc.b "press 'w' to write a new bootsector.",13,10,13,10
	dc.b "REMOVE WRITE PROTECTION TAB!",13,10,13,10,13,10
	dc.b "Press 'q' to return to the desktop.",13,10,0
	
	even

boots:	ds.b 510
checksum:	ds.b 2

	even

bootcode:
	; all bootsector code (PC-relative) must goi between her, max. size ~410 bytes)
bootcode_end:	dc.b 0

; BOOTSECTOR CODE END
;
; stack
stkstart: 	ds.l 256
stackend:	ds.l 1	

[elliot]

Okay so you could "assemble", cool.

If the disk doesn't have to be readable by GEMDOS you can use the entire bootsector (except for the first and last word) for your code.

Okay I knew there was a limit but how does this work, how many bytes were loaded by (I assume) TOS on boot?

[Greenious]

Okay so you could "assemble", cool.

If the disk doesn't have to be readable by GEMDOS you can use the entire bootsector (except for the first and last word) for your code.

Okay I knew there was a limit but how does this work, how many bytes were loaded by (I assume) TOS on boot?

Every sector on a standard floppy is 512 bytes, but the boot sector is special, as it also contains data that defines the format of the disk and the adress to the root directory. If I remember correctly, 488 450 bytes is available for code if you want to keep that info and have a disk you can use as a regular disk aswell.

If you want to use the whole bootsector for code, it will not read correctly in GEMDOS and/or show a directory that seems scrambled beyond repair.

[elliot]

Okay so I did not take the info in right. So effectively if you do not want the FAT info then your boot code could be 512 (prob less a handful of header bytes). I read it like you could string a few sectors together or something.

What if (and really speculating) you formatted track one as only having one sector of 4,608 or 5120 bytes? Would this work?

I seem to remember Golden Axe if you examined the disk only track one was readable BUT I do not know how many sectors that track had.

[Greenious]

This is from memory, so I may be wrong, but the WD1772 can only handle 256 bytes, 512 bytes and 1024 bytes sectors.

Second, even if TOS could read a 1024 byte sector at boot, and I don't think it can, it would only read 512 bytes of it.

But this is from memory, and it was like 30 years ago I played with boot sectors...

[atari_mark]

Jumping on the bandwagon, attached is a POV boot loader I wrote. The version uploaded has two parts, I grab part of a pic and save it as pov.dat file using the Steal.s code. Run pov_boot.s to load the file, read the old boot sector and write the new one. Just change the code in 'mycode' section to whatever you want.

POVBOOT.zip

[joska]

Okay I knew there was a limit but how does this work, how many bytes were loaded by (I assume) TOS on boot?

As others have already pointed out, the boot sector is 512 bytes and all of those will be loaded. Program exection starts at the first word if the word checksum of the bootsector is $1234. So you will need to reserve one word for a checksum, whose value would be $1234 minus the checksum of the other 255 words in the bootsector. If you're using the entire bootsector this word can be placed anywhere but you will need to calculate it yourself.

If you have a GEMDOS-compatible bootsector the boot code is located at offset 58, and can be up to 450 bytes. Execution starts with the first word of the bootsector, but since there's 56 bytes of data immediately after the first word, the first word must be a BRA.S instruction to the actual bootsector code. The last word of the bootsector contains the checksum, when you have a GEMDOS compatible bootsector this will be calculated by the XBIOS function Protobt. Or you can calculate it yourself.

[elliot]

Yes I remember the boot sectors with code had the first instruction being a jump.

I was more wondering if there was a legitimate method to assemble and write to the boot sector in any software, as I say, the only method I know was to assemble and then "hack" a write to the boot sector. In fact I never even managed to assemble! I wrote in HEX and to be honest I just adjusted other people's code.

[ThorstenOtto]

I guess you always need some custom tool. You can use an assembler for the actual code, but then have to "inject" that into some template with the parameter block for GEMDOS (if you want the disk to be also readable by TOS), and calculate the checksum.