A600 CPU adapter (PLCC to DIP64)

[Maximilian]

I think I'll update the scematics and PCB so that the adapter works like the patched version.

Some crazy ideas:
1. Use the original (defunct) IDE connector as a support for the PCB, you could also get a nice and beefy 5v there
2. Remove the 68000 completely and do a zero wire type pcb install, the only problem is that not all software will run on an 68030, but that could probably be fixed in the software itself or with different WHD load settings.

The second option would be nice as imho i'm not totally sure the original CPU isn't causing the problems.

It's a shame i don't have an A600 PCB to operate on, but I don't have a Logic analyzer or the skills do debug it as well.

[raffles]

Hi Guys,

Please excuse the long first post. I'm interested in trying my TF534 on the A600. I've run up a design for an adapter similar to the one discussed in the thread but, prior to fabrication, was just wondering what the eventual conclusion from the discussion was with regards to the required signals for disabling the A600 CPU?

The last schematic posted shows BR and VPA on the accelerator side being pulled to +5V via a 1K resistor as well as BR being pulled to GND via a 220 on the CPU side.

In his video TF Live - The flame burns on the A600? - TF suggests that BGACK should also be held low and that some additional soldering would be required.

Assuming any signal in my current design can be easily broken up and jumpered to hi/lo on both the CPLD and/ or CPU side what signals would be useful in the jumper header?

I understand that some testing has been done with the the current design by various users but TF did also suggest on the video that some components on the 600 side were getting hot which made me think that perhaps the disabling needs optimization.

Also, would BR and VPA on the accelerator side be better pulled to +3.3V rather than +5V If a linked jumper wire from the accelerator was able to provide 3.3V to the adapter? I appreciate that the CPLDs are 5V tolerant but was just wondering if this was more desirable / worth the hassle.

Apologies for all the questions, the thread was interesting but it did seem to trail off a bit towards the end so I thought it would be useful to consolidate the information gathered.

Thanks

Raffles.

[kludge]

Yeah, _VPA and _BR @DIP64 are pulled high through a 1 kohm resistor, and _BR (and indirectly _VPA, as they are tied together on the A600 mainboard) on the PLCC socket are pulled low through a 220 ohm resistor). I think you are correct in that Stephen thought that messing with _BGACK could be a solution. I haven't messed with this anymore, as noone (as in the 3-4-5-ish people that's got the adapter) has been able to get the TF534 working reliably, while both the TF536 and Matzes 030 accelerator showed great promises. I was holding off until the 536 release before diving deeper, but when that got canned I kind of zoned out.

I've been thinking about making a pure A600 accelerator from Matzes designs, but I haven't started yet. And I don't know if I ever will :D

I have the eagle files published on my gitlab page for a straight adapter with the footprint for the upside-down PLCC connector if you need something to base your design on. Or are you done with that part? I think it would be awesome if you could make it work!

(I think I'm kinda close to 100 % sure of the pull-ups/pull-downs mentioned above. I looked through a couple of images to check it out, but I could have gotten something mixed up.)

[raffles]

Hi Kludge,

Thanks for the reply and for your original research into getting this up and running. I have the adapter pretty much designed and ready to go in KiCad - No Eagle ransomware here :). The PLCC64 USD footprint is done and I've added two M2 mount holes 74.5mm apart to utilize HDD cradle mount points on the motherboard. This will hopefully avoid any seating issues.

I just wanted to confirm the signals that were used and also what potential signals to jumper out for experiments. I've split out VPA, BR, BG and BGACK into 68K and Accelerator/CPLD sides with the option to pull either up or down via jumpers to individual SMD resistors. That will allow me to recreate your original configuration as well as introduce BGACK into the equation.

If I manage to get this to work I'll recreate the released TF534 Eagle project over in KiCad and route it up for the PLCC 68K footprint with the inclusion of the appropriate CPU disable logic once I've firmly established what that is. The adapter ultimately is only really useful for experimentation. Thanks again for your help and I'll let you know how I get on.

If anyone else wants to chip in with suggested signal configurations to try, let me know.

Cheers.

[dalek]

Just FYI in case you haven't seen it, over at a1k.org Matze has a design for a 68000-DIP->68000-DIP switch for the A500 that I've been meaning to try out one day...

[mkl]

Hi.
I think you shouldn't connect E/VPA/VMA from PLCC 68000 to DIP socket, the 68000 doesn't tristate these with bus grant? A pull-up resistor at DIP socket /VPA.
A600 doesn't use these from 68000, but GAYLE makes CIA cycles from normal 68000 cycles.l

[mkl]

220 ohm pull down with 1 k pull up makes 0,9volts.Maybe 47 ohm, or can you ground the bus request, then switch off halt/reset or something on dip socket using 2n7002 or fdv301 from bus grant.

[terriblefire]

Hi.
I think you shouldn't connect E/VPA/VMA from PLCC 68000 to DIP socket, the 68000 doesn't tristate these with bus grant? A pull-up resistor at DIP socket /VPA.
A600 doesn't use these from 68000, but GAYLE makes CIA cycles from normal 68000 cycles.l

The low end Amigas dont actually ever use BG/BR/BGACK. So i dont think this is an actual problem. It will be an issue on the STE.

[mkl]

In A600 the on board 68000 needs to release the bus, pulling bus request low should start this process.

[terriblefire]

Ok now i understand what you mean... i.e. both CPUs are going to be driving E/VPA/VMA...?