Hangs when trying to run

[StormTrooper]

I am having some issues getting this to work.

I've built the circuit and using the same components as per the BOM.
Burnt the gal and ROM (Using [Apple II Super Serial Card ROM - 341-0065-A.bin - duplicated 16 times)

When I run IN #2 the Apple freezes and I can't type in any further commands.

Is there any troubleshooting steps you can offer. I've tested all the chips and they work fine so I'm not sure where to start looking next.

[jmthompson]

I had that same issue, never did diagnose it since my only purpose for the card was to get ADTPro working, and it does not use the firmware. I suspect the issue may be related to the fact that my card omits the DIP switches for configuring the card defaults and it's trying to configure the card into an invalid state as a result.

Unfortunately my Apple IIe isn't set up anymore so I don't thing I'll be doing much with this card anymore. Working ACIAs are too hard to find.

[StormTrooper]

Thanks for the info. That is unfortunate. I guess it would either require a hardware mod (dip switches) or hack the original fireware.
Serial cards are horribly expensive now so thought this would be a good alternative.

[btb]

I tried changing the firmware so it just loads a couple of constant bytes and that didn't help. (see https://forum.vcfed.org/index.php?threads/apple-iie-diy-serial-card.1237266/page-4#post-1285999)

I wonder if it's due to a flaw in the ROM select logic instead? I notice it depends on RWB and A11, which the original card doesn't seem to AFAICT. Do you have any notes for how you came up with the GAL equations?

[btb]

I see the chip enable for the 74x245 (called "LATCHCE") looks a bit different as well, not taking the latch into account like the Apple SSC does. I think maybe with some new equations this could be made to work.

[polpo]

@btb thanks for noticing that the select logic seems off. I took a stab at some new equations based directly on the Apple SSC schematic but I'm not having much luck. I've replaced the following original equations:

C8EN = C8EN * /A8 * /A9 * /A10 * /A11 * /IOSTRB * /RES
     + IOSEL
ROMOE = C8EN * IOSTRB * RWB
      + IOSEL * RWB
LATCHCE = DEVSEL + IOSEL + IOSTRB

with:

IOLATCH = /IOSEL * IOLATCH + RES + IOSTRB * A8 * A9 * A10
/ROMOE = /IOSEL * /IOSTRB + /IOSEL * IOLATCH
/LATCHCE = /DEVSEL * /ROMOE 

The above is a simplification of the following logic which more directly follows the schematic. BTW the schematic is fun to follow, as the LS279 SR latches are used as inverters or NAND gates, or as a sort of SR with the roles of S and R flipped.

IOLATCH = /(/(/IOSEL * IOLATCH) * /RES * /(IOSTRB * A8 * A9 * A10))
/ROMOE = /IOSEL * /(IOSTRB * /IOLATCH)
/LATCHCE = /DEVSEL * /IOSEL * /(IOSTRB * /IOLATCH)

Hopefully someone who is better at boolean logic or schematic reading than I am can make a better attempt. Or maybe my equations are correct and something is wrong with the board I built.

[StormTrooper]

I'll give this a test on the 2 boards I built and see what happens.

Glad to hear others are working on this as it would be a shame to give up on this project

Update: No luck - I don't think it's your board.

[ryucats]

Jumping in really late here ...

... it looks like one of the issues is that the GAL isn't mapping the C800 region correctly. I think this because the monitor shows the correct code at C200 (in my case, SSC in slot 2) but garbage in C800.

Replacing the ROMOE line in the .pld file with:

ROMOE = IOSEL
     + IOSTRB
     * /A8 * /A9 * /A10

... which is a closer match to the logic as described in the SSC programmer's manual (page 46) makes the correct code show up at C800.

The card still doesn't survive running SlotScan, which may be due to a missing jumper block, but this appears to map the ROMs correctly at least. There's more work to be done unmapping C800 when CF00 is accessed -- this was just a quick validation of the card design.

[ryucats]

I think I've got the GAL code nailed down. I redrew the ROM select logic in KiCAD for clarity, then recreated the logic 1:1 in WinCUPL (as I'm more familiar with that than galasm):

Name            Simple Serial Card;
Partno          SSC0001;
Revision        01;
Date            3/9/23;
Designer        Chris RYU;
Company         RyuCats;
Location        None;
Assembly        None;
Device          g22v10;

/* Inputs */

Pin 1 = reset;
Pin 2 = CTS;
Pin 3 = io_C800;
Pin 4 = slot_select;
Pin 5 = io_slot_access;
Pin 6 = RW;
Pin 7 = A11;
Pin 8 = A10;
Pin 9 = A9;
Pin 10 = A8;
Pin 11 = A3;

/* Outputs */

Pin 14 = rom_c800_enable;
Pin 15 = rom_latch;
Pin 16 = ls245_enable;
Pin 17 = eprom_a8;
Pin 18 = eprom_a9;
Pin 19 = eprom_a10;
Pin 20 = rom_enable;
Pin 21 = PHI2;
Pin 22 = d0;

/*  Latch (RS flip-flop) definition:
    Q  = (Q & RESET) # !SET;
*/

PHI2 = !slot_select; /* per schematic */

cf00_access = io_C800 # !A8 # !A9 # !A10; /* CF00 access, pull low */

/* 
    if either reset or cf00 access is pulled low, then rom_latch = 1
    if io_slot_access is 0, then rom_latch = 0
    if io_slot_access is 1, then rom_latch = no change
*/
rom_latch = (rom_latch & io_slot_access) # !(reset & cf00_access);
rom_c800_enable = rom_latch # io_C800; /* enable if both pulled low */

ls245_enable = ( io_slot_access & rom_c800_enable & slot_select); /* c800 ? */
rom_enable = (io_slot_access & rom_c800_enable);

eprom_a8 = A8 # !A11;
eprom_a9 = A9 # !A11;
eprom_a10 = A10 # !A11;

This appears to do the right thing regarding mapping in C800 when Cx00 is accessed, and unmapping again when CF00 is touched. SlotScan still hangs, but it seems to be happening during the slot probe now, rather than when it tries to switch to 80-column mode with the SSC ROM still sort of mapped in. I think that's caused by the aforementioned lack of DIP switches, but I'd need to modify the ROM to verify and I'm a bit pressed for time for the next few days.

A .jed file is attached for non-WinCUPL users to test.

Edit: I'm not sure that the D0 voodoo is complete/correct; I put a no-slot clock under the SSC ROM and it's properly detected, so I'm reasonably certain the ROM side of the logic is okay.

Edit edit: I have no idea what the D0 logic is supposed to be doing when the DIP switches (and the '365s that the D0 logic looks like it should be gating) were removed.

Edit edit edit: it works. SlotScan "crashed" because I hadn't re-wired the 80-column card back into the video path (my test rig is a Franklin ACE 1000, so the aftermarket 80-column card needed to do video passthrough). The SSC shows up as a normal serial card now. Use ssc-cr-2023030902.jed.gz (which removes the D0 logic) to program the GAL and all should be good.

ssc-cr-2023030901.jed.gz

ssc-cr-2023030902.jed.gz

[polpo]

@ryucats - I gave your .jed a try. I just happened to be rewriting and testing out the GAL equations myself after seeing your first comment from a couple days ago, and just now refreshed the page and saw your comment.

Apologies as I'm a big Apple II noob, but here's what I'm doing to verify the GAL: I'm going into the ROM monitor, typing c200 to latch the c800 enable, then typing c800 and repeatedly pressing return to start reading the ROM. I'm not reliably seeing the contents of the ROM come out on c800. Sometimes the first few bytes read reliably but then it seems that the latch resets and I start getting A0 on the monitor. I hooked a scope up to pin 14 of the GAL to see activity on the c800 enable signal, and I do see it briefly going low on successful reads...

As for patching the ROM to hard-code the jumper values, see @btb's comment on the VCFed forums here - he's done the work: https://forum.vcfed.org/index.php?threads/apple-iie-diy-serial-card.1237266/page-4#post-1285999

[ryucats]

@polpo Yes, I'm seeing similar behavior -- thanks for letting me know, I was about to issue a pull request.

I'm not getting garbage, though. After seeing the correct ROM code at C800 for as long as I care to hit return, I leave it alone for about a minute, look at C800 again, and it's replaced with the 80-column card C800 code. Completely deterministic so far. But that's probably just a side-effect of the difference between your test platform and mine.

Here's a guess:

cf00_access is getting tripped by a spurious hit on CFxx. Which means that IOSTROBE had to go low while A{8,9,10} went high. The schematic for the original SuperSerialCard filters those three address lines with a series RC scheme to (I guess) debounce transitions.

As it's pretty hard to weld a resistor and a capacitor into the middle of a GAL, I'm thinking maybe add a check for !A11 into the cf00_access statement. It shouldn't be necessary, as those three address lines high plus a low IOSTROBE equals CF00 access ... but given the "do this with as few parts as possible" design philosophy behind the original SuperSerialCard, I could see an RC scheme being used instead of an additional chip for a four-input AND gate.

Let me try that real quick and get back to you ... and thanks for the VCFed pointer :)

[ryucats]

... no, no good, still lose C800 on the second access. Logic analyzer time.

[ryucats]

Okay, I see what's happening:

... as soon as IOSTRB (i.e., access to C800) goes low, that's it for C800 access until it's re-enabled by access to C200.

That's happening because:

rom_c800_enable = rom_latch # io_C800; /* enable if both pulled low */
...
rom_enable = (io_slot_access & rom_c800_enable);

... which appears to be a byproduct of my equation simplification. Removing # io_C800 makes the monitor error when C200 is hit. It's something simple -- but my brain is pretty much tapioca at the moment, so I might need a bit of time to figure out what's supposed to be happening here.

[ryucats]

It looks like the design is sensitive to data bus timing. I was using a 74ACT245 for the data bus transceiver ... replacing that with a 74LS245, and no functional changes to the .pld, results in a card that keeps C800 access until CF00 is touched.

@polpo Are you using anything other than a 74LS245 as the data buffer?

[polpo]

Hmm. I'm using a 74HCT245, as suggested in this project's README. I can dig around and see if I have any LS245s... It's odd that would affect it as it's on the data bus, but I'm willing to entertain anything at this point.

With the GAL equations I've been working on, I could get C800 access to be stable if I repeatedly read from C2xx before reading C800. A single read on C200 isn't enough to reliably set the latch long-term. How finicky...

I was going to experiment with using the GAL22V10's registered outputs and add a couple bodges to latch A8-A10 with PHI0 as a clock to see if it would remove any spurious states on the address bus that look like CFxx.

[ryucats]

I would take the parts recommendations in the README with a grain of salt -- it seems clear that the original designer didn't ever get the ROM logic working (c.f. the vestigal '365 select logic using A3/D0), so the timing differences between a TTL '245 and a CMOS '245 affecting the C800 ROM portion would not have been noticed.

Edit: so what's happening, I think, is the CMOS '245 is latching the data bus before the ROM has noticed that it has been selected and then fed a byte to the '245, hence the garbage.

Introducing a delay between ROMOE being pulled low and the '245 being enabled might do the trick. Just moving rom_enable to after ls245_enable doesn't appear to work. I think the GAL is much faster than the discrete logic it replaced, so there'd need to be a bunch of no-ops between the two?

Edit: by "no-op" I mean running one of the ls245_enable inputs through a couple of inverters to create a delay.

[polpo]

@ryucats I didn't have an LS245 in my parts stash so I ordered one and tried it yesterday. What an improvement! Both your .jed and the galasm-based one I've been hacking on work much, much better.

Calling IN#2 from BASIC still doesn't work quite as expected, but I'm still not 100% confident in my board. For example I can't send commands to change baud rate after typing IN#2, but at least garbage characters appear on the screen when I type on the other end of the serial connection.

[StormTrooper]

I've also ordered some LS245's and can then run some tests as well on the 2 PCB's I have.

[jmthompson]

Sorry I'm late to the party. :)

GAL speed is likely part of the issue. My original build was using a 7ns GAL (because I have a lot of them for other projects) and it was way too fast and nothing worked right. It worked much better with a 15ns part; a 25ns GAL would probably be even better but I don't have any that slow.

BTW thanks everyone for fixing this up in my absence. I'm still kinda shocked there is so much interest in something I just thew together to try to get software onto my Apple IIe. I stopped working on this though because I had trouble finding reliable ACIAs, and ended up with an Uthernet II card instead. I occasionally mull over the idea of redesigning this card to use an ACIA built inside of a CPLD, but I don' t have the itch to scratch anymore.

[polpo]

I keep thinking to myself that I should dive in and emulate an SSC on a Raspberry Pi Pico. I’ve done ISA card emulation with a Pico so an Apple II card should be possible.

[ryucats]

@jmthompson When you say that you couldn't find reliable ACIAs, were you talking about NOS NMOS ACIAs, or the currently-available WDC 65C51?

The reason I'm asking is that you are recommending CMOS ACIAs in README.md; the WDC part has a reasonably well-known showstopping transmit bug (discussed at http://forum.6502.org/viewtopic.php?f=4&t=2543 ) that makes those parts essentially worthless for most applications, and NOS CMOS 65C51s are IME always defective. NMOS, on the other hand, seems to be okay -- does that match with your experience?

[jmthompson]

@ryucats yeah I am aware of the WDC bug, though I had completely forgotten about it until after I made the schematics and boards. In this case I'm talking about my poor luck at finding the NMOS parts on eBay that actually worked reliably. I had one whole batch, for example, that just returned $FF no matter what byte was received, and wouldn't transmit at all. That's why I mentioned the idea of recreating the ACIA in a CPLD (or maybe a Raspberry Pi Pico plus some level shifters).