Aros/Platforms/68k support/Developer/Libraries

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) ).

* LIBBASESIZE:
   - Would have space for an additional BPTR for the library's SegList
   - Space for an additional N struct Library * slots after
     the end of LIBBASETYPE, where N is the number of auto-opened libraries.
   - These slots would hold the opened library handles for the
     auto-opened libraries. But I don't like this change but won't veto it. 
     It can always be reverted when proper support for global variables is 
     implemented in ROM linking and the ROM bootstrap code. 
     To me write-only media and write-able global variables sounds mutually
     exclusive. Well, actually *read*-only media and write-able global 
     variables sounds even more mutually exclusive ;-)
     Please outline how it would work for an EEPROM or alike. 
     EEPROM Very easy. In your linker script you declare .bss and .data sections 
     in RAM, whereas .rodata and .text are in ROM. At startup, the Kickstart copy 
     the .data section stored somewhere in ROM into proper location in RAM and 
     zeroes the .bss section. And at the same time we could replace the ROMtag 
     scanner with a list of modules that is generated at link time; for example 
     using the AROS symbolsets.  I thought "binary compatibility" goes both ways, 
     original rom modules work with Aros rom modules and vice versa.. 
     IMHO this is the worst solution. Chip RAM is too valuable for that. 
     Either modules are going to be proper fully rommable or _everything_ can be
     relocated to RAM by tiny relocator and expansion RAM configuration code in
     ROM. Anyway, both solutions are bad ideas for basic A500/A1200 modes which will
     kill my interest instantly.

* set_open_libraries():
  - Would take LIBBASE as a parameter
  - Would OpenLibary() to the post-LIBBASETYPE Library *slots

* set_close_libraries()
  - Would take LIBBASE as a parameter
  - Would CloseLibary() the post-LIBBASETYPE Library *slots

* An additional header would be '-include libname_libraries.h', that
  would be autogenerated, and have lines like:

  #define GM_SEGLIST_SLOT (BPTR(((APTR *)(((IPTR)LIBBASE)+LIBBASESIZE))[0])
  #define UtilityBase     ((APTR *)(((IPTR)LIBBASE)+LIBBASESIZE))[1]
  #define GfxBase         ((APTR *)(((IPTR)LIBBASE)+LIBBASESIZE))[2]

  I tried to get rid of these
  '#define libbase' hacks. This code assumes that LIBBASE is available 
  in all functions that call a function of an auto-opened library. 
  This assumption is false. If you see no other way out please only 
  implement when compiling the kobjs on m68k. I mean, genmodule could 
  supported two types of libraries (or just make a second genrommodule 
  for the sake of it). Whatever assumption is made, it would only apply 
  to code that is explicitly written/modified against that assumption...
...

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

const IPTR UtilityBase_offset = LIBBASESIZE+1*sizeof(APTR);

const IPTR GfxBase_offset = LIBBASESIZE+2*sizeof(APTR);

Code should then do

#include <proto/utility_rel.h>
#include <proto/gfx_rel.h>
in case of
#include <proto/utility.h>
#include <proto/gfx.h>

gfx_rel.h would #include <inline/gfx_rel.h>

and in inline/gfx_rel.h you would have the following:

static inline void RectFill(...)
{
    extern const IPTR GfxBase_offset;
    struct GfxBase *GfxBase = (struct GfxBase *)((char *)(GET_A6)+GfxBase_offset);
    AROS_LC5NR(void, RectFill, ...)
}

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

 struct DataTypesBase *DataTypesBase = hook->h_Data;

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:

d0 = FindResident("dos.library");
move.l d0,a0
move.l RT_INIT(a0),a0
jsr (a0)

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?)

olddir = CurrentDir(toclone);
cis = Open("", FMF_READ);
CurrentDir(olddir);

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:

old = SetConsoleTask(((struct FileHandle*)BADDR(toclone))->fh_Type);
cis = Open("*", MODE_OLDFILE);
SetConsoleTask(old);

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)

jsr        %a6@(76 * -6)    /* Exec/DoIO() */

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.

#define offset -76

#ifdef ...

jsr offset(a6)

#endif

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

    dos.library -----> packet wrapper ---\
                                          \
> aros dos handler
                                          /
    arosdos.library ---------------------/

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:

  #define FMF_MODE_OLDFILE   (FMF_AMIGADOS | FMF_WRITE | FMF_READ)
  #define FMF_MODE_READWRITE (FMF_MODE_OLDFILE | FMF_CREATE)
  #define FMF_MODE_NEWFILE   (FMF_MODE_READWRITE | FMF_LOCK | FMF_CLEAR)

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):

UBYTE _fib[sizeof(struct FileInfoBlock) + 3];
struct FileInfoBlock *fib = (APTR) (((IPTR) _fib + 3) & ~3);

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:

BCPL_Action 600 (0x77f6c, 0x1f007, 0x1f018, 0x1f033)
             D0  D1       D2       D3       D4

D0 = BCPL routine to call
D1..D4 arguments

[LoadSeg] Loading 'L:Shell-Seg'...
Try Function 00f93158
[ELF Loader] Not an ELF object
[InternalLoadSeg] FAILED loading 0001c8ee as an ELF object.
Try Function 00f92720
read_block(file=116974, buffer=00069e6a, size=4, func[0]=00059bb2)
  buf=00069e6a, subsize = 4 (of 4)
HUNK_HEADER:
    Hunk count: 1
    First hunk: 0
    Last hunk: 0
    Hunk 0 size: 0x001ba8 bytes in ANY memory
HUNK_CODE(0): Length: 0x001ba8 bytes in ANY memory
HUNK_END
[InternalLoadSeg] Succeeded loading 0001c8ee as an AOS object.
[LoadSeg] segs = 0001c905
pr_GlobVec = 0007c660
BCPL_Action 600 (0x77f6c, 0x1f007, 0x1f018, 0x1f033)
BCPL_Action 608 (0x0, 0x1f007, 0x1f018, 0x1f033)
BCPL_Action 696 (0x303782bc, 0x3ef0b3, 0x1f018, 0x1f033)
BCPL_Action 700 (0x11215381, 0xf, 0x1f018, 0x1f033)
BCPL_Action 700 (0x14, 0xd6847a03, 0x11215381, 0x1f033)
BCPL_Action 700 (0x48e72022, 0xffffffff, 0x11215381, 0x1f033)
BCPL_Action 712 (0x0, 0xffffffff, 0x11215381, 0x1f033)
BCPL_Action 700 (0x48, 0xffffffff, 0x11215381, 0x1f033)
BCPL_Action 700 (0xc, 0xd6847a03, 0x11215381, 0x1f033)
BCPL_Action 708 (0x0, 0xffffffff, 0x44854e04, 0xffffffff)
BCPL_Action 708 (0xe1898283, 0xffffffff, 0x44854e04, 0xffffffff)
BCPL_Action 708 (0x2, 0xffffffff, 0x44854e04, 0xffffffff)
BCPL_Action 708 (0x303782bd, 0xffffffff, 0x44854e04, 0xffffffff)
BCPL_Action 708 (0x0, 0xffffffff, 0x44854e04, 0xffffffff)
...

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.

+    ((BPTR*)BADDR(hunktab[last]))[0] = BNULL;

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:

[InternalLoadSeg] Succeeded loading 0000000040725b80 as an ELF object.
FixFonts Loading 20
        Hunk count: 1
allocmem 0000000040725bb0 24
        First hunk: 0
        Last hunk: 0
        Hunk 0 size: 0x001ff4 bytes in ANY memoryallocmem 000000004091d3b0 8192
@000000004091d3b4
HUNK_CODE(0): Length: 0x001ff4 bytes in ANY memory
HUNK_RELOC32:
        Hunk #0:
HUNK_END
freemem 0000000040725bb0 24
[InternalLoadSeg] Succeeded loading 0000000040728240 as an AOS object.
[KRN] KrnUnregisterModule(0x0x4091d3b4)
[KRN] Next segment pointer 0x0x4091d3b4
[KRN] Next segment pointer 0x0x754eff7000
[KRN] Trap signal 11, SysBase 0x406455b8, KernelBase 0x40646600
[KRN] Process 0x4072d590 (FixFonts)
    RSP=000000004094cf30  RBP=000000004094cf50  RIP=00000000404aac0c
    RAX=000000754eff7000  RBX=00000000405202a8  RCX=00007f0e99a91770 RDX=0000000000000000
    RDI=00007f0e99d36860  RSI=0000000000000000  RFLAGS=0000000000010246
    R8 =00007f0e9a140700  R9 =00000000404dc320  R10=0000000000000000 R11=0000000000000246
    R12=000000004071f9f0  R13=000000004071f910  R14=000000004072d6f8 R15=0000000000000000

Many AROS programs have this:

AROS_UFH3(__startup static ULONG, _start,
      AROS_UFHA(char *, argstr, A0),
      AROS_UFHA(ULONG, argsize, D0),
      AROS_UFHA(struct ExecBase *, sysbase, A6))
{
<stuff>
}

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..

Lets say we have following lores sprite image (standard mode in AOS)

00X00000
00XX0000
00XXX000
00XXXX00

It has hotspot offset of (2,0)

Now lets see how it looks on hires screen at (0,0)

(without hotspot offset, wrong positioning)
S000XX0000000000
0000XXXX00000000
0000XXXXXX000000
0000XXXXXXXX0000

(with 2,0 _hires_ pixel hotspot offset, still wrong positioning. This is what happened previously)

00S0XX0000000000
0000XXXX00000000
0000XXXXXX000000
0000XXXXXXXX0000

(with 2,0 _lores_ pixel hotspot offset, or 4 pixel hires, finally we have correct hotspot positioning)
0000SX0000000000
0000XXXX00000000
0000XXXXXX000000
0000XXXXXXXX0000

(S = hotspot)

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.

#define RATIO_FIXEDPART  4
#define RATIO_UNITY      (1 << RATIO_FIXEDPART)

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

#define C_1084_HEIGHT    198 /* mm */
#define C_1084_WIDTH    264 /* mm */

if (GetMonitorEDIDSize(..,&MonitorEDIDWidthMM, &MonitorEDIDHeightMM)) {
  ms->ratiow = ((MonitorEDIDWidthMM)<<RATIO_FIXEDPART)/264;
  ms->ratioh = ((MonitorEDIDHeightMM)<<RATIO_FIXEDPART)/198;
} else {
  ms->ratiow = RATIO_UNITY;
  ms->ratioh = RATIO_UNITY;
}

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.x = 44*320/screen_pixel_width
res.y = 44*256/screen_pixel_height

(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:

#define C_1084_WIDTH_FIN  0xa6  /* 10.4 " * 16 in hex */
#define C_1084_HEIGHT_FIN 0x7c  /*  7.8 " * 16 in hex */

DPI.x = (screen_pixel_width << (RATIO_FIXEDPART * 2)) / (ms->ratioh * C_1084_WIDTH_FIN);
DPI.y = (screen_pixel_height << (RATIO_FIXEDPART * 2)) / (ms->ratiov * C_1084_HEIGHT_FIN);

.. 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:

  res.x = (1280 * 11 * ratioh / pixel_width)  >> RATIO_FIXEDPART
  res.y = (1024 * 11 * ratiov / pixel_height) >> RATIO_FIXEDPART

Screen DPI can be directly calculated from DrawInfo Resolution as:

#define C_1084_WIDTH_CIN  104  /* 10.4 " in centi-inches */
#define C_1084_HEIGHT_CIN  78  /*  7.8 " in centi-inches */

  dpi.x = (11 * 1280 * 10) / C_1084_WIDTH_FIN  / res.x
  dpi.y = (11 * 1024 * 10) / C_1084_HEIGHT_FIN / res.y

Screen DPC (dots per centimeter) is calculated as:

#define C_1084_WIDTH_MM  264  /* 10.4 " in mm */
#define C_1084_HEIGHT_MM  198  /*  7.8 " in mm */

  dpc.x = 11 * 1280 * 10 / C_1084_WIDTH_MM  / res.x
  dpc.y = 11 * 1024 * 10 / C_1084_HEIGHT_MM / res.y

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:

"/* Aspect ratios: The proper fraction xAspect/yAspect represents the pixel
* aspect ratio pixel_width/pixel_height.
*
* For the 4 Amiga display modes:
*  320 x 200: 10/11  (these pixels are taller than they are wide)
*  320 x 400: 20/11
*  640 x 200:  5/11
*  640 x 400: 10/11          */
#define x320x200Aspect 10L
#define y320x200Aspect 11L
#define x320x400Aspect 20L
#define y320x400Aspect 11L
#define x640x200Aspect  5L
#define y640x200Aspect 11L
#define x640x400Aspect 10L
#define y640x400Aspect 11L"

http://www.steguy.bravehost.com/Amiga_Files/V39_Support_Issues.txt

"-------------------------- getaspect -------------------------------

    bmhd->xAspect = 0;  /* So we can tell when we've got it */
    if(GfxBase->lib_Version >=36)
        {
        if(GetDisplayInfoData(NULL, (UBYTE *)&DI,
                sizeof(struct DisplayInfo), DTAG_DISP, modeid))
                {
                bmhd->xAspect =  DI.Resolution.x;
                bmhd->yAspect =  DI.Resolution.y;
                }
        }

    /* If running under 1.3 or GetDisplayInfoData failed, use old method
    * of guessing aspect ratio
    */
    if(! bmhd->xAspect)
        {
        bmhd->xAspect =  44;
        bmhd->yAspect =
                ((struct GfxBase *)GfxBase)->DisplayFlags & PAL ? 44 : 52;
        if(modeid & HIRES)      bmhd->xAspect = bmhd->xAspect >> 1;
        if(modeid & LACE)      bmhd->yAspect = bmhd->yAspect >> 1;
        }"

and here's another interesting remark:

http://vlists.pepperfish.net/pipermail/netsurf-commits-netsurf-browser.org/2011-July/010011.html

"/* AmigaOS sees 4:3 modes as square in the DisplayInfo database,
* so we correct 16:10 modes to square for widescreen displays. */
xres = (xres * 16) / 4;
yres = (yres * 10) / 3;"

(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:

[DOS] DosInit: InitCode(RTF_AFTERDOS)
[DOSBoot] __dosboot_BootProcess: Booting from device 'EMU:'
    Hunk count: 1
    First hunk: 0
    Last hunk: 0
    Hunk 0 size: 0x0010d8 bytes in ANY memory @011d5064
HUNK_CODE(0): Length: 0x0010d8 bytes in ANY memory
HUNK_RELOC32:
    Hunk #0:
HUNK_END
[KRN] Trap signal 11, SysBase 0xf522dc, KernelBase 0xf52f38
[KRN] Process 0x1025508 (FixFonts)
     SP=011f0d30  FP=011f0d48  PC=b762e84e
     R0=4eff7000  R1=00000000  R2=b7631b6c  R3=00f531a4
     R4=011f0dd7  R5=011f0dd7

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:

#define USE_TEXTEDITOR 1

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:

20-901 [513 226x165]: [WBLIB] OpenWorkbenchObjectA: name =
Wanderer:Tools/ExecuteStartup
20-905 [513 041x231]: [WBLIB] OpenWorkbenchObjectA: isDefaultIcon = 1
20-908 [513 060x281]: [WBLIB] OpenWorkbenchObjectA: it's a TOOL
20-912 [514 037x012]: [WBLIB] OpenWorkbenchObjectA: it's a CLI program
20-914 [514 008x061]: [Open] FH=1032b898 Process: 0x10100c08

"WANDERER:Wanderer", Window: 0x00000000, Name: "CON:////Output Window/CLOSE/AUTO/WAIT", Mode: 1005

Icon added:

10-571 [510 226x248]: [WBLIB] OpenWorkbenchObjectA: name =
Wanderer:Tools/ExecuteStartup
10-576 [511 040x007]: [WBLIB] OpenWorkbenchObjectA: isDefaultIcon = 0
10-579 [511 220x055]: [WBLIB] OpenWorkbenchObjectA: it's a TOOL
10-581 [511 226x103]: [WBLIB] OpenWorkbenchObjectA: it's a WB program
10-585 [511 226x159]: [WBLIB] OpenWorkbenchObjectA: stack size: 32768
Bytes, priority 0
10-590 [511 226x231]: [WBLIB]  WB_LaunchProgram: Success

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:

AlohaWorkbench(WBPort)

WBPort - a pointer to an initialized MsgPort structure in which the special communications are to take place.

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.

/home/twilen/aros/arch/m68k-all/mathieeedoubbas/./mathieeedoubbas_init.c:11:10: error: #include expects "FILENAME" or <FILENAME>. This definition is handled by the %build_module macro but not by the %build_archspecific macro. It will need to be implemented in config/make.tmpl if needed.

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

Inc.

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:

   64-bit divide
   64-bit multiply
   movep
   cmp2
   chk2
   cas (w/ a misaligned effective address)
   cas2

</snip>

lowlevel.library

trunk/AROS/rom/devs/keyboard/keyboard.c
trunk/AROS/rom/devs/keyboard/keyboard_intern.h

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.

IPTR FrameIClass__IM_DRAW(Class *cl, struct Image *im, struct impDraw *msg)
{
    DEBUG_IFRAME(dprintf("dispatch_frameiclass: draw Width %ld Height %ld\n",im->Width,
im->Height));
    //kprintf("%ld %ld\n",im->Width,im->Height);
    return draw_frameiclass(cl, im, msg, im->Width, im->Height);
}

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

(if (< #wbversion 40)
(   (exit #msg-badkick (quiet))
    ))

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

(set #wbversion (/ (getversion "Libs:version.library") 65536))

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:

const char *amigaGetOSVersion(void)
{
   static const char *osver[] = { "2.0","2.0x","2.1","3.0","3.1","3.2","3.3","3.4","3.5","3.9","3.9","3.9","3.9","3.9","4.0pre","4.0pre","4.0" };
   int ver = SysBase->LibNode.lib_Version;
   #ifndef __amigaos4__
   if (ver >= 40 && ver < 50) {   // Detect OS 3.5/3.9
      struct Library *VersionBase;
      if ((VersionBase = OpenLibrary("version.library",0))) {
         ver = VersionBase->lib_Version;
         CloseLibrary(VersionBase);
      }
   }
   #endif
   #ifdef __POWERUP__
   if (FindResident("MorphOS") && ver > 45) ver = 45;
   #endif
   if (ver < 36) ver = 36;
   else if (ver > 51) ver = 51;
   return osver[ver-36];
}

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:

IPTR func(LONG dummy, Tag tag1, ...)
{
   AROS_SLOWSTACKTAGS_PRE(tag1)
   retval = funcA(dummy, AROS_SLOWSTACKTAGS_ARG(tag1));
   AROS_SLOWSTACKTAGS_POST
}

and

IPTR  func(Class *cl, Object *obj, ULONG MethodID, ...)
{
  AROS_SLOWSTACKMETHODS_PRE(MethodID)
  retval = funcA(cl, obj, AROS_SLOWSTACKMETHODS_ARG(MethodID))
  
  AROS_SLOWSTACKMETHODS_POST
}

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.

If EXISTS ENV:SYS/Packages
    List ENV:SYS/Packages NOHEAD FILES TO T:P LFORMAT="If EXISTS
${SYS/Packages/%N}*NCD ${SYS/Packages/%N}*NIf EXISTS
S/Package-Startup*NExecute S/Package-Startup*NEndif*NEndif*N"
    Execute T:P
    Delete T:P QUIET
    CD SYS:
EndIf

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^{[check spelling]} 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.

Compiler: m68k-AmigaOS
Building Makefile: "E:\amiga\AmiDevCpp\usr\local\amiga\Makefile.win"
Executing  make...
mingw32-make.exe -f "E:\amiga\AmiDevCpp\usr\local\amiga\Makefile.win" all
m68k-amigaos-gcc-3.4.0 -c afa_os/arossupport.c -o aros/WORKBE~1/libs/MUIMAS~4/arossupport.o
-I"E:/amiga/AmiDevCpp/usr/local/amiga/m68k-amigaos/sys-include"
-I"E:/amiga/AmiDevCpp/usr/local/amiga/m68k-amigaos/include" -I"afa_os/include" -I"arosinclude"
-I"Aros/workbench/libs/muimaster" -I"Aros/workbench/libs/muimaster/classes"
-I"Aros/workbench/classes/zune/aboutwindow"  -m68020 -m68881 -D__AROS__ -fno-strict-aliasing -E -w -O2
afa_os/arossupport.c:18:43: macro "__AROS_LCA" requires 3 arguments, but only 1 given
afa_os/arossupport.c:18:43: macro "__AROS_LCA" requires 3 arguments, but only 1 given
afa_os/arossupport.c:23:42: macro "__AROS_LCA" requires 3 arguments, but only 1 given
afa_os/arossupport.c:23:42: macro "__AROS_LCA" requires 3 arguments, but only 1 given
afa_os/arossupport.c:172:21: macro "__AROS_LCA" requires 3 arguments, but only 1 given
afa_os/arossupport.c:180:44: macro "__AROS_LCA" requires 3 arguments, but only 1 given
afa_os/arossupport.c:180:44: macro "__AROS_LCA" requires 3 arguments, but only 1 given
.....
"""""

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.

TASK [arosc.library context]
|
|
\ /
module
|
|
\ /
arosc.library

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

              RemoveClass(FindClass("gadgetclass"));
              BOOPSI_GadgetClass_Startup_lib();
              RemoveClass(FindClass("sysiclass"));
              BOOPSI_SysIClass_Startup_lib();
              BOOPSI_TbiClass_Startup_lib();
              RemoveClass(FindClass("buttongclass"));
              BOOPSI_ButtonGClass_Startup_lib();
              RemoveClass(FindClass("imageclass"));
              BOOPSI_ImageClass_Startup_lib();

SETFUNC(DoGadgetMethodA,Intuition,IntuitionBase); // // editpad scrollbar after load full size
SETFUNC(RefreshGadgets,Intuition,IntuitionBase);
if (replacevisualprefs)
{
SETFUNC(AddGadget,Intuition,IntuitionBase);
SETFUNC(AddGList,Intuition,IntuitionBase);
}
SETFUNC(RemoveClass,Intuition,IntuitionBase);
SETFUNC(NextObject,Intuition,IntuitionBase);
SETFUNC(DisposeObject,Intuition,IntuitionBase);
SETFUNC(AddClass,Intuition,IntuitionBase);
SETFUNC(FreeClass,Intuition,IntuitionBase);
SETFUNC(MakeClass,Intuition,IntuitionBase);
SETFUNC(NewObjectA,Intuition,IntuitionBase);
SETFUNC(MakeClass,Intuition,IntuitionBase);
SETFUNC(SetGadgetAttrsA,Intuition,IntuitionBase);
SETFUNC(ObtainGIRPort,Intuition,IntuitionBase); // text is draw only on top of screen
SETFUNC(ReleaseGIRPort,Intuition,IntuitionBase);
SETFUNC(DrawImage,Intuition,IntuitionBase); //redraw errors on old icons on workbench
SETFUNC(DrawImageState,Intuition,IntuitionBase); //redraw errors on old icons on workbench
SETFUNC(ModifyIDCMP,Intuition,IntuitionBase);  //immediate redraw when scroll not work(MUI)

RemoveClass(FindClass("icclass"));  //kingcon scrollbar redraw not immediate.
BOOPSI_ICClass_Startup_lib();
RemoveClass(FindClass("rootclass"));
InitRootClass_lib();
RemoveClass(FindClass("groupgclass"));
BOOPSI_GroupGClass_Startup_lib();
RemoveClass(FindClass("modelclass"));
BOOPSI_ModelClass_Startup_lib();
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();
//
RemoveClass(FindClass("fillrectclass"));
BOOPSI_FillRectClass_Startup_lib();

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:

a0 = WB startup message
move.l     wa_Lock(a0),d1
callsys    DupLock
move.l     d0,__curdir(A4)
move.l     d0,d1
callsys    CurrentDir

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:

pr_CurrentDir = NULL
pr_HomeDir = set
pr_CIS = NULL
pr_COS = NULL
pr_ConsoleTask = NULL
pr_FileSystemTask = set

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()