Amiga.org

Operating System Specific Discussions => Amiga OS => Amiga OS -- Application questions and support => Topic started by: Thomas Richter on September 22, 2018, 02:58:57 PM

Title: The Os 3.1.4 Thread
Post by: Thomas Richter on September 22, 2018, 02:58:57 PM
Hi folks,

the purpose of this thread is to exchange information and experiences around AmigaOs 3.1.4. If everything goes well - and it currently looks that it will - the AmigaOs bug fix release will appear in very near future. If you have technical questions around this release, you may try it here - I'll try to look into them from time to time, all hoping that things don't go overboard, and I hope some members of the development and beta-tester team will do so as well.

What could go in here:

- Questions regarding the distribution of 3.1.4
- Exchange of experiences with 3.1.4

Note well: This is not an official support thread, and is not part of a "support system" for 3.1.4. If anyone helps, then just on the basis of availability and good will. We may probably help you to identify one or the other problem, regardless our attempts to avoid them in first place. If, however, you have any official question regarding warranty, support, legal questions... go, ask the official sources. None of them are here. We will also ship a FAQ along with 3.1.4, and it's certainly worth looking there first before coming here. We tried to identify the most obvious questions there, and wrote everything down we could think of.

PS: I kindly ask you to stop any attempt to troll here. Quite seriously, I'm really tired of this after all the work that went into the product, and I believe I also speak for all team members. For that, please go elsewhere.

Title: Re: The Os 3.1.4 Thread
Post by: number6 on September 22, 2018, 03:29:12 PM
@Thomas Richter

Just for historical purposes, in case anyone is unaware of past and present discussion:

AmigaOS 3.1.4 beta! (http://eab.abime.net/showthread.php?t=89251)

Perhaps it will offer some worthwhile ideas for discussion.

#6
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on September 22, 2018, 03:32:24 PM
I am also a part of the Team, and of course willing to help too.  :)
Title: Re: The Os 3.1.4 Thread
Post by: amigakit on September 22, 2018, 08:43:42 PM
First of all, I would like to congratulate you on your hard work.  I know you have the best of interests for our Classic Amiga community and future.  I would like to thank you for your efforts and enthusiasm for progressing our platform.

One thing that Amiga history has taught us is that when the custodians of the updates to AmigaOS no longer operate in the Amiga market, the branch becomes closed and we need to restart development.  This happened of course with Commodore and then H&P.  The OS3.9 work has been seemingly lost and 3.1.4 has been had to go back to go forward.

Does the 3.1.4 changes I presume all fall under the ownership of Hyperion?  So any work you do for them is automatically assigned copyright to them?
Title: Re: The Os 3.1.4 Thread
Post by: number6 on September 23, 2018, 03:23:49 PM

Does the 3.1.4 changes I presume all fall under the ownership of Hyperion?  So any work you do for them is automatically assigned copyright to them?

I believe these are questions that Thomas would prefer to be discussed outside of the context of this thread.

Quote
If, however, you have any official question regarding warranty, support, legal questions... go, ask the official sources.

#6
Title: Re: The Os 3.1.4 Thread
Post by: boemann on September 23, 2018, 03:30:49 PM
I'm curious about the windows partially outside the screen feature as was reported when news first broke about this 3.1.4 update. Is this feature still going to be released and can you tell just a little bit about this feature.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 23, 2018, 04:30:46 PM
Pulling windows out of screens is a feature of intuition v45 which will be available for all customers of 3.1.4 as an optional component for installation. Unfortunately, it is only optional because it does not work with cybergraphics.

Unfortunately, CGfx depends on compiler-specific register- and memory allocation of the compiled intuitition v40 code beyond our knowledge, and intuition v40 is the only component which was built with the Greenhill compiler. Unfortunately, the compiler is no longer available, and even if it would, we would not know how to integrate it into the built-system, so we cannot reproduce what Cgfx requires.

We reached out to Frank Mariak asking for insight, and offered an internal interface in intuition v45 for CGfx to reproduce (with some assembly stubs potentially) its requirements. Even some first contact was established successfully, this went unfortunately nowhere.

So, at this time, intuition v45 is for native graphics and P96 only, and only as an optional feature. I would have preferred to offer this as a regular part of 3.1.4, but we cannot risk to loose Cgfx customers.

Title: Re: The Os 3.1.4 Thread
Post by: BozzerBigD on September 23, 2018, 05:29:39 PM
@number6
Quote
I believe these are questions that Thomas would prefer to be discussed outside of the context of this thread.

Why should we get excited about this if this branch will be equally likely to dry up should Hyperion's money problems end in bankruptcy? OS3.9 is fine for users IMHO and there are a small number of Classic developers still operating that a bug fix may interest so what exactly are we attempting to achieve? AmiKIT is a Workbench replacement, many still use Directory Opus and now Amiga OS 3.1.4 is here!?! Rather than ask us to ask Thomas technical questions Thomas should tell US why this is of interest and what would be the benefit of buying it over and above OS3.9? I'm not trolling, this is a serious question.

From beta thread:
Quote
Lots of bug fixes and:
- Fast File System with native 64-bit support for NSD, TD64 and direct SCSI, long filenames and resizable media support
- CrossDOS with native 64-bit support for NSD, TD64 and direct SCSI support, long filenames and resizable media support, new mfm.device
- Format, DiskCopy and HDToolbox with 64-bit support based on NSD, TD64 and direct SCSI support, plus bug fixes
- C:Mount for large media, direct SCSI support and resizable removable media
- Working soft links for the RAM disk and Fast File System
- Shell tools with long filename support, softlinks and large media support
- Math libraries that reconfigure themselves when an FPU becomes available after loading.
- New DIR command with nicely formatted output
- New Workbench that also copies links
- CPU command with 68060 support
- exec.library that no longer dies on 68060
- SetPatch, without NSDPatch and RomUpdates (not needed anymore)
- Intuition with off-screen window dragging
- aux-handler now completely rewritten in C. No more BCPL code in AmigaOS!
- More bugfixed portions: audio.device, asl.library, Compugraphic fonts, diskfont and fixfonts, icon.library, iffparse.library, Installer, iPrefs, Locale, parallel and serial devices, RAMlib and RAMdrive, rexxsyslib, scsi.device, speak-handler, More, and others
- Added V45 layers.library, V45 execute command, V46 Shell

Great! Lots of work and extra 060 support is a great addition IMHO but does this all actually add up to a better and more complete product compared to OS3.9 or do you just view this a cleaner and future proof (from a technical viewpoint rather than legal obviously) version?
Title: Re: The Os 3.1.4 Thread
Post by: boemann on September 23, 2018, 05:44:15 PM
'I for one have been waiting eagerly for this update ever since it was announced - granted I use 3.1 today so for those of you using non retro versions it may not be such a big thing, but for me it serves as a way to fix bugs while still keeping it as original as possible
Title: Re: The Os 3.1.4 Thread
Post by: BozzerBigD on September 23, 2018, 05:51:43 PM
Quote
while still keeping it as original as possible

This is the thing I don't understand... OS3.5 and OS3.9 WERE official OS versions. They provide an 'original' Amiga experience. OS3.9 is worth it IMHO just because it has the .LHA Unarchiver program on the Dock out of the box. Commodore were both the Amiga's saviour and its destroyer. We don't owe them anything and in particular we shouldn't feel we are losing out on the retro C= experience by not sticking to the 'grey and blue' C= version of the OS!
Title: Re: The Os 3.1.4 Thread
Post by: Oldsmobile_Mike on September 23, 2018, 06:44:25 PM
Always nice to see additional development, even if it means more fragmentation.  I'll probably pick and chose from 3.1.4 components (once released) to add to my existing 3.9 systems.  Of course I don't expect anyone to support these hacked together kludges beyond myself.  ;)
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on September 23, 2018, 07:18:44 PM
Always nice to see additional development, even if it means more fragmentation.  I'll probably pick and chose from 3.1.4 components (once released) to add to my existing 3.9 systems.  Of course I don't expect anyone to support these hacked together kludges beyond myself.  ;)

Not really fragmentation. Let me explain:

All 3.1.4 components are way beyond in fixes and features than what 3.9 brought to the table. What 3.1.4 lacks is all those third party applications that 3.9 brought along, like video player, web browser, dock bar, tcp-ip stack, etc.

The core of the Operating System is way better in all aspects than what 3.9 ever was/is.

The best part of this, is that taking some precautions, you can integrate 3.1.4 in a working 3.9 system, and get the best things of both worlds: the best OS core (3.1.4), and the more handy applications some of which came with 3.9.

I have already performed the 3.9 + 3.1.4 integration several times: It requires some work, but it is not voodoo magic by any means.
Title: Re: The Os 3.1.4 Thread
Post by: Dynamic_Computing on September 23, 2018, 07:24:48 PM
I agree with Gulliver - The Amiga OS is fairly simple at its core, so changing some libraries and careful use of the setpatch command should allow anything from 3.14 work perfect with an OS 3.9 install. I personally like OS 3.9 (Except the horribly long boot times), but I certainly will be buying 3.14 when it comes out!
The other benefit of the Amiga OS is that it really easy to back up the entire OS and all partitions, allowing you to play with things and test things, and if they break, just copy the old install right back to the original drive.
I am very excited for the new patch, and I hope it is a success for the group that is working on it.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 23, 2018, 09:45:23 PM
Why should we get excited about this if this branch will be equally likely to dry up should Hyperion's money problems end in bankruptcy? OS3.9 is fine for users IMHO and there are a small number of Classic developers still operating that a bug fix may interest so what exactly are we attempting to achieve?
Look, I'm not doing a sales pitch here, because I don't have to. My income from this is exactly zero, and it's all for fun. It's a bug fix after all, even though it went a bit overboard. So, there is really nothing revolutionary new here, and I'm not trying to sell you this as something new.

Even if Hyperion goes bankrupt, it surely does not affect the software on your system. It does not make the update worse, even if it is the last update. So, what exactly are you afraid of? That it is the last update? And if so, why would it help not to install it?

AmiKIT is a Workbench replacement, many still use Directory Opus and now Amiga OS 3.1.4 is here!?! Rather than ask us to ask Thomas technical questions Thomas should tell US why this is of interest and what would be the benefit of buying it over and above OS3.9? I'm not trolling, this is a serious question.
3.1.4 is not a workbench replacement. An updated workbench is part of it, yes. But it is an updated operating system. Why this is of interest? How should I know - why do you care about an Amiga? An Amiga is not a "useful" system anyhow. If your main use is to play legacy games, for example, the operating system is irrelevant for you in first place, and you probably run it under 1.3.

I addressed and fixed the bugs I found probably because I'm a little bit perfectionistic, and I like to get the system as good as I possibly can.

I don't know whether this is a "sufficient" explanation for you, but as said, I don't need to sell 3.1.4. to you. It is the way how I wanted to have it, under the constraints we had. I would have also loved to update 3.9, but we couldn't. So it is 3.1.4, not 3.9.4, neither 3.14.

Lots of work and extra 060 support is a great addition IMHO but does this all actually add up to a better and more complete product compared to OS3.9 or do you just view this a cleaner and future proof (from a technical viewpoint rather than legal obviously) version?
Actually, that list is a bit outdated by now in the sense that the list is quite a bit incomplete. Anyhow....

3.1.4 goes into a different direction than 3.9. 3.9 was about new features. 3.1.4 is about bugfixing. Why not a 3.9 bugfix? Because 3.9 is lost in time and space. 3.1.4 is the best we could do.

Is it "future proof"? I beg your pardon. Amiga and "future"... If you want a future proof system, buy a PC or a smartphone. Actually, buy a new one every two years. (-:

Title: Re: The Os 3.1.4 Thread
Post by: utri007 on September 23, 2018, 10:05:24 PM
Quote
I have already performed the 3.9 + 3.1.4 integration several times: It requires some work, but it is not voodoo magic by any means.

Could you tell more about this? This what I'm going todo, so I'm interested.
Title: Re: The Os 3.1.4 Thread
Post by: giZmo350 on September 23, 2018, 10:46:56 PM
When might this be available for purchase?  :D
Title: Re: The Os 3.1.4 Thread
Post by: wawrzon on September 23, 2018, 10:57:10 PM
Quote
I'll probably pick and chose from 3.1.4 components

Quote
so changing some libraries and careful use of the setpatch command should allow anything from 3.14 work perfect with an OS 3.9 install.
that, once assumed 3.1.4 kickstart come in a form that allows he regular user to cherry pick its components, which i doubt, because it would defeat its purpose, both conceptually and commercially.
people are able to manipulate the genuine kickstarts thanks to doobrey tools extracting and compiling in the particular modules, right. but this was a necessary hack, introduced years after they have been abandoned with no further support. if 3.1.4 was intended for the user to be recombined at will it would create support hell without limits.

speaking of dragging windows outside the screen, im wondering why is it so complicated. power windows did that, and very well (i have been using the hack for years). aros is doing it. hell, even os4 is able to do that.. well. that might have been a feature worth an update, while all of them, as far as i read, actually are already covered by hacks and patches.
Title: Re: The Os 3.1.4 Thread
Post by: wawrzon on September 23, 2018, 11:07:04 PM
@thor
Quote
Even if Hyperion goes bankrupt, it surely does not affect the software on your system.

i think, what people are wondering about is, why invest so much work for a limited outcome (you call it a bugfix release yourself), one might not be able to build upon any further (due to contractual circumstances). see what (expectably) happened to p96 as example.
thats also probably what amigakit was pointing at. however this exactly is what you (understandably) do not want to discuss here, so consider it an off topic, alright.
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on September 23, 2018, 11:19:58 PM
Quote
I have already performed the 3.9 + 3.1.4 integration several times: It requires some work, but it is not voodoo magic by any means.

Could you tell more about this? This what I'm going todo, so I'm interested.

No problem.  :)

Just give me a day or two, I need to first get back home, and do this procedure all over again, so that I take notes, and dont miss something when retelling it.  ;D
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on September 23, 2018, 11:30:21 PM
When might this be available for purchase?  :D

Very soon as Thomas has already said.

It really depends on ironing out the last details and see that no other bugs creep out of their caves.  :D

Title: Re: The Os 3.1.4 Thread
Post by: BozzerBigD on September 23, 2018, 11:30:50 PM
Quote
Is it "future proof"? I beg your pardon. Amiga and "future"... If you want a future proof system, buy a PC or a smartphone. Actually, buy a new one every two years. (-:

I meant "future proof" in the sense of being a future proof code base in order to eventually extend the feature set to beyond that of OS3.9. If this is just a perfectionist project with no intention of taking it further and pushing past OS3.9 on 68k then I am not really interested. Perfectionism for perfectionism's sake is a pointless endeavour IMHO. We live in a fallen world and unless clean code actually gives you kicks then efficiency or features is normally the priority not simply eliminating ALL bugs just for the sake of it. AmigaOS is already efficient and features beyond 3.1.4 are available in OS3.9 so good luck to you but I'll be waiting for OS3.2.x before I'm on board.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 24, 2018, 06:09:03 AM
I meant "future proof" in the sense of being a future proof code base in order to eventually extend the feature set to beyond that of OS3.9.
Os4 for classic also exists. Maybe that's more what you want.

How and why exactly should I make promises? I cannot give you any. If the product sells well, it would be fairly stupid not to make another after a while. If it does not sale well, there will not be. As simple as it is.

Will AmigaOs grow out of its legacy and overtake the world of operating sytems? No.

3.1.4 is *not* a revolutionary design, there are no revolutionary ideas in it. If you do not care about fixed bugs, but new features, this is not for you. For a >20 year old system, it is a bit late to care about new features anyhow.
Title: Re: The Os 3.1.4 Thread
Post by: bubbob42 on September 24, 2018, 03:04:42 PM
As Thomas said, this product is an upgrade to OS3.1.4, not 3.9, for many reasons. We'll supply a rather lengthy FAQ, which will also cover that topic, so I won't go into detail here.

But I'd like to emphasize one thing: You can spend all day to discuss whether this thing is worth the trouble, waste of time and energy, complain about things OS3.9 did better 18 years ago, etc.. Or not.

What you'll get is what's possible under the circumstances. There has been no alternative, no "better", "future-proof" approach. Lot's of "DOs": We couldn't do more. It was either do or don't. Maybe someone could have done better, but he did not. Let's leave it at that. ;)

So, now you have another *option* to build your own system, nothing more. The glass is half full - why not have a sip? You may even like the taste. :)

 
Title: Re: The Os 3.1.4 Thread
Post by: boemann on September 24, 2018, 08:01:06 PM
Another question (and thanks for the comprehensive answer to my last):  Is stderr redirection fixed ( or should I say implemented) both in the shell but also in dos.library / execute. Because it isn't working in 3.1.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 24, 2018, 08:25:10 PM
Another question (and thanks for the comprehensive answer to my last):  Is stderr redirection fixed ( or should I say implemented) both in the shell but also in dos.library / execute. Because it isn't working in 3.1.

3.1 never had stderr redirection. 3.9 had, with "*>foo". However, the problem is what programs do about it, because AmigaDos aka Tripos does traditionally not have a stderr stream. This was added somewhere later with v37 or even beyond, but programs had to explicitly write to process->pr_CES, and of course no program did, because it was traditionally not there. Even C standard libraries had not been adapted to make use of it, as far as I recall.

So in that sense, there is really nothing to fix, but that is not the fault of the Os. What *> does is that redirects stderr, and CONSOLE:, but whether that does actually make a difference is anybodies guess. For most programs, the answer is no.

This will not change in 3.1.4, but "simply" because we cannot touch all programs.

Title: Re: The Os 3.1.4 Thread
Post by: boemann on September 24, 2018, 08:31:53 PM
well my point is that even pr_CES or the tags for Error was never implemented afaict, so there is actually non functional API in 3.1- hence my question about it being fixed.

I know it's impossible to fix old programs, but first step would be the os actualy allowing it.

Anyway thanks for your answer - I know what to expect now - and still looking forward to buying it
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 24, 2018, 08:57:52 PM
well my point is that even pr_CES or the tags for Error was never implemented afaict, so there is actually non functional API in 3.1- hence my question about it being fixed.
Well, please define "implemented". Yes, pr_CES is of course "implemented". It sits there, waiting to be used. I can ensure you that the shell also fills it if you redirect stderr with *>, but that doesn't help if programs do not pick it up. We cannot fix that, of course.

If the question is: Did we actually touch dos.library? No, not this time. We already attacked one dragon in 3.1.4. (which is graphics, now at 45.27), and that is one monster enough for me this time. There is a tiny patch for dos in SetPatch, and quite some improvements in dos handlers, but Tripos itself remained untouched. This time.
Title: Re: The Os 3.1.4 Thread
Post by: Bennymee on September 24, 2018, 09:25:02 PM
There is a lot going on concerning filesystems, harddrives and recovery.
Is there also something planned for the cd-rom driver cdo:  ?

Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 24, 2018, 09:38:57 PM
Is there also something planned for the cd-rom driver cdo:  ?

No, nothing is planned, but a lot is done. CDFS is really all new. Speaks ISO, rockridge, Joliet and UDF, supports audio tracks and is multithreaded. There is no HFS and HFS+ support because the code for that was not in good shape, and there is no CDXL support either because I do not know enough on which of the many CD modes is right for that.
Title: Re: The Os 3.1.4 Thread
Post by: NorthWay on September 24, 2018, 10:21:32 PM
One could have hoped the OS included STDIN: STDOUT: and STDERR: (or just IN: OUT: ERR:). Would have been more "Amiga way" to me.
Title: Re: The Os 3.1.4 Thread
Post by: graffias79 on September 24, 2018, 10:42:04 PM
Will this operating system be distributed as ROMs and diskettes?
Title: Re: The Os 3.1.4 Thread
Post by: boemann on September 25, 2018, 09:39:05 AM
Quote
Well, please define "implemented". Yes, pr_CES is of course "implemented". It sits there, waiting to be used. I can ensure you that the shell also fills it if you redirect stderr with *>, but that doesn't help if programs do not pick it up. We cannot fix that, of course.
Ok that is not what my research showed me happening but cool, I'll try again


Quote
If the question is: Did we actually touch dos.library? No, not this time. We already attacked one dragon in 3.1.4. (which is graphics, now at 45.27), and that is one monster enough for me this time. There is a tiny patch for dos in SetPatch, and quite some improvements in dos handlers, but Tripos itself remained untouched. This time.
All your work is appreciated
Title: Re: The Os 3.1.4 Thread
Post by: bison on September 25, 2018, 11:03:55 PM
Is 3.1.4 being tested with emulators such as FS-UAE, or is it intended for real hardware only?
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on September 25, 2018, 11:36:57 PM
Is 3.1.4 being tested with emulators such as FS-UAE, or is it intended for real hardware only?

I am nearly always working away from home, so I usually run/test 3.1.4 in WinUAE on a notebook, and when I have time at home, usually on weekends, I can test it under real hardware.

Emulators are great for the convenience, speed and portability factor. Real hardware is much better when trying to test because either things work or not, there is no second guessing, or blaming it on bad emulator configuration options, or corner cases with unimplemented functions. So each option has its place.
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on September 25, 2018, 11:40:21 PM
Will this operating system be distributed as ROMs and diskettes?

Yes, but there will also be other forms of distribution which I cannot discuss.  :-X
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 26, 2018, 06:17:48 AM
Is 3.1.4 being tested with emulators such as FS-UAE, or is it intended for real hardware only?

Both, but my confidence in emulators is limited, so real hardware has the final say. I found at least two serious bugs in eUAE (the last and latest emulator on Linux that works for me) while testing,  and I'm not using Windows for development either. Os 3.1.4 was completely build on vamos - thanks to Christian Vogelsang!
Title: Re: The Os 3.1.4 Thread
Post by: wawrzon on September 26, 2018, 02:55:15 PM
is e-uae up to date at all? i thought it was dead? jason has years ago used its fork, puae and im certain it has been discussed why not to use fs-uae which uses updates and fixes from winuae. here probably are severe reasons backing up these choices. but reading about necessary fixes to probably an outdated emulator, makes me wonder if there aint more inaccuracies that otherwise has been fixes in the current releases.
Title: Re: The Os 3.1.4 Thread
Post by: bison on September 26, 2018, 07:35:15 PM
Quote
is e-uae up to date at all? i thought it was dead?
It seems like it might be.  The last release was over ten years ago, the files are gone on Source Forge, and it does not appear to be in the Debian or Ubuntu repositories, although I seem to remember that it had been quite recently.  I've been using FS-UAE for a while now, so I'm not really sure when this happened.

http://www.rcdrummond.net/uae/ (http://www.rcdrummond.net/uae/)

https://sourceforge.net/projects/uaedev/files/ (https://sourceforge.net/projects/uaedev/files/)
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 26, 2018, 07:51:04 PM
Could we please keep the thread on topic?

Thank you.
Title: Re: The Os 3.1.4 Thread
Post by: kamelito on September 26, 2018, 07:52:21 PM
Is 3.1.4 being tested with emulators such as FS-UAE, or is it intended for real hardware only?

Both, but my confidence in emulators is limited, so real hardware has the final say. I found at least two serious bugs in eUAE (the last and latest emulator on Linux that works for me) while testing,  and I'm not using Windows for development either. Os 3.1.4 was completely build on vamos - thanks to Chris

WinUAE should be better under Wine until FS UAE merge the latest WinUAE codebase.
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on September 27, 2018, 04:00:22 AM
Quote
I have already performed the 3.9 + 3.1.4 integration several times: It requires some work, but it is not voodoo magic by any means.

Could you tell more about this? This what I'm going todo, so I'm interested.

No problem.  :)

Just give me a day or two, I need to first get back home, and do this procedure all over again, so that I take notes, and dont miss something when retelling it.  ;D

Well, I did something better than what I promised:

I created a simple, but rather lengthy AmigaDOS script that will update a 3.5/9 system to 3.1.4.

It is a quick and dirty hack, but it gets the job done, at least on a clean AmigaOS 3.9 system that I have tested with.

I have handled it to other testers to see if it works for them. And if everything goes well, you will have a way to upgrade your  system, and even better than that, you will be able to read the AmigaDOS commands it contains and use a different, much better way to perform the upgrade yourselves.

My idea, if it turns out okay, is to upload it to Aminet so that anyone can use/re-use/read it and understand how the bloody thing works.  ;D

Title: Re: The Os 3.1.4 Thread
Post by: Dynamic_Computing on September 27, 2018, 05:56:43 AM
Thanks so much, Gulliver! That script will certainly make our lives easier!
Title: Re: The Os 3.1.4 Thread
Post by: Romanujan on September 27, 2018, 07:56:18 AM
It is a quick and dirty hack, but it gets the job done, at least on a clean AmigaOS 3.9 system that I have tested with.

It would be better if it could update not plain OS 3.9, but OS 3.9 with BoingBag 2...
Title: Re: The Os 3.1.4 Thread
Post by: Rotzloeffel on September 27, 2018, 08:45:01 AM
It would be better if it could update not plain OS 3.9, but OS 3.9 with BoingBag 2...

:) There is NO NEED anymore for any Kind of Boing-whatever.... 3.1.4 is much more newer.

The new setpatch can also handle 68060 CPU and ROMUPDATE is obsolete

@Gulliver
maybe we could include this script into the Distribution ? Modules Disk ?
Title: Re: The Os 3.1.4 Thread
Post by: Romanujan on September 27, 2018, 10:34:44 AM
:) There is NO NEED anymore for any Kind of Boing-whatever.... 3.1.4 is much more newer.

I assumed that OS 3.1.4 won't contain most BB2 updates (Reaction, Amplifier, and several others) - in fact, I assumed it won't contain these components at all... do you have access to 3.1.4 beta to confirm this, or is that statement just your guess?
Title: Re: The Os 3.1.4 Thread
Post by: Rotzloeffel on September 27, 2018, 11:02:10 AM
I assumed that OS 3.1.4 won't contain most BB2 updates (Reaction, Amplifier, and several others) - in fact, I assumed it won't contain these components at all... do you have access to 3.1.4 beta to confirm this, or is that statement just your guess?

Yes, I have Access to 3.1.4..... I talked about the ROM-updates, so maybe I missunderstood.... for these Special 3.9 addons of course no, they are not included.

Reaction is Copyrighted by Haage&Partner I think.....
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 27, 2018, 11:25:19 AM
I assumed that OS 3.1.4 won't contain most BB2 updates (Reaction, Amplifier, and several others)
It will not contain any extternal contributions that were made to 3.9, nor anything H&P developed in-house. However, fixes to Os core components that arrived through the BoingBags are included to the degree we could, either directly, or indirectly by re-checking the defect reports from back then and re-integrating appropriate bug fixes.

For example, H&P shipped in 3.9 a customized printer.device, which we did not have, so we had to restart the work on this component, which turned out to be a much longer and tedious job than we originally hoped. This is probably another story...

Workbench was also updated by H&P, but there is a later version from Olaf, plus more bug fixes, we include. So the workbench is in a post 3.9 state, and the printer.device is, too. The 3.9 version for example never worked reliable with my Nec P6 (or actually, any slow printer), but the new version does.

Reaction and components using reaction are not included, though. We don't have reaction.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas on September 27, 2018, 12:17:33 PM
I assumed that OS 3.1.4 won't contain most BB2 updates (Reaction, Amplifier, and several others) - in fact, I assumed it won't contain these components at all... do you have access to 3.1.4 beta to confirm this, or is that statement just your guess?

You are right. 3.1.4 is an update for OS 3.1. OS 3.5/3.9 components are not included.

However, some common components like icon.library, workbench.library, scsi.device and such got updates beyond those of OS 3.9, so you should use these instead.

I think all of the components of the AmigaOS ROM Update received updates, so you should remove/disable the ROM update and use the disk-based/LoadModule'd versions instead.

IMHO mixing OS 3.9 and 3.1.4 is not a good idea. It's for version-number-junkies only. But I'm also happy with OS 3.9 BB2, I never felt the desire to update beyond it. So my opinion might not count that much.
Title: Re: The Os 3.1.4 Thread
Post by: bubbob42 on September 27, 2018, 01:16:59 PM
IMHO mixing OS 3.9 and 3.1.4 is not a good idea. It's for version-number-junkies only.

You forget the updated shell commands which have been updated to tolerate long filenames and large harddisks, among other bugfixes. Or the printer stuff.

I'd recommend updating almost everything, except for the prefs maybe. Those have been overhauled to offer just the functions of their 3.9 counterparts, except for using GadTools instead of ReAction. And even that might change in the future.
Title: Re: The Os 3.1.4 Thread
Post by: Romanujan on September 27, 2018, 01:23:38 PM
IMHO mixing OS 3.9 and 3.1.4 is not a good idea. It's for version-number-junkies only. But I'm also happy with OS 3.9 BB2, I never felt the desire to update beyond it. So my opinion might not count that much.

Well, I like Amplifier (IMHO it feels better than AmigaAMP). And I don't mind the latest Reaction sitting there on my SD card - it's probably good for compatibility. I already got rid of several OS 3.9 components I consider bloatware (like the dock included with the system, I forgot it's name).
Title: Re: The Os 3.1.4 Thread
Post by: number6 on September 27, 2018, 02:44:01 PM
I assumed that OS 3.1.4 won't contain most BB2 updates (Reaction, Amplifier, and several others)
It will not contain any extternal contributions that were made to 3.9, nor anything H&P developed in-house. However, fixes to Os core components that arrived through the BoingBags are included to the degree we could, either directly, or indirectly by re-checking the defect reports from back then and re-integrating appropriate bug fixes.

For example, H&P shipped in 3.9 a customized printer.device, which we did not have, so we had to restart the work on this component, which turned out to be a much longer and tedious job than we originally hoped. This is probably another story...

Workbench was also updated by H&P, but there is a later version from Olaf, plus more bug fixes, we include. So the workbench is in a post 3.9 state, and the printer.device is, too. The 3.9 version for example never worked reliable with my Nec P6 (or actually, any slow printer), but the new version does.

Reaction and components using reaction are not included, though. We don't have reaction.

Did you or Olaf speak to Detlef Würkner (tetisoft)?
I only mention this because we went through most of these issues concerning printer during AmigaOS4.x development, and he surely did a lot of work on this.

#6
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 27, 2018, 03:24:25 PM
Did you or Olaf speak to Detlef Würkner (tetisoft)?
I only mention this because we went through most of these issues concerning printer during AmigaOS4.x development, and he surely did a lot of work on this.
It is more complicated like this. We had the original 3.0 (v39) printer.device, but this was not an option because it did not support RTG prining. Then I looked into the Os 4.0 version, but this was neither an option because it had so many Os 4-isms that it would have been a lot of work to even make it working back on the legacy system. Then, we decided for an interim release, one of the drilled-up versions before it became an Os 4 version. That did compile, but...

Up to then, I believed that graphics was the worst part of the Os. I learned I was wrong. It is really hard to say, but there were probably more changes than there was code to begin with, and the printer.device we have now is certainly in a much better shape than the Os 4 version. To name a few:

- Of all the printer.devices I have seen, only the v39 version and now the v45 version handles double-buffering correctly.

- Aborting a printer.device request was broken in one way or another in all versions I revisited. Traditionally, the printer.devices handled "paper out" and "printer not connected" just the wrong way round, and this was just one problem. Another was that not all requests were terminated (v39) or some requests were terminated but such that the abortion was in the middle of a ESC sequence such that you had to turn the printer off and on again to be able to continue printing.

- All the Os 3.9 printer drivers, but none of the v39 (Os 3.0) printer drivers returned the wrong result code from initialization. Nobody noticed since none of the printer devices actually checked that the driver could actually initialize itself successfully. In case it could not, the code would just crash right away.

- All printer devices from Os 3.9 on did not buffer printer drivers. Whenever you started a new print job, it insisted to reload the driver from disk.

- Scaling was broken, that is, if you printed with some printer drivers, the graphics was simply not scaled at all, or scaled wrongly.

- Floyd-Steinberg dithering overrun the buffer and then left artefacts at the right edge of the printed graphics.

- Rotated HAM printing did not work as the color information was not carried over correctly.

... The list goes on and on like this. The whole printer device, including the Os 4.0 version, is a medium-sized nightmare. We worked on this about six weeks, such that the release note "Printer device  updated (oh no, not again!)" became a running gag in the team.

I hope we edged out the majority of bugs by now - at least we haven't found any new ones anymore, but the printer was really the buggiest part of all. In terms of features, we may be behind the 3.9 version (no fancy preview) but in terms of correctness, I believe we are well ahead of v39, and pretty much ahead of the Os 4 version as well. This thing was really beasty.

The bad part is: Once you have done a job like this, it looks like "evident and obvious" that things "simply work". Be aware it wasn't. There is nothing particularly fancy in 3.1.4 that makes it "stand out". So, no eye candy, no advanced features. Just working.
Title: Re: The Os 3.1.4 Thread
Post by: number6 on September 27, 2018, 03:38:36 PM
@Thomas Richter

Thank you very much for your detailed response.
One related item popped up in our long discussion during OS4.x work performed  by Detlef:

Are there any known conflicts with Turboprint?

#6
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 27, 2018, 03:47:39 PM
Are there any known conflicts with Turboprint?

I haven't tested, but the interface of the printer.device is still the very same interface CBM defined in v39, except that we have now more than one possible back-end printer we can serve (as in 3.9). Thus, clearly, you cannot use the 3.1.4. printer drivers for TurboPrint, but that is old news and was always like this. Other than that, I do not quite see in how far it could conflict. TurboPrint just replaces the printer.device completely, so how could it conflict?
Title: Re: The Os 3.1.4 Thread
Post by: number6 on September 27, 2018, 03:57:51 PM
Are there any known conflicts with Turboprint?

I haven't tested, but the interface of the printer.device is still the very same interface CBM defined in v39, except that we have now more than one possible back-end printer we can serve (as in 3.9). Thus, clearly, you cannot use the 3.1.4. printer drivers for TurboPrint, but that is old news and was always like this. Other than that, I do not quite see in how far it could conflict. TurboPrint just replaces the printer.device completely, so how could it conflict?

re:prefs

 (https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=17531&forum=14&start=240&viewmode=flat&order=0#266877)
Quote
TurboPrint installed? IIRC it messes with the prefs

Forgive me if I'm a bit behind as of any status change since 2006.

#6
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 27, 2018, 04:28:21 PM
re:prefs
 (https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=17531&forum=14&start=240&viewmode=flat&order=0#266877)

Oh, the preferences format. Yes, 3.9 used an integrated overall preferences with graphics and printer in one single file. 3.1.4 supports both, and by default, uses the 3.1 preferences system. So that aspect should be fine. But I have not tried, really.

There is an entry on the FAQ (as soon as 3.1.4 is released) that covers how to handle preferences. If you want to continue to use the 3.9 preferences, you need to delete one file.
Title: Re: The Os 3.1.4 Thread
Post by: number6 on September 27, 2018, 04:43:21 PM
@Thomas Richter

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?

This is not a big issue to me, but I get questions...

#6
Title: Re: The Os 3.1.4 Thread
Post by: olsen on September 27, 2018, 05:03:15 PM
Did you or Olaf speak to Detlef Würkner (tetisoft)?

Not to my knowledge. Porting code from OS4 is a thorny issue indeed.

Some of the earlier work on OS4 (2003-2007) was still built and tested on 68k machines before it was ported and developed further on PPC hardware. This is code which is both useful or interesting and likely to port easiest, but it is also code which has not been touched in more than 10 years. I still believe it would be a good idea to look at what we have in the archives, but code review and rework are guaranteed to follow. As small as the team was, this was not always an option.

Another constraint results from the code ownership. We can only work with material for which the author and owner consents that it may be adapted. So far we have limited ourselves to material for which the author's consent had already been granted or was easily obtained. Please do not assume that the "easy way" was at all easy in the end. It was "just" a trade-off in terms of time and manpower. Even something seemingly simple such as the whole set of tools and drivers for mass storage devices (e.g. scsi.device, HDToolbox, ProdPrep) quickly ballooned and required that we seek advice before finding an acceptable solution to apply fixes and enhancements. This kind of thing happened again and again over time. And the HDToolbox saga, for example, still is not over -- some of the work we began has in fact turned into research projects.

If anything, the Amiga operating system and its components are, or have become over the course of a decade, more demanding of finding clever ways to resolve their shortcomings, or to find robust workarounds.
Title: Re: The Os 3.1.4 Thread
Post by: number6 on September 27, 2018, 05:12:21 PM
Did you or Olaf speak to Detlef Würkner (tetisoft)?

Not to my knowledge. Porting code from OS4 is a thorny issue indeed.

Some of the earlier work on OS4 (2003-2007) was still built and tested on 68k machines before it was ported and developed further on PPC hardware. This is code which is both useful or interesting and likely to port easiest, but it is also code which has not been touched in more than 10 years. I still believe it would be a good idea to look at what we have in the archives, but code review and rework are guaranteed to follow. As small as the team was, this was not always an option.

Another constraint results from the code ownership. We can only work with material for which the author and owner consents that it may be adapted. So far we have limited ourselves to material for which the author's consent had already been granted or was easily obtained. Please do not assume that the "easy way" was at all easy in the end. It was "just" a trade-off in terms of time and manpower. Even something seemingly simple such as the whole set of tools and drivers for mass storage devices (e.g. scsi.device, HDToolbox, ProdPrep) quickly ballooned and required that we seek advice before finding an acceptable solution to apply fixes and enhancements. This kind of thing happened again and again over time. And the HDToolbox saga, for example, still is not over -- some of the work we began has in fact turned into research projects.

If anything, the Amiga operating system and its components are, or have become over the course of a decade, more demanding of finding clever ways to resolve their shortcomings, or to find robust workarounds.

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
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter 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".
Title: Re: The Os 3.1.4 Thread
Post by: number6 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
Title: Re: The Os 3.1.4 Thread
Post by: Romanujan 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).
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver 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.
Title: Re: The Os 3.1.4 Thread
Post by: SnkBitten 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....:)

 
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter 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.
Title: Re: The Os 3.1.4 Thread
Post by: olsen 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 ;)
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter 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.
Title: Re: The Os 3.1.4 Thread
Post by: number6 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
Title: Re: The Os 3.1.4 Thread
Post by: BozzerBigD 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?
Title: Re: The Os 3.1.4 Thread
Post by: Louis Dias 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?
Title: Re: The Os 3.1.4 Thread
Post by: olsen 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.
Title: Re: The Os 3.1.4 Thread
Post by: number6 on September 30, 2018, 02:27:27 PM
@thread

newish information (http://eab.abime.net/showpost.php?p=1272752&postcount=311)

#6
Title: Re: The Os 3.1.4 Thread
Post by: kolla 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.
Title: Re: The Os 3.1.4 Thread
Post by: kolla 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.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 30, 2018, 07:01:11 PM
And we're done.... Available immediately:

http://www.hyperion-entertainment.com/index.php/where-to-buy/direct-downloads/188-amigaos-314
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 30, 2018, 07:27:15 PM
Here we have a couple of FAQs.

One is the general installation FAQs,
one is the general FAQ, and finally,
Robert Miranda from ex-GVP Tech support provided a FAQ for GVP Turbo Boards and their installation with 3.1.4.

Os 3.1.4 is available immediately here:
 
http://www.hyperion-entertainment.com/index.php/where-to-buy/direct-downloads/188-amigaos-314
Title: Re: The Os 3.1.4 Thread
Post by: Oldsmobile_Mike on September 30, 2018, 07:50:48 PM
Probably stretching this request, but any side-by-side screenshots of the 3.1.4 prefs programs with the 3.9 ones?
Title: Re: The Os 3.1.4 Thread
Post by: utri007 on September 30, 2018, 08:19:07 PM
Bought and got mail from support@2checkout.com with serial. But can't register. Says "Invalid serial number. Please try again".

Double check it two different web browsers and 100% serial is correct.

Download link in mail does work, so problem is partially sorted out.

I curious, what kind of icon set there is for A500/A600/A2000?
Title: Re: The Os 3.1.4 Thread
Post by: shaf on September 30, 2018, 09:22:10 PM
It worked for me.

Title: Re: The Os 3.1.4 Thread
Post by: utri007 on September 30, 2018, 10:01:55 PM
It worked for me.

I should have waited, still can't register.
Title: Available now: AmigaOS 3.1.4
Post by: bubbob42 on September 30, 2018, 10:14:33 PM
It's done - you can now buy AmigaOS 3.1.4.


This product is based on OS3.1, but many components are more advanced than their OS 3.9 counterparts. More than 200 bugs have been fixed. Support for large media has been integrated into the system--no more hassle with small boot partitions. We'll post more details in the days to come.

The system is sold as digital download for now. The package includes ADFs of the classic six OS disks and a model-specific module disk. The latter allows for installation of 3.1.4 together with older V40.x Commodore, AmigaTechnologies or Hyperion ROMs. We didn't test Cloanto ROMs, but they might work.

In the package you'll also find two variants of ROM-images: .bin-format files for those who'd like to burn the ROM(s) themselves and also a single ROMImage file, which can be used with MapROM or emulation. The latter is needed for Vampire cards as well. If you're using the ROM, you won't need the module disk at all. On the disks you'll also find an upgraded intuition.library (V45). It's currently not CyberGfx-compatible, though we tried our best. You can activate it using LoadModule and it’ll allow you to move windows across the screen's borders.

After some delay you'll be able to buy a bundle containing a physical ROM and a set of disks from dealers. This will always include the digital download.

You'll need different bundles for A500/A600/A2000 or A1200, A3000, A4000D and A4000T.

We recommend the A1200 bundle for Vampire owners. Please note that Hyperion cannot offer any support when using the OS with the Vampire, since it's a system evolving constantly. Please check the ApolloTeam website for more information. I'd like to emphasize that we had a very productive and pleasant cooperation.

The system requirements: 68000, 2MB of RAM.

A new and exclusive icon GlowIcon set done by Masion is included on the storage disk. We'll supply more icons in this style later. By default, reworked classic icons with four colours will be installed.

Buy it here:

http://www.hyperion-entertainment.co...88-amigaos-314

Attached are a few screenshots - we hope you'll enjoy the product! :)



Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on September 30, 2018, 11:56:40 PM
BestWB 1.0 is out

http://lilliput.amiga-projects.net/BestWB.htm
Title: Re: The Os 3.1.4 Thread
Post by: giZmo350 on October 01, 2018, 12:18:05 AM
BestWB 1.0 is out

http://lilliput.amiga-projects.net/BestWB.htm

Dang! That was freaky fast!  ;D
Thanks Gulliver!

Does anyone remember where that post was that provided a script to update OS3.5/3.9 with the new components of this OS3.1.4?
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on October 01, 2018, 12:21:49 AM
BestWB 1.0 is out

http://lilliput.amiga-projects.net/BestWB.htm

Dang! That was freaky fast!  ;D
Thanks Gulliver!

Does anyone remember where that post was that provided a script to update OS3.5/3.9 with the new components of this OS3.1.4?

I uploaded it to Aminet (http://aminet.net/misc/os/Updateto314.lha)
Title: Re: The Os 3.1.4 Thread
Post by: giZmo350 on October 01, 2018, 12:24:11 AM
BestWB 1.0 is out

http://lilliput.amiga-projects.net/BestWB.htm

Dang! That was freaky fast!  ;D
Thanks Gulliver!

Does anyone remember where that post was that provided a script to update OS3.5/3.9 with the new components of this OS3.1.4?

I uploaded it to Aminet (http://aminet.net/misc/os/Updateto314.lha)

You da Man Gulliver! Thanks again!
 :) ;) :D ;D 8)
Title: Re: The Os 3.1.4 Thread
Post by: guest21671 on October 01, 2018, 07:33:02 AM
I wonder whatever happened to Amiga OS 3.2.
Title: Re: The Os 3.1.4 Thread
Post by: AdvancedFollower on October 01, 2018, 08:18:08 AM
Will this work with a MiST running the AGA core?
Is it possible to install it on top of ClassicWB 3.1 Lite, or do you have to install it on a clean Workbench?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 01, 2018, 09:18:06 AM
The update is made for the physical 68K based real Amiga machines, so that is what we promise where it works. No promises for the MiST, of course, but it would astonish me if it would not work.

It comes with its installation script that performs a clear install. Even though this is the recommended way of installation, you will then get a workbench that looks exactly like the 3.1 workbench.
Title: Re: Available now: AmigaOS 3.1.4
Post by: nicholas on October 01, 2018, 09:58:34 AM

After some delay you'll be able to buy a bundle containing a physical ROM and a set of disks from dealers. This will always include the digital download.

Excellent, looking forward to upgrading the A3K.  Any ETA on when the physical ROMs will be available?
Title: Re: The Os 3.1.4 Thread
Post by: boemann on October 01, 2018, 12:29:03 PM
So what exactly is the difference between the various ROMs.

I have an A1000 that I'd like to twinkick
But I'm also going to install vampire on it later on.

So would I need two different versions or..?
Not to speak of trying it out in  UAE
Will one version fail where anothe one works and vice versa?

I really would like to what the differences are
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 01, 2018, 01:08:58 PM
So what exactly is the difference between the various ROMs.
The difference is which subsystems are included in the ROMs, in particular for hardware-near components. Unfortunately, CBM did not follow their own design principles and hard-coded a couple of decisions. For example, the A4000 ROM contains a RAM-Test for static column DIMMs that would, in this form, crash any other machine. Some machines include a "real" scsi.device, such as the A3000, some an IDE "emulation layer" such as the A4000.

At least, we have now a generic AGA/ECS graphics that is exactly the same on both machines.

I have an A1000 that I'd like to twinkick
But I'm also going to install vampire on it later on.
Well... there is no A1000 ROM, so we cannot guarantee that things will work on this machine, but it is quite likely (actually, very likely) that the A500 ROM will do, all provided the machine even takes a 512K ROM.

The vampire is just another beast. What the vampire team currently recommends is to go for the A1200 ROM. So for your particular setup, you need two ROMs, yes. A500 is a 16-bit ROM, A1200 is a 32-bit ROM, and their contents is different due to differring machine components.

Will one version fail where anothe one works and vice versa?
That is very likely, indeed. It all goes back to a couple of not-so-wise decisions and not following the own engineering guidelines in-house at CBM, and ignoring the same guidelines later on for the vampire. Sorry for that, but we cannot fix that.


Title: Re: Available now: AmigaOS 3.1.4
Post by: giZmo350 on October 01, 2018, 01:30:33 PM
We didn't test Cloanto ROMs, but they might work.

This irks me as the only ROMs available within the last year or so have been Cloanto ROMs (@amigakit). However, AOTL does sell Hyperion ROMs. I'm sitting on 3 Cloanto A500 3.1 ROMs and wish I had bought from AOTL now.

I realize that 3.1.4 ROMs are recommended for the updated OS but as it stands those are not available as yet. So using MapROM seems to be the only option at this time if using Cloanto ROMs.(?)

Has anyone tried OS3.1.4 with Cloanto ROMs yet?

Good to see that the Hyperion vs Cloanto conflict has affected the project.  :-\
Title: Re: Available now: AmigaOS 3.1.4
Post by: Thomas Richter on October 01, 2018, 01:42:43 PM
I realize that 3.1.4 ROMs are recommended for the updated OS but as it stands those are not available as yet. So using MapROM seems to be the only option at this time if using Cloanto ROMs.(?)
Not really. I would just go for the default software installation, and LoadModule will take care of it. MapRom is not required for that. In fact, a physical ROM is not required for 3.1.4.

Of course, the usual disclaimer applies. How can a vendor give you a warranty for a product that was developed elsewhere and they have not tested with? 3.1.4 works with the original 3.1 ROMs, that is something we can ensure. I would be surprised if it would not work with Cloanto, but... no promises.

Title: Re: Available now: AmigaOS 3.1.4
Post by: giZmo350 on October 01, 2018, 01:59:29 PM
I realize that 3.1.4 ROMs are recommended for the updated OS but as it stands those are not available as yet. So using MapROM seems to be the only option at this time if using Cloanto ROMs.(?)
Not really. I would just go for the default software installation, and LoadModule will take care of it. MapRom is not required for that. In fact, a physical ROM is not required for 3.1.4.

Of course, the usual disclaimer applies. How can a vendor give you a warranty for a product that was developed elsewhere and they have not tested with? 3.1.4 works with the original 3.1 ROMs, that is something we can ensure. I would be surprised if it would not work with Cloanto, but... no promises.

Thanks for the reply THoR.... I don't have any unrealistic expectations with this new OS3.1.4. However, I would think that this updated OS might present a predicament to any vendor selling Cloanto ROMs going forward (what ever complication that might be). Like you said, might not be a problem, but I was never happy buying Cloanto ROMs in the first place, especially when that's not what I ordered but received anyway. I know, not your fault.

Errr yea, I meant LoadModule.  :o

Ah, such as life....  I don't mean to rant.   ;)

I'm just going to wait to purchase until the new ROMs are available. Guess I'll use the Cloanto ROMs for mini hockey pucks! LOL

BTW, I highly recommend that anyone considering purchasing OS3.1.4 read the FAQ.txt first! Especially if you don't plan on purchasing the 3.1.4 ROMs. Very good information in there!

http://eab.abime.net/showpost.php?p=1273051&postcount=10
Title: Re: The Os 3.1.4 Thread
Post by: number6 on October 01, 2018, 03:00:45 PM
Apologies in advance for somewhat off topic, but I'm concerned about this:

@bubbob42

Would you please do something about the facebook page.

By having the April posting as the last current legal status, how can one draw any other conclusion that you still have an issue re:

Quote
As of today "AmigaOS Workbench 3.1 (40.43) for desktop Amiga" is available again as digital download ! For now only in the European Economic Area but we are working to go worldwide again soon.

Quote
It is not meant to replace our official website, support forum, development blog or other resource, but to complement them

How does the above information "complement" the official website?

#6
Title: Re: The Os 3.1.4 Thread
Post by: bubbob42 on October 01, 2018, 03:29:34 PM
@bubbob42

Would you please do something about the facebook page.


Sorry - I'm neither representing Hyperion nor am I part of Hyperion. Just a developer posting information because Hyperion cannot look after every forum.

The Facebook page will surely get an update in the next few days.
Title: Re: The Os 3.1.4 Thread
Post by: AdvancedFollower on October 01, 2018, 05:45:55 PM
The update is made for the physical 68K based real Amiga machines, so that is what we promise where it works. No promises for the MiST, of course, but it would astonish me if it would not work.

It comes with its installation script that performs a clear install. Even though this is the recommended way of installation, you will then get a workbench that looks exactly like the 3.1 workbench.

Just tried it on my MiST running Minimig-Mist 1.2.3 Beta and it seems to work fine. I was able to boot both from the ADF and from a 4 GB .HDF which I had prepared in WinUAE.

When adding BestWB to the install, it crashes on the next boot (on the MiST but not in WinUAE). "Software Failure - ramlib #80000004". However that's not related to OS 3.1.4 itself of course, since that's a third party modification. I'm guessing it's adding something to the startup-sequence, Devs: or somewhere that's not compatible. Will have a look later.


Edit: Turns out the problem was 68020.library that BestWB installs. Removed that and it works great now. So if any of the other 5 people who own a MiST want to try it, that's what you have to do  :-*
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 01, 2018, 06:04:11 PM
Best guess - the SVX datatype? Please remove it. The 8SVX can play stereo samples just fine now.
Title: Re: The Os 3.1.4 Thread
Post by: madgrizzle on October 01, 2018, 06:40:58 PM
I have a KS 3.1 for my 3000 that's been modified to allow for a 060 with FPU.  If I understand what's been posted, I don't need to change the ROM and can just use the disks and modules disk?  I'm fairly green on this stuff..
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 01, 2018, 06:56:47 PM
I have a KS 3.1 for my 3000 that's been modified to allow for a 060 with FPU.  If I understand what's been posted, I don't need to change the ROM and can just use the disks and modules disk? 

Yes, you can. The system will then go through one reboot on the coldstart to install the new modules.
Title: Re: The Os 3.1.4 Thread
Post by: utri007 on October 01, 2018, 10:29:40 PM
I'm trying to make 1mb kickstart. Everything OK, but I just can't get new exec work. Everything else works, with bb2 exec, but if I try 3.1.4 exec it just doesn't work. Currently I have only tried with WinUAE.
Title: Re: The Os 3.1.4 Thread
Post by: SnkBitten on October 02, 2018, 03:22:31 AM
Booted Amithlon using the 3.1.4 kickstart and 3.1.4 Workbench successfully.  Installed WB 3.1.4 inside WinUAE then compressed (.lha) the volume and moved it over to my Amithlon system.  Uncompressed it to a newly created volume (made bootable) and replaced the kickstart in smallird.gz with the A2000 3.1.4 kickstart.   I had to copy a few files over (Amithlon specific stuff) and modify the startup-sequence but it booted without issue.  The new intuition.library works fine as well allowing windows to be moved off the edges.  I have a LOT of work to make it similar to my OS 3.9 setup but I want to see how well it compares.
Title: Re: The Os 3.1.4 Thread
Post by: Dynamic_Computing on October 02, 2018, 04:50:00 AM
Amiga OS 3.1.4 question - I decided to to a fresh install on my A4000 Desktop with my Warp Engine. I have two big SCSI drive - 74 Gig and 300 Gig that both worked 100% on OS 3.9. With 3.1.4 I installed from floppy, changed my tooltype on HDtoolbox to warpdrive.device, and created a nice 4 Gig Workbench partition. OS installed just fine with no errors.
Now after booting up, HDToolbox sees my drives and I can partition them, but no matter what size I partition them formatting gives me a "Seek Failure" error and cancels the format. Tried different sizes, different drives, same error. Original 4 Gig works fine on my 74 Gig drive, but I can't format anything else. Possible bug with OS 3.1.4 with Warpengine?
Again, these drives have been working perfect with Amiga OS3.9.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 02, 2018, 05:34:25 AM
Possible bug with OS 3.1.4 with Warpengine?
Again, these drives have been working perfect with Amiga OS3.9.
No, possible bug in Warpengine. Please go, check the FAQ. Edit the partitions, set the "Direct SCSI" flag, save the partitions back, reboot, and all will be fine.
Or, if that is too much, install NSDPatch, it's on the installer disk. The latter I consider a kludge, but anyhow, it's your system, do as you like.

In 3.9 "NSDPatch" was hard-wired into SetPatch. It is no longer required, the FFS can speak SCSI itself if you ask for it.
Title: Re: The Os 3.1.4 Thread
Post by: Dynamic_Computing on October 02, 2018, 05:50:32 AM
Thank you, Thomas Richter! I honestly did not try the "Direct SCSI" Flag, although I did see it. I will try that right away. Thanks for the help.

Edit - checking the direct SCSI switch did the trick. All is well
Title: Re: The Os 3.1.4 Thread
Post by: kolla on October 02, 2018, 09:18:09 AM
I bought this for Minimig, but I cannot legally use it.

Quote
This license allows you to install or operate the AmigaOS only on a computer system that had a version of AmigaOS installed on it at the time you acquired such computer system, which was especially prepared for running AmigaOS through the use of a dedicated (flash)rom or similar mechanism or for which a legitimate version of AmigaOS was or is available.
Title: Re: The Os 3.1.4 Thread
Post by: boemann on October 02, 2018, 10:10:18 AM
You need to update the installation readme.

For installing the new intuition library you also need to copy the loadmodule from the modules file

It also seems like you need to do
C:LoadModule module libs:intuition.library

as romupdate will stop once it finds out filesystem is already v 46
Title: Re: The Os 3.1.4 Thread
Post by: nicholas on October 02, 2018, 10:16:40 AM
I bought this for Minimig, but I cannot legally use it.

Quote
This license allows you to install or operate the AmigaOS only on a computer system that had a version of AmigaOS installed on it at the time you acquired such computer system, which was especially prepared for running AmigaOS through the use of a dedicated (flash)rom or similar mechanism or for which a legitimate version of AmigaOS was or is available.

Were you informed of this at Point of Sale?

If not then you are entitled to a full refund. In England at least. Dunno about in Viking country.
Title: Re: The Os 3.1.4 Thread
Post by: bubbob42 on October 02, 2018, 01:01:00 PM
"or for which a legitimate version of AmigaOS was or is available."

Come on kolla, which OS did you use before on the Minimig? AtariTOS? Stop nitpicking, consider it as an A500 and use the package. How would you be able to write more rants if you don't have first hand experience of the thing? :D
Title: Re: The Os 3.1.4 Thread
Post by: kolla on October 02, 2018, 01:29:12 PM
"or for which a legitimate version of AmigaOS was or is available."

Come on kolla, which OS did you use before on the Minimig?

(http://kolla.no/minimig/IMG_0003.jpg)
(http://kolla.no/minimig/IMG_6357.jpg)
(http://kolla.no/minimig/IMG_6359.jpg)

Looks legit, doesn't it?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 02, 2018, 01:38:07 PM
Don't feed the troll. He'll go away if you leave him alone.
Title: Re: The Os 3.1.4 Thread
Post by: bubbob42 on October 02, 2018, 03:27:09 PM
Don't feed the troll. He'll go away if you leave him alone.

But he's such a cute bear, so hard to ignore. :D
Title: Re: The Os 3.1.4 Thread
Post by: outlawal2 on October 02, 2018, 05:53:07 PM
Seriously Kolla?  <smh>
Stop wasting everyones time. AGAIN

Anyway, I apologize for not reading all of the previous pages, but the question I have is if I want to use this on my A1200 and my A3000 I need to order it twice?  Is this correct?  Also, will this version run with the ROMs I currently have installed or do I need new ones? 

Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 02, 2018, 06:43:43 PM
The question I have is if I want to use this on my A1200 and my A3000 I need to order it twice? 
Yes. Two systems, two licenses, and two different(!) kickstarts, and also two different sets of modules (and module disks). For example, the scsi.device is different, and the A3000 contains additional components for configuring its RAM timing that will not work on the A1200.

Also, will this version run with the ROMs I currently have installed or do I need new ones?
This depends on your liking. Two options exist: One with the current ROMs and a RAM-Upgrade only. This version requires a reboot like 3.9 did, and one version which contains a ROM image (at this time). Separate ROMs will become available from dealers. If you buy physical ROMs and disks from a dealer, this will contain a serial number which will allow you to download the electronic edition as well.


Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 02, 2018, 06:47:34 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).

The picture datatype is a slim version again, only 68K. But the same features, plus a couple of bug fixes on the way.
Title: Re: The Os 3.1.4 Thread
Post by: outlawal2 on October 02, 2018, 06:54:18 PM
Thanks!
Title: Re: The Os 3.1.4 Thread
Post by: Jiffy on October 02, 2018, 09:20:01 PM
Very nice. Any information about when this will become available completely with the updated ROMs?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 02, 2018, 09:25:40 PM
Any information about when this will become available completely with the updated ROMs?
I afraid none of us here works for Hyperion. I believe it all depends now on negotiations with dealers and how fast they can deliver.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on October 02, 2018, 10:01:07 PM
Dunno about in Viking country.

In Viking country, such "easter egg" agreements are by their very nature void. Also void is any attempt at preventing software from running on hardware by terms of licenses - you can run whatever software you have bought on whatever hardware you own, even if it means modifying the software.

Such a clause in the "EULA" of this OS release is straight out pointless and bewildering.
Title: Re: The Os 3.1.4 Thread
Post by: First Ninja on October 02, 2018, 10:24:10 PM
If you have technical questions around this release, you may try it here - I'll try to look into them from time to time, all hoping that things don't go overboard, and I hope some members of the development and beta-tester team will do so as well.

First off - please let me say I'm really psyched about the update, and that I'm eager to get my hands on it as soon as the ROM chips are available to buy! I think it's nothing short of commendable of you guys to show the AmigaOS community the kind of devotion you have. Hopefully, the recent surge of interest in AmigaOS hardware should reflect back on the sales, too. Here's hoping it'll be the success it truely deserves to be!

Now, and for my question - I happen to have a CD32, and with a bit of luck I'll have a CDTV sometime in the near future, too. Are there any plans to bring these platforms on par with the rest of the MC680x0-based AmigaOS systems?

Please pass on my very best to the rest of the team - it's an outstanding piece of work and again, the community has every reason to feel grateful for all of your work!
Title: Re: The Os 3.1.4 Thread
Post by: bubbob42 on October 02, 2018, 11:39:13 PM
Now, and for my question - I happen to have a CD32, and with a bit of luck I'll have a CDTV sometime in the near future, too. Are there any plans to bring these platforms on par with the rest of the MC680x0-based AmigaOS systems?

We left both machines out because we lacked resources (developers) and had to focus our efforts. I own two CDTVs myself (one with upgraded bootroms) and a CD32, but never had the the time to even try 3.1.4 ROMs with either of them. If a buyer reports an A500 ROM working fine with a CDTV, I'll be the first (ok, second ;) ) to cheer.

Just assume we're interested in supporting these machines in the future. The status of the CD32's material is bit uncertain, though. At the end of the Commodore era, some bits and pieces may have gone missing. So no promise here, just willingness.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 03, 2018, 06:13:49 AM
Now, and for my question - I happen to have a CD32, and with a bit of luck I'll have a CDTV sometime in the near future, too. Are there any plans to bring these platforms on par with the rest of the MC680x0-based AmigaOS systems?
First, thanks for the flowers, appreciated.

Concerning the CD32: We should have somewhere, deeply hidden in the archive, the sources for the system, but they require some care, review and testing before they could be released. To give you some idea: We had a new exec library ready, but - according to one of our testers - it managed to disable the CD-Rom, without which the CD32 is a bit pointless. It turned out that this is because the CD32 has some even cheaper, but less compatible emulation of the "IDE interface" (which is really only a couple of gates) in one of its custom chips that is not entirely compatible, and the exec hardware detection logic apparently disabled that as a side effect. Even though we made some attempts to fix it, the issue never really went away, and it may require some additional changes in the scsi.device we do not know. So yes, there is certainly willingless, but it is much more of an effort than one might guess.

For the CDTV, the situation is even less rosy. As far as I know, we do not even have the sources anymore, so the question in how far it could be supported. Given that most programs for it were written with the modified 1.3 in mind, it is also questionable in how far this attempt would be worth it. I would expect a couple of compatibility problems at least, so the potential end result is probably less useful than one might hope.

Title: Re: The Os 3.1.4 Thread
Post by: kolla on October 03, 2018, 07:23:21 AM
Just installed, and some first impressions....

* The Norwegian locales are horrid. Not the original CBM ones, but all locales that are new look like they are written by someone with seriously lacking knowledge about the Norwegian language.
* The Reboot command is still not installed, why oh why not.
* Cool to see Ed using current console window
* Too much ">NIL:" in the startup-sequence - F.ex. Assign is already quiet, as is Path, if an assign or path fails, wouldn't the user be better off being told so?
* Apparently random use of (redundant) full path to programs in startup-sequence, C:SetPatch instead of just "SetPatch", while BindDrivers gets to be left without C: in front of it.
* Where are the new icons? Are they not part of the release for A1000/A500/A600/A2000?
Title: Re: The Os 3.1.4 Thread
Post by: AdvancedFollower on October 03, 2018, 08:54:05 AM
Dunno about in Viking country.

In Viking country, such "easter egg" agreements are by their very nature void. Also void is any attempt at preventing software from running on hardware by terms of licenses - you can run whatever software you have bought on whatever hardware you own, even if it means modifying the software.

Such a clause in the "EULA" of this OS release is straight out pointless and bewildering.

They probably had to put the clause there due to ongoing disputes. Remember, every cent you give Hyperion or Cloanto goes straight to the pockets of lawyers. The money is not spent evolving the Amiga platform.
Title: Re: The Os 3.1.4 Thread
Post by: bubbob42 on October 03, 2018, 09:19:05 AM
Ah, our friend again.

* The Norwegian locales are horrid. Not the original CBM ones, but all locales that are new look like they are written by someone with seriously lacking knowledge about the Norwegian language.

I'm pretty confident that our native norwegian translator will take suggestions. Just make sure to keep the length limits.

Quote
* The Reboot command is still not installed, why oh why not.

If this issue is so dear to you, I might consider it for the next update. Who could resist that bear?


Quote
* Cool to see Ed using current console window

Try to delete a line using del-key. So many little things which should have been done ages ago spread all over the OS.


Quote
* Apparently random use of (redundant) full path to programs in startup-sequence, C:SetPatch instead of just "SetPatch", while BindDrivers gets to be left without C: in front of it.

And your point is?

Quote
* Where are the new icons? Are they not part of the release for A1000/A500/A600/A2000?

You missed that, how could you! Posted in three forums and sure soon part of Hyperion AmigaOS3.1.4 FAQ on the website.

Btw.: How's your web-based ROM generator coming along?
Title: Re: The Os 3.1.4 Thread
Post by: kolla on October 03, 2018, 09:35:37 AM
They probably had to put the clause there due to ongoing disputes. Remember, every cent you give Hyperion or Cloanto goes straight to the pockets of lawyers. The money is not spent evolving the Amiga platform.

Indeed - which I find it it so fulfilling to support this effort - I much rather see lawyers getting the money than the developers. It is refreshing to see that the developers think so too.

Regarding the "clause", if it means what it says, they could just written that one can install it on any system one see fit. The only situation it would make sense to word it such manner, is if Hyperion intends to declare certain earlier versions/distributions of AmigaOS somehow "illegal". To add the confusion, OS 3.1.4 comes with kickstart for emulation use.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on October 03, 2018, 10:02:26 AM
I'm pretty confident that our native norwegian translator will take suggestions. Just make sure to keep the length limits.

It is just too much. I suggest the person takes contact with people or organisations that actually do translations.
For example, the KDE team has some good people, and Språkrådet (the person should know this) offers help for free too, and we have free to use online dictionaries.
Do you have .ct files available? I can rewrite them for you for free, I need to do something about the Workbench menus anyways (random use of uppercase in menu entries, "Leer Zeichen In Kom Po Sita")

Quote
And your point is?

Consistency is king.

Quote
You missed that, how could you! Posted in three forums and sure soon part of Hyperion AmigaOS3.1.4 FAQ on the website.
Good, I can imagine that.

Quote
Btw.: How's your web-based ROM generator coming along?

The web-frontend to amitools' romtool.py? Last I did anything with it, it worked fine.

Another thing I noticed...
* Serial Prefs still tops at "MIDI speed".
Title: Re: The Os 3.1.4 Thread
Post by: bubbob42 on October 03, 2018, 10:14:14 AM
Another thing I noticed...
* Serial Prefs still tops at "MIDI speed".

Yes, this was actually different half a year ago. However, Thomas suspected that this setting would be deeply ingrained into relicts of OS1.3 system prefs structures which are still in use, so simply changing the gadget did not suffice. And - as usual - he was right. We'll dig up this pit later.
Title: Re: The Os 3.1.4 Thread
Post by: Mr_Byte on October 03, 2018, 01:23:01 PM
As i understand: The included filesystem and everything will work with big harddrives from the box..Is there any advantages to use another fs like PFS, if i use the standard ide44 on my amiga 1200?
Title: Re: The Os 3.1.4 Thread
Post by: bubbob42 on October 03, 2018, 01:28:52 PM
Both file systems have their advantages and drawbacks. It’s a matter of use case and taste.

Toni added support for HDToolbox’s new direct scsi setting in PFS3, btw.

Edit: And he repaired it for his latest release
Title: Re: The Os 3.1.4 Thread
Post by: Rotzloeffel on October 03, 2018, 01:29:59 PM
As i understand: The included filesystem and everything will work with big harddrives from the box..

If you have a physical Rom, yes at power on
Title: Re: The Os 3.1.4 Thread
Post by: lumby on October 03, 2018, 01:53:48 PM
@Thomas Richter

I have bought a copy for my A4000 but have discovered that Danish is no longer available.
I think I have not been mentioned anywhere?
Title: Re: The Os 3.1.4 Thread
Post by: bubbob42 on October 03, 2018, 02:23:23 PM
Danish and swedish are currently being prepared.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 03, 2018, 02:57:46 PM
As i understand: The included filesystem and everything will work with big harddrives from the box..
Yes. If you do not have a ROM, you can also put this into the RDB of the harddrive, and you *may* have to turn on the DirectSCSI flag in HDToolBox. There are multiple options. Please check the FAQ.

Is there any advantages to use another fs like PFS, if i use the standard ide44 on my amiga 1200?
How can I tell you? FFS is the system 3.1.4 was designed and tested for, including all the tools and utilities like "Format", "HDToolBox" and "Diskdoctor" (yes, the doctor is back, thanks Olaf!). It supports hardlinks and softlinks (now correctly) with all the command line tools provided.

FFS is certainly an archaic file system, and it is not particularly smart, but it should work quite fine.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 03, 2018, 02:59:10 PM
If you have a physical Rom, yes at power on
Not even that is required. It is sufficient to put the FFS into the RDB. HDToolBox can do that for you. Steps are in the FAQ.

Title: Re: The Os 3.1.4 Thread
Post by: eliyahu on October 03, 2018, 04:15:10 PM
@Thomas

is there any plan to add a new forum at support.amigaos.net (the official hyperion support site) for OS 3.1.4?

-- eliyahu
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 03, 2018, 04:23:23 PM
is there any plan to add a new forum at support.amigaos.net (the official hyperion support site) for OS 3.1.4?

There should be - isn't there one? It's really up to Hyperion to set one up - I'm not an employee of Hyperion, though.
Title: Re: The Os 3.1.4 Thread
Post by: LiveForIt on October 03, 2018, 05:17:01 PM
Hyperion has a support forum.

http://forum.hyperion-entertainment.biz
Title: Re: The Os 3.1.4 Thread
Post by: eliyahu on October 03, 2018, 05:33:11 PM
Hyperion has a support forum.

http://forum.hyperion-entertainment.biz (http://forum.hyperion-entertainment.biz)

yes, i know that. that's the same site i pointed to. what i asked was if -- on that site -- hyperion was planning on adding a new forum to address support questions/issues for OS 3.1.4.

-- eliyahu
Title: Re: The Os 3.1.4 Thread
Post by: LoadWB on October 03, 2018, 05:49:32 PM
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.

Period?  Speaking for yourself, of course.  I quite happily used HP printers on my parallel port without purchasing TurboPrint -- in fact I only learned of its existence around OS3.9 when people were discussing broken print drivers and how to roll them back.
Title: Re: The Os 3.1.4 Thread
Post by: bubbob42 on October 03, 2018, 07:40:50 PM
Please use the “classic” subforum for now.

Hyperion has a support forum.

http://forum.hyperion-entertainment.biz (http://forum.hyperion-entertainment.biz)

yes, i know that. that's the same site i pointed to. what i asked was if -- on that site -- hyperion was planning on adding a new forum to address support questions/issues for OS 3.1.4.

-- eliyahu
Title: Re: The Os 3.1.4 Thread
Post by: F1Lupo on October 03, 2018, 07:54:36 PM
I only see downloads on Hyperion site but where do we buy physical roms then ?? ???
Title: Re: The Os 3.1.4 Thread
Post by: LiveForIt on October 03, 2018, 08:14:45 PM

Only digital download for now,
I guess you buy it from AmigaKit when roms are burned.
or else you can pick up eprom bruner from ebay.
Title: Re: The Os 3.1.4 Thread
Post by: BozzerBigD on October 03, 2018, 09:48:27 PM
@LoadWB

Quote
I quite happily used HP printers on my parallel port without purchasing TurboPrint

Maybe if more people had bought TurboPrint and seen its value IrseeSoft would still be in the Amiga market! You obviously weren't into printing 24-bit graphics then?! TurboPrint was worth it for the Graphics Publisher program on its own IMHO. The difference was night and day between the native printer drivers and TurboPrint's and by around 1996 the difference was embarassing. C= sucked at updating Workbench and the Amiga graphics chips, their two biggest failures. Third party software took over to fill the void as did third party accelerators and RTG cards. OS3.9 was the obvious pinnacle of third party contributor/kludge based OS development post-Commodore. OS3.9 works better than we have a right to expect considering and with TurboPrint, CrossDos and AsimCDFS installed in addition to Boing Bags 1 & 2 I really can't see how OS 3.1.4 is any match for my current system except that the code is probably much neater  ;D

Please explain how a custom OS3.1.4 installation to update elements of my OS3.9 system would be worth my time/money?
Title: Re: The Os 3.1.4 Thread
Post by: F1Lupo on October 03, 2018, 10:06:22 PM
.... OS3.9 works better than we have a right to expect considering and with TurboPrint, CrossDos and AsimCDFS installed in addition to Boing Bags 1 & 2 I really can't see how OS 3.1.4 is any match for my current system except that the code is probably much neater  ;D

Please explain how a custom OS3.1.4 installation to update elements of my OS3.9 system would be worth my time/money?
I've got my A4000 and A1200T with OS3.9 BB1 & 2 working fine after many many many hours of tinkering so I'll be hesitant to mess with them now but I have a 1200 that runs OS3.1 only and will definitely buy the update for that since I have no fear of messing anything up on it ;D
btw, I'd love to have this official update for my Amiga 1000 too but don't see it as one of the supported systems sadly

 
Title: Re: The Os 3.1.4 Thread
Post by: BozzerBigD on October 03, 2018, 10:36:23 PM
I saw that one remit/design goal of OS3.1.4 was to make the OS play nicer with 060 boards. However, does this improve upon OS3.9 support plus Oxypatcher / Phase5 support etc? Is this update really for people that stuck to OS3.1 and forgot to buy OS3.5 and OS3.9? I mean I didn't install Boing Bags 3 & 4 because they were unofficial and I found the Boing Bag 2 install painful but that is nothing compared to still using Blue & Grey Worbench 3.1 in 2018! I can see why THOSE Amigans might seriously NEED to upgrade. The rest of us not so much. But I still think this is mainly about stopping Vampire users pirating core OS elements for VampireOS and instead encourage them to pay Hyperion for the pleasure.
Title: Re: The Os 3.1.4 Thread
Post by: First Ninja on October 03, 2018, 10:39:35 PM
Danish and swedish are currently being prepared.

That's great news! You don't happen to need Swedish, semi-professional proofreading on a pro-bono basis? I'm a member of TED Translators (https://www.ted.com/participate/translate), I've done a few jobs for Steam (https://translation.steampowered.com/) and I'd say I know the Swedish Amiga terminology realized by Commodore's Swedish branch quite well.
Title: Re: The Os 3.1.4 Thread
Post by: Tygre on October 03, 2018, 11:25:36 PM
Hi Thomas and all!

I probably come late but I wanted to thank all people involved in working on 3.1.4! It is an amazing feat to have succeeded in reworking, recompiling, modernizing, improving a code base that has been around for such a long time :) You all deserve big thanks and our (my at leat!) admiration for doing this job! It must have been similar to monks doing mediaeval illumination ;) ("Un travail de moine" in French...)

Congrats and thank you!

Pulling windows out of screens is a feature of intuition v45 which will be available for all customers of 3.1.4 as an optional component for installation. Unfortunately, it is only optional because it does not work with cybergraphics.

Unfortunately, CGfx depends on compiler-specific register- and memory allocation of the compiled intuitition v40 code beyond our knowledge, and intuition v40 is the only component which was built with the Greenhill compiler. Unfortunately, the compiler is no longer available, and even if it would, we would not know how to integrate it into the built-system, so we cannot reproduce what Cgfx requires.

We reached out to Frank Mariak asking for insight, and offered an internal interface in intuition v45 for CGfx to reproduce (with some assembly stubs potentially) its requirements. Even some first contact was established successfully, this went unfortunately nowhere.

So, at this time, intuition v45 is for native graphics and P96 only, and only as an optional feature. I would have preferred to offer this as a regular part of 3.1.4, but we cannot risk to loose Cgfx customers.
Title: Re: The Os 3.1.4 Thread
Post by: madgrizzle on October 04, 2018, 03:27:00 AM
I have a KS 3.1 for my 3000 that's been modified to allow for a 060 with FPU.  If I understand what's been posted, I don't need to change the ROM and can just use the disks and modules disk? 

Yes, you can. The system will then go through one reboot on the coldstart to install the new modules.

Is it feasible to make a custom 3.1.4 rom that has whatever modification my current one has?
Title: Re: The Os 3.1.4 Thread
Post by: Tygre on October 04, 2018, 04:48:00 AM
Hi Thomas!

Let me second what Olaf wrote:

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.


Very nice! I'm curious if you could tell us more about testing: do you use test frameworks? What test cases exist? Did you inherit test cases or build your own test suites?

Cheers!
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 04, 2018, 08:44:33 AM
I saw that one remit/design goal of OS3.1.4 was to make the OS play nicer with 060 boards. However, does this improve upon OS3.9 support plus Oxypatcher / Phase5 support etc?
Phase5 was/is a closed universe, they did not provide any information concerning their 68060 support. In fact, there is no CPU library included in the distribution because you should always use the CPU library that came from the vendor of the board. Failing that, use the MMULib-driven CPU libraries which provide an open architecture, and come with comparable or better tools than the ones from many vendors.

Is this update really for people that stuck to OS3.1 and forgot to buy OS3.5 and OS3.9?
No. Many components included in 3.1.4 are more advanced than those shipped with 3.9. All the datatypes are post-3.9, the workbench and icon library are post-3.9, all libraries are post-3.9, the printer device is a hybrid, and the preferences are reworked 3.1 preferences as we do not have reaction. Some of the tools are also somewhere in between 3.1 and 3.9 such as the calculator, the clock, the icon editor, and HDToolbox.


I mean I didn't install Boing Bags 3 & 4 because they were unofficial and I found the Boing Bag 2 install painful but that is nothing compared to still using Blue & Grey Worbench 3.1 in 2018!
I thrust you that you are capable of configuring the workbench to your liking. 3.1.4 allows this to the very same degree 3.1 did and 3.9 did.

But I still think this is mainly about stopping Vampire users pirating core OS elements for VampireOS and instead encourage them to pay Hyperion for the pleasure.
Seriously - no. 3.1.4 development started almost three years ago. There is no conspiracy here. The whole thing started because Olaf more or less suggested it as a "tiny bug fix release", which then went more and more overboard.


Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 04, 2018, 08:48:36 AM
Very nice! I'm curious if you could tell us more about testing: do you use test frameworks? What test cases exist? Did you inherit test cases or build your own test suites?
I wish we had, but there is no automated tool for that in Amiga land I'm aware of. So it was all manual, bug reports in a bug tracker, and new versions every couple of days. The most complicated part about it was that I had to fix bugs in "dry runs", both lacking an Amiga and lacking a printer.
Title: Re: The Os 3.1.4 Thread
Post by: bubbob42 on October 04, 2018, 10:29:00 AM
But I still think this is mainly about stopping Vampire users pirating core OS elements for VampireOS and instead encourage them to pay Hyperion for the pleasure.

Do you really think we wasted thousands of hours of spare time to achieve just that? Especially when we started long before any Vampire/coffin/whateverOS surfaced? Ask yourself: Would this motivate you?

I cannot follow your thoughts, honestly. Especially when you don't have to buy anything and could just enjoy OS3.9. :)
Title: Re: The Os 3.1.4 Thread
Post by: olsen on October 04, 2018, 11:28:21 AM
Very nice! I'm curious if you could tell us more about testing: do you use test frameworks? What test cases exist? Did you inherit test cases or build your own test suites?

Cheers!

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.
Title: Re: The Os 3.1.4 Thread
Post by: olsen on October 04, 2018, 11:43:04 AM
But I still think this is mainly about stopping Vampire users pirating core OS elements for VampireOS and instead encourage them to pay Hyperion for the pleasure.

Do you really think we wasted thousands of hours of spare time to achieve just that?

They built the Eiffel tower to investigate how well the corrosion-proof coating of the cast-iron tower endures the harsh conditions at 320m elevation, near its tip, didn't they? ;)
Title: Re: The Os 3.1.4 Thread
Post by: bubbob42 on October 04, 2018, 12:24:32 PM
They built the Eiffel tower to investigate how well the corrosion-proof coating of the cast-iron tower endures the harsh conditions at 320m elevation, near its tip, didn't they? ;)

You're not being supportive! :D
Title: Re: The Os 3.1.4 Thread
Post by: nicholas on October 04, 2018, 03:00:19 PM
Anyone know why the Hyperion page still charges VAT for those that live outside the EU?
Title: Re: The Os 3.1.4 Thread
Post by: number6 on October 04, 2018, 03:44:23 PM
Anyone know why the Hyperion page still charges VAT for those that live outside the EU?

Source (https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=41399&forum=27&start=420&viewmode=flat&order=0#817262)

Only Hyperion's "fullfillment partner" will respond to that apparently.

#6
Title: Re: The Os 3.1.4 Thread
Post by: olsen on October 04, 2018, 04:26:06 PM
Anyone know why the Hyperion page still charges VAT for those that live outside the EU?

Source (https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=41399&forum=27&start=420&viewmode=flat&order=0#817262)

Only Hyperion's "fullfillment partner" will respond to that apparently.

#6

Not exactly an explanation, but I recently learned how complicated the VAT issue has become for services rendered and goods delivered both within the European Union and from the European Union to non-member states. In my opinion it is quite likely for a payment processor such Avangate to slip up here.

Within the European Union the VAT added on top of the net price used to be the rate current in the country from which it was sold. For example, with the seller in Germany the standard rate of 19% VAT rate would be applied to a customer in Denmark. This was changed recently, and now the VAT rate of the customer has to be applied to the net price, e.g. for a seller in Germany and the customer in Denmark, the standard rate of 25% would have to be applied. Sounds sufficiently complicated, and it certainly is (and gets more so because you have to keep track of the specific payments made and the taxes you charged on top of the net price). It gets more complicated still because of exceptions the individual countries apply to taxation. Luckily, these tend not to affect services and goods rendered through payments made through online service because this has been standardized.

It gets really tricky when you sell from the European Union to a non-member state such as Switzerland or Norway. Services and goods may be taxed differently or not at all, for example. So the buyer may have to pay import taxes on floppy disks and EPROMs, but not on the digital download which contains the same information as the floppy disks and EPROMs (or it might be a reduced tax rate).

There's plenty of opportunity for things to go wrong.
Title: Re: The Os 3.1.4 Thread
Post by: utri007 on October 04, 2018, 04:37:15 PM
Is scsi.device 45.7 better than 43.45p?

http://aminet.net/package/driver/media/SCSI4345p

43.45p has been best scsi.device for amiga for years now, it doesn't have typical size limits at all. Including 128gb limit.

45.7 does it offer same features?
Title: Re: The Os 3.1.4 Thread
Post by: Oldsmobile_Mike on October 04, 2018, 05:59:25 PM
No. Many components included in 3.1.4 are more advanced than those shipped with 3.9. All the datatypes are post-3.9, the workbench and icon library are post-3.9, all libraries are post-3.9, the printer device is a hybrid, and the preferences are reworked 3.1 preferences as we do not have reaction. Some of the tools are also somewhere in between 3.1 and 3.9 such as the calculator, the clock, the icon editor, and HDToolbox.

How do these first two items compare to Oliver Roberts WarpDT datatypes and Peter K.'s icon.library?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 04, 2018, 06:38:20 PM
Is scsi.device 45.7 better than 43.45p?
I cannot tell since I do not know this version. What I had available are the versions from Heinz, and a couple of later versions from early Os 4 development which addressed a couple of additional bugs.

So, what do we have here:

A series of bug fixes of known bugs (insufficient memory allocation and memory trashing, and lack of testing memory allocations for success).

Support for LBA48 commands. This might help to avoid the 128GB limit.

MAXTRANSFER is no longer needed for the device, it can handle large block transfers now just fine.

Emulation of SCSI_INQUIRY works now with CF-Cards and ATAPI devices.

Support for the TD64 command was added.

I did not add support for third-party extensions. I believe the device is the wrong place for this. If vendors want to sell third party solutions, they need to supply proper firmware for their extensions instead of fiddling with the device itself.

I neither added any "speed patch" since I do not have any Amiga that runs with the scsi.device, so I'm very conservative on modifying working code just for speed reasons. You do not know what it breaks if you play with it, and if you cannot even test yourself and can only depend on beta-tester input, I'd rather keep my hands off. Don't break things, don't touch things, unless you really have to.

Title: Re: The Os 3.1.4 Thread
Post by: graffias79 on October 04, 2018, 07:15:31 PM
So if I took an IDE CD-ROM and connected it to an A4000D's IDE port it should theoretically work just with the CDFS that is included in 3.1.4?
Title: Re: The Os 3.1.4 Thread
Post by: utri007 on October 04, 2018, 07:18:33 PM
SCSI.device's size limits are quite important for me. My boot partition is 30gb and hard drive is 500gb. That hard drive was not recognized at all with original 3.1 scsi.device, but worked out of the box with with my custon kickstart with 43.45p scsi.device

Has anyone tested big hard drive support?
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on October 04, 2018, 08:04:07 PM
SCSI.device's size limits are quite important for me. My boot partition is 30gb and hard drive is 500gb. That hard drive was not recognized at all with original 3.1 scsi.device, but worked out of the box with with my custon kickstart with 43.45p scsi.device

Has anyone tested big hard drive support?

I have been using a 1TB drive without issues since the last 3.1.4 beta days.
Title: Re: The Os 3.1.4 Thread
Post by: NorthWay on October 04, 2018, 09:22:47 PM
I expect this one has been fixed long ago? https://groups.google.com/forum/#!searchin/comp.sys.amiga.programmer/bug%7Csort:relevance/comp.sys.amiga.programmer/t15D2Bxk6fE/dclD2BImq_0J
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 04, 2018, 09:45:19 PM
Yes, this was fixed.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 04, 2018, 09:48:09 PM
So if I took an IDE CD-ROM and connected it to an A4000D's IDE port it should theoretically work just with the CDFS that is included in 3.1.4?
I haven't tested, but ATAPI is there, and SCSI support is also there in CDFS.
Title: Re: The Os 3.1.4 Thread
Post by: Amon_RA on October 04, 2018, 10:47:45 PM
You need to update the installation readme.

For installing the new intuition library you also need to copy the loadmodule from the modules file

It also seems like you need to do
C:LoadModule module libs:intuition.library

as romupdate will stop once it finds out filesystem is already v 46

I found the same issue. Loading it via LoadModule ROMUPDATE just doesn't work (pure bit correctly set).
Title: Re: The Os 3.1.4 Thread
Post by: BozzerBigD on October 04, 2018, 11:42:58 PM
@Thomas Richter
Quote
No. Many components included in 3.1.4 are more advanced than those shipped with 3.9. All the datatypes are post-3.9, the workbench and icon library are post-3.9, all libraries are post-3.9, the printer device is a hybrid, and the preferences are reworked 3.1 preferences as we do not have reaction. Some of the tools are also somewhere in between 3.1 and 3.9 such as the calculator, the clock, the icon editor, and HDToolbox.

Thanks. So it's a partial update with no Reaction but with better Datatypes , libraries etc? Why now if not to coinside with the Vampire? Why was a bug fix deemed necessary? The Vampire is the only fuel for Classic development so it's resonable to suspect Hyperion's rush is motivated by the Vampire and has caused them to instigate the update to the code for the new machines to increase cash flow at a difficult time for the company. That is an obvious assumption. What is less obvious is the real world benefits of installing O3.1.4 instead of OS3.9 with third party software? Is the plan to get third party developers to support OS3.1.4 going forwards instead of OS3.9? How many copies would need to be sold for ongoing development?
Title: Re: The Os 3.1.4 Thread
Post by: ronniebeck on October 05, 2018, 08:28:56 AM
.....Why now if not to coinside with the Vampire? Why was a bug fix deemed necessary? The Vampire is the only fuel for Classic development so it's resonable to suspect Hyperion's rush is motivated by the Vampire....
Why is any bug fix deemed necessary.  Maybe you mean "why was this bug fix done now and not years ago?".
Rush? The Vampire has been around quite sometime and Hyperion had, according to Wikipedia, to "an exclusive license to develop and market AmigaOS 4 and subsequent versions with the name AmigaOS" since 2009.  A blind man typing on his keyboard via a 4 meter long stick could produce a fix faster than that.  It is hardly a rush.  I would like to hear the motivations for 3.1.4 and why it comes now from horses mouth (Hyperion and the developers) rather than pure speculation.  The guys behind the development are well known and well respected within the community.  Maybe they could explain their own motivations behind this here (if they haven't already).

How many copies would need to be sold for ongoing development?

Yes how many indeed.  If sales revenue of 3.1.4 could ever be commercially interesting.........
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 05, 2018, 11:33:45 AM
Thanks. So it's a partial update with no Reaction but with better Datatypes , libraries etc?
Yes.

Why was a bug fix deemed necessary?
Huh? "Necessary"? Look, once again, I cannot tell you why you want the update or not. It was necessary because there are plenty of bugs or annoyances in the distribution, including the latest Os 3.9. For example the 4GB boot partition necessary with 3.9 is such an annoyance that will go away. The reboot will go away. The printer.device will work again.... there are plenty small bugs here and there.

The Vampire is the only fuel for Classic development so it's resonable to suspect Hyperion's rush is motivated by the Vampire and has caused them to instigate the update to the code for the new machines to increase cash flow at a difficult time for the company.
Oh my. Seriously... 3.1.4 is hardly on a rush. The whole thing is under development for 3 years now, so nobody was on a rush creating it. The original idea, put forward by Olaf back then, was to fix only seriously broken issues of 3.1 such as the HDToolbox which could not handle partitions or drives larger than 4GB. Actually, while at it, more and more components were reviewed and fixed. The whole thing is completely unrelated to the Vampire at all. It is a bugfix release that really went overboard because much more was touched than originally planned. 3.1.4 should have been a much smaller release in the beginning, but issue after issue appeared.

Is the plan to get third party developers to support OS3.1.4 going forwards instead of OS3.9?
I'm sorry, I really don't get your attitude. There is no "instead of". 3.1.4 is not incompatible to 3.9. So an application running on 3.1.4 will surely work on 3.9 as well. An application running on 3.9 that does not depend on reaction also works on 3.1.4. We'd love to include reaction, but we cannot.

How many copies would need to be sold for ongoing development?
No company would publically discuss its long term product and management strategy, not even with its developers. This is a management issue, not a development issue. I'm not a Hyperion employee, and even if I would, I wouldn't know the plans of the management. My best guess is that Hyperion doesn't know at this point either, and by best guess is that it would be rather stupid to stop a product line if it sells well. How well is "good enough" I can hardly tell and it is not on me to make this decision. It is a decision that will most likely be taken as soon as the plans for yet another release are on schedule. It's a little bit early to do that as even this one hasn't been rolled out completely (i.e. physical ROMs and disks).
Title: Re: The Os 3.1.4 Thread
Post by: ronniebeck on October 05, 2018, 11:42:10 AM
Is the plan to get third party developers to support OS3.1.4 going forwards instead of OS3.9?
I'm sorry, I really don't get your attitude.

Me neither.  From my perspective, the update is a welcome release and much appreciated by myself.  Thank you! Nice work!  :-)
Title: Re: The Os 3.1.4 Thread
Post by: stefcep2 on October 05, 2018, 12:43:47 PM
Well done Thomas and the team. Another option for users is always good.

@ronniebeck: don't buy it.  you won't be happy
Title: Re: The Os 3.1.4 Thread
Post by: madgrizzle on October 05, 2018, 02:11:51 PM
You posted this on your bug fix thread (I didn't want to post there...)

"First, if you have a 060 processor, you no longer need an F-Space fix to turn off the FPU. Exec no longer crashes on a 060 FPU. Yet, you still need the 68060.library to enable it. This was to avoid incompatibilities."

So if I understand this correctly, when physical roms are available, they will work as is with my 3000 and 3640 w/060+FPU.  Correct?  This "F-Space fix" is what was done to the ROM I used currently?  I know I can thick, but I'd hate to purchase something (when available) to find out I'm wrong.
Title: Re: The Os 3.1.4 Thread
Post by: vxm on October 05, 2018, 02:19:02 PM
First, thanks for your fantastic work!
Is it planned to include the latest upgrades of the OS39 Shell-seg?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 05, 2018, 02:30:44 PM
So if I understand this correctly, when physical roms are available, they will work as is with my 3000 and 3640 w/060+FPU.  Correct?
Yes, though you still need to install a 68060.library. There is none included, but you know where to find one.

This "F-Space fix" is what was done to the ROM I used currently?
The F-Space fix was something vendors did to work around the issue in exec, i.e. such a fix is on all 060 cards I'm aware of. Of course, it does not apply if you hacked up a 040 card with a 060 adapter. Such cards will now work out of the box, a 68060.library provided.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 05, 2018, 02:34:30 PM
First, thanks for your fantastic work!
Is it planned to include the latest upgrades of the OS39 Shell-seg?

3.1.4 includes Shell V46, which is (of course) based on the V45 shell. There is one new feature in the shell which is not part of the V45 shell, and that is "pipes". There is no external "Pipe" command required anymore, and components have been updated to work with pipes. So for example, the following

Code: [Select]
list | sort | more

gives you a sorted directory listing that is paged through "more". In addition to the "|" pipe, we have "||" for concatenation, and "(" for grouping. Actually, "(" is a built-in command. So you can write things like

Code: [Select]
( list || dir ) | more
which concatenates the output of list and dir, and then pages it through more.

Title: Re: The Os 3.1.4 Thread
Post by: nicholas on October 05, 2018, 02:46:13 PM
Anyone know why the Hyperion page still charges VAT for those that live outside the EU?

Source (https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=41399&forum=27&start=420&viewmode=flat&order=0#817262)

Only Hyperion's "fullfillment partner" will respond to that apparently.

#6

Not exactly an explanation, but I recently learned how complicated the VAT issue has become for services rendered and goods delivered both within the European Union and from the European Union to non-member states. In my opinion it is quite likely for a payment processor such Avangate to slip up here.

Within the European Union the VAT added on top of the net price used to be the rate current in the country from which it was sold. For example, with the seller in Germany the standard rate of 19% VAT rate would be applied to a customer in Denmark. This was changed recently, and now the VAT rate of the customer has to be applied to the net price, e.g. for a seller in Germany and the customer in Denmark, the standard rate of 25% would have to be applied. Sounds sufficiently complicated, and it certainly is (and gets more so because you have to keep track of the specific payments made and the taxes you charged on top of the net price). It gets more complicated still because of exceptions the individual countries apply to taxation. Luckily, these tend not to affect services and goods rendered through payments made through online service because this has been standardized.

It gets really tricky when you sell from the European Union to a non-member state such as Switzerland or Norway. Services and goods may be taxed differently or not at all, for example. So the buyer may have to pay import taxes on floppy disks and EPROMs, but not on the digital download which contains the same information as the floppy disks and EPROMs (or it might be a reduced tax rate).

There's plenty of opportunity for things to go wrong.

The payment portal thinks it's clever and uses geolocation on your IP. I disabled my VPN and it didn't charge me VAT.

It's been an hour though and I still haven't received a confirmation email let alone the actual OS files.

Patience isn't my strong point though lol
Title: Re: The Os 3.1.4 Thread
Post by: nicholas on October 05, 2018, 03:05:34 PM
Is it possible to make a Super Kickstart Disk with the A3000 ROM images using your tool Olsen?


http://aminet.net/package/util/misc/MakeSuperDisk
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 05, 2018, 03:26:17 PM
Is it possible to make a Super Kickstart Disk with the A3000 ROM images using your tool Olsen?
I don't know, we haven't tested. Actually, the build chain does generate a superkickstart compatible version of exec, and probably even builds the superkickstart, but in how far this is working I do not know. It certainly lacks testing, and for that it is not sold.

This being said, we can probably arrange something if you are aware of the limitations. I would suggest that you go for an A3000 ROM, and then send a small mail to Hyperion asking them for the A3000 superkickstart version of it, and I'll see what I can do about it.

Wether this will work I cannot promise, of course.

Title: Re: The Os 3.1.4 Thread
Post by: vxm on October 05, 2018, 03:27:01 PM
"( list || dir ) | more" is okay but "list | sort | more" gives me "required argument missing".

And about the ability to display a file according to its datatype via multiview?
Title: Re: The Os 3.1.4 Thread
Post by: BozzerBigD on October 05, 2018, 03:36:55 PM
@Thomas Richter

Quote
I'm sorry, I really don't get your attitude.

Just checking that it won't further fragment development resources etc. It's great that OS3.x is under development again and it is a shame it ever stopped to be honest. A clean version of OS3.1.4 deserves a clean machine IMHO and I'm sadly not really interested until a Vampire standalone is available. Then I think this project has legs.
Title: Re: The Os 3.1.4 Thread
Post by: olsen on October 05, 2018, 03:56:31 PM
Is it possible to make a Super Kickstart Disk with the A3000 ROM images using your tool Olsen?


http://aminet.net/package/util/misc/MakeSuperDisk

Yes, but some assembly is required.

Both the 1.3 and 2.x (and by extension the 3.x) ROMs on a SuperKickstart disk consist of both the respective ROM image (256 KB for Kickstart 1.3, 512 KB for everything else) and what's called "bonus" code which is appended to the ROM. The Kickstart selection menu of the A3000 boot roms checks if the bonus code is present, and if it's not it will refuse to load the respective Kickstart ROM image.

The purpose of this specific "bonus" code (there's a bonus module in the A3000 ROM which has a different purpose) is to set up the MMU and exception handlers which allow for the respective Kickstart loaded to remain in memory until you switch it off. It's a software solution for what the Amiga 1000 did in hardware back in the day ;)

You can make the AmigaOS 3.1.4 A3000 Kickstart ROM suitable for use on a SuperKickstart disk by copying the respective bonus code from what's in your A3000 "WB_2.x:devs/kickstart" file and appending it to the Kickstart ROM image. If the "WB_2.x:devs/kickstart" file is larger than 524288 bytes, then copy all the data which begins at the 524289th byte until the end of the kickstart file. That data contains the bonus code which the Kickstart selection menu expects. Append this bonus code to the AmigaOS 3.1.4 A3000 ROM file and the MakeSuperDisk program should be able to use it.

Come to think of it, we could add the A3000-specific bonus code to the ROM image and include it in the A3000 download package as a "SuperKickstart ROM image" file.
Title: Re: The Os 3.1.4 Thread
Post by: bubbob42 on October 05, 2018, 04:56:08 PM
Just checking that it won't further fragment development resources etc.

On the contrary - our goal has always been to unite our resources with other developers'. That's the only reason why the Vampire supported 3.1.4 even before release. And not some tin foil hat conspiracy about Hyperion trying to rip off Vampire users, I'm afraid.

So, the truth may be a bit boring, but at least gratifying. :)

 
Title: Re: The Os 3.1.4 Thread
Post by: stx on October 05, 2018, 07:27:31 PM
I'm having the following issue:
https://forum.icomp.de/index.php?thread/40-x-surf-100-and-rapid-road-not-working-after-amigaos-3-1-4-upgrade

According to Jens, there is something broken with the freemem list in the 3.1.4 kickstart.

For those having the same issue with an X-Surf 100 card, see the workaround using the MuSetCacheMode tool.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 05, 2018, 08:00:02 PM
According to Jens, there is something broken with the freemem list in the 3.1.4 kickstart.
The Kickstart doesn't set any cache modes, it never did. The mmulib does.

For those having the same issue with an X-Surf 100 card, see the workaround using the MuSetCacheMode tool.
I have an XSurf-100 and see no issues.

Do you have an issue with it? If so, please report the output of MuScan and ShowConfig *without* any MuSetCacheMode workaround. In case you use an ENVARC:MMU-Configuration, please report this as well.

Title: Re: The Os 3.1.4 Thread
Post by: kamelito on October 05, 2018, 08:24:44 PM
@thor,
You probably have seen Bryce Nesbitt interview, at one point he spoke about memory protection, was it ready? code was available? is this something that can be added to AmigaOS knowing that they knew how to do it back then?
Are you going to follow CBM roadmap at one point?

https://vimeo.com/272762254
Title: Re: The Os 3.1.4 Thread
Post by: stx on October 05, 2018, 09:35:49 PM
Thanks Thomas for helping on my X-Surf 100 issue.

Output of MuScan just after running setpatch:

Code: [Select]
MuScan 46.1 (02.07.2016) <A9> THOR

68040 MMU detected.
MMU page size is 0x1000 bytes.

Memory map:
0x00000000 - 0x001FFFFF CacheInhibit
0x00200000 - 0x00BBFFFF CacheInhibit Blank
0x00BC0000 - 0x00BFFFFF CacheInhibit I/O space
0x00C00000 - 0x00D7FFFF CacheInhibit Blank
0x00D80000 - 0x00DFFFFF CacheInhibit I/O space
0x00E00000 - 0x00E8FFFF CacheInhibit Blank
0x00E90000 - 0x00EAFFFF CacheInhibit I/O space
0x00EB0000 - 0x00EFFFFF CacheInhibit Blank
0x00F00000 - 0x00F7FFFF CacheInhibit
0x00F80000 - 0x00FFFFFF ROM CacheInhibit
0x01000000 - 0x06FFFFFF Blank
0x07000000 - 0x07FFFFFF
0x08000000 - 0x3FFFFFFF Blank
0x40000000 - 0x4000FFFF I/O space
0x40010000 - 0x43FFFFFF Blank
0x44000000 - 0x44FFFFFF I/O space
0x45000000 - 0x4FFFFFFF Blank
0x50000000 - 0x5FFFFFFF
0x60000000 - 0xFFFFFFFF Blank

Output of showconfig:
Code: [Select]
PROCESSOR:      CPU 68040/68882fpu/68040mmu
CUSTOM CHIPS:   AA NTSC Alice (id=$0033), AA Lisa (id=$00F8)
VERS:   Kickstart version 46.45, Exec version 46.45, Disk version 45.194
RAM:    Node type $A, Attributes $505 (FAST), at $7000000-$7FFFFFF (16.0 meg)
        Node type $A, Attributes $405 (FAST), at $50000000-$5FFFFFFF (256.0 meg)
        Node type $A, Attributes $703 (CHIP), at $4000-$1FFFFF (~2.0 meg)
BOARDS:
 individual Computers X-Surf 100 Rev.3 Z-II/Z-III Ethernet:   Prod=4626/100($1212/$64)
     (@$40000000, size 64meg, subsize 64K)
 Great Valley Products Spectrum Memory:   Prod=2193/1($891/$1)
     (@$44000000, size 2meg, subsize same)
 Great Valley Products Spectrum:   Prod=2193/2($891/$2) (@$E90000 64K)
 Commodore (West Chester) A 590/2091 SCSI:   Prod=514/3($202/$3) (@$EA0000 64K)
 E3B ZorRAM/BigRam+/256MB Zorro III memory Expansion:   Prod=3643/32($E3B/$20)
     (@$50000000, size 256meg, subsize autosized Mem)

I don't have a file named ENVARC:MMU-Configuration yet.
Title: Re: The Os 3.1.4 Thread
Post by: stx on October 05, 2018, 10:06:33 PM
Here is another output of MuScan. This time also after setpatch but skipping the "LoadModule ROMUPDATE" (meaning running 3.1 kickstart instead of 3.1.4):

Code: [Select]
MuScan 46.1 (02.07.2016) <A9> THOR

68040 MMU detected.
MMU page size is 0x1000 bytes.

Memory map:
0x00000000 - 0x001FFFFF CacheInhibit Imprecise NonSerial
0x00200000 - 0x00BBFFFF Blank
0x00BC0000 - 0x00BFFFFF CacheInhibit I/O space
0x00C00000 - 0x00D7FFFF Blank
0x00D80000 - 0x00DFFFFF CacheInhibit I/O space
0x00E00000 - 0x00E8FFFF Blank
0x00E90000 - 0x00EAFFFF CacheInhibit I/O space
0x00EB0000 - 0x00EFFFFF Blank
0x00F00000 - 0x00F7FFFF CacheInhibit
0x00F80000 - 0x00FFFFFF ROM
0x01000000 - 0x06FFFFFF Blank
0x07000000 - 0x07FFFFFF CopyBack
0x08000000 - 0x3FFFFFFF Blank
0x40000000 - 0x4000FFFF CacheInhibit I/O space
0x40010000 - 0x43FFFFFF Blank
0x44000000 - 0x44FFFFFF CacheInhibit I/O space
0x45000000 - 0x4FFFFFFF Blank
0x50000000 - 0x5FFFFFFF CopyBack
0x60000000 - 0xFFFFFFFF Blank
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 06, 2018, 01:07:37 AM
Thanks. This is not related to 3.1.4 or rather, only very indirectly. The mmulib setup code is too critical about a particular decision and rejects a test because the ColdReboot() vector is now in RAM, not in ROM. The issue will go away with a ROM, or I check what I can do with the next release of the mmu.lib.

For the time being, please create a file

ENVARC:MMU-Configuration

and add the following single line:

ClearTTx

on top. This should resolve the issue.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 06, 2018, 01:10:38 AM
Memory protection is not going to work on AmigaOs. This is because there is no clear indication as which resource is owned by which task (or "MMU context"). The Os nicely shifts resources back and forth, so you never know where it belongs.

There are a couple of simpler forms of "memory protection" you can play, of course. MuProtectModules, for example, adds write protection for the modules that have been installed by LoadModule. In principle, you could do the same with resources loaded by "Resident", except that I haven't done that yet.

Title: Re: The Os 3.1.4 Thread
Post by: stx on October 06, 2018, 02:05:11 AM
Quote
For the time being, please create a file

ENVARC:MMU-Configuration

and add the following single line:

ClearTTx

This trick works great! Thanks a lot!
Title: Re: The Os 3.1.4 Thread
Post by: kolla on October 06, 2018, 06:35:13 AM
Quote from: Thomas Richter
We'd love to include reaction, but we cannot.

Because Hyperion is not exclusive owners of either?
Is Reaction licensed from Caldi etc, under conditions that restricts Hyperion to only use it on OS4/PPC?
Title: Re: The Os 3.1.4 Thread
Post by: kolla on October 06, 2018, 07:00:11 AM
I saw on a different forum that someone wrote ...
Quote
Personally, I'd choose to buy the version that fits best to the majority of Amigas in one's household.
I am not sure what this person implicitly meant with this.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 06, 2018, 10:22:48 AM
Quote
For the time being, please create a file

ENVARC:MMU-Configuration

and add the following single line:

ClearTTx

This trick works great! Thanks a lot!
In the meantime, I fixed this in the mmu.library. New version will appear ASAP.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on October 06, 2018, 01:19:30 PM
With the new Intuition.library, there is one (to me) odd limitation - even though one can pull windows off-screen, the size of window is still limited by the size of screen.

I again request for locale ct files to be "released", so one can make own locale catalogs without the hassle of "disassembling" existing ones.
Title: Re: The Os 3.1.4 Thread
Post by: Acill on October 06, 2018, 02:42:48 PM
A guide to do this 3.9 merge with it would be nice. I am having a hell of a time getting this onto my 4000T with a clean install and then getting anything over to it so my hardware works like mediator and USB then RTG. The lack of a CD ROM drive out of the box is a hard thing to not have. MUI is to big to fit on a floppy for install to get Poseidon on to get USB working and so on.
Title: Re: The Os 3.1.4 Thread
Post by: bubbob42 on October 06, 2018, 03:11:03 PM
A guide to do this 3.9 merge with it would be nice.

We have this:

http://www.hyperion-entertainment.com/index.php/frequently-asked-questions/55-amigaos-314/255-can-i-mix-os-39-components-with-os-314

and Ignacio's excellent script on Aminet:

http://aminet.net/package/misc/os/Updateto314

Should suffice. I'd also think some YouTubers might pick this up. :-)
Title: Re: The Os 3.1.4 Thread
Post by: giZmo350 on October 06, 2018, 03:15:12 PM
The lack of a CD ROM drive out of the box is a hard thing to not have. MUI is to big to fit on a floppy for install to get Poseidon on to get USB working and so on.

@Acill
Install the USB software and then run these commands from CLI.
You'll have to replace subwayusb.device in the second command with what ever RapidRoad's device name is. This should activate the USB port. Then use a USB CD unit to install MUI.

This, of course, will work if the RapidRoad software is installed generally like the older Subway USB software.

C:AddUSBClasses
C:AddUSBHardware DEVS:USBHardware/subwayusb.device

Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 06, 2018, 05:49:32 PM
With the new Intuition.library, there is one (to me) odd limitation - even though one can pull windows off-screen, the size of window is still limited by the size of screen.
This is correct and intentional. Otherwise, you could move the window in such a way that you cannot reach controls anymore.

I again request for locale ct files to be "released", so one can make own locale catalogs without the hassle of "disassembling" existing ones.
Sounds all plausible to me, though if you want to get something fixed on short notice, I propose that you prepare a "diff" of old vs. new strings and I'll forward to the translator. This is easier procedural-wise, as silly as it sounds.

Title: Re: The Os 3.1.4 Thread
Post by: Acill on October 06, 2018, 09:54:00 PM
The lack of a CD ROM drive out of the box is a hard thing to not have. MUI is to big to fit on a floppy for install to get Poseidon on to get USB working and so on.

@Acill
Install the USB software and then run these commands from CLI.
You'll have to replace subwayusb.device in the second command with what ever RapidRoad's device name is. This should activate the USB port. Then use a USB CD unit to install MUI.

This, of course, will work if the RapidRoad software is installed generally like the older Subway USB software.

C:AddUSBClasses
C:AddUSBHardware DEVS:USBHardware/subwayusb.device

I'll give it a try, thank you! I am also thinking of putting back in my CF drive over the new SSD in it and just trying the update script listed earlier.
Title: Re: The Os 3.1.4 Thread
Post by: Bennymee on October 07, 2018, 09:42:17 AM
@kolla

In screenmode, you could also insert custom width and height, the windows can then be larger.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on October 07, 2018, 11:27:09 AM
With the new Intuition.library, there is one (to me) odd limitation - even though one can pull windows off-screen, the size of window is still limited by the size of screen.
This is correct and intentional. Otherwise, you could move the window in such a way that you cannot reach controls anymore.

That sounds impossible - if you can move it, you can move it back, if you can resize it, you can resize it back.
Unless you also have implemented some way of "lobbing" windows off-screen??

Quote
I again request for locale ct files to be "released", so one can make own locale catalogs without the hassle of "disassembling" existing ones.
Sounds all plausible to me, though if you want to get something fixed on short notice, I propose that you prepare a "diff" of old vs. new strings and I'll forward to the translator. This is easier procedural-wise, as silly as it sounds.

It sounds really silly, and tedious - as I mentioned, the Norwegian locales are ridden with errors, for example the title windows of the prefs programs are consistently inconsistent. Imagine if in German it was "ASL-Einstellungen", "Audioeinstellungen", "IControl-Einstellungen", but "Workenbench Einstellungen". And for the latter, "Keine Farbe Ikonen", "Kein Tittel Feld", "Tastatur Auswahl Verzögerung" ... it just goes on and on. Even Google Translate does better :p

If I had .ct files, I would happily provide diffs and new locales for both the official variants of Norwegian (not just bokmål, as it currently is).

(Wasn't there an Amiga translator organisation or something similar earlier at some point?)
Title: Re: The Os 3.1.4 Thread
Post by: kolla on October 07, 2018, 11:34:01 AM
In screenmode, you could also insert custom width and height, the windows can then be larger.

Yes, I know that, but then I would also have a panning Workbench screen.
I would actually prefer if I could turn off the entire off-screen thing (which would be an IControl thing) also when using v45 Intuition.library.

And why is v45 left out from the 68000 distro? As far as I know, CyberGraphX requires at least 020.
Would it not be better to just include a separate kickstart file for CyberGraphX users?
Title: Re: The Os 3.1.4 Thread
Post by: Rotzloeffel on October 07, 2018, 02:27:50 PM
And why is v45 left out from the 68000 distro? As far as I know, CyberGraphX requires at least 020.
Would it not be better to just include a separate kickstart file for CyberGraphX users?

What is a 68000 distro? You can equip every normal A500 with a 030, add the "Matze" Zorroadapter and use a Graphicboard with the A500...

There is NO 68000 distro....
Title: Re: The Os 3.1.4 Thread
Post by: gregthecanuck on October 08, 2018, 02:44:58 AM
With the new Intuition.library, there is one (to me) odd limitation - even though one can pull windows off-screen, the size of window is still limited by the size of screen.
This is correct and intentional. Otherwise, you could move the window in such a way that you cannot reach controls anymore.

This same rule apples on Windows. You can manually size a window only to the maximum screen size. *Programmatically* you can make the window much larger but as has been mentioned this does introduce usability issues.
Title: Re: The Os 3.1.4 Thread
Post by: kirk_m on October 08, 2018, 03:57:08 AM
I purchased this for my A1200, and want to write the ROMs.  I know I need 27C400 EPROMs to do this, but, is there anything more "modern" to use than a UV-erase EPROM?  I know I can still get the UV-erase EPROMs, but, they are likely used and in need of erasure, but, I do not own a UV-based eraser.
Title: Re: The Os 3.1.4 Thread
Post by: shaf on October 08, 2018, 04:09:47 AM
Well I have both an EEPROM Programmer and UV Eraser, and am willing to support Amiga Users in the Toronto area as long as the supply the  Blank ROMs.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on October 08, 2018, 06:55:03 AM
This same rule apples on Windows.
Since when was following Windows' example a good thing? There is no such limitations in macOS or any other desktop I'm using, and strangely enough, there are no problems with "unreachable controls", so I am curious on exactly how one would manage to move windows in a way so that window gadgets would really become unreachable. Anyways, I hope it will be possible to turn off this feature (IControl prefs), as my "amiga workflow" is very much accustomed to windows being limited by the screen border (and if I could request a feature, it would be to have another hotkey for grabbing and moving windows without having to use titlebar - then it would be possible to move windows in a way so that control gadgets would be unreachable.)
Title: Re: The Os 3.1.4 Thread
Post by: kolla on October 08, 2018, 07:01:42 AM
There is NO 68000 distro....
Well, once you add accelerator card with 020+, you can also move to a different kickstart - I have one reason, and one reason only for using CGFx (v4), and that is CVPPC. Anyways, would it not be easier to just provide a legacy kickstart image for (the few) CGFx users, than requiring everyone else to meddle with startup-sequence and double-boot and potentially waste precious chipram? Oh well, making custom kickstarts is easy enough.
Title: Re: The Os 3.1.4 Thread
Post by: Jope on October 08, 2018, 12:16:12 PM
Come to think of it, we could add the A3000-specific bonus code to the ROM image and include it in the A3000 download package as a "SuperKickstart ROM image" file.

Why not also include a 1.3/3.1.4 superkick adf so that the HDSetup script's ExtractKickstart will work for that authentic feeling? ;-)
Title: Re: The Os 3.1.4 Thread
Post by: gregthecanuck on October 09, 2018, 04:45:21 AM
This same rule apples on Windows.
Since when was following Windows' example a good thing? There is no such limitations in macOS or any other desktop I'm using, and strangely enough, there are no problems with "unreachable controls", so I am curious on exactly how one would manage to move windows in a way so that window gadgets would really become unreachable. Anyways, I hope it will be possible to turn off this feature (IControl prefs), as my "amiga workflow" is very much accustomed to windows being limited by the screen border (and if I could request a feature, it would be to have another hotkey for grabbing and moving windows without having to use titlebar - then it would be possible to move windows in a way so that control gadgets would be unreachable.)

Tell that to my support team who regularly field support calls from users messing up and putting their window titlebars outside of a clickable area (i.e. off the top of the screen). There are "power users" (most users in these forums) that have a clue, and then there is Joe Average who would have no idea how to deal with a window bigger than the screen. These types of UI decisions are difficult - do you annoy the power users but keep the other 99% from getting into trouble, or do you make the power users happy but end up with loads more support calls and confusion.

I deal with this type of issue all the time in my day job, "dumbing things down" is a necessary evil if you want your support staff and costs to stay sane.

Title: Re: The Os 3.1.4 Thread
Post by: bubbob42 on October 09, 2018, 09:33:27 AM
Hyperion has now released a Bonus icon package created by Martin "Mason" Merz. It contains icons for many popular applications in the AmigaOS3.1.4 GlowIcon style.

Registered buyers can find it in their personal download section on the Hyperion website as a free addon.

Attached is a little preview. Thank you, Martin!

Title: Re: The Os 3.1.4 Thread
Post by: kolla on October 09, 2018, 09:51:38 AM
I deal with this type of issue all the time in my day job, "dumbing things down" is a necessary evil if you want your support staff and costs to stay sane.

So tell them to use Windows, where the dumbing down is already done.
There is no "support staff" for Amiga and Joe Average is not Amiga user anyways.

I still have not seen any description on _how_ one can end up with control gadgets becoming unreachable if windows can be resized larger than screen size.
Title: Re: The Os 3.1.4 Thread
Post by: kreciu on October 09, 2018, 03:58:09 PM
I stared reading about 3.1.4 and I think I like it (even if I was VERY skeptical about it initially).  I think I will get myself nice Christmas gift 2019 :), but I want boxed version :).

Is there any chance that there could be better "support/integration" of PPC boards... (what ever this means...).

Also, any chance to get OS3.9 true upgrade, to make it more up to date?

AND also we need better support of OS4.1 for classics. Like I mentioned before it is like a demo version of this system on Amiga Classic. It works... but hardware support is minimal (FastATA, PCI-USB etc. etc. etc. etc. etc.).

I like to dream :).
Title: Re: The Os 3.1.4 Thread
Post by: bubbob42 on October 09, 2018, 05:10:27 PM
I like to dream :).

Dreams can come true, if you take one step at a time and enjoy each of them. ;)
Title: Re: The Os 3.1.4 Thread
Post by: stx on October 09, 2018, 09:07:51 PM
Quote
For the time being, please create a file

ENVARC:MMU-Configuration

and add the following single line:

ClearTTx

This trick works great! Thanks a lot!
In the meantime, I fixed this in the mmu.library. New version will appear ASAP.

I just tested the updated mmu library and it works perfectly. No need for the ClearTTx configuration anymore. Thank you!
Title: Re: The Os 3.1.4 Thread
Post by: BozzerBigD on October 10, 2018, 12:11:21 PM
Is there a T-Shirt and voucher pre-order scheme for the physical copies of this OS / Roms? I guess they'll be ready "when it's done"?  Maybe the T-Shirt could have a nice "Kills 99% of known AmigaOS 3.1 bugs dead!" tag line? ;-)
Title: Re: The Os 3.1.4 Thread
Post by: kreciu on October 10, 2018, 03:08:21 PM
It there any list of "bugs killed" in the ROM? My Amiga only needs to reset like "10x" before normal operation ;).
Title: Re: The Os 3.1.4 Thread
Post by: Louis Dias on October 10, 2018, 03:09:11 PM
I have a rom burner ... now if some enterprising Amigan could create a custom 3.1.4 CD32 rom file...I just might buy the 1200 version...
I could be wrong but did the CD32 use 2 512k ROM chips?  Perhaps only the first one would need to be custom...
Title: Re: The Os 3.1.4 Thread
Post by: TribbleSmasher on October 10, 2018, 06:15:22 PM
No, it's only one chip. As stated somewhere else, the A1200 ROM will not search for extensions ROMs for CD32, so those extra modules you would add cannot be found and therefore are of no use, sadly. One has to do a little bit more to create a CD32 ROM.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 10, 2018, 06:56:59 PM
It there any list of "bugs killed" in the ROM?

I'll try to get this updated in this thread:

https://forum.amiga.org/index.php?topic=73694.0
Title: Re: The Os 3.1.4 Thread
Post by: BozzerBigD on October 11, 2018, 06:24:44 PM
@Thread

What would give me the best improvements for my 060 RTG Miggy; Boing Bags 3 & 4 on top of Boing Bag 2 on my OS3.9 partition or incorporating the 'improvements' / bug fixes in OS 3.1.4? Should I do both? Should I be worried about instability?
Title: Re: The Os 3.1.4 Thread
Post by: giZmo350 on October 11, 2018, 06:31:44 PM
@Thread

What would give me the best improvements for my 060 RTG Miggy; Boing Bags 3 & 4 on top of Boing Bag 2 on my OS3.9 partition or incorporating the 'improvements' / bug fixes in OS 3.1.4? Should I do both? Should I be worried about instability?

Excellent questions!  ;)
I'm running straight up OS3.9 w/BB1&2.... no other patches on my A2K.
Title: Re: The Os 3.1.4 Thread
Post by: NinjaCyborg on October 11, 2018, 06:40:05 PM
I just wanted to add my thanks to everyone involved in this project. I think it's just brilliant.
Title: Re: The Os 3.1.4 Thread
Post by: BozzerBigD on October 11, 2018, 06:49:45 PM
@giZmo350

I think I'm qualified to say that our icons would load a lot faster if we upgraded to Boings Bags 3 & 4 plus FBlit is built in so that would save RAM on AGA screen modes! I can't say I've got my head around what the real world benefits of upgrading to OS 3.1.4 components would be though Im sure there would be some given the effort to incorporate them into a OS3.9 system. Maybe the OS3.1.4 physical copy should come with a OS3.9 'upgrade' option?
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on October 11, 2018, 07:03:19 PM
I made a script to help update 3.1, 3.5 or 3.9 with 3.1.4.

It is in Aminet.
Make a backup first, and then execute it.

http://aminet.net/misc/os/Updateto314.lha
Title: Re: The Os 3.1.4 Thread
Post by: giZmo350 on October 11, 2018, 07:05:41 PM
I made a script to help update 3.1, 3.5 or 3.9 with 3.1.4.

It is in Aminet.
Make a backup first, and then execute it.

http://aminet.net/misc/os/Updateto314.lha

Yup.... this is exactly what I need to do.  :D
Title: Re: The Os 3.1.4 Thread
Post by: BozzerBigD on October 11, 2018, 07:16:01 PM
@giZmo350

That's great but should we upgrade with Boing Bags 3 & 4 first?
Title: Re: The Os 3.1.4 Thread
Post by: giZmo350 on October 11, 2018, 07:29:48 PM
@giZmo350

That's great but should we upgrade with Boing Bags 3 & 4 first?

my gut feeling tells me NOT to install BB3&4. However, OldsmobileMike swears by them (I think he's the patch king!). So, I guess I'll just try it with & without BB3&4.

It shouldn't be too time consuming (or dangerous) as I'm lucky to have one of these to quickly make a backup to another CF card. I probably won't get to it right away as I'm going to wait to buy OS3.1.4 with a ROM chip when they're available. But I'll surely post results when I do!

(https://amazingdiy.files.wordpress.com/2012/10/pcd50b.jpg?w=479)

Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 11, 2018, 08:42:47 PM
That's great but should we upgrade with Boing Bags 3 & 4 first?
No, there is nothing in the boing bags we haven't fixed otherwise. The components in 3.1.4 are more recent versions of the Os components than those in the boing bags.
Title: Re: The Os 3.1.4 Thread
Post by: BozzerBigD on October 11, 2018, 08:59:45 PM
@Thomas Richter

So has OS 3.1.4 incorporated FBlit into the core system then?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 11, 2018, 09:02:14 PM
So has OS 3.1.4 incorporated FBlit into the core system then?
No, please no! FBlit is too buggy for any practical use, so keep hands off! If you want a working software blitter - P96 has one.

What happened in this direction, however, is that intuition is now smart enough to detect itself whether it can place icons in FastRAM. There is no need to (and it is certainly not adivisble to) change the default allocation policy for the workbench. It all works correctly right away, and icons will be in fast if the system allows.
Title: Re: The Os 3.1.4 Thread
Post by: BozzerBigD on October 11, 2018, 09:04:35 PM
Surely it has its uses transferring some graphics into fastmem rather than Chip Mem?
Title: Re: The Os 3.1.4 Thread
Post by: giZmo350 on October 11, 2018, 09:07:34 PM
That's great but should we upgrade with Boing Bags 3 & 4 first?
No, there is nothing in the boing bags we haven't fixed otherwise. The components in 3.1.4 are more recent versions of the Os components than those in the boing bags.

Does that go for BB1&2 also?
Title: Re: The Os 3.1.4 Thread
Post by: kreciu on October 11, 2018, 09:14:35 PM
Now we need official update for 3.9 :), something like 0S3.9.5.


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.

THAT would be something :)

 (I have no idea what I'm talking about ;) ).
Title: Re: The Os 3.1.4 Thread
Post by: Oldsmobile_Mike on October 11, 2018, 10:07:39 PM
my gut feeling tells me NOT to install BB3&4. However, OldsmobileMike swears by them (I think he's the patch king!). So, I guess I'll just try it with & without BB3&4.

Ha!  I'm gonna lose that title since it's been weeks since I've even had a chance to turn any of my Amiga's on, and I haven't been following this development nearly as closely as I should be.  :(

That being said I never had any issues with 3.9 + all the BB's, and I used to spend way more time than I'd want to admit hunting down the latest and most esoteric versions of patches and libraries that I could find, all in the name of "performance and tuning".  Call it the old hot-rodder in me, I suppose.  ;)

Maybe when the ROM's come out I'll have time to test 3.1.4.  That's what I'm telling myself, anyway...
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 11, 2018, 10:25:23 PM
Does that go for BB1&2 also?
Yes, of course.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter 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.
Title: Re: The Os 3.1.4 Thread
Post by: kreciu 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 :).
Title: Re: The Os 3.1.4 Thread
Post by: mfletcher 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?
Title: Re: The Os 3.1.4 Thread
Post by: Tygre 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!
Title: Re: The Os 3.1.4 Thread
Post by: x303 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).
Title: Re: The Os 3.1.4 Thread
Post by: TribbleSmasher on October 13, 2018, 08:44:37 PM
Thats wrong, there is a little red X under each item.
Title: Re: The Os 3.1.4 Thread
Post by: Jiffy 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.
Title: Re: The Os 3.1.4 Thread
Post by: kreciu on October 14, 2018, 03:47:27 PM
The same here. I will get it with new ROMs and nice box :).
Title: Re: The Os 3.1.4 Thread
Post by: NinjaCyborg 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.
Title: Re: The Os 3.1.4 Thread
Post by: Motormouth 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
 


Title: Re: The Os 3.1.4 Thread
Post by: Tygre 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,
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter 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.
Title: Re: The Os 3.1.4 Thread
Post by: Dynamic_Computing 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
Title: Re: The Os 3.1.4 Thread
Post by: nicholas 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.
Title: Re: The Os 3.1.4 Thread
Post by: olsen 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.
Title: Re: The Os 3.1.4 Thread
Post by: x303 on 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.
Title: Re: The Os 3.1.4 Thread
Post by: graffias79 on October 17, 2018, 03:36:36 AM
So I upgraded my A1200 to 3.1.4 but it has 3.1 ROMs.  Before installing the update I installed MMULib from Aminet as it seemed to be suggested in the installation guide.  I have a Paragon 030/40 accelerator, which has a full MC68030 with a 68882 FPU.  Anyway after installing MMULib to get the 68030.library installed, I proceeded to upgrade the system.  Unfortunately it looks like LoadModule put all of the ROM patches into ChipRAM.  This ate up a ton of my ChipRAM and made the system feel very lethargic.

Is there a software fix for this or is this never going to be possible because my FastRAM is unable to endure a reboot?  I DID keep a backup of my previous config so I can revert while I wait for someone that can burn my Kickstart to physical chips.  It would be nice to be able to use it right away though.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 17, 2018, 04:57:13 AM
This is actually mentioned in the FAQ. Add "MuProtectModules ON REMAP" to the startup-sequence. This will (at least) mirror the modules from Chip to Fast. So it will still eat up chip memory, but at least the speed will be back to normal.
Title: Re: The Os 3.1.4 Thread
Post by: Rotzloeffel on October 17, 2018, 02:35:28 PM
You probably should find a way to "move" the Modules to FastRAM instead of mirror them.... this will help a lot of People  8)
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 17, 2018, 03:35:08 PM
You probably should find a way to "move" the Modules to FastRAM instead of mirror them.... this will help a lot of People  8)

There is always "NOMEMFKICK" as option to LoadModule which attempts that - this can be tried as an alternative as well. Problem is that this neither needs to work (if the RAM looses contents during bootstrap or is not auto-configuring) and that it also needs to keep exec in ChipMem.

The *real* problem is that multiple vendors do not set the attributes for their RAM correctly, or neither implement autoconfig correctly. Add on top that Ranger memory is neither suitable because the RAM-Test for ranger memory is simply broken in Os 3.1.

There is a tag for identifying suitable memory which is also used by default, but what can you do with all the multiple hardware on the market that did not quite follow CBMs recommendations (leave alone CBM, which did not follow its own best practises).

In the end, you never know what you get.
Title: Re: The Os 3.1.4 Thread
Post by: Rotzloeffel on October 18, 2018, 02:00:57 PM
I will check this out with GVP 030  8)
Title: Re: The Os 3.1.4 Thread
Post by: Romanujan on October 23, 2018, 03:53:58 PM
According to the FAQ, with 3.1.4 I don't need AmberRAM anymore. How do I mount second RAM disk with plain OS 3.1.4 than? I'm currently using AmberRAM just to have T: and Clipboards: completely separated from RAM:, so I won't copy/delete them by accident.
Title: Re: The Os 3.1.4 Thread
Post by: outlawal2 on October 23, 2018, 07:12:34 PM
OK so attempted to purchase 3.1.4 for my 3000 and 1200..  Made the purchase (Of course my money is taken with zero issues)
Then when I try to download it says I need to create a new account.  So I do this and it says OK click on the link in the email we sent you.
I received no email.  Checked multiple times and even tried to create account again and no dice.  So the account was created but I can't activate.

So I go to the forum and apparently they are having some kind of issue sending emails and are getting blocked.  So I try to ask a question in the forum and of course I need to create an account and guess what?  Yep I will need to click on another email that never arrives.  And NOWHERE on the site is a place to reach anyone if you have issues.

So exactly how is anyone supposed to download their software with this situation?
Title: Re: The Os 3.1.4 Thread
Post by: number6 on October 23, 2018, 07:26:13 PM
OK so attempted to purchase 3.1.4 for my 3000 and 1200..  Made the purchase (Of course my money is taken with zero issues)
Then when I try to download it says I need to create a new account.  So I do this and it says OK click on the link in the email we sent you.
I received no email.  Checked multiple times and even tried to create account again and no dice.  So the account was created but I can't activate.

So I go to the forum and apparently they are having some kind of issue sending emails and are getting blocked.  So I try to ask a question in the forum and of course I need to create an account and guess what?  Yep I will need to click on another email that never arrives.  And NOWHERE on the site is a place to reach anyone if you have issues.

So exactly how is anyone supposed to download their software with this situation?

Would you please give a direct link to forum where this issue is being discussed?
Thanks.

#6
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 23, 2018, 07:47:54 PM
According to the FAQ, with 3.1.4 I don't need AmberRAM anymore. How do I mount second RAM disk with plain OS 3.1.4 than? I'm currently using AmberRAM just to have T: and Clipboards: completely separated from RAM:, so I won't copy/delete them by accident.
You cannot mount a second ram disk on the RAM-Handler.
Title: Re: The Os 3.1.4 Thread
Post by: rxxic on October 23, 2018, 07:54:55 PM
OK so attempted to purchase 3.1.4 for my 3000 and 1200..  Made the purchase (Of course my money is taken with zero issues)
Then when I try to download it says I need to create a new account.  So I do this and it says OK click on the link in the email we sent you.
I received no email.  Checked multiple times and even tried to create account again and no dice.  So the account was created but I can't activate.

So I go to the forum and apparently they are having some kind of issue sending emails and are getting blocked.  So I try to ask a question in the forum and of course I need to create an account and guess what?  Yep I will need to click on another email that never arrives.  And NOWHERE on the site is a place to reach anyone if you have issues.

So exactly how is anyone supposed to download their software with this situation?


I bought them too, I received an e-mail with the download link. No issues downloading AmigaOS 3.14.

However, I could not find the purchased items in my Hyperion account at first, but a couple of hours later everything was there too.

maybe you just have to wait for the servers to do their work..
Title: Re: The Os 3.1.4 Thread
Post by: outlawal2 on October 23, 2018, 07:57:34 PM
The issue was not with the purchase.. It was with the ACTIVATION of my account on the site.
I received the email with my serial# as that came from a 3rd party commerce site.. (Whoever they use to take your money)  That worked fine.

It was after the fact when I tried to create an account on the website that I have not received an activation email so I am dead in the water
Title: Re: The Os 3.1.4 Thread
Post by: kolla on October 24, 2018, 01:50:30 PM
@outlawal2

Hm, wasn't it you who told me to stop wasting everyone's time? Well well...
Title: Re: The Os 3.1.4 Thread
Post by: Tenacious on October 24, 2018, 06:02:18 PM
I've tried to keep up, but this has become a really long thread that gets personal at times. 

I gather that OS3.1.4 has been released recently - good.  It is a preliminary or test release because the new ROMs are not yet available?  Is there a release date for plug-n-play ROMs for various models?

If there was an announcement, I could have easily missed it because of the new Amiga.org web site/format.  Please forgive my ignorance.  I just don't log-in as much nor use Amigas as much as before.

On a bright note, it is very encouraging and even exciting that the OS is being updated and bug-fixed.  The last time I felt this good about Amiga was when i discovered BetterWB or installed OS3.5.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 24, 2018, 06:05:51 PM
It is a preliminary or test release because the new ROMs are not yet available?  Is there a release date for plug-n-play ROMs for various models?
This pretty much depends on the dealers and their negotiation with Hyperion. I afraid I cannot really say except that everything is prepared for a nice "boxed" release.
Title: Re: The Os 3.1.4 Thread
Post by: outlawal2 on October 25, 2018, 01:46:19 AM
@outlawal2

Hm, wasn't it you who told me to stop wasting everyone's time? Well well...

Exactly how is my posting a question about the purchase of 3.1.4 wasting everyone's time?  At least my question is in regards to the subject at hand and not simply being a dick.  You sir cannot say the same.

Please go away as this is a forum for decent Amiga fans.

(And for the record my question was answered from someone on the Hyperion site that was able to assist me with the issue and all is well now.)
Title: Re: The Os 3.1.4 Thread
Post by: Romanujan on October 27, 2018, 12:37:21 PM
Does anyone know how can I get the original OS 3.1.4? I've purchased licenses for all the 5 versions, but I got the original 3.1.4 only for my first purchases, for the second batch I only got some revised ROM image - which broke RomSplit compatibility (and has less aesthetic 'About' window).
Title: Re: The Os 3.1.4 Thread
Post by: kolla on October 27, 2018, 02:11:22 PM
I'm sure romsplit will be updated, and then you can easily change the copyright notice in exec.library yourself with a binary capable editor.
Of course, doing so is breaking the terms of use considerably :)
Title: Re: The Os 3.1.4 Thread
Post by: Romanujan on October 27, 2018, 03:37:32 PM
I don't want to hexedit the files, I just want the original software, just as it was initially released.

I'm really disappointed that they altered the software while keeping the version number and didn't even tell anything to buyers, causing confusion. I purchased licenses even for hardware I don't have and don't intend to buy - partially to encourage the development, partially for nostalgia/collecting purposes (I wanted to "have it all", if you understand me) - hexediting is not a solution at all.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 27, 2018, 04:35:53 PM
Does anyone know how can I get the original OS 3.1.4?
You don't.

I've purchased licenses for all the 5 versions, but I got the original 3.1.4 only for my first purchases, for the second batch I only got some revised ROM image - which broke RomSplit compatibility (and has less aesthetic 'About' window).
RomSplit is not a feature that is promised or supported. You get already the modules in binary form. If that is not good enough, I afraid I cannot help.
Title: Re: The Os 3.1.4 Thread
Post by: Romanujan on October 27, 2018, 05:06:53 PM
Yet, I didn't get what I have seen on the screenshots. And, as a paying customer, I don't consider silent changes to the product a fair practice.

Lesson learned. I definitely won't spend that much on Hyperion software in the future. If anything at all.
Title: Re: The Os 3.1.4 Thread
Post by: kreciu on October 28, 2018, 08:57:25 AM
That is strange. So, there are different versions of 3.1.4 but have the same number name? Is there going to be a final version? Maybe updates should be delivered separately, so there is no confusion like 3.1.4.1...? Are there going to be "silent" versions of the 3.1.4 ROM ?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 28, 2018, 09:02:57 AM
There are no changes besides the copyright string (fortunately or unfortunately, we had a couple of bugs fixed in the meantime, but addressing those will be reserved for 3.1.4.1 as there are likely more coming).

So feel ensured that this is the same 3.1.4 it used to be in the beginning.
Title: Re: The Os 3.1.4 Thread
Post by: Romanujan on October 28, 2018, 09:37:48 AM
Thomas, this doesn't matter - Hyperion delivered me something slightly different than what he was delivering to the people purchasing the product few days earlier, and I didn't get any information about it before the purchase. If there was a legal flaw within the copyright and they were required to stop distributing the old version, the proper action would be to bump the Kickstart version number (46.143 -> 46.144) and specify the version being sold on the web page, together with a short changelog ("just some copyright strings changed, due to legal reasons") - that's it. A "legal bugfix" release, probably no one would get angry.

I purchased more than I needed to support the development. But silently changing the product without notifying the customers is DEFINITELY NOT something I am willing to support in the future.
Title: Re: The Os 3.1.4 Thread
Post by: NinjaCyborg on October 28, 2018, 09:46:05 AM
Thomas, this doesn't matter - Hyperion delivered me something slightly different than what he was delivering to the people purchasing the product few days earlier, and I didn't get any information about it before the purchase. If there was a legal flaw within the copyright and they were required to stop distributing the old version, the proper action would be to bump the Kickstart version number (46.143 -> 46.144) and specify the version being sold on the web page, together with a short changelog ("just some copyright strings changed, due to legal reasons") - that's it. A "legal bugfix" release, probably no one would get angry.

I purchased more than I needed to support the development. But silently changing the product without notifying the customers is DEFINITELY NOT something I am willing to support in the future.

A non-code change doesn't require a revision change. If you love Amiga it shouldn't be too difficult to forgive minor imperfections.
Title: Re: The Os 3.1.4 Thread
Post by: Romanujan on October 28, 2018, 10:15:17 AM
Minor imperfection (lack of version bump) - such things I easily forgive, no matter whether it is Amiga or not.
Company behaviour I consider unfair (lack of notification about collectors/nostalgia product change) - much less likely.

This was a code change - the resulting binary is different.
Title: Re: The Os 3.1.4 Thread
Post by: NinjaCyborg on October 28, 2018, 11:26:13 AM
Minor imperfection (lack of version bump) - such things I easily forgive, no matter whether it is Amiga or not.
Company behaviour I consider unfair (lack of notification about collectors/nostalgia product change) - much less likely.

This was a code change - the resulting binary is different.

The code section of the binary is not different only the data section.
Title: Re: The Os 3.1.4 Thread
Post by: Romanujan on October 28, 2018, 03:38:23 PM
Doesn't matter which sections were altered, the resulting binaries are, in my opinion, inferior. RomSplit got updated, and it seems the 2nd release exec for A1200 needs 152 bytes more in the ROM; IMHO a strange effect if only two strings were changed to be few bytes longer (or maybe AmigaOS require data/code sections to be aligned somehow? I must admit, I have no idea), and definitely not a nice one.

What's even more perplexing, exec from all the Modules ADF disks I got still contain old copyright strings - if these ones are OK, than why the hell the ROM image was changed??? Amiga ecosystem has several pieces of software depending on exact ROM locations (RomSplit, various softkickers, WHDLoad, and who knows what else) - why to do such change, which can only bring trouble?
Title: Re: The Os 3.1.4 Thread
Post by: number6 on October 28, 2018, 04:37:19 PM
@thread

To all inquiring about the changes:

Olaf/Olsen (https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=41399&forum=27&start=440&viewmode=flat&order=0#818250)

#6
Title: Re: The Os 3.1.4 Thread
Post by: kreciu on October 29, 2018, 01:52:03 PM
There are no changes besides the copyright string (fortunately or unfortunately, we had a couple of bugs fixed in the meantime, but addressing those will be reserved for 3.1.4.1 as there are likely more coming).

So feel ensured that this is the same 3.1.4 it used to be in the beginning.

I see, I was thinking there are some substantial updates.
Title: Re: The Os 3.1.4 Thread
Post by: Dynamic_Computing on October 29, 2018, 02:09:29 PM
That is strange. So, there are different versions of 3.1.4 but have the same number name? Is there going to be a final version? Maybe updates should be delivered separately, so there is no confusion like 3.1.4.1...? Are there going to be "silent" versions of the 3.1.4 ROM ?

Yes... Thank goodness there is no other software out there that updates and you receive a slightly new version. Like on your phone, or computer, or watch, or almost all software that is currently created... :-\
Title: Re: The Os 3.1.4 Thread
Post by: kreciu on October 29, 2018, 02:31:17 PM
Yes... Thank goodness there is no other software out there that updates and you receive a slightly new version. Like on your phone, or computer, or watch, or almost all software that is currently created... :-\

I don't remember when I had to purchase software update for my phone, computer etc. Maybe after support time is over, I do pay for updates/upgrades.

Personally, I don't care "what is out there".

It was not clear to me what type of updates are for 3.1.4 and it seemed to me strange that tweaks are being made to released version. In general I got used to that there are "strange things" in Amiga World, so I don't care about those thing to much (or basically at all). So, I simply wanted to know what is happening there.

I will wait for boxed version with ROMs, I have no way to burn ROMs on my own and this will be my "final version" of 3.1.4 :).
Title: Re: The Os 3.1.4 Thread
Post by: Romanujan on October 29, 2018, 05:11:20 PM
Yes... Thank goodness there is no other software out there that updates and you receive a slightly new version. Like on your phone, or computer, or watch, or almost all software that is currently created... :-\

All I have seen so far (like MS Windows) warn about this in their EULA - AmigaOS 3.1.4 is the first one I have seen that did not. And, you have just mentioned one of the reasons why I switched from Windows to Linux at home, and why I use Android or iOS devices as secondary devices only, when I want mobile net access or navigation.
Title: Re: The Os 3.1.4 Thread
Post by: kreciu on October 29, 2018, 07:57:48 PM
I actually think that I will like 3.1.4 more then 3.9. Simpler, cleaner and way newer. With few of my own "additions" it should work very well. I just can't wait for physical version with ROMs. I will get at least two :).
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on October 30, 2018, 09:05:45 AM
I just can't wait for physical version with ROMs. I will get at least two :).
Alinea seems to have them from Nov. 3rd on: https://www.amiga-shop.net/Amiga-Software/AmigaOS-Amiga-Betriebssysteme/AmigaOS-3-1-4::859.html

Title: Re: The Os 3.1.4 Thread
Post by: kreciu on October 30, 2018, 12:58:24 PM
Great to see those. I've never shopped with them, I will wait for Amigakit.com.

BTW. It reminds me old good days when you got floppies and ROMs :).

PS. Just don't update ROMs to often, I "hate" disassembling my monster A1200 ;).
Title: Re: The Os 3.1.4 Thread
Post by: kreciu on October 30, 2018, 01:00:07 PM
(double post)
Title: Re: The Os 3.1.4 Thread
Post by: kolla on December 18, 2018, 12:16:56 PM
(http://kolla.no/shell46pipes.jpg)

Meh.

(http://kolla.no/shell45pipes.jpg)

In comparison to shell v45 that does not throw "CONSOLE:" requesters when running scripts with pipes in the background.

This, along with the failat/abort bug, makes the shell in OS 3.1.4 really annoying to make script for.
Title: Re: The Os 3.1.4 Thread
Post by: wmaciv on December 23, 2018, 05:34:37 PM
Just installed 3.1.4 (ROM and disks). Previous install was patched exec 3.1 (to allow full 060 to boot), running Thor's MuLIb suite with zero problems. Now, using Thor MuLib (latest) with 3.1.4, unless I set SetPatch to "NOCACHE", the CPU CHECKINSTALL command on the very next line of the Startup-sequence will crash the system without fail.

If I then boot into WB the only way that seems to work, with SetPatch NOCACHE QUIET, then open a shell window and type "CPU", it returns the correct CPU setup, but the Data Cache and Data Burst are disabled (off).

If I then try to command "CPU CACHE", about 75% of the time the system will lock up and guru, the other 25% I am able to activate the Data Cache and Burst.

Everything worked great with the previous 3.1 installation (patched exec) and latest distribution of MUlibs, but now, this...

Anyone have any ideas? Thomas?

Thanks.
   
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on December 23, 2018, 08:07:03 PM
Just installed 3.1.4 (ROM and disks). Previous install was patched exec 3.1 (to allow full 060 to boot), running Thor's MuLIb suite with zero problems. Now, using Thor MuLib (latest) with 3.1.4, unless I set SetPatch to "NOCACHE", the CPU CHECKINSTALL command on the very next line of the Startup-sequence will crash the system without fail.
There is no difference concerning the memory setup between 3.1 and 3.1.4 that would explain this. You can also LoadModule 3.1.4 on top of a 3.1 ROM. If this solves the problem, then probably the ROM chip is not compatible to the hardware. I would try the 3.1 ROM with a LoadModule installation and continue from there.
Title: Re: The Os 3.1.4 Thread
Post by: wmaciv on December 23, 2018, 08:40:54 PM
Egregious error in the post; forgot to mention that this is an A2000 with a GVP A2000-040 combo with 060 adapter, 64MB GVP SIMM RAM, and GuruROM.  I looked around a1k.org and found a few mentions of possible problems with this card setup?  Still do not understand how 3.1 ROM with your MuLIbs works flawlessly, but the new SetPatch / CPU command in 3.1.3 seems to make the system unstable when any attempt to enable Data Cache is made.
Title: Re: The Os 3.1.4 Thread
Post by: Jeff on December 24, 2018, 12:20:27 AM
Amiga OS 3.1.4 is available as a download again. I just bought all of the versions :D What a nice Christmas gift! Thank you to whoever made this happen.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on December 24, 2018, 12:36:18 AM
Still do not understand how 3.1 ROM with your MuLIbs works flawlessly, but the new SetPatch / CPU command in 3.1.3 seems to make the system unstable when any attempt to enable Data Cache is made.
As stated, there is no difference in setpatch as far as the memory or mmu setup is concerned, and the CPU command does not change that either. The only thing it does is that it may, upon request, change the state of the CPU caches. If the system does not work stable with CPU caches, you have a hardware problem, probably because the ROM you received has a lower speed-grade than the one present before. There is no difference as far as the CPU setup is concerned.
Title: Re: The Os 3.1.4 Thread
Post by: outlawal2 on December 24, 2018, 03:48:47 AM
OK just installed the ROMs in my 3000 and reinstalled the OS from the new floppies...   But it still says my disk is 2 GIG even though it is 16.  Could this be because it was formatted before as 2 GIG?  No matter what I try it only shows up as 2 GIG.
This is a Sandisk MicroSD and the adaptor is a SCSI 2 SD adaptor...   Other than the size issue it works fine..

Just wondering what I am doing wrong as everyone I have seen thus far says the new OS detects the disks perfectly..
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on December 24, 2018, 08:26:16 AM
OK just installed the ROMs in my 3000 and reinstalled the OS from the new floppies...   But it still says my disk is 2 GIG even though it is 16.  Could this be because it was formatted before as 2 GIG?
If you haven't repartitioned with HDToolbox, then the partition sizes stay exactly as they were before. To use the full disk size, you can either repartition which would require a full install, or you can add another partition that uses the remaining 14GB.
Title: Re: The Os 3.1.4 Thread
Post by: outlawal2 on December 25, 2018, 12:58:39 PM
Yeah but I DID repartition with the tools provided with the new OS..  (Hence my question)
Strange....

Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on December 25, 2018, 04:09:13 PM
Yeah but I DID repartition with the tools provided with the new OS..  (Hence my question)
Strange....
Note that "HDToolBox" keeps a database of disks. You can always "add new drive type" and there trigger a re-scan of the harddisk, then use this as basis for new partitions. Otherwise, HDToolBox will use whatever it saved the last time it recognized the drive.
Title: Re: The Os 3.1.4 Thread
Post by: giZmo350 on December 25, 2018, 04:16:21 PM
Note that "HDToolBox" keeps a database of disks. You can always "add new drive type" and there trigger a re-scan of the harddisk, then use this as basis for new partitions. Otherwise, HDToolBox will use whatever it saved the last time it recognized the drive.

Huh, I never knew that. Is that something new? Good to know. Thx!
Title: Re: The Os 3.1.4 Thread
Post by: olsen on December 26, 2018, 02:06:36 PM
Note that "HDToolBox" keeps a database of disks. You can always "add new drive type" and there trigger a re-scan of the harddisk, then use this as basis for new partitions. Otherwise, HDToolBox will use whatever it saved the last time it recognized the drive.

Huh, I never knew that. Is that something new?

No, this is a very old feature which goes back to the days of the A590 which shipped with 3.5" XT drives (ST 506 interface, ~20 MB per drive), but would also accept a SCSI drive.

The problem which the database solved was that the XT drives did not necessarily report their respective model and properties correctly when prodded. Commodore shipped a database of known-working drive types and their properties with the HDToolBox program, with the option for the user to add more drive types by entering the respective configuration data manually. For example, if you flipped over the A590 case, you would see a label describing the type, manufacturer and model, along with the number of cylinders/sectors/tracks/heads. If you ever lost the database, or corrupted it by accident, you could at least set up your drive correctly by following the label data. The usual approach would be to pick a database entry which matched the model and manufacturer information.

The problem with hard disk drives not producing reliable information about their respective configuration persisted for a very long time indeed, right until into the mid-1990'ies before the great mergers/acquisitions of hard drive manufacturers left us with only a handful of companies (Seagate, Western Digital, Fujitsu, Toshiba).

There is some extraordinarily complex code in HDToolBox which tries almost every trick that might work for XT and SCSI drives of that age to figure out the configuration parameters. To those unfamiliar with its purpose the code is perplexing and outright impenetrable. When we updated HDToolBox for the 3.1.4 update, we asked around for help and received kind advice from Ralph Babel and Joanne Dow. When Joanne kindly showed us how the RDPrepX tool approached the same problem as the mystifying HDToolBox configuration code, the penny finally dropped and the pennies just kept dropping. This kind of code is supposed to be as complicated/peculiar as it appeared :o

Long story short: the database in HDToolBox and the arcane configuration parameter heuristics have no place in a (somewhat) modern hard disk setup program. But for the time being we will be stuck with it :(
Title: Re: The Os 3.1.4 Thread
Post by: TribbleSmasher on December 26, 2018, 02:49:26 PM
The problem with this 'drive definitions' database is that sometimes the installdisk where the hdtoolbox is on is rather full and the user gets weird error messages about 'disk full' when reading new drives with it.
Title: Re: The Os 3.1.4 Thread
Post by: wmaciv on December 27, 2018, 02:46:09 PM
Ok, waiting for another copy of the 3.1.4 ROM, but the "crashing" seems to involve any command invoked form the "C" directory once the Data Cache on the 060 is enabled.  Assign, Ed, CPU, etc., all generate an immediate crash.  Why only the C directory commands?  Is this REALLY because the ROM chip is too "slow"?  I though after installing MuLibs and remapping KS to RAM, all calls were placed against the re-mapped copy in RAM anyway?  Still does not explain why the exact same hardware setup worked fine with 3.1 and the current MuLibs distribution; nothing else changed. 
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on December 27, 2018, 11:11:13 PM
Ok, waiting for another copy of the 3.1.4 ROM, but the "crashing" seems to involve any command invoked form the "C" directory once the Data Cache on the 060 is enabled.  Assign, Ed, CPU, etc., all generate an immediate crash.
There is nothing particular about Ed, CPU or Assign that would prevent them from functioning on a 68060. In fact, I do have a 68060 myself, with a Blizzard 2060, and everything works just fine. If things crash with otherwise "known to be stable commands", then this is an indicator of some hardware defect and not a software failure.

Why only the C directory commands?
I'm sure everything else will also crash, sooner or later, unless you also have a bad disk, or the disk with the 3.1.4 copy you received was bad. As stated, all these commands have been tested fine - if enabling CPU caches makes the system unstable, something is bad with the communications to RAM or ROM.

Enabling caches enables another, faster Bus protocol known as "bursting". If the timing does not fit, this will make the system unstable.


Still does not explain why the exact same hardware setup worked fine with 3.1 and the current MuLibs distribution; nothing else changed.
Yes, the ROM changed, and you touched the machine. It is also possible that the chips received some static and you fried them. If turning caches on or off makes a difference, then this is not a software failure. It is some freaky hardware that is involved.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on December 28, 2018, 06:19:19 AM
@wmaciv

You need to isolate the problem...

Does it only happen with 3.1.4 programs on 3.1.4 kickstart, or also with 3.1 programs on 3.1.4 kickstart and/or 3.1.4 programs on 3.1 kickstart?

You write "lock up and guru" - so what is the guru? Same every time?
Title: Re: The Os 3.1.4 Thread
Post by: wmaciv on December 28, 2018, 02:48:07 PM
Understand about the isolating the problem (which is ongoing).  Really do not want to go back to 3.1 with patched exec. Absolutely ove MuLibs and think Thomas probably ought to charge for it :).  The hardware I am using is definitely in the realm of "edgy", as it is the GVP G-Force A2000-040 with 060 adapter running at 75MHz.  It was rock stable in last config (3.1 / MuLibs), so will continue to fight the good fight and see if a I can make it work with 3.1.4 / MuLibs. 

I am close to starting the Zeus 040 along the same path, just waiting for the updated device driver ROMs to arrive.  I want to see if I can get 3.1.4 working well with an 060 adapter on the Zeus.  Had one on the card temporarily running at 70MHz under 3.1 with MuLibs a while back, but wanted to wait until I could get the repaired 53C710 device driver before really going full bore.  At least with the Zeus, I have the option of mapping a little bit of the onboard RAM to the ZII address space at boot. 
Title: Re: The Os 3.1.4 Thread
Post by: duga on December 28, 2018, 02:49:48 PM
Ok, waiting for another copy of the 3.1.4 ROM, but the "crashing" seems to involve any command invoked form the "C" directory once the Data Cache on the 060 is enabled.  Assign, Ed, CPU, etc., all generate an immediate crash.  Why only the C directory commands?  Is this REALLY because the ROM chip is too "slow"?  I though after installing MuLibs and remapping KS to RAM, all calls were placed against the re-mapped copy in RAM anyway?  Still does not explain why the exact same hardware setup worked fine with 3.1 and the current MuLibs distribution; nothing else changed.

Which speed does your ROM have?
Title: Re: The Os 3.1.4 Thread
Post by: wmaciv on December 28, 2018, 02:58:38 PM
You know, the one I have now came from the sordan.ie fellas advertising on Amibay.  The ROM is the produced is completely covered by the registration/serial number sticker and I am loath to peel it back to see.  The patched exec 3.1 I was recently using was 120ns AMD.  I am supposed to be receiving my second kit of ROM+disks today from Amiga on the Lake and will see what shows up.
Title: Re: The Os 3.1.4 Thread
Post by: wmaciv on December 29, 2018, 01:39:27 AM
Both the new ROM's (3.1.4) and the original 3.1 patched exec ROM are 150ns.  No explanation there...
Title: Re: The Os 3.1.4 Thread
Post by: dschallock on December 29, 2018, 09:53:34 PM
Hi,
First a huge thanks to Thom and the team for making this upgrade.  Truly Amazing!

I think these questions may be very simple and perhaps already covered but I have been looking and I'm sorry I couldn't find the information I need so I will ask anyway:

1) I just received my 3.1.4 disks and Roms from AOTL (thanks guys)... I currently have 3.1 roms and OS installed, Can I/should I upgrade 3.1 to 3.1.4 or do I need to do a fresh install?

2) If I can upgrade, do I swap the roms first and then do the software upgrade?

3) I have a particular version of my 040 and 060 library installed in order to make my Cyberstorm accelerator work, Should I take precautions to copy those immediately over the new install to maintain functionality of that accelerator's 060?

Thanks ahead of time for anyone responding and helping me answer these questions!
-Dan
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on December 29, 2018, 09:59:40 PM
1) I just received my 3.1.4 disks and Roms from AOTL (thanks guys)... I currently have 3.1 roms and OS installed, Can I/should I upgrade 3.1 to 3.1.4 or do I need to do a fresh install?
The install script on the Install disk makes a fresh install. Unless you know what you are doing, this is the recommended (and supported) way. If you know your system well, you can also install manually.

2) If I can upgrade, do I swap the roms first and then do the software upgrade?
If you bought the ROM version, please install the ROM first. Otherwise, the installer script will ask you for the Modules disk which include the modules that are in ROM. Since they are not included in the set, installation would then fail.


3) I have a particular version of my 040 and 060 library installed in order to make my Cyberstorm accelerator work, Should I take precautions to copy those immediately over the new install to maintain functionality of that accelerator's 060?
The installer script does not overwrite or replace them. It just warns you that they need to be present, and the default startup-sequence checks whether they are present. There is no CPU library included in the distribution.
Title: Re: The Os 3.1.4 Thread
Post by: dschallock on December 29, 2018, 11:07:36 PM
Thanks Thomas for the reply!

So, Install Rom first.  Then install from disk.  It will do a fresh install (over the top of my 3.1 if I point it to that partition) and if that partition already has a libs directory with 040 and 060 libraries on it they would not be over written or erased.  Does that sound correct?

I don't have alot of hacks installed on the system but I do have toolsDaemon installed I think... Should I disable that before letting the install happen?

Thanks,

Dan
Title: Re: The Os 3.1.4 Thread
Post by: kolla on December 30, 2018, 01:19:32 AM
You should update ToolsDaemon, and it will work fine with new workbench.library
http://aminet.net/package/util/boot/ToolsDaemon22
Title: Re: The Os 3.1.4 Thread
Post by: QuikSanz on December 30, 2018, 08:00:16 AM
I had only read bits and pieces here till today. After reading the whole thing it appears to me that We need a way to add parts of OS 3.9 to 3.1.4 not the chicken before the egg!

Chris
Title: Re: The Os 3.1.4 Thread
Post by: kolla on December 30, 2018, 02:27:25 PM
Yes, it's easier to plug bits and pieces of Amiga OS 3.9 (+BB2/3/4) ontop of 3.1.4 than vice versa. As bonus, you then also avoid the mostly useless diskfilling bloat and "bling" of 3.9.

Sadly they conflict here and there though, such as IPrefs and locale string IDs, at least. My work-around has been to make locale:catalogs/mylang/3.9, fill them with catalog files  from catalogs/mylang/sys of 3.9, and then binary edit the 3.9 binaries to look there. Or vice versa.
Title: Re: The Os 3.1.4 Thread
Post by: cehofer on December 30, 2018, 07:37:15 PM
First off, I apologize ahead of time if this has been discussed or if there is a thread discussing the A4000T and scsi.device.

I need some help on my Amiga 4000T.  I installed the 3.1.4 ROMs yesterday.  The machine boots, displays the 3.1.4 ROM graphic asking for the floppies.  It did not recognize my HD.  I booted off the 3.1.4 "Install" floppy, ran HDtools and it would not recognize any of my SCSI devices using the scsi.device.  It scanned LUN0 -7, device 0-7 and nothing.  My devices are LUN0, CD address 1 and HD address 5.

I re-installed my 3.1 ROMs and the machine booted as normal.  The old scsi.device is version 43.45.

The instructions provided only pertain to installing the ROMS correctly.  It appears I did this correctly because I get a magenta screen with the insert floppy animation and it will boot off the Install floppy.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on December 30, 2018, 08:35:05 PM
I need some help on my Amiga 4000T.  I installed the 3.1.4 ROMs yesterday.  The machine boots, displays the 3.1.4 ROM graphic asking for the floppies.  It did not recognize my HD.  I booted off the 3.1.4 "Install" floppy, ran HDtools and it would not recognize any of my SCSI devices using the scsi.device.  It scanned LUN0 -7, device 0-7 and nothing.  My devices are LUN0, CD address 1 and HD address 5.
*Which* ROMs did you install? There are ROMs for the A4000, and for the A4000T. They are both different - did you order the correct one? And which device is your harddisk connected to? The NCR scsi, then the device name is "NCR scsi.device" and not "scsi.device". If it is a scsi harddisk, you need to change the device name in HDToolbox. If it is an IDE harddrive, the name is "scsi.device" (just to confuse you).

I re-installed my 3.1 ROMs and the machine booted as normal.  The old scsi.device is version 43.45.
I don't know which ROMs you got, but this doesn't sound like a 3.1 ROM. The 3.1 version numbers are 40.something.
Title: Re: The Os 3.1.4 Thread
Post by: cehofer on December 30, 2018, 09:32:48 PM
It appears I ordered the incorrect set of ROMs for the A4000.  Normally, they are the same.  I have a desktop as well so no loss there.  This is SCSI not IDE so I wonder if I rename the device to NCR as you suggested if that would work.  I remember off my desktop that the IDE mimics a scsi.

These are 3.1 Roms but I have upgraded 3.9 all the way to BB4.  The ROMs have stamped on them 40.70 1995
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on December 30, 2018, 09:38:01 PM
It appears I ordered the incorrect set of ROMs for the A4000.  Normally, they are the same.  I have a desktop as well so no loss there.  This is SCSI not IDE so I wonder if I rename the device to NCR as you suggested if that would work.  I remember off my desktop that the IDE mimics a scsi.
At this time, renaming would not work simply because the device is not included in the A4000 ROMs. Yes, the "scsi.device" emulates a couple of scsi commands, but these commands go straight to the IDE interface and not to the NCR scsi host adapter chip on the A4000T. While the IDE logic on the A4000T is identical to that of the A4000, the A4000 does not have a true SCSI connector and for that reason the "NCR scsi.device" is missing.

These are 3.1 Roms but I have upgraded 3.9 all the way to BB4.  The ROMs have stamped on them 40.70 1995
So the "NCR scsi.device" is then updated via ROM updates. Yes, this gives the V43 version number indeed.
Title: Re: The Os 3.1.4 Thread
Post by: cehofer on December 31, 2018, 01:38:07 AM
Thomas,

I want to thank you.  That was a d'oh! on my part.  I contacted Amiga on the Lake and they will swap the ROMS no problem.   I will let you know when I get it running.

Thanks again!
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on January 01, 2019, 03:25:20 AM
I downloaded the AIFF and WAV datatypes on aminet and tried them for 3.1.4.  I then tried to play an AIFF from a CD but multiview says format not recognized.  Are the
http://aminet.net/package/util/dtype/AIFF_dtc code need to be updated for 3.1.4 to work?

Title: Re: The Os 3.1.4 Thread
Post by: dschallock on January 02, 2019, 05:52:57 PM
Ok, I have installed my 3.1.4 ROMS (bought from AOTL) and the software via the disks provided.
My system is an Amiga 3000 with a cyberstorm MK II 060 installed.
I purchased the Amiga 3000 3.1.4 ROMS and disks from Amiga On The Lake.


Everything seems to be working great.  I have noticed a few issues but they may have nothing to do with 3.1.4.


1) I have been getting checksum errors on my HD seemingly randomly.  I took the HD out of the equation and installed a scsi to micro sd adapter from Amiga Kit and did a fresh install of 3.1.4 on that flash media.  Everything works fine, but if I play around long enough and copy lots of data onto the drive then I was able to get some checksum errors too.  I went back to the spinning scsi HD and it seems to work fine for quote a while then I eventually get some errors. This "working fine for a while and then errors" makes me suspect something else like a heat related issue rather than 3.1.4.  I should mention that I have 3 partition on the HD.  I reformatted the "Workbench" partition before installing 3.1.4 using the standard format command from workbench.  However the drive has 2 other partitions (work and work2) that have all the years of personal data collected... those partitions were formatted PFS II back in the late 90s.  I haven't had a technological opportunity to back all that data up and reformat those partitions yet.  I mention that because I don't know if the PFS II format is mucking up the issue.

2) I use Dopus 4 as my "go to" file browser for years.  I have an external scsi cd rom drive plugged into the Amiga 3000's external scsi port.  After the install of 3.1.4 I copied the CD0 driver from storage into the devs directory and modified the icon tool type to the ID number of my drive.  rebooted.  Everything working great!  I noticed when I run DOPus and click on the shortcut "CD0" on the bottom it consistently crashes the system.  Alternately if I type the name of the cd inserted into DOPUS (like; AmigaFiles: ) it loads the contents into the DOpus window just fine... no crashes.

3) Since the installation of 3.1.4 Roms and software there seems to be some games that don't want to run that ran before with 3.1 .  One notable example of a game that does not work (although in all fairness I didn't test it before) is the new Amiga game "Worthy".  I purchased the boxed edition and it comes with a CD Rom and a floppy you can boot from.  I have searched the message forums and the game seems to run for everyone but I just get a grey screen.  Now, this of course in all likely hood has nothing to do with 3.1.4... but I thought I would mention it in case it was somehow a clue to something common going on with my installation. 

Thanks!
Dan
Title: Re: The Os 3.1.4 Thread
Post by: outlawal2 on January 02, 2019, 09:17:58 PM
Are there instructions on how to install the AmigaOS-3.1.4-IconPack.lha that can be downloaded off the Hyperion website?
These are not the same icons that are included on the Storage disk.

Title: Re: The Os 3.1.4 Thread
Post by: giZmo350 on January 02, 2019, 10:12:15 PM
Create a folder called glowicons   [ example: work:glowicons ]

Dump Hyperion icons in new folder
Open a shell and enter:
copy work:glowicons/#? sys: all
and reboot.

Might just work.....  ;)
Title: Re: The Os 3.1.4 Thread
Post by: outlawal2 on January 03, 2019, 03:48:27 AM
Tried that before i asked the question and it copied everything over..  Restarted and no change to my icons..  :-[
Title: Re: The Os 3.1.4 Thread
Post by: NinjaCyborg on January 04, 2019, 11:20:19 AM
the iconpack is a set of icons in the same style as 3.1.4 glowicons, for you to put on your work: drawers, projects and apps as you see fit. It's not the same as the workbench iconset on the storage disk. It's just in the same style.
Title: Re: The Os 3.1.4 Thread
Post by: outlawal2 on January 04, 2019, 01:30:52 PM
OK so exactly how do you use them?  Please tell me you don't have to individually select each one to change them?
Again telling people to "use them as you see fit" is not very helpful when people are asking HOW do you use them?

This is a recurring theme on these forums when people ask for assistance and get responses that do not explain HOW to do things.
An example is a question asking about how to connect an Amiga to the internet and the typical response is "Use Miami" with no explanation on how to use Miami.
This is not helpful.

So again, exactly how are the icons used?

Title: Re: The Os 3.1.4 Thread
Post by: TribbleSmasher on January 04, 2019, 03:01:01 PM
Icons are seperate files that provide a picture and sometimes additional informations. So if you want to use them, you copy or drag'n'drop them to the place you want.
If you have a program called MyTool then there is probably a file MyTool.info at the very same place. That MyTool.info file is the icon. Note that you cannot see the .info extension on the Workbench as it is hidden. If you have another nice looking icon you can normally just drop it into the same place as the old one. But:
The old one might have extra settings stored in the tooltypes which you can access from the information menu. You need to keep those or remember them, as the new icon might have different ones or none at all. There are special tools to swap only the image of icons.
Also important is, that you can use an icon with a different name and just rename it to your needs, but you must not mixup the different types, e.g. don't use a tools icon for a drawer.
All that is a little bit harder to do with Workbench, you might be better off using a file manager, like Directory Opus or DosControl.
Also, you must never put icons to programs that had none in the first place, as they are not intend to run from workbench. But it's fine for drawers.
Title: Re: The Os 3.1.4 Thread
Post by: F1Lupo on February 28, 2019, 12:04:55 AM
I got my 3.14 ROMS and disk and want to do a fresh install in my A4000 with Cyberstorm MKIII and VA2000RTG (P96) video card
questions:1- do I need to copy over my 060 drivers to a disk before starting or ok to just use 060 drivers on install disks?
2- been a while and I remember it was a pain in the arse to get P96 working so can I get my RTG card up and running without P96 installed on a fresh install or do I need a separate monitor to start and then install RTG card and P96?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on February 28, 2019, 06:23:31 AM
do I need to copy over my 060 drivers to a disk before starting or ok to just use 060 drivers on install disks?
I do not know what you mean by "060 drivers" - probably the 68060.library? No, you do not need to make a backup, the installer does not overwrite it.

2- been a while and I remember it was a pain in the arse to get P96 working so can I get my RTG card up and running without P96 installed on a fresh install or do I need a separate monitor to start and then install RTG card and P96?

You can also install from the running workbench by inserting the install disk and run the installer from there. However, before resetting the system, you may want to check in the freshly installed startup-sequence, whether the monitor drivers for P96 are loaded, i.e. the startup-sequence may require some editing after installation. If you do not have a second monitor that is able to show the native Amiga screen, it is advisable to keep a backup of the startup-sequence (actually, the installer will make one for you).
Title: Re: The Os 3.1.4 Thread
Post by: F1Lupo on February 28, 2019, 02:04:21 PM
@ Thomas
ok so then rather than starting from a 'clean' drive you're saying to install new 3.14roms and 3.14 from install disks over my existing AmigaOS boot drive/folder?

Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on March 01, 2019, 10:12:33 AM
@ Thomas
ok so then rather than starting from a 'clean' drive you're saying to install new 3.14roms and 3.14 from install disks over my existing AmigaOS boot drive/folder?

Both is possible. If you install over your existing installation, it will replace the components that have been installed before. Certainly, the workbench then looks a bit "messed up" as the icons from your previous installation may then overlap with the new icons. If you want to avoid that, make a clean install, and copy your own data back from a backup, including the 68060.library.
Title: Re: The Os 3.1.4 Thread
Post by: F1Lupo on March 01, 2019, 03:50:13 PM
@ Thomas
thanks :)
Title: Re: The Os 3.1.4 Thread
Post by: cehofer on March 13, 2019, 02:59:38 PM
I have upgraded my 3.9BB4 A4000D and A4000T to 3.14.  One thing I noticed right away is that Aweb-II will no longer execute on both machines.  I am able to change HD back to 3.9BB4 and no issues.   That seems to be the most stable browser I have.  Any idea why or is there a recommended browser
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on March 13, 2019, 03:23:21 PM
I have upgraded my 3.9BB4 A4000D and A4000T to 3.14.  One thing I noticed right away is that Aweb-II will no longer execute on both machines.  I am able to change HD back to 3.9BB4 and no issues.   That seems to be the most stable browser I have.  Any idea why or is there a recommended browser

Is this the AWeb-II browser that was bundled with Os 3.9? If so, then this is intentional. The browser was not supposed to be used with any other operating system, and it uses some (undocumented) hooks in IPrefs and workbench.library to identify the host system.
Title: Re: The Os 3.1.4 Thread
Post by: Minuous on March 13, 2019, 04:34:16 PM
No, the version of AWeb in BB4 is a much later version than what was originally in OS3.9, from after AWeb was open sourced, and should not have any deliberate restrictions.
Title: Re: The Os 3.1.4 Thread
Post by: cehofer on March 13, 2019, 05:18:29 PM
Yes, the Aweb II I was using was 3.4.167SE (11/22/00) so looks like from 3.9.  This was the one not working.  I wonder why BB4 didn't install this the new one. 

I manually installed  3.5.09 (07/05/11) version from BB4 and it worked.

Thanks!!!
Title: Re: The Os 3.1.4 Thread
Post by: cehofer on March 18, 2019, 03:34:16 PM
I have a question about my Oktgon 2008 v6.8 on 3.14.  The card by design has up to 8MB on board.  Per the Oktagon instructions, you can add up to 6MB of memory and the Amiga will find and use it no problem.  However if you add 2MB more giving you 8MB on the card, the Amiga autoconfig will shut off that 2nd 4MB bank down and allocate it for an IBM Bridgeboard by design.  Is there a way to configure 3.14 to not do this?  When I boot with 8MB installed, I get the ROM board diagnostic screen saying the 2nd bank 4MB of the Oktagon has been disabled <CONTINUE>.  Scout will see the 2nd bank of 4MB but says it is bad memory.  I have moved the zip chips around and tested them.  They are all good.   

I will never use a Bridgeboard on this system so it would be nice to shut this "feature" off if I can.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on March 19, 2019, 08:54:24 PM
I have a question about my Oktgon 2008 v6.8 on 3.14.  The card by design has up to 8MB on board.  Per the Oktagon instructions, you can add up to 6MB of memory and the Amiga will find and use it no problem.  However if you add 2MB more giving you 8MB on the card, the Amiga autoconfig will shut off that 2nd 4MB bank down and allocate it for an IBM Bridgeboard by design.  Is there a way to configure 3.14 to not do this?
Nope. This is a hardware limitation.

When I boot with 8MB installed, I get the ROM board diagnostic screen saying the 2nd bank 4MB of the Oktagon has been disabled <CONTINUE>.
Scout will see the 2nd bank of 4MB but says it is bad memory.  I have moved the zip chips around and tested them.  They are all good.   

I will never use a Bridgeboard on this system so it would be nice to shut this "feature" off if I can.
I do not quite understand. If the memory is "shut down for a bridgeboard", then where is the bridgeboard? Remove it, and you will be good. There is only 8MB of autoconfig space available, so the system needs to do something about it.
Title: Re: The Os 3.1.4 Thread
Post by: cehofer on March 19, 2019, 11:35:58 PM
I don't have a bridgeboard.  Maybe be a limitation of the V6.8 ROM of the Oktagon.

Here is right out of the oktagon 2008 manual:

"If you own or plan to purchase a PC or AT board in the future, then you may upgrade your controller to a max of 6MB.  The PC or AT boards require free address space  of the remaining 2MB.

In case you upgrade your controller to the full 8MB and activate it anyhow, the Amiga's operating system  disables 4MB of the 8MB and then makes it available  to the PC/AT  Board.  "

After reading this, it sounds like the Amiga is doing it.  Even if I set the jumper to "test", it activates the RAM but doesn't allow the Amiga to use it.  I still get the Board Diagnostics screen with the 4MB ram disabled.

Here is out of the GVP 2008 SCSI/RAM8 card out of the Big Book of Amiga Hardware:

"Memory Configurations Notes:

0MB, 2MB, 4MB, 8MB - Autoconfig, populate in pairs from the bottom (edge connector) upward, set jumpers.
6MB* - leave the third pair of SIMMs out and populate the top pair of SIMM sockets, set jumpers, and insert an AddMem command in the startup-sequence for address range 800000-9FFFFF.

* - this setting was intended for compatibility with the Commodore A2086/2286/2386 Bridgecards.  The Bridgecards required that it be AutoConfig-located in Zorro II Fast RAM expansion space, aligned at address 200000 or 600000, and allocated a 2MB segment.  The AddMem command mapped the additional 2MB of RAM on the card, on the top pair of SIMM sockets.  It was not possible to Autoconfig the additional 2MB of memory as another 2MB board as board slot order prevented the Bridgecard to be placed at one of it's preferred locations"

So it is the Amiga doing it in the Z2 Memory address space.  It also sounds like the Oktagon2008 is smarter than the GVP2008/4008. 

That also sounds like something that should be taken out or as an option because I doubt anybody is running a PC Bridgeboard anymore.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on March 20, 2019, 01:28:00 AM
I don't have a bridgeboard.  Maybe be a limitation of the V6.8 ROM of the Oktagon.
I cannot really tell you want the Oktagon does. However, I can tell you how the autoconfig process works. There, a board can indicate how much address space it needs in the 8MB autoconf window. All expansion does is that it tries to find a window in the 8MB available space to put the board into. If that does not succeed, the expansion library disables the board. The ROM cannot do much more because that is really a hardware limitation. Whether the oktagon is capable of populating a full 8MB window I cannot tell, and unfortunately, Oliver Kastl is quite out of reach. It is not a matter of the board ROM, but of the autoconfig logic on the board.

The only thing we can do at this moment is to observe the behaviour. Maybe you can run "showconfig" on the board with the 8MB populated, and post the result here. This would at least show what the board indicates to the Os. The Os is then rather in a "take it or leave it" position. It can include the board, or disable it, but it cannot resize it.

That also sounds like something that should be taken out or as an option because I doubt anybody is running a PC Bridgeboard anymore.
There is no "add a bridgeboard" function in expansion. Expansion (the part of the Os that configures autoconfig boards) does not really know anything about the board type except whether it is I/O or memory. Hence, there is no logic that can be changed regarding bridgeboards.

As far as their usage is concerned - actually, there are some, still. Not for any practical purposes, of course, but what is a practical purpose of an Amiga these days in first place, anyhow?

Title: Re: The Os 3.1.4 Thread
Post by: cehofer on March 20, 2019, 02:33:59 PM
Is my Picasso taking up the 2MB space and not allowing Oktagon to take the full space or is that different memory?

6MB
----------------------------------------------------------------------------------------------------------
PROCESSOR:      CPU 68060/68882fpu
CUSTOM CHIPS:   AA NTSC Alice (id=$0033), AA Lisa (id=$00F8)
VERS:   Kickstart version 46.143, Exec version 46.45, Disk version 45.194
RAM:    Node type $A, Attributes $505 (FAST), at $8000000-$FFFFFFF (128.0 meg)
        Node type $A, Attributes $505 (FAST), at $7400000-$7FFFFFF (12.0 meg)
        Node type $A, Attributes $605 (FAST), at $400000-$9FFFFF (6.0 meg)
        Node type $A, Attributes $703 (CHIP), at $4000-$1FFFFF (~2.0 meg)
BOARDS:
 Phase 5 Digital Products CyberStorm:   Prod=8512/25($2140/$19) (@$EA0000 128K)
 Village Tronic Picasso II(+) Memory:   Prod=2167/11($877/$B) (@$200000 2meg)
 Village Tronic Picasso II(+):   Prod=2167/12($877/$C) (@$E90000 64K)
 Village Tronic Ariadne Ethernet Card:   Prod=2167/201($877/$C9) (@$EC0000 64K)
 BSC Memorymaster:   Prod=2092/8($82C/$8) (@$600000 4meg Mem)
 BSC Memorymaster:   Prod=2092/8($82C/$8) (@$400000 2meg Mem)
 BSC Oktagon 2008:   Prod=2092/5($82C/$5) (@$ED0000 64K)

8MB
------------------------------------------------------------------------------------------------------------
PROCESSOR:      CPU 68060/68882fpu
CUSTOM CHIPS:   AA NTSC Alice (id=$0033), AA Lisa (id=$00F8)
VERS:   Kickstart version 46.143, Exec version 46.45, Disk version 45.194
RAM:    Node type $A, Attributes $505 (FAST), at $8000000-$FFFFFFF (128.0 meg)
        Node type $A, Attributes $505 (FAST), at $7400000-$7FFFFFF (12.0 meg)
        Node type $A, Attributes $605 (FAST), at $600000-$9FFFFF (4.0 meg)
        Node type $A, Attributes $703 (CHIP), at $4000-$1FFFFF (~2.0 meg)
BOARDS:
 Phase 5 Digital Products CyberStorm:   Prod=8512/25($2140/$19) (@$EA0000 128K)
 Village Tronic Picasso II(+) Memory:   Prod=2167/11($877/$B) (@$200000 2meg)
 Village Tronic Picasso II(+):   Prod=2167/12($877/$C) (@$E90000 64K)
 Village Tronic Ariadne Ethernet Card:   Prod=2167/201($877/$C9) (@$EC0000 64K)
 BSC Memorymaster:   Prod=2092/8($82C/$8) (@$600000 4meg Mem)
 BSC Memorymaster:   Prod=2092/8($82C/$8) (@$0 4meg Mem)
 BSC Oktagon 2008:   Prod=2092/5($82C/$5) (@$ED0000 64K)

Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on March 20, 2019, 06:20:49 PM
Is my Picasso taking up the 2MB space and not allowing Oktagon to take the full space ...
Precisely. That is 2MB video RAM, and this needs to sit, of course, somewhere.
Title: Re: The Os 3.1.4 Thread
Post by: F1Lupo on March 21, 2019, 10:50:55 PM
where is the new Disk Doctor located??? I can't even find it on the OS3.14 disks ?
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on March 21, 2019, 11:26:32 PM
where is the new Disk Doctor located??? I can't even find it on the OS3.14 disks ?

It is in C:

And in your floppies it should be on the "Extras" floppy, also in C:
Title: Re: The Os 3.1.4 Thread
Post by: paul1981 on March 22, 2019, 11:05:36 AM
where is the new Disk Doctor located??? I can't even find it on the OS3.14 disks ?

He was struck off in the 80's.  ;D
Title: Re: The Os 3.1.4 Thread
Post by: F1Lupo on March 23, 2019, 09:17:13 PM
@ Gulliver
and there I was looking for a nice new icon for it ;D ok found in C: but getting following screen: 'DiskDoctor: required arguement missing'  ??? ?

@ paul1981
 ;)
Title: Re: The Os 3.1.4 Thread
Post by: nbache on March 23, 2019, 10:25:35 PM
Wild guess: Maybe the doctor needs to know who the patient is (i.e. device name)?

Best regards,

Niels
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on March 23, 2019, 11:38:00 PM
@klx300r

Niels is right, you need to specify action and device name.

An example to diagnose DH0:

DiskDoctor examine DH0:

Remember that as most commands, using ? as arguments will give you all option/switches.
Title: Re: The Os 3.1.4 Thread
Post by: F1Lupo on March 24, 2019, 03:58:35 AM
ah yes now I remember DiskDoctor is only for disks..I was thinking of DiskSalv that saved my arse a few times that works on HD's and has a nice little GUI
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on March 24, 2019, 09:54:23 AM
ah yes now I remember DiskDoctor is only for disks..I was thinking of DiskSalv that saved my arse a few times that works on HD's and has a nice little GUI
Huh? DiskDoctor is for disks and harddisk partitions all alike, just provided that they are formatted with the FFS.
Title: Re: The Os 3.1.4 Thread
Post by: F1Lupo on March 24, 2019, 04:08:44 PM
ah yes now I remember DiskDoctor is only for disks..I was thinking of DiskSalv that saved my arse a few times that works on HD's and has a nice little GUI
Huh? DiskDoctor is for disks and harddisk partitions all alike, just provided that they are formatted with the FFS.
hmm I was thinking of the original not the new one with OS3.14....anyhow trying the 'new' DiskDoctor on an FFS SD card 2GB partition that popped up a few checksum errors now..fingers crossed  ;)
Title: Re: The Os 3.1.4 Thread
Post by: F1Lupo on March 24, 2019, 04:15:40 PM
I just noticed I lost a few icons on my AmiDock that were there before I installed 3.14 over my OS3.9 using Gulliver's script ? no big deal as I have another partition with only a clean OS3.14 just wonder why the icons disappeared?
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on March 24, 2019, 06:03:02 PM
I just noticed I lost a few icons on my AmiDock that were there before I installed 3.14 over my OS3.9 using Gulliver's script ? no big deal as I have another partition with only a clean OS3.14 just wonder why the icons disappeared?

This is just a guess due to insufficient information, but the Workbench preferences program has the "No NewIcons" option ticked by default in 3.1.4, and if you happen to have a NewIcon, it will not be displayed. So untick that option, save and reboot your machine and see if they now appear.

If this does not work, please confirm to what program the missing icons were for, so that I can try to help you in narrowing the problem you are having.
Title: Re: The Os 3.1.4 Thread
Post by: F1Lupo on March 27, 2019, 09:25:22 PM
I just noticed I lost a few icons on my AmiDock that were there before I installed 3.14 over my OS3.9 using Gulliver's script ? no big deal as I have another partition with only a clean OS3.14 just wonder why the icons disappeared?

This is just a guess due to insufficient information, but the Workbench preferences program has the "No NewIcons" option ticked by default in 3.1.4, and if you happen to have a NewIcon, it will not be displayed. So untick that option, save and reboot your machine and see if they now appear.

If this does not work, please confirm to what program the missing icons were for, so that I can try to help you in narrowing the problem you are having.
thanks for the tips...bit of troubleshooting found the culprit to be a checksum error on the partition where the program was on. Luckily DiskSalv solved the problem for me and after I booted up the icon appeared in my AmiDock again so all good :D
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on March 28, 2019, 01:29:26 AM
I am glad you got it solved.  :)
Title: Re: The Os 3.1.4 Thread
Post by: F1Lupo on March 28, 2019, 04:11:42 AM
I am glad you got it solved.  :)
thanks for your program and help  :)
Title: Re: The Os 3.1.4 Thread
Post by: Dynamic_Computing on March 28, 2019, 06:21:59 AM
I have AmigaOS 3.1.4 on my A500 with an ACA500+ - fresh install. Any time I try to use the intuition patch so I can move Windows off screen, I get a software error (a guru screen on boot) I have Amiga OS 3.1.4 on my A4000 and it works OK. Has anyone had a problem with the ACA500+ like this? (Amiga 500, rev 6 board, MegaAChip with 2MB - also tried on my Rev 5 A500 with 1 MB CHIP and same results.)
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on March 28, 2019, 03:58:23 PM
I have AmigaOS 3.1.4 on my A500 with an ACA500+ - fresh install. Any time I try to use the intuition patch so I can move Windows off screen, I get a software error (a guru screen on boot) I have Amiga OS 3.1.4 on my A4000 and it works OK. Has anyone had a problem with the ACA500+ like this? (Amiga 500, rev 6 board, MegaAChip with 2MB - also tried on my Rev 5 A500 with 1 MB CHIP and same results.)

For starters, it would be helpful to know which guru you see. How much memory is avaialble in total? 1MB total will not make you happy.
Title: Re: The Os 3.1.4 Thread
Post by: Dynamic_Computing on March 28, 2019, 10:49:35 PM
My system has the 2 MB Megachip, so 2 MB of CHIP RAM and 7 MB on the ACA500+. Plenty of RAM. My point where I reference 1 MB was just explaining that I tried it on two different Amiga 500, one with one megabyte of Chip ram one with 2 megabytes of Chip ram. Both machines had 7 megabytes of fast ram. When I try to load the intuition.library it will often just give me the flashing red "software failure", but today it is crashing to the green ACA500+ error screen. I will have to edit down the photo that I took - too big for an attachment.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on March 29, 2019, 12:21:31 AM
When I try to load the intuition.library it will often just give me the flashing red "software failure", but today it is crashing to the green ACA500+ error screen.
No need for a photo. I only need the number that is shown in the software error. It's an 8 digit number that identifies the cause of the problem.
Title: Re: The Os 3.1.4 Thread
Post by: cehofer on April 04, 2019, 12:08:01 AM
Have you been seeing any "Block Checksum" errors with 46.13?  I have a physical drive that 2 partitions, system and work that they have crept up on and on my SCSI2SD partition.  I have used Dave Haynie's DiskSalv4.  It detects the errors and supposedly repairs them but on reboot my Work partition still spends time re-indexing and will say "Block ###" has a checksum error "retry" "cancel".  It did seem to fix my System partition.  I even went as far as to copy my Work data to another drive, reformat and copy the data back, and I still get the error on copying.  Usually formatting will get rid of bad blocks on the drive.

This drive has been wiped and formatted with 46.13 from the start.  I did not update the file system.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on April 04, 2019, 06:19:37 AM
Have you been seeing any "Block Checksum" errors with 46.13?  I have a physical drive that 2 partitions, system and work that they have crept up on and on my SCSI2SD partition.  I have used Dave Haynie's DiskSalv4.  It detects the errors and supposedly repairs them but on reboot my Work partition still spends time re-indexing and will say "Block ###" has a checksum error "retry" "cancel".
Argh! Never, ever, use DiskSalv4 on a disk with partitions that extend beyond the 4GB bondary. This will successfully corrupt your disk (as seen) as the tool does not speak NSD, TD64 nor DirectSCSI. To rescue disks from a corrupt disk, use DiskDoctor, which is part of the toolchain you received with 3.1.4.

This said, both diskdoctor and DiskSalv report false positives from time to time - this will be fixed in 3.1.4.1. Meaning, it will report (erraneously) some false "corrupt header blocks" that are, actually, completely fine (and data blocks of a file).

Best cure is to retrieve all files on the mentioned disk with DiskDoctor (delivered on the Extras disk) to a new disk, format the corrupt disk, and copy files back. DiskSalv *cannot* repair partitions beyond the 4GB boundary. Instead, it will corrupt them.
Title: Re: The Os 3.1.4 Thread
Post by: cehofer on April 04, 2019, 08:22:58 PM
I did not run Disksalve4 until I had the checksum issue.

The two physical partitions in question are System 970MB and Work 1.4GB.  This is a 4Gig drive total.  The third partition on that drive has not given me issue.  I have learned early on that the Boot or System partition I keep under a gig.  The SCSI2SD in question is only a 1.9G partition.

Here is what seemed to fix the issue on Work and the SD card.  I first reformatted Work with FFS and International (default) checked.  Even after that, I would still get those checksum errors when copying back to that partition.   I then reformatted it with only FFS and no International and no trashcan.  That seemed to fix it.  I filled the partition copying data to it and deleting it successfully.  I did the same to the SCSI2SD partition.  They are behaving now.

 Can you explain what "International mode" is?

I had a crash.  I backup to my Western Digital Worldbook NAS using the SMBFS2.1, Deneb v9, poseidon 4.5 and a linysys usb nic.  I have another 4000T and 4000D running 3.1.4 but using Ariadne and CBM2065 NIC running the same SAMBA and SMBFS2.1.  They backup fast and without issue.

BTW, I don' t know if you updated the BSDSocket lib or what, but network speed has greatly improved with 3.1.4.

This 4000T with USB/nic, Internet is fast but for whatever reason SMBFS is slow.  I'm talking floppy slow.  And for whatever reason, it will lock up my NAS and in turn crashing the Amiga.  I don't know why the SMBFS doesn't time out but it doesn't.  I have to power cycle my NAS to get it back.

I was doing a backup to the NAS when it crashed and after that I had these Checksum issue.  I found it odd that I had the checksum issue or corruption while reading from the disk instead of writing to it. 

I usually backup to USB and then copy that to NAS.  I was tweeking Genesis hoping to get better performance out of the usb/nic when all this happened.  I can't find anything anywhere to help my usb/nic. 

FYI, I am not using DMA for my Deneb as it says it conflicts with the SCSI card.

Title: Re: The Os 3.1.4 Thread
Post by: wiser3 on April 04, 2019, 11:49:19 PM
this will be fixed in 3.1.4.1

Any other sharable news of what will be fixed in 3.1.4.1? Is it based on the 3.1.4 ROM? I'm not thrilled about buying another ROM set but would if it included off-screen window dragging.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on April 05, 2019, 07:13:59 AM
Any other sharable news of what will be fixed in 3.1.4.1? Is it based on the 3.1.4 ROM? I'm not thrilled about buying another ROM set but would if it included off-screen window dragging.
There is no new ROM for 3.1.4.1. Anything beyond 3.1.4.1 if there may be a new ROM will still be shipped with intuition v40 as cybergraphics is incompatible and we cannot fix that.
Title: Re: The Os 3.1.4 Thread
Post by: Orphan264 on April 05, 2019, 02:32:33 PM
Can you explain what "International mode" is?

I would also like to know more about that. If I recall it first appeared around the time Workbench 2.04 was released, but I could be wrong...
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on April 05, 2019, 03:13:58 PM
The international mode of the FFS changes how file names with international characters are handled. Note that FFS is not case-sensitive, that is, file name matching needs to know how to convert letters from lower case to upper case to identify a file name - and also how to compute the hash-value of a file name to quickly locate the file.

Now, the OFS originally only did that based on the ASCII encoding, i.e. it would identify a=A, but it would fail on the upper half of the ISO-Latin-1 encoding, namely ä!=Ä. So, it was case-senitive for "funny German Umlauts" to give one example.  The international mode finally made the FFS "ISO-Latin" aware.

All "modern" variants of FFS are "international" in this respect, i.e. handle upper and lower case correctly and handle case-insentivitiy also for letters beyond the ASCII set. That is, the dircache, long file name and long-file-name compatibility variants of FFS and OFS are all fine in this respect.

There is really little reason - except for legacy or compatibility to 1.3 - to use the incorrect (first generation) versions.

Other than that, the administration information and block layout etc. is all the same.
Title: Re: The Os 3.1.4 Thread
Post by: gregthecanuck on April 05, 2019, 11:10:29 PM
There is no new ROM for 3.1.4.1. Anything beyond 3.1.4.1 if there may be a new ROM will still be shipped with intuition v40 as cybergraphics is incompatible and we cannot fix that.

Have you considered shipping the new intuition in ROM and making some sort of patch available for cybergraphics compatibility instead? i.e. something that patches in the old v40 intuition? This could be an option at the time of installing 3.1.4.
Title: Re: The Os 3.1.4 Thread
Post by: jsixis on April 06, 2019, 12:30:51 AM
if there is no NEW Rom for 3.1.4 then why was I sold one?
This is starting to stink.
Title: Re: The Os 3.1.4 Thread
Post by: wiser3 on April 06, 2019, 01:04:36 AM
if there is no NEW Rom for 3.1.4 then why was I sold one?
This is starting to stink.

There is a new ROM for 3.1.4.
There will not be new ROM for 3.1.4.1. Notice the additional .1.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on April 06, 2019, 08:28:31 AM
Have you considered shipping the new intuition in ROM and making some sort of patch available for cybergraphics compatibility instead? i.e. something that patches in the old v40 intuition? This could be an option at the time of installing 3.1.4.
And how exactly should I create such patches? And how ship them? We don't have sources for CyberGraphics, leave alone any rights on it. CyberGraphics depends critically on the stack layout and register allocation of the old GreenHill compiler, running only on old Sun Sparcs, as soon as you compile the old code with a new compiler, CyberGfx does no longer work.

If you want intuition v45 in ROM, write Frank Mariak to update CyberGraphics. I'm happy to help, deliver test versions to him, or add hooks for CyberGraphics to receive intuition internal information, with all the blessings from Hyperion. But I,  personally, will not touch CyberGraphics. It's Frank's code, not mine.
Title: Re: The Os 3.1.4 Thread
Post by: gregthecanuck on April 06, 2019, 09:44:22 AM
Have you considered shipping the new intuition in ROM and making some sort of patch available for cybergraphics compatibility instead? i.e. something that patches in the old v40 intuition? This could be an option at the time of installing 3.1.4.
And how exactly should I create such patches? And how ship them? We don't have sources for CyberGraphics, leave alone any rights on it. CyberGraphics depends critically on the stack layout and register allocation of the old GreenHill compiler, running only on old Sun Sparcs, as soon as you compile the old code with a new compiler, CyberGfx does no longer work.

If you want intuition v45 in ROM, write Frank Mariak to update CyberGraphics. I'm happy to help, deliver test versions to him, or add hooks for CyberGraphics to receive intuition internal information, with all the blessings from Hyperion. But I,  personally, will not touch CyberGraphics. It's Frank's code, not mine.

Hi Thomas - I wasn't suggesting to patch CyberGraphics... instead some sort of run-time patch to intuition to slot in V40 or some sort of interface patch to make it work with CyberGraphics. It seems a shame to hold back a nicely updated intuition for a 'dead' set of third-party libraries.

Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on April 06, 2019, 09:49:42 AM
Hi Thomas - I wasn't suggesting to patch CyberGraphics... instead some sort of run-time patch to intuition to slot in V40 or some sort of interface patch to make it work with CyberGraphics. It seems a shame to hold back a nicely updated intuition for a 'dead' set of third-party libraries.
As said, the problem is not identified in source code. It is the stack frame layout and the register allocation that Cybergraphics seem to depend on. However, without knowing what exactly CyberGraphics depends on, I can hardly do anything. It really needs Frank to do some work.
Title: Re: The Os 3.1.4 Thread
Post by: Dynamic_Computing on April 06, 2019, 02:38:50 PM
There is no new ROM for 3.1.4.1. Anything beyond 3.1.4.1 if there may be a new ROM will still be shipped with intuition v40 as cybergraphics is incompatible and we cannot fix that.

Have you considered shipping the new intuition in ROM and making some sort of patch available for cybergraphics compatibility instead? i.e. something that patches in the old v40 intuition? This could be an option at the time of installing 3.1.4.

I agree that this is not the best idea. The intuition patch crashes my system with my ACA500+ and I have not found a workaround yet. It works ok on my A4000, but causes graphics artifacts when I drag a few Windows off screen and then back. Notably, iBrowse Windows on workbench on my RTG Cybergraphx 4D card using picasso96. (I have never used the Cybergraphx RTG software).
I love the freedom of moving Windows off screen, but as I have issues with two out of two systems that AmigaOS 3.1.4 is installed on when using the new intuition, I suspect committing it to ROM would be a bad move right now.
Title: Re: The Os 3.1.4 Thread
Post by: cehofer on May 02, 2019, 04:38:56 PM
Thomas,

One thing I noticed that is completely different is the Printer Preferences.  My 3.9bb4 is version 44.23 11/24/99 and has more options as to device unit #, unit name but more importantly the ability to configure a custom print device such as usb or netprint.device.  I have looked in the icon information but I don't see any TOOLTYPES that I can turn on to add these to my printer preferences. 
I tried:
DEVICE=netprinter.device
UNITNUM=0

Then when I went into Netprinter Prefs and configured my printer IP and hit either SAVE or USE, the system crashes with 80000004 every time.

Netpar still works with these Tooltypes configured and redirects to Parallel.  I would think NetPar would stop working as well until I removed those Tooltypes.

 Also version 44.23 has  three tabs to it page size/Margins and settings.  The 3.1.4 printer preferences version 45.3 9/11/18 is just a single page with them combined.   I was able to use NetPar which has a custom parallel.device that redirects parallel to network but I would like to use USB too. 

Can you give some guidance?

Thanks.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on May 03, 2019, 07:38:22 AM
One thing I noticed that is completely different is the Printer Preferences.  My 3.9bb4 is version 44.23 11/24/99 and has more options as to device unit #, unit name but more importantly the ability to configure a custom print device such as usb or netprint.device.  I have looked in the icon information but I don't see any TOOLTYPES that I can turn on to add these to my printer preferences. 
You can't, because there are no fields like this in the preference editor right now. You can continue to use the 3.9 prefs, though. Just make sure you delete the "printergfx" preferences file in ENVARC:sys. The printer device does support printing to other devices than parallel and seriell, and supports the prefs format of 3.9.

Then when I went into Netprinter Prefs and configured my printer IP and hit either SAVE or USE, the system crashes with 80000004 every time.
What is a "netprinter prefs" (I do not know such a program, nor is it part of 3.1.4.)?

Title: Re: The Os 3.1.4 Thread
Post by: kolla on May 03, 2019, 11:13:39 AM
What is a "netprinter prefs" (I do not know such a program, nor is it part of 3.1.4.)?

You ask people to hunt Aminet for your own stuff to "complete" 3.1.4, but you are incapable of searching Aminet for "netprinter" yourself?

http://aminet.net/package/comm/tcp/NetPrinter
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on May 03, 2019, 12:46:46 PM
You ask people to hunt Aminet for your own stuff to "complete" 3.1.4, but you are incapable of searching Aminet for "netprinter" yourself?
In bad mood again? What happened to you today?

What do you think I am? Your private service agent? Programmer, customer-care and technical support in one person?
Title: Re: The Os 3.1.4 Thread
Post by: kolla on May 04, 2019, 08:35:49 AM
What do you think I am? Your private service agent?
Certainly not.
Quote
Programmer, customer-care and technical support in one person?
Yes you are, by your own decision, that's apparently how you want things to be.

But that's all beside the point - which is that there are possibly compatibility issues with OS 3.1.4 print system and netprinter, which you easily could have found on Aminet, instead of pretending that you cannot be bothered.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on May 04, 2019, 09:26:36 AM
Yes you are, by your own decision, that's apparently how you want things to be.
Then be informed that I'm not. If you want to report problems,  go to Hyperion. I'm not saying this the first time.

But that's all beside the point - which is that there are possibly compatibility issues with OS 3.1.4 print system and netprinter, which you easily could have found on Aminet, instead of pretending that you cannot be bothered.
I am not *pretending* - I *AM NOT* your customer care service center. Not YOURs in particular. I you want me *privately* to look into something, you need to provide more information, because my time is precious, and I'd rather like to spend it with more productive activities than searching for a particular piece of software.

 
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on May 06, 2019, 08:46:16 PM
Then when I went into Netprinter Prefs and configured my printer IP and hit either SAVE or USE, the system crashes with 80000004 every time.
Can you give some guidance?
Two, actually. No, three:

1) Please replace the icon of this program. It is corrupt and not in proper format. Just copy any other icon over.

2) The only problem I could detect was that this program requires more stack than the usual 4K. Thus, select the icon, select "Info", then enter a larger stack size in the window you see. I would suggest 32768 bytes (32K), but probably a smaller size will suffer.

3) Don't listen to trolls like Kolla. If I receive proper information, I can help. This is a "give and take". If you make my job easier, I can help you better.

So much for "conspiracy theories" of "3.1.4 is guilty for breaking programs."
Title: Re: The Os 3.1.4 Thread
Post by: pixie on May 06, 2019, 09:12:22 PM
How does 3.1.4 stack against 3.9, version wise? It's more like 14 or 1.4?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on May 07, 2019, 05:44:12 AM
How does 3.1.4 stack against 3.9, version wise? It's more like 14 or 1.4?

There is probably not any difference. We just made the stack of ramlib and some intuition functions a bit larger to avoid common problems of 3.1. However, what has probably happened here is that the user had a "Stack" command in his S:Startup-Sequence, and replacing that with the official 3.1.4 startup sequence removed it.

When writing a program, you can tell the system how much stack the program should get at least. For that, place the following "magic cookie" in your program code:

const char stackcookie[]="$STACK:32768\n";

The newline is necessary. Both the workbench and the shell scan for the pattern, and adjust the stack upwards if they find it.
Title: Re: The Os 3.1.4 Thread
Post by: pixie on May 07, 2019, 09:33:44 AM
My bad, english is not my native language, I meant stack as in compare. I know it is a bit trivial question to make and probably is answered elsewhere, is that is a bit odd convention scheme. cheers
Title: Re: The Os 3.1.4 Thread
Post by: nbache on May 07, 2019, 10:33:03 AM
@pixie:

I think you are talking about the version numbering itself, right?

Note that 3.1.4 is not building upon 3.9 (nor 3.5), but developed on top of 3.1 as a new "branch". Therefore it would not make sense to give it a revision number which increases from .9 (like .14). Some of the features which were in 3.5/3.9 have (if I understand correctly) been redeveloped "from scratch" on top of 3.1 for 3.1.4. But in its nature it is an update of 3.1.

Best regards,

Niels
Title: Re: The Os 3.1.4 Thread
Post by: kolla on May 07, 2019, 04:14:25 PM
Note that 3.1.4 is not building upon 3.9 (nor 3.5), but developed on top of 3.1 as a new "branch". Therefore it would not make sense to give it a revision number which increases from .9 (like .14). Some of the features which were in 3.5/3.9 have (if I understand correctly) been redeveloped "from scratch" on top of 3.1 for 3.1.4. But in its nature it is an update of 3.1.

That's not entirely correct, as certain components - and I would rather say, core components - such as Workbench (workbench.library), the CLI (shell-seg) and quite a few others, are direct descendants of OS 3.5/3.9, and certainly not developed "from scratch" for OS 3.1.4. It was all about what was available legally and practically to develop from. In many ways, OS 3.1.4 complements OS 3.9, as it has focused on components that did not see any changes from OS 3.1 to 3.9.
Title: Re: The Os 3.1.4 Thread
Post by: cehofer on May 08, 2019, 01:23:45 AM
Thomas,

I am sorry I started a fight here.  First off, I want to say I for one greatly appreciate your help and knowledge of the Amiga OS in general.  Thank you for that!  I was hoping you were going to say to just add some "tooltypes" to the printer prefs and I would be good to go.  I have been busy so I haven't had a chance to try restoring 3.9 printer prefs.  It doesn't sound too difficult.

Kolla is correct that netprinter is a network printer redirection program on aminet.  I will have to restore 3.9 printer prefs and see if I keep getting that crash when I try to use or save netprinter prefs. 

I am currently using netpar, also on Aminet, and it works nice with my new HP CLJ Pro MFPM281 printer.  I have printed from Pagestream4 and Finalwriter97 in color.  What seems to work best in Finalwriter is using the Postscript driver.  It is nice that HP still makes printers on PCL5, 5e and 5c along with Postscript even though that is emulated but it still works.  The only beef I have with NetPar is that it has a banner page and wastes a page of paper every print.  I cannot figure out how to shut it off in the docs.  It is annoying!  So if somebody knows hot to stop the Banner print page, I would highly appreciate it!
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on May 08, 2019, 06:45:35 AM
I am sorry I started a fight here. 
No worries, you haven't. Just be aware that I am not the Hyperion support. If you have issues, I need all your help if you want me to hunt them down.

Concerning your particular problem, as stated, increase the stack size and all will be fine. Or use the 3.9 prefs if that suits you better.

The only beef I have with NetPar is that it has a banner page and wastes a page of paper every print.  I cannot figure out how to shut it off in the docs.  It is annoying!  So if somebody knows hot to stop the Banner print page, I would highly appreciate it!
Not one of my programs, nor part of 3.1.4, so I'm out here.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on May 09, 2019, 06:30:38 AM
Unfortunately, it is up to me to report a bug myself and inform the users. As it seems, a bug present in the 3.9 version of the scsi.device made it into the 3.1.4 release without being identified in the code review.

The problem is that the scsi.device erraneously reports a problem if a block transfer of more than 255 blocks crosses a 4GB boundary. The transfer would have worked, data integrity is not harmed, but the command is aborted.

One can work around the problem by setting (*sigh* again) MaxTransfer to 1FE00, limiting block transfers to 255 blocks, as we had it before. So, we have - unfortunately yet again - revert to the old MaxTransfer workaround to cure glitches in the drivers, but this is the only practicle way how to get rid of the issue.

Thanks to Toni Willen for identifying and reporting the problem.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on May 09, 2019, 03:42:55 PM
Well, duh. I noticed that I needed max transfer settings pretty much right away half a year ago, but you insisted on calling me a liar and conspiracy theorist, and whatnot when I mentioned the problem.
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on May 09, 2019, 10:09:38 PM
It is all about me!  ;D
Title: Re: The Os 3.1.4 Thread
Post by: chris on May 09, 2019, 11:40:32 PM
I am currently using netpar, also on Aminet, and it works nice with my new HP CLJ Pro MFPM281 printer.  I have printed from Pagestream4 and Finalwriter97 in color.  What seems to work best in Finalwriter is using the Postscript driver.  It is nice that HP still makes printers on PCL5, 5e and 5c along with Postscript even though that is emulated but it still works.  The only beef I have with NetPar is that it has a banner page and wastes a page of paper every print.  I cannot figure out how to shut it off in the docs.  It is annoying!  So if somebody knows hot to stop the Banner print page, I would highly appreciate it!

Maybe try Olaf's lpr.device (http://aminet.net/package/comm/tcp/lpr-dev) instead.  I'd hope that is fully compatible given the author's involvement in OS3.1.4 :D (also I'm pretty sure it doesn't try to do anything fancy like banner pages, although it has been some years since I last used it)
Title: Re: The Os 3.1.4 Thread
Post by: cehofer on May 10, 2019, 07:02:32 PM
I installed the 3.9 printer prefs, printer gfx and printer PS along with the env-archive/sys printer.prefs.  When I tried to set up netprinter.prefs, it still crashed on use or save.

Chris, I will have to try lpr.device.

thanks
Title: Re: The Os 3.1.4 Thread
Post by: cehofer on May 10, 2019, 07:34:04 PM
Thomas,

Would this SCSI.device bug cause my harddrive light to come fully on and computer to crash.  I have had this issue with my 2 A4000Ts but not my 4000D with oktagon scsi.  What will happen without rhyme or reason, I have tried different size drives and different size partitions but on boot sometimes or sometimes drive access the HD light will go on full bright and computer will crash.   Since I have re-formatted my partitions without "international mode" it has occurred much less.  This has happened on 3.9 and 3.1.4  I am using the current 46.13 FFS.  On 3.9 I was using 45.13 the "unofficial ffs".  I have installed the new 46.13ffs on my 3.9 now.

I have the SD2SCSI V6 and  I am able to capture scsi traffic.   I contacted Michael McMaster, developer of SD2SCSI.  He analyzed the logs and told me that it was occurring during sync transfers.

"Please use scsi2sd-util to set the "speed" limit option to Async 5MB/s. I can see that the logs all show synchronous data transfers, and the hang occurred during a sync transfer. It would be good to know if the problems go away in async mode."

I could get this to occur on a regular basis using Samba swat web page on the A4000T.  I just go to the browse to the swat page and browse around on help, config, etc and the drive light would go fully on and A4000T would crash.   I did as Michael suggest and it did stop it for awhile but would still occur from time to time.  What has made my A4000T the most stable is formatting the drives without "international mode".  I have since put the SD2SCSI to full speed again and  I really don't see any difference.

My SCSI is configuration is I have a physical SCSI II 4gig HD partitioned :

1gig System
1.4 gig Work
1.6 gig Data.

I have several drives on the SD2SCSI 32Gig SD card divided into 2 SCSI IDs 4 and ID5 16G each:
900MB
1.8G
3.9
3.8
5.6

3.5
3.8
3.8
1.8

The controller is configured for Sync transfers and SCSI II.  The Termination is the SD2SCSI active termination built in it.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on May 10, 2019, 08:15:59 PM
, I have tried different size drives and different size partitions but on boot sometimes or sometimes drive access the HD light will go on full bright and computer will crash. 
No. This has absolutely nothing to do with the issue. The issue, to repeat this again, only affects transfers over 255 sectors that *also* cross a 4GB boundary. Hence, they are pretty rare. Even then, the system would not react with a deadlock, but with an error condition. What you see here is likely a hardware issue. I would also suggest to check the power supply.

I have the SD2SCSI V6 and  I am able to capture scsi traffic.   I contacted Michael McMaster, developer of SD2SCSI.  He analyzed the logs and told me that it was occurring during sync transfers.

The issue is also *only* in the IDE version of the (not-so) scsi.device. "Sync" transfers - and the SCSI2SD - are SCSI devices, not IDE devices.  Termination is one issue, if the host cannot catch up with the transfer speed of the SCSI2SD, then this is another issue.
Title: Re: The Os 3.1.4 Thread
Post by: kirk_m on May 20, 2019, 08:24:57 PM
Has anyone encountered any issues with SCSI drives no longer working after installing 3.1.4 on an A2000 that has a Blizzard 2060 accelerator card?  I swapped out my 3.1 ROMs for 3.1.4 yesterday, and, now the SCSI drives do not show up in the early startup, or, anywhere else for that matter.  The IDE drives are still visible, as I was able to install 3.1.4 onto a drive connected to the Buddha IDE controller.

If I reinsert the 3.1 ROMs, my SCSI devices (SCSI2SD and CDROM) are again visible and usable (indeed, the SCSI2SD is my 3.9 boot drive on this computer).
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on May 20, 2019, 09:22:21 PM
Has anyone encountered any issues with SCSI drives no longer working after installing 3.1.4 on an A2000 that has a Blizzard 2060 accelerator card?
Nope. Given that I own exactly this combo, and I develop (amongst others) on this combo - no, that should be (and provably, actually is) working quite fine.

I swapped out my 3.1 ROMs for 3.1.4 yesterday, and, now the SCSI drives do not show up in the early startup, or, anywhere else for that matter.  The IDE drives are still visible, as I was able to install 3.1.4 onto a drive connected to the Buddha IDE controller.
That sounds more like a hardware issue to me. Oh, yes, a SCSI2SD here, too.
Title: Re: The Os 3.1.4 Thread
Post by: giZmo350 on May 20, 2019, 09:59:48 PM
Has anyone encountered any issues with SCSI drives no longer working after installing 3.1.4 on an A2000 that has a Blizzard 2060 accelerator card?

I have the same setup, including a SCSI2SD V5 (SCSI2SD not in my sig A2000 though) and would try it out but alas, I do not yet own OS3.1.4.

Kirk, I thought you owned a SCSI card reader, i.e., a PCD-50B? If you do, you should use it with your Blizz 2060. It's ideal!  ;)
Title: Re: The Os 3.1.4 Thread
Post by: kirk_m on May 21, 2019, 03:07:35 AM
Thomas,

The HD activity light stays illuminated on the 2000, as well as the LED on the SCSI2SD when the 3.1.4 ROM is installed.  Also, 2060scsi.device shows up nowhere in the list of devices that are currently active on the system.  If I plug the 3.1 ROM back, all of this comes back, and, the LEDs behave as they should.   Also, reinstalling the 3.1 ROM makes everything work again -- all drives appear, I can boot from the SCSI drive, etc.  As soon as I put the 3.1.4 back, it disappears.

Does this steadily illuminated LED indicate anything?

Also what version firmware is on your 2060's ROM?  Sysinfo reports v8.2 on mine.  It seems that 8.5 is the last version made (at least according to the archive on A1K).  Does this make any difference?


Gizmo:

No, I don't have one of them there fancy card-readers :)
Title: Re: The Os 3.1.4 Thread
Post by: Rotzloeffel on May 21, 2019, 10:07:54 AM
Has anyone encountered any issues with SCSI drives no longer working after installing 3.1.4 on an A2000 that has a Blizzard 2060 accelerator card?

Same setup here! No problems and I am using a scsi2SD V5.....
Title: Re: The Os 3.1.4 Thread
Post by: kirk_m on May 21, 2019, 08:18:27 PM
Has anyone encountered any issues with SCSI drives no longer working after installing 3.1.4 on an A2000 that has a Blizzard 2060 accelerator card?

Same setup here! No problems and I am using a scsi2SD V5.....

Funny you should reply... I got my 2060 from you :)
Title: Re: The Os 3.1.4 Thread
Post by: Rotzloeffel on May 22, 2019, 07:47:03 AM
Funny you should reply... I got my 2060 from you :)

:) haha.... OK :) Never sell things, you not have twice :)

did you set the Jumper which copies the ROM into the FastRAM? Maybe there is a Problem? I did not set this Jumper!

I use MUFastROM instead....
Title: Re: The Os 3.1.4 Thread
Post by: kirk_m on May 22, 2019, 04:56:51 PM
It all works  now.  Very strange.  I messed with it a little more,   unplugging and plugging cables from the SCSI2SD itself, as well as reinstalling the ROM, and, then it booted from the SCSI2SD.  Maybe a bad connection.
Title: Re: The Os 3.1.4 Thread
Post by: paul1981 on May 22, 2019, 08:40:33 PM
It all works  now.  Very strange.  I messed with it a little more,   unplugging and plugging cables from the SCSI2SD itself, as well as reinstalling the ROM, and, then it booted from the SCSI2SD.  Maybe a bad connection.

Or a glitch in the matrix  8)
Title: Re: The Os 3.1.4 Thread
Post by: Jope on June 04, 2019, 08:27:20 AM
Thomas, I have a few requests about hdtoolbox..

- Please allow it to be used on CF cards that report themselves as removable
- Please make the minimum width of a partition's gadget two or maybe even five pixels in the partitioning screen - if you have for example a 500MB boot and a 60GB work, it is very difficult (or impossible?) to select the boot partition
Title: Re: The Os 3.1.4 Thread
Post by: Daedalus on June 04, 2019, 10:20:20 AM
I'm not sure if it supports the selection methods of previous versions, but on older versions of HDToolbox you could select any partition by clicking any other partition, then using the left and right cursor keys to cycle through them. I haven't used 3.1.4 on such a large hard drive so I haven't had a need for that method in the 3.1.4 version yet.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 04, 2019, 05:40:55 PM
- Please allow it to be used on CF cards that report themselves as removable

This is not a matter of HDToolBox. It is the matter of the host adapter to report a "random access device". This is the only device type that allows RDBs.
Title: Re: The Os 3.1.4 Thread
Post by: thyslo on June 06, 2019, 01:20:35 PM
While playing around with OS 3.1.4 and WinUAE I noticed the following:

When the 68040.library from the mmulibs package is installed in libs: the OS 3.1.4 SetPatch command consumes some MBytes of memory. In my example about 5 MBytes of fast memory which were missing after SetPatch run. It seems not to be important if there really is a 68040 CPU activated or if only a 68030 is set up in WinUAE.

With 68040.library installed, SetPatch (without QUIET) reports that it is activating some 68040 related patches. Without 68040.library it does not mention 68040 related patches and the 5 MBytes are not missing.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 06, 2019, 08:41:43 PM
Yes, of course. Whether it is 5MB or some other number depends on how much main memory you have. The 5MB are for the MMU tables the 68040 requires. The "CPU Checkinstall" in the startup-sequence should actually detect the case when the 68040.library is not loaded.

Less memory goes away for the 68030, though. It's MMU has a feature called "early termination page descriptors" that can safe quite a bit of memory by avoiding duplicated table descriptors. Unfortunately, Motorola stopped supporting them with the 68040 on.
Title: Re: The Os 3.1.4 Thread
Post by: thyslo on June 07, 2019, 07:33:46 AM
Ah thanks, now it makes sense:-)
Title: Re: The Os 3.1.4 Thread
Post by: kamelito on June 13, 2019, 11:53:11 AM
@Thomas Richter

> We'd love to include reaction, but we cannot.

Now it seem that you can : "Hyperion Entertainment and the AmigaOS development team would like to thank the original developers for creating ReAction and providing the opportunity to roll out ReAction on all versions of AmigaOS."

---
 Hyperion Entertainment
Full acquisition of ReAction GUI toolkit

ReAction logoBrussels, May 14, 2019

Hyperion Entertainment CVBA is pleased to announce that it has acquired full ownership of ReAction.

ReAction is the official AmigaOS GUI system since it was incorporated into AmigaOS 3.5 in 1999. With the release of AmigaOS 4 and newer it has been improved, bug-fixed and a more consistent and uniform look was created as is apparent from the various applications that make use of it. Hyperion Entertainment and the AmigaOS development team would like to thank the original developers for creating ReAction and providing the opportunity to roll out ReAction on all versions of AmigaOS.

Stay tuned for more news regarding ReAction in the near future!
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 13, 2019, 09:26:44 PM
Please don't underestimate the amount of work that has to go into this. Yes, we have reaction now. Christopher Aldi has been finally paid. It's been only 20 years... (-;

Still: Classes are in Os 4.x style at this point, need to be reviewed, to be broken down to a 3.x interface, need to be tested, and still someone has to write the prefs editors and the tools for them - as their sources were provided by H&P, and are hence are still not available. We could use the 4.x prefs editors, yet again, this means that they need to be adapted to the 3.x styles, reviewed, rewritten, tested... you get the picture. It's a long road, and we have only little man power.

So, I guess a minimal development time for this is 6-12 months, and - I personally - would believe that we should probably not delay 3.2 by that much. So maybe not right now, but certainly at some point.

Anyhow, that's in the end a management decision. Delay the process, or release sooner without reaction. A decision I really don't want to make.

Title: Re: The Os 3.1.4 Thread
Post by: kamelito on June 13, 2019, 10:08:01 PM
@Thomas Richter
Thanks  for answering. As for management décision I would suggest release early release often.
Ping me if you need QA.
Title: Re: The Os 3.1.4 Thread
Post by: guest21671 on June 14, 2019, 05:00:06 AM
3.2 already exists   They need to work on their numbering scheme
Title: Re: The Os 3.1.4 Thread
Post by: kolla on June 14, 2019, 06:41:51 AM
I would suggest release early release often.

Impossible!
Title: Re: The Os 3.1.4 Thread
Post by: kirk_m on June 15, 2019, 03:23:32 PM
I have encountered the following issue after installing 3.1.4 on a bog-standard A3000 16MHz (no expansion cards, 2mb fast, 2mb chip).

When setpatch runs after first reboot, the computer hangs with a purple screen if all caches are not disabled from early startup.  Commenting setpatch out allows the system to run if you haven't disabled the caches.  Using NODATACACHE NODATABURST NOCACHE NOBURST  in the startup sequence does not prevent the lockup -- all caches have to be disabled in the BOOT OPTIONS of early startup menu.

I have installed MMULIB to get the 68030.library for the install, same result.

I've run out of ideas now on how to get things working properly.  Any help is appreciated.
Title: Re: The Os 3.1.4 Thread
Post by: kirk_m on June 16, 2019, 02:02:29 AM
I figured it out.  The 3000 had 2mb of fast ram, all ZIPs.  They were all fast page mode, so I swapped them out for Static Column zips and now burst works, since FPM memory and burst are incompatible.
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on June 16, 2019, 03:03:38 AM
@deFriselle

3.2 does not exist. It was just 3.1 with changes on the Walker ROM to
acomodate its hardware and a SetPatch that changed the copyright
strings and audio cdrom support, nothing more.

On the numbering scheme, you should blame both Olaf and Thomas for
playing with MetaFont and loving the Pi number.  ;D

So, to sum up, 3.2 does not exist, but we are working on it  :-X

@kamelito

We hope we can release more often too!

@kirk_m

It is good that you solved it.
I will probably add this information to the FAQ, you never know who
might encounter the same issue.
Title: Re: The Os 3.1.4 Thread
Post by: guest21671 on June 16, 2019, 04:50:25 AM
By that logic 3.5 and 3.9 don't exist either
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on June 16, 2019, 05:22:42 AM
By that logic 3.5 and 3.9 don't exist either

No, 3.5 and 3.9 existed, were released and sold as such. They were real products.

3.2 was not ever sold or marketed like that. It was mostly amiga enthusiasts that labeled it that way or hoped that 3.2 would exist in some form. Just wishfull thinking that something else beyond 3.1 was there when there wasn't.
Title: Re: The Os 3.1.4 Thread
Post by: guest21671 on June 16, 2019, 05:47:50 AM
Oddly the few Walker built and in the hands of collectors run it.
http://www.blachford.info/computer/walker/walker_working.html

Doesn't matter   We won't see any versions between 3.1.x and 4.x.x   Maybe after the litigation is settled and C-A Acquisitions gets to work
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on June 16, 2019, 11:29:45 AM
Oddly the few Walker built and in the hands of collectors run it.
http://www.blachford.info/computer/walker/walker_working.html

Doesn't matter   We won't see any versions between 3.1.x and 4.x.x   Maybe after the litigation is settled and C-A Acquisitions gets to work

Well, you are wrong on both assumptions.  :)
Title: Re: The Os 3.1.4 Thread
Post by: guest21671 on June 17, 2019, 05:25:00 AM
No one else has the rights
Title: Re: The Os 3.1.4 Thread
Post by: kolla on June 17, 2019, 07:08:59 AM
The actual property owners have no rights? Remember that Hyperion is developing under a license - who grants them this license? Oh yes, that would be "the parties", which Hyperion are now in dispute with. Licensed rights can very well be revoked.
Title: Re: The Os 3.1.4 Thread
Post by: Minuous on June 17, 2019, 09:36:22 AM
It can't be revoked, it is a perpetual licence.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on June 17, 2019, 09:43:07 AM
It's only perpetual for as long as the licensee fulfills their obligations. Hyperion broke their obligations numerous times, and continue to do so.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 17, 2019, 05:29:47 PM
To all: Could you keep this b*llsh*t out of this thread? I asked in the very first post, so please be so kind and discuss this elsewhere.
Title: Re: The Os 3.1.4 Thread
Post by: guest21671 on June 18, 2019, 06:58:39 AM
Rights to 3.1 only in as it relates to AmigaOS 4 development
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 18, 2019, 08:48:47 AM
Rights to 3.1 only in as it relates to AmigaOS 4 development
Did you read what I have written? Keep this b*ll out of here.  You are a layman as far as legal aspects are concerned, same as anyone else here.

This thread is for discussing the technical aspects of 3.1.4. (and beyond).

And no. Read the "Definitions section" of the Settlement Agreement. "Os 4" is there defined as "The operating system developed by Hyperion", and it explicitly states "irrespectively of the version number".
Title: Re: The Os 3.1.4 Thread
Post by: kolla on June 19, 2019, 05:53:09 PM
So then OS 3.1.4 is not an update of OS 3.1, but a new OS developed by Hyperion.
Title: Re: The Os 3.1.4 Thread
Post by: x303 on June 19, 2019, 10:26:09 PM
Question: does os 3.1.4 show memory > 1.7GB [more or less] correctly ? On 3.9 (and versions below that) it shows memory with a negative number when setting anything above 1.7GB. 'Normal' amigas might not have that much, but you can set upto 3GB on winuae.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 19, 2019, 11:27:37 PM
Question: does os 3.1.4 show memory > 1.7GB [more or less] correctly
AmigaOs cannot administrate more than 2GB RAM, for multiple reasons. Bit 31 of allocated memory must remain 0. Harddisk space is announced correctly, though (which was a defect of 3.9).

Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 19, 2019, 11:29:13 PM
So then OS 3.1.4 is not an update of OS 3.1, but a new OS developed by Hyperion.
...not but, but "because", which makes it a proper update. Now, go trolling elsewhere. Kolla, I asked multiple times what your problem is. Have you problems at your job, or position, or family that you are so negative about everything and everyone.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on June 21, 2019, 09:10:12 AM
I am not negative against everything and everyone, the list is extremely short - I am mostly positive with all that goes on in the Amiga community, I have supported bounties, kickstarters, software development, patreons for developers, podcasts... I have done testing, reported bugs and helped with debugging (and you know this, but where Olsen always is the kindest and easy to communicate with, you tend to be arrogant and patronising). I was not negative against you, nor OS 3.1.4, before it became clear how this "product" is distributed and what the implications are (btw - "distribution" is on-topic, according to post #1 in this very thread) . I don't know exactly what triggered you to start this "slanderous campaign" against me - I do not have any problems, neither in job nor private, and if I had, it would be none of your business. What I am negative against is bullshit, and lately you have been climbing up the "bullshit ladder" quite rapidly. Why are you resorting to "scientology" tactics btw, are you a scientologist perhaps? Or perhaps you just enjoy the status of "alpha-nerd" among a handful of faithful sycophants, like some certain other Germans I know of...  It's not like I am the only one who find it troubling to see where things are heading with the way the OS is now developed, but I am perhaps more vocal about it... there are others who just roll their eyes and leave.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 21, 2019, 12:29:15 PM
I was not negative against you, nor OS 3.1.4, before it became clear how this "product" is distributed and what the implications are (btw - "distribution" is on-topic, according to post #1 in this very thread) .
What is the problem with distribution? You can buy it, in multiple ways. With ROM, without ROM, electronically, physically, as you like. At that point, you started to provocate. Questions nobody here can answer, for the purpose to ramble, not to get them answered. You know as much as I do about the story. These were never serious questions to begin with, you know that, I know that. Nobody here can give you a legally binding answer, and it does not help to continue nagging and anyoing people about it. Read the license on the web page. If that does not answer your question, nobody here can give you an answer either.

I wouldn't know any better way of distribution, seriously.

I don't know exactly what triggered you to start this "slanderous campaign" against me
Read your posts. As simple as that.

I do not have any problems, neither in job nor private, and if I had, it would be none of your business.
I just wonder why you react as you react. You like to provocate people. Why is that race for attention? You criticise anyone and anything, without willing to contribute for the positive. That is called "trolling". People that troll do that for a reason. I don't know your reason, but there must be one. You could also be helpful. "Here is my swedish translation" would be one. "I would like to be member of the beta-tester team" would be one. Yet, nothing of that happens. That is your decision, but don't blame anyone for a decision you made yourself.

What I am negative against is bullshit, and lately you have been climbing up the "bullshit ladder" quite rapidly.
As for example?

Why are you resorting to "scientology" tactics btw, are you a scientologist perhaps? Or perhaps you just enjoy the status of "alpha-nerd" among a handful of faithful sycophants, like some certain other Germans I know of...
You are wrong on this account, most definitely. Could you please, just for a moment, try to put yourself in my position? I'm working unpaid here. Yet, all I hear from you is negative feelings about every minor bit, most of which is due to misunderstandings, lack of insight, or ignorance. Do you believe it is fun to communicate to people like you?

It's not like I am the only one who find it troubling to see where things are heading with the way the OS is now developed, but I am perhaps more vocal about it... there are others who just roll their eyes and leave.
So where is it heading, in your oppinion? You know nothing where it is heading, actually, you are not in the communication pipeline, you are not a beta-tester, you are not a developer. I can only repeat what vision or strategy here is: Don't break things, keep the software collection workable, as much as we possibly can. Try to progress where we can.

At points, this requires to make compromises. At times, these compromises require insights into details you do not have. Please believe that it is all but easy to find such compromises. The problem is that everyone here seem to have an opinion, yet without the insight, yet without willing to contribute. See the problem?

Do you believe we make bugs for purpose? That I'm withholding updates for a purpose? That I define the copyright situation?

So, what can we do about that? That, for starters, you thrust us that there are sometimes good reasons for choices being made, probably for reasons you do not fully understand at this point, or do not have the insight in. I'm trying to provide motivations, but if you do not want to contribute, it does not make sense to keep nagging about them every time. Shell parsing is one, for example. I explained why the Pipe command is a bad idea, you do not understand the details because you don't have to maintain the code - so then, it does not matter to continue questioning the decision. At this point, I still stand for the decision getting rid of some legacy, for the better.

You question why we make bugs? We make bugs because we are all human. We try to fix things, as fast and as smooth as possible, but the whole situation complicated, and I cannot resolve issues that are not under my control. So what do you want to hear? That there will be an update? Yes, of course, there will be. That this will be free of charge? Yes, it will.

Timing is not entirely under my control, and the speed by which we deliver bug fixes neither. With only part-time developers handy, part-time beta-testing, and a "community" that nags about every little problem... it is not easy. With the contraints we have, it is a pretty rough life.

Please keep this in mind, and be a bit more moderate in what you demand from people working entirely in their spare time.
Title: Re: The Os 3.1.4 Thread
Post by: number6 on June 21, 2019, 01:21:15 PM
Quote
What is the problem with distribution? You can buy it, in multiple ways. With ROM, without ROM, electronically, physically, as you like. At that point, you started to provocate. Questions nobody here can answer

Not entirely true re:answer. Everything may change with time, but the legal docs are clear.
The request for injunction to prevent release was denied.
In layman terms rights revert to time prior to the filing of the suit basically.
Therefore there is currently no problem with the distribution.
Please don't make me cut and paste from the docs. Just accept it.
There really are other threads to argue the lawsuits themselves.

#6
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 21, 2019, 07:27:20 PM
10...
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 22, 2019, 07:23:33 PM
..9..
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 23, 2019, 06:23:59 PM
..8..
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 24, 2019, 04:43:34 PM
..7..
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 25, 2019, 05:07:28 PM
..6..
Title: Re: The Os 3.1.4 Thread
Post by: kolla on June 26, 2019, 12:51:31 PM
So will Hyperion have their website fixed in the remaining days? It is still broken in all kinds of ways, despite _requiring_ registration for updates, https is largely unsupported on the site, and the certificate ran out almost two months ago.

Why is this so damn hard to fix? Is one supposed to just use fake credentials to protect oneself?

This (among a handful of other things) is what I mean with "distribution problems"... a class action style GDPR based lawsuit would fit them well, huh?

And while I am posting - someone tell Damien over at EAB that it is the only site I am banned, unlike what he likes to believe.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 26, 2019, 04:19:35 PM
Why is this so damn hard to fix?
I'm not Hyperion, but let me make a best guess: Because the whole website is maintained by one single individual - who probably feels disillusional about Amiga, and has to make a living by a day job.

You somehow seem to consider Hyperion as a small or medium sized enterprise, with a regularly paid web master, taking care of all the responsibilities in a 9-to-5 job. I afraid that it is not like this. I wish it would be different, but as far as I understand, there is simply not enough regular income to pay such a position. So, in the end, it all boils down to a lot of voluntary work, with only little financial benefit with a salery below industry standards.

So probably attempt to make the following calculation: How many copies were sold, by how much a copy. Then consider how much you need to hire personell, in times like this where it is hard to find qualified people, then consider for how long you could pay them with the income you generate, and then consider the likeliness of finding interested applicants.

This is a small market, with many risks, with only limited chances for success.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 26, 2019, 06:46:21 PM
..5..
Title: Re: The Os 3.1.4 Thread
Post by: hth313 on June 26, 2019, 08:29:17 PM
Quote
And while I am posting - someone tell Damien over at EAB that it is the only site I am banned, unlike what he likes to believe.

Done.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on June 27, 2019, 07:10:59 AM
Quote
You somehow seem to consider Hyperion as a small or medium sized enterprise
Nonsense, stop putting words in my mouth - I consider them a one-man show, a lawyer, with a plumber and an sql-jockey as sidekicks.

But... it's not like https is magic and maintaining a certificate is wizardry, this is really simple to fix issues, but yet they are incapable. It seems they are only interested to offer support if your problem is related to registering and paying, otherwise it is utter silence.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 27, 2019, 08:18:20 AM
But... it's not like https is magic and maintaining a certificate is wizardry, this is really simple to fix issues, but yet they are incapable. It seems they are only interested to offer support if your problem is related to registering and paying, otherwise it is utter silence.
Then again, what help is this forum? Nobody here is from Hyperion, so nobody here can help in first place. Write them, or don't, but this is certainly the wrong place.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on June 27, 2019, 03:11:14 PM
Then again, what help is this forum? ... this is certainly the wrong place.

This is related to "distribution of OS 3.1.4", which was one of the "right things" to discuss here.

I understand that you are not the right person to answer, but if your "countdown" has any credibility, it shows that you clearly have _some_ communication with Hyperion and whoever is running the website, so you could certainly mention for that person, whoever it is, that these issues should not be ignored. They are after all, a registered commercial company, with products and customers - would be a shame if they were slammed with a GDPR fine on top of everything else going on with them.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 27, 2019, 05:51:50 PM
Ah, so you ask me to ask them. So, why didn't you say so in first place?

I can certainly do that, probably at the time the count down runs out because then I have to inform them that there is something on their server to grab.
Whether this has any effect I do not know. I have no saying how they should run their server or their company or how to plan their work hours. There is certainly room for improvement...

It also sounds a little bit complicated to me because for that it seems easier to cut out the middle man and write directly, but well.... since you asked so nicely.

Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 27, 2019, 05:53:39 PM
..4..
Title: Re: The Os 3.1.4 Thread
Post by: hth313 on June 27, 2019, 06:02:24 PM
...
Title: Re: The Os 3.1.4 Thread
Post by: Tygre on June 28, 2019, 02:00:39 AM
Quote
You somehow seem to consider Hyperion as a small or medium sized enterprise
Nonsense, stop putting words in my mouth - I consider them a one-man show, a lawyer, with a plumber and an sql-jockey as sidekicks.

But... it's not like https is magic and maintaining a certificate is wizardry, this is really simple to fix issues, but yet they are incapable. It seems they are only interested to offer support if your problem is related to registering and paying, otherwise it is utter silence.

You read Thomas' and agree with him: Hyperion are a (very) small operation (with possibly little revenue), so why would they spend time on things that do not directly bring money? Especially to help someone who complains without contributing much...

As we say in French: "it's easy to criticize, but hard to act".
Title: Re: The Os 3.1.4 Thread
Post by: kolla on June 28, 2019, 03:50:11 AM
If Hyperion would fix their distribution issues, that is, fix their website to follow at least work properly with https, and fix the software license for OS 3.1.4 so that it doesn't consist of nonsensical conditions, and make it absolutely clear what hardware they consider permittable for OS 3.1.4, I would buy 9 copies of OS 3.1.4 instead of just the one I have. I am also happy to buy them the certificate, install it on their server and make sure https works properly. For free. Or just set up Let's Encrypt, which is for free. Because these are realy trivial issues to fix for anyone with slightest clue.

It's not about helping me, it's about helping themselves, about having at least *some* credibility as a *computer software* company that knows what it's doing. This low resource, undermanned and "possibly low revenue" (are you kidding? It's a "negative revenue" company), is still capable of writing a software license that is long, full of quasi-legalese nonsense, still capable of buying Reaction, still capable of fighting legal battles east and west, still capable of threatening people east and west, still capable of stepping all the toes they can and burning all bridges they have had with other Amiga entities, still capable of updating content and do announcements, still capable of pissing people off by attempting to register trademarks which they don't own and tons more. But no resources to take necessary measures to secure the privacy of their own customers, who are the only source of income they have, and for whom they have legal responsibilities.
Title: Re: The Os 3.1.4 Thread
Post by: Tygre on June 28, 2019, 05:24:26 AM
It's not about helping me, it's about helping themselves, about having at least *some* credibility as a *computer software* company that knows what it's doing. This low resource, undermanned and "possibly low revenue" (are you kidding? It's a "negative revenue" company), is still capable of writing a software license that is long, full of quasi-legalese nonsense, still capable of buying Reaction, still capable of fighting legal battles east and west, still capable of threatening people east and west, still capable of stepping all the toes they can and burning all bridges they have had with other Amiga entities, still capable of updating content and do announcements, still capable of pissing people off by attempting to register trademarks which they don't own and tons more. But no resources to take necessary measures to secure the privacy of their own customers, who are the only source of income they have, and for whom they have legal responsibilities.

This contradicts your comment that this is a "one-man show" (your words). So, again, you are just complaining for the sake of complaining.

QED!
Title: Re: The Os 3.1.4 Thread
Post by: kolla on June 28, 2019, 11:27:19 AM
There is no contradiction and you have not demonstrated anything, so a "QED" here is out of place.
Title: Re: The Os 3.1.4 Thread
Post by: Tygre on June 28, 2019, 06:23:29 PM
There is no contradiction and you have not demonstrated anything, so a "QED" here is out of place.

QED bis... ;D
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 28, 2019, 07:24:46 PM
..3..
Title: Re: The Os 3.1.4 Thread
Post by: kamelito on June 29, 2019, 03:57:56 PM
@Thomas Richter
Do you plan to add MEMF_PRIVATE,  MEMF_SHARED  and MEMF_EXECUTABLE to a future update and the corresponding code to protect those regions if an MMU is present in the current system?
Do you know what Bryce Nesbitt wanted to add in Exec in that direction before CBM bankruptcy?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 29, 2019, 07:55:51 PM
..2..
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 29, 2019, 08:21:57 PM
@Thomas Richter
Do you plan to add MEMF_PRIVATE,  MEMF_SHARED  and MEMF_EXECUTABLE to a future update and the corresponding code to protect those regions if an MMU is present in the current system?
Well, not too soon, at least. You know that there is no accessible interface for the MMU on some P5 cards, so depending on this for the operating system is probably not such a good ideal.

Do you know what Bryce Nesbitt wanted to add in Exec in that direction before CBM bankruptcy?
Only partially, what Mike told me. However, how all of this would fit together is unclear to me, as it would have required that device drivers (for disks) operate in a certain way that might be hard to achieve. It is bad enough that only a minority of them calls the CachePre/PostDMA() functions correctly.
Title: Re: The Os 3.1.4 Thread
Post by: Dr_Procton on June 29, 2019, 08:41:36 PM
Will be Reaction included in the next update?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 29, 2019, 08:45:20 PM
Will be Reaction included in the next update?
In 3.1.4.1? No, certainly not. This is only a collection of bug fixes that piled up over the last months, nothing more.
Title: Re: The Os 3.1.4 Thread
Post by: kamelito on June 29, 2019, 09:00:43 PM
Any answer from Frank Mariak about CGX incompatibilities with Intuition V45?
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on June 29, 2019, 09:04:29 PM
Any answer from Frank Mariak about CGX incompatibilities with Intuition V45?

An unfriendly and negative answer I am afraid.
Title: Re: The Os 3.1.4 Thread
Post by: giZmo350 on June 30, 2019, 06:05:51 AM
Any answer from Frank Mariak about CGX incompatibilities with Intuition V45?

An unfriendly and negative answer I am afraid.

Trying Amiga Times.........
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on June 30, 2019, 08:07:29 PM
..1..
Title: Re: The Os 3.1.4 Thread
Post by: kolla on July 01, 2019, 07:48:59 PM
0.09998788... (as calculated on AC68080)
Title: Re: The Os 3.1.4 Thread
Post by: giZmo350 on July 02, 2019, 02:32:00 AM
..1..

Really?

@kolla....        B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC Squared?

You still BANNED over @EAB?  HAHAHAHA! How does it feel to be the RUSH LIMBAUGH* of Amiga?

*Question Everything
Title: Re: The Os 3.1.4 Thread
Post by: kolla on July 02, 2019, 05:29:01 AM
It's not a loss for me, and Damien seems super proud about his accomplishment.

I was given no other reason than "trolling", nothing specifics, I guess it is reason enough that a certain "high profile" (read "alpha nerd") character keeps going ballistic over questions that he finds "impossible to answer". Well, this is Amiga, what goes around comes around, I'm sure that in hindsight some years from now, things will appear clearer for everyone.

(What's more concerning is that the EAB site prevents banned users from accessing their accounts, like... at all, and hence prevents them from seeing what info that is stored, and prevents banned users from closing their accounts, and prevents anonymizing personal information. I asked the site admins for what info they have stored on me, but have not heard anything. Now what does GDPR say about these things?)

What was the point of this count down anyways?
Title: Re: The Os 3.1.4 Thread
Post by: Louis Dias on July 02, 2019, 02:16:25 PM
-1
Title: Re: The Os 3.1.4 Thread
Post by: number6 on July 02, 2019, 02:45:47 PM
@thread

since no one else seems willing to cross post (http://eab.abime.net/showpost.php?p=1330157&postcount=796)

#6
Title: Re: The Os 3.1.4 Thread
Post by: Louis Dias on July 02, 2019, 02:54:45 PM
@thread

since no one else seems willing to cross post (http://eab.abime.net/showpost.php?p=1330157&postcount=796)

#6
That was a whole lot of shaking of the champagne bottle only to see the cork flop off...
Title: Re: The Os 3.1.4 Thread
Post by: kolla on July 02, 2019, 03:07:20 PM
Costel could just put it on Aminet and call it the day :)
Title: Re: The Os 3.1.4 Thread
Post by: hth313 on July 02, 2019, 05:46:12 PM
Github would be even better, you can have releases there too.  ;D
Title: Re: The Os 3.1.4 Thread
Post by: number6 on July 02, 2019, 06:09:25 PM
@thread

another update (http://eab.abime.net/showpost.php?p=1330288&postcount=809)

#6
Title: Re: The Os 3.1.4 Thread
Post by: kolla on July 03, 2019, 07:14:06 AM
Github would be even better, you can have releases there too.  ;D
Of course :)

However, since Costel is one of the guys currently maintaining Aminet (the database, I presume), it seems like the natural choice.
http://wiki.aminet.net/Team_Members

But why not both - Aminet could have its own installation of gitlab, with a CI/CD (continuous integration & delivery - exactly what Hyperion are notoriously bad at) prepped and aimed for Amiga developers.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on July 03, 2019, 07:15:07 AM
(double-post)
Title: Re: The Os 3.1.4 Thread
Post by: hth313 on July 03, 2019, 08:22:46 AM
I had no idea Costel maintained Aminet, interesting to know.

Gitlab is nice too and you can also use it on your own server. I used mentioned Github as I am more used to it.

In any case, this reminds me of the product company I worked at a few years back. We developers made a release and then marketing did their stuff. Writing press releases, talking about sports, taking coffee breaks and god knows all they were up to, not always getting the release out the door asap it felt like. We seldom communicated release dates as it was notoriously hard to predict it, we developers slipped in late corrections, had to re-test and marketing had their rituals. It was better when we could hand out nightly builds to customers in need, as we could skip most procedures.

The "funny" part was that marketing did not even want a lot of releases as they could not handle it. We developers had lots of automation, so we could quite easily crank out new releases, but it was a different story in marketing.
Title: Re: The Os 3.1.4 Thread
Post by: number6 on July 03, 2019, 12:44:52 PM
Github would be even better, you can have releases there too.  ;D
Of course :)

However, since Costel is one of the guys currently maintaining Aminet (the database, I presume), it seems like the natural choice.
http://wiki.aminet.net/Team_Members

But why not both - Aminet could have its own installation of gitlab, with a CI/CD (continuous integration & delivery - exactly what Hyperion are notoriously bad at) prepped and aimed for Amiga developers.

Keep in mind Costel joined Hyperion in May 2015.
The page you quoted is June 2015.
And Amiganews seems to have enough on their hands without having to spread themselves too thin over at Aminet.
Source (http://amiga-news.de/de/news/AN-2019-06-00035-DE.html)

#6
Title: Re: The Os 3.1.4 Thread
Post by: kolla on July 03, 2019, 02:24:40 PM
Well, Aminet could need some love too, its "software architecture" (*snigger*) is ancient by today's standards - both the web front-end and the database backend should be distributed around on multiple instances from different hosting sites.
Title: Re: The Os 3.1.4 Thread
Post by: TribbleSmasher on July 06, 2019, 10:00:29 AM
Is the delay caused by the ongoing need to update FAQs, news etc. on Hyperion-Entertainment.com in the background?
When i browse to their Website i often get a 'different' front page displayed, sometimes with 'downloads' or 'FAQ' tabs open on the left side...
 ???
Title: Re: The Os 3.1.4 Thread
Post by: trekiej on July 06, 2019, 07:21:57 PM
Hello.
Is there a How-to on using the Rom files with a SS Disk Drive on a A1000?
Title: Re: The Os 3.1.4 Thread
Post by: trekiej on July 07, 2019, 08:24:38 PM
Thanks, I found a very good source with Epsilon's Blog.
Title: Re: The Os 3.1.4 Thread
Post by: Senex on July 07, 2019, 08:27:55 PM
@number6

De facto Aminet is a one-man job for many years already, with Christoph doing the actual work while Nicolas is providing the server and Costel running a mirror.
Title: Re: The Os 3.1.4 Thread
Post by: Dynamic_Computing on July 08, 2019, 05:53:58 AM
 ;)
Well, Aminet could need some love too, its "software architecture" (*snigger*) is ancient by today's standards - both the web front-end and the database backend should be distributed around on multiple instances from different hosting sites.

I suspect it is still "ancient" so it continues to work perfect on real Amiga's using things like iBrowse. It is a delight to use on my Amiga4000! I hope they don't change a thing.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on July 08, 2019, 06:10:16 AM
What I was mentioning, has nothing to do with browser support 😛

What I am talking about, is to make the service more robust, getting rid of downtime on the web frontend and avoid "single points of failures". You may have noticed that every now and then the web frontend is unreachable, or is answering "can not connect to database" - that's what should be fixed, using a more "modern" approach.

The service could also be made more amiga friendly with better native tools - UHCTools is great, and I have myself made an Amiga guide frontend to Aminet. This type of frontends could be helped with better APIs to the official database, for example, instead of implementing database and search engines over again, or go nuts parsing HTML output from a service that cannot be relied upon. My favorite interface used to be ADT, the official Aminet Download Tool (which I also somewhat maintained an Amiga version of), but it should be fully re-implemented, as it fails in all kinds of ways today.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 08, 2019, 11:02:42 AM
...0! Off we go!

Title: Re: The Os 3.1.4 Thread
Post by: kamelito on July 08, 2019, 03:53:07 PM
Kudos, care to elaborate about "new intution support"?
Thanks
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 08, 2019, 05:57:00 PM
Sure. Actually, I was going to write about the changes anyhow, so we can start with intuition if this is most interesting for you.

Actually, there is really not much new here. The V45 added off-screen dragging, and for that modified the check for valid window positions and sizes. Interestingly, this check exists twice. Once in the event handler that processes user mouse movements, and another time when moving the window through the MoveWindow() function. The implementation of the latter had a bug - instead of checking whether the right window border would leave the screen when moving the window left, and then disallowing the move, it checked the left window border. Hence, moving windows by programs already stopped the movement pretty early at the left edge of the screen. All other checks were ok.

Then, there is a tiny "preparation change" in OpenScreen() for rtg graphics. The problem P96 and also CGfx have to solve here is to identify the type of bitmap to allocate. That is, whether OpenScreen asks for a RTG bitmap, a true-color bitmap, a high-color bitmap or a native bitmap. Unfortunately, there were no means to provide this information  to the rtg.library, so what P96 did is that it "went fishing" for register contents, and if they looked fine, it assumed that the call was coming from intuition. And if so, P96 goes "fishing for data" on the stack frame, and there finds the view mode of the screen it was supposed to open, and then could allocate the bitmap correctly.

So V45 intuition contains a big kludge to create a "nicely loooking" stack frame for P96.

Needless to say, it cannot stay this way. Actually, this was already clear around ~2001/2002, so back then (remember, already 17 years ago) I extended the interface for AllocBitMap() in P96. If you set a specific flags combination for AllocBitMap() which would be otherwise invalid, its last argument, which is usually the "friend bitmap", becomes a taglist. And on this taglist intuition places now a tag defining the viewmode.

If this first attempt to allocate a proper bitmap fails - and it does by default as the flag combination is invalid under normal circumstances and the graphics.library implementation refuses it - then the old method is used, so compatibility is retained.

Before you ask, I do not know what CGfx would expect here, or how to update the kludge to make CGfx working - or at least move closer to a working cgfx. I don't have access to its sources like I do (and did back then) for P96.

In the future, this "kludge" in intuition may just go away. It is not needed for P96 anymore, and it does not help for CGfx for reasons unclear to me.
Title: Re: The Os 3.1.4 Thread
Post by: Dr_Procton on July 08, 2019, 06:10:46 PM
Great work Thomas. You and Olaf can really do the magic..
Everyone should appreciate the genuine effort to give us a better 3.1 system.
For my part: Thank you.
Title: Re: The Os 3.1.4 Thread
Post by: TribbleSmasher on July 08, 2019, 07:41:26 PM
@ Thomas
As the update requires a proper 3.1.4 installation and the disk itself doesn't boot, why is the installer on that disk needed, and therefore also the compression of the most files?
Did the "old" installer not meet the requirements?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 08, 2019, 07:55:49 PM
Did the "old" installer not meet the requirements?
Yes, it did. But the reason for including the installer is that the installer itself also received an update. (-:

Actually, not really much of one, but if I find a bug, I fix it. The problem here was that the installer was a bit uncareful in identifying possible target volumes. Instead of sending an ACTION_DISK_INFO right away - which has additional meanings for some handlers - it tests now upfront with ACTION_DISK_INFO whether the target is a file system in first place.

Actually, the story behind this is that the installer crashed if a certain handler was installed in the system. The embarrasing part is that this was one of my own handlers - well, a beta handler that never made it to the public (Clip-Handler, shows the clipboard contents as a file), so probably no harm done. No matter what, a bug is a bug is a bug, and so the installer received an update.
Title: Re: The Os 3.1.4 Thread
Post by: kamelito on July 09, 2019, 07:14:40 AM
@Thomas Richter thanks for the details.
Not sure if this is a bug but I’ve seen this related to AmigaOS 3.1.4.
http://eab.abime.net/showthread.php?t=98038
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 09, 2019, 02:37:52 PM
Well, probably time to continue with another episode. This time with my "most beloved component", which is HDToolBox.

First, one bug I am responsible for: If you scan a SCSI chain, and there is a "hole" in the assigned IDs - e.g. SCSI IDs 0 and 1 are present, 2 is not, but 5 and 6 are - then HDToolBox stopped looking for any further drives once it found a non-existing ID. The story is that I was actually attempting to abort the loop for scanning for LUNs, logical units, but I hit the wrong loop. Oh well,  this is fixed.

All other issues were old, from 3.1 times and before. The first newly discovered issue is how HDtoolbox "determines" the drive geometry, i.e .what you see as "sectors per block" "number of tracks" and so on. Nothing of that data is in good relation to reality, and most of the data is just "phantasy" the HDToolBox makes up. Background is that SCSI disks simply address disks as a linear list of sectors, and even if they have tracks, the track size varies by the cylinder, so the physical reality does not fit into the "rigid" scheme used by the dos.library for mounting disks. HDToolBox has just to make up a reasonable geometry such that the entire number of sectors fits, or is at least not larger than the real number of sectors.

Problem is, what is "reasonable". Well, if you had a disk initialized, HDToolBox reserved two tracks for the RDB to store the file system in. Always. Unfortunately, if the disk geometry is not reasonable, two tracks may be just "very little", e.g. if the algorithm generated a disk geometry (all made up, as said) with 2 sectors per track. Then there would be a total number of four sectors available for the RDB - where it does not fit in, of course.

So that got fixed, both the algorithm how the disk geometry is estimated, or made up, and second, the number of tracks to reserve for the RDB.

Then, we had a couple of issues where users put the FFS on a quite large (for Amiga times, at least) partition, and then received an "Out of memory" when attempting to validate the partition. This can be resolved by using a larger block size of 4096 bytes rather than 512 bytes, and the former is recommended for many modern drives and SD cards anyhow that work internally with 4K sectors. So HDToolBox now switches to 4K sectors when the partition size is large enough, and it also aligns partitions to 4K boundaries.

Finally, we have two "freak accidents" in the HDToolBox, errors that are real "face palm" experiences. No, this time not caused by me. First, the stack size of a file system. HDToolBox was kind enough to recognize that the FastFilesystem is not written in BCPL and hence does not require a "GlobVec", but it did not enter a stack size for it, so the stack size remained at its default, as created by the expansion.library when creating the mount list of the drive. The default is 600.

The right question is now "600 what"? And the answer is "it depends...". Unfortunately, the dos.library knows two types of handlers: BCPL handlers and C/assembly handlers. The former are created by an internal function named "createtask" (not to be confused with exec tasks) and it takes the stack size in long words. The latter are created by "CreateProc", which takes the stack size in bytes. So, if you mount a handler with "GlobVec=0", then the stack size in the mount list means "long words", and if it is a C mount, the stack size means "bytes". Unfortunately, the default left behind by the expansion library is "BCPL mount", which - with a stack size of 600 - results in 2400 bytes of stack. As soon as the HDToolBox patches this to "this is a C mount", the result is a stack size of 600 *bytes*, which is really quite tight, even for the FFS.

So, in the end, HDToolBox now also leaves sufficient information to extend the stack size to 2048 bytes.

The second accident is in the bytes/block settings for the fast file system. Betatesters reported that whenever a file sytem was removed from the RDB, the block size was reset to 512 bytes, which then resulted in an unsuable partition if the partition was originally formatted with larger block sizes. This sounds like a (well not harmless but) simple GUI bug, but it wasn't. To understand the issue, you need to know how partitions are mounted.

Step 1) is that the expansion.library creates a "template" for the mount list (or its equivalent), which is "globvec = 0" (BCPL mount), 600 LONGs stack (see above), 1 sector per block.
Step 2) is that the firmware of the hostadapter uses this template and fills in the partition boundaries from the disk, such as "LowCyl" and "HighCyl".
Step 3) is that the file system is loaded from RDB and has a couple of ideas of its own what it needs, so for example to get the GlobVec and the stack size replaced. This is communicated by "PatchFlags" which instruct the firmware to replace some of the entries created in 1) or 2) by data by its own.

Now, if you instruct HDToolBox to use a different number of sectors per block, two things happen: First, the partition layout is modified, that is, the data in step 2). Second - and this is the crazy part - HDToolBox also updates the Patchflags for the file system with something that looks "apparently" as if the block size is also to be modifed at file system level. (1<<DE_SECTORSPERBLOCK) is or'd into the patch flags.

This, however, would be fatal: A file system with the sectors per block patched over would mean that the sectors per block from the partiion is replaced. So if you create two partitions, one with 512 byte blocks, and another with 4096 bytes per block, and use one file system for both of them, the above patch flags seem to override the block size for both - and then ruins at least one of the partition.

Luckely (ehem) another bug compensates the first bug: (1 << DE_SECTORSPERBLOCK) is actually the wrong flag (face palm #2). Due to the way how the patch flags are enumerated, it modifes the stack size. Harmless for the partition, but leaves the stack size then at 0. Ok, the dos.library is not quite as stupid to allow this size, and then selects one by itself.

What is left is a typical exercise in database management: If you have two data entries that mean the same (block size at partition level, block size at file system level), you need to keep them consistent. HDToolBox attempted to do so, but failed. Whenver a file system was deleted, one part of the information was removed, and then the other - at partition level - was removed as well, resulting in an invalid block size at partition level.

So, two bugs, with only one of them the result might be more fatal than with two of them, but bad enough...

Needless to say, this was fixed. HDToolBox no longer attempts to (wrongly) set the block size at file system level, and now the block size stays where it should be if you remove a file system from the list.
Title: Re: The Os 3.1.4 Thread
Post by: Aegis on July 09, 2019, 10:03:57 PM
The Click to Front commodity is broken in 3.1.4/1 (because of the intuition-v45 changes?) - please fix for the next release!
Title: Re: The Os 3.1.4 Thread
Post by: Louis Dias on July 10, 2019, 05:21:13 AM
The Click to Front commodity is broken in 3.1.4/1 (because of the intuition-v45 changes?) - please fix for the next release!
Do you mean 3.1.4.1.5?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 10, 2019, 05:41:49 AM
The Click to Front commodity is broken in 3.1.4/1 (because of the intuition-v45 changes?) - please fix for the next release!
No, it's not. Please read the FAQ. The default tooltypes of ClickToFront are that you need to hold down ALT (or some other qualifier) to make it work. It has been like this forever. Reading the FAQ should definitely be the first step.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on July 10, 2019, 07:19:55 AM
Under what conditions does the new SetPatch replace shell with L:Shell-Seg and under what conditions does it not replace shell with L:Shell-Seg? Does it care about what version of shell that is already resident?
Title: Re: The Os 3.1.4 Thread
Post by: kamelito on July 10, 2019, 07:26:45 AM
@Thomas Richter
Is a new SDK planned?
Will we see one day updated RKM? those from CBM stopped at version 2 of the OS as you know.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 10, 2019, 07:44:00 AM
Under what conditions does the new SetPatch replace shell with L:Shell-Seg and under what conditions does it not replace shell with L:Shell-Seg? Does it care about what version of shell that is already resident?
It's a version/revision match with the Os 3.1.4. shell. If the new shell is already loaded with LoadModule, it won't do anything.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 10, 2019, 07:49:17 AM
Is a new SDK planned?
We should definitely make one, yes. It's a matter of priorities, though. Not much was new for 3.1.4, but there will be a couple of news for 3.2 so I'm updating the includes and autodocs as I go. But it still means that all of this needs to be packed and brought into a usable state. Then, one of the known defects of the current SDK is that they aren't "const correct", which causes quite some annoyances with even the SAS/C, and that should be fixed as well.

So, it's a long road. I don't have a milestone for that yet, but I believe it should work like first publishing 3.2 - with no definite deadline at this point - and then continue with the SDK for it.

There is already a new "Shell.guide" that explains the extended synax, the new commands and provides some insight into the new features, but that is already covering the V47 shell (currently in alpha stage), so I'm not going to say much about it at this point.

As for the RKRMs: Oh well, I wish I had all the time.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 10, 2019, 05:21:55 PM
Maybe time for another update on the update. The shell was mentioned already above, so let's continue with this module.

The most prominent bug in the shell was that I forgot to forward the error code from program execution to the topmost level of the shell, which was caused by the integration of pipes into the shell. Kolla noted this probably first. Some people reported problems in the FailAt command, but this was actually fine all the way and the problem was in the shell.

Error forwarding was broken also in another mechanism, namely variable and backtick expansion. If that failed, no error was reported, though it probably should.

What was a bug left over from V45 was that redirection to NIL: did work well with console redirection, thus you could get a spurious "please insert volume console:". Probably nobody noticed the problem in V45 because it was part of the "&" (run back) operator, but now that the same mechanism is also used to run the left-hand side of a pipe, the error became apparent.

Then, we had a bug in the proper handling of $?, which evaluates whether a variable is present. If so, $?a returns 1, otherwise 0. This worked only for environment variables, but not for shell local variables. I believe this might have also been an old bug that remained unnoticed.

Last, I recall that we also had a parsing bug with two variables sitting close to each other, such as $a$a. Since Shell and Execute share the same parser - a useless issue of code replication that will go away next time - the same bug was also in execute, and thus you also have a new version of execute as well.

Speaking of execute, it can now also run at the right-hand side of a pipe, a feature that was somehow "in focus", but I simply forgot to put it in. The best application for this is probably together with "list lformat". You can create a shell script dynamically by "list", and pipe it directly into execute.

There was an APIPE: handler in Aminet that would do similar by executing everthing that was written into it, now the shell can do it natively.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on July 10, 2019, 06:40:05 PM
I found $? so unreliable that I simply dropped using it, and instead use the old 'if "$var" eq "${var}"'-trick, really wishing that non-existing variables could just expand to an empty string.

A shame that all these new features cannot really be used in distributed scripts anyways, since only a fraction of the systems out there may have the shell required.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on July 11, 2019, 05:33:48 AM
Thanks a lot for the update!   This issue with Multiview does not look like got addressed in 3.1.4.1:

https://forum.amiga.org/index.php?topic=73908.0


Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on July 11, 2019, 05:39:23 AM
Cross-posting a copy command memory leak issue from here:

http://forum.hyperion-entertainment.com/viewtopic.php?f=15&t=4321
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 11, 2019, 06:48:24 AM
Cross-posting a copy command memory leak issue from here:

http://forum.hyperion-entertainment.com/viewtopic.php?f=15&t=4321
I afraid it is too late now.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 11, 2019, 06:51:30 PM
More on the update.

There is a new version of the FastFileSystem in the update as well. Actually, this is only a very minor update as there was nothing to fix, just a couple of things to improve. So, your data is not in danger.

If the FFS initialized a volume for long file names (DOS/6 or DOS/7), it also wrote administration information for directory caches. This data was actually never used, as the dircache remained disabled, so it did nothing bad. As the data is not needed, the new FFS no longer writes this useless data.

Then, when mounting multiple partitions, the 3.1.4. FFS mounted all partitions in parallel. This might have caused a lot of head movements on mechanical disks, so 3.1.4.1 reverts this to serial mounts.

There is a tiny improvement for users of the omniscsi.device, and probably some other devices in combination of removable media. In case you mounted such devices on a drive with a medium inserted, nothing would happen. The corresponding device does not return a proper result for TD_GETCHANGESTATE, such that the FFS would assume that no medium is inserted. The new FFS performs now a "dummy read" to "wake up" the affected device - this will avoid this problem.

The same issue also existed in CrossDos and the CDFileSystem where it was fixed (or rather, worked around) as well.

The FFS "bitmap" records which blocks of a volume are allocated and which are free. For large volumes, there can be many bitmap blocks, and these are recorded in "bitmap list blocks". Previous versions of FFS wrote the bitmap list blocks and the actual bitmap blocks "interleaved", which makes them slow to read. The new FFS writes them in a contiguous list of blocks. This would allow the FFS in a future release to read them in one single access, improving the startup time. The code for that is not yet there, but there is some preparation for it.

Last but not least, the "disk validator" in the FFS was also improved.  The previous version would read blocks in a rather simple-minded fashion: Allocate a block buffer, read the block, validate the block, release the block, then continue. Thus, a lot of rather useless memory allocation operation were performed, one after another - this made disk validation unnecessarily slow. The new FFS will allocate the block first, then use throughout the validation process, and release it when its done.

Oh, and one final change: The FFS creates (since 3.1.4) its own entries in the "FileSystemResource". In order to avoid problems with "HDToolBox" type programs that do not inidicate a proper stack size (due to a mix up of the unit), the FFS now creates the proper "PatchFlags" to indicate a stack size of 2048.

The next (major) release will include just another mechanism for file handlers to indicate their stack size that is a bit more "fool proof" than the current way... Live and learn....
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on July 12, 2019, 05:32:32 AM
For the multiview issue, this one, and any other minor issue it doesn't sound like there is any plan for a 3.1.4.2...instead next release is a 3.2?

Cross-posting a copy command memory leak issue from here:

http://forum.hyperion-entertainment.com/viewtopic.php?f=15&t=4321
I afraid it is too late now.
Title: Re: The Os 3.1.4 Thread
Post by: Rotzloeffel on July 12, 2019, 10:44:17 AM
no, not realy
Title: Re: The Os 3.1.4 Thread
Post by: kolla on July 12, 2019, 03:32:30 PM
That's how it goes when there's no official and publicly available bug tracker that users can compare bugs they find against. So unnecessary.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 12, 2019, 04:08:27 PM
That's how it goes when there's no official and publicly available bug tracker that users can compare bugs they find against. So unnecessary.

There is one. There is a support thread at the Hyperion web side right for that. It doesn't take a bug tracker to collect bugs from users. But it doesn't matter if the bug is reported too late.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on July 13, 2019, 10:44:58 AM
There is one. There is a support thread at the Hyperion web side right for that.

That is not a bug tracker - you don't know what a bug tracker is??

It takes a public bug tracker for _users_ to know what bugs are already _known_ and, potentially, addressed.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 13, 2019, 11:05:13 AM
That is not a bug tracker
Yes.  But, guess what, you can still report bugs there. Is there a reason why I need to repeat this again?

It takes a public bug tracker for _users_ to know what bugs are already _known_ and, potentially, addressed.
My experience is that the barrier for *users* using bug trackers is too high, leave alone looking up what bugs are reported, leave alone providing useful bug reports that could be handled this way. So, yes, we do have an internal bug tracker where the bugs collected there go, but not for the public. A bug tracker is next to useless for the general audience.


Title: Re: The Os 3.1.4 Thread
Post by: kolla on July 13, 2019, 11:31:54 AM
I have zero interest in reporting bugs that may or may not be already known, it's just too much hassle.

At least you could have a text file somewhere, listing a summary of all known bugs. How hard can it be to generate such a list from your internal bug tracker
Title: Re: The Os 3.1.4 Thread
Post by: TribbleSmasher on July 13, 2019, 11:41:10 AM
Doesn't make sense. It is lot less work on your part if you just drop a few lines here instead of studying the whole buglist and then drop the very same text.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 13, 2019, 11:47:02 AM
I have zero interest in reporting bugs that may or may not be already known, it's just too much hassle.
I had enough university projects where it was a quite hard fight to convince users (from academia) to use a bug tracker. Now do that with arbitrary users. Please go here, create an account, register your mail, select the subsystem, type the bug description here...

Be realistic: Forget it. Even in my unversity projects, most users wrote emails, much to my dislike, because it was just easier. Users know how to use a forum. We collect bugs, decide whether that even is a bug in first place. Keep the barrier low for users. A forum is ideal for them - easy access, known medium, low barrier. We filter, collect and feed the bugtracker.

At least you could have a text file somewhere, listing a summary of all known bugs. How hard can it be to generate such a list from your internal bug tracker
Not hard. But why would that help? Would users read them before reporting? No. Reading bug lists requires understanding bugs, requires some technical background, and investing time for it. Thanks, but no, thanks.

Title: Re: The Os 3.1.4 Thread
Post by: kolla on July 13, 2019, 11:50:41 AM
So dumb sheep, that is what we are.

(Begs the question - what do dumb sheep need "advanced" CLI for.)
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 13, 2019, 11:55:22 AM
So dumb sheep, that is what we are.

It is really that simple: If you want to get access to a bug tracker, become a beta tester. You get early access to the beta phase, a bug list, and a bug tracker. You don't what that? Well, then you're a user. Decide your role, but don't complain about the consequences.

Users don't want to be bothered with bug tracking, which is quite a task and requires in depth knowledge of the system and its components - this does not quality anyone as "dumb". I don't want to be bothered with the internal workings of my washing machine either, I just want that it does its job properly.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on July 13, 2019, 12:02:57 PM
It is realy not my loss that you miss out on bug reports.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 13, 2019, 12:13:46 PM
It is realy not my loss that you miss out on bug reports.

Should I be afraid? This is a free world. You can take decisions as you like, but don't make anyone else feel guilty for consequences of your decision you don't like. You can contribute in many ways if you like. You can report bugs in the Hyperion forum as user, and they will be read. Or you can become a beta tester if you like, and get better access, but more responsibility. Or become a developer, and get even more access, and even more responsibility.

It's really your choice to pick. What else should I say? You want to pout since you don't get what you want? Well, works for me, too. I cannot change the rules either.
Title: Re: The Os 3.1.4 Thread
Post by: TribbleSmasher on July 13, 2019, 12:17:23 PM
Googling kolla's sig brings out his interpretation of responsibility....
Title: Re: The Os 3.1.4 Thread
Post by: kolla on July 13, 2019, 12:39:01 PM
Googling kolla's sig brings out his interpretation of responsibility....

Yes, though it's much harder to spot now, due to it being my signature.

Right?
Title: Re: The Os 3.1.4 Thread
Post by: TribbleSmasher on July 13, 2019, 01:22:55 PM
Well, fourth result with Google, while context is given away in the first result...
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on July 13, 2019, 09:57:03 PM
Not to re-hash again and again but I haven't heard anybody reproducing this.   Is this reproducible for anybody else?  It is definitely a very minor thing but just wanted to check...

Thanks a lot for the update!   This issue with Multiview does not look like got addressed in 3.1.4.1:

https://forum.amiga.org/index.php?topic=73908.0
Title: Re: The Os 3.1.4 Thread
Post by: TribbleSmasher on July 14, 2019, 12:40:42 AM
If you want to get response i would recommend to at least describe the problem. i do not browse links for your convenience. ;)
Title: Re: The Os 3.1.4 Thread
Post by: Dynamic_Computing on July 14, 2019, 01:35:45 AM
I understand that this thread has devolved into a few people whining, but I have just published a video on the new patch released this week! I try to keep it basic, but informative, to cater to more people. I hope it helps some people! Keep up the fantastic work, everyone!

https://youtu.be/a2eAol231j4
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on July 14, 2019, 04:57:37 AM
Sure...

If I open multiview with Execute (amiga-E) from workbench and load a text file from a requester, the text file loads properly.  I then use Workbench to go to another file and drag that icon into the multiview window, multiview will not respond to open up file and I get a error message in title bar saying icon cannot be dragged into this window. 

However, if I again load a text file via the "Open" menu item in multiview, I can load a new text file.  And then if I drag an icon into this window, it works!


If you want to get response i would recommend to at least describe the problem. i do not browse links for your convenience. ;)
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 14, 2019, 07:52:26 AM
Sure...
No worries. The problem has been found and fixed in the meantime. Along with the problem of "copy" you reported.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on July 14, 2019, 03:03:32 PM
Thanks for confirming!

Sure...
No worries. The problem has been found and fixed in the meantime. Along with the problem of "copy" you reported.
Title: Re: The Os 3.1.4 Thread
Post by: wiser3 on July 14, 2019, 04:47:18 PM
Well, probably time to continue with another episode. This time with my "most beloved component", which is HDToolBox.

With the latest release do we still have to enter "0x1FE00" in the MaxTransfer setting box? If so, why? Please explain more about this setting and what it take for HDToolBox to figure it out itself.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 14, 2019, 09:14:27 PM
With the latest release do we still have to enter "0x1FE00" in the MaxTransfer setting box?
Yes.

If so, why?
Another unforeseen bug in the scsi.device. The current scsi.device, which was backported from an Os 4 version, unfortunately performs a read on write-only IDE registers to determine the continuation position of a long transfer that had to be truncated, and thus continues from the wrong point on.

This issue has been found and fixed in the meantime and will be resolved with the next version of the scsi.device.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on July 15, 2019, 07:05:09 AM
So how will next version of scsi.device be "rolled out"?
Part of free update 3.1.4.1.5 loaded with LoadModule? OS 3.2 as a new product, with new floppies and kickstart chips to buy?
Questions that nobody can answer?
Title: Re: The Os 3.1.4 Thread
Post by: Rotzloeffel on July 17, 2019, 03:22:49 PM
We could... but we don´t want to  8)
Title: Re: The Os 3.1.4 Thread
Post by: Matt_H on July 18, 2019, 12:55:06 AM
Two things:

First, Thomas, thanks so much for the work you and Olaf (and others?) are doing to polish up 3.1. It’s really great to see the classic “lightweight” branch of the OS maintained again. I’ve bought versions for my 4000T and my 2000.

Second, does the 3000 version come with a SuperKickstart file compatible with the 1.4 ROMs?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 18, 2019, 10:57:45 AM
Second, does the 3000 version come with a SuperKickstart file compatible with the 1.4 ROMs?
No, sorry, it does not. The ROM is a regular A3000 ROM. This being said, some users successfully converted it to a superkickstart file. As far as I remember, all you had to do is to attach the right superkickstart code at its end, where this code just comes from the original superkickstart file.
Title: Re: The Os 3.1.4 Thread
Post by: Matt_H on July 18, 2019, 05:46:03 PM
No, sorry, it does not. The ROM is a regular A3000 ROM. This being said, some users successfully converted it to a superkickstart file. As far as I remember, all you had to do is to attach the right superkickstart code at its end, where this code just comes from the original superkickstart file.

Ah, oh well. Is an official SuperKickstart planned for a later update?  Good to know there are potential workarounds in the meantime.

In the absence of a physical ROM replacement, can LoadModule successfully load in the 3.1.4 modules on a 1.4 system? (after SuperKickstart 3.1 has been softkicked, of course)
Title: Re: The Os 3.1.4 Thread
Post by: hth313 on July 18, 2019, 07:54:19 PM
The bonus code is the part after 512K of any 2.x or 3.x superkickstart file.

During startup it is copied onto the last 4K of the actual kickstart image, the MMU is configured so that this RAM image loaded appears in the ROM location and write protects it. Then the system resets and your soft kicked image is now the “ROM”. As long as you do not fiddle with the MMU in a bad way it stays there and appears to be the ROM so ordinary resident tricks should work the same as with a real ROM.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 18, 2019, 09:24:53 PM
Ah, oh well. Is an official SuperKickstart planned for a later update?
Not really. Problem is the lack of testing opportunities for this, and you can always install a new ROM chip instead. Actually, the superkickstart code in the A3000 Os ROM has (at least two) bugs which demonstrates that this code is too fragile to be kept in there forever.


In the absence of a physical ROM replacement, can LoadModule successfully load in the 3.1.4 modules on a 1.4 system? (after SuperKickstart 3.1 has been softkicked, of course)
Well, again, I haven't tested this, but I see no reason why not. But then again, in such a case I would rather consider MuMapROM as it replaces the entire ROM in one go.


Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 19, 2019, 06:44:35 PM
Maybe continue with the next episode. What is also new is DiskCopy and Format. Both system tools suffered from a defect declaring the font definition as "static", which would have triggered a "hit". The problem there was that the structure that describes the desired font ended up on the stack instead of the heap, and thus went away later on in the program, causing the problem. In our testing, nothing else overwrote the stack, so the problem remained undetected.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on July 21, 2019, 06:04:28 AM
I was trying the 68k version of the WarpBMP datatype (https://www.warpdt.co.uk/) to load a BMP picture into multiview using the 46.13 picture.datatype.  This is using Amiga native graphics (A4000T) and no graphic card installed.   

I am seeing the picture not loading correctly.  Top of screen is getting rendered incorrectly and then the whole system crashes with guru 8100 0005 after trying to quit multiview or right click for menus.

Attached is a photo of the screen after loading.
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on July 23, 2019, 12:37:05 AM
@my_pc_is_amiga

Hi,

Are you also the same person posting as "Castellen" in other Amiga forums?
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on July 23, 2019, 02:03:01 AM
No, I'm somebody different.   Has anybody reproduced the strange loading of pictures (e.g. BMP pictures) that causes a guru.  I'm always paranoid that I'm hitting some hardware issue with my A4000T instead of software when it comes to these memory corruptions -- feel much better if it just software since that always can get fixed :).

I'm also finding that if I load a picture in multiview in full screen mode and if the picture size is small, a small screen is opened.  Because of that, there isn't enough screen real estate for the menu bar to fully show and the ASL requester cannot open properly.

I think heard that the older AIFF/WAV datatypes (that are available on Aminet) need some updating to get them to work again with the 3.1.4.   I haven't been able to get those old ones to work anymore.

Lastly, a wish that I don't think has even made it into OS4.x--to have copy and search support for amigaguide in multiivew.


@my_pc_is_amiga

Hi,

Are you also the same person posting as "Castellen" in other Amiga forums?
Title: Re: The Os 3.1.4 Thread
Post by: Dynamic_Computing on July 23, 2019, 06:55:07 AM
I am having an issue with one of my machines - my most powerful one.
A4000, Warp Engine upgraded to 68060/80 MHz, 96+ MB RAM, 15,000 RPM SCSI Hard Drive, Cybergraphx 64 3D with Picasso drivers.
Running Amiga OS 3.1.4.1 with real ROMS. The entire system works great and incredibly fast, except booting. Startup Sequence hangs on setpatch for about 90 to 120 seconds - it runs, and I can see the results of it, and it just sits there until "Intuition is trying to close Windows" pops up. A few minutes later, it seems to finish and it boots normally and works fantastic.
I suspect it MIGHT be the CPU command right after setpatch, but not 100% sure. Anyone else experience this?
The system is not locked as the mouse moves fine and I can move the shell window around.
The slowness in booting also occurred on a raw install, no update from 3.9
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 23, 2019, 09:40:23 AM
The system is not locked as the mouse moves fine and I can move the shell window around.
The slowness in booting also occurred on a raw install, no update from 3.9
You can always test this by booting in interactive or echo mode, i.e. "set echo on" at the start of the startup-sequence. You then see where the system hangs. My best guess is in "SetPatch", or to be precise, in the 68060.library building the MMU tables. 96MB is quite some memory, so constructing them may take a while. If you are using the mmu.library, try to upgrade it. The latest release keeps the cache enabled for building the initial tables and may hence operate somewhat faster.
Title: Re: The Os 3.1.4 Thread
Post by: Dynamic_Computing on July 24, 2019, 04:53:18 AM
I can certainly test that theory by taking out most of the memory. I can just boot it with the onboard 16 MB. I will track down the latest mmu.library, too. Thanks for the quick response!
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 24, 2019, 06:24:40 AM
I can certainly test that theory by taking out most of the memory. I can just boot it with the onboard 16 MB. I will track down the latest mmu.library, too. Thanks for the quick response!
Another "most promising candidate" is the FFS which requires some time to validate large partitions. While the new FFS would be somewhat faster with this, the best option you have is to use larger block sizes (i.e. 4096 bytes per block = 8 sectors per block) to speed up the operation. This requires, however, reformatting the affected partition(s).
Title: Re: The Os 3.1.4 Thread
Post by: Rotzloeffel on July 26, 2019, 07:42:47 AM
I was trying the 68k version of the WarpBMP datatype (https://www.warpdt.co.uk/) to load a BMP picture into multiview using the 46.13 picture.datatype.  This is using Amiga native graphics (A4000T) and no graphic card installed.   

could you please test this with the Picture.datatype from 3.9 ? I also had some issues with warp-Datatypes and the new Picture.library. I allready reported this to Oliver Roberts.

It seems the warp.datatypes are the "Problem"
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on July 27, 2019, 05:16:57 PM
I copied the picture.datatype from OS 3.9 and OS3.9bb2 versions to my 3.1.4 installation and still see same issue in the 3.1.4 environment.  I also tried bmpdt.lha on aminet and see same issue. Adpro that doesn’t use data types is okay with same BMP picture. 

Then I loaded the OS3.9 env. from an Emergency Disk that booted the CD-ROM.  I loaded up the warpbmp datatype and loaded the *bmp into multiview and no issue (no crashing or picture corruption).  Also, in the 3.9 env. multiview is giving full access to menu bar for small images -- in 3.1.4 multiview is making small screen size as reported previously.

I was trying the 68k version of the WarpBMP datatype (https://www.warpdt.co.uk/) to load a BMP picture into multiview using the 46.13 picture.datatype.  This is using Amiga native graphics (A4000T) and no graphic card installed.   

could you please test this with the Picture.datatype from 3.9 ? I also had some issues with warp-Datatypes and the new Picture.library. I allready reported this to Oliver Roberts.

It seems the warp.datatypes are the "Problem"
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on July 27, 2019, 10:18:24 PM
I've been trying to get CrossDOSFileSystem to work with Poseidon USB Stack and have read through the FAQ, etc. but no luck.  It gets mounted but DOS says "Not a DOS disk".  Fat95 mounts but I rather use CrossDOSFileSystem.  Does anybody have a Poseidon config. that works with thumb drives?   Also, in the FAQ, it mentions, mount flags like Fat32, "DirectSCSI" -- if we were to use these, do we need to use it like this in a mountfile:

Control  = "Fat32=1, DirectSCSI=1"
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on July 28, 2019, 05:22:45 AM
Don't know if this is related to the previous memory leak with shell "copy" command  -- but in doing a copy in workbench (drag-and-drop) from my hard drive to RAM:, I was doing a large copy.  It was enough that filled up my RAM disk.  I got the message that my RAM disk is full but after acknowledging the requester and stopping the copy, my ram was not freed properly.  My fast ram in workbench title bar showed "3,782,782,128 other memory" (~3.5GB!).   I only have 272MB of fast memory.   And doing an avail, I saw negative numbers being reported for "available" 
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 28, 2019, 08:43:47 AM
I've been trying to get CrossDOSFileSystem to work with Poseidon USB Stack and have read through the FAQ, etc. but no luck.  It gets mounted but DOS says "Not a DOS disk".  Fat95 mounts but I rather use CrossDOSFileSystem. 
Is this a "superfloppy" with no partition information on it, or a partitioned disk? Thumbdrives that are pre-formatted for the PC are the latter, thus use the instructions in the FAQ. Also note the name of the drive, it should end with a 'C' or a '0' to indicate the partition number, and the right DOS type as indicated in the FAQ.

Does anybody have a Poseidon config. that works with thumb drives?   Also, in the FAQ, it mentions, mount flags like Fat32, "DirectSCSI" -- if we were to use these, do we need to use it like this in a mountfile:

Control  = "Fat32=1, DirectSCSI=1"
No, the FAQ does certainly not mention a mount flag like Fat32. Fat32 support is built into CrossDos, this is what it says. "DirectSCSI" *is* a mount flag, but you only need that for broken devices that do not support reads beyond the 4GB barrier. I am not aware that the usbscsi.device is broken, but I could be wrong. So, nothing of the above. Mount flags are just used as indicated in the FAQ:

Code: [Select]
DirectSCSI=1

This is a native mount flag, not part of any "control" or whatsoever - there are examples in the FAQ (yes, really!). But, you don't want this mount flag anyhow.

Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on July 28, 2019, 09:37:13 AM
Don't know if this is related to the previous memory leak with shell "copy" command  -- but in doing a copy in workbench (drag-and-drop) from my hard drive to RAM:, I was doing a large copy.  It was enough that filled up my RAM disk.  I got the message that my RAM disk is full but after acknowledging the requester and stopping the copy, my ram was not freed properly.  My fast ram in workbench title bar showed "3,782,782,128 other memory" (~3.5GB!).   I only have 272MB of fast memory.   And doing an avail, I saw negative numbers being reported for "available"
Sorry, I cannot reproduce this here. I need better instructions for reproduction. If the RAM disk becomes full, you get a requester whether the incomplete object should be removed. If I say "no", the RAM is still full, but I see a small amount of RAM left. If I say "yes", the RAM is released.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on July 28, 2019, 06:01:18 PM
I was trying to reproduce as well and haven't seen it for a 2nd time.    I tried both ways of saying "yes" and "no" but haven't reproduced.  Unfortunately, I don't have any more details of what led up to it except I'm attaching some photos of when it happened the first time.


Sorry, I cannot reproduce this here. I need better instructions for reproduction. If the RAM disk becomes full, you get a requester whether the incomplete object should be removed. If I say "no", the RAM is still full, but I see a small amount of RAM left. If I say "yes", the RAM is released.
Title: Re: The Os 3.1.4 Thread
Post by: utri007 on July 28, 2019, 11:00:46 PM
Do I remember right that CDTV will be supported in future?  Stephen Leary aka Terrible fire has rebuild cdtv.device, so that he could support CDTV with his accelerators.

Because of copyrights everyone needs to build it himself.

Quote
The build environment requires.

CDTV.H from the original CDTV Developer CD. Place it in the build folder.
Python 2.7 - to generate the cdtv.i file from the CDTV.H (can be done on linux etc)
VASM - My assembler of choice.
Amiga NDK 3.9
Gnu Make
MD5SUM (to verify the file checksum only)
OR...

You can use docker. Add the CDTV.H file then..

docker build . -t terriblefire/vbcc

Then to build the sources

docker run --rm --volume "$PWD":/usr/src/compile --workdir /usr/src/compile -i -t terriblefire/vbcc make

He has a message for a Amiga os devs

Quote
I am happy for the original copyright holders and those with an AmigaOS development license to compile and include this code in a binary ROM that they distribute. Actually please do!!! I want this to happen. Make improvements to the CDTV Extended ROM while you are at it!!!





Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on July 28, 2019, 11:24:29 PM
Is this a "superfloppy" with no partition information on it, or a partitioned disk? Thumbdrives that are pre-formatted for the PC are the latter, thus use the instructions in the FAQ. Also note the name of the drive, it should end with a 'C' or a '0' to indicate the partition number, and the right DOS type as indicated in the FAQ.

Let me check this some more...
[Edit]  Got it to work using DosType 0x4D534800 for a partition table drive -- user mistake :)

Quote
No, the FAQ does certainly not mention a mount flag like Fat32. Fat32 support is built into CrossDos, this is what it says. "DirectSCSI" *is* a mount flag, but you only need that for broken devices that do not support reads beyond the 4GB barrier. I am not aware that the usbscsi.device is broken, but I could be wrong. So, nothing of the above. Mount flags are just used as indicated in the FAQ:

When I look at: http://us4.aminet.net/aminet/docs/help/AmigaOS_3.1.4-FAQ.txt -- Line 652

'Note: CrossDOS supports long file names, the mount flags "EnableNSD", "DirectSCSI", Fat32, Fat16, Fat12 and Fat8.'

So "Fat32, Fat16, Fat12 and Fat8" text after the "mount flag" wording is what confused me but thanks for the clarification.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on July 29, 2019, 04:32:16 AM
I loaded up the 3.1.4.1 env. but using 3.9 Multiview 45.9.  No issues using the BMP datatype with the older multiview 45.9.  It seems like newer multiview 45.22 is having some issue.   I am keeping 3.1.4 picture.datatype 46.13 loaded.

I copied the picture.datatype from OS 3.9 and OS3.9bb2 versions to my 3.1.4 installation and still see same issue in the 3.1.4 environment.  I also tried bmpdt.lha on aminet and see same issue. Adpro that doesn’t use data types is okay with same BMP picture. 

Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 03, 2019, 12:17:46 AM
I have deneb usb card using pio device driver on a 68040 a4000t. With 3.1.4.1 I have experienced workbench GUI freezing when I remove a usb thumb drive. I have a shell window open and that was still working okay . With info I see usb drive removed from device list.  Later I loaded up 3.9 and haven’t yet encountered this issue.

With 3.1.4.1 I tried putting in pc dos disk in floppy to see if same issue - this is working okay. Then  I tried Jaz disk with mount file for CrossDos- this worked also

I seemed to have hit an issue with HDToolBox. With a jaz disk in the drive, HDToolBox gets stuck when scanning scsi.device at the unit number of the jaz disk. Also when booting  I’ve experienced the scsi bus did not find all disks and only the jaz disk showed up in the early boot menu
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 03, 2019, 03:55:40 PM
I loaded up the 3.1.4.1 env. but using 3.9 Multiview 45.9.  No issues using the BMP datatype with the older multiview 45.9.  It seems like newer multiview 45.22 is having some issue.   I am keeping 3.1.4 picture.datatype 46.13 loaded.
That looks more like an issue with the datatypes you are using. The datatypes that come with the Os have been tested and work fine.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 03, 2019, 04:02:52 PM
I have deneb usb card using pio device driver on a 68040 a4000t. With 3.1.4.1 I have experienced workbench GUI freezing when I remove a usb thumb drive.
Well,  so there is an issue with the USB stack, or the deneb device driver. Device mounting and loading did not change from 3.1 to 3.1.4 at all. Aminet provides a tool to detect deadlock situations and provide debug information in such a case, but this requires a serial terminal, connected via a null-modem connector at 96008N1. It could also be a hardware lockup, in which case there is nothing that can be done by software. The tool you are looking for is "Locksmith", see Aminet. It installs a keyboard interrupt handler that prints details about the lock-up over the serial port.

I seemed to have hit an issue with HDToolBox. With a jaz disk in the drive, HDToolBox gets stuck when scanning scsi.device at the unit number of the jaz disk. Also when booting  I’ve experienced the scsi bus did not find all disks and only the jaz disk showed up in the early boot menu
There is no single scsi.device. You mean the SCSI scsi.device of an A3000 or A4000T? The JAZ comes in various combinations, SCSI, some IDE, some parallel. If scanning the SCSI bus locks up then this is because there is an electrical problem at the SCSI bus, typically the result of bad termination or bad cabling. HDToolbox uses regular SCSI Inquiry commands to find out more about the device. However, if you want to learn more about the problem, please download SCSISnoop from aminet, and install Sashimi, and run SCSISnoop on the device and unit of the JAZ drive. Then capture the output of SCSISnoop over Sashimi and provide it here.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 05, 2019, 05:45:19 AM
Thanks Thomas for the debug tools.   The Jaz drive is a real SCSI device and is using the 2nd.scsi.device on the A4000T at unit 1.  I'm attaching the SCSISnoop for when 3.1.4.1 HDToolbox is launched vs. the 3.9 version (both being used in the 3.1.4.1 env.).   I also noticed when I use the SCSIQuery, it also is does the  defect check and it is there that Jaz drive hangs.   The 3.9 HDToolbox doesn't look like it does that step.


There is no single scsi.device. You mean the SCSI scsi.device of an A3000 or A4000T? The JAZ comes in various combinations, SCSI, some IDE, some parallel. If scanning the SCSI bus locks up then this is because there is an electrical problem at the SCSI bus, typically the result of bad termination or bad cabling. HDToolbox uses regular SCSI Inquiry commands to find out more about the device. However, if you want to learn more about the problem, please download SCSISnoop from aminet, and install Sashimi, and run SCSISnoop on the device and unit of the JAZ drive. Then capture the output of SCSISnoop over Sashimi and provide it here.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 06, 2019, 07:04:28 AM
Thanks Thomas for the debug tools.   The Jaz drive is a real SCSI device and is using the 2nd.scsi.device on the A4000T at unit 1.  I'm attaching the SCSISnoop for when 3.1.4.1 HDToolbox is launched vs. the 3.9 version (both being used in the 3.1.4.1 env.).   I also noticed when I use the SCSIQuery, it also is does the  defect check and it is there that Jaz drive hangs.   The 3.9 HDToolbox doesn't look like it does that step.
Thanks, I seem to remember this when creating the IOTools. Collecting the defect data from a JAZ drive may take a while, so it probably does not hang, but is just busy. Instead of the size of the defect list, the IO drives had a custom SCSI command to read out the lifetime of the medium, but that helps little if you need the precise list of defect sectors. So just give it some time to process the results. The time should be rather measured in minutes but seconds, but the command will succeed after quite a while.

This said, all the defect management by HDToolBox is pretty much nonsense for even remotely modern drives - they do that all themselves. In principle, HDToolBox can collect such defect lists (which it does) and store it in the RDB of the disk (which it does) where it could be used by the device running the system, to work around such defects. This made some sense in the time of RLL and MFM disks which had no defect management in their firmware (which firmware?), but in how far the scsi.device implementation of this is working I do not know. For (real) scsi based disks (and anything more modern), this is just bogus as the drive manages defects itself.

One way or another, HDToolbox is a dinasour, and this defect management should really go as it is non-sensical. But then again, I would prefer not to waste any more time in this dinasour, and let it get extinct for good. The hdwrench library of 3.9 is in better shape and omits this step (for reasons), but its unfortunately not available for 3.1.4 and successors.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 07, 2019, 06:35:45 AM
Thanks Thomas for the details.   Yes, HDToolbox is working fine after sometime (I needed to have a little more patience...).   I didn't really time it but it does take a awhile to show up.   

Upon booting, I still see issue where only the JAZ disk shows up in the early boot menu and none of my bootable hard disks shows up.  The JAZ disk shows up as MSH0 unbootable and no other hard disk in early boot (even though I have a scsi ID 3 and 6 hooked up).  And so in this scenario I get to a "insert floppy" screen from the ROM.  Without a disk in the JAZ it is okay and 3 and 6 comes up just fine and everything boots.

In regards to the usb stack and mounting devices, I tried LockSmith and then got into the situation where Workbench GUI is freezing while I remove a usb device.  But I could not get locksmith to send anything on serial port on the deadlock.   I did a check with Lockout and Locksmith is working with that test scenario.  So maybe something else is causing a hang besides semaphores?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 07, 2019, 10:06:01 AM
Upon booting, I still see issue where only the JAZ disk shows up in the early boot menu and none of my bootable hard disks shows up.  The JAZ disk shows up as MSH0 unbootable and no other hard disk in early boot (even though I have a scsi ID 3 and 6 hooked up).  And so in this scenario I get to a "insert floppy" screen from the ROM.  Without a disk in the JAZ it is okay and 3 and 6 comes up just fine and everything boots.
Did you install an RDB on it and made it bootable with the HDToolBox? Which hostadapter is the JAZ connected to? It is mostly a matter of the hostadapter to ensure the creation of the mount entries - which is what you see in the boot menu. There is also a "last drive" flag in the RDB which indicates that the corresponding host adapter should not scan for any other drives behind the selected SCSI ID, thus disabling any drives with an ID higher than the drive the RDB was written to.

In regards to the usb stack and mounting devices, I tried LockSmith and then got into the situation where Workbench GUI is freezing while I remove a usb device.  But I could not get locksmith to send anything on serial port on the deadlock.   I did a check with Lockout and Locksmith is working with that test scenario.  So maybe something else is causing a hang besides semaphores?
Then that's not semaphore related, but either the system is blocked with interrupts disabled (i.e. within a Disable()), or it is some kind of hardware lockup. I afraid there is nothing I can really do then.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 12, 2019, 04:28:29 AM
Did you install an RDB on it and made it bootable with the HDToolBox? Which hostadapter is the JAZ connected to? It is mostly a matter of the hostadapter to ensure the creation of the mount entries - which is what you see in the boot menu. There is also a "last drive" flag in the RDB which indicates that the corresponding host adapter should not scan for any other drives behind the selected SCSI ID, thus disabling any drives with an ID higher than the drive the RDB was written to.

I made this drive sometime ago and so can't remember exactly but it does look like it has a RDB on it and is showing up as not bootable in early startup menu.  After loading it up in HDToolbox, there was a message about some changes  were needed for the drive and so I did a save and now during boot it no longer stops at unit=1.   So there must have been some "last drive" flag set. 

Quote
Then that's not semaphore related, but either the system is blocked with interrupts disabled (i.e. within a Disable()), or it is some kind of hardware lockup. I afraid there is nothing I can really do then.

I did a lot more testing on this now and finally figured out that having the "Unmount partitions after removal" option enabled in the "LUN Defaults of the massstorage.class of the usb stack was causing issues.  I tried it with both the Deneb and a RapidRoad USB cards and both were doing the hang when that option was set.  Without this, it no longer hangs.  As a matter of fact, I actually started to see the issue in 3.9 as well when the option set.     


In regards, to 3.1.4 multiview (v45.22) and the warp BMP datatype, I was trying to see if I could do some captures with MuForce and so attaching some of the dumps from the serial port.   What doesn't make sense is that this log shows input.device having issue...don't really understand that.   With the 3.9 Multiview (v45.9) program in 3.1.4 env. I don't see graphic corruption issue -- when i did this comparison with v45.22 and v45.9, everything is exactly the same except for the multiview version.


And for the RAM issue that I had, I haven't been able to reproduce exact same issue.  However, I have experienced 800 0004 GURU while deleting the files from the RAM disk.  I'm attaching a MuForce output for this crash.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on August 12, 2019, 05:51:12 AM
Which input.device are you using? Poseidon comes with input.device backported from MorphOS (v50) to fix various issues with USB hidd and v40 input.device (multi-kbd/mouse support and more), so maybe you are using that?
Title: Re: The Os 3.1.4 Thread
Post by: F1Lupo on August 12, 2019, 06:40:48 AM
anyone else notice a slight slow down with the new FFS update? I'm now getting 1,310,720 bytes/sec but was getting 1,638,400 with previous version
Title: Re: The Os 3.1.4 Thread
Post by: kolla on August 12, 2019, 09:09:56 AM
Quote
was getting 1,638,400 with previous version

Really? That number looks way too, uhm... casual, to be real :)
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 12, 2019, 02:20:29 PM
anyone else notice a slight slow down with the new FFS update? I'm now getting 1,310,720 bytes/sec but was getting 1,638,400 with previous version
The only thing that changed in the FFS was the disk validator, disk formatting and the mounting procedure. The I/O main loop and I/O operations in general did not change at all. So whatever this is (or not) is not due to the changes in the FFS.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 12, 2019, 02:29:14 PM
Which input.device are you using? Poseidon comes with input.device backported from MorphOS (v50) to fix various issues with USB hidd and v40 input.device (multi-kbd/mouse support and more), so maybe you are using that?

That is not a "fix" of the input.device, it is an extension of its interface. The problem is that the USB hid class uses for input.devices below V50 IND_WRITEEVENT to propagade keyboard and mouse events to the chain of input device handlers. But this command only does this: Propagade events. Unfortunately, the USB hid class seems to expect that the input.device generates keyboard repeat events itself, which it does not (i.e. auto-repeat a key once it is kept pressed) - it is not the purpose of this command to interpret commands in any particular way. It would be the job of the usb hid class to synthetize such events. Thus, this is actually a defect in Poseidon. What V50 added was a new command (IND_ADDEVENT) Poseidon uses instead in case a V50 is detected, and this new command then takes over the job of creating synthetic events to generate keyboard repeat events - but as said, this is not a bug fix, it is an extended interface.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 12, 2019, 02:37:59 PM
I did a lot more testing on this now and finally figured out that having the "Unmount partitions after removal" option enabled in the "LUN Defaults of the massstorage.class of the usb stack was causing issues.  I tried it with both the Deneb and a RapidRoad USB cards and both were doing the hang when that option was set.  Without this, it no longer hangs.  As a matter of fact, I actually started to see the issue in 3.9 as well when the option set.   
"Removing" mouted drives is not an obvious thing to do - in fact, this is not possible under AmigaDOS. Removable media should *always* be mounted with a mount list, and never over an RDB. As you observe, multiple bad things can happen if you just attempt to kill a running handler. Once FFS is running, it cannot be killed anymore - unfortunately, it does not support ACTION_DIE. 

In regards, to 3.1.4 multiview (v45.22) and the warp BMP datatype, I was trying to see if I could do some captures with MuForce and so attaching some of the dumps from the serial port.   What doesn't make sense is that this log shows input.device having issue...don't really understand that.
This is probably a side-effect of something else, i.e. the datatype probably stumps on memory that belongs to the input.device and by that kills it. There are two possible options: 1) There is an option to reduce the interface of the picture datatype to that of V40. This has the impact that true-color pictures are only rendered by dithering, but the interface remains then at the V40 level the datatype may expect. There is an ENV: varaiable to change that which is mentioned in the FAQ, but unfortunately I'm currently away so I cannot check right now. 2) Try to run MuGuardianAngel on top of MuForce. This may detect additional problems MuForce alone is not able to pick up.


With the 3.9 Multiview (v45.9) program in 3.1.4 env. I don't see graphic corruption issue -- when i did this comparison with v45.22 and v45.9, everything is exactly the same except for the multiview version.
There isn't really a substantial change between the versions. One thing you can try is to give multiview more stack. There is a stack check included, but maybe the stack is not sufficient for the datatype.


And for the RAM issue that I had, I haven't been able to reproduce exact same issue.  However, I have experienced 800 0004 GURU while deleting the files from the RAM disk.  I'm attaching a MuForce output for this crash.
This can be almost anything and is probably due to some other bad effect that happened earlier. I would need a long stack traceback to see anyhting there.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 13, 2019, 05:28:18 AM
Thanks Thomas!

Once FFS is running, it cannot be killed anymore - unfortunately, it does not support ACTION_DIE. 
I assume this is also true of the crossdosfilesystem?

Quote
1) There is an option to reduce the interface of the picture datatype to that of V40. This has the impact that true-color pictures are only rendered by dithering, but the interface remains then at the V40 level the datatype may expect. There is an ENV: varaiable to change that which is mentioned in the FAQ, but unfortunately I'm currently away so I cannot check right now. 2) Try to run MuGuardianAngel on top of MuForce. This may detect additional problems MuForce alone is not able to pick up.

I'll have to check out the ENV variables some more.  I was trying them sometime ago but at that time I didn't see it helping.  I haven't been able to get MuGuardianAngel to work -- seems to hang system.  I have put it after MuForce.

Quote
One thing you can try is to give multiview more stack.
I tried changing to 94096k stack and still saw issue.


Quote
This can be almost anything and is probably due to some other bad effect that happened earlier. I would need a long stack traceback to see anyhting there.
Attached is a longer stack trace -- hopefully this is long enough.  If not I can try to do another capture. This time when it failed I got 800 0005.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 13, 2019, 05:29:32 AM
Which input.device are you using? Poseidon comes with input.device backported from MorphOS (v50) to fix various issues with USB hidd and v40 input.device (multi-kbd/mouse support and more), so maybe you are using that?

I've been using the 3.1.4.1 version of input.device.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on August 13, 2019, 02:28:52 PM
this is not a bug fix, it is an extended interface.

Well, from users' perspective, that is rather irrelevant distinction.

For me, the particular "issue" is that with original input.device, I cannot click on links in IBrowse using USB mouse, as if IBrowse doesn't get the mouse-button release event properly... with input.device v50 it works. As apparently there is no interest in maintaining Poseidon for Amiga OS, and all development taking place for MorphOS and AROS.. perhaps I should just switch to anaiis for AmigaOS and see how that works.

Anyways - the point here was just to give a heads up to make my_pc_is_amiga, that when installing Poseidon, a different input.device may also have been installed.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 13, 2019, 03:16:21 PM
perhaps I should just switch to anaiis for AmigaOS and see how that works.
Thanks -- I didn't know about Anaiis.  I looks like it only supports subway / highway as of now.  Sirion USB stack for OS4 I guess it out of the question as of now for 3.x -- I'm not aware of any 68k version and assume there isn't any drivers for the classic zorro cards.

Quote
Anyways - the point here was just to give a heads up to make my_pc_is_amiga, that when installing Poseidon, a different input.device may also have been installed.

Thanks for letting me know.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 13, 2019, 04:20:34 PM
Well, from users' perspective, that is rather irrelevant distinction.
Not really. It is a defect of the delivered USB stack, and it should have been done correctly in the stack in first place. Delivering an alternative input.device was never the right solution in first place - this was the kludge to begin with. One way or another, this issue has been addressed, but in how far an updated Poseidon stack can be delivered is something I cannot decide. All I can say is that I took precautions to address the problem, and I did my best to provide a solution.

Title: Re: The Os 3.1.4 Thread
Post by: Matt_H on August 13, 2019, 05:04:47 PM
perhaps I should just switch to anaiis for AmigaOS and see how that works.
Thanks -- I didn't know about Anaiis.  I looks like it only supports subway / highway as of now.  Sirion USB stack for OS4 I guess it out of the question as of now for 3.x -- I'm not aware of any 68k version and assume there isn't any drivers for the classic zorro cards.

Sirion was originally written for the Thylacine card, so a 68K version does exist. But even the OS4 version has extremely limited driver support (for both Amiga cards and USB peripherals) and the 68K version is even older and more limited. As far as I’m aware, none of the OS4 components were ever backported.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 14, 2019, 04:49:50 AM
I assume this is also true of the crossdosfilesystem?
No, CrossDos does support ACTION_DIE, and then also goes away, but all provided that there are no locks left on any mounted volume. Then again, I do not know what Poseidon exactly attempts. Actually, the only file system where I did *not* add ACTION_DIE is the FFS.

I tried changing to 94096k stack and still saw issue.
I'll check the MuForce hit once I'm back home. Right now, it makes no sense - thanks.
Title: Re: The Os 3.1.4 Thread
Post by: beller on August 14, 2019, 06:13:14 AM
Are there any known issues with the 3.1.4 serial device?  I have a GuruModem which worked fine on my A600 but on the A1200 with 3.1.4 I can receive characters like a list of available wifi sites, but I don't appear to be transmitting properly.  Checked all the settings and it should be working.

Also, I searched the Hyperion site and noticed a complaint about iPrefs crashing after changing a preference on an OS 4 machine.  The post on Hyperion said it was fixed.  I saw this same crash several times today.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 14, 2019, 06:19:56 AM

I tried changing to 94096k stack and still saw issue.
I'll check the MuForce hit once I'm back home. Right now, it makes no sense - thanks.

Just to clarify, the MuForce hit I posted recently was for when deleting files from RAM disk.   

For multiview (seperate issue), I haven't been able to get anything that makes sense from MuForce.   But there is still 1 thing that is different:

1) v40.8 (3.1) --> this is opening screen that is larger than the picture size (no issue)
2) v45.9  (3.9) -> this is opening screen that is larger than the picture size (no issue)
3) v45.22  (3.1.4) --> this one is scaling screen to match picture size (see graphic corruption and memory corruption).   Also, as noted previously, the other side affect is if the picture is very small then the menu/ASL requester cannot show on the very small screen.

Can it be something to do with the screen size change that is happening in v45.22?

Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 14, 2019, 06:27:45 AM
Are there any known issues with the 3.1.4 serial device?  I have a GuruModem which worked fine on my A600 but on the A1200 with 3.1.4 I can receive characters like a list of available wifi sites, but I don't appear to be transmitting properly.  Checked all the settings and it should be working.

I've been using serial.device on my A4000T with a null modem cable with 3.1.4 and haven't seen any issue when using the terminal program "Term"

Quote
Also, I searched the Hyperion site and noticed a complaint about iPrefs crashing after changing a preference on an OS 4 machine.  The post on Hyperion said it was fixed.  I saw this same crash several times today.

Is this a OS4 machine that you have or talking about crashes with 3.1.4.   Do you have sequence of how it crashes (i.e. what preference editor, etc) if on 3.1.4
Title: Re: The Os 3.1.4 Thread
Post by: beller on August 14, 2019, 01:56:00 PM
No...it’s not an OS 4 machine it’s an A1200.  I noticed this error while searching for info on Hyperion’s web site.  I had iPrefs crash repeatedly on 3.1.4 which, just guessing, must share some of the same code as OS4.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 14, 2019, 01:57:19 PM
For multiview (seperate issue), I haven't been able to get anything that makes sense from MuForce.   But there is still 1 thing that is different:

1) v40.8 (3.1) --> this is opening screen that is larger than the picture size (no issue)
2) v45.9  (3.9) -> this is opening screen that is larger than the picture size (no issue)
3) v45.22  (3.1.4) --> this one is scaling screen to match picture size (see graphic corruption and memory corruption).   Also, as noted previously, the other side affect is if the picture is very small then the menu/ASL requester cannot show on the very small screen.

Can it be something to do with the screen size change that is happening in v45.22?
There simply is no "scale to screen" option for background images in the current IPrefs. It was not part of 3.1, so it was not part of 3.1.4 either. This option will come again in 3.2.

I am unclear what you mean by "this is openening screen".
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 14, 2019, 01:59:03 PM
No...it’s not an OS 4 machine it’s an A1200.  I noticed this error while searching for info on Hyperion’s web site.  I had iPrefs crash repeatedly on 3.1.4 which, just guessing, must share some of the same code as OS4.
No, it is not. The IPrefs from 3.1.4 is essentially one of the versions from 3.9. I am not aware of any defect there. If you see a crash, I would like to have the MuForce output as I have no defect on file for it.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on August 14, 2019, 02:01:58 PM
Well, from users' perspective, that is rather irrelevant distinction.
Not really. It is a defect of the delivered USB stack, and it should have been done correctly in the stack in first place. Delivering an alternative input.device was never the right solution in first place - this was the kludge to begin with.
That's easy to say 15-20 years later. When Chris was developing Poseidon, this may not have been so obvious for him, and also his focus was forward, towards MorphOS. Unlike you, he couldn't use OS 3.1 sources as reference. Anyways - you were around too, so why didn't you do anything... The "kludge" has been the fix for the last 20 years or so, if OS 3.1.4 input.device comes with a better "solution", then fine... guess I could give it a whirl, the software license be damned.

Quote
One way or another, this issue has been addressed, but in how far an updated Poseidon stack can be delivered is something I cannot decide. All I can say is that I took precautions to address the problem, and I did my best to provide a solution.
Poseidon sources are available, I don't see what would disallow you to fix things "properly" if you so wish.

Btw - I notice that there is quite a brawl on the apollo-core forum about you and your opinions, mr ppcamiga1 :)
( http://www.apollo-core.com/knowledge.php?b=1&note=17502&x=6&z=fuqLnm )
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 14, 2019, 02:29:07 PM
That's easy to say 15-20 years later. When Chris was developing Poseidon, this may not have been so obvious for him, and also his focus was forward, towards MorphOS.
Look, this is all speculation. Whether this was obvious, whether it was not, whether it was intended or not. I do not know. The fix was done at the wrong end - it is too late for a change.

Unlike you, he couldn't use OS 3.1 sources as reference.
For this, you do not need any sources. You only need to know the documentation of IND_WRITEEVENT. Actually, the docs say it all: It sends the given event down the stream of input event handlers. That is it, and the source for the input.device do not tell you anything beyond this. For reasons unknown to me, Chris seemed to  assume or require that it also creates synthetic keyboard repeat events, but it is not promised by the interface at all. And actually *should not*. If it would, it would break software such as FKey or commodities in general as they may create more events than intended, and different events than intended.

Anyways - you were around too, so why didn't you do anything...
You seem to believe that you have the right to demand service from me. How come? So, let's straighten up things for you again: I am not your AmigaOs service personell. First, I did not have Poseidon back then when Chris wrote it. How should I possibly be responsible for something I did not write, I did not use, I did not own and I was not even aware of. If he'd asked, I would have told him, but this is all years ago.  We are doing something for it right now as the problem was reported, and that is the earliest point at which a problem can be handled.

The "kludge" has been the fix for the last 20 years or so, if OS 3.1.4 input.device comes with a better "solution", then fine... guess I could give it a whirl, the software license be damned.
The input device of 3.1.4 is the same as that of 3.1, and the only new thing it added was NSD. It does not provide any better solution than 3.1, but as of 3.1, there was already a correct way of doing it, namely create synthetic keyboard events yourself for keyboard repeat. Why Chris did not do that is unclear to me. 3.1.4 did not offer any particular "please fix Poseidon for me" feature.

Poseidon sources are available, I don't see what would disallow you to fix things "properly" if you so wish.
One word: Time. Poseidon sources for AROS are available, which do not compile on a 68K classic system. Poseidon sources for 68K are licensed by iComp, and from there I'll try to arrange an update. But anyhow, you can certainly try to be helpful and fix this in the AROS branch.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on August 14, 2019, 03:36:09 PM
You keep talking about keyboards while all my issues with input.device and Poseidon were related to mouse.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 14, 2019, 03:42:44 PM
Just to clarify, the MuForce hit I posted recently was for when deleting files from RAM disk.   
The RAM disk file deletion itself is fine, so I can only assume that something broke before this point and damaged the data structures of RAM: MuGuardianAngel may be able to detect this problem. BTW, in case the machine seems to hang when you run it: This is normal. What it does during startup is to fill the free RAM with a "magic cookie" and depending on the size of the RAM, this may take quite a while. So give it some time. Also, you will notice that the system is considerably slower when it runs. This is also normal and due to the RAM checks.

For multiview (seperate issue), I haven't been able to get anything that makes sense from MuForce.   But there is still 1 thing that is different:

1) v40.8 (3.1) --> this is opening screen that is larger than the picture size (no issue)
2) v45.9  (3.9) -> this is opening screen that is larger than the picture size (no issue)
3) v45.22  (3.1.4) --> this one is scaling screen to match picture size (see graphic corruption and memory corruption).   Also, as noted previously, the other side affect is if the picture is very small then the menu/ASL requester cannot show on the very small screen.

Can it be something to do with the screen size change that is happening in v45.22?
The picture datatype is able to scale pictures. In case you have trouble with this function, I would need the original picture size, and the size you scaled it to, which would allow me to reproduce the issue.

Thanks,
Thomas

Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 14, 2019, 03:50:34 PM
You keep talking about keyboards while all my issues with input.device and Poseidon were related to mouse.
Not that I'm aware of, but then again, I'm not using Poseidon. So what is the issue with the mouse?
Title: Re: The Os 3.1.4 Thread
Post by: kolla on August 14, 2019, 07:31:13 PM
You keep talking about keyboards while all my issues with input.device and Poseidon were related to mouse.
Not that I'm aware of, but then again, I'm not using Poseidon. So what is the issue with the mouse?

Like I wrote... a particular problem I have with original input.device, is that I cannot click on links in IBrowse using USB mouse, as if IBrowse doesn't get the "mouse-button release" event properly. I also recall problems with other programs (DOpus Magellan among them), but I don't recall exactly how the problems manifest themselves in the various programs. Because with input.device v50, these problems are not there.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 14, 2019, 10:43:52 PM
Like I wrote... a particular problem I have with original input.device, is that I cannot click on links in IBrowse using USB mouse, as if IBrowse doesn't get the "mouse-button release" event properly. I also recall problems with other programs (DOpus Magellan among them), but I don't recall exactly how the problems manifest themselves in the various programs. Because with input.device v50, these problems are not there.
Ok, I understand. Maybe. What I do not understand is that the input device, no matter which revision, will not generate key-up events itself. Thus, if Poseidon does not feed key-up events (or rather "button-up" events), they will not appear on the input event chain, no matter which version of the device you are using. What is different is that sending events down the handler chain does not update the keyboard qualifier. Thus, if a software attempts to learn about the pressed "qualifier keys" by PeekQualifier(), then this will not work for synthetic events. However, software should really not depend on PeekQualifier() in first place (see the docs, this is what the input device "thinks" the qualifiers to be, not naturally what they *are*). Instead, software should use the qualifier information from the event (or equivalent IDCMP message) where we do have reliable information.

Thus, at this point, this looks like an implementation defect  at DOpus attempting to obtain qualifiers in an unreliable way. PeekQualifier() is not as useful as one may think, and it certainly should not be called to obtain keyboard or mouse button state information.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 15, 2019, 06:05:13 AM
For multiview (seperate issue), I haven't been able to get anything that makes sense from MuForce.   But there is still 1 thing that is different:

1) v40.8 (3.1) --> this is opening screen that is larger than the picture size (no issue)
2) v45.9  (3.9) -> this is opening screen that is larger than the picture size (no issue)
3) v45.22  (3.1.4) --> this one is scaling screen to match picture size (see graphic corruption and memory corruption).   Also, as noted previously, the other side affect is if the picture is very small then the menu/ASL requester cannot show on the very small screen.

Can it be something to do with the screen size change that is happening in v45.22?

I am unclear what you mean by "this is openening screen".


Multiview has a menu item for using a "separate screen".   Initially, when I load the picture, the picture is displayed in a window on workbench.   I then use the "separate screen" menu option.  Multiview then opens a new screen.   The screen that opens for v45.22 is always exactly the same as the picture size.   So for instance if the picture is 200x100 pixels, the screen would be that same size.    In the other multiview versions, the picture is still displayed in 200x100 pixels but the screen itself could be 668x472.  The pixels that are not part of the picture are displayed black.  In the other multiview versions I can move the mouse pointer beyond the picture size into the black space.  For 45.22, I cannot (hence reason I'm thinking the screen size itself has been sized to same as picture).

I'm attaching a few MuGuardianAngel dump -- thanks for letting me know that it takes time to boot.   I actually started to see something during boot itself but this is something else and not related to multiview.  The other 2 attachments are 2 times that I got multiview to crash.   Strange thing is that with MuGardianAngel enabled, the graphic corruption doesn't happen right away.  And only happens if I start clicking or try to open an ASL requester, and then I see issue.

Title: Re: The Os 3.1.4 Thread
Post by: kolla on August 15, 2019, 06:34:59 AM
Like I wrote... a particular problem I have with original input.device, is that I cannot click on links in IBrowse using USB mouse, as if IBrowse doesn't get the "mouse-button release" event properly. I also recall problems with other programs (DOpus Magellan among them), but I don't recall exactly how the problems manifest themselves in the various programs. Because with input.device v50, these problems are not there.
Ok, I understand. Maybe. What I do not understand...
Quote
Why Chris did not do that is unclear to me.

So it looks like you don't really understand what input.device v50 "cludges" to make things work.

USB is a complex mess, with at least two protocols just for the mouse (bootmouse and hid) and ditto for keyboard, and lots of products in the market that break these protocols in various creative ways. Chris was very clear that using v50 input.device from MorphOS was only a half-way and quick solution for him, and that the entire input system for AmigaOS should have to be rewritten.

Quote
Thus, at this point, this looks like an implementation defect  at DOpus
DOpus, IBrowse, various other MUI software and whatever else that misbehaves with original input.device and Poseidon - you are now the one speculating ... educated speculation, but speculation nevertheless.

For DOpus it is easy enough to look for PeekQualifier in the code... I am not convinced that it is used in parts of the code relevant to where I experience trouble...

https://github.com/mheyer32/dopus5allamigas/search?q=PeekQualifier&unscoped_q=PeekQualifier

You also wrote...
Quote
All I can say is that I took precautions to address the problem, and I did my best to provide a solution.
yet...
Quote
The input device of 3.1.4 is the same as that of 3.1, and the only new thing it added was NSD. It does not provide any better solution than 3.1, but as of 3.1, there was already a correct way of doing it, namely create synthetic keyboard events yourself for keyboard repeat.
This is confusing. Unless the precaution was to not change anything, and to define "the problem" as non-existent.

Anyways - the best advice - as of now - for anyone using Poseidon with USB keyboard and/or mouse - is to load input.device v50 using LoadModule.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 15, 2019, 03:48:52 PM
So it looks like you don't really understand what input.device v50 "cludges" to make things work.

USB is a complex mess, with at least two protocols just for the mouse (bootmouse and hid) and ditto for keyboard, and lots of products in the market that break these protocols in various creative ways. Chris was very clear that using v50 input.device from MorphOS was only a half-way and quick solution for him, and that the entire input system for AmigaOS should have to be rewritten.
USB might be a mess, but that mess is the responsibility of the hid.class and not of the input.device. It is up to the hid.class to create the right events and feed them to the system. If it does not do that, the system will misbehave. It is not the job of the input.device to fix inconsistent input.

Quote
Thus, at this point, this looks like an implementation defect  at DOpus
DOpus, IBrowse, various other MUI software and whatever else that misbehaves with original input.device and Poseidon - you are now the one speculating ... educated speculation, but speculation nevertheless.
Not quite so. The only difference as far as Poseidon is concerned, and yes, I did have a look at the 68K sources -before you ask- is that it uses IND_ADDEVENT vs. IND_WRITEEVENT for submitting events to the input device, and the only difference on the side of the input.device is that IND_ADDEVENT creates synthetic keyboard repeat events and updates the qualifier mask for PeekQualifier().


yet...
Quote
The input device of 3.1.4 is the same as that of 3.1, and the only new thing it added was NSD. It does not provide any better solution than 3.1, but as of 3.1, there was already a correct way of doing it, namely create synthetic keyboard events yourself for keyboard repeat.
This is confusing. Unless the precaution was to not change anything, and to define "the problem" as non-existent.
The precautions do not address 3.1.4 in any way. This is for 3.2 and beyond. Loading another input.device because the hid.class does only half of its job, and applications are uncareful about qualifier masks is rather a workaround than a fix. I do not know Chris' motivation, but maybe he wasn't willing to create branches of his code to address interface changes that appeared in Morphos. The original input.device as such has a reasonably well-defined interface.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 15, 2019, 03:52:11 PM
Multiview has a menu item for using a "separate screen".   Initially, when I load the picture, the picture is displayed in a window on workbench.   I then use the "separate screen" menu option.  Multiview then opens a new screen.   The screen that opens for v45.22 is always exactly the same as the picture size.   So for instance if the picture is 200x100 pixels, the screen would be that same size.    In the other multiview versions, the picture is still displayed in 200x100 pixels but the screen itself could be 668x472.  The pixels that are not part of the picture are displayed black.  In the other multiview versions I can move the mouse pointer beyond the picture size into the black space.  For 45.22, I cannot (hence reason I'm thinking the screen size itself has been sized to same as picture).
Thank you for the logs, I'll have a look as soon as I am back home. Yes, multiview opens the screen the same size of the picture, that is correct. I wonder why that would be a problem? Do you use RTG graphics or FBlit in your system? For which picture size does the problem appear?
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 16, 2019, 04:42:01 AM

Thank you for the logs, I'll have a look as soon as I am back home. Yes, multiview opens the screen the same size of the picture, that is correct. I wonder why that would be a problem?

Do you use RTG graphics or FBlit in your system? For which picture size does the problem appear?
I'm using the Amiga native graphics and not using any hacks (no FBlit or anything). For the #?.bmp files, I've only checked a handful and can't see there is any particular size causing the issue.  I actually compared the picture on my monitor with both v45.22 and earlier Multiview versions and the picture itself is exactly the same x and y size in all versions.  There is no scaling going on between the versions.  In v45.22 where I see graphic corruption, it seems like certain pixels of the picture get overwritten.

I've tried all kinds of IFF sizes and those load just fine.   However, if the IFF picture is small there is a secondary problem with the small screen size -- title bar could be not long enough to show all menus and if you do use the Open ASL, the ASL won't be opened because there is no space on the screen. 
Title: Re: The Os 3.1.4 Thread
Post by: kolla on August 16, 2019, 12:14:19 PM
the ASL won't be opened because there is no space on the screen.

Imagine if it was possible to open a window larger than screen, and move it around with a qualifier + left mouse button pressed...
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 16, 2019, 08:05:44 PM
I'm using the Amiga native graphics and not using any hacks (no FBlit or anything). For the #?.bmp files, I've only checked a handful and can't see there is any particular size causing the issue.
Thanks, I received the images and I'll check them - I'm now on my way home.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 16, 2019, 08:06:55 PM
Imagine if it was possible to open a window larger than screen, and move it around with a qualifier + left mouse button pressed...
Imagine a world where i wouldn't have to repeat myself for kolla. Reasons have been given, you do not want to understand them - that's it.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on August 16, 2019, 10:23:26 PM
You are good at repeating how much you "have to" repeat the reason for me, yet no reason has been given, and certainly not repeated, other than "Windows does this" and some fictional arguments about third party commodities that may end up moving windows into a position where no gadgets can be reached... (something third party commodities can already do btw, regardless of window size) - no name of such commodity has been given, no demonstration of the so called problems have been given. Other windowing systems have no issues with this.  It is just another "because I say so".
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 17, 2019, 07:15:55 AM
You are good at repeating how much you "have to" repeat the reason for me, yet no reason has been given.
Then read again. I'm tired of repeating.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on August 17, 2019, 11:08:13 AM
As I wrote, the only thing you keep repeating, is that you are tired of repeating, you repeat that over and over when you have no better argument.

Why don't you instead come up with a solution to the problem described - what to do when a screen is too small for ASL requesters to show up? Obviously, only you can do it.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 17, 2019, 06:02:23 PM
As I wrote, the only thing you keep repeating, is that you are tired of repeating, you repeat that over and over when you have no better argument.
I don't *need* a better argument. There is no point in convincing you - I really don't care about it.

Why don't you instead come up with a solution to the problem described - what to do when a screen is too small for ASL requesters to show up? Obviously, only you can do it.
Probably because there are more important problems to solve? If the screenis to small, not all windows will fit. Hasn't been any different ever. Making windows partially inaccessible to the user is not a solution either.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 17, 2019, 06:07:48 PM
I'm using the Amiga native graphics and not using any hacks (no FBlit or anything). For the #?.bmp files, I've only checked a handful and can't see there is any particular size causing the issue.  I actually compared the picture on my monitor with both v45.22 and earlier Multiview versions and the picture itself is exactly the same x and y size in all versions.  There is no scaling going on between the versions.  In v45.22 where I see graphic corruption, it seems like certain pixels of the picture get overwritten.

I've tried all kinds of IFF sizes and those load just fine.   However, if the IFF picture is small there is a secondary problem with the small screen size -- title bar could be not long enough to show all menus and if you do use the Open ASL, the ASL won't be opened because there is no space on the screen.
The right border trash is apparently due to a misalignment of the pixel dimension, and the number of bytes in a row of a BMP file. This is an old bug, actually. The bmp.datatype is not in good shape. That the system crashes for some BMPs is a new bug, but actually in the picture datatype. It is only triggered if a datatype adjusts the attribute of the picture.datatype in "inconvenient order" *and* the image depth is higher than the maximal available screen depth. That one of the bmps does not decode is just the matter of the simplicity of the bmp.datatype. There are many BMP variants out in the wild - there are multiple windows header versions, an OS/2 version, and an option for runlength compression the simple bmp.datatype does not support at present.

So thanks for the pictures, the defects have been fixed to the amount possible. The bmp.datatype requires a major rehaul, though, as it only supports a minor subset of the BMP formats available.

Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 17, 2019, 09:47:13 PM
I actually started to see something during boot itself but this is something else and not related to multiview. 

This hit was coming from mounting of the "PCO" dosdriver.  When I changed the stack size in the PC0 mount list from the default of 600 to 1200, I no longer saw the hit.   The nice thing here is that I as a simple user I could read the stack size warning in the debug output from MuGuardianAngel :)
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 18, 2019, 04:00:22 AM
Just to clarify, the MuForce hit I posted recently was for when deleting files from RAM disk.   
The RAM disk file deletion itself is fine, so I can only assume that something broke before this point and damaged the data structures of RAM: MuGuardianAngel may be able to detect this problem. BTW, in case the machine seems to hang when you run it: This is normal. What it does during startup is to fill the free RAM with a "magic cookie" and depending on the size of the RAM, this may take quite a while. So give it some time. Also, you will notice that the system is considerably slower when it runs. This is also normal and due to the RAM checks.

I have actually been seeing hits while copying files through the Workbench copy (drag-n-drop).  Attaching the hits.  So looks like something is happening before I do a delete.  This copy is coming from the USB thumb drive with a rapidroad usb module on the xsurf zorro card to the RAM: disk.   I'm attaching a second capture when doing the Workbench delete.   In this case I didn't see any "software failure" but my memory didn't back to 100% free.   Is this same issue that was already reported with the shell "copy" command or something different?
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 18, 2019, 04:01:10 AM
The other capture attached.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 18, 2019, 04:13:12 AM

So thanks for the pictures, the defects have been fixed to the amount possible. The bmp.datatype requires a major rehaul, though, as it only supports a minor subset of the BMP formats available.

Thanks a lot.   Does that mean you also fixed the screen size to be large enough for menu items, etc. for when small pictures are loaded?   

Also, one other observation is that when certain pictures (l.e. BIRD.BMP) is loaded in a window on workbench versus in its own screen the aspect ratio changes.  The picture in the window looks like the correct aspect ratio.   This I think has "always" been there -- at least from what I could tell.   

And finally, if there is a picture that has a large resolution -- large than a screen resolution available the screen is made much larger (so screen is scrolling).  I've noticed that even with OS4 multiview.  This is when scaling of the picture is needed (is this what will be there for 3.2)?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 18, 2019, 11:37:58 AM
This hit was coming from mounting of the "PCO" dosdriver.  When I changed the stack size in the PC0 mount list from the default of 600 to 1200, I no longer saw the hit.   The nice thing here is that I as a simple user I could read the stack size warning in the debug output from MuGuardianAngel :)
If you see a stack warning from PC0:, then you are not using the crossdosfilesystem from 3.1.4. (or 3.1.4.1) because this has an automatic stack extension to at least 2K. You can always check the mounts by downloading "Devices" from Aminet and then running "Devices PC0:" on the shell.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 18, 2019, 12:02:10 PM
Thanks a lot.   Does that mean you also fixed the screen size to be large enough for menu items, etc. for when small pictures are loaded?   
No. There was some other reason why we had the screen not larger than the image. I believe this was due to the CDXL datatype which required this. So at this point, there is no fix. What multiview could do is use a smaller font, but that does not need to work either if the screen is just too small. Use the shortcuts from the menu.

Also, one other observation is that when certain pictures (l.e. BIRD.BMP) is loaded in a window on workbench versus in its own screen the aspect ratio changes.  The picture in the window looks like the correct aspect ratio.   This I think has "always" been there -- at least from what I could tell.   
There is no aspect ratio correction whatsoever. While the picture.datatype supports scaling, multiview does not make use of it.


And finally, if there is a picture that has a large resolution -- large than a screen resolution available the screen is made much larger (so screen is scrolling).  I've noticed that even with OS4 multiview.  This is when scaling of the picture is needed (is this what will be there for 3.2)?
Yes, this is intentional. The screen width or height will be made larger if necessary. There is no scaling intended, see above. Multiview opens an autoscroll screen, so you scroll.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 18, 2019, 12:46:28 PM
The other capture attached.
Not reproducable here. Note that the RAM: task is only detecting the problem, not necessarily causing it. Are you using the original RAM: disk, or some replacement? Also, what was the size of the file you had copied (how) and how did you delete it?

From the pattern observed in the rear mungwall, only a single bit was changed from 1 to 0. This looks more like an indication of bad RAM and a hardware problem.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 18, 2019, 12:51:14 PM
I have actually been seeing hits while copying files through the Workbench copy (drag-n-drop).  Attaching the hits.  So looks like something is happening before I do a delete.  This copy is coming from the USB thumb drive with a rapidroad usb module on the xsurf zorro card to the RAM: disk.   I'm attaching a second capture when doing the Workbench delete.   In this case I didn't see any "software failure" but my memory didn't back to 100% free.   Is this same issue that was already reported with the shell "copy" command or something different?

See above. These are bit-flips in the memory cookie. This does not look like a software problem. Bitflips indicate problems on the bus and are caused by aging hardware.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 18, 2019, 08:29:09 PM
If you see a stack warning from PC0:, then you are not using the crossdosfilesystem from 3.1.4. (or 3.1.4.1) because this has an automatic stack extension to at least 2K. You can always check the mounts by downloading "Devices" from Aminet and then running "Devices PC0:" on the shell.

It looks like I'm running 45.36 according to "version l:crossdosfilesystem"   It looks like the "StackSize" mount option overrides the automatic extension...when mount it with StackSize=600 (Mount file default), I get this. 

Code: [Select]
DeviceName : PC0
Type       : Device
Task       : 79A0190 PC0
Handler    : L:CrossDOSFileSystem
Stacksize  : 600 BYTEs
Priority   : 10
Segment    : 0x1E68213
FirstHunk  : 0x79A0850
GlobalVec  : do not create GlobVec
Startup    : 0x799FC3C
ExecDevice       : mfm.device
Unit             : 0
Flags            : 0x1
Environment      :
TableSize        : 0x13
BytesPerSector   : 512
FirstLong        : 0
Surfaces         : 2
SectorsPerBlock  : 1
SectorsPerTrack  : 9
Reserved         : 1
PreAlloc         : 0
Interleave       : 0
Direct SCSI      : no
Superfloppy      : no
Disable NSD      : no
LowCyl           : 0
HighCyl          : 79
Buffers          : 5
BufMemType       : 0x1
MaxTransfer      : 0x7FFFFFFF
Mask             : 0xFFFFFFFE
BootPri          : 0
DosType          : MSD0x0
Baud             : 1200
Control          : 0x0
Bootblocks       : 0


When I mount it while removing the StackSize option altogether, I get 2400 bytes stack size.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 18, 2019, 09:05:41 PM
Not reproducable here. Note that the RAM: task is only detecting the problem, not necessarily causing it. Are you using the original RAM: disk, or some replacement? Also, what was the size of the file you had copied (how) and how did you delete it?

From the pattern observed in the rear mungwall, only a single bit was changed from 1 to 0. This looks more like an indication of bad RAM and a hardware problem.

I'm using the original RAM: disk.   I was copying entire directory and so not sure exactly file size to when I saw errors.  When I got to RAM: disk full, I did a cancel and then did a workbench delete.   
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 18, 2019, 09:09:22 PM

It looks like I'm running 45.36 according to "version l:crossdosfilesystem"   It looks like the "StackSize" mount option overrides the automatic extension...when mount it with StackSize=600 (Mount file default), I get this. 
This extension cannot be overridden, I checked. I can only assume that the initial memory allocation of CrossDos allows MuGa to pick this up. One way or another, the stack is extended later on, so this is not a problem.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 18, 2019, 09:10:17 PM
I'm using the original RAM: disk.   I was copying entire directory and so not sure exactly file size to when I saw errors.  When I got to RAM: disk full, I did a cancel and then did a workbench delete.
The error pattern - namely individual bits in wrong position in the MuGa fence - is a strong indicator that this is some form of hardware problem.
Title: Re: The Os 3.1.4 Thread
Post by: trekiej on August 18, 2019, 09:12:12 PM
Does 3.1.4 do anything in particular for an A2000?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 18, 2019, 09:26:54 PM
Does 3.1.4 do anything in particular for an A2000?
What do you mean "in particular"? There is no "particular" A2000 ROM, just one common for the A500,A600 and A2000 (i.e. ECS machines).
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 18, 2019, 09:51:51 PM
I've noticed that if I do a "remove object" from the requester after the RAM: disk is full, the #?.info drawer that was  created in RAM: does not get deleted.  The dir. gets deleted but not the #?.info.   This is when I drag an entire disk into the RAM: window and the directory get's created.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 18, 2019, 09:57:27 PM
I'm using the original RAM: disk.   I was copying entire directory and so not sure exactly file size to when I saw errors.  When I got to RAM: disk full, I did a cancel and then did a workbench delete.
The error pattern - namely individual bits in wrong position in the MuGa fence - is a strong indicator that this is some form of hardware problem.

I turned off the SimpleSCSI flag in Trident and seems to be working okay now.  But I'm crossing my fingers -- need to check more (hopefully it is not some heated related thing and I was lucky not to hit issue).   But I turned SimpleSCSI back on and then started to see hits.   I also did a copy from my SCSI hard disk to RAM: and didn't see any hits.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 18, 2019, 10:02:07 PM
No. There was some other reason why we had the screen not larger than the image. I believe this was due to the CDXL datatype which required this. So at this point, there is no fix. What multiview could do is use a smaller font, but that does not need to work either if the screen is just too small. Use the shortcuts from the menu.

For the about requester and the ASL requester, maybe a suggestion would be to pop up on workbench if not able to open on its own pubscreen.   If in full screen mode there is no shortcut to go back to window mode -- and so only option as of now would be to quit program with Amiga-Q.
Title: Re: The Os 3.1.4 Thread
Post by: TribbleSmasher on August 18, 2019, 10:04:16 PM
Does 3.1.4 do anything in particular for an A2000?

Please note that the new 3.1.4 requires a little more resources than the older 3.1 due to recent improvements. So with an unexpanded A2000 it is not that good choice.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 18, 2019, 11:06:06 PM
I've noticed that if I do a "remove object" from the requester after the RAM: disk is full, the #?.info drawer that was  created in RAM: does not get deleted.  The dir. gets deleted but not the #?.info.   This is when I drag an entire disk into the RAM: window and the directory get's created.
Not reproducable here. If you drag an entire disk onto RAM:, diskcopy will complain that the object is of wrong type and cannot be copied (which is true, RAM: is a handler without underlying device). If you drag the contents of a volume onto a disk, everything can be removed again. If you drag contents onto RAM: and RAM: gets full, you can either answer to remove the incomplete object, which it always does completely, or leave the incomplete object on disk. In this case, you may end up with a .info without a corresponding file or directory, but in any case, they could be deleted fine.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 18, 2019, 11:08:17 PM
I turned off the SimpleSCSI flag in Trident and seems to be working okay now.  But I'm crossing my fingers -- need to check more (hopefully it is not some heated related thing and I was lucky not to hit issue).   But I turned SimpleSCSI back on and then started to see hits.   I also did a copy from my SCSI hard disk to RAM: and didn't see any hits.
SimpleSCSI? I'm not aware of this flag, what is it supposed to do? One way or another, if you see bitflips like this, something is wrong. Before you seem to believe that everything is right, give the system some time to warm up and then try again. Such bus errors do not get away easily - they indicate a hardware problem that is in general not solvable by software.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 19, 2019, 05:53:57 AM
Not reproducable here. If you drag an entire disk onto RAM:, diskcopy will complain that the object is of wrong type and cannot be copied (which is true, RAM: is a handler without underlying device). If you drag the contents of a volume onto a disk, everything can be removed again. If you drag contents onto RAM: and RAM: gets full, you can either answer to remove the incomplete object, which it always does completely, or leave the incomplete object on disk. In this case, you may end up with a .info without a corresponding file or directory, but in any case, they could be deleted fine.

To clarify, I am opening up the RAM: disk to show its window on workbench.  I then drag a disk icon into the window of the RAM: disk and do the copy (this is not a diskcopy).  As you mentioned there are 2 ways to delete files in workbench after I get the "disk is full" prompt:

1) Cancel the operation and say no to "remove incomplete object"  Then use the menu item to delete entire directory by selecting it within the RAM: window.  This one deletes the directory and the *.info file.
2) Cancel the operation and say yes to "remove incomplete object"   In this situation, the *.info file is left in the RAM: disk.  Not a big deal as I can delete the *info if need to manually. 
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 19, 2019, 06:03:42 AM
SimpleSCSI? I'm not aware of this flag, what is it supposed to do? One way or another, if you see bitflips like this, something is wrong. Before you seem to believe that everything is right, give the system some time to warm up and then try again. Such bus errors do not get away easily - they indicate a hardware problem that is in general not solvable by software.

The only description I have is this from the manual:

"- Simple SCSI:
  Filter out or emulate most SCSI commands that are not used by Windows and
  hence, a lot of devices will drop dead on these (or just return junk). It
  will also intercept  all  calls  to  MODE_SENSE  and  returns  faked  but
  accurate geometry data."

I had this option enabled for the massstorage.class and now I have it disabled.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 19, 2019, 06:13:43 AM
This extension cannot be overridden, I checked. I can only assume that the initial memory allocation of CrossDos allows MuGa to pick this up. One way or another, the stack is extended later on, so this is not a problem.


Thanks -- I had a MuGa enabled as I was using trackdisk.device (stack issue) and CMD (Mung-wall damaged) -- not sure the sequence of events for these but thought in case it is any use, I'm attaching them.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 19, 2019, 12:58:11 PM
Thanks -- I had a MuGa enabled as I was using trackdisk.device (stack issue) and CMD (Mung-wall damaged) -- not sure the sequence of events for these but thought in case it is any use, I'm attaching them.
trackdisk wasn't changed for 3.1.4, and as far as CMD is concerned, I cannot reproduce this here. The hit comes from a call into AllocEntry()/FreeEntry(), and neither of the two are called by CMD itself. The dos.library calls them when initializing a new process, but the size of the allocation does not fit the size the dos.library uses. So this comes from somewhere else. If you run MuGA, please try to reproduce the CMD issue, but for MuGA, add to the command line "STACKCHECK STACKLINES=32" to get a larger stack dump.
Title: Re: The Os 3.1.4 Thread
Post by: trekiej on August 19, 2019, 03:39:41 PM
@Thomas R. and Tribble Smasher
I need to see the Release Notes.

I understand that SCSI got improved or updated.
Would this help an A2091, for example?

How about Z2 RTG video cards?
Better performance also?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 19, 2019, 03:44:22 PM
@Thomas R. and Tribble Smasher
I need to see the Release Notes.
Release notes are non-public by decision of Hpyerion.

I understand that SCSI got improved or updated.
Would this help an A2091, for example?

The A2091 comes with its own boot ROM, as far as I understand, so this does not help anything. What does help is that autoconf timing got a little bit more relaxed, helping to auto-detect the A2091 in fast systems. This could have failed before.


How about Z2 RTG video cards?
Better performance also?
RTG cards are handled by either P96 or Cybergraphics, and none of them are part of the Os. However, there is an updated P96 available for purchase (for little money) from iComp which fixes some of the known issues, such as rendering problems for HiColor modes or a more flexible use of the hardware sprite. The speed of RTG cards over Z2 bus is a hardware limitation, namely a bandwidth limitation of Zorro-II, and this cannot be addressed by software.



Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 20, 2019, 05:10:03 AM
trackdisk wasn't changed for 3.1.4, and as far as CMD is concerned, I cannot reproduce this here. The hit comes from a call into AllocEntry()/FreeEntry(), and neither of the two are called by CMD itself. The dos.library calls them when initializing a new process, but the size of the allocation does not fit the size the dos.library uses. So this comes from somewhere else. If you run MuGA, please try to reproduce the CMD issue, but for MuGA, add to the command line "STACKCHECK STACKLINES=32" to get a larger stack dump.

I just did multiple double clicks of the CMD icon (i.e. enable/disable/enable/disable, etc), and eventually got the hit.  This is with MULTIPLE=TRUE and NOTIFY=TRUE tooltypes and FILE=ram:CMD_file

For the PC0 stack, I did see 2048 stack in xoper when having the mount file set to 600 - so yeah the auto is working.   
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 20, 2019, 12:44:26 PM

I just did multiple double clicks of the CMD icon (i.e. enable/disable/enable/disable, etc), and eventually got the hit.  This is with MULTIPLE=TRUE and NOTIFY=TRUE tooltypes and FILE=ram:CMD_file
See above.  This hit is coming from a FreeEntry() call which releaes 18 bytes of memory from an AllocEntry() call of a corresponding size. There is no place in the CMD executable nor in the operating system where 18 bytes are allocated via AllocEntry() during the exeuction of a binary. In fact, AllocEntry() is not used by CMD at all, but only by Create(New)Proc of the Os, and there only with 20 bytes (for the seglist array) and not with 18 bytes.

I cannot reproduce this here. Hence, this is due to some other patch, hack or modification of the operating system. I cannot fix what does not come from Os components.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 20, 2019, 11:35:15 PM

I just did multiple double clicks of the CMD icon (i.e. enable/disable/enable/disable, etc), and eventually got the hit.  This is with MULTIPLE=TRUE and NOTIFY=TRUE tooltypes and FILE=ram:CMD_file
See above.  This hit is coming from a FreeEntry() call which releaes 18 bytes of memory from an AllocEntry() call of a corresponding size. There is no place in the CMD executable nor in the operating system where 18 bytes are allocated via AllocEntry() during the exeuction of a binary. In fact, AllocEntry() is not used by CMD at all, but only by Create(New)Proc of the Os, and there only with 20 bytes (for the seglist array) and not with 18 bytes.

I cannot reproduce this here. Hence, this is due to some other patch, hack or modification of the operating system. I cannot fix what does not come from Os components.

Thomas, thanks for checking this.   I wasn't tracing my steps carefully enough.  Enabling/Disabling CMD multiple times alone does not cause the hit as I originally posted.  I tried that alone and did not see it.   It is only after I do the "ECHO >PRT:" below and then remove CMD redirection that I get the hit.


1) Set these options in the ToolTypes for CMD:
MULTIPLE=TRUE
NOTIFY=TRUE
FILE=ram:CMD_
2) Double click CMD in workbench to install redirection.
3) In shell do this, ECHO >PRT: "Test"
4) Double click on "CMD" icon in workbench.  This will of course remove it.  It is at this point that I get the hit.


Could you check one more time if this is making any more sense or if you can reproduce?  I don't have any known patches in my system (just running LockSmith, MuForce, and MuGa). 
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 21, 2019, 05:23:39 AM
Finding something else when using CMD with ASL requester:

1) Set these options in the ToolTypes for CMD:
MULTIPLE=TRUE
NOTIFY=TRUE
(FILE=ram:CMD_file)  --> this will open ASL requester.
2) Double click CMD in workbench to install redirection.
3) In shell do this, ECHO >PRT: "Test"
4) Once ASL is open, click cancel button in ASL.   
5) After sometime a requester will come up to say "Printer Trouble: Check printer and cabling" (my printer is off).
6) Click cancel on that requester and then CMD redirection closes.
7) I get this hit.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 22, 2019, 09:48:53 PM
Finding something else when using CMD with ASL requester:

No, seriously. This is the same as above. I cannot reproduce this here. Is this the standard asl.library? Is this the standard icon.library?
Title: Re: The Os 3.1.4 Thread
Post by: trekiej on August 23, 2019, 02:07:03 AM
Who would own the code in the A2091?
I wonder if it needs to be updated.

Each manufacturer would have to, of course, update their own code.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 23, 2019, 04:53:52 AM
Finding something else when using CMD with ASL requester:

No, seriously. This is the same as above. I cannot reproduce this here. Is this the standard asl.library? Is this the standard icon.library?

Strange for sure.  Yes, this is the 3.1.4 versions (icon.library v45.22 and asl.library v46.15).   And you tried this?
Code: [Select]
echo >prt: test
If I get a chance I'll try on an A3000.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 23, 2019, 05:41:38 AM
Strange for sure.  Yes, this is the 3.1.4 versions (icon.library v45.22 and asl.library v46.15).   And you tried this?
Code: [Select]
echo >prt: test
If I get a chance I'll try on an A3000.
I tried "InitPrinter", which also prints data through PRT: Is this the 3.1.4 Port-Handler on your side?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 23, 2019, 05:43:48 AM
Who would own the code in the A2091?
I wonder if it needs to be updated.

Each manufacturer would have to, of course, update their own code.
That is, pardon, was CBM of course. My research shows that this is build from the same code as the scsi.device, even though I haven't tried to build it, and I don't know whether it would build. To make this a ROM image, a bit more would probably be required, probably. With the A2091, you should be much better off with the Guru-ROM, though.
Title: Re: The Os 3.1.4 Thread
Post by: trekiej on August 23, 2019, 06:16:48 AM
No offense intended, would the rom need to be switched in software or rom chip replacement?
 :D
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 23, 2019, 06:20:18 AM
No offense intended, would the rom need to be switched in software or rom chip replacement?
 :D

I have no idea, really.
Title: Re: The Os 3.1.4 Thread
Post by: trekiej on August 23, 2019, 07:02:34 AM
I will stop bugging you. :D

edit:
For a little while, at least.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 23, 2019, 08:23:07 PM
I tried "InitPrinter", which also prints data through PRT: Is this the 3.1.4 Port-Handler on your side?

Yes this is 3.1.4 port-handler.  I've done a little more testing to compare Workbench versus shell execution.  When I run CMD in the shell with the MULTIPLE option enabled, I don't see any issue (no hits).    The only way to stop CMD in this mode is to send CTRL-C and that works fine.  If I  issue another CMD command from another shell, I'm notified that "CMD: Device already redirected" and CMD will not close.

The only time I'm getting a hit is if I have MULTIPLE=TRUE in the tooltype and I execute as in the sequence I sent before from Workbench:

1) Set these options in the ToolTypes for CMD:
MULTIPLE=TRUE
FILE=ram:CMD_file
2) Double click CMD in workbench to install redirection.
3) In shell do this, ECHO >PRT: "Test" or do the InitPrinter
4) Double click on "CMD" icon in workbench.  This removes but at this point that I get the hit.

If I execute CMD with MULTIPLE from workbench and then execute CMD from shell, shell notify's me that device already redirected and CMD does not close.

While I was playing around and I use the FILE option in the command line, the ASL requester always opens no matter if I specify FILE or not.

Code: [Select]
CMD FILE=ram:test
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 23, 2019, 10:58:38 PM
A few things I'm noticing with printing and was trying to figure out with the CMD command:

a) Not sure if this is intended but "InitPrinter" is initializing twice:
Code: [Select]
0000: 1B266C32 411B2664 401B266C 36441B26    .&l2A.&d@.&l6D.&   
0010: 6C316C32 65363046 1B266134 6C37344D    l1l2e60F.&a4l74M     
0020: 1B266130 520D1B26 64401B28 304E1B28    .&a0R..&d@.(0N.(     
0030: 73306231 30683271 30703073 33743075    s0b10h2q0p0s3t0u     
0040: 3132561B 2A722D34 551B2A76 31530D1B    12V.*r-4U.*v1S..     
0050: 266C3241 1B266440 1B266C36 441B266C    &l2A.&d@.&l6D.&l   
0060: 316C3265 3630461B 2661346C 37344D1B    1l2e60F.&a4l74M.     
0070: 26613052 0D1B2664 401B2830 4E1B2873    &a0R..&d@.(0N.(s     
0080: 30623130 68327130 70307333 74307531    0b10h2q0p0s3t0u1     
0090: 32561B2A 722D3455 1B2A7631 530D0D0A    2V.*r-4U.*v1S...     
00A0: 0C         



b) When I first turn on the computer and then turn on the HP 932C deskjet printer, it goes through some kind of reset (including a form feed).  But if I turn it off and on again it doesn't do that again. The Power LED goes on and when I go through the echo >prt: "test", I eventually get the "Check cables" requester.  Hitting cancel, seems to make the printer go through the reset and is happy again.

c) Also, the HP 932C printer is strange in that after the Init sequence or even with a normal echo >prt: "test", I get a"Resume" light blinking on the printer -- though seems like i can safely ignore that.   I was trying 2 drivers in Pagestream.   This is the end of the output.   Pagestream drivers issues a Reset and system printer driver issues a form feed.  For Pagesteam driver, I don't get the resume light blinking.

Code: [Select]
Pagestream Driver
0350: 57F4000D 03E0003F FFFFF800 7FFFF000    Wô...à.?..ø...ð.     
0360: 01F01B2A 62313757 F4000D03 E0003FFF    .ð.*b17Wô...à.?.     
0370: FFF8003F FFC00001 F01B2A62 3557EC00    .ø.?.À..ð.*b5Wì.     
0380: 0103FE1B 2A72431B 45                   ..þ.*rC.E           


Pagestream with Prefs. Printer Driver
14810: 1B266C31 6C326536 30461B26 61346C37    .&l1l2e60F.&a4l7     
14820: 344D0D1B 2A6F3071 32441B2A 7030581B    4M..*o0q2D.*p0X.     
14830: 2A723046 1B2A7433 3030521B 2A723066    *r0F.*t300R.*r0f     
14840: 32343030 73347431 7530411B 2A62326D    2400s4t1u0A.*b2m     
14850: 30571B2A 62326D30 571B2A62 326D3057    0W.*b2m0W.*b2m0W     
14860: 1B2A6232 6D30571B 2A72431B 266C316C    .*b2m0W.*rC.&l1l     
14870: 32653630 460C                          2e60F.               
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 24, 2019, 09:30:00 AM
The only time I'm getting a hit is if I have MULTIPLE=TRUE in the tooltype and I execute as in the sequence I sent before from Workbench
I finally found the culprit here after looking at the code for a while. The problem was that CMD was apparently using the buffer of the FILE tooltype for appending the digit for identifying multiple outputs, which was of course only allocated to hold the name itself. (Outch!). So that got fixed. What I also fixed is that FILE was ignored when run from the shell. I've no idea why was that.

Thank you for the report!
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 24, 2019, 09:50:09 AM
A few things I'm noticing with printing and was trying to figure out with the CMD command:

a) Not sure if this is intended but "InitPrinter" is initializing twice:
InitPrinter() doesn't initialize much. It just creates the ANSI "reset" code, and that is it:

Code: [Select]
Write(file,"\x1b#1\n",4)
This is, essentially, InitPrinter. (Hear, AmgiaOs source code public. (-;)). Everything else is up to the printer driver which takes this ANSI code and generates the printer-specific verson of it. This generate a bunch of CSI codes that are created both by the aRIS command (which is the nice name of this reset sequence), and the generic initialization of the printer that installs the page margins etc from the preferences.

c) Also, the HP 932C printer is strange in that after the Init sequence or even with a normal echo >prt: "test", I get a"Resume" light blinking on the printer -- though seems like i can safely ignore that.   I was trying 2 drivers in Pagestream.   This is the end of the output.   Pagestream drivers issues a Reset and system printer driver issues a form feed.  For Pagesteam driver, I don't get the resume light blinking.
The problem is that the amiga printer model is that of a line printer. You print a line, you are done. Unfortunately, this printer model is not adequate for today. Your hp is a page printer, that is, it needs an entire page at once. The reason why it is blinking is that it misses the form feed to indicate that the page has been transmitted completely, but this never comes. The problem is that we cannot simply send this when closing PRT: since that doesn't fit the model of the line printer either. There is no problem with a program opening and closing PRT: every line - this is acceptable behaviour. Even worse, if we would create a form feed at the end of a text output, it would be no longer possible to mix graphics and text on the same page. We had all this during beta testing, but there is no good solution to the problem. You can eject the page manually, you can create a form feed by software and send it to PRT:, all of this is fine.

So, in essence, I had the choice to either print some output incorrectly (by injecting always form feed when closing the device) or by leaving an inconvenience at the user. I believe what we settled at is to create the formfeed after printing graphics output, but not after text output. This is the best I can offer with the aged "page model" the Amiga has.
Title: Re: The Os 3.1.4 Thread
Post by: kamelito on August 24, 2019, 03:51:22 PM
Is it possible to print to file line by line and when you’ve a page you send it to the printer?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 24, 2019, 04:55:15 PM
Is it possible to print to file line by line and when you’ve a page you send it to the printer?

I'm not sure what you're asking. Certainly it's possible from an application to do that. AmigaOs cannot and should not distinguish whether a page is complete or not. This is, however, not an implementation strategy for the printer.device for the problem I just mentioned. As stated, it is perfectly fine for an application to print a line, then wait five seconds, then print another. There is no way for the printer.device to find out whether the two lines were supposed to go on the same page or on two different pages.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 25, 2019, 03:33:56 AM

I finally found the culprit here after looking at the code for a while. The problem was that CMD was apparently using the buffer of the FILE tooltype for appending the digit for identifying multiple outputs, which was of course only allocated to hold the name itself. (Outch!). So that got fixed. What I also fixed is that FILE was ignored when run from the shell. I've no idea why was that.

Thank you for the report!

Nice!  Thanks for finding and fixing!   For CMD with ASL requester, what is the expected behavior when we hit cancel in the ASL?   With a cancel in ASL, I get a "Check printer / cable" requester and then if I hit cancel there I get message that CMD redirection has been removed.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 25, 2019, 04:10:26 AM

This is, essentially, InitPrinter. (Hear, AmigaOs source code public. (-;)). Everything else is up to the printer driver which takes this ANSI code and generates the printer-specific verson of it. This generate a bunch of CSI codes that are created both by the aRIS command (which is the nice name of this reset sequence), and the generic initialization of the printer that installs the page margins etc from the preferences.

a) It looks like the printer.device does its own Initprinter() when opened, then SYS:Tools/InitPrinter does  Initprinter() and then before PRT: closes, it adds a form feed at the end.   I think you might mean aRIN since if I send aRIS, I only get the PCL code of "*EE" (HP reset code).  One question is why the Initprinter() does not issue aRIS at the beginning before the aRIN? 

Another way to say this if that I can see aRIN when doing below and see the form feed at the end (using CMD).  The "test" text sits inbetween.

Code: [Select]
echo >prt: "test" NOLINE

b) I'm actually seeing a form feed (CTRL-L) in text mode and in graphic mode.  And if I do below with no CMD, a form feed happens on the ink jet printer and resume light blinks.

Code: [Select]
echo >par: CTRL-L NOLINE

c) If I do a PCL code of a single reset, the power LED starts blinking (according to the manual when LED blinks this means data is being received):
Code: [Select]
echo >par: "*EE" NOLINE
If I do a second "*EE", then it stops blinking.  No clue why I get 2 different responses for the same code being sent.

And finally, if I do a:
Code: [Select]
echo >par: "*EEtest*EE" NOLINE
The text "test" gets printed and the 2nd reset ejects the paper without a form feed.  No resume light blinks. Or alternatively,

Code: [Select]
echo >prt: "test" NOLINE
echo >par: "*EE" NOLINE    ; turns off blinking by issue reset after form feed (0xC) from prior command.

It seems like the Pagestream driver when it issues a *EE (PCL reset) at the end, this essentially does a form feed and no resume light blinks.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 25, 2019, 04:30:54 AM
Is it possible to print to file line by line and when you’ve a page you send it to the printer?

I'm not sure what you're asking. Certainly it's possible from an application to do that. AmigaOs cannot and should not distinguish whether a page is complete or not. This is, however, not an implementation strategy for the printer.device for the problem I just mentioned. As stated, it is perfectly fine for an application to print a line, then wait five seconds, then print another. There is no way for the printer.device to find out whether the two lines were supposed to go on the same page or on two different pages.

There is this book "Mastering Amiga Printers" that mentions on page 173 that if you do

ECHO >PRT: IS THERE ANYONE THERE NOLINE that "the output data is now sitting in the printer's line buffer" and then if you issue

ECHO >PRT:

the text will print.

But with FormFeed appended at the end when redirection close, this doesn't seem to work that way anymore. It will just print right away.  I have no clue why ECHO > prt: would work without a string being sent.  I guess ECHO >PRT:  was suppose to send the 0x0D 0x0A. 

If you do a ECHO >PRT: "", then you will get 0x0D 0x0A and 0x0C.       
If you do a ECHO >PRT: "" NOLINE, then actually nothing happens.

Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 25, 2019, 08:18:13 AM

But with FormFeed appended at the end when redirection close, this doesn't seem to work that way anymore. It will just print right away.  I have no clue why ECHO > prt: would work without a string being sent.  I guess ECHO >PRT:  was suppose to send the 0x0D 0x0A. 

If you do a ECHO >PRT: "", then you will get 0x0D 0x0A and 0x0C.       
If you do a ECHO >PRT: "" NOLINE, then actually nothing happens.
Echo without arguments sends only a line feed. 0x0A. What the printer driver does with that is up to the printer driver. It probably appends a CR as well. If I recall correctly, we also had a special tweak in the driver that appends a form feed if the printer driver closes without anything being printed, for page printers only.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 25, 2019, 10:26:38 AM
Echo without arguments sends only a line feed. 0x0A.

It doesn't seem to be doing that...using PAR: below so that printer driver is out of the picture...

Code: [Select]
5.0.Workbench:> run cmd multiple notify
[CLI 1]
5.0.Workbench:> CMD redirection of parallel.device installed

5.0.Workbench:> echo >par:
5.0.Workbench:> ;No ASL comes up, this is not expected.

5.0.Workbench:> echo >par: ""
Redirected 1 bytes from parallel.device to RAM:CMD_File
5.0.Workbench:> type hex ram:CMD_file
0000: 0A                                     .                   

5.0.Workbench:> echo >par: "" NOLINE
5.0.Workbench:> ;No ASL comes up, this I assume is expected with the NOLINE option.     
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 27, 2019, 05:36:16 AM
A different observation for the CMD tool.  I'm sending the same number bytes each time but the CMD notify text is reporting an accumulation of bytes.   That is, the text says 172 bytes sent to CMD_File2 but in reality only 86 bytes were sent to that file.

Code: [Select]
5> run cmd notify multiple
[CLI 1]
5> CMD redirection of parallel.device installed

5> echo >PRT: "Test"
Redirected 86 bytes from parallel.device to RAM:CMD_File1
5> echo >PRT: "Test"
Redirected 172 bytes from parallel.device to RAM:CMD_File2
5> echo >PRT: "Test"       
Redirected 258 bytes from parallel.device to RAM:CMD_File3
5>


Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 27, 2019, 06:15:37 AM
Had a separate question on stderr redirection.   I don't think *> is implemented in 3.1.4 (or even in prior versions)?  I haven't been able to get it to work even though I have gotten it to work in 4.x. 

If for some reason DOS commands produce error it looks like these are passed together with stdout and in the case of >PRT:, these error messages get printed as text to PRT:

Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on August 27, 2019, 07:52:23 AM
@Thomas Richter

It seems that my_pc_is_amiga has scored a point!

 ;)
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 27, 2019, 04:20:06 PM
Had a separate question on stderr redirection.   I don't think *> is implemented in 3.1.4 (or even in prior versions)?  I haven't been able to get it to work even though I have gotten it to work in 4.x. 
*> is implemented on the shell side, unfortunately only few application programs use stderr to this point. The diskdoctor of 3.1.4 will print errors on *> if requested, and *> also redirects CONSOLE:

This will change for 3.2 where I touched the dos.library to redirect PrintFault() through stderr (rather than stdout) and where most application programs in C: where also modified to use stderr consistently for error output.

So in that sense, this is not a failure of the shell which prepares everything fine as it is. It is a matter of the programs not using what has been prepared for them. The situation is improving.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 28, 2019, 01:32:20 AM
@Thomas Richter

It seems that my_pc_is_amiga has scored a point!

 ;)

I've posted too many things and so not sure which one you are referring to :)
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 28, 2019, 01:39:51 AM
This will change for 3.2 where I touched the dos.library to redirect PrintFault() through stderr (rather than stdout) and where most application programs in C: where also modified to use stderr consistently for error output.

Thanks for the peak preview of 3.2 :).   If there are some changes being done for the C: programs, then there could be a slight improvement for Eval error detection...

Eval '? LFORMAT="%X*N";  this is not producing an error as it should be.  The %X is not correct and should be %X2 or some number after %x.  Instead in 3.1/3.1.4, eval prints something but doesn't make sense (*N doesn't get correctly parsed).  In 4.x, the error is produced saying in affect that LFORMAT is not in correct format.
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on August 28, 2019, 03:48:12 AM
@Thomas Richter

It seems that my_pc_is_amiga has scored a point!

 ;)

I've posted too many things and so not sure which one you are referring to :)

Thomas was awarding virtual points to any user guessing some of the new features that 3.2  brings. You guessed one: a working stderr.

And it seems you are now near another, this one is very small. ;-)

It is up to Thomas to "spill the beans".
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 28, 2019, 05:46:23 AM

Thomas was awarding virtual points to any user guessing some of the new features that 3.2  brings. You guessed one: a working stderr.

And it seems you are now near another, this one is very small. ;-)

It is up to Thomas to "spill the beans".

Mmm...AmigaGuide text search (though I don't think that one is small).   Seems like there was some kind of search in v34.6   And the other "wish" is a fix for the high res. pointer slanting on native amiga screens (and that one surely isn't an easy fix).   This has been there since 3.0...
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 28, 2019, 06:20:19 AM
Mmm...AmigaGuide text search (though I don't think that one is small). 
It is not a big one. We have a text datatype with search functionality, but did not use it since it was dependend on reaction which we did not have.

And the other "wish" is a fix for the high res. pointer slanting on native amiga screens (and that one surely isn't an easy fix).   This has been there since 3.0...
I've no idea what this means.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on August 28, 2019, 08:06:51 AM
Thomas was awarding virtual points to any user guessing some of the new features that 3.2  brings. You guessed one: a working stderr.

If pointing out well known limitations and bugs in OS 3.1(.4(.1)) count as guessing new features for 3.2, then there are plenty of "virtual points" to be earned. Thomas has himself documented the issue with lacking support for stderr rather extensively in his Shell.guide for Shell v45 on aminet - this guide, with updates for v46 and future v47, should also have come as part of OS release.

http://aminet.net/package/util/boot/ShellUpdate
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on August 28, 2019, 11:49:16 AM
  And the other "wish" is a fix for the high res. pointer slanting on native amiga screens (and that one surely isn't an easy fix).   This has been there since 3.0...

Could you please try to describe with more detail this issue you find?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 28, 2019, 03:54:51 PM
If pointing out well known limitations and bugs in OS 3.1(.4(.1)) count as guessing new features for 3.2, then there are plenty of "virtual points" to be earned. Thomas has himself documented the issue with lacking support for stderr rather extensively in his Shell.guide for Shell v45 on aminet - this guide, with updates for v46 and future v47, should also have come as part of OS release.

http://aminet.net/package/util/boot/ShellUpdate
There will be an update of this guide as well. Actually, there already is one which describes the new commands, the new arguments of old commands, and the recent and less recent changes to the shell. So yes, we're well aware of the need to document the upcoming changes 3.2 will bring, including a new SDK that is also under preparation. It is just a slow going process.
Title: Re: The Os 3.1.4 Thread
Post by: outlawal2 on August 28, 2019, 06:28:43 PM
Forgive me if this is a silly question or if this has been answered already, but will 3.2 require another new ROM or will it work with 3.1.4?
And thanks for all of your hard work!  Sometimes it doesn't appear that folks appreciate the work you are doing but I can assure you MANY of us do..

Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 28, 2019, 06:39:37 PM
Forgive me if this is a silly question or if this has been answered already, but will 3.2 require another new ROM or will it work with 3.1.4?
And thanks for all of your hard work!  Sometimes it doesn't appear that folks appreciate the work you are doing but I can assure you MANY of us do..
I don't know, as I don't have to decide. This is a management decision. At this point, the project is run in such a way that we keep all options open.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 28, 2019, 07:34:14 PM
Eval '? LFORMAT="%X*N";  this is not producing an error as it should be.  The %X is not correct and should be %X2 or some number after %x.  Instead in 3.1/3.1.4, eval prints something but doesn't make sense (*N doesn't get correctly parsed).  In 4.x, the error is produced saying in affect that LFORMAT is not in correct format.
I'm not even sure what it should print in your expectation. "*N" in quotes expands to the line feed. This is expected and desired. If you want an asterisk within quotes, you need to escape the BCPL escape character by an escape character, which is the asterisk itself.


Title: Re: The Os 3.1.4 Thread
Post by: kolla on August 28, 2019, 10:12:38 PM
Part of the "issue" here is that in this case, *N does not expand to linefeed (but ***N does).


Edit: But after a little experimenting, this looks more like confusion over what %X is and how it works - lformat "%X1*n" works as expexted, with "%X*n" %X apparently just "swallows" the * and the n, while "%X *n" (space betweem X and *) does not. What's correct behaviour here is probably debatable, but I agree that it would be best to exit with error about bad template.

So, will C:Info and C:Date get LFORMAT too? And maybe C:Assign?
Title: Re: The Os 3.1.4 Thread
Post by: kolla on August 28, 2019, 10:43:20 PM
(Delete - double post)
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 29, 2019, 02:24:53 AM
Part of the "issue" here is that in this case, *N does not expand to linefeed (but ***N does).
Huh? %X is not part of an LFORMAT template. So list just prints that, for every file found. *N is expanded to a line feed as it is in double quotes. Every line feed in backticks is replaced by a blank. Thus, `list LFORMAT="%X N"` returns the pattern "%X" repeated n times, where n is the number of files in the directory. Every %X is separated from every other %X by blanks. Of course, "eval" cannot compute anything from that, so it prints an error.

I'm not sure what is the defective part here. That looks all exactly as it should look.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 29, 2019, 04:50:03 AM
Edit: But after a little experimenting, this looks more like confusion over what %X is and how it works - lformat "%X1*n" works as expexted, with "%X*n" %X apparently just "swallows" the * and the n, while "%X *n" (space betweem X and *) does not. What's correct behaviour here is probably debatable, but I agree that it would be best to exit with error about bad template.

OS4 reports an error about a bad LFROMAT while OS3.x does not.   %X is not the correct format, it needs to be %X1, or %X2, etc. According to AmigaDOS manual, "The %X and %O options require a number of digits specification (for example %X8 gives 8 digits of hex output)."  So my expectation was to have EVAL produce an error.   
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 29, 2019, 04:51:32 AM
And thanks for all of your hard work!  Sometimes it doesn't appear that folks appreciate the work you are doing but I can assure you MANY of us do..

I copy that.   Yes, thanks for all the hard work!
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 29, 2019, 04:54:03 AM
  And the other "wish" is a fix for the high res. pointer slanting on native amiga screens (and that one surely isn't an easy fix).   This has been there since 3.0...

Could you please try to describe with more detail this issue you find?

Easier to see with pictures:

a) NTSC Hires Laced with Hires pointer (aspect ratio is messed)
b) Multiscan with Hires Pointer (pointer looks okay).
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 29, 2019, 05:44:03 AM
Is this a bug?

A different observation for the CMD tool.  I'm sending the same number bytes each time but the CMD notify text is reporting an accumulation of bytes.   That is, the text says 172 bytes sent to CMD_File2 but in reality only 86 bytes were sent to that file.

Code: [Select]
5> run cmd notify multiple
[CLI 1]
5> CMD redirection of parallel.device installed

5> echo >PRT: "Test"
Redirected 86 bytes from parallel.device to RAM:CMD_File1
5> echo >PRT: "Test"
Redirected 172 bytes from parallel.device to RAM:CMD_File2
5> echo >PRT: "Test"       
Redirected 258 bytes from parallel.device to RAM:CMD_File3
5>

Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 29, 2019, 06:19:57 AM
Going back to the SYS:Tools/InitPrinter

Code: [Select]
0000: 1B266C32 411B2664 401B266C 36441B26    .&l2A.&d@.&l6D.&   
0010: 6C316C32 65363046 1B266134 6C37344D    l1l2e60F.&a4l74M     
0020: 1B266130 520D1B26 64401B28 304E1B28    .&a0R..&d@.(0N.(     
0030: 73306231 30683271 30703073 33743075    s0b10h2q0p0s3t0u     
0040: 3132561B 2A722D34 551B2A76 31530D1B    12V.*r-4U.*v1S..     
0050: 266C3241 1B266440 1B266C36 441B266C    &l2A.&d@.&l6D.&l   
0060: 316C3265 3630461B 2661346C 37344D1B    1l2e60F.&a4l74M.     
0070: 26613052 0D1B2664 401B2830 4E1B2873    &a0R..&d@.(0N.(s     
0080: 30623130 68327130 70307333 74307531    0b10h2q0p0s3t0u1     
0090: 32561B2A 722D3455 1B2A7631 530D0D0A    2V.*r-4U.*v1S...     
00A0: 0C         

From the "open" source :) and from doing a hex dump of InitPrinter, we can see it is a just a aRIN Escape code being sent (0x1B2331):
Code: [Select]
00E0: 5052543A 00001B23 310A0000 000003F2    PRT:...#1......ò 

But wouldn't it make sense to also send a aRIS (0x1B63) beforehand so that the printer first goes back to it's defaults before changing it to the prefs value (before the aRIN)?

The HP Printer driver output (HP PCL code) for the aRIN is this and there is no PCL EscE (PCL code for reset) in there.


Code: [Select]
0000: 1B266C32 411B2664 401B266C 36441B26    .&l2A.&d@.&l6D.&     
0010: 6C316C32 65363046 1B266134 6C37344D    l1l2e60F.&a4l74M     
0020: 1B266130 520D1B26 64401B28 304E1B28    .&a0R..&d@.(0N.(     
0030: 73306231 30683271 30703073 33743075    s0b10h2q0p0s3t0u     
0040: 3132561B 2A722D34 551B2A76 31530D1B    12V.*r-4U.*v1S..

.&l2A                          USA Letter
.&d@                           Turn off underline
.&l6D                          6 lines per inch
.&l1l 2e 60F                   Perforation skip mode on, top margin 2lines, 60 text length
.&a4l74M                       Left 4 margin,right margin 74
.&a0R                          Move to row 0
.                              Carriage Return
.&d@                           Turn off underline
.(0N                           ECMA-94 Latin 1
.(s0b 10h 2q 0p 0s 3t 0u 12V   normal,10 chars/inch,Letter,Fixed,Upright,Courier,don't know ,12/72nd inch height
.*r-4U                         4 planes, cymk palette
.*v1S                          Foreground color


Title: Re: The Os 3.1.4 Thread
Post by: kolla on August 29, 2019, 06:27:06 AM
Of course, "eval" cannot compute anything from that, so it prints an error.

Well, it doesn't print any error, and that's the real bug here.

Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 29, 2019, 06:52:50 AM
Of course, "eval" cannot compute anything from that, so it prints an error.

Well, it doesn't print any error, and that's the real bug here.
Sorry, what? Eval prints an error. List does not, never did. printf() neither prints or returns an error for an unknown formatting string.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on August 29, 2019, 07:11:59 AM
Sorry, what? Eval prints an error.
OK, sure, if you say so - this "attitude of denial" is what I disliked when sending bug reports to you.
Title: Re: The Os 3.1.4 Thread
Post by: kolla on August 29, 2019, 10:56:56 AM
As my_pc_is_amiga wrote, on OS4 this makes more sense, eval gives an error.
Title: Re: The Os 3.1.4 Thread
Post by: paul1981 on August 29, 2019, 12:05:00 PM
  And the other "wish" is a fix for the high res. pointer slanting on native amiga screens (and that one surely isn't an easy fix).   This has been there since 3.0...

Could you please try to describe with more detail this issue you find?

Easier to see with pictures:

a) NTSC Hires Laced with Hires pointer (aspect ratio is messed)
b) Multiscan with Hires Pointer (pointer looks okay).

On a Hires or Hires Laced PAL/NTSC screen with a Hires pointer the pointer will not be interlaced. Is this what you mean? On a Multiscan screen you will get a Hires pointer of a double vertical resolution too (640x480 which matches the screen mode). Remember also that the aspect ratio of 640x480 is different to 640x400 which does make a difference. I believe there is a program on aminet to Lace the pointer.
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on August 29, 2019, 01:32:50 PM
  And the other "wish" is a fix for the high res. pointer slanting on native amiga screens (and that one surely isn't an easy fix).   This has been there since 3.0...

Could you please try to describe with more detail this issue you find?

Easier to see with pictures:

a) NTSC Hires Laced with Hires pointer (aspect ratio is messed)
b) Multiscan with Hires Pointer (pointer looks okay).

On a Hires or Hires Laced PAL/NTSC screen with a Hires pointer the pointer will not be interlaced. Is this what you mean? On a Multiscan screen you will get a Hires pointer of a double vertical resolution too (640x480 which matches the screen mode). Remember also that the aspect ratio of 640x480 is different to 640x400 which does make a difference. I believe there is a program on aminet to Lace the pointer.

I was thinking the exact same thing. When the screen mode proportions change, so does the mouse pointer.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 29, 2019, 05:20:03 PM
Eval '? LFORMAT="%X*N";  this is not producing an error as it should be.  The %X is not correct and should be %X2 or some number after %x.  Instead in 3.1/3.1.4, eval prints something but doesn't make sense (*N doesn't get correctly parsed).  In 4.x, the error is produced saying in affect that LFORMAT is not in correct format.
Well, I checked. *N does get parsed correctly. Also, Eval doesn't do anything wrong, it just uses VFWritef of the dos.library. The dos.library however just swallows the character following the %X, and ignores it if it is not in range. Actually, as part of the tripos library, it not only accepts hex digits there, but anything. So the character 'G' would mean 16. I'm not sure whether anything depends on this, but it should reject (or at least skip over) things that are below '0', larger than '9' and below 'A', and anything above 'Z'.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 30, 2019, 05:31:33 AM
So the character 'G' would mean 16. I'm not sure whether anything depends on this, but it should reject (or at least skip over) things that are below '0', larger than '9' and below 'A', and anything above 'Z'.

Interesting...I did not know that the "number" after the %X is suppose to be "hex" -ish.   From a user-perspective who does not know the internal working this is kind of confusing.   

eval '? LFORMAT "%X*N"    --> seems like this should throw an error like OS4.
eval '? LFORMAT "%X0*N"  --> outputs same as "%X1*N".    Seems like "%X0" should be thrown out as anything valid (i.e. error) since 0 does not make sense as a qualifier anyways and it is producing single digit output.

For 'G' to 'Z', these are not real hex numbers in the normal sense though these are "nice' to have so that longer number strings are possible.  So not sure what to say there...

Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on August 30, 2019, 05:40:16 AM
Quote from: paul1981 link=topic=73661.msg844992#msg844992

On a Hires or Hires Laced PAL/NTSC screen with a Hires pointer the pointer will not be interlaced. Is this what you mean? On a Multiscan screen you will get a Hires pointer of a double vertical resolution too (640x480 which matches the screen mode). Remember also that the aspect ratio of 640x480 is different to 640x400 which does make a difference. I believe there is a program on aminet to Lace the pointer.

Not sure if related to pointer interlace or not but that sounds like the issue or the affect that is happening.  On a hires screen (no interlace), why would the pointer need to laced? I can kind of understand it for hires interlace but not hires.   

The "http://aminet.net/package/util/misc/LacePointer" only works for lores pointer mode.   LoRes pointer mode does not seem to have any strange affects in the aspect ratio from what I recall or seen recently in other screenmodes...I haven't check thoroughly though.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on August 30, 2019, 05:43:53 AM
Interesting...I did not know that the "number" after the %X is suppose to be "hex" -ish.   From a user-perspective who does not know the internal working this is kind of confusing.   

eval '? LFORMAT "%X*N"    --> seems like this should throw an error like OS4.
eval '? LFORMAT "%X0*N"  --> outputs same as "%X1*N".    Seems like "%X0" should be thrown out as anything valid (i.e. error) since 0 does not make sense as a qualifier anyways and it is producing single digit output.

For 'G' to 'Z', these are not real hex numbers in the normal sense though these are "nice' to have so that longer number strings are possible.  So not sure what to say there...
Eval does not attempt to validate the formatting pattern. It just uses them to do the formatting by the dos.library. That the pattern looks so strange is part of the BCPL legacy. Actually, the whole rule that the digit or number after the X is the field width comes from BCPL, and that letters A to Z are valid there also comes from BCPL. It's part of the syntax defined by the language.
Title: Re: The Os 3.1.4 Thread
Post by: paul1981 on August 30, 2019, 09:35:18 PM

Not sure if related to pointer interlace or not but that sounds like the issue or the affect that is happening.  On a hires screen (no interlace), why would the pointer need to laced? I can kind of understand it for hires interlace but not hires.   

The "http://aminet.net/package/util/misc/LacePointer" only works for lores pointer mode.   LoRes pointer mode does not seem to have any strange affects in the aspect ratio from what I recall or seen recently in other screenmodes...I haven't check thoroughly though.

I was just stating that the pointer on a Hires PAL or NTSC screen will not be interlaced even if in an interlaced mode. I suppose Commodore chose this behaviour because an interlaced pointer would drive the user crazy without a flicker fixer (only minority of users had these)...who knows?! That's my best guess.

Interestingly though, when this happens and the user is using a Hires pointer on a Hires Laced screen, obviously the pointer accuracy is only at half vertical resolution because it's not laced...but this isn't quite true. I just tested it with the multiple selection (hold left mouse down to select icons) and you do get the full vertical resolution accuracy in reality, but the pointer only updates it's vertical position on every 2nd row (it can't do any other as it's not laced). If you use the keyboard controls to move the mouse you can clearly see this behaviour - a movement left or right is one keypress at a time per pixel, but for the vertical direction it takes two keypresses to move the mouse pointer that you see, but Workbench does 'see' that bit inbetween that it couldn't show with the pointer so the mouse does actually run at full laced resolution. I think there should be an option to lace the pointer in interlaced screenmodes via Pointer Prefs. I haven't tested A multiscan interlaced screen, but I'd bet that the pointer would not be laced either.
Title: Re: The Os 3.1.4 Thread
Post by: trekiej on August 31, 2019, 01:19:09 AM
My A2000 has a 68000 in it.
Would 3.1.4 have to make a Look Up Table for Floating Point Operations?
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on September 02, 2019, 06:11:54 AM
I haven't heard if this one was reproducible?

A different observation for the CMD tool.  I'm sending the same number bytes each time but the CMD notify text is reporting an accumulation of bytes.   That is, the text says 172 bytes sent to CMD_File2 but in reality only 86 bytes were sent to that file.

Code: [Select]
5> run cmd notify multiple
[CLI 1]
5> CMD redirection of parallel.device installed

5> echo >PRT: "Test"
Redirected 86 bytes from parallel.device to RAM:CMD_File1
5> echo >PRT: "Test"
Redirected 172 bytes from parallel.device to RAM:CMD_File2
5> echo >PRT: "Test"       
Redirected 258 bytes from parallel.device to RAM:CMD_File3
5>


Also, what is correct behavior of CMD when using ASL.  I'm seeing this behavior:
1) Launch CMD (without "FILE" specified) and can set MULTIPLE=FALSE.
2) echo >prt: "Test" in shell.
3) ASL comes up and hit cancel.
4) Wait for some time and requester comes up saying "Check Printer"
5) Hit cancel in requester and this hit comes.

"Capture.txt" --> first capture.
"Capture2.txt" --> 2nd capture after I did a reboot.

Would it make sense that cancel in ASL just cancels entire redirection and also cancel anything going to PRT:?
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on September 02, 2019, 07:07:33 AM
ED in 3.1.4 when executed from an existing shell does not open a new console window.  Instead it is using the existing one. 

What I'm finding though is that if I am in a serial terminal shell then I am getting this hit.

1) On Amiga host do the following in the shell:
a) mount AUX:
b) newshell AUX:

2) On serial terminal on remote computer do the following:
ed t:new

3) Hit happens as attached.

Older version of ED will open up new console window on host and no hit.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 02, 2019, 07:28:56 PM
I beiieve I found this one. It is a bit hairy and hard to reproduce. The trouble is that CMD apparently used the output buffer of the asl requester to construct
a new unique file name for multiple redirection.

Would it make sense that cancel in ASL just cancels entire redirection and also cancel anything going to PRT:?

Hmm. The question is what "cancel" means for you. I suppose it means "cancel the redirection".
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 02, 2019, 07:30:35 PM
ED in 3.1.4 when executed from an existing shell does not open a new console window.  Instead it is using the existing one. 
Yes. This is intentional.

What I'm finding though is that if I am in a serial terminal shell then I am getting this hit.
Thanks, this was easy to find and fix. Got it covered. Looks like an old bug to me.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on September 02, 2019, 08:59:10 PM
I beiieve I found this one. It is a bit hairy and hard to reproduce. The trouble is that CMD apparently used the output buffer of the asl requester to construct
a new unique file name for multiple redirection.

Would it make sense that cancel in ASL just cancels entire redirection and also cancel anything going to PRT:?

Hmm. The question is what "cancel" means for you. I suppose it means "cancel the redirection".


Thanks -- in this test case I used single redirection but I guess it is same issue. 

For me cancel would mean to cancel the entire "job" to PRT: and not send anything but "cancel redirection" alone would be okay.   This is more of a documentation or FAQ thing so that the user can be aware.

How about the the print output of the CMD "Redirected 172 bytes from parallel.device to RAM:CMD_File2" when this is only suppose to be 86 bytes?
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on September 02, 2019, 09:03:04 PM
ED in 3.1.4 when executed from an existing shell does not open a new console window.  Instead it is using the existing one. 
Yes. This is intentional.

Cool -- does this mean that ED can work in serial terminal mode (i.e. no menus)?

Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 02, 2019, 09:10:32 PM
Cool -- does this mean that ED can work in serial terminal mode (i.e. no menus)?
That is the idea, yes.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on September 02, 2019, 09:22:49 PM
The SYS:System/Intellifont behavior has changed a little in 3.1.4.  When starting-up it is actually scanning all of my volume's first level directories for fonts and not just the FONTS: assign and so it is taking some time now to start up.   Also, the cycle gadget now contains the complete path instead of the text "Fonts: Path Component #1" This is okay except the path text is not fitting in the cycle gadget and so the text goes onto other portions of the GUI.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 02, 2019, 09:30:07 PM
The SYS:System/Intellifont behavior has changed a little in 3.1.4.  When starting-up it is actually scanning all of my volume's first level directories for fonts and not just the FONTS: assign and so it is taking some time now to start up.   
Actually, this did NOT change. Intellifont always scanned all inserted volumes for fonts.
Title: Re: The Os 3.1.4 Thread
Post by: Matt_H on September 03, 2019, 04:50:48 AM
Also, the cycle gadget now contains the complete path instead of the text "Fonts: Path Component #1" This is okay except the path text is not fitting in the cycle gadget and so the text goes onto other portions of the GUI.
I can replicate this issue. Given that the path is listed in the string gadget just above, listing it again in the cycle gadget is unnecessary. Not sure if listing it a second time is a bug or a feature, but I think the old behavior from 3.1 is better.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on September 03, 2019, 04:57:23 AM
I ran SnoopDos and do see a difference in the 3.1.4 version and found out there is a NODISKSCAN flag that is not there in 3.1.   When I run with this option, then I see same scanning behavior as 3.1. 

If the new diskscan option is suppose to show all Intellifont directories besides the FONTS: assign, then it isn't doing that.  Only the FONTS: assign shows up in the cycle gadget for me.

A separate thing is in regards to the cycle gadget in the 3.1.4 version.  The cycle gadget in 3.1 shows "Not in Fonts: Path" when adding a path with the file folder gadget when that is not in the FONTS: path.  This is not happening with 3.1.4 -- i.e. there is no text like that.

The SYS:System/Intellifont behavior has changed a little in 3.1.4.  When starting-up it is actually scanning all of my volume's first level directories for fonts and not just the FONTS: assign and so it is taking some time now to start up.   
Actually, this did NOT change. Intellifont always scanned all inserted volumes for fonts.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on September 03, 2019, 04:59:39 AM
Cool -- does this mean that ED can work in serial terminal mode (i.e. no menus)?
That is the idea, yes.

Nice!
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 03, 2019, 07:54:39 AM
I ran SnoopDos and do see a difference in the 3.1.4 version and found out there is a NODISKSCAN flag that is not there in 3.1.   When I run with this option, then I see same scanning behavior as 3.1. 
No, you see a *different* behaivour than 3.1. Once again, I did not invent the code to scan all devices. That's in the code since ever.
Title: Re: The Os 3.1.4 Thread
Post by: Matt_H on September 03, 2019, 01:47:28 PM
A separate thing is in regards to the cycle gadget in the 3.1.4 version.  The cycle gadget in 3.1 shows "Not in Fonts: Path" when adding a path with the file folder gadget when that is not in the FONTS: path.  This is not happening with 3.1.4 -- i.e. there is no text like that.

I can replicate this as well. Definitely starting to look like a bug was accidentally introduced in the cycle gadget.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 03, 2019, 06:59:55 PM
I can replicate this as well. Definitely starting to look like a bug was accidentally introduced in the cycle gadget.
The 3.1 version just printed that the directory was in component #n of the path, which was not very useful at all. (How do you count that and why is this
useful information?) 3.1.4 prints the full font path. I now added a code to check for paths that are too long. In that case, the name is now abbreviated.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on September 03, 2019, 08:46:56 PM
Thanks!  The bigger thing is that that there is no way to add another font path to the cycle gadget list.   In 3.1, you could add a path and that would show up in the cycle gadget list.   This is not happening anymore.   

Side point -- getting the Intellifont template with the 3.1 version in the shell shows 1 option only, VALIDATE/S. In 3.1.4 it is VALIDATE/S, NODISKSCAN/S

I can replicate this as well. Definitely starting to look like a bug was accidentally introduced in the cycle gadget.
The 3.1 version just printed that the directory was in component #n of the path, which was not very useful at all. (How do you count that and why is this
useful information?) 3.1.4 prints the full font path. I now added a code to check for paths that are too long. In that case, the name is now abbreviated.
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on September 03, 2019, 11:23:20 PM
Side point -- getting the Intellifont template with the 3.1 version in the shell shows 1 option only, VALIDATE/S. In 3.1.4 it is VALIDATE/S, NODISKSCAN/S

NODISKSCAN
Disables the initial automatic disk scan.
Title: Re: The Os 3.1.4 Thread
Post by: Matt_H on September 04, 2019, 04:24:47 PM
Side point -- getting the Intellifont template with the 3.1 version in the shell shows 1 option only, VALIDATE/S. In 3.1.4 it is VALIDATE/S, NODISKSCAN/S

NODISKSCAN
Disables the initial automatic disk scan.

The corresponding tooltype should be added to the icon in the 3.2 release as well.
Title: Re: The Os 3.1.4 Thread
Post by: Matt_H on September 04, 2019, 05:16:09 PM
I can replicate this as well. Definitely starting to look like a bug was accidentally introduced in the cycle gadget.
The 3.1 version just printed that the directory was in component #n of the path, which was not very useful at all. (How do you count that and why is this useful information?)
It's not useful on its own, but in conjunction with the path listed in the textfield gadget just above I think it makes sense.
Quote
3.1.4 prints the full font path.
Not necessary, in my opinion, as per above.
Quote
I now added a code to check for paths that are too long. In that case, the name is now abbreviated.
Thanks, that'll help, but I still think the cycle gadget is displaying redundant information.

Perhaps some screenshots will make it easier to explain.

Here's 3.1:
3.1_1.png: A just-started Intellifont under 3.1. Workbench:Fonts (path gadget) is recognized as the first component of Fonts: (cycle gadget).
3.1_2.png: I've clicked the cycle gadget. Path gadget changes to Work:PageStream/SoftLogik/Fonts and the cycle gadget changes to acknowledge it's the second component of my Fonts: path.
3.1_3.png: I've typed Work: into the path gadget, and the cycle gadget helpfully informs me that it's not part of the Fonts: path.
3.1_4.png: I've typed a nonsense path into the path gadget and the cycle gadget informs me it's not valid.

And here's 3.1.4:
3.1.4_1.png: A just-started Intellifont under 3.1.4. Workbench:Fonts (path gadget) is repeated in the cycle gadget.
3.1.4_2.png: I've clicked the cycle gadget. Path gadget changes to Work:PageStream/SoftLogik/Fonts and so does the cycle gadget. I don't see a reason to print this information twice.
3.1.4_3.png: I've typed Work: into the path gadget but the cycle gadget changes to Work:PageStream/SoftLogik/Fonts again. I have no way of knowing whether I've selected my intended Fonts: component (e.g., if I mistyped the path or selected the wrong directory from the ASL requester).
3.1.4_4.png: I've typed a nonsense path into the path gadget. Same behavior as 3.1.4_3.png.


Meanwhile, I can confirm my_pc_is_my_amiga's account that something is different in the startup scanning behavior. I think Intellifont always scanned DF0: (and root directories of other volumes?), but now it's scanning root and first-level directories across my whole hard drive as well. Is that the intended behavior or is that a bug?
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on September 05, 2019, 04:00:07 AM
Thanks Matt_H for taking the screenshots -- those are very good!   What screen grab program are you using?
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 05, 2019, 07:37:56 PM
It's not useful on its own, but in conjunction with the path listed in the textfield gadget just above I think it makes sense.
For that, you must have first selected the cycle gadget, which is not necessarily the case, e.g. with CycleToMenus.

Thanks, that'll help, but I still think the cycle gadget is displaying redundant information.
Sorry, I don't agree. It was displaying useless information. How is the font path enumeration relevant to the function of the program? How do you know which font path element corresponds to which directory without selecting it?

3.1_3.png: I've typed Work: into the path gadget, and the cycle gadget helpfully informs me that it's not part of the Fonts: path.
3.1_4.png: I've typed a nonsense path into the path gadget and the cycle gadget informs me it's not valid.
How is it useful to install fonts into something that is not part of the font path? The program should rather go back to one of the font paths if an invalid font is selected.

3.1.4_2.png: I've clicked the cycle gadget. Path gadget changes to Work:PageStream/SoftLogik/Fonts and so does the cycle gadget. I don't see a reason to print this information twice.
Because it allows a quick access if you have CycleToMenu installed. The font path enumeration is useless as information to the user.


3.1.4_3.png: I've typed Work: into the path gadget but the cycle gadget changes to Work:PageStream/SoftLogik/Fonts again. I have no way of knowing whether I've selected my intended Fonts: component (e.g., if I mistyped the path or selected the wrong directory from the ASL requester).
The program should indeed refuse this input and revert the gadget to one of the available paths.

Meanwhile, I can confirm my_pc_is_my_amiga's account that something is different in the startup scanning behavior. I think Intellifont always scanned DF0: (and root directories of other volumes?), but now it's scanning root and first-level directories across my whole hard drive as well. Is that the intended behavior or is that a bug?
That is intended, of course. It should scan all media, not just some media. It is getting even weirder - depending on the file system of the media, it scanned in different formats.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on September 06, 2019, 01:12:20 AM
That is intended, of course. It should scan all media, not just some media. It is getting even weirder - depending on the file system of the media, it scanned in different formats.

But valid font directories that are not in the FONTS: assign are not showing up in the cycle list.
Title: Re: The Os 3.1.4 Thread
Post by: Steady on September 06, 2019, 01:25:22 AM
3.1_3.png: I've typed Work: into the path gadget, and the cycle gadget helpfully informs me that it's not part of the Fonts: path.
3.1_4.png: I've typed a nonsense path into the path gadget and the cycle gadget informs me it's not valid.
How is it useful to install fonts into something that is not part of the font path? The program should rather go back to one of the font paths if an invalid font is selected.


Perhaps it will help if the string gadget is also changed to reflect the same valid font path with some text in highlight pen stating that an invalid path was selected. Obviously some room would need to be added for that.
Title: Re: The Os 3.1.4 Thread
Post by: Matt_H on September 06, 2019, 03:36:20 AM
Thomas, thanks for your answers. Some additional thoughts:

It's not useful on its own, but in conjunction with the path listed in the textfield gadget just above I think it makes sense.
For that, you must have first selected the cycle gadget, which is not necessarily the case, e.g. with CycleToMenus.
Aha! There's the issue: the UI design you're suggesting makes sense with CycleToMenu, but not without it. Maybe it's time to start bundling that commodity with the OS? Or building the functionality into GadTools?

Quote
Thanks, that'll help, but I still think the cycle gadget is displaying redundant information.
Sorry, I don't agree. It was displaying useless information. How is the font path enumeration relevant to the function of the program? How do you know which font path element corresponds to which directory without selecting it?
I looked at the successor program in OS4, TypeManager, and its cycle gadget does both, e.g., "#1: Workbench:Fonts", "#2: Work:PageStream/SoftLogik/Fonts", plus a "Not in Fonts: path" option. Maybe that's the approach to follow.

Quote
3.1_3.png: I've typed Work: into the path gadget, and the cycle gadget helpfully informs me that it's not part of the Fonts: path.
3.1_4.png: I've typed a nonsense path into the path gadget and the cycle gadget informs me it's not valid.
How is it useful to install fonts into something that is not part of the font path? The program should rather go back to one of the font paths if an invalid font is selected.
I could envision a scenario where someone would want to install some fonts in the directory of a word processor or DTP program but not have them be part of the system Fonts: path, so the option to select a non-path directory should remain.

Quote
3.1.4_2.png: I've clicked the cycle gadget. Path gadget changes to Work:PageStream/SoftLogik/Fonts and so does the cycle gadget. I don't see a reason to print this information twice.
Because it allows a quick access if you have CycleToMenu installed. The font path enumeration is useless as information to the user.
I understand the reasoning now. See above re: CycleToMenu.

Quote
3.1.4_3.png: I've typed Work: into the path gadget but the cycle gadget changes to Work:PageStream/SoftLogik/Fonts again. I have no way of knowing whether I've selected my intended Fonts: component (e.g., if I mistyped the path or selected the wrong directory from the ASL requester).
The program should indeed refuse this input and revert the gadget to one of the available paths.
I think the 3.1/OS4 behavior is better, e.g., notifying the user that it's not in the path, in case that's the user's intent like in the word processing/DTP scenario I mentioned. If the entered directory itself is invalid there needs to be some way of alerting the user that something is wrong (to replace the behavior shown in 3.1_4.png) - simply reverting to a path component makes it look like a bug. If you don't want to print an error in the cycle gadget, maybe pair the revert with a beep/screen flash?

I'm finding what I think are additional bugs in the current 3.1.4 version as well. After a non-path directory is entered and the cycle gadget is clicked again, the cycle and path gadgets get out of sync, so it's not clear where the newly installed fonts will end up.

Quote
Meanwhile, I can confirm my_pc_is_my_amiga's account that something is different in the startup scanning behavior. I think Intellifont always scanned DF0: (and root directories of other volumes?), but now it's scanning root and first-level directories across my whole hard drive as well. Is that the intended behavior or is that a bug?
That is intended, of course. It should scan all media, not just some media. It is getting even weirder - depending on the file system of the media, it scanned in different formats.
Interesting. I'm not quite sure I understand the rationale, but I've got the NODISKSCAN option so I'm happy. :)


Title: Re: The Os 3.1.4 Thread
Post by: kolla on September 06, 2019, 07:28:48 AM
e.g. with CycleToMenus.

with what?

http://aminet.net/search?query=CycleToMenus

"Found 0 matching package(s)"

What are you talking about?
Title: Re: The Os 3.1.4 Thread
Post by: nbache on September 06, 2019, 08:13:31 AM
Try the singular: CycleToMenu

Best regards,

Niels
Title: Re: The Os 3.1.4 Thread
Post by: kolla on September 06, 2019, 08:38:51 AM
Try the singular: CycleToMenu

Thanks!

If this functionality is so important that it affects OS development, then it should probably be incorporated.
Title: Re: The Os 3.1.4 Thread
Post by: bubbob42 on September 07, 2019, 01:54:21 PM
Try the singular: CycleToMenu

If this functionality is so important that it affects OS development, then it should probably be incorporated.

It’s been on the list already, but don’t moan if it doesn’t make it into next release, ok? :)
Title: Re: The Os 3.1.4 Thread
Post by: kolla on September 08, 2019, 01:37:42 AM
It’s been on the list already, but don’t moan if it doesn’t make it into next release, ok? :)
I will only moan when it comes into the OS, but isn't possible to turn off.

Like the requesters of OS 3.1.4. They pop up with "Cancel" right under the mouse button... I never had any issue with requesters on Amiga, but now I find myself pressing "Cancel" by accident without even having had a chance to read what the requester was about. No way to turn _that_ damn "feature" off? I want the requesters to pop up like they used to - in the upper left corner, far away from where I am working, thank you very much!
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on September 08, 2019, 07:15:27 AM
No way to turn _that_ damn "feature" off? I want the requesters to pop up like they used to - in the upper left corner, far away from where I am working, thank you very much!

Have your tried the ASL prefs program to change position and then used the "Override application" option?
Title: Re: The Os 3.1.4 Thread
Post by: kolla on September 08, 2019, 10:54:45 AM
No way to turn _that_ damn "feature" off? I want the requesters to pop up like they used to - in the upper left corner, far away from where I am working, thank you very much!
Have your tried the ASL prefs program to change position and then used the "Override application" option?
Turned out to not be related to OS 3.1.4, it was a third party commodity that did more than what documentation said it would.
So, my my apologies for moaning - on "naked" OS 3.1.4, requesters work as normal.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on September 09, 2019, 12:22:42 AM
1) FixFonts

a) Executing FixFonts from workbench does not give the user any DOS error message and doesn't show that it completed properly.  From the shell it does give DOS error but it is not too informative as to what file is causing the problem.   This is just an example below.  I actually had a #?.font file that was write protected but had to search it as I did not know which one.

>protect FONTS:emerald.font -w
>FixFonts
FixFonts failed: file is write protected  (Shell gives this


2) If I send this to Postscript printer
echo >PRT: "TEST" NOLINE

Then nothing gets printed.  I'm attaching the CMD output.

With echo >PRT: "TEST", it prints okay (it looks like it needs a LF/CR).  Is this a bug?
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on September 09, 2019, 05:43:00 AM
I have this in my shell-startup to set the background to black and foreground text to white. 

Code: [Select]
echo "*e[>1m*e[32;41m*e[0;0H*e[J"
prompt "*n*e[>1m*e[33;41m*e[1m%N.%R.*e[30;41m%S>*e[0m*e[32;41m "
alias CLS "echo *"*E[0;0H*E[J*""

With more and Ed in the same console window, this is not always working.  More when hitting space to next page starts to put background in grey.  Ed does not put text to white.  Is there a way to have this work?

Title: Re: The Os 3.1.4 Thread
Post by: kolla on September 09, 2019, 07:34:44 AM
Is there a way to have this work?
Only way to have it work reliably, is to use a console replacement that features its own palette settings. One alternative is ViNCEd - http://aminet.net/package/util/shell/ViNCEd (note that this version is old, but newer versions are only included in OS 3.9, various boingbags and BestWB, with copyright Amiga Inc. - not as a single archive. Note also that these ViNCEd versions come with their own version of More which installs to S:, which is a script that work around an issue with original CBM More - this work-around is not needed with the More of OS 3.1.4 anymore, from what I understand... an updated VINCEd that get rid of confusing copyright notices and more "streamlined" installation for OS 3.1.4 owners would probably be a good idea)
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 09, 2019, 08:37:51 PM
1) FixFonts
I added this to the bug tracker. It's pretty minor at this point.

2) If I send this to Postscript printer
echo >PRT: "TEST" NOLINE

Then nothing gets printed.  I'm attaching the CMD output.

With echo >PRT: "TEST", it prints okay (it looks like it needs a LF/CR).  Is this a bug?
No, a disagreement of how AmigaOs considers printers to work, and how postscript printers do work in reality. As I already explained, AmigaOs assumes a line printer, so every character is printed immediately, then the print head is moved. Or it is moved according to the control characters. Unfortunately, postscript doesn't work like that. It is a page printer system, so sequences like TAB or backspace do not work as they would work under assumption of AmigaOs.

What the postscript driver does is that it cheats. It keeps instead a line buffer, then when the Amiga transmits a control character like "backspace", it erases the last character in the line buffer, moves the "virtual print head" back, and then inserts the next character to be printed on top of it.

The line buffer is then printed on the next LF/CR.

So this is all to make the usual ASCII control sequences work "approximately correct" even if postscript does not work like that.

Of course, if the line feed never comes, the buffered line is never printed.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on September 10, 2019, 05:50:05 AM
1) FixFonts
I added this to the bug tracker. It's pretty minor at this point.

Yeah -- definitely a minor issue.  Thanks for adding it to the bug tracker.   Do you have any more comments on the Intellifont?   The larger concern IMO is that I can't tell if any non-FONTS: path can be added to cycle gadget.   From the auto disk scan it doesn't seem to be adding and if I do it manually with File Folder gadget I can't tell.
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 10, 2019, 12:52:34 PM
Do you have any more comments on the Intellifont?   The larger concern IMO is that I can't tell if any non-FONTS: path can be added to cycle gadget.   From the auto disk scan it doesn't seem to be adding and if I do it manually with File Folder gadget I can't tell.
Well, I added this back mostly on the basis of "it has always been like that", but quite frankly, I don't get the use-case. Actually, I think it is potentially dangerous for the common user as this type of installation is allowed, but would mostly result in non-working fonts. What also happened is that intellifont became fully localizable (so there is a catalog now).
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on September 10, 2019, 03:28:21 PM
Well, I added this back mostly on the basis of "it has always been like that", but quite frankly, I don't get the use-case. Actually, I think it is potentially dangerous for the common user as this type of installation is allowed, but would mostly result in non-working fonts.

I'm actually still confused over the purpose of the initial first level dir. disk scan then.  What was Intellifont doing with the scan information if not adding to the installation paths for the cycle gadget? It sounds like you added that back in now but is there something else that Intellifont is doing with that information.

Would like to understand more of why the fonts would be non-working for a non-assigned FONTS: path.

Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 10, 2019, 04:32:15 PM
I'm actually still confused over the purpose of the initial first level dir. disk scan then.  What was Intellifont doing with the scan information if not adding to the installation paths for the cycle gadget?
The same it ever did. Scanning for fonts. Whatever fonts were found and not in the system appear on the left hand side for installation. Since all your fonts are already installed, it does not find any new, so the left hand remains empty for you. That was the original purpose of Intellfont - original name "Fountain" - to be a source of fonts. Thus, you can insert a font disk in any drive, click on Intellifont, and there you go.

Would like to understand more of why the fonts would be non-working for a non-assigned FONTS: path.
Well, simply because diskfont does not look for fonts there. So if I put a font outside of FONTS:, the system ASL requester does not show them.
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on September 11, 2019, 05:51:47 AM
Thus, you can insert a font disk in any drive, click on Intellifont, and there you go.

Thanks -- I somehow got totally confused but now it is making sense (I wasn't thinking about Source files for the disk scan at all).   This is very nice -- I tired it just now with a font disk in DF0: and it found 2 fonts that was missing from my FONTS:.   It compares what is already installed versus what was installed and listed in the source pane, 2 missing out of 3 in DF0: -- nice! I tried the older version of Intellifont and it only showed 1 out out 3 even though I had 2 missing.  So it seems to be better there.

A few feedbacks:

It scans the RAD: disk but does not scan RAM: disk.   Only reason for a RAM: disk scan would be if I had found a bunch of fonts to install and put them in RAM (like from Aminet)

For the left side pane, would be nice to have some kind of cycle gadget as well.  Maybe 1 cycle for the listing of the disk scan and a way to add to the cycle gadget list with the file folder.  For example, if I had decided to insert a CD-ROM  after launching the program, I could add some fonts to install but could still go back to the disk scan list as well. The way it works now is the "disk scan" list gets removed with whatever is put in by the user by the file folder icon.   

One other thing I noticed is if I do a manual source add to DF0: then it doesn't scan the 1st level directories.  I have to go to the specific font dir. one by one. 
Title: Re: The Os 3.1.4 Thread
Post by: kolla on September 11, 2019, 10:40:59 AM
What happens to "Fonts:" when you insert a disk labeled "Fonts"? Where does "Fonts:" take you? :)
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 11, 2019, 05:08:38 PM
What happens to "Fonts:" when you insert a disk labeled "Fonts"?
Nothing. The fonts target is only computed from DLT_DIRECTORY entries in the DosList. As far as ASL or DiskFont is concerned: They don't mind whether the volume is FONTS: or FONTS: is an assign. Which is also the reason why the install disks are named Fonts and Locale (and not Fonts3.1.4 and Locale3.1.4).
Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 11, 2019, 05:19:25 PM
So it seems to be better there.
For some reason, it only scanned disks if the disk was handled by the trackdisk.device. Which today makes little sense as you probably want to install fonts from CD, a USB thumbdrive and so on...

It scans the RAD: disk but does not scan RAM: disk.
That's right. It only scans devices that have a "startup vector" and hence are usually handled by some sort of file system. RAM: does not fall into this scheme, even though it is a file system by its own. Why that decision was made is unclear to me. This is legacy code.

One other thing I noticed is if I do a manual source add to DF0: then it doesn't scan the 1st level directories.  I have to go to the specific font dir. one by one.
That's correct. This is due to the format on which such "font add-on disks" where supposed to be delivered. You can read a bit more on this in the in-program help (press "HELP", then click on all the buttons - probably try the source button). There are two types of "font add-on disks" supported: The Amiga "font library disks", and so called PC "FAIS" disks. Foramts are a tiny bit different, and intellifont has scanning support for both of them. They had fonts in particular directories the program would find, and only such directories or places are scanned.

From the way how the code looks, I would say that this is essentially an Agfa program that was originally developped for PC, and then ported over to Amiga (with more or less success), taking the concepts of the PC workflow with it. The same also applies to the "bullet.library" which is actually an Agfa (compugraphic) library that was (rather poorly) ported to Amiga, and then, with lots of effort, fixed by Olaf.

For example, the bullet library in its original (3.1) incarnation was not even a proper library. Only one program could use it at a time. If more than two fonts were supposed to be created at the same time, they would both use the same global space in the library, overwriting each others data. As said, Olaf fixed this for 3.9, and it was a little polished for 3.1.4.
Title: Re: The Os 3.1.4 Thread
Post by: utri007 on September 12, 2019, 08:15:48 PM
What about if I just want to burn eprom, but not install OS3.1.4 update. Files on update floppy doens't seem to be ready modules?
Title: Re: The Os 3.1.4 Thread
Post by: Gulliver on September 13, 2019, 07:45:33 PM
What about if I just want to burn eprom, but not install OS3.1.4 update. Files on update floppy doens't seem to be ready modules?

Please refer to section 9.3 of the AmigaOS 3.1.4 FAQ.

http://aminet.net/docs/help/AmigaOS_3.1.4-FAQ.txt
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on September 14, 2019, 04:59:57 AM
From the way how the code looks, I would say that this is essentially an Agfa program that was originally developped for PC, and then ported over to Amiga (with more or less success), taking the concepts of the PC workflow with it. The same also applies to the "bullet.library" which is actually an Agfa (compugraphic) library that was (rather poorly) ported to Amiga, and then, with lots of effort, fixed by Olaf.

As always, thanks for the insights!
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on September 14, 2019, 05:10:16 AM
Did this make it into the bug tracker?

A different observation for the CMD tool.  I'm sending the same number bytes each time but the CMD notify text is reporting an accumulation of bytes.   That is, the text says 172 bytes sent to CMD_File2 but in reality only 86 bytes were sent to that file.

Code: [Select]
5> run cmd notify multiple
[CLI 1]
5> CMD redirection of parallel.device installed

5> echo >PRT: "Test"
Redirected 86 bytes from parallel.device to RAM:CMD_File1
5> echo >PRT: "Test"
Redirected 172 bytes from parallel.device to RAM:CMD_File2
5> echo >PRT: "Test"       
Redirected 258 bytes from parallel.device to RAM:CMD_File3
5>

Title: Re: The Os 3.1.4 Thread
Post by: Thomas Richter on September 14, 2019, 08:26:15 PM
Did this make it into the bug tracker?
No, simply on the basis that it is fixed already. (-:
Title: Re: The Os 3.1.4 Thread
Post by: my_pc_is_amiga on September 15, 2019, 12:34:27 AM
Any comment on an aRIN sequence where aRIN sends a reset  plus init sequence.  As it is now, it is possible that the printer could have some configuration set that does not get set back to the original prefs by init alone.  Init only sets mostly prefs but if user changes something outside of prefs then that printer code does not go back to default with aRIN alone