Invisible wrote:
> Until yesterday, I had always assumed that any kind of emulation or
> virtualisation solution would be roughly 1,000,000x slower than native
> execution, so it's not something I've ever been interested in. Hence
> it's something I know almost nothing about. However, since it appears
> that you can actually run real software at almost native speeds,
> suddenly it becomes far more interesting... ;-)

There is an emulator for PowerPC processors called PearPC.

It has two modes. One is an actual interpreter. Runs anywhere; it's quite
portable C code. 500x slower than native.

The other mode is only for x86 hosts. Translates PowerPC instructions into
x86 instructions on-demand, and caches the translations. 15x slower than
native.

I have also seen an IBM PC emulator written in Java. It was pretty fun to
see Linux and DOS boot inside a browser (even though the RAM usage was
insanely high). But even Lemmings under DOS ran at slow motion in that
emulator...

Post a reply to this message

>> A hundred maybe, but a million?
>
> Last time I checked, the IA32 instruction set is *very* complex. I doubt 
> it's got any simpler since then...

But still, presumably you write your emulator in such a way that the most 
common instructions (that usually take 1 or just a few clock cycles) are 
emulated as fast as possible.

I would guess emulation is a prime candidate to be written in assembler, 
where you can just have a huge branch table for each instruction type, then 
jump the real CPU program counter into that table based on the op-code.  In 
that way, I would imagine you can get away with even a factor of 10 
slow-down for the common instructions.

Post a reply to this message

> 1. Go to http://www1.interq.or.jp/t-takeda/top.html
>
> 2. Download the zip file at the top of that page.
>
> 3. Unzip it somewhere.
>
> 4. Find an ISO image for a Linux LiveCD.
>
> 5. Do the following:
>
>   qemu.exe -cdrom My_LiveCD.iso
>
> 6. Watch it boot up.

qemu doesn't work for me, it crashes out with a "this program has gone 
wrong" windows error box.  The console says "cannot find kqemu" or 
something, so I downloaded and installed that but it still crashes out.  I 
even tried XP compatibility mode etc but nope.  This is on Vista 64bit. 
Shame, because my XP machine is at least 5x slower...

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> So when you say "works on any reasonably modern PC", what you 
>> *actually* mean is "works on any brand new bleeding-edge PC"?
> 
> No. I believe it was the 386 that added the capability.
> 
> You know, two generations back before the Pentium came out?
> 
> Added primarily to emulate multiple "DOS boxes" under Windows.

The 386 or so added "virtual mode" (or whatever the exact term is) that 
makes the CPU act as if it's in real mode, but it's really in protected 
mode, and the OS can control the page mappings and so forth.

You can use that to make real mode applications (e.g., DOS programs) 
think they have the machine to themselves. But that doesn't work for a 
protected mode program such as an OS.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

scott wrote:

> qemu doesn't work for me, it crashes out with a "this program has gone 
> wrong" windows error box.  The console says "cannot find kqemu" or 
> something, so I downloaded and installed that but it still crashes out.  
> I even tried XP compatibility mode etc but nope.  This is on Vista 
> 64bit. Shame, because my XP machine is at least 5x slower...

On my system I also get an error saying "can't find kemu", but it runs 
anyway.

Try the "-no-kqemu" flag and see if that makes any difference for you...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Nicolas Alvarez wrote:

> I have also seen an IBM PC emulator written in Java. It was pretty fun to
> see Linux and DOS boot inside a browser (even though the RAM usage was
> insanely high). But even Lemmings under DOS ran at slow motion in that
> emulator...

Heh. That's pretty crazy! ;-)

Somebody somewhre is working on a Gameboy emulator in Haskell - but 
AFAIK that machine operates vastly slower than any PC anyway...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

> Somebody somewhre is working on a Gameboy emulator in Haskell - but AFAIK 
> that machine operates vastly slower than any PC anyway...

IIRC it uses a 1MHz processor (can't remember which).  Funnily enough the 
same processor was used in a graphics calculator I once had (TI-86), so it 
was relatively easy to port the games :-)

Post a reply to this message

>>> However, the idea of being able to just plug in a USB stick and click 
>>> an icon and instantly have a complete Linux environment set up 
>>> exactly the way I want it is... pretty neat, actually.
>>
>> You might have problems with IO speed if you do that. USB is a lot 
>> slower than SATA.
> 
> Depends what you want to do. Running Damn Small Linux from a USB drive 
> is probably *faster* than running it from a CD-ROM due to the vastly 
> superior seek time. (CD-ROM drives typically have a horrible seek time!) 
> Also, DSL is based on KNOPPIX and uses a cloop compressed filesystem 
> image, so there's less data to shift (but more CPU load).
> 
> If I get bored enough maybe I'll benchmark it. But either way, it's a 
> trivial matter to copy a folder off the USB drive and onto a spare 
> folder on the local HD, run it for a while, and then just delete it when 
> you're done. That's about the easiest install/uninstall procedure 
> imaginable! ;-)

I was wrong.

DSL copies *the entire CD image* into RAM when it boots. So the medium 
it's running from affects only the time taken to load the whole image 
into RAM; after that, it makes no difference at all.

(In fact, if you copy the CD ISO-image onto your HD and run QEMU, DSL 
boots *faster* than if you really boot from CD.)

In terms of running speed however... Well it turns out that with a few 
mouse clicks you can install Doom under DSL. (The speed with which it 
downloaded and installed shocked me for a moment - until I remembered 
that back when Doom came out, all games came on 1.44 MB floppies, not 
dual-layer BluRay disks like they do today.) Doom runs pretty fast when 
booting DSL natively, and slightly slower under QEMU. (The speed 
difference is small enough that I'm not sure if I imagined it.)

That's a pretty impressove vote for QEMU!

OTOH, my system here at work has very little RAM and a slow CPU, so 
running QEMU basically disables the whole of the rest of the machine. 
You can run QEMU *or* do something else, but not both. (My monster 
machine at home has no such difficulty.)

PS. Yes, I'm playing Doom at work. And? ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

scott wrote:
>> Somebody somewhre is working on a Gameboy emulator in Haskell - but 
>> AFAIK that machine operates vastly slower than any PC anyway...
> 
> IIRC it uses a 1MHz processor (can't remember which).  Funnily enough 
> the same processor was used in a graphics calculator I once had (TI-86), 
> so it was relatively easy to port the games :-)

I'm reasonably sure the Gameboy is a Z80... Wikipedia will know.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:

> I'm reasonably sure the Gameboy is a Z80... Wikipedia will know.

Nope, I was wrong. Apparently it uses a 4 MHz customised Z80 with an 
on-die ROM for bootstrap and a customised instruction set somewhat 
similar to the Intel 8080... Oh well!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message