Welcome, Guest. Please login or register.

Author Topic: The Os 3.1.4 Thread  (Read 239778 times)

Description:

0 Members and 6 Guests are viewing this topic.

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #239 on: October 11, 2018, 10:32:29 PM »
Other idea... I know it this will sound "crazy" but is there any way that Amiga could detect CD-ROM without any other external drivers (considering there is a HDD/CD-ROM on one tape, 4xeide or other solution). I assume there would not be space in ROMs do to it.
The devil is in the detail. Yes, the built-in scsi.device (which speaks IDE, not SCSI) does now support ATAPI, and hence can load from CDROM. Yes, the Os-supplied CDFS is ROM-able and could therefore run from ROM if needed. I have not checked ROM space, but you should also understand that many CDROMs are actually connected to custom host-adapters, and *they* would require a modification to boot from CD as well.

So there is a link missing between the host adapter on one side, and the CDFS on the other side. For traditional file systems, this gap is filled by the RDB, which sits on the harddisk and which is required to be loaded by host adapters, then mounts the file systems and carries the boot process over.

But a standard ISO CD does not have an RDB on it that would mount a device, and could continue booting, and the standard host adapter neither looks for RDBs on optical devices. ISO images either depend on a (PC-based) boot floppy emulation, or the (PC-based) El-Torito boot mechanism, and there is no support for something like this in Amiga-land, leave alone any standard that comes close to it.

Hence, adding the CDFS to ROM does not solve the problem. It would require a modification of host adapter firmware. Given that most (if not all) vendors that made such adapters are out of business, chances are pretty slim that this would ever happen.
 

Offline kreciu

Re: The Os 3.1.4 Thread
« Reply #240 on: October 12, 2018, 03:56:25 PM »
Same here... I will use 3.1.4 on my 030 desctop, but for 060/PPC I want "updated" OS3.9 :).
Re-A1200inE/BOX/3.2/AmigaOS3.2/TF1260@66Mhz/256Mb/MediatorTX/R9200SE/SpiderUSB/LAN/SB128/16Gb-CF/DVD-ROM/FDD-HD
 

Offline mfletcher

  • Full Member
  • ***
  • Join Date: Mar 2008
  • Posts: 133
    • Show only replies by mfletcher
Re: The Os 3.1.4 Thread
« Reply #241 on: October 12, 2018, 06:57:46 PM »
I guess its too early to ask but, I bought 3.1.4 for the A1200 last night, and I was wondering if theres anyone in North America that could burn me some new roms if I supply the rom file?
 

Offline Tygre

Re: The Os 3.1.4 Thread
« Reply #242 on: October 12, 2018, 07:47:33 PM »
Hi Thomas and Olsen!

Thank you for your answers, very interesting!

The Amiga operating system and all its components matche one of the textbook definitions of legacy code: code for which no automated tests exist. It is not designed to be testable, which makes it very hard to both design effective tests and to deploy a testable version in the same context as it would be in if it were production code and not test code (ROM space is the major limitation here). The operating system source code is a mix of 'C' and assembly code, both of which provide very little leverage to achieve abstraction layers which are much more easily available in object-oriented languages.

If you are used to testing frameworks to make your life easier, you know what you are missing. I did investigate how testing of complex 'C' code is being done, and the sad result seems to be that is an unsolved problem. The testing frameworks I found which apparently catered to the need of automated 'C' code testing seemed to be not much more useful and powerful than the equivalent to planting assert() calls and the occasional printf() in the code (debugging like it's 1983), so I was none the wiser.

As far as I can tell there is no worthwhile test framework for 'C' legacy code, but I'd very much like to be proven wrong on that... So we did not use one on AmigaOS, which is why there are no use cases and no test suite to speak of.

Compatibility testing still worked very much like it did when Commodore was still in business: testing by exercising the features, discovering compatibility issues more or less by chance as well as by methodical exploration.

One exception is the new "Disk Doctor" which I wrote from scratch for Workbench 3.1.4. The code was designed to be testable, and it even includes a damage simulation feature which makes the disk access layer pretend that certain forms of data corruption or read errors exist on the medium. Automated testing involved having Disk Doctor examine and recover data from hundreds of Amiga disk images.

I don't know of a good framework to test C code either, even less so for OS and OS ROM and libraries... Could you explain in more details what you mean about "It is not designed to be testable"? Naively, I would have think that, being a set of libraries (in ROM or software), there could be tests for each and every available data structures and functions provided by these libraries, but I'm certainly missing something here... in particular, when it comes to dynamic stuff, like tasks and processes.

Could you tell us more about the features that you exercised? Do you have a set of programs that you know are "tough" on the OS and "play" with them to test the OS?

Best!

Offline x303

Re: The Os 3.1.4 Thread
« Reply #243 on: October 13, 2018, 02:12:49 PM »
It's still a shame that if you wanna get an ---electronic--- copy (download), you still need to fill in a billing address. That's holding me back from buying....   ::)
And you can't remove any product from the shopping cart (if selected wrong).
 

Offline TribbleSmasher

Re: The Os 3.1.4 Thread
« Reply #244 on: October 13, 2018, 08:44:37 PM »
Thats wrong, there is a little red X under each item.
 

Offline Jiffy

  • Sr. Member
  • ****
  • Join Date: May 2003
  • Posts: 474
    • Show only replies by Jiffy
    • http://clausewitz.nl
Re: The Os 3.1.4 Thread
« Reply #245 on: October 13, 2018, 10:12:42 PM »
I'm waiting with my purchase until physical roms are available: no means to burn the roms myself.
Life sucks. Then you die. Then they throw mud in your face. Then you get eaten by worms. Be happy it happens in that order... My Amiga 1200
 

Offline kreciu

Re: The Os 3.1.4 Thread
« Reply #246 on: October 14, 2018, 03:47:27 PM »
The same here. I will get it with new ROMs and nice box :).
Re-A1200inE/BOX/3.2/AmigaOS3.2/TF1260@66Mhz/256Mb/MediatorTX/R9200SE/SpiderUSB/LAN/SB128/16Gb-CF/DVD-ROM/FDD-HD
 

Offline NinjaCyborg

Re: The Os 3.1.4 Thread
« Reply #247 on: October 14, 2018, 08:02:23 PM »


I don't know of a good framework to test C code either, even less so for OS and OS ROM and libraries... Could you explain in more details what you mean about "It is not designed to be testable"?


He means, you can't easily do test driven development, or have test traceability, which is much easier to do with object oriented code. Plus there's nothing like selenium that could drive the UI automatically to test GUI stuff.
 

Offline Motormouth

Re: The Os 3.1.4 Thread
« Reply #248 on: October 14, 2018, 09:36:29 PM »
I have 3.1.4 compatibility questions.

First will 3.1.4 work the Fusion Forty board?
This was a great 040 board for OS 1.3 and the A2000, and if I remember correctly the first 040 board.

As a result the FF40 has odd 68040 FPU support in its 68040.library (very non standard verses boards release after A3640 and OS 2.0 came out)
Also the original FF40 did not work with AmigaOS 2.0+ roms, the FF40 needed to be updated to plug n' go 3.4 roms.

So will 3.1.4 work with an updated FF40 board, and will it work with its, FF40, 68040.library?

Second will 3.1.4 work with with the ACA500 or ACA500+ as both have their own "scsi.device"?

Lastly, will 3.1.4 work with the sonnet amiga project?  My initial guess is that it would.  My concern would be will mmu support changes vs 3.1

I love the fact that the vampire already has support for 3.1.4.  It is nice to see the community working together on this. ;D
 


 

Offline Tygre

Re: The Os 3.1.4 Thread
« Reply #249 on: October 15, 2018, 12:44:20 AM »


I don't know of a good framework to test C code either, even less so for OS and OS ROM and libraries... Could you explain in more details what you mean about "It is not designed to be testable"?


He means, you can't easily do test driven development, or have test traceability, which is much easier to do with object oriented code. Plus there's nothing like selenium that could drive the UI automatically to test GUI stuff.

Traceability between functions and tests is of course possible, not more easier/difficult with C than with Java... it all boils down to the code and the framework(s) (if any). So, thanks but I would prefer a direct answer ;)

Best,

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #250 on: October 15, 2018, 01:22:33 AM »
First will 3.1.4 work the Fusion Forty board?
If it worked with 3.1, it is highly likely that it will work with 3.1.4 because there is no substantial change.

As a result the FF40 has odd 68040 FPU support in its 68040.library (very non standard verses boards release after A3640 and OS 2.0 came out)
Also the original FF40 did not work with AmigaOS 2.0+ roms, the FF40 needed to be updated to plug n' go 3.4 roms.

So will 3.1.4 work with an updated FF40 board, and will it work with its, FF40, 68040.library?
There is no 68040.library coming with 3.1.4, so if the FF040 library works with 3.1, there is no reason why it should not also work with 3.1.4.


Second will 3.1.4 work with with the ACA500 or ACA500+ as both have their own "scsi.device"?
See above. The scsi.device was always in ROM, even for the A500, and that did not change in 3.1.4. I see no reason why this would break.


Lastly, will 3.1.4 work with the sonnet amiga project?  My initial guess is that it would.  My concern would be will mmu support changes vs 3.1
There are no changes with respect to the MMU. Actually, the Os does not make use of it. It is part of the CPU library to put it to use, but the CPU library is board specific.
 
The following users thanked this post: Motormouth

Offline 10MARC

Re: The Os 3.1.4 Thread
« Reply #251 on: October 15, 2018, 04:30:00 AM »
I just put up a video with a overview/installation guide/troubleshooting guide for Amiga OS 3.1.4 and the associated "Best Workbench 1.0" - Maybe it will help some people.

I had some issues with the warpdrive.device SCSI controller that I was able to overcome thanks to some help from Thomas Richter on one issue, and good old fashioned trial and error on other issues.

https://youtu.be/Bo3j-fknCQs
 

Offline nicholas

Re: The Os 3.1.4 Thread
« Reply #252 on: October 15, 2018, 12:48:59 PM »
It's still a shame that if you wanna get an ---electronic--- copy (download), you still need to fill in a billing address. That's holding me back from buying....   ::)
And you can't remove any product from the shopping cart (if selected wrong).

I didn't have to provide my billing address. Just name, email address and country of residence.
“Een rezhim-i eshghalgar-i Quds bayad az sahneh-i ruzgar mahv shaved.” - Imam Ayatollah Sayyed  Ruhollah Khomeini
 

Offline olsen

Re: The Os 3.1.4 Thread
« Reply #253 on: October 15, 2018, 05:12:18 PM »
Hi Thomas and Olsen!

Thank you for your answers, very interesting!

...

I don't know of a good framework to test C code either, even less so for OS and OS ROM and libraries... Could you explain in more details what you mean about "It is not designed to be testable"? Naively, I would have think that, being a set of libraries (in ROM or software), there could be tests for each and every available data structures and functions provided by these libraries, but I'm certainly missing something here... in particular, when it comes to dynamic stuff, like tasks and processes.

What is missing in the operating system in general is even the most humble unit test which more complex tests could build upon.

From how I understand the rationale for implementing tests (as described in great detail in Michael Feathers' book "Working effectively with legacy code"), the tests are to assist in making code changes more robust, if not allowing them to be made in the first place. Code which is more easily changed is also likely to be more easily changed for the better: reduced complexity, fewer side-effects, better understanding of its design and relationships within the context it is a part of.

There is nothing there which one could build upon. You would have to start from scratch and construct the unit tests as well as build test harnesses. The Amiga operating system is comparatively small but it is by no means simple. Adding the scaffolding for building a testable operating system out of what we have is a major challenge.

The "modern" testing approach which grew out of the use of object oriented implementation languages was not available to the designers of the Amiga operating system. This is why testing began from the outside in, by testing how software of particular interest/import interacted with the operating system, and by analyzing the behaviour triggered by the changes which were introduced. It might have been the industry standard in the 1980'ies and the 1990'ies.

What methods I applied under such circumstances (only 'C' and assembly language used as implementation languages) came from the books I read on this matter: "Writing solid code" (Steve Maguire), "Code complete" (Steve McConnell) and "Clean code" (Bob Martin). Unit testing is part of this toolbox, but it's much easier to write new code to follow the principles described in the books than to make legacy code conform to them after the fact. The new Disk Doctor was written from the ground up and this is why I could design it to be testable, and to apply the best practices I learned from these three books (as well as I was able).

Quote
Could you tell us more about the features that you exercised? Do you have a set of programs that you know are "tough" on the OS and "play" with them to test the OS?

As far as I know "empirical testing" was used to as large a degree as was possible. You install the new software then try to use the programs you are familiar with. If necessary, unwelcome changes in behaviour are then documented and this goes into the bug tracker. Then it's the old reproduce, analyze, fix, retest loop. There was no shortage of known operating system bugs which went through the same loop without having to start out as a bug tracker ticket. In short, the whole process used the methods available at the time when the Amiga operating system was designed and still being maintained in the years 1985-1994.

With the new Disk Doctor things were a bit different, and only because I had the luxury to start from scratch. The central data structure which the new Disk Doctor uses to keep track of what type of information it finds in a block on the medium had to be both very memory-efficient and still fast enough to work on a plain 68000 machine. To this end I designed and implemented a sparse bit array, with unit tests and a test harness. This was tested separately before I integrated it into the Disk Doctor code. Testing the new Disk Doctor both involved old school "empirical testing" and building a test set of some 450 ADF images which were then fed into the new Disk Doctor through a script file. This test exercised the entire program, including its in-memory database, the memory management, and the diagnostic as well as the data recovery functions.
 
The following users thanked this post: Tygre

Offline x303

Re: The Os 3.1.4 Thread
« Reply #254 from previous page: October 15, 2018, 08:36:25 PM »
I didn't have to provide my billing address. Just name, email address and country of residence.

When I wanna buy w/ paypal or iDeal I do have to fill in the billing address.