cosam
Deep Blooper
Posts: 15
|
Post by cosam on Nov 17, 2023 18:22:59 GMT
I'm familiar with the potential for conflicts when using the TED on real hardware like the Duo. If I understand correctly, the patches for the CD System Cards ensure that the hardware (RAM, maybe also registers?) in the TED are used, resolving the conflict so the ROM can be used safely. What I'm looking for is the opposite; is there a way to disable the hardware on the TED and have everything mapped to the real hardware?
Why would anyone want to do this? Because I've been trying (with some success) to develop some diagnostic tools that would help when repairing/rebuilding e.g. a Duo, IFU-30, etc. The obvious way to run these would be from a flash cart like the TED.
My current approach is to add these diagnostics to the 240p Test Suite. Although this may not seem the obvious choice, similar tests have been added for the Sega Mega CD and it provides an easy framework with a nice interface. It uses huc so whilst any solution involving assembly is probably possible, it might need a bit of massaging to play nicely with its approach to memory and banking.
|
|
|
Post by dshadoff on Nov 17, 2023 22:49:57 GMT
I don't know if the Everdrive RAM can be disabled, but I have a couple of alternate flash card projects which might interest you (and solve your problem): This one is good for prototyping, as it is reprogrammable via a standard EPROM programmer: github.com/dshadoff/ProtoHu_revAThis one looks nicer, since the chip is completely sandwiched between thin PC Boards: github.com/dshadoff/Megavault
|
|
cosam
Deep Blooper
Posts: 15
|
Post by cosam on Nov 17, 2023 23:25:04 GMT
Oh nice! I had at some point envisioned a PCB with some kind of socketed EPROM on it but these are way neater. Might just get some of those done next time I'm ordering boards...
|
|
|
Post by elmer on Nov 18, 2023 15:57:45 GMT
What I'm looking for is the opposite; is there a way to disable the hardware on the TED and have everything mapped to the real hardware? You don't say which version of the TED you're trying to develop for. If you're trying to use a TED v1 or TED v2, then you can just develop for HuCARD or CD (in either HuC or ASM) and the TED hardware will only get in the way in the bank $00-$7F region, i.e. the only thing that you won't be able to test is the SCD RAM on a DUO or Super CD-ROM2. If you're trying to use a TED Pro, then it should be basically the same if you're developing for a HuCARD (in either HuC or ASM). The only difference would be if you were developing for CD/SCD/ACD, in which case the TED Pro will emulate the CD hardware on a CoreGrafx/TurboGrafx, unless they're attached to an IFU, in which case the TED Pro is supposed to disable its own CD hardware emulation, just like it does on a DUO. If really you want to be able to test the built-in SCD RAM (banks $68-$7F) on a DUO, then you'll need a custom-designed HuCARD that only responds to the bottom 512KB of the HuCARD address range. Dave's designs may be able to do that, but the TED v1 and TED v2 are always active in the entire 1MB region of HuCARD address space. AFAIK the TED Pro is also always active in the entire 1MB region of HuCARD address space by default, but I *believe* that could potentially be changed with a customized FPGA setup, which is something that the TED Pro is supposed to allow for. What do you believe that the TED is doing that would get in the way of your hardware tests? <EDIT> Well ... except that all versions of the TED do kinda need a lot of the PCE's hardware to be functional just so that you can enter its menu and select/run your test program in the first place. If you're really trying to do deep diagnostic tests on a partially-broken PCE, then you may want something that boots automatically into your program. For that you'd either need to use something like Dave's HuCARD design, or one of the old flash-based HuCARDs, or you *could* potentially write your own TED v2 firmware like TEOS, but that's a fairly-substantial amount of work, and definitely isn't a task for HuC!
|
|
cosam
Deep Blooper
Posts: 15
|
Post by cosam on Nov 18, 2023 16:36:37 GMT
Ideally it would be something that can run on any version of the TED, or any other flash card/SD solution for that matter, although I realise that may be unrealistic. What I'm most worried about is triggering the same kind of issues as an unpatched System Card on a TED has, or anything that could indadvertedly damage hardware, either on the card or console. If there was some way to simply disable all the "extra" stuff on the TED, such as by twiddling whatever registers it might expose, that seemed to be the safest way to proceed. I'm set on developing purely for HuCard because if you're able to boot from a CD (unless you're doing so "virtually" from a TED Pro of course, which I wouldn't want to be a requirement) a whole bunch of hardware needs to be operating correctly and this is exactly the hardware I want to make diagnostics for. The SCD RAM is definitely something I would want to be able to test (and one of the diagnostics I already have working) but if this is impossible when using a TED then so be it, I can just note that that's the case and possibly even disable that test if there's some way to detect if a TED is being used. Same goes for anything else the TED has/does. By the same token, if a custom HuCard is really the only way to perform all the tests I want then that's fine too. The target audience is basically people who would be diagnosing and repairing broken consoles so they would likely have the equipment and know-how to build/flash such a card too. EDIT: above reply's edit acknowledged
|
|
|
Post by dshadoff on Nov 18, 2023 17:05:10 GMT
OK, here's an idea... During the development phase, you will want to iterate with new versions of the program quite often. It might be best to leave the SCD RAM testing to the final piece of code, and ensure that your test suite is covering other bases first. Much of this can be done on emulators like Mednafen, and toggling various config options We've made a fork specifically for PC Engine development here: github.com/pce-devel/mednafenPceDevEventually you will want to also validate on a real machine (probably several machines); you should be able to test most everything except the SCD memory from bank $68 to $7F on a Turbo EverDrive, and Turbo EverDrive v2 might also be the best choice for rapid turnaround - you can deploy a new image to the EverDrive without tediously moving the SDCard between PC and card. Since I don't use Windows for PC Engine development, I wrote this utility in Python to send images (because the original utility only runs on Windows): github.com/pce-devel/PCE_TurboEverdrive_USBSorry, but I don't know anything about the EverDrive v1 (or the cheap Chinese clones of it), so I'm not sure if it works for that card.
|
|
cosam
Deep Blooper
Posts: 15
|
Post by cosam on Nov 18, 2023 17:30:54 GMT
Yep, Mednafen is what I've been using so far, tricked it into emulating the CD hardware by booting a random CD game with my image as the BIOS. I didn't know about the development edition though, I will check that out (and your Python tool as I'm also not a Windows user). SCD RAM diagnostics are already working, as well as some other stuff, so it's time to try it out on some real machines, hence this thread I have a TED v2 on order but then noticed the stuff about potential hardware conflicts.
|
|
|
Post by dshadoff on Nov 18, 2023 20:17:57 GMT
elmer , was there a way to check - from within a program - whether it is running on a TED ? This might be a useful "startup probe" in order for the program to be self-aware and disable any "dangerous" (or not meaningful) tests. Also, enable/disable of SCD RAM is "supposed to be" a sequence of port reads (or writes) on original hardware, right ? I don't have this written down, but it might also be useful to share here - to assist with the testing.
|
|
cosam
Deep Blooper
Posts: 15
|
Post by cosam on Nov 18, 2023 20:46:51 GMT
Never came across anything like that for SCD RAM but every other sort of memory on the thing has its idiosyncrasies so why not? Definitely possible because the chip selects come from the ASIC. I have been looking into the custom flash card thing and the ProtoHu certainly looks like it fits the bill. Only 512K of flash with 19 address lines connected so it responding to the upper half of HuCard space is unlikely 70ns flash would be quick enough, wouldn't it? Seems the easiest to get a hold of. And 2 x 1.2mm board seems about right(?)
|
|
|
Post by dshadoff on Nov 18, 2023 21:54:30 GMT
Sure, 70ns is easily fast enough. Make sure you get the 5V version of the chip. I'm pretty sure I used 0.8mm for the board with all the electronics, and 1.6mm for the 'spacer' board. (The TSOP chip has a 1.2mm height, and the pin headers stick through slightly more than that.)
But now that you mention it, the 512KB card image (normally banks $00-$3F) may get an 'echo' from $40-$7F, as I think there is an address line which is not referenced as part of the address decode. This might interfere with your probing of the SCD RAM. The solution to this would be to route the top two most-significant address lines through an 'OR' gate to the flash /CE pin (currently, only the most-significant address line goes directly).
The pin header's /CE pin (as seen by the EPROM programmer) should go to one of these inputs, with the other input getting a weak pull-down (~47K -to 100K).
...If you're the same cosam (the great) who has been reverse-engineering the PC Engine circuit boards, this shouldn't be a big problem for you. Feel free to take any element of the design for your own purposes, and please continue to ask any questions that you may have.
|
|
cosam
Deep Blooper
Posts: 15
|
Post by cosam on Nov 18, 2023 22:08:10 GMT
Oh that's right of course, incomplete address decoding will cause a mirror in the top half - the opposite of what I said. Might be able to get away with a couple of diodes or something... I will have a play (And yes, I'm the lunatic making the repro PCBs so I recognised your name from your responses regarding that.)
|
|
cosam
Deep Blooper
Posts: 15
|
Post by cosam on Nov 19, 2023 15:21:03 GMT
So this is what I think you were getting at, makes sense! And using your board as a base (after being quite amazed what a job Kicad did of importing an EAGLE project) this is what I came up with. A quick (in)sanity check would be most appreciated I moved the headers down a smidge, didn't look like it would fit in a Duo slot as the case protrudes a tiny bit more.
|
|
|
Post by elmer on Nov 19, 2023 15:30:19 GMT
Also, enable/disable of SCD RAM is "supposed to be" a sequence of port reads (or writes) on original hardware, right ? I don't have this written down, but it might also be useful to share here - to assist with the testing. Here's the code from the Japanese SCD BIOS ... $01:C875 LDA #$AA ; A9 AA $01:C877 STA $18C0 ; 8D C0 18 $01:C87A LDA #$55 ; A9 55 $01:C87C STA $18C0 ; 8D C0 18 That's for enabling the DUO's RAM. AFAIK there is no way to disable it other than powering down the DUO. elmer , was there a way to check - from within a program - whether it is running on a TED ? This might be a useful "startup probe" in order for the program to be self-aware and disable any "dangerous" (or not meaningful) tests. Yes there is, you can check for a string in the TED2's firmware bank, but you've got to enable that bank and page it in first, and you CANNOT do that in HuC because it will crash the machine! There's a sample test in my ASM library code in the HuC repository, but it's only for the TED v2, and not the TED v1. Anyway, that's not what @cosasm really needs to do here, the problem is more subtle. The problem with the TED v1 and TED v2 and any other flash-rom HuCARD, is that you want to avoid having both the DUO's SCD RAM and the HuCARD both responding at the same time in the HuCARD memory range of banks $40-$7F and causing bus-fighting. That's *why* the SCD has an unlock-sequence in a DUO, and why the return values of the EX_MEMOPEN system call let you detect whether you've got external SCD RAM on a HuCARD, or internal SCD RAM inside a DUO. You can put a SuperCD HuCARD card in a DUO and it will work perfectly fine, and use the SCD RAM that's built into the HuCARD, and avoid enabling the DUO's on-board RAM. That's because Hudson and NEC thought ahead and avoided the problem. The TED v2 patches for the System Card BIOS basically just do the same and tell the System Card that the TED v2 has its own built-in RAM, and that the System Card shouldn't try to enable the DUO's on-board SCD RAM. From my perspective, because all known modern HuCARD designs (including the TED) are built to use the whole HuCARD memory address range of banks $00-$7F, it's just not safe to "test" SCD RAM in a HuCARD program, and if you write a CD version of your test program that runs on a SuperCD system, then you can safely test for SCD RAM, but you may only actually be testing the TED v2's own built-in RAM, and not the DUO's on-board RAM. If you DO create your own 512KB HuCARD, then sure, you can do the test, but then you've got to make sure that your program isn't used by folks with other different hardware.
|
|
cosam
Deep Blooper
Posts: 15
|
Post by cosam on Nov 19, 2023 15:53:16 GMT
This is great info - thanks! Is it really only banks $40-$7F then? No issues with the "standard" 64K CD RAM at $80-$87? Or the Backup RAM? Or even the registers at $18xx?
As everything requires its special little unlocking/enabling sequence, it would seem that whichever device receives those register writes would enable its own implementation of the hardware, or not? I suppose it's also possible that both the internal console hardware and the flash card would receive them and assume they were the only one to do so.
|
|
|
Post by elmer on Nov 19, 2023 16:36:29 GMT
This is great info - thanks! Is it really only banks $40-$7F then? No issues with the "standard" 64K CD RAM at $80-$87? Or the Backup RAM? Or even the registers at $18xx? Yep, the only problem with a TED v1/ TED v2 is the DUO's mapping of internal SCD RAM to banks $40-$7F, there is no other conflict. The TED v1/v2 design doesn't map their hardware into the other areas, nor into the PCE's hardware bank (bank $FF). The TED PRO is a totally different beast, but since its ARM chip reconfigures the FPGA on-the-fly as it loads different types of games (i.e. HuCARD or CD), and it auto-detects whether there is CD-hardware attached to the PCE and doesn't enable its own FPGA-emulations when it detects those on a DUO/IFU, then you're probably OK. As everything requires its special little unlocking/enabling sequence, it would seem that whichever device receives those register writes would enable its own implementation of the hardware, or not? I suppose it's also possible that both the internal console hardware and the flash card would receive them and assume they were the only one to do so. The TED v1/TED v2 won't get in the way of any hardware testing (except for the DUO's SCD RAM). The TED PRO is a different beast, as are the other modern CD-emulators. FWIW, there is already a CD testing program for the TEDv2 in my ASM examples that you might wish to look at, with both HuCARD and ISO versions. The HuCARD version is currently written to assume that it is running on a TEDv2, but I should really fix that since the only reason that it assumes the TEDv2 is so that it can detect/allow for a loading a different ROM through USB after it has finished running. <EDIT> The HuCARD version is a reasonable way of testing if the basic CD-ROM hardware is operating correctly, and it prints some status messages that are useful for diagnosing problems. The ISO version does the same, but since you can only boot off it, you need to know that the CD-ROM is operating before running it. The ISO version loads some graphics and streams an ADPCM file, so it's a good test of CD-reading and of the ADPCM hardware. The ISO is for SCD, and boots directly into SCD RAM, so it's also a test that SCD RAM works. One thing that's not currently checked is the basic CD RAM in banks $80-$87, but that could easily be added. <EDIT2> Heck, it would be easy to have the HuCARD check for the basic CD RAM, and have the ISO just be a basic CD program, since IIRC it doesn't actually *need* any SuperCD capabilities. The TED2 Gulliver HuVIDEO playback example is a much better test of SuperCD RAM and extended CD functionality.
|
|