Best practices for use of address space by expansion cards?

2 replies [Last post]
Joined: Aug 3 2011
Posts: 33

Are there any existing best practices for expansion card address space usage, and if so, what are they?

The reason I ask is, I'm considering a card that would take 16 bytes of address space. The Apple II gave each slot the DEVSEL space ($C0nx, where n is the slot number), the IOSEL space ($Cnxx), and a bankswitched ROM area ($C800-CFFF), but the Apple-1 has no such space. Granted, Woz probably would've just slapped the card on S and called it a day - that's quite evident based on the PIA having been slapped on Z with no other logic, despite only using 4 bytes. But, I'd rather be more economical with address space than that.

We know the lines that are run to the slots for chip select are the R, S, and T lines (which are mapped to $C, $B, and $A respectively). The S line is unused, but the T line is taken (completely) by the CFFA1, and the R line is taken (partially, and the address decode logic here is smart, so $C2-CF are free) by the ACI.

I'm thinking there's a couple ways to go here, both of them using the $C2-CF space in 512-byte chunks (following the example of the ACI), still leaving S unused for something else (or adding it to this scheme as well, but having a line dedicated to 4 kiB for personal experiments would also be handy).

First option would be, hardcode certain cards to use certain addresses. This would make software easier to write, with the major downside that the scheme breaks down once there's eight cards, including the ACI. And, more than one of a card is right out.

Second option would be a 4 jumper block on each $C card past the ACI, to determine what addresses it responds to. Means that the user has to do more configuration, but given that most users who would actually stick third-party hardware in probably soldered their Apple-1s together, that's a reasonable burden. And, code has to adapt to where a card is, but that's the case on the Apple II, too.

Third option would be to find three unused pins on the bus, and make a new slot expander that repurposes them for Apple II-style chip select. Dangerous because that means it'll break compatibility with things for sure (yes, there may only be one 6800-powered clone out there, but the bus was meant to handle it), but easy to use.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: Aug 3 2011
Posts: 33
Re: Best practices for use of address space by expansion cards?

Actually, you know, it'd only need one unused pin on the bus to get Apple II-style chip select... now I need to look a little more closely to see what can be taken. The DMA pin is always a possibility, but it'd be nice to leave that compatibility in.

The other thing is, although it's only relevant for my application or other similar small applications (porting DEVSEL-only hardware from the Apple II, for instance)... only A0, A1, and A4 go to the PIA (in addition to the $D chip select).

A4 is used as one of the PIA's three chip selects (the second is hooked to VMA (or to +5V on a 6502), the third is hooked to the $D select). Given that A5 through 11 are fair game in this space, and anything with A4 inactive is fair game, that makes things quite interesting. For starters, that means that $D000 through $D00F is free - invert A4, and you mirror the PIA behavior, but shifted down by $10. But, that's the ugly way to do it that wastes address space, in an area that only has half of its address space free, and in 16 byte chunks. (Well, the PIA is only using 4 bytes of its 16 byte chunks, too, but can't use the other 12 bytes.) But, there's certainly ways to decode things here.

I'm almost tempted to say, $D02x to the same card that gets $C2-C3, $D04x to $C4-C5, so on, so on. Not the most efficient (the $D1ex (e for even) through $DFex positions are unused, still), but 16 byte chunks are hard to find uses for - maybe D2ex for $C2-C3, D4ex for $C4-C5, so on, and then D1ex for $B0-B1, D3ex for $B2-B3, so on would work. I'd need to check how that actually works, though, as far as the logic, because there's different address pins involved here (I don't normally think about this, so it takes me a while to think whether saves much or not). It could save some config jumpers at least. (And, actually, the latter scheme would probably use less address decode logic, too, at least in the $C space, I think?)

speedyG's picture
Joined: Nov 16 2011
Posts: 2426
Re: Best practices for use of address space by expansion cards?

Hello bhtooefr,
just added a reply to the other posting and refering there to 2 pages....
probably your thinking about something i´m allready working about...
sincerely speedyG


In early days I had a lot of money but no time - now I have no money but a lot of time....
the second part includes less friends but a lot more joy on life....