Panasonic HHC ROM 'capules'

[Paul Berger (Canada)]

(01-14-2023 07:47 PM)Jeff_Birt Wrote:  I was wondering if anyone, in the USA, who had an original ROM capsule would be willing to loan it to me? A friend of mine developed these 3D printable ROM./PCB carriers that fit the Molex sockets in the TRS-80 model 100 et. al. There is a link on the page below to the Github repo for the project.

http://tandy.wiki/Molex78802_Module

He was nice enough to offer to develop carriers for this Molex socket variation. I do not have an original ROM carrier to measure up though, so we are starting from the design he has already done for the Molex 78802 socket (which he found datasheets for) and measurements I am making of the socket in my HHC. Being able to measure up a real module would be a big help. Of course, the new models will be added to his repo and open for all to use.

I am not in the USA but near enough on the East Coast of Canada, I could give you one of the EPROM capsules I have, I got several with an ex insurance salesman's HHC. send me a private message if you are interested.
Paul.

[brouhaha]

(01-14-2023 07:47 PM)Jeff_Birt Wrote:  Being able to measure up a real module would be a big help. Of course, the new models will be added to his repo and open for all to use.

That would be great!

For the 16KiB module, a PCB will be needed, using either current memory technology, or old SMD EPROMs.

I initially thought that a Microchip SST39SF010A-70-4C-WHE (TSOP package) flash chip would fit and probably meet the necessary electrical characteristic, and it's cheap (under $1.50). There's a problem with that; the flash chip takes up to 100 microseconds to power up. The HHC power switches the chip, and although the HHC docs say that 16K capsules are "slow ROM", but I doubt that they wait 100us.

Next I thought an FRAM (ferromagnetic-effect nonvolatile RAM) such as Infineon FM18W08-SG might be suitable, but its power-up spec is even words, 10ms. Similarly Everspin MRAM has a 2ms startup.

Similarly, Infineon NVSRAM have a long startup time.

This makes it seem unlikely that any modern memory technology will be suitable. I'm sure old EPROMs can be found, though it's less common to find them in suitable surface-mount packages.

I'm willing to design a PCB once I know the required dimensions to fit the carrier design.

[Jeff_Birt]

As luck would have it a few hours after posting my last message an HHC with 4 capsules showed up on eBay so I snatched it up.

Regarding the response time of the ROM. On page 15 of Panasonic_HHC_Technical_Information_of_Hardware.pdf it describes the slow bit which causes a /8 of the Y-driver clock for 'slow' devices, stretching out the high part of the signal. It is not clear yet to me what effect this has. It seems to me that the OS must be smart enough to pause briefly when switching banks.

The above linked page has a basic design for a PCB that is a good starting point.

[brouhaha]

The problem with using modern memory chips (flash, FRAM, MRAM, NVSRAM) for an HHC module (whether 4KB, 8KB, or 16KB) is worse than that. It doesn't matter if there are software delays after "activating" the capsule. The power to the capsule sockets is switched by the HHC hardware on _every_ access. If the CPU is executing code from the capsule, it's switched off even between two consecutive reads. AFAICT no modern non-volatile memory chip can handle that; they all have at least 100 microseconds of required startup delay, whereas the HHC needs them to be ready in a few hundred nanoseconds.

AFAICT, Microchip was the last manufacturer of CMOS EPROMs, and they've been obsoleted. They also appear to be the last manufacturer of 5V parallel NOR flash, like the SST39 I mentioned, and those have the 100us startup time requirement.

It's possible that some other flash vendor may make chips that start up faster, but probably not in 5V parts.

Using 3.3V memory in the capsule will require some form of level adaptation, though possibly not full-on level translators. I've had good luck with TI SN74CBTD3861 voltage clamps for interfacing 5V systems to 3.3V logic. That part has ten NMOS pass transistors, biased such that they turn off if one side is over roughly 3.3V. With those between the 5V and 3.3V worlds, the 3.3V device is protected. Unlike level translators, they have basically no propagation delay (less than one ns), but they also don't provide buffering or drive. Anyhow, those would work to use a 3.3V memory part, but of course it's trickier to squeeze a memory part AND three of these voltage clamp chips into a PCB the size of the capsule.

Using new-old-stock OTP 27C128 (or 256, 512) is looking more and more attractive, though a DIP obviously won't fit, and a J-lead PLCC might not either, and those were the most common EPROM packages.

Obviously the 4KB and 8KB modules are easier when using new-old-stock EPROMs, because a 2732 or 68764 should fit your new carrier replacement.

[Jeff_Birt]

I was chatting about this with a friend last night and we were scouring through datasheets looking for a similar 'power on until first read' spec for EPROMs, which does not exist. He then suggests looking at the programming specifications as the programmer will turn power on and need to know how quickly it can then start programming the part. For garden variety 27C128 type parts this was about 2us. This is likely the reason they provide the /8 pulse stretcher for 'slow' memory.

With a 1mhz clock on a 6502 one instruction cycle is 1us. Each opcode takes 2-6 instruction cycles so it would take 17~50 opcodes to eat up the 100us power rise time of the flash memory.

I'm going to try to measure the time from power on of the EPROM until A13 is twiddled. Looking at the hand drawn schematics reveal A13 is used as /CE for the option ROMs. This should provide an answer as to how much of a start up delay there is.

[Jeff_Birt]

I had thought the HHC must poll each ROM socket at power on to determine if a ROM is present. Looking at a manual for a capsule it does seem like this is the case. I set the scope up to trigger on a rising edge looking at the VCC on each socket and...nothing. Very odd. I'll need to pull the back cover off to delve deeper into it. When I get the newly ordered capsules in, I can test on of those in this HHC.

BTW, I confirmed I found the VSS pin of the socket by measuring from it to the /RESET of the 6502. I could capture the /RESET rise after power was switched on. Measuring to the address and data bus pins reveals toggling but I did not specifically test A13 so see if it went low briefly at power on, that would have been a good test.

[brouhaha]

If you look at the schematics, and trace back the gates of the transistors that switch power to the capsule sockets, you'll see that the 6502 phase 2 clock is gated into them, so even if a capsule is selected on consecutive memory cycles, the supply to the capsule pulses.

There's another interesting wrinkle. If a CMOS memory device is used, whether it's an old 27Cnn EPROM, or a modern flash, FRAM, MRAM, etc., when the power supply on pin 24 of the socket is switched off, the device will partially power itself from any address and data lines that are in a logic 1 state, because the ESD protection diodes in the chip will be forward biased. This has both good and bad consequences for trying to make the memory device work reliably on the HHC, but in general it makes the analysis more difficult.

[Jeff_Birt]

The phi0 clock is output by the custom ASIC chip. This chip has a config register with a bit that is set when accessing 'slow' memory. It looks like the effect is that phi0 is /8, i.e. 1.2mhx to 150khz. If so, this will provide a lot more time for the ROM to become stable.

The uses of the open collector invertors to short out VCC to the ROMs on deselection is also odd. Especially given that they all seem to have come with a cap tacked across VCC and VSS. I have another computer in pieces on my bench right now. When I'm done with it, I'll poke around on the HHC and see if I can see this /8 feature in action on the scope.

If nothing else, it is an interesting design...

[brouhaha]

(01-16-2023 02:32 AM)Jeff_Birt Wrote:  The phi0 clock is output by the custom ASIC chip. This chip has a config register with a bit that is set when accessing 'slow' memory. It looks like the effect is that phi0 is /8, i.e. 1.2mhx to 150khz. If so, this will provide a lot more time for the ROM to become stable.

That still only gives a little over 3us from power application to data required to be valid, which is not enough for any of the modern memory chips to power up. If the new module either had a batter, or a supercap that got charged (through a diode from the capsule connector pin 24), maybe it would work. Some circuitry, maybe just a single CMOS gate, would be necessary to derive a chip select, basically by inverting the pin 24 level, so that the memory while powered by the battery/supercap without power from the computer would not be selected and try to drive the bus.

Given how big even "small" modern memory chips are, maybe a new capsule could have a half-pitch DIP switch (e.g. CTS 218) to select between multiple images. Or a fine-pitch header and jumper blocks. Though if it's easy to hook up a programming fixture, maybe it's unnecessary.

[Paul Berger (Canada)]

The discussion above got me thinking about what was in the custom GE module that that uses industry standard EPROMs, and the EPROM that are in it are Intel 27128A which are the 250nS NMOS part. A quick look at it seems to indicate that they followed the capsule design and switch the power as there is a transistor connected to the Vcc pin of the EPROMs. There is not a huge amount of circuitry in this module so perhaps I will put it on the list for reverse engineering, but not right away I have other things on the go right now.
I suppose one reason for switching the power on the capsules might be for power saving, NMOS is not the most power efficient logic family which is why the HHC turns off the processor whenever it can.
Paul.

[brouhaha]

(01-16-2023 04:13 AM)Paul Berger (Canada) Wrote:  and the EPROM that are in it are Intel 27128A which are the 250nS NMOS part.

It does seem like NMOS EPROMs (2732[A], 68764/68766, 27128[A]) are more likely to work satisfactorily than newer CMOS parts, in part because the NMOS parts have somewhat different ESD protection characteristics, and don't power the entire chip fram any I/O pin, like the clamp diodes in the CMOS parts.

[Lourensk]

I did an attempt long ago to re-program the original Motorola MCM68766C Eproms with Microsoft basic a while ago.

I used Matt's Arduino shield to program those ancient Eproms:
https://www.mattmillman.com/tms2716-programmer-shield/

But unsuccessful, perhaps due to a corrupted dump as written above..

[Jeff_Birt]

Tried looking at the VCC turn on of capsule socket last evening on a different HHC. Same result, never see VCC applied, not even a blip that the scope can trigger on. I did capture the /8 of PHI0 though (at CPU), and also A13 at the capsule socket.

There must be something else going on w.r.t. the capsule sockets. The way they did A12, according to hand drawn schematics, is odd. At this point I'm not sure how it finds out there is a ROM in the socket.

   

   

[Jeff_Birt]

I guess the way A12 is configured it can't pull the A12 pin on the EPROM up unless the EPROM has VCC applied.

I was also just looking at the schematics again and noticed that the 'All Off' switch does not actually disconnect power to everything. the VCC regulator is always powered. The instructions in the manual say to turn off the 'All Off' switch, plug the capsule in, then turn switch back on. The switch only disables the CPU power. Maybe the polling for ROMs takes place before the switch is turned on?

I seem to recall seeing a low-level signal on the capsule socket VCC when the 'All Off' switch was off. I dismissed it as noise as it was 'All Off'. Perhaps that is the polling process to discover ROMs? If so, I will need to wait until my capsules from eBay arrive to do further testing.

[Paul Berger (Canada)]

Reading the technical information pamphlet I don't think that anything would be powered when the All Off switch is open. It states that the switch turns off the power to the CMOS chips and if you look at Tony Duell's schematic he labels this as "VRAM" which also appears to power the Y driver chip which is the chip that supplies the "CPU ON" signal that turn on power to the processor as well as all the NMOS and TTL.

[Jeff_Birt]

I tried it again and was able to capture the capsule socket being powered on, with no capsule present. I also did the IC4 power cycle to demonstrate how much time things send powered down when just the menu is being displayed. Note that you can see the 'slow' memory access here too.

   

   

[brouhaha]

(01-17-2023 01:16 PM)Jeff_Birt Wrote:  At this point I'm not sure how it finds out there is a ROM in the socket.

It determines that by reading it. If there's nothing there, or if you're not actually doing something that needs the ROM (which could include using it to control an I/O device, even while another capsule has overall control), then it never accesses it again, so you wouldn't ever see the power getting switched on.

I haven't yet identified the specific code involved. It's probably SNAP code, and I haven't decoded all of that. It might be part of power-up, or it might be done by LOC.PRG, which is called by the menu selector.

I need to write a SNAP decompiler. In the past, I've just decoded SNAP words by hand, and that's a pain, especially with control structures that use relative addresses.

[Jeff_Birt]

Got the ROM 'capsules' in, wound up with 7 of them. All are boring insurance stuff. Made a quick 3D model of one today for fun. Now at least I can investigate the ROM power on sequence.

A friend has made some FLASH based ROM boards for the Epson PX-8 which uses a similar power on/off scheme for the ROMs to save power. He found the following whitepaper which describes the time from power on until first read in detail. His ROM boards are working so far on the PX-8.

https://www.renesas.com/us/en/document/a...-nor-flash

   

[brouhaha]

So Reensas flash also can take 260 us from power up to first read, as with the other modern memory chips I looked at. That seems far to long even in the HHC slow mode.

it's a worst-case spec, but even if a typical part only needed half of that, it would still be far too long.

Previously Jeff wrote:

Quote:With a 1mhz clock on a 6502 one instruction cycle is 1us. Each opcode takes 2-6 instruction cycles so it would take 17~50 opcodes to eat up the 100us power rise time of the flash memory.

That doesn't help, though. The capsule gets power cycled on EVERY access. It's not like it gets powered up, and then some 6502 code gets run from somewhere else, and then the capsule is read. While the 6502 code is executed from somewhere else, the capsule is powered down.

The reason modern flash take a long time to power up, compared to EPROMs, is that they actually have a fairly complex state machine or microcontroller inside that manages write and erase cycles. However, that controller has to initialize itself at power up before even reads are possible. EPROM and masked ROMs didn't have any of that.

Anyhow, since I have not actually tried modern flash chips with the HHC, by all means please take my statements here with a grain of salt, and actually try it. Given that the CMOS will try to power itself through the ESD protection diodes of the address and data lines, maybe it will stay alive and work.

[brouhaha]

(01-23-2023 08:12 PM)Jeff_Birt Wrote:  Made a quick 3D model of one today for fun.

That looks great! What software do you use for your 3D modeling?