Hyperion: "Halloween special double-treat for the Classic AmigaOS"

[Heiroglyph]

Since assembly based modules are not really going to get smaller, what about shrinking more of the C based modules by using the new compiler?

The new layers.library for example was a backport from OS4 changes if I'm not mistaken, so would probably be C.

I would assume that there would be a few like that.

[olsen]

@ olsen

Wow, thanks for that answer. I had no idea it was that complicated.

Others may have a different point of view on the subject of rewriting scsi.device and the FFS. My personal opinion of assembly language at this scale and at this level of complexity is that I would rather write this in 'C', if possible. Alas, this is not an option here.

I suppose v43 would still be too large even with some of the compiler trickery you used on other components of this release?

I honestly have not checked this yet, but there there is room for experimentation: the boot menu (which appears when you hold down both mouse buttons during the system startup), the con-handler (which implements the CON: device), gadtools.library, icon.library, layers.library, ram-handler (which, as the name says, implements the RAM: device) and the ROM shell are written almost entirely in 'C' and would most certainly shrink when rebuilt using SAS/C.

There is something of a catch, though. Commodore chose not to use SAS/C 6 back in 1993/1994 because it was felt that the code generation was not yet sufficiently mature for ROM code. While SAS/C kept maturing after Commodore had collapsed, it was never used on a larger scale for a production ROM build. The 'C' language portion of the A4000T (and A4091) scsi.device was built using SAS/C 6, but it was the exception.

I am not that knowledgeable about the quality of the code generated, and the bugs that might still be present in it. This means that additional testing would be required before more ROM components could be rebuilt with SAS/C 6.59, falling back onto the original SAS/C 5.04 compiler where needed.

[edit] Actually, now that I think about it, and if I'm remembering correctly, didn't the different version numbers of the original 3.1 (40.63/68/70) have to do with bugs/problems with scsi.device depending on platform? Now I see why! [/edit]

The A3000 build of scsi.device did cause problems in Kickstart 40.70 for some SCSI devices, if I remember correctly. This is why (and which is where I learned about it) Village Tronic went back to the Kickstart 40.68 ROM for the A3000 and A3000T.

What exactly did not work properly was very difficult to tell, because the code change history of scsi.device between versions 40.63 and 40.70 is incomplete. These were among the last changes made to the operation system before Commodore eventually shut down in April 1994. Heinz Wrobel told me that these issues had been successfully resolved in scsi.device V43, which he had prepared.

[NorthWay]

One does note the lack of any 68060 handling.
Notwithstanding a library(s) at SetPatch time, that would be (at my count/understanding) 11 instructions more.

Kudos for making more options available.
Funnily enough I think what frustrates "hobby-hackers" like myself is that the OS is simple and clear enough to understand so that we feel like we could contribute to the improvement of it, but there is no-one to talk to about it and there isn't anything being produced anyway. (Though from time to time you see the odd the odd "vigilante" slogging through the battle alone and produce something.)

[kolla]

@Olsen
Thank you for describing so elaborate how the closed source model doesn't work

[wawrzon]

@olsen
Aros has a corresponding device weitten in c. I think its called ata.device. However there is some finetuning actually causing problems. Like it isnt working dependably with the internal a4k ide. You might take look if you need (i guess not) the sources are open, no nda..

[Iggy]

@Olsen
Thank you for describing so elaborate how the closed source model doesn't work

 And yet the two most popular NG OS' are closed source, while AROS is a distant third.
 And Windows and OSX dominate the desktop market while Linux systems are a single digit percentage of the market (and that estimate is being kind).
 
 Its simple economics, professional programmers need to earn a living, there is no profit in open software to generate an income to pay the programmers.
 Open software is free, but you get what you pay for.
 
 Which explains why when I recently needed to uses a spreadsheet, even though I already had Open Office on my system, I paid for an Office365 license so I could have access to Excel.
 It's just a better program than its equivalent in OO.

[utri007]

Bought both 17,91 euros that is bargain.

A600 and A1200 can use 1mb rom without any modification.

[olsen]

@Olsen
Thank you for describing so elaborate how the closed source model doesn't work

Could be... but it's hard to tell which contributes more to the somewhat disfunctional state of the art: the lack of development process, the lack of contributors, the use of a very old toolchain, the use 68000 language in complex subsystems, the need to remain backwards compatible with any changes made, the lack of documentation for ancient hardware, the age of the target platform itself.

Fix any two of these issues and you might just find that the others remain as stubbornly intractable as before

[wawrzon]

Could be... but it's hard to tell which contributes more to the somewhat disfunctional state of the art: the lack of development process, the lack of contributors, the use of a very old toolchain, the use 68000 language in complex subsystems, the need to remain backwards compatible with any changes made, the lack of documentation for ancient hardware, the age of the target platform itself.

Fix any two of these issues and you might just find that the others remain as stubbornly intractable as before

Could all be solved i guess, but it would involve opening the sources, collaboration with the community and perhaps involving some aros solutions like up to date compilers and unified build system. i suspect some years ago you could have some valuable contributors like that. The problem is the uncertaim legal situation of software in question. And of course the will of some parties to be rewarded upon just everything like sole posession of licenses, copyright notices and some minor fixes. This attitude and any notable development is imho mutually exclusive. Wehave to be aware of this.

[guest11527]

solutions like up to date compilers and unified build system.  

You might be astonished how much AmigaOs depends on the nature of the compilers and assemblers. It is a very non-trivial task to port this to any different compiler. For example, many parts of the sources compile with the SAS/C, but some shabby areas (especially graphics) require the even older lattice compiler because nobody dared to touch the sources and fix them up.   The build process is really very delicate.  On the good part, you no longer depend on ancient hardware. The whole build process works now fully automatic on the Unix command line, using the ancient compiler tools.

[Iggy]

You want a REAL challenge?
 Take the OS apart a rebuild it using assembly code scrapping the C components and reduce its overall size while improving its performance.
 Before anyone says it can't or shouldn't be done, let me explain my logic.
 In the '80's and '90s I was using Microware's OS-9 operating system for 68K based commercial and industrial applications.
 Microware was promoting CDi and porting its OS to other platforms using C (the 68K version of OS-9 being written virtually entirely with assembly code).
 They called this variant OS9000, and as their products evolved, they tried to simplify the naming of all OS' to OS-9 and use the C based code for all versions including the 68K fork.
 In the long run, the customers asked for the original version to continue to be developed because it was faster, more efficient and more compact.
 
 No matter what anyone tells you about C, tighter code can be generated by more direct means.
 It just takes a lot more work and it isn't portable.
 
 You want retro?
 Go full retro, and re-write 3.1 to be tighter, faster and more efficient.
 THEN you'll also have the room needed for the improvements you've been discussing.
 
 The only reason this probably can't be done?
 Lack of programmer competency.

[guest11527]

You want a REAL challenge?

No, I want a solution. That requires being pragmatic.

[wawrzon]

You might be astonished how much AmigaOs depends on the nature of the compilers and assemblers. It is a very non-trivial task to port this to any different compiler. For example, many parts of the sources compile with the SAS/C, but some shabby areas (especially graphics) require the even older lattice compiler because nobody dared to touch the sources and fix them up.   The build process is really very delicate.  On the good part, you no longer depend on ancient hardware. The whole build process works now fully automatic on the Unix command line, using the ancient compiler tools.

thomas, look, idont want to show off, but last week i have made the source of fryingpan compile for 68k target with gcc 6.1.0 with paranoia setting from within aros source tree. i have only received one hint from toni what concerns asm syntax. and while the work isnt finished, i need to debug some issues (luckily aros has gdb, so at least i get some hints as to where to look), i must insist that im a complete ignorant what concerns programming in whichever aspect. so, if a noob can do that kind of work, just because he wants to contribute, a professional with years of experience may well fix something more complicated.

[Iggy]

No, I want a solution. That requires being pragmatic.

It IS a real solution, you just don't have programmers with enough talent enough to pull it off.
 Then again, I'm not sure there is anyone that can still code at this level.
 
 BUT, the ONLY realistic way you are going to shrink the existing code IS to replace the C coded portions of the OS.

[wawrzon]

omg.. there it goes again.

[Pgovotsos]

The only reason this probably can't be done?
 Lack of programmer competency.

You do realize that when you insult the few people interested in doing anything in this space, the less likely they will retain their interest? We already have extremely competent people sacrificing what free time they have - you know after their real jobs that pay their bills, family, education and everything else. The only compensation they get is our thanks. When people stop appreciating what they are able to give us, what reason is there for them to continue? Would you work for free for some ungrateful person who does nothing but insult you, contributes nothing themselves, but continues to demand you do more and to do that more to their personal specifications regardless of the obstacles?

You ungrateful person. Assuming that you are a productive member of society and not the typical, modern, "gimme dat" American (judging from your attitudes and behavior probably not a good assumption), why don't you get off your lazy butt and actually contribute something yourself? Or are you one of "those who can't, criticize those who can"?

Why don't you try to find a few minutes in a busy day to find sources, decipher undocumented code, code that has multiple dependencies on other seemingly unrelated undocumented code, work with hardware that is insufficiently documented itself, try to figure out why someone 30 years ago chose to put THAT command THERE - a place it doesn't make sense for it to be but it is because of some quirk of the hardware or other modules of the software - someone who might be dead and can't explain the reason, and then rewrite it, still trying to maintain it within the extremely limited resources of the hardware. Do you have any concept of how MUCH needs to be in Kickstart and in only 512K? If you think this simplified description of what olsen, Thomas and others have to deal with is overstating the situation, read the experience of the people who rewrote the console.

These people are doing this out of love for the platform and the community. If the community, with people like you, stops appreciating them, goes out of their way to insult them, I would completely understand why they would stop spending their precious time and expertise and go elsewhere. Heck, with ungrateful, rude, crass, offensive jerks like you contributing nothing but bile, I'd go so far as to ENCOURAGE them to leave and let you to fester in your own crap.

Grow up. Act like an adult or go away. Nobody needs or wants your tantrums.