HuCard CARD_DETECT line on Duo/Duo-R/SuperCDROM?

[elmer]

Ugh, that's a total bummer. So you're getting a bus fight and the internal SCD-RAM is winning.

And that is a VERY-BAD-THING™, and will cause both the TED and CD Stupid Card (and ANY 1MB flash-or-RAM card) to have both the card's memory chip and the internal RAM chip fighting to both respond to a CPU "read" request at the same time.

At least, that's the case when the SCD RAM is unlocked.

I'm going through this in my head, and hope that someone with electronics experience can help me understand this.

In the case of the CD Stupid Card and the TED v2 and TheOldMan's ROM/RAM card, all the cards have SRAM mapped into the 512KB $080000-$0fffff region which will overlap the DUO's 192KB of SCD RAM at $0d0000-$0fffff.

AFAIK all these card designs will respond to a CPU "write" request to the overlapped RAM at the same time that the SCD RAM is doing the same "write" ... and so both RAM chips will end up containing exactly the same memory contents.

If we've got 2 SRAM chips which contain exactly the same data, and they're both responding to a CPU "read" request at the same time, with the same byte, and so either both trying to drive the same data bus lines high, and both trying to drive the data bus lines low ... then is this still a problem ... there's no "conflict" as such?

Now, I do understand that in the case of uninitialized random data, there certainly could be a conflict between the 2 chips ... but in the real world games don't read uninitialized data, because there's just no point in a programmer doing that.

For myself, I've run a couple of SCD games that use the SCD RAM with both the CD Stupid Card and the TED v2, and I've not seen any problems. TailChao obviously didn't see any problems when creating the CD StupidCard, and I'm going to assume that TheOldMan hasn't seen any problems, yet, either.

I understand that things are different with a 1MB FLASH card that's unlocking the SCD RAM ... because the unchangeable flash will definitely have different contents to the RAM. In that case, it's probably "uninitialized" flash memory, which IIRC is going to default to $ff.

So that would still be a VERY-BAD-THING™, but do we really have problem on the cards that have RAM?

[TailChao]

So that would still be a VERY-BAD-THING™, but do we really have problem on the cards that have RAM?

It's an average BAD™ problem to have two devices driving the bus if they have the same value.

It's not a VERY-BAD™ problem until both cards have different values in RAM and you perform a read where both will respond and try to drive the bus to opposing states.

In the case of the CD Stupid Card, it's only an issue when you switch into linear mode, or if you read willy-nilly from uninitialized memory.

Either way, it should be corrected.

[elmer]

It's not a problem until both cards have different values in RAM and you perform a read where both will respond and try to drive the bus to opposing states.

OK, that's what I hoped.

I think that that means that a 1MB-RAM card is still viable ... even though it wouldn't be considered "best-practice".

It would just mean clearing the upper 256KB to zero in the same piece of CD boot code that shadow-copies the BIOS into the lower 256KB, which is trivial.

Or does the whole idea now fall into the too-stupid-to-do category?

In the case of the CD Stupid Card, it's only an issue when you switch into linear mode, or if you read willy-nilly from uninitialized memory.

Either way, it should be corrected.

Definitely! I'm glad that it sounds like an easy-fix to patch the BIOS.

I should probably post a warning on KRIKzz's forum about using an unpatched BIOS image with the TED v2.

[TailChao]

I think that that means that a 1MB-RAM card is still viable ... even though it wouldn't be considered "best-practice".

It would just mean clearing the upper 256KB to zero in the same piece of CD boot code that shadow-copies the BIOS into the lower 256KB, which is trivial.

Or does the whole idea now fall into the too-stupid-to-do category?

I wouldn't say it's "too-stupid-to-do" quite yet. But I'd like to see if there's a way to disable the SuperCD RAM after it's been enabled.

I should probably post a warning on KRIKzz's forum about using an unpatched BIOS image with the TED v2.

I've now got a TED v2.x compatible patch (v3.6) in the CD Stupid topic if someone is willing to verify it.

[elmer]

I wouldn't say it's "too-stupid-to-do" quite yet. But I'd like to see if there's a way to disable the SuperCD RAM after it's been enabled.

It would certainly be great if it were a re-triggerable flip-flop instead of a one-time-latch ... thankyou for looking at this and for fixing the CD StupidCard so quickly! 

I've now got a TED v2.x compatible patch (v3.6) in the CD Stupid topic if someone is willing to verify it.

I wish that I could help, but I don't have mine.

On the positive side ... it just got delivered at it's destination in the Ukraine today, so I'm hoping that I'll get the replacement in a few weeks.   

[elmer]

But I'd like to see if there's a way to disable the SuperCD RAM after it's been enabled.

I burned a small test program onto CD and tried a few combinations of writes to $18c0 (the SCD RAM unlock register) to see what would happen.

The program starts with SCD RAM unlocked by the System Card, and I did tests by writing to bank $7F and displaying the memory to see if the data was written OK, or even visible at all.

Write $aa $55 to register ... no effect, RAM still visible and writes enabled.
Write $00 $00 to register ... no effect, RAM still visible and writes enabled.
Write $55 $aa to register ... no effect, RAM still visible and writes enabled.
Write $a0 $50 to register ... no effect, RAM still visible and writes enabled.

So, at this point I'm reasonably confident that we're not going to be able to re-lock/hide the SCD RAM once the System Card 3 BIOS has unlocked it.

I've tested the "unlock" on the TED v2 with a System Card 3 image, followed by a "hard-reset", followed by a System Card 2 image ... and the SCD RAM is still unlocked.

So I think that it's going to require a console power-off to lock it again.

***************

I've also tested the how the TED v2 handles loading a System Card 3 image.

It switches itself into read-only mode ... but it still seems to be mapped into the entire bank $00-$7F region.

Unless it's doing some non-obvious bank mapping that I'm not aware of, this is a VERY-BAD-THING™.

!!! IMPORTANT !!!

It means that TED v2 owners really need to run a patched System Card 3 image if they're going to use it to run CD games on a Duo/Duo-R/SuperCDROM.