Discussion:
Apple II peripheral lines
Add Reply
Anthony Ortiz
2018-02-09 16:04:15 UTC
Reply
Permalink
Raw Message
I would like to see if I understand some concepts correctly so please pardon my ignorance in advance :

DeviceSelect - when an access occurs to C0XN (where X is the slot number and N is anything) the MMU sets the DeviceSelect signal for that particular slot which the card detects, at which point custom logic on the card will read some of the lower address lines to decode N and triggers whatever internal circuitry is designed to handle command N.

Is this how it works? If so, when I write a value to one of these DeviceSelect addresses, is the card able to decode the value on the databus as well? Say I create a serial card and want to send a byte, if I write $66 to one of these addresses and the card interprets the address as a SendChar command, will it be able to decode $66 from the databus and do it’s thing?

IOSelect : when an access occurs to somewhere between CX00-CXFF (where X is the slot number) then the peripheral cards firmware will be mapped to this 256 byte range.

Is this right? It so, does this mean that if I do a JSR C100 then as soon as C100 is placed on the address bus the mapping will occur just in time for the 65X02 to be able to execute the firmware located at that address? Also, this must be tied to the PC I would imagine, because if the instruction at C100 does a LDA $FFFF or any absolute address command then at some point $FFFF will appear on the address bus and the IOSelect signal will no longer be active and the firmware will be pulled out from under its feet... unless the firmware stays until an IOSelect from another slot occurs? I’m confused here lol!
Jorge
2018-02-09 17:27:52 UTC
Reply
Permalink
Raw Message
Post by Anthony Ortiz
DeviceSelect - when an access occurs to C0XN (where X is the slot number and N is anything) the MMU sets the DeviceSelect signal for that particular slot which the card detects, at which point custom logic on the card will read some of the lower address lines to decode N and triggers whatever internal circuitry is designed to handle command N.
Is this how it works? If so, when I write a value to one of these DeviceSelect addresses, is the card able to decode the value on the databus as well? Say I create a serial card and want to send a byte, if I write $66 to one of these addresses and the card interprets the address as a SendChar command, will it be able to decode $66 from the databus and do it’s thing?
Yes, the card will see $66 in the data bus and R/W set to W.
Post by Anthony Ortiz
IOSelect : when an access occurs to somewhere between CX00-CXFF (where X is the slot number) then the peripheral cards firmware will be mapped to this 256 byte range.
Is this right? It so, does this mean that if I do a JSR C100 then as soon as C100 is placed on the address bus the mapping will occur just in time for the 65X02 to be able to execute the firmware located at that address? Also, this must be tied to the PC I would imagine, because if the instruction at C100 does a LDA $FFFF or any absolute address command then at some point $FFFF will appear on the address bus and the IOSelect signal will no longer be active and the firmware will be pulled out from under its feet... unless the firmware stays until an IOSelect from another slot occurs? I’m confused here lol!
lda $ffff is 4 bus operations, 1)read the lda opcode at addr ($C100), 2)read $ff at addr+1, 3)read $ff at addr+2, 4)read whatever is at address $ffff, 5)fetch the next opcode at addr+4.
James Davis
2018-02-09 18:10:40 UTC
Reply
Permalink
Raw Message
Post by Anthony Ortiz
DeviceSelect - when an access occurs to C0XN (where X is the slot number and N is anything) the MMU sets the DeviceSelect signal for that particular slot which the card detects, at which point custom logic on the card will read some of the lower address lines to decode N and triggers whatever internal circuitry is designed to handle command N.
Is this how it works? If so, when I write a value to one of these DeviceSelect addresses, is the card able to decode the value on the databus as well? Say I create a serial card and want to send a byte, if I write $66 to one of these addresses and the card interprets the address as a SendChar command, will it be able to decode $66 from the databus and do it’s thing?
IOSelect : when an access occurs to somewhere between CX00-CXFF (where X is the slot number) then the peripheral cards firmware will be mapped to this 256 byte range.
Is this right? It so, does this mean that if I do a JSR C100 then as soon as C100 is placed on the address bus the mapping will occur just in time for the 65X02 to be able to execute the firmware located at that address? Also, this must be tied to the PC I would imagine, because if the instruction at C100 does a LDA $FFFF or any absolute address command then at some point $FFFF will appear on the address bus and the IOSelect signal will no longer be active and the firmware will be pulled out from under its feet... unless the firmware stays until an IOSelect from another slot occurs? I’m confused here lol!
[IIRC, the convention is: "$C0SN" or "$C0Sx". "S"/"s" for slot number, "N"/"n" or "X"/"x" for {hexadecimal} number. (But who cares?)]

Accessing $CFFF turns off the card space and reinstates ROM space, IIRC.
That way a card cannot be easily overridden (usurped).
cb meeks
2018-02-09 18:52:05 UTC
Reply
Permalink
Raw Message
Post by Anthony Ortiz
Is this right? It so, does this mean that if I do a JSR C100 then as soon as C100 is placed on the address bus the mapping will occur just in time for the 65X02 to be able to execute the firmware located at that address? Also, this must be tied to the PC I would imagine, because if the instruction at C100 does a LDA $FFFF or any absolute address command then at some point $FFFF will appear on the address bus and the IOSelect signal will no longer be active and the firmware will be pulled out from under its feet... unless the firmware stays until an IOSelect from another slot occurs? I’m confused here lol!
I believe that when you execute a "LDA $FFFF" from address $C100, the program counter (PC) is executing at $C100, then $C101, then $C102. At which point, the accumulator would have the value of $FFFF's contents. But the PC then carries on with the next instruction in the card's $C103 space.

Only if you were to branch out of the $CNXX space were the card to switch "off".

Someone please correct me if I'm wrong.
MG
2018-02-09 20:36:43 UTC
Reply
Permalink
Raw Message
Regarding $CFFF - it is a card's responsibility to recognize this and switch off its $C8-space in order to avoid bus contention with other cards. A card is allowed to assert $C8-space when its $CsNN space is being accessed.

$CFFF should not do anything to a card's $CsNN space.

Therefore an instruction executing LDA $CFFF at $C100 is basically telling all cards to release $C800-$CFFF, and since the next instruction fetch accesses $C103, the card in slot one gets to have $C800-$CFFF.
Anthony Ortiz
2018-02-09 20:43:02 UTC
Reply
Permalink
Raw Message
Not $CFFF, $FFFF.

I figured if code at $C100 were to LDA $FFFF then at that moment (when address bus has $FFFF on it) device select would turn off and the rug would be pulled out of that address space and therefore right out from under the executing program. But I forgot that the next instruction will cause the address space to populate with the PC ($C103) and fetch the next instruction, and when it does that device select is set and rom is mapped back in so all is well. Am I right or do I still have it wrong?
Jorge
2018-02-09 21:33:38 UTC
Reply
Permalink
Raw Message
Post by Anthony Ortiz
Not $CFFF, $FFFF.
I figured if code at $C100 were to LDA $FFFF then at that moment (when address bus has $FFFF on it) device select would turn off and the rug would be pulled out of that address space and therefore right out from under the executing program. But I forgot that the next instruction will cause the address space to populate with the PC ($C103) and fetch the next instruction, and when it does that device select is set and rom is mapped back in so all is well. Am I right or do I still have it wrong?
100% correct.
Anthony Lawther
2018-02-09 20:39:17 UTC
Reply
Permalink
Raw Message
Post by cb meeks
Post by Anthony Ortiz
Is this right? It so, does this mean that if I do a JSR C100 then as
soon as C100 is placed on the address bus the mapping will occur just in
time for the 65X02 to be able to execute the firmware located at that
address? Also, this must be tied to the PC I would imagine, because if
the instruction at C100 does a LDA $FFFF or any absolute address command
then at some point $FFFF will appear on the address bus and the IOSelect
signal will no longer be active and the firmware will be pulled out from
under its feet... unless the firmware stays until an IOSelect from
another slot occurs? I’m confused here lol!
I believe that when you execute a "LDA $FFFF" from address $C100, the
program counter (PC) is executing at $C100, then $C101, then $C102. At
which point, the accumulator would have the value of $FFFF's contents.
But the PC then carries on with the next instruction in the card's $C103 space.
Only if you were to branch out of the $CNXX space were the card to switch "off".
Someone please correct me if I'm wrong.
There's essentially two ways to look at this:

1. What is in the current memory map?

For most cards with firmware it is safe to expect a single page of firmware
that will map into the $CSxx range; this is never "switched off" from a
memory map perspective. If more space is required then this access can also
map more firmware into the $C800 - $CFxx range which is shared between all
slots, and also motherboard ROM on some models. The card must release this
range upon an access to $CFFF; to simplify decoding many cards release on
any access in the $CFxx range.
Some cards can use a bank switching scheme within these ranges, but that is
more unusual.

2. What is the circuitry doing?

In order to avoid bus contention, only one device can drive the data bus at
a time. IOSelect is the signal that enables a particular card's circuitry
(usually ROM) to drive the bus.
This is always generated "just in time" as otherwise the card could mess
with video generation and every part of the system would need to fully
decode the Address bus for every operation (and maintain an internal copy
of the system state to properly interpret the address).
In the example given, the bus cycles for reading memory to execute the LDA
$FFFF would each generate an IOSelect pulse except for the one cycle that
actually reads from location $FFFF.

Full Address decoding is one valid mode of operation for a slot card, but
it can lead to incompatibility with partially decoded cards.

There's more to it, but Sather covers it quite well in my opinion.

Regards,
Anthony.
cb meeks
2018-02-09 21:48:59 UTC
Reply
Permalink
Raw Message
Post by Anthony Ortiz
DeviceSelect - when an access occurs to C0XN (where X is the slot number and N is anything) the MMU sets the DeviceSelect signal for that particular slot which the card detects, at which point custom logic on the card will read some of the lower address lines to decode N and triggers whatever internal circuitry is designed to handle command N.
Is this how it works? If so, when I write a value to one of these DeviceSelect addresses, is the card able to decode the value on the databus as well? Say I create a serial card and want to send a byte, if I write $66 to one of these addresses and the card interprets the address as a SendChar command, will it be able to decode $66 from the databus and do it’s thing?
IOSelect : when an access occurs to somewhere between CX00-CXFF (where X is the slot number) then the peripheral cards firmware will be mapped to this 256 byte range.
Is this right? It so, does this mean that if I do a JSR C100 then as soon as C100 is placed on the address bus the mapping will occur just in time for the 65X02 to be able to execute the firmware located at that address? Also, this must be tied to the PC I would imagine, because if the instruction at C100 does a LDA $FFFF or any absolute address command then at some point $FFFF will appear on the address bus and the IOSelect signal will no longer be active and the firmware will be pulled out from under its feet... unless the firmware stays until an IOSelect from another slot occurs? I’m confused here lol!
Let us not forget the genius that is Woz. However, IIRC, he had a little help on the slot stuff from Baum I believe?
Michael J. Mahon
2018-02-10 01:45:00 UTC
Reply
Permalink
Raw Message
Post by cb meeks
Post by Anthony Ortiz
I would like to see if I understand some concepts correctly so please
DeviceSelect - when an access occurs to C0XN (where X is the slot number
and N is anything) the MMU sets the DeviceSelect signal for that
particular slot which the card detects, at which point custom logic on
the card will read some of the lower address lines to decode N and
triggers whatever internal circuitry is designed to handle command N.
Is this how it works? If so, when I write a value to one of these
DeviceSelect addresses, is the card able to decode the value on the
databus as well? Say I create a serial card and want to send a byte, if
I write $66 to one of these addresses and the card interprets the
address as a SendChar command, will it be able to decode $66 from the
databus and do it’s thing?
IOSelect : when an access occurs to somewhere between CX00-CXFF (where X
is the slot number) then the peripheral cards firmware will be mapped to
this 256 byte range.
Is this right? It so, does this mean that if I do a JSR C100 then as
soon as C100 is placed on the address bus the mapping will occur just in
time for the 65X02 to be able to execute the firmware located at that
address? Also, this must be tied to the PC I would imagine, because if
the instruction at C100 does a LDA $FFFF or any absolute address command
then at some point $FFFF will appear on the address bus and the IOSelect
signal will no longer be active and the firmware will be pulled out from
under its feet... unless the firmware stays until an IOSelect from
another slot occurs? I’m confused here lol!
Let us not forget the genius that is Woz. However, IIRC, he had a little
help on the slot stuff from Baum I believe?
That's right. Allen worked with Woz on the peripheral architecture.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Charlie
2018-02-10 16:20:05 UTC
Reply
Permalink
Raw Message
Post by Anthony Ortiz
DeviceSelect - when an access occurs to C0XN (where X is the slot number and N is anything)
Not quite. X is the slot number + 8.

Charlie

Loading...