04 March 2021, 12:03 | #41 | ||||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,546
|
Quote:
Quote:
Just note that without AmigaOS such PPC hardware is no Amiga at all. It has no Amiga hardware. It is a UBoot- or OpenFirmware based PPC-board with standard components. You will boot with the firmware, which in fact is comparable to a BIOS. Quote:
jsr -offset(a6)call to the function's library vector offset. This is probably nothing the m68k backend of your compiler can generate, so you will need a linker library with a small assembler stub function to do these calls (amiga.lib). Quote:
If you want to take over the system, then you need to be prepared for all kinds of M68k CPUs (68000 up to 68060), FPUs and MMUs, countless expansion boards and memory layouts. But I guess this is no longer an option for you, as you want to access a hard disk, and you don't even know which IDE or SCSI chip the controller board uses! |
||||
04 March 2021, 12:17 | #42 |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Great! I think that's everything I need. I think I'm looking at under 200 lines of C code to be added to PDPCLIB. Plus under 100 lines of assembler to implement setjmp/longjmp.
Then I need maybe 100 lines of header files to contain structures like ExecBase. I only need to populate the fields I'm actually interested in, and will have "filler" for the rest. These structures would be provided by the OS (AmigaPDOS) rather than PDPCLIB. AmigaPDOS also needs to provide amiga.lib containing Read() etc. I think that is the only library I need to actually provide. That's probably 200 lines of code. Does the DOSBase global variable belong in PDPCLIB or amiga.lib? ie do existing C compilers put the variable in their C library or does Commodore provide it in some *.library (for the first Amiga 1000)? The first step would be to get the above running under some existing C compiler such as SAS/C, assuming SAS/C allows you to bypass their own header files and libraries. Then a "hello, world" will start working. It is this "hello, world" that I want to run on AmigaPDOS in the medium term, but not the short term. That would be the end of my involvement with AmigaOS and SAS/C. Then I would want GCC 3.2.3 for 68000 to be compiled as a cross-compiler on my Windows machine. Then GCC will start producing 68000 assembler, which looks like this: cmp%.w %0,%1 fpmove%.l %x1,%x0 I don't know if that is the same format that SAS/C accepts, but it's not that important, as the next step is to build binutils, possibly version 2.14a, as that is what I am currently using to produce executables for PDOS/386. It looks to me like it can produce a.out format executables for 68000. a.out is a format PDOS can already handle. I don't see support for Amiga "hunk" format. I can modify PDOS to start putting a structure pointer into memory location 4, to make it AmigaOS-like. Accepting OS calls via location 4 instead of INT 21H shouldn't be a big deal. I will not have a switch between application mode and OS mode, everything will run in OS mode, in a single memory space. If a suitable BIOS is available, I'm hopefully looking at 500 lines of C code to be added. I'll keep interrupts disabled so that I don't need much/any 68000 assembler. Assuming a IBM-PC-style BIOS is available (instead of Kickstart), it will need to have the ability to load the first (boot) sector from a FAT-formatted floppy, which will need to be written in 68000 assembler. Or an MBR plus boot sector from a hard disk. This will then load the loader (IO.SYS), which needs to be located in consecutive sectors. It is 18k in size. This then loads the kernel (MSDOS.SYS), which can be located anywhere in the root directory and is about 100k in size. Then I will be running Amiga programs, just not in Amiga hunk format. Then in the medium term I can add Amiga hunk format to what PDOS supports. Currently it supports ELF and a.out and Windows executable formats. So then the "hello, world" I described above will immediately start working. In the longer term, hopefully someone will update binutils to make it produce Amiga hunk format. Or provide an independent assembler and linker. These may even already exist. They need to be restricted to just use Read etc that AmigaPDOS actually supports. Also in the longer term, support for the Amiga file system can be added to AmigaPDOS, including Amiga-style hard disks which presumably require a different MBR too. Or maybe this bit won't be technically possible? Anything I've missed? Thanks. Paul. |
04 March 2021, 12:43 | #43 | |||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,317
|
Quote:
Quote:
Quote:
All the details, of course, and this sounds more like a work plan for the next years to come, of course... |
|||
04 March 2021, 12:46 | #44 | |
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,748
|
Quote:
On the up side though, you should not need any assembler if you only use OS functions. |
|
04 March 2021, 13:07 | #45 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
Also, even if I do enable interrupts, how many different interrupts will the hardware generate? Is it just the timer interrupt? And I would actually expect that to have a default handler in the new BIOS. Right? I don't think the BIOS can have a requirement for the operating system to take ownership of interrupts by a particular point. |
|
04 March 2021, 13:36 | #46 | ||
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
#ifdef MOTOROLA #ifdef SGS /* Many SGS assemblers croak on size specifiers for constants. */ return "lea 0,%0"; #else return "lea 0.w,%0"; #endif #else return "lea 0:w,%0"; #endif Quote:
Is there anyone interested in assisting with this initial task? No coding is required. I will provide approx 16 68000 assembler files that need to be assembled and linked by an AmigaOS assembler and linker, and then run on AmigaOS. If you can tell me the command required to assemble a file, and to link 16 object files, I will write a simple script. It will probably take a number of iterations before it works. I will do the development in public to give people (anyone) an opportunity to point out any problem they can see. I don't care if AmigaOS is being run emulated or on real hardware, and I don't care if the assembler and linker being used are commercial or freeware. Actually, I'm happy to start doing this with the RS6000 target, instead of 68000, if someone is willing to assist with assembling and testing that. The RS6000 target produces assembler that looks like this: {andil.|andi.} %0,%1,0xff {cau|addis} %0,%1,ha16(%2) So your assembler will need to be able to cope with that. Thanks. Paul. |
||
04 March 2021, 14:00 | #47 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,546
|
|
04 March 2021, 14:17 | #48 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,546
|
Quote:
http://sun.hasenbraten.de/vasm/ Build it with make CPU=m68k SYNTAX=stdand it should be able to consume GCC assembler output, with option -gas. Use option -Fhunk for hunk-format object files and -Fhunkexe for hunk format executables. It's all free and portable ISO-C99 source. If you need a portable cross linker: http://sun.hasenbraten.de/vlink/ Build it with "make". Option -bamigahunk outputs hunk-format. All C99. Quote:
And "ha16" is usually written as "@ha, attached to label, to select 16-bit halfword relocation of the MSW. |
||
04 March 2021, 14:21 | #49 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
Even if there is no BIOS available, I'd still like to get PDPCLIB ported to both 68000 and RS6000 flavors of AmigaOS before I move on though. Also, I realized something else - I'm happy to send C code instead of 68000 assembler files if someone would like to build PDPCLIB for the Amiga with their current C compiler. I could then delay the building of the GCC cross-compiler for Windows until I know PDPCLIB can be made to work. The C code can be downloaded from Sourceforge as a snapshot, or "git" can be used. |
|
04 March 2021, 14:47 | #50 | |||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,546
|
Quote:
EDIT: BTW, if you want to target an 68k system with PDOS, the Atari ST may be more suitable. It even has a BIOS, and no multitasking OS. Quote:
Quote:
Last edited by phx; 04 March 2021 at 14:48. Reason: Atari |
|||
04 March 2021, 14:53 | #51 | |||
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
Quote:
Quote:
|
|||
04 March 2021, 15:23 | #52 | |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,546
|
Yes.
BTW, not all Amigas have an RTC chip. But I guess a wrong time doesn't matter, as long as you get any time. Quote:
(If you don't find my email address, e.g. in the vasm doc, drop me a private message on EAB.) |
|
04 March 2021, 22:24 | #53 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
Also thanks to Volker pointing me to his website, I am going to start by using his C compiler as well, instead of GCC. I believe I have successfully built the compiler, assembler and linker from his website on my Windows box using gcc from Cygwin. |
|
05 March 2021, 07:23 | #54 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
In order to execute Read(), were you nominally required to #include <clib/dos_protos.h> (and did that exist in the first SDK?) I'm thinking that I would like to have the above header file, but make it: #define Read(a, b, c) DOSBase->Read(a,b,c) rather than having a normal prototype and a real function. It would be transparent to any application that was following the rules. Is there anything wrong with that approach? Thanks. Paul. |
|
05 March 2021, 07:49 | #55 |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Rather than use gcc 3.2.3 with the 68000 target, I'd like to try Volker's C compiler instead.
I'd prefer to execute the compiler directly, not requiring vc with a config file. And just generate the assembler file. That's how I run gcc too. I get these errors: vbccm68k -gas -I . -I ../src -S -o amistrt.s amistrt.c error 5: Unknown Flag <-S> vbccm68k -gas -I . -I ../src -o amistrt.s amistrt.c error 3: Flag <-o> needs string Anyone know what parameters are required? I'd rather generate .s than .asm because .s are temporary assembler files in PDPCLIB, while .asm is genuine source code. Thanks. Paul. |
05 March 2021, 10:56 | #56 | ||||||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,546
|
Quote:
Quote:
Quote:
Quote:
Code:
xref _DOSBase xdef _Read _Read: movem.l d2-d3/a6,-(sp) movem.l 16(sp),d1-d3 move.l _DOSBase,a6 jsr -42(a6) movem.l (sp)+,d2-d3/a6 rts Quote:
Quote:
|
||||||
05 March 2021, 12:37 | #57 | |||
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
Quote:
#define Read(a,b,c) (int (*)())((char *)DOSBase - 40)(a,b,c) Also, is there a way of deriving these offsets from this: http://amigadev.elowar.com/read/ADCD.../node0075.html I don't know how to convert: LIBENT Read into offset 42. No matter which direction I count from. Quote:
|
|||
05 March 2021, 13:49 | #58 | ||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,317
|
Quote:
Code:
<pragmas/dos_pragmas.h> which defines Read() in a way that is most convenient for the compiler. Do not roll your own, somebody else did that already for you. Quote:
Just a matter of warning: If your program runs from the boot block of the disk, then there will be no dos.library at that point. It is rather initialized by the boot block. |
||
05 March 2021, 13:53 | #59 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,546
|
Quote:
Passing arguments in registers is compiler specific. And your syntax was wrong. Maybe something like: Code:
#define Read(a,b,c) ((int (*)(__reg("d1")int, __reg("d2")int, __reg("d3")int))(*(char **)((char *)DOSBase-40)))(a,b,c) Quote:
Usually you will use FD files (dos_lib.fd), which define the the offset and register arguments of library functions. These FD files can be used as input for tools like fd2pragma, which can generate anything you need. From assembler stub functions over compler-specific inline code to a complete linker library. Portable source is here: http://phoenix.owl.de/fd2pragma.tar.gz |
||
05 March 2021, 14:18 | #60 | |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,546
|
Quote:
<proto/libname.h>and your compiler vendor will guarantee to include the optimal pragma/inline solution. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
|
|