The Os 3.1.4 Thread

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

[my_pc_is_amiga]

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.

[my_pc_is_amiga]

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.   

[my_pc_is_amiga]

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.

[my_pc_is_amiga]

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.

[my_pc_is_amiga]

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.

[my_pc_is_amiga]

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. 

[my_pc_is_amiga]

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.

[my_pc_is_amiga]

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.

[my_pc_is_amiga]

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.   

[my_pc_is_amiga]

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

[my_pc_is_amiga]

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.

[my_pc_is_amiga]

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.

[my_pc_is_amiga]

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


[my_pc_is_amiga]

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.               


[my_pc_is_amiga]

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.