[SOLVED] 2 files with floppy image

[neon]

Hello,

m12:

The org directive only specifies a linear starting offset. That is, it specifies a starting offset within some segment (in this case, 0:7c00) which is the same linear address of 0x7c0:0. Also thanks for the feedback on the series.

feare56:

Right; the VBR should display output on error (and during loading) provided it is being properly executed by the environment. The lack of output and the output of the provided image tells us the problem lies within the environment configuration, invalid image, or, if the VBR is being executed, possible error in the software or on-disk filesystem structure. It is easy enough to check if the VBR is being executed by just calling Print with some small test string at the start of the VBR (right after Main). I suspect that the VBR isn't getting executed though but recommend to check. Also recommend to make the change suggested in my previous post as that could break if the assembler assembles jmp Main as a short jump rather then far jump.

Please try these two suggestions and let us know what happens.

[Prochamber]

since my internet isn't letting me upload the files i will give you the code from both.

Just use pastebin.
You probably shouldn't trust that sectors per track is constant, BIOS may be using different geometry. Fetch this with BIOS interrupt 13h function 08h.
Also, what's with this:

Code: Select all

TIMES 0Bh-$+start DB 0

bpbOEM db "Flow OS "

You just wrote zero bytes over the OEM identifier then wrote one after that.
Remove the first line and you may produce a BPB.

so you first overwrite the ivt, then disable interrupts, then call an interrupt?

Actually this isn't a problem, the second stage was loaded at 0x0050:0000, which is 0x00500, this first byte of free conventional memory and 'CLI' disables hardware interrupts not software interrupts so there is no problem with INT 10h. However this might be a problem for INT 13h which likely relies on hardware interrupts and it may lockup the system without them.

[Mikemk]

'CLI' disables hardware interrupts not software interrupts

I actually didn't know this.

[feare56]

@neon: Looks like the problem is in main.

@Prochamber: Yea I forgot to remove it and had to as it gave me a times is -2 error

[neon]

Hello,

I am still concerned about the environment displaying Booting from Hard Disk. Are you absolutely sure the environment is properly treating the image as a floppy image?

The series VBR uses org 0 rather then org 0x7c00. This allows us to set the segment registers to 0x7c0 and offset properly without concern of the initial origin. There appears to be some differences between the series VBR and the VBR provided in this thread. We encourage using org 0 to minimize possible errors, and to properly set the segments to 0x7c0 not 0x7c00.

That is,

Code: Select all

org 0
...

Main:
   cli
   mov ax, 0x7c0
   mov ds, ax
   mov es, ax
   mov fs, ax
   mov gs, ax

...

If you rather stick with org 0x7c00 then the segment registers must be set to 0 instead. Please try one of these two changes and let us know if there are any additional errors. Regarding the use of CLI, it is recommended to disable hardware interrupts when modifying the segment registers and more importantly, the kernel mode stack.

[feare56]

Ok i mannaged to get "Loading boot image" on the screen. Except I don't know if this is a problem.

Code: Select all

org 0x0001
bits 16

Start: jmp Main

Now it is not loading stage2. As for the Hard Disk on the screen I don't really know if it is truley booting it as a floppy

[neon]

Hello,

Based on the provided code, I suspect not all of the requested changes have been made yet. Please be sure to make the following changes in order to avoid future errors with the VBR. (If you have already made a change then it can be disregarded.)

1. Use bpbOEM db "MSWIN4.1". Not doing so may cause some compatibility issues with some systems.
2. Use jmp short Main ... nop instead of just jmp Main. Not doing may cause triple fault if its assembled as a short jump. The BPB must be 3 bytes from start of image.
3. Do not use org 1. Stick with org 0 with all segments set to 0x7c0 (including CS.) This will simplify the code and also possibly fix your off-by-1 display error.

Unfortunately we cannot address if there is an error with the VBR during loading of the stage2 file without knowing if it is being treated as a proper floppy image. The software will only work for floppies due to its use of CHS and standard INT 13h services. (However if you do want to use hard disk, we do provide fat16 and fat32 hard disk VBR's that you can try.)

[Prochamber]

Using 'jmp short Main' then 'nop' will not work since your 'Main' section is out of range of a short jump. I recommend that you move your main section or have your initial short jump (2 byte) lead to another standard (3 byte) jump instruction. i.e.

Code: Select all

jmp short ToMain
nop
(BPB values)
ToMain: jmp Main

[feare56]

Ok with a bit of work I have finally got it to boot and display it as a floppy!!

[feare56]

Thank you guys especially you neon

[Mikemk]

Ok with a bit of work I have finally got it to boot and display it as a floppy!!

Good job.

On another note, though, it may be a good idea to keep it as a hard drive, since floppies are outdated, and you actually have a chance of people running your os on real hardware with a hard drive.

[Combuster]

and you actually have a chance of people running your os on real hardware with a hard drive.

Are you sure? I have too much old equipment where floppies are still the most effective test cycle.

[Mikemk]

and you actually have a chance of people running your os on real hardware with a hard drive.

Are you sure? I have too much old equipment where floppies are still the most effective test cycle.

Yes, but the majority of users (myself included) can only afford one or two computers and don't want to pay for floppies. If you first work on hard drive support, then later add floppies and SSD, more people will be able to run your os, and therefore you have a higher chance of success.

Just my opinion and 2¢.

[JAAman]

1. Use bpbOEM db "MSWIN4.1". Not doing so may cause some compatibility issues with some systems.

this is only true if you are running some small 3rd party OS which uses a FAT driver which clearly ignores the FAT specification (no MS FAT driver has ever been released to the public which does this check)

in fact, only retail copies of win98 set bpb.OEM = "MSWIN4.1"
win95 default retail sets this to "MSWIN4.0", retail versions of DOS set this to "MSDOSx.x", computers sold with windows/DOS pre-installed set this to the name of the system builder (if you buy a win98 system from DELL, this string is "DELL" if you buy it from gateway its "GATEWAY" etc)

my default install of winXP (PRO-OEM-no vender information set) sets this to a random string of characters

therefore, any driver which perform this check, would be incompatible with any disk formatted with any version of windows or DOS other than win98 (and incompatible with disks formatted with some copies of win98 as well)

[Mikemk]

therefore, any driver which perform this check, would be incompatible with any disk formatted with any version of windows or DOS other than win98 (and incompatible with disks formatted with some copies of win98 as well)

So does this mean we need to cause more compatibility issues by setting it randomly?