13 March 2021, 18:15 | #181 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Quote:
That assumes that you are only using binaries from these versions. Frankly, nowadays I don't worry about any registers including a0/d0 as ParseArgs() is doing the argument parsing for me, and it receives them through other channels. |
|
13 March 2021, 18:18 | #182 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Once again: For legacy BCPL programs, special registers are to be populated in a way that is not documented. What is documented is RunCommand(). That - and not any register values - define the interface how a command is started. Actually, it is much worse. Not only have the registers be prepared correctly, also the stack frame has to be prepared, and in a particularly weird way as the BCPL stack grows from small addresses to large addresses. This is much more than "how to find out the right values".
Quote:
Do you understand the difference between an interface and an implementation? |
|
13 March 2021, 18:29 | #183 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,751
|
|
13 March 2021, 18:39 | #184 | |||||
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
Quote:
But if the stack doesn't even grow the same way, then my main() can't even call printf() and work on both environments, so I'll have to abandon that. Quote:
Quote:
Quote:
Quote:
|
|||||
13 March 2021, 18:59 | #185 | |||||||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Quote:
The problem exists as long as you want to start a binary, or load a binary for that matter. Again, the interface for loading the binary is LoadSeg(), another dos.library function. It does hunk loading much better and reliable than any program you can write, despite that it is a waste of time re-implementing things that are already present. Quote:
Quote:
Quote:
Quote:
Quote:
An implementation is a specific function that implements an interface, i.e. concrete code. That code, however, exists already, in dos.library. The reason why this is so particular important is that AmigaDos carries a lot of legacy cruft around, and if you want to be compatible, you better use the Os functions to do all this nonsense correctly that is not fully written down. Quote:
Thus, if your VM stays "tight shut" to the host environment, all fine. As soon as it interferes with the surrounding world, it need to use the interfaces of this surrounding world instead of inventing or reimplementing them. |
|||||||
13 March 2021, 19:46 | #186 | |||||||||||||
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
|||||||||||||
13 March 2021, 21:12 | #187 | |||||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Quote:
Quote:
Quote:
Back in that time, you used the Metacomco BCPL compiler for it which depended on this environment. Not sure whether a copy of this still exists. This is all not surprising as it seems - note again that the dos.library *is* Tripos (or, back then, was - it is different today) CBM was short of a file system/dos for its Amiga, and could not complete its own in time, so they just bought Tripos. Quote:
Quote:
Note well, it is not only AmigaOs binaries that read from address 4, but pretty much everything else as well. System libraries, as well as other tasks running at the same time. This is a multitasking Os, after all. |
|||||
13 March 2021, 21:34 | #188 | |||
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
Quote:
Quote:
I don't need an MSDOS interface for this to work (although AmigaPDOS internally will use something similar to an MSDOS API, in preparation for MSDOS-like calls). Everything will look like MSDOS, and you will get a "C:\>" prompt and you can do "type config.sys" or whatever and all the executables will be called xxx.exe (no choice). But it will run D7-aware pure AmigaOS executables to start with. Quote:
This might qualify as a VM, I'm not sure. I won't have access to address 4, so it's probably not a real VM. You can consider AmigaPDOS to just be an "unusual application". It is an OS sitting there waiting for a BIOS, and I've provided a suitable BIOS by simply leveraging off AmigaOS. Thanks to this new concept of not needing to intercept Traps, it should be possible for AmigaPDOS to technically appear (to AmigaOS) to be a "normal AmigaOS application". |
|||
13 March 2021, 23:18 | #189 | |
Registered User
Join Date: Mar 2019
Location: Poland
Posts: 59
|
Quote:
These programs will be kept in Amiga hunk format as you plan to load and run some of Amiga programs later. I assume that only console Amiga programs will be considered due to text only interface offered b PDOS. This is some sort of running hosted - the method I described on at the beginning of this thread I think that the best approach would be to make an Amiga console application (PDOSShell) that will present a console/Dos type shell in Amiga window. When someone enters a name at the prompt, PDOSShell checks if a program is for Amiga or PDOS and call LoadSeg for Amiga programs and your own hunk loader for PDOS ones. Then you will be able to offer Amiga environment, arranged by dos.library to run Amiga programs, redirecting their output to your window. Your PdosBase will be useless for Amiga programs but for PDOS ones you can present your PDosBase/API as you like in any register and form. PDOSShell will take care of managing filebased fat pseudopartitions like c: etc. reading/writing from them, generally will handle BIOS interface call mapping and PDOS calls into Amiga equivalents as needed. Actually, if I was going to implement it, I'd use a device like, for example, diskimage.device from Aminet to mount images and access them from both AmigaOS (via CrossDos filesystem) and PDOS side, or directly reading blocks via such device for PDOS fat implementation. |
|
14 March 2021, 06:12 | #190 | |
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
Quote:
*At a later date* to *extend AmigaOS* (even if due to technical limitations the functionality only actually appears in AmigaPDOS), I should have a pos.library in the same linked list in ExecBase where I currently find dos.library. "Pos" is what I call my MSDOS-inspired API. It was also inspired by OS/2 which has functions like DosOpen(). Inspired by the word "Dos" I created "Pos" so as to not conflict, and provide an API that would be restricted to what an MSDOS INT 21H could handle. The purpose of PDOS/3X0 is to run stock-standard MVS executables, rather than creating my own API. The purpose of AmigaPDOS should be to run stock-standard AmigaOS executables, rather than creating my own API. If I do create an extended API, that is fine as a separate exercise, but it should ideally fit in with the existing AmigaOS API, rather than having some pointer directly of SysBase or something like that. The AmigaOS way of adding extended functionality is to have a new .library accessible via OpenLibrary() which goes to a linked list off SysBase. But let's forget about extensions for now, and focus on a subset of the actual AmigaOS API. ie applications should be able to do Read() which is documented. Having said that, due to a technical quirk that doesn't exist in other environments like MVS and Windows, it is necessary to first extend the AmigaOS published API to introduce the concept of an *optional* SysBase override via D7. Anyone who is interested in running under an alternative AmigaOS-compatible environment such as AmigaPDOS is expected to recompile their software after updating the startup code with about 10 lines of code. If no-one else is willing to cooperate with their startup code, so be it, AmigaPDOS will only ever be able to run PDPCLIB-based programs where the startup code has definitely been updated. The sort of AmigaOS executables I plan to run, such as GCC 3.2.3, will be linked with PDPCLIB, so there's one HUGE (3 MB executable, 400,000 lines of C code) application that is expected to work. I consider that to be a great technical achievement and will be happy to end my work there. However, I would now like to consider spreading AmigaPDOS elsewhere, specifically the 80386 and x64 (ie a 64-bit version of it). The 80386 has a suitable BIOS to run AmigaPDOS too. An identical BIOS in fact. Obviously all applications, plus the OS itself, will need to be recompiled to produce 80386 code. That's fine. I have a compiler available. But the applications will need to have a C runtime library available too, which is also fine, that's what the Amiga target is for, and fread() will call Read() and Read() (currently as 68000 assembler) will need to be rewritten in 80386 assembler, perhaps even doing an INT 22H (to separate it from MSDOS INT 21H), or, more likely it will be written in C code instead, to call a DOSBase->Read() function, since the interface is necessarily different due to different registers being used. It will all be hidden in Read(), and so long as everyone follows the rules, everything will be fine. The SysBase will still be the same, still a linked list that contains "dos.library". I can't see any reason why this can't run on the mainframe either, which also provides an identical BIOS. The executable format for 80386 will probably be a.out, and the startup code is necessarily different as well, registers d0 and a0 do not exist, and in this case I think should make the interface a normal function call that expects 3 parameters, like this: int amigaentry(unsigned long cmdlen, char *cmd, void *sysbase) There is no choice but to provide the sysbase. There is no sensible address to hardcode. You certainly can't assume that "4" is going to be available. With all this in place I can build and run the 80386 version of AmigaPDOS (and the applications that run under it, such as "hello, world") on my Windows box. A recompilation with vbcc should see it running just fine on the 68000 too. And the binaries that run under the 68000 version will also run fine on genuine AmigaOS. Finally, I have the outlines for a different version of PDOS called PDOS-generic. This doesn't attempt to clone someone else (MVS, MSDOS, AmigaOS) API, but will introduce its own API. This API will be called osfunc(). All OS calls will be routed through that, and PDOS-generic will handle those requests. When running PDOS-generic executables on PDOS-generic on a 68000 machine, e.g. Atari, I will reuse the hunk format, since I already have code to handle that, and it's not very important, but I will change the magic cookie from 000003F3 to say 00000F3F to signify that it is not going to work under AmigaOS, because PDOS-generic does not call executables that expect this: int amigaentry(unsigned long cmdlen, char *cmd, void *sysbase) and especially not d0/a0/d7 being set. PDOS-generic will alter the FAT format to take certain directory entry bits to signify things like "text" or "binary" depending on whether the file in question was written out using fopen "w" or "wb". It will also have an EBCDIC/ASCII indicator so that different character sets can be intermingled. Sound like a plan? As far as I can tell, most of the code to do what I want for both AmigaPDOS and PDOS-generic (on all environments) is already written, I just need to piece it together. |
|
15 March 2021, 05:33 | #191 | ||||
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
Quote:
Quote:
osfunc(OS_PRINTF, 0, "\x1b[2J"); which will be translated into a standard Write() to AmigaOS Output() handle, that someone will have provided an ANSI terminal for me (micro-emacs, actually). Quote:
Quote:
Basically you will go: bios.exe AmigaPDOS.exe flatfile.dat flatfile.dat will be accessed with Open(), Read(), Seek() (I think), which is what PDPCLIB will be using. I don't know if you can simply point flatfile.dat to some sort of raw device. |
||||
17 March 2021, 21:44 | #192 |
Registered User
Join Date: Jun 2020
Location: Brno
Posts: 90
|
I ran through this whole discussion because, at the beginning, I thought OP wanted to create some tiny micro operating system (with a simple text console and a filesystem?) which would boot directly from the diskette on the Amiga, independent on AmigaOS. That OS would allow him to run his own programs (even built by his own ported C compiler?) which would use his own API to call his own OS functions.
It would be interesting. Implementing some simple filesystem (obviously own trackdisk reader is needed), keyboard input, text output, memory management, ... I was a little skeptical because OP apparently thought that the Amiga had some "PC BIOS" available which already does it all. Yet I thought maybe he would program it himself. I reckon it's a big big feat to implement it all. Seems that nothing like that is planned. Honestly, I even don't know what is planned and what is the purpose of it all. My question is: Maybe something like that already exists on the Amiga? Some micro OS booting from diskette, with documentation how to program for it. I remember that some trackmos (by Sanity? by Chaos?) contained a simple "OS" (I think demo Arte can crash into its console). Last edited by defor; 18 March 2021 at 11:08. |
18 March 2021, 14:42 | #193 | |
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
Quote:
I'll probably develop "generic" first, since I can get that working on my Windows machine. And then a simple recompilation of the C code should activate it for AmigaOS. Unless I'm missing something. |
|
18 March 2021, 18:11 | #194 | ||
Registered User
Join Date: Jun 2020
Location: Brno
Posts: 90
|
Quote:
Quote:
Unfortunately it seems that it is of no use for me. I'm looking for something similar to what I described in my previous post. Something simple. Targeted for programmers who want to play with old Amigas in non-system way (direct access to custom registers) but who want to have an access to some filesystem on diskette (read/write files). Something, what I believe, many demoscene coders were tinkering with to simplify process of producing trackmos. Honestly, I don't know what "BIOS" are you referring to ("independent product"). IMHO there is nothing like a BIOS. If your OS wants to access diskdrive and read a file data, you must either keep AmigaOS running, or write your own trackdisk loader (or use some existing one). Situation gets even worse if you want to allow your system to read from HDD. There might be some available code not dependent on AmigaOS which can read/write tracks, but I guess you must find such for every existing most popular HDD drivers on Amiga platform. So it seems to me that your are likely talking about some "PDOS emulator" or "PDOS virtual machine" running on AmigaOS, using AmigaDOS to access existing Amiga filesystem (filesystems, in fact, because there are a lot of them). I don't understand why you want to use amiga hunks as your chosen format for executables, but whatever. I wish you good luck with your endeavour but it departs too much from what I am looking for. |
||
19 March 2021, 01:06 | #195 | |||
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,546
|
Quote:
Quote:
Quote:
I would do the minimum required to implement a 'generic' API, with such things as DOSbase or INT21 hidden inside a low level module that even your library code calls via the PDOS API. C knows nothing about DOSbase or INTs, so you should not be discussing them except in regards to the low level implementation of PDOS on different platforms. The API will only be valid for C source code that uses generic functions, because the machine code generated will be quite different depending on the host platform. In short, your OS should be designed to provide exactly the same source code API on all platforms, and application code should compile for any host platform with no changes. To do that the code should be pure generic C with no references to platform specific stuff or analogs of such. The OS source should also be fully generic except for a small low level interface module to the host API. |
|||
19 March 2021, 10:59 | #196 | |||||
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
Quote:
https://sourceforge.net/p/pdos/gitco...ter/tree/bios/ and it has been confirmed to run on AmigaOS. Quote:
Quote:
Quote:
Quote:
Note that AmigaOS massively inspired this "generic PDOS". Couldn't have done it without AmigaOS and you guys helping me to understand how it works. Operating via fixed address 4 (and the need to relocate that address for my own use) was the breakthrough I needed. Before that I was stuck in "everything needs to be done via Trap or the OS needs to fill in DLL locations for the executable". I did know about the CVT in MVS, and I knew it was used for Unix calls, but I didn't make the connection that it could ALL be done via a fixed location. |
|||||
19 March 2021, 11:07 | #197 | ||||||
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
https://sourceforge.net/p/pdos/gitco...ee/bios/bios.c I'm open to suggestions on improvement, before I get too deep down the wrong path. But so far it's all working. On 3 completely different platforms. |
||||||
19 March 2021, 12:16 | #198 |
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
Also it was you guys who even explained the very purpose of a BIOS to me, to separate the hardware. Previously (in PDOS/386) I had mixed the replacement BIOS (including dealing with hardware interrupts) in with the OS. And on the mainframe there was no concept of a BIOS at all. I wondered why that was the case, but it never occurred to me that one should actually be written for it. Once again I mixed what was basically a BIOS in with the OS.
|
19 March 2021, 16:24 | #199 | |
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
Quote:
There could be a chain of 10 systems, all passing an OS_FREAD request up, until someone reads an actual physical hard disk. And there could be CPU switches along the way, ie 68000 to 80386, or just mode switches, e.g. 8086 to 80386 to x64. |
|
20 March 2021, 20:32 | #200 | |
Registered User
Join Date: Mar 2021
Location: Sydney, Australia
Posts: 184
|
Quote:
https://groups.google.com/g/alt.os.d.../c/D0PvjBFiNhY in the second message (which you only seem to be able to see if you wait a while and then click down the bottom to refresh). |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
|
|