campbellb@gtephx.UUCP (Brian Campbell) (07/18/89)
As Brian W. explained, it seems that software that requires a card to be in a certain hard-coded slot position is a mark of sloppy programming. I would agree that this generally true, although there could be occasional exceptions. Having flexible slot assignments does make programming the card ROM more difficult. It also seems that code must be relocatable, and that means that JSRs in the ROM to subroutines in the ROM are not possible. Is this true? Anyway, my main point is that even with flexible slot assignments there is a "preferred" assignment scheme. This means that the certain cards are recommended in certain slots, but can be put in other locations at the users discretion. I thought this was due to the following reasoning. Is this description accurate and anywhere close to the mark? In the pre-IIGS days, the apple bootup sequence always started by scanning the slots, starting in slot 7, and continuing down to slot 1, if need be. As soon as it finds a slot with a card, it stops scanning and it starts executing the ROM on that card. For example, since it never makes sense to boot off of a printer, you put that down in a low slot position, like #1. Since, it makes sense to boot off of a disk, you put that in a high slot position. But use #6 (not #7) in case you want to add hard disk later. It makes more sense to boot off of a hard disk if you have it, so you want to put that in the highest slot (#7). The point of all of this, is that by using preferred slots you reduce the chances of having to re-arrange the positions of existing cards when adding a new one. For example, if you had a printer card in slot 1, and a disk card in slot 2, where would you add the serial card that you bought six months later? If you put it in a higher slot the system would try to boot off of it. You would have to keep moving your disk card to a higher slot position as you added cards, unless it was in a high slot already. With the IIGS, this behavior can be made obsolete. From the control panel, one can either specify that the old style scanning be done, or SPECIFY A PARTICULAR SLOT to boot from. This means that the cards can be in any ol' position, although, this may not mean as much with the slots being predefined. Or it may mean a lot. I prefer to boot directly from slot 5 (via my 3.5" drive) rather than scan down to slot 6 which has my 5.25" drive (which is often has either no disk or has a data disk).
mwedel@hobbes.uucp (Mark Wedel) (07/19/89)
One of the other main reasons while cards have standard locations is because apple Pascal dictated it. With pascal, you had to have your floppy drive in slot 6, second in slot 5, third in slot 4, and I'm not sure of the fourth. Also, it would only take a printer card in slot 1 and a communications card in slot 2. Because of this, many people followed this convention, so that if they used pascal, they would have the full powers of all their cards and so that they would not have to re-arrange it when using.. As for booting, I'm not sure, but I think the computer may be smart enough to know what it can and cannot boot (if you put a printer card in slot 7, and disk controller in slot 6, it might just boot slot 6, and ignore the printer card..) I'm not sure if the new version of Apple Pascal still needs these standard slot locations. Mark Wedel mwedel@hobbes.Tymnet.Com ...ucbvax!hplabs!oliveb!tymix!hobbes!mwedel
dlyons@Apple.COM (David Lyons) (07/19/89)
In article <447ed450.f759@gtephx.UUCP> campbellb@gtephx.UUCP (Brian Campbell) writes: > [...] Having flexible slot assignments does >make programming the card ROM more difficult. It also seems that code must >be relocatable, and that means that JSRs in the ROM to subroutines in the ROM >are not possible. Is this true? [...] True--you can't just JSR $Cnxx from the $Cnxx space without assuming you know what slot you're in. For simple ROMs, the answer is to simply not make JSRs to your own ROM code. For more complicated ROM, you can take advantage of the $C800-$CFFE space, which is *shared* (more or less carefully) between different slots. Only one slot "owns" this space at a time, any twiddling $CFFF tells all cards they no longer own it. As soon as $Cnxx is twiddled, slot n owns the space until $CFFF is twiddled. So you can put your subroutines in the $C800-$CFFE space and JSR them with no problems. 'course, if some cards forget to twiddle $CFFF before assuming they own that space, there can be problems. (There *are* cards like that out there, and I *can't imagine* what company would have produced them.... :-) > [...] since it never makes sense to boot off of a printer, >you put that down in a low slot position, like #1. Since, it makes sense to >boot off of a disk, you put that in a high slot position. Except that the system is smart enough to realize when a card is not a bootable device--it looks at $Cn01, $Cn03, and $Cn05 for the values $20, $00, $03 to identify it as bootable. (I think the ROMs *before* the enhanced IIe also looked at $Cn07, but I'd have to look it up.) --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
dseah@wpi.wpi.edu (David I Seah) (07/20/89)
Some other feller writes: >> [...] since it never makes sense to boot off of a printer, >>you put that down in a low slot position, like #1. Since, it makes sense to >>boot off of a disk, you put that in a high slot position. Dave Lyons reponds: >Except that the system is smart enough to realize when a card is not a bootable >device--it looks at $Cn01, $Cn03, and $Cn05 for the values $20, $00, $03 to >identify it as bootable. (I think the ROMs *before* the enhanced IIe also >looked at $Cn07, but I'd have to look it up.) It might be fun to take an old Grappler or old unused interface card with a removable EPROM and reprogram it for some fun. As long as the boot device signature bytes are intact, one could probably have the reprogrammed card do something interesting like print "SWOOSH" or make a rude noise or put up a little icon of some kind on the screen identifying the computer as "MINE!" Afterwards, the firmware could get back control and continue scanning down the slots. Sound feasible? I've heard that the Transwarp GS board puts up a graphics screen when you powerup. If this is true, how does the Transwarp get control? Does it immediately pull a non maskable interrupt and grab the buses, then control the Apple in all its entirety? Dave Seah | O M N I D Y N E S Y S T E M S - M | Internet: dseah@wpi.wpi.edu | "User Friendly Killing Machines" | AlinkPE: AFC DaveS | A Division of SLO, International | Bitnet: dseah@wpi.bitnet
brianw@microsoft.UUCP (Brian Willoughby) (07/20/89)
Dave seems to have answered all the questions, but I still haven't
figured out why my Laser Universal Disk Controller (and Apple 3.5 Drive)
won't auto boot on my II+. I guess the ID bytes are incorrect for the
routine in the II+ boot ROM. I've tried it in slot 6 as the only drive
controller, and the Applesoft prompt just appears, like there is no
disk peripheral.
Oh, the woes of outdated systems :-)
Brian Willoughby
UUCP: ...!{tikal, sun, uunet, elwood}!microsoft!brianw
InterNet: microsoft!brianw@uunet.UU.NET
or: microsoft!brianw@Sun.COM
Bitnet brianw@microsoft.UUCPSEWALL@UCONNVM.BITNET (Murph Sewall) (07/20/89)
>I've heard that the Transwarp GS board puts up a graphics screen when you >powerup. If this is true, how does the Transwarp get control? Does it >immediately pull a non maskable interrupt and grab the buses, then control the >Apple in all its entirety? The TWGS is the MAIN CPU! (recall it REPLACES the 65816 that comes from the factory). It's not too surprising thaat the accelerator has some power up diagnostics, etc. Adding a little code to display a graphic ahead of the 'bootstrap' ROM is no hassle (assuming the capacity of whatever on-board chip contains the power-up ROM has more memory than is needed for that purpose). Murph Sewall Vaporware? ---> [Gary Larson returns 1/1/90] Prof. of Marketing Sewall@UConnVM.BITNET Business School sewall%uconnvm.bitnet@mitvma.mit.edu [INTERNET] U of Connecticut {psuvax1 or mcvax }!UCONNVM.BITNET!SEWALL [UUCP] (203) 486-5246 [FAX] (203) 486-2489 [PHONE] 41 49N 72 15W [ICBM] -+- I don't speak for my employer, though I frequently wish that I could (subject to change without notice; void where prohibited)
matthew@sunpix.UUCP ( Sun Visualization Products) (07/22/89)
In article <7012@microsoft.UUCP>, Brian Willoughby writes: | | | Dave seems to have answered all the questions, but I still haven't | figured out why my Laser Universal Disk Controller (and Apple 3.5 Drive) | won't auto boot on my II+. I guess the ID bytes are incorrect for the | routine in the II+ boot ROM. I've tried it in slot 6 as the only drive | controller, and the Applesoft prompt just appears, like there is no | disk peripheral. | | Oh, the woes of outdated systems :-) | | Brian Willoughby | UUCP: ...!{tikal, sun, uunet, elwood}!microsoft!brianw Brian, The reason why your UDC won't boot from power-on, is that Apple reduced the number of bytes to check for a disk controller card from 4 to 3. The reasoning behind this? Apple Pascal identifies drives by the same 4 bytes as the old monitors use to do. ($01, $03, $05, $07). Since Apple Pascal did not know about the new disk drive, and since Apple Comp. did not want Apple Pascal confusing any non-Disk ][ drive as a Disk ][ drive, they eliminated byte $07 from the list of valid ID bytes. (Actually it can be used to test to see if the drive is a Disk ][ or not). The fix for your older system? If you have modified, or are going to modify, your monitor rom, search for the autoboot search routine. It starts by loading a value of $07 into one of the registers, just replace the $07 with a $05. Thats all there is to it. (Matter of fact, thats all Apple did to the boot routine when they came out with the enhanced Apple //e roms). -- Matthew Lee Stier | Sun Microsystems --- RTP, NC 27709-3447 | "Wisconsin Escapee" uucp: sun!mstier or mcnc!rti!sunpix!matthew | phone: (919) 469-8300 fax: (919) 460-8355 |
APTC1%MKVAX1@MSUS1.BITNET (07/22/89)
Correct me if I'm wrong, but wasn't it rather out of the ordinary to have a hard drive back in the first Apple ][ (before the ][+, heck even when the ][+ came out). That was back when the good drives were those huge Winchester packs that held a whole 15 or 20 megs. Now if my first premis is correct, why would apple build a computer (targeted as a home computer) with the idea of sticking a hard drive on it? aptc1%mkvax1@msus1.bitnet
SEWALL@UCONNVM.BITNET (Murph Sewall) (07/23/89)
>Correct me if I'm wrong, but wasn't it rather out of the ordinary to have a >hard drive back in the first Apple ][ (before the ][+, heck even when the >][+ came out). That was back when the good drives were those huge Winchester >packs that held a whole 15 or 20 megs. Now if my first premis is correct, >why would apple build a computer (targeted as a home computer) with the idea >of sticking a hard drive on it? The *BEAUTY* of the Apple ][ design was it was developed on the notion that all manner of here-to-fore unheard of devices might become available to be added in the future. Any student of innovation in 1979 would have *expected* pocket sized hard disks with 100+ MByte capacities by (probably) the turn of the century if not sooner. Woz had the idea that an Apple owner might want to stick almost *anything* into it. Somebody (Steve Jobs?) forgot the elegance of the original concept while designing the Macintosh (a processor capable of addressing 16 Mbytes of RAM locked into a box designed for only 512K) Even without the benefit of hindsight, it was clear that Apple's excuses were 'dense.' 1. DRAM is too expensive (RAM costs had been falling like the proverbial stone for half a decade with no sign of let up; anyone with a shirt pocket calculator could predict when the price for an Mbyte or RAM would be below the cost of 100 Kbytes in 1980). 2. Color is too expensive (the Japanese had already started development on HDTV; color TV prices had been falling steadily since 1965!) 3. The 'mass market' didn't want "open architecture" (so howcome the Apple 2 wiped out earlier closed CP/M machines wholesale and continued to outsell less expensive competitors, such as the Commodore 64, which were not nearly as adaptable?). Although Apple does appear to be learning something from the market place, I read recently that Apple (the MBA's at Apple, not DTS I suspect) is surprised at the sales strength of the IIcx (with 3-slots) compared to the SE-30 (with only one slot). Murph Sewall Vaporware? ---> [Gary Larson returns 1/1/90] Prof. of Marketing Sewall@UConnVM.BITNET Business School sewall%uconnvm.bitnet@mitvma.mit.edu [INTERNET] U of Connecticut {psuvax1 or mcvax }!UCONNVM.BITNET!SEWALL [UUCP] (203) 486-5246 [FAX] (203) 486-2489 [PHONE] 41 49N 72 15W [ICBM] -+- I don't speak for my employer, though I frequently wish that I could (subject to change without notice; void where prohibited)
samt@pro-europa.cts.com (Sam Theis) (07/23/89)
Comment to message from: pnet01!crash!apple.com!oliveb!tymix!hobbes!mwedel (Mark Wedel)
The latest released version of Apple Pascal (1.3) still is picky about slots.
It doesn't support disks in slot 7, just 4, 5 and 6. Good ol' UCSD P-code.
----
UUCP: {nosc, uunet!cacilj, sdcsvax, hplabs!hp-sdd, sun.com}
...!crash!pnet01!pro-nsfmat!pro-europa!SamT
ARPA: crash!pnet01!pro-nsfmat!pro-europa!SamT@nosc.mil
INET: SamT@pro-europa.cts.com - BITNET: pro-europa.uucp!SamT@psuvax1rlw@pro-embassy.UUCP (Ron Wilson) (10/08/89)
Network Comment: to #151 by obsolete!asuvax!hrc!gtephx!campbellb%handies.ucar.edu The firmware on the old ]['s was smart enough to not try to boot from a printer card - I know - I once put a printer card in slot 7 with a Disk ][ card in 6 - it booted just fine. Besides, what if you had a printer card but no disk?
fiddler%concertina@Sun.COM (Steve Hix) (10/13/89)
In article <8910101231.AA13463@trout.nosc.mil>, rlw@pro-embassy.UUCP (Ron Wilson) writes: > Network Comment: to #151 by obsolete!asuvax!hrc!gtephx!campbellb%handies.ucar.edu > > The firmware on the old ]['s was smart enough to not try to boot > from a printer card - I know - I once put a printer card in slot 7 > with a Disk ][ card in 6 - it booted just fine. The firmware, on startup, would (still does, I suppose) scan all the slots, from 7 down, for a bootable device. Said device has a signature (value) in *its* ROM telling the //'s firmware routine to begin executing the card's ROM at address <mumble>. It won't try to boot off a printer or video card, but a disk or ROM card would be fair game. > Besides, what if you had a printer card but no disk? The // would quickly scan the slots, find no boot device, then jump into Applesoft (or Integer BASIC, if you had a ][ with no Applesoft card) and wait for you to type something. ------------ "...I was to learn later in life that we tend to meet any new situation by reorganizing: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralization." - Petronius Arbiter, 210 B.C.