A little under a year ago I found a nice deal on an Apple IIc. I had actually been looking specifically for the IIc, it's the version of the Apple II that was most memorable to me. Actually back in the late 1980s I had no idea the Apple IIe existed, didn't know the machine was designed with expansion slots... So when I first saw a IIe my thought was, "why is it so big?" But as I've learned more about the Apple II slots and the early history of the platform I've come to appreciate the design of the I/O system and the way the system accommodates expansion hardware and ROM.

Anyway, I've been having fun with my IIc but I've started to think I'd like to upgrade it... With a Mockingboard, for starters. Of course there's one on the market and I could just buy that, but I was also thinking, maybe a RAM expansion, or CPU upgrade... But with the limited space it'd be difficult to combine two different devices that sit in the CPU socket... And I love how simple the Apple II I/O slot makes the design of add-on hardware, it seems a shame that it has to be so much more complicated on the IIc. So I thought maybe I'd try to make my own.

So I've been reading Apple II memory maps, learning how it uses its I/O space, how the different RAM bank switching mechanisms work, etc., and learning how 6502 timing works.

The first goal I set for myself is to build that Mockingboard - but do it in a way that separates the specialized logic (i.e. blocking access to the system's built-in "mouse card" and redirecting that traffic to the Mockingboard hardware) from the Mockingboard hardware itself... That way I can physically relocate the Mockingboard hardware to an area where there's a little more free space inside the case (there's not much! It's an amazingly compact machine!), and also I can replace the "slot host" module later, build one that incorporates a faster CPU and RAM expansion.

...Though I couldn't resist throwing a 65816 into the first version of the slot host board. I know it's still going to be running at 1MHz and so it's not going to do anything for existing software... It's not even going to map the second bank of RAM into the 816's address space, except via the already-existing bank-switching mechanisms... But it will give me the ability to use the 816 in my own programs - 16 bit registers, relocatable "direct page" and stack, memory move instructions, etc. I love the machine as it is, but I also want to explore possibilities, of what it could be, and while incorporating an 816 instead of a 65C02 does complicate things a little (and I'm already deep in unknown territory here) - it doesn't complicate them *that* much... I'm working from Daryl Rictor's 6502-65816 adapter as a reference for how to include that in the design.

Fun adventures, though I still have a lot to learn to make this stuff happen. One bit I'm still uncertain of is the timing of how my "slot host" hardware is going to intercept slot 4 traffic. The mockingboard has two VIAs in the 0xC400-0xC4FF address space. (Generally speaking an Apple II I/O card has three address ranges, but I think the Mockingboard only uses the one) When software writes to those addresses, the plan is to isolate the CPU's data and address busses from the system - so to the rest of the machine that cycle will turn into a read from some RAM address, but actually the CPU will be interacting with the Mockingboard. My concern there is the amount of time it would take the address bus to settle sufficiently, then for my I/O logic to recognize the address and isolate the bus - I don't understand the whole timing cycle well enough yet to know if that will be fast enough to prevent unintended I/O or RAM writes to reach the system. (Like if the MMU detects the falling edge of R/W before I isolate it, that sort of thing)

(Of course, since it's 0xC400-0xC4FF I think I could just let the write through to the rest of the system with the address bus and R/W line intact... Since that's ROM space for the "mouse card" writes to those addresses shouldn't matter, I'd just have to cut off the data bus so reads wouldn't be an issue. Could be a simpler way to go for the purpose of the Mockingboard, it just wouldn't be as broadly applicable to other expansion hardware..)

Hi, and welcome aboard.

It's be a shame to make any permanent modifications to that classic little computer so I hope you don't go that far.

It's sounds like you really want an Apple IIgs though.

_________________
Bill

I mean,
1: it's my business what modifications I make to my machine
2: none of the modifications I'm talking about are even beyond what was available in the 1980s as upgrades for the Apple IIc...

As for the IIgs... Of course the possibility of getting a IIgs has occurred to me. But as lovely a machine as it is, it holds no appeal to me, at least not at present. I'd rather take a machine I do like, and upgrade that.

The way I figure it, Apple II's were meant to be upgraded and expanded. The IIc is something of an exception, but it doesn't need to be.

Indeed, welcome. Seems like a good plan to start with an existing product (in this case the Mockingboard) because you know there's a design nearby in design space which will work. I'm not too surprised your finding the physical space a constraint - I've never seen a IIc close up but it's clearly a compact (or dense) construction.

Good luck, anyway. You'll surely be able to get answers here when you have specific questions about your build, or about debugging. There's a wealth of knowledge in the forum's back catalogue too, so it's worthwhile to try searching for previous experience.

Of course it is and I didn't mean to suggest otherwise. That doesn't change my sentiment though, does it?

_________________
Bill

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I hope you stick with it, tetsujin. Plenty of people here will be interested to see what you do.

I honestly wasn't trying to discourage him. I guess I should have been more explicit. His initial proposed mod is harmless, so no issues with that. However, if (hypothetical) he wanted to drill the case, or otherwise do an irreversible mod I personally think it'd be too bad. As he pointed out though, it's his so of course he is entitled to do anything he wants to it. Even get mad at it and smash it with a hammer. But they are not making any more of these so irreversible changes are indeed a loss.

Sorry, but I honestly thought all this would be self-evident.

To the OP, my apologies. I did not intend offence.

_________________
Bill

I echo that sentiment. And BTW I certainly don't object to undertaking mods that might undermine the resale value of a vintage piece. After all, look what I did to my KIM-1! (Although admittedly it was not a vintage item at the time... )

Alright, maybe we can work through this. But even though there's a great deal of 65xx expertise on this forum, it's not a IIc forum and not everyone here knows what a Mockingboard is or what it does. (I don't.) So, some links and/or some descriptive text would be helpful.

Also, and along the same lines, you don't seem to me to be asking any specific question. I get how you're attracted to having some of the 816's new instructions available (even though its extra address range won't be accessible if you use Daryl's adapter design). But, AIUI, Daryl's setup behaves like and presents the same pinout and signals as a 65C02, so I'm at a loss as to why there should be concern, as you say, about "the amount of time it would take the address bus to settle sufficiently, then for my I/O logic to recognize the address and isolate the bus."

It seems to me that if a 65C02 will work in your scheme then Daryl's adapter should also work. But is it possible you haven't yet decided what your scheme is? That's alright too... but if you're asking for guidance then it'll help if you're more specific about your concerns. (What bus? Why does it isolate? What I/O logic? And so on.)

Cheers (and welcome),

Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Altair 8800 home computers were sold as kits so many users continue to add or modify their original kits. That was common practice at the time. First computer I physically worked on was an Altair that someone assembled/modified and gave to me to tinker with while waiting for my security clearance. I don't think I had added any collectible value to it! Bought my current Altair decades ago from a co-worker for $25 only because I've hacked up my first Altair past recognition, so I want to see what an original looked like. He contacted me later telling me not to junk the Altair because he'd just sold his for $2500! That was the first time I realized my career has transition from "cutting edge" to "collectible". Kinda sad, really.
Bill

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Fair enough, I guess it just felt a little frustrating 'cause I came here feeling like it was a place where my desire to work with and upgrade a 6502 machine would be understood, and instead it felt like it was being discouraged. Though maybe that's on me. I needed to take some time to process that.

Personally I don't consider permanent alteration off the table. One thing I would like to explore in the future is ways to make the machine better for debugging. So, for instance, adding a NMI button could be useful there. The machine is a classic, and cutting its case isn't a decision I'd make lightly, but at the same time, I'm writing this chapter of the machine's history.



A Mockingboard is a soundcard for the Apple II, using the AY-3-8910 interfaced with a VIA chip.
The Apple II provides what seems to me actually a pretty nice expansion bus system: 0xC000-0xCFFF is dedicated to I/O and each slot gets 16 + 256 memory addresses plus another 2048 that are shared cooperatively between the slots. The computer handles most of the address decoding so it seems pretty simple to build I/O cards for the full-size Apple II machines.
The trick to building a board like this on the IIc is, it actually doesn't have physical slots. It has integrated peripherals that occupy addresses in that I/O space. So on the IIc, creating any kind of card that occupies a "slot" (logically speaking) means not only decoding addresses and responding to the ones of interest, but also blocking that traffic from reaching the corresponding integrated device. I want to add a Mockingboard to my machine, but I also want to separate out the specialized piece of logic that masks out one of the IIc's built-in devices, so that creating an add-on for the IIc could be just as simple as for other Apple II machines.



The timing concern has to do with how the system behaves in cases where the CPU generates traffic that appears to be directed to some point in the original IIc hardware, but the expansion board recognizes that it's actually meant to go somewhere else - and so it has to disconnect the CPU from the IIc's data and address bus to prevent the traffic from having unwanted side-effects. Likewise if I add RAM using the '816's 24-bit address space (which would require adding circuitry to Daryl's design to provide latching for the top 8 bits of the address), I want to make sure that writes to that expansion RAM don't alter data in the IIc's regular RAM before my logic kicks in and isolates the bus. For the Mockingboard this isn't a huge problem (the board's VIAs are in a location that corresponds to the host system's built-in mouse card ROM) but for reads I don't want two different devices to wind up (briefly?) driving the bus, and for expansion memory writes I don't want those getting latched somewhere in the system before my logic isolates the bus and causing some location in the host system's RAM to get rewritten.

Some of this is going to be specific to the Apple II hardware, and as you say this forum might not be the best place for that kind of insight. But also I need to better understand the timing cycle of the 6502. For that, I don't know that I have specific questions yet, I need to build my understanding a bit more first.

As sort of an "expert" on vintage computers (meaning, I have a boat-load of them...lol), I also do not prefer or recommend any permanent alterations to vintage equipment.

Having said that, it's yours...do what you want.

Now, I have made some exceptions in the past.

1) I drilled a slot for my F18a VGA connector on my TI-99/4a. Why? Because it's amazing and this one TI will be mine forever. Also, I have like 8 others that are original.

2) I painted a C128D keyboard that was so yellowed, that "yellow" wasn't the actual color. It was brown and orange. No amount of retro-brighting would have helped it (I tried somewhat). In fact, too much retro-brighting will damage the plastics from what I understand.

3) I drilled a slot for the Sophia 2 DVI connector on my Atari 800XL. Why? Same as #1 above.

That's about all I can think of. I have a few other vintage computers I may paint because the cases were either already damaged when I received them or so badly marked up that they cannot be restored without drastic measures. Like a Laser 128 case that has permanent markers all over it that no amount of scrubbing is removing.

Now, on the topic of Mockingboards and the IIc. There was a guy in Korea (can't remember his name) that sold a custom Mockingboard card you install inside the IIc and it works like a conventional Mockingboard A. Works like a charm. Although, I still find myself using my Apple IIe with a Mockingboard clone more often (something about those slots I really love).

_________________
Cat; the other white meat.

If you're short of space then it is possible to use ribbon cables with DIP40 headers and place an accelerator in a spare corner. This works until the board becomes dislodged and sparks against another board. A cheaper and more study option is to add hex spacers to existing screw holes. This can separate the top and bottom of a case by more than one inch. The gap can be filled with plastic, such as imitation Lego. Some or all of the gap can be filled with filter foam. Almost every city has a foam supplier who will cut foam to size. From personal experience, when I made a mascot costume, my local supplier took it as a challenge to cut foam a thinly as possible; knowing that the thickness or straightness wasn't important.

Notching out page $C4 of the address-space is slow and awkward with discrete logic. Normally, I'd recommend against programmable logic for this task because the energy consumption hinders a portable implementation. However, if you're starting from a legacy desktop system, this isn't a concern. The remaining concern with programmable logic is the Eldritch horror commonly known as WinCUPL. It might be easier to decode a different, unused address range and patch any legacy software to use it.

If you want 65816 with a larger address range, you might want to copy elements of the CMD SuperCPU which provided 20MHz 65816 as a Commodore64 cartridge. That would be an impressive hack if someone invented it today. In addition to having a moderately over-clocked 65816, it has some very clever circuitry which only slows the processor for reads and multiple writes. Specifically, the first write from the processor to the legacy host doesn't slow the processor.

Getting a larger amount of RAM is more important than getting the processor to go faster. And getting the processor to go faster may take many steps. Make sure that your 65816 board has tri-state buffers to allow video during the dormant legacy bus phase. Also make sure that you can tweak the processor's clock duty and RDY signal from a 5cm*7cm prototyping bodge board. This will allow you to increase the processing speed after the address decode, extra peripherals and extra memory work. It'll be ugly but it'll work.

When accessing the large RAM on the 65816 board, dummy writes to the legacy host are an obvious problem. However, dummy reads may also be a problem. For example, RAM read from $12C40x may strobe a 6522 at $C40x and interfere with interrupts. The obvious solution is to ensure that dummy reads are directed to a safe region of the legacy host's memory, such as $00xx or $FFxx. That is the sensible option. There is also my preferred option where legacy I/O is mirrored in every 65816 64KB bank. This requires breaking the extended RAM into many fragments and this creates problems which don't otherwise have to be solved. However, with suitable banking of the RAM and ROM, it is possible to have perhaps 64 banks of 48KB RAM. From 65816 bank register selection, RAM and ROM may be selected independently and each bank of ROM may have entry points for Commodore, Apple or Acorn applications. This works in a manner which does not interfere with native 65816 vectors at $00FFEx. Indeed, it may be possible to run one or more unmodified Acorn ROMs from $8000-$BFFF and task switch this with Commodore and Apple applications. Oh, and in this arrangement, you don't have to worry about dummy reads or writes to $Cxxx.

I'm attempting similar from a compact, portable board. However, there is equal merit to start from an Apple system, an Acorn system or W65C265 development board.

If you want MMU for privilege protection, it might be easier to place a privilege bit on a subset of the I/O (and discourage 65816 long addressing). 6522 has two chip select signals. One of these may be derived from 74x138 address decode or similar. The other may be derived from a privilege bit flip-flop. The principle also works further back in address decode. For example, a 74x138 may correctly fail to decode anything if the privilege bit is absent. For maximum performance and convenience, you might want cards in page $C0, $C1, $C2 and $C3 to be privileged while cards in page $C4, $C5, $C6 and $C7 are unprivileged.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!