Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: The Os 3.1.4 Thread  (Read 101212 times)

0 Members and 2 Guests are viewing this topic.

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #600 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.
 
The following users thanked this post: Tygre

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #601 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".
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
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM460 and Mac minis with MorphOS
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #602 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.

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #603 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.
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
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM460 and Mac minis with MorphOS
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #604 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.

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #605 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.

 
The following users thanked this post: my_pc_is_amiga

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #606 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 :)
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #607 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?
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #608 on: August 18, 2019, 04:01:10 AM »
The other capture attached.
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #609 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)?
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #610 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.
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #611 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.
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #612 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.
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #613 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.
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #614 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.