TED v2 Programming Notes

[elmer]

2016-11-30 Modified this message to be a "sticky" for the all sorts of PCE & PC-FX tools and information.
2016-12-23 Updated the version of HuC.
2017-05-15 Updated the version of HuC, fix links to Charles MacDonald's docs.

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

Here are some links to programming information for the PC Engine.

Charles MacDonald's PC Engine Hardware Notes
http://dreamjam.co.uk/emuviews/txt/pcetech.txt

Charles MacDonald's SuperGrafx Hardware Notes
http://dreamjam.co.uk/emuviews/txt/sgxtech.txt

Charles MacDonald's PC Engine Hardware Notes (original but dead link)
http://cgfm2.emuviews.com/txt/pcetech.txt

Charles MacDonald's SuperGrafx Hardware Notes (original but dead link)
http://cgfm2.emuviews.com/txt/sgxtech.txt

Tomaitheous (Bonknuts) Downloads and Blog
https://pcedev.wordpress.com/downloads-and-links/

Archaic Pixels HuC & PCE documentation
http://www.archaicpixels.com/Main_Page

The Old Rover's HuC Tutorials
http://obeybrew.com/tutorials.html

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

Here's my fork of Uli's new HuC, with a bunch of bug fixes and improvements.

The new fork of HuC
https://www.pcengine-fx.com/forums/index.php?topic=21350.0

Latest HuC build ...
https://www.pcengine-fx.com/forums/index.php?topic=21350.msg487200#msg487200

Anyone that's interested in building the tools can find the source at https://github.com/jbrandwood/huc


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

After some experimentation, I can't really recommend CC65 on the PCE at this time, but here's a conversation about it.

CC65 and the PCE
https://www.pcengine-fx.com/forums/index.php?topic=18654.0


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

Here's my customized PCE/PCFX/VB version of the Mednafen emulator.

Mednafen General Documentation
http://mednafen.fobby.net/documentation/

Mednafen Debugger Documentation
http://mednafen.fobby.net/documentation/debugger.html

You may wish to edit the mednafen-09x.cfg configuration file to change the following settings ...

Code Select Expand

;Automatically go into the debugger's step mode after a game is loaded.
debugger.autostepmode 1

;Force SuperGrafx emulation.
pce.forcesgx 1

;Treat the fast-forward button as a toggle.
fftoggle 1

I've put up yet-another new Windows build of Mednafen (with my changes) for anyone that wants it ...

https://www.dropbox.com/s/6rpkviyhgihw4gt/mednafen-0.9.38.7-x86-elmer-2.zip?dl=1

Just to remind any newcomers to this thread, the modifications are in Mednafen's PCE and PC-FX debugger displays in order to make them a bit more pleasant to look at, and more readable.

This is still a 32-bit version that only supports the PCE and PC-FX.

New features are ...

    PCE now has 480KB of SCD RAM (banks $44-$7F), plus the 2MB ACD RAM (banks $40-$43).
    PC-FX now has 8MB RAM.

    The extra RAM can be useful during homebrew development as a place to store debugging-info.

    It might also be useful for someone that needs the extra memory for a translation.

    N.B. This is a 32-bit build, but 64-bit Windows builds are now working if someone wants to build it from source.

The patch files and a build script are available at ...

https://www.dropbox.com/s/i3mor256dhrddef/build-msys2-mednafen-0.9.38.7-x86-elmer-2.zip?dl=1


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



I've created a patch for the US Turbo Grafx Super System Card so that it will safely run on the Turbo Everdrive 2.

As a by-product, this also allows the TED2 to act as a replacement for the crazily-expensive US Super System Card.

It also gives 512KB of RAM out-of-the-box for translations/homebrew.

Well ... actually it gives 768KB if you really need it, or even a full 1MB if you want to write a program that overwrites the entire System Card image, but I believe that 512KB should be enough for most people.

The new System Card image has a header so that it can be detected, and it has backup copies of the first-and-last 16 bytes of the System Card so that they can be restored if a programmer wants to enable/use any of the other TED2 hardware that's on the card.

The Street Fighter II mapper is NOT enabled, because there are some programming "gotchas" when using it, and so it was safer to disable it "by default".

To use the patch, just apply the xdelta patch to a US Super System Card image and then copy the newly patched image to your TED2's SD card.

You should see the old System Card version number replace with "TED2" and the new patch version number.


Current Patch Version 3.01 - Initial version

Patch file for USA System Card 3.0 (in xdelta3 format) ...

https://www.dropbox.com/s/zcz384fj47xu84u/TED2%20System%20Card%203.01%20USA.xdelta?dl=1

Patch file for JPN System Card 3.0 (in xdelta3 format) ...

https://www.dropbox.com/s/nuctz90ra9aoo3k/TED2%20System%20Card%203.01%20JPN.xdelta?dl=1

An xdelta3 patching utility from romhacking.net that is know to work and be easy to use ...

http://www.romhacking.net/utilities/704/

Source code file (for pceas assembler) ...

https://www.dropbox.com/s/6ufsomh9z683xwb/syscard3-ted2.asm?dl=1

[elmer]

; ***************************************************************************
;
; Turbo Everdrive V2 Programming Notes (2015-11-26)
;
; ***************************************************************************
;
; The TED v2 contains 4MB of RAM, which it maps into the PCE's 1MB of HuCard
; address space (banks 0-127).
;
; The TED v2 maps either RAM or its FPGA into bank 0 of HuCard address space.
;
; When the TED is reset, TED_REG_CFG is set to 0 and the FPGA is mapped
; into bank 0, which the CPU reset maps into $E000-$FFFF ... and so the
; TED boots into it's firmware using the normal reset vector contained
; in the FPGA firmware ROM.
;
; In order to read/write the TED's registers you've got to map out the
; entire bank 0 of HuCard address space ... which means that you can't
; do it if your code is located in HuCard RAM bank 0, and you usually
; can't do it with interrupts enabled, either.
;
; The TED v1 only mapped 256 bytes of registers into HuCard address space,
; but the TED v2 maps the entire 8KB (you can read the TED boot code).
;
; The TED's registers are normally left "locked" to prevent problems.
;
; In order to make an changes to the registers, you must first unlock
; them by writing $A5 to TED_REG_KEY1 and $56 to TED_REG_KEY2.
;
; The registers can then be "locked" again when you're finished by
; setting a bit in the TED_REG_CFG register.
;
; It is technically possible to leave them "writable" while the RAM bank
; is selected ... but I can't think of a time that this would actually
; be useful.
;


; ***************************************************************************
;
; TED_REG_CFG Bit Settings - (N.B. The register is read-write)
;
;   Bit 0 : cfg_regs_oe_off : Bank 0 mapping (0=FPGA, 1=RAM)
;   Bit 1 : cfg_regs_we_off : FPGA Registers (0=access, 1=locked)
;   Bit 2 : cfg_usb_boot    : unknown (leave zero)
;   Bit 3 : cfg_skip_eep    : Normally set by KRIKzz : unknown (set to 1)
;   Bit 4 : cfg_ram_we_off  : RAM Read-Only? (0=writable, 1=read-only)
;   Bit 5 :                 : SF2 2MB mapper (0=disabled, 1=enabled) Only $1ff0-$1ff3.
;   Bit 6 :                 : unknown (leave zero)
;   Bit 7 :                 : unknown (leave zero)
;


; ***************************************************************************
;
; TED_REG_STATE Bit Settings - (N.B. The register is read-only)
;
;   Bit 0 : st_spi          :
;   Bit 1 :                 : unused (leave zero)
;   Bit 2 : st_usb_wr       :
;   Bit 3 : st_usb_rd       : unknown (leave zero)
;   Bit 4 :                 : unused (leave zero)
;   Bit 5 :                 : unused (leave zero)
;   Bit 6 :                 : unused (leave zero)
;   Bit 7 :                 : unused (leave zero)
;

TED_STE_SPI      =      0
TED_STE_USB_WR   =      2
TED_STE_USB_RD   =      3


; ***************************************************************************
;
; TED1_REG_SPI_CFG Bit Settings - (N.B. The register is read-write)
; TED2_REG_SPI_CFG Bit Settings - (N.B. The register is read-write)
;

TED_SPI_SS       =      0
TED_SPI_SPEED    =      1
TED_SPI_AREAD    =      2


; ***************************************************************************
;
; TED_REG_MAP Bit Settings - (N.B. The register is write-only)
;
;   Bit 0  : unknown (leave zero, else hangs)
;   Bit 1  : unknown (leave zero, else hangs)
;   Bit 2  : Map RAM (leave one,  else hangs)
;   Bit 3  : unknown (leave zero, else ignored)
;   Bit 4  : Top 512KB bank bit 0
;   Bit 5  : Top 512KB bank bit 1
;   Bit 6  : Top 512KB bank bit 2
;   Bit 7  : unknown (leave zero, else ignored)
;
;   The 4MB RAM in the TED2 is split into 8x512KB banks ...
;
;   Bank 0 : Used as Top 512KB : Used for SF2 mapper $1FF0
;   Bank 1 :                   : Used for SF2 mapper $1FF1
;   Bank 2 :                   : Used for SF2 mapper $1FF2
;   Bank 3 :                   : Used for SF2 mapper $1FF3
;   Bank 4 : Same as Low 512KB
;   Bank 5 :
;   Bank 6 :
;   Bank 7 :
;
;   !!! WARNING !!!
;
;   Writing to the SF2 mapper registers only changes the bottom 2 bits
;   of the 512KB bank number, so you should set the mapper to bank 0
;   before enabling/using the SF2 mapper, or you'll get weird results.
;

TED_MAP_BANK0    =      $04
TED_MAP_BANK1    =      $14
TED_MAP_BANK2    =      $24
TED_MAP_BANK3    =      $34
TED_MAP_BANK4    =      $44
TED_MAP_BANK5    =      $54
TED_MAP_BANK6    =      $64
TED_MAP_BANK7    =      $74


; ***************************************************************************
;
; When TED is mapped into CPU space at $e000-$ffff.

TED_BASE_ADDR   =       $E000    ; SPI registers base address

;
; TED registers that are the same for TED v1 and TED v2.
;

TED_REG_SPI      =      0
TED_REG_SPI2     =      1
TED_REG_FIFO     =      3
TED_REG_STATE    =      4
TED_REG_KEY1     =      5
TED_REG_CFG      =      6
TED_REG_MAP      =      7
TED_REG_KEY2     =      10

;
; TED v1 (From KRIKzz's edio.c sample code)
;

TED1_REG_SPI_CFG =      8
TED1_REG_VERSION =      9

;
; TED v2 (From KRIKzz's bios.s source code)
;

TED2_REG_SPI_CFG =      2
TED2_REG_VERSION =      8
TED2_REG_I2C     =      9


; ***************************************************************************
;
; Example macros in CA65 format.
;
; N.B. CA65 uses the "a:" prefix to force absolute (16-bit) addressing.
;
;      Without that, CA65 will output a zero-page instruction if we set
;      TED_BASE_ADDR to $0000.
;

        ; This works on both TED1 and TED2.
        ;
        ; N.B. The 2nd write is only needed on the TED1.

        .macro  TED_UNLOCK
                lda     #$A5
                sta     a:TED_BASE_ADDR + TED_REG_KEY1
                lda     #$56
                sta     a:TED_BASE_ADDR + TED_REG_KEY2
        .endmacro

        ; This works on both TED1 and TED2.

        .macro  TED_SET_CFG_FPGA
                TED_UNLOCK
                sei
                stz     a:TED_BASE_ADDR + TED_REG_CFG
        .endmacro

        ;
        ; TED2-only macros.
        ;

        .macro  TED2_SET_CFG_1MB_RAM
                lda     #%00001011
                sta     a:TED_BASE_ADDR + TED_REG_CFG
                cli
        .endmacro

        .macro  TED2_SET_CFG_SF2_RAM
                lda     #%00101011
                sta     a:TED_BASE_ADDR + TED_REG_CFG
                cli
        .endmacro

        .macro  TED2_SET_CFG_1MB_ROM
                lda     #%00011011
                sta     a:TED_BASE_ADDR + TED_REG_CFG
                cli
        .endmacro

        .macro  TED2_SET_CFG_SF2_ROM
                lda     #%00111011
                sta     a:TED_BASE_ADDR + TED_REG_CFG
                cli
        .endmacro

        ;
        ; These USB macros should work on both TED1 and TED2.
        ;

        .macro  TED_USB_RD_TEST
                tst     #(1 << TED_STE_USB_RD), a:TED_BASE_ADDR + TED_REG_STATE
        .endmacro

        .macro  TED_USB_WR_TEST
                tst     #(1 << TED_STE_USB_WR), a:TED_BASE_ADDR + TED_REG_STATE
        .endmacro

        .macro  TED_USB_RD_WAIT
                .local  usb_rd_wait
usb_rd_wait:    TED_USB_RD_TEST
                beq     usb_rd_wait
        .endmacro

        .macro  TED_USB_WR_WAIT
                .local  usb_wr_wait
usb_wr_wait:    TED_USB_WR_TEST
                beq     usb_wr_wait
        .endmacro

        .macro  TED_USB_RD_BYTE
                USB_RD_WAIT
                lda     a:TED_BASE_ADDR + TED_REG_FIFO
        .endmacro

        .macro  TED_USB_WR_BYTE
                USB_WR_WAIT
                sta     a:TED_BASE_ADDR + TED_REG_FIFO
        .endmacro

[elmer]

Updated the header file in the first post.

Looks like KRIKzz moved some of the registers around in the TED v2 which is a bit of a pain.

I think that the SD card registers are now correct ... it seems that I can initialize the SD card and detect my 8GB SDHC card correctly. But I could be wrong.

[elmer]

I'm double-posting this because it's pretty important!

This follows on from investigations into when & how the Duo/Duo-R/SuperCDROM unlock the built-in SCD RAM chip.

https://www.pcengine-fx.com/forums/index.php?topic=20009.msg433149#msg433149

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.

[elmer]

I've written a patch for the US Super System Card 3 to allow it to run safely on the TED2.

It also gives us 512KB RAM for translations/homebrew to use.

The current version of the patch is put in the 2nd message in this thread, and I'll update that message if/when there are new versions.

[ClodBusted]

Bloody good work!

512KB should be enough for most people.

This made me chuckle.

[TurboXray]

Woot!

[elmer]

Bloody good work!

512KB should be enough for most people.

This made me chuckle.

Haha, yep, I should have said 640KB! 

Woot!

The next thing is ... "what are we going to do with the extra memory"?

I think that it might be a good idea for homebrew programmers to limit themselves to 512KB, because that would allow new homebrew to run on any of the recent cards, or TheOldMan's ROM/RAM card when they get made.

Otherwise you'd be limiting yourself to TED2 and the CD-Stupid-Card (or the 1MB-RAM card if they ever get made).

We can easily add extra utility functions (like Chris Covell's PCEmon) into the 2nd 256KB region.

I've allocated 4 bytes in the header region to use to signal the availability of any new functionality to programs ... now it just needs someone to want to actually put in that new functionality.

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

Anyway ... if people actually try this on their consoles, could they please report the results here?

I'd like to make sure that the US Super System Card functions work properly on all the different various PCE console versions.

[elmer]

Updated the source code to work with both the Japanese and the USA System Card 3.0 images.

Added an xdelta patch for the Japanese PC Engine System Card 3.0.

Renamed the USA System Card 3.0 xdelta patch to keep the naming consistent and distinct.

Updated the 2nd post in the thread with the new files.

[TurboXray]

The next thing is ... "what are we going to do with the extra memory"?

Hmm...

 I think the first thing I will do is put Megaman 2 on CD and hack in a CD audio play routine. I didn't have the ram for it before, but now I do.

 Though technically, I can also make a custom system card rom + game, and the gamer would only have to put in an audio CD/R for the music.


 So, there's supposedly 4megabytes of ram.. but how does one access it? If the SF2 mapper is unchanged, then only 2megabytes are addressable via bank switching (disregarding the initial lower 512k).

[elmer]

I think the first thing I will do is put Megaman 2 on CD and hack in a CD audio play routine. I didn't have the ram for it before, but now I do.

 Though technically, I can also make a custom system card rom + game, and the gamer would only have to put in an audio CD/R for the music.

That would be cool to see! 

The TED2-with-USB-option really is an absolute pleasure to work with.

KRIKzz provides a small program that you run on your PC to quickly upload/run a cartridge image. That makes testing stuff really simple.

The only "gotcha" is that your cartridge is run as RAM, wheras it will be run as ROM (write-protected) when it is booted off the TED2's SD card.

It's a good idea to leave the first 16-bytes of any cartridge reserved/blank so that you can map in the TED2 hardware without overwriting any of your code/data.

So, there's supposedly 4megabytes of ram.. but how does one access it? If the SF2 mapper is unchanged, then only 2megabytes are addressable via bank switching (disregarding the initial lower 512k).

The "SF2-enable" configuration bit that I've found only seems to enable the 2MB of bank-switched memory (by writing to $1ff0-$1ff3).

The obvious way to extend that out to the entire 4MB of TED2 memory would just be to extend that scheme out to $1ff4-$1ff6.

Unfortunately, that doesn't seem to work with the "SF2-enable" bit, or with any other bit combination that I've tried.

If you can figure out how to get access to the upper 1.5MB, that would be great!

Please note that something "weird" seems to happen when you set the "SF2-enable" bit.

It looks like writing to $7f:$1fff increments/changes which 512KB bank is mapped into the bank-switched region.

I can just-about-imagine KRIKzz putting this in the hardware to make it easier to just write the Street Fighter II HuCard image directly into the TED2's RAM without worrying about setting the bank number, but it's a bit annoying.

It's why I left the SF2 mapper disabled in the System Card patch ... because it could cause havok to a game that doesn't expect that to happen.

[ParanoiaDragon]

The next thing is ... "what are we going to do with the extra memory"?

Hmm...

 I think the first thing I will do is put Megaman 2 on CD and hack in a CD audio play routine. I didn't have the ram for it before, but now I do.

 Though technically, I can also make a custom system card rom + game, and the gamer would only have to put in an audio CD/R for the music.


 So, there's supposedly 4megabytes of ram.. but how does one access it? If the SF2 mapper is unchanged, then only 2megabytes are addressable via bank switching (disregarding the initial lower 512k).

If you do, I guess I'll have to definitely put MM2 on my list of soundtracks to work on, though, I'd still like to work on Jackal first.  For MM2, since songs seem to generally be longer then ones in MM!(unless it's my imagination), I suspect they won't require as much filler material, so it's "possible" that the songs won't take as long in general to compose.  Still, it could be a couple years before the soundtrack is done, which is fine by me, it's something I'd love to do, no matter how long it takes!

[TurboXray]

Hmm. I guess I should add support for CD audio for both then and put them out. I think the only thing to fix in the Jackal nes2pce rom, mainly, was the last boss scroll issue (split screen). I can't remember if I added 2nd player option to the game or not. I thought I did. I'll have to recheck. Jackal on the PCE is actually harder than the NES one, simply because the slowdown is gone. I thought about adding an easy mode option, but that's off topic to this thread. All of this is.

[ParanoiaDragon]

Hmm. I guess I should add support for CD audio for both then and put them out. I think the only thing to fix in the Jackal nes2pce rom, mainly, was the last boss scroll issue (split screen). I can't remember if I added 2nd player option to the game or not. I thought I did. I'll have to recheck. Jackal on the PCE is actually harder than the NES one, simply because the slowdown is gone. I thought about adding an easy mode option, but that's off topic to this thread. All of this is.

Gah, I don't mean to derail the thread, but I totally thought that cd audio support was already in Jackal!  Ok, back to the thread, nothing to see here!

[elmer]

Updated 1st post with the latest header/macros.

KRIKzz posted the TED2 firmware bank 0 on his forum, and that's helped give clues for some of the missing information.

In particular, we can now access the full 4MB RAM on the TED2 without using the "Street Fighter 2" mapper registers.

In fact ... because of the strange behavior with writes to the banks when using the "Street Fighter 2" mapper, I'd suggest just ignoring it and using the TED_REG_MAP register instead.

I've added macros for accessing the the USB port.

The SD Card is still a PITA, and needs a lot more work before it's cracked.

There's a newly documented bit in the CFG register ... but I have no idea what it does.

[TurboXray]

So, if you enable write mode for ram.. that means all ram is writable? 'Cause Gate of Thunder tries to overwrite a constant in the $fffx range of bank 0 of the system card, at initial boot. The one that's used to setup the starting bank (it's either $f4 or $f5).

[elmer]

So, if you enable write mode for ram.. that means all ram is writable?

Yes, that seems to be the case.

If you want to use your own CD-access routines you can use the entire 1MB of unbanked space.

That's a pretty good amount of space for a 4th-gen console.

Doing that would limit you to the TED2, or CD Stupid Card, or my mythical 1MB-RAM card ... but you could get some nice results.

Going for the full 4MB could be impressive ... but then you'd be limited to just the TED2 ... probably "forever", since the 4MB CellularRAM chip that KRIKzz is using is already "end-of-life" AFAIK.

'Cause Gate of Thunder tries to overwrite a constant in the $fffx range of bank 0 of the system card, at initial boot. The one that's used to setup the starting bank (it's either $f4 or $f5).

It overwrites $00:$1ff5.

If you look at the source for the System Card patch, I repair the damage twice ... once in the EX_SCRSIZ call that "Gate of Thunder" makes just after overwriting that location, and again when the System Card is restarted, just-in-case someone resets the card in the exact microsecond between the write and the fix ... or if something else in "Gate of Thunder" overwrites that location.

[videogameattic]

This is awesome!  I wish I would've waited and got a 2.0 Everdrive though is there a way to patch the rom to use a file on the SD card for the extra ram to be used on the Everdrive 1.2?  Sorry if this topic has been covered.

[elmer]

Sorry, it's just not possible on the Everdrive 1.2

[videogameattic]

Oh well, looks like it's time to upgrade.  Good job on this though

[Johnpv]

I was asked to cross post this hear from the Ys IV thread.

"So I wanted to see if anyone else noticed this about Ys IV, or more specifically the dubbed version.  I have a Turboeverdrive 2.4 and normally I just leave it in and use the modded system 3.01 bios with it.  With the patched version of Ys IV though I noticed the game really doesn't like that.  If I run it with the the modded for everdrive bios I get a lot of lock ups, graphical glitches and other issues.  If I play the game without the everdrive in the system, and using just the Duo's bios, I get none of these issues.   Has anyone else run into this?  I guess I should also mention I'm playing on a PCE Duo."

[Vimtoman]

I think your not suppose to use the moddified bios on an Everdrive with a Duo as it could possibly damage it.

[elmer]

I think your not suppose to use the moddified bios on an Everdrive with a Duo as it could possibly damage it.

Nope ... exactly the opposite.

You are supposed to use the modified Super System Card image on a TED v2, and not use the original unmodified image.

I'll take a look and try to recreate the problem with Ys IV when I can find the time.

It sounds weird that it would only have problems on the translation patch and not on the original version.

[TurboXray]

I was asked to cross post this hear from the Ys IV thread.

"So I wanted to see if anyone else noticed this about Ys IV, or more specifically the dubbed version.  I have a Turboeverdrive 2.4 and normally I just leave it in and use the modded system 3.01 bios with it.  With the patched version of Ys IV though I noticed the game really doesn't like that.  If I run it with the the modded for everdrive bios I get a lot of lock ups, graphical glitches and other issues.  If I play the game without the everdrive in the system, and using just the Duo's bios, I get none of these issues.   Has anyone else run into this?  I guess I should also mention I'm playing on a PCE Duo."

I think there were a couple revision to that modded bios. Are you using the newest one in which elmer fixed the bus conflict/fighting issue for Duo and SCD units?

[Vimtoman]

I think your not suppose to use the moddified bios on an Everdrive with a Duo as it could possibly damage it.

Nope ... exactly the opposite.

You are supposed to use the modified Super System Card image on a TED v2, and not use the original unmodified image.

Ah that was it 

[Johnpv]

I'll take a look and try to recreate the problem with Ys IV when I can find the time.

It sounds weird that it would only have problems on the translation patch and not on the original version.

Would it help any if I could get you footage of it?  I don't know if it does cause the problem on the original version.  I have the original version but I've just been playing through the translated patched one. 

I think there were a couple revision to that modded bios. Are you using the newest one in which elmer fixed the bus conflict/fighting issue for Duo and SCD units?

I do believe I am, but I will check and make sure when I get home from work later today.

[mj9123456]

Elmer, did you ever find out whether or not running the BIOS on the TED v1.2 is a problem?

[elmer]

Elmer, did you ever find out whether or not running the BIOS on the TED v1.2 is a problem?

Sorry, I've still not run a test.

When I eventually do, I really I don't think that it's going to show us any reason to avoid using the System Card 3 BIOS image on a TED v1 on a DUO.

People have been doing that for a while, and as far as I can tell, nobody has reported any problems.

It may be bad in an "academic" fashion, but it doesn't seem (so far) to be bad in a "practical" fashion.

The TED v2 with its random RAM contents on startup is a very different piece of hardware.

Would it help any if I could get you footage of it?  I don't know if it does cause the problem on the original version.  I have the original version but I've just been playing through the translated patched one.

Nope, not really. Random corruption isn't useful for debugging.

Now, if you can get it to *always* do something wrong at the same point in the game, then that's totally useful information.

I played through the first couple of levels of the translation in Mednafen with various breakpoints to spot corruption and I haven't seen anything.

At this point, there's not much more that I can do without a bug report that's repeatable.

To be honest, your report sounds similar to the guy on Krikzz's forum that was having problems with the TED v2 on his SuperGrafx.

In that case, it eventually turned out that he just needed to give his cartridge connector a really, really good cleaning.

I don't know if that's the problem that you're having, but a good cleaning certainly couldn't hurt!

[mj9123456]

Elmer, did you ever find out whether or not running the BIOS on the TED v1.2 is a problem?

Sorry, I've still not run a test.

When I eventually do, I really I don't think that it's going to show us any reason to avoid using the System Card 3 BIOS image on a TED v1 on a DUO.

People have been doing that for a while, and as far as I can tell, nobody has reported any problems.

It may be bad in an "academic" fashion, but it doesn't seem (so far) to be bad in a "practical" fashion.

The TED v2 with its random RAM contents on startup is a very different piece of hardware.

Thanks for letting me know.

[Johnpv]

Nope, not really. Random corruption isn't useful for debugging.

Now, if you can get it to *always* do something wrong at the same point in the game, then that's totally useful information.

I played through the first couple of levels of the translation in Mednafen with various breakpoints to spot corruption and I haven't seen anything.

At this point, there's not much more that I can do without a bug report that's repeatable.

To be honest, your report sounds similar to the guy on Krikzz's forum that was having problems with the TED v2 on his SuperGrafx.

In that case, it eventually turned out that he just needed to give his cartridge connector a really, really good cleaning.

I don't know if that's the problem that you're having, but a good cleaning certainly couldn't hurt!

I'll definitely give the hucard connector a cleaning.   It was repeatable for the lock ups.  Like in the ice cave, if I used my TED V2 there within a few steps into one of the two caves in the snow ice area, the game would lock up.  Every single time.  Not using the Everdrive in that portion and it would work fine.

[tbone3969]

Ok so I have my Super System 3.0 rom and I have the 3.0 USA System Card patch file in xdelta format.  The instructions say to "apply the xdelta patch to the image".  How exactly do I do that?

[elmer]

Ok so I have my Super System 3.0 rom and I have the 3.0 USA System Card patch file in xdelta format.  The instructions say to "apply the xdelta patch to the image".  How exactly do I do that?

Is the ability to use Google a dying art these days? 

http://www.romhacking.net/utilities/704/

[tbone3969]

Ok so I have my Super System 3.0 rom and I have the 3.0 USA System Card patch file in xdelta format.  The instructions say to "apply the xdelta patch to the image".  How exactly do I do that?

Is the ability to use Google a dying art these days? 

http://www.romhacking.net/utilities/704/

Many thanks.

[Nexus7]

So, why doesn't Krikzz advertise this feature?

[elmer]

So, why doesn't Krikzz advertise this feature?

I imagine that because then he'd have to test it and support it, and he doesn't think that it's an important-enough feature to go to that effort.

Putting the System Card BIOS into RAM on the TED v2 opens-up the possibility for games to overwrite it, corrupt it, and either crash or behave wrongly.

The patch contains a fix for one well-known case of that happening in Gate of Thunder.

I don't know of any other games that might have similar problems, but I haven't played-through every single CD ever released to check them all.

If there is ever a report of a repeatable problem with a certain game, then it can probably be found and fixed.

If you want a better explanation than that, then you'd have to ask krikzz himself.

[fluxcore]

Setup:

OG PCE w/IFU and cd player (briefcase)
Turbo Everdrive v2.5
3rd party 2.0A power supply

Issue:

When pressing 'RUN' within the patched cd system bios, the 'WAIT A MOMENT' status stays for a lot longer than on a proper system v2.1 card, and then proceeds to a black screen, but never progresses past there. Just a bunch of CD seeking noises. Happens with both burned CDs and officially pressed CDs. Loads fine with the official card.

I'm wondering if something in the v2.5 revision of the TED has changed? As I understand it, even with the oldest-school CD setup, the v2+ TEDs with the patched bios should function as a 3.0 system card.

I've ordered a legit 3.1 card anyway (they aren't that expensive), but am interested in seeing if the TED version can be made to work (i.e. if there's a bug, or problem with my system).

Awesome work with the bios patch btw, very appreciative of anyone working to make these old systems more usable and available!

Cheers

[SiberianSpForces]

If you haven't already, post the issue on kirkzzizesses's forum.

[elmer]

When pressing 'RUN' within the patched cd system bios, the 'WAIT A MOMENT' status stays for a lot longer than on a proper system v2.1 card, and then proceeds to a black screen, but never progresses past there.

Sorry, I've been busy dealing with my personal life for the last week+.

IIRC, the TED that I got on last-year's Black Friday was a 2.5, and I have the rest of the equipment.

I can test it here and try to reproduce the problem ... but I can't see why Krikzz would change the FPGA's register settings with 2.5.

It *could* possibly be something to do with voltage regulation and bus-loading on your particular hardware.

Do you know if the capacitors have been replaced on your system?

What are the specs on the 3rd-party PSU?

[fluxcore]

I can test it here and try to reproduce the problem ... but I can't see why Krikzz would change the FPGA's register settings with 2.5.

It *could* possibly be something to do with voltage regulation and bus-loading on your particular hardware.

Do you know if the capacitors have been replaced on your system?

What are the specs on the 3rd-party PSU?

I agree, it does seem more likely to be some kind of power issue, it certainly wouldn't be the first time with a TED. The red LED track displaying 'PC' while loading does slightly pulse at times, which makes me think maybe power, as well.

The DC adapter is a 100-240V-> 9V 2A (so cheapo switching adapter), what specs in particular are you after?

Supposedly the CD/IFU have had caps changed, but I haven't confirmed. I'll open it up and take a peek when my RGB mod board arrives (it's currently unmodded). If there are any voltmeter readings etc that would be helpful I can get some.

Cheers for the response, I really just asked in case there was a known issue or something obvious

[Keith Courage]

I recently got a new V2.5 and I cannot get the patched file to work. I have tested the everdrive in 3 different DUOs with original power supplies and no region mods. Game starts to load and then crashes immediately on the first picture that shows up. Must be something wrong with my Everdrive?

All game roms load up with no issues at all.

[tbone3969]

Are you sure you applied the patch correctly?  I can send you my file which I have confirmed works on my TurboGrafx CD.

Wait.....   you said DUO.  What would you need a system 3.0 card for?

I am sure you know it will not function as an arcade card.

[Keith Courage]

So you can leave your Turbo Everdrive in the system and still run Super CD games without damaging the DUO. That was the original purpose of the patch correct?

I've tried many patches that others have sent me to avail but if you want to send me yours so I can try it again it can't hurt.

I've also tested it in a Turbo Grafx and regular PC engine with the exact same results.

[OldMan]

So you can leave your Turbo Everdrive in the system and still run Super CD games without damaging the DUO. That was the original purpose of the patch correct?

I've tried many patches that others have sent me to avail but if you want to send me yours so I can try it again it can't hurt.

I've also tested it in a Turbo Grafx and regular PC engine with the exact same results.

Elmers patch does work. Honestly.
The major problem I had was finding the correct version of the system card. It is -not- the 3.0 version; read the patch information carefully (it only works on 1 specific version card).

The version I used that worked had a bunch of the same exact values at the beginning. Apparently, this
is delay code to fix a problem with the reset signal (as far as I remember ).  You may also need to do some monkeying around with the header info, iirc.

It's also possible that something has changed with the 2.5 everdrive. That -may- be your problem.

[Keith Courage]

Is there any kind of test I can do to find out if the problem is my everdrive or the patched files I've tried? I've honestly tried multiple ones sent to me by people who claim that they work on their setup. So I'm more leaning towards there being something odd with the everdrive. Not sure if krikzz will let me send it in for any warranty service for this patch/function not working since he doesn't really condone the use of it.

[NecroPhile]

Have you tried a different SD card?  I don't know why it'd matter, but maybe there's something about the one you're using that the TED doesn't like.

[Keith Courage]

Well after all my testing I never thought it could be the game I was using. I was testing Dragon Slayer II. For whatever reason this game crashes on the first game screen that has ADPCM audio with every system I've tested it on. So there is some bug with this game and the patched file working correctly. Anyone else else stumble across any other games it won't work with?

As of now I've tested 5 other Super CD games with no issues at all. Glad to know my everdrive isn't a dud.

[NecroPhile]

Funky.  Which region system card is supposed to be patched?  Maybe this is one of the few games that won't work on US syscard.

[Keith Courage]

I've tested both the US and JP patched files with it. No difference. I know it's not my disc because it loads up fine using a system card or built in DUO system card.

Nevertheless great work on the patch. Can't complain if only 1 game out of the entire pc engine library doesn't work correctly with it.

[elmer]

Well after all my testing I never thought it could be the game I was using. I was testing Dragon Slayer II. For whatever reason this game crashes on the first game screen that has ADPCM audio with every system I've tested it on. So there is some bug with this game and the patched file working correctly. Anyone else else stumble across any other games it won't work with?

Hmmmm ... that's really good to know!

There is definitely a potential issue with the patched system card on the TED v2, in that the HuCard ROM is actually in writable RAM instead of ROM.

The patch already has one bug-fix in it to deal with Gate of Thunder erroneously writing to ROM area ... but that was the only game that I knew of that did that.

Perhaps you've found a 2nd game that needs a fix. I'll have to take a look at that.

Is the crash during the 1st ADPCM that's in the castle, or is it in the 1st cutscene when you start the game?

Thanks for the report and the confirmation that other games work!

[Keith Courage]

it happens just passed the cutscenes as the adPCM audio starts to play and the main character gets out of bed.