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

[guest11527]

Tony has a couple of nice blogs on his adventures in this area...

That's really only the internal design of the console.device. FYI, ViNCEd works completely different from that and has two internal representations of lines: A "packed" line where each line is broken up into "words" that share the same attributes, with blanks in between, and an unpacked version with a one-byte glyph and a two-byte attribute per character in the line. Whenever the cursor enters a line, this line is unpacked, the user makes edits, and when the cursor leaves the line, it is packed again.

The internal representation is all fine, but the problem is how the console interacts with the shell. ViNCed somehow "hijacks" the CLI structure of the I/O streams that reach the handler, and from that "guesses" (it's a bit better than this, but let's make it simple) what the corresponding CLI is, from there figures out what the path is, and from there runs the TAB-expansion, and from there places the expansion back into the window. Actually, a separate side-thread is responsible for that.

It works, but the bad part about is the lack of isolation. Essentially, the console has to mess with data structures (the CLI) it should really not care about. The CLI structure is frozen, so nothing bad can happen, but it's still not how it is supposed to work. The shell should care about its own structures, and do the expansion, and the console should inform the shell when the user needs an expansion.

On the ViNCEd side (not the "ROM console") everything is there to support such an improved operation, but from the Shell side it is not.

[Georg]

The shell should care about its own structures, and do the expansion, and the console should inform the shell when the user needs an expansion.

OTOH with expansion being done in console handler it also works inside programs started from shell. So if you type "list ?" you can still enter a directory name with tab expansion which you could not if expansion was (only) done by shell itself.

[olsen]

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.

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.

That framework (leaving aside for a moment why it is subject of criticism) at least allows for the work to be done such that it can be published without being challenged, that money can be earned by selling it and the publisher is legally required to honor the contracts being made with the participants of the project.

One downside to that framework is that the rightsholder (of the Amiga operating system as it is) requires that the material being worked on be treated as confidential. That's how it is for now. This would be a dealbreaker for many people who would otherwise feel more motivated to join in.

The Amiga community today is what is is: a community. It follows (at least from my point of view) that the same dedication should be extended to Amiga operating system development in the form of a community-driven project. I can agree to that. As things are, it's not going to  happen like that, with the existing legal framework governing the Amiga operating system in place.

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.

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.

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

[utri007]

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?

[guest11527]

OTOH with expansion being done in console handler it also works inside programs started from shell. So if you type "list ?" you can still enter a directory name with tab expansion which you could not if expansion was (only) done by shell itself.

Yes, though is this really a good approach? If this is, for example, some sort of program is running in the shell, then TAB should just do the natural thing, namely move to the next tab position, and not do anything beyond.
I remember having written a program that expects some sort of matrix input (a 3x3 matrix), entered row by row, where each column is separated by TAB. If the Shell would run an expansion on this program, it would not only misunderstand the input, it would also mess it up.

Currently, ViNCEd goes in circles to find out when it can do what. For example ^Z (the magic "give me a new job") works only if a program is currently holding the shell, and TAB only works if the shell is visible and no program is running.

For that, the *console* analyzes whether a Shell is running in it, and if so, checks its structures. Instead, the shell should say what it needs, and not the other way around.

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

[nicholas]

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

Who are they?

Cloanto claim ownership of the whole OS, Hyperion claim to own a licence to distribute it from the latest shell company that McEwen is passing off as the original Amiga Inc.

So who should he take it up with?

[Pgovotsos]

Who are they?

Cloanto claim ownership of the whole OS, Hyperion claim to own a licence to distribute it from the latest shell company that McEwen is passing off as the original Amiga Inc.

So who should he take it up with?

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.

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

[Gulliver]

Now this is starting to get weird:

Now both Hyperion and Cloanto are developing independent AmigaOS 3.1 continuation branches.
They are both actively selling kickstart licenses.
And have provided affordable disk versions.

So:
At least we got two companies developing the OS for Amigas.
Would this state of affairs fragmentate (yet again) the Amiga scene?
Seems, at last, they both realized money is available in the 68k world.

Food for thought.

[Cosmos]

Now this is starting to get weird:

Now both Hyperion and Cloanto are developing independent AmigaOS 3.1 continuation branches.
They are both actively selling kickstart licenses.
And have provided affordable disk versions.

So:
At least we got two companies developing the OS for Amigas.
Would this state of affairs fragmentate (yet again) the Amiga scene?
Seems, at last, they both realized money is available in the 68k world.

Food for thought.

It's called division = to sink the Classic definitively...

[SpaceMonkey]

I'm hoping for the following

KickStart 3.10
All the latest modules and bug fixes for all known issues which supersedes OS 3.9 rom updates
Full support for disks up to 128GB
Supports all hardware
1 MB Rom(yes i know this causes issues for A4000\A3000)
Support for re flash-able roms

WorkBench 3.2
all Bug fixes in 3.1
Support for KickStart 3.10

WorkBench 3.10
All Bug fixes known for 3.9
merge all boing bags

Common
Fix HDTOOLS

[kolla]

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.

Didn't the page of Hyperion have that information?

EDIT: Ah, it was here

Btw - to mentioned something I would have thought was obvious, it would be nice if Remus could also save split data for the kickstarts it builds. Also, it is worth mentioning that there is an alternative to Remus, romtool, written in python - https://github.com/cnvogelg/amitools/tree/master/amitools/rom

[gregthecanuck]

I'm hoping for the following

KickStart 3.10
All the latest modules and bug fixes for all known issues which supersedes OS 3.9 rom updates
Full support for disks up to 128GB
Supports all hardware
1 MB Rom(yes i know this causes issues for A4000\A3000)
Support for re flash-able roms

WorkBench 3.2
all Bug fixes in 3.1
Support for KickStart 3.10

WorkBench 3.10
All Bug fixes known for 3.9
merge all boing bags

Common
Fix HDTOOLS

Exactly!!

@Olsen - thanks for your feedback on this thread so far. As you can see there is a lot of interest in getting a new supported OS3.x distribution going. Hopefully the rights/IP holders can be convinced to help open things up to advancement.

[QuikSanz]

I'm hoping for the following

KickStart 3.10
All the latest modules and bug fixes for all known issues which supersedes OS 3.9 rom updates
Full support for disks up to 128GB
Supports all hardware
1 MB Rom(yes i know this causes issues for A4000\A3000)
Support for re flash-able roms

WorkBench 3.2
all Bug fixes in 3.1
Support for KickStart 3.10

WorkBench 3.10
All Bug fixes known for 3.9
merge all boing bags

Common
Fix HDTOOLS

There is at least a 1meg flash rom available. Can all we need squeeze into 1Meg?. Would be nice to have an image of it.