![]() |
![]() |
#1 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,470
|
RKRM - AmigaDOS work in progress
Hi folks,
years ago when I did not know better, I was always wondering (and a bit upset) why there was not an RKRM volume about the dos.library and AmigaDOS. Well, reasons are of course that AmigaDOS is nothing but Tripos in a disguise, and thus the AmigaDOS manual was published through a different channel than the RKRMs. In fact, if you look into the Tripos manual and compare it to the Bantam volume, you might be suprised about the similarities. Anyhow, the AmigaDOS manual leaves a lot to be deserved - it does not document a lot, and it is incomplete and misses quite some information. Then, we have documentation such as Ralph's Guru Book, which is pretty much out of print and hard to get. Hence, it is really about time to improve the situation, and so I started drafting a dos.library documentation in RKRM style: https://github.com/thorfdbg/rkrm-dos/ Note well that this is all work in progress, at this point quite incomplete, and it will certainly take several months (if not years) to arrive at a final stage. But, at least, a start has been made. Of course, for a project like this, I need some help. Proof-reading, fixing defecs, improving formulation, spell-checking, and much more. My github page therefore not only contains the (fairly incomplete) PDF, but also the LaTeX source. If you are interested, you can submit change requests, defect reports etc. there, and even patches to the LaTeX source. Thanks, Thomas |
![]() |
![]() |
#2 |
Registered User
Join Date: Aug 2012
Location: RAM:
Posts: 83
|
Wow! This looks great. Well done.
|
![]() |
![]() |
#3 |
Zone Friend
Join Date: May 2006
Location: France
Posts: 1,890
|
Nice, but existing RKRM stopped at version 2.0 too.
|
![]() |
![]() |
#4 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,659
|
Nice.. back in the day, the stuff that I felt was missing, was all the packet/handler/filesystem stuff, not so much the high level file functions of dos.library.
This just a nudge towards where to focus ![]() |
![]() |
![]() |
#5 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,470
|
|
![]() |
![]() |
#6 |
Zone Friend
Join Date: May 2006
Location: France
Posts: 1,890
|
Is all this stuff necessary if you backport the new DOS from OS4?
|
![]() |
![]() |
#7 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,295
|
Gave it a quick skim, and so far looks very good and well-written. Really like the tips+code snippets.
Noticed two small things: Indentation for the parameters for Open() in 3.4 is a bit off, and in 3.9.2 you write that it's important to use MEMF_PUBLIC, but I think that should be MEMF_CLEAR. |
![]() |
![]() |
#8 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,470
|
Thanks, can you please open up a bug report on the github so I don't forget to look it up? With a work of that size, it is easily forgotten.
Thanks, Thomas |
![]() |
![]() |
#9 |
Registered User
![]() Join Date: Dec 2017
Location: Austin, TX
Age: 41
Posts: 418
|
It looks really useful.
I'm not sure why but the PDF is very slow to render in Chrome and Okular/Poppler on Linux. I installed Texlive and rebuilt the PDF. It's 4x smaller and renders almost instantly. |
![]() |
![]() |
#10 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 541
|
Quote:
![]() |
|
![]() |
![]() |
#11 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 541
|
Quote:
![]() |
|
![]() |
![]() |
#12 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,946
|
|
![]() |
![]() |
#13 |
Registered User
Join Date: Aug 2006
Location: Finland
Age: 52
Posts: 244
|
This fabulous! Thanks for initiating it. (secretly waiting for an overlay file description for absolute dummies)
|
![]() |
![]() |
#14 |
Zone Friend
Join Date: Mar 2004
Location: Middle Earth
Age: 40
Posts: 2,130
|
|
![]() |
![]() |
#15 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,659
|
Yeah, what's up with that? Is the conversion from tex to pdf generating too many points, perhaps?
|
![]() |
![]() |
#16 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 541
|
Quote:
![]() What is not covered quite so well is the role of the overlay manager code, the part which the undocumented bits of LoadSeg() play and, arguably, how to specify the overlay node layout so that both the linker and you understand what is supposed to happen. In short, the complex bits are complex and the obscure bits are obscure, but they are taken care of before the executable is created and later loaded by a combination of dos.library magic in LoadSeg() and the overlay manager code which is linked against that executable. The use of overlays fell out of favour in the late 1980'ies because the Amigas made in that time had much more memory available or could be expanded (RAM prices were also not quite so high any more as they used to be in 1984-1987). The design of the overlay feature also left something to be desired, specifically flexibility. You had to preplan which parts of the program had to be in memory at a time. For some applications, e.g. the original Deluxe Paint (which had to work with as little as 256 KBytes of system RAM), this must have been not much of a challenge, but Deluxe Paint II struggled. Also, you could not override the overlay manager and say "my Amiga has enough memory to load the entire program, just do it". The Aztec 'C' compiler (ca. 1987, I think) offered an alternative overlay manager which sort of emulated what was the standard on the Apple Macintosh. You could actually override it and load the entire program into memory. You could also load and unload overlay portions on demand under program control, rather than having the overlay manager code do it all for you. This worked so well, it became the go-to solution for use of overlays in large programs, e.g. Deluxe Paint III. Of course, there was a catch. The Aztec 'C' custom overlay manager worked its magic by hacking how the dos.library overlay loader did its part of the job by providing information about the size of the overlay table which disabled clearing that table. This is important because the Aztec 'C' custom overlay manager needs to be able to load/unload each overlay node upon demand and has to know where these nodes are stored in memory. Sounds harmless, but it gets more interesting. The load/unload operation performed was cleverly optimized to reuse the overlay node information associated with every function call in the program. If you invoked a function stub found in an overlay node which had not been loaded yet, it would call the custom overlay manager, which would see to getting it loaded and then rewrite the function stub to point to the code that was just loaded. Yup, self-modifying code in action and no "cache clear" operation involved. You can guess how much fun this was bound to be when the 68040 came around. To complement the load operation, the unload operation then restored the function stub by looking at what it found in the overlay function table which had been cleverly prevented from getting cleared. With self-modifying code, of course. By comparison, the AmigaDOS default overlay manager does not use self-modifying code. It's just that the linker makes sure that every single function call passes through the overlay manager, even if the overlay node associated with that function is already in memory. So you have this built-in function call overhead (not so great for Sculpt-3D) and a significantly larger executable than might have been needed. To add insult to injury, the 1985-1987 era developer tools were prone to wrap every single object code module which was part of an overlay executable into a single hunk. This is how you you got large overlay programs consisting of hundreds (!) of hunks which would slow down loading further. For the whole saga, buy the book ![]() |
|
![]() |
![]() |
#17 |
Amigan
![]() Join Date: Feb 2012
Location: London
Posts: 1,323
|
The RKRM looks really interesting thanks Thomas. I know you already have a few guides on Aminet.
Probably it's easy to render a HTML or AmigaGuide from the LaTeX if you know how. It's amazing to me how they managed to incorporate Tripos into AmigaOS. Take a look at the code for the date command: https://github.com/borb/tripos/blob/.../com/bcpl/date It's completely alien! Notice the use of rdargs() though. |
![]() |
![]() |
#18 |
Zone Friend
Join Date: May 2006
Location: France
Posts: 1,890
|
OT : Was CAOS only a design document? How far was it for completion?
|
![]() |
![]() |
#19 | |
Moderator
Join Date: Nov 2001
Location: Germany
Posts: 879
|
Quote:
|
|
![]() |
![]() |
#20 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,470
|
Certainly. This is what I wrote up, it will become (in one way or another, probably in shorter form) be part of the above document.
This being said, some work was done on it last week such that there is now already something about processes and how to create them. There will be not much progress this week as I'm on a business trip. |
![]() |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Uni-Launcher (Work in Progress) Ideas? | DisasterIncarna | support.Apps | 10 | 10 August 2022 11:36 |
PdfTools Suite - Work in Progress a New Programs | savior | News | 18 | 26 April 2019 19:31 |
Work in progress. | Cowcat | Coders. General | 7 | 18 February 2014 22:33 |
Work In Progress - Speedball 2 | Bitmap Brother | Nostalgia & memories | 3 | 21 September 2005 00:50 |
Trick Or Treat Remake - Work in Progress | ant512 | Amiga scene | 15 | 16 November 2004 17:25 |
|
|