Apollo Team announces the Vampire V4

[nexus]

why do you keep suggesting arm?
do you not understand all the types of boards out there atm?
nobody said it had to be a arm chip
and i never said i was making a emulated 68k this is a forum im just speaking my thoughts on this subject isnt that what a forum is for?
too much assuming

[Megol]

Originally Posted by Samurai_Crow

Are you eager to write an ARM JIT for the full 68080 instruction set including AMMX2?

How could he answer that given that AMMX2 isn't documented nor described?

[kolla]

Originally Posted by nexus

the fpga run software code that configures it to simulate a 68k

No it doesn't, it just loads a recipe for all the gates, and once all gates are configured, you have a 68k core there. At that point it is not running anything, and once you throw code at it, it's that 68k core that is running the code, not any "software code that configures it to simulate a 68k".

emulating a 68k with hardware

I would love to see 68k emulation done with something else than hardware.

either way it can be done other ways and better for less

CPU emulation is really not an issue, 68k CPUs are single core and AmigaOS and Amiga programs mostly uses the CPU sequentially, only exception is FPU. What bogs down any software emulator is chipset emulation, for many reasons... chipset components run in parallel with the CPU, and in parallel with each other. Chipset emulation is not just computation, it is simulating analogue effects and aspects, some whack effect that costs _nothing_ on real Amiga, can need tons of code to emulate well with software.

For the "simulation vs emulation" discussion.

Simulation is downloading a youtube video of an Amiga AGA demo from youtube, convert it to "DVD quality" MPEG1, and play it off with RiVa on your Vampire, showing your friends how your A500 can show an AGA demo.

Emulation is feeding the original AGA demo binary to some piece of software that manages to parse all its content and present it in a way that resembles running the demo on real hardware.

[nexus]

the software that configures the fpga is software code telling it how to be a emulated 68k or whatever
like i said
it is emulated not simulated if it was simulated then it better act 100% like a known 68k which it doesnt
since this is this new 68080 whatever it is emulating 68k buy use of hardware setup from software
again it doesnt matter by the end result

[Mr-Z]

Originally Posted by nexus

the software that configures the fpga is software code telling it how to be a emulated 68k or whatever
like i said
it is emulated not simulated if it was simulated then it better act 100% like a known 68k which it doesnt
since this is this new 68080 whatever it is emulating 68k buy use of hardware setup from software
again it doesnt matter by the end result

One way or another it's no emulation, when you configure the FPGA as a 68K processor then it's a 68K processor.
And it does act 100% like a 68K processor but with new features.


You seem to mix up the fact that the software is there to tell the FPGA how to configure itself.

[nexus]

if it acts 100% as a 68k then it should have same instructions pipeline the same amount instructions per clock etc etc etc it doesnt

and i swore i said multiple times how a fpga is configured think you need to reread before commenting

[ShK]

A FPGA for an ASIC is same as a CD-RW for a CD-ROM.

VHDL (VHSIC Hardware Description Language) is a hardware description language which tells to FPGA how to set a real hardware (gates and wires). It's not the code which is being run.

CD-RW does not emulate CD-ROM. 68080, 68060, 68040, etc. does not emulate 68k.

[nexus]

i know what VHDL and verilog are very well
and without that code you have nothing

and that analogy is horrible and helps your case 0
please stop referencing things that have nothing to do with how fpga works
you are just confusing the lurkers

anyway i see its nothing but team members commenting on my post so already a conflict here i made my point
no need to use a fpga and charge ridiculous prices

[Bruce Abbott]

Originally Posted by nexus

no need to use a fpga and charge ridiculous prices

'Ridiculous prices' is selling a second-hand Blizzard 1230-IV for the same price as a Vampire.

it is emulated not simulated if it was simulated then it better act 100% like a known 68k which it doesnt since this is this new 68080 whatever it is emulating 68k...

A simulator doesn't have to act 100% the same, it only has to look like it's (close enough to) the same. A simulated CPU is pure software, it isn't connected to any hardware so it doesn't have to emulate anything. In the old days an emulator was a piece of hardware which was inserted into a board in place of a chip. Now the same word is being to describe what are really simulators - but as with most categories there are gray areas.

The original Amiga custom chips were prototyped on wire-wrap boards with TTL logic gates, which made them an emulation of the final chipset. But custom chips haven't been designed that way for many years - now they are all done with HDL. First simulated in a computer to check that the design works properly, then downloaded into the configuration memory of an FPGA, or producing the mask for the final metalization layer of a gate array chip, or the masks for every layer of a custom chip or CPU. Is the final result software or hardware, an emulation or a real chip? If the hardware it's connected to can't tell the difference then the question is moot.

if it acts 100% as a 68k then it should have same instructions pipeline the same amount instructions per clock etc etc etc it doesnt

I was shocked to find out that the 68060 doesn't pipeline the same number of instructions per clock as a 68000, and only emulates some FPU instructions. Turns out that all the various 68k CPUs have differences that make them incompatible with each other - some programs that run fine on a 68000 even crash on a 68010!

Properly written software should work fine on any CPU ('real' or 'emulated') with a compatible instruction set, despite any extra instructions that might be present or how the pipeline works. Sometimes that means having patches or special code to handle different stack frames etc., but we already have to deal with that when moving from 68000 to 020 etc. Just yesterday I discovered that my assembler had 68020 turned on by default, so some of the programs I wrote crash on a 68000! But they all worked fine on my A600 because it has a Vampire in it.

[demolition]

Originally Posted by Bruce Abbott

The original Amiga custom chips were prototyped on wire-wrap boards with TTL logic gates, which made them an emulation of the final chipset. But custom chips haven't been designed that way for many years - now they are all done with HDL. First simulated in a computer to check that the design works properly, then downloaded into the configuration memory of an FPGA, or producing the mask for the final metalization layer of a gate array chip, or the masks for every layer of a custom chip or CPU. Is the final result software or hardware, an emulation or a real chip? If the hardware it's connected to can't tell the difference then the question is moot.

One could also argue that the Amiga Custom Chips are really emulations of the original wire-wrap boards.

But you are right that there is really no functional difference between an ASIC and an FPGA, other than the mask being programmable in the FPGA while it is hard-coded in the ASIC. The comparison of ASIC/FPGA towards CD/CD-R and ROM/EPROM is quite accurate. It is close to impossible to get the same compatibility if one would base it on a software emulation since the signals would have to traverse so many layers, both hardware and software, and all of them would add latency and jitter. Using a small FPGA for 'bus-handling' could help with some of the jitter, but it cannot do anything about the latency and if you want to interface with the buses in a real computer, then you need to comply with the timing requirements.

[Marlon_]

Originally Posted by nexus

no need to use a fpga and charge ridiculous prices

Can you present an alternative to FPGA that is viable and cost less?

[Daedalus]

I don't understand why some people find "emulation" such a dirty word. We're mostly accustomed to thinking of emulation as a software package that allows other software to think it's running on the real hardware, but that's just *software* emulation. Emulating anything is mimicking its behaviour with the intention of appearing as the original thing. Whether it's hardware, software or even just behaviourally. AGA machines emulate ECS machines in hardware for example, allowing ECS-specific software to run without realising it's running on an AGA machine. There are even options in the early Kickstart screen to select the emulation used. And 68k CPUs (along with most other series of CPUs) emulate certain features of earlier CPUs in the family for compatibility.

Hardware emulation is a thing too, for reasons including latency as pointed out above. It's also used in complex system development, where hardware emulators are often used in the place of processing or I/O boards that are unfinished, or for debugging the system as a whole, since they add features like freezing, stepping and memory examination.

As for the CD-R / CD-ROM point, well yes, the CD-R is actually emulating an original CD. It's not an original CD, it doesn't have the holes in a thin layer of aluminium to represent bits as the original CD specification lays out, and as the laser head in a CD reader is designed to read. Instead it mimics this physical arrangement using different coloured dye to approximate the same effect as the holes on laser light. As a result, the CD drive can read it, even though it's physically totally different to what the drive was originally intended to read. Same goes for an EPROM versus a mask ROM: The EPROM doesn't have the data permanently etched into it, it's stored in an entirely different manner. But it's presented to the host system in the same fashion so it can't tell the difference. That's emulation.

This analogy also falls down at another point: With a CD-R (or an EPROM), you're putting in data that can be a 1:1 copy of the original since the original is simply a data storage medium and can be read as such. It's not the case for FPGA CPU cores, where the original behaviour has to be reverse engineered and reimplemented, resulting in a core that is not 1:1 with the original, but a detailed approximation. It can be fine-tuned and adjusted with core updates to fix things like cycle-exact bus timings, FPU precision and what not that are closer to the original chips - in other words, creating a more accurate emulation.

[kolla]

I would prefer emulation for CPU and FPGA for chipset. That would mean CPU is mainstream and upgradable, and never bogged down when code is hitting the chipset.

[demolition]

Originally Posted by Daedalus

It's not the case for FPGA CPU cores, where the original behaviour has to be reverse engineered and reimplemented, resulting in a core that is not 1:1 with the original, but a detailed approximation.

Reverse engineering is the typical approach, but it is possible however, to make an almost perfect copy of an ASIC in an FPGA if you delid the ASIC and create VHDL code based on the layout of the original chip. The only real difference compared to the real thing here would be the propagation delays since the routing would have to be different as the gates cannot be relocated in an FPGA. Also, since the silicon process is different, the gates will act a little different in regards to delay, rise times etc. But for a pure digital logic chip like a CPU it could act like a ~100% copy of the original.

[kolla]

Originally Posted by Daedalus

resulting in a core that is not 1:1 with the original

What is the original? There are tons of different 68000 chips, different 68010 chips, different 68020 chips etc.

ASICs has the same problem as FPGA in this matter.

[Daedalus]

Originally Posted by kolla

What is the original? There are tons of different 68000 chips, different 68010 chips, different 68020 chips etc.

ASICs has the same problem as FPGA in this matter.

And, as I pointed out, later 68K chips emulate some of the functions of earlier 68K chips for compatibility. If the different versions of the same chip are using different implementations, then you could easily say that they're emulating the original of that type. But that's a design that's emulating a previous design, not hardware that takes on the behaviour of other hardware.

[Predseda]

Okay, in short - is there any sign that Vampire V4 for A1200 is coming?

[Marlon_]

Originally Posted by Predseda

Okay, in short - is there any sign that Vampire V4 for A1200 is coming?

All I can say is that a Vampire for 1200 is still under development and not abandoned.

[Predseda]

[Megol]

One can't really call FPGAs hardware - they are more of hardware emulators. They consist of lookup tables coupled with programmable routing.

And while even I have some aversion towards emulation instead of running on FPGA it's not logical, an emulator is technically an implementation of an architecture as much as a heap of lookup tables and configurable muxes. The differences are the trade offs.