New Replacement Workbench 3.1 Disk Sets www.amigakit.com

[F0LLETT]

Of course, I knew Id forgotten something, .
Need to find some time to fix it.

Tis true though for alot of todays tech. Remember going out to loads of service calls, just to turn customers TV's off and on again.
SONY's were the worst, had to leave them off for 20 mins as the caps held their charge that long.

[mrmoonlight]

Yes my os 3.1 are on the way ,wonderful and on we go best wishes Brian
 
 Nice one Amigakit

[Kooler]

My point remains that some users would prefer an updated AmigaOS3.9 CD with all of the latest improvements already included...
 
 I would guess Hyperion would need to be involved, as I believe that they own the rights to AmigaOS3.9 (possibly excluding a few parts of it contributed by those same 3rd party developers)

 
 It doesn't look like Hyperion has sufficient rights to do this under the Settlement Agreement between Amiga and Hyperion. The copyright part is a bit vague, leaving it to paragraph (c) of the Grant (1.) section to explain the scope of the agreement, which is what Amiga users always knew it was about, namely developing AmigaOS 4 for the PowerPC:
 
 

Solely for the purposes of marketing, distributing and making available AmigaOS 4 and any hardware required or desired to operate with AmigaOS 4...

[Kooler]

Q: Wasn´t Cloanto´s workbench distribution license only valid for emulation purposes? If then, can this be considered an ilicit act?
 
 Could anyone shed some light on this?

 
 Did you see this from the Amiga Forever site:
 
 

 a "Classic Support" scenario was explicitly outlined in a Coexistence Agreement between Amiga, Inc. and Cloanto, for use also outside of emulated Amiga systems.
 

[kolla]

Is scsi.device also updated to support large drives?

[kolla]

Updated kickstarts would be great too. In general, an AmigaOS "3.2" with all essencial bits updated to what is in 3.9+boing bags, things like shell, various libs, handlers and devices - a 3.9 without all the fluff (Reaction etc) from 3.5 and 3.9. I have put together something like this already for my minimig.

[guest11527]

Despite legal constraints: There's also a serious size constraint here to place 3.9 (or parts thereof) in ROM. The workbench.library is considerably larger than the 3.1 version, and so is the Shell. One way or another, something has to go from ROM. Workbench is a candidate, audio is a candidate, mathieesingbas is a candidate (the latter for more than one reason). It remains a bit unclear which compatibility issues may arise from this, which is probably the reason why nobody wants to do it.

[olsen]

Despite legal constraints: There's also a serious size constraint here to place 3.9 (or parts thereof) in ROM. The workbench.library is considerably larger than the 3.1 version, and so is the Shell. One way or another, something has to go from ROM. Workbench is a candidate, audio is a candidate, mathieesingbas is a candidate (the latter for more than one reason). It remains a bit unclear which compatibility issues may arise from this, which is probably the reason why nobody wants to do it.

Actually, if one were to build a new ROM there could be sufficient free space to keep all components in it. I tested this with a fully native build that utilizes SAS/C for almost all components. That change allows for considerable space savings, e.g. the A4000T ROM has enough room for the SCSI/ATA scsi.device flavours and workbench.library to fit. Taken a step further, the disk-based icon.library that was part of AmigaOS 3.5/3.9 could fit, too. The same could be done for the A1200 V40 ROM which has almost no free space left.

However, this native build is pretty much untested. If one were to use its components, mix them with existing components, the results might be more mature and robust than in a fully native build.

[guest11527]

Actually, if one were to build a new ROM there could be sufficient free space to keep all components in it. I tested this with a fully native build that utilizes SAS/C for almost all components. That change allows for considerable space savings, e.g. the A4000T ROM has enough room for the SCSI/ATA scsi.device flavours and workbench.library to fit. Taken a step further, the disk-based icon.library that was part of AmigaOS 3.5/3.9 could fit, too. The same could be done for the A1200 V40 ROM which has almost no free space left.

However, this native build is pretty much untested. If one were to use its components, mix them with existing components, the results might be more mature and robust than in a fully native build.

Strange, so what's so incredibly huge in the 3.1 ROMs that CBM got so tight on ROM space? intuition alone? Ok, there *is* indeed some headroom left in the A2000 ROMs (and A500's of course), but as soon as the scsi controler or/and the on-board IDE had to go into ROM, CBM tried really to cram in the bytes.

[olsen]

Strange, so what's so incredibly huge in the 3.1 ROMs that CBM got so tight on ROM space? intuition alone? Ok, there *is* indeed some headroom left in the A2000 ROMs (and A500's of course), but as soon as the scsi controler or/and the on-board IDE had to go into ROM, CBM tried really to cram in the bytes.

As far as I recall the only two V40 ROMs which had little room to spare were those for the A1200 and A4000T models.

The A1200 ROM basically covers everything which the A500/A600/A2000 needs, which means PCMCIA hardware support. The big difference is in the graphics.library, which is significantly larger for the A1200 due to AA support, than the ECS version used in the A500/A600/A2000 ROM.

The A4000T ROM has even more crammed into it, which includes the ATA scsi.device, the really large A4091 scsi.device (which itself includes the bootstrap script for the NCR SCSI controller) and the large AA graphics.library. The combination of these components left no room for workbench.library, which was moved out to disk.

V40 was built almost exclusively using Lattice 'C' 5.04 which did not feature the more refined and effective optimization functionality available later in SAS/C. Commodore did not use SAS/C for production code, or for that matter, used 68020 code generation, because of code generation maturity issues. Because of this, all the compiled 'C' code was targeted for the plain 68000, and no 68020 specific optimizations could have helped to reduce the code size for the A1200/A3000/A4000/A4000T.

[matthey]

Actually, if one were to build a new ROM there could be sufficient free space to keep all components in it. I tested this with a fully native build that utilizes SAS/C for almost all components. That change allows for considerable space savings, e.g. the A4000T ROM has enough room for the SCSI/ATA scsi.device flavours and workbench.library to fit. Taken a step further, the disk-based icon.library that was part of AmigaOS 3.5/3.9 could fit, too. The same could be done for the A1200 V40 ROM which has almost no free space left.

Please leave the icon.library out of Kickstart. Everybody is using PeterK's icon.library because it's much faster, smaller and supports most Amiga icon types.

The A4000T ROM has even more crammed into it, which includes the ATA scsi.device, the really large A4091 scsi.device (which itself includes the bootstrap script for the NCR SCSI controller) and the large AA graphics.library. The combination of these components left no room for workbench.library, which was moved out to disk.

V40 was built almost exclusively using Lattice 'C' 5.04 which did not feature the more refined and effective optimization functionality available later in SAS/C. Commodore did not use SAS/C for production code, or for that matter, used 68020 code generation, because of code generation maturity issues. Because of this, all the compiled 'C' code was targeted for the plain 68000, and no 68020 specific optimizations could have helped to reduce the code size for the A1200/A3000/A4000/A4000T.

SAS/C "refined and effective optimizations"? You have to be kidding. The icon.library was compiled with SAS/C and PeterK's optimized version is now about 35% smaller with much added functionality (my record library reduction is 43% but that was an early version of GCC/EGCS which I could take to half size with some effort). I would say that SAS/C is better for size than speed. I have a working and well tested workbench.library which is 191168 bytes without any hand optimizations from me (it has bug fixes applied). I bet I could optimize away another 10kB or so with basic hand optimization (getting rid of that slow SAS/C copymem routine would probably save 500 bytes alone). Granted the code quality is nowhere near as bad as the intuiton.library. It might be worth trying vbcc for small executable sizes. Vbcc's features:

+ best 68k peephole optimizing assembler ever in vasm
+ uses optimized inlined assembler functions (the default)
+ sophisticated optimizations that exceed SAS/C (some don't seem to work)
+ cross-assembler for fast compiles on faster computers
+ good Amiga and 68k features and support (Amiga hunk output, IEEE math libraries for fp)
+ actively maintained by knowledgeable and helpful people who know the 68k and Amiga
+ source code available and compiles on a 68k Amiga with few dependencies
+ free for Amiga use
+ easy Amiga installation
+ good c99 support
? some of the link code is highly optimized (hit and miss)
- the 68k backend is average at best
- no 68k instruction scheduler
- lacking tools although many GCC and SAS/C tools are compatible (CPR debugger)
- slow at compiling
- memory hungry
- no C++ support

There should be a much improved version of vbcc out in the next few weeks. SAS/C is a dead end last decade compiler. How about giving the new version of vbcc a try?

[guest11527]

Please leave the icon.library out of Kickstart. Everybody is using PeterK's icon.library because it's much faster, smaller and supports most Amiga icon types.

Relax, nobody is going to release a new kickstart anyhow, exactly due to the legal problems it would cause.

SAS/C "refined and effective optimizations"? You have to be kidding.

Back then had a good optimizer, compared to the other compiler(s) that were available, Manx (Aztec) namely. Gcc had an even better optimizer, but no (or unsufficient) native support for the Amiga toolchain, so it was often not an option to use.

I really haven't tried vbcc, so I cannot judge, but a lot of the compiles here depend on some SAS/C magic, for example layers depends on SAS/C being able to use the library base as the "data segment" of the code, so "global variables" (that's not exactly a C term, I know) appear in the library base. I'm unclear whether vbcc can do that, but gcc couldn't back then.

So it's much more  a question of the overall tool chain than really some particular feature of the optimizer. SAS/C, even the latest version, has some bugs in its optimizer, too. Try to use mathieedoubbas mathematics and see it spill the lower 32 bits of the IEEE double floats from time to time... )-:

Anyhow, nothing's going to happen as far as the Kickstart is concerned, so it's all an academic discussion to begin with.

[matthey]

Back then had a good optimizer, compared to the other compiler(s) that were available, Manx (Aztec) namely. Gcc had an even better optimizer, but no (or unsufficient) native support for the Amiga toolchain, so it was often not an option to use.

That was what 20 years ago now?

I really haven't tried vbcc, so I cannot judge, but a lot of the compiles here depend on some SAS/C magic, for example layers depends on SAS/C being able to use the library base as the "data segment" of the code, so "global variables" (that's not exactly a C term, I know) appear in the library base. I'm unclear whether vbcc can do that, but gcc couldn't back then.

Vbcc uses the standard:

A7=stack pointer
A6=library base
A5=frame pointer (unused unless -use-framepointer)
A4=small data pointer (unused unless -sd)

Both A5 and A4 are free by default so there should be no conflicts. There is a function attribute called __saveds which loads A4 or a function called geta4() which can be placed at the start of a function using small data when not compiled for it. If A4 is used as the pointer to your library base, it may not take much to convert to compiling with vbcc. What SAS/C attributes and functions are used to setup and access the library base in this way?

Vbcc supports these attributes:
 __far, __near, __chip, __saveds, __interrupt, __amigainterrupt, __stdargs, __section

So it's much more  a question of the overall tool chain than really some particular feature of the optimizer. SAS/C, even the latest version, has some bugs in its optimizer, too. Try to use mathieedoubbas mathematics and see it spill the lower 32 bits of the IEEE double floats from time to time... )-:

Vbcc has bugs too but they are getting fixed .

[olsen]

Please leave the icon.library out of Kickstart. Everybody is using PeterK's icon.library because it's much faster, smaller and supports most Amiga icon types.

Well, I'm not using it So far I'm reasonably satisfied with the icon.library which I wrote for the OS 3.5 update. If there is a problem badly in need of a solution, it's in how workbench.library and icon.library interact for directory scanning and display. It just does not scale: larger icon files, more files, no matter what, the performance and responsiveness quickly goes down the drain.

SAS/C "refined and effective optimizations"? You have to be kidding.

Hey, I wrote "*more* refined and effective", and the reference was Lattice 'C' 5.04. SAS/C 6 was definitely an improvement considering the quality of the code optimization. However, it did take a couple of years to mature (1995-1996), by which time Commodore could no longer put it to good use.

I was told that Commodore was a driving force in getting SAS, Inc. to improve the code generator and the optimizer. They would submit samples of code as produced by the Green Hills compiler (obviously, they could not share compiler source code) and ask the compiler developers at SAS to replicate the results. Step by step the compiler improved.

The icon.library was compiled with SAS/C and PeterK's optimized version is now about 35% smaller with much added functionality (my record library reduction is 43% but that was an early version of GCC/EGCS which I could take to half size with some effort).

I can't comment on the size and functionality of the replacement icon.library, as I have never used it. I only spent a couple of months rewriting the icon.library from scratch, integrating NewIcons support, colour icon support, etc., making it work better with workbench.library, building new APIs, etc. The focus was not on optimizations for size or speed, because icon loading is pretty much restricted by what the file system can do (and that isn't much). My focus was more on making the whole thing as robust as I could, and on opening up the API.

I would say that SAS/C is better for size than speed. I have a working and well tested workbench.library which is 191168 bytes without any hand optimizations from me (it has bug fixes applied). I bet I could optimize away another 10kB or so with basic hand optimization (getting rid of that slow SAS/C copymem routine would probably save 500 bytes alone). Granted the code quality is nowhere near as bad as the intuiton.library. It might be worth trying vbcc for small executable sizes. Vbcc's features:

+ best 68k peephole optimizing assembler ever in vasm
+ uses optimized inlined assembler functions (the default)
+ sophisticated optimizations that exceed SAS/C (some don't seem to work)
+ cross-assembler for fast compiles on faster computers
+ good Amiga and 68k features and support (Amiga hunk output, IEEE math libraries for fp)
+ actively maintained by knowledgeable and helpful people who know the 68k and Amiga
+ source code available and compiles on a 68k Amiga with few dependencies
+ free for Amiga use
+ easy Amiga installation
+ good c99 support
? some of the link code is highly optimized (hit and miss)
- the 68k backend is average at best
- no 68k instruction scheduler
- lacking tools although many GCC and SAS/C tools are compatible (CPR debugger)
- slow at compiling
- memory hungry
- no C++ support

There should be a much improved version of vbcc out in the next few weeks. SAS/C is a dead end last decade compiler. How about giving the new version of vbcc a try?

Colour my curious. Where do I start?

The lack of an interactive source debugger is something of a dealbreaker, though. I'd hate to go back to where I was back in 1987. Life's too short for peppering your code with printf()s and assert()s, rerunning it, watching it crash, modifying it and rerunning it all over again. Now CodeProbe may not be much fun, but it's not that big a productivity sink as "old school" debugging is.

[guest11527]

That was what 20 years ago now?

Yes, certainly - that's what I'm describing.

Vbcc uses the standard:

Sorry, that's not exactly what the problem is. The trick that is used here is the following: If you have a file like this:

struct Library *GfxBase;

void LIBFUNC foo(struct RastPort *rp)
{
 SetAPen(rp,0);
}

then, with a properly defined LIBFUNC macro, SAS/C will place "GfxBase" as an object into the library you are creating (*not* the data segment), will create a library entry for "foo" and will use a6 to load a4 with the "near" data pointer, i.e. it will use the library base as "near" data. SAS/C can also create the fd file for your, or place the functions at specific offsets in the library.

As said, SAS/C provides a lot of system-specific "magic" to support AmigaOs development and a bit of the toolchain depends on this magic.

There are a couple of other "magical" support features it supports, so it does require some work to move from one compiler to another for system components. For user programs, this is much less an issue.
 
You don't even want to know how I compiled mathieesingtrans for 3.9 on SAS/C given that the compiler actually does not support single precision IEEE math...

[matthey]

Well, I'm not using it So far I'm reasonably satisfied with the icon.library which I wrote for the OS 3.5 update. If there is a problem badly in need of a solution, it's in how workbench.library and icon.library interact for directory scanning and display. It just does not scale: larger icon files, more files, no matter what, the performance and responsiveness quickly goes down the drain.

I can't comment on the size and functionality of the replacement icon.library, as I have never used it. I only spent a couple of months rewriting the icon.library from scratch, integrating NewIcons support, colour icon support, etc., making it work better with workbench.library, building new APIs, etc. The focus was not on optimizations for size or speed, because icon loading is pretty much restricted by what the file system can do (and that isn't much). My focus was more on making the whole thing as robust as I could, and on opening up the API.

I appreciate that you are proud of your own work, and I'm not saying it's bad, but PeterK's icon.library really is significantly faster and it supports PNG and AmigaOS 4 icons as well as everything it did before while shrinking over 1/3. There is good and then there is amazing .

Hey, I wrote "*more* refined and effective", and the reference was Lattice 'C' 5.04. SAS/C 6 was definitely an improvement considering the quality of the code optimization. However, it did take a couple of years to mature (1995-1996), by which time Commodore could no longer put it to good use.

The guys that did SAS/C were professional, fixing a lot of bugs and giving a lot of Amiga support. The basic code generation was ok but they did some weird stuff like branching into CMP.L #imm,Dn instructions for little if any advantage and they loved the double memory indirect addressing modes like ([d16,An],od.w) which was used more with later versions (IBrowse has 1968 uses). These didn't hurt the 68020 code as much as for 68040 and 68060 where instruction scheduling is sorely needed. There are way too many byte and word operations for the 68060 which is most optimal with longword operations also. The direct FPU generation is poor for the 6888x and worse for the 68040+. It should be possible to generate good quality code for the 68020-68060, excluding the 16 bit 68000.

I was told that Commodore was a driving force in getting SAS, Inc. to improve the code generator and the optimizer. They would submit samples of code as produced by the Green Hills compiler (obviously, they could not share compiler source code) and ask the compiler developers at SAS to replicate the results. Step by step the compiler improved.

Looking at other compilers code generation is a good start. It's hard to imagine that Green Hills compiler was once better after looking at the intuition.library disaster. The Green Hills compiler is still around and pretty well respected in the embedded market for it's optimizing capabilities. They still have a ColdFire backend but I couldn't tell whether they had dropped 68k support.

Colour my curious. Where do I start?

The lack of an interactive source debugger is something of a dealbreaker, though. I'd hate to go back to where I was back in 1987. Life's too short for peppering your code with printf()s and assert()s, rerunning it, watching it crash, modifying it and rerunning it all over again. Now CodeProbe may not be much fun, but it's not that big a productivity sink as "old school" debugging is.

Frank Wille's vbcc site is here:

http://sun.hasenbraten.de/vbcc/

Unfortunately, the version there is pretty old now. There should be a new version available anytime (surely before the end of the year) with a huge number of bug fixes and improvements. You can always e-mail Frank for the newest sources also.

The newest version of vbcc for the Amiga 68k target generates Amiga symbols and debug information (with -g) in the Amiga Hunk format executables that is compatible with CodeProbe and BDebug. CodeProbe is a good debugger but I prefer BDebug from the Barfly package.

http://aminet.net/dev/asm/BarflyDisk2_00.lha

BDebug is another great developer tool you should try if you have not.

Sorry, that's not exactly what the problem is. The trick that is used here is the following: If you have a file like this:

struct Library *GfxBase;

void LIBFUNC foo(struct RastPort *rp)
{
 SetAPen(rp,0);
}

then, with a properly defined LIBFUNC macro, SAS/C will place "GfxBase" as an object into the library you are creating (*not* the data segment), will create a library entry for "foo" and will use a6 to load a4 with the "near" data pointer, i.e. it will use the library base as "near" data. SAS/C can also create the fd file for your, or place the functions at specific offsets in the library.

Don't you mean the LIBFUNC macro causes the function to use A4 like a small data pointer to load A6 from GfxBase in the library base? What does the LIBFUNC macro look like?

As said, SAS/C provides a lot of system-specific "magic" to support AmigaOs development and a bit of the toolchain depends on this magic.

There are a couple of other "magical" support features it supports, so it does require some work to move from one compiler to another for system components. For user programs, this is much less an issue.

The C language did not specify much back then so every compiler had it's own customized features and pragmas. We have better C standards with C99 now that should be used where possible over custom compiler features. It's always a pain to convert the old stuff though. You should see the GCCisms that the AROS 68k build system uses and would need updated to compile with vbcc. It makes these problems look easy.