Z80 Reverse-Engineering And Hacking Adventures

What else can I say?

Similar projects worth following
Ziggurat29 and I are now on our third(?) Z80-based machine reverse-engineering/hacking adventure. He's WAY smarter than I... But I tend to ramble and get way off-topic, burying his hard work amongst my rants. Maybe a dedicated project-page can keep it a little more sane and plausibly organized.

Our first adventure was with a weird old piece of test-equipment which barely seems to have existed, according to the internet. A Kaypro-based Logic Analyzer.

Our second adventure was a bit more common of a machine, still available in large quantities... The good ol' TI-86.

Today we're working on yet another weird old seemingly-non-existant piece of test equipment... A "Spectradata SD70," which we are guessing controlled a spectrum-analyzer which, of course, we don't have any info about, either.

Here, since I'm usually so disorganized in my logs, maybe a 

Table Of Highlights:


Reversing For Fun And Profit - Why I Like To Do It --Ziggurat29

Z80 Hackery With Ziggurat29 - A "Brief" History --Eric

Spectradata SD70 - Eric's Interest

Reverse Engineering

Spectradata SD70 - The Beginning


(Surely more logs than listed here)


If you're reading the logs through the logs-list, rather than one by one, you're missing quite a bit, as many of our discoveries, both related and unrelated to the log itself, wind-up in the comments.  Heh... whatcanyado


current disassembly work; very much a work-in-progress

plain - 342.98 kB - 06/22/2022 at 15:54


These are datasheets and whatnot for the stuff on the SD70 board. The SIO and PIO technical manual are put here separately just because they are so large and exceed the limits of this site. But this has most of the juicy stuff.

x-zip-compressed - 24.34 MB - 06/21/2022 at 17:40


Zilog Z80-SIO Technical Manual.pdf

you kinda need these special manuals to get the real skinny on how these peripheral chips work -- the datasheets are just high-level details. The DART is, I guess long since discontinued, but the SIO is similar in that it does what the DART does and also some ancient synchronous protocols as well. But the register detail is important. This one is big, so I couldn't zip them all into one package.

Adobe Portable Document Format - 24.10 MB - 06/21/2022 at 17:36


Zilog Z80-PIO Technical Manual.pdf

you kinda need these special manuals to get the real skinny on how these peripheral chips work -- the datasheets are just high-level details. This one is big, so I couldn't zip them all into one package.

Adobe Portable Document Format - 25.76 MB - 06/21/2022 at 17:34



Spectradata SD70 v1.8 ROM - Intel Hex

hex - 45.01 kB - 06/15/2022 at 20:16


View all 6 files

  • Chicken Egg In-System-Programming

    Eric Hertz2 days ago 0 comments

    Heh, apparently the idea of in-system programming has me in a chicken-egg infinite-loop.

    'Cause apparently (clicking-through old logs to "add a log") I'e already written quite a bit about it... And, here I was, 'bouts to write about it again as though something new.


    Anyhow, I've finally swapped-out my test-firmware EPROM for a flash chip, which at the very least will prevent me from stupidly looking at the UV eraser.

    The flash chip (An AT29C512 in a PLCC package) I made a DIP adapter for back during #Improbable AVR -> 8088 substitution for PC/XT ... Stupidly, I lost the documentation, so had to beep out the wiring. But, after having done-so, I realized just how forward-thinking I was way back when (Thank you, old me!).

    This guy can replace any (jedec-pin-compatible) PROM from the 28pin 64kilobitters to the 32pin 512kilobitters, and probably more in either direction, by changing a few jumpers.

    And, unlike plugging a 256kbitter in a 128kbitter's socket, when you program it in a regular external chip programmer, with the regular [AT29C512] chip-specific settings, you don't have to load it at an offset (e.g. 0x4000, when using a 256kb chip in place of a 128kb chip, due to the higher address bit's being tied high for a different purpose).

    So, I shoulda been using this all along, but I had to figure out those jumpers and its pin-compatibility first, so had been using a 256kb chip with an offset at 0x4000, and noticeably-increasing UV-erasure-times, and...

    Anyhow, after I reverse-engineered my own project, I made sure I won't lose that documentation by folding it up and sliding it in the space between the PCB and the pins... Or, I would-have, but a folded 8.5x11 just won't fit. So I spent friggin' hours, strung-along by "just one more step" trying to print it smaller, just to find out all my attempts were unnecessary because apparently all I had to do from the start was unplug the printer and plug it back in. (Yes, OBVIOUSLY, one of the first things I tried was turning it off and back on. Stupid "soft" power switches!)

    Anyhow, printed at about 1/4 page it fits snugly and should be there for me in another 7 years, for another project.

    Before that, though, it'll speed up this project, slightly, and "idiot-proof" it a bit, and reduce the dangers.


    It's still quite a process to pull it, change jumpers, put it in the programmer, and actually the process is tremendous...

    So, yes, immediately after the first successful test and the noticeable albeit slight improvement, I started thinking, again, about in-circuit programming.


    This is no longer the "Wild West Of Computing"... we have fewer of the sorts of hurdles they had to hack-around... (Though, we have hurdles of our own). I'm not afraid to use some of our newer tools. 5V-only Flash-ROMs exist, now. OK? Right? So, Hey, Me: save yerself some trouble, dummy!

    Right. So *all* I need is a means to upload the new firmware image, then the unit can program that to itself. Presto!

    So, the whole reason this interests me, again, is because large/untested code-changes are *extremely* daunting to me.

    And... what would an in-system firmware-downloader/flash-programmer be...? A large/untested code-change.

    I [kinda] need this thing to be able to make this thing. Chicken-Egg.

    I think I ran into the same with #Vintage Z80 palmtop compy hackery (TI-86) ... Heh!

    Anyhow, not a show-stopper, but a bit ironic.


    The other idea, e.g. using an AVR, putting the Z80 in bus-release, well, it has a slew of other such chicken-egg issues, many similar (e.g. parsing ihex files)... But, long-run, I guess, stand-alone in-circuit-programming is the best option... So, I guess I just need to bite the bullet.

    So I guess we're talking a jumper/switch to boot to a higher address in the flash, loading the flash-writing utility into RAM (almost forgot that!), listening...

    Read more »

  • Another workbench!

    Eric Hertz06/27/2022 at 20:32 0 comments

    Flat surfaces are at a premium in my lab... But have more than doubled in the last few weeks!

    Would you believe there's a dev-compy behind and to the left of the executive swivel-chair? It's a sleek little machine, top of its line only a few years ago, portable, self-contained, and highly-cusomized for my needs.

    In fact, there's now a 270degree work surface to be swivelled-to... Office supplies, pens, scissors, etc. on my right. Universal chip-programmer, and its dedicated computer to the left of that. SD70, next, and a printer behind it. Next is the surface for the sorting-tray when setting pieces and tools aside. It serves double-duty for cable-management and power-distribution. And its addition to the lab brought along with it a nice cat-hangout with in-floor A/C for these hot days. To the left of that is a toolbox. And finally that slick little dev-computer I mentioned, along with space for marking-up assembly-listings, drawing-up blueprints and schematics, and such. All just a swivel-away! 

    Oh, and I almost completely forgot the workbench behind the compy is dedicated to projects that are "backburnered". Just a chair-slide away to try out whatever new idea may've popped in my head during a sip of coffee.

    And behind that (not in photo) is a 10ft wide and 8ft tall opening view window! Oh, right, and a dedicated executive parking-spot merely ten feet away!

    Oh, that's just the start! I was talking about work-surfaces and completely forgot to mention the storage! A whole wall of small parts and drawers for tools. Another for bigger things like project-boxes, power-supplies, and motherboards. A third for more of that, lesser-used test-equipment, reference-manuals, and other paperwork/documents.

    It's no longer just a vision, it is a reality! It's actually pretty awesome, if you can just see it in there...

    (Where'd that crazy operations-tech disappear to now? Right... assembly-listings...)


    Oh no...

    Another project I'd been pondering led me down a rabbithole which gave me a very strange idea that, actually, is even stranger in that I hadn't thought of it before....

    Yahsee, my family's very first computer (which, really, was for me) was a "Macintosh Performa 640CD *DOS Compatible*" Yep, you read that right... it had a daughterboard with a 486 CPU. A "DOS-Compatibility Card." I'd thought long and hard about whether we should spend the same amount for a faster PowerPC, or whether it'd be more worthwhile for me to be exposed to both Apples and PCs... And, well, the thought was that PPCs were *so* new, at the time, that nothing would really *need* it for several years.

    Anyhow... It just now, via that other completely-unrelated project's research rabbithole, occurred to me that I could use *that* computer to run my chip-programmer. Heh!

    Let's talk about *that* rabbithole, eh? It doesn't have a parallel port, nor ISA slots... But, yahknow, I think I've learned enough about the 486 chip, ISA, and parallel ports to actually be able to wire one in. HAH!

    But, really, that'd be quite a thing, 'cause that poor DOS card was the major selling-point, but I hadn't yet realized that my interest in computers was mostly about I/O. So, it barely got used, until it was old-enough that I got a real 486 hand-me-down that got all the love the family-compy should've. Hmmm...

    Ah, right... How to transfer files? What'm I gonna hook a USB Floppy or CD-burner to my phone? Whew! Nipped that one in the bud!

    GAH, but wait! A) Sure, why not? [FAT12, maybe). B) CF-cards are IDE. C) I'll've already tapped into ISA. D) Most the remaining ROM-changes aren't gonna come off the phone. At which point E) Ethernet is a plausibility... Heh!

    Power. Seriously. That 486-lappy surely *sips* juice in comparison. OK, bud-nipped.

    But, some hack along those lines might be quite the thing some day... It's sad seeing the machine I cut my teeth on (and my dad worked so hard to save up for) collecting dust!

  • Coding Abounds!

    Eric Hertz06/27/2022 at 08:19 0 comments

    @ziggurat29 has been spending much of his spare time this past week+ coding at the lowest-level for a machine he's never even seen, except in photos.

    I had a moment a while-back feeling it a bit like the olden days I've caught-wind of recently from the datasheets of old mask-ROM microcontrollers I've found in my PCB-scrap-bin. I came across at least one that supplied an empty table, in the back pages, that purchasers could fill with the raw hex values of their program, then mail to the manufacturer to do the actual ROM-writing. Heh, sneakernet, eat your heart out. We don't need to deal with the multitude of different floppy formats you might send-in! And, No. We can't supply you with an assembler to run at your own workplace, but if you'd like to dial-in to time-share on our central computer for a fee only huge corporations could afford, you can use the assembler we use here. They've got that, but, no mention of uploading ROM images. And, again, an empty table on several pages of paper.

    Heh. What an era.

    Alright, well, he's not looking up raw hex values... But still... "write it out, send it in."

    For a minute there I also thought it a bit like NASA uploading new firmware to a probe, in order to overcome whatever weird new situation it faces... But then I realized, heck, I bet even in that extremely "out there" situation, NASA's programmers almost certainly have a duplicate in a lab that they can debug on.

    A couple days after my thinking this, he suggested pretty much the same idea:

    Comparing it to e.g. the way-back when a university might have a single computer, and the research-professors would send their stacks of punchcards to be processed. Their having to write the entire program, with no debugger and no step-by-step testing. Then waiting, possibly a few days, while a queue of others' code was executed, before hearing the result... And, then, possibly finding out they forgot to punch a hole. Heh! Or the instruction-set documentation *seemed* crystal-clear, while in-fact being ambiguous... Or who knows what all.


    Anyhow, it's quite something.

    In the times when I await the next stack of punch-cards, I'm running-around trying to maintain the central systems, over here... 

    E.G. The "punch card reader" (my beloved 486 laptop and my also-beloved parallel-port chip-programmer) is in sore need of a recalibration or two. Also, there's word in the industry of an upgrade that might remove a step or two... (Did you know FAT32 didn't come out until Win95 OSR2? And apparently Android doesn't do FAT16, heh! Yeah, this whole thing can run off a Win98 boot floppy, but then I need PCMCIA support in DOS, which I've never done... So... choices, choices...).

    Anyhow, Central Systems also offers its remote clients limited debugging-support; Our maintenance/operations-tech has become somewhat-familiar with The Central Computer's Instruction-Set, and can spot a few common mistakes, increasing deugging turnaround-times from days to, well... days. Heh! 

    ("increasing" "de-ugging"... hah! If Freud were here...!)


    The cat says it's time for bed.

    Anyhow, in short, we've got quite a few of the peripherals going... Turn it on at the stroke of midnight and you've got a clock in a rackmount! (Actually, maybe it's more of an instrument-case?) 

    And the "DART" (back then they hadn't yet standardised on "UART") is coming "soon" (where'd that operations-tech run off to, anyhow?), so we can attach a terminal!

    Discussion for the future has gone as far as developing a C-Runtime Library and porting BASIC. And the system has been likened to "Heck yeah! Who doesn't want a rackmount TRS-80 in their garage?!"


    The deeper we get into the system itself, well... I joked the other day along the lines of:

    "A physicist, a chemist, and an electrical engineer walk into a bar... OK, so what *really* happened was the EE walked into the bar while looking at his calculator. The physicist and chemist, well, they saw...

    Read more »

  • "We" have hacked it!

    Eric Hertz06/23/2022 at 00:28 3 comments

    @ziggurat29 gets all the credit. But I got to be the first to see it running, and burned/swapped the ROM, so that counts for something, right? 

    Awesome work, my friend!

  • "How do I assemble it?"

    Eric Hertz06/22/2022 at 10:06 2 comments

    Admittedly, my first thought is probably far more realistic than I thought upon thinking it...

    But my second thought was something along the lines of "is there an open-source assembler? [Ziggurat29 had issues with sdcc [but for an 8080]... Am I gonna have to use a CP/M-based assembler?"

    Heh... Then thoughts went to, "BAH! I can use ZAC!"

    Yeah, we're talkin: 

    1) Write the new SD70 code on my TI-86.

    2) Assemble it, under ZAC, on the TI-86

    3) Transfer that to compy

    4) Convert it somehow to an EPROM image

    5) Burn EPROM


    It makes a heck of a lot of sense, no? Use the tools I know!

    (As crazy as it may sound, I *did* actually think of some code I wrote on the TI-86 which could be handy here... what was it? Oh, the flash-programming code... hmmm)

    OK, that's a bit ridiculous, assembling code for this on my calculator... But it really made sense at the time!

    Heh, maybe that flash-programming bootloader-ROM I mentioned earlier should use TI-Graphlink instead of Zmodem?

    *Sigh* brain...

  • The mysterious AMD chip

    Eric Hertz06/22/2022 at 05:09 0 comments

    Well, shoot... I thought I had a dedicated log for this. And Right Now I can't do linking or copy-pasting, lest I lose my train of thought.

    So this'll be short, then maybe reorganized, later.

    Several pins are N/C, the 'scope shows various non-TTL waveforms on them, less than 1V. I'm guessing they're just floating.

     But, pin 5 looks a bit like a sawtooth wave (or more like a capacitor charging slower than it's discharged).

    It's between about 1V and 4V, and at roughly 5MHz. Since it's right next to the Z80-CPU-Clock input to the AMD (pin 6), my guess is that it's for the case where the AMD chip might need to drive a crystal of its own... 

    So, I dunno, I guess that spoke to me of a microcontroller, but I suppose many devices might work asynchronously to a bus (e.g. a video card's pixel clock). So, who knows.

    As @ziggurat29 pointed-out, it seems to be flooded with data/register-configs(?) with no handshaking... It's expected to accept and respond to an IORQ at whatever timing the CPU gives it. That'd be hard for a microcontroller.  So, I guess we're back to some sort of dedicated peripheral chip, or programmable logic. (Hmm, what about a FIFO memory? Seems silly, most its pins tied together).


    But here's a weird one... Pin 7 seems to be outputting a square wave at about 308KHz 50% duty-cycle. 

    (BTW, likely coincidence, but this is the same frequency put into the DART when set to 9600baud. Yes, I did try a different baud setting, this was unchanged).

    Looks like the CPU clock frequency divided by 16... 

    I was unable to see any signal on pins 40 or 35/37... I'm not sure if that's because it wasn't configuerd to be outputting anything there, or if it's very brief pulses.

    BTW, this thing gets hot if you leave your finger on it long... At first I thought the probing of floating pins was causing the heat-up, maybe putting them in weird inbetween-states, but now I think maybe it was just that my finger was blocking its regular cooling.

    OH, big one: The 308KHz signal seems to start *immediately* on power-up. Plausibly before the processor even configures it? It continues during reset. I should've thought to hold reset *during* power-up (TODO?).

    TODO: Merge other/past notes about it here, or at least link them...

  • In-Circuit Programming?

    Eric Hertz06/21/2022 at 21:24 0 comments

    @wmeyer48 wrote a comment on the front-page about a guy who built an In-Circuit Emulator back when these things were new...

    Always did kinda wonder how those worked...

    I did just see a vid about how debuggers insert breakpoints. (Surprisingly obvious... self-modifying code *replaces* the actual instruction with a call to the breakpoint function). 

    It requires the code be executed from RAM, though. But that factoid was a key to one of my earlier ponderings about some sort of in-circuit-programming method. Maybe swap the ROM with a battery-backed SRAM which also just happens to be connected to another machine capable of erasing and writing it. (and, i suppose, somehow putting the z80 in a bus-released state, and resetting it, DMA?).

    Would be pretty easy these days for a microcontroller to be that reprogramming host. Would be even easier to put something like this in the system via a 40-pin "chip clip" atop the z80, to access those reset and bus-release signals.

    Surely nowhere near the functionality nor complexity of an ICE, but within my means. I might just go about it something like that, as I do quickly get overwhelmed with big code-changes which haven't been tested in small pieces along the way. 


    Somewhere in there I begin to contemplate using FLASH, instead of RAM, and take it a step further to a sort of in-"ROM" bootloader so the Z80 can reprogram its own ROM (e.g. via a serial-dump?). But that'd be a ways off (I'd have to learn something like Zmodem?).

    And, it's interesting to point out, developers at the time didn't *have* FLASH as an option. And large SRAMs (even approaching the size of their ROMs) were *very* expensive, if even available in single chips.

    The ol' "Wild-West of Computing" was a crazy era with many hurdles to overcome... inspired quite a bit of "hackery" at its finest.


    Thanks to wmeyer48 for the reminder. 


    1 friggin 18 in morning, 6/23:

    DUH. The flash-programming utility is:

    A) stored in a higher address-space, selectable via a switch on the appropiate address bit. SD70 boots into that space, instead of the bootloader (which would otherwise precede *any* firmware tests)...

    This makes it sound too complicated.

     Simply upload an intel-hex file.

    No friggin' fancy terminal-emulator combined with xmodem, or whatever, to switch from text-mode to binary-upload...

     Simply flip a switch on the SD70, reset...

    Even my phone can do the next part (assuming it gives me permission):

    'cat newfirmware.hex /dev/ttyUSB0'


    The ihex format looks pretty simple.

    The only concern is flow-control... Flash-programming is kinda slow (slower than serial?!)

    Oh, and the potential for ihex files which are sparse or out of order. 

    These might otherwise require a RAM big enough to store the full ROM image...

    BUT Could easily be fixed in a bash-script at the sending-side.


    So, say I can find a 32K+ flash chip in my collection... seems more than reasonable, given the things I've scavenged.

    The first 16K are for the firmware testing. The second 16K is for the FLASH-programming utility. Simply use a switch a pull-resistor, and a.c n XOR (or numerous other options) to swap the highest bit's value, depending on if you want to boot into the testing firmware or the flash-loader.

    Really, this explanation makes it seem more complicated than it is.

    I doubt I can get this done in just a few days, but it'd be so worthwhile that it's probably one of the first things I'll do before I begin my own firmware experiments.

    Only thing is  it means getting flash-programming and serial I/O right, first...


    This "duh" comes after hours of contemplating using an AT89C52 *as* the flash-ROM. Thing about this microcontroller, over say the AVRs I'm *way* more familiar with, is that it can be programmed as though it was an EPROM. And *that* means it can also be read-back *just like an eprom*.

    So, the idea, essentially, was to use it...

    Read more »

  • DART and CTC working together...

    Eric Hertz06/21/2022 at 09:32 3 comments

    There's a reset pin in the RS232 connector?! Also, definitely a bit loopy.

    Oh, heh the resistor on PIOBPpin34 is tied high. And before the bodge, that's the only thing that was connected to that PIO pin by-design.

    Also, I haven't read up on this particular Timer/Counter, but feeding an input into it at the same frequency the Counter/Timer is driven (via CLK) seems like it's asking for weird aliasing effects, or worse, unless I suppose they're asynchronous?

    Also, not grasping why these I/O devices all need /M1; it's available on the expansion-header, as well. Oh, maybe for the weird Z80-Peripheral IM2 scheme?


    Alright! Did some 'scoping!

    CTC pins 9,22,23 seem always at about 1.2MHz. ~28us high, 56us low.

    CTC pin 20 appears always high (pulled-up?) BUT, I stopped checking after the first few tests (anyone have reason for me to be more thorough with that one? The PIO might drive it?).

    CTC pin 7, obviously, is where it's at...

    If I didn't make any translational errors:

    (M# corresponds to the measurement number. It's only here for my transferring notes)

    M2 110: Immeasurable, looks low

    M4 300: ~86.2KHz

    M7 600: Immeasurable, looks low

    M3 1200: Immeasurable, looks low

    M5 2400: Immeasurable, looks low

    M8 4800: ~152KHz

    M1 9600: ~300KHz

    M6 19200: ~610KHz

    (Surely I must've swapped 300 and 2400 somewhere, in testing)

    Otherwise, it looks reasonable, doubling with the baudrate... 32x faster... wait, didn't I hear the DART doesn't have a divide-by-32? Huh.

    The ones I could see all have a 28us high pulse, (matching the 1.2MHz presumed-input. the remainder of the time it's low.

    Heh, I guess that's all I have to report after hauling the thing and the scope to an outlet only to find out the thing's power switch is on the front panel back in "the shop". But, it was for the better, because when I got back the blaring sun was mostly blocked by a nearby building.

    Also ran some scoping on the AMD, which I'll throw in a previous log about that guy.

  • "sd70 keyboard" schematic

    Eric Hertz06/20/2022 at 03:14 3 comments

    Anything of particular note? Hmm... Definitely etched "in-house." I keep thinking its crazy there's such tiny power/ground traces, and that they meander like they do, but the vast majority of the board doesn't use them.

    Working my way back into the motherboard, next, from here... That'll likely take longer, since the friggin traces jump sides so often...

    Updated Keymatrix. Thankya to @ziggurat29 

    Note that Col3/row3 has no button, nor a place for one, but @ziggurat29 says there's code for it(?!). I don't see any hidden buttons/pads on the keyboard nor mainboard. Though I haven't hunted those traces on the mainboard.

    Oh Snap, I forgot to make note of the fact most each button has two names, which the "2nd" button selects. If I understand correctly.


    These be the LEDs. If you don't care too much about the wiring, the 8255 on the right is where to look. The labels mostly correspond with the button names. Although four LEDs are not associated with buttons. "Pause" and "Stop" are the easy ones. "Slew" and "Scan" are both button-names and independent LEDs. So, I called the independent LEDs e.g. "Slew Active" and the ones on the buttons "Slew BTN"

    They're driven at their cathodes through 74LS245's on the mainboard, we're guessing for drive-strength, but 245's don't invert, so in code I'm pretty sure, they're also active-low. The 245's DIR and OE pins are tied active.

    There seem to be potential for two more LEDs which are N/C at the "keyboard" PCB. Again maybe suggesting the mainboard was intended to be used in other systems.

    8255 cleaned-up, and in its entirety:

  • Spectrophotometer? + Potential ROM reuse

    Eric Hertz06/19/2022 at 18:26 0 comments

    I guess it never occurred to me that machines doing light-spectrum-analysis of some sample might do it in various different ways, and therefore, may in fact be different machines and therefore have different names. Or something.

    I decided to do some looking-into terms used on this thing, like the "[wavelength?] slew rate" and came across the term: Spectrophotometry.

    It's pretty much how I imagined, I just thought it was a "Spectrum Analyzer". I guess the difference is that other methods might, say, turn the sample into plasma, to see what colors it *emits*, whereas, I think this machine is more about seeing what colors the sample *reflects* (or *transmits*). It's more of a passive measurement, in terms of the sample.

    Actually, though, this is probably more along the lines of the sorta thing I'd actually find uses for. E.G. I had a weird LED which I'm near-certain glows blue when fully-powered, but more of a teal when the power supply is removed and the capacitor discharges. I don't want to plasmatize anything, here, just see if the spectrum changes.

    AND this would be *far* simpler to make hardware for. The Applied Science guy had such a machine with, simply, a piece of fiber-optic he'd point at various samples. Sure, if you run the machine once, pointing at white paper,  then run it again pointing at the LED, it's basically calibrated-enough to see *changes* in peak wavelengths. Not like I need to know exact luminous-flux values, or even exact wavelengths, or something.

    So, again, I'm ponderng actually figuring out how to use this thing as it was intended. Hah!

    Again, the hardware isn't *that* complicated...

    (no linky wikipedia imagery?)

    The fiber optic would point at the object/sample. The other end points at a prism, or diffraction-grating (aka "monochrometer," thus the "MONO" port on the back). The photodiode on the other side of the prism is moved-around within the rainbow at its output, to see a small window of the different colors. An aperture might be useful on the photodiode to focus on a smaller range of wavelengths, and also in case the light source is too dim/bright...

    I mean, yeah, it could definitely be doable.

    Reality sets in, a bit, I guess... The SD70 doesn't do the actual measurements; as far as I can tell, it just moves the photo-sensor/prism.

    So that means we need an analog circuit for the photodiode, and maybe aperture control, and an A/D converter, and some way to communicate its readings (e.g. to a computer)... at which point we're talking a microcontroller. At which point we could just program a few more GPIOs to move the prism (or photodiode). At which point we could put a linear CCD on the prism... Heh. Haven't I been here before?

    Part of me wants to use this thing as it was intended, though. So, I dunno. Maybe I'll add a toggle-switch between its ROM's Chip-Select and whatever custom firmware we might come up with.


    On that note, we discovered a function-call that calls a function's address loaded/stored in RAM... A function-pointer. Which, I suppose, in the interest of hackery, could make for a way to boot off the original ROM, then bounce off into another/custom program. It'd be a hack, and I can't quite visualize its being any easier than just toggling that chip-select. 

    But, that thought-process brought up a thunk I hadn't thunk: What about a custom (boot) ROM which accesses functions in the original? Like what? Well, e.g. the init-code is just a bunch of grunt-work which could easily be mis-copied... Have you ever tried to get an HD44780-compatible LCD running? Oh, sure it looks simple enough, just load those register... but I've run into modules whose init-sequence had to be in exactly the right order (despite the registers being loaded with the same values either way!). Or, e.g. the RS-232 initialization, which also requires the CTC... Heh, or that front panel! Matrix scanning... And, it looks like there's already a serial put-string...

    Read more »

View all 17 project logs

Enjoy this project?



wmeyer48 wrote 06/21/2022 at 18:06 point

Long ago and far away I knew a guy who was developing a CPU in-circuit emulator. Too long now to recall whether he used a Kaypro or an Osborne. No matter. He coded it all in hex. Seriously. I don't remember whether he had a name for it at that time. Would have been roughly 1983.

  Are you sure? yes | no

ziggurat29 wrote 06/21/2022 at 19:50 point

ICE, ICE, baby! A big hit in the 80's, before all that funky JTAG jive!

  Are you sure? yes | no

Eric Hertz wrote 06/21/2022 at 21:08 point

Cool, Inspired some ramblings on an in-circuit programmer (not emulator) I'd been mulling-over. There's sure to be a log-entry on it later. Sounds like a smart guy to befriend back in the ol' wild-west of computing. Thanks for sharing!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates