Welcome, Guest. Please login or register.

Author Topic: The Os 3.1.4 Thread  (Read 239604 times)

Description:

0 Members and 4 Guests are viewing this topic.

Offline hth313

  • Newbie
  • *
  • Join Date: Aug 2018
  • Posts: 20
  • Country: 00
  • Gender: Male
    • Show only replies by hth313
Re: The Os 3.1.4 Thread
« Reply #539 from previous page: July 18, 2019, 07:54:19 PM »
The bonus code is the part after 512K of any 2.x or 3.x superkickstart file.

During startup it is copied onto the last 4K of the actual kickstart image, the MMU is configured so that this RAM image loaded appears in the ROM location and write protects it. Then the system resets and your soft kicked image is now the “ROM”. As long as you do not fiddle with the MMU in a bad way it stays there and appears to be the ROM so ordinary resident tricks should work the same as with a real ROM.
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #540 on: July 18, 2019, 09:24:53 PM »
Ah, oh well. Is an official SuperKickstart planned for a later update?
Not really. Problem is the lack of testing opportunities for this, and you can always install a new ROM chip instead. Actually, the superkickstart code in the A3000 Os ROM has (at least two) bugs which demonstrates that this code is too fragile to be kept in there forever.


In the absence of a physical ROM replacement, can LoadModule successfully load in the 3.1.4 modules on a 1.4 system? (after SuperKickstart 3.1 has been softkicked, of course)
Well, again, I haven't tested this, but I see no reason why not. But then again, in such a case I would rather consider MuMapROM as it replaces the entire ROM in one go.


 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #541 on: July 19, 2019, 06:44:35 PM »
Maybe continue with the next episode. What is also new is DiskCopy and Format. Both system tools suffered from a defect declaring the font definition as "static", which would have triggered a "hit". The problem there was that the structure that describes the desired font ended up on the stack instead of the heap, and thus went away later on in the program, causing the problem. In our testing, nothing else overwrote the stack, so the problem remained undetected.
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #542 on: July 21, 2019, 06:04:28 AM »
I was trying the 68k version of the WarpBMP datatype (https://www.warpdt.co.uk/) to load a BMP picture into multiview using the 46.13 picture.datatype.  This is using Amiga native graphics (A4000T) and no graphic card installed.   

I am seeing the picture not loading correctly.  Top of screen is getting rendered incorrectly and then the whole system crashes with guru 8100 0005 after trying to quit multiview or right click for menus.

Attached is a photo of the screen after loading.
« Last Edit: July 21, 2019, 06:06:02 AM by my_pc_is_amiga »
 

Offline Gulliver

Re: The Os 3.1.4 Thread
« Reply #543 on: July 23, 2019, 12:37:05 AM »
@my_pc_is_amiga

Hi,

Are you also the same person posting as "Castellen" in other Amiga forums?
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #544 on: July 23, 2019, 02:03:01 AM »
No, I'm somebody different.   Has anybody reproduced the strange loading of pictures (e.g. BMP pictures) that causes a guru.  I'm always paranoid that I'm hitting some hardware issue with my A4000T instead of software when it comes to these memory corruptions -- feel much better if it just software since that always can get fixed :).

I'm also finding that if I load a picture in multiview in full screen mode and if the picture size is small, a small screen is opened.  Because of that, there isn't enough screen real estate for the menu bar to fully show and the ASL requester cannot open properly.

I think heard that the older AIFF/WAV datatypes (that are available on Aminet) need some updating to get them to work again with the 3.1.4.   I haven't been able to get those old ones to work anymore.

Lastly, a wish that I don't think has even made it into OS4.x--to have copy and search support for amigaguide in multiivew.


@my_pc_is_amiga

Hi,

Are you also the same person posting as "Castellen" in other Amiga forums?
 

Offline 10MARC

Re: The Os 3.1.4 Thread
« Reply #545 on: July 23, 2019, 06:55:07 AM »
I am having an issue with one of my machines - my most powerful one.
A4000, Warp Engine upgraded to 68060/80 MHz, 96+ MB RAM, 15,000 RPM SCSI Hard Drive, Cybergraphx 64 3D with Picasso drivers.
Running Amiga OS 3.1.4.1 with real ROMS. The entire system works great and incredibly fast, except booting. Startup Sequence hangs on setpatch for about 90 to 120 seconds - it runs, and I can see the results of it, and it just sits there until "Intuition is trying to close Windows" pops up. A few minutes later, it seems to finish and it boots normally and works fantastic.
I suspect it MIGHT be the CPU command right after setpatch, but not 100% sure. Anyone else experience this?
The system is not locked as the mouse moves fine and I can move the shell window around.
The slowness in booting also occurred on a raw install, no update from 3.9
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #546 on: July 23, 2019, 09:40:23 AM »
The system is not locked as the mouse moves fine and I can move the shell window around.
The slowness in booting also occurred on a raw install, no update from 3.9
You can always test this by booting in interactive or echo mode, i.e. "set echo on" at the start of the startup-sequence. You then see where the system hangs. My best guess is in "SetPatch", or to be precise, in the 68060.library building the MMU tables. 96MB is quite some memory, so constructing them may take a while. If you are using the mmu.library, try to upgrade it. The latest release keeps the cache enabled for building the initial tables and may hence operate somewhat faster.
 
The following users thanked this post: 10MARC

Offline 10MARC

Re: The Os 3.1.4 Thread
« Reply #547 on: July 24, 2019, 04:53:18 AM »
I can certainly test that theory by taking out most of the memory. I can just boot it with the onboard 16 MB. I will track down the latest mmu.library, too. Thanks for the quick response!
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #548 on: July 24, 2019, 06:24:40 AM »
I can certainly test that theory by taking out most of the memory. I can just boot it with the onboard 16 MB. I will track down the latest mmu.library, too. Thanks for the quick response!
Another "most promising candidate" is the FFS which requires some time to validate large partitions. While the new FFS would be somewhat faster with this, the best option you have is to use larger block sizes (i.e. 4096 bytes per block = 8 sectors per block) to speed up the operation. This requires, however, reformatting the affected partition(s).
 
The following users thanked this post: 10MARC

Offline Rotzloeffel

Re: The Os 3.1.4 Thread
« Reply #549 on: July 26, 2019, 07:42:47 AM »
I was trying the 68k version of the WarpBMP datatype (https://www.warpdt.co.uk/) to load a BMP picture into multiview using the 46.13 picture.datatype.  This is using Amiga native graphics (A4000T) and no graphic card installed.   

could you please test this with the Picture.datatype from 3.9 ? I also had some issues with warp-Datatypes and the new Picture.library. I allready reported this to Oliver Roberts.

It seems the warp.datatypes are the "Problem"
Save Planet Earth! It is the only one in the galaxy with fresh and cold beer :laughing:
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #550 on: July 27, 2019, 05:16:57 PM »
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. 

Then I loaded the OS3.9 env. from an Emergency Disk that booted the CD-ROM.  I loaded up the warpbmp datatype and loaded the *bmp into multiview and no issue (no crashing or picture corruption).  Also, in the 3.9 env. multiview is giving full access to menu bar for small images -- in 3.1.4 multiview is making small screen size as reported previously.

I was trying the 68k version of the WarpBMP datatype (https://www.warpdt.co.uk/) to load a BMP picture into multiview using the 46.13 picture.datatype.  This is using Amiga native graphics (A4000T) and no graphic card installed.   

could you please test this with the Picture.datatype from 3.9 ? I also had some issues with warp-Datatypes and the new Picture.library. I allready reported this to Oliver Roberts.

It seems the warp.datatypes are the "Problem"
« Last Edit: July 28, 2019, 05:11:31 AM by my_pc_is_amiga »
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #551 on: July 27, 2019, 10:18:24 PM »
I've been trying to get CrossDOSFileSystem to work with Poseidon USB Stack and have read through the FAQ, etc. but no luck.  It gets mounted but DOS says "Not a DOS disk".  Fat95 mounts but I rather use CrossDOSFileSystem.  Does anybody have a Poseidon config. that works with thumb drives?   Also, in the FAQ, it mentions, mount flags like Fat32, "DirectSCSI" -- if we were to use these, do we need to use it like this in a mountfile:

Control  = "Fat32=1, DirectSCSI=1"
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #552 on: July 28, 2019, 05:22:45 AM »
Don't know if this is related to the previous memory leak with shell "copy" command  -- but in doing a copy in workbench (drag-and-drop) from my hard drive to RAM:, I was doing a large copy.  It was enough that filled up my RAM disk.  I got the message that my RAM disk is full but after acknowledging the requester and stopping the copy, my ram was not freed properly.  My fast ram in workbench title bar showed "3,782,782,128 other memory" (~3.5GB!).   I only have 272MB of fast memory.   And doing an avail, I saw negative numbers being reported for "available" 
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #553 on: July 28, 2019, 08:43:47 AM »
I've been trying to get CrossDOSFileSystem to work with Poseidon USB Stack and have read through the FAQ, etc. but no luck.  It gets mounted but DOS says "Not a DOS disk".  Fat95 mounts but I rather use CrossDOSFileSystem. 
Is this a "superfloppy" with no partition information on it, or a partitioned disk? Thumbdrives that are pre-formatted for the PC are the latter, thus use the instructions in the FAQ. Also note the name of the drive, it should end with a 'C' or a '0' to indicate the partition number, and the right DOS type as indicated in the FAQ.

Does anybody have a Poseidon config. that works with thumb drives?   Also, in the FAQ, it mentions, mount flags like Fat32, "DirectSCSI" -- if we were to use these, do we need to use it like this in a mountfile:

Control  = "Fat32=1, DirectSCSI=1"
No, the FAQ does certainly not mention a mount flag like Fat32. Fat32 support is built into CrossDos, this is what it says. "DirectSCSI" *is* a mount flag, but you only need that for broken devices that do not support reads beyond the 4GB barrier. I am not aware that the usbscsi.device is broken, but I could be wrong. So, nothing of the above. Mount flags are just used as indicated in the FAQ:

Code: [Select]
DirectSCSI=1

This is a native mount flag, not part of any "control" or whatsoever - there are examples in the FAQ (yes, really!). But, you don't want this mount flag anyhow.

 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #554 on: July 28, 2019, 09:37:13 AM »
Don't know if this is related to the previous memory leak with shell "copy" command  -- but in doing a copy in workbench (drag-and-drop) from my hard drive to RAM:, I was doing a large copy.  It was enough that filled up my RAM disk.  I got the message that my RAM disk is full but after acknowledging the requester and stopping the copy, my ram was not freed properly.  My fast ram in workbench title bar showed "3,782,782,128 other memory" (~3.5GB!).   I only have 272MB of fast memory.   And doing an avail, I saw negative numbers being reported for "available"
Sorry, I cannot reproduce this here. I need better instructions for reproduction. If the RAM disk becomes full, you get a requester whether the incomplete object should be removed. If I say "no", the RAM is still full, but I see a small amount of RAM left. If I say "yes", the RAM is released.