Obsolete processors resurected in FPGAs

"Rainer Buchty" <buchty@atbode100.informatik.tu-muenchen.de> wrote in 
message news:cn7jhc$19bkr$1@sunsystem5.informatik.tu-muenchen.de...

> Next thing is, that mostly all 6502 cores I've seen so far emulate the 
> 65C02.
> For quite a number of legacy stuff which exploited the NMOS 6502 illegal
> opcodes for timing reasons a 65C02 is plain unusable.

Daniel's T65 can be configured as either. :-)

It can't do the Atari "sally" variant yet, but I imagine that most games 
writers would want their code to run on the ordinary 6502 in old 800 
machines as well. So code using 'sally' illegals would be even rarer than 
those using the usual illegals.

I wonder what fraction of all code used illegal opcodes, and were they ever 
much use?

"vax, 9000" <vax9000@gmail.com> wrote in message
news:cn6qnq$58c$1@charm.magnus.acs.ohio-state.edu...
> Monte Dalrymple wrote:
>
> >> > I am not sure of the specifics, because the customer took this
> >> > responsibility.
> >> > I suspect that the hardware certification process is easier than the
> >> > software
> >> > certification process. I saw a copy of the procedure used for
software
> >> > certification and I don't know how anyone could actually get any code
> >> > written in a finite amount of time following the procedure. But then,
> > I'm a
> >> > hardware guy. I do know that the customer found my testbench to be
> >> > very useful.
> >>
> >> Testbenchs are always under appreciated.
> >
> > Indeed.
>
> Agree. I only test my hobby project with a few settings and pray that
> everything else works.
>
> Did you try Zilog 16C01/16C00 (CMOS version Z8000)? Did you find any
> difference between Z8000 and 16C00?
>
> vax, 9000

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.

Hal Murray wrote:
> 
> >And unless you have the time and inclination to figure out the internal
> >timing for
> >this kind of subsystem (a non-trivial task) you wil never be able to achieve
> >cycle accuracy. A similar problem arises whenever you have more than one
> >clock domain in the device, as the original synchronization strategy will be
> >very
> >difficult to discern.
> 
> Why not?  Old cycle times were slow by modern standards.  Just add
> enough delay to match the specs.

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.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

In article <M7Lld.340$IM1.37@newsfe4-gui.ntli.net>,
 "Kryten" <kryten_droid_obfusticator@ntlworld.com> 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
	http://www.funet.fi/pub/cbm/documents/chipdata/6502-NMOS.extra.opcodes

and how they map into the overall opcode table here
	http://www.funet.fi/pub/cbm/documents/chipdata/64doc

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

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:jdzld.1215$3U4.105563@news02.tsnz.net...
> Monte Dalrymple wrote:
>
> > "Jim Granville" <no.spam@designtools.co.nz> wrote in message
> >>Interesting, Sounds a lot of work on the Z8000, can you elaborate on the
> >>reasons/needs for this core, in particular.
> >>Could also be a good example, for the OP.
> >>
> >>-jg
> >>
> >>
> >
> >
> > The original customer for this design makes air data computers, and
projects
> > demand to continue well beyond when the "obsolete part stock" quantities
of
> > the Z8000 will be around. Since the software for this system has to be
FAA
> > certified, changing even one line of code is horrendously expensive. I'm
> > sure
> > that the OP was talking about exactly these kinds of applications. There
are
> > a number of similar applications out there, because the Z8000 was the
first
> > MIL-qualified 16-bit CPU and was designed into quite a few military and
> > mil-spec systems. These are the kinds of systems with very long
lifetimes. I
> > know that the Z8000 was used in the F-15, the F-16, the 747 and the 757,
> > for example. All of these aircraft are still flying and are still in
> > production as
> > far as I know. These kinds of applications are the exact opposite of the
> > more
> > common "throw-it-away-in-18 months" that most people deal with today.
>
> ..and industrial systems are somewhere in-between.
>
> Did you need to get certification for the Z8000 SoftCPU ? - it seems
> this would need to be fully qualified as well, or have the MIL/FAA
> not quite caught up with the idea of SoftCPU ?
> -jg
>

"bh" <spam_not@nosuch.com> wrote in message 
news:<pAOld.5262$GV4.3584986@news4.srv.hcvlny.cv.net>...

[snip]
> 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.

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