Oh come on Hyperion...

[wawa]

Originally Posted by Lord Aga

I'm offended! Didn't you see post #54 !?!

i spoke about the current status. should you come up with improved amiga os replacement even implemented in amos ill be among the first to applaud.

[NorthWay]

Originally Posted by Olaf Barthel

Actually, I believe it might just be: assuming responsibility.

That would be assuming ownership. It is not my understanding that Hyperion holds 3.x rights.
I would love to be corrected. (And then heavily depressed.)

[gulliver]

This is another view of the Amiga boot process by Harry Sintonen:

http://www.amiga.org/forums/showpost...2&postcount=12

[dalek]

You know what really gets me?

I grew up with the _Commodore_ Amiga. When I see a kickstart screen with a slightly different shade of purple and a different logo, with _Commodore_ removed and some other company's name splashed there, it really feels like a dirty money grab. It looks and feels wrong.

Yeah I know there were other things changed, but really does it warrant a whole rebranding? The community already have fixes for some of the issues addressed so it's not like a whole lot of engineering effort would have been needed to release something without the whole land grab opportunistic vibe behind it.

Re-released WB 3.1 disks with trivial fixes just so the copyright text can be changed and then charging customer's for the privilege is not really seomthing that sits well with me.

I get it, hyperion paid money for some copyright licenses and wants a return on that investment. But there has to be better ways of doing so than gouging uninformed users returning to the retro Amiga scene.

For me, I'll take my 3.1 bugs and all, and if needed use the community provided workarounds for any major issues.

[IridiumFX]

Still off topic, but glad it took this turn. Thanks everyone, I was reading with genuine interest about the boot process (including the external post). Fascinating how apparently simple the Amiga OS is, yet completely crazy behind the scenes. Loving it more than ever

[kolla]

Regarding datatype.library 45...

http://aminet.net/package/util/libs/dtypeslib453
http://aminet.net/package/util/sys/AddDataTyps452

[Olaf Barthel]

Originally Posted by gulliver

This is another view of the Amiga boot process by Harry Sintonen:

http://www.amiga.org/forums/showpost...2&postcount=12

This is, as it should be, technically detailed and correct. Knowledge of the 'Resident' exec data structure and its contents are required. What I remembered certainly is not to be taken as accurate information

One thing might or might not be worth explaining further.

When the CPU starts up, it picks up the initial values for the stack pointer and the program counter from addresses 0 and 4, respectively. The program counter refers to the exec cold start code in ROM, but the stack pointer does not reference any valid RAM address.

What is picked up as the stack pointer address is of no relevance to the cold start code, because it resets the stack pointer to address 1024 (in chip memory) very early on. Prior to that, the stack pointer just contains the values of the two words which precede the cold start code address.

At address 0, there is a 16 bit word which identifies the type of Kickstart ROM used. In Kickstart 2.x and beyond it can be used to discriminate between a special types of test images and the "real" ROM image used in production.

At address 2, there is a 16 bit word which contains the 68000 instruction for "jump to absolute address". Combined with the contents of address 4, this becomes "jmp $f800d2". Why code with this specific meaning is found here is unclear to me, to say the least...

[ross]

Originally Posted by Olaf Barthel

At address 2, there is a 16 bit word which contains the 68000 instruction for "jump to absolute address". Combined with the contents of address 4, this becomes "jmp $f800d2". Why code with this specific meaning is found here is unclear to me, to say the least...

To give every Amiga machine always a functional RESET with this code snippet:

--- supervisor
lea 2.w,a0
reset
jmp (a0) ;prefetch

EDIT: written quickly before lunch so some explanation maybe due.
reset is a 68000 privileged instruction used to reset external device (RESET* is an output line asserted at cold start or by this instruction).
By itself has no effect on 68k at all so the prefetch normally goes and the jmp (a0) is executed (even if RAM no more in place).
CIAs are connect to RESET* and so the bits is defaulted and OVERLAY is mapping ROM at address 0.
Therefore the code execute the jmp at ROM start
This is valid for every ROM, wherever is the actual boot address, suffice a JMP opcode at offset 2 in ROM,
offset 4 is anyhow right by 68k vector specification. Offset 0 is used as a tag for ROM size/type (like Olaf described).


Regards,
ross

[Olaf Barthel]

Originally Posted by Overflow

@Olaf

I always enjoy reading your posts, but Im having a hard time finding something concrete to focus on in you last post. Im just a socalled enduser, and I do see increased activity (in Amiga terms) on the AOS3.x platform, partly/mostly cause of the Vampire project.
There is some clear misgivings amongst some developers with regards to lack of support for debugging/mmu issues.

I guess my question is; where do you see things progressing? Some are up in arms over ApolloOS, but given the dormant state of AOS3, it was ineviable.

If official developers give us a good reason to purchase updates, by showing a concrete plan, I expect many ApolloOs users will be happy to spend the money.

Atm it feels dead in the water. Correct me if Im wrong It certainly wont be the first time!

As things stand today, there is a need for the operating system to support the hardware solutions in development/shipping right now. My personal take on this situation is that resolving compatibility issues (e.g. support for debugging, MMU setup and operations) will require sharing and coordination of responsibility.

There had been no need for that kind of responsibility, because the 68000 Amiga operating system was to be superseded by the PowerPC operating systems.

Things have changed. It should not be the case that it is "easier" to adapt new hardware to old software than to change that software. If Amiga hardware development is to have a shot at becoming a sustainable business, no developer should be burdened by having to do both the engineering and the "reverse engineering" work, just to figure out how to make his products work.

I can see that happening, it needs to happen. I doubt it will be easy to accomplish, though. Even in the days of Commodore Amiga software/hardware developers were fiercely independent, and this still seems to be true today, perhaps more so. One big difference between then and now was that the quality and availability of documentation and example code used to be better, and Commodore was at least actively supporting the developers. While the Amiga was still new, engineering practices and the knowledge required of the hardware developers was still in step with the time. This is no longer the case, as modern Amigas are beholden to hardware and software designs of the early 1990'ies, yet need to leverage today's technology. That's a lot of knowledge to master and to apply, and it seems that everybody has to find his own way to collect the relevant documentation and put it to use. This should be much easier than it is today.

All of this suggests to me that the current practice of taking what's in the 68000 Amiga operating system for granted will only make it harder to create new product. The 1994 operating system design today is both a rocky foundation and a constraint. This has to change, too.

[Olaf Barthel]

Originally Posted by ross

To give every Amiga machine always a functional RESET with this code snippet:

--- supervisor
lea 2.w,a0
reset
jmp (a0) ;prefetch

Yes, that works: it's the recommended way to do this for Kickstart 1.3. Because it was documented in 1988 ("The Official Way to Software Reboot an Amiga", which I just dug up on http://www.textfiles.com/programming/AMIGA/techart4.txt), the "jmp" instruction probably is a compatibility measure.

EDIT: written quickly before lunch so some explanation maybe due.
reset is a 68000 privileged instruction used to reset external device (RESET* is an output line asserted at cold start or by this instruction).
By itself has no effect on 68k at all so the prefetch normally goes and the jmp (a0) is executed (even if RAM no more in place).
CIAs are connect to RESET* and so the bits is defaulted and OVERLAY is mapping ROM at address 0.
Therefore the code execute the jmp at ROM start
This is valid for every ROM, wherever is the actual boot address, suffice a JMP opcode at offset 2 in ROM,
offset 4 is anyhow right by 68k vector specification. Offset 0 is used as a tag for ROM size/type (like Olaf described).


Regards,
ross

Back in the day, this still appeared to be too much work

Most people who needed to perform a proper reset just seemed to jump straight to $fc00d2 (with $fc00d2 loaded into a register and a "jmp (register)", because the prefetch only pulls two words in advance, and "jmp $fc00d2" would need three). The Amiga 600 ROMs even made some room around $fc0000 just so that the reset ROM jump that used to be valid in 1988 could still work. This was called "kickety-split", and it's an option for the ROM image build tool.

Incidentally, leveraging the prefetch can be be used to force the Amiga 1000 Kickstart to be reloaded: reset, then overwrite the first 32 bit word of the ROM so that the ROM checksum will become invalid. exec will notice the checksum mismatch, but get stuck. Hold down the Control+Amiga+Amiga keys to trigger a hardware reset and the boot ROMs will prompt you to insert a Kickstart disk again.

[IridiumFX]

Completely agree with you Olaf. That's why I say that every missed chance to share info could be a disaster. If there was a coordinated and legal effort (whether open or under NDA, does not really matter, atm) to restart Amiga OS development, I'd be more than willing to sacrifice most of my free time to the cause.

Originally Posted by Olaf Barthel

As things stand today, there is a need for the operating system to support the hardware solutions in development/shipping right now. My personal take on this situation is that resolving compatibility issues (e.g. support for debugging, MMU setup and operations) will require sharing and coordination of responsibility.

There had been no need for that kind of responsibility, because the 68000 Amiga operating system was to be superseded by the PowerPC operating systems.

Things have changed. It should not be the case that it is "easier" to adapt new hardware to old software than to change that software. If Amiga hardware development is to have a shot at becoming a sustainable business, no developer should be burdened by having to do both the engineering and the "reverse engineering" work, just to figure out how to make his products work.

I can see that happening, it needs to happen. I doubt it will be easy to accomplish, though. Even in the days of Commodore Amiga software/hardware developers were fiercely independent, and this still seems to be true today, perhaps more so. One big difference between then and now was that the quality and availability of documentation and example code used to be better, and Commodore was at least actively supporting the developers. While the Amiga was still new, engineering practices and the knowledge required of the hardware developers was still in step with the time. This is no longer the case, as modern Amigas are beholden to hardware and software designs of the early 1990'ies, yet need to leverage today's technology. That's a lot of knowledge to master and to apply, and it seems that everybody has to find his own way to collect the relevant documentation and put it to use. This should be much easier than it is today.

All of this suggests to me that the current practice of taking what's in the 68000 Amiga operating system for granted will only make it harder to create new product. The 1994 operating system design today is both a rocky foundation and a constraint. This has to change, too.

[NorthWay]

Apart from the gross rights mess, would it be an idea to set up a bug tracker for 3.1/3.9 some place where the public can report and comment/workaround on bugs? Possibly with an option for suggestions or requests.

No, it doesn't do tiddly-squat with the OS stuck in development limbo, but wouldn't it be something that have to be done anyway if it ever becomes unstuck?
(And no, I'm not that guy who knows anything about server side ticket/tracking tools.)

[Minuous]

I maintain a list of known bugs at http://amigan.1emu.net/releases/ami-code.txt , everyone is welcome to contribute to it.

[bubbob42]

Originally Posted by Minuous

I maintain a list of known bugs at http://amigan.1emu.net/releases/ami-code.txt , everyone is welcome to contribute to it.

That's great - your list includes the SAS/C kprintf-Bug which drove me quite mad when I first encountered it.

[nogginthenog]

I use Atlassian's JIRA at work. It's quite nice for bug tracking & development.
When the AmigaOS source is released under an open source license we can use it at no cost

[Olaf Barthel]

Originally Posted by NorthWay

Apart from the gross rights mess, would it be an idea to set up a bug tracker for 3.1/3.9 some place where the public can report and comment/workaround on bugs? Possibly with an option for suggestions or requests.

Yes, this definitely needs to happen.

We eventually settled for Bugzilla as a bug tracker for AmigaOS development work, briefly tried Mantis, but switched back to a more modern version of Bugzilla in the end.

Seems to me that there are not that many bug trackers around which can be self-hosted, and I believe it ought to be self-hosted. The old-timers aside (Bugzilla, etc.), has anybody a suggestion as to what might be a good choice today?

[Olaf Barthel]

Originally Posted by Minuous

I maintain a list of known bugs at http://amigan.1emu.net/releases/ami-code.txt , everyone is welcome to contribute to it.

Nice

Considering how long AmigaOS 3.x has been around and not seen any improvements, the list is a wee bit on the short side

Seriously, reports on bugs, as well as enhancement requests have been reported to and recorded by Commodore up until the bitter end.

Anybody remember the Commodore "report" tool of old? It produced a bug report/enhancement request in a standardized format which would then be sent via e-mail to Commodore. Upon arrival, a Perl script would process the e-mail message contents and would then store it in a database. That "database" was actually a file system hierarchy on a Unix server. The top level directories represented the respective categories (e.g. "AmigaBasic", "ARexx", ..., "util.command", "wack", "workbench") and the reports were then stored as individual files in those directories. Another script would process these files and send the new entries to the respective developers, as well as the private news groups which 3rd party developers had access to.

A copy of the "bugs" and "ereq" databases was available to the European Amiga Developer Support Program (ADSP) subscribers, and as luck had it, Village Tronic GmbH managed to acquire what turned out to be the very Amiga Unix server (an Amiga 3000T prototype) on which these databases were stored. The database contents have been preserved, and cover the years 1990-1993 (roughly).

It's not always easy to tell which database entries are still relevant, and which problems were addressed, but the entries might just be worth looking over. There are more than 3,000 bug report entries around, and more than 2,200 enhancement requests.

[MartinW]

Originally Posted by Olaf Barthel

Seems to me that there are not that many bug trackers around which can be self-hosted, and I believe it ought to be self-hosted. The old-timers aside (Bugzilla, etc.), has anybody a suggestion as to what might be a good choice today?

Unless you're open source (which we know AmigaOS is not) then you are very limited unless you want to pay $$$. I have experience of Jira and it's probably the bar that most others are measured against but hell, it's complex! (and very expensive for non OS)

Currently at work we are using Visual Studio Online. Somewhat simpler, a bit on the quirky side but it works for us. Not self hosted however. The nice thing about that is (for us) you get a few full users for free which can be the developers, but you can have as many free 'Stakeholdrs' as you like and they can still participate with bug tracking, just not the code side of things.

Any reason for the self-hosting other than privacy and control? Most of the hosted ones have private repository options which may or may not come free / low cost.

[Leffmann]

Originally Posted by Olaf Barthel

A copy of the "bugs" and "ereq" databases was available to the European Amiga Developer Support Program (ADSP) subscribers, and as luck had it, Village Tronic GmbH managed to acquire what turned out to be the very Amiga Unix server (an Amiga 3000T prototype) on which these databases were stored. The database contents have been preserved, and cover the years 1990-1993 (roughly).

Would you consider sharing them? There can't be anything confidential or which must still be kept closed, since they were already shared 25 years ago.

[NorthWay]

We use Jira at work (among others like BMC Remedy), though I was somewhat hazily of the impression that it was kinda part of the open source movement. Mea culpa.
Am I totally wrong in thinking GitHub has some tracking stuff? (Possibly with some requirements that can't be met?)

All I wanted was to complain about Deallocate()...