Curious connections: Voyager probes and Sinclair ZX Spectrum

The Voyager space probes are dear to the hearts of every geek who can remember the 1980s. The twin robotic spacecraft launched in 1977, the same year as the Apple II, the TRS-80 and the Commodore Pet, making the spacecraft the patron saints of the modern computer age. By the time Voyager’s primary mission ended with Voyager 2' …

[AndrueC]

*Cough*

The Amstrad CPC6128 was released in 1985. The Spectrum 128k was Johnny Come Lately as far as Z80 memory paging was concerned in home computing.

I don't know about the Spectrum 128k but RAM swapping wasn't a huge inconvenience on the CPC. You just divided your code and data into blocks and arranged them as required. Paging was something you did relatively infrequently, something of a context switch rather than something you were continually working around. And again I don't know about the Speccy but on the CPC you could hide one RAM page behind ROM. When you wrote to the address it went through to the RAM so if you were only writing data you effectively extended the address space.

[munnoch]

The Spectrum switched in banks of 16K. So unlike the Voyager you could arrange to not pull the rug out from under your feet at least in terms of code running from RAM. With Interface 1 however you also had ROM switching in the bottom 16k of the address space which must have involved some sort of dispatch vector shenanigans between the two of them.

Most common use for RAM switching would be to swap over the frame buffers, display one whilst you wrote to the other, then swap them over. This made 128K games run slightly faster since you didn't need to LDI the new frame to the video address. Video memory was 6k. Can't for the life of me remember what we put in the other 10k since obviously it would only be available half the time and you couldn't just switch it whenever you felt like it. I'm guessing we put two copies of the same read-only stuff like tables and sprites in there rather than code. Am I right in remembering that the bank switched to the video address was slightly slower to access? Probably used the same technique on the CPC but its video memory was a bit bigger.

The only game I can think of that we enhanced to take advantage of the extra memory in the 128K was Outrun. It could keep more of the stages you'd played through in memory instead of having to reload from tape so game restarts could be quicker.

[Anonymous Coward]

Slower access

I'm pretty sure you're right. I believe it was also the case on the 48k speccy. Putting the interrupt vector table in the dissplay RAM was fun too.

[Sapient Fridge]

Re: Slower access

The 48K spectrum didn't do any RAM paging. I wrote several games for it (in Z80 assembly) before the 128K Spectrum came out.

I'm suprised the article said the ROM was badly documented given that the full disassembly was published in 1983 (2 years before the 128K Spectrum):

http://www.primrosebank.net/computers/zxspectrum/docs/CompleteSpectrumROMDisassemblyThe.pdf

Brings back memories that does!

[desht]

Re: Slower access

> Brings back memories that does!

Certainly does. That book was absolutely invaluable when I was writing & debugging xzx, the first Speccy emulator for Linux/Unix machines.

[JohnGrantNineTiles]

Re: Slower access

I suspect when he says the code was "badly documented" he actually means that Sinclair didn't have access to the source, having parted ways with the writers of it and omitted to keep the rights. That caused issues with the sale to Amstrad.

[AndrueC]

Most common use for RAM switching would be to swap over the frame buffers, display one whilst you wrote to the other, then swap them over.

Ah. The CPC didn't support page swapping for video. Programmers did of course still render into a buffer to improve performance(*) and reduce artefacts and I suppose you could render into RAM hidden behind ROM which sounds advantageous by in effect avoiding losing twice the address space to video but when complete you'd have to bring that page fully into the Z80's address space by hiding the ROM so that you could copy from there to the video buffer. I imagine games probably didn't use the ROM anyway so likely paged it out once they started running and just accepted having to 'waste' RAM on a video buffer. I think if a game needed more RAM it'd be code and data that they paged rather than video. Maybe just using it like a RAM Drive.

With Interface 1 however you also had ROM switching in the bottom 16k of the address space which must have involved some sort of dispatch vector shenanigans between the two of them.

Good point I'd forgotten about that. If I remember correctly the swap occurred when the I1 detected a specific address appearing on the bus. That triggered it to disable the internal ROM substitute its own contents. I don't know the reverse operation occurred but of course once you're running code on your ROM you can opt for a more specific command. There were several devices that did similar things including once that could pause the computer and allow you to examine memory or dump a memory snapshot to tape or disc.

(*)I know on the originally Speccys that accessing the video area of RAM was slower because the video hardware had priority and could NOP the Z80 while it was working. Unlike the Zx80 Sinclair didn't give the option of disabling frame syncs. I imagine the same was true of the CPC but it had a more advanced graphics chip that could adjust (the chip as in the BBC I think) so there were a few things you could do to be clever.

[AndrueC]

Ah, found it! The CPC range used the 6845. A cursory glance at that page suggests that it might have been possible to avoid copying stuff around RAM by reprogramming the scan start address when the frame was ready. And re-reading the other web page doesn't mean you couldn't use RAM paging - just that wherever the active video buffer had to be within the normal Z80 address space.

So my trick of writing through ROM seems like it would work and wouldn't require you to copy stuff around. Assuming my brief scan of that documentation for the 6845 is correct.

The original Speccy didn't have a dedicated video controller. It was all part of the logic held in its ULA. And I seem to remember a number of sources saying that Sinclair used far more of the gates on that than they should have.

Oh and the Microdrive used the same ROM swapping system as I1.

[Dan 55]

The Sinclair 128K Speccies had memory contention on pages 1, 3, 5, and 7. The Amstrad 128K Speccies had memory contention on pages 4-7. As a result Dizzy sounds normal(ish) on Amstrad 128K Speccies and demonic on Sinclair 128K Speccies.

[J.G.Harston]

On the CPC you set the 6845 start register to any address within a wrapping 16K block, and there was an I/O register to select the the base address of the 16K: 0K, 16K, 32K, 48K.

[J.G.Harston]

With Interface 1 however you also had ROM switching in the bottom 16k 8K of the address space

The Interface 1 code could see the top 8K of the system ROM and call code there.

[neuro]

cough, cough

the spectrum 128k was released in 1985 too, just not in the uk

[1024MAK]

Bank switching / paging

The Amstrad CPC 464 was also late to the party with regards to bank switching / paging of memory within a processors 64K address range.

Bank switching / paging memory had been around for years before.

I'm just giving two British and one American computers as examples (details below) but I'm sure there are even earlier examples. Certainly some microcontrollers of the time also used paging / bank switching for data RAM (registers) and sometimes program code space. You could also consider the Z80 processor as also using a type of paging / bank switching with it's alternative register set.

The Acorn BBC B released 1 December 1981 had paging / bank switching for the language and service ROMs (called sideways ROMs). But static RAM (SRAM) or DRAM could also be used if on an expansion board that plugged into IC sockets on the main board.

The Commodore 64, released August 1982 had paging / bank switching of both ROMs and RAM.

The Memotech MTX512 released in 1983 had paging / bank switching for the both the ROM area and the RAM area (it having 64K bytes of RAM and 24K bytes of ROM).

[Dan 55]

"The consequences of a coding error are also somewhat different"

Well, neither Sinclair nor Sugar were going to issue a bug-fixed ROM for the Spectrum, bless them. Sinclair because it would have taken money away from his portable TV and the C5 and Sugar because he'd spent more than enough money already buying it from Nine Tiles, despite it starting up with "© 1982 Sinclair Research Ltd", it never was.

[DJV]

"infuriating bodge"

One solution to the 64K limit was the Commodore equivalent from around 1982 - the 6509 processor. This was basically a 6502 with an addition to handle banked memory via two enhanced instructions - LDA(z),Y and STA(z),Y. These allowed one bank to access any of the other available banks to load and save data. The bank to use was specified by writing to the first two memory locations in the normal 64K memory map (the 6510 used in the C64 did something slightly different with the same two memory locations). The 6509 was only ever used in the CBM-II series (designated the 500, 600 and 700 series in some countries), which didn't last that long as Commodore lost enthusiasm for the project early on and ended up dumping stock.

[Doctor Syntax]

"The best technologies have a cultural impact that far outlives their original purposes, and to feel an intimate connection to them as that happens is worth celebrating indeed. "

They also illustrate another important lesson - don't lose your documentation. Nor, come to that, your build tools.

[45RPM]

One of my first jobs as a developer was to rebuild a system, porting it from Vax to the then brand spanking new (and, in fact, only available in sample form) Alpha processor.

Just a few snags. The documentation had been lost. The code was poorly documented. The code hadn’t been consistently checked in to CMS (think a VMS only very primitive Git). So I then had to check all of the development systems, gathering up scraps of code, debugging madly as I went, to see if I could build a coherent working version. Documenting it all as I went.

The code was all nearly entirely C with a bit of Pascal and a smidgen of DCL. And no AI to ask. No Stack to ask either if it comes to that. So yes. I sympathise with this story. It was a different world.

[Phil O'Sophical]

It was a different world.

And so much more fun.

I'm glad that I'm now retired from what it's become.

[MrBanana]

Too many conversations with Informix 4GL customers along the lines of....

"You just need to change this statement in the SQL code to fix it."

"Oh, great. How do I find that line in the P-code file, and then recompile it?. That's all we have. No documentation or functional specification".

"Err nope. if all you have is the P-code. Then that's already compiled. You're screwed. Please stay on the line for one of our mental health advisers".

[Anonymous Coward]

> They also illustrate another important lesson - don't lose your documentation. Nor, come to that, your build tools.

That's a nice thing to say, along the lines of "make sure to make a million dollars" but it's not always possible.

This is almost a 50 year project. Think of all the people that have come and gone, and where a particular manual might be. It could have been taken home and either forgotten when they retired, or the person has died and no one even knows.

It could also be a case of "you don't need to document that, there's only one sane way to do it and everybody knows" and the rationale behind "there's only one sane way to do it" is long lost. It's obvious when someone explains it but you need someone to explain it.

I'm personally in that situation right now, thus anon.

[MonkeyJuice]

As Voyager 2 was nearly three billion miles (4.7 billion kilometers) away at that point, however, hardware upgrades were ruled out by the cost of delivery

This elicited a much needed hearty chuckle on a dreary Monday. Exactly like peeking and poking at 110 baud with a 48 hour latency wouldn't.

[Sam not the Viking]

Special Delivery

It would be delivered to the wrong Voyager. "How did we do today?"

[RMclan]

Re: Special Delivery

Evri: You weren't at home so we left your package behind Titania

[Caver_Dave]

Documentation

The original Spectrum was very well specified. I have the complete ROM disassembly book still on my bookshelf.

[Anonymous Coward]

Re: Documentation

I thought that book was reverse engineered from the actual ROM.

[Caver_Dave]

Re: Documentation

Even if it was 'externally' generated then it was still available to the support teams in perpetuity.

I had the complete ROM listings for the Epson PX4, Epson EHT-10, etc. About 4 inches thick of fanfold made into a book for each.

[Dan 55]

Re: Documentation

I wouldn't like to have been the person who had to type out all of that and coax it to assemble with a different toolchain in 1985.

[ChoHag]

Re: Documentation

As long as it's not being typed out *on* a spectrum.

[Tron]

Re: Documentation

One of the joys of 8-bit machines was the publication of ROM disassemblies. The Sinclair machines (and peripherals) were particularly well covered. Most were third party jobs, but Apple produced their own. Yes, Apple!

Interested parties might want to check out 'The ZX Spectrum ULA. How to Design a Microcomputer' by Chris Gifford.

[JohnGrantNineTiles]

Re: Documentation

For a long time I had a printout of the original source code, which was properly commented. If I ever find it it'll go to the Centre for Computing History to be reunited with the prototype.

[Anonymous Coward]

"It's not as nasty as Intel's segment register solution"

Actually, Intel solution is quite clean, especially in protected mode, where it allows an high degree of security that is now mostly lost, so we can enjoy a lot of vulnerabilities because the lack of it.

The only thing it wasn't goot at is swapping memory in and out to an external storage - segments are too large. 64K or larger pages would be as well, anyway.

[MonkeyJuice]

Re: "It's not as nasty as Intel's segment register solution"

I think the author was specifically referring to the Real Mode of the 808x, prior to the Protected Mode of the 286s, which, I can assure you, was a pile of shite to move to after being spoiled by the Motorola 68000.

[John Smith 19]

For all old NASA computer stuff

The classic is "Computers In Spaceflight: The NASA Experience" by Tomayko, written in 1988. It's everything from Gemini up to Voyager and Galileo, with a side order of the ground systems running checkout.

I like it because it shows a time when people didn't just write language, they hacked whole processors.

Lots of oddball word lengths, often opcodes with built-in ECC due to the fear of radiation flipped bits (this at a time when most of the memory for all of these was core store, whose radiation hardness was pretty impressive).

IIRC the most "Advanced" actual microprocessor was the RCA1802. An SOS design. It still amazes me the silicon layer in it was 0.5 micrometres thick.

For any of you who've seen "Space Cowboys," you'll find quite a lot to keep you amused as well.

Also lots of bit slice hardware (you might like to look at "Mick & Brick" if you want to dig deeper) and stuff built round the the TTL '171 ALU, as used by the Xerox PARC Alto, PDP 11, DG Nova, and pretty much anything else that was on the minicomputer market in the 70's and 80's.

Happy reading.

[Maurice Mynah]

Re: For all old NASA computer stuff

74181, I think you mean? (74171 is a quad flip flop. Might take a lot of those to get anywhere useful!)

[John Smith 19]

"74181, I think you mean? "

Quite correct.

In fact the '181 is mostly 2 input OR,AND, NOR and NAND gates, with a smattering of EORs, about 90+ all told, but that's again from memory.

I think it's still a pretty good building block.

[Empire of the Pussycat]

Mick & Brick

That brought memories flooding back!

M&B helped when I was developing a co-processor for signal acquisition and DSP back in the '80s.

[John Smith 19]

Re: Mick & Brick

In a parallel history microprocessors come out a bit later and people realise that Unix (which at this point was available for the copy costs of a distribution tape) gave them access to all the dev tools they'd need to host a modern (for the time) OS onto their custom hardware, allowing them to write in C instead of whatever assembler they'd invariably managed to knock together.

People were running phototypesetting systems and image processing systems on custom processors in the late 70's. The tech could deliver substantial performance, but doing it all in some one-of-a-kind assembler meant it never got the critical mass to go mainstream.

What might have been.

[John Smith 19]

"M&B helped when I was developing a co-processor for signal acquisition and DSP back in the '80s."

I'm quite sure you weren't alone in that, before Ti brought out the TMS340 range and that took care of an awful lot of those sorts of things. Prior to them Intel had a funny thing out the 2920, very odd.

[Anonymous Coward]

A 280 processor?

Had to re-read that a couple times, but my speccy had a Z80 processor, not a "280"

[AndrueC]

Re: A 280 processor?

Yeah I noticed that as well. Was the article typed out manually then OCRd? Retro technology and all that.

[jake]

Re: A 280 processor?

Or was the article written by an AI that was partially trained on OCRed documents?

[John Smith 19]

Re: A 280 processor?

Indeed.

Someone hasn't proof-read the copy. :-(

Now if they switched on narrator and had it speak their copy their ears would have detected the dud instantly.

[Simon Harris]

The longest wait was the five minutes it took to blow a new 32k UVEPROM.

Of course if you were strapped for cash, and didn't have many to spare, the longest wait was the 1/2 hour or so in the UV eraser to wipe the previous version of the software from the EPROM first.

[neuro]

what?

i mean … what?

[John Smith 19]

"i mean … what?"

They are talking about UV eraable EPROMs, which had a clear "lid" on them.

This meant you could stick a bunch of them in a UV eraser (IE a sealed light box with a UV tube in) that could mass wipe them.

Wildly implausible, but real, unlike this gadget, which sounds plausible, but never existed.

[J.G.Harston]

Not only did the Spectrum not have a modern operating system - how could it without time travel? - it doesn't even have a 1980-era operating system. Absolutely everything is done by jumping to more-or-less random points in the system code. Though, to give full credit, that's exactly the same as the Apple II.

[sitta_europea]

" ... Absolutely everything is done by jumping to more-or-less random points in the system code. ... "

Exactly what I did in the late 1970s, when I had to not only do all the data reduction for RadioImmunoAssay, but also spectrum stabilization for (sixteen photomultipliers in) the scintillation counters in the instrument on the bench. A 6800, 2K of ROM (there wasn't an unused byte) and 256 bytes of RAM. Data input via DMA. Needs must.

[AndrueC]

There were a few formal entry points using the RST command but yes it was basically just a command line processor with a variant of BASIC as it's scripting language.

[Anonymous Coward]

Time capsule of a machine

It's truly amazing about these Voyager probes. Imagine working on the team that maintains and supports them. It's like dealing with a time capsule of a design from decades ago, which you can't upgrade and it's standalone. Whether it's a Spectrum or a Commodore floating in space millions and millions of miles away, you can only work with that design and nothing more. So you must learn the system in and out, and work with its limited capabilities to get the task at hand completed.

There's something calming about this, knowing that the Voyager systems are not subject to constant upgrades with the latest and greatest technologies. You have to work with what you have, and understand it very well. And the fact it was designed so long ago adds to that challenge.

Kudos to all these modern day folks who work on the teams that support these systems, and still know how to work with them.

Very cool article.

PS: you may all now carry on bragging about your accomplishments and what you did in the past.