Flash based HuCard project

[Pierre95]

Hello,

I recently put a PC engine GT back to life by changing its capacitors and found it would be interesting to design a Flash based Hucard so that games could be downloaded through USB.

However, I have questions about the signal named XCHECK corresponding to HuCard pin number 1.

According to turbografx schematics, this pin is pulled up through a 4,7K resistor, but I didn't find the component (IC) where this signal is connected. XCHECK should inform the system that a card is inserted.

What is the state of address and databus when no card is connected? Is it high impedance?

Thanks a lot if someone can provide some help.

[elmer]

Hi, and welcome to the forum!

I recently put a PC engine GT back to life by changing its capacitors and found it would be interesting to design a Flash based Hucard so that games could be downloaded through USB.

If that's something that would interest you, and you don't want to use any of the existing flash HuCards, then I hope that you have fun with the project!

You can take a look at this as one example of an existing design (complete with schematic) ...

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

However, I have questions about the signal named XCHECK corresponding to HuCard pin number 1.

According to turbografx schematics, this pin is pulled up through a 4,7K resistor, but I didn't find the component (IC) where this signal is connected. XCHECK should inform the system that a card is inserted.

Yes, that's its purpose (it is normally known as the "CARD DETECT" signal).

Most HuCard designs just hardwire the pin to ground.

It is not directly used on the base PC Engine or PC Engine GT or Turbo Grafx ... but it is sent out to the expansion port, and it is used on the Duo/Duo-R/Duo-RX/SuperCDROM to disable the built-in System Card 3 ROM whenever a HuCard is inserted.

What is the state of address and databus when no card is connected? Is it high impedance?

No, they're driven by the processor. The HuCard bus is just a physical extension of the regular CPU address and data buses.

[esadajr]

You may wanna get in touch with gamingenterpricesinc (forgot what his nickname is in this forum). He developed the low cost flash Hucard.

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

[Pierre95]

Hello,

Thank you for your replies. I aldready had some discussions with the guy from gamingenterprisesinc. His design is simple and use very few components however it requires removing the card from the console while Flashing to avoid conflicts between the console buses and the PIC IO ports. A similar conflict exists between VCC from console and USB VCC.

I was guessing if the CARD DETECT signal was not used internally to maintain the CPU in a halted/high impedance state till the insertion of an HuCard. This could be used to solve the conflict mentionned above.

But from your answer, I understand that the signal is only used to toggle between a built-in system card 3 accessed through expansion bus, and the Hucard (Hucard has priority over Card 3 ROM). This means the CPU is constantly driving the address bus even when no HuCard is inserted.

[elmer]

I was guessing if the CARD DETECT signal was not used internally to maintain the CPU in a halted/high impedance state till the insertion of an HuCard. This could be used to solve the conflict mentionned above.

But from your answer, I understand that the signal is only used to toggle between a built-in system card 3 accessed through expansion bus, and the Hucard (Hucard has priority over Card 3 ROM). This means the CPU is constantly driving the address bus even when no HuCard is inserted.

Yes, that's correct. When powered-on the CPU will try to run the program in the HuCard slot, and if there isn't actually a ROM there, it is going to just read $FF and end up crashing.

If you don't want to remove the card in order to flash it, you're probably best off getting the CPU itself to do the flashing, and just use an FTDI USB-to-FIFO chip for the communication.

Basically, you'll end of re-creating a Turbo Everdrive v1.

[Pierre95]

You mean the PC engine CPU flashing it's own Flash EPROM? Well but this requires some bootloader residing in an unerasable segment of the Flash.

However even the FTDI USB to FIFO solution requires some isolation logic to avoid conflicts beteen the FTDI output and the databus of the CPU. And the Turbo Everdrive has a generous FPGA with plenty of logic for glue purposes.

[elmer]

You mean the PC engine CPU flashing it's own Flash EPROM? Well but this requires some bootloader residing in an unerasable segment of the Flash.

Yes, either in the flash, or in a separate ROM, or inside an FPGA.

However even the FTDI USB to FIFO solution requires some isolation logic to avoid conflicts beteen the FTDI output and the databus of the CPU.

Yes, you'd probably just make it a memory-mapped peripheral (probably somewhere in bank $FF).

And the Turbo Everdrive has a generous FPGA with plenty of logic for glue purposes.

Yes, that's the kind of setup that you'd probably need if you want the PCE's CPU to do the flashing.

Alternatively, if you still want to do the flashing from USB while the card is inserted in PCE, then you're going to have to isolate the entire HuCard address and data buses from your flashing, and you're going to need a certain a amount of intelligence on the board itself, possibly in either an FPGA or a CPLD.

You might be able to accomplish the isolation just by asserting the HuCard RESET signal during the entire flashing process ... but you might need to use actual buffers.

I really don't know ... these are experiments for you to try as you design your hardware.

Have you looked at the Cypress PSoC 5?

Have fun! 

[Pierre95]

Thanks a lot for your support

Driving the XRESET signal while programming is probably a good solution provided it puts unconditionally the address and data bus of the CPU in high impedance state.

The XRESET pin is mentionned as an input, but what happens when initiating a reset with the SELECT+RUN keys? Does XRESET remain an input, or a short pulse initiated by the CPU appears to reset other ICs like the 6270?

PSoC 5 has too much options for the expected usage, in my point of view...

[TheOldMan]

but what happens when initiating a reset with the SELECT+RUN keys?

During the pad read, there is a check for [SELECT]+{RUN]. If the key combination is pressed, the code jumps to the reset vector.  I don't believe the "soft reset" has anything to do with the hardware signals.

[thesteve]

i can confirm that
the run/select is supported only in software and simply runs a restart for the game (oftem without restarting the gpu/ram)

[thesteve]

as for the reset pin, it tri-states the data pins, but im not sure about the addresses

[Pierre95]

OK so the SELECT+RUN command initiates a software reset, but only an hardware reset puts for sure both the address and data buses in a high impedance state for the whole time the XRESET pin is low.

[elmer]

OK so the SELECT+RUN command initiates a software reset, but only an hardware reset puts for sure both the address and data buses in a high impedance state for the whole time the XRESET pin is low.

"Yes" ... you need the hardware reset ... but "no", we're not sure if that will tri-state the address bus, or only the data bus.

AFAIK, you'll need to test that yourself.

[Pierre95]

OK thank you for that precision.

If only we could get the 6280 CPU specification from NEC/Hudson... Don't know if the 6502 specifications can be considered as the 6280 Address bus can have different behaviour due too specific implementation.

The design would also have to manage isolation for control signals (/OE, /R)

[elmer]

If only we could get the 6280 CPU specification from NEC/Hudson... Don't know if the 6502 specifications can be considered as the 6280 Address bus can have different behaviour due too specific implementation.

Yes, it certainly would be nice! But since they never released the chip commercially AFAIK, I'm not sure if their internal documents will ever see the light of day.

I think that the closest thing that we've got to look at are the 65C02 documents which form the basis of the core inside the 6280.

I suspect that you're just going to have to experiment.

If you do, please let us know about anything that you find. I'm always interested to know more about the PCE hardware.