[UserReview] Vampire V2-128 received and it's just pure p0rn.

[psxphill]

Natami missed a bit of blitter support, for example the line mode.

Which is ironic as the line mode was original suggested (IIRC) by r j Michael as it was a simple addition to the blitter engine. However it probably depends on where you start from, so if the Natami blitter didn't internally work exactly like the Amiga blitter then it may have been much harder to add. Plus just because something is simple in hardware, doesn't mean it's simple to figure it out in your head.

[psxphill]

I think people are forgetting *how* HAM modes could and were used in productivity software, because they are thinking of style-guide compliant software ie lots of menus, lots of windows all on a high res screen.

It's a pity that the OS wasn't designed to work around HAM issues.

The left hand side of menus and windows is fine, because the border would use an indexed colour. The problem is in the right hand side where there is no guarantee how many pixels it would take before the r,g & b would get reloaded. Which is why you would often see horizontal lines across ham images when a menu was up.

If the OS extended the right hand edge of the layers by three pixels then it could add extra pixels to get the colour back to where it would be if the menu wasn't there. You could minimize the extra fringing in some circumstances, by using the closest index colour to the pixel to the right of the upper layer.

Unfortunately HAM wasn't taken seriously when the OS was designed. It was left over from when the Amiga was a games machine that output YUV, when it flipped to a computer that output RGB then it wasn't expected to be useful. It was going to be removed, but after all the years juggling to fit the functionality in agnus and denise there wasn't time/money/motivation to go through that again & then they would have spare space to add new functionality which would also have taken time.

It's pretty standard for commodore to build hardware that the software doesn't support.

[psxphill]

RAM performance only affects stuff that is not cached. Typical Amiga benchmark programs fit entirely into the cache so you don't see much effect of the RAM performance.

I would hope that busspeedtest would be doing enough to avoid being affected by the data cache. Setpatch hasn't been loaded, so it shouldn't even be active.

As Apollo is super scalar then how fast it runs depends on the program you are running, it's entirely possible that it can run busspeedtest faster than real world programs. I've not looked at whether instructions take a variable number of clocks, but that could also favour one program over another.

Comparing benchmarks between different cpus is often a pointless exercise. The only thing you can take away from it is the speed the benchmark runs at, it would be a mistake to infer any other performance characteristics.

[psxphill]

Pretty strong compared to an 68060 that could execute two instructions in one cycle only if they fit into four bytes.

Yeah, so you can't take how fast one program runs compared to a 68060 and infer how fast another program will run.

A performance analyser that can show you how full the instruction pipelines are and how much time is spent waiting for memory accesses would be awesome.

[psxphill]

Listening to the podcast, BigGun seemed inclined to prefer AOS if it could be developed more freely, I guess opensource, but capitulates more or less to the realisation that this will most likely never happen.

Enter AROS.

The only downside I can see with this is that they have been pretty clear that they aren't too bothered with 100% compatibility (especially MMU) and using AROS rather than AOS will make that easier.

If they committed to 68060 MMU compatibility then I would be less cynical. I find it morally annoying that Apollo is and never will be opensource, so nobody else can make it compatible either and making it incompatible is made easier by the work put into AROS for free. I suppose one day someone will reverse engineer their FPGA bitstream and fix it.

[psxphill]

You mean SATA III, so we can use SSDs with 550MB read/write capabilities.
Yeah, no Amiga should use anything less that that.

I'd rather see m.2 slots that support SATA and PCIe, otherwise you're limited to budget SSD's.

[psxphill]

I was wondering about the HDMI out on the Vampire v2. If a person in the US slaps a vampire on a PAL A600, does that circumvent any PAL/NTSC issues?
 
 Or in other words, is all HDMI the same?  Would there still be any need to do the dual mouse button press to switch to NTSC?

If you have a PAL A600 but want to run in 60hz mode then you'll still need to use the boot menu.

Depending on what you mean by "is all HDMI the same" you could either answer yes or no.

[psxphill]

If you consider using FPGA emulation, why are you even bothering with this thread?

It is essentially https://en.wikipedia.org/wiki/In-circuit_emulation, although traditionally ICE is slower while Vampire is faster.

Even though it's emulation, it's still cool.

[psxphill]

In circuit emulation usually involves a microcontroller rather than an FPGA.

Maybe before FPGA's were available.

Google throws up a lot of results for: in circuit emulation FPGA

https://books.google.co.uk/books?id=Hay1AAAAIAAJ&pg=PA62&lpg=PA62&dq=in+circuit+emulation+using+fpga&source=bl&ots=vRsodFxXzB&sig=Q0OaeukqJfoXVty2HwxGNW-Hykw&hl=en&sa=X&ved=0ahUKEwju1rrm8NDSAhVNOMAKHXTcCtY4ChDoAQgfMAA#v=onepage&q=in%20circuit%20emulation%20using%20fpga&f=false

https://www.aldec.com/en/solutions/hardware_emulation_solutions/co-emulation

What? No. Nothing like that.

Yes, everything like that.

please, not another discussion if fpga is emulation or not!

It's not a discussion, it is emulation. It's really unhelpful that people use the "I don't like emulation, I like FPGA's, therefore FPGA's aren't emulation" logic.

[psxphill]

So, is all use of FPGA emulation?
Does something have to exist to be emulated?
Do you consider Indivision ECS an emulator?
Do you consider C64 DTV an emulator?
Do you consider Akiko an emulator?

Where do you draw the line - when is something no longer emulation?

You can build an emulator before you build the thing you're emulating.
Indivision ECS uses a real denise, so it's not emulation.
DTV emulates a C64.
Akiko emulates two CIAs.

Old dot matrix printers can emulate Epson and IBM dot matrix printers.
Old PC graphic cards could emulate CGA/EGA/Hercules graphics cards.
Soundcards emulate soundblaster.

There are grey areas, but emulating a CPU isn't one of them.

[psxphill]

Then everything is emulation.

Only in a world of logical fallacy and trolling.

[psxphill]

The Paula chip is emulating bits of the original Lorraine prototype then.

It would be more industry practice to say the bread boards emulated the chips.

Emulation is primary about translation and imitating behaviour. Ask Toni Wilen about how UEA works and how it is different than using FPGA.

It's nothing to do with translation, it's only to do with imitating behaviour.

You're assuming that I don't know how emulators written for CPU's work and how emulators written for FPGA's work. I completely understand the difference between them, but they are still emulators.

CPU's are programmable, so are FPGA's. If the programs are both imitating behaviour then how are they not both emulators?

[psxphill]

Not at all. But I have yet to see emulation work as well as current FPGA options do.

If you ignore latency then UAE works as well as any real Amiga or FPGA emulation.

So how do one distinguish between using FPGA and using UAE? You can see on this very thread how people are confusing the two, and it is even worse "out there" among more normal people.

You distinguish between then by the actual difference. If you need consistent timing and low latency then use real hardware or an FPGA, if you don't then UAE is just as good.

But I like it how people fill pages full of text discussing the meaning of a word; especially given that meaning of language is non-deterministic anyway, depending on context and evolves over time.

Which is why we don't need people trying to twist the words meaning for their own agenda by applying negative connotations to it. We may as well start referring to UAE as a Nazi.

[psxphill]

leaving out evident issue of 68k software emu on x86 host, amithlon didnt provide amiga chipset functionalities. i bet this will make a noticeable difference.

Being able to skip emulating different areas of memory and switching between emulating cpu/blitter/copper etc will make a huge difference.

Ditching the OS and letting all the memory accesses through to the hardware would require a bit of work, but you may be able to use the amiga pci drivers.

That would be the ultimate, something bootable that allows you to enable different JIT emulators 68k/ppc/arm etc that can then boot different OS.

[psxphill]

The difference was just where "the software runs". For the 68882, it runs as microcode in the ROM of the chip. For the 68040, it is 68K code in the 68040.library.

Only some of it is 68k in the 68040.library, some of it is implemented in hardware. Less of it is implemented in hardware on the 68060, I'd settle for vampire being compatible with the 68060. I'd like to be able to switch to 68040 though because there are times when you can't run any emulation software.

The 080 fpu is the first ever 68k fpu in an (amiga targeted) fpga.

It's a software emulated fpu. Those have existed for years.

So, my thoughts were based on an assumption that a full 882 implementation is a lot of work and would use up a lot of gates that could be used for other stuff and the fact that most people that really needed FPU had migrated to 040 and 060 based machines and recompiled binaries that no longer used unimplemented FPU operations.

If that's not correct, then great, 882 me up.

Eagerly awaiting an A1200 version!

Your assumption is wrong.

The 040 & 060 cpu can still run some of the 68882 instructions & emulates some of them, while vampire can run none of them and emulates all of them. If vampire could run all 060 or 040 instructions without emulation then this discussion wouldn't exist.