CompuServe Thread

Trent, A couple of questions… 1. I'm using WB 2.1. However, my Kickstart on boot-up is version 37.175, the same as WB 2.04. Is this normal? 2. How do I get a copy of SetPatch V40.16? I could only find V40.14 in the libraries. BTW, I've found that my system worked with Gigamem and GVPCPUCTRL V1.14 only ONCE! After one successful boot, with Gigamem up and running and humming along with AdPro, my problems returned on the second warm boot. I do not understand, and would like to try your solution. Thanks in advance. Stephen Bailey Sawyer & Bailey Film and Video – Chicago

Trent, My cpu and GVPCpuCtrl are at the top of the User-Startup already. I have tried all possible combinations of setpatch 40.16, 40.14, 38.31, GVPCpuCtrl 1.14, 1.15, 1.16 and 68040.library 37.10 and 37.30. One combination would give a single warm start with 37.30, but then no cold or warm boot after that. My sense is that GVP had to kludge (they would, I'm sure, call it 'elegant engineering') the 68040 implementation like they did their SCSI device (evidence the 'pulsing HD light show' that gets truley ridiculous with two or more removable media devices in the system) because of C= limitations at the time that GVP was ready to release thier product. The fact that you need a GVPCpuCtrl instead of being able to use the cpu commmand for FASTROM says something about the non-standard nature of the GVP hardware, I'm guessing. It probably has to do with mapping the 32 bit RAM outside Autoconfig space – who knows. Anyway, (guessing again) it is possible that after C= standardized the handling of MMU and MCP inclusive processors on the 16 bit Zorro II bus, GVP found they were not in compliance and just continued to provide software to 'fix' hardware issues. Anyway, my experience with GVP hardware in the past is that there are many revisions of their hardware issued under the same name. For example, I have a Combo '030 card that, for over a year, GVP tech support insited had certain jumpers which in fact it did not. Only one guy admitted that some cards were made without these jumpers, and he had already given his notice so I guess he felt safe in admitting that such hardware existed. Anyway, instead of just swapping for a 'correct' board, GVP thinks it saves money by throwing ever-increasing patches at the problem and inadequate answers at the users who are stuck with the hardware that all of a sudden, no longer works with later OS revisions. Another problem is that the patches and GVP ROM upgrades usually break something unrelated to what you were trying to fix in the first place. But this is the price we pay for companies that try to get products to market when we want them in spite of, how shall we say, luke-warm support from the machine maker. My worry is that the revision/production run from which my GFOrce-040 came from has an EC040 on it instead of the 68040. (I had heard that there was a Motorolla production run where all the MMU-less chips were mislabled.) The reason that seems like a possibility is that the use of the FASTROM option without SSP gives no speed difference at all. Second, the board seems to be incompatible with the version of the 68040.library that adds MMU service to the OS. A chip with no MMU would barf on any attempt to remap ROM using the MMU interfaces of the standard 040. wmc – via Autopilot!