Welcome, Guest. Please login or register.

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

Description:

0 Members and 2 Guests are viewing this topic.

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #59 on: September 27, 2018, 05:35:55 PM »
Different topic. Pardon me is this has been mentioned here or on eab, but it's related in the sense of "sources".
Has a new icon editor been developed, or is the intent to use iconedit as it stands?
Neither - nor. We did simply not have the capacity to develop a new one from scratch, nor did we have the sources of the 3.9 one, nor reaction available. So, what happened in the end is what happened with many components: We took what we had (the v40 version) and fixed as many bugs as we could find. Which were also a number, such obvious ones as forgetting a WaitBlit() such that the editor rendered nonsense, broken picture import functions, incorrect handling of rtg screens and a couple of others I would need to look up in the release notes.

This is pretty much the theme of 3.1.4: It looks very much like 3.1 looked, but we tried however our best to iron out all bugs we could find. There are only very few components we did not touch - some of the shell commands did not require a change. Probably the half of them has been updated to support the new features such as working softlinks or long file names.

The problem is: If you have so few active developers, and only partial access to sources, it already takes a long time to review all of the Os. In this case, almost three years, "all in".
 

Offline number6

Re: The Os 3.1.4 Thread
« Reply #60 on: September 27, 2018, 05:57:12 PM »
Different topic. Pardon me is this has been mentioned here or on eab, but it's related in the sense of "sources".
Has a new icon editor been developed, or is the intent to use iconedit as it stands?
Neither - nor. We did simply not have the capacity to develop a new one from scratch, nor did we have the sources of the 3.9 one, nor reaction available. So, what happened in the end is what happened with many components: We took what we had (the v40 version) and fixed as many bugs as we could find. Which were also a number, such obvious ones as forgetting a WaitBlit() such that the editor rendered nonsense, broken picture import functions, incorrect handling of rtg screens and a couple of others I would need to look up in the release notes.

This is pretty much the theme of 3.1.4: It looks very much like 3.1 looked, but we tried however our best to iron out all bugs we could find. There are only very few components we did not touch - some of the shell commands did not require a change. Probably the half of them has been updated to support the new features such as working softlinks or long file names.

The problem is: If you have so few active developers, and only partial access to sources, it already takes a long time to review all of the Os. In this case, almost three years, "all in".

I'm aware of the lack of sources there (iconedit), but it was a good idea to state that for those who were not aware.
I understand fully from what you and Olaf have written what the 1st step is, and that future enhancements depend upon success with this version. (repeating that so you don't get any new feature requests. heh.)
As far as "problem is", that's also something I don't think we should dwell on, since it only distracts from your sincere desire to help.
Thank you both for all of your hard work over the years.

#6
 

Offline Romanujan

  • Newbie
  • *
  • Join Date: Aug 2010
  • Posts: 37
    • Show only replies by Romanujan
Re: The Os 3.1.4 Thread
« Reply #61 on: September 27, 2018, 07:47:07 PM »
And what is the situation with picture.datatype? AFAIK the OS 3.9 version has one unique important feature: it's a fat binary (m68k + PPC).
 

Offline Gulliver

Re: The Os 3.1.4 Thread
« Reply #62 on: September 27, 2018, 09:47:05 PM »
And what is the situation with picture.datatype? AFAIK the OS 3.9 version has one unique important feature: it's a fat binary (m68k + PPC).

This new picture.datatype is faster, has less bugs and will now work with 68000 processors (the one from 3.9 required a 68020).
The PPC code is no longer there, which makes it much smaller and less bloated.

If you have PPC hardware, if it is compatible, you can always get OS4.
 

Offline SnkBitten

  • Full Member
  • ***
  • Join Date: Feb 2016
  • Posts: 113
  • Country: us
  • Gender: Male
  • Amithlon Fanatic
    • Show only replies by SnkBitten
    • http://amithlon.snkbitten.com
Re: The Os 3.1.4 Thread
« Reply #63 on: September 27, 2018, 11:49:19 PM »
Totally out of normal consideration, but any idea how OS 3.1.4 would function running on Amithlon?   I have a standard 3.1 Kickstart and 3.1 WB partition setup that boots perfectly fine so I'm curious how well this updated version would function.  I setup the 3.1 bootable environment to test since Bernie had initially shown Amithlon on 3.1 before he was provided 3.9.

The general question would probably fall more under how well does OS 3.1.4 function with RTG, AHI, etc.. as those are Amithlon requirements.   I'd love to update the 3.1 environment to 3.1.4 under Amithlon and see how it runs since 3.1 is already a lighter resource hungry than 3.9.

I'm a huge Amithlon fan....so had to throw that question out there....:)

 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #64 on: September 28, 2018, 06:46:15 AM »
Totally out of normal consideration, but any idea how OS 3.1.4 would function running on Amithlon?

Frankly, we haven't tested as our main concern were the classic machines (A500 through A4000T). But if 3.1 runs without problems, chances are better than even that 3.1.4 will run as well.
 

Offline olsen

Re: The Os 3.1.4 Thread
« Reply #65 on: September 28, 2018, 07:17:32 AM »
Right. I'm aware of that and obviously am aware of the code ownership restraints. You are to be commended for finding workarounds.

I only mentioned/linked to detlef because at that time we seem to have encountered similar issues to what you are discussing...lack of sources, working with a binary only, issues with prefs, etc. I just happen to see a lot of parallels in the struggle.
I thought perhaps if all of detlef's postings from that era were examined, you might find something helpful, or perhaps an issue not considered yet.

#6

Personally, I feel uncomfortable to "mine" the work of other developers for clues instead of asking them directly, if they are still around and are inclined to go over their past work, offering insights. Ten, twenty or more years down the line it does become difficult to remember the rationale for design and implementation decisions made, though.

Old code tends to make you make the worst assumptions about the motivations and especially the ability of the original developer and designer (exceptions exist, though: I still find Exec to be exceptionally slick code, for example, and just to mention it, the Amiga platform-specific code of the Amiga Unix kernel). You're almost always biased, and it takes an effort to dial back how harshly you are bound to judge what you will see. Well, you are looking for bugs after all, and compatibility/portability issues, too. But you cannot conveniently infer the reason behind the design and implementation. What works for me is to remind myself constantly that the guys who wrote this weren't "stupid", it's just that I don't know enough about the code yet: I'm the one who's stupid right now.

The code does not always provide answers, and given its age, the only way forward often is to go back to the specifications for which it was built, e.g. the ROM kernel reference manuals, schematics, etc., and do your homework ;) If you are lucky, you can talk to other developers who have been around a long time and who can provide context. We have been very lucky in this respect (and here's hoping dearly that our luck will not run out any time soon).

That said, nothing beats reading the code and testing how it works and interacts. This is what takes so much time, especially in such a small team. The printer.device is one such case. We lacked the source code to the device as used in the OS 3.5/3.9 updates, so for the OS4 work I "ported" the V39 code to build cleanly and portably under SAS/C, then moved it to the PPC platform. Detlef Würkner's work would subsequently build upon it.

The cleanest way to start over for the 3.1.4 update seemed to be to take the SAS/C port I had prepared and take it from there. Sure enough, this was 10-15 year old code which had not been reviewed since. There was trouble in every corner. Thomas reviewed the printer.device, tested, updated and rewrote it, filling in the gaps in the implementation to allow for OS 3.5/3.9 driver and prefs compatibility. Then it turned out that the HP printer drivers which were added in the OS 3.5/3.9 update were just as lacking as the printer.device and had to be reviewed, tested and updated. This was pretty scary :(

I'm still floored by what Thomas accomplished. At the back of my mind I still do wonder if printer.device deserved that much love, though. It's an interface for transforming bitmap imagery and for producing text output on mechanical devices which, unless you exclude the generic PostScript and HP-PCL printer drivers, are now so old that they are no longer being manufactured. Still, this is probably part of the package if you are going to update an operating system and its components which was last updated at this scale some 24 years ago. Funny thing: the reconstruction of Babbage's Analytical Engine includes a print output device (as part of the original design), so who am I to argue ;)
« Last Edit: September 28, 2018, 08:23:09 AM by olsen »
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #66 on: September 28, 2018, 07:40:07 AM »
Let me second what Olaf wrote:

I do not want anyone to misread my comments on printer as the author's being stupid. Not at all. But one important piece in the puzzle was missing, namely: Testing! The interim code we had failed for:

a) Legacy code, and legacy design. It was built upon an ad-hoc design built around ad-hoc compiler interfaces (such as, stack-based arguments) from technology that died already 20 years ago. No matter how smart you are, such things are going to bite you. Once code starts to grow iteratively ("organically grown code"), when feature piles upon feature, you soon arive at a state where it becomes almost impossible to manage. Add a couple of bad design decisions, and you have the receipt for failure.

b) Testing! The problem with the printer device was not only that it was legacy code, it was also not tested to the degree necessary. This being said, I'm not fully in line that the printer is my accomplishment. It is to a major degree the result of our beta test group that continued to file bug after bug. In the end, I do not remember how many we had for the printer and the HP drivers.

c) Code review. In the beginning, I was hoping that I could get away with the existing code, just make tweaks and that's be it. Little did I know. In the end, it turned out that I did a review for every section of it, and every part and module had at least one bug. Probably the only part I did not review that closely was the interpretation of the printer.device specific ESC-code interpreter, and I am somehow affraid that I missed bugs there. But it is rarely used...

Concerning a): Graphics is another such nightmare. From its "design", one can guess that the intentions were all good. Build a lightweight (yes, really) interface around the custom hardware that exploits its features best. Unfortunately, in the end, it turned out that exactly that idea is quite inadequate to address the needs of the system, and kludges piled upon kludges.

Just to give you some idea: graphics has a nice system to represent copper instructions. First in an abstract way, for each viewport (aka "intuition screen"), which are then merged together to form a final display (aka "overlapping screen support"). This is all nice, but then the authors were hit by the problem that re-computing the copper list just for a color change was too much of a load, so a kludge was implemented on top that just "pokes" the existing copper lists quickly without going through a full rebuild. That made things faster, but more fragile. In fact, during testing our test team discovered a 30 year old bug in graphics that could (and did) trash memory by the above mechanism, and it took several days of debugging to iron out where that bug actually was.

Again: Legacy design + organic code + lack of testing -> receipt for failure.

If you wonder why 3.1.4. is smaller than you probably would have hoped for is because we tried this time to stress the importance of testing and debugging, and to limit the race for new features. I'm still beind this management choice.
 

Offline number6

Re: The Os 3.1.4 Thread
« Reply #67 on: September 28, 2018, 02:00:42 PM »
@olsen

Quote
Personally, I feel uncomfortable to "mine" the work of other developers for clues instead of asking them directly

I agree. My comment about postings refers only to the fact that years of public discussions where we all attempted to better one another....are just that...public.
Therefore, looking at that public information should not fall under your concern of code ownership or anything related to same.

Not being aware of the degree of interaction nor the rights to do so between folks working on "classic" vs "NG", I posed an admittedly ignorant alternative means to acquiring information.

#6
 

Offline BozzerBigD

Re: The Os 3.1.4 Thread
« Reply #68 on: September 28, 2018, 03:01:59 PM »
@olsen

Quote
The cleanest way to start over for the 3.1.4 update seemed to be to take the SAS/C port I had prepared and take it from there. Sure enough, this was 10-15 year old code which had not been reviewed since. There was trouble in every corner. Thomas reviewed the printer.device, tested, updated and rewrote it, filling in the gaps in the implementation to allow for OS 3.5/3.9 driver and prefs compatibility. Then it turned out that the HP printer drivers which were added in the OS 3.5/3.9 update were just as lacking as the printer.device and had to be reviewed, tested and updated. This was pretty scary :(

This really is baffling to me and it seems to me a mission anal retentiveness rather than to be useful in the real world!!! The Printer Drivers / printer.device were ALWAYS rubbish and are not worth updating! Everyone who wanted to use a printer on their classic who didn't want to be limited to a centronix era dot-matrix monstrousity bough TurboPrint period. There is absolutely NO point reinventing the wheel just because TurboPrint is no longer developed just as in the same way OS3.9 is no longer developed. These products were good and can still be bought / downloaded the last time I checked!

Maybe people just love putting right what once went wrong in a weird geeky 'Quantum Leap' kinda way but this project really doesn't seem to provide ANY real world benfits to the few Classic users remaining over and above what has gone before.

OS3.9 IS STILL FOR SALE AT VESALIA'S WEB STORE!!! THOMAS ET AL. ARE COMPETING AGAINST A 16 YEAR OLD PRODUCT AND DON'T SEEM TO CARE ABOUT IMPROVING ON IT (FEATURES, COMPATIBILITY AND SPEED IS ALL MOST OF US REALLY CARE ABOUT). IT SEEMS THOMAS MIGHT BE TEMPTED TO COMPETE WITH OS3.9 IF WE ALL INVEST IN THIS SPELLING AND GRAMMAR CHECKING EXCERCISE FIRST!! IS THAT ABOUT THE LONG AND THE SHORT OF IT? AM I MISSING ANYTHING? Sorry to use caps but what exactly are we buying and why?
"Art challenges technology. Technology inspires the art."

John Lasseter, Co-Founder of Pixar Animation Studios
 

Offline Louis Dias

Re: The Os 3.1.4 Thread
« Reply #69 on: September 28, 2018, 04:15:41 PM »
Boy someone woke up on the wrong side of the bed...
If you're 'retro' then you have an old printer too.   Besides, who knows if some dependency, when updated, broke printer.device which mandated some fixing...

Can't release software that fixes some things while breaking others.

As for sales of OS 3.5/3.9 - who is profiting and is any of that money being re-invested?
 

Offline olsen

Re: The Os 3.1.4 Thread
« Reply #70 on: September 28, 2018, 04:36:42 PM »
@olsen

Quote
The cleanest way to start over for the 3.1.4 update seemed to be to take the SAS/C port I had prepared and take it from there. Sure enough, this was 10-15 year old code which had not been reviewed since. There was trouble in every corner. Thomas reviewed the printer.device, tested, updated and rewrote it, filling in the gaps in the implementation to allow for OS 3.5/3.9 driver and prefs compatibility. Then it turned out that the HP printer drivers which were added in the OS 3.5/3.9 update were just as lacking as the printer.device and had to be reviewed, tested and updated. This was pretty scary :(

This really is baffling to me and it seems to me a mission anal retentiveness rather than to be useful in the real world!!! The Printer Drivers / printer.device were ALWAYS rubbish and are not worth updating!

The code never significantly evolved out of the state which the Workbench 1.3 update dropped it into. As the printer market evolved during the six years which followed Workbench 1.3 Commodore never caught up. This was likely just the kind of expensive development work which Commodore was "famous" for not undertaking.

I don't think that the printer.device or the drivers were always rubbish. For a brief time (say 1986-1988) they were adequate, but both the driver design and how the text and graphics output shaped the design of the printer.device stopped it from ever being able to become relevant again. Apple, for example, early on settled on a graphics device abstraction layer which both worked for the display and the printed output (the original Quickdraw even tried to encompass component colour printing, which was eventually replaced when proper RGB colour support came to the Macintosh II). For the Amiga it was bitmap colour graphics all the way, within the constraints of the original custom chipset, slightly updated in Workbench 3.0.

In any case, custom printing software which clung to the printer.device API was just as constrained by the limitations of the architecture as the original printer.device. The big problem lies with how "printing" was designed for the Amiga first, and with the limitations of the implementation second.

Quote
Everyone who wanted to use a printer on their classic who didn't want to be limited to a centronix era dot-matrix monstrousity bough TurboPrint period. There is absolutely NO point reinventing the wheel just because TurboPrint is no longer developed just as in the same way OS3.9 is no longer developed. These products were good and can still be bought / downloaded the last time I checked!

Maybe people just love putting right what once went wrong in a weird geeky 'Quantum Leap' kinda way but this project really doesn't seem to provide ANY real world benfits to the few Classic users remaining over and above what has gone before.

That certainly depends upon your expectations, and what we could deliver. For example, with all the bug fixes and enhancements, there's a new file system recovery tool included which to the best of my knowledge has never existed before. It may yet be useful...

Quote
OS3.9 IS STILL FOR SALE AT VESALIA'S WEB STORE!!!

Is it? How come that new copies are still available after some 20 years? I do wonder how this is possible.

Quote
THOMAS ET AL. ARE COMPETING AGAINST A 16 YEAR OLD PRODUCT

Well... not really. The scope of the OS 3.9 update is different from what we came up with. Fixing the printer.device and drivers was an unexpected detour, but it is not representative of the OS 3.1.4 update as a whole. There are bug fixes in it which which were not even in reach for the OS 3.5/3.9 update, and for that matter, for Kickstart/Workbench 1.3.

The major reason why the work was done is in that it makes more sense to adapt the operating system than to require that the designers and developers of the new Amiga hardware which has become available as of late to adapt their hardware instead. There's a towering stack of unfixed bugs and increasingly rickety workarounds in place in the Amiga operating system and, for example, Picasso96. It's about time that this is addressed.

Quote
AND DON'T SEEM TO CARE ABOUT IMPROVING ON IT (FEATURES, COMPATIBILITY AND SPEED IS ALL MOST OF US REALLY CARE ABOUT). IT SEEMS THOMAS MIGHT BE TEMPTED TO COMPETE WITH OS3.9 IF WE ALL INVEST IN THIS SPELLING AND GRAMMAR CHECKING EXCERCISE FIRST!! IS THAT ABOUT THE LONG AND THE SHORT OF IT? AM I MISSING ANYTHING?

The satisfaction of setting something right that was broken and could be repaired :) Yes, really: leave things better than you found them.
« Last Edit: September 28, 2018, 04:58:43 PM by olsen »
 

Offline number6

Re: The Os 3.1.4 Thread
« Reply #71 on: September 30, 2018, 02:27:27 PM »
 

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #72 on: September 30, 2018, 05:08:52 PM »
(FEATURES, COMPATIBILITY AND SPEED IS ALL MOST OF US REALLY CARE ABOUT).

You should buy a Vampire card, it comes with a kickstart and OS that fits all you care about.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #73 on: September 30, 2018, 05:18:25 PM »
@olsen

You mention new hardware that has been coming lately. You are aware that one reason why there is a wave of new hardware these days, is a tool which quite a few hardware developers have mentioned that they could never manage without, and this tool was made by someone who had good help from the leaked OS sources. Just throwing it out there, what goes around, comes around.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #74 from previous page: September 30, 2018, 07:01:11 PM »