Oops, my obsession with computers from my childhood strikes again!

[stephen_usher]

Did they provide the CPL file so the you can compile the GAL code for the chip using WinCPL?

Good to see the old girl working again.

Freeze spray is just butane or propane, nothing conductive.

[rubber_jonnie]

Did they provide the CPL file so the you can compile the GAL code for the chip using WinCPL?

Good to see the old girl working again.

Freeze spray is just butane or propane, nothing conductive.

I actually have the JED file specific to that apple part number for both GAL and PAL. I did try to read the original but it seems like it's encrypted/protected.

As for the freeze spray, it's shall we say vague about the contents other than it's a 'mixture of gases', however there was obvious condensation after using it on the ICs and I suspect possibly some of that got into the sockets, so giving it a proper clean did the trick.

It is good the have her back running again, but I have just figured out the 80 column/RAM issue too, and it seems to be the MMU. It's definitely temperature related as adding 2 small heatsinks to it extends the time the problem takes to occur. In addition if I freeze spray the heatsinks on the MMU while the problem is occurring, the problem clears.

TBH this is the worst outcome really, as unless I can rig up some cooling that will make it behave until I can find a replacement, then it'll be stuck with just 64K and no 80 column display.

As for a replacement, that's another story altogether...

[stephen_usher]

Well, we could look at the original Apple II slot control circuitry, replicate that and sit the MMU daughter board containing that circuitry. After all, the rest of the MMU is obviously functional and the slot decode logic would not have changed.

It would probably just need address decode and access to the R/W line to determine the direction of the transceiver. i.e. “is the address being accessed within the slot address range?” yes/no + “is it read?” yes? Then put the direction from the slots to the main bus.

[rubber_jonnie]

Well, we could look at the original Apple II slot control circuitry, replicate that and sit the MMU daughter board containing that circuitry. After all, the rest of the MMU is obviously functional and the slot decode logic would not have changed.

It would probably just need address decode and access to the R/W line to determine the direction of the transceiver. i.e. “is the address being accessed within the slot address range?” yes/no + “is it read?” yes? Then put the direction from the slots to the main bus.

I'll be honest, the thought had crossed my mind, but it is a little out of my wheelhouse. Be interesting to do though.

[stephen_usher]

Hmm... Reading this makes it look a little more complicated... There's DMA involved.

P.S. Looking at the original schematics though, it doesn't look too bad: https://www.applefritter.com/files/styl ... k=haqfMWKl

[Tomswork]

@rubber_jonnie

Yes I have used there code to program both types of gals and they have both worked

Tom

[rubber_jonnie]

Hmm... Reading this makes it look a little more complicated... There's DMA involved.

P.S. Looking at the original schematics though, it doesn't look too bad: https://www.applefritter.com/files/styl ... k=haqfMWKl

Apparently there is an excellent description in "Understanding the Apple IIe by Jim Sather, so I'm going to have (another) look there, but I also read some info on other forums (Don't berate me for visiting other forums!!!) that says some of the soft switching, like PR#3 to jump into 80 column mode is handled by the MMU, so I think that will complicate matters.

I've attached that PDF and just renamed to TXT for uploading purposes.

[rubber_jonnie]

@rubber_jonnie

Yes I have used there code to program both types of gals and they have both worked

Tom

Did you use a 16V8B GAL or a 16V8? The 16V8 seems to be much faster, so that may be my problem when using the 16V8B.

[Tomswork]

@rubber_jonnie

Good question i will have to look may have been a 16v8 d part


Tom

[stephen_usher]

Apparently there is an excellent description in "Understanding the Apple IIe by Jim Sather, so I'm going to have (another) look there, but I also read some info on other forums (Don't berate me for visiting other forums!!!) that says some of the soft switching, like PR#3 to jump into 80 column mode is handled by the MMU, so I think that will complicate matters.

I've attached that PDF and just renamed to TXT for uploading purposes.

But we know that this part of the chip is still working correctly so we don’t have to replicate that. The aim is to do a minimal replication of the functionality which has failed.

Just to confirm, without the 80 column card the other peripherals also stop working after the MMU warms up?

If this is the case then it’s most likely the transceiver direction control that’s broken. In this case a simple 16V8 can be used. It will need address lines 13, 14 and 15 for address decode, R/W and /IOSELECT for CPU access and Phi0 plus DMA for card DMA access. You probably don’t even need Phi0 as that’s up to the peripheral timing.