OSDev.org

requimrar wrote:I just set BX to 0 and everything worked. I don't know how or why you managed to get my posted code working, but either way thanks for all your help.

Don't stop there - if changing BX from 7 to 0 makes it work and changing it back to 7 stops it working, there's something else wrong, though I suppose it could be a BIOS bug. That would be worth exploring further, and the same applies to finding out why your attempt to print directly to the screen failed.

One thing's still puzzling me though - how does "mov si, msg" generate the right address to go with DS=0 when the code all follows "ORG 0x7C00"? What's the point of an org directive if it's just ignored when addresses are calculated?

@DavidCooper: will actually get assembled as

DavidCooper wrote:One thing's still puzzling me though - how does "mov si, msg" generate the right address to go with DS=0 when the code all follows "ORG 0x7C00"? What's the point of an org directive if it's just ignored when addresses are calculated?

ORG 0x7C00 says "Start the address counter at 0x7C00"

So when DS is loaded with 0 as in the code above, shouldn't that mean it'll hunt for "msg" in amongst the interrupt vectors at the bottom of memory instead of somewhere a little up from 7C00? That's the bit I don't understand - how can the code be working?

Edit: No, wait - I've misread what you said. It adds 7C00 to the address and creates the right address for SI to go with DS=0. But If you were to use ORG 0x18000 (half way up the next block of 64K in memory), it couldn't add 18000 to SI and get an address to reach it with DS=0, so do you always have to set DS to the bottom of the 64K block in which the variable you're trying to line up on resides?

The reason I'm asking about this is that I'm trying to understand why Requimrar's removal of
made the code semi-work (while including it prevented it from doing so).

I don't get what you mean by VBR.

For reference, a VBR (Volume Boot Record) is what you have in the first post. It is started by either the BIOS or MBR or chainloaded by another boot loader. It is also sometimes known as "stage 1" although I personally prefer the term VBR.

It is that you have attempted to write directly to display and failed that got my attention into thinking the problem may not be what you think. It would be interesting if given the above changes to see if you can now print to display directly.

Nable wrote:to Blacklight
AFAIK, `mov to ss' blocks interrupts for the one next instruction automatically, so, you don't need cli/sti when setting up your stack.
For example, see IASDM vol3, chapter 21.4.2, table 21-3, row 2.

Good to know for future reference, thanks!

EDIT: Seems I missed a couple posts.

DavidCooper wrote:so do you always have to set DS to the bottom of the 64K block in which the variable you're trying to line up on resides?

If your code is loaded at 1234h:5678h , then you'll want your DS in most cases to be 1234h, and often your org to be 5678h. ORG just tells your assembler what base address to add to labels in order to calculate absolute addresses.

DavidCooper wrote:The reason I'm asking about this is that I'm trying to understand why Requimrar's removal of

Code: Select all

   xor ax, ax
   mov ds, ax
   mov es, ax

made the code semi-work (while including it prevented it from doing so).

It shouldn't if ORG is 7C00h, unless the BIOS already sets CS/DS/ES to 0 (which it seems that many do). However, reloading them should by all means logically not break the code.

Thanks Blacklight, Combuster and Owen for fixing my misunderstanding of what org directives actually do - you can see now why I've always depended so much on seeing the hex to understand what's going on in other people's code. Anyway, it looks as if Requimrar must have done something else in addition to commenting out the segment setting code to get it to print a letter as setting the segments to 0 can't have have had any role in stopping it working (although it could have prevented it from failing). The change of BX=7 to BX=0 likewise shouldn't have made the difference it was reported to have made. I suspect he's been making multiple changes and only telling us about one each time, giving us a misleading impression of what's causing/fixing the problems. Either that or there are some very strange things going on which really need to be investigated further (by experimentation) to ensure that the same weird bugs don't return to catch him out again.