Tornado64 x86 emulator

[Geri]

Ahem...

You may want to consider doing what Bochs does, which is build two separate .exe's, one which has the debugger, but is slower, and one that does not and is faster.

But I would definitely use the debugger if it displayed values in hexadecimal, and had breakpoints.

yeah, maybe having two separate exe would be a good idea.

Speaking of which, I'm still trying to figure out why I can't boot from floppy disk image. I think it may have something to do with the fact that I'm switching to 32-bit mode first, and then trying to send commands directly to the FDC controller (0x03f5), instead of going through the 16-bit BIOS calls.

...

Anyway, should this direct FDC controller access be working in the current version that is located at the link above?

the bios also wraps to 0x3f5 so the port itself should be fine.
are you trying to write value 2 (read whole track) command?

thats unimplemented.

if this is the problem, if you tell me, how that mode works, i implement it (becouse i never heard from this)

also i remember fixing an error with floppy read or write, but i dont know if its included in the version or not.

For instance, when I send the GetVersion command (0x10), and then read back the results, I'm getting 0xFF, where on (almost) all other emulators and hardware, I'm getting 0x90. (VMWare returns 0x81... wtf?)

i have no idea, what is that command, or how you try to acess it. i dont have such thing implemented.

Thanks. Keep up the good work.

thankyou for sending this lot of bugreports. you making my emulator better.

[Geri]

i have no idea, what is that command, or how you try to acess it. i dont have such thing implemented.

oh, wait, i have it implemented.
you try to request it with 0x0E and then load it from port 3f5?

[Geri]

it seems i dont have 32 bit support for the floppy drive, and even partial for 16 bit port access.
if you send me your floppy image, i can debug the issue.

[SpyderTL]

i have no idea, what is that command, or how you try to acess it. i dont have such thing implemented.

oh, wait, i have it implemented.
you try to request it with 0x0E and then load it from port 3f5?

Details on the Version FDC command are on the FDC page.

Code: Select all

Version
Returns one byte. If the value is 0x90, the floppy controller is a 82077AA.
Version command = 0x10
No parameter bytes.
No interrupt.
First result byte = 0x90

[SpyderTL]

it seems i dont have 32 bit support for the floppy drive, and even partial for 16 bit port access.
if you send me your floppy image, i can debug the issue.

Bootable floppy image can be downloaded from http://ozone.codeplex.com

You should get a command prompt. You can hit TAB to get a list of static classes that can be used as commands.

[SpyderTL]

the bios also wraps to 0x3f5 so the port itself should be fine.
are you trying to write value 2 (read whole track) command?

I'm sending a Read Data (0x06) command, or'd with the MFM mode flag (0x40). So, um, 0x46 is what I'm sending.

I just realized that I'm also using DMA to transfer data, rather than PIO (polling). That may actually be the problem.

I may try switching back to PIO mode just for testing purposes...

Thanks.

[Geri]

the only 32-bit wide port write i recive is your PCI queries (or is that from the bios maybe)

[Geri]

ok, i debugged it

i get the folowing op on write ports:
70 (0x46???? what is that?)

0 (wtf?)
0 (wtf?)
0 (wtf?)
2 (read whole TRACK?)

i guess this last 4 is the parameter you want to give, and the 0x46 is the code of your operation. please tell me, what this operation is meant to do.

[Geri]

aha, so the things are starting to become clean

I'm sending a Read Data (0x06) command, or'd with the MFM mode flag (0x40). So, um, 0x46 is what I'm sending.

now i know: i dont have any branch for the mode 0x06 or 0x46.
if you tell me what it precisely does, i add it.

[Geri]

i fixed the issue, now your operating system boots from floppy image.

i added this two missing read modes:

if((opcode_byte==0x06)||(opcode_byte==0x46)){
..
}

both assumes DMA read, assuming 8 incoming byte (i hope 8 is the correct)

you think is this correct like this?

[Geri]

i have invented a new optimisation mechanism.

it is much shorter, much simplyer, does not requies large decode buffers, solves the optimization problems with segmentation, and will be much-much faster.

complitely remove the old optimizator.
with this, from the old 2-300 mhz, i hope i can go up to 300 mhz-1 ghz speed

[stlw]

i have invented a new optimisation mechanism.

it is much shorter, much simplyer, does not requies large decode buffers, solves the optimization problems with segmentation, and will be much-much faster.

complitely remove the old optimizator.
with this, from the old 2-300 mhz, i hope i can go up to 300 mhz-1 ghz speed

Hi,

What do you mean by optimization ? Is Tornado64 actually optimizing binary translator ?

Thanks,
Stanislav

[Geri]

i have invented a new optimisation mechanism.
Hi,

What do you mean by optimization ? Is Tornado64 actually optimizing binary translator ?

Thanks,
Stanislav

its morphed x86 bytecode into something else (vliw).
it is disabled by ifdefs in the current version, becouse it only gave 5% speed-up. or most likely, 5% speed drop.

the problem was that building the new opcode was very complicated, complex, and slow, had a large memory demand (256 kbyte instruction cache) and that ruined the whole thing.

now i am pressing shift-delete on this code, becouse it does not works in the practice.
i wrote the emulator to be very very flexible, so its not a big deal to restart it. (i mean, restart the optimizator, not the whole emulator)

i never actually told this to anybody, but since it not works in practice, now i told it.

but this wasnt included in the tornado64 release publicly available at all. or at least, i dont think i enabled it.

[SpyderTL]

ok, i debugged it

i get the folowing op on write ports:
70 (0x46???? what is that?)

0 (wtf?)
0 (wtf?)
0 (wtf?)
2 (read whole TRACK?)

i guess this last 4 is the parameter you want to give, and the 0x46 is the code of your operation. please tell me, what this operation is meant to do.

According to the wiki page fdc, command 0x06 is "Read Data". The 0x40 flag specifies MFM mode (double/high density).

There is also another flag that you may want to keep an eye out for. 0x80 specifies that both heads should be read, so in this case, you may someday get a 0xC6 command as well. It would work exactly the same.

So when can we get an updated version with the working floppy code and improved performance? (And breakpoints?)

[SpyderTL]

i fixed the issue, now your operating system boots from floppy image.

i added this two missing read modes:

if((opcode_byte==0x06)||(opcode_byte==0x46)){
..
}

both assumes DMA read, assuming 8 incoming byte (i hope 8 is the correct)

you think is this correct like this?

Command 0x06 can be used for both PIO (polling) and DMA transfers. Before sending the Read Data 0x06 command, you have to send a Specify 0x03 command, which enables/disables DMA mode.

And, yes, the Read Data 0x06 command is 8 bytes long, including the op code.

All of this information is on the FDC page.