|
Post by dshadoff on Nov 19, 2023 20:23:02 GMT
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 did a quick check, and I wanted to know which chip you were planning to use for the OR gate. Your partial schematic of the OR gate implies a 74LS32, but there are two issues: 1) The system is CMOS logic, so it should be 'HC' rather than 'LS', and 2) That pinout is not correct. Assuming that you're using a TSOP variant of 74HC32... The pinout issue extends to the board layout - it appears that pins 1 and 3 are function-swapped here (pin 1 is an input, not an output), as well as the other gates on the chip. Please double-check the datasheet of the specific chip. If you choose a different part, be sure that: a) it can accept 5V supply (and logic) - 'HC' logic will, but many of the other variants no longer support this b) The propagation time is small. I suggest targeting below 10ns at 5V. Here is an example datasheet of a part matching that criteria: www.mouser.ca/datasheet/2/916/74HC_HCT32-1541847.pdfOnce this is clarified, I'm happy to give it another review (I didn't continue checking after having found the above). I don't know if this will reduce cost or complexity for you, but it is likely that you can find a single-gate variant these days as well (such as 74LV1T32).
|
|
cosam
Deep Blooper
Posts: 15
|
Post by cosam on Nov 19, 2023 20:50:51 GMT
Assuming that you're using a TSOP variant of 74HC32... The pinout issue extends to the board layout - it appears that pins 1 and 3 are function-swapped here (pin 1 is an input, not an output), as well as the other gates on the chip. Please double-check the datasheet of the specific chip. Thanks! Yes it was meant to be HC, doesn't appear to exist in Kicad as a standard part so I took an LS and then forgot to rename it. The pinout however... wow, no idea how that's even possible! I did have a play with some other parts but they all followed the usual 14-pin 74 series convention so not sure what's happened there. Glad you noticed as that would have caused the pulling out of much hair! Should be fixed now:
|
|
|
Post by dshadoff on Nov 19, 2023 21:05:46 GMT
Yes, this looks better, and the rest of the layout seems to be as expected as well.
|
|
cosam
Deep Blooper
Posts: 15
|
Post by cosam on Nov 19, 2023 21:20:32 GMT
Great stuff, thanks for checking. JLC want an extra $30 for white solder mask on 0.8mm so I guess the first batch will be green
|
|
|
Post by dshadoff on Nov 19, 2023 21:31:28 GMT
|
|
|
Post by elmer on Nov 19, 2023 22:04:12 GMT
Ooooh, I should probably look to see if it's finally time to get my Enterprise RAM+USB board built!
|
|
cosam
Deep Blooper
Posts: 15
|
Post by cosam on Nov 20, 2023 14:04:35 GMT
OK, I think what elmer is saying has finally crystalised in my head (yes, it can take a while and often only really happens when I actually set fingers to keyboard...). So to sum up: - I can run diagnostics off a custom 512K HuCard, no issues with hardware conflicts, etc. Do what you want.
- I can run it off a TED or similar as a HuCard program and test everything except SCD RAM.
- I can check (before enabling anything) if SCD RAM responds and:
- A: If it does, that can only be RAM on a TED or similar, as anything on a Duo will not have been enabled yet. I leave the SCD RAM on the Duo disabled, everyone is happy (just can't test SCD RAM as stated above)
- B: If it doesn't there is no SCD RAM on the HuCard, I can detect with some EX_MEMOPEN-esque code which hardware is available, enable SCD RAM accordingly and run tests on it.
I might even get away with testing Duo SCD RAM off a TED Pro... if it only enables its CD stuff when running CD programs, the SCD RAM check (before enabling) will fail and it would look like "B".
|
|
|
Post by elmer on Nov 20, 2023 16:24:22 GMT
I can run diagnostics off a custom 512K HuCard, no issues with hardware conflicts, etc. Do what you want. Yep, you got it! The big problem is that you'll be the only person with that particular HuCARD, unless you decide to sell them ... in which case you'll be one of only two or three people on this planet with that particular HuCARD! I can check (before enabling anything) if SCD RAM responds and: A: If it does, that can only be RAM on a TED or similar, as anything on a Duo will not have been enabled yet. Not exactly ... if you're running a HuCARD program on a TEDv1, TEDv2, TED PRO, etc, then the HuCARD memory region will be configured as read-only, so you'll never detect RAM there. A TEDv2 running a patched Super System Card image specifically enables the HuCARD address space as read-write (so that it looks like there is SCD RAM available), normal HuCARD images are run read-only. I can detect with some EX_MEMOPEN-esque code which hardware is available, enable SCD RAM accordingly and run tests on it. Yes, there are PCE hardware registers that will tell you if there is on-board SCD RAM ... but you cannot then enable that RAM on the DUO unless you're running on that custom 512KB HuCARD, or else you'll cause bus-fighting because all existing flash-HuCARDs respond to memory requests in banks $40-$7F. I might even get away with testing Duo SCD RAM off a TED Pro... if it only enables its CD stuff when running CD programs, the SCD RAM check (before enabling) will fail and it would look like "B". Again, nope, not by default, because when running HuCARD images, the TED Pro will be initialized to respond to the entire 1MB range of HuCARD addresses. IIRC Krikzz does ship some sample TED Pro FPGA code that would let you build your own custom bitstream that would only respond in the bottom 512KB, and then I believe that the TED Pro will automatically use it if it's in the same directory as your HuCARD program.
|
|
cosam
Deep Blooper
Posts: 15
|
Post by cosam on Nov 20, 2023 16:53:52 GMT
The big problem is that you'll be the only person with that particular HuCARD, unless you decide to sell them ... in which case you'll be one of only two or three people on this planet with that particular HuCARD! Yeah I can live with that. I will publish the project so people could potentially make their own, I know a couple of people who may be interested in doing that. But I realise it's only for a niche within a niche if you're running a HuCARD program on a TEDv1, TEDv2, TED PRO, etc, then the HuCARD memory region will be configured as read-only, so you'll never detect RAM there. A TEDv2 running a patched Super System Card image specifically enables the HuCARD address space as read-write (so that it looks like there is SCD RAM available), normal HuCARD images are run read-only. So, unless HuCard SCD RAM is explicitly enabled, the bus fighting is just between a read-only area of HuCard space and the SCD RAM in a Duo? Is there another way to detect if "something" is there, like reading values other than $FF for example? (Which does not in itself sound particularly reliable...) Yes, there are PCE hardware registers that will tell you if there is on-board SCD RAM ... but you cannot then enable that RAM on the DUO unless you're running on that custom 512KB HuCARD, or else you'll cause bus-fighting because all existing flash-HuCARDs respond to memory requests in banks $40-$7F. The plan is to only issue the enable when I'm sure it's safe to do so. This may well only be the case when running off my special HuCard, so it might be that I need to detect that scenario explicitly (which sounds challenging). Again, nope, not by default, because when running HuCARD images, the TED Pro will be initialized to respond to the entire 1MB range of HuCARD addresses. IIRC Krikzz does ship some sample TED Pro FPGA code that would let you build your own custom bitstream that would only respond in the bottom 512KB, and then I believe that the TED Pro will automatically use it if it's in the same directory as your HuCARD program. OK, let's call that a stretch goal then For now I think just disabling the ability to run the SCD tests in that situation is fine.
|
|
|
Post by elmer on Nov 22, 2023 4:01:38 GMT
Yeah I can live with that. I will publish the project so people could potentially make their own, I know a couple of people who may be interested in doing that. But I realise it's only for a niche within a niche Cool, I'm sure that there are *some* other people who will make one of those boards! So, unless HuCard SCD RAM is explicitly enabled, the bus fighting is just between a read-only area of HuCard space and the SCD RAM in a Duo? Is there another way to detect if "something" is there, like reading values other than $FF for example? (Which does not in itself sound particularly reliable...) Hmmm ... in a real PCE or TurboGrafx Super System HuCard, the RAM on the card is *always* enabled AFAIK. It's only on the TEDv2, where the card is based on RAM and not FLASH-ROM, that you can select whether the entire 1MB region is currently read-only (i.e. ROM) or read-write (i.e. RAM). That setting can be changed at any time, but you have to enable the TEDv2 hardware registers, and that's not something that you can do in a HuC program. If you're looking for a simple way HuC-compatible way to determine whether your test program is running on a TEDv1/TEDv2/etc, or is running on your new 512KB card, then I'd suggest using a nasty-hack, and distribute your test program as a 1MB HuCARD image. If you create your actual program as a 512KB image, and then add on another 512KB of dummy data afterwards that contains some identifyable strings ... then if you can detect those strings in HuC, you can assume that you're running as an emulated 1MB HuCARD on a TEDv1/TEDv2/etc, but if you can't detect those strings, then you can assume that your program is running on a physical 512KB HuCARD! Quick and nasty, but I can't think of anything simpler. Now, just-in-case I was too vague with my earlier hints ... If you want to design this 512KB HuCARD and also write a HuC program to go with it because it's something that you'll find fun to do, then go ahead and enjoy the challenge! If you're just looking for programs that can test whether certain hardware is working on your new motherboard PCBs, or when repairing an old PC Engine ... then you can potentially save a bunch of time and effort by taking a look at the asm example programs that I pointed out. I suspect that you'll find that you can test the functioning of all of the PCE's hardware that you wish to with a simple combination of those example programs.
|
|
cosam
Deep Blooper
Posts: 15
|
Post by cosam on Nov 22, 2023 12:04:07 GMT
Thanks for bearing with me I did wonder about extending the image and putting some kind of magic number in there, although if I go past 512K then I'm encroaching on the exact region I wanted to keep free. The program at present is under 256K even, should that be of any consequence. It's looking more and more like I just need to disable any tests that could potentially cause a conflict and only enable these in special builds and/or behind a prominent warning that asks the user to do something mildly extraordinary to acknowledge. Re. your existing tests I have looked and will go through them properly. Next to "happy flow" checking if things are working or not I'm aiming to provide information to diagnose common faults and identify where they are when possible. I am not usually one for reinventing the wheel but it turns out I'm interested in how this particular wheel works so it's fun to tinker with The only reason I'm using huc and 240p as a base is to flatten out the learning curve a tad. I'm already having to do some bits in assembly to work around huc's limitations so gradually getting into that too.
|
|