• CD-ROM board: HD64F3039 = H8/3039 = H8/300H

    Eric Hertz • 12/04/2022 at 12:36 • 0 comments

    I'm Reorganizing, bare with me...

    ...

    I was planning on starting this "project" with a more 'vintage' uC (e.g. the 6502-compatible I found at the bottom of the box) but this is the order of the pictures on my phone, and reorganizing with a thumb is a PITA, so I guess I'll start with this one. 

    And, actually, maybe it's a good thing, 'cause it shows this "technique" is still useful with more current eWaste, as well...

    This was the interface board from a CD-ROM drive, as I recall. Most of the time, I've found that their chipsets are very closed secrets. But this one has a good ol' microcontroller.

    This is a Hitachi (now Renasis) H8/3039 which is apparently a 16/32bit microcontroller. 

    The F in 64F3039 indicates that it's in-system-programmable, BUT: who has the time/energy to figure out that protocol, when you can just attach an E[E]PROM?

    Actually, more-importantly, [yeah, I'm going about this documentation all backwards] is the underlying concept, here, that seems applicable to the wide number of assorted uCs one might encounter in old junk.

    Anyhow, Wire-up the "mode" pins to Mode1 or Mode3, add a regular ol' external EEPROM, and whatever the heck is in the flash is completely irrelevant.

    It'd make a heck of a lot more sense if I'd started with the 6502, 8031, and similar "fallback-mode" devices, instead. But I need to get this list documented for my own purposes...

  • VCR board: M50950 = MELPS 740 ~= W65C02++

    Eric Hertz • 12/04/2022 at 11:43 • 2 comments

    Well, sheesh. Apparently I only found *two* such uCs in all those years' scavengings? Can't be...

    K'den...

    Well, this one's apparently got a core that's an extension of the 6502.

    https://en.m.wikipedia.org/wiki/Mitsubishi_740

    This, as I recall (or deduce), came from a VCR.

    I was pretty stoked finding out its mask-ROM could be bypassed... Had to write it on the board! 

    (I coulda sworn I'd done similar on at least a couple other boards. Where'd they go?)

    In a way, I guess, that makes this a 6502 in a weird package...

    Finding out /that/ it could be bypassed wasn't as simple as looking at the pinout... I'll give you a hint, it's one of these pins.

    ...Some more hints...

    ...but, yahknow... that could be for external /RAM/... which wouldn't be uncommon for microcontrollers ala 8051 or ATmega8515...

    BAM! "Microprocessor Mode"

    Alls yahs gots tahs does is connect the pin called CNVSS (intuitively: "Connect-to-VSS"?) to VCC. Of Course!

    So, now we've got a souped-up 6502 to install behind a switch-panel and LEDs.

    I gotta say, though, I'm a bit jealous of "Memory Expanding Mode's" multiplexing of the Address/Data lines with GPIO... hmmm...

    No wait! They thought of that, too!

    So that's that. A 6502 with a slightly wonky pinout, and a few extra features, if you aren't interested in compatibility.

    Update 3-23-23: And here's an actual 6502 for comparison (Wikipedia).

    So, not being familiar with 6502's, bus/interface-wise it seems to be lacking:

    RDY, S0, and NMI. Lacking DMA pins, RDY would be my first guess at how to essentially "halt" the CPU for e.g. single-stepping. Maybe those SRDY pins are relevant, though.  My second guess might be that the clock itself is steppable, but I gather, from the various CPUs I've explored, that single-stepping/halting the clock isn't always a possibility, especially depending on the "process" (NMOS, CMOS).

    The Wikipedia article mentions that often 6502 designs included faster memories whose accesses by other devices were "hidden" from the CPU, interleaved with its clock. I used a similar method, albeit in reverse, long ago for attaching a slower 8051 to a fast framebuffer; interleaving random CPU accesses on i.e. the low clock pulse, when high clocks were constantly used for redrawing sequential pixels. So maybe that idea could open up other options: e.g. with a fast latch attached externally, maybe a "jump -1" instruction could be injected into the path between the CPU and firmware [ROM?] when the external RAM or IO devices need it to wait before accessing them. (DMA in progress, halt [at address X?], STOP toggle-switch, etc.) Only thing is how to know if it occurs in the middle of a multibyte instruction read... Something to ponder. Or just use an interrupt, where the input is like a DMA-Request input, and the Interrupt-handler toggles a pin that enables the aforementioned "jump -1" latch, double-dutying as a "DMA-Acknowledge" output... hmmm...

    Something like this could be useful for other such processors, as well (8051?).

    Part of where I'm going, here, is a vague idea of having a single "front-panel", and a single array of I/O/Memory devices, slowly built-up over time... a cabinet, backplane, front-panel, etc. that ALSO contains *numerous* such processors, with the ability to switch them in and out of the system, maybe even in realtime, via software. And, at a very low level, (as opposed to, say, attaching them all via SCSI or GPIB). So, there needs to be some way to block one CPU while another is working on the bus.

    ...

    I thought it a bit interesting to see how this chip was ordered from Mitsubishi:

  • 8x51's as 8x31's, and NOPping OTP PICs

    Eric Hertz • 12/04/2022 at 09:14 • 0 comments

    At my first electronics gig, a contractor was developing with 8052 drop-in-compatibles. There was a pile of 8752's, as I recall, with windows, continuously cycling through the UV eraser for a day or two every couple weeks. When the updates were finally worked-out on the prototype system, they burnt OTP 8052s for the actual systems, about twenty of them.

    Sounds great, right?

    Well, after a week or so of testing all the systems working in unison, of course we found some things that needed to be changed, called in the contractor, and went through it all again. At least a few times.

    Thankfully, about midway through the process, eraseable 8952s became affordable in our smallish quantities, so we only "wasted" probably around fourty to sixty OTP 8x52s.

    I remember a cardboard coffin filled with these things, thinking "what on earth can be done with them now?!"

    ...

    Fast-forward a couple years and I met a buddy who was in a similar situation at his workplace; they had piles of "burnt" One-time-programmable PICs waiting for trash-pickup.

    He came up with something I'd thought utterly ridiculous at the time.

    Apparently, as I recall, the PICs he scavenged had NOP=0x00. And, being that 'unburnt' bits were 1, he discovered he could essentially wipe-out all the old code and write whatever he wanted in the previously-unused portions of ROM.

    Wow, smart!

    Oh, but he was ridiculously-smarter than just that.

    Eventually he got to the point of seeing which pre-existing op-codes he could modify (by changing 1 bits to 0), so he could do things like modify already-burnt IRQ tables and use far more of the ROM than was previously left 'unburnt'/empty.

    I really thought him insane, at the time. But, I mean... THAT'S A HACK.

    ...

    Somehow I hadn't pieced-together that the same might-could've been done with our burnt OTP 8052s... (Is NOP 0x00?), but I/we had also moved-on to the 8052-pin-compatible AVRs at that point, and reflashing was no problem. (nevermind /in-system/ programming!!!)

    ...

    Fast-forward again, I started getting into the idea of learning a little about other CPU/uC architectures: MIPS due to some hackery with an old cable-modem, then on to MIPS-core PIC32s... I also dabbled in x86 with #Improbable AVR -> 8088 substitution for PC/XT , albeit from a completely different direction...

    Then, a couple years ago, I wound up in a situation where learning Z80 made sense, as I began #Vintage Z80 palmtop compy hackery (TI-86) ... 

    Started discovering these things really are all quite a bit more similar than I'd previously expected. There seem to be "camps" of folk into specific architectures, so I guess I mistakenly thought them to be very different, conceptually.

    I started digging through my boxes of old scavenged PCBs to see what *other* processors I could learn about, and, repurpose. Many Z80s, a handful of others like an 8085, An 8031... 

    We're talking CPUs, here, not microcontrollers, because, well, who has time to learn not only a new architecture, but *also* a different programming technique for each one?

    But then, when I stumbled on the 8031 I learned something incredible! The 8031, on that particular scavenged PCB, was accompanied (of course) by an EPROM... BUT, it wasn't a CPU, it was an MCU. Weird.

    Then it got even weirder... The 8031 is, frankly, just an 8051 without an internal ROM. Wut?!

    Nope, it got even weirder, in a good way...

    Apparently "That Pin" that was always tied to some rail on our 8052s is tied to that rail for the sake of identifying whether you want your 8051/52 to act like an 8051/2 or... whether you want it /to use external ROM/, bypassing the internal one, essentially (if not /actually/) turning your 8051/52 into an 8031/2.

    WUT?!

    It basically means those 8051/8052 microcontrollers can be turned into 8-bit CPUs, with a few extra inbuilt peripherals.

    ...

    And, apparently, the 8051/31 aren't the only ones...

    Yahknow that weird microcontroller used for old keyboards, in old PCs? I think it's the 8048. Well, as-marked, it's a keyboard-controller....

    Read more »

  • Intro here...

    Eric Hertz • 12/04/2022 at 08:39 • 0 comments

    I've been meaning to log my findings for a while  now...

    This, is that kind of energy-time, *not* introduction-writing-energy-time, so I'll update this later. But until then, check out the additional "logs" here!

    ...

    This "project" (as opposed to this log, within this project) "started" with a random musing over at:

    https://hackaday.io/project/185218-random-tricks-and-musings/log/213963-reusing-maskotp-rom-ucs