OSDev.org

Hi,
i tried to convert MiniDOS's (from Dex) code to Pascal for use to my OS (REAL MODE) - it is a code that will run programs on floppy diskette. I got a strange thing when using this function, Bochs 2.3 panics with this:

00044745494p[CPU0 ] >>PANIC<< prefetch: getHostMemAddr vetoed direct read, pAddr=0x000af9ff

What is this ? I REALLY DON'T KNOW what to do now. It is Dex's code, I just translated it to Pascal...

Here is the unit:
http://inflater.ic.cz/POS_FLS.PAS
I use only ConvertFileName and ExecFile functions...

Here is the "function-run" code I use:
I am feeling really lazy when I am asking you something but I don't know the workaround for this problem... :(

inflater

Okay, I don't know Pascal and can therefore only point you in the right direction, sorry.

Searching the Bochs source points to here: cpu/cpu.cc: lines 773 to 785.

I've had a read of the sourcecode of that and the getHostMemAddr member function. From what I can see (in the Bochs source code - not yours), it looks like somewhere you're trying to read from IO mapped VGA memory (0x9FFFF to 0xC0000 according to the Bochs source code)

EDIT: Fixed little thing unrelated to technical side.

@inflater, First ask yourself does MiniDos work fine in BOCHS, answer Yes.
Does your converted to pascal work fine, answer No.
Meaning you have made a mistake in your converting it, its no uses say its not my code, you need to understand both pascal (or in this case tasm) and fasm to convert it right.
There lots of things in tasm (as used by turbo pascal) that mean totally differant things in fasm.

And lot of this suff can be written in pascal instead of inline, but first you need to know whats going on.
Bascally it takes a name as written in a cli and converts it to as it is written in a Dir entry in a fat file sys.
Which is :
CLI = "hello.com"
Dir entry ="HELLO COM"
You need to do this in pascal.

I/O mapped VGA memory ?! My god...

inflater

inflater wrote:I/O mapped VGA memory ?! My god...

inflater

I/O mapped simply means (this is a non technical description because I'm not wholly certain just how it works) that a certain area of memory is reserved for usage for interaction with I/O devices - in this case the VGA (Video Graphics Array) controller. More likely this isn't a specifically VGA adaptor - I dunno if you could even find one of them any more - but the idea here is the same (when it comes to using I/O ports to program it, more recent VESA controllers and things can emulate old VGA cards, I believe).

Hi,

Midas wrote:From what I can see (in the Bochs source code - not yours), it looks like somewhere you're trying to read from IO mapped VGA memory (0x9FFFF to 0xC0000 according to the Bochs source code)

You're right, but this code (in Bochs) is the instruction prefetch code. I would expect that the CPU dump (in the Bochs log) would say that the panic occured when CS:IP = 0x000AF9FF (e.g. CS = 0xA000 and IP = 0xF9FF, or some other combination that adds up to the same address).

Basically, it looks like Inflator was trying to execute code from VGA display memory. This sort of thing can be caused by trashing the stack (e.g. some code that pushes 3 things onto the stack and pops 2 or 4), so that "ret" sends the CPU to the wrong place. There's a lot of different bugs that could cause it to happen though....

@Inflator: Try inserting infinite loops in your code (e.g. "JMP $"). If Bochs reaches the infinite loop you know the bug is after the loop, and if it panics instead you know the bug is before the infinite loop. Keep shifting the infinite loop until you know roughly where the bug is. Then, just before the bug add the following:
Start Bochs with the internal debugger enabled (and type in "c" to get it running). When Bochs gets to this code it'll wait for CX to change. Now press "control + C" to stop Bochs and return to the debugger. Then type in "set cx=1" (or "set $cx=1" for an old version of Bochs). This changes CX and lets Bochs continue. Now you can "single-step" through the code by typing in "s", you can view the contents of the CPU's registers by doing "info r" or "dump_cpu" and see what is in memory with "x /<length> <address>". Basically, you can watch Bochs do each instruction one by one and see exactly what happens at each step...


Cheers,

Brendan

Well, I found somehow the problem:
The file executing routine fails after RETF.

Next at t=99387821
(0) [0x00003457] 0337:00e7 (unk. ctxt): xor bx, bx
<bochs:37>
Next at t=99387822
(0) [0x00003459] 0337:00e9 (unk. ctxt): retf
<bochs:38>
Next at t=99387823
(0) [0x000af9ff] 9fa0:ffff (unk. ctxt): (invalid)

This seems like incorrectly converted file name to execute, and that incorrect converting will point to some curious segment 9FA0...

//EDIT:
It is not in name. I also tried this, this is without conversion:
It is in code then...

inflater

First i have forgot all i new about pascal, but here looks like a problem
"rootconvertedfilename"
In your code it looks like a byte size var. In my code it much bigger (20 bytes)

The DB stands for "DEFINE BYTE". So I changed

rootconvertedfilename: byte

to

rootconvertedfilename: array[0..20] of byte;

which wont work too. I think the error is in file-executing code, not the converting routine.

inflater

inflater wrote:
rootconvertedfilename: array[0..20] of byte;

not sure about the other possible issues and don't use Pascal, but this looks suspect to me - should it be array[0..19] if you want 20 elements

Adam

I tried that

rootconvertedfilename: array[0..19] of byte

and still no luck.
I think that the error is in EXECUTING code, not the converting routine OR data types.
But I cant find it...

inflater