Dragon 64 motherboard replacement

[Giranda]

Hi Sixxie,

I've been trying to get one of Jon's lower case boards working with my issue 5 motherboard but so far I'm not having much luck, as the issue 5 board refuses to start up when the lower case board is connected. The lower case board works fine with my original D32 issue 2, so I don't think there's a problem with that.

I was comparing the original D32 and D64 schematics with the one for the replacement board, to try and work out what might be different, and if I am reading the schematics correctly, the _MS line is tied to _FS on the original schematics, but is connected to +5V on the Issue 5.

When I traced the connections on the lower case board, it doesn't seem to connect to _FS on the motherboard, but it does connect to the motherboard _MS line, and also to both the socket it has for the MC6847, and also to _PE on the 74HCT161 counter the board uses uses to drive some of the address lines for the external character ROM.

So, I *think* (if I am tracing things correctly), the lower case board is passing the _FS signal from the 6847, back to the motherboard via the _MS connection which it is expecting is also tied to _FS, but which is actually tied to +5V on the issue 5 motherboard.

Do you or anyone know if this is likely to be the cause of my non-booting issue 5, which just has some garbage on the screen whenever I power it up with the lower case board attached?

Any help, insight or advice would be very gratefully accepted, I'm currently trying to resist the urge to start tinkering and patching things, when I am not 100% sure I know what I'm doing, as I'll probably get myself into trouble break my motherboard!

[sixxie]

Interesting - yes, you'll certainly have hit on the issue there!

My "issue 4" didn't connect MS# at all, as the connection wasn't clear on the scans I'd transcribed from. I fixed mine by bodging it to +5V, as there was no reason in the Dragon's operation for it to ever tristate the address lines (and anyway, I think my DA0 is connected to an HCT logic gate, so I never wanted its inputs to be floating).

But if the lowercase board uses that pin to feed back to FS#, than yep, that's a problem. Annoyingly, it's much easier fixed on my "issue 4" as I can just resolder the bodge wire (and replace that HCT gate with an LS). I'm guessing you'll have to break a track and _then_ solder a bodge

Well, sorry about that... it must be time for an "issue 6"!

[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 I have (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 tomorrows 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!

[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.