Frank Townsend wrote:

>Michael:
>
>
>Thanks for your advice!
>
>
>The SVA card is in Slot 7, and so far, a C700L lists what looks like valid
>assembler code.
>
>So I tried to save this to disk with the following (which I'm not quite sure
>is correct).
>
>Assuming that a 2708 EPROM contains 1024 bytes:
>
>CALL-151
>C007:0
>1100<C700.CB00M
>C006:0
>BSAVE ROM,A$1100,L$1500
>
>I modeled this on a code snippet used to copy a IIe ROM, and admit I'm not
>quite sure why C007 and C006 are zeroed.
>
>Does this look right?

There is a problem, and it is with exactly what you were wondering about.

Contrary to what the Apple //e Reference Manual says, as reported by
Jim Sather in "Understanding the Apple //e", the softswitch at C006,C007
turns slot ROMs _on_ after a write to C006, and turns internal //e ROM
in the slot space on after a write to C007.

So the code you used was correct for capturing the internal //e ROM,
but doesn't get the slot ROM.  For that, you need to reverse the two
addresses, writing first to C006, then, after saving the ROM, writing
to C007.

Another problem you will need to deal with is that only the first 256
bytes of the ROM can be captured in this way--from C700.C7FF, and
the remaining 768 bytes will not be visible unless the slot 7 ROM
has been switched into the C800.CFFF space.

Typically, a card will enable its ROM in the C800.CFFF space when
a DEVICE SELECT address is referenced--that is, an address in the
C0sX space, where s = slot + 8.  For slot 7, the "0" DEVICE SELECT
address is C0F0.  Generally a read is sufficient, and harmless (in terms
of changing the state of the device).

After this read, the entire slot ROM, in this case 1KB, is mapped into
C800.CBFF, and can be moved to RAM before writing it to disk.

So, the sequence that should capture it is:

CALL-151
C006:0
C0F0 <return>
1800<C800.CBFFM
C007:0
BSAVE ROM,A$1800,L$400

The file "ROM" should then contain the entire ROM contents, and,
in all liklihood, the first 256 bytes of it will be the "slot" portion, or
C700.C7FF.  (This can be verified by looking at the data in this
address range, before doing the "C007:0" above, and seeing which
256-byte "page" of the saved ROM is the same code.)

1KB of code is non-trivial in size, but not too difficult to disassemble
and reverse-engineer.  This will almost certainly tell you how to start
the disk, read sectors, and, possibly, how to write sectors.  There
may even be hints about how to patch calls to the slot ROM into
RWTS, so that an 8" disk drive can be used by DOS 3.3.

When you're done, you will probably know more about this card
than all but a very few people.  Alternatively, you may be able to
enlist the aid of other card owners in such a project, since you
would all benefit from software support.

You will almost certainly have to figure out how to patch ProDOS
if you want to use the card from that OS, since I doubt that SVA
ever produced software to do that.

-michael

 Email:  mjmahon@aol.com
 Home page:  http://members.aol.com/MJMahon/


From david@uow.edu.au Wed Dec 19 09:55:57 CST 2001

mjmahon@aol.com (Michael J. Mahon) writes:
>Typically, a card will enable its ROM in the C800.CFFF space when
>a DEVICE SELECT address is referenced--that is, an address in the
>C0sX space, where s = slot + 8.  For slot 7, the "0" DEVICE SELECT
>address is C0F0.  Generally a read is sufficient, and harmless (in terms
>of changing the state of the device).

That is actually atypical. Most cards enable the IOSTB space (C800..CFFE)
when they receive an IOSEL access (CnXX). Furthermore, you have to turn
off any other cards access by touching address CFFF. I would use:

]CALL -151
*CFFF				turn off all cards IOSTB space
*1000<Cn00.CnFF			read IOSEL space and enable IOSTB space
*1800<C800.CFFF			read IOSTB space

You shouldn't need to mess with the C006/7 switches as they are normally
in the correct state.

You will probably find that 1000.10FF matches part of the 1800.1FFF space
or alternatively the last 256 bytes of the IOSTB space are rubbish (instead
of decoding CFFF many cards decode CFxx and bank switch those 256 bytes
into the IOSEL space). If you want to burn a new ROM you will need to work
out how these two memory images are combined.

P.S. Make sure you do not have your //e in 80 column mode when you do
this.
--
David Wilson  School of IT & CS, Uni of Wollongong, Australia