hunt@tramp.Colorado.EDU (Lee Cameron Hunt) (12/17/89)
I'm the proud owner of a new A2630. I got mine scavaged from a 2500/30 so I don't have the associated manuals for it yet, so my question may be answered in there. But, here goes... I was looking around my local BBS for programs for 68020/30 machines and ran across SetCPU (v. 1.5a), Dave Haynie. I started using the FASTROM option and that seems to speed things up nicely. In the SetCPU docs, Dave mentions that he turns on the instruction cache, off the data cache, and turns off bursting (NOBURST) for both data and instructions. My question is: first, why turn off data caching and, second, why exacty is data and instruction bursting? (I guess that's actually a two-question question, oh well...). I seem to remember vaguely conservations about this utility a while back (and I didn't pay much attention since I just had a plain 2000). However, I *think* I remember the data cache being turned off for fear of DMA controllers screwing up somehow (I have a HardFrame 2000). But, when I try turning both the CACHE and BURST flags on (for data and inst.) things seem to work fine. So, should I worry about having these options enabled? Also, what does the file "KickFile" do that comes with SetCPU? And, finally could anybody give me or tell me how to obtain a CardROMList entry for a HardFrame 2000? Thanks ahead of time! (No more of this "thanks in advance" stuff! :-) --Lee p.s. Maybe this is standard practice for SIMMs but I still am a bit agast by the fact that in order to add the extra 2Mb of on-board 32-bit RAM you must solder them in. (!) Why not spend a few more $$s in manufacturing costs and add sockets? (I assume there are SIMM sockets). Oh, yeah, Dave: when you do figure out how one can add faster 32-bit RAM (so the board will have fewer or no async. wait states) please let us know. (I believe you posted saying it involved cutting a trace or something). One final, final, thing: I heard thru the graphvine that Amix could be added to these coprocssor boards. Where do the ROMs for Amix attach? On the memory daughterboard connector? In one of the already-filled socketed ROMs on the A2630? This inquring mind wants to know!
daveh@cbmvax.commodore.com (Dave Haynie) (12/20/89)
in article <14956@boulder.Colorado.EDU>, hunt@tramp.Colorado.EDU (Lee Cameron Hunt) says: > Keywords: cache, burst, why? > I was looking around my local BBS for programs for 68020/30 machines and > ran across SetCPU (v. 1.5a), Dave Haynie. If it says 1.5a, you might have something weird. There was a 1.5 Alpha, though I don't think I gave it out, and a few Beta versions which had very limited testing release. The release version says "V1.50" or something similar; I always use a numeric revision number. > In the SetCPU docs, Dave mentions that he turns on the instruction cache, > off the data cache, and turns off bursting (NOBURST) for both data and > instructions. Well, actually, the '030 and the OS do that, I just let them. The '030 comes up with all cache control stuff off. The 1.3 OS turns on the I-Cache, but as it doesn't really know about 68030s, it doesn't turn anything else on. > My question is: first, why turn off data caching and, second, why exacty > is data and instruction bursting? (I guess that's actually a two-question > question, oh well...). Data caching can in theory run into trouble with DMA activity, unless the device driver for your particular DMA device knows to flush the data cache after a transfer. In practice, this doesn't _seem_ to be a problem, but there's no guarantee. Data caching will mess up the Bridge Card software, though a accessory program called "CacheCard" that I wrote will take care of that problem. There's never any need to not enable the burst mode bits in normal operation, though they might not actually do anything. What burst modes do are to allow the 68030's caches to be loaded by line instead of longword from memory, and this line load can take less time than an equivalent load of four longwords. As these are loaded into the cache, there's no guarantee that any of the last three longwords in the line load will actually be used, but if you design it right and make burst loads much faster than simple longword loads, statistics will work in the favor of burst and it'll make things faster. Setting the burst bit won't do anything if you don't also enable the associated cache. Burst cycles are arbitrated in hardware, so if a memory system doesn't support burst (the A2630's on-board RAM doesn't), no bursting will be attempted. > But, when I try turning both the CACHE and BURST flags on (for data and > inst.) things seem to work fine. > So, should I worry about having these options enabled? The data caching is at your own risk for the moment, but it doesn't seem to me like much of a risk. I use it with the A2630 and both 2090A and 2091 hard drives and I've never had a problem, other than managing the Bridge Card, which has a 100% workaround. Theory states you can have trouble with it, but in practice it doesn't seem much to worry about. The 1.4 OS is supposed to make it easy for device drivers to flush the cache when theoretically required -- not such a big deal now, but don't expect that caches will remain at 256 bytes for long. > Also, what does the file "KickFile" do that comes with SetCPU? KickFile transfers a KickStart image to a ROM file, so that you can KickROM it with SetCPU off a hard disk if you like, rather than going to floppy every time. > And, finally could anybody give me or tell me how to obtain a CardROMList > entry for a HardFrame 2000? The SetCPU docs tell how to do this in the general case, but you'd have to contact Microbotics for the specifics. The thing to know is where ROM and where I/O are on the board; SetCPU can translate the ROM for you and things are cool, but if you tell it to translate I/O as well, you'll crash. > --Lee > p.s. Maybe this is standard practice for SIMMs but I still am a bit agast > by the fact that in order to add the extra 2Mb of on-board 32-bit RAM you > must solder them in. (!) Why not spend a few more $$s in manufacturing costs > and add sockets? (I assume there are SIMM sockets). Those are ZIPs, not SIMMs. There aren't any good sockets for them, far as we can tell. Unlike DIPs, if you push a ZIP into a standard socket (assuming you get one in the zig-zag pinout), all or most of the pins bend up instead of going into the sockets. So you'd really need an expert to install them in any case. If there had been room for DIPs, you would have had sockets. > Oh, yeah, Dave: when you do figure out how one can add faster 32-bit RAM > (so the board will have fewer or no async. wait states) please let us know. > (I believe you posted saying it involved cutting a trace or something). No, actually, I mentioned that the board can be programmed, via a PAL and a delay line, to support different combinations of CPU and RAM speed. No cuts should be required. There are limits, and it's the kind of thing I want to be real sure about before I mention the details for any particular setup. Even if it's a "hack at your own risk" modification, I want it to be as reliable as the Commmodore approved 25MHz setup. > One final, final, thing: I heard thru the graphvine that Amix could be > added to these coprocssor boards. Where do the ROMs for Amix attach? The on-board ROMs already have Amix support in them. Amix itself will probably be distributed on tape with a magic floppy to get you rolling. -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough