Os 3.2 development preview

[kolla]

@rxxic:

Well, don't throw away your OS3.9 CD just yet; not every tool will be as feature-complete as H&P's equivalents, so some components from OS3.2 will be better to be overwritten with OS3.9 components.

Such as?

The only components I would perhaps wish to bring from OS3.9, from the top of my head...

* SYS:System/Find - only requires one or two Reaction classes that I presume are now part of OS3.2
* RAWBInfo - same as Find, only requires classes that I presume are now part of OS 3.2
* Unarc - also requires resource.library, which I presume would need to be brought from OS 3.9
* "Ghostbuster" edition of SYS:Prefs/Workbench that allows one to hide NDOS/"Uninitialized" (sic) volumes from Workbench.

Anything else?

[kolla]

- Have the possibility to change the icon type in the WBInfo window. e.g., from "Project" to "Tool". Actually the RAWBInfo is really useful!

Frankly, the info window should not replace an icon editor.

Oh please... that is not an argument 

The info window has always been an editor, where you...
* edit stack size
* edit priority
* edit tooltypes
* edit default tool
* edit comments
* edit file system flags
* edit icons graphics by drag&drop

I don't think it is too much to ask for...
* edit type of icon (tool/drawer/project/disk)

[kolla]

I don't think it is too much to ask for...
* edit type of icon (tool/drawer/project/disk)

It is too much to ask. Changing this will break the application whose icon you edit, or will create strange results.

As will editing stack size, tooltypes, setting a different default tool, changing file system flags...

Well, long live RAWBInfo, SwazInfo and other similarly buggy patches then.

[kolla]

No. I don't care, I don't mind. If the FPGA bit in ExecBase is set, it will print that information. That's it. It is not the job of exec or CPU to set it, and it means whatever the folks that set it make to mean it. I was suggesting an API to get additional details on the CPU, but this proposal was put down, so we have one flag that means "FPGA". We are running low of exec->AttnFlags anyhow, so we cannot spend more than a bit on it.

Cool, I will then request for this flag to be supported by the other 68k cores running on FPGAs - what could possibly break

[kolla]

Other FPGA are not improving the Amiga CPU or the Chipsets’ their aim are more into preservation and so accuracy. Knowing that they should be treated like any other Amigas no?

What do you mean "other FPGA"? The Vampire Vampire V4 and the MiSTer use the exact same FPGA, a Cyclone V. So what is different? The CPU softcore - the MiSTer/Minimig currently supports three 68k cores, Fx68k for cycle exact 68000, TG68 for 020+, and M68K as an alternative for 020+. There is also NG68 in its infancy, which unlike TG68 is aimed at 32bit 020+ from scratch, as not as an afterthought ontop of a 68000 implementation.

[kolla]

Cool, I will then request for this flag to be supported by the other 68k cores running on FPGAs - what could possibly break

I don't know, I don't care. We cannot give every version of the Apollo core another flag because we don't have many flags left. Probably four or five by now. I can possibly give another flag for another vendor with a different instruction set, but we should really be vendor-neutral in the Os.

It's up to Gunnar how to solve this. Currently, you can read the pcr register of the CPU and find out this way, but a more plausible approach would be to have a library call offering a tag-based interface checking the availability of features.

The "problem" here is that you call this an "FPGA flag" - for sure it is not an "FPGA flag", it is an "Apollo Core flag" - one day that CPU may exist in ASIC, and the flag will still be there, and it will be very inaccurate to call it an "FPGA flag".

Gunnar is not the only guy who implement 68k cores on FPGA, there are at least 3 others, why should they not also use the same "FPGA flag" on their cores?

[kolla]

Here we go again. Just because you $favorite_feture is not supported, you bully around. Kolla, forget it.

No - it really is not a "$favourite_feature", I really couldn't care less about this feature, when it comes to icons, the tools provided by the operating system have been borderline useless/pointless since forever, so I have my ways around it.

But I see where the request comes from, and I find your argument against it very weak, for the reasons I mention - the WBInfo window is already an editor, a rather extensive one - the primary reason for a user to open an info window is to make changes - be it replace icons, edit tool types, set default tool, toggle filesystem flags etc. - because, you know...

an *information window*

that can not..
* display the version of a file
* does not show what filesystem is used on a device/volume (but hey, random information of a filesystem - blocksize - always what I look for!)
* the content size of a drawer (but hey, you can edit tooltypes of drawers - awesome!)

It is a job for an icon editor. We have one. Again a very basic one.

Then, for the sake of consistency, shouldn't also editing tooltypes, default tool, stack size, priority etc. also be left as a job to the icon editor?

The current icon editor is nothing but a very simple and extremely basic graphical editor, and not really so useful for editing icons as it doesn't grasp the "new" icon format properly (read only?), doesn't support more than the 8 basic pens, pasting brushes from programs like PPaint etc doesn't work as intended etc.

Its _only_ metadata editing capabilities IconEdit can do, is setting the "icon type".

Besides, Rawbinfo or swazinfo are not patches. They just implement the info hook of the workbench. If you want features implemented there, bug their authors. It's ok to have third party tools.

RAWBInfo (ReAction-WorkBench-Info) has all features one can wish for, only problem is that it is buggy and unmaintained, and it currently needs 020+, but that could just be a matter of ReAction classes not supporting 68000.

[kolla]

What do you mean "other FPGA"?

You know that exactly.

No, I don't know what kamelito - not you - means with "other FPGA". There is a whole range of FPGA based Amiga systems around, and more are coming, and the various 68k implementations have different goals. So, I wonder what projects specifically kamelito - not you - was thinking about when he wrote "other FPGA".

And again, does it make sense to call it "Apollo FPGA" the day Apollo Core is ASIC, or is implemented on something that is not regarded as FPGA, for example through software emulation? It should really be enough to say that C:CPU now recognise the Apollo Core 68080 CPU core, without dragging the term "FPGA" into it.

[kolla]

Then why all the rumble again?

Because a very reasonable request was made, and your counter argument was very weak. WBInfo is much more of a metadata editor than IconEdit is.

[kolla]

For those of you who want to contribute to a little test, here is a resident module that is supposed to enable 4-way adapters on the internal IDE interface of the A1200 and A4000.

So much fuss about this... it works, of course.

[kolla]

At this point, I don't.

So what would be the point of me sending you an "original" IdeFix97 adapter from IComp?

So you have no system with IDE? No A600, A1200 nor A4000, and I already know you don't have access to CD32, so no AGA either.

[kolla]

Danish locales stands out btw - in the LOCALE:languages...

Code: [Select]

svenska.language            1060 ----rw-d 27-Sep-18 22:07:14
português.language          1096 ----rw-d 27-Sep-18 22:07:14
norsk.language              1056 ----rw-d 27-Sep-18 22:07:14
nederlands.language         1072 ----rw-d 27-Sep-18 22:07:14
italiano.language           1072 ----rw-d 27-Sep-18 22:07:14
français.language           1068 ----rw-d 27-Sep-18 22:07:14
español.language            1060 ----rw-d 27-Sep-18 22:07:14
deutsch.language            1068 ----rw-d 27-Sep-18 22:07:14
dansk.language              1980 ----rw-d 27-Sep-18 22:07:14

The language file of for dansk has a lot of stuff that no other language files have.

[kolla]

Maybe tha Danish are just more elaborate on how to name things?

Well, they do have a rather interesting relationship to numbers.

But I think it boils down to the danish translator "vertex" being much more thorough in his work than his co-translators back in 1992. The assembler source code for the language files at all typically around 7kB. The danish one is by far the largest, with more than 26kB.

[kolla]

Can you confirm this or show me how to do it correctly? Thanks!

Code: [Select]

Date Freitag 13-Dez-19
or just

Code: [Select]

Date 13-Dez-19
Note that you can specify non-existing dates, then the day will be ignored

Code: [Select]

Date Montag 13-Dez-19
If you just specify day, it will jump ahead to the next of this day

Code: [Select]

Date Freitag
And, as mentioned you can du superduper useful things like

Code: [Select]

Date Gestern
Date Morgensto jump the system time back and forth.

I have no idea what the usecase is for the above ways of setting system time.

[kolla]

It seems that Danish has more complicated rules for case-insensitive string comparison as it has a separate function for it, and does not use the generic ANSI comparison for it. I do not know why.

I believe it has to do with where our national letters æøå and their upper case equivalents ÆØÅ are in the Latin-1 (ISO-8859-1) codeset, which makes it necessary to be more explicit when defining the case conversions and the sorting rules.

Right, and the same is the case for many other languages too, including Norwegian, Swedish, and even German. Yet...

As I said, the Danish translator seems to have been more thorough than his colleagues.

[kolla]

mmh.. maybe if you are coding in a night session, fall into a microsleep just around midnight, while typing and, oh dear when you push the save button it is today already. But as a perfectionist with maybe some OCD you want the date of the file to be "yesterday".. So here it comes.
I could imagine it happened often during the early OS development phases, often enough for the early gods to implement that option!

LOL!

I think it is more of a side effect of Date using dos.library, it just accepts whatever dos.library manage to interpret as some sort of time stamp

Anyways - the unmentioned program in this hoopla, is SYS:Prefs/Time...