PDOS for Amiga

[phx]

Originally Posted by kerravon

Note that once the work had already been done to make GCC C90-compliant (which was done as a separate project), GCC is basically a glorified "hello, world".

You mentioned the C90-compliancy multiple times now. What do you mean?
I know gcc is not 100% ISO-C compliant in its default setting (which is a bad idea for portability with other compilers), but isn't it just a matter of the option

-std=c90

or

-ansi

?

Originally Posted by kerravon

Another piece of information. PDOS/386 has no device drivers.

As Roondar already indicated this will never work on an Amiga. There is no BIOS (simple interrupt handler from the 70s), but a full-blown multitasking OS in ROM, immediately when you switch on the system.

So when you don't want to run as an application under AmigaOS you will have to do everything yourself and access the hardware chips directly. Also note that there is not even a standard FDC chip to access floppy disk dirves, but you have to do everything yourself: turning on the motor, step the head, start the disk-DMA, decode the MFM-data...

[Thomas Richter]

Originally Posted by roondar

Well, you can - to a point. You are not required to use all of Kickstart when booting from floppy. However, that might still not be as helpful as you'd hope.

Hold on. No. This is a binary decision. You either use all of the os, or none of the Os. The only other decision point is whether you continue booting into the "dos.library" (aka the Tripos layer) or use it without, but that is as far as it goes. You cannot use the trackdisk.device for accessing the floppy without the rest of the system.

Originally Posted by roondar

Essentially, the issue as I understand it is that the trackdisk device in the Kickstart (which you'd need to use to read sectors from disk at the lowest supported level) is not built to be independent of the rest of the OS. Basically, the trackdisk device relies on the kernel for memory allocation and probably runs as a task under Exec as well.

It *definitely* runs as an exec task, and it requires exec, the cia.resources, the timer.device, the disk.resource and the graphics.library. So no, it cannot be run "independently".

Originally Posted by roondar

If you want to stay compatible with that, you might have to define areas of memory that you can't interact with.

You cannot use "trackdisk only". That is not going to work. You can allocate sufficient memory for yourself and run as an exec task, bu you cannot run without the rest of the system without "overtaking" the system entirely. You can run the system without the dos.library and everything that is beyond that - this is a decision you can take. But a system booted to this point already has graphics and intuition, essentially a full-blown system just without the file systems.

Originally Posted by roondar

Basically, the issue is that for the Amiga, the BIOS and the OS are essentially intertwined to a high degree and that there is no official way to bypass this and just say, read a sector from a disk.

There is no "Bios". There is kickstart. From within the boot sector of the floppy, you have the ability to read arbitrary sectors from disk, as you get the IORequest for floppy IO passed in. That is, you can run without Dos. But you cannot run without exec, graphics or intuition. They are all initialized before the boot sector picks the activity. The only thing it usually does is to initialize the dos.library and thus continue the bootstrap process from that point.

[Docent]

Originally Posted by kerravon

Yes, I want to do this - but it will be a minimal implementation. Just enough to run C90 programs - and specifically C90 programs that have been built using PDPCLIB.

Taking over the hardware can be done but it will significantly limit the possibility to use any of the additional devices or expansion cards - their drivers are offered as system devices and require AmigaOS to run. You'll be limited to default PAL/NTSC display, builtin keyboard, serial and floppy.
Additionally, bear in mind that Amiga hardware is more complex than most of its competitors. For example, the floppy controller is not a simple pc controller that only requires to specify track/sector number to read it. Its a DMA controller that reads the whole track in MFM format and you need to decode it yourself to read a sector.
Get "Amiga Hardware Reference Manual Third Edition" from here https://commodore.bombjack.org/amiga/amiga-books.htm You'll find there the information on Amiga hardware directly from the source

Now, As I wrote earlier in order to recreate some of AmigaOS functionality, you'll need to implement a number of libraries and devices.
Amiga doesn't have any sort of minimal BIOS, its Kickstart contains all required libraries and devices and it is initialized when the computer is turned on.
Get "Amiga ROM Kernal Reference Manual Libraries Third Edition" and "Amiga ROM Kernal Reference Manual Devices Third Edition" from the link above and see yourself that there is no way to build some minimal implementation without reimplementing most of exec.library and a number of devices. Things like memory management, interrupt handling, task management, scheduling, libraries/devices handling need to be implemented with exact clones of all AmigaOS structures for compatibility.
Basically, you need to implement the whole microkernel functionality.

Originally Posted by kerravon

Ok, thanks for the pointer.

I found this:

https://wiki.amigaos.net/wiki/Basic_...ut_Programming

BPTR myfilehandle = IDOS->Open(UBYTE* filename, LONG accessMode);

That looks doable to me.

This is for AmigaOS4. This version targets PPC cpus, you'll probably want to target Motorola 68k based Amiga classic systems, ie. Kickstart 1.3,2.0, 3.0 or 3.1. There is no interfaces there, just plain Open/Close calls. See the books I listed above for details.

Originally Posted by kerravon

PDPCLIB implements PDOS/386 (a 32-bit version of MSDOS, basically) with the use of Pos*() function calls, which you can see here (with some edits to avoid confusion):

So basically for AmigaOS I need to replace PosOpenFile() with Open().

If I use the Open() from dos.library that comes with a recent version of AmigaOS, will the resulting executable actually work on the very first version of AmigaOS on the Amiga 1000?

Unless you use functions that were added later for KS 2.0 or 3.0 it should work - usually API in newer Kickstarts is compatible with previous versions.

Originally Posted by kerravon

I would like PDPCLIB to be able to be used with the standard dos.library, but I would also like to build my own mini dos.library with just Open() etc that PDPCLIB actually needs.

As I mentioned earlier, it will be quite easy to use dos.library when running hosted. But even mini dos.library reimplementation will require other system components to be recreated. For your PDPCLIB, just redirect all Open/Close/Read/Write calls to their counterparts in dos.library. You'll just need to have initialized DosBase first.

Originally Posted by kerravon

Regardless, when I have my executable that calls Open(), what does that executable actually look like? Is there some code linked in that does an INT like MSDOS, or is there a DLL reference like Windows uses, and the AmigaOS (or AmigaPDOS) loader will modify the executable to provide a pointer to the code that needs to be executed?

Thanks. Paul.

In order to call a function in a library, you need to have an initialized library base. To get initialized library base, the library needs to be opened first.
There is one library (exec.library) that is always open and its LibraryBase is usually at $4 address. Exec.library contains functions to open/close other libraries and devices. So, to call a function from dos.library, first you need to call OpenLibrary from exec.library with "dos.library" as a name and 0 for any version. If this function succeeded, you'll get from it a pointer to DosBase. AmigaOS includes/pragmas resolve dos.library's Open call to a call relative to DosBase, so you need initialized DosBase first to perform any dos library function calls. This is also the case for any other library or device.
In an executable, generated assembly code is usually in the form of jsr -440(a6), where DosBase is first loaded in register a6 and -440 is a negative offset in jumptable, containing jump to address of called function in a library.

[roondar]

Originally Posted by Thomas Richter

Hold on. No. This is a binary decision. You either use all of the os, or none of the Os. The only other decision point is whether you continue booting into the "dos.library" (aka the Tripos layer) or use it without, but that is as far as it goes. You cannot use the trackdisk.device for accessing the floppy without the rest of the system.

This is a matter of definition. What I meant is that you don't need nearly all libraries and/or devices in memory to use the trackdisk.device. Obviously, you will need to actually be running the OS.

So no, it cannot be run "independently".

So, you're telling me that I was correct to point this out. Thanks, I guess?

You cannot use "trackdisk only". That is not going to work. You can allocate sufficient memory for yourself and run as an exec task, bu you cannot run without the rest of the system without "overtaking" the system entirely. You can run the system without the dos.library and everything that is beyond that - this is a decision you can take. But a system booted to this point already has graphics and intuition, essentially a full-blown system just without the file systems.

It obviously can work, WHDLoad does exactly this. As do many demos and games that run from the OS, yet deactivate it while the game/demo is running. Now, I'd agree it's silly to run an OS on top of Amiga OS in this way, nor am I saying it's a wise course of action. But that doesn't change the facts.

There is no "Bios". There is kickstart. From within the boot sector of the floppy, you have the ability to read arbitrary sectors from disk, as you get the IORequest for floppy IO passed in. That is, you can run without Dos. But you cannot run without exec, graphics or intuition. They are all initialized before the boot sector picks the activity. The only thing it usually does is to initialize the dos.library and thus continue the bootstrap process from that point.

You're misunderstanding what I'm saying. Perhaps I wasn't very clear about it though. What I mean is that the functions you'd find in a BIOS on other systems (which is what the OP was talking about) are part of the OS on the Amiga. Hence the functionality normally found in a BIOS and OS functionality is 'intertwined' as there is no such thing as a BIOS on the Amiga.

This is a follow up to earlier comments of mine, where I literally said "The traditional BIOS functionality from the PC doesn't exist as such in the Kickstart, it's all mixed in the with the Amiga OS". Context is key here.

[kerravon]

Originally Posted by phx

You mentioned the C90-compliancy multiple times now. What do you mean?
I know gcc is not 100% ISO-C compliant in its default setting (which is a bad idea for portability with other compilers), but isn't it just a matter of the option

-std=c90

or

-ansi

?

My derivative of GCC 3.2.3 does not use Unix open() and various other Posix calls. GCC is fundamentally a program that reads a bunch of text files and outputs another text file (an assembler program). This is something that can be done purely using C90, and now it does. My GCC is a single executable, so there is no need to worry about fork()/exec() or even system() to work.

It's a 3 MB executable.

As Roondar already indicated this will never work on an Amiga. There is no BIOS (simple interrupt handler from the 70s), but a full-blown multitasking OS in ROM, immediately when you switch on the system.

Ok, this is another spanner in the works. And explains why Commodore don't want to release even an old version for free.

What about the Amiga 1000? Kickstart is not in ROM. How are the sectors of a floppy disk read without Kickstart being available? Maybe I want to target the Amiga 1000 purely, and for other environments (like Amiga 500) assume that the Kickstart ROM has been replaced with whatever the Amiga 1000 has in ROM (ie ignoring the Amiga 1000 Kickstart disk).

So when you don't want to run as an application under AmigaOS you will have to do everything yourself and access the hardware chips directly. Also note that there is not even a standard FDC chip to access floppy disk dirves, but you have to do everything yourself: turning on the motor, step the head, start the disk-DMA, decode the MFM-data...

Wow. Ok, I didn't expect to be involved in turning on the motor. I didn't need to do this on the IBM PC (where the BIOS was available) or on the mainframe (where you construct a CCW and send the request to the channel subsystem).

[phx]

Originally Posted by kerravon

My derivative of GCC 3.2.3 does not use Unix open() and various other Posix calls. GCC is fundamentally a program that reads a bunch of text files and outputs another text file (an assembler program). This is something that can be done purely using C90, and now it does. My GCC is a single executable, so there is no need to worry about fork()/exec() or even system() to work.

Good job! It means you can compile this GCC version on any system with a working ANSI-C compiler!? That's real portability, and that's how it should have been done from the beginning. Congratulations!

What about the Amiga 1000? Kickstart is not in ROM. How are the sectors of a floppy disk read without Kickstart being available?

There is a small Boot ROM, which can do nothing else than loading 256K of a kickstart disk into the WOM (Write-Once Memory).
You can use it to load your OS instead, but afterwards you still have to do everything yourself.

[kerravon]

Originally Posted by phx

Good job! It means you can compile this GCC version on any system with a working ANSI-C compiler!? That's real portability, and that's how it should have been done from the beginning. Congratulations!

Yes, exactly. I used to compile GCC 3.2.3 with different C compilers to use debugging facilities, but it's been a long time since I did that. The 68000 target will use some extra source that wasn't compiled with either the mainframe or 80836 targets, so there's a possibility something there doesn't work and will need a bit more work to be done. I normally only build GCC 3.2.3 with other versions of GCC, not other C compilers. I do cross-compilation as well.

There is a small Boot ROM, which can do nothing else than loading 256K of a kickstart disk into the WOM (Write-Once Memory).
You can use it to load your OS instead, but afterwards you still have to do everything yourself.

Ok, based on all of this, I have a new proposal.

How about first step is write a 32-bit IBM PC-like BIOS to enable porting of IBM PC operating systems?

Here are the main BIOS functions I currently use:

C:\devel\pdos\src>grep Bos pdos.c
bootedAt = BosGetClockTickCount();
memavail = BosExtendedMemorySize();
rc = BosFixedDiskStatus(x);
BosReadKeyboardCharacter(&scan, &ascii);
BosReadKeyboardCharacter(&scan, &ascii);
retval = BosGetSystemDate(&c,&y,&m,&d);
BosSetSystemDate(year / 100,year % 100,month,day);
BosGetSystemTime(&ticks,&midnight);
BosReadKeyboardCharacter(&scan, &ascii);
rc = BosDiskSectorRead(readbuf, 1, drive, track, head, sect);
BosDiskReset(drive);
rc = BosDiskSectorRLBA(readbuf, 1, drive, sector, 0);
BosDiskReset(drive);
rc = BosDiskSectorWrite(writebuf, 1, drive, track, head, sect);
BosDiskReset(drive);
rc = BosDiskSectorWLBA(writebuf, 1, drive, sector, 0);
...


Here is a simple example:

/* BosWriteText - BIOS Int 10h Function 0Eh */ int BosWriteText(int page, int ch, int color) { union REGS regsin; regsin.h.ah = 0x0e; regsin.h.al = ch; regsin.h.bh = page; regsin.h.bl = color; int86i(0x10 + BIOS_INT_OFFSET, &regsin); return (0);
}


So Kickstart would be replaced by this BIOS. ie the BIOS would be loaded by the Amiga 1000, and install some interrupt vectors, not necessarily interrupt 0x10, and then wait for the OS disk to be inserted. The OS could be PDOS or Linux or FreeBSD, whatever. (Assuming they used the non-existent 32-bit BIOS, which they probably don't, but PDOS/386 basically does).

Actually I would be happy if BosWrite() even did graphics conversion instead of writing to the serial port. So long as it is in the BIOS code, not the OS code. If the hardware hasn't provided text capabilities, then the BIOS should be the thing that compensates for the hardware, it shouldn't be left to the OS to do. That's my current thinking, anyway. That's what "feels right" to me. The BIOS should be providing this hardware separation layer.

Having proposed this, ie a deviation from Commodore Kickstart, does this buy me anything:

https://en.wikipedia.org/wiki/AROS_R...erating_System

A workable AmigaOS Kickstart clone for the Motorola 68000 processor was released on March 31, 2011 as part of a programming bounty.


Perhaps this alternate kickstart can be hacked into an actual BIOS? It may even contain character to graphics conversion capability already?

[kerravon]

Originally Posted by roondar

As I understand it, the current OS 4.0 solution to this problem is to call an emulator to run the 68K application.

Ok, I don't want that. I would instead like a separately-built PDOS and applications for the PPC.

I took a look at GCC 3.2.3 and there is a target called "rs6000". Do you think that would produce code that will run on these newer flavors of Amiga hardware? I'm still talking about 32-bit of course.

[kerravon]

Originally Posted by Docent

Taking over the hardware can be done but it will significantly limit the possibility to use any of the additional devices or expansion cards - their drivers are offered as system devices and require AmigaOS to run. You'll be limited to default PAL/NTSC display, builtin keyboard, serial and floppy.

I'm happy to have just a handful of devices, but I do require a hard disk. I do want to distribute a hard disk image with all the GCC source code on it. Just the GCC executable itself takes up 3 MB, ie more than a floppy can handle.

Additionally, bear in mind that Amiga hardware is more complex than most of its competitors. For example, the floppy controller is not a simple pc controller that only requires to specify track/sector number to read it. Its a DMA controller that reads the whole track in MFM format and you need to decode it yourself to read a sector.

Ok, thanks.

Things like memory management, interrupt handling, task management, scheduling, libraries/devices handling need to be implemented with exact clones of all AmigaOS structures for compatibility.
Basically, you need to implement the whole microkernel functionality.

No, this is way out of my scope. There won't be any "tasks" at all. It will be a single-tasking OS. But yes, I do want to eventually run a "hello, world" Amiga hunk, after first getting a Pos*() ELF executable to work.

In order to call a function in a library, you need to have an initialized library base. To get initialized library base, the library needs to be opened first.
There is one library (exec.library) that is always open and its LibraryBase is usually at $4 address. Exec.library contains functions to open/close other libraries and devices. So, to call a function from dos.library, first you need to call OpenLibrary from exec.library with "dos.library" as a name and 0 for any version. If this function succeeded, you'll get from it a pointer to DosBase. AmigaOS includes/pragmas resolve dos.library's Open call to a call relative to DosBase, so you need initialized DosBase first to perform any dos library function calls. This is also the case for any other library or device.
In an executable, generated assembly code is usually in the form of jsr -440(a6), where DosBase is first loaded in register a6 and -440 is a negative offset in jumptable, containing jump to address of called function in a library.

Ok, thanks. What I'd like to know is how DosBase is set by OpenLibrary. Is the Amiga hunk executable passed some pointer at startup, or does OpenLibrary() do an interrupt to retrieve the DosBase from AmigaOS?

[Thomas Richter]

Originally Posted by kerravon

No, this is way out of my scope. There won't be any "tasks" at all. It will be a single-tasking OS. But yes, I do want to eventually run a "hello, world" Amiga hunk, after first getting a Pos*() ELF executable to work.

If you have the trackdisk.device to access the disk, you have tasks. If you have the dos.library, you have tasks.

Originally Posted by kerravon

Ok, thanks. What I'd like to know is how DosBase is set by OpenLibrary.

It isn't. It is the job of the caller to get the return code from OpenLibrary and store it in DOSBase, which is a "global" of the program. There are no interrupts involved in the system function. It is really only:

struct DosLibrary *DOSBase;


int main(int argc,char **argv)
{
DOSBase = OpenLibrary("dos.library",40);
...
}

and *that* is it. However, it is typically part of the startup code supplied witht the compiler to open this library.

[kerravon]

Originally Posted by Thomas Richter

If you have the trackdisk.device to access the disk, you have tasks. If you have the dos.library, you have tasks.

I can't answer this at this point, but I can tell you that someone else who actually wrote a large amount of the assembler in the MVS version of PDPCLIB insisted that there was no way that my 5000-line or whatever PDOS/3X0 could possibly run an MVS executable because it needed (all sorts of MVS things). But he was certainly wrong about PDOS/3X0. I was able to implement the actual MVS calls I was actually using in PDPCLIB without remotely copying how real MVS was doing things. It wasn't necessarily pretty, but it did in fact work.

It isn't. It is the job of the caller to get the return code from OpenLibrary and store it in DOSBase, which is a "global" of the program. There are no interrupts involved in the system function. It is really only:

DOSBase = OpenLibrary("dos.library",40);

and *that* is it. However, it is typically part of the startup code supplied with the compiler to open this library.

Yes, but that's my question. At some point I would like to write that "startup code". I'm trying to scope the problem. I'd like to know how OpenLibrary() manages to return that DOSBase pointer (DOSBase in particular, that's probably the only one I actually care about) to the caller. Is the entire dos.library linked in to every executable, and even if it is, is the Read() functionality (accessed via DOSBase) just a "stub" that does an interrupt, or does it link to some DLL somehow?

[Thomas Richter]

Originally Posted by roondar

This is a matter of definition. What I meant is that you don't need nearly all libraries and/or devices in memory to use the trackdisk.device. Obviously, you will need to actually be running the OS.
So, you're telling me that I was correct to point this out. Thanks, I guess?
It obviously can work, WHDLoad does exactly this.

Not really. It tries its best to store the machine state, take over the system completely, and in this state, the called games cannot call the Os. It also tries to restore the state.


However, see the autodocs: You cannot block the interrupts for an elongated time and hope that the system returns in proper shape. It probably works on your system, due the imense work that went into this hack, but that doesn't mean that the system supports this type of activity.

[roondar]

Originally Posted by Thomas Richter

Not really. It tries its best to store the machine state, take over the system completely, and in this state, the called games cannot call the Os. It also tries to restore the state.

However, see the autodocs: You cannot block the interrupts for an elongated time and hope that the system returns in proper shape. It probably works on your system, due the imense work that went into this hack, but that doesn't mean that the system supports this type of activity.

Well, I didn't mean to say it was supported by the OS because that is clearly not true. I meant to say that it's possible to do it regardless (especially if you don't desire to return to the OS afterwards), even though it's not recommended in any way. As far as I know, WHDLoad is one of the most used tools on the Amiga and works across a wide variety of system configurations - not just my A1200 or A600

It is however certainly true it doesn't always (fully) work. IIRC it has some issues with networking in particular and no doubt it may have other incompatibilities as well. Overall, the best advice IMHO would still be to either use the OS or not use it at all.

[Thomas Richter]

Originally Posted by kerravon

Yes, but that's my question. At some point I would like to write that "startup code".

The line I placed there is (part of) the startup code.

Originally Posted by kerravon

I'm trying to scope the problem. I'd like to know how OpenLibrary() manages to return that DOSBase pointer (DOSBase in particular, that's probably the only one I actually care about) to the caller.

In a nutshell, OpenLibrary() is part of the exec.library, and as part of the call, it receives the SysBase library implicitly as its argument. What OpenLibrary() does is that it searches the available libraries in SysBase, present there, and searches over the libraries, and returns the one named "dos.library".

struct Library *OpenLibrary(const char *name) 

{
  struct Library *l;


 for(l = SysBase->LibList.lh_Head;l->lib_Node.ln_Succ;l = l->lib_Node.ln_Succ) {
 if (!strcmp(name,l->lib_Node.ln_Name))
   return lib;
 }


 return NULL
}

Of course, there's a bit more than this (version checking, disk access if not found), but that's the pattern. There is no interrupt here anyhwere.

Originally Posted by kerravon

Is the entire dos.library linked in to every executable, and even if it is, is the Read() functionality (accessed via DOSBase) just a "stub" that does an interrupt, or does it link to some DLL somehow?

There is nothing linked. The executable just retrieves the library pointer, and in that library is an array of functions, one of which is Read(). In old times, there was still a set of "stub functions" in amiga.lib which called through the function pointer array of the library, but today, most compilers create the indirect jump through the function pointer array of the library transparently.

[Bruce Abbott]

Originally Posted by kerravon

Ok, based on all of this, I have a new proposal.

How about first step is write a 32-bit IBM PC-like BIOS to enable porting of IBM PC operating systems?

Yes.

So Kickstart would be replaced by this BIOS. ie the BIOS would be loaded by the Amiga 1000, and install some interrupt vectors, not necessarily interrupt 0x10, and then wait for the OS disk to be inserted. The OS could be PDOS or Linux or FreeBSD, whatever. (Assuming they used the non-existent 32-bit BIOS, which they probably don't, but PDOS/386 basically does).

Yes, you could do that. On the A1000 it would be loaded into the WCS (Writeable Control Store) from floppy disk. On other machines it could be loaded into RAM or burned into a ROM.

Actually I would be happy if BosWrite() even did graphics conversion instead of writing to the serial port. So long as it is in the BIOS code, not the OS code. If the hardware hasn't provided text capabilities, then the BIOS should be the thing that compensates for the hardware, it shouldn't be left to the OS to do. That's my current thinking, anyway. That's what "feels right" to me. The BIOS should be providing this hardware separation layer.

Yes, that could be done.

Having proposed this, ie a deviation from Commodore Kickstart, does this buy me anything:

https://en.wikipedia.org/wiki/AROS_R...erating_System

A workable AmigaOS Kickstart clone for the Motorola 68000 processor was released on March 31, 2011 as part of a programming bounty.

Not much. Being a clone of Amiga OS it has a lot of stuff in it that doesn't apply to you.

Perhaps this alternate kickstart can be hacked into an actual BIOS? It may even contain character to graphics conversion capability already?

Yes, but using it would be a lot more work than writing code from scratch specifically for your application. You just have to understand how the hardware works in sufficient depth to get the stuff you need going.

The IBM PC BIOS was written in assembler. I suggest you do the same for your BIOS, then you can make use of code from games that take over the system (which are almost always written in pure assembly language). This BIOS could also be used in other 68k based machines, including DIY computers - something I have been thinking of doing myself.

You might be interested in a program for the Amiga called 'The Transformer' - a PC emulator that was launched with the A1000 - which does something quite similar to what you propose. It has all the standard PC BIOS functions (including reading and writing 720k FAT format disks), plus an x86 CPU emulator to run PC code. When the program is run it takes over the entire machine, installs its own interrupt vectors and controls the hardware directly, including character based screen output.

Unfortunately the source code to the Transformer seems to have been lost, however I have disassembled the exe and am working on making it compatible with higher spec Amigas. If this is successful then I will split off the x86 emulator part to make a standalone BIOS that could be used on an Amiga or other 68k hardware.

[kerravon]

Originally Posted by Thomas Richter

for(l = SysBase->LibList.lh_Head;

Thanks. That's getting closer to what I need. How does SysBase get set? At some point there needs to be some sort of communication between the OS and the executable, whether that is an interrupt, a parameter passed at startup, or a DLL. I can't think of any other way to do it. Well, unless the entire functionality is linked into the executable, directly manipulating the hardware and bypassing the OS altogether.

In old times, there was still a set of "stub functions" in amiga.lib which called through the function pointer array of the library, but today, most compilers create the indirect jump through the function pointer array of the library transparently.

Ok, so this function Read():

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

would have resided in amiga.lib?

I think I would like to revive that, to be able to build PDPCLIB (and thus GCC etc) according to the official docs of the Amiga 1000, and have the source still work in newer 68k environments.

[kerravon]

Originally Posted by Bruce Abbott

The IBM PC BIOS was written in assembler. I suggest you do the same for your BIOS, then you can make use of code from games that take over the system (which are almost always written in pure assembly language). This BIOS could also be used in other 68k based machines, including DIY computers - something I have been thinking of doing myself.

I dislike writing in assembler, except for small stubs with no loops. So reworking someone else's assembler is not something I want to do. I'd rather write my own in 99% C90.

Unfortunately the source code to the Transformer seems to have been lost, however I have disassembled the exe and am working on making it compatible with higher spec Amigas. If this is successful then I will split off the x86 emulator part to make a standalone BIOS that could be used on an Amiga

That sounds good. I'm not that interested in the BIOS, so if you're providing that (I assume it is some sort of freeware?), that would be great. Do you have a timeframe when you would expect a basic BIOS to be available?

or other 68k hardware.

Other 68k hardware would require a different BIOS, wouldn't it? The interface could be the same, but it needs to manipulate different graphics chips or whatever.

[Thomas Richter]

Originally Posted by kerravon

Thanks. That's getting closer to what I need. How does SysBase get set?

That is the only constant in AmigaOs, and the only part of the memory map that never gets changed. You find a pointer to SysBase in memory location 4. The startup code picks it up from there, and stores it in the global variable SysBase, i.e.

SysBase = *((struct ExecBase **)(4L));

Originally Posted by kerravon

Ok, so this function Read():

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

would have resided in amiga.lib?

Yes, though as said, it doesn't do much. It would have an external reference to DosBase, would load that into register a6, would get the arguments off the stack, where the compiler put them, and would deposit them into the input registers of the Os function, namely into registers D1 through D3, and then would call indirectly through an offset in DosBase, and return the result back in D0.


Today, compilers do not need these stub functions but create the call code directly.

[Bruce Abbott]

Originally Posted by kerravon

Wow. Ok, I didn't expect to be involved in turning on the motor. I didn't need to do this on the IBM PC (where the BIOS was available) or on the mainframe (where you construct a CCW and send the request to the channel subsystem).

The floppy drive takes a long time to spin up, so by explicitly starting the motor you can do other stuff while waiting. Of course the PC BIOS also turns the drive motor on internally, but if it hides that from you then your (single tasking) application is forced to wait while it spins the drive up.

Turning on the motor is pretty easy. Encoding and decoding the disk data is a lot harder. The Amiga does it with a combination of Blitter and CPU operations. Most other machines have a dedicated disk controller (eg. uPD765) to do it, which makes the job a lot easier but is not as flexible. It gets even more complicated when a disk is written to by a PC. The PC controller only writes one sector at a time, causing corruption in the sector gaps that can upset the Amiga's sync detector (the Amiga normally reads and writes whole tracks, so the sector gaps are always clean).

Maybe I want to target the Amiga 1000 purely, and for other environments (like Amiga 500) assume that the Kickstart ROM has been replaced with whatever the Amiga 1000 has in ROM (ie ignoring the Amiga 1000 Kickstart disk).

On other Amigas you can let the system start up and load the boot sector into memory, just like the PC does. Then you can take over and blow the system away, using your own low level routines for further drive access. This is how most games do it (often with non-standard data formats to combat piracy or just to get more space on the disk).

[Bruce Abbott]

Originally Posted by kerravon

I dislike writing in assembler, except for small stubs with no loops. So reworking someone else's assembler is not something I want to do. I'd rather write my own in 99% C90.

You can do that if you feel more comfortable with C, but you still need good understanding of how the hardware works and how you compiler deals with it.

That sounds good. I'm not that interested in the BIOS, so if you're providing that (I assume it is some sort of freeware?), that would be great. Do you have a timeframe when you would expect a basic BIOS to be available?

As far as I know the code is abandonware. If this is a problem well...

No idea on timeframe. Right now I just want to get it working on faster Amigas to see what use it could have been if properly written (the code is full of MOVE SR instructions that crash on 68010 and later CPUs, and doesn't like FastRAM).

Other 68k hardware would require a different BIOS, wouldn't it? The interface could be the same, but it needs to manipulate different graphics chips or whatever.

Different yes, but the same applies to PCs. Every BIOS has stuff in it specific to the motherboard it is used in. The whole principle of a BIOS is to hide those differences from you. If someone wants to use your DOS on their machine then it's their responsibility to modify the BIOS code to suit.