RIP to BT Garner of MindRec.com... He passed away early 2023 from health problems. BT was one of the top PCE homebrew developers and founder of the OG Turbo List, then PCECP.com. Condolences to family and friends.
IMG
IMG
Main Menu

Flash based HuCard project

Started by Pierre95, 01/05/2016, 10:49 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

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!

Quote from: Pierre95 on 01/05/2016, 10:49 AMI 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/


QuoteHowever, 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.


QuoteWhat 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/
Gaming since 1985

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

Quote from: Pierre95 on 01/06/2016, 04:52 AMI 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

Quote from: Pierre95 on 01/07/2016, 08:08 AMYou 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.


QuoteHowever 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).


QuoteAnd 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!  :wink:

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

OldMan

Quotebut 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

Quote from: Pierre95 on 01/10/2016, 05:37 PMOK 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

Quote from: Pierre95 on 01/13/2016, 06:52 AMIf 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.

NightWolve

https://shop.retrogate.com/everdrive/turbo-everdrive-v2-buy

IMG

Description
The Turbo EverDrive v2,4 is a flashcart for the TurboGrafx-16 and PCEngine, which loads the ROMs in the console itself. The handling of the flashcart is very simple. Plug your microSD card into your Turbo EverDrive v2,4 and plug your Turbo EverDrive into the HuCard slot of your system.
 
Features

PCEngine and TurboGrafx-16 systems are supported.
FAT32 file formats are supported.
Supports microSD cards up to 32GB.
Instant loading.
Street Fighter II mapper support.
On board reset button.
4Mbyte of ROM memory.
Cart may not work properly with region modded systems.
USB port for developers (optional).

elmer

Quote from: NightWolve on 01/13/2016, 02:02 PMhttps://shop.retrogate.com/everdrive/turbo-everdrive-v2-buy
Yes, I'd just buy a Turbo EverDrive, too ... and did.  :wink:


Quote from: Pierre95 on 01/05/2016, 10:49 AMI 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.
But perhaps he really does want to design his own ... some people enjoy doing that kind of thing.  :-k

Vimtoman

I agree it's great to see someone having a bash at it.

thesteve

you know, if you run the system bus through a PIC you could just have it running a loop untill the rom is ready and then going active
would require likely a slightly bigger chip then GameOofYou used as it would need to map the system bus and program the chip, whereas his only programs the chip
also doing that you could run lower voltage flash as it would be buffered

Pierre95

@elmer

The documentation at http://archaicpixels.com/HuC6280 does not specify the state of the address bus when /RESET is low but the documentation says:

Quote/RESET terminal
A program is started by reading lower address from the physical address 0x001FFE and upper address from the physical address 0x001FFF when a RESET input becomes Low.
Which can be interpreted as "the processor outputs the physical addresses 0x1FFE and 0x1FFF when /RESET is low" So the address bus is probably not at high impedance when /RESET is low. But as you say elmer, it should be verified through experimentation.

@NightWolve, yes the Everdrive is a great product but for educational purposes, I find it interesting to design a similar hardware.

Pierre95

Hello,

Line A20 of HuC6280 is named XCE on the Hucard connector. This line is used as the ROM chip select. This is OK for 1MB or smaller ROMS as all ROMs fit this size, except street fighter II which is 2,5MB. This means this ROM requires some memory banking to allow reaching the extra segments which dos not fall in the 21 bits addressable space, right?

I am a bit confused about the addressable segments.

Here http://emu-docs.org/PC%20Engine/pce_doc/pce_memory.html

It is written Hucard storage goes till F6h =1968KB

But here http://www.db-elec.com/home/technical-info/tg16/memory-map

it says the space between 80h and F7h is unused (reserved for CD ROM) so what is the truth about that?

Also here: http://emu-docs.org/PC%20Engine/hw.html

It seems segments 01 of ROM is unused, but when looking into a ROM file through hexeditor, there is data in this segment...

elmer

Quote from: Pierre95 on 01/30/2016, 06:32 AMI am a bit confused about the addressable segments.
I recommend that you ignore everything on emu-docs.org, they don't seem to have a clue, and are just plain wrong.

Try this instead ... http://www.archaicpixels.com/Memory_Map

HuCard space is just the lower 1MB of the processor's 2MB of address-space.

If you've not already seen it, this is the document that you should be looking at ...

Charles MacDonald's TurboGrafx-16 Hardware Notes
http://www.romhacking.net/documents/302/

"Street Fighter II" fits 2.5MB into the 1MB of HuCard address space by adding a secondary banking mechanism to switch the contents of the top 512KB region of the HuCard address-space.

Pierre95

Thanks a lot elmer, both links are really helpfull.