How buggy was Kickstart 1.0

[redblade]

Hi.

I was just reading Amazing Computing Issue 01 from the eab ftp and it mentions the Date virus slowing down the amiga doing file listings because the file date was set in the future compared to the amiga clock. What were the other major problems of kickstart 1.0?!?

Seems like a good magazine, a lot of source code and tutorials.

Thanks

[TroyWilkins]

I could be wrong here, but I believe some of the others were the following:

When dragging an icon, it doesn't check to see if you're dragging it to a new location that makes sense. For example, dragging the icon for a drawer into the window for that drawer. I believe that causes a crash and makes a mess of the disk.

When resizing a window, it doesn't check to see if you're dragging above or to the left of the open window, and if you do that, the guru appears.

When allocating RAM, it doesn't check to see if that ram is actually available before allocating it and trying to use it, so if you only had the base 256K of RAM the 1000 came with, and didn't have the extra 256, this could easily crash the system when you tried to run something.

I could be wrong about these, as these are from memory, and I don't have a working emulated A1000 setup at the moment to test with.

[Hewitson]

Although it focuses more on Workbench than Kickstart, you might find this website interesting:

http://www.gregdonner.org/workbench/index.html

[BastyCDGS]

Originally Posted by Hewitson

Although it focuses more on Workbench than Kickstart, you might find this website interesting:

http://www.gregdonner.org/workbench/index.html

Thank you for this!

I was just reading it, but there is something causing me to wonder about the recoverable RAM disk. It is said in the WB1.3.x series that it is called RAMB0:

But I only remember it always have been the device name RAD:

More confusing there is a claim there have been different types of the recoverable RAM drive. Was it really about device names? I would assume it had more to do with the Flags settings in the MountList.

Can someone explain this to me, please?

[Leandro Jardim]

Originally Posted by TroyWilkins

...
When resizing a window, it doesn't check to see if you're dragging above or to the left of the open window, and if you do that, the guru appears.
...

Yeah, if you press LAMIGA+M while you are dragging you will be able to resize the "rubber band" in opposite direction and this will sooner or later crash the Amiga OS.

Learned that in my days of Amiga 500. Good times...

[Olaf Barthel]

Originally Posted by Leandro Jardim

Yeah, if you press LAMIGA+M while you are dragging you will be able to resize the "rubber band" in opposite direction and this will sooner or later crash the Amiga OS.

Learned that in my days of Amiga 500. Good times...

This was a bug in the Intuition state machine. Timer and input events (keypresses, mouse movements, mouse clicks) flow through Intuition, and what actions are permissible is defined by what conditions the current state allows.

For example, pressing the left mouse button while the pointer is within the area of the window title bar transitions to a state which allows you to move the window around. As you move the mouse, a rectangle is redrawn which stands in for the window, respecting the boundaries of the screen. You leave this state when you let go of the left mouse button, which cleans up the rectangle and moves the window.

Because shouldn't be able to flip through the screens while you are dragging a window around, Intuition should have ignored the Amiga+M and Amiga+N keys, but these slipped through (the state transition table has "default actions" for events which are not specifically covered or restricted). While Intuition didn't leave the window dragging state, it still called code in the handler functions which responded to the Amiga+M and Amiga+N input events. For one thing, this broke the window position and size validation (clipping).

This bug was eventually fixed in Kickstart 2.0.


Speaking of entertaining bugs which lead to major desasters in the day, consider this: in the Workbench (1.1-1.3) open a drawer which contains a subdirectory, then drag the parent drawer into its subdirectory. This shouldn't work, should it?

Now close the window of both the parent drawer and of the subdirectory you dragged the parent drawer into.

What happened? You just deleted the parent drawer and all its contents.

This bug used to be ridiculously easy to trigger if your left mouse button was unreliable (because it was worn out). You'd start dragging a drawer to a different place and midway the left mouse button no longer stayed pressed. Then Workbench would either move it or copy its contents. Sometimes a drawer was moved into one of its subdirectories, and you didn't notice that it had wound up in the wrong place. Then you closed the many windows you had open to figure out where it went.

You could level up the degree of desaster you found yourself in by using the always reliably "Disk Doctor", but then back in the day your choices were extremely limited...

[Olaf Barthel]

Originally Posted by TroyWilkins

I could be wrong here, but I believe some of the others were the following:

When dragging an icon, it doesn't check to see if you're dragging it to a new location that makes sense. For example, dragging the icon for a drawer into the window for that drawer. I believe that causes a crash and makes a mess of the disk.

This was a different kind of bug, if I remember correctly.

No matter, the Workbench should not have needed to make sure that you would not move a directory within its subdirectory tree. The file system should have denied this attempt, but then it did not

[redblade]

Originally Posted by TroyWilkins

I could be wrong here, but I believe some of the others were the following:

When dragging an icon, it doesn't check to see if you're dragging it to a new location that makes sense. For example, dragging the icon for a drawer into the window for that drawer. I believe that causes a crash and makes a mess of the disk.

When resizing a window, it doesn't check to see if you're dragging above or to the left of the open window, and if you do that, the guru appears.

When allocating RAM, it doesn't check to see if that ram is actually available before allocating it and trying to use it, so if you only had the base 256K of RAM the 1000 came with, and didn't have the extra 256, this could easily crash the system when you tried to run something.

I could be wrong about these, as these are from memory, and I don't have a working emulated A1000 setup at the moment to test with.

256K RAM, Must of struggled to get the Amiga to do anything productive with that type of memory.

Originally Posted by Hewitson

Although it focuses more on Workbench than Kickstart, you might find this website interesting:

http://www.gregdonner.org/workbench/index.html

Yes that is a great site I've been there a few times and I see he is active on this site.

Originally Posted by Leandro Jardim

Yeah, if you press LAMIGA+M while you are dragging you will be able to resize the "rubber band" in opposite direction and this will sooner or later crash the Amiga OS.

Learned that in my days of Amiga 500. Good times...

Originally Posted by Olaf Barthel

This was a bug in the Intuition state machine. Timer and input events (keypresses, mouse movements, mouse clicks) flow through Intuition, and what actions are permissible is defined by what conditions the current state allows.

For example, pressing the left mouse button while the pointer is within the area of the window title bar transitions to a state which allows you to move the window around. As you move the mouse, a rectangle is redrawn which stands in for the window, respecting the boundaries of the screen. You leave this state when you let go of the left mouse button, which cleans up the rectangle and moves the window.

Because shouldn't be able to flip through the screens while you are dragging a window around, Intuition should have ignored the Amiga+M and Amiga+N keys, but these slipped through (the state transition table has "default actions" for events which are not specifically covered or restricted). While Intuition didn't leave the window dragging state, it still called code in the handler functions which responded to the Amiga+M and Amiga+N input events. For one thing, this broke the window position and size validation (clipping).

This bug was eventually fixed in Kickstart 2.0.


Speaking of entertaining bugs which lead to major desasters in the day, consider this: in the Workbench (1.1-1.3) open a drawer which contains a subdirectory, then drag the parent drawer into its subdirectory. This shouldn't work, should it?

Now close the window of both the parent drawer and of the subdirectory you dragged the parent drawer into.

What happened? You just deleted the parent drawer and all its contents.

This bug used to be ridiculously easy to trigger if your left mouse button was unreliable (because it was worn out). You'd start dragging a drawer to a different place and midway the left mouse button no longer stayed pressed. Then Workbench would either move it or copy its contents. Sometimes a drawer was moved into one of its subdirectories, and you didn't notice that it had wound up in the wrong place. Then you closed the many windows you had open to figure out where it went.

You could level up the degree of desaster you found yourself in by using the always reliably "Disk Doctor", but then back in the day your choices were extremely limited...

You guys are serious users, trying to do stuff like moving the parent directory into the child directory, I didn't think of that.

My WB 1.3 days involved, just booting up workbench to run xcopy 2, novirus, AmigaBASIC. I didn't get heavily into WB untill I got my second hand A600HD. Before that it was just CLI or Disk Master 1.3

Thanks for the replies

[TroyWilkins]

Originally Posted by redblade

256K RAM, Must of struggled to get the Amiga to do anything productive with that type of memory.

To be fair, the designers didn't want it released with so little RAM, it was always supposed to have at least 512K RAM. But my understanding is that that was one of the first ways in which Commodore management screwed things up, insisting on it not being released with so much expensive (at the time) RAM, and one of the engineers (I can't recall who ATM) telling them how they could do it.

[Leandro Jardim]

Originally Posted by redblade

You guys are serious users, trying to do stuff like moving the parent directory into the child directory, I didn't think of that.

[Olaf Barthel]

Originally Posted by redblade

256K RAM, Must of struggled to get the Amiga to do anything productive with that type of memory.

Tell that to the Apple Macintosh users: in 1984 it shipped with as much memory as the C64 had: 64 KBytes. For the Amiga 256 KBytes of memory must have appeared to be really massive by comparison

[britelite]

Originally Posted by Olaf Barthel

Tell that to the Apple Macintosh users: in 1984 it shipped with as much memory as the C64 had: 64 KBytes

Citation needed.

The first model as far as I can tell shipped with 128k.

[chb]

Originally Posted by britelite

Citation needed.

The first model as far as I can tell shipped with 128k.

AFAIK there was no Macintosh with less than 128k of RAM. However, the ROM on the first models was only 64k in size, so combined the space for OS + programs was really tiny compared to even the base Amiga 1000 (256k RAM + 256k WCS).

EDIT: That 64k figure may be true for the early prototypes that had an 6809 instead of the 68000:
https://www.i-programmer.info/histor...1-the-mac.html

[mark_k]

A similar thing happened during development of the Amiga; 128KB chip RAM was originally supposed to work.