Reminder: There is now a dedicated project-page at #Z80 Reverse-Engineering And Hacking Adventures . Be sure to head over there for the latest!

ALSO: The comments, here, contain a wealth of insight! 

READ THE COMMENTS!

This is an interesting find! I don't know how big the eprom is, but considering there is only 2 KiB ram, I would suspect the rom is concomitantly smallish. Which means.... you already know I want a rom dump!

Interesting that they used the various Z80 peripheral chips, so I wonder if maybe IM2 might be in the mix. I've rarely seen that for whatever reason.

Also interesting are the many unpopulated parts and the lack of silkscreen. It's pretty clear that ROM expansion was anticipated, but who knows about the rest. Judging by the ROM sticker, I presume this is the Spectra Data model SD70; e.g.:

https://anatekinstruments.com/products/spectra-data-sd70

That might get you to finding some technical manuals. The board is very roomy. Gotta figure out that AMD part...

Interesting, yahknow... It hadn't really clicked that there's no silkscreen. I was pretty wowed by how clean everything is, and the almost dayglow green soldermask. Also, surprised I hadn't really noticed the unpopulated ROM spots (suppose they could be RAM, too... Wonder if SRAM comes in EPROM pinouts for exactly such purposes...), seeing as how I'm always looking for potential points of hackery. Yeah, they must've had other/future plans for this board. Or, maybe they reused it from something else...

You found it! The Only mention of it on all of the interweb... heh! It's a mixed-bag sorta store, mostly surplus, but also merged with a test-equipment dealer (manufacturer?). In this case, I'm pretty certain it was surplus, and my guess as to the cost being *so* low is that they too couldn't find anything about it. There's one left in stock, and like you pointed-out, it's *very* roomy, inside, making it surprisingly light and shipping surprisingly reasonable. Why am I hesitating to get it? It might have a legible AMD chip! Though, my guess is these two units have always been together (ohhh... now I feel bad separating them!), so they probably have the same ROM version and options (lacking GPIB).

I was wondering how deep your Z80 disassembly addiction goes... I hesitate to tell you I dug out a PCB from an old 1200baud modem which looks to have been Z80, and surely its ROM is in my mostly-unlabelled scavenged EPROM collection.

But this, this is different, I know... It's quite a curiosity. 

It'll be a while until I've got my chip programmer set up, so I won't be *as much* an addict-enabler ;)

Interesting that you find it interesting that they used so many Z80 support chips. I was under the impression most things Z80 had them. Hmmm....

I also hesitate to mention that I also found in my scrap PCB pile, IIRC, a 2400baud modem with a Z180 and a Z180-(was it)-KIO, which I looked up and found to be basically all the Z80 support chips in one large PLCC.

I think I've gone a bit overboard, now, in thinking it might be plausible to turn it into a Kaypro-(or similar)-compatible, get some CP/M up on there, a flip-up LCD (or that EL panel I've been wanting to use?) hah!  Heck, even mount a keyboard on there somewhere... Throw in the Omni4's logic-analyzer board (or duplicate it?)... Sheesh, brain, why? Besides, I ain't adding a homebrew floppy controller, to anything, ever. So There, brain!

Judging by your front panel shots with LCD text, this is possibly a German/Swiss product. "SD70" unfortunately collides with much more prolific model train stuff, so it's hard to drill down in the search results. 'Thanks' google and pagerank. For this search, maybe we need an 'inverse page rank'.

The German/Swiss origin might suggest the clean design you observed, though I noticed that the chips are pretty haphazardly oriented, so I'm leaning German over Swiss, lol. Without a silkscreen, and without a distinguishing pad for pin 1 (e.g. the notional 'extra rom' places), it will be a challenge to figure out some of the others. Like the mysterious ones that have sockets, but no chips. What are those, and why did they go to the bother of the cost of putting in the (expensive) machine pin sockets?  I suspect all of this is business-related:

* the socketed stuff is for upgrade options within the SD70 product line.
* the unsocketed rom (and other) stuff is for stuff for a different non-SD70 product line. Having one display board PCB design across product lines is economical.
* the lack of silkscreen is just being cheap.

My addiction to disassembly has no known depth. And I am particularly interested in this firmware because of the potential IM2 aspect. The presence of the PIO, CTC, and DART are good indicators that IM2 is being used.

So please addiction-enable away! I have 2 weeks before start date, and I maybe can make some headway in that time.

The Z80 systems I have ever seen rarely used the Z80 peripheral chips, and so did not use IM2. In addition to being like the 8255 that provides a few parallel ports, the Z80 PIO also serves as sort of an 'interrupt controller'. Your mention of there being an 8255 suggests to me that they are using IM2, because otherwise why bother? Why not just stick to the 8255 throughout the design? Incidentally, I know that also the TRS-80 Model II was a full-on Z80 design that used the whole chipset, but I struggle to recall another that I encountered.

I probably won't be able to make sense of everything in the disassembly. Part of the programming is in the wiring itself. The priority system in IM2 is set by the order of the the daisy-chain wiring, and I can't see that from code. Also, we don't know about what external dodads this was supposed to connect to. Some mass spectrometer thing?

But who cares? I should be able to sort out a lot, I think, and maybe even figure out some clues to the AMD device. I wish there was a regex search over part numbers.

LOL at German over Swiss!

OK, OK, I think my 486 lappy still runs, I'll dig out the chip programmer soon.

But, wouldn't you rather 8080?

And, maybe I can probe some pins if you give me some guidance.

IM2 sleuthing/deduction sounds quite sound... I did wonder about the 8255 and Z80-PIO oddity!

I'm done with the 8080; I've had my fun there.

This is your project and all this is at your leisure. But I won't lie I'm quite eager for this rom dump.

I will doubtless have many pin probing questions, but again you can do that when/if you want.

The only thing I can guess about 8255 is that they just needed some garden-variety parallel IO without interrupt capability, and anyway the 8255 has 3 ports instead of 2. Won't know until we get there.

Ask and ye shall Receive... Holy Moly, you wouldn't believe the number of computers and various media types involved in getting this on the internet!

https://cdn.hackaday.io/files/8348357160832/SD70.HEX

There's a raw binary , there, too... under this "project" page's files.

And, if you wanna look at some MCS48 code for nostalgia, or whatnot, I also uploaded the ROM from the 8035 board I repurposed (with only a tiny amount of vintage-destroyer-guilt). Apparently it was a parallel printer adapter for Commodore 64's... There's some interesting ASCII in there that almost looks easter-eggish.

OK, lessee...

The programmer has a replacement "family module" that I had to make, long ago, which wasn't making contact, so all the reads were 0xff.

The 486 somehow managed to boot, this time, despite the dead battery which forced me to regut it last time, then I stupidly left attached this last time and was drained, again, to the point of not being detected, again, which unlike last time, thankfully, did not prevent booting this time. (weird, but welcome).

The reads were great after I figured out the contact issue, which was an ordeal, involving fear of yet another mysteriously-internally-shorted transistor despite its working fine the last time. Thankfully, just shitty contact, this time.

The chip's label covers most of the part number, but the programmer program has an awesome search that just looks for each letter typed, anywhere, in any order... So, "8A-2" was all it needed to find it... Heh! No such luck, though, trying to find that AMD part in there...

Oh, lappy did complain, however, about the floppy drive, despite its having been fine the last time, and wouldn't boot until I removed it (thankfully modular), then explicitly told it to try the hard disk first, which is ridiculous (and again, I don't recall being an issue previously) considering its modularity, intentionally designed to be removed to make the system thinner, and its not being an option to configure/disable in the bios.

OK, Now... I had a PCMCIA to Compact Flash adapter, and a 32MB CF card amazingly easily-found... Just copy the files to CF and plop the CF into a USB reader, plug that into a USBC adapter, then the phone, right?

Phone No likey FAT16.

OK, here's weird: There was a 128MB SmartMedia card in a PCMCIA adapter in the lappy when i took it out of the bag...

WTH, I actually tried to use that thing? Last I recall, it had a major read error that crashed every system I tried it in... But there it was. And, oddly, there was a USB adapter for it in my box of PCMCIA cards... So, while trying to figure out what I was going to try next, I figured I'd see if it actually worked in the phone... And... it did. (What?!).

OK, so plug er back into lappy, copy files. Lappy doesn't even see it. Nada, no response. (why was it in the slot earlier?!)

OK, maybe it was a Cardbus card? I'd long ago removed the case. I recall, though, this lappy has cardbus in the specs... but also recall having tried many with exactly the same nada response... So, looker up. Sure nough Windows 95 didn't have cardbus support until OSR2, which this is not. Heh. (So, why was it in the slot?) So I compare various cards, and no, this isn't cardbus... So, why no work? So then when did FAT32 come out, anyhow? OSR2. SHEESH. But, still, I should see the drive in fdisk, right? Friggin FDIK is not fdisk. Friggin keyboard is malfunctioning. There ain't no commandlining this... Oh, I know, I can boot off the card, anyhow, it looked like it was bootable, then copy from DOS... HAH, keyboard, dummy.

But I try, anyhow, and it won't boot. But the CF card also looked bootable, so tried that, too, nogo... Why was that stupid SM card in there, anyhow? Back to Win, pop it in, no PCMCIA ding, either... Well, I mean, I should've at least got that... Turns out even though the SM card is definitely made to go in only one way, this adapter ignored that. Flip it over, ding ding. But, no drive in My Computer, of course, cause fat32. Heh.

Alright, so now to get out the big guns, my main compy is a bit of a hassle to get going, power-wise, space-wise, etc. Also, despite being probably 50x faster than my first internet-browsing computer, and plenty fast enough for nearly everything else I do, this one takes *minutes* to load a search page. I ain't bouts to upload from it. Can I network-share over wifi to a phone? Nevermind, OK, FAT16 CF goes to Compy, copy to FAT32 SM, copy to phone. No prob. FAT16 to Compy, Done. Compy to FAT32? No drag-n-drop... WTH. It's mounted Read Only. OK, remount. Nope, write-protected. Pull the thing out, no write-protect sticker. Dunno. Look at the files, Sure-enough, I did a badblock test a while back and wrote a dud file over them... Nice. So, no wonder it's not crashing systems anymore... But... No idea why it's write protected.

Then it hits me... DUH. I can just plug the friggin phone into compy and drag directly to it. Sheesh.

I was *almost* beginning to plan-out installing Win98 on the lappy. HAH!

LOL, what an adventure.

My mind's really quite boggled how these issues hadn't come up before, and the ones that didn't which seemed almost certain.

Oh, heck, I also had Tom'sRootBoot in the floppy drive, if that drive was flaking due maybe to just a poor connection, I probably could've done the copy to FAT32 under that.... GAH, No! The friggin keyb! LOL.

Guess I better lower my expectations for my next 486 go-round. Or raise my expectations of things to tackle... Win98, after the keyboard. Battery, I think just needs to be charged externally. AND REMOVED when in storage. Cardbus cards DO slide in, but are keyed not to fit older slots, so Win98 would mean USB2.0! I do like that lappy, and have used it several times over the past few years, even used it for #OMNI 4 - a Kaypro 2x Logic Analyzer ! So, maybe some fixing (and upgrading!) is in order.

you have my undying gratitude. just setting up to check it out. looking at your screen shots:

* character LCD, 40x2
* 10 buttons, accompanying LED indicators. I'm calling these 'mode' buttons for now
* 12 buttons as a numeric keypad with dot and 'C' (presumably 'clear')

That will probably help make sense of a bunch of the PIO in the code. I don't suppose you can read the crystal frequency off the can?

Taking a quick glance at the code so far:
* definitely IM2
* RAM at c000-c7ff
* LCD appears to be at port 68h and 69h; my current guess is an HD44780-compatible
* lots of IO ports!
* I guess it's both German /and/ Swiss:  "Uferstrasse 74  D-2900 Oldenburg"

you have quite the vintage hardware collection!

Looks like your IM2 deduction was right! Nicely-done, and glad it turned out to be what you were looking for!

You missed a note. Or, rather, it's probably so obvious to you as to not be noteworthy, but I felt kinda smart noticing.... Looks like the first instruction is a jump to the actual startup code 'round 0x1800, as I recall.

Wait a minute... I *was* thinking that was merely so they could put the brand/model-string where it's easily viewable... But as I wrote that it occurred to me it probably had more to do with interrupt/rst vectors... But, no, there was ASCII there... a LOT. OK, IIRC of your explanations of IM2, those interrupt vectors are actually assigned *by* the interrupting device... Weird, almost suggesting a "device" could come with its own ROM, for "drivers", e.g. if installed on an upgrade card? Hmm. Anyhow, fine, then that means no need for low-address interrupt vectors. But, can I also gather, from this, that there is no use of RST? (I'm just throwing out my own reasoning, here, I could certainly look it up.)

I'm betting you're right about the display. And, IIRC, I do believe the C was Clear.

(I'd originally hoped that keypad was 4x4 for hex-entry, make a single-stepping "trainer" out of it, heh! I suppose A-F could be moved elsewhere... but I guess hex-entry would require *running* code to process the keypad, so hand-entry of instructions, single-stepping, etc. would be more like interfacing with a "monitor program"(?) (in ROM) than a typical front panel with switches and LEDs. Could be useful. Sure, why not?)

I gather you sleuthed the RAM address by seeing the assignment to the stack pointer?

Finding the LCD address, though, hah! Well, wait, is it mem-mapped? I guess there were several initialization instructions in a row, so multiple writes to the same address early-on. Or did you uncover a function like putc() by searching for accesses to the strings?

I'll look up the crystal frequency next i have access. If you think of any multimeter-probing, lemme know. Oscilloscoping, though, would have a long turnaround-time... Doable, though.

Most (albeit not all) my vintage equipment wasn't so vintage when I got it... I used to be the place family-friends sent their eWaste. Unfortunately, I was too naive to imagine things like 286s would ever be desirable again.

Thus things like that C64-to-parallel-printer converter's having been in pieces in my scrap PCBs and scavenged project-boxes bins for so long, just waiting to be repurposed. Some of these things I've contemplated reassembling. Most, though, lost important pieces in moves. That one, well, I stumbled on all the parts, but I saw several on ebay for only a few bux, must not be particularly sought-after.

486 lappy, though... That one is kinda special, so survived the scavenging where three P150 lappies didn't.

Anyhow, you've only a short time remaining to fuel your z80-disassembly addiction, and here I am talking your ear off. I don't expect you to explain how you came to your findings, unless you want to.

Oh, you know I tend to ramble. Yes I was using 'edit' to add things and didn't hit 'refresh' before I did 'edit', so I may have missed a response and said something redundant.

Yes, when I start it is usually from reset and then go forward. But it branches off quickly from there because it is a wasteland of data and code and erroneous disassembly, and I like to set up meaningful cross-references. During that exploratory phase I stumbled upon some math routines. Many are 48 bits. But soon I got to some stuff pointing near, but not exactly, to text strings. I really like to hit text IO as soon as possible because the text gives you a clue as to what the calling code does; e.g. via error messages or prompts. We're at a disadvantage because we don't know what this contraption is, other than the control panel for a spectroscope thingamajig.

It turns out the text strings are prefixed by a couple bytes, and terminated with an '@'. Yes, an '@'. Hey, this is Swiss. Or German. Or both! I like to think the '@' is a tiny strudel given to the CPU as a reward for having finished sending out the text. Gotta keep the CPU motivated. And then suffixed with a byte. Having the hunch that this is a HD44780 based upon your photo and also wishful thinking I could see that these string lumps were referenced by some common code that did IO and went from there from all calling references and collecting all the strings. This took a while.

Turns out the wrapped strings consist of a native LCD command, an initial cursor position, an @-terminated ASCII string, and then a final cursor position. Cursor positions are linear, so e.g. 1 means line 0, column 1, and 41 means line 2, column 1. Because of a quirk with the @-terminator, it is impossible to set the cursor at line 2 column 24, but I guess they didn't care. (There are some other similar quirks elsewhere.)

Yes, the RST are useless because they put their big fat copyright all over that area. I mean, it's not like they haven't got over 2k unused at the end of rom where that could be placed, but hey, whatever. Have a strudel.

The ISR vector table is at 0x0100 after some padding following the big fat copyright. There are 16 entries. Most (12) are no-ops. So that means 4 to figure out.

I'm going great guns right now, and am now collecting port numbers. I'm up to 19 and I'm sure there are quite a few more. They have a routine that blasts ports from a list, so I've been collecting from those for starters. It's been a bear. Then I need to find the other ports that are conventionally accessed. I noticed an OTIR! That is a new one for me. I wonder which peripheral could use that. There's no handshaking with that instruction, so it doesn't seem like the DART can use it.

There are DIP switches that are surely connected to some PIO. I have a hunch one selects GPIB or RS232 because there's a fork in the code path on the boot screen that indicates which mode you're in. If you want to diddle dip switches one-by-one and reboot and see if you get the GPIB message, do let me know which switch that was (if any). That might help locate a PIO in the port address space. But don't kill yourself. Maybe I'll have a smarter request later, anyway.

You really could put a decent BASIC on this and access via the serial port. It won't be too much fun with 2k ram, but I'm sure you can figure something out with extending the RAM but maybe we're aways off from understanding address decoding and how practical that is.

I'll send you the work when it gells a little more. It's pretty raw right now. Figuring out the ports blind is going to be... Interesting.

Interesting!

Yahknow, BASIC is an idea I hadn't really pondered... I'd rambled about my universal reduced-assembler (maybe urasm?) idea, before, thinking along the lines of a minimal "OS" that could run on nearly any 8bitter... (BTW, long-winded response to your response is in the queue). I figured libraries and drivers could be done similarly... but, ultimately, I think I'd pretty much limited the idea to getting a terminal attached. What to do then? Maybe just a monitor-program... a full-fledged OS would be way beyond me. But, Why not BASIC? Hmmm.... Might even be able to port something already-existant (TinyBASIC?). And certainly would be way more useful than trying to ASM everything... Hmmm....

Part of this "universal" endeavor includes the idea that RAM/ROM is *way* more available today... If nothing else, because it uses only a fraction of the available instruction-set, so like RISC, uses far more instructions to accomplish the same goals. That's by-design... Reduce the learning-curve, reduce entry-barriers like your experience getting SDCC to compile for your 8080. If SDCC had an 8080 interface from the start, then moving that to z80 could be as simple as redirecting its output to z80-uasm. Sure, not *nearly* as optimized as it could be, but functional, nonetheless.

I imagine throwing a 64K (largely unused) SRAM at this particular machine shouldn't be too difficult.

BTW, the crystal is marked 4.9152.

And I think imma start some pin-probing, though I don't really know what'd be useful. I doubt a full schematic is in my near future.

48bit (integer?) math, wild... Only thing I can think is the stepper, but I've done a bit with motors and 32 bits has never been a limitation... Otherwise, maybe floating-point? Or, I suppose, if they implemented acceleration curves, I suppose they could be doing a lot of squaring. I can't imagine a huge number of steps for their diffraction grating(?) just going on how precise they'd have to make that machinery to have a million steps over what i imagine to be a mm-ish... Maybe the steps fit in 24bits. Oh, or maybe rather than moving the grating/prism, they move the sensor... hmm... Spectrometers definitely aren't my area of expertise.

Interesting about the @ termination. I coulda sworn some of the z80 instructions commonly used for string-stuff could automatically detect null termination(?).

LOL at 19 ports, likely more... I guess I'm still thinking in microcontroller-realm, though. Yeah, I mean, a single PIO chip is two ports, ritght? And there's two of them. Then the serial... And I saw GPIB mentioned in the rom dump, even though the splashscreen says RS-232, only. Timer/Counter... And whatever controls the stepper... And I don't think that even includes the actual UI, which is where port-io would be really heavy. HAH!

Looking at these traces to start some probing... *sigh* I see one reason the horizontal on one side, vertical on the other technique is no fun...

Erm, check out the three new pics I added, (at the top of the pics. Couldn't figure out how to insert them at the end).

Lemme know what you think...

(Hint: theree chips, three brands and one marked like I've never seen!)

You've probably already deduced quite a bit of this, but I've followed some traces... (schematic added to photos).

Looks like there are two LS138 3-in 8-out demuxes used for IO. Their inputs are connected to A3-A5. A6 selects between the two. Oddly(?), M1 disables them.

There's another LS138 down by the ROM and RAM. It's hard-wired to only demux 2bits to four. A14 and A15. Output 0 goes to the ROM's Enable input(s!). Output 3 goes to the RAM's Chip-Select AND Output-Enable (maybe allowing for more time to dig up the data?).

Outputs 1 and 2 go to the unpopulated DIPs between the ROM and RAM. It looks like Output1 is intended to go to a ROM, while Output2 is intended for RAM (/WR is available, there) (or maybe 5V flash, if they had it way back then?).

The unpopulated IDC header has all the data bits, but only A0 and A1, Interestingly, it also has IORQ and M1... So, I guess it handles ports 0-3? I can't trace a few pins, I thought they may go to the LS138's, and this might make for an LCD header... but not found., and M1... well. But, seems a bit strange to put "add-ons" at the lowest ports, so maybe those unknown pins go elsewhere. Heh, didn't think to check e.g. A7.

The NMI pin is hardwired high. As are BusReq and WAIT.

I guess that's it, for now...

the clock frequency of 4.9152 is... interesting. pity that 'scope is difficult for you, but we're aways off from caring about any of that. For now I'm going to assume that's a master clock fed to everything. The choice might make sense for serial or something. Knowing will possibly be important later for understanding the CTC and DART, and I have seen at least one spin delay loop in the code so far.

Figuring out the address decoding for both memory and ports would be a big help. right now I'm awash in in's and out's. Flying blind on a rocket cycle, what I was prepared to do was pattern match the read and write patterns of groups of ports against the data sheets of the various chips to do a process of elimination/exclusion. Painful. I probably should script that but I guess I'm not smart enough. Anyway, anything you can find out from the actual board will be a godsend. Maybe continuity from the various chip selects back to the decoders might be enlightening. I'm digesting your '138 work now; that's a help. So each peripheral is almost certainly in an 8-port block.

I'm going to try to wrap up my port survey and restrain myself from more disassembly tomorrow to soak up some datasheets. I have never worked with the actual support chips and need to understand the IM2 architecture better.

It's always a learning experience. I was surprised to see 'ld (ix+ffh), a' apparently does not do what I think it does. I guess the addend is sign-extended?! Because it's very clear that this was meant to logically be 'ld (ix-1), a'. This surprised me because the offset is 8 bits, and IX of course is 16 bits. I always expected the offset to be treated as unsigned. I couldn't find chapter and verse in the docs, but I guess the fact that this code would never have worked if it wasn't interpreted as signed is the existence proof. So I maybe I learned something new here! (This was in a binary-to-hex routine, fwiw.)

You can fit a delicious BASIC in 16k. The TRS80 Model I had a 12k rom, and much of that space was devoted to keyboard, video, and other IO not relevant here. It seems from your findings that the address decoding is in sections of 16k, and the second unpopulated 28-pin dip is ready for ram, so you could potentially drop in up to 16k without rework if the wiring permits. I guess the 2k being in a 24pin package limits options there, but I know you're not scared of bending pins and kynar wire!  Speaking of which...

Wow, a lot of mods to this board. So, a low volume production. But then, I guess mass spectrometers don't exactly fly off the shelves.