PDOS for Amiga

[kerravon]

pdld has been updated, but qemu still doesn't like it.


[kerravon@paul-pinebook pdld]$ file a.exe
a.exe: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), statically linked, stripped





[kerravon@paul-pinebook pdld]$ qemu-m68k a.exe
qemu-m68k: /home/kerravon/devel/pdos/pdld/a.exe: Invalid ELF image for this architecture



[kerravon@paul-pinebook pdld]$ hexdump a.exe
000000 7F454C46 01020100 00000000 00000000 .ELF............
000010 00020004 00000001 00400034 00000080 .........@.4....
000020 000000C8 00000000 00500020 00020028 .........P. ...(
000030 00040003 2F380001 41F90040 00502F08 ..../8..A..@.P/.
000040 2F380003 20380004 4E404EFA FFFE0000 /8.. 8..N@N.....
000050 48690A00 002E7368 73747274 6162002E Hi....shstrtab..
000060 74657874 002E6461 74610000 00000000 text..data......
000070 00000000 00000000 00000000 00000000 ................
000080 00000001 00000034 00400034 00400034 .......4.@.4.@.4
000090 0000001C 0000001C 00000005 00000001 ................
0000A0 00000001 00000050 00400050 00400050 .......P.@.P.@.P
0000B0 00000004 00000004 00000006 00000001 ................
0000C0 00000000 00000000 00000000 00000000 ................
0000D0 00000000 00000000 00000000 00000000 ................
0000E0 00000000 00000000 00000000 00000000 ................
0000F0 0000000B 00000001 00000006 00400034 .............@.4
000100 00000034 0000001C 00000000 00000000 ...4............
000110 00000001 00000000 00000011 00000001 ................
000120 00000003 00400050 00000050 00000004 .....@.P...P....
000130 00000000 00000000 00000001 00000000 ................
000140 00000001 00000003 00000000 00000000 ................
000150 00000054 00000017 00000000 00000000 ...T............
000160 00000001 00000000 ........
[kerravon@paul-pinebook pdld]$


Can anyone see an issue?


Attached the above (hopefully).

[phx]

Originally Posted by kerravon

library = (struct Library *)SysBase->LibList.lh_Head;
while (library != NULL)
{
if (strcmp(library->lib_Node.ln_Name, "dos.library") == 0)
{
DOSBase = library;
break;
}
library = (struct Library *)library->lib_Node.ln_Succ;
}

so now I am expecting a ixemul.library to exist

As nobody else mentioned it: I doubt that this will work.

1. ixemul.library (or whatever you call you new library) might not be loaded into memory, if no other process opened it before. So you won't find it in the active library list until somebody opens it.
2. Using a pointer on a library from the LibList without opening it does not increment its use-counter, so it may disappear from memory when the last process closes it and your program crashes.
3. These are the reasons why you must obtain a library pointer with

   OpenLibrary()

   (exec.library). Only

   OpenLibrary()

   will be capable to load a library from disk into memory.

Originally Posted by kerravon

[kerravon@paul-pinebook pdld]$ qemu-m68k a.exe
qemu-m68k: /home/kerravon/devel/pdos/pdld/a.exe: Invalid ELF image for this architecture
(...)

Can anyone see an issue?

The ELF executable seems fine. Statically linked with a start address of 0x400034. The question is: does your qemu system allow executing code at this address? When I look at our vbcc m68k-linux port, then a virtual address of 0x1800040 is used in the linker script.

Maybe it needs some signature (.note segment) to make it valid for execution on Linux? I know that NetBSD needs a

.note.netbsd.ident

with some defined contents.


BTW, even if your program is executed, this will never work:

Disassembly of section .text:

00400034 <.text>:
  400034:       2f38 0001       movel 0x1,%sp@-
  400038:       41f9 0040 0050  lea 0x400050,%a0
  40003e:       2f08            movel %a0,%sp@-
  400040:       2f38 0003       movel 0x3,%sp@-
  400044:       2038 0004       movel 0x4,%d0
  400048:       4e40            trap #0
  40004a:       4efa fffe       jmp %pc@(0x40004a)

You load 32-bit values from address 1, 3 and 4 instead of the constants 1, 3 and 4. Your forgot the '#' in the source.

[kerravon]

Originally Posted by kerravon

000000 7F454C46 01020100 00000000 00000000 .ELF............
000010 00020004 00000001 00400034 00000080 .........@.4....
000020 000000C8 00000000 00500020 00020028 .........P. ...(

Offset 0x29 should be 0x34, not 0x50. :-)


I can now get the executable to loop, or crash, so I can detect things. But I can't yet see any output. I have tried putting various things on the stack to provoke some activity, but nothing I have tried so far works.

[kerravon]

Originally Posted by kerravon

Offset 0x29 should be 0x34, not 0x50. :-)


I can now get the executable to loop, or crash, so I can detect things. But I can't yet see any output. I have tried putting various things on the stack to provoke some activity, but nothing I have tried so far works.

I figured out the secret by switching to exit - this returns 6:


[kerravon@paul-pinebook pdld]$ ./m68ktest.exe
[kerravon@paul-pinebook pdld]$ echo $?
6
[kerravon@paul-pinebook pdld]$





.text

.globl myentry
myentry:

#yyy: jmp yyy

mov.l #0x410a410a, -(sp)
# push sp
# pop d0
# mov sp, a0
lea 0(sp),a0
# length to write
move.l #2, -(sp)

# lea msg, a0
move.l a0, -(sp)
# move.l #0, -(sp)
# move.l a0, -(sp)
# move.l #0, -(sp)

# 1 = stdout handle
move.l #1, -(sp)

# fake return address
move.l #5, -(sp)

# 4 = write
move.l #1, d0
move.l #6, d1
move.l #7, d2
move.l #8, a0
trap #0

zzz: jmp zzz



# .data

msg:
.ascii "H\n"
#msg: dc.b 'H', '\n', '\n', 'H', 'i', '\n'
[kerravon@paul-pinebook pdld]$

[kerravon]

Here is a working executable, and attached.


[kerravon@paul-pinebook scratch]$ hexdump m68ktest.exe
000000 7F454C46 01020100 00000000 00000000 .ELF............
000010 00020004 00000001 00400034 00000060 .........@.4...`
000020 000000A0 00000000 00340020 00010028 .........4. ...(
000030 00030002 70047201 41FA000E 2F082417 ....p.r.A.../.$.
000040 76034E40 4EFAFFFE 48690A00 002E7368 v.N@N...Hi....sh
000050 73747274 6162002E 74657874 00000000 strtab..text....
000060 00000001 00000034 00400034 00400034 .......4.@.4.@.4
000070 00000018 00000018 00000005 00000001 ................
000080 00000000 00000000 00000000 00000000 ................
000090 00000000 00000000 00000000 00000000 ................
0000A0 00000000 00000000 00000000 00000000 ................
0000B0 00000000 00000000 00000000 00000000 ................
0000C0 00000000 00000000 0000000B 00000001 ................
0000D0 00000006 00400034 00000034 00000018 .....@.4...4....
0000E0 00000000 00000000 00000001 00000000 ................
0000F0 00000001 00000003 00000000 00000000 ................
000100 0000004C 00000011 00000000 00000000 ...L............
000110 00000001 00000000 ........
[kerravon@paul-pinebook scratch]$ file m68ktest.exe
m68ktest.exe: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), statically linked, stripped
[kerravon@paul-pinebook scratch]$ ./m68ktest.exe
Hi
^C
[kerravon@paul-pinebook scratch]$





[kerravon@paul-pinebook scratch]$ readelf -a m68ktest.exe
ELF Header:
Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: MC68000
Version: 0x1
Entry point address: 0x400034
Start of program headers: 96 (bytes into file)
Start of section headers: 160 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 40 (bytes)
Number of section headers: 3
Section header string table index: 2

Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00400034 000034 000018 00 AX 0 0 1
[ 2] .shstrtab STRTAB 00000000 00004c 000011 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
D (mbind), p (processor specific)

There are no section groups in this file.

Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000034 0x00400034 0x00400034 0x00018 0x00018 R E 0x1

Section to Segment mapping:
Segment Sections...
00 .text

There is no dynamic section in this file.

There are no relocations in this file.

The decoding of unwind sections for machine type MC68000 is not currently supported.

No version information found in this file.
[kerravon@paul-pinebook scratch]$







[kerravon@paul-pinebook scratch]$ cat m68ktest.asm
# Simple Motorola 68000 program for Linux

# Written by Paul Edwards
# Released the public domain

#asami -o m68ktest.o m68ktest.asm
#ldami -s -o m68ktest.exe m68ktest.o

#m68kemul m68ktest.exe


# a7=sp (stack)


.text

.globl myentry
myentry:

# 4 = Linux write syscall
move.l #4, d0

# 1 = stdout handle
move.l #1, d1

# Don't know if there is a nicer way of doing this
lea msg, a0
move.l a0, -(sp)
move.l (sp), d2

# 3 = length of data to write
move.l #3, d3

trap #0

zzz: jmp zzz



# .data

msg: dc.b 'H', 'i', '\n'
[kerravon@paul-pinebook scratch]$

[kerravon]

Originally Posted by phx

As nobody else mentioned it: I doubt that this will work.

1. ixemul.library (or whatever you call you new library) might not be loaded into memory, if no other process opened it before. So you won't find it in the active library list until somebody opens it.
2. Using a pointer on a library from the LibList without opening it does not increment its use-counter, so it may disappear from memory when the last process closes it and your program crashes.
3. These are the reasons why you must obtain a library pointer with

   OpenLibrary()

   (exec.library). Only

   OpenLibrary()

   will be capable to load a library from disk into memory.

Thanks for that technical info.

The ELF executable seems fine. Statically linked with a start address of 0x400034. The question is: does your qemu system allow executing code at this address? When I look at our vbcc m68k-linux port, then a virtual address of 0x1800040 is used in the linker script.

I looked for that executable you mentioned, but couldn't find it on your website. Eventually I found a vim.tiny on the debian ISO referred to in the qemu documentation, and was able to compare headers (and zapped things to be the same) and found that this was incorrect:


Elf32_Half e_ehsize;


because the size of an internal structure had been used, and that changed because I was doing links on a machine with 64-bit long. So I changed to using the proper external size, and it worked.

Maybe it needs some signature (.note segment) to make it valid for execution on Linux? I know that NetBSD needs a

.note.netbsd.ident

with some defined contents.

Code was added to do this, but it didn't fix the problem, and also with the above bug fix, it worked without needing this.


Also qemu didn't mind the address I loaded it at.

BTW, even if your program is executed, this will never work:

Disassembly of section .text:

00400034 <.text>:
  400034:       2f38 0001       movel 0x1,%sp@-
  400038:       41f9 0040 0050  lea 0x400050,%a0
  40003e:       2f08            movel %a0,%sp@-
  400040:       2f38 0003       movel 0x3,%sp@-
  400044:       2038 0004       movel 0x4,%d0
  400048:       4e40            trap #0
  40004a:       4efa fffe       jmp %pc@(0x40004a)

You load 32-bit values from address 1, 3 and 4 instead of the constants 1, 3 and 4. Your forgot the '#' in the source.

Thanks. It also didn't work even with that change, because qemu-m68k needs things in registers, not on the stack. Took a huge number of attempts to figure that out.


I also can't use ".data" currently with pdld, so that is back to the pdld author to diagnose, and another thing that caused delays.

[kerravon]

The .data issue (simply adding .data so that msg is in .data) is back to me to diagnose (ie the pdld author doesn't see anything wrong).


[kerravon@paul-pinebook pdld]$ ./pdld.exe --oformat elf --image-base 0x1800000 m68ktest.o
[kerravon@paul-pinebook pdld]$


[kerravon@paul-pinebook pdld]$ qemu-m68k a.exe
Segmentation fault (core dumped)



[kerravon@paul-pinebook pdld]$ file a.exe
a.exe: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), statically linked, stripped
[kerravon@paul-pinebook pdld]$



[kerravon@paul-pinebook pdld]$ readelf -a a.exe
ELF Header:
Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: MC68000
Version: 0x1
Entry point address: 0x1800034
Start of program headers: 128 (bytes into file)
Start of section headers: 200 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 2
Size of section headers: 40 (bytes)
Number of section headers: 4
Section header string table index: 3

Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 01800034 000034 000018 00 AX 0 0 1
[ 2] .data PROGBITS 0180004c 00004c 000004 00 WA 0 0 1
[ 3] .shstrtab STRTAB 00000000 000050 000017 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
D (mbind), p (processor specific)

There are no section groups in this file.

Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000034 0x01800034 0x01800034 0x00018 0x00018 R E 0x1
LOAD 0x00004c 0x0180004c 0x0180004c 0x00004 0x00004 RW 0x1

Section to Segment mapping:
Segment Sections...
00 .text
01 .data

There is no dynamic section in this file.

There are no relocations in this file.

The decoding of unwind sections for machine type MC68000 is not currently supported.

No version information found in this file.
[kerravon@paul-pinebook pdld]$




[kerravon@paul-pinebook pdld]$ hexdump a.exe
000000 7F454C46 01020100 00000000 00000000 .ELF............
000010 00020004 00000001 01800034 00000080 ...........4....
000020 000000C8 00000000 00340020 00020028 .........4. ...(
000030 00040003 70047201 41F90180 004C2F08 ....p.r.A....L/.
000040 24177603 4E404EFA FFFE0000 48690A00 $.v.N@N.....Hi..
000050 002E7368 73747274 6162002E 74657874 ..shstrtab..text
000060 002E6461 74610000 00000000 00000000 ..data..........
000070 00000000 00000000 00000000 00000000 ................
000080 00000001 00000034 01800034 01800034 .......4...4...4
000090 00000018 00000018 00000005 00000001 ................
0000A0 00000001 0000004C 0180004C 0180004C .......L...L...L
0000B0 00000004 00000004 00000006 00000001 ................
0000C0 00000000 00000000 00000000 00000000 ................
0000D0 00000000 00000000 00000000 00000000 ................
0000E0 00000000 00000000 00000000 00000000 ................
0000F0 0000000B 00000001 00000006 01800034 ...............4
000100 00000034 00000018 00000000 00000000 ...4............
000110 00000001 00000000 00000011 00000001 ................
000120 00000003 0180004C 0000004C 00000004 .......L...L....
000130 00000000 00000000 00000001 00000000 ................
000140 00000001 00000003 00000000 00000000 ................
000150 00000050 00000017 00000000 00000000 ...P............
000160 00000001 00000000 ........
[kerravon@paul-pinebook pdld]$




Can anyone see anything wrong (source and executable attached)?


Thanks. Paul.

[kerravon]

Originally Posted by kerravon

000080 00000001 00000034 01800034 01800034 .......4...4...4
000090 00000018 00000018 00000005 00000001 ................
0000A0 00000001 0000004C 0180004C 0180004C .......L...L...L

The repeated addresses 1800034 and 180004c looked odd to me, but the pdld author confirmed they were correct.


The next thing that looked odd to me was the repeated 1 at offset A3, so I zapped it to 2, and I was quite surprised when it worked! Still waiting for an explanation on that. That was very lucky indeed.



So then I moved on to the next thing I need, which is relocations.



[kerravon@paul-pinebook pdld]$ ./pdld.exe --oformat elf --image-base 0x1800000 --emit-relocs m68ktest.o
[kerravon@paul-pinebook pdld]$ hexdump a.exe
000000 7F454C46 01020100 00000000 00000000 .ELF............
000010 00020004 00000001 01800034 00000080 ...........4....
000020 000000C8 00000000 00340020 00020028 .........4. ...(
000030 00050004 70047201 41F90180 004C2F08 ....p.r.A....L/.
000040 24177603 4E404EFA FFFE0000 0180003A $.v.N@N........:
000050 00000001 48690A00 002E7368 73747274 ....Hi....shstrt
000060 6162002E 72656C2E 74657874 002E6461 ab..rel.text..da
000070 74610000 00000000 00000000 00000000 ta..............
000080 00000001 00000034 01800034 01800034 .......4...4...4
000090 00000018 00000018 00000005 00000001 ................
0000A0 00000001 00000054 0180004C 0180004C .......T...L...L
0000B0 00000004 00000004 00000006 00000001 ................
0000C0 00000000 00000000 00000000 00000000 ................
0000D0 00000000 00000000 00000000 00000000 ................
0000E0 00000000 00000000 00000000 00000000 ................
0000F0 0000000F 00000001 00000006 01800034 ...............4
000100 00000034 00000018 00000000 00000000 ...4............
000110 00000001 00000000 0000000B 00000009 ................
000120 00000000 00000000 0000004C 00000008 ...........L....
000130 00000000 00000001 00000004 00000008 ................
000140 00000015 00000001 00000003 0180004C ...............L
000150 00000054 00000004 00000000 00000000 ...T............
000160 00000001 00000000 00000001 00000003 ................
000170 00000000 00000000 00000058 0000001B ...........X....
000180 00000000 00000000 00000001 00000000 ................
[kerravon@paul-pinebook pdld]$ zap a.exe 0xa3 0x02
[kerravon@paul-pinebook pdld]$ ./a.exe
?^C
[kerravon@paul-pinebook pdld]$

zapping at least allows it to load and run, but it is printing garbage.


I didn't expect qemu to even use the relocations.


Any ideas?


Thanks. Paul.

[kerravon]

Originally Posted by kerravon

Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000034 0x01800034 0x01800034 0x00018 0x00018 R E 0x1
LOAD 0x00004c 0x0180004c 0x0180004c 0x00004 0x00004 RW 0x1

I now have a theory that those two contradictory things (read and execute and read and write) cannot be on the same page.

[kerravon@paul-pinebook pdld]$ hexdump a.exe
000000 7F454C46 01020100 00000000 00000000 .ELF............
000010 00020004 00000001 01800034 00000080 ...........4....
000020 000000C8 00000000 00340020 00020028 .........4. ...(
000030 00040003 70047201 41F90180 004C2F08 ....p.r.A....L/.
000040 24177603 4E404EFA FFFE0000 48690A00 $.v.N@N.....Hi..
000050 002E7368 73747274 6162002E 74657874 ..shstrtab..text
000060 002E6461 74610000 00000000 00000000 ..data..........
000070 00000000 00000000 00000000 00000000 ................
000080 00000001 00000034 01800034 01800034 .......4...4...4
000090 00000018 00000018 00000005 00000001 ................
0000A0 00000001 0000004C 0180004C 0180004C .......L...L...L

And zapping offsets 0xaa and 0xae to 0x10 solves the problem. Interestingly 0x18 gives a mapping error, like this latest test:


qemu-m68k: /home/kerravon/devel/pdos/pdld/m68ktest.exe: Error mapping file: Invalid argument


In fact - disturbing the value 4C (either up or down) gives the mapping error too.

[kerravon]

Originally Posted by kerravon

I now have a theory that those two contradictory things (read and execute and read and write) cannot be on the same page.

Theory was confirmed by pdld author, and now fixed, and even relocs work. Note that I can now confirm that the address doesn't matter:


[kerravon@paul-pinebook pdld]$ readelf -a a.exe | grep 401
Entry point address: 0x401000
[ 1] .text PROGBITS 00401000 001000 000018 00 AX 0 0 4096
LOAD 0x001000 0x00401000 0x00401000 0x00018 0x00018 R E 0x1000
00401006 00000001 R_68K_32
[kerravon@paul-pinebook pdld]$




and nor was a .note section required.




And I believe I have everything I need now to create the Amiga emulator for the limited purpose I have in mind.

[kerravon]

Originally Posted by kerravon

And I believe I have everything I need now to create the Amiga emulator for the limited purpose I have in mind.

First step is to port PDPCLIB to 68000 Linux. That involved fixing a bug in pdld.


That is now working sufficiently:


[kerravon@paul-pinebook xxx]$ qemu-m68k ./pdptest.exe abc def
welcome to pdptest
main function is at 0040130C
allocating 10 bytes
m1 is C0802004
allocating 20 bytes
m2 is C0803004
stack is around C08001BC
printing arguments
argc = 3
arg 0 is <./pdptest.exe>
arg 1 is <abc>
arg 2 is <def>
[kerravon@paul-pinebook xxx]$



I haven't yet implemented setjmp/longjmp, but I don't think I need that for proof of concept, so the difficult assembler work can be deferred.


BFN. Paul.

[kerravon]

Ok, the Amiga emulator work was going well, and I was able to execute an Amiga Hunk executable and get it to return a value.


However, I'm now a bit stuck with the DOS calls - and it's possible that there is a concept I am missing and there is a show-stopper.


I have this intrusive code:


_Input:
.globl Input
Input:
MOVE.L A6,-(A7)
MOVEA.L _DOSBase,A6
#ppp: jmp ppp
# JSR -54(A6)
lea -54(a6), a6
move.l a6, -(sp)
move.l (sp)+, d0
MOVEA.L (A7)+,A6
RTS



And I'm getting the expected result (the d0 is returned to bios.exe so that I can inspect the value):

[kerravon@paul-pinebook xxx]$ ./bios.exe pdptest.exe

bios starting
about to execute program with entry point C080202C
SysBase is 004092E8
DOSBase is 004092D6
inputaddr is 004092A0
return from called program is 4092a0
enter command, exit to exit

bios exiting
[kerravon@paul-pinebook xxx]$





The original code has been tested on a real Amiga as far as I know - and it is generated code too - so the JSR should be correct.


That -54 offset is quite odd - it's not a multiple of 4.


But I tried directly calling that and it apparently works.


My primary suspect is that I failed to set up the DOS structures properly, and I am missing a level of indirection.


Here is what I have:


static struct {
void *(*Input)(void);
char filler[50];
struct Node node;
} dosfuncs = {
Input,
{},
{
NULL,
{},
"dos.library"
}
};




static struct ExecBase SysBase = {
{},
{ &dosfuncs.node, {} },
};






static int callami(char *buf)
{
printf("SysBase is %p\n", &SysBase);
printf("DOSBase is %p\n", DOSBase);
printf("inputaddr is %p\n", &dosfuncs.Input);
/* dosfuncs.Input(); */
return (callami2(strlen(buf) + 0x80000000UL,
buf,
&SysBase,
genstart));
}




Full code is here:


https://sourceforge.net/p/pdos/gitcode/ci/master/tree/generic/bios.c#l1342



https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/amisupa.asm#l74


Any insights?


Is that JSR going to offset -54 (which I am showing on return), or the value at that offset?



Thanks. Paul.

[meynaf]

Originally Posted by kerravon

That -54 offset is quite odd - it's not a multiple of 4.

It does not need to. The contents is a bunch of JMP instructions, not addresses.
So the value it has to be multiple of is 6, as JMP to absolute value is 2 byte opcode + 4 byte address.

[kerravon]

Originally Posted by kerravon

Is that JSR going to offset -54 (which I am showing on return), or the value at that offset?

Don't worry - I constructed an assembler jump table and answered my own question and now I am progressing again.

[kerravon]

Originally Posted by kerravon

Don't worry - I constructed an assembler jump table and answered my own question and now I am progressing again.

I'll investigate the crash on exit "tomorrow". I suspect BSS isn't being cleared in exeload.c and the calloc in bios.c is insufficient.

I'll investigate the incorrect parameters too.


[kerravon@paul-pinebook xxx]$ qemu-m68k ./bios.exe pdptest.exe "abc def"

bios starting
about to execute program with entry point C080202C
welcome to pdptest
main function is at C0802200
allocating 10 bytes
in callocmem
m1 is C0CC7008
allocating 20 bytes
in callocmem
m2 is C0CC8008
stack is around C07FFE70
printing arguments
argc = 4
arg 0 is <UNKNOWN>
arg 1 is <pdptest.exe>
arg 2 is <abc>
arg 3 is <def>
Segmentation fault (core dumped)
[kerravon@paul-pinebook xxx]$




Attaching bios.exe, an m68k Linux program, and pdptest.exe a valid Amiga Hunk that conforms to the "D7 standard".


All source code has been committed to Sourceforge.



BFN. Paul.

[kerravon]

Originally Posted by meynaf

It does not need to. The contents is a bunch of JMP instructions, not addresses.
So the value it has to be multiple of is 6, as JMP to absolute value is 2 byte opcode + 4 byte address.

Thanks. Our messages crossed. I didn't know how to force a 6-byte JMP instruction so I had to declare the 2 bytes manually.

[kerravon]

Originally Posted by kerravon

I'll investigate the crash on exit "tomorrow". I suspect BSS isn't being cleared in exeload.c and the calloc in bios.c is insufficient.

Nothing to do with BSS. It was longjmp issues.

I'll investigate the incorrect parameters too.

Amiga programs only expecting parameters, not program name.


Anyway, it took the entire day, but I finally got it to work:


[kerravon@paul-pinebook xxx]$ ./bios.exe pdptest.exe "abc def"

bios starting
about to execute program with entry point C080202C
welcome to pdptest
main function is at C0802200
allocating 10 bytes
m1 is C0CC7008
allocating 20 bytes
m2 is C0CC8008
stack is around C07FFEC0
printing arguments
argc = 3
arg 0 is <UNKNOWN>
arg 1 is <abc>
arg 2 is <def>
return from called program is hex 0
enter command, exit to exit

bios exiting
[kerravon@paul-pinebook xxx]$




Note that my Linux system is automatically invoking qemu-m68k to run that.



Attaching the executables.


P.S. Implementing Amiga 68000 abstracted the code so that I now have a better understanding of how x86 and ARM currently work and how they should work.