 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Until yesterday, the only products I'd heard of where Bochs (only runs
> on Linux) and VMware (AFAIK that's extremely expensive).
I was wrong: Apparently Bochs now runs on Windoze too. (And indeed, QEMU
is using the Bochs BIOS code, and both use the same VGA BIOS.)
However, Bochs looks significantly more complicated to set up...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>>> Also - virtual machines are SOOOO SLOOOOOW... :-/
>>
>> They aren't that slow. Thing is, you're using QEMU, which isn't a virtual
>> machine, it's an emulator. Software like VMware or VirtualBox use your
>> real
>> CPU instead of basically executing x86 code on an interpreter.
>
> Presumably that requires *very* specialised hardware though?
I was right:
http://en.wikipedia.org/wiki/X86_virtualization
Hardware-assisted virtualisation is a feature found only on the very
newest CPUs from Intel and AMD.
That still leaves open the question of how some products claim to
virtualise without emulation on CPUs that lack this technology.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
