danbabcock@eklektik.UUCP (/dev/ph1) (07/18/90)
Brian Moffet wrote: >Could someone explain to me why the expansion memory to be used >for Amiga OS 2.0 has to be the first item on the bus (on a 1000)? [lots of good stuff deleted for brevity] >So, why does the memory that KS 2.0 going to be loaded into >have to be the first thing on the bus? Is there a sort of >bootstrap going on where a very small section of KS 2.0 >(enough to know how to deal with only 1 device is loaded) >is used, and then as soon as it knows about the memory, it loads >the rest into core and lets the major program take over the >auto-config? Yes, you're exactly right. What KickIt actually does is to hook a small routine (one like you suggested) into ColdCapture, then do a complete reset. The ColdCapture code is responsible for configuring the RAM card ("guaranteed" to the first device), then jumping to Kickstart 2.0. This is actually a rather clever scheme, because it lets you fully use and test the new Kickstart, including the autoconfig code, without requiring any temporary hacks (well, one temporary hack - the new Kickstart has to somehow learn about the RAM card in which it resides; I don't know how they do that...). >If the bootstrap scenario is the case, what would be the >problem with making the bootstrap code understand more than 1 >device on the bus? The problem is that the new Kickstart won't know about those other devices. Since they are already configured, they don't respond - so the OS thinks there isn't anything there (though it does somehow know about the first RAM card; see the above). If you just want to play with the new Kickstart, you can simply replace the reset/ColdCapture sequence with a JMP $200002 (also modify the code that scans for devices so that it doesn't reject the RAM card if it's not the first one). If you need to use other devices (like a hard drive controller), then you have to somehow force-feed the right stuff in one of the expansion.library lists after 2.0 is up and running. You lose the ability to autoboot in any case. All these dilemas are a result of the Kickstart code residing on an autoconfig card. If you could somehow load Kickstart 2.0 into a NON-autoconfig card (or better a hacked autoconfig card?), all these issues would disappear. (well, some of them?....:-)) To K.C. Lee : How's your 512K 1000 daughterboard hack coming? I'd be happy to modify your boot ROMs for you... -- Dan Babcock Voice: (412)-373-1753 Internet: danbabcock@eklektik.pgh.pa.us People/Link: DANBABCOCK
dzenc@GNU.AI.MIT.EDU (07/20/90)
In article <4661@eklektik.UUCP> danbabcock@eklektik.UUCP (/dev/ph1) writes: >Since they are already configured, they don't respond - so the OS thinks >there isn't anything there (though it does somehow know about the first RAM >card; see the above). If you just want to play with the new Kickstart, you >can simply replace the reset/ColdCapture sequence with a JMP $200002 >(also modify the code that scans for devices so that it doesn't >reject the RAM card if it's not the first one). If you need to use other devices >(like a hard drive controller), then you have to somehow force-feed the right >stuff in one of the expansion.library lists after 2.0 is up and running. You >lose the ability to autoboot in any case. Well, being jelous of all the people who were running 2.0, I had to figure out a way of doing it on my 500 (with 3 megs/85 meg hd) without dismantling it. The memory expander is the second thing on the bus, and doesn't have pass through, so there was no way to use KickIt without removing my HD controller. I've hacked up a boot disk which saves the proper config information, dis- ables AutoConfig, reboots, ManualConfigs (TM) the hard drive, loads 2.0 KS and starts it (reboots), ManualConfigs (TM) the hard drive, and AddMems the remaining 1.5 megs of memory. If anybody wants to play with it, I'm more than happy to send you the programs I've written, and the startup-sequence. -Dan >-- Dan Babcock >Voice: (412)-373-1753 >Internet: danbabcock@eklektik.pgh.pa.us >People/Link: DANBABCOCK ___________________________________________________________________________ | _______ |________________________________________| | || |o| Dan Zenchelsky | | | ||____| | | Any sufficiently advanced bug is | | | ___ | dzenc@gnu.ai.mit.edu | indistinguishable from a feature. | | |_|___|_| |______________-- Rich Kulawiec__________| |__________________________________|________________________________________|
peck@ral.rpi.edu (Joseph Peck) (07/20/90)
In article <4661@eklektik.UUCP> danbabcock@eklektik.UUCP (/dev/ph1) writes: >Brian Moffet wrote: > >>Could someone explain to me why the expansion memory to be used >>for Amiga OS 2.0 has to be the first item on the bus (on a 1000)? > >[lots of good stuff deleted for brevity] ditto > >All these dilemas are a result of the Kickstart code residing on an >autoconfig card. If you could somehow load Kickstart 2.0 into a NON-autoconfig >card (or better a hacked autoconfig card?), all these issues would disappear. >(well, some of them?....:-)) > Ah hah! Well, I have a spirit inboard 1000 with 1.5 meg. I am relatively sure that it uses the same pseudo-autoconfigure hooks that Dave Haynie wrote about. Is there any chance that I'll ever be able to use 2.0 on it? (Using kickit that is) An A3000 is in my distant future, but I would like to use and develop code that is compatible with 2.0 now. > >-- Dan Babcock >Voice: (412)-373-1753 >Internet: danbabcock@eklektik.pgh.pa.us >People/Link: DANBABCOCK Thanks for any info, Joe Peck peck@ral.rpi.edu "Commodore does Henry Ford one better. Actually 4095 better. We get a choice of colors!"
valentin@cbmvax.commodore.com (Valentin Pepelea) (07/21/90)
In article <4661@eklektik.UUCP> danbabcock@eklektik.UUCP (/dev/ph1) writes: >Brian Moffet wrote: > >> So, why does the memory that KS 2.0 going to be loaded into >> have to be the first thing on the bus? >> >> ... >> >> If the bootstrap scenario is the case, what would be the >> problem with making the bootstrap code understand more than 1 >> device on the bus? > > The problem is that the new Kickstart won't know about those other devices. > Since they are already configured, they don't respond - so the OS thinks > there isn't anything there. Exactly. That is why KickIt resets the machine, and the devices are re- Autoconfig'ed (tm) one by one. But an interesting problem arose with the GVP A3001 accelerator with built-in AT disk controller. Under WB 1.3 the memory would get autoconfigured first and the disk controlled second. Under 2.0 the disk controller would get autoconfigured first. Since the memory board would therefore not reappear at the same address, the KickIt process would not work. To solve that, I wrote MMUkick, which boots the new kickstart file using the MMU. The kickstart image and the MMUkick program are first loaded in CHIP ram, the MMU then translates that image at $F00000, a routine residing in CHIP ram is loaded into the instruction cache of the '020 or '030, executes a reset, re-enables CHIP memory and finally transfers control to $F00002. Upon a reset, FAST memory dissappears until it is re-autoconfigured and the boot-roms are seen where CHIP memory used to be. That means that if we want to do anything special after a reset instruction, we must be executing out of the instruction cache of the CPU. Wonderful. The MMUkick command then must also be inserted early in the startup sequence, so that it may copy the kickstart image from CHIP ram into FAST ram, and prevent that memory block from being allocated. If the command is not executed, eventually the CHIP memory area in which the kickstart image is located will be allocated and overwritten. The GVP accelerator was not too happy to comply with this new utility though. First of all, not only were data fetches to CHIP memory cache inhibited, but instruction fetches were too! So while the code that transfered control to $F00002 had to be residing in CHIP ram, the code that turns the boot-rom off and the CHIP ram on had to be loaded into the instruction cache from FAST ram. God what a nightmare, but boy what a hack! The GVP accelerator recognizing the genial method by which all its defenses were being broken decided to use its secret weapon. It would simply refuse to propagate the RESET from the CPU to external devices. The GVP engineers at this point feared that the artificial intelligence PALs put into their board were organizing a revolt and therefore promptly made new ones that fixed the RESET problem and did not inhibit caching of CHIP ram instruction fetches. The 50,000 line Lisp program was also turned off. You may obtain a new set of well disciplined PALs freely for your GVP board by simply calling the GVP folks. The MMUkick utility is available from CATS for US and Canadian devellopers, and from your country's Technical Support Manager is you are residing in Europe. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
daveh@cbmvax.commodore.com (Dave Haynie) (07/24/90)
In article <13352@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: >To solve that, I wrote MMUkick, which boots the new kickstart file using the >MMU. The kickstart image and the MMUkick program are first loaded in CHIP ram, >the MMU then translates that image at $F00000, a routine residing in CHIP >ram is loaded into the instruction cache of the '020 or '030, executes a reset, >re-enables CHIP memory and finally transfers control to $F00002. [...] The >MMUkick utility is available from CATS for US and Canadian devellopers, and >from your country's Technical Support Manager is you are residing in Europe. The latest version of SetCPU, V1.6, provides similar functionality. While the load mechanism is a bit different, it winds up working very similarly to MMUKick, rebooting an alternate OS through Chip RAM. It supports both 256K and 512K ROM images assembled for $00fc0000, $00f80000, $00f00000, and probably other locations we haven't thought of yet. It's quasi-supported by me, actual, real, and naturally unrestricted Public Domain (source and binary), and may even make it to this here network, or a Fish Disk, one of these days... >Valentin -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy The Dave Haynie branch of the New Zealand Fan Club
SRWMCLN@windy.dsir.govt.nz (Clive Nicolson) (07/25/90)
In article <13385@cbmvax.commodore.com>, daveh@cbmvax.commodore.com (Dave Haynie) writes: > > Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > The Dave Haynie branch of the New Zealand Fan Club I can only assume that you are comming down this way (NZ) soon.?!?. Clive.
danbabcock@eklektik.UUCP (/dev/ph1) (07/25/90)
Joe Peck (peck@ral.rpi.edu) wrote: [I'm not going to re-quote everybody (there ought to be a law...:-)] >Ah hah! Well, I have a spirit inboard 1000 with 1.5 meg. I am relatively >sure that it uses the same pseudo-autoconfigure hooks that Dave Haynie >wrote about. Is there any chance that I'll ever be able to use 2.0 on >it? (Using kickit that is) An A3000 is in my distant future, but I >would like to use and develop code that is compatible with 2.0 now. Well, it doesn't have the problem of going away at reset that autoconfig cards do, so - yes - it would be a great home for Kickstart. I should mention that KS1.2/1.3 really mishandles this memory. If ExecBase gets smashed (a fairly common thing) the startup routine fills this memory with zeros. Also, the memory test is destructive (but that only matters if you fix the "feature" just mentioned). This is not good. It means that using a RRD (recoverable RAM disk) is a risky business. Of course, since you are using a 1000, you can easily modify your Kickstart disk to avoid all these problems. There's just one small problem. Commodore does not currently supply a version of 2.0 that was assembled/compiled for $C00,000 (The one they distribute to developers is assembled/compiled for $200,000. The one in the 3000 is assembled/compiled for $F80,000 but they use the MMU to place it wherever they want physically). Of course, as Albert (hp4nl!neabbs!ajbrouw) suggested, C= could supply an easy-to-use utility for relocating Kickstart to any address, but they might not do that, for the usual reason (laziness). Of course, a patient person could do it himself, using just the final object code, if he were so inclined (when the final version comes out, that is; it doesn't make too much sense when there is a new version every hour). If you do get access to a machine with memory at $200000, be sure to contact Dan Zenchelsky (dzenc@gnu.ai.mit.edu); he wrote some really nice utilities to make life easier (see previous postings, if possible, for details). -- Dan Babcock Voice: (412)-373-1753 Internet: danbabcock@eklektik.pgh.pa.us People/Link: DANBABCOCK > Thanks for any info, > Joe Peck > peck@ral.rpi.edu