Hi All,
I've tried getting the emulator to work on both Windows (XP - my workstation) and Linux (Debian Etch Server).
Under Linux (built from es40_cvs_20080503_1030_src.zip) the emulator starts but then fails with;
%SYS-I-READROM: Reading original ROM image from cl67srmrom.exe.
%SYS-I-DECOMP: Decompressing ROM image.
Segmentation fault
Under Windows (built from the es40_018_win32_exe.zip) the emulator starts but then just hangs at 0% using around 50% of the CPU. See below;
%SYS-I-READROM: Reading original ROM image from rom\cl67srmrom.exe.
%SYS-I-DECOMP: Decompressing ROM image.
0% - I left this overnight before ^C to terminate it.
I've tried both the cl67srmrom.exe from the HP Alpha site as well as the one included in the Windows distribution on both variants.
In addition I tried just using the 0.18 source for Linux but that didn't seem to include the configure scripts. I needed the latest snapshot in order to get a distribution I could build.
I'm pretty new to this, so may have missed something somewhere.
cheers,
Rob.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks - On the Linux build I am running the latest CVS Build (es40_cvs_20080503_1030_src) unless there's another I can't see. If I pull down the latest CVS Windows exe it just doesn't run at all. Just comes up with the system cannot execute the specified program.
I'm concentrating on the Linux build as that's the preferred option.
Adding the second CPU to the config allowed the ROM Decompression to work.
I then see the following and the host usage just lists the es40 process as taking up 200% of the CPU.
%SYS-I-ROMLOADED: ROM Image loaded successfully!
Start threads: cpu0 cpu1 ali kbd ide0 ide1 sym nic
Arbitration 0000000000010000 from CPU 0 (@13e39)... won 00000008000100f0
Not quite sure what the next thing I should see is.
I've created an image of the VMS 7.3-1 Alpha CD using the Linux dd command. That's what I'm pointing at.
cheers,
Rob.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi All,
I've tried getting the emulator to work on both Windows (XP - my workstation) and Linux (Debian Etch Server).
Under Linux (built from es40_cvs_20080503_1030_src.zip) the emulator starts but then fails with;
%SYS-I-READROM: Reading original ROM image from cl67srmrom.exe.
%SYS-I-DECOMP: Decompressing ROM image.
Segmentation fault
Under Windows (built from the es40_018_win32_exe.zip) the emulator starts but then just hangs at 0% using around 50% of the CPU. See below;
%SYS-I-READROM: Reading original ROM image from rom\cl67srmrom.exe.
%SYS-I-DECOMP: Decompressing ROM image.
0% - I left this overnight before ^C to terminate it.
I've tried both the cl67srmrom.exe from the HP Alpha site as well as the one included in the Windows distribution on both variants.
In addition I tried just using the 0.18 source for Linux but that didn't seem to include the configure scripts. I needed the latest snapshot in order to get a distribution I could build.
I'm pretty new to this, so may have missed something somewhere.
cheers,
Rob.
Either using the latest source from the CVS or configuring the emulator to have two CPUs (at least for decompressing the ROM image) should fix it.
HTH,
Martin
Martin,
Thanks - On the Linux build I am running the latest CVS Build (es40_cvs_20080503_1030_src) unless there's another I can't see. If I pull down the latest CVS Windows exe it just doesn't run at all. Just comes up with the system cannot execute the specified program.
I'm concentrating on the Linux build as that's the preferred option.
Adding the second CPU to the config allowed the ROM Decompression to work.
I then see the following and the host usage just lists the es40 process as taking up 200% of the CPU.
%SYS-I-ROMLOADED: ROM Image loaded successfully!
Start threads: cpu0 cpu1 ali kbd ide0 ide1 sym nic
Arbitration 0000000000010000 from CPU 0 (@13e39)... won 00000008000100f0
Not quite sure what the next thing I should see is.
I've created an image of the VMS 7.3-1 Alpha CD using the Linux dd command. That's what I'm pointing at.
cheers,
Rob.