A few years ago I bought a few Dallas DS1216E clock modules. Like this:
They are direct replacements for the original SMT "No Slot Clock". It goes underneath the CD ROM in the IIe or the CF ROM in the Platinum IIe, and under the system ROM in a IIc.
They contain an embedded 3 volt cell of which all are long dead. There is a hack to attach an external battery like a CR2032. I further modded the chip by grinding out the potting epoxy around the embedded coin cell and physically disconnecting it by grinding away its leads, and then re-potting it in epoxy to prevent any leakage.
All well and good - I installed them in several of my systems and they've worked for years.
Recently the one in my daily use IIe failed. The driver wouldn't recognize the clock's presence in the system. I got one of my spares. Same thing.
I tried the installed ones in my other machines - all of them failed.
So I bought four more.
One of them failed right off the bat. No recognition.
The funny thing is, the driver recognized the presence of the chip, but by the time bootup was complete and the No-Slot-Clock utilities ran, they couldn't find the clock. Rebooting, the driver failed to recongnize the clock. All the remaining three did the same thing.
Now why do you suppose that all of these DS1216E modules failed all at once? And across multiple systems.
I'm loath to buy a new production No-slot-clock from Reactive Micro at US$40 plus another $30 shiping to Canada, it'll cost me $100 (canadian) or more just to get it here and if it too fails...
Anyone have any ideas?
You can also find it on AliExpress: https://www.aliexpress.com/item/1005002495649607.html
If it doesn't work, always ask for full refund.
Probably not the answer you're looking for, but instead of paying $40 for a NSC consider the ROMXe/c/c+ products. That gets you all of the ROMX features plus a built-in RTC with replaceable battery (that will last much longer than the NSC and keep more accurate time). Yes, you'd have to use a different ProDOS driver but think of all the other added benefits: dead RAM memory test, phantom warmstart elimination, etc.
If this does interest you, I may still have a $20 off discount code for these (part of a promo that I was offering to the FujiNet group to help spur development). Send me a DM if you want one.
First thing I would do is, to measure the battery voltages of all clock modules... then the next step can be discussed.
If you changed all module batteries (using a CR2032) at the same time... it might be possible that all of them reached EOL in between because of they are all produced at the same time / batch
That's an interesting concept, and I thought that might be the case at first but I don't think it is relevant, because even with dead batteries these clocks should work when powered by the computer. The batteries are only for keeping time with the computer powered off.
That said, I do have fresh (3.2V) power from CR2032 coin cells.
Haven't tested it yet... but I do have 2 NoSlotClock Apple II machines and I will see by tommorrow if they are still working... and let you know more details then.
Curious to know what your situation is.
Sorry for the delay... so my Dallas 1216E "no slot clock" is working as expected.
Clock reading after more then > 8 month while I didn't used the Apple IIe... overall only a couple of minutes wrong
IMG_20221228_140838.jpg
Setting new time...
IMG_20221228_183301 (1).jpg
and readout after a complet reboot
IMG_20221228_183416.jpg
So... I don't have any issue here... not sure why you're having such trouble...
Yeah, I am not sure either. I have to do some more testing when I have time. I will repeat the tests across several machines.
Are your No Slot Clocks genuine ones from SMT, or generic Dallas DS1216E composite chips?
All no-slot clocks I'm using are Dallas DS1216 Chips... which I'm using in a IBM 5155 (XT Portable), too.
IMG_20230103_173524 (1).jpg
Hope this helps...
Update on the situation.
I have been running my IIe systems experimentally with new production Western Design Center's WDC6502S CPU chips. Some pin modifications are necessary to get them to work, but they run perfectly well. The pin modification is as follows:
Lift pin 1 and leave disconnected.
Lift pin 35 and tie it to pin 8. Pin 8 remains connected.
Except...
They don't seem to get along with the Dallas DS1216E no-slot-cock chips. I am assuming that there is a timing issue somewhere or a bus voltage level issue that is otherwise ignored by either the modern CPU or the clock chip.
So I went to the parts bin and found an old production GTE Micro G65C02P-2, 1985 production CPU and swapped it. Lo and behold the clock was regognized and I could set the time.
I have tried a couple of the Dallas DS1216E chips that I relegated to the "bad" pile, and returned them to the "good" pile.
I'm not sure that is an adequate adapter for a WDC chip in a //e. Someone had posted abot an Open Source project for an adapter socket for that on here within the last year. It has a couple of discrete components, resistor and maybe a cap or diode. I don't remember off the top of my head. I actually made a couple of them from PCBs I was sent and they work fine. Didn't try them with a no-slot-clock though, so I can't say if they'd solve that problem. I'll have to dig around and see if I can find one of them and see what is on there.
Here's one of the related threads...
https://www.applefritter.com/content/w65c02s-adapter
Here's another:
https://www.applefritter.com/content/w65c02s-6502
Hope that helps...
For what it's worth, all of the WDC 65xx CPUs appear to be incompatible with the DS1215 with stock drivers.
I've personally tested Plamen's //e accelerator and his 65c816 replacement, as well as various iterations of WDC65c02S interface per their application notes; Plamen's stuff has a 100% failure rate, and the WDC-with-various-lifted-pins-and-pullups has a 90% failure rate. A quick Google search shows someone on Facebook reporting the failure to Plamen, but no root-cause analysis.
I suspect that the WDC is switching state on eithet !CE or !OE faster than the DS1215 can handle.. When work slows down a bit, I'll pull my logic analyzer out of storage and see if I can't work out what's wrong.
Edit: there's a bit at the bottom of the ReactiveMicro NSC wiki page (https://wiki.reactivemicro.com/No-Slot_Clock) that might be relevent:
"I played around with NS.CLOCK.SYSTEM to try to investigate the issue. As you can see from the above, it is not an issue of the accelerator speed since it fails with UW at 1MHz.
"I discovered that inserting a load from somewhere in $C0xx in NS.CLOCK.SYSTEM magically made it work. I settled on LDA $C00B, since this seems to have no documented effects. I built a modified NS.CLOCK.SYSTEM called NS.CLKUW.SYSTEM which seems to work fine on all systems with or without UW installed. This seems to be a corner-case bug in the Ultrawarp logic.
"Modded and fixed NS.CLKUW.SYSTEM can be found here: https://github.com/bobbimanners/ProDOS-Utils/tree/master/No_Slot_Clock"
I think Bobbi is not exactly correct in her assessment -- the problem stems from the UltraWarp's WDC65c816, not the UltraWarp logic. I won't be able to test this possible fix until next week; OP, you might want to try her NS.CLKUW.SYSTEM with the WDC CPU.
Update:
I think that CRYU is on to something. I grabbed a copy of the Bobbi Manners NS.CLKUW.SYSTEM disk image from the github page.
It works well enough with a regular garden variety 65C02.
But with the W65C02S installed it does say the driver is installed on bootup (a step forward) but the time reads 00:00:00 (a step backward) and the NSC utility program doesn't find the clock. So no joy there.
To answer softwarejanitor's comments:
I tried the WDC W65C02S using WDC's instructions of lifting pin 1, Lifting pin 36 and tying it to pin 8. The machine runs perfectly and passes diagnostics, but doesn't like the NSC driver (either of them)
I also tried with the adapter board as shown in this thread https://www.applefritter.com/content/w65c02s-adapter which adds a bypass capacitor and two pullup resistors. The machine works equally well, but same issue with the clock driver...
Back to the drawing board. I will try reaching out to Bobbi Manners, maybe.
I should probably point out that Bobbi's implementation of the "fix" is, um, a bit sloppy.
Classic ProDOS clock drivers must be a maximum of 125 bytes, full stop, because they're written over the built-in clock driver. The stock NSC driver, which Bobbi patched, is 125 bytes. There's no room for three more bytes of WDC workaround.
What she did was chop code off the end of the driver (restores $CFFF from the stack before exiting) to make room for the necessary $C0xx access at the beginning. In fairness that is fine for anything earlier than a //e. Not having either a //e or the technical reference manual immediately at hand, I don't know what the ramifications of not restoring ROM state is on a //e ... but that code was most likely there for a reason.
The driver code itself is used to probe the NSC. I think, but am not able to confirm until next week, that an all-zero read from the NSC would pass the probe's consistency check.
I don't see any room for further byte-saving in the driver (assuming that their scheme of saving ROM state is actually valid on a //e). I strongly suspect that she tested this on an UltraWarp-equipped ][/][+, since the UW uses a WDC chip and it only passes the initial probe on your WDC-equipped //e.
A very (very!) quick disassembly of NS.CLOCK.UTILS shows that it has the original driver embedded in the executable, and uses that for probing rather than the installed (patched) ProDOS driver.
Without knowing all the information, what I gleaned from Bobbi's website and github page is that the original NSC driver had scanning routines to search for the clock. So it queried each slot to see if the NSC was underneath a ROM in a slot card - (I've run NSCs on a II+ under the Super Serial Card's ROM in the past) and then the F8 ROM on a II+ and finally the CD/CF ROM on a IIe / system ROM on IIc.
It self-modified to read the clock in the position it was found.
The modified UltraWarp code assumed it was a IIe and permanently set the card at the CD/CF ROM position. That's how she was able to keep the code at the correct byte length.
But being a total dunce in assembly language, that's all that I know.
Ah, you're right. I was barking up the wrong tree because I didn't read the README.md. She documented what she did, and it is supposed to work on all platforms.
I still believe that she is wrong about it being an UltraWarp issue, because none of us can get it working with a WDC chip, UW or no UW.
I'd really like to know the underlying issue, as I have a couple of these and I want to free up a slot in my Franklin. When I get home next week, I intend to a) test her driver on my Franklin to see if it breaks the same way for me as it does for you, and b) when that fails wire the logic analyzer to the NSC and compare NMOS behavior with WDC CMOS behavior.
(i.e., "let me get back to you because I'm intrigued and confused that this doesn't work in the first place")
Okay, so I got back last night. I hooked everything up this morning. Here's how it went:
I then spent about a half hour comparing the capture with the DS1215 datasheet, and confirmed that the protocol capture matched the specification. It did.
Armed with this, I installed a WDC 65C02 into the Franklin. I then executed the same test procedure, but omitting the initial time setting (because, natch, it had already been done).
After executing NS.CLOCK.SYSTEM, I noticed that the driver didn't complain that it couldn't attach. I fired up NS.CLOCK.UNIL ... it detected the NSC, and the time was correct.
I turned the Franklin off, waited fifteen minutes, turned it on. NSC was still detected.
I then installed Plamen's 65C816. Same deal -- everything worked.
I unhooked the Saleae from everything, in case the probes were somehow positively interfering with the test. Nope, everything still worked.
I have a couple of guesses what's going on, in descending order of probability:
If the last guess is correct, then I'll wire in the Saleae at that point and debug further.
Try out the a2stuff driver and see if that gets you going.
Ah. I see ...
... it does *not* work on the motherboard, nor on an Apple2Card. The NSC works with a WDC CPU *only* if it is behind a 74LS245 (aka an octal bus transceiver). I got lucky testing it with a SSC, which does buffer the data bus with a '245.
So that indicates that the WDC isn't driving the data bus hard enough for the NSC, or isn't keeping the signal on the bus long enough ... or the other way around.
I'll do another logic analysis in the near future to figure out if this can be fixed in software (I doubt it) or if we need to interpose a '245 ... but the quick fix right now is to put it on a SSC and use the driver in the above post.
What's the speed of your WDC chip?
The 65c02 is clocked at 1MHz. Plugged into the logic board per the notes at https://www.westerndesigncenter.com/wdc/AN-002_W65C02S_Replacements.php
Adding a pull-up resistor (I used 6.8k) between pin 11 (D0) and pin 28 (Vcc) on the NSC appears to fix all issues. The NSC isn't driving the address line high enough for the WDC.
Edit: that made it 90% better, but it failed to detect a couple of times. I think lowering the resistor value to 4.7k might be better. @baldrick, does a pull-up improve the detection for you?
That is fantastic sleuthing, CRYU, thanks!
I will test that in the next day or so and report back. Ideally it ought to run with the corrected driver from https://github.com/a2stuff/prodos-drivers, which I'll probably use henceforth if this experiment works.
Update.
The following tests were done on an enhanced IIe.
Card compliment: 64K in Aux slot, Disk II controller in Slot 6, Super Serial Card in Slot 2 (as appropriate - see below) generic parallel card with onboard 2716 ROM
Using the updated NSC driver as posted at https://github.com/a2stuff/prodos-drivers
Using a Dallas 1216E variant, which is a generic version of the original SMT No Slot Clock.
With 65C02:
Clock found in S2 under SSC ROM (with appropriate pin bridges)
Clock found under CD ROM on motherboard
No issues
With WDC65C02S modified with pin 1 lifted, pin 36 and tied to pin 8:
Clock found in S2 under SSC ROM (with appropriate pin bridges)
Clock not found under the 24 pin ROM on a generic parallel card in slot 2 (but there's no 74LS245 on that card)
With no pullup resistor: Clock not found under CD ROM
With 3.3K pullup resistor between pin 28 and pn 11 on the clock/ROM: Clock not found
With 4.7K pullup resistor between pin 28 and pin 11 on the clock/ROM: Clock not found
With the WDC65C02S with pullup resistors on the CPU as per the WDC site:
Same as above. No joy.
The regular 65C02 did not care whether there was a pullup resistor present or not. It always found the clock.
So my results did not match yours. I will keep testing. I have a few ideas, but I am not opposed to running the NSC underneath the Super Serial Card's ROM if all else fails.
Let me try again. Baldrick, what speed is your WDC cpu?
Hmmmm. I'm out of ideas -- I've moved it under the $D000 ROM, detected. Dan ][, detected. SSC, detected.
I'm using Henry's ReactiveMicro NSC, which *shouldn't* be different, but maybe it is.
Or perhaps it's bus timing; you're on a //e, and I'm on a Franklin. The Franklin is a bit off with bus timing -- the FloppyEmu won't work with an Apple FDC, only the uSci.
Or maybe the NSC is terrified of my logic analyzer.
The chip is the current production chip, part number W65C02S6TPG-14, which is rated to 14 MHz maximum.
The system itself is running at the stock 1.0 MHz.
Is this important?
My guess is that the 14MHz part has tighter tolerances on the data setup and hold times. Rather than a level issue (and adding a resistor to one line of the data bus is probably not the best solution), this is probably a timing issue. Adding a bus transceiver between the DS1216 probably adds enough delay to make it work. Just my guess; haven't looked at all the data sheets to confirm...
Hey folks! I'm the maintainer of the a2stuff repos. Watching this thread with interest! I'll keep an eye out here but if anyone needs a build to test a driver patch or has a fix, please let me know!
I'm guessing it's timing rather than signal level as well. If it was signal level then the pullup resistor on the data line may have solved the issue as it did for cryu.
I don't have a logic analyzer so comparing timing with the garden variety 65C02 will prove difficult.
There are some uber-cheap logic analyzers available like this thing: https://tinyurl.com/523a7kcj but I wonder if they're any good...
Adding a bus transceiver to the clock is not a trivial thing to do. It's not impossible, mind you, but the clock is already more than twice as tall as the ROM chip itself, and the only good thing about it in a IIe is that it is more or less in line with slot 6, and disk drive controller cards are mercifully short.
I've now tried various cmbinations of WDC65C02S / WDC65C02S with pullup resistors and the original 65C02.
I've tried various values of pullup resistor on the A0 line on the bus at the clock.
There is no instance of any WDC65C02S where it recognizes the clock on the motherboard.
On the Super Serial Card, underneath its ROM, it works perfectly, but as cryu noted it is behind a 74LS245 bus transceiver.
All a pullup resistor does at A0 on the clock is raise the voltage from about 1.0V RMS to about 1.26V RMS - a noticeable rise in level without affecting timing.
This got me wondering if there is a way to delay just the signal at the clock using a couple of transistors. Could they (a) be made into a bidirectional circuit, and (b) offer a similar delay as an LS245...
I think you want to play with the D0 line, not A0.
It seems like the answer to this whole issue is probably just to use an older 65C02 instead of the WD65C02S if you are using a Dallas clock chip. It isn't that hard to find a suitable part. Either that or if you must use the WDC part then put the clock on an SSC or other card like that with a suitable EPROM socket... Unless it's just an interesting exercise I'm not sure it's worth more working on it.