PDOS for Amiga

[kerravon]

Originally Posted by meynaf

This is linked to float stuff. You need to link with some floating-point .lib or something like that.
Personnally i would instead avoid using floats, but that's just me.

Ok, I don't actually need floating point for what I wish to do, so I'll just create some dummy functions to satisfy the linker.

That would be a good thing i suppose, but it might make things more complicated than it's worth.
As an example, Read() isn't as minimalistic as it looks. It's in dos.library, not in exec.library. So to access it, you not only have to provide the ExecBase structure, but also DosBase.

I have already written that code, which you can find here:

https://sourceforge.net/p/pdos/gitco...358b6a/#diff-3

I have committed all the work I did today (see other files too).

Furthermore, even if some Read() is provided, the code may or may not work as it can not only read from files but also other peripherals as well (like the input from a console window).

I'm only expecting the hard disk and stdin to work.

Besides, to Read() something you need some Open() as well and the path provided here of course uses the Amiga way of doing, not pc-dos/windows nor unix.

No. If that is user-supplied, then when running under AmigaPDOS, the Amiga executable will open a PC-DOS filename, referring to a file on the FAT hard disk.

[kerravon]

Originally Posted by phx

Your code does a floating point IEEE double precision comparison somewhere. As you probably didn't enable FPU-code generation in the compiler (which doesn't exist for plain 68000) you need soft-float support.

AmigaOS has soft-float support in the mathieee*.library, which most Amiga compilers would use. With vbcc you can alternatively link with the standalone soft-float linker library, msoft.lib (-lmsoft), which implements John R. Hauser's free IEC/IEEE Floating-point Artithmetic Package.

Thanks. I am happy to assume a machine that has these instructions, so I enabled fpu. I still got link errors on __ldivu so I enabled 68020 and all code-generation problems went away.

What I would really have liked is to generate 68020 instructions only when the ldivu etc situation occurred, so that simple programs that don't actually exercise floating point or 32-bit divides or whatever, still run on a plain 68000. But until that is available, I'm happy to just require a minimum of a 68020. I guess I could look at adding ldivu etc and drop back to 68000 at a later date as another option.

[Thomas Richter]

Originally Posted by kerravon

Thanks. I am happy to assume a machine that has these instructions, so I enabled fpu. I still got link errors on __ldivu so I enabled 68020 and all code-generation problems went away.

Well, I thought you are targetting a 68000? __ldivu is likely a 32/32 signed long division which is not available as an instruction on the 68000, so it is available as a function of the link library of your compiler.


On AmigaOs, it is available in a separate system library, i.e. utility.library which programs needing it would open.

[meynaf]

Originally Posted by kerravon

Ok, I don't actually need floating point for what I wish to do, so I'll just create some dummy functions to satisfy the linker.

If you don't need floating point, then you should remove all floats from your code. You will not need anything special to satisfy the linker then.

Originally Posted by kerravon

No. If that is user-supplied, then when running under AmigaPDOS, the Amiga executable will open a PC-DOS filename, referring to a file on the FAT hard disk.

This looks somehow incompatible with your desire to have simple Amiga native programs run on AmigaPDOS.

[phx]

Originally Posted by kerravon

Thanks. I am happy to assume a machine that has these instructions, so I enabled fpu. I still got link errors on __ldivu so I enabled 68020 and all code-generation problems went away.

Not a real problem. When you enable FPU-code, then you should also enable 68020 anyway. The FPU coprocessor interface is not present for 68000 and 68010.

What I would really have liked is to generate 68020 instructions only when the ldivu etc situation occurred

I didn't have a closer look into you project, but this could be easily solved by moving the 020+ and FPU-code into separate object files, which you compile with -cpu=68020 and -fpu=68881, while the rest is compiled for 68000.

I guess I could look at adding ldivu etc and drop back to 68000 at a later date as another option.

This is from vbcc's clib:

 ;   32bit Division/Modulo for 68000/68010

* Functions:
*  long           __divu(register long d0, register long d1)
*  long           __divs(register long d0, register long d1)
*  long           __modu(register long d0, register long d1)
*  long           __mods(register long d0, register long d1)
*  __ldivs etc. expect parameters on the stack

        mc68000

        code

        xdef    __divu
        xdef    __divs
        xdef    __modu
        xdef    __mods
        xdef    __ldivs
        xdef    __ldivu
        xdef    __lmods
        xdef    __lmodu

__lmods
        movem.l 4(sp),d0/d1
__mods:
        tst.l   d1
        bmi     1$
        tst.l   d0
        bmi     2$
        bsr     __divu
        move.l  d1,d0
        rts
1$:     neg.l   d1
        tst.l   d0
        bmi     3$
        bsr     __divu
        move.l  d1,d0
        rts
2$:     neg.l   d0
        bsr     __divu
        neg.l   d1
        move.l  d1,d0
        rts
3$:     neg.l   d0
        bsr     __divu
        neg.l   d1
        move.l  d1,d0
        rts


__lmodu
        movem.l 4(sp),d0/d1
__modu:
        bsr     __divu
        move.l  d1,d0
        rts


__ldivs
        movem.l 4(sp),d0/d1
__divs:
        tst.l   d0
        bpl     2$
        neg.l   d0
        tst.l   d1
        bpl     1$
        neg.l   d1
        bsr     __divu
        neg.l   d1
        rts
1$:     bsr     __divu
        neg.l   d0
        neg.l   d1
        rts
2$:     tst.l   d1
        bpl     __divu
        neg.l   d1
        bsr     __divu
        neg.l   d0
        rts


__ldivu
        movem.l 4(sp),d0/d1
__divu:
        move.l  d2,-(sp)
        swap    d1
        move.w  d1,d2
        bne     2$
        swap    d0
        swap    d1
        swap    d2
        move.w  d0,d2
        beq     1$
        divu    d1,d2
        move.w  d2,d0
1$:     swap    d0
        move.w  d0,d2
        divu    d1,d2
        move.w  d2,d0
        swap    d2
        move.w  d2,d1
        move.l  (sp)+,d2
        rts
2$:     move.l  d3,-(sp)
        moveq   #16,d3
        cmp.w   #$80,d1
        bhs     3$
        rol.l   #8,d1
        subq.w  #8,d3
3$:     cmp.w   #$800,d1
        bhs     4$
        rol.l   #4,d1
        subq.w  #4,d3
4$:     cmp.w   #$2000,d1
        bhs     5$
        rol.l   #2,d1
        subq.w  #2,d3
5$:     tst.w   d1
        bmi     6$
        rol.l   #1,d1
        subq.w  #1,d3
6$:     move.w  d0,d2
        lsr.l   d3,d0
        swap    d2
        clr.w   d2
        lsr.l   d3,d2
        swap    d3
        divu    d1,d0
        move.w  d0,d3
        move.w  d2,d0
        move.w  d3,d2
        swap    d1
        mulu    d1,d2
        sub.l   d2,d0
        bhs     8$
        subq.w  #1,d3
        add.l   d1,d0
7$:     bhs.s   7$
8$:     moveq   #0,d1
        move.w  d3,d1
        swap    d3
        rol.l   d3,d0
        swap    d0
        exg     d0,d1
        move.l  (sp)+,d3
        move.l  (sp)+,d2
        rts

        end

[kerravon]

Originally Posted by meynaf

If you don't need floating point, then you should remove all floats from your code. You will not need anything special to satisfy the linker then.

The code in question is the C runtime library. The code is required for anyone doing floating point stuff defined in C90. I don't want to break it for everyone (ie including non-68000 users). By putting dummy functions in, it would have just crashed and burned on the 68000.

This looks somehow incompatible with your desire to have simple Amiga native programs run on AmigaPDOS.

AmigaPDOS is ... PDOS! PDOS is ... MSDOS! :-) Just a 32-bit version, hopefully running on the 68000 too. You will get MSDOS-like behavior from both the OS (AmigaPDOS) and applications (including any supported AmigaOS applications).

[kerravon]

Originally Posted by phx

Not a real problem. When you enable FPU-code, then you should also enable 68020 anyway. The FPU coprocessor interface is not present for 68000 and 68010.

Well, I would have preferred pure 68000 code to be generated, even if no FPU was available.

I now think it is important for the generated assembler to work on 68000 for something as important as the C runtime library, so I would like the 68000 non-FP code like ldivs to be available.

This is from vbcc's clib:

Are you willing to make this ldivs etc support code public domain? Or do you know of an alternate public domain source? I have libnix for the Amiga, but I didn't find any 32-bit divide etc support.

Thanks. Paul.

[meynaf]

Originally Posted by kerravon

The code in question is the C runtime library. The code is required for anyone doing floating point stuff defined in C90. I don't want to break it for everyone (ie including non-68000 users). By putting dummy functions in, it would have just crashed and burned on the 68000.

Why sticking with C90 ? You could design your own programming language. C is too limited IMO.

Originally Posted by kerravon

AmigaPDOS is ... PDOS! PDOS is ... MSDOS! :-) Just a 32-bit version, hopefully running on the 68000 too. You will get MSDOS-like behavior from both the OS (AmigaPDOS) and applications (including any supported AmigaOS applications).

Why sticking with MSDOS ? (I know, i repeat myself sometimes ).
As i understand you want your OS to be universal and it's clearly the wrong candidate for that.

[kerravon]

Originally Posted by meynaf

Why sticking with C90 ? You could design your own programming language. C is too limited IMO.

One step at a time. :-) First I want to see the limits of C90. It was considered to be "portable assembler", and I like that idea.

Why sticking with MSDOS ? (I know, i repeat myself sometimes ).
As i understand you want your OS to be universal and it's clearly the wrong candidate for that.

Why do you think it's the wrong candidate? I need to start somewhere. That's what I was using in the late 1980s, and it was being commercially used. I wrote in portable C back then too, I didn't do MSDOS-specific programming.

[meynaf]

Originally Posted by kerravon

One step at a time. :-) First I want to see the limits of C90. It was considered to be "portable assembler", and I like that idea.

And when you know the limits of C90, what will you do ?

Originally Posted by kerravon

Why do you think it's the wrong candidate? I need to start somewhere. That's what I was using in the late 1980s, and it was being commercially used. I wrote in portable C back then too, I didn't do MSDOS-specific programming.

MSDOS is very limited. No multitasking, no gui, no api for graphics, sounds, etc. Even Microsoft had to throw it away.
But ok, one step at a time.

[kerravon]

Originally Posted by kerravon

Are you willing to make this ldivs etc support code public domain?

It occurred to me - can this support code be written in C? If so, I'd prefer that, and maybe I can write my own.

[kerravon]

Originally Posted by meynaf

And when you know the limits of C90, what will you do ?

Probably find out what the barrier is to doing the same thing with Pascal. ie an OS and applications completely written in Pascal with no assembler.

MSDOS is very limited. No multitasking, no gui, no api for graphics, sounds, etc. Even Microsoft had to throw it away.
But ok, one step at a time.

Yeah, we still don't have a public domain operating system as good as MSDOS. Everything is copyrighted. So when I've reached MSDOS capability, I'll look at expanding. I'm actually more interested in access the serial port so that I can run a BBS. It's not covered by the C90 standard and I don't think it can be coerced into it. I think it needs some extensions. But I'm not sure what those would look like. I'm open to suggestions. :-)

[kerravon]

Could someone help me with the code required to:

1. Save sp to a static variable in amistart
2. In exita, place return code into d0
3. Restore sp to saved value

Thanks. Paul.



*
section "CODE",code
xref ___start
xdef ___amistart
xdef ___exita

___amistart:
movem.l d0/a0/a6,-(sp)
jsr ___start
rts

* This function receives a return code as a parameter. The stack
* then needs to be restored and the parameter placed in register d0
* prior to return to the OS.

___exita:
rts

[kerravon]

I'm unclear about FreeMem:

http://amigadev.elowar.com/read/ADCD.../node0355.html

If I want to free all the memory I allocated, should I set the "desired block size" to 0?

Thanks.

[tolkien]

It should be the same bytesize you have used in allocmem.

[phx]

Originally Posted by kerravon

Are you willing to make this ldivs etc support code public domain? Or do you know of an alternate public domain source?

The m68k 32-bit division algorithm is common knowledge. You should find it somewhere (based on Donald Knuth's Algorithm D?). Otherwise just use what I pasted and strip the comments.


Writing it in C is possible, of course. But definitely slower.

Originally Posted by kerravon

Yeah, we still don't have a public domain operating system as good as MSDOS.

Er... what? How about BSD or Linux? At least the BSD-license is pretty close to public domain, and it should be hard to find any better OS.

[phx]

Originally Posted by kerravon

Could someone help me with the code required to:

1. Save sp to a static variable in amistart
2. In exita, place return code into d0
3. Restore sp to saved value

        section CODE,code
        xref    ___start
___amistart:
        move.l  sp,savedSP
        movem.l d0/a0/a6,-(sp)
        jmp     ___start

        xdef    ___exita
___exita:
        move.l  4(sp),d0
        move.l  savedSP,sp
        rts

        section BSS,bss
savedSP:
        ds.l    1

EDIT: Assuming __start() does never return, but always calls __exita().

[kerravon]

Originally Posted by phx

EDIT: Assuming __start() does never return, but always calls __exita().

Thanks so much! That was the final thing that I was waiting on so that I could create what I believe to be a technically-valid AmigaOS "hello, world" so I have emailed that to you.

I would like the assembler to be flexible enough to handle __start() returning, so I modified your code slightly.

There is still some work to do with getting things like rename() implemented for AmigaOS, but I'd like to see "hello, world" working first.

[kerravon]

Originally Posted by phx

The m68k 32-bit division algorithm is common knowledge. You should find it somewhere (based on Donald Knuth's Algorithm D?).

https://skanthak.homepage.t-online.de/division.html

Yikes.

Otherwise just use what I pasted and strip the comments.

I would like to use your code, but would it be possible for you to email me with the actual code (ie no comments) that you are happy to make public domain, and include an explicit "the below is public domain" or something like that? Preferably with your name in it. I'd like to have a written record of permission in case I am ever questioned about it. Then I can go back to 68000 which would be great.

Writing it in C is possible, of course. But definitely slower.

I'm not worried about the speed. I think it will be rare for this code to be exercised.

Er... what? How about BSD or Linux? At least the BSD-license is pretty close to public domain, and it should be hard to find any better OS.

As noted, both of those are licensed software. I am after code with absolutely no strings attached, ie an explicit public domain notice, and no following caveats. If I instead see an explicit "copyright", I will continue looking. :-) For whatever reason people are holding back on writing "public domain" and actually going to the effort to write "copyright", that's the reason I am holding back too. It's a very long road to assemble the required software, but there are a few people in the world interested. Not many, but a few. :-)

[kerravon]

I currently have this code in my AmigaOS executables:

#ifdef __AMIGA__
if (cmdlen >= 0x80000000UL)
{
cmdlen -= 0x80000000UL;
SysBase = (struct ExecBase *)pdosbase;
}
else
{
SysBase = *(struct ExecBase **)4;
}


So that I am not dependent on Commodore's
SysBase, and can add my own features to
AmigaPDOS, I was thinking that a6 should
point to an AmigaPDOS parameter block, and
the first element of that is a traditional
SysBase.

So SysBase is set and looks normal, but a new
set of API calls is opened up, via the second
element. I'm thinking the MSDOS API, like this:

ret = PosFindFirst(p, 0x10);

which will only do something sensible when
operating on an AmigaPDOS-controlled disk.

And to make things easier for the next person,
I'll have a reserved word after that.

Any flaw in this concept?

Thanks. Paul.