• Please review our updated Terms and Rules here

Apple IIe DIY Serial Card?

btb said:
Now I'm thinking that the SSC is so devilishly simple already, there's probably not going to be a workaround that's any easier than just making it a full clone with the switches and all. Could leave out the jumper block but that might be about it.

for a low parts-count version, you can modify the firmware and be slightly incompatible - ooorrrrr I think one could put the switch settings in a couple unused bytes in the EEPROM, and there might be just enough free pins on the GAL to put in the select logic for it. (you also have to make sure to merge the CTS bit into the SW2 byte)
Click to expand...

Just took a quick look at the schematics for the card; it looks like you have two unused outputs and one input on the GAL, so it seems like adding the switches should be pretty trivial. You could either do it like the original did, with two separate hex buffers (this would let you eliminate the CTS->D0 logic from the GAL) or... was pondering if you could be clever/evil and implement it *without* the buffers in front of the switches. Here's my harebrained idea:

You already have the '245 buffering the slot, so if we can control the switch banks another way we don't need another buffer. So... to provide "enable-able" switch banks:

1: Put weak pull-up resistors on D0-7
2. Arrange your two banks of six switches (*only 5 on one bank actually connect to the data lines) so each switch can connect between the apropos data line and a "common" for each switch bank.
3: Connect those two "commons" to the unused GAL outputs. These are now the "enable" lines for the switches.
4: It looks like you'll need to connect A0 to the GAL's last unused input as well, so you can distinguish between the two switch banks.
5: Program the GAL so the switch enable lines change between tri-state when unselected and "0" when the switch address is selected. This will cause the GAL to pull down the data lines for any switch in the closed position when active.
6: You leave the CTS wiring as-is.

The only thing I don't really like about this is you will be asking the GAL to pull down potentially up to six data lines at once. I think it should be fine if you use light enough pull-ups, but if you were worried you could put an open-collector inverter like a 74LS05 between the GAL and the switches to give it the extra oomph...

(Hrm. Looking at the old GAL22v10 datasheet, if I'm reading it correctly it's rated to pull down as much as 16ma, which should equal a pull-up of 312 ohm at 5v? That should be fine, then; 10K pull-ups will probably work and the the load against the GAL will be trivial.)

FWIW, this idea is kind of stolen from how the keyboard scanning works in some old home computers, like the TRS-80 or PET.
 
Huh, how did that chip escape my notice? And why didn't anyone tell me I can order chips directly from TI for dirt cheap and flat shipping????
 
Heh. I have about two dozen of them lying around; I needed some for my Tandy 1000 projects and saw a tube of surplus ones on eBay for about what five of them cost on Digikey. Of course that was before the dark times.
 
Trying to just hack the firmware to hard-code the switch values.

Looking at: https://6502disassembly.com/a2-rom/SSC.html -
there doesn't seem to be any place in the firmware itself that actually cares about the CTS flag (bit 0 of $Cs82) -
so hopefully there's no need to do anything to merge that into the byte.

So I replaced the five instances of:

Code: 
b9 81 c0                     lda     DIPSW1,y
with:
Code: 
a9 9f                        lda     lda #%10011111
ea                           nop

and the one instance of:

Code: 
b9 82 c0                     lda     DIPSW2,y
with:
Code: 
a9 f7                        lda     lda #%11110111
ea                           nop

Those constants should represent the switch settings suggested at https://adtpro.com/connectionsserial.html#Super_Serial_cabling, with the unused bits set to 1 (they'd be pulled high by resistors on the original SSC)

but no change at all. hmm
 
About 6 months ago I designed a 2-layer version of the jmthompson SSC of my own so I could get the boards made for $2 at JLCPCB and finally got around to building it today. A seller on eBay local to me that has a bunch of NOS electronics ("press-send" is their name) had most of the parts like the 6551, MAX232s, 74HCT245, and EEPROM. With $1 local pickup and JLCPCB fabbing the PCBs, the board was pretty dang cheap to build.

The board works perfectly in ADTPro, which is most of what I'm going to use it for, but it just spews garbage to the screen and beeps when doing IN#2. I thought it was my fault but I found this thread and the issue on GitHub, so I'm thinking it's the same underlying problem.
 

Attachments

  • 1d1dfb1bc313a883.jpeg
    1d1dfb1bc313a883.jpeg
    501.1 KB · Views: 29
In this GitHub issue, @btb mentions the GAL equations looking off. I took a stab at rewriting them to match the Apple SSC schematic but I haven't noticed much of an improvement, but I might have missed something. Maybe I'll also try to patch my ROM with the changes up above.

I'm also tempted to redesign with the discrete logic chips that the GAL replaces. SOIC versions of the chips needed are still in decent supply at DigiKey and Mouser and would save board space.
 
Last edited:
I like how you think. I also took a stab at rewriting the GAL equations. Then for fun I felt like trying out the wire-wrapping kit I acquired, and I did this little bit of madness to replace the GAL:
IMG_5488.jpegIMG_5489.jpeg

but it still doesn't work. Pretty confusing because it really seems like it should. Still functions perfectly once you have ADTPro up and running.
 
Last edited:
Dang...this is awesome.

How many boards did you have to print to get them for $2? This would obviously be a MUCH easier way than what I was trying to do if it's cost effective...
 
I imagine it will be fixed eventually but I'm not sure what the problem is exactly at this point, since my reproduction should have been quite equivalent aside from the physical switches.
 
I reworked the GAL equations in WinCUPL (as I am not familiar with galasm, and couldn't find clear documentation on how to emulate parenthetical operations to emulate a latch).

The card appears to work now, insofar as the ROM is correctly mapped into C800 and unmaps when CFxx is accessed. SlotScan correctly identifies the card. I have created a pull request that also contains a mechanism to snarf the SSC ROM from mirrors.apple2.org.za and apply btb's ADTPro fixes.

However ... a CMOS '245 appears to latch the data bus before the ROM has reacted, resulting in nondeterministic garbage at C800 after awhile. A 74LS245 does not seem to have this issue. The fix would probably be to introduce a reasonable delay between pulling ROMOE low and enabling the '245.
 
You must log in or register to reply here.
Back
Top