Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A600 Memory

AuthorTopic: The Os 3.1.4 Thread  (Read 80948 times)

0 Members and 3 Guests are viewing this topic.

Offline trekiej

Re: The Os 3.1.4 Thread
« Reply #630 on: August 19, 2019, 03:39:41 PM »
@Thomas R. and Tribble Smasher
I need to see the Release Notes.

I understand that SCSI got improved or updated.
Would this help an A2091, for example?

How about Z2 RTG video cards?
Better performance also?
Amiga 2000 Forever :)
Welcome to the Planar System.
 

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #631 on: August 19, 2019, 03:44:22 PM »
@Thomas R. and Tribble Smasher
I need to see the Release Notes.
Release notes are non-public by decision of Hpyerion.

I understand that SCSI got improved or updated.
Would this help an A2091, for example?

The A2091 comes with its own boot ROM, as far as I understand, so this does not help anything. What does help is that autoconf timing got a little bit more relaxed, helping to auto-detect the A2091 in fast systems. This could have failed before.


How about Z2 RTG video cards?
Better performance also?
RTG cards are handled by either P96 or Cybergraphics, and none of them are part of the Os. However, there is an updated P96 available for purchase (for little money) from iComp which fixes some of the known issues, such as rendering problems for HiColor modes or a more flexible use of the hardware sprite. The speed of RTG cards over Z2 bus is a hardware limitation, namely a bandwidth limitation of Zorro-II, and this cannot be addressed by software.




Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #632 on: August 20, 2019, 05:10:03 AM »
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.   
« Last Edit: August 20, 2019, 05:41:38 AM by my_pc_is_amiga »
 

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #633 on: August 20, 2019, 12:44:26 PM »

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.
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #634 on: August 20, 2019, 11:35:15 PM »

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

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #635 on: August 21, 2019, 05:23:39 AM »
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.
 

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #636 on: August 22, 2019, 09:48:53 PM »
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?
 

Offline trekiej

Re: The Os 3.1.4 Thread
« Reply #637 on: August 23, 2019, 02:07:03 AM »
Who would own the code in the A2091?
I wonder if it needs to be updated.

Each manufacturer would have to, of course, update their own code.
Amiga 2000 Forever :)
Welcome to the Planar System.
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #638 on: August 23, 2019, 04:53:52 AM »
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.
« Last Edit: August 23, 2019, 05:03:40 AM by my_pc_is_amiga »
 

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #639 on: August 23, 2019, 05:41:38 AM »
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.
I tried "InitPrinter", which also prints data through PRT: Is this the 3.1.4 Port-Handler on your side?
 

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #640 on: August 23, 2019, 05:43:48 AM »
Who would own the code in the A2091?
I wonder if it needs to be updated.

Each manufacturer would have to, of course, update their own code.
That is, pardon, was CBM of course. My research shows that this is build from the same code as the scsi.device, even though I haven't tried to build it, and I don't know whether it would build. To make this a ROM image, a bit more would probably be required, probably. With the A2091, you should be much better off with the Guru-ROM, though.
 

Offline trekiej

Re: The Os 3.1.4 Thread
« Reply #641 on: August 23, 2019, 06:16:48 AM »
No offense intended, would the rom need to be switched in software or rom chip replacement?
 :D
Amiga 2000 Forever :)
Welcome to the Planar System.
 

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #642 on: August 23, 2019, 06:20:18 AM »
No offense intended, would the rom need to be switched in software or rom chip replacement?
 :D

I have no idea, really.

Offline trekiej

Re: The Os 3.1.4 Thread
« Reply #643 on: August 23, 2019, 07:02:34 AM »
I will stop bugging you. :D

edit:
For a little while, at least.
Amiga 2000 Forever :)
Welcome to the Planar System.
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #644 on: August 23, 2019, 08:23:07 PM »
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