AmigaOS 3.2 and beyond

[Jope]

Originally Posted by AMIGASYSTEM

The name of the DosDriver in my opinion doesn't influence on its functionality, in my systems I use Driver names invented by me and I don't have any problem in the various mounting volumes.

Example CD0 you can rename CDX, CDY or CDZ and it will always work the same way.

This is not a matter of opinion, it is a documented feature of the 3.1.4 and 3.2 CrossDOSFilesystem when it is running in hard disk mode.

So just to emphasize: no other filesystem driver I know of behaves like this, but this one does. Feel free to read the FAQ / other documentation included with 3.1.4 and 3.2.

[AMIGASYSTEM]

Originally Posted by Jope

This is not a matter of opinion, it is a documented feature of the 3.1.4 and 3.2 CrossDOSFilesystem when it is running in hard disk mode.

Thanks, read the FAQ, it's a pretty unusual convention.

So just to emphasize: no other filesystem driver I know of behaves like this, but this one does.

In fact that's why it seemed strange to me, never happened that a DOSDrivers name could have this kind of function, there's always something new to discover on AmigaOS.

[Thomas Richter]

A little bit of background on this: The overall problem is that there is no institution/software module on Amiga that cares about partition tables. The firmware of the boot hardware has to do it, and thus it is not part of the ROM (exception: scsi.device).

Now, PC harddrives use another partition mechanism than Amiga (Bios partition vs. Amiga RDB), and as nothing in the Amiga can read PC Bios partitions, CrossDos has to do it.

The question is now where the partition number you want to mount comes from. CrossDos uses the convention of the last letter of the device name. FAT95 the last digit of the "FileType" entry in the mount list.

The latter, is however, a rather bad idea. Consider that you have two partitions on a PC Bios disk. With the FAT95 convention, the DosTypes of the two partitions is different, and hence, FAT95 is loaded twice into RAM, which is wasteful.

This said, CrossDos (starting with 3.2) does also support FAT95 partition indication, but this is not recommended for the reasons already given.

[indigolemon]

Originally Posted by Thomas Richter

A little bit of background on this: The overall problem is that there is no institution/software module on Amiga that cares about partition tables. The firmware of the boot hardware has to do it, and thus it is not part of the ROM (exception: scsi.device).

Now, PC harddrives use another partition mechanism than Amiga (Bios partition vs. Amiga RDB), and as nothing in the Amiga can read PC Bios partitions, CrossDos has to do it.

The question is now where the partition number you want to mount comes from. CrossDos uses the convention of the last letter of the device name. FAT95 the last digit of the "FileType" entry in the mount list.

The latter, is however, a rather bad idea. Consider that you have two partitions on a PC Bios disk. With the FAT95 convention, the DosTypes of the two partitions is different, and hence, FAT95 is loaded twice into RAM, which is wasteful.

This said, CrossDos (starting with 3.2) does also support FAT95 partition indication, but this is not recommended for the reasons already given.

Love posts like that that explain the 'why' of things. Thanks Thomas!

[PeterK]

I think I have found a BUG. When we are inside the drawer that doesn't have an icon and we are doing cleanup and then SNAPSHOT the System crashes. Both WinUAE and Real Amiga.

I found the reason for the snapshot problem occurring when my icon.library and workbench.library v47 are both interacting. Since build #445 my library notifies the Workbench when a deficon is written by PutIconTagList() to disk by calling UpdateWorkbench(UPDATEWB_ObjectAdded). If I disable this call then the crashes don't happen. Edit: But I don't want to remove this notification, because it's correct and was forever a legal option for PutIconTagList().

It could be possible that my UpdateWorkbench() call is executed in the middle of an update that the new Workbench v47 now does itself, when the deficon has already been released from memory and before the internal icon pointer was updated with the real icon, or something like this. Then my call could get an invalid address as it has occurred in FreeDiskObject() ??

Update: Why does the Workbench not use PutIconTagList() with the tag NotifyWorkbench in order to update the deficons as my library does it? Then, this option could only be activated once! Additional update code in workbench.library is not necessary, because WorkbenchUpdate() can do that already.

[digitalMedic]

I was just told that the 3.2 Roms have a bug in them that affects Z3 autoconfig and it is likely causing an issue I am having. Where can we find more info on this and the extent of the problem? I didn't see any information on the Hyperion support forum and a search of this thread came up empty. I don't want to buy two new sets of Rom chips until the problem is fixed, especially since I am not keen on having to buy them again as it is. Thanks for any info someone can provide.

[hexaae]

AmigaGuide

Is it in to-do a Search feature, finally bringing you to the (first) page with highlighted matching text(s) in the whole page and Next, Previous (page) features?

[klx300r]

Originally Posted by digitalMedic

I was just told that the 3.2 Roms have a bug in them that affects Z3 autoconfig and it is likely causing an issue I am having. Where can we find more info on this and the extent of the problem? I didn't see any information on the Hyperion support forum and a search of this thread came up empty. I don't want to buy two new sets of Rom chips until the problem is fixed, especially since I am not keen on having to buy them again as it is. Thanks for any info someone can provide.

hmm I’d love to know too before I install new OS3.2 roms in my 4000!

what zorro3 cards are you having (or heard others)issues with?

[digitalMedic]

My CVisionPPC is not being recognized. P96 cannot see it. One of the devs said it might be from the bug in the Z3 auto config. Hoping someone here has some insight on the possible bug.

[klx300r]

@ digitalMedic


ah sorry to hear that & hope there's a fix soon for it..hoping my Zorro 3 cards work fine with the OS3.2 roms

[gdonner]

Originally Posted by klx300r

@ digitalMedic

ah sorry to hear that & hope there's a fix soon for it..hoping my Zorro 3 cards work fine with the OS3.2 roms

They should--this is the first time I've heard of any issue with the 3.2 ROM.

I can vouch for at least the BigRamPlus, ZZ9000, and X-Surf 100 (with Rapid Road) working fine with 3.2 ROMs on both the A3000 and A4000.

From my non-programming user view, it does seem like Phase 5 boards are more complex than most, and more likely to balk at any low-level AmigaOS changes or fixes.

[digitalMedic]

I installed Cybergfx4 in the mean time and it works fine now. The P96 dev said he submitted at bug report to Hyperion and they have a fix that will be released with the 3.2.1 update. I will just continue with Cybergfx4 until then.

[klx300r]

@ DigitalMedic

good to hear you got it up in the mean time.

@gdonner

I know what ya mean about the Phase 5 zorro cards ;-)

[Thomas Richter]

Originally Posted by digitalMedic

I installed Cybergfx4 in the mean time and it works fine now. The P96 dev said he submitted at bug report to Hyperion and they have a fix that will be released with the 3.2.1 update. I will just continue with Cybergfx4 until then.

The issue with these cards is that they include a PCI bridge that is initialized by the proprietary P5 firmware upon boot. If that isn't run, or you disable it, then the card remains invisible.

If you are an iComp customer, please contact Jens. I send him a beta driver that includes init code for the PCI bridge. Whether this works I do not know, but at least I understand now a little bit better what the problem is.

[digitalMedic]

Thank you. I appreciate your work!

[klx300r]

@ThoR

Once again thanks so much to you and all the OS3.2 devs/ testers etc….honestly us Amiga users wouldn’t still be here in 2021 if it wasn’t for you guys and the awesome Amiga Community

[gdonner]

Originally Posted by klx300r

@ThoR

Once again thanks so much to you and all the OS3.2 devs/ testers etc….honestly us Amiga users wouldn’t still be here in 2021 if it wasn’t for you guys and the awesome Amiga Community

I second that--credit where credit is due!

[bdb]

Originally Posted by gdonner

They should--this is the first time I've heard of any issue with the 3.2 ROM.

I can vouch for at least the BigRamPlus, ZZ9000, and X-Surf 100 (with Rapid Road) working fine with 3.2 ROMs on both the A3000 and A4000.

From my non-programming user view, it does seem like Phase 5 boards are more complex than most, and more likely to balk at any low-level AmigaOS changes or fixes.

Same here, BigRAMPlus, X-Surf 100 w/ RR, A4000 FastATA, and CyberVision 64 all working fine.
When I had the CVPPC, it was recommended to use the CyberGraphx V3/4 system, not P96; that was in a time of 3.1 ROMs. I sold my CVPPC when I bought a Mediator with a Radeon 256Kb GPU card - it was faster, with the Z3 RAM benefits, better resolutions and easy to set up with the P96 system (still in use on one of my A4000Ts with 3.2 ROMS).

[number6]

@thread

There is an AmigaOS 3.2 presentation scheduled as one of the talks at AmiWest on Sunday.

Brian Carpignano - What's new in OS 3.2

Broadcast schedule: http://amiwest.net/broadcast/

Please keep in mind that the broadcast link currently posted was used for some testing and the actual daily link will change for each day (Saturday and Sunday) and be listed on the above page prior to the day's steam beginning.

#6

[Romanujan]

Will he talk about OS 3.2.1?