Amiga questions you've always been too embarrassed to ask

[Jope]

Originally Posted by thomas

The drive moves the head one track up or down. This is the click you hear. AFAIK if the head moves over the magnetic surface of a disk, even if the disk is not rotating, a small electric pulse is generated and the drive knows that a disk is in. If no such pulse appears, then there is no disk in the drive. This is how the drive checks for disk changes.

Hmm, I'm not sure if you wrote what you meant there?

The drive has a diskchange pin, which reflects the state of the disk change switch near the write protection switch.

However there is a logic gate between the switch and the diskchange pin, which holds the status of the switch and that only gets updated every time you step in or out.

The guys at Commodore noticed quite early on that the anti-click method works for most drives, but by the time they were going to implement it in trackdisk.device, someone noticed that they had already shipped some machines with mechanisms that were incompatible with it.

Thus they didn't want to enable it in ROM for 2.x, even though 2.x introduced a bit you can flip to enable it at your own peril.

That said, the big question is: why does the drive not need to click when a disk is in the drive?

I've never investigated this myself, so I'd have to start guessing. When the disk is in the drive and diskchange is detected as on, the OS is happy with this state of things.

My assumption is that the diskchange signal will reflect an ejected disk immediately when you eject it and only the no disk -> disk detected transition requires the head step for it to become visible at the diskchange pin.

[Jope]

Originally Posted by Marcuz

I've always wondered what made the weight of the power unit on A500 and on A1200 so different, with the former being a brick and the other being so light: since I burned a couple of the A500 ones, in very little time, with them being so expensive, I was kind of let down when I got the A1200, because its power unit seemed so cheap.

This one has been answered here a couple of times, but my two eurocents:

Some power bricks are light, these are switch mode power supplies. Some power bricks have the traditional iron core transformer in them, these will be the heavier PSUs.

The switch mode is more efficient at converting the wall electricity into DC voltages your Amiga can use, but this is not the whole truth when trying to determine which PSU is better.

As has been discussed elsewhere on this forum various times, weight alone will not make a PSU better or worse. You will have to look at the specifications on the sticker under the PSU to find out which PSU outputs more current.

[Jope]

Originally Posted by s2325

Is there more use to Amiga keys than to resetting machine?

Originally Posted by diablothe2nd

yep, they're used for shortcuts like ctrl+c and ctrl+v does on the PC.

These are accessed via the left amiga key. Here's some of the commands:
In a console window:
x = cut
c = copy
v = paste

In system requesters:
v = left gadget of a requester
b = right gadget of a requester

Anywhere in intuition:
these for 1.x:
n = workbench screen to front
m = workbench screen to back

these for 2.x onwards:
n = frontmost screen to back
m = workbench screen to front

when you look at your right click menu you'll see some of them listed there

And these shortcuts are accessed with the right Amiga key only.

Originally Posted by lilalurl

Add to that, in Workbench, that you can use right (IIRC) Amiga key + arrows to move the mouse cursor. Combine with some other keys (CTRL, ALT, SHIFT) for various effects (left and right click, faster cursor speed).

Either Amiga key can be held down to make the arrow keys move the mouse pointer.

Here's what the qualifiers do:
either shift = pointer moves in larger jumps if either is held down
left alt = left mouse button
right alt = right mouse button

[Jope]

Originally Posted by Mrs Beanbag

Here's one I thought of the other day... how do you get to the alternative functions on the numerical keypad? i.e. Home, Page Down, etc. instead of the numbers and symbols? Or were those things just printed on the keys without thinking it through. Because the weirdest one is Num Lock. How can you turn Num Lock off, if it has to be off in order for you to press it?

These were introduced when the A2000 came out and PC compatibility was suddenly more of an issue. So the answer is, they are there for use with bridgeboards and other PC emulators.

Even though PC emulation never became that important in the grand scheme of all things Amiga, the additional legends were kept on the keycaps for all future models.

[Jope]

Originally Posted by amiman99

I would like to see detailed documentation how everything is executed, just for my curiosity.

I'm not going to go into full details, read the Amiga guru book, the 1.2 exec disassembly by M. Wandel, and the RKM set from Commodore if you really want to know more. Some of this might be a tiny bit inaccurate, since I've stopped googling up information on other people's behalf and my memory is getting worse over the years.

The hardware remaps the ROM to start from memory address 0 when the machine boots. The very beginning of the ROM has two long words for the stack pointer and the initial program counter, which tell the CPU where to jump and start executing code.

The initial bit of code that the CPU sees after it has read the program counter address from the beginning of the ROM is the start of exec.library.

Exec.library is a bit special because it can be run directly but it can also be called as an OS library. Off it goes, initializing all the hardware registers, moving the ROM back in to its right place at the top of the 16M address space, testing for for the existence of CHIP RAM and adding it to the system memory list, adding all the modules from ROM etc.

Later on it ends up starting multitasking and after that it's go.

Now in order for exec to be able to find all the other loadable modules (libraries, resources, devices) that are baked into the ROM, there is a structure in front of each module that is called a ROMtag.

Exec reads all the ROMtags and selects the newest version of each if there are duplicates.

The ROMtag contains info about how large the module is and where is the initialization code and what is the version number.. Exec examines this, sets up the module's metadata in the OS data structures and suddenly you have graphics drivers, a floppy driver and so on.

There is no filesystem in ROM. It is just a bunch of modules that each have this special tag in front of them so that they can be distinguished from the sea of binary code.

[xArtx]

Who (the programmer or a chip) dictates where graphics are stored in memory?
It appears they are organised into blocks, so the block image transferrer can access them.
It appears they are never stored linear.
One layer of a bitmap can be between two layers of another bitmap.

Now it needs to be stored in memory, the addresses of more than one layer?

So the blit can take any block alignment out of memory it feels like?

[Leffmann]

The programmer decides. The Amiga DMA devices have no fixed locations, banks or offsets as such, so you specify addresses telling them where to get or put the data. You're limited to chip memory and a couple of small alignment requirements, but that's it.

[dJOS]

Why are Amiga dos parameters syntax so much harder to understand than ms-dos?

Maybe I'm an idiot but I've always found ms-dos programs parameters more intuitive to understand and use

Eg when you type "program name" /? or equiv to find all the options and how to use them.

[Jope]

Amiga DOS is basically a research OS called Tripos that has been ported to run under exec. Thus it is not MS-DOS nor is it UNIX.

"program name" ? gives you the usage template, which looks a bit different to what you get under MS-DOS, but nevertheless well documented in AmigaDOS literature. It is not really very difficult, only different.

Pro tip: http://archive.org/search.php?query=...iatype%3Atexts

[dJOS]

Yeah the usage template is what I was referring to - its not at all intuitive and prolly why back in the day I rarely ventured into the Amiga CLI.

[ajk]

Command lines just are not intuitive almost by definition, particularly if you have no prior experience with any of them, but AmigaDOS (just like the others) is easily picked up after a 10 minute read of the manual. Everything has its quirks. This still keeps bugging me when I need to use the Windows cmd:

C:\>cd d:
d:\

C:\>cd d:\

C:\>d:\
'd:\' is not recognized as an internal or external command, operable program or batch file.

C:\>d:

d:\>  (finally)

[dJOS]

Lol, I still haven't figured out the Amiga dos equiv of cd.. To drop back one directory level

[ajk]

cd /

[dJOS]

Bah, too frigin simple!

[Jope]

Originally Posted by dJOS

Yeah the usage template is what I was referring to - its not at all intuitive and prolly why back in the day I rarely ventured into the Amiga CLI.

I beg to differ. The /K and /S etc. tell you whether the command line option is a standalone switch, or whether it expects an argument etc.

It is just different, not difficult.

[xArtx]

Originally Posted by Leffmann

The programmer decides. The Amiga DMA devices have no fixed locations, banks or offsets as such, so you specify addresses telling them where to get or put the data. You're limited to chip memory and a couple of small alignment requirements, but that's it.

It didn't occur to me that the author could also be using a sprite sheet
(if that is the done thing with Amigas).

[Mrs Beanbag]

Originally Posted by xArtx

It didn't occur to me that the author could also be using a sprite sheet
(if that is the done thing with Amigas).

What applies to bitplanes also applies to sprites (or more usually in games, bobs), they can be anywhere in Chip RAM and don't have to be stored all in one contiguous space. I think some games use "sprite sheets", but you can store each sprite image separately if you prefer (that's what I do anyway, taking my lead from how AMOS Basic does it).

[diablothe2nd]

here's some tips on why sprite sheets are better than individual files

http://player.vimeo.com/video/44440528

its obviously a more modern take on it, but its totally relevant to amiga


and here's part 2 for those that are curious. it refers to openGL specifically but the mechanics are similar:

http://player.vimeo.com/video/55557803

[OddbOd]

Originally Posted by dJOS

Why are Amiga dos parameters syntax so much harder to understand than ms-dos?

Because the Amiga's CLI is more powerful it is by necessity a little more complicated, it's a classic trade-off. Commodore occasionally included programs written by third parties so there were inconsistencies at times. The only clear example that springs to mind is FastFonts that came with 1.3, it used the UNIX switch convention but then again the same thing happened with DOS applications e.g. PKZIP used UNIX style switches, so overall it's like Jope said, no harder just different.

@ajk: There are good reasons for the "quirks" of the Windows command-line interpreter which really have nothing to do with Windows, they're holdovers from DOS and CP/M, this is analogous to the way AmigaDOS inherited some of it's conventions from TRIPOS.

cd D:

Tells the CLI to print the current working directory of "drive" D, it is not intended to change directories to the root of D, that is done like this:

cd /d D:\

As you've already established just entering D:\ is invalid syntax, it means nothing to the CLI. Back in QDOS/86-DOS/PC-DOS there was no directory support at all, this wasn't added until MS-DOS/PC DOS 2.0 it was then that the "quirks" you describe were added because they're in fact necessary features (see here for an explanation as to why). Under Windows NT, DOS-like behaviour is all faked for backwards compatibility. For example drive letters are completely arbitrary, they're just mappings in the registry back to the real NT volumes, have a look in the registry under HKLM\SYSTEM\MountedDevices to see what I mean.

[ajk]

@OddbOd

Sure, I know it works the way it works for a reason. It was just an example of how another CLI is not necessarily any more intuitive than the AmigaDOS one