The Os 3.1.4 Thread

[my_pc_is_amiga]

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. 

[my_pc_is_amiga]

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

[my_pc_is_amiga]

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.

[my_pc_is_amiga]

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?

[my_pc_is_amiga]

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. 

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.

[my_pc_is_amiga]

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?

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.

One thing you can try is to give multiview more stack.

I tried changing to 94096k stack and still saw issue.

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.

[my_pc_is_amiga]

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.

[my_pc_is_amiga]

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.

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.

[my_pc_is_amiga]

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?

[my_pc_is_amiga]

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"

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

[my_pc_is_amiga]

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.

[my_pc_is_amiga]

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. 

[my_pc_is_amiga]

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

[my_pc_is_amiga]

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?

[my_pc_is_amiga]

The other capture attached.

[my_pc_is_amiga]

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