problem starting es40 under linux/ppc

[Fausto Saporito]

Hello,

i'm trying to run es40 under DEBIAN PPC, but after the message "decompressing rom", I have a loop, and on the text window I have this looped error messages:

Unknown opcode: 01
Unknown opcode: 04
Unknown opcode: 07
Unknown opcode: 07
Unknown opcode: 04
Unknown opcode: 00.21a0
Unknown opcode: 02
Unknown opcode: 03
Unknown opcode: 00.23b0
Unknown opcode: 00.1003240

and the CPU goes a 100%.

I'm using the latest CVS version.
Is this related to the rom, or vga bios?

thanks in advance,
Fausto

[Zhe]

Hello Fausto,

This is the bug which I described here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1859001&group_id=187340&atid=920906

As what described in the post, this is due to an error (maybe about endianess) in CAlphaCPU::get_icache. Aas far as I can found, by changing
#define ICACHE_LINE_SIZE        512 // in dwords
into
#define ICACHE_LINE_SIZE        16 // in dwords
and
  v_a = address & ICACHE_MATCH_MASK;

  if (address & 1)
  {
    p_a = v_a & ~X64(1);
    asm_bit = true;
  }
  else
  {
    result = virt2phys(v_a, &p_a, ACCESS_EXEC, &asm_bit,0);
    if (result)
      return result;
  }
 
  memcpy(state.icache[state.next_icache].data, cSystem->PtrToMem(p_a), ICACHE_LINE_SIZE * 4);
into
  for(i=0;i<16;i++)
  {
    v_a = (address & X64(ffffffffffffffc0)) | (u64)i << 2;
    if (address & 1)
    {
      p_a = v_a & X64(00000fffffffffff);
      asm_bit = true;
    }
    else
    {
      result = virt2phys(v_a, &p_a, ACCESS_EXEC, &asm_bit,0);
      if (result)
        return result;
    }
    state.icache[state.next_icache].data[i] = (u32)(cSystem->ReadMem(p_a,32));
  }
can make the emulator working.

Zhe

[Fausto Saporito]

Hello Zhe,
thanks for the patch.
I read also your comment (in the Bug track page) and about disk, and I'm working on the largefile problem. If I create a 4GB image (for disk) fopen fails.
I have to use fopen64, but still the number of block is 0, when the disk is mounted... I'm checking this.

regards,
fausto

[Camiel Vanderhoeven]

Hello Fausto, Zhe,

These bugs are probably related to endianess. I added big-endian support at some time to support Solaris on a Sparc system, but never really got it working; if you could mail any patches you need to make to me at camiel@camicom.com, I would be very grateful. You'd do me an even bigger favor if you could grab the latest (today's) CVS repository contents, and apply your patches to that code. You can either mail me the files you changed, or diff output.

I was about to drop endianess-support completely, because I no longer have a big-endian system; but if you can help me get it working and support it, I'll keep it in.

Thanks!

Camiel.

[Fausto Saporito]

Hello Camiel,

I will be happy to test the emulator on my PPC machine, so please don't drop it :-)
About "largefile" support I noticed that this problem is present in all version (little endian / big endian), basically it doesn't possible to mount disk image >= 2GB.

So in UNIX environment this is quite simple, because we have fopen64/fseeko/ftello functions, but for Windows this is a pain, cause this functions are not present and we should use the "windows" API CreateFile/ReadFile/SetFilePos.
I tried to re-create the 64-bit version, but the code should use off_t type (for example) and not "unsigned long", so in this way it's simpler modify the code with "unsigned long long" (the type needed for 64bit functions), defining the off_t type with u64, for example.

The strange thing, under Windows, is fopen open a "large file", but there's no way to handle that file with fseek/ftell. So under Linux/UNIX we need fopen64/fseeko/ftello, under Windows we need only fseeko/ftello.

So you should decide how to implement this, maybe rewriting a little part of the sourcecode with more general type.

I hope I was clear, otherwise ask me for details :-)

regards,
fausto

PS
for the CPU changes in the es40_endian.h, under Linux we could use the endian.h standard file, but I think this file is Linux related, and not present in other platform.
In this file there are the definitions and macros used by Zhe (and detailed in the Bug Tracker).

[Fausto Saporito]

Hello all,

another update: thanks to Zhe patch now I don't have anymore the Unknow opcode problem, but during the startup, I have these messages (I suppose these are errors):

pci0.2(cirrus) Legacy memory access with memory disabled from PCI config.
[repeated lot of times]
pci0.4(dec21143).0 PCI IO access with IO disabled from PCI config.
[repeated lot of times]
pci0.15(ali_ide).0 PCI IO access with IO disabled from PCI config.
[repeated lot of times]

and after 10 mins no console is ready...

Another endianess problem?

regards,
fausto

[Fausto Saporito]

Hello again,

I have to correct my previous message, I do not have the SDL graphic console, but on the first serial line, I have the output of SRM console.
So, basically, it seems the graphic output is broken... and the network too...

[on the SRM console]
*** Error (EWA0), Network station address is a Null address

regards,
fausto

[Camiel Vanderhoeven]

Hello Zhe, Fausto,

I've changed the Icache (I hope that takes care of the invalid opcodes, please check it for me!), and I've included Zhe's changes in es40_endian.h (Zhe, could you let me know your full name, so I can properly credit you in the changelog)

The errors in ali, vga and nic are probably generic endianess issues in pcidevice.h. I'll think about how to fix this, and then ask you to test it again.

64-bit file support is something I'm already working on.

Camiel.

[Zhe]

Hello Camiel,

The current CVS (with your patched Icache) works fine, except all PCI related... My es40_endian.h is patched specific for OS X(which probably has headers like BSD*, not so compatiable as Linux) and there's another OS X patch to startup the SDL, I'll mail you soon.

Zhe