[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
Hugh...
(H.HOOD, CAT9, TOP23, MSG:3/M645;1)
<<<<< I'd like to be able to make the change either from BASIC or the
""""" "monitor".
This is a IIe (actually, a Laser 128EX), so there are no CDA's.
_____
/ \
)=====(
\___+_/
..:... Hans
(H.HAUMANN, CAT9, TOP23, MSG:4/M645;1)
>>>>> Hans:
"""""
Please do something for me. After booting ProDOS and getting into BASIC.SYSTEM,
get into the monitor (type CALL -151) and do a listing of the contents from
$BF12 to $BF1F (type BF12L).
Please let me know what the HEX contents of these locations are. This is the
device driver address table for the slots that ProDOS uses. I _think_ we can
re-map Slot 7 to Slot 5 with one POKE _if_ you are using ProDOS 8 on the
program
you will be running.
Hugh..
(H.HOOD, CAT9, TOP23, MSG:5/M645;1)
<<<<< Coming up...
"""""
from ProDOS 8 vers. 2.0.2:
$BF12- 08 FD 08 FD 08 FD
$BF16- 08 FD 4E C5 00 D0 0D C7
_____
/ \
)=====(
\___+_/
..:... Hans
(H.HAUMANN, CAT9, TOP23, MSG:6/M645;1)
>>>>> Re: Changing slots in P8
"""""
I feel I need to comment on what's going on here.
Or, at least what I _think_ is going on here :) If the idea is to swap the
entries in the P8 device driver list, read on... If it isn't, then forget the
whole rest of this msg while I pull my foot out of my mouth :)
P8 stores its device driver table at $BF10 thru $BF2F. If I recall correctly,
the goal is to swap slot 5 with slot 7. The quick and dirty method is to take
the contents of $BF1A/1B and swap them with $BF1E/1F assuming drive 1 in both
cases. Depending on the device driver(s) in question, this might work. Here's
the problem tho: The MLI sets up a command block (device driver parameter
list)
prior to calling the device driver. One of those parameters in the command
block is UNIT NUMBER (found at $43) which is in the format: %DSSS0000, where D
is the drive number minus one, and SSS is the slot number. OK? Keep this in
mind. Next, let's take a look at the hardware side. Most external cards
can
be plugged into any slot and work. The easiest way to communicate with a card
is to read/write at the slot hardware _base_ address, using the X-Register to
specify the actual slot offset. For example, the assembly language instruction
LDA $C080,X where X=$10 would access slot 1. If X=$20, then the access would
be to slot 2, etc. So, the people who write device drivers, only need a base
address ($C080) and where their card is at (loaded in the X-Reg). Now, let's
put the two together.
1. The device driver needs the X-Register to be set to the slot number.
2. The MLI issues the slot number as part of the Unit Number.
Hmmm...If you were a device driver, where would you get that slot number??? :)
And everythings fine until.... someone _swaps_ the entries in the P8 device
driver table and _doesn't_ tell P8 about it :(
Say you have a 3.5 drive on slot 5, and a SCSI card in slot 7, and you swap the
device drivers. =Potentially= you have the 3.5 driver accessing the SCSI card,
and the SCSI driver accessing the 3.5 drive. +NOT+ what you want!!! AND- I
don't even want to think about what would happen if the two swapped entries
refered to different devices, i.e. a serial device and a block device. Yikes!
So, I can be wrong on this, because not all device drivers are written the same
way. Maybe it'll work for you, but I wanted to at least inform you that the
results may prove disasterous. Also, since I'm jumping in here, maybe I drew
the wrong conclusion about where this discussion was going to go, and in that
case Sorry!
BTW, I'm currently writing a P8 device driver to control an IDE HD with
multiple
partitions, which the user may map into unused P8 slots. (like the RamFAST).
The basic theory is to fill the unused P8 device driver vectors with my device
driver entry point and then translate the different Unit Numbers passed by the
MLI into the correct partition, there by creating virtual drives. If someone
tried to swap the entries, nothing would happen because the entries are the
same-- it's the Unit Number that makes the difference.
So, basicly, hot swapping the device driver entries is a BAD idea, in my
opinion, of course :)
-Sully
(All miss-spellings are my own :)
(R.SULLIVAN8, CAT9, TOP23, MSG:7/M645;1)
>>>>> Hans:
"""""
Sully knows exactly what I was hacking to do, and makes great points. Don't
worry though, I wasn't going to let you walk into the quicksand, at least not
without adequate warning and protection. <g>
Currently, what cards are in slots 5 and 7, respectively, and how many devices
are attached to each card? If slot 5 is the built-in diskport, how many drives
are attached?
Will the program from which you want to access the 'swapped' slot device
address
files on it from BASIC with BASIC.SYSTEM commands (e.g. LOAD X, S5,D1), or will
it address it from machine code?
BTW, before you even attempt to swap the $C7 0D for the $C5 4E with a few
POKES,
_everything_ needs to be backed up. Plus, unless Sully bales me out with the
answers, I need to re-read Gary Little's explanation about the whole mapping
procedure, as another location (Sully's $BF32,X) may also need to be massaged.
Of course, if you're a curious sort, and a bit impulsive, and if you've _got
everything backed up_, and your estate planning is in order, you can go ahead
with the POKES anyway, and let us know what happens. <g>
Hugh...
(H.HOOD, CAT9, TOP23, MSG:8/M645;1)
>>>>> Hans, Hugh,
"""""
I whipped up a short program that will correctly handle the slot 5/slot 7 swap
problem. This program applies a patch to P8 that will intercept calls to slot
5/7, fix the Unit Number, then passes (redirects) control to the opposite slot.
When the program is launched, it will relocate itself between the BI and the
buffers, so it is protected from other programs. The patch must be applied each
time Prodos is launched, but never twice in the same session. I'm emailing you
guys a copy of both the program and the Merlin source. I used GSHK with
BinaryII, hope that isn't a problem.
-Sully
(R.SULLIVAN8, CAT9, TOP23, MSG:9/M645;1)
<<<<< Hugh and Sully,
"""""
Actually, that's exactly what I want to streamline -- the HD backup process.
Here's what I've got:
The machine is a Laser 128EX with an expansion box, so I've got two available
expansion slots -- slot 5 and slot 7. Each slot is controlled by a hardware
switch. If I switch slot 5 "on", I can only access 128K of ram, and since I
use
AppleWorks a lot, slot 5 remains dedicated to ram. If I switch slot 7 "on", I
lose access to any 3.5" drive connected to the external drive port (a 5 1/4"
drive simply responds to s6,d2, but a 3.5" drive is addressed as s7,d1 -- same
port). So the problem is that I have three "devices" (1 MB of ram, HD, and
3.5"
drive) competing for two resources, but I only ever need any two of them at the
same time.
In normal use, I have 1 MB of extended ram tying up slot 5 and an Apple High-
Speed SCSI card in slot 7. For the occasions when I need to transfer a file to
(or from) a 3.5" drive, I simply set up a ramdisk, temporarily move the file
(or
disk) to the ramdrive, flip the switch, and reboot. Although this is fine for
the occasional transfer, it's not conducive to making even a single backup.
Backups to a 3.5" disk are not imposssible, but I have to physically move the
SCSI controller temporarily to slot 5 first. I want to avoid having to move
the
controller back and forth. Up until now, I've done that at the expense of
making any backups.
What's frustrating is that when I use a program like Copy-II-Plus, the 3.5"
drive activity light comes on for a moment as all the drives are polled, it
just
never shows up in the list of drives to be accessed until I switch slot 7 "off"
-- but then I can't access the HD.
After reading Sully's explanation of what needs to happen, I fear that
remapping
the slot won't provide a solution since that will probably remap the external
drive port to slot 5 as well. :-(
_____
/ \
)=====(
\___+_/
..:... Hans
(H.HAUMANN, CAT9, TOP23, MSG:11/M645;1)
>>>>> Hans,
"""""
I had a similar situation with a Laser awhile ago. The best solution ended up
being backing up to another device on the SCSI chain; I realize that might not
be suitable for you, but it was the best I could come up with.
Ryan
http://www.keystroke.net/~rsuenaga
"There's no shortage of windmills to tilt at."--Logan
ANSITerm and CoPilot v2.55
(A2LAMP, CAT9, TOP23, MSG:12/M645;1)
<<<<< Much as I hate to, I may just abandon the expansion box and mount
""""" the SCSI controller in the open from the side of the machine. At least
that way I won't need to physically move the controller to change slots -- I'll
just need to flip switches.
I tried to see if I could just add a jumper or two to make one of the slots in
the expansion module act the same as the slot in the side of the machine, but I
didn't see any obvious way to do it.
_____
/ \
)=====(
\___+_/
..:... Hans
(H.HAUMANN, CAT9, TOP23, MSG:14/M645;1)
>>>>> Hans,
"""""
You have an interesting situation there. I'm not sure why CopyII+ doesn't see
your drive. I'm with Ryan, tho- The easiest way would be to connect another
scsi device for backups. A Zip drive would be my recommendation.
-Sully
(R.SULLIVAN8, CAT9, TOP23, MSG:18/M645;1)
<<<<< Sully, A Zip drive on a IIe (or clone)? You mean I can just unplug
""""" my ZIP from my Performa and move it over to my Laser? Can I just use
an
AHS utility or ProSel-8 to format a ZIP disk?
_____
/ \
)=====(
\___+_/
..:... Hans
(H.HAUMANN, CAT9, TOP23, MSG:20/M645;1)
>>>>> Sure, why not? I had a Zip Drive running on one of my //es :)
"""""
> You mean I can just unplug my ZIP from my Performa and move it over to my
> Laser?
Provided you have a properly working existing SCSI chain and follow the
usual SCSI rules, sure. One caveat: watch out for the limit of 14 Prodos
devices.
> Can I just use an AHS utility or ProSel-8 to format a ZIP disk?
Yeah. . . use Chinook SCSI utils. That'll work fine. If not, use the AHS
SCSI utils. That'll work too, but Chinook's better.
Ryan
http://www.keystroke.net/~rsuenaga
"There's no shortage of windmills to tilt at."--Logan
ANSITerm and CoPilot v2.55
(A2LAMP, CAT9, TOP23, MSG:22/M645;1)
RAMFAST, PRODOS 8, AND FLOPTICALS Is there any way to set up a RamFAST
""""""""""""""""""""""""""""""""" Rev.D with the latest ROMs so that P8
programs such as AppleWorks will be able to use a Floptical drive?
I have tried to figure out the slot mapping, but my RamFAST manual has taken a
walk, and as I recall it wasn't very helpful. If I don't map slots, and try to
launch AppleWorks, I get a text error panel that says to insert /HD.PGM/,
which
is the name of the hard disk partition that has my copy of AW 5.1 on it. If I
map slots, AW doesn't recognize the Floptical drive.
Ideas?
Don V. Zahniser
Delivered by CoPilot for ANSITerm
(D.ZAHNISER, CAT20, TOP13, MSG:154/M645;1)
>>>>> I don't have (8-bit) AppleWorks, but I do have a Floptical and the
""""" same RF as you. Here are a few tips that might help:
* Cold Boot with a disk in the Floptical drive. RF acts a lot better when
it knows about the Floptical from the start.
* Once you're booted up, go into the RF Utilities and make sure your
Floptical disk is recognized, and that it's marked as ACTIVE. At this
time you can also note your SCSI IDs.
I believe the problem is the manual mapping. I wrestled with this problem
while
trying to get my PCT to work w/the Floptical. ProDOS seems to re-map volumes
upon entry to P8. What I noticed is that ProDOS replaced my Floptical with
/RAM3. (Using a CDA such as File-a-Trix is handy for listing what volumes are
considered on-line when you're in P8)
The only solution is to arrange your SCSI IDs in such a way that the all of the
volumes (Floptical, HD partitions, etc.) that you NEED to appear in P8 do so
with auto-mapping and don't exceed P8's 12 volume limit. This eliminates the
need for manual mapping. How much changing you have to do depends on your
setup. :/
I set my Floptical ID between my boot drive and my 2nd (bigger) drive. Since
there are 3 partitions on my boot drive, the Floptical appears as the 4th
volume
and shows up in P8 just fine.
_/\_/\__
/ o o\___
// \________/
// \ Wily
(P.CREAGER, CAT20, TOP13, MSG:160/M645;1)
<<<<< Wily (and anyone else with a RamFAST)
"""""
Playing around with Wily's recommendations, I stumbled upon the following
procedure for getting RamFAST to automagically recognize any disk in the
Floptical drive under P8. It has interesting implications for users of other
removable media drives, I am sure.
1) Shut off the GS
2) Insert an unformatted disk (or disk from an inactive FST) into the
Floptical drive.
3) Boot the GS into the RamFAST Utilities by holding the zero key down. What
you
should see on the right-hand side is your usual list of volumes, except that
for
the Floptical drive, you should see a generic volume name based on the SCSI ID
of the Floptical device. On my system, this generic name is CVTECH.ID4.A (The
device name is CVTECH.S7.F).
4) Map the generic volume name into an empty slot. What you will find at this
point is that any disk that you put into the Floptical drive will be mapped to
the same slot to which you mapped the generic volume name.
I stumbled into this when I put a HD disk from GNN into the Floptical drive.
Curiously, Finder polled the drive, and did nothing with it. No Icon, no error
message. I went into RamFAST Utilities, and there was the generic volume ID.
Further analysis with UniverseMaster and UtilityWorksGS seem to indicate that
the disk name has 'illegal' characters that aren't recognized by the MS-DOS
FST.
I have 2 AOL disks with the same syndrome. I have been able to format these
with RamFAST Utilities where GSOS programs won't.
I was able to reproduce the sequence above by deactivating the MS-DOS FST prior
to shutting off the GS, and using an MS-DOS disk in the Floptical drive when I
booted it into RamFAST Utilities.
Don V. Zahniser
Delivered by CoPilot for ANSITerm
(D.ZAHNISER, CAT20, TOP13, MSG:161/M645;1)
<<<<< I just found out there may be an intermediate step missing from my
""""" previous post. It _may_ be necessary to go into SCSI Utilities while
in
RamFAST.Util and click on the device containing the 'unrecognizable' disk
prior
to mapping the generic volume name to the slot. Here are some alternate
instructions to try:
1) Launch RamFAST Utilities.
2) Insert media that is known to be not recognized by Prodos or installed FSTs.
3) Click on SCSI Utilities, then click on the device containing the media. One
or more generic partition IDs should appear on the right side of the screen.
Click 'Quit' to return to the main RamFAST Utilities panel. Depending on the
contents of the media, one or more new volumes (one or more of which should be
generically named with the SCSI ID - e.g. CVTECH.ID0.A, CVTECH.ID0.B, etc)
should appear.
4) Click on the _first_ (e.g.- the CVTECH.ID0.A partition) and map that to a
slot.
5) Quit the RamFAST Utilities, which should prompt a reboot.
I just used Compton's Encyclopedia (which is an 'unknown' format) to map my
CD-ROM drive to a slot. Now, for the first time, I can directly access
GO.Prodos on the Golden Orchard CD-ROM from within AppleWorks.
Don V. Zahniser
Delivered by CoPilot for ANSITerm
(D.ZAHNISER, CAT20, TOP13, MSG:162/M645;1)
DELPHI AND INTERNET ODDS & ENDS If you are thinking about venturing onto
""""""""""""""""""""""""""""""" the Internet, or have general questions
about
how to do things out there, I have a recommendation for you. Use Lynx (see
below
for help with this) and visit the following site:
http://people.delphi.com/THE_WAVES/