cpb@doc.ic.ac.uk (C P Brown) (03/18/91)
I'm using Dave Haynie's SetCPU V1.6 with an '030 board on an A500, and I see that there is an option to add ROMS from expansion devices into 32-bit memory. The documentation mentions the codes required for the 2090A disk controller. Does anyone know the equivalent codes for the A590 ROMs? Such things as manufacturer and product code, start and end address, length are needed. Also the documentation seems to be a little out of date as there are some options in SetCPU1.6 which are not mentioned in the docs. I'm particularly interested in the KickBoot option with KeepExec. I reckon by the sound of it that this will load Kickstart from the indicated disk/file and retain the Exec as currently colnfigured. Will this keep the memory structure nodes intact I wonder? Also, how does one get Kickstart into a file? Thanks for any help, email preferred. Phil
daveh@cbmvax.commodore.com (Dave Haynie) (03/20/91)
In article <3026@gould.doc.ic.ac.uk> cpb@doc.ic.ac.uk (C P Brown) writes: >I'm using Dave Haynie's SetCPU V1.6 with an '030 board on an A500, and >I see that there is an option to add ROMS from expansion devices into >32-bit memory. The documentation mentions the codes required for the 2090A >disk controller. I never found an A590/A2091 setting that works. It could be that the grain of the A590/A2091's ROM vs. I/O registers is too tight. Also, I'm not entirely sure the A590/A2091 runs the code out of ROM -- you have your choice as a device driver writer with autoboot ROMs of running from ROM or RAM if you have 16 bit ROMs, as I understand it anyway. In any case, that setting probably won't show much improvement with an A590/A2091 anyway; certainly nowhere as much as it did for the A2090a. >Also the documentation seems to be a little out of date as there are some >options in SetCPU1.6 which are not mentioned in the docs. I'm particularly >interested in the KickBoot option with KeepExec. There's no such option as KICKBOOT. That's probably KICKROM you're thinking of. The documentation (at least the documentation I supplied with the 1.6 distribution) does mention KEEPEXEC under the KICKROM section. Essentially, you can get into trouble booting with Exec still intact in many cases. When you normally do a warm reboot, Exec will wake up, find ExecBase still intact, and generally assume that a few of the things ExecBase knew about, like the amount of Chip RAM available, is correct. However, SetCPU temporarily hijacks a chunk of Chip RAM to effect its reboot. You get that back when you type SetCPU FASTROM or SETCPU KICKROM under the new OS (SetCPU maintains three kinds of FASTROMs -- the FASTROM, you get via the FASTROM option with no reboot, a SLOWKICK, which is KICKROM with ROM image in Chip RAM, and FASTKICK, which is KICKROM with the ROM moved into Fast RAM). Anyway, if Exec is left intact during the KICKROM operation, the Chip RAM that SetCPU gives back may already be in Exec's memory lists, depending on what your setup is. So KICKROM will normally clobber ExecBase. Just in case you don't want that clobbering to take place, you can specify KEEPEXEC. >I reckon by the sound of it that this will load Kickstart from the indicated >disk/file and retain the Exec as currently colnfigured. Will this keep the >memory structure nodes intact I wonder? Well, it may. You still have to reset, but you might possibly find things like recoverable RAMDisks still around. That depends more on the Exec versions than SetCPU, but somewhat on SetCPU, too, since it does in fact hijack this Chip RAM, it doesn't AllocMem() it or anything. SetCPU essentially becomes the operating system for a moment or two during the rebooting process, where it runs Exec in an ever-so-slightly virtual environment, hiding Chip RAM, tricking the system into rebooting out of SetCPU rather than ROM, etc. It took many nights of hacking, and lots of Guinness, to figure that part out. >Also, how does one get Kickstart into a file? You can do something like this in C, for 256K ROMs. void main() { FILE *file = fopen("SYS:KickStart","w"); char *buf = (char *)0x00fc0000; if (file) { fwrite(buf,1,0x00040000,file); fclose(file); } } If you have a KickStart disk instead, you can write a program, or use your favorite disk sector editor, to copy disk blocks 1 though 512 out to floppy. A good starting point for the code would be to close the code SetCPU itself uses to read in the floppy's ROM image, since the source code is provided (again, at least the way I sent it out). By the way, if you dump ROM, make small edits to the image, and load it something like: SetCPU FASTROM SYS:KickStart SetCPU will, in fact, load the ever-so-slightly modified ROM image without forcing you to reboot. This is basically to support the kind of patch hacks like SetCPU V1.5 did for you automatically, without me getting blamed for them. But don't tell the software guys, they would consider this evil too. >Phil -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "What works for me might work for you" -Jimmy Buffett
jason@cbmami.UUCP (Jason Goldberg) (03/20/91)
In article <19989@cbmvax.commodore.com>, Dave Haynie writes: > You can do something like this in C, for 256K ROMs. > > void main() { > FILE *file = fopen("SYS:KickStart","w"); > char *buf = (char *)0x00fc0000; > > if (file) { > fwrite(buf,1,0x00040000,file); > fclose(file); > } > } > Can you imagine a MAC engineer giving code to dump Apple ROMs to disk? :-) P.S. Won't the software guys yell at you for going straight to that hardware address? -Jason- --------------------------------------------------------------------------- Jason Goldberg UUCP: ucsd!serene!cbmami!jason Del Mar, CA
David.Plummer@f70.n140.z1.FIDONET.ORG (David Plummer) (03/29/91)
JG>
JG> > You can do something like this in C, for 256K ROMs.
JG> >
JG> > void main() {
JG> > FILE *file = fopen("SYS:KickStart","w");
JG> > char *buf = (char *)0x00fc0000;
JG> >
JG> > if (file) {
JG> > fwrite(buf,1,0x00040000,file);
JG> > fclose(file);
JG> > }
JG> > }
JG> >
JG> Can you imagine a MAC engineer giving code to dump Apple ROMs to
JG> disk? :-)
JG>
JG> P.S. Won't the software guys yell at you for going straight to that
JG> hardware address?
JG>
JG>
JG> -Jason-
JG>
What did you want, DumpRomDisk(FILE *image) calls in Kickstart!?!?
--
David Plummer - via FidoNet node 1:140/22
UUCP: ...!herald!weyr!70!David.Plummer
Domain: David.Plummer@f70.n140.z1.FIDONET.ORG
Standard Disclaimers Apply...