PDOS for Amiga

[kerravon]

Originally Posted by phx

From assembler stub functions

Thanks,
fd2pragma -i dos_lib.fd -s 90
generated this:

SECTION ".text",CODE
XREF _DOSBase

XDEF _Read
_Read:
XDEF Read
Read:
MOVEM.L D2/D3/A6,-(A7)
MOVEA.L _DOSBase
,A6
MOVEM.L 16(A7),D1/D2/D3
JSR -042(A6)
MOVEM.L (A7)+,D2/D3/A6
RTS


I confirmed that this was functionally the same as what you showed earlier, with A7 = SP.

But with or without -gas it is not assembling. But I should be able to manually fix that. There aren't many functions I actually need.

C:\devel\fd2pragma>vasmm68k_std -gas -Fhunk Read.s
vasm 1.8j (c) in 2002-2020 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.3n (c) 2002-2020 Frank Wille
vasm std syntax module 5.3 (c) 2002-2020 Volker Barthelmann
vasm hunk format output module 2.13 (c) 2002-2020 Frank Wille

error 2 in line 2 of "Read.s": unknown mnemonic <SECTION>
> SECTION ".text",CODE

error 2 in line 3 of "Read.s": unknown mnemonic <XREF>
> XREF _DOSBase

error 2 in line 5 of "Read.s": unknown mnemonic <XDEF>
> XDEF _Read

error 2 in line 7 of "Read.s": unknown mnemonic <XDEF>
> XDEF Read

error 1 in line 10 of "Read.s": illegal operand types
> MOVEA.L _DOSBase
***maximum number of errors reached!***


I would like this solution to work with both VBCC and GCC. I assume both of them use the stack the same way, so that this Read() function can be called?

I'll put Read/Open/etc (just the ones I need) into a single amiga.asm which I distribute with PDPCLIB, but eventually I think the functions should be individual members of amiga.lib distributed with AmigaPDOS. OS/2 distributes a os2386.lib too. I'm not sure if individual compiler vendors distribute their own version of os2386.lib.

I assume that clib/dos_protos.h is distributed by Amiga OS rather than individual compiler vendors too? I was planning on having a separate "amiga" directory under PDOS to store Amiga-specific stuff (I should really create a "windows" one too, and move Windows stuff out of "src").

[Bruce Abbott]

Originally Posted by kerravon

I'm not talking about Amiga OS, I'm talking about Amiga PDOS. For what reason can I not keep interrupts disabled on Amiga PDOS?

Why would you even want to?

Also, even if I do enable interrupts, how many different interrupts will the hardware generate?

There are 6 interrupt levels, used by the serial port, timers, vertical blank, blitter, copper, disk controller and audio channels. If you take over the system you can get away with not using them, but then you must poll each device to see if it needs servicing.

And I would actually expect that to have a default handler in the new BIOS. Right?

Yes.

I don't think the BIOS can have a requirement for the operating system to take ownership of interrupts by a particular point.

The BIOS should be responsible for handling interrupts, as this is hardware that higher levels shouldn't have to know about.

The purpose of a BIOS is to virtualize the hardware. When you port an OS from one hardware platform to another, this is the part that needs to be written to handle that specific hardware. On a PC the BIOS is in a ROM on the motherboard, and any hardware differences are incorporated into it by the manufacturer. The Amiga's 'BIOS' is integrated into its multitasking OS and cannot easily be extracted, so to do what you want without any baggage you need a custom BIOS.

When porting from x86 to 68k, the compiler must also generate appropriate instructions to suit the CPU. A PC's BIOS is accessed via x86 software 'interrupts'. The 68000 can do something similar with traps. The Atari ST uses trap #13 to call its BIOS functions.

[kerravon]

Originally Posted by Bruce Abbott

Why would you even want to?

I was thinking of the assembler code I was required to write for PDOS/386. I had to write a set of interrupt handlers. But the main problem there was that because I was running in 32-bit mode, the BIOS couldn't handle the interrupts itself, so I needed to take care of that and return to real mode and then do the BIOS interrupt myself. But I don't think that is required for AmigaPDOS even for applications, since they are invoking the OS via function call.

The purpose of a BIOS is to virtualize the hardware. When you port an OS from one hardware platform to another, this is the part that needs to be written to handle that specific hardware.

Ok, but the OS still needs to be modified to handle different types of BIOSes, there's no standard for that, right?

The Atari ST uses trap #13 to call its BIOS functions.

Cool. Maybe what I want then is a BIOS that is identical to Atari ST, for the Amiga?

[kerravon]

Originally Posted by Thomas Richter

Trust your compiler vendor.

I am a compiler vendor. I will be shipping a custom version of GCC 3.2.3.

In clib/exec_protos.h there is a function called AllocMem() which seems to be the simplest way (ie what I'm after) to allocate memory. Does the stub for this function also appear in amiga.lib? Thanks.

[kerravon]

Originally Posted by kerravon

It occurred to me that the BIOS could be on the disk as IO.SYS, and after loading itself into memory, it then loads the OS under a fixed name from the same disk. I believe this is what the Raspberry Pi does.

I realized that this is not going to work. The normal booting from a FAT drive assumes that a BIOS already exists in order to load more sectors from the FAT drive.

So perhaps I want a BIOS loaded from floppy (the same way that the Amiga 1000 loads Kickstart) and then the BIOS loads the first sector from the hard disk and transfers control to it.

I guess it would be helpful to know whether the Atari BIOS allows booting from a FAT hard disk in this manner.

Another possibility would be to have a modified FAT that places the entire BIOS in consecutive sectors and the Amiga 1000 (or some equivalent that can read hard disks) can read that.

[meynaf]

Originally Posted by kerravon

Another possibility would be to have a modified FAT that places the entire BIOS in consecutive sectors and the Amiga 1000 (or some equivalent that can read hard disks) can read that.

I think that if you want to access the hard drive, you need a working kickstart.
Otherwise you're gonna make your life more complex and be limited to single Amiga model.
But this has some benefits. The AmigaOS offers a lot more than mere BIOS.
Why not just redirecting your API to AmigaOS then ? You could access any file system this way, including FAT. For text output, there is simple stdout.
If you're gonna use Amiga thru an emulator, you can use PDOS on the Amiga in pretty much the same way - as a VM.
Only thing you need is a .lib redirecting all your calls.
If it can't work this way, what did I miss ?

[kerravon]

Originally Posted by meynaf

I think that if you want to access the hard drive, you need a working kickstart.
Otherwise you're gonna make your life more complex and be limited to single Amiga model.

Well, people without an Amiga 1000 or emulator would have the options of:

1. Replacing the Kickstart ROM with the new BIOS ROM, which will obviously only allow them to boot PDOS, until other OSes come along that support the Atari (or whatever) BIOS.

2. Creating a version of the BIOS code that can be loaded by Kickstart, with Kickstart being replaced (or ignored) by the BIOS.

This would mean that the entire memory wouldn't be available, but that is OK, the BIOS will prevent all the memory from being available too, and the IBM PC BIOS provides a call to retrieve the available memory a bit at a time, in the knowledge that it is not a single block.

But this has some benefits. The AmigaOS offers a lot more than mere BIOS.

I don't require more than a mere BIOS, and I don't want people to have to buy AmigaOS.

Why not just redirecting your API to AmigaOS then ? You could access any file system this way, including FAT. For text output, there is simple stdout.

It defeats the purpose of being an OS.

If you're gonna use Amiga thru an emulator, you can use PDOS on the Amiga in pretty much the same way - as a VM.

What does a VM give me?

Only thing you need is a .lib redirecting all your calls.

Which calls? The Atari BIOS calls?

If it can't work this way, what did I miss ?

The thing you are missing is that I don't want to be dependent on AmigaOS. The purpose is to provide a complete replacement.

However, you have made a good suggestion. Can the Atari OS be run on the Amiga? If so, someone must have provided the Atari BIOS. And actually I don't really care if PDOS runs under AmigaOS, so long as PDOS is only making BIOS calls (trap #13). (Or some replacement BIOS, e.g. IBM PC BIOS if you want).

The job of making the Atari BIOS independent of AmigaOS, or independent of just Kickstart, can be an exercise for another day. My main interest is getting PDOS to run on the Amiga and Atari hardware, with minimal changes to PDOS code, and for those minimal changes to be things like using Atari BIOS instead of IBM PC BIOS. I don't like the idea of modifying PDOS to use AmigaOS calls. I guess if the AmigaOS calls are hidden in a function called AtariBIOSReadDiskSector() it's no big deal.

Does that open up a new path for quick implementation?

[kerravon]

Originally Posted by kerravon

C:\devel\fd2pragma>vasmm68k_std -gas -Fhunk Read.s

I had a brainwave to switch to "mot" and got:

C:\devel\fd2pragma>vasmm68k_mot -gas -Fhunk Read.s
vasm 1.8j (c) in 2002-2020 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.3n (c) 2002-2020 Frank Wille
vasm motorola syntax module 3.14c (c) 2002-2020 Frank Wille
vasm hunk format output module 2.13 (c) 2002-2020 Frank Wille

error 1 in line 10 of "Read.s": illegal operand types
> MOVEA.L _DOSBase

error 1011 in line 11 of "Read.s": identifier expected
>,A6

I traced that strange error to this rogue x'0d':

000070 53426173 650D2C41 360A094D 4F56454D SBase.,A6..MOVEM

It seems that there are a lot of them:

C:\devel\fd2pragma>hexdump Read.s
000000 0A095345 4354494F 4E09222E 74657874 ..SECTION.".text
000010 222C434F 44450A09 58524546 095F444F ",CODE..XREF._DO
000020 53426173 650D0A0A 09584445 46095F52 SBase....XDEF._R
000030 6561640A 5F526561 643A0A09 58444546 ead._Read:..XDEF
000040 09526561 640A5265 61643A0A 094D4F56 .Read.Read:..MOV
000050 454D2E4C 0944322F 44332F41 362C2D28 EM.L.D2/D3/A6,-(
000060 4137290A 094D4F56 45412E4C 095F444F A7)..MOVEA.L._DO
000070 53426173 650D2C41 360A094D 4F56454D SBase.,A6..MOVEM
000080 2E4C0931 36284137 292C4431 2F44322F .L.16(A7),D1/D2/
000090 44330A09 4A535209 2D303432 28413629 D3..JSR.-042(A6)
0000A0 0A094D4F 56454D2E 4C092841 37292B2C ..MOVEM.L.(A7)+,
0000B0 44322F44 332F4136 0A095254 530A D2/D3/A6..RTS.

I tried switching from gcc to bcc32, but it didn't compile. I switched to wcl386 and it compiled, and produced the same rogue x'0d'.

I tried changing the "wb" in fopen in fd2pragma.c to "w", but that didn't fix the problem.

I added -g0 to bcc32 which allowed it to compile (ignoring all the warnings), but got the same result.

I changed the "rb" to "r" in fopen, and got:

C:\devel\fd2pragma\zzz>..\fd2pragma -i ..\dos_lib.fd -s 90
Error 38 : Could not open file "..\dos_lib.fd".

I was horrified that my file had apparently been deleted, but false alarm, it was still there.

That error appears to be in an enum block, of value ERR_CLIB_ARG_COUNT, but when I checked that code I gave up.

Using micro-emacs to edit (using the output of the original fd2pragma) Read.s and write it back, caused the x'0d' to disappear and I got a clean assembly:

C:\devel\fd2pragma>vasmm68k_mot -gas -Fhunk Read.s
vasm 1.8j (c) in 2002-2020 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.3n (c) 2002-2020 Frank Wille
vasm motorola syntax module 3.14c (c) 2002-2020 Frank Wille
vasm hunk format output module 2.13 (c) 2002-2020 Frank Wille

.text(acrx2): 26 bytes


So I'm in business!

[meynaf]

Originally Posted by kerravon

Well, people without an Amiga 1000 or emulator would have the options of:

1. Replacing the Kickstart ROM with the new BIOS ROM, which will obviously only allow them to boot PDOS, until other OSes come along that support the Atari (or whatever) BIOS.

Booting an Amiga without kickstart requires quite a lot of init code. I don't think it's worth going into.

Originally Posted by kerravon

2. Creating a version of the BIOS code that can be loaded by Kickstart, with Kickstart being replaced (or ignored) by the BIOS.

That's what many games do : take over upon startup.
Still, there is a lot to do yourself and you'll end up with more Amiga specific code than if you'd just used AmigaOS.
And say good bye to hard drive access.

Originally Posted by kerravon

This would mean that the entire memory wouldn't be available, but that is OK, the BIOS will prevent all the memory from being available too, and the IBM PC BIOS provides a call to retrieve the available memory a bit at a time, in the knowledge that it is not a single block.

On the Amiga you can take over the whole memory if you want (if you kill the system).
But if it's not required then there is no reason to not leave AmigaOS running.

Originally Posted by kerravon

I don't require more than a mere BIOS, and I don't want people to have to buy AmigaOS.

You don't need to use the whole OS obviously, and people who have an Amiga (or an emulator) of course already have AmigaOS.

Originally Posted by kerravon

It defeats the purpose of being an OS.

Look, you mention in first post PDOS works also on mainframes. These don't allow their OS to be switched off to plug another one, do they ?
I coded on IBM C370 in the past and didn't even know how much memory there was on it !

Besides, PDPCLIB run on Linux and Windows -- so why not just doing the same on the Amiga ?

Originally Posted by kerravon

What does a VM give me?

An abstraction layer.

Originally Posted by kerravon

Which calls? The Atari BIOS calls?

Your calls. Your own APIs.

Originally Posted by kerravon

The thing you are missing is that I don't want to be dependent on AmigaOS. The purpose is to provide a complete replacement.

But this is just not possible if you want to access hard drives.

Originally Posted by kerravon

However, you have made a good suggestion. Can the Atari OS be run on the Amiga? If so, someone must have provided the Atari BIOS. And actually I don't really care if PDOS runs under AmigaOS, so long as PDOS is only making BIOS calls (trap #13). (Or some replacement BIOS, e.g. IBM PC BIOS if you want).

Atari BIOS does not run independently of the rest of the OS. There is also XBIOS (extended bios), GEM, and all these are there too regardless if you use them or not.
Actually the situation is pretty much the same as on the Amiga.

Originally Posted by kerravon

The job of making the Atari BIOS independent of AmigaOS, or independent of just Kickstart, can be an exercise for another day. My main interest is getting PDOS to run on the Amiga and Atari hardware, with minimal changes to PDOS code, and for those minimal changes to be things like using Atari BIOS instead of IBM PC BIOS.

Atari BIOS has little to do with PC BIOS outside of the name.
You can't run something that's low level PC software on a machine that's obviously not a PC.

Originally Posted by kerravon

I don't like the idea of modifying PDOS to use AmigaOS calls.

Regardless if you use AmigaOS calls or Amiga hardware directly, you *have* to modify PDOS.

Originally Posted by kerravon

I guess if the AmigaOS calls are hidden in a function called AtariBIOSReadDiskSector() it's no big deal.

Well, something like that can be done, even though accessing a disk sector directly isn't something i'd recommend on a hard drive.

Originally Posted by kerravon

Does that open up a new path for quick implementation?

The path for a quick implementation is to list all the functions you need on the Amiga side, then implement them. Whether internally they use some BIOS, AmigaOS calls, or hardware directly, does not matter then.

[Thomas Richter]

Originally Posted by kerravon

I am a compiler vendor. I will be shipping a custom version of GCC 3.2.3.

In clib/exec_protos.h there is a function called AllocMem() which seems to be the simplest way (ie what I'm after) to allocate memory. Does the stub for this function also appear in amiga.lib? Thanks.

Yes, it does. The calling conventions of the stub functions is stack-based, 32-bit ints. That should fit to what gcc does by default. However, for gcc, you should also have "inline"-stub functions that are a bit more efficient and avoid the register ping-pong. If not, FD2Pragma can create some, if they are not part of the package anyhow (they should).

[Thomas Richter]

Originally Posted by kerravon

I realized that this is not going to work. The normal booting from a FAT drive assumes that a BIOS already exists in order to load more sectors from the FAT drive.

So perhaps I want a BIOS loaded from floppy (the same way that the Amiga 1000 loads Kickstart) and then the BIOS loads the first sector from the hard disk and transfers control to it.

I guess it would be helpful to know whether the Atari BIOS allows booting from a FAT hard disk in this manner.

Another possibility would be to have a modified FAT that places the entire BIOS in consecutive sectors and the Amiga 1000 (or some equivalent that can read hard disks) can read that.

First, Amiga does not have a bios. It has a kickstart. The kickstart has no idea about FAT, and at the time the boot procedure arrives at your boot block, neither has any idea about a file system. Not even the built-in file system, which is FFS. FFS is initialized by the dos.library, but you don't have the dos.library at the bootblock. In the boot block, you can run sector-based floppy I/O by means of the IORequest your bootblock receives through register A1. That is it, nothing else. No harddisk, nothing. Harddisk booting works differently, there is no boot block for harddisks. The way how floppy booting typically goes is that the boot block of the floppy calls "FindResdient" on the "dos.library", and then calls the init-vector of this resident module. This will initialize the dos.library. This call never returns. The dos.library will take over booting, and will create a shell to read from S:Startup-Sequence. Thus, you cannot "boot yourself" and use the dos.library at the same time. In particular, Read() does not exist in the boot block. DoIO() does (aka "read a floppy block").

[Thomas Richter]

Originally Posted by kerravon

So I'm in business!

Nope. Not for booting. See above. Read() is a function of the dos.library,and it does not exist once the operating system reaches the floppy boot block. It is rather up to the boot block to create it - but if you create it, the CPU does not come back to you, but continues the regular bootstrap process by executing S:Startup-Sequence.

[Thomas Richter]

Originally Posted by kerravon

1. Replacing the Kickstart ROM with the new BIOS ROM, which will obviously only allow them to boot PDOS, until other OSes come along that support the Atari (or whatever) BIOS.

It woudln't allow you much. In particular, it wouldn't allow you to access harddisks since their firmware obviously depends on a kickstart and the functions in the kickstart. The only "fixed" part in the hardware is the floppy hardware, so you would need to write your own floppy access code. Note that there is no floppy controller in the system that could help you. Controlling the stepper motor and decoding MFM is up to you.

Originally Posted by kerravon

2. Creating a version of the BIOS code that can be loaded by Kickstart, with Kickstart being replaced (or ignored) by the BIOS.

That still doesn't give you access to the harddisk, see above. You can either take over the entire system, or leave the system intact. This gives you only the option to operate in some form of virtual machine.

Originally Posted by kerravon

I don't require more than a mere BIOS, and I don't want people to have to buy AmigaOS.

You expect something that is simply not present. The Amiga does not have a Bios. It has the entire operating system build it - or major parts of it - and the expansion/third party hardware all depends on it.

Originally Posted by kerravon

It defeats the purpose of being an OS.

Ehem. AmigaOs may be a toy system all right, but just because it doesn't follow your expectations of having some bios-type abstraction layer - but rather the device abstraction bulit into the Os itself by its own means - still makes it an Os. MacOs didn't work any different. It had MacOs in ROM, obviously. There is no Bios.

Originally Posted by kerravon

What does a VM give me?

Access to the Os services like "reading a file" without having to take over the entire system and reimplement all its services, while still providing the illusion to the programs you run that they talk to their Os.

Originally Posted by kerravon

The thing you are missing is that I don't want to be dependent on AmigaOS.

That doesn't work on the Amiga. AmigaOs *is* what you call the "Bios". You cannot be independent of the Bios but use its services, that is a contradiction in terms. If you want to boot without AmigaOs, well, you need to write your own operating system from ground up. And yes, this means turning on the flopppy motor, run the stepper motor, and decoding MFM yourself. It also means that you don't have harddisk access because the harddisk firmware *depends* on the "Bios", aka "AmigaOs functions".

Originally Posted by kerravon

However, you have made a good suggestion. Can the Atari OS be run on the Amiga?

Yes, in a virtual machine. There are ST emulators for this purpose. Same as MacOs. MacOs can be run on the Amiga, also in a virtual machine. ShapeShifter does exactly that.

Originally Posted by kerravon

If so, someone must have provided the Atari BIOS.

Correct, you need to extract the Atari ROM from an Atari and provide it to the virtual machine. Actually, the entire ROM, not just what Atari calls the "Bios". There is much more in the Atari TOS Rom than the lower "Bios" layer.

Originally Posted by kerravon

And actually I don't really care if PDOS runs under AmigaOS, so long as PDOS is only making BIOS calls (trap #13). (Or some replacement BIOS, e.g. IBM PC BIOS if you want).

*Sigh* AmigaOs does not operate by traps. If you want to implement a "call by trap" functionality in your virtual machine, you have to do that yourself. Exec does have functions to collect exceptions in your task.

Originally Posted by kerravon

The job of making the Atari BIOS independent of AmigaOS, or independent of just Kickstart, can be an exercise for another day.

sed -e 's/day/decade/', because it means that you have to write your own floppy access code, and for every harddisk/firmware vendor, your own driver. Good luck doing that, and good luck finding the specification. There are probably drivers in the NetBSD community for many (though not all) third-party extensions. No, these extensions don't implement any "bios" trap call. They implement an AmigaOs "resident module" mechanism, which - of course - requires an operating AmigaOs.

Originally Posted by kerravon

My main interest is getting PDOS to run on the Amiga and Atari hardware, with minimal changes to PDOS code, and for those minimal changes to be things like using Atari BIOS instead of IBM PC BIOS.

See above, you start from the wrong assumption. There is no Bios.

Originally Posted by kerravon

I don't like the idea of modifying PDOS to use AmigaOS calls.

Well, then it wouldn't work. There are two options: Keeping AmigaOs alive, then you need to use its services (obviously). That's the VM approach. Or you don't, but then you need to implement *everything* yourself. Including all the hardware fiddling to read a sector from a device. There is no "part of AmigaOs" you can split off - except that you can split off "dos.library" (Tripos) at the boot sector, and only keep exec, graphics and intuition running.

Originally Posted by kerravon

I guess if the AmigaOS calls are hidden in a function called AtariBIOSReadDiskSector() it's no big deal.

Does that open up a new path for quick implementation?

The only quick path I can see is to go for a VM, same as the ST emulators and Mac emulators do.

[kerravon]

Originally Posted by meynaf

That's what many games do : take over upon startup.
Still, there is a lot to do yourself and you'll end up with more Amiga specific code than if you'd just used AmigaOS.
And say good bye to hard drive access.

Why does hard drive access disappear?

You don't need to use the whole OS obviously, and people who have an Amiga (or an emulator) of course already have AmigaOS.

Not necessarily. You need to buy AmigaOS. The purpose of AmigaPDOS is to create a basic OS for the Amiga emulator that includes a C compiler that allows you to build AmigaOS executables, and improve AmigaPDOS itself if you want more functionality. That's as far as I personally want to get it.

Look, you mention in first post PDOS works also on mainframes. These don't allow their OS to be switched off to plug another one, do they ?

I don't really understand that question. Do you mean by management policy or what is technically possible? I don't really get involved in policy. Yes, PDOS/3X0 can be booted without MVS/VM/etc being available. Right from the hard disk. Not one byte of anyone else's code on the hard disk. (Obviously other people contributed code to the project, but it's all explicit public domain).

I coded on IBM C370 in the past and didn't even know how much memory there was on it !

Ok, cool! I now have GCCMVS which is a replacement for that. So long as you only want C90. And GCCMVS-produced executables work all the way back to S/370, unlike IBM C370.

Besides, PDPCLIB run on Linux and Windows -- so why not just doing the same on the Amiga ?

Did you meant PDPCLIB or PDOS? PDPCLIB works on both of the above, PDOS runs under neither (unless you use an emulator like Bochs).

Atari BIOS does not run independently of the rest of the OS. There is also XBIOS (extended bios), GEM, and all these are there too regardless if you use them or not.

I don't have a problem with dead code being present. I'm just after that wonderful BIOS.

Actually the situation is pretty much the same as on the Amiga.

From what I understand, the Amiga doesn't provide a BIOS of the sort that could let me read a sector from the hard disk. The IBM PC BIOS certainly does. I don't know about Atari BIOS.

Atari BIOS has little to do with PC BIOS outside of the name.
You can't run something that's low level PC software on a machine that's obviously not a PC.

I don't need it to be the same interrupt number, I just need it to have the equivalent (or similar) functionality. In fact, I can't actually imagine how a BIOS couldn't be the same as the IBM PC. How else do you do this?

/* BosDiskSectorRLBA - read using LBA Int 13h Function 42h */ /* Returns 0 if successful, otherwise error code */ int BosDiskSectorRLBA(void *buffer, unsigned int sectors, unsigned int drive, unsigned long sector, unsigned long hisector)

Regardless if you use AmigaOS calls or Amiga hardware directly, you *have* to modify PDOS.

Sure. I have no problem if that modification is to support Atari BIOS calls instead of IBM PC BIOS calls.

Well, something like that can be done, even though accessing a disk sector directly isn't something i'd recommend on a hard drive.

No, this is something I definitely want to do. That's the entire purpose of the operating system. It's all designed to read sectors on a FAT-formatted hard disk. I guess I don't really care if the BIOS calls instead give me data in a flat file managed by AmigaOS instead.

The path for a quick implementation is to list all the functions you need on the Amiga side, then implement them. Whether internally they use some BIOS, AmigaOS calls, or hardware directly, does not matter then.

I'm not sure exactly what you're saying. The functions I need are as above - BosDiskSectorRLBA() and similar. And yes, by hook or by crook I need those implemented. You have given me an idea though - maybe even on Windows I can have an implementation of PDOS where all the BIOS calls are actually defined in terms of operating on a flat file. Then I would no longer need to use Bochs. But I can't do interrupts anymore if I do that. However, if I support an Amiga-style API for executables, I don't need to do interrupts. However, a problem with the Amiga is that applications are hardcoded to use offset 4, instead of getting that magic number 4 passed in as a parameter to the executables. Memory address 4 will not be something available to me if PDOS is running as a Windows app. But I could have a flavor of PDOS that is similar to AmigaOS except for the fact that executables receive the SysBase as a parameter. Or I could do it at the kernel32.dll level. Let me think about that.

[kerravon]

Originally Posted by Thomas Richter

Nope. Not for booting. See above. Read() is a function of the dos.library,and it does not exist once the operating system reaches the floppy boot block.

I was referring to PDPCLIB there, not PDOS. I believe I have everything I need to implement PDPCLIB for AmigaOS.

[meynaf]

Originally Posted by kerravon

Why does hard drive access disappear?

Because you need a working AmigaOS to be able to access the hard drive, for the reasons Thomas mentioned. No AmigaOS, no hard drive.

Originally Posted by kerravon

Not necessarily. You need to buy AmigaOS. The purpose of AmigaPDOS is to create a basic OS for the Amiga emulator that includes a C compiler that allows you to build AmigaOS executables, and improve AmigaPDOS itself if you want more functionality. That's as far as I personally want to get it.

But then the Amiga emulator isn't needed anymore. Why not just doing that on the host machine ?

Originally Posted by kerravon

I don't really understand that question. Do you mean by management policy or what is technically possible? I don't really get involved in policy. Yes, PDOS/3X0 can be booted without MVS/VM/etc being available. Right from the hard disk. Not one byte of anyone else's code on the hard disk. (Obviously other people contributed code to the project, but it's all explicit public domain).

So you could have a direct access to a mainframe's hard drive ? Looks strange to me.

Originally Posted by kerravon

Did you meant PDPCLIB or PDOS? PDPCLIB works on both of the above, PDOS runs under neither (unless you use an emulator like Bochs).

I mean PDPCLIB. You could start by having it working on the Amiga, without PDOS.

Originally Posted by kerravon

I don't have a problem with dead code being present. I'm just after that wonderful BIOS.

Then for the same reasons you shouldn't be against using AmigaOS. Just see it as a big BIOS containing a lot more features.

Originally Posted by kerravon

From what I understand, the Amiga doesn't provide a BIOS of the sort that could let me read a sector from the hard disk. The IBM PC BIOS certainly does. I don't know about Atari BIOS.

It doesn't work this way. AmigaOS will allow you to read a sector from the hard disk, all you have to do is to find the device name, open that device, and send it an io request. It is more complicated because devices are a lot more than just unit numbers.

Originally Posted by kerravon

I don't need it to be the same interrupt number, I just need it to have the equivalent (or similar) functionality. In fact, I can't actually imagine how a BIOS couldn't be the same as the IBM PC. How else do you do this?

/* BosDiskSectorRLBA - read using LBA Int 13h Function 42h */ /* Returns 0 if successful, otherwise error code */ int BosDiskSectorRLBA(void *buffer, unsigned int sectors, unsigned int drive, unsigned long sector, unsigned long hisector)

Atari ST BIOS can do it this way :

C:
long Rwabs(int rwflag, long buffer, int number, int recnr, int dev);

Asm:
 move.w dev,-(sp)
 move.w recnr,-(sp)
 move.w number,-(sp)
 move.l buffer,-(sp)
 move.w rwflag,-(sp)
 move.w #4,-(sp)
 trap #13
 add.l #14,sp

But now question is : why would you want to do that. Accessing the file system with normal Open() & co is a lot easier.

Besides, this requires a dedicated hard drive. A flat file does not.

Originally Posted by kerravon

Sure. I have no problem if that modification is to support Atari BIOS calls instead of IBM PC BIOS calls.

So it shouldn't make a difference if these calls are AmigaOS calls instead.

Originally Posted by kerravon

No, this is something I definitely want to do. That's the entire purpose of the operating system. It's all designed to read sectors on a FAT-formatted hard disk. I guess I don't really care if the BIOS calls instead give me data in a flat file managed by AmigaOS instead.

Accessing a disk image in a file is another story, and clearly a lot easier to manage...

Originally Posted by kerravon

I'm not sure exactly what you're saying. The functions I need are as above - BosDiskSectorRLBA() and similar. And yes, by hook or by crook I need those implemented. You have given me an idea though - maybe even on Windows I can have an implementation of PDOS where all the BIOS calls are actually defined in terms of operating on a flat file. Then I would no longer need to use Bochs. But I can't do interrupts anymore if I do that. However, if I support an Amiga-style API for executables, I don't need to do interrupts. However, a problem with the Amiga is that applications are hardcoded to use offset 4, instead of getting that magic number 4 passed in as a parameter to the executables. Memory address 4 will not be something available to me if PDOS is running as a Windows app. But I could have a flavor of PDOS that is similar to AmigaOS except for the fact that executables receive the SysBase as a parameter. Or I could do it at the kernel32.dll level. Let me think about that.

On the Amiga you can still use interrupts under the OS. You just have to ask nicely
That applications use address 4 is no problem - this information will be hidden in the Amiga specific code. On Windows there is nothing such as SysBase anyway so even if you could have a valid address, what would it point to ?

[kerravon]

Originally Posted by Thomas Richter

It woudln't allow you much. In particular, it wouldn't allow you to access harddisks since their firmware obviously depends on a kickstart and the functions in the kickstart.

Ok, that's dead in the water then. I will not attempt to bypass AmigaOS if physical hard disks are only accessible via Kickstart.
[/quote]

You expect something that is simply not present.

No, I realize there is no BIOS.

Ehem. AmigaOs may be a toy system all right, but just because it doesn't follow your expectations of having some bios-type abstraction layer - but rather the device abstraction bulit into the Os itself by its own means - still makes it an Os.

I was talking about PDOS not being an operating system if it doesn't read hard disk sectors. I don't consider AmigaOS to be a toy operating system anyway. People used MSDOS commercially for a long time, doing productive work. AmigaOS always blew MSDOS away.

Correct, you need to extract the Atari ROM from an Atari and provide it to the virtual machine. Actually, the entire ROM, not just what Atari calls the "Bios".

Ok, would it be possible to replace the Atari ROM (just the BIOS calls I need) with calls to AmigaOS functions? I still want to access the Atari ROM-replacement via trap #13 though.

*Sigh* AmigaOs does not operate by traps.

I realize that. I already know the essential elements of an Amiga executable to get a "hello, world" through. It is only those essential elements that I am interested in.

If you want to implement a "call by trap" functionality in your virtual machine, you have to do that yourself. Exec does have functions to collect exceptions in your task.

Atari OS running under Amiga OS must already do these "call by trap" to access the Atari BIOS. So who implemented the trap/exec part of that?

The only quick path I can see is to go for a VM, same as the ST emulators and Mac emulators do.

Ok, so I'm after a VM under AmigaOS, with a mini Atari-compatible ROM, to be used just for the BIOS calls, but I will support a mini-AmigaOS API, not the Atari API.

Once working, this would then allow me to run AmigaOS executables (although a.out format rather than hunk to start with) on the Atari. Not requiring a VM either - directly on the Atari hardware without Atari OS. Right?

[phx]

Originally Posted by kerravon

I would like this solution to work with both VBCC and GCC. I assume both of them use the stack the same way, so that this Read() function can be called?

Yes. The 68k C-ABI defines that all arguments are passed on the stack. Smaller types than "int" are extended. In the past, mostly before OS2.0 and in pre-C90 times, also 16-bit-int compilers were used. But today you will only use 32-bit int.

There may be differences in the ABI when it comes to floating point, though. Don't know if that affects you. AmigaOS compilers will return a float result in FPU register fp0 (when compiling with FPU code enabled) while many other (Unix-based) compilers always return it as 64-bit double precision in the CPU's register pair d0/d1. Which Amiga compilers only do with soft-float.

I'll put Read/Open/etc (just the ones I need) into a single amiga.asm which I distribute with PDPCLIB, but eventually I think the functions should be individual members of amiga.lib distributed with AmigaPDOS.

You should prefer the latter. A single amiga.asm with all stub functions will result in a single object file, which may add a lot of unused code to an executable when linked. Create object files for all individual OS-call stubs.

I assume that clib/dos_protos.h is distributed by Amiga OS rather than individual compiler vendors too?

Yes. I think it should be part of the SDK, since OS2.0 (?) in the early 90s.

Originally Posted by kerravon

I had a brainwave to switch to "mot" and got:

C:\devel\fd2pragma>vasmm68k_mot -gas -Fhunk Read.s

Correct. You will need mot-syntax to assemble fd2pragma's output. MIT syntax ("std" in vasm) is rarely used on the Amiga, except as output of gcc.

error 1 in line 10 of "Read.s": illegal operand types
> MOVEA.L _DOSBase

error 1011 in line 11 of "Read.s": identifier expected
>,A6

Your Read.s is corrupt. The operands were split into two lines...

I traced that strange error to this rogue x'0d':
(...)
I changed the "rb" to "r" in fopen, and got:

C:\devel\fd2pragma\zzz>..\fd2pragma -i ..\dos_lib.fd -s 90
Error 38 : Could not open file "..\dos_lib.fd".

Hmm... that may be a problem in fd2pragma when running on CR/LF line-ending hosts, like Windows. fopen() with "rb" or "wb" is definitely wrong, when dealing with text files. But fd2pragma can also output binaries, so you have to be careful.

Somebody should debug that (probably me, as the original author of fd2pragma disappeared ).

Simple solution would be to run fd2pragma with "-s 12". Special 12 directly outputs a hunk-format linker library with individual object files for all functions.

[kerravon]

Originally Posted by meynaf

But then the Amiga emulator isn't needed anymore. Why not just doing that on the host machine ?

PDOS is an operating system. I don't think it is correct to call it an "Amiga emulator". I do intend to have it support Amiga executables, but it can do that even on some other 68000 machine that has a BIOS (not necessarily the Atari).

So you could have a direct access to a mainframe's hard drive ? Looks strange to me.

There are lots of hard disks on a mainframe. Yes, systems programmers have access to hard disks and can install whatever they want on there (so long as management doesn't stop them). They can then IPL off those disks. Obviously easier to do on a DR site. PDOS/3X0 post-dates my career as a mainframe systems programmer, so I do the same thing using a mainframe emulator (Hercules) instead.

I mean PDPCLIB. You could start by having it working on the Amiga, without PDOS.

Absolutely. That is my first step, and I have everything I need to do that already. My questions are about what comes after that, which is PDOS. I may still have some questions about PDPCLIB, but none at the moment.

Then for the same reasons you shouldn't be against using AmigaOS. Just see it as a big BIOS containing a lot more features.

I want to write to memory address 4 to install my own Sysbase and handle requests from Amiga hunks myself.

It doesn't work this way. AmigaOS will allow you to read a sector from the hard disk, all you have to do is to find the device name, open that device, and send it an io request. It is more complicated because devices are a lot more than just unit numbers.

I realized something I would like to do. I don't know if AmigaOS supports FAT-16 and FAT-32 file systems with LFN support, but PDOS does. So I would like to treat AmigaOS as a "very big BIOS" (as you suggested) and get access to raw hard disks. These raw hard disks could then be transported to another machine that understands FAT.

Atari ST BIOS can do it this way :
long Rwabs(int rwflag, long buffer, int number, int recnr, int dev);

Thanks. Looks like what I need.

But now question is : why would you want to do that. Accessing the file system with normal Open() & co is a lot easier.

I have my own file system to support. I just need access to the hard disk, by sector, and PDOS will do the rest. That's what PDOS is designed to do.

Besides, this requires a dedicated hard drive. A flat file does not.

Sure. But you don't need an operating system at all if you only intend to read/write flat files. I do agree that flat files are useful if I only want to run in an emulated environment.

That applications use address 4 is no problem - this information will be hidden in the Amiga specific code. On Windows there is nothing such as SysBase anyway so even if you could have a valid address, what would it point to ?

On PDOS, without much work, there will be a SysBase. 80386 executables running under PDOS could start doing calls via SysBase. There is no reason why the SysBase interface should be restricted to 68000/Amiga. It's just as valid an interface as INT 21H or kernel32. The only problem is that address 4 may not be available. I think it might be used for 8086 interrupts. I really need executables to be flexible with that address. It should be provided as a parameter/register to executables I think. So I will need a modified AmigaOS 80386 executable. The startup code needs to be modified anyway, because of the different registers 80386 vs 68000, so I don't think that should be an issue.

[Thomas Richter]

Originally Posted by kerravon

Ok, would it be possible to replace the Atari ROM (just the BIOS calls I need) with calls to AmigaOS functions? I still want to access the Atari ROM-replacement via trap #13 though.

Well, in Atari ST emulators, this is essential what happens. The emulator (via exec) catches the trap, and replaces the function. So, for example, a "Bios call" such as "read sector 5 from harddisk 1", would be translated to "seek to offset 5*512 in the harddisk image file, then read 512 bytes from that file". That was a rather common method. However, that means that AmigaOs is still intact.

Originally Posted by kerravon

Atari OS running under Amiga OS must already do these "call by trap" to access the Atari BIOS. So who implemented the trap/exec part of that?

The author of the emulator, together with the help of exec to forward the traps to the emulator.

Originally Posted by kerravon

Ok, so I'm after a VM under AmigaOS, with a mini Atari-compatible ROM, to be used just for the BIOS calls, but I will support a mini-AmigaOS API, not the Atari API.

That might be a strategy.

Originally Posted by kerravon

Once working, this would then allow me to run AmigaOS executables (although a.out format rather than hunk to start with) on the Atari. Not requiring a VM either - directly on the Atari hardware without Atari OS. Right?

Well, it would run on emulated Atari hardware, but that might be good enough. I do not quite know why you want to do what you want to do, so I cannot judge whether that is sufficient. My Amiga already has an operating system.