Dragon 64 motherboard replacement

[Giranda]

Thanks very much for the help, and no worries at all. I just wanted to check with you before I started hacking away at my motherboard, only to find out later that I'd come to the wrong conclusion and made a right old mess!

I think I've got all LS chips in the issue 5 board but I'll go check that in a sec... Is there a particular problem with HCT gates and floating pins? I'm only a software engineer, so I can usually follow the logic of the gates in a circuit but I don't know most of the rules for their electrical properties very well.

I'm also investigating a little weirdness with behaviour of cartridges in the expansion port when an Oojamaflip is connected, so once I've verifed the lower case board is working, I'll start looking into that next.

I have a CoCoSDC and DragonMMC which both work fine when connected directly to the cartridge port, so the port itself is okay but when I plug in a pull up adapter and oojamaflip (ready for a SuperSprite FM+ which isn't built yet), the DragonMMC continues to work fine, but the CoCoSDC starts misbehaving. I haven't connected both SD carts at the same time or anything daft, I'm just testing them one at a time, with nothing else in the second Oojamaflip port.

When the CoCoSDC is connected via the Oojamaflip, it seems to initially boot okay but then won't load anything from the SD card, and just gives a "BT error" when a load command is entered. Not sure what that means yet, and have to keep reminding myself it's probably not a Bluetooth or British Telecom error!

Anyhow, that's tomorrow problem, I'll go modify my motherboard and let you know how it goes with the lower case board.

Cheers again for your help, have a great evening!

[sixxie]

I think I've got all LS chips in the issue 5 board but I'll go check that in a sec... Is there a particular problem with HCT gates and floating pins?

They're CMOS, and CMOS doesn't like floating inputs - I believe the uncertain state can cause them to transition rapidly, leading to high current draw.

[Giranda]

Ah okay, thanks for the info, I will keep that in mind when choosing logic ICs in the future.

I made the change to the motherboard, so the _MS line is linked to _FS and not +5v, and can confirm the lower case board is now working great.

Thanks very much for your help!

[Alastair]

When the CoCoSDC is connected via the Oojamaflip, it seems to initially boot okay but then won't load anything from the SD card, and just gives a "BT error" when a load command is entered. Not sure what that means yet, and have to keep reminding myself it's probably not a Bluetooth or British Telecom error!

In DragonDOS BT stands for boot error.

[Giranda]

Thanks, I've just RTFM'd myself, and looked up the error code appendix in the DOS manual, so I don't have to keep asking "what about this one?" over and over.

The CoCoSDC is throwing a BT error if I type BOOT, and an IV if I try to DIR, so it just can't read the SD card I think, but only when it's plugged into the Oojamaflip. The DragonMMC is fine via the Oojamaflip, so I don't think it's the flip itself. Not sure what's causing it yet, but first guess would be voltage drop when the SD card is accessed and maybe pulls quite a bit of current.

Cheers!

[robcfg]

Wasn't there an issue with CoCoSDC and some boards that required adding some pull up or pull down resistors to some cpu tracks?

I have that small pcb on my 64 (the one with the resistors on the cpu socket) and my CoCoSDC work fine with Oojamaflip.

Another thing to check would be what else are you connecting to the Oojamaflip.

[bluearcus]

Yeah, if you are getting strange CoCoSDC behaviour, I'd always look as a first option at obtaining and fitting a pullup board.

[Giranda]

Hi again, sorry for being slow to reply, I wanted to take time to check all of the various combinations of things I have before posting an update.

I'm still having the problem when trying to use the CoCoSDC with the Issue 5 motherboard if it is connected via any sort of cartridge port expander. I've tried a couple of different cartridge port expanders, including an oojamaflip but without any success. I've tried both expanders with, and without a pull-up adapter but this did not help. I tried swapping the 6309 out for the 6809 from my original D32 board but that didn't make any difference either.

In all cases, and with all combinations of cart expander, pull-up adapter and CPU, the CoCoSDC works fine with the original D32 board. Whether it is connected directly, via either the Oojamaflip, or via the other cartridge port expander I have, and with or without a pull-up adapter fitted, regardless of CPU 6309/6809, It just works.

When the CoCoSDC is connected directly to the D64 issue 5 motherboard, it works fine and the pull-up adapter and CPU type make no difference but if I try to get it to work via either the Oojamaflip, or the cartridge port expander, the computer will start and it looks like the CoCoSDC has completed bootstrapping, but if I attempt to launch any software (SDXC or a disk), I just get an error. Does anyone know if this is also an issue with original D64 boards? If it is I can move to it's own thread instead of this one.

I'm a bit stuck as to what could be causing it now, I'm sure it must be something to do with signalling but I've no idea what. Does the CoCoSDC use any other signalling lines which aren't fitted with pull-ups on the adapter, or might be noisy and need a little filtering?

I wondered whether it might be worth trying to add some extra caps for the power drain when the SD card is accessed, or maybe inductors to filter any noise the SD card and Atmega in the CoCoSDC might be leaking back to the Dragon's expansion port but I don't really know where to start.

Any ideas anyone might have for what to try next would be very gratefully accepted!

[sixxie]

Can't think of a reason it wouldn't work. We're talking adding a couple of centimetres to the signal path via a port you know works otherwise. Weird.

I had a board similar to the oojamiflip and ran a disk controller off it for years on a real D64. I might still have it around - I'll report back if I find it!

[bluearcus]

I'd be suspicious of the 3.3v signal level output-ness of the CoCoSDC.

The CoCoSDC design doesn't have a dedicated voltage regulator to bring supply down to 3.3V from the Dragon's 5V. It uses a regulator on the SD card reader module. Try measuring the 5V line on the CoCoSDC and the supposed 3.3V out on the SD module for the scenario where you are connected to the Dragon directly, and to the Dragon through an Oojimaflip or similar.