AmigaOS3.2 on A2000 with A2630 (030) CPU Board

[ahandyman59]

I have an Amiga 2000 that I've used for years. Today I upgraded the kickstart from 3.1.4 to 3.2. Now every time it boots, it give me that irritating message about needing the 68030.library file. I dug out my library disk and copied the 68030.library file and the mmu.library files over to DH0evs and it still gives me that irritating error message. I have tried removing all 68k libraries. Tried copying the 68020.library file over and renaming it 68030.library. I have tried most combinations I can think of and the error won't go away and won't let the system start without something being done. It does say one possibility is to remove the cpu check from startup and use some utility to start the MMU stuff, but I don't know any command to start the mmu stuff. The library files I am using are those from the MMULib stuff on Aminet.

I'm starting to wonder if the old girl (a2000), with the A2630 accelerator board isn't able to deal with kickstart 3.2... Any ideas?

[Thomas Richter]

Then you didn't install it properly. The installation procedure will copy everything into the right place, including those libraries. They need to go to LIBS:, and *removing* them is not going to help.

In other words, please use the Os installer. Failing that, copy them manually, but please in the right place. The right place is the LIBS directory of your boot disk.

[SpeedGeek]

Originally Posted by ahandyman59

I'm starting to wonder if the old girl (a2000), with the A2630 accelerator board isn't able to deal with kickstart 3.2... Any ideas?

It appears to be a case of vice versa. If OS 3.2 can't "Deal" with your A2000/A2630 system without requiring you to install a 68030.library, then it's probably time to reconsider your decision to purchase this version.

You should question why all the Commodore versions (1.3-3.1), the H&P versions (3.5-3.9) and the Cloanto version (3.X) of Amiga OS can deal just fine with your system without this "New" requirement.

EDIT:
It is apparently possible to use OS 3.2 without having the 68030.library installed. See below.

[Thomas Richter]

Originally Posted by SpeedGeek

It appears to be a case of vice versa. If OS 3.2 can't "Deal" with your A2000/A2630 system without requiring you to install a 68030.library, then it's probably time to reconsider your decision to purchase this version.

You should question why all the Commodore versions (1.3-3.1), the H&P versions (3.5-3.9) and the Cloanto version (3.X) of Amiga OS can deal just fine with your system without this "New" requirement.

Stop the nonsense please. You know as well as I do what the library is good for, and that it's merrily a boot warning, and not a boot failure. If the OP had installed the system properly, everything would be fine. Yes, of course you can boot without the library, it's just not recommended because some setups then don't work. And, as you know of course, would not work either "out of the box" with Kick 3.1 or any other kickstart on the market.

[Lisko]

Originally Posted by ahandyman59

I have an Amiga 2000 that I've used for years. Today I upgraded the kickstart from 3.1.4 to 3.2. Now every time it boots, it give me that irritating message about needing the 68030.library file. I dug out my library disk and copied the 68030.library file and the mmu.library files over to DH0evs and it still gives me that irritating error message. I have tried removing all 68k libraries. Tried copying the 68020.library file over and renaming it 68030.library. I have tried most combinations I can think of and the error won't go away and won't let the system start without something being done. It does say one possibility is to remove the cpu check from startup and use some utility to start the MMU stuff, but I don't know any command to start the mmu stuff. The library files I am using are those from the MMULib stuff on Aminet.

I'm starting to wonder if the old girl (a2000), with the A2630 accelerator board isn't able to deal with kickstart 3.2... Any ideas?

Don't forget to also copy 680x0.library together with 68030.library and mmu.library to libs: folder.

[SpeedGeek]

Originally Posted by Thomas Richter

Stop the nonsense please. You know as well as I do what the library is good for, and that it's merrily a boot warning, and not a boot failure. If the OP had installed the system properly, everything would be fine. Yes, of course you can boot without the library, it's just not recommended because some setups then don't work. And, as you know of course, would not work either "out of the box" with Kick 3.1 or any other kickstart on the market.

What nonsense? The OP did not state that this was a boot warning, he stated he got an irritating message about "Needing" the 68030.library.

Your reply to the OP was to explain how to properly install the library, not to explain how to boot without it. Now, that this more detailed information was finally posted, I can use it to update my previous post.

So, because there are a few 030 systems which might not work out of the box, all of the 030 systems should now install a performance and memory reducing solution? Now, that's what I call nonsense.

[ahandyman59]

I went back and used the install again in MMULib and this time it apparently worked correctly. The system boots normally and all is good again. Problem solved.

[stevelord]

Originally Posted by Thomas Richter

Yes, of course you can boot without the library, it's just not recommended because some setups then don't work. And, as you know of course, would not work either "out of the box" with Kick 3.1 or any other kickstart on the market.

What similar setups wouldn't work out of the box with 3.1? I appreciate that's an open-ended question but I'm interested in understanding what you had in mind.

[Thomas Richter]

Bridge boards with a 68030 will hang, and some graphics cards, most notably the CVision3D, will not work reliable with a 68030. This goes down to a hardware defect of the 68030 which, despite having a "cache inhibit input" line, caches long-word aligned long word write accesses in its cache, regardless of whether the hardware asserts the line or not. Both the bridge board, and some graphics cards, have long-word aligned long word hardware read/write registers that would be cached erroneously.

The 68030.library fixes this, by enabling the MMU. Actually,the manuals of said bridge boards come with the recommendation to insert "Enforcer QUIET" into the startup-sequence, which did the same back then. However, the sole purpose of "Enforcer" was a somewhat different one, and it has been superseded a long time ago, and the bridge boards are not the only hardware that have trouble with the 030.

[stevelord]

Oof that sounds like a nasty bug. Thanks for taking the time to explain it.

[SpeedGeek]

Originally Posted by stevelord

Oof that sounds like a nasty bug. Thanks for taking the time to explain it.

The limited explanation of the problem itself does not offer a satisfactory explanation of the solution provided. First, even though Enforcer was not specifically intended to fix BridgeBoard 030 systems, it worked well enough in that regard that Commodore found no reason to replace it.

I find claims that Enforcer was "Superseded A Long Time Ago" to be rather suspicious. If you want the latest version it's still available on Mike Sinz's website.

Enforcer has an important advantage over the library solution since it runs as an executable. This makes it possible to create a script to run Enforcer before the Janus software starts and also send Enforcer a break when the Janus software quits.

The other more important information about the performance penalties of the provided solution was conveniently omitted. While, it's not possible to provide exact detailed performance information. The following general example should suffice.

Generic 68030 system:

MMU enabled (LE config) = 30% performance loss

MMU enabled (ME config) = 20% performance loss

MMU enabled (HE config) = 10% performance loss

MMU disabled = 0% performance loss

LE = low efficiency, ME = medium efficiency, HE = high efficiency

[thebajaguy]

In 3.5 years of Tech Support at GVP back in the day, the standard solution for BridgeCard enabling with A3001/Combo 030/G-Force boards (with MMUs) was:

1. In S:Startup-Sequence, modify the SetPatch command with 'NoCache' option to keep the data cache off initially.
- this will actually cause the OS 3.2 CPU Check command in S:Startup-Sequence to pass without error.
2. The call to Bindrivers to load the Janus driver for the Bridgecard (use 2.1, not the earlier offerings) out of sys:Expansion will now work. RTG software should also be started around this time.
3. Once you have all things operational, use the last SetCPU offering (v1.6) from Dave Haynie / AmiNet with the 'cache FastROM' options, and it works around both the CIIN issue and the BridgeCard's (or RTG's) shared memory problem, and remaps Kickstart to 32-bit RAM. Place it after the Binddrivers or RTG startup commands in s:Startup-sequence, or place it in S:User-Startup toward the end to be 'safe'.

This should work for C= A2630's with Full (non-EC) CPU, too. If your system is a bit more complex, I'll point you to the MuLibs package.

My original daily driver at GVP (before the A3000T w/GF040) was an A2000 w/030 and A2286 BridgeCard. The latter was for the DOS-based CRM software we used for call-tracking/case management. The Amiga and PC both had Ethernet networking, too.

This basic information (reworded slightly), and the MuLibs option, is mentioned in the CPU-FAQ.readme included with the OS 3.2 documentation in the FAQs folder of the OS 3.2 CD image. It's toward the bottom, under the 68030 section. I actually wrote that document.

[SpeedGeek]

I agree that SetCPU is a practical option for BridgeBoard 030 systems with certain limitations. In particular, SetCPU was developed for OS 1.3-2.x systems and would only have some limited degree of compatibility with OS 3.x systems.

Another issue (not BridgeBoard related) is the possibility of supporting the few Zorro III I/O Boards which might need the CIIN feature/bug fix.

Enforcer, should be able to handle both of the above issues quite well since it's development continued long after the end of Commodore.

However, SetCPU does have the same advantage (as an executable) as noted above.

BTW, all of the options discussed thus far would qualify as "LE Config" MMU solutions noted above.

[patrik]

Originally Posted by SpeedGeek

The other more important information about the performance penalties of the provided solution was conveniently omitted. While, it's not possible to provide exact detailed performance information. The following general example should suffice.

Generic 68030 system:

MMU enabled (LE config) = 30% performance loss

MMU enabled (ME config) = 20% performance loss

MMU enabled (HE config) = 10% performance loss

MMU disabled = 0% performance loss

LE = low efficiency, ME = medium efficiency, HE = high efficiency

Are there any ME or HE implementations available?

[Thomas Richter]

This is not a matter of the implementation. It is the matter of a configuration, in particular of the page size. The default page size of the 68030 configuration is to use 1K pages, which is picked if the library finds the MMU unconfigured, otherwise it will pick whatever it finds.

The reason for that is that it is the most compatible setting that works under all Os configurations. All versions of Kickstart below 3.0 use a chip mem start address of 0x400, corresponding to a 1K zero-page zone. If a larger page size is used, parts of the chip mem will not be reachable by the CPU anymore, and accesses to this zone then have to be emulated, making the access to this region extremely slow. All higher kickstart versions use a zero-page start address of 0x1000, corresponding to 4K pages you find on the 68040 and 68060, which was a modification useful for these processors as they do not support a 1K page setup. Anything above 4K pages again causes the same trouble and should be avoided for that reason. The 68030 supports up to 32K page sizes, but that is too much also for some other applications - 16K would be an upper practical limit, which - however - already requires preparation of a larger zero page size. This happened in Os 3.1.4.

In how much a particular configuration impacts performance depends on the application and how its memory access pattern looks.

Thus, in total:
Kickstart < 3.0 : most practical setting is the one present, 1K pages.
Kickstart < 3.1.4: most practical page size is 4k
Kickstart >= 3.1.4: most practical page size is 16k

[SpeedGeek]

Originally Posted by patrik

Are there any ME or HE implementations available?

Yes, and I released a benchmark tool so users can actually see the performance differences:

https://eab.abime.net/showthread.php?t=92994

BTW, there is nothing special about the 1K page size. Mike Sinz was just being lazy and since Enforcer was primarily intended as a debugging tool, performance was not a priority. But when Commodore decided to use it for fixing BridgeBoards, that's when the performance issue should have been given some consideration.

The only reason that a page size > 4K would be a problem is if you want to manage the Zero page area differently than Chip RAM. This is an optional choice rather than a required one.

[patrik]

Originally Posted by Thomas Richter

In how much a particular configuration impacts performance depends on the application and how its memory access pattern looks.

What made me notice was the difference in TCP/IP performance.

The below local network receive speeds test are from my A3000 030@25MHz, X-Surf-100, Kickstart3.1, OS3.2.1.

With 68030.library and mmu.library:

8.Ram Disk:> version 68030.library 
68030.library 46.6
8.Ram Disk:> ttcp -s -r 
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket
ttcp-r: accept from 192.168.1.1
ttcp-r: 16777216 bytes in 28.22 real seconds = 580.58 KB/sec +++
ttcp-r: 2049 I/O calls, msec/call = 14.10, calls/sec = 72.61
ttcp-r: 0:28real
8.Ram Disk:> ttcp -s -r 
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket
ttcp-r: accept from 192.168.1.1
ttcp-r: 16777216 bytes in 28.26 real seconds = 579.76 KB/sec +++
ttcp-r: 2049 I/O calls, msec/call = 14.12, calls/sec = 72.51
ttcp-r: 0:28real

Without:

8.Ram Disk:> version 68030.library 
kan ej finna objektet
8.Ram Disk:> ttcp -s -r 
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket
ttcp-r: accept from 192.168.1.1
ttcp-r: 16777216 bytes in 24.16 real seconds = 678.15 KB/sec +++
ttcp-r: 2049 I/O calls, msec/call = 12.07, calls/sec = 84.81
ttcp-r: 0:24real
8.Ram Disk:> ttcp -s -r 
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket
ttcp-r: accept from 192.168.1.1
ttcp-r: 16777216 bytes in 24.14 real seconds = 678.71 KB/sec +++
ttcp-r: 2049 I/O calls, msec/call = 12.06, calls/sec = 84.88
ttcp-r: 0:24real

Not like half the speed, but at 16% difference, it was noticeable.

Would it be possible to add an option to increase the page size?

[patrik]

Originally Posted by Thomas Richter

This is not a matter of the implementation. It is the matter of a configuration, in particular of the page size. The default page size of the 68030 configuration is to use 1K pages, which is picked if the library finds the MMU unconfigured, otherwise it will pick whatever it finds.

The reason for that is that it is the most compatible setting that works under all Os configurations. All versions of Kickstart below 3.0 use a chip mem start address of 0x400, corresponding to a 1K zero-page zone. If a larger page size is used, parts of the chip mem will not be reachable by the CPU anymore, and accesses to this zone then have to be emulated, making the access to this region extremely slow. All higher kickstart versions use a zero-page start address of 0x1000, corresponding to 4K pages you find on the 68040 and 68060, which was a modification useful for these processors as they do not support a 1K page setup. Anything above 4K pages again causes the same trouble and should be avoided for that reason. The 68030 supports up to 32K page sizes, but that is too much also for some other applications - 16K would be an upper practical limit, which - however - already requires preparation of a larger zero page size. This happened in Os 3.1.4.

In how much a particular configuration impacts performance depends on the application and how its memory access pattern looks.

Thus, in total:
Kickstart < 3.0 : most practical setting is the one present, 1K pages.
Kickstart < 3.1.4: most practical page size is 4k
Kickstart >= 3.1.4: most practical page size is 16k

If it finds the MMU unconfigured, could it be improved to check for start of chipmem to be able to decide to use a larger and better performing page size instead of defaulting to 1k?

[SpeedGeek]

Originally Posted by patrik

If it finds the MMU unconfigured, could it be improved to check for start of chipmem to be able to decide to use a larger and better performing page size instead of defaulting to 1k?

Is there any reason you can't just use CPU FastROM? Since, I already explained this in great detail and even updated the benchmark tool I think it's a fair question to ask.

[hooverphonique]

Originally Posted by Thomas Richter

All versions of Kickstart below 3.0 use a chip mem start address of 0x400, corresponding to a 1K zero-page zone. If a larger page size is used, parts of the chip mem will not be reachable by the CPU anymore, and accesses to this zone then have to be emulated, making the access to this region extremely slow. All higher kickstart versions use a zero-page start address of 0x1000, corresponding to 4K pages you find on the 68040 and 68060, which was a modification useful for these processors as they do not support a 1K page setup.

I Always wondered why the chip memory pool on my A4000 started at $1000, even though the exception vectors are all below $400 - now I know.