The floppy "startup-sequence" to launch the app

[8bitsten]

Hello,

I was recently creating a simple

startup-sequence

script for a floppy so I can boot from it and launch the program. It works really nice on WB31:

   
   ECHO "AMISNAKE Loading..."

   AMISNAKE:Amisnake.run >NIL:

   ENDCLI

I have decided to try it on WB13, but it ends with the error

Unknown command ECHO

. I have removed the

ECHO

command and it started working nicely. But when I tried it back on WB31 it stops working with the error

AMISNAKE:Amisnake.run: Unknown command AMISNAKE:Amisnake.run failed returncode 10

. I have tried to figure out out the problem and I found that the

ECHO

command is essential here(!). Whatever I have done without the initial

ECHO

script it did not work on WB31. Apparently, I must be doing something really bad!







Thanks for any help
STeN

[TCD]

Could you upload the ADF that doesn't work with 3.1?

[Torti-the-Smurf]

ECHO is NOT in the 1.3 KickstartRom.
Its on the Workbench 1.3 Disk,
so you would need to copy the ECHO command from the Workbench 1.3 Disk to yours, so it can work in a 1.3 Setting.

Are you sure "AmiSnake.run" is a executable Binary File ?
Seems like a Skript file.

What TCD said. Lets have a look at this disk (AmiSnake.run) thing.

[a/b]

In WB3.1 Echo is a built-in shell command, in WB1.3 it's loaded from disk (e.g. copy it from Workbench disk, it's in C directory). The same for EndCLI.
Are you sure Amisnake is able to run on WB1.3 (or does it require WB2.0+ or similar)?

[8bitsten]

In WB3.1 Echo is a built-in shell command, in WB1.3 it's loaded from disk (e.g. copy it from Workbench disk, it's in C directory). The same for EndCLI.

ECHO is NOT in the 1.3 KickstartRom.
Its on the Workbench 1.3 Disk,
so you would need to copy the ECHO command from the Workbench 1.3 Disk to yours, so it can work in a 1.3 Setting.

a/b and Torti-the-Smurf
Thanks for the clarification!

Are you sure Amisnake is able to run on WB1.3 (or does it require WB2.0+ or similar)?

Are you sure "AmiSnake.run" is a executable Binary File ?
Seems like a Skript file.

a/b and Torti-the-Smurf
Yes, it is - it is just a test app (hunk binary) done in C (VBCC). To make absolutely sure I had made no mistake I made a simple "Hello World", but the result is same It must be something really stupid...

Attached is the adf - if you can check it I will really appreciate that.

[alkis]

This is weird.
It doesn't want to run when it's the first thing in the startup-sequence. Probably something is not opened yet.

In KS2.0 (a500+) and in KS3.0 (A1200) if you uncomment the echo in startup-sequence it runs.

In KS1.3 (a500) if you copy echo and uncomment the echo then it runs.

[8bitsten]

This is weird.
It doesn't want to run when it's the first thing in the startup-sequence. Probably something is not opened yet.

In KS2.0 (a500+) and in KS3.0 (A1200) if you uncomment the echo in startup-sequence it runs.

In KS1.3 (a500) if you copy echo and uncomment the echo then it runs.

@alkis This is exactly my experience. I would love to know what is going wrong there... I spent several hours trying to find out what the issue is but had no success.

STeN

[meynaf]

It is possible the C startup code badly wants the shell window to be opened and doesn't work if it's not. On 1.3 it is always open, but starting with 2.0 it is only opened when actually used.

[Exodous]

I'm intrigued by this, so have just tried it myself.

If I replace the bootblock with one from 1.3 (boot from a 1.3 disk in DF0: and open a Shell, insert your disk in DF1: and do "install df1:") then it works fine on both a Quickstart 500 and Quickstart 1200 without the echo command enabled.

As far as I recall, the only difference is that KS2.0+ bootblocks load the expansion.library as well as the dos.library, but that shouldn't cause this sort of oddity otherwise a lot of other software would break.

Using the 2.0+ bootblock, I tested with a short assembler program I just knocked up and it works fine, so I guess there is something wrong in the startup code your program is linked with.

What are you using to write/link your program with?

[8bitsten]

I guess there is something wrong in the startup code your program is linked with.

It is possible the C startup code badly wants the shell window to be opened and doesn't work if it's not.

@Exodous and @meynaf

First let me thank both of you for your time and help

So the suspect is compilation or linking... I used VBCC and this example code https://github.com/8bitsten/public/t...hellointuition. I cannot find anything wrong there.

But I found that the

>NIL:

in

startup-sequence

is the problem. When I removed it starts working on WB31... No idea why.

What is even worse that I wrote another example (called

rl.exe

) - just simple

printf()

and scanline

COLOR0

changed in asm and it works fine with and without

>NIL:

:

;This does not work !!
;HelloInt.exe >NIL:

;I have removed ">NIL:" and it  works just fine
;HelloInt.exe

;But this works!! Why?
rl.exe >NIL:

I updated the ADF (floppy_issue2.zip) and put both samples here.

In a result: I know a workaround, but still, I feel bad about not knowing where the problem is.

Warm Regards,
STeN

[alkis]

Ok, I've looked at the source and I think this must be the problem
struct Screen* workBenchScreen = getWorkbenchPubScreen();
https://github.com/8bitsten/public/b...ntuition.c#L62

this must return null (cause there is no workbench screen at the moment) and thus you return -1 which gives "Unknown command"

[meynaf]

Originally Posted by 8bitsten

But I found that the

>NIL:

in

startup-sequence

is the problem. When I removed it starts working on WB31... No idea why.

This is normal.
>NIL: suppresses the output and the screen is not opened. Without it, there is some output (pretty much like if the echo command was there) and the screen is opened.

[8bitsten]

Ok, I've looked at the source and I think this must be the problem
struct Screen* workBenchScreen = getWorkbenchPubScreen();
https://github.com/8bitsten/public/b...ntuition.c#L62

this must return null (cause there is no workbench screen at the moment) and thus you return -1 which gives "Unknown command"

@alkis That was my guess as well. I "logically assumed" there is no Workbench screen, but it is. Believe me - I spend ~2 hours commenting our and in line by line trying to figure out where the problem is and the non-existence of Workbench screen was my first tip. But it is here

• See the screensho
• Even if it will be not there there are many

  pritntf()

  statements whose output will be printed. But from the CLI output, it seems the program is not even started
• It will not work on WB13.

But thanks for the tip. I really appreciate that.



Regards,
STeN

[Exodous]

As @meynaf says, if you suppress all console output, there is no screen. Having a single printf causes the screen to be opened.

If you add the following just after your "struct Screen* workBenchScreen = getWorkbenchPubScreen();" line:

printf("Workbench Screen: 0x%08lx\n", (long) workBenchScreen);

You will see the value of the screen pointer when you run your program.

From a floppy boot, running this after you've done some screen output prints a valid hex value and the program works.

From a floppy boot, if you run it with ">NIL:" you see nothing, but it fails.

However, from a floppy boot, if you run it with ">output.txt" it doesn't open any screen, but puts the content in the file "output.txt" which can then be viewed separately after booting into Workbench and will show "Workbench Screen: 0x00000000".

[8bitsten]

Quote:
Originally Posted by 8bitsten View Post
But I found that the >NIL: in startup-sequence is the problem. When I removed it starts working on WB31... No idea why.

@meynaf Hello, what do you mean by that, please? The

>NIL:

discards the text output (diagnostic messages in our
case), but the UI part should work right? Moreover, the

rl.exe

(2nd example) works with

>NIL:

, the only issue is with

HelloInt.exe

(see GitHub).

Obviously, I am doing something wrong... and I hate that.

Thank you for trying to help me.

Kind Regards,
sTeN

[8bitsten]

As @meynaf says, if you suppress all console output, there is no screen. Having a single printf causes the screen to be opened.

If you add the following just after your "struct Screen* workBenchScreen = getWorkbenchPubScreen();" line:

printf("Workbench Screen: 0x%08lx\n", (long) workBenchScreen);

You will see the value of the screen pointer when you run your program.

From a floppy boot, running this after you've done some screen output prints a valid hex value and the program works.

From a floppy boot, if you run it with ">NIL:" you see nothing, but it fails.

However, from a floppy boot, if you run it with ">output.txt" it doesn't open any screen, but puts the content in the file "output.txt" which can then be viewed separately after booting into Workbench and will show "Workbench Screen: 0x00000000".

@Exodous AAaaaa. That makes sense. Let me check it.

[alkis]

Well, the thing is....
You redirect to NIL: and thus OS delays the opening of WB.
If you don't redirect to NIL: it works cause it opens the screen.

Here is the run when I replaced all printfs with DBG(), where DBG() is:
void kprintf(const char *fmt, ...);
#define DBG(...) kprintf(__VA_ARGS__)
(Note that this works for gcc, don't know how vbcc would want that. Also note you additionaly have to link with debug '-ldebug')


And here is the output in console log.

FS: mounted virtual unit dh0 (..\shared\Amiga500P)
FS: work (flags=00000002,E=0,ED=1,EF=0,native='..\shared\Amiga500P') starting..
Program started!.
Hello Intuition.
[ERROR] Workbench screen cannot be accessed.
Good Bye!.
WARNING: BPL strobe refresh conflict, hpos 03!
WARNING: BPL refresh conflict, hpos 05!
WARNING: BPL refresh conflict, hpos 07!
ShowCursor 0

[meynaf]

Originally Posted by 8bitsten

@meynaf Hello, what do you mean by that, please? The

>NIL:

discards the text output (diagnostic messages in our case), but the UI part should work right?

The shell window does open only when there is actual text output to show. Which isn't the case when using >NIL:.
And the screen won't open unless the shell window does.
And without screen, the UI won't work.

[8bitsten]

@meynaf @alkis @Exodous Fantastic!

Now I'll find some peace... before the next problem comes along.

Thanks for the help!

Regards,
Petr