6 ms·

AmigaOS 3.1.4 released

60 points by erickhill 8y ago

snvzz 8y ago
Already bought and tried in an emulator. I find it annoying the rom doesn't include workbench.library, and the provided one in LIBS: isn't romable. It'd only be proper to provide a 1MB rom image with it, or a limited functionality version.
- obarthel 8y ago
  ROM space is very tight for this release on account of the much larger mass storage drivers (SCSI, IDE) and the integrated OCS/ECS/AGA graphics.library. Commodore was already pushing the limits for the 1994 Kickstart 3.1 in the Amiga 1200 ROM, and it only got worse. The Amiga 4000T ROM would no longer contain workbench.library either (in 1994) because the graphics.library and the SCSI driver took up so much room. There is no room for workbench.library and icon.library in the 512 KB 3.1.4 ROM. Going back to a previous set of workbench.library/icon.library versions is not an option because these do not fit either. 1 MB ROMs are not viable solution at this point. Only a select few models support these, and the point was to make the 3.1.4 update available to all desktop systems. Besides, a 1 MB ROM would require retooling of the build process for the operating system, which we did not attempt. The last 1 MB ROMs were built in 1994 (for the CD32) and very little documentation survives on how this is done, and how the ROM images need to be prepared. We were already quite busy with the desktop systems and chose not to spend the time on research and QA work necessary for the 1 MB ROM build.
  - snvzz 8y ago
    >There is no room for workbench.library and icon.library in the 512 KB 3.1.4 ROM. Unfortunately. Understandable. >Only a select few models support these, and the point was to make the 3.1.4 update available to all desktop systems. Nobody is telling you to ditch the 512k rom. It's just it sucks not to have workbench.library and icon.library, when using a system that does maprom with 1mb support. >The Amiga 4000T ROM would no longer contain workbench.library either (in 1994) because the graphics.library and the SCSI driver took up so much room. And roms with workbench inside were proudly released recently. Meaning both there's interest, and that you understand this interest. >We were already quite busy with the desktop systems and chose not to spend the time on research and QA work necessary for the 1 MB ROM build. It's good if there was at least consideration. Maybe try and release romable versions of workbench and icon library? The community will take over from there, with tools.
    - obarthel 8y ago
      > Nobody is telling you to ditch the 512k rom. It's just it sucks not to have workbench.library and icon.library, when using a system that does maprom with 1mb support. The next best thing is to load both the workbench.library and icon.library using the LoadModule command (which is part of the AmigaOS 3.1.4 update, if I remember correctly) and reboot your machine. Both libraries will then remain in memory as if they had been in the ROM. They will survive subsequent warm reboots, but they will consume RAM. Loading the libraries in this manner can be handled by the Startup-Sequence, for example. > Maybe try and release romable versions of workbench and icon library? Both libraries are technically "fit" to go into ROM, if there were enough space available for them to fit ;-) They are "romable".
      - snvzz 8y ago
        >They will survive subsequent warm reboots, but they will consume RAM. As long as it's fast ram, it's pretty good for a next best thing. I wasn't aware. >Both libraries are technically "fit" to go into ROM, if there were enough space available for them to fit ;-) They are "romable". That's great news. I'm not sure where I heard they weren't. I'm hopeful tools to do that will pop up on Aminet :)
        obarthel 8y ago
        > As long as it's fast ram, it's pretty good for a next best thing. I wasn't aware. The ROM changes which shipped with the AmigaOS 3.5/3.9 updates all exercised the same mechanism by which operating system modules loaded into RAM whose contents would survive a warm reset would supersede the contents of the ROM image. If I remember correctly, the same tool (LoadModule) had been used then. Documentation for these technical aspects has always been somewhat lacking I'm afraid... Not everyone wants to trawl the Amiga forums for hints on what is possible and how. This time, however, there is an official FAQ on the web site of the company which sells the product and further pointers to more information on Amiga forums which cover the AmigaOS 3.1.4 update. > That's great news. I'm not sure where I heard they weren't. I'm hopeful tools to do that will pop up on Aminet :) You might want to have a look at Christian Vogelgsang's https://github.com/cnvogelg/amitools https://github.com/cnvogelg/amitools collection.
deleted 8y ago
[deleted]
rbanffy 8y ago
How is it delivered? How would I install it on my 500 or 600?
- garethsaxby 8y ago
  At present if you get the direct download you have to write to an EPROM, install into your AMIGA and then write out and use the Kickstart floppy. Actually having the kit to do the programming, the correct EPROM chips and doing it right is a little more involved, from what I've read; I haven't touched an Amiga in some time myself. The news post on Hyperion's website states that you'll be able to buy ROMs and floppy disks that have already had the updated code written to them "shortly".
- snvzz 8y ago
  There's going to be a physical version at some point, but summary: 1. Buy A500/A600 download version, or A1200 if you've got a Vampire accelboard. 2. Get adf into Amiga floppies by whatever means (serial cable, pcmcia nic adapter, flashfloppy-enabled floppy drive emulator) 3. Boot workbench disk or installer disk. ROM patches will be loaded by loadmodule @ startup-sequence. 4. (Optional) Flash into (E/EE)PROM chip or (more sane) into A500Flash1M or similar such rom switcher solution with a flashrom in it. Note you'll want at least 2MB RAM total for this, at least 1MB of which being CHIP RAM. If you don't have this much, don't even bother.
  - Annatar 8y ago
    And where could one get a compatible ROM flasher and WORM chips?
    - gbin 8y ago
      If you are looking for an affordable solution you can use this: https://gglabs.us/node/2038 https://gglabs.us/node/2038
Annatar 8y ago
"Remember "Diskdoctor"? It earned its PhD and is now ready to reliably rescue data from your floppies or hard disks." Remember the cool old "AGA - time to upgrade - AGA" slogan in some of the demos? Now it's ZFS - time to upgrade - ZFS ...it's the 21st century, and AmigaOS doesn't even have software RAID, let alone ZFS yet. We still have to check filesystems for metadata corruption, and checking them for data corruption is still science fiction. And nobody bats an eyelash, like it's the most normal thing in the world. Meanwhile, the capacitors are leaking like crazy, modern PC-bucket power supplies don't deliver steady 5V, the clock crystal loses or gains up to 5 seconds per day, even the newest accelerator hardware doesn't support ECC memory... what could possibly go wrong with one's data?
- snvzz 8y ago
  You could use OFS (Original File System, before FFS) which has checksums in every block! Note blocks are <512byte because of that (ouch) and everything else about OFS sucks.
  - Annatar 8y ago
    I could, but then I have to ditch all the FFS features. I mean the whole thing that they're still mucking around with filesystem checks is nonsense. That was the thing of the past even way back in 2001 on SGI IRIX 6.5 with XFS, and we're still doing this. Can't even do a software RAID 1+0.
  - obarthel 8y ago
    Smaller than 512 bytes? I beg to differ. The file system data structure layout requires a minimum of 512 bytes per block. The Amiga OFS/FFS, etc. file system data structures scale with the block size (block sizes of 512, 1024, .., 65536 bytes are possible). At 256 bytes per block, for example, the directory hash table size would shrink so much that you'd have so many hash collisions that it would be morbidly funny... Anyway, the data blocks in OFS have to account for the checksum and some metadata which aids in recovery. So you are correct that the payload (488 bytes for a 512 byte block) is smaller than the raw block size.
zmix 8y ago
Why 3.1.4 and not 3.9.1 ?
- obarthel 8y ago
  The AmigaOS 3.9 code was largely unavailable for development work. What remained and was availabie is material which was licensed for inclusion in AmigaOS4. What we got here is a mix of the AmigaOS 3.1 code (bug fixes galore, plus enhancements), the 3.5 update, the 3.9 update plus completely new software such as Disk Doctor V2.134 (written from scratch to support large storage devices and all Amiga file system flavours descended from the 1986 default file system; this is not your father's Disk Doctor any more). The other reason why it's 3.1.4 is that we realized early on that we could not continue development of the 3.x line anyway, so we joked it would have to be an irrational version number instead, perhaps one digit at a time.
  - WorldMaker 8y ago
    Good old "PiVer", the TeX approach to versioning: https://en.wikipedia.org/wiki/Software_versioning#TeX https://en.wikipedia.org/wiki/Software_versioning#TeX
  - zmix 8y ago
    Thanks for clarification. And thanks for Term and MagicMenu (and all the other work) ! :)

60 points by erickhill 8y ago

Already bought and tried in an emulator. I find it annoying the rom doesn't include workbench.library, and the provided one in LIBS: isn't romable. It'd only be proper to provide a 1MB rom image with it, or a limited functionality version.

obarthel 8y ago
ROM space is very tight for this release on account of the much larger mass storage drivers (SCSI, IDE) and the integrated OCS/ECS/AGA graphics.library. Commodore was already pushing the limits for the 1994 Kickstart 3.1 in the Amiga 1200 ROM, and it only got worse. The Amiga 4000T ROM would no longer contain workbench.library either (in 1994) because the graphics.library and the SCSI driver took up so much room. There is no room for workbench.library and icon.library in the 512 KB 3.1.4 ROM. Going back to a previous set of workbench.library/icon.library versions is not an option because these do not fit either. 1 MB ROMs are not viable solution at this point. Only a select few models support these, and the point was to make the 3.1.4 update available to all desktop systems. Besides, a 1 MB ROM would require retooling of the build process for the operating system, which we did not attempt. The last 1 MB ROMs were built in 1994 (for the CD32) and very little documentation survives on how this is done, and how the ROM images need to be prepared. We were already quite busy with the desktop systems and chose not to spend the time on research and QA work necessary for the 1 MB ROM build.
- snvzz 8y ago
  >There is no room for workbench.library and icon.library in the 512 KB 3.1.4 ROM. Unfortunately. Understandable. >Only a select few models support these, and the point was to make the 3.1.4 update available to all desktop systems. Nobody is telling you to ditch the 512k rom. It's just it sucks not to have workbench.library and icon.library, when using a system that does maprom with 1mb support. >The Amiga 4000T ROM would no longer contain workbench.library either (in 1994) because the graphics.library and the SCSI driver took up so much room. And roms with workbench inside were proudly released recently. Meaning both there's interest, and that you understand this interest. >We were already quite busy with the desktop systems and chose not to spend the time on research and QA work necessary for the 1 MB ROM build. It's good if there was at least consideration. Maybe try and release romable versions of workbench and icon library? The community will take over from there, with tools.
  - obarthel 8y ago
    > Nobody is telling you to ditch the 512k rom. It's just it sucks not to have workbench.library and icon.library, when using a system that does maprom with 1mb support. The next best thing is to load both the workbench.library and icon.library using the LoadModule command (which is part of the AmigaOS 3.1.4 update, if I remember correctly) and reboot your machine. Both libraries will then remain in memory as if they had been in the ROM. They will survive subsequent warm reboots, but they will consume RAM. Loading the libraries in this manner can be handled by the Startup-Sequence, for example. > Maybe try and release romable versions of workbench and icon library? Both libraries are technically "fit" to go into ROM, if there were enough space available for them to fit ;-) They are "romable".
    - snvzz 8y ago
      >They will survive subsequent warm reboots, but they will consume RAM. As long as it's fast ram, it's pretty good for a next best thing. I wasn't aware. >Both libraries are technically "fit" to go into ROM, if there were enough space available for them to fit ;-) They are "romable". That's great news. I'm not sure where I heard they weren't. I'm hopeful tools to do that will pop up on Aminet :)
      - obarthel 8y ago
        > As long as it's fast ram, it's pretty good for a next best thing. I wasn't aware. The ROM changes which shipped with the AmigaOS 3.5/3.9 updates all exercised the same mechanism by which operating system modules loaded into RAM whose contents would survive a warm reset would supersede the contents of the ROM image. If I remember correctly, the same tool (LoadModule) had been used then. Documentation for these technical aspects has always been somewhat lacking I'm afraid... Not everyone wants to trawl the Amiga forums for hints on what is possible and how. This time, however, there is an official FAQ on the web site of the company which sells the product and further pointers to more information on Amiga forums which cover the AmigaOS 3.1.4 update. > That's great news. I'm not sure where I heard they weren't. I'm hopeful tools to do that will pop up on Aminet :) You might want to have a look at Christian Vogelgsang's https://github.com/cnvogelg/amitools https://github.com/cnvogelg/amitools collection.

deleted 8y ago

[deleted]

rbanffy 8y ago

How is it delivered? How would I install it on my 500 or 600?

garethsaxby 8y ago
At present if you get the direct download you have to write to an EPROM, install into your AMIGA and then write out and use the Kickstart floppy. Actually having the kit to do the programming, the correct EPROM chips and doing it right is a little more involved, from what I've read; I haven't touched an Amiga in some time myself. The news post on Hyperion's website states that you'll be able to buy ROMs and floppy disks that have already had the updated code written to them "shortly".
snvzz 8y ago
There's going to be a physical version at some point, but summary: 1. Buy A500/A600 download version, or A1200 if you've got a Vampire accelboard. 2. Get adf into Amiga floppies by whatever means (serial cable, pcmcia nic adapter, flashfloppy-enabled floppy drive emulator) 3. Boot workbench disk or installer disk. ROM patches will be loaded by loadmodule @ startup-sequence. 4. (Optional) Flash into (E/EE)PROM chip or (more sane) into A500Flash1M or similar such rom switcher solution with a flashrom in it. Note you'll want at least 2MB RAM total for this, at least 1MB of which being CHIP RAM. If you don't have this much, don't even bother.
- Annatar 8y ago
  And where could one get a compatible ROM flasher and WORM chips?
  - gbin 8y ago
    If you are looking for an affordable solution you can use this: https://gglabs.us/node/2038 https://gglabs.us/node/2038

Annatar 8y ago

"Remember "Diskdoctor"? It earned its PhD and is now ready to reliably rescue data from your floppies or hard disks." Remember the cool old "AGA - time to upgrade - AGA" slogan in some of the demos? Now it's ZFS - time to upgrade - ZFS ...it's the 21st century, and AmigaOS doesn't even have software RAID, let alone ZFS yet. We still have to check filesystems for metadata corruption, and checking them for data corruption is still science fiction. And nobody bats an eyelash, like it's the most normal thing in the world. Meanwhile, the capacitors are leaking like crazy, modern PC-bucket power supplies don't deliver steady 5V, the clock crystal loses or gains up to 5 seconds per day, even the newest accelerator hardware doesn't support ECC memory... what could possibly go wrong with one's data?

snvzz 8y ago
You could use OFS (Original File System, before FFS) which has checksums in every block! Note blocks are <512byte because of that (ouch) and everything else about OFS sucks.
- Annatar 8y ago
  I could, but then I have to ditch all the FFS features. I mean the whole thing that they're still mucking around with filesystem checks is nonsense. That was the thing of the past even way back in 2001 on SGI IRIX 6.5 with XFS, and we're still doing this. Can't even do a software RAID 1+0.
- obarthel 8y ago
  Smaller than 512 bytes? I beg to differ. The file system data structure layout requires a minimum of 512 bytes per block. The Amiga OFS/FFS, etc. file system data structures scale with the block size (block sizes of 512, 1024, .., 65536 bytes are possible). At 256 bytes per block, for example, the directory hash table size would shrink so much that you'd have so many hash collisions that it would be morbidly funny... Anyway, the data blocks in OFS have to account for the checksum and some metadata which aids in recovery. So you are correct that the payload (488 bytes for a 512 byte block) is smaller than the raw block size.

zmix 8y ago

Why 3.1.4 and not 3.9.1 ?

obarthel 8y ago
The AmigaOS 3.9 code was largely unavailable for development work. What remained and was availabie is material which was licensed for inclusion in AmigaOS4. What we got here is a mix of the AmigaOS 3.1 code (bug fixes galore, plus enhancements), the 3.5 update, the 3.9 update plus completely new software such as Disk Doctor V2.134 (written from scratch to support large storage devices and all Amiga file system flavours descended from the 1986 default file system; this is not your father's Disk Doctor any more). The other reason why it's 3.1.4 is that we realized early on that we could not continue development of the 3.x line anyway, so we joked it would have to be an irrational version number instead, perhaps one digit at a time.
- WorldMaker 8y ago
  Good old "PiVer", the TeX approach to versioning: https://en.wikipedia.org/wiki/Software_versioning#TeX https://en.wikipedia.org/wiki/Software_versioning#TeX
- zmix 8y ago
  Thanks for clarification. And thanks for Term and MagicMenu (and all the other work) ! :)