After installing Amibian on the Raspberry Pi, I wanted to go forward and try a hard disk install.
I'm using the folders on the memory stick as hard drives. This has the downside that certain characters in filenames are not accepted. ("español")
But I can throw in files directly and even through ethernet, so I can ditch the idea of translating files from/to adf images. And although the memory stick isn't especially fast, it is still fairly rapid as an Amiga hard disk.
Some Workbench re-learning was in order. Firstly I remove the visually throttling main window, by checking "Backdrop" from the Workbench menu.
Instead of dragging an icon to the desk (which looks ok but is non-permanent) the icons have to be treated with "Leave Out" from the Icons menu, which doesn't sound that intuitive.
For the cheap TV, I adjusted Workbench to fit a 640x240 resolution instead of 640x256. Strangely, although the panel should be 768-high, implying a 256-high Amiga screen with no interference pattern, I can only have 240 with no interference. Well, enough of that TV. Many programs play nice with this Workbench setting.
Directory Opus is a great help in arranging folders, moving files and creating icons for software.
|I've probably looked at this and CLI more than the actual Workbench|
Yes, every file needs that .info file in order to be visible in the WB environment. Folders (drawers, directories) can also display the "real" files as a list.
I was pleased to see that media files can launch apps, for example IFF images saved in Dpaint will again open in DPaint by clicking their icons.
But it's not possible to globally link file extensions to particular applications. Also, Dpaint doesn't seem to remember the folder from which the file was loaded from.
|We reached peak Deluxe Paint in 1988|
The un-wisdom of constantly rewriting on an USB stick is not lost on me, and I intend to make enough backups in case it eventually breaks. It also helps to have multiple images if the Workbench setup becomes broken. Fortunately, by today's standards an entire Amiga hard drive install with software is not very huge.
As the ethernet is connected and running, I can use the scp command to transfer files over to the Raspberry filesystem, to /media/usb0/System/ or how ever it might be represented there. It's useful to share the ssh keys between the computers before this, so the transfers don't get bogged down by permission requirements.
Default login and password for Amibian is root/1234. Scp is also a good way to make the drive backups.
Copying over ssh can be done even when the emulation is on, but I have tried to avoid doing this, especially on the System drive. The Workbench/AmigaDOS probably doesn't do a lot actively but it's better to be safe than sorry. Maybe a completely separate "hard disk" should be set up for the file transfers.
This was annoying and slowed the boot just a tiny amount.
After some Googling I found out the error message emerges from a step in startup-sequence that launches iPrefs. The thing is, if there is text output before the iPrefs it will produce this alert. This may be one reason why all the startup-sequence commands have their output to >NIL:
Looking at the boot more closely it was easy to see the error messages in the vein of "Monitors/PAL.info.uaem: file is not executable"
The .uaem files are not part of the Amiga system, but are generated by the UAE (The U#? Amiga Emulator) These files begin to crowd the file system and this experience shows they can actually cause some harm!
The Amibian likely doesn't produce them, but as I built the install using UAE on Linux they probably came out from that.
So in UAE a file might not only have an .info, but both the file and the .info will have an .uaem too. To represent one item there might be four files which is ridiculous.
Removing the .uaem files from devs:Monitors/ removed the error message.
Modern or not
Time has passed and a lot of desktop conventions have become widely accepted. I was seeking a balance between the "original Amiga experience" and looking for some modest ways to update it.
Back in the day only few of the most used apps were placed as icons on the desktop. I now felt compelled to put as many apps as desktop icons as possible. Furthermore, I put them in a neat line at the bottom of the screen, like the icon strip in Mac OS and others.
...which is strange as I don't use an app launcher in Linux either, but it does have that handy menu.
While I wouldn't want any additional launcher to clutter the WB experience (a few must exist), at least this could be done.
Workbench Storage disk should have storage/keymaps with different country keymap files. These are then copied to devs:keymaps. After this the desired keymap can be selected in prefs/input.
The Swedish keymap was only a partial solution and I especially kept missing the [ ] characters which are in a silly place to begin with in that keymap. So I have persisted with the "wrong" US keymap.
Although the Blackstorm keyboard I've used is a nice counterpart to the black box and TV, it doesn't have function keys or a numeric keypad.
Even if I had all the keys in correct places, it's not all going to be like 2021.
One widespread agreement is now that Control-C is Copy, Control-X is Cut, Control-V is Paste and Control-Z is undo. Old Amiga software is inconsistent about what keyboard shortcuts to use. And whether to use Control-key or the Amiga-key as the base? How universal is the clipboard?
The shortcuts are likely partly inspired by Unix and partly an own convention. There are mixtures, like the menu item saying "Save" but the shortcut is Amiga+W(for Write).
Even if some programs allow adjusting shortcut keys, it might not work 100%. In AMOSPro editor I could change them but Control-C was out of bounds as it is the "break" key.
While I feel for "u key as undo" (as in Deluxe Paint) I have to agree having undo together with C/X/V cluster makes sense.
A minor grievance is that text generally cannot be marked with a single drag, but has to be double-clicked at first. The Amiga Shell (CLI) actually has a more modern single drag "paint selection" but the other programs haven't all caught on.
You use Right Amiga+C and V to copy/paste in Workbench. It does work across software, but apparently not in smaller text entry boxes.
Mouse wheels were not really a thing in Amiga's heyday, but now I feel it is indispensable. There's a software called FreeWheel that enables the wheel in Workbench applications, but sadly I only got it working in UAE on Linux, not on Amibian. Possibly the Amibian mouse routines are very minimal.
I actually now like the ubiquitous Amiga top-down, pull-down menus. Nowadays operating systems try to abolish menus, or offer different ways to present the same idea. The rigid pull-down menus don't work that well on touch screens.
I actually enjoyed, at least up to a point, the need of manual tweaking here and there, having to move and confirm window and icon positions by hand.