Obsolete processors resurected in FPGAs

software

As far as I know, the comparison was only done with the Z8000. However, I am pretty sure that the CMOS conversion at Zilog was done directly from the schematics, so the devices would be identical.

As an aside, it's amusing to look at the Zilog website for a description of the 16C0X. It starts off with "RISC-like load/store architecture"... The Z8000 is classic CISC and is not anywhere near being load/store. The only thing RISC-like about it is the fact that the instruction set is quite regular.Classic marketing.

You wouldn't need to *match* the timings, only meet them. You can always provide more setup time or allow less setup time from the peripheral.

In article , "Kryten" writes: |> I wonder what fraction of all code used illegal opcodes, and were they ever |> much use?

On the C64 they were used quite often for fancy video manipulation; AFAIK they were also used within a floppy speeder to speed up GCR decoding.

IIRC the mainly used ones were of the "do something and wire-or the accu in" kind and multi-cycle NOPs.

You'll find a list here

and how they map into the overall opcode table here

Rainer

There are a number of applications where old 8080 code or Z8000 has gone through significant number of code reviews and the logic is considered safe for some special applications. Nevertheless, having confidence in the softCPU is pretty important in order to have the qualify-by-similarity argument will hold. Something like an 8080 is a much simpler task to verify, but it cannot be ignored.

Likewise, you really need to do some over-all system testing to insure subtle timing differences have not resulted in unexpected consequences. Just meeting/exceeding the timing of the original component is not good enough (IMHO) since there may be unknown dependencies on timing that might have been caught in the original qualification program.

With respect to FAA certification, I believe RTCA DO-254 addresses some of these issues.

-BH

projects

of

FAA

are

first

lifetimes. I

Tee hee. How very true.

Many years ago I worked on an academic project that involved modifying an existing industrial robot controller (an ASEA IRb6, if anyone's interested). It was a very early design with a single Intel 8008 CPU, and it had no useful external data comms links. So we replaced the CPU board with our own version that had a Z80 on it instead (advanced stuff, eh!) and, at least to start with, we wanted to run the original code on it. We disassembled the maker's 8008 machine code and re-assembled it for the Z80 (the Z80 opcodes and architecture were a proper superset of the 8008, but the binary instruction codings were different).

Everything worked perfectly except that, in one mode of operation, the robot moved at double speed. It turned out that the original designers had not been able to make the 8008's interrupt service routine run fast enough, and therefore it missed every second clock interrupt when in that particular mode. They had knowingly compensated for that by multiplying all the "speed" constants by two. Our Z80 design processed everything about 5x faster than the old version, and therefore it *didn't* miss alternate clock interrupts.

We had not anticipated this behaviour, because we knew that everything was controlled by clock interrupts and therefore assumed that the timing and speeds would all be OK.

Happy days, when it was possible to reverse-engineer by hand the whole embedded firmware of a non-trivial product...