Welcome, Guest. Please login or register.

Author Topic: Os 3.2 development preview  (Read 135441 times)

Description:

0 Members and 4 Guests are viewing this topic.

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #464 from previous page: December 13, 2019, 06:19:01 AM »
Another day, another component: The window class

This is a reaction class, and a representation of an intuition window. The class implements message handling, refresh and iconification, on top of the boopsi system.
The 3.9 preferences are based on the window class. The window class we have here is based on the Os 4 (v50) class, though with a couple of fixes:

*) As for all boopsis, the library open/close code had a race condition that could crash the machine in rare circumstances.
*) window iconification is now based on the native intuition window flag, and no longer on a custom gadget.
*) the busy-pointer is now the native intuition busy pointer and no longer a custom pointer.
*) the window backfill hook could crash in some situations
*) message handling had a race condition that, under rare circumstances, could have made the class loop forever, and it might have
forgotten to reply some messages, causing memory holes.

Thus, mostly bugfixes, though the class itself is quite a bit shorter now because code that was part of the class moved into intuition, and it was also
recompiled with somewhat better compiler settings.
 
The following users thanked this post: Tygre

Offline kolla

Re: Os 3.2 development preview
« Reply #465 on: December 13, 2019, 06:52:17 AM »
- Conclip was updated for the new con-handler features. Once loaded, CON:-windows can be iconified, and icons can be dragged into them.
Do iconified CON:-windows act as app-icons?
Can for example scripts be dropped on the icon of an iconified CON:-window?

Quote
- IPrefs allows now the scaling the image, or centering it, or tiling it. Scaling comes in two quality factors. IPrefs shows all the names of all windows that block the workbench from being closed, making it easier to identify components that are "in the way". IPrefs also reads the configuration for the workbench title string, and the workbench flags, such as windows can be dragged out of the screen.
I am still puzzled by how all this is the job of IPrefs (as in *Intuition* Prefs) rather than Workbench itself.

Quote
- SetDate gets a new keyword "FROM" that copies the date over from another file.
As in posix style "touch -r" I presume?
A long time wish-list/request from me would be that C:Date should be able to set system time in a similar faction, from the timestamp of a reference file.

Quote
- The CPU command is now able to detect the F6 erratum of the 68060 and identifies the Apollo FPGA.
Huh, do you mean the Apollo Core 68080 CPU? Or can you actually identify which FPGA is used? You are aware that there are at least three different variations of the AC68080? Without any FPU, with "full FPU" (Cyclone V FPGA, V4 standalone), and lastly the more interesting and most common, "limited FPU" (Cyclone III, Gold Core 2.7+ on various V2 and V3 cards). Can C:CPU now distinguish between the different FPU implementations?

Quote
- changetaskpri  can now also change the priority of a cli process by name, not only by its "process ID".
- the same goes for "break", which also accepts the name of a CLI process to stop.

One can already do this with back-ticking, for example "break `status command name`", but there is always the problem of many tasks having the same name. What does "changetaskpri" and "break" do when they find more tasks matching the name they are given?
« Last Edit: December 13, 2019, 06:53:00 AM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline my_pc_is_amiga

Re: Os 3.2 development preview
« Reply #466 on: December 13, 2019, 07:03:59 AM »
Ah...thanks for the info.   Found one that doesn't need v41 and it is working!

http://wup.aminet.net/package/util/dtype/fpWAV_dt40.2

They do work, but only for 8 bit samples because this is all the hardware can do.

I'll have to check more but I seem to be getting "Unknown data type for <filename>" for both a AIFF and WAV file.

I was trying the versions here:
https://www.stephan-rupprecht.de/

To make that particular wav datatype work on any 3.x version of AmigaOS you also need to use his sound.datatype v41.
 

Offline kolla

Re: Os 3.2 development preview
« Reply #467 on: December 13, 2019, 07:04:24 AM »
@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?
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline my_pc_is_amiga

Re: Os 3.2 development preview
« Reply #468 on: December 13, 2019, 07:09:53 AM »
GIF and AIFF datatypes... :)

@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?
 

Offline kolla

Re: Os 3.2 development preview
« Reply #469 on: December 13, 2019, 07:18:42 AM »
- 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)
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #470 on: December 13, 2019, 07:39:52 AM »
Do iconified CON:-windows act as app-icons?
Technically, yes, but this is not your question.

Can for example scripts be dropped on the icon of an iconified CON:-window?
No.


I am still puzzled by how all this is the job of IPrefs (as in *Intuition* Prefs) rather than Workbench itself.
IPrefs installs the backfill hook and keeps care of the refresh. It also the job of IPrefs to read the preferences and push them into workbench, intuition and other system compnoents.



As in posix style "touch -r" I presume?
As in "copy it from another file".

A long time wish-list/request from me would be that C:Date should be able to set system time in a similar faction, from the timestamp of a reference file.
No. What's the point, and why do you want to automate the system date setting? It's only set once the system is booted.

Huh, do you mean the Apollo Core 68080 CPU? Or can you actually identify which FPGA is used?
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.


One can already do this with back-ticking, for example "break `status command name`", but there is always the problem of many tasks having the same name. What does "changetaskpri" and "break" do when they find more tasks matching the name they are given?
Change all of them, break all of them. It is a pattern match. Same as in "killall" vs. "kill".

 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #471 on: December 13, 2019, 07:41:03 AM »
* SYS:System/Find - only requires one or two Reaction classes that I presume are now part of OS3.2
I'm not there yet, but we have a new "Find" utility that is gadtools based, scalable GUI of course.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #472 on: December 13, 2019, 07:43:00 AM »
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.
 

Offline kolla

Re: Os 3.2 development preview
« Reply #473 on: December 13, 2019, 08:34:19 AM »
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.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline kolla

Re: Os 3.2 development preview
« Reply #474 on: December 13, 2019, 08:39:46 AM »
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 :)
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline kamelito

Re: Os 3.2 development preview
« Reply #475 on: December 13, 2019, 09:40:44 AM »
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?
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #476 on: December 13, 2019, 09:44:22 AM »
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.
Here we go again. Just because you $favorite_feture is not supported, you bully around. Kolla, forget it. This is not how it works. We need to schedule the rare development time reasonable, and this is without reason. The only use case that comes into my mind where you would adjust the icon type is if you edit the icon anyhow, so it is better placed in an icon editor rather than the generic workbench interface. The system default tools should satisfy the needs of the majority of users, in a simple effective way without overloading the functionality with features that are only requied rarely and that just overload the (already too large) GUI.

Use the right tool for the job. No, adjusting the icon type is not a good feature for an *information window*. It is a job for an icon editor. We have one. Again a very basic one.

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.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #477 on: December 13, 2019, 09:49:02 AM »
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.
 

Offline kolla

Re: Os 3.2 development preview
« Reply #478 on: December 13, 2019, 09:51:50 AM »
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.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline kolla

Re: Os 3.2 development preview
« Reply #479 on: December 13, 2019, 09:55:21 AM »
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?
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS