OS3.2 Bootable Disk Image

[aNdy/AL/COS]

I'm soon to release my Amiga game, Spheroid, which runs on all Amiga's with at least 1Mb or RAM from OS1.2 to OS3.2.


The game can be run from HD and will be released on a bootable disk image.


My disk image boots automatically on all Amiga's (it has the necessary C: and S: folders, etc.) but not on OS3.2. On OS3.2, it stalls at the AmigaDOS window. Typing 'Spheroid' then restarts the process and the program loads and runs fine.


How can I alter my disk image so that it boots on all systems including OS3.2 without the user having to type anything? Something to do with my start-up sequence?

[Nor Bert]

Show startup-sequence

[aNdy/AL/COS]

Yeah, stupid me. Should have posted the startup-sequence!

; ECHO "Loading Spheroid..."
; ECHO "BUILD20231015RC"
Spheroid

I did some experimenting and by commenting out the ECHO calls as above, the game booted, loaded and ran.

The problem is with the ECHO call? May need a newer version in my C: drawer? Is a newer version compatible with OS1.x, 2.x and 3.x?

[Don_Adan]

Originally Posted by aNdy/AL/COS

Yeah, stupid me. Should have posted the startup-sequence!

; ECHO "Loading Spheroid..."
; ECHO "BUILD20231015RC"
Spheroid

I did some experimenting and by commenting out the ECHO calls as above, the game booted, loaded and ran.

The problem is with the ECHO call? May need a newer version in my C: drawer? Is a newer version compatible with OS1.x, 2.x and 3.x?

Kickstart 3.2 has bug in initialisation of dos.library.

https://eab.abime.net/showpost.php?p...postcount=1604

"Echo" command is not handled correctly for OFS disks.
For works on all (?) kicks You must use "echo" from WB 1.3 and OFS disk created/formated under WB 2.0 (not under WB 1.3).

[aNdy/AL/COS]

Thanks for the info! I'll give that a try!

[Nor Bert]

Try program TYPE or similar

[Dunny]

Originally Posted by Don_Adan

Kickstart 3.2 has bug in initialisation of dos.library.

https://eab.abime.net/showpost.php?p...postcount=1604

"Echo" command is not handled correctly for OFS disks.
For works on all (?) kicks You must use "echo" from WB 1.3 and OFS disk created/formated under WB 2.0 (not under WB 1.3).

Wait, so all the disks - and there's a metric crapload of them - that were created under 1.2/1.3 that use Echo will fail to boot in 3.2?

Is there anything we as users can do to fix this? This is a pretty major issue, if not a critical issue.

[Olaf Barthel]

Originally Posted by Boing-Ball

There is a reference to 3.2 kickstart and not 3.2.2 (47.111). So was this not fixed in the current hot fix of 3.2.2.1 ?

No, we learned of this issue too late and the research effort required to pinpoint the source of these troubles promises to be "interesting", to say the least. Something to keep us busy over those dark and not necessarily snowy winter nights for sure.

[Don_Adan]

Originally Posted by Dunny

Wait, so all the disks - and there's a metric crapload of them - that were created under 1.2/1.3 that use Echo will fail to boot in 3.2?

Is there anything we as users can do to fix this? This is a pretty major issue, if not a critical issue.

Yes, disk loading will be stopped for kick 3.2.
User can press Return to continue loading.
Or can install OFS bootblock from WB 2.0+.

[derSammler]

Wonder how such a bug can stay unnoticed at all. I mean, ECHO in the S-S is not rare. And I would assume not doing initialisation of dos.library correctly causes some more issues than that. What does the QA team actually test before a release?

Makes me glad even more I stayed at 3.1.4.

[Olaf Barthel]

Originally Posted by derSammler

Wonder how such a bug can stay unnoticed at all. I mean, ECHO in the S-S is not rare. And I would assume not doing initialisation of dos.library correctly causes some more issues than that. What does the QA team actually test before a release?

Everything which can be tested in practice (before a pending release date sneaks up on you). Which is always a subset of the software which makes up and interacts in the ROM and the disk-based parts of the operating system. More often than one would hope for, it requires luck to identify random quirks for what they are.

The means by which we are able to systematically identify sources of trouble in the operating system are very limited, owing to constraints on how much work we can get done in our spare time, which also goes for the beta testers. You will have heard this epic song before, I trust. Everybody has been singing it for years (it could be a hit, but you never know).

The question "You call this software development?" may be asked. To which I might respond that this is a legacy operating system involving in no small part what could be considered archaeology (but in a nice way).

We will always be at a considerable disadvantage with AmigaDOS, which the boot process, the initial CLI and the modern shell are part of. I would have never even expected the boot block, the startup sequence and the "Echo" command to jointly derail the boot process by making the "Echo" command read a line from the standard input stream. It makes no sense and does not even possess the grace of being funny.

In so many words, the hunt is on, we just need to figure out where the problem is, because the problem area is so large and complex. But that's AmigaDOS for you: if it works perfectly, it's mostly by accident, stubbornness or random strokes of good luck, but not by design.

Makes me glad even more I stayed at 3.1.4.

As is your prerogative

[Olaf Barthel]

Originally Posted by Boing-Ball

Every day is a school day.

Indeed. You practically always learn something new, which somebody else did not know was going to be the subject of a lesson some 20-30 years hence. One might think that the copious available operating system documentation would be helpful, but in terms of useful documentation on AmigaDOS as a whole there is preciously little available. Sure, you could defer to the source code as a last resort, but it tends to raise exponentially more questions than it could have answered.

Such is the luck of the AmigaOS developer: you might not have realized it when you started out, but you are also a researcher who ought to keep a lab notebook.

If this sounds like an interesting challenge, which might just change your life for the better, give us a call

Hope you and the Team over at Hyperion get this one sorted out. Here is to hotfix 3.2.2.2 then..

There is always hope

[aNdy/AL/COS]

My sincere apologies for opening this can of worms! I only wanted my game to be as compatible as possible with as many Amiga models and KS versions as possible...

[AMIGASYSTEM]

@aNdy/AL/COS


I think I found a good alternative to Echo, check out this little video, if you're interested I'll pass on the necessary files.
3.2
This procedure works with all OS's including OS 3.2, although it 3.2 behaves slightly differently from other Kickstarts, closing the programme opens a double "1>" and a strange corruption in the prompt (see screenshot), but everything works normally!

https://eab.abime.net/zone/Test-Startup.zip


@Boing-Ball

On OS 3.2 not only with echo there are problems, also with CliTyper, see screenshot

[aNdy/AL/COS]

@AMIGASYSTEM

Watched the video, interested in how you achieved that! Does this also work all the way down to OS1.2?

In theory, I could just do away with the ECHO command to solve my 'problem'. I only wanted to display a message to the user to show something was happening until the game took over the system and showed the loading screen...

[boemann]

For now I believe you can make it work by running

c:install df0:

with a install command from a newer AmigaOS (I believe 2.0 and up )

The command installs a bootblock on the specified disk. Commodore made an updated boot block back then. It doesn't prevent booting on 1.x so don't worry

Now we must have introduced a bug but it only manifests itself with a disk with one of the old bootblocks as well as an echo command and running 3.2.2

It should get you going but obviously we will look into the issue for the many disks out there

[aNdy/AL/COS]

@boemann

I created my test disk image around 9 months ago and can't remember if I 'INSTALL'ed it using OS1.3 or above or what version of ECHO I put in the C: drawer.

I'll redo the disk using OS2.x to 'install' and different versions of ECHO.

Thanks for comments and suggestions everyone!

[AMIGASYSTEM]

Originally Posted by boemann

c:install df0:

with a install command from a newer AmigaOS (I believe 2.0 and up )

Install 2.0 or higher will not allow booting a disc on Amiga 500 (Kick 1.2/1.3)


@aNdy/AL/COS

Yes the startup also works with kickstart 1.2, I can send you the info in PM.

If you don't need the Command Prompt when you exit the game, I can add EndCli in the startup, which is better for those who only use the game, this way no prompt will be present.

[Don_Adan]

Originally Posted by AMIGASYSTEM

Install 2.0 or higher will not allow booting a disc on Amiga 500 (Kick 1.2/1.3)

Why? You can install OFS bootblock too, not only FFS bootblock. This is CLI tool and FFS bootblock is installed as default, but OFS bootblock can be installed too.

[aNdy/AL/COS]

Originally Posted by AMIGASYSTEM

@aNdy/AL/COS

Yes the startup also works with kickstart 1.2, I can send you the info in PM.

If you don't need the Command Prompt when you exit the game, I can add EndCli in the startup, which is better for those who only use the game, this way no prompt will be present.

Would be interested to see this please!