# Aros/Platforms/68k support/Developer/Libraries

* Navbar for the Aros wikibook
* Aros User
* Aros User Docs
* Aros User FAQs
* Aros User Applications
* Aros User DOS Shell
* Aros/User/AmigaLegacy
* Aros Dev Docs
* Aros Developer Docs
* Porting Software from AmigaOS/SDL
* For Zune Beginners
* Zune .MUI Classes
* For SDL Beginners
* Aros Developer BuildSystem
* Specific platforms
* Aros x86 Complete System HCL
* Aros x86 Audio/Video Support
* Aros x86 Network Support
* Aros Intel AMD x86 Installing
* Aros Storage Support IDE SATA etc
* Aros Poseidon USB Support
* x86-64 Support
* Motorola 68k Amiga Support
* Linux and FreeBSD Support
* Windows Mingw and MacOSX Support
* Android Support
* Arm Raspberry Pi Support
* PPC Power Architecture
* misc
* Aros Public License

## Introduction

Libraries/Applications "automagically" open libraries that were available when they were compiled. If there is an issue, it would be easiest to downgrade the AROS version of graphics.library to 39 (in graphics.conf file) for the purpose of "frankenrom". Another option: define global GfxBase variable somewhere in layers - this should prevent the "automagic" from working and thus you will need to open graphics manually.
* autoconfig (wip, fast ram expansions already work, autoboot rom support to do. Very important for UAE harddrive testing)
* expansion.library is currently set as noautolib. Is it because expansion (autoconfig) is not needed in non-Amiga systems or it needs to be initialized some other way?
* utility.library math functions are ugly piece of work. Double return values (D0 and D1) - A0 and A1 must be preserved. Eww. Just eww. Looks like a bunch of ASM work needs to be done here for m68k. Did you check arch/.unmaintained/m68k-native/utility ? Only need to dynamically select between 68020+ and 68000/010 versions.
Getting rid of the rom directory as different arch may put more or less modules in rom. Some arch may even make it configurable which modules to put in rom depending on how much non-volatile storage is available. Having the rom/ directory make the m68k port easier, simply because only had to support the librom.a minimal AROS C library, not the full AROS C. In ABI V1 librom.a is gone. There is one library in arosstdc.library that will be usable by all modules. It will be initialized as one of the first modules. Therefore also the IO functions are moved to arosstdcdos.library that is disk based module. How are you handling the ctype.h family of functions? I would like to see an option for LANG=C only stripped down set.
I think there should be defines for TaggedOpenLibrary library id numbers. (but where? It should be only used by rom code). It would be quite useful in m68k-amiga because it makes rom file slightly smaller (currently there are lots of library name strings here and there). UtilityBase = TaggedOpenLibrary(7); looks quite ugly..
workbench/libs/gallium: -Wall cleanup. Different enum types are being compared, and the compiler is unhappy. I looked at the enum lists for each type, and they seem very different. The code is like this in the trunk of main Mesa repo as well (workbench/libs/mesa/).

### ROMmable

The following changes to the genmodule tool will better support ROMmable modules:
I have an alternative solution also used in the ABI V1 branch. The only assumption that is made is that LIBBASE of the library we are executing code in A6 (on i386 this is in *(%ebx) ).
To me there is no place in clean code for these #define hacks, they change the semantics of some code (struct IntuitionBase *, function pointers to functions in amiga shared libraries, ...). It is incompatible with how the C library is implemented in ABI V1. The stubs code for stack based functions in a library needs the global libbase and a #define won't be noticed. Problem for C library still remains in ABI V1. Maybe a static C link library can be reintroduced in the arch/m68k-native tree, allow me to have what in my mind is a proper and clean m68k branch.
Constraints:
(1) Don't want to put BSS in (precious) Chip RAM (2) Some machines have Fast RAM, some don't, so I can't *at compile time* determine where to link the .BSS to. (3) Due to (1) and (2), .text cannot have absolute references to anything in the BSS - i.e. FooBase, BarBase, etc.
The '#define hacks' allow me to satisfy all constraints, and I do not plan to add them to the source code itself - only genmodule, and only when it is targeting a read-only ROM.
The end result of all of this is that genmodule would run in two (target depenant) modes: .bss mode for disk loadable modules, and .rela.bss mode of ROM modules. Hmm... .rela.bss.... (/me thinks)
Also I would be able to *remove* a lot of the '#define hacks' that already exists in the codebase, since only genmodule would need to be concerned about where to place the library handles.
An alternative. Make a custom link script for the ROM that links all kobjs together with the BSS sections linked to the first page(s) of chip RAM. Bootstrap code would then need to copy the initialization values to this page. In a later stage on machines with a MMU to remap the ROM and the BSS section to fast RAM.
In the _start.c file you would have the following
Code should then do
gfx_rel.h would #include <inline/gfx_rel.h>
and in inline/gfx_rel.h you would have the following:
This last code without inline can also be used in as stub in the static link library. The link library would be called libgfx_rel.a etc.
If you look in the repository in the branch branches/ABI_V1/trunk-genmodule_pob/AROS/tools/genmodule you should find most infrastructure there. Only GET_A6 is called GET_LIBBASE and is implemented as inline asm in aros/$cpu/cpu.h (only i386 ATM). Problem is that it can't be introduced in the main trunk without breaking bin compatibility in i386/x86_64 because there is no reg allocated now for that purpose.
This would move the auto-opened libraries to the LibBase, out of BSS, making the process of building ROMmable libraries easier. No code changes would need to be made to existing libraries, and no ABIs would need to change.
I would think you need to pass LIBBASE as a parameter then to the function explicitly. You can still do this and put it in A6. The only quirk would be things like callbacks that are not listed in the .conf file, which would want to get handles to the library's opened libbases. How is that handled? Or should those callbacks be specified in the .conf? ReadStruct/WriteStruct are good examples. Their callback routines (in the Hook structure) will probably want to talk to both the LibBase class and DOSBase.
Basically all code that currently uses libbases should provide also alternative code that uses the _offset variable. So in the ABI V1 branch for each library there is now libxxx.a and libxxx_rel.a static link library generated. The former will have stubs for the functions in the library using the global libbase, the latter stubs using _offset. If you link code with the latter lib but don't define the _offset variable you get a linker error. The m68k ROM module would need to link -lxxx_rel (or uselibs=xxx_rel).
For Hooks I think we need provide support for saving A6/LIBBASE in the Hook data and restore it by a special support HOOK function. Don't know if this is possible and if it would have impact on the number of arguments that can be passed.
For the hooks I was looking at (datatypes.library, the LibBase was already in the Hook's h_Data. So I just added
at the start of the hooks manually, and everything was good.
(I have a patch for datatypes.library that makes it ROMmable, using the '#define hack', putting the LibBases in the LIBBASETYPE explicitly, and explicitly opening them on the library's init, and modifying the hook routines as described above.
Could BHFormat be reworked so that it doesn't open muimaster.library if run from the CLI? The system could ask inserting different disks. A CLI version of format could be included. System/Format could be reworked to get rid of some dependencies or at least work with the basic libraries (I don't think iffparse or datatypes should be required for formatting, but are subdependencies of muimaster.library.). How about reworking BHFormat to have a ./configure option to only use gadtools.library instead of MUI Master? I have to have gadtools in the ROM anyway for AmigaOS 3.x.
Which ones should I work on making ROMable?
C/Shell - Yes! Shell is a good one since it's in the original kickstart and booting without Startup Sequence it allows you to perform operations without the need of accessing the HD, it's a good candidate.
Libs/arosc.library - I suppose that since arosc.library may be used by various programs and system components it would be quite interesting to have it on ROM to be able to launch various apps from the shell.
Libs/datatypes.library - I this requires datatypes on disk so I'm not sure having it in ROM would help much. It's nice to have because programs requiring it wouldn't fail loading but since there wouldn't be any datatype loaded I don't think it's necessary.
Libs/muimaster.library - MUI uses external classes and I don't know if it allows loading apps without external classes present. If it does then it may be useful but if it doesn't then skip it. Lots of dependencies.
Libs/asl.library - This may come very handy with an updated Shell with auto-completion...
Libs/diskfont.library - Not prioritized. If you want to load fonts from disk then you can also store diskfont.library on the same disk.
Libs/gadtools.library - This may be useful for some basic apps. I can't remember if it's present in default KS, if it's not then it's not so high-priority. KS 3.0 seems to want it in ROM. Along with If, EndIf, and some other commands.
System/Format - If you have a system capable of accessing writable media then you'll be able to access files outside rom too. It's a nice thing to have but IMHO "Format" is not a priority.
The basic infrastructure for ROMmable shell commands. There seems to be an alignment issue, though, since sometimes it just works (adding 'shellcommands' to KRSRC), and sometimes get a hang. Can someone review the 'pure' changes I needed to make to workbench/c/shellcommands/Shell? Test the built shell, and it seems to work for trivial tasks.
At first, found it a little difficult to program in the .bss and .data free Pure style, coming from a MMU OS (Linux) where shared executable pages are easy, and -fPIC compilers actually work. But coming to really really like the Pure style, and for AROS we should promote the style and advantages more. Here's, just off the top of my head, some of the best parts of Pure:
All Pure programs/libraries can:
* have their .text segments marked read-only
* be linked into a ROM
* can have multiple executions of the same object, i.e. Shell[1], Shell[2], Shell[3] all share the same .text segment
Due to the above, for low memory systems, Pure is a total win. In an ideal world compilers wouldn't support BSS or data sections. All these MMU tricks etc. are just work-arounds for programmers' laziness. And don't get me started on garbage collection ;-) Yes, it's a little more work to code in Pure, but think it's worth it. I can't disagree more. In my mind the compiler and/or build infrastructure should make it possible to have pure programs using global variable, auto-opening libraries, etc. Then, this would require a '-fPIC Data' style, correct? Where the .text segment could be linked to any location, and there is a 'task global' (either a member of struct Task and/or a register) that points to the task's "private" .bss/.data area. This is similar to the Amiga BCPL support, in fact, and the tc_GlobVec pointer would be just the field to use, since it would essentially be providing the same service. But I'd hate to be the one to implement the compiler changes for all the supported AROS archs to make this happen. I'm more in favor of a register to use for storing the global pointer. It would be the same register also used for the libbase as it has similar function. On i386 ABI V1 I used %ebx for this; which is a stack pointer *(%ebx) is the place for storing the base. For m68k A6 would be used.
-fPIC under ELF for most architectures wants to use a 'global offset table', and position independent code (which takes ANOTHER register out of the available pool). To make '-fPIC-data' - I'm not sure about how to do that easily. In adtools' gcc there is a --baserel options but I don't know much more than that it exists.
Also I think that in the ABI V1 branch the base is there to have this possible. Please try to limit the code you convert to this Pure way of doing things.
Can linker merge identical strings in rom? I noticed rom is full of dos.library, intuition.library etc.. strings? (and all kinds of debugging strings too). Wasn't that the purposed of exec.library's TaggedOpenLibrary - it took a bunch of magic numbers and did the appropriate OpenLibrary("blah.library") for that number. That would solve the repeated string problem.
Only do manual opening of libraries when really needed for backwards compatibility. Don't do it for fun. The main goal was to make the program pure. This means - it can now be made resident using C:Resident. Just the command is very small and I thought it is a good idea. It is not about the fact that it is small or large program. Problem is that code in repository is often taken as start by programmers to start new projects. This way bad habits get spread. In the past I have spent considerable time to get rid of these manual opening of libraries often filled with bugs as the exception clauses are not in the common code path. And it really hurts me every time I see this code being re-added. When in ABI V1 I do think to implement a compile switch that allows making programs able to be included without needing to do something.

### Dos Library

Autoconfig boot rom is now supported, UAE uaehf.device gets initialized properly but it crashes when it is time to init dos.library. AROS dos.library seems to be normal autoinit library but official roms do it differently. Well, what actually seems to happen is the bootblock returns both D0 (error code) and A0 (pointer to a Resident rt_Init structure), and the Boot Block loader is supposed to MakeLibrary with the rt_Init passed in. (assuming that the bootblock returned D0==0, then it also returned a Resident InitTable in A0).
All autobooting harddrives' boot rom code do following at the end of boot phase:
aros dos rt_init contains init tables, not code -> crash. dos rt_init code initializes dos.library "manually". InitResident is not used for this. (dos is weird, even after BCPL was gone). The first thing to do is to add an option to genmodule so as it is able to generate libraries not relying on RTF_AUTOINIT flag. The rest is pretty straightforward. It will not harm other ports. I implemented reverse thing for resources (option resautoinit), it was used for battclock.resource. It is easy. Existing genmodule's code can be used for resources.
How to do this without breaking non-m68k builds? How to disable autoinit and put init code pointer in rt_init? Harddrive boot code includes final jsr or jmp in autoboot rom. It can't be patched.
Floppy boot code does return dos resident in A0. Which means it can be fixed without touching dos.
But nothing prevents floppy boot block to also having jsr(a0), it isn't going to return, it was only designed this way to allow strap to free temporary resources (boot block buffer, trackdisk, etc..) before starting dos.
Note that replacing AOS dos.library with AROS dos.library will not work, because it is very incompatible in things which interface with filesystems, starting processes (like the Shell/CLI stuff) and probably other stuff.
MorphOS dos.library is based on AROS one but much more compatible to AOS. You would have more luck with that one. That is ... until you want to use other AROS components like filesystems which use FSA packet API, which will not work anymore.
Currently latest problem is simply NewAddTask getting or reading startup parameters (startup pc etc..) incorrectly and crashing because of bad initial PC.
Couldn't the initial ROM be mostly a loader for disk based modules? Would love to, but afs.handler depends on Intuition, which depends on Graphics, Layers, oops, .. This could probably be changed so that afs.handler only opens and uses intuition if intuition is already loaded at the time the handler wants to show a requester. It already checks if the first intuition screen is open beforehand.
Shouldn't workbench/libs/partition be in rom/partition? Yes, the entire source tree could do with a clean up, and this has been discussed before on this dev list. It looks like a component you'd want to have to be able to boot from a hard disk on m68k. It is not needed, this is autobooting hard disk driver's task. (read partition tables, add partitions, add possible filesystems in RDB). Of course we don't need to simulate this with future rom built-in drivers. In existing ports it's used by the strap module to mount partitions, so it needs to be part of the kernel (or to be exact, loaded by the bootloader).
Boot priority is already stored in the partition table. Only in RDB one. It's not stored anyhow on CDs, USB flash, etc. The priorities of unpartitioned removable media such as CDs and floppies have traditionally depended on the priority assigned to the drive they're in. Bootable USB sticks use SFS in an RDB and therefore have a priority just like internal HDs. MBR partitions don't store priorities, but there are other reasons why their use for bootable volumes isn't recommended anyway (e.g. a custom device name can't be chosen).
All existing graphics HIDDs seem to include attrbases tables that are not rommable. (writable data and bss). We actually have a BSS (ugh) on the m68k-amiga ROM. If you can deal with just having BSS, we're good. A note/warning about performance loss. Hidd stubs do not generate error/warning now, if used in ROM-able code, but the performance will suffer drastically when they are in use. Instead of initializing the methodID only once, they will call oop.library/GetMethodID upon every use of these stubs. This cannot be fast... ;) Understood. I'll need to find a (clean) way to AllocMem an area of all of the stubs in a class to use to store their MIDs. (just so everyone else knows, this slowdown should only impact m68k-amiga). Just committed changes to Intuition, Hyperlayers, and Graphics that remove the need for them to have .BSS and .DATA segments. This is required for the two-rom-split method of getting AROS into UAE.
Is there some kind of framework for compiling and linking ROM build-in resident commands? (at least add resident and friends seem to be implemented. About pure binaries, look at C:Dir, some commands which i backported from MorphOS are pure. In a short, they don't use startup code and any global variables. That's factual.).
Most KS2.0+ bootable disks require build-in resident commands and I guess boot shell should be some kind of resident program too. Programs in workbench/c/shellcommands can be integrated into shell binary. Look at macros there. They are defined in shcommands_notembedded.h. And there is another file, shcommands_embedded.h. I don't know what is needed to make use of this feature. Looks like no-one has tried it for a while.
Look under AROS/workbench/c/shellcommands/, you'll find programs that use a set of macros defined within AROS/compiler/include/aros/shcommands_notembedded.h.
Those macros expose an interface that should be reimplemented in shcommands_embedded.h in order to produce programs that can be embedded in ROM.
As of now, those macros let you produce reentrant code effortlessly, write the embedded version of those macros unless you want to embed the produced files "as is" within the ROM and use LoadSeg on them then (which could be a viable option, depending on your needs).
Those macros expose an interface that should be reimplemented in shcommands_embedded.h in order to produce programs that can be embedded in ROM. DOS/AddSegment will be very useful as well. Have to hook FindSegment into the LDDaemon to complete the picture...) I'll make sure to have the FindSegment in LDDaemon at a *lower* priority than on-disk executables, so that we don't lock-in the ROM versions.
Amiga IDE support is also in my "implement soon" list. Do I add #ifdefs to existing ata.device or do I need to do something else? (it seems to be too PC hardware specific and not exactly modular). I would go for separate module for Amiga. The ata.device is a "touchy" ;) subject - it has been broken many times by people trying to improve and there always seems to be not enough testers available after changes are made ;)
Most of those breakages are through necessity because the old code was severely handicapped/badly designed - personally I think its working extremely well these days since there are hardly any reports of it not working - if at all. The only thing (imho) still needing to be done is to correct the initial probing code to not add legacy ports that haven't been associated with an ata controller, if it has found pci controllers with devices attached.
Im not sure how different the amiga's internal ide implementation is - but I would imagine it would be possible to move the bits that do differ (probing, programming the chipset directly) into separate files and only include those in your specific build .. e.g. dma_amiga.c
I'm also not sure how the elbox fast ata etc. controllers work but it would be nice to have AROS able to support them also (I have 2 still, as well as 2 mediator PCI-bus boards).
I checked NKD autodocs for 1.3 and 3.1 and in both cases these functions are described as returning BOOL. Please note that AROS aims to be compatible with 3.1 not with 1.3. You might need to completely separate dos library into arch tree if such changes are needed.
I also think this change might break binary compatibility on existing ports (BOOL is 2 bytes AFK while LONG is 4 bytes). The NDK autodocs for 1.3 and 3.1 and in both cases these functions are described as returning BOOL. Please note that AROS aims to be compatible with 3.1 not with 1.3. You might need to completely separate dos library into arch tree if such changes are needed.
what do I do with dos.conf? Lock/Open (and others) aren't aliases anymore. (dos.conf not committed) I think the easiest thing to do would be to make stub files in rom/dos/ for the aliases functions, then you can check in dos.conf that doesn't have the aliases.
DevCD NDK 2.0 and 3.1 dos_protos.h: <snip> LONG Examine( BPTR lock, struct FileInfoBlock *fileInfoBlock ); LONG ExNext( BPTR lock, struct FileInfoBlock *fileInfoBlock ); LONG Info( BPTR lock, struct InfoData *parameterBlock ); </snip> Same in SAS-C include/clib/dos_protos.h. n fact BOOL and ULONG return types are binary compatible. In any way the value is returned in a CPU register, so it occupies the whole register. The difference is only how it is evaluated. For example on m68k WORD would be evaluated using tst.w and ULONG - using tst.l. Just NDK 3.1 definition guarantees that upper half of the register will not contain trash.
WB3.0 C:Assign seems to do this: if (AssignLock(whatever, NULL) != DOSTRUE) then print "can't cancel > <whatever>". Failed. Unfortunately AssignLock return type is BOOL . Replace it with LONG (for example) and Assign works correctly.. Seems both are broken, as BOOL should be typedef'ed as "short" and AssignLock really should be LONG according to original AOS includes. Ah, AssignLock returns LONG but AssignLate, AssignPath and AssignAdd return BOOL. (Mistake that was fixed in later version?)
Testing KS 3.1 CreateNewProc: CreateNewProc's NP_Arguments tag Does NOT add "\n". Input DOES return NP_Arguments argument stream. RunCommand: Same results. Does not add "\n", Input+FGetC returns command argument(s). There was tiny difference: (probably due to different input handles) CreateNewProc FGetC returned EOF when argument stream ended. RunCommand FGetC waits for more characters (press return in CLI returned one linefeed) SystemTagList test results: it seems to do everything (or is it shell that does it?) All whitespace (spaces and tabs) swallowed between command and arguments. Trailing whitespace is not swallowed. If "\n" already in argument string = end of argument string. If no "\n" in argument string = add one at the end. CreateNewProc's NP_Arguments tag does NOT add "\n". Input DOES return NP_Arguments argument stream. Also without "\n" at the end of argument string RunCommand FGets does not return until return is pressed.
C:Run does this (maybe others too?)
This can't work in dos packets mode. CurrentDir takes and returns FileLocks, Open returns FileHandles.
Dos packet way of duplicating console handles (and only console handles) is:
Do we need special function for duplicating console handles or how to solve this incompatibility? (at least until everyone switches to dos packets) Currently AROS C:Run hangs, WB2.x/3.x versions work.
dos.library/MatchNext does not always return ERROR_NO_MORE_ENTRIES when it finishes. ("go out of for(;;) loop --> MakeResult" does not set ERROR_NO_MORE_ENTRIES) It confuses WB3.x:C/Dir. "(null)" appears in rightmost column if number of directory entries is odd. Never mind. It is not MatchNext bug (It works correctly, I was blind again) It is WB3.x:C/Dir misusing (?) VFPrintf (RawDoFmt), expecting %s with NULL pointer (not pointer to empty string) to produce nothing in output. KS 3.1 confirmed, RawDoFmt completely ignores %s if string pointer is NULL. It does not attempt to access address zero either (confirmed with UAE memory watch points)
Been noticed this several times already. Please use a named constant instead of a number and a comment; that way, the compiler can check that the offset if correct and people know which function you're calling. First I have to say: gcc 680x0 assembly syntax is HORRIBLE. (at least to anyone who started coding for Amiga in assembly in 1980s..). Sorry about that but I don't know (or want to know, see above) how to make working constants. This is Jason's problem :D
GCC 68k also understand Motorola 68k syntax automatic. you can write jsr -(76*6)(a6) best is when you write 68k asm code as a separate file. GCC asm detect for small .s or large .S, if your asm file have a large .S (for example file have name myasm.S) then C define preprocessor can use in asm code, too.
Open FMF_x parameters are a problem under m68k-amiga. (Used in many places inside rom modules and aros applications). It breaks SnoopDos and probably all other programs that take over dos/Open vector.
a) get rid of them completely? (are they actually even used?). Choose this. The new modes were never even documented in the Open Autodoc AFAIK. They are documented in and also quite used. I meant "used" as in "actually does something different than only getting converted back to ACTION_FIND* in packet handler or most flags getting ignored in original non-dos packet version of afs.handler". Don't mind having some kind of NewOpen with new better/extended mode flags but using original Open with totally different and incompatible mode parameter can't be right.
b) add some wrapper that converts FMF_ stuff to original MODE_xxxx parameters before calling Open. (instead of wrapping them inside Open, this is how it works in dos packets mode currently)
My suggestion...
1) dos.library should be free of extensions, to be compatible with AmigaOS 3.1 up to the binary level (that extension I implemented years ago was supposed to be binary compatible as well, but In didn't take into account programs that would SetFunction some of dos.library functions and take over them.
2) an arosdos.library could be implemented, or some hidds, or some other thing that would implement the extensions.
The scheme would be as follow
There should be one packet handler wrapper per aros dos handler. In case of a dos handler based solely upon packets (a port from AmigaOS) then an aros-specific packet.handler would act as a wrapper around it, as it is now I think.
The immediate result of getting rid of those flags right now is that we would lose functionalities in the arosc.library (or however it's called in Staf's modifications) since they are implemented system-wide at the level of dos.library, like file append for instance. And pipefs would not work anymore (but it would need a rework anyway, since it's quite antiquated and doesn't really work well).
The idea would be to be "future proof", and not fossilize on the old amigados packet handlers. Without a clear "new dos" project to push forward, though, the only viable options are: either keep everything as it is, trying to find the ways to be compatible with the AROS way *and* the AmigaOS way, or just go for the AmigaOS way.
This is the mapping in use:
As you see, MODE_NEWFILE would also create the file if it doesn't exists and clears it if it does, so you should not use it in that context. Use MODE_OLDFILE instead for everything.
What do with AROS code that allocates struct FileInfoBlock from stack? This does not guarantee required LONG alignment (BPTRs and m68k-amiga). Replace them with AllocDosObject? But it adds yet another memory allocation test and memory free call, I think it makes simple code. Too complex and ugly.
New macro that allocates from stack + hides the alignment hack? (preferably macro that also works with other DOS structures like InfoData too).
Code like (from c/dir.c):
is imho too ugly..
IMHO just use AllocDosObject, since allocating. Is that really an issue with GCC? There are some alignment options for a lot of stuff from the int and long - and FileInfoBlock starts with a LONG (-malign-int).

#### BCPL_Action

Anyway, all DOS structures introduced pre-2.0 should be allocated with AllocVec because it was the BCPL way.
trying to boot a Workbench 1.3 ADF. I'm able to load the 'Shell-Seg' Shell DOS process, but it's using the (nearly impossible to google) dos.library *BCPL* interface.
I think it is not impossible to provide a 'thunk' from 1.3 BCPL interfaces to Library interfaces. Just A Small Matter of Programming.
IF.. we can find documentation....
Here's a dump, where I have stubbed out the BCPL Action routine (stored in reg A5) with a debugging call. Ie:
The 'BCPL4Amiga.lha' archive on aminet.net is a *treasure trove* of information:
* How to call BCPL routines
* How the BCPL stack frame works (eww!!!)
* What D0/A1 is (it's NOT what I thought!)
* What almost all of the pr_GlobVec AmigaDOS offsets do!
I think I can make a BCPL thinking library from this, no problem!
If I can add this support, it would give AROS m68k the ability to run all the Amiga 1.0-1.3 BCPL CLI commands!
It'll give me something to do while I wait for Toni to finish the graphics drivers.
This might also help.
Actually, in this case, I do believe the printed English version of the Amiga Guru Book would be the best source of information.
Hm, actually the C= guys tried to remove all BCPL stuff from AOS and explicitly replaced all the related CLI commands with C equivalents which go via DOSBase instead of a GlobVec - if I do read it correctly, with V37 only 4 BCPL handlers in L: where left. All remaining GlobVec legacy was re-implementing on top of dos.library - thus also avoiding the option to keep local copies of a jump table with modified entries for jump vectors.
Having a global (resp. local) non-library-based vector as jump table with both - public and private data entries, BSS and the ability of overlaid loading of different modules of a program, well, it could be considered both: very flexible or utterly broken ;-) The "Chapter 16" of the Guru Book "BCPL and the Global Vector" starts with a quote saying "If you understand it, it's obsolete."
IMHO it would be more useful to have all the C-based standard CLI commands and filesystem drivers from V37 and beyond working than old BCPL stuff.
AOS 1.0-1.3 code/tools does not provide any missing functionality to a "Frankenrom".
Of course a compatibility layer for other, non-OS BCPL code might be useful - but then again it may only be relevant for specific hardware drivers which are neither available for UAE nor most Amiga models.
Basically just for anything that is not V37-aware and requires a GlobVec other than -1. Is that worth the overhead?
How (well) does MorphOS implement BCPL legacy? Or does one at most get a GlobVec of -1?
I would agree, but one of my unstated goals is to have AROS M68K be able to run all the Workbench ADFs that come with Amiga Forever.
Also, a number of 'magazine disks' use L:Shell-Seg. I'm going to work on supporting L:Shell-Sig from AOS 1.3 only for now, as that will bring in the maximum advantage to AROS m68k as a ROM replacement.
The BCPL thunk code does not seem, at this time, to be taking up too much code space, and I'm putting it in arch/m68k-amiga/dos/, so it won't impact any other ports.
Do not enable 32-bit fast ram boards, for some unknown reason booting hangs if it is enabled. This is now fixed. Normal pointer to BCPL conversion error in NIL handler, worked only accidentally. (It took ages to find this one..) I guess BCPL pointer bugs will be the most common ones because no other port needs them. Perhaps it is possible to add some BCPL pointer debug check macros? For example check that pointer's 2 lowest bits are zero when converting to BCPL pointer and check that BCPL pointer points to expected memory range? (They nearly always points to non-existing ram if conversion is done twice or it is missing)
There are not any other than original Commodore BCPL WB 1.x programs and related software like handlers. (Did anyone even have a BCPL compiler outside of Commodore?) It most likely didn't prevent non-BCPL programs from using BCPL features. Problem is finding them (maybe very old PD disk series?)
should remember that BPTRs don't really exists on (all?) other ports..
It's the first one that is opened via diskfont.library/newfontcontensts.c. Don't know which one that is exactly, the file name is 20.
This should be already zeroed when hunktab was allocated. But it doesn't seem to be or it's overwritten later.
I've added some more debug messages e.g. to KrnUnregisterModules, here comes a debug log that might help bit, you can see from addresses it is on a 64-bit machine:
Many AROS programs have this:
A6 does not and can not contain SysBase in m68k-amiga port. It contains BCPL magic (actually most address registers contain undocumented BCPL stuff) and it is impossible to detect between normal and BCPL programs at runtime. (some can have normal C startup then do BCPL stuff later..) Are there any ports that do *not* have a global SysBase that user space can get to? Is the only way to get SysBase at program startup and library init on m68k by the absolute address $4? I think there should be a way to pass SysBase to a new program or library without needing an absolute address. The latter is especially difficult on hosted platforms. As a last resort we can do it again during loadseg so a symbol name SysBase gets the right value by the loader. I do prefer the current solution though.
The loadseg way of initializing sysbase? Nothing. If you look at InternalLoadSeg_ELF, it already handles that case: rom/dos/internalloadseg_elf.c: Lines 388-406. So only (a) HUNK architectures that (b) don't have a global SysBase need SysBase passed to them. I don't think there are any of those under AROS. That a wrong strip of an executable will make it unusable. This linked with the fact that we plan to switch to ELF executables in the future and not relocatable objects. We still need relocation info in the file.

### Intuition Library

Unfortunately intuition and layers had other m68k build issues that made gfx HIDD testing impossible. OpenScreen internals do not work. It is already partially fixed but at least one more problem remains.
More important issue is that I can't seem to get mouse working (software nor hardware). IntuitionBase->ActiveMonitor is always NULL, intuition/misc.c only sets mouse if it is non-NULL. MySetPointerPos is called and mouse coordinates change when I move the mouse. It looks like graphics subsystem thinks mouse is shared with other host windows. aoHidd_Gfx_IsWindowed is set to FALSE.
If old modeid is not available, openworkbench selects 640x200 resolution but still uses original saved display dimensions.
This causes visual problem (and huge chip ram usage) in situations where some RTG mode has been saved (for example 1024x768) but we are now booting with RTG board disabled (or removed), result is huge superbitmap native chipset screen in normal 640x200 resolution. Which is quite annoying. It should fall back to original nominal dimensions and depth if mode was missing.
Perhaps boot menu screen selection and openworkbench screen mode selection should be merged? Both need similar special code to select the best mode, especially when using Amiga hardware (PAL/NTSC/RTG)
Amiga port uses following "default" modes:
* 640x256 (PAL) or x512 (interlaced)
* 640x200 (NTSC) or x400 (interlaced)
Above modes use either two or four planes. Yes boot menu is fine but the problem is initial screen (shell) default resolution and aros boot image resolution. It is 640x200 on NTSC machines, 640x256 on PAL machines. (But both PAL and NTSC modes are added to mode database if chipset supports PAL/NTSC changes = ECS Agnus or newer) AROS m68k also adds early Picasso96 driver "RTG" support which means resolution of 640x480. Not all RTG Picasso96 drivers support PAL or NTSC -like mode resolutions. Only the gfx driver knows which is the best "default" mode unless some ugly checks are added to common code (like current boot screen resolution selection does).
And finally, initial screen must be 2 planes only due to bandwidth and chip memory usage reasons but AROS boot image is 16 colors and assumes square pixels (=interlace needed)
Other supported platforms can work with much simpler solution because they all support at least 256 color screens and there is no huge vram/blitter bandwidth bottlenecks.
Interlaced and 4 planes only needed when opening boot screen image (for correct aspect ratio) Use of 4 plane hires for boot menu or initial shell is too slow on OCS/ECS chipset.
Perhaps some kind of function in gfx hidd that can be asked something like "give me array of modeids+depths for x" where x = boot menu, boot image or initial shell screen? (Remember that depth is required if planar mode)
640x480x8 (if RTG mode, 640x400 or 640x512 may not be supported)
Intuition/monitorclass.c/SetPointerPos includes hotspot offsets in HIDD_Gfx_SetCursorPos coordinates which does not work with Amiga chipset if mouse sprite resolution is not same as screen resolution. (Most common case is lores sprite and hires screen)
Hotspot should be in sprite resolution pixels, not in screen resolution pixels.
For example if hotspot is -3, screen is hires and sprite is lores: Sprite is moved left -3 hires pixels, but it should be either -6 hires pixels of -3 lores pixels. (HIDD can easily convert this automatically, SetCursorShape already includes hotspot offset data)
amiga-m68k native mouse positioning works in all resolutions correctly if SetPointerPos "Take HotSpot into account" is removed and hot spot offset is handled in HIDD.
HIDD coordinates are top-left corner of the sprite. The graphics driver has no clue about hotspot (except hosted, but it's there just for input reporting only). Sprite coordinates should come in sprite's resolution. Just previously, there was no separate sprite resolution.
Sprite shape resolution != sprite positioning resolution. Sprite shape is independent of positioning (at least on AGA, ECS and older have restrictions) remember the sprites on AGA machines had positioning resolution independent on the screen resolution. Which meant the sprite moved with HiRes (or even SuperHiRes) resolution even on LoRes screen. There's a flag that has to be set in order for that to happen though. The default setting is to have LowRes sprites on LowRes and HighRes screens and HighRes sprites on SuperHighRes screens. The resolution is globally set for all sprites though.
Normally sprite has lores pixels but hires horizontal resolution.
-> graphics driver needs to know hotspot offset. (or it needs to know mouse pointer resolution so that it can add correct offset). There's no "hotspot" in the sprite. It's just a sprite. Hotspot is Intuition's thing. Doesn't this mean that sprite position should be specified in bitmap's resolution? Well, in "positioning resolution". Guess positioning resolution == screen resolution. So, Intuition can adjust offsets. In fact moving mouse pointer is actually MoveSprite. I added monitorclass method only for convenience. Added these methods to monitorclass in order to remove hotspot specification from ChangeExtSpriteA. Previously hotspot specification was a private extension there. See SVN history.
It can't unless Intuition knows the sprite resolution, which is the problem. Sprite position is always in screen resolution, this is not the problem. (Hardware may not support it but it is not Intuition's problem)
Yes, this is quite backwards way to do it (Move the mouse instead of moving the hotspot) but correct fix would require Intuition update so that it knows mouse resolution and at least I don't want to touch that stuff. This quick fix at least makes Amiga native modes usable (and afaik no one else uses hardware cursors so this won't affect other platforms)
Here is visual explanation because I am still not sure if my previous explanation was too confusing..

### Icon Library

In: workbench/libs/icon/./diskobjio.c is sdd_Stream a BPTR to a file, a pointer to a buffer, both? Where does sdd_Stream come from? This stuff comes from big Endian struct reading/writing support in compiler/arossupport. The type of the stream can be whatever and depends on what the hook function wants it to be (is passed to functions like ReadStruct, ...).
icon.library uses dostreamhook (in support.c) which needs stream to be a BPTR (file handle). support.c/ReadIcon_WB does the initial ReadStruct passing "file" param (BPTR) as stream value.
icon resizing only kicks in if an icon's Gadget->MutalExclude has (1 << 31) set, so all old icons should continue to be displayed pixel-for-pixel.
ilbmtoicon now accepts a --dpi x:y parameter (default is 72:72, the old Macintosh desktop publishing resolution) to allow you to specify the icon's default resolution in dots-per-inch.
This is translated into Amiga Display Resolution Ticks, so that the icon.library logic doesn't need to do any unit conversion.
The icon scaling is a bit rough, but it is fast for C code. (Could be faster if someone would implement the HIDD hooks for CyberGfx/ScalePixelArray..).
BitMap icons are scaled with BitMapScale, and ARGB icons are scaled using a Bresenham rescaler (needs to be extended to average pixels when scaling up), since BitMapScale appears to clobber the 'A' portion of ARGB bitmaps.
As I noted in my commit message, I need to add an additional tag to IconControl to help Wanderer control icon scaling.
We should also put in an override in Prefs/ScreenMode to allow the adjustment of screen DPI/DPC too, via the MonitorSpec ratioh/ratiov parameters. From my understanding, the display width/height ratio defines (or has an impact on) the pixel width/height ratio. E.g. if a single pixel is square by default, running the display in a different resolution than the one which it physically provides may change that aspect.
From my testing on AOS 3.9, MonitorSpec's ratioh/ratiov do not change (ie, they are always RATIO_UNITY) regardless of the screen mode (even 1280x200 NTSC was ratioh=16, ratiov=16)
Therefore, I believe those parameters do not reflect the pixel size, but the monitor size itself.
As for DRI Resolution, I believe that the equations I have posted are a good approximation of the AOS behavior, and allow extension to other display formats (widescreen, portrait mode, etc)
MonitorSpec ratioh and ratiov are fixed-point fractions, are defined by the RATIO_FIXEDPART and RATIO_UNITY macros.
What they are a ratio *of* is still a bit of a mystery. Maybe a ratio of 'this monitor' versus a 1084S?
It's a little related. MonitorSpec's ratioh and ratiov always appear to be RATIO_UNITY (1.0) on AOS, so I'm going to have AROS calculate ratioh and ratiov like this
Monitors that comply with the VESA EDID spec will have MonitorEDIDWidthMM and MonitorEDIDHeightMM set from the EDID information, and all others will assume a 4:3 13" monitor.
A Screen's DrawInfo 'Resolution' parameter (in 'ticks') would be calculated as
(res.y will be slightly different for Amiga NTSC screens, with a value of 56 for 200 rows instead of 52, but that should not be a big problem)
With this information, an application can calculate a display's DPI as:
.. and then, there will be enough information to dynamically rescale icons based upon DPI and aspect ratio of the screen.
MonitorSpec: ratioh, ratiov - ratio between size of a 1084S and the current monitor (larger fractions are larger monitors, smaller are smaller)
DrawInfo Resolution: Since this is related to mouse ticks, it would make more sense for this calculation to be a inverse relationship to overall DPI, instead of to the number of pixels in the display.
Therefore, DrawInfo.Resolution would be calculated as:
Screen DPI can be directly calculated from DrawInfo Resolution as:
Screen DPC (dots per centimeter) is calculated as:
From my understanding, the display width/height ratio defines (or has an impact on) the pixel width/height ratio. E.g. if a single pixel is square by default, running the display in a different resolution than the one which it physically provides may change that aspect.
IMHO the xAspect/yAspect fields in the ILBM BMHD chunk are related, when it comes to interpreting similar values in graphics/monitors.
See: http://amigan.1emu.net/reg/ILBM.txt
"Typical values for aspect ratio are width : height = 10 : 11 (Amiga 320 x 200 display) and 1 : 1 (Macintosh*)."
and from EA's ilbm.h:
http://www.steguy.bravehost.com/Amiga_Files/V39_Support_Issues.txt
and here's another interesting remark:
http://vlists.pepperfish.net/pipermail/netsurf-commits-netsurf-browser.org/2011-July/010011.html
(this overrides the DI.Resolution.x and DI.Resolution.y)

### diskfont Library

Only fixed.font or do all fonts have the same problem? Isn't it like that amiga fonts are actually hunk binaries?
Do all hunk binaries fail or just some font on non-m68k ports?
Enable internalloadseg_aos.c debugging and include related log messages, maybe it helps to find the problem (I still can't see anything wrong :
Here is the log up to segfault in FixFonts:

### Graphics library

Dynamic allocation of pixbuf for BlkMaskBitMapRastPort patch does
* Eliminates the need for the pixbuf semaphores (improving concurrency)
* Dynamically allocates pixbuf as needed
* Moves NUMPIX to the bltmaskbitmaprastport.c file, and documents it
* We can now handle source images where width * sizeof(HIDDT_Pixel) exceeds NUMPIX, so long as we have enough memory available.
Small comment: Please create graphics' private memory poll and use polled memory allocation functions, i.e. AllocPolled/FreePolled. Very frequent calls of regular, non polled memory allocations are good candidate for performance loss. AROS should get a better memory allocator. The current mem allocator is a speed brake if you use frequently allocs /free which C++ programs do. Or use arosc for malloc a better mem handler? If so, the patch Jason do should use malloc. The memallocs in the patch can too large to work in a pool. So even if poolmem is used, the alloc will go straight to a alloc of non-pooled mem mostly.
Pools are great for collections of items of identical size, but that is not the case here.
For this type of usage (variable size, unknown maximum size), pools are not very helpful. Both of these statements are just theory unless proven by some benchmarks. Personally I would think memory pools is advisable, if not for speed then for memory fragmentation or be able to deallocate a whole bunch of allocated memory with one DeletePool command. The latter is IMO most usable during clean up.
malloc cannot be currently used in AROS libraries as it is allocated on calling task context. And arosc malloc/free just uses a memory pool and AllocPooled/FreePooled ...
What is the minimum size for 'NUMPIX'? The default (50000) leads to an allocate of 200000 bytes when graphics.library is initiated. That's a little much for a buffer that is used by only a few functions. This gets you 200x250 pixels bitmap which is not that much TBH. Maybe you could change the implementation to allocation the buffer dynamically? The Root BitMap class does this for several calls (BM__Hidd_BitMap__PutAlphaImage, BM__Hidd_BitMap__PutTemplate, BM__Hidd_BitMap__PutAlphaTemplate, etc). Alternatively, please ifdef it for m68k - decreasing this value in general will mean more instances of smaller VRAM->RAM reads which will probably slow the operations.

### workbench Library

Wrote Wanderer:Tools/Info at line 58 there is:
I suppose you could try with 0 there
SYS:System/Wanderer/Tools/ExecuteStartup is missing an icon. (deleted in revision 34053, shouldn't there be replacement?)
No icon -> OpenWorkbenchObjectA opens a CLI output window because GetIconTags("ExecuteStartup") returns isDefaultIcon=TRUE.
Just wondering why no one has noticed this previously unless there is some other reason for hidden console window. (only tested using m68k-amiga port)
Without icon:
"WANDERER:Wanderer", Window: 0x00000000, Name: "CON:////Output Window/CLOSE/AUTO/WAIT", Mode: 1005
Icon added:
Looking at workbench.library/wanderer as sources well and noticed the AppMenu and AppIcon didn't seem to be quite implemented yet. It looks like wbhandler.h should have a type added for update AppMenu after update AppIcon, and the library code should send update (AppIcon|AppMenu) messages to the registered port for the event types after they're successful in adding/removing their list changes. Yes, workbench.library needs a bit of work. Was 'RegisterWorkbench' an AROS specific improvement, or is there an AOS equivalent? Seems aros specific, the ol' being AlohaWorkbench, dating back to ... hmm... well, so heck lot long time back, but it's intentionally left undocumented as the sole purpose is to register ... workbench, as ... workbench. Appendix C, page 2,... AlohaWorkbench - This routine allows the Workbench tool to make its presence and departure known to Intuition.
AlohaWorkbench - In Hawaiian, "aloha" means both hello and goodbye. The AlohaWorkbench routine allows the Workbench program to inform Intuition that it has become active and that it is shutting down.
This routine is called with one of two kinds of arguments-either a pointer to an initialized message port (which designates that Workbench is active and communications can take place), or NULL to designate that the Workbench tool is shutting down.
When the message port is active, Intuition will send IntuiMessages to it. The messages will have the Class field set to WBENCHMESSAGE. The Code field will equal either WBENCHOPEN or WBENCHCLOSE, depending on whether the Workbench application should open or close its windows. Intuition assumes that Workbench will comply, so as soon as the message is replied to, Intuition proceeds with the expectation that the windows have been opened or closed accordingly.
The procedure synopsis is:
I'm not sure its the same function, but something was written in an old amigamail or devcon article about similar functionality being supported (I've lost my paper copies over the years). dopus magellan is probably the best possibility for a real commercial client.
Ideally folks should be able to have multiple workbench.library clients running as in a multi-screen workbench program.
An app writer might want to implement workbench drawer navigation and file handling features for use on its own public screen along with having its AppWindows (not being on the Workbench screen) for drag and drop, in place of file requesters. They might want to go as far as doing their own drawer window code equivalents using PROGDIR: as a root window and showing only their project files or only supported clipart file types by showing the actual clip and not the icon image.

### mathffp.library

Building mathffp.library. Fixed, I forgot to commit header file modifications.. (btw, could someone fix lh_SysBase == NULL problem?). Use BNULL for BPTR NULLs. Just add support for .bss in the ROMs by hard linking it to an absolute address. Not going to happen. Chip RAM is precious, slow, and the only RAM guaranteed to be on all Amiga models. If I hard-linked the .bss, I would have to use Chip RAM, which would reduce the amount of RAM available for DMAable bitmaps, floppy tracks, and audio. Using space in the library's handle (which is allocated in Fast RAM if it is available) is a much better solution. Then ,store method IDs in the library base and do not use the stubs (they weren't meant for ROM code without .bss anyway) :-D
This is again m68k-amiga specific which can't expect FPU but still needs to support floating point. Which means we need to do it "amiga way" and use mathieeedoubxxx libraries. (non-amiga way would be trapping FPU exceptions, this is only allowed when emulating missing 040/060 fpu functions :))
Is the correct way to do this to replace gcc math C library functions with stubs that call IEEDP library functions? (and put lib bases in aros_privdata)
IEEEDP functions then either use software versions or inline asm fpu versions of math functions (replace lib vectors with FPU functions when library is opened)
Math libraries have few known m68k related problems.
Cmp and Tst functions are documented to return correct set 68k flags which is impossible with plain C SetSR sets the codes but final copy to D0 resets all flags.. (all math lib SetSR calls are useless in m68k C code).
Only FFP Cmp and Tst have assembly fixes, other FFP functions still return at least wrong N-flag (FFP sign bit is bit 7, not 31), fortunately IEEE signbit it bit 31. I'll try to fix IEEE Cmp and Tst later, Jason can attempt to fix other return code problems if still interested :)
Also Autodocs are slightly incorrect, for example Cmp and Tst are documented as always returning V=0 which is impossible because V flag is set/reset by m68k CMP and is required by bgt and other branch commands.. (which are documented as working with math libs!)
Linking with -libm should solve the issue. If it's already linked with -libm then I wouldn't know why it's not working. It is not yet done because it isn't that simple, proper m68k Amiga way is to redirect compiler math libs to math libraries in LIBS: (LIBS: math libraries then use either software or FPU depending on hardware config).
Is there something that needs to be done before LC_LIBDEFS_FILE can work in overridden c-file? I tried to override mathieeedoubbas/mathieeedoubbas_init.c (as arch/m68k-all/mathieeedoubbas/ mathieeedoubbas_init.c) to support m68k FPU functions. Already included ieeedpbas_fpu.c can't be used on m68k-amiga because AOS C-library math functions should call math lib functions internally, not the other way round.
Oops, I forgot to reply that LC_LIBDEFS_FILE wasn't really needed. I overrode if because I didn't want to add yet another idef _m68000 and because m68k FPU routines should always use FPU instructions, even if m68k AROS setup is compiled to be 68000 compatible (which is true today). Init routine then patches function pointers at runtime if FPU is detected.
btw, IEEE Div and Mul software versions are not implemented, anyone can implement these?
68040 and 68060 don't implement all instructions in hardware that older CPUs and FPUs supported (some rarely used instructions and FPU instructions like sin and cos) Motorola distributed assembly code (including sources) that implement software emulation of missing instructions, for example Commodore and accelerator manufacturers included it with 68040 or 68060.library. (I guess everyone already knew that?)
Motorola's emulation files come with following licence, is this AROS compatible? It should be, for example it is included with netbsd but I'd like to have confirmation before it becomes part of m68k-all.
* 08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)~
* MOTOROLA MICROPROCESSOR & MEMORY TECHNOLOGY GROUP
* M68000 Hi-Performance Microprocessor Division
* M68060 Software Package Production Release
* M68060 Software Package Copyright (C) 1993, 1994, 1995, 1996 Motorola
Inc.
* All rights reserved.
* THE SOFTWARE is provided on an "AS IS" basis and without warranty.
* To the maximum extent permitted by applicable law,
* MOTOROLA DISCLAIMS ALL WARRANTIES WHETHER EXPRESS OR IMPLIED,
* INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
* FOR A PARTICULAR PURPOSE and any warranty against infringement with
* regard to the SOFTWARE (INCLUDING ANY MODIFIED VERSIONS THEREOF)
* and any accompanying written materials.
* To the maximum extent permitted by applicable law,
* IN NO EVENT SHALL MOTOROLA BE LIABLE FOR ANY DAMAGES WHATSOEVER
* (INCLUDING WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS,
* BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR OTHER
PECUNIARY LOSS)
* ARISING OF THE USE OR INABILITY TO USE THE SOFTWARE.
* Motorola assumes no responsibility for the maintenance and support
* of the SOFTWARE.
* You are hereby granted a copyright license to use, modify, and
distribute the
* SOFTWARE so long as this entire notice is retained without alteration
* in any modified and/or redistributed versions, and that such modified
* versions are clearly identified as such.
* No licenses are granted by implication, estoppel or otherwise under
any
* patents or trademarks of Motorola, Inc.
* 08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)08:22, 5 May 2011 (UTC)~
%build_module does not support asmfiles. Could anyone more familiar with this add support?
I need asmfiles support to build 040/060 missing instruction emulation module. It is m68k-only, there is nothing to override and it requires m68k assembly.
I assume r38541 and r38542 are those Motorola codes, right? What about files in m68k-all/mathieeedoubbas. Is this Motorola code as well? Actually, that's just the 'normal 68882 FPU' instructions. Toni's talking about a separate issue, which is the emulation code from Motorola to support partially implemented FPU instructions on the 68040 and 68060 (which had most, but not all, of the 68882 FPU in them).
Yes, some rarely used non-FPU instructions are missing. They are also handled by emulation code.
<snip> The unimplemented integer instructions are:
</snip>

### lowlevel.library

Lowlevel.library is not a rom module (it is rom in cd32-only) and also there is no amiga hardware specific implementation yet = on-disk original version must be supported.
Without this hack you only get random memory corruption that is difficult to debug when lowlevel.library is expunged (for example whdload does this at startup)
Better question is: how does original keyboard.device survive? Perhaps it does not use or need opener specific structures? Is there any test case/test application that can be used to compare results AROS vs OS3.1? I assume there is nothing about this in RKMs/Guru Book and we can't disassemble the KS binaries to check. Multiple OpenDevice("keyboard.device") on KS3.1 return static value in io_Unit field. (Pointer relative to keyboard.device base address). I'd say there is no need for opener-specific KBUnit structure. (Perhaps original keyboard.device only works properly when there is single opener?).

### reqtools.library

Original m68k reqtools.library gadgets also have some problems, all button gadgets are not visible but they do work when clicked (and they even become visible permanently after clicking them once)
Perhaps this is related: Deluxe Paint 2 and 3 (not tested others, 2 and 3 used for overlay tests) button gadgets have similar graphics glitches.
Button text/label becomes permanently invisible after it has been clicked once (or if gadget was originally drawn as active)
Its possible that fid->fid_EdgesOnly is 0.should 1 if it is drawn later,
I get in mind, frameiclass, is lots modify for AFA.I send you the file private, maybe you see difference.
Some time i have post the problems AFA have with AROS code. I think these 2 are also maybe possible. Have you check if this problems are not in AROS 68k?
I mean text in wb 3.9 about Req is correct show.
//RemoveClass(FindClass("itexticlass")); // text in WB 3.9 about is not written. //BOOPSI_ITextIClass_Startup_lib; ////// //RemoveClass(FindClass("frbuttonclass")); // gadget boxes are too large //BOOPSI_FrButtonClass_Startup_lib;
but in the last functions, not knowing what to fix, I deactivate them.
I am quite sure reqtools uses standard intuition gadgets (it was 1.3 compatible for a long time), not boopsi. reqtools 68k call this code, maybe you add some debug code to look also if fid->fid_EdgesOnly = 0 or 1. I disabled EdgesOnly test: no effect on hidden button gadgets.
I noticed RefreshBoolGadgetState is called when selection state changes and it looks ok at that point but something after this call clears the label text. Maybe you try out to skip draw_frameiclass(cl, im, msg, im->Width, im->Height) No effect either (on hidden buttons, gadgets started to look strange of course). I just noticed it is the backfill pattern that overwrites the gadget because gadtools demo part that shows non-backfill window works correctly.
its not use by many software, if then text is not overwritten, you can be sure something in frameiclass. It seems all Aros native programs use boopsi if no one has noticed this previously.

### wbversion

The installer script does not accept aros by the Version. A message instructs the use of Kick 3.1. So is it possible that AROS wbversion is compatible to AOS and show that AROS is at least kick 3.1 ?
fails here

#### Have the KS3.1

How is #wbversion set? What version of Scalos is this and where can it be downloaded from?
* wbversion is defined by looking at libs:version.library's version:
from scalos'installer script
I don't think there is a version.library in AROS. I guess this explains the failure.
It doesn't have any functions, does it? M68k software surely assumes it exists. It has no extra functions but can be expunged normally.
I found this with codesearch:
Looks like all we have to do is to set lib_Version to 40 for OS3.1.

### Zune

global.prefs is incompatible with m68k-amiga. It has little-endian data included that crash m68k-amiga TextEditor mui class. For example decimal 500 is read as F4010000 when TextEditor asks for MUIM_GetConfigItem / MUICFG_TextEditor_UndoSize. Class is fixed (that prevented it to initialize), prefs problem is different problem and only solution currently is to delete the prefs file. If it *is* supported to be cross-platform, all data should be big-endian (since Classic AmigaOS is our lowest common denominator, and Big Endian is easier to read by eye in a hex dump!)
I see a few of those where IPTR is reverted to ULONG (probably not good on x86_64?). Examine the #ifdef __AROS__ lines added above that code again.
I believe the SDI_hook.h and SDI_compiler.h changes are stable, and ready to backport. I would like to proposes that we have a top-level workbench/libs/SDI, that has the 'master' versions of the SDI headers for AROS, that are installed in :Development/Include/. Current packages that use SDI should then pick those up, instead of the (probably stale) versions in their local includes. Does not make much sense to me when there is already compiler/include (and technically it isn't a library so workbench/libs isn't the place for it). AROS should only have one version of SDI (hopefully the most current!) in its tree, not four or fix copies of different revisions.
On a different note, I can't figure out how to make the SDI varadic VA_* macros work for the AROS architectures that use non-uniform varadic arrays. (x86_64 specifically). Currently on AROS there are quote elaborate macros (and helper functions) for the following cases:
and

## Contribution

Package-Startup is executed from its parent directory. So it adds "system:extras/Zune/MCC_NList/Classes" to Libs:
This complicate part of Startup-Sequence reads all variables in env:sys/packages. The variables contain the path to s/Package-Startup.
Someone bored enough should help to fix m68k compilation problems in contrib :) what compiler error you get ? maybe you try to compile contrib with old compiler(best switch off optimizer in GCC to avoid broken programs)and old AROS 68k macro files in 68k.cpu.h
I notice that the macros Mason have do for GCC 4.5.0 do not work for compile AFA(with GCC 3.4.0 and GCC 4.5.0), only old AROS macro and GCC 3.4.0 work ok.
But in theory it should work when i change libcall.h and cpu.h.
macro errors get more visible, when you compile with Option -E, so only the preprocessor stuff is done and the asscii file is saved. Here is the mail sent to Jason that he did not answer:
this zune file or arossupport.c
when I use old libbcall.h all work. I have it attach(currently it is named libbcall.h_ because I used your file)
here is the full log output of amidevcpp.
-E option i use to get preprocessor error output. When I use not -E i get only a syntax error which is not precise. Oddly, AROS works.
on line 18 there is just a simple call of that.
return MUI_NewObjectA(classname, &tag1);
but it happen also on LHA macros. Currently only working compiler is latest + Jason's A6 gcc register patch. (and this surely has nothing to do with possible compiler problems)
btw, there is something wrong with either aros mui or libraries when also using native amigaos libraries. Scout crashes due to corrupt region pointer when calling DisposeRegion (or was it ClearRegion). (I was trying to use amigaos nlist because aros version does not compile) Region pointer points to some strange string data. Debugging memory overflows/corruption is boring..
I think here is problem that sdi includes does think its 68k and use 68k kompiler syntax. to see whats really wrong use compiler option -E and post preprocessor file, because sdi use so many nested macros.
If the output of -E in functionheader show something as this and have a asm command in, that's wrong for new compiler.
funcname(char *args __asm("a0") )
> /home/twilen/AROS/contrib/bgui/examples/FieldList.h:150:21: error: too > many arguments to function 'SetFLAttr'
this is different.maybe a wrong prototype of SetFLAttr.if not here you can too look when compiler Option -E is set in makefile, whats the full sourceline without macros in it.
> > btw, there is something wrong with either aros mui or libraries when > also using native amigaos libraries. Scout crashes due to corrupt > region pointer when calling DisposeRegion (or was it ClearRegion).
As far I remember, there is on AROS different lib slot usage of zune MUI API. I fix offsets for AFA, but don't know what is different. I send you the AFA muimaster.h defines privat, attachments here do not work.
Because all of the OOP stuff in amiga is due to black-box concept and much work need for add a feature, implementation is limited and many features are missing. That's also a problem on MOS MUI4.
On MUI and boopsi picture datatype developers that use that begin to hack and use undocumented features.
So I suggest that on AROS 68k same way is go as AFA do.the AROS MUI lib is name as zune.library. All AROS programs are compiled to use zune.library on 68k.
This allow you to get best compatibility by using MUI 68k and avoid that new features cant add in zune, it break some programs.
user can use as in AFA the zune promoter to tell a program that it should use zune.library instead of muimaster.library
Because AFA has been out so long, only around 70-80% of MUI 68k programs work perfectly on zune. It also does not like OO stuff, too hard to find problems, so I gave up, to make zune more compatible since many years.
for the bgui on AROS stuff I have currently no other idea, as the Problem come from AROS input device. I cannot test this on AFA.

### arosc library

The librom.a library now has the old-style 'no %f/%g' printf family, arosc.library has the floating point stuff. So, if you want %f, use 'linklibs="arosc"', and *not* linklibs="rom". It may be prudent to have the 'rom' version print out '???' or something if someone accidentally links with it and uses a '%f' format. Only Prefs for openurl.library needed %f.
FYI: it is not allowed to link modules (libraries, devices, etc) with arosc.library - this is because arosc.library stores the context in calling task.
So when the task dies, context dies, but the module had its memory allocated on that context. That's why modules need to be linked with librom.a (even if they are NOT it the ROM) and C lib functions missing in librom.a must be implemented directly in module (that's what I had to do with mesa.library for example).
"So, if you want %f, use 'linklibs="arosc"', and *not* linklibs="rom"" does not apply to them. :) PS. The macro for building modules explicitly disables linking with arosc.library - this is on purpose (that's why Kalamatee got linker errors)
What does RawDoFmt under AOS print? Wasn't it something like just the '%' stripped, i.e. 'f'?

### bgui library

All bgui.library gadgets are visible (some have small alignment bugs) but they can't be selected or activated with a mouse. Keyboard shortcuts work (if gadget has a keyboard shortcut set)
bgui.library demos and FileMaster 3 ("for some reason" this is one of my test cases...) has same BOOPSI problem.
They are in normal non-pressed state. Also it is not just button gadgets, all bgui gadget types can't be selected with a mouse.
Everything else works (more or less) except mouse selection. For example string gadget that is selected when window opens has cursor visible and even text editing works fine.
Pressing a key that is shortcut for button gadget works and gadget's text label disappears (which is wrong, it should show pressed state) Keeping shortcut key pressed while pressing ESC cancels the press event and text label re-appears.
So there is at least two different problems with bgui gadgets:
* mouse selection.
* button gadget (maybe others, can't really test until mouse selection works) pressed state is rendered incorrectly.
I activate many AROS functions and classes for test in AFA (that make problems with 68k code), but bgui addbuttons Testprogram (I use it only for tests) work ok.So seem no problem in one of this AROS function.
buttonclass gmhittest on AFA is same as on AROS and work with all.
I also revert some compatibility enhancement of AFA code.bgui still work. I test when i have time on AROS 68k.
what happen if they cant click, is there no press state show when you click in it ?
here you can see what problems are cause by some AROS functions in some programs. Normally I deactivate all these functions with known bugs.
so if you get such a problem it help maybe to find what function cause this.
this is stable working AROS code with no known compatibility Bugs

### prefs

WB3.1 Prefs/Palette apparently manually creates DrawInfo structure(s) causing crash in sysiclass_aros.c because it assumes valid dri_Screen.
Preferences program does not crash anymore when dri_version = DRI_VERSION + 1 is set in openscreen.c and only "new" drawinfo versions is allowed in sysiclass_aros.c.
Is this change ok or is it better to have some kind of "extended drawinfo" flag instead of changed version number? Unfortunately this will break backwards compatibility with old AROS programs. (I'll put this inside AROS_FLAVOUR_BINCOMPAT ifdef if there is no compatible solutions)
Prefs/palette stops crashing and works except color chooser circle is completely black, first all colors are drawn and when it is finished, it is overwritten with black color.
WB3.1 Prefs/Palette calls AreaCircle (or AreaEllipse) twice (this is used to draw the narrow black border around color wheel), both have same center coordinates, one has few pixels, a larger radius, and finally AreaEnd is called, which should only fill the narrow area border area. AROS version fills both circles, resulting in a completely black color wheel. (I am not going to touch this)
Apparently AreaEnd always uses blitter-like area fill.

### wb

AOS Workbench started programs also have NULL pr_CurrentDir.
For example very common SAS-C startup code (source comes with compiler) does following when started from WB:
Unfortunately at exit it does not restore pr_CurrentDir, it only Unlock's __curdir(a4). Which means there is no other way to handle this than to have NULL pr_CurrentDir. (Currently it causes double unlock which at least UAE fs ignores without crashes, not sure about others). I now have confirmed following Process variables when started from WB:

## Commodities

Debugging this and it is ScreenToFront("wb screen") that gets called by Wanderer (or something) after selecting Execute. It seems screendepth isn't checking (at least correctly) that requested screen is already in front. Call trace is: screendepth->RethinkDisplay->MrgCop