exxos's Atari, Amiga & retro forum

They are even a bit ropey on the A4000

GadgetUK164 wrote: 28 Jan 2021 15:35 Thanks, I will give that a go!

Just had a look at the drive I put in, It's a Pioneer DVR-110D DVD RW

I can't see why any IDE CD ROM drive wouldn't work tbh.

alenppc wrote: 02 Feb 2021 17:50

lilwashu wrote: 02 Feb 2021 17:46 I ordered one of these cards, and have exactly the same behaviour which is a pain. I cloned the A2000 install I put onto the Sandisk CF on the evening it worked onto an SD card, put the IDE-SD adapter from my A1200 back in the A2000, and it works.

Totally mystified as to why the CF card isn't working in the A2000 - I would like it to as the SD card doesn't mount well in the case.

This is such a strange behaviour. Can you try my disk image and let me know if you get the same problem? Will PM you the link.

I tried the image and no joy, so decided to call it a day and plug the A1200 SD card adapter in permanently, copied everything across, then put the CF adapter into the A1200 which worked the other day, and IT DIDNT WORK.

I had a look at my H2 adapter under a magnifier and everything looked fine until I lightly prodded some of the connections from the CF slot to the board with a pick and they moved. I've resoldered them and it now works in the A2000.

So it looks like I had a CF adapter with dodgy joints and therefore intermittent function. Thanks to Alen for the help, hopefully that will be it!

Well glad it's finally sorted. Those cheap China adapters are sometimes badly soldered, sometimes I have to reflow them as well.

I've just found two pins on the D2 adapter in a similar state so will reflow those at some point and give it a try.

Just to close this off, the D2 adapter (came attached to a rear slot bracket, 40 pin with external power) works fine when all the pins are soldered to the board.

I see several mentions that the 536 locks up when using with the A2091 and thought I'd post my findings in regard to that

While working on the Buster CPLD replacement I found that Buster doesn't signal bus requests to the coprocessor slot unless /BOSS is asserted which causes the A2091 to lock up as it never gets a bus grant (because the CPU never sees the request).

I found that grounding the /BOSS signal on my coprocessor slot adapter and that allowed the system to boot so if your system needs to support DMA of some kind (Like if you use the A2091 with vb2091 to support DMA in a Z3 system) you will want to do this unless the TF is plugged into the CPU socket rather than the slot.

LIV2 wrote: 09 Mar 2021 17:12 I found that grounding the /BOSS signal on my coprocessor slot adapter and that allowed the system to boot so if your system needs to support DMA of some kind (Like if you use the A2091 with vb2091 to support DMA in a Z3 system) you will want to do this unless the TF is plugged into the CPU socket rather than the slot.

Nice find. So its possible the adaptor needs to assert Boss?

Yep, you're meant to do some bus arbitration before asserting boss (/BR, wait for /BG then assert /BOSS) before Buster will give the copro control but if you haven't got a CPU in the motherboard socket you can just ground /BOSS on the riser and you're good to go.

I am working on adding proper arbitration to SukkoPeras riser (so you can leave the other cpu in) as I need to test that the copro arbitration of my Buster replacement but I'm not sure when I'll have that done

As a step to that I've already updated his adapter to add solder jumpers to ground /BOSS and cut off the E clock which has been upstreamed to his repo

in practice just holding BOSS low seems to work on most setups. I think the proper ARB is to make sure the motherboard CPU goes through proper reset cycle then stops in a good state.. which isnt guaranteed if you do it the brute force way but works probably 99% of the time.