Close
0%
0%

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:

Intro

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

Ports

(Surely more logs than listed here)

BIG NOTE:

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

SpectraDataSD70-20220622a.lst

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

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

Download

Z80Manuals.zip

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

Download

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

Preview
Download

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

Preview
Download

SD70.HEX

Spectradata SD70 v1.8 ROM - Intel Hex

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

Download

View all 6 files

  • ? Spectradata SD-70 in the wild ?

    Eric Hertz5 days ago 0 comments

    Did You Buy it?

    As far as I've been able to gather from the interwebs, only two of these machines may've ever existed...  

    I'd been contemplating buying the second to keep them together, and also maybe to find out a few unknowns. (E.G. What is that AMD chip's part number? Did the other unit have the GPIB chips installed? Did they hand-etch the front-panel board on both of them? Were they built at the same time, e.g. for the same customer, or...?)

    Anyhow, if you bought the second one (or just happen to have another, or know anything about it) it would be great to hear from you!

    eric -> wa -> zhu -> ng

    Via:

    gm -> ail

    Of the dotcoms

    (Why can't I unbold that?!)

    I'm curious what others' interests may be, or what they may do with it... Reverse engineering endeavors of their own? Actually use it as intended (Do you know anything about the equipment it attaches to?) Figured it was a great price for a project-box, a bit like I did at first (wanna sell its guts?)? Did you find it through the logs, here? If you put anything on the net about it, I'd be happy to put some links in here. So-forth.

    For the search engines:

    spectra data SD-70

    Spectradata SD70

  • The Rominator: Overkill maybe.

    Eric Hertz08/01/2022 at 09:11 0 comments

    It works!

    As I recall (shyeah right... like I'mma go back and read all that!) the ordeals of the last log basically amounted to really weird luck prompting me to realize some variable initializations never occurred.

    After I fixed that, it all seemed to work as-tested on a PC, up to the point of actually performing the Flash-writing, which couldn't be tested yet because the SD70 has separate chip-selects for each of its 4 16k memory-sockets, and the Flash I've been using in the first socket requires an "unlock" procedure that requires accessing 32K of its address space.

    The plan since I started this flash-endeavor has been to have a jumper on "The Rominator" which selects one of two 16k pages to boot from. Simply switch the jumper to boot into the firmware-uploader, switch it back to boot into the new firmware.

    I went a little overboard because, well, the simplicity of the idea grew in complexity quite quickly. 

    E.G. the SD70's ROM sockets obviously don't have WriteEnable... So I need a wire and test-clip for that. 

    The A14 line is pulled high, as for smaller ROMs that pin has another purpose, so I already needed/had a jumper to disconnect it and a resistor to pull the chip's A14 low... But now I need a way to actually control it (for unlocking the flash-write) AND a way to invert it (for selecting which image to boot from). OK, three jumpers. 

    The Output-Enable is connected to the Chip-Enable (maybe it decreases access time?), but the flashing procedure requires /OE to be high. I ran into the same with #Vintage Z80 palmtop compy hackery (TI-86) , so if I want to use The Rominator in another project, I might benefit there, as well, from now another jumper and another test-lead. 

    The Chip-Enable, now, has to have *two* inputs ORed together, and another test-lead.

    Surely I'm forgetting something.

    While I was at it, I decided to give A15 similar treatment as A14... Now the original "stock" firmware can be booted via jumper, as well. Oh, right, and A15 is also pulled high at the socket, so had to have a jumper and pull-down.

    OK...

    Now, I didn't have much space left on the board, so was quite pleased to find an SOIC 74F00 in my collection... Until I realized 100k pull-down resistors would not be anywhere near spec (600uA out of the input, 100kohm, 6V?!). Alright, well, at that point I was beat (how long has this been, a week?!) So I decided I'll just require that A14 and A15 are always driven by either an output or by power rails. A14 already has a header, now, for a test-lead, but I didn't do that for A15, so I fudged another header-pin next to the jumper for grounding.

    Heh. This has gotten crazy. BUT: The previously-unnamed Rominator was of great use in #Improbable AVR -> 8088 substitution for PC/XT , and now again in this project, so I guess its new versatility could be useful in another project down the line.

    (Did I mention I spent Hours fighting my printer several weeks back so I could print its schematic small-enough to strap to it? I guess I'll have to do that again. Thankfully this time I think I know why it was so difficult last time. Though, this time there's quite a bit more information to fit in there).

    Oh, right... So I finally put it in the socket for the first time in what seems like forever (I seriously expected this to take an afternoon, not DAYS) and it still booted the old firmware just as I expected... But, it didn't boot all the way... What?

    Took me a while to remember that ordeal of the last log... right, trying to hunt down incredible odds led me to load an earlier version. So, while flashing the latest version, I also flashed the stock firmware at 0x8000... Tried the latter first. No problemo. Tried the firmware-flasher next at 0x0000, burnt an old test-program to 0x4000 (over the serial port!). Not a hiccup. booted from that for some pithy nostalgia from who can remember how many weeks ago...

    Holy Moly, I can In-System-Program, now! And I can...

    Read more »

  • Merging C and ASM...

    Eric Hertz07/23/2022 at 06:32 6 comments

    Next-Next and Next-day brief Updates at the end...

    ...

    I am by no means experienced nor knowledgeable in this realm... 

    I have done a bit of inline asm in my otherwise avr-gcc progects. But this is very different.

    Here we have a booting system written in assembly, and I plan to make a bootable utility in C that makes use of the initial-setup and functions that assembly-code provides. In a sense, I'll just replace its "main loop" with my own.

    Initial experiments were very promising. I wrote a small main()-like function in C, wrote a "void function(void);" *declaration* (not definition) for one of the assembly functions, called that function from mine...

    From that alone (not even "including" the original assembly file in any way) sdcc gave me assembly-output that was *easily* modified in such a way that I could little more than copy/paste its output into the original assembly file and run my code as though I'd written a new function in assembly in the original.

    Basically, sdcc's assembly output did "calls" to labels, and those labels just happened to not exist within its awareness... and it didn't seem to care.

    Which was *great* because when I pasted that output into the original assembly file, those labels now were available, and my assembler replaced them with the appropriate 16bit addresses. Just like assembly does.

    I guess I'd expected sdcc to croak on the missing labels long before actually outputting a usable assembly file.

    So... Awesome!

    ...

    So then I bit off more than I could chew.

    Wrote the entire utility in C, tested it with gcc as best as possible all along the way. Finished it, finally, today...

    Then... yeah.

    OK, so the big thing that ultimately stopped me from proceeding with my original plan (of copy/pasting sdcc's output into the original assembly file, then hand-modifying it as-necessary) is the fact that the sdcc output uses the same label-names in all functions. e.g. "00104$" which resulted in my assembler's complaining of duplicate labels 69 times. I *almost* considered hand-changing them until I realized it looks like it only complains about the first duplicate of each... Heh.

    So then, obviously, just throw the thing into sdcc's assembler, instead, right? But apparently *that* didn't like the original assembly in an entirely different and equally difficult to repair way: Apparently it's so low-level that it doesn't handle things like "equ"... which would be a tremendous feat to remove all instances of. Heh.

    Again, I'm no expert, maybe it was just a matter of find/replace... but this came after quite some effort dealing with many other incompatibilities, e.g. "immediate values" are prefixed with # in one, but not the other...

    So, finally after much "hand-jobbing" I decided it was time to throw up my hands and come up with another way.

    Now, I should probably interject that obviously there is some "right" way, otherwise we wouldn't have many of the fine things we have... I imagine "the linker" is a big part of it. I have history with that beast that prevents me from preferring trying another go at it over, say, hand-editting 69 labels.

    But, I think I came up with another solution, which actually should be easier... just modify the original to call some specific address, say near the end of the ROM. Assemble that in the usual way. Then modify sdcc's assembly-output with actual addresses instead of labels pointing to the original code. There's only three functions and one buffer to be loaded into RAM. Four addresses to hand-enter. Oh, and a .org at the beginning of its output to somewhere after the original's.  And, finally, add a .org at the decided-upon jump-to-address, with a jump to my main(). Then, of course, use sdcc's tools to compile that, as though it was its own completely standalone thing. Merge the two ihex files, and we're done! Scripting that whole process should be easy-enough, too. And it allows for keeping the two codebases separate, which has...

    Read more »

  • To Xon or to Xoff, that is the question.

    Eric Hertz07/16/2022 at 03:21 10 comments

    Apparently the answer is "Just don't".

    I'm too tired of the whole scenario to go into it. But let's just say that some once-standards seem to have been brushed-aside in really awful ways that make me lose faith in far too many things.

    I commented on it in a previous log... Basically having come across several linux mailing list archives of folk submitting patches to support Xon/Xoff for various USB-Serial dongles (whose chips actually support it at the hardware level!) and yet those patches being abandoned for essentially "most USB adapters don't support it" despite the fact the drivers claim to. AND, the fact that the stty-default, when you plug those dongles in, is to claim that it's enabled. Worse than that, there were even folk submitting patches to at least give a *warning* to the user that xon/xoff isn't supported, and even *those* patches were seemingly driven out of the kernel.

    I also found this: https://hackaday.io/project/16097-eforth-for-cheap-stm8s-gadgets/log/49010-a-serial-terminal-for-linux-with-working-xonxoff

    Wherein Thomas went into a lot of digging to figure out (and share) where the hurdle exists...

    ...

    This is now the /third/ such thing I've run into that was basically once such a standard as to be in nearly all the great references that were de-facto reading for generations of folk using RS-232.

    The first was long-enough ago that it's a bit muddled in my mind. As I recall it had to do with counting edges on handshaking lines. The great example I recall of its disappearance (and yet claiming to still exist at the driver level) was a GPS standard which is often used to synchronize systems' realtime clocks, e.g. data-logging systems which aren't able to connect to the internet... Like what? Think trailcams if you can't imagine scientific research. Isn't that pretty much *exactly* what linux was once so great for? It blew my mind how, frankly, rude folk were toward this guy, and indirectly toward the entire scientific community, for not using things "the one way" "everyone" does. Goes ENTIRELY against everything that I thought made linux great.

    ....

    The second was custom baudrates.

    The Standard, for generations, was to assign your custom baudrate to 38400baud. The Idea being that nearly every terminal application, or serial application, supports selecting that baudrate from a list, whether supplied by the OS, or in a list in the program itself. Thus nearly *every* serial program could make use of a custom baudrate, as long as you configured it before loading the program.

    Yes, at the driver-level that might mean running a custom program to actually set the appropriate registers, but even that had become commonplace enough that linux has provided the appropriate and common tools to do-so, for decades; one for countless different serial chips. EXCEPT. USB-Serial dongles. Why? Searches of mailing lists result in pretty much the exact same sentiment, over and over... "Most USB serial chips don't support it" which, frankly, wasn't even true, in my experience, decades ago, and far less today. AND, again, the drivers seem to allude to the support being there, and configuration-programs give no warning it isn't.

    Again, this isn't just about buying cheap hardware, we now live in an era where USB is darn near the only reasonable option. This is downright absurd. Their arrogance is affecting everyone from kids learning Arduinos to government-sponsored research endeavors. Nevermind the folk who put tremendous effort into making great software that stood the test of time.

     And, nevermind the folk who wrote excellent resources/reference-manuals that we still are referred to as "The Best" now in an era where those things we learned are now just flat-out lied-about still existing in our configuration utilities and drivers.

    ...

    The third is XON/XOFF, and again, frankly, I'm still seeing red that I spent a week or more implementing that in an embedded project *because* stty reports Xon/Xoff is enabled As Default...

    Read more »

  • L O L

    Eric Hertz07/10/2022 at 12:01 6 comments

    If you read the last log, you'll understand why I'm LOLing about what I have for this one...

    Alright, so, I had several epiphanies lately for long-running unsolveds. Though, weirdly (to the point of LOLing) they seem nearly completely opposed to my plans eventually-made in the last log (many of which I guess I'd forgotten).

    One was that I recalled once having written a program in C that didn't have all the system-specific stuff included/configured... and yet, it compiled to assembly source-code, which left the unknown function-calls (e.g. printf()) as just i.e. 'call printf' despite there not being anything in that assembly-output called 'printf'.

    That was long ago, and a mistake, and I think I chalked it up to the idea that one can compile several separate C files, individually, then I guess the linker must be responsible for linking things like "call printf" in one assembly-output file to the actual printf function in another assembly-output file.

    I was intrigued, but I guess it seemed kinda obvious-enough at the time that I didn't really think about it again until just a few days ago, when that memory came to me out of the blue, and I realized that I could compile my code in C, and the assembly output could be merged with the assembly @ziggurat29 wrote for things like configuring devices, and... using the serial port!

    Hah! So, in C, I can pretty much simply call the "serpush" and "serpull" he'd written in assembly, as easily as (and essentially the same as) calling stdio.h's getchar() and putchar()!

    This is revolutionary.

    (just now it occurred to me I could prb do the same for programs on the TI-86(!!?))

    Just before writing this, another similar epiphany: I could probably somewhat-easily merge assembly code I'd written /on/ the TI-86, /for/ the TI-86, into our code for the SD-70...

    So, somewhere in there I decided to try this mystical idea of compiling C source code that wasn't fully-defined... and... Holy Moly, it worked.

    First test was making a front-panel LED blink, by calling a function writen in assembly... Hah! 

    Realy, it only takes a *tiny* bit of finagling to literally throw the assembly-output from C into the assembly code we wrote for the replacement firmware. I can even call C functions from the assembly's original "main"-like loop.

    I know, I know, it's friggin' obvious, right? Well, it was obvious to me when I made that mistake forgetting a function-definition long ago... I knew from many times compiling the Linux kernel that there were a TON of object-files each compiled from a C file which was aware *of* the others' functions (via declarations) but completely unaware of *where* to find them (the actual *address*). I dunno, I guess I figured there was no way the individual C files' gcc-output could possibly be human-readable, nevermind straight-up-easily-understood assembly that could quite literally be pasted into one's own assembly code.

    Really, friggin' amazing.

    And it worked like a charm in sdcc, turning my C code into z80 assembly, just like that. Hah!

    So, here's where the LOLs come in... I guess I completely forgot my AVR-programmer idea (and many others) from the last log just a few days ago, nevermind the countless thoughts and ramblings on it prior...

    And the next thing I know, (well, OK, there was a LOT of "knowing of" things inbetween) I've got an ihex-parser, tested with printfs in linux, in its native ARM (rathern trying to figure out a z80 emulator and whatever hardware emulation it might also need) that could easily be reconfigured to use "serpull" in the (new) firmware-assembly by merely adding 'getnextbyte equ serpull'. HAH!

    Then, I wrote and printf-tested the sector-grouper... Because, e.g. the first 128bytes (one flash sector) are very sparse due to the RST vectors, etc... Each is in its own ihex line. So, all those (and everything up to address 0x07ff) have to be combined into a full sector's data-buffer before that sector can be written to flash. Just finished testing that a bit ago... And no chip-pulling-jumper-changing...

    Read more »

  • Chicken Egg In-System-Programming

    Eric Hertz07/03/2022 at 07:31 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... https://hackaday.io/project/185919-z80-reverse-engineering-and-hacking-adventures/log/207723-in-circuit-programming 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.

    BUT

    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.

    Heh.

    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

    LOL.

    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...

View all 22 project logs

Enjoy this project?

Share

Discussions

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