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

[elmer]

Has anyone done any experiments to see exactly how the HuCard slot's /CARD_DETECT line disables the built-in CD BIOS on the Duo/Duo-R/SuperCDROM?

Can it be changed at any time, or is it latched at power-on?

Is it the same mechanism that's used on all of the machines?

Does the 64KB of CD RAM in banks $80-$87 also get disabled?

Inquiring mind(s) need to know!   

[TurboXray]

From what I know; the effective change happens immediately upon the change from the hucard side. Well, whatever the propagation delay is, but it should be faster than any bus cycle of the cpu.

 Only the lower 1megabyte range is changed; the upper range remains as is. The 64k in the upper range mapped by the original base CD system, is always there when attached. This allows Duos and SuperCDROM addon units access to the 64k when older system hucards are inserted (Bios 2.x and lower).

 A word of caution about CD ram in bank $80/87 range: don't use it for page #1. For some reason, it causes issues (wrong values being read).  Any of the memory from $68 to $7f is fine to map into page 1 (address $2000). I found this out when doing nes2pce stuffs. Otherwise, it works fine mapped anywhere else (including page #7 which houses the interrupt vectors).

 IIRC, this is how the later version GE cards work on Duo/SuperCD units - bus access to rom changes on the hucard -> the card changes the state of the hucard detect pin, otherwise when accessing banks $68-7f it disables the hucard allows access to that ram. This is for the later GE cards. Mednafen author would probably know more (I never had any GE cards to test myself).

 Also to note: there's open bus address ranges in the upper 1megabyte range. The Arcade card, both pro and duo, map in interface registers in the $1a00-1aff range (hardware bank #$FF). That's pretty convenient cause that bank is always mapped there. The reason they chose $1a00-ff range is interesting; maybe some hardware dev stuff had additional mapped things in around this address range as well.

 The arcade card also mapped stuff in lower banks $40-43. These are mirrored corresponding I/O ports per 8k bank. I suspected that on the Duo card, they used the hucard detect pin, but now that I think about it - that's probably open bus range as well ($40-$67).

[elmer]

Thanks, that's exactly what I wanted to know, and exactly what I hoped was going on.

That means that a 1MB-RAM HuCard is possible. 

[thesteve]

more than that the arcade card DUO doesnt use card detect, and does add a ram bank

[ccovell]

Super CD RAM ($68-7F) also needs to be unlocked before using it:

   lda   #$AA
   sta   $18C0
   lda   #$55
   sta   $18C0   ;Unlocks Super CD-RAM!

[TurboXray]

The card calls EX_MEMOPEN first before writing those. Has anyone tested to see if reading from $18c5, $18c6, and $18c3 is required first?

[elmer]

Super CD RAM ($68-7F) also needs to be unlocked before using it:

   lda   #$AA
   sta   $18C0
   lda   #$55
   sta   $18C0   ;Unlocks Super CD-RAM!

Does anyone have any idea why they've even put that "lockout" in there?

Are there any carts that don't activate CARD_DETECT, but do still actually put stuff into the 3rd-256KB region ($0c0000-$0fffff) that would cause a conflict?

Perhaps they were just "being safe"?

While I'm asking ... does anyone know of any carts or add-ons that have been mapped into the $140000-$17ffff or $180000-$1bffff 256KB regions?

Just for fun, I'm trying to figure out how to make the cheapest but practical 1MB-RAM card, and have found that it would only take one additional 12cent part to make it "stealthy" and have it activate when a specified 256KB region is written to.

Is there any reason that anyone can think of to avoid that being the "obvious" $80000-$bffff region and make it one of the higher regions instead?

[TailChao]

Are there any carts that don't activate CARD_DETECT, but do still actually put stuff into the 3rd-256KB region ($0c0000-$0fffff) that would cause a conflict?

Perhaps they were just "being safe"?

My concern is moreso whether or not CARD_DETECT is honored over this enable sequence (i.e. if a card is present, the internal 192KB of RAM can absolutely not be unlocked).

If CARD_DETECT is ignored, there's the potential for bus fights both in the TED v2 and CD Stupid Card.

[ccovell]

Well, I only have a SCD-ROM2 to test my things out with, but using a GameofYou flash cartridge containing PCEmon (so no intermediate software like on the Everdrive), all of the CD RAM is accessible from the cartridge, SCD-RAM starts out locked, and reading $18XX is not necessary before unlocking it.

[TailChao]

Well, I only have a SCD-ROM2 to test my things out with, but using a GameofYou flash cartridge containing PCEmon (so no intermediate software like on the Everdrive), all of the CD RAM is accessible from the cartridge, SCD-RAM starts out locked, and reading $18XX is not necessary before unlocking it.

Ugh, that's a total bummer. So you're getting a bus fight and the internal SCD-RAM is winning.
I'll have to update the modified SCD 3.0 software in the CD Stupid Card.

[TurboXray]

I have a way to check to see if unlocking SCD ram disables the detect pin feature.

[thesteve]

im fairly sure the cart detect pin only effects the rom mapping
as in cart in disables internal rom, while everything remains unchanged
using a system cad in a duo doesnt conflict only because the internal and external timings match

[elmer]

Well, I only have a SCD-ROM2 to test my things out with, but using a GameofYou flash cartridge containing PCEmon (so no intermediate software like on the Everdrive), all of the CD RAM is accessible from the cartridge, SCD-RAM starts out locked, and reading $18XX is not necessary before unlocking it.

Ugh, that's a total bummer. So you're getting a bus fight and the internal SCD-RAM is winning.
I'll have to update the modified SCD 3.0 software in the CD Stupid Card.

I'm too much of a newbie to have been around for GameOfYou's flash card, so I did a bit of searching and then found the schematic for it at ...

http://www.gamingenterprisesinc.com/Flash_HuCard/

So the problem is that he's tying the CARD_DETECT line low in hardware ... which probably should disable the 192KB of SCD RAM ... but Chris is telling us that it doesn't.

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.

So, if I'm understanding this, the "solution" would be to modify the SCD BIOS image on the CD Stupid Card and the TED to not actually do that "unlock" sequence anymore ... is that right?

I've not looked (yet) ... is that "unlock" process a part of the BIOS, or is it something that CD games do themselves?

I have a way to check to see if unlocking SCD ram disables the detect pin feature.

Thanks!   

[thesteve]

a duo has 4 ram banks in it
the work ram, is tied directly to the data bus with its own chip select pin off the 6280
the V-Ram is on its own bus and only directly connected to the 6270
the CD system ram is on the main bus, but uses 2 chip select pins off the D91317GD
the ADPCM has its own bus off the D91317GD

[TailChao]

So, if I'm understanding this, the "solution" would be to modify the SCD BIOS image on the CD Stupid Card and the TED to not actually do that "unlock" sequence anymore ... is that right?

I've not looked (yet) ... is that "unlock" process a part of the BIOS, or is it something that CD games do themselves?

It looks like the unlock is part of the BIOS, @ $286B (mapped to $C86B). It calls EX_MEMOPEN and then decides whether or not to do the write sequence based upon its return.

Unfortunately, I only modified the jump table to point to a dummy EX_MEMOPEN. I'll need to change any direct references like this and stray write sequences. If a game does the write sequence directly, I can't do much about it.

Edit : It seems this is the only time the RAM is unlocked, and the BIOS is also using the return of EX_MEMOPEN to change whether it displays "SUPER CD-ROM2" or "CD-ROM2." Unless there's some packed code in the BIOS I don't know about, we should be fine.
I'll have some patches tomorrow.

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