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

[wawrzon]

I'm all about supporting 68k development, so I'm buying them.

I would like more details on what is in here though. IDE and SCSI changes especially. FFS version would be nice to know too.

Did the layers.library update make it in?

you do have changelog right there. not much to read. think twice whom actually to reward for a honest support all these years.

[wawrzon]

This is in a text file included with the ROMs. This is from the a500/600, etc version.


Building kickstart 40.72 from BuildList : 22-Feb-16  18:20:18

            exec 40.12   @ $F80000-$F8383C Size:  14396  (22.2.2016)
       expansion 40.2    @ $F8383C-$F842AC Size:   2672  (9.3.93)
 mathieeesingbas 40.4    @ $F842AC-$F85384 Size:   4312  (16.3.93)
        graphics 40.24   @ $F85384-$F9E410 Size: 102540  (18.5.93)
             dos 40.3    @ $F9E410-$FA801C Size:  39948  (1.4.93)
              fs 40.1    @ $FA801C-$FADFBC Size:  24480  (15.2.93)
         console 40.2    @ $FADFBC-$FB1C40 Size:  15492  (5.3.93)
          layers 40.1    @ $FB1C40-$FB4DF4 Size:  12724  (15.2.93)
            a600 40.21   @ $FB4DF4-$FB7850 Size:  10844  (19.4.1998)
     con-handler 40.2    @ $FB7850-$FBA014 Size:  10180  (12.5.93)
        bootmenu 40.5    @ $FBA014-$FBB624 Size:   5648  (17.3.93)
           audio 37.10   @ $FBB624-$FBC6C4 Size:   4256  (26.4.91)
         cardres 40.4    @ $FBC6C4-$FBD2A8 Size:   3044  (4.5.93)
         utility 40.1    @ $FBD2A8-$FBDDA0 Size:   2808  (10.2.93)
       battclock 39.3    @ $FBDDA0-$FBE70C Size:   2412  (20.4.92)
        carddisk 40.1    @ $FBE70C-$FBF03C Size:   2352  (12.2.93)
        ramdrive 39.35   @ $FBF03C-$FBF630 Size:   1524  (21.5.92)
         mathffp 40.1    @ $FBF630-$FBFACC Size:   1180  (16.3.93)
             cia 39.1    @ $FBFACC-$FBFEBC Size:   1008  (10.3.92)
         battmem 39.2    @ $FBFEBC-$FC00A0 Size:    484  (6.3.92)
           potgo 37.4    @ $FC00A0-$FC01D8 Size:    312  (28.1.91)
      filesysres 40.1    @ $FC01D8-$FC0378 Size:    416  (15.2.93)
            misc 37.1    @ $FC0378-$FC0428 Size:    176  (8.1.91)
            disk 37.2    @ $FC0428-$FC0770 Size:    840  (21.4.91)
          ramlib 40.2    @ $FC0770-$FC0B94 Size:   1060  (5.3.93)
          keymap 40.4    @ $FC0B94-$FC1814 Size:   3200  (12.3.93)
           timer 39.4    @ $FC1814-$FC2600 Size:   3564  (29.7.92)
           strap 40.3    @ $FC2600-$FC362C Size:   4140  (13.2.2016)
        rawinput 40.1    @ $FC362C-$FC4C60 Size:   5684  (8.3.93)
       trackdisk 40.1    @ $FC4C60-$FC6968 Size:   7432  (12.3.93)
            icon 40.1    @ $FC6968-$FC8D98 Size:   9264  (15.2.93)
             ram 39.4    @ $FC8D98-$FCB210 Size:   9336  (9.8.92)
           shell 40.2    @ $FCB210-$FCF6F0 Size:  17632  (4.3.93)
       intuition 40.85   @ $FCF6F0-$FE9090 Size: 104864  (5.5.93)
        gadtools 40.4    @ $FE9090-$FEEC24 Size:  23444  (24.5.93)
              wb 40.6    @ $FEEC24-$FFFBF8 Size:  69588  (22.2.2016)
           wbtag 39.1    @ $FFFBF8-$FFFCBC Size:    196  (20.4.92)

Build of kickstart 40.72 completed at : 22-Feb-16  18:20:18

lol..

[wawrzon]

Could you elaborate on any future plans for this new 3.1 distribution? Is this a one-shot release? Is there any sort of roadmap? Are you testing the waters for demand before making that decision?

shouldnt we wait till after the roadmap dor os4 is actually delivered, which subject is open since a decade at least? do you really need to think there is some master plan, a strategy, behind this release, other than just a tactical opportunity? follow the occams instead to create theories beyond necessity, and your life will be easier. in this case buy the rom if it offers functionality you currently need, but dont buy it upon assumption about what you imagine your purchase might led to eventually one day.

[wawrzon]

@olsen

for what i know there are simple solutions for 1mb kickstart on amiga. i dont remember technical details though. ít could be googled i guess.

but how it stands, the kickstarts here being simply images not actual roms, the 512k limit doesnt apply anyway, since winuae and fs-uae can take advantage of split images, and so far i know even some aca accelerators can be fed with 1mb kickstart replacements.

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

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

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

[wawrzon]

omg.. there it goes again.

[wawrzon]

Sources do not follow the usual convention of .h files, rather depend on a delicate toolchain to generate these from the sources,

im not sure what you are talking about, but we have some similar kind of mechanism on aros too, to define library interface, and even building a regular third party amiga library is involving generating something like that from sources, so it shouldnt be unthinkable of by a regular amiga coder.

together with some assembler stubs that depend on implementation details of the compilers, plus several compiler-specific extensions - as for example to put the library base pointer into a specific register - which, even worse, are completely undocumented.

yes, libbase goes on68k in a particular register, was it a6? aros has a set of macros for that. there are complaints it isnt directly supported by the compiler and that the macro solution is ugly, yet i dont understand enough of this to tell why and how to make it better. however with some entity behind it, it might be easier to convince the gcc maintenance team to at least review the proposals of the patches pushed upstream for an obsolete os for an almost obsolete cpu architecture. i dont place much hopes with it, but if anything maybe apollo softcores may have some significance here.

I fiddled about a week understanding one particular compiler switch for the Lattice compiler that was nowhere in a manual and that was specifically added for CBMs needs and then left alone....

therefore im not sure if sticking to abandoned tools is always better than switching to currently used ones. but im noob in programming as i said.

In short: Too much to do, too many chances to get break something, with too little people to clean it up => just stick with what you have and of what you know that it does its job.  

As said, it compiles under Linux, so it's not that bad anymore, actually.

right, or at least one step at a time. however i was only loosely mentioning that there could be ways to consider if the general attitude was not to keep everything behind the closed doors. as it is, this way people will never learn, and there are ocassional gifted newcomers, only not to os4 camp, where they would have to sign nda beforehand. that is really killing all the spirit. but lets them have it their way.

[wawrzon]

@thor, olsen

alright, sounds like you are stepping in right direction. even if the build system relies on particular versions of make and more than one compiler the sources are not available for, it is fine as long as binaries are freely available to all invloved.

i applaud your effort, guys. the thing is, that as long as solutions proposed by you cost more and deliver less than third party replacements, they still are supposed to be met with criticism. especially, as its been mentioned already, that the target audience has been left outside, standing in the rain for years and had to look for alternatives, and also that the updates are being published under a label with known track of record of ignorance against the genuine amiga hardware and scene, and also been known for not delivering on announcements.

[wawrzon]

Call me uncharacteristically optimistic.[...] getting more Amiga developers involved.

thats exactly a part im sceptical about. you want to eat a cake and keep it. but i bet you wont get people involved if you dont open up. and you dont seem to plan to.

[wawrzon]

You do know that you're complaining to the wrong people. You keep griping about opening the source code but the people you're griping to don't have the rights to do so. They are individuals working on parts of the code, either under contract or volunteer. They don't own it and so can't make the decision to open it.

I know that this has been pointed out several times to you and the other open source "demanders" in this and many other threads. You need to understand that you are making impossible demands of these people. They can NOT do what you are demanding.

This is an example of what I meant above about not being appreciative and grateful for what they are able to accomplish. Look, these people are doing what they can in their spare time and for little or no compensation. How many people do you think have the knowledge, skills, access to the source code, and more importantly the desire to do this work on a long dead computer platform? If people continue to make impossible demands of them, question their ability or insult them, how much longer do you think that desire will last?

These guys don't owe us anything. They have expended a great deal of time and effort to give us what they have. They could just as easily turned away and pursued something profitable. Honestly, with the negativity they get from some of the community, I'm surprised that they haven't and that anyone remains willing to work on a dead product for obnoxious and ungrateful users.

Try saying "Thank you" instead to these guys.

If you have issues about the source code, take it up with the rights holder, please.

yawn.. its not a complaint. i wrote that im fond of what olaf does, simply it wont lead far, i fear, given the circumstances. there is nothing in your post that wouldnt be obvious to almost anybody here, if you are being just grateful and you dont have anything to add, then its fine too.

[wawrzon]

I understand this as being an unsatisfying solution for you. The situation as it is means that all of us, who are trying to get AmigaOS 3.1 into a maintainable state and beyond, are limited by the legal framework currently in place.

thx for understanding. and explanation. one important thing i see, is mention, that this way the publisher is obliged to honour the agreements with you, the developers. this of course is an understandable reason to the status quo as present. i think, i understand very well your and thors idea how to advance and would really welcome that succeed.  

This could change. I doubt that it will change in the short term.

While we are waiting for the change to come, there's something we can do that makes a difference.

exactly, alas, and since effectively a third of human life has passed with us waiting and nothing changed, i must say my expectation as it is probably with quite a few among the remaining community has hit the bottom.

One: figure out how the Amiga operating system might be made suitable in the context of a community-driven project (this will take time, knowledge of the legal framework,  talking to the right people and convincing them), making the change happen.

sorry, but i dont see how the community can help with this. even if it could, it would require a willing partner on the other side, who is actually the only instance that can declare terms. i simply dont see a possibility to open the content we are speaking of. others might try, but given the attitude in communication it usually remains just useless talk on the forums.

Two: work on Amiga operating system development as it is possible right now - at the very least you could get insights into how it works, how to develop it, and that is information you could in time pass on to others when the operating system development becomes more open (even NDAs elapse). You cannot be expected to gain all that working knowledge solely from studying source code

[/QUOTE]

im sure many do that anyway. there are people replacing the whole components of the system with their code, there is a huge number of patches, the third party software, that could be considered today a necessary contributions is being actively developed. this all for better or worse, with more or less skill, with no supervision, not particularly much communication, with efforts being doubled or quadrupled in the same area. i think its likely to remain like this.

[wawrzon]

I bought kickstart and wb mostly for a support. But I started to make a new 1mb custom kickstart and I can't split this kickstart. RomSplit just says unsupported kickstart, what other tools are for that?

of course. romsplit can only disassemble the kickstart it knows. it wont disassemble just any of your custom kickstarts, even though remus can assemble such. im not aware of any other tools to do that, even though an experienced coder could probably extract the modules by hand. your alternative is to take this kickstart as is or to stick to the patched one.

[wawrzon]

I am not a lawyer nor do I play one on TV so I don't know. I certainly don't think that Thomas and all are the ones. Complaining to or about them is just a waste of time and can't accomplish anything positive.

there might be some "the lawyers" around, but it is not us. therefore i say, that it is not our job to figure out a solution that would allow for some developments on amiga front. even though im rather impressed that someone like olaf did the work to rearrange sources for better maintainability, as i imagine how much hassle it might be, without a single patch applied. then again, neither this or the few patches to kickstart isnt what the future developments depend on. im not complaining that olaf does this work. i rather fear that it is in vain. and not because of my complaints, but rather because of the so called objective difficulties.