Search results

Yeah, I don't think Woz has much control over what Apple releases, that'll be squarely in the court of the legal department, and sadly, it's much easier to say no than it is to potentially open yourself up to some form of legal liability. At least they've allowed the release of the IWM spec...

Well, ish. =D It is backward compatible with the Disk II, but some features are entirely new. Some of these are relatively trivial (slow/fast mode just halves/doubles the clock, for example), but the asynchronous mode that the Mac uses is a bit more complex...

So I've been playing around with this for a bit and I've started wondering, why make a minimal, corner-cutting clone of the IWM when I can make a full-fledged clone of the IWM? And I think I might be able to, all in logic. The target platform is a pair of ATF1504s, one as the clock generator...

Like the !ENBL1 and !ENBL2 lines? I know the IWM has no head select mechanism but I've never heard there was anything awry with the drive select lines...

I've spent a bunch of time trying to nail down the logic side of this, and after several false starts, I think I have a working strategy. I hope one day to use a Renesas GreenPak or two in one of my designs, but it won't be this time, sadly - I'll be using an Atmel ATF1504 CPLD for the CPU...

Thanks for the suggestion, and I know it comes from a good place, so please don't take what follows as an attack, it is not meant that way. (Also, please forgive the string of ham-fisted metaphors.) I die a little inside every time someone tells me to use an RP2040 or STM32 or whatever the...

Ladies and gentlemen, my next trick is impossible improbable... It seems like the IWM is the only (or at least the biggest) thing standing in the way of a Plus or SE made of entirely new parts - and possibly also the biggest problem for those trying to revive an old board. For completeness's...

Gah, sorry for the late reply, this fell between the proverbial cracks... _______________ _____________ | \o o o o o/ | | | _____ | | |___\o_o_o_o/___| |_|_________|_| ||||||||| ||||||||| ||||||||| ||||||||| ||||||||| ||||||||| |||||||||...

Uploading the hex file with ghofbauer's change for an external oscillator here, in case anyone else finds it useful.

Sure, I can do that, though if it is the clock that's still at fault, I'd really like to be able to cook up a solution that just slots in without any external hacks like this...

This is great stuff! I love how many subprojects contributed to make it possible and I'm happy to have played a small part in realizing it. What's left besides the IWM to make a Plus that's totally free of parts that have to be recovered from vintage machines?

Hmm. Well, it's a data point, at least. I assume it's the same PIC16F87/88 you're testing in both boards and it works in one but not the other? Also, I've forgotten - do you have a TechStep? If so, can you check on the working SE whether the PIC16F87/88 passes the ADB test? Other than that...

Yup, that looks right. Try the hex file I attached earlier, though, I'm hoping that will answer some questions...

Well, the configuration registers are outside the normal program memory space for the PIC, there's probably some special way of looking at them in your programmer's app. Not sure what it might be because I've never used the official app for the TL866+...

Address 0x2007 should be 0x3F30, address 0x2008 should be 0x3FFC.

I'm still thinking a quirk of the timing is the most likely cause... as before, there's very little else it could be. Looking at the configuration register bits for the PIC16F87/88, if the TL866/T48 somehow didn't program them (left them all set to 1), it seems like the PIC would never work at...

I can send it to you once I'm done with it.

Thanks for the offer! Email sent.

That is hard to explain. I have to imagine it's something to do with the different clock speed of my port... maybe there's a change in the characteristics of the PIC's internal RC oscillator as it warms up that starts outside of spec and gradually moves into spec? That's just a guess, though...

Interesting. This doesn't point to a load issue, I don't think. This could still be an issue with TashRouter, but it might also be an issue with someone on the network creating an illegal packet and TashRouter gagging on it. TashRouter really should just discard the packet and keep on...