Vampire discourse, keep it civil (was: Vampire 1200 V2 waiting times)

[kamelito]

Originally Posted by Thomas Richter

Concerning "The Enforcer" on Vampire, may I add the following (from http://www.sinz.org/Michael.Sinz/Enforcer/index.html):


This is Mike's expressed will concerning the Enforcer. Did actually anyone from the Vampire team attempt to contact Mike on that and paid the fee for the source code, if I may ask?

MuForce is heavily based on Enforcer source code and I find quite odd that you don’t provide the source code of it in the archive…

[Thomas Richter]

MuForce is Enforcer, and it is published with agreement with its original author. Since Mike wants to sell the enforcer sources, I see no reason to provide sources for my modifications either. At least, it would require another agreement with Mike. You find, however, the sources of many other MuTools in the MuManual archive in Aminet.

[hammer]

Originally Posted by Bruce Abbott

Of Course. Would have been stupid to choose a CPU that wasn't.

It was special enough to have been chosen for the IBM System 9000, Tandy 6000, Sage IV (which was used to develop AmigaDOS), Sun 1, Corvus Concept, Silicon Graphics IRIS 1000 and 1200, Apple Lisa and Macintosh, Atari ST, Sharp XC68000, HP Laserjet printers, many arcade machines and the Sega Megadrive/Genesis.

Again, 68000 in the Amiga wasn't special since 68000 CPU was used in many other systems.

Originally Posted by Bruce Abbott

I wouldn't say 'almost useless', but certainly no match for a modern PC.

My unsupported Google Pixel 2 with Qualcomm MSM8998 Snapdragon 835 (with Adreno 540 iGPU)'s Genshin Impact test smashed Pi 4 CM's results.

Originally Posted by Bruce Abbott

You may be right. I don't follow the modern PC gaming scene (lost interest after the huge disappointment of Crystal Dynamics' attempts to 'modernize' Tomb Raider).

There are other "hot" fictional women main character games besides Tomb Raider.

Lara Croft's near rails game design is dated when multi-billion dollar revenue Genshin impact follows Zelda's Breath of the Wild's Open World with story game design.

Originally Posted by Bruce Abbott

The C64 was the biggest selling home computer of all time, and the C128 wasn't far behind

C64 is not the best-selling desktop microcomputer when the PC is included in the debate.

C64 was a zombie platform when PC Wing Commander (1990) and PC Doom (1993) arrived on the scene.

Originally Posted by Bruce Abbott

(the C65 - had they produced it - would have extended that line even further).

C65 is pointless since extended graphics modes are planar-based. C65's R&D effort should be on Amiga's ECS.

C65's CSG 4510 R3 @ 3.54 MHz is uncompetitive and it lacks 386's 32-bit evolution.
65CE02 was the basis for the system on a chip CSG 4510.
CSG 4510 includes a custom MMU for 1MB RAM support. LOL. July 1979's Intel 8086 has 1 MB RAM support.

Originally Posted by Bruce Abbott

The 6502 was also used in the famous Apple II, BBC Micro, and Atari 8 bit computers.

Apple II was replaced by the 68000-based Macintosh. Apple III is a failure.
Apple replaced the uncompetitive CSG/MOS 65xx CPU road map with a 68K CPU road map.

BBC Micro was replaced by ARM-based Archimedes. Acorn replaced the uncompetitive CSG/MOS 65xx CPU road map with RISC-based ARM. ARM evolved into a modern 64-bit CPU.

Atari 8-bits was replaced by ex-Commodore CEO's 68000-based Atari ST.
Atari replaced the uncompetitive CSG/MOS 65xx CPU road map with a 68K CPU road map.

Atari 8-bit's designer, Jay Miner led a team and designed Amiga's custom chips and selected 68000. Jay Miner's Amiga Corporation replaced the uncompetitive CSG/MOS 65xx CPU road map with a 68K CPU road map.

Western Design Center is a tiny company when compared to Intel, AMD, VIA, and ARM.
CSG/MOS is bankrupt.

Originally Posted by Bruce Abbott

Commodore licensed the design to other manufacturers, allowing variants to be developed for the Atari 2600, NES, Atari Lynx, and PC Engine. Not a bad roadmap!

Atari 8-bit's designer, Jay Miner led a team and designed Amiga's custom chips and selected 68000. Jay Miner's Amiga Corporation replaced the uncompetitive CSG/MOS 65xx CPU road map with a 68K CPU road map.

Atari Lynx's WDC 8-bit 65SC02 (3.6 Mhz average) wasn't a high-performance desktop CPU. Atari Lynx is a dead-end platform.


NEC TurboGrafx-16 PC Engine's HuC6280 is an upgraded CMOS version of the popular NMOS-based MOS Technology 6502 8-bit CPU. HuC6280 wasn't a high-performance desktop CPU. December 1989, PC Engine SuperGrafx's HuC6280A has a 21-bit external address bus. HuC6280A's extensions are incompatible with CSG 4510's extensions. TurboGrafx-16 PC Engine is a dead-end platform. PC-FX's 32-bit CPU comes from a 32-bit V-810 RISC CPU along with the HU 62 series CPU. PC-FX was a product failure and a dead-end platform.


68HC000 is the CMOS update for 68000. HuC6280 is a dead-end CPU design since it wasn't expanded into 32 bits like Intel 80386.
For Japan Inc, the SuperH RISC CPU family replaced CSG/MOS/WDC 65xx CPU designs.

For the embedded markets, ARM and RISC V have displaced CSG/MOS/WDC 65xx CPU and Japan Inc's SuperH CPU designs.

Originally Posted by Bruce Abbott

The 80386DX was supposed to debut at 16MHz, but was unreliable at that speed and so was downgraded to 12.5MHz. The companion 387 FPU wasn't produced until 2 years later, so early 386 computers had to use the 80287 which was slower. The first PC to use the 80386 was the Compaq Deskpro 386, which was announced in September 1986. A system with 1MB RAM, 40MB hard drive and EGA graphics cost the equivalent of US$18000 today. It had a socket for an 80287 running at a miserable 8 MHz.

The 80386 was introduced as pre-production samples for software development workstations in October 1985. Manufacturing of the 386 in significant quantities commenced in June 1986 along with the first plug-in device that allowed existing 80286-based computers to be upgraded to the 386, the Translator 386 by American Computer and Peripherals. In September 1986, the Compaq Deskpro 386 was announced.

Introduction timeline for 80386 with 32-bit external bus
80386-12, 12 Mhz, October 17, 1985
80386-16, 16 MHz, December 1985
80386-20, 20 MHz, February 16, 1987
80386DX-25, 25 MHz, April 4, 1988

Introduction timeline for 80386SX with 16-bit external bus
80386SX-16, 16 Mhz, June 16, 1988

1990 Wing Commander and 1993 Doom did NOT use x87 FPU. Your FPU argument is a red herring.

Where's the 32-bit 65xxx road map?
Where's the 65xxx FPU road map?

Intel 80286 has MMU for Xenix (licensed Unix). Where's CSG/MOS's MMU R&D road map?

Again, my argument is about the R&D road map.

For the PC, Intel wasn't the only manufacturer for FPU.

March 1987, ATi EGA Wonder has $399 USD cost or $1,007 in today's money.
In the Steam survey for July 2022,
NVIDIA's GeForce RTX 3090 outnumbered the lower-cost AMD RX 6600 XT or RX 6700 XT.
NVIDIA's GeForce RTX 3080 Ti outnumbered the lower-cost AMD RX 6600 XT or RX 6700 XT.

https://pcpartpicker.com/products/vi...520&sort=price
US's price range for GA102-based RTX 3080 10 GB to RTX 3090 Ti 24 GB

PS, I owned MSI Gaming X RTX 3080 Ti.

There's a reason why IBM has exited the PC graphics card business.

Originally Posted by Bruce Abbott

WDC released the 65C02 in 1981, so what took them so long to produce a 16 bit version? Doesn't matter, the truth is that bolting 16 bit stuff onto an aging 8 bit design generally doesn't work well (Intel's 8088 was the exception, and it was only successful because IBM chose it for their toy desktop computer). The 65C816 didn't languish just due to being late to the party.

65C816 lacks 386's 32-bit and X86-64 evolution. 65xx/65xxx's R&D road map for high-performance desktop CPU is inferior when compared to Motorola's 68K and Intel's X86.

The Intel 8088 microprocessor is a variant of the Intel 8086. Intel 8088 has an eight-bit external data bus instead of the 16-bit bus of the 8086.
The first Compaq Deskpro (1984) used an 8086 running at 8Mhz and a 16-bit external bus. 8088 is software compatible with 8086.

PC clones timeline
In 1982, Eagle PC / 1600 series has 8086 @ 4.77 MHz with 16 bit bus.
In 1983, Olivetti M24/AT&T 6300 has 8086 @ 8 MHz while Tandy 2000 has 80186 @ 8 Mhz with 16 bit bus.
The Phoenix BIOS in 1984, however, and similar products such as AMI BIOS, permitted computer makers to legally build essentially 100%-compatible clones without having to reverse-engineer the PC BIOS themselves.

Any PC with 80286 CPU and sufficient RAM can run Microsoft Xenix (licensed Unix). 80286 was released in 1982.

The arrival of the clones and Compaq in particular signaled the end of IBM's short-lived dominance in the market. The driving forces would from now on be companies that powered both the PC and its imitators, Intel and Microsoft.

Originally Posted by Bruce Abbott

PC fans were desperate to make the PC the solution to any problem, including running 'unix'. I don't know if it was the best selling 'unix', but even if it was the impact was negligible. It was discontinued in 1989. Most PC users of the day never saw or used it.

Microsoft chairman Bill Gates said at Unix Expo in 1996 that, for a long time, Microsoft had the highest-volume AT&T Unix license.

IBM's and Microsoft's original plan was to use OS/2 to replace Xenix, but the divorce led to Microsoft's Windows NT replacing Xenix.

MS-DOS 2.x was modeled after Xenix i.e. then new API was modeled on the Unix/Xenix file I/O API, these new API calls were called "XENIX calls."
This was a time when MS thought UNIX is the future.

XENIX used a forward slash as a separator, but versions 1.x of MS-DOS, borrowing from the tradition of DEC operating systems, already used the forward slash for switches in the command line, so Microsoft, at IBM's request, decided to use the backslash as the separator instead.
To summarize:

With bigger disks, hierarchical organization of files has become necessary and MS chose the directory tree used by XENIX.

The MS-DOS 1.x FCB APIs could not deal with directories, so they added new APIs which operated on file paths (instead of just name.ext) and returned handles, again apparently inspired by XENIX.

At IBM's request, version 2.0 of MS-DOS also possessed the undocumented ability to perform rudimentary background processing--an interim solution to a growing awareness of the potential of multitasking. To properly support the print spooler, the free-for-all memory management of DOS 1.x ("all memory after the load address belongs to the user program") was no longer usable and DOS needed a way to track which memory area was used by which program. Apparently, the memory management code was also borrowed from/inspired by XENIX.

Originally Posted by Bruce Abbott

Accelerator cards are not a 'platform' so this challenge makes no sense. But the technology of 4VSA is used in V4 Vampire cards, so it supports the classic Amiga platform. Warp 560, Pi Storm etc. are simply different accelerator cards that have the same or lesser functionality.

The hardware platform is Amiga 500, NOT the accelerator cards. Try again.

The Amiga 500/1200 serves as a hardware platform for accelerator cards that follows Amiga 500's/1200's software and hardware interface requirements.

Originally Posted by Bruce Abbott

I know very little about Warp 560/1260 and Google didn't help much

Warp 560/1260 are 68060 accelerator cards that follow Amiga 500's/1200's software and hardware interface requirements.

Warp 1260 is functionally similar to TF1260, but with additional RTG support.
CS Labs' website from http://www.amigawarp.eu/

Originally Posted by Bruce Abbott

Well you see, when you already have one accelerator card in an Amiga, you don't generally feel the need to jam another one in alongside it...

Preconfigured PiStorm /Pi 3a/emu68/32 GB MicroSD for about $100 USD from Poland is not expensive.

Originally Posted by Bruce Abbott

The supply of A500's isn't infinite, and I have noticed prices are starting to climb. Already Agnus chips are reaching silly prices, and people are selling stripped (possibly faulty) motherboards for more than a complete A500 sold for a few months ago. Eventually - if the Amiga remains popular enough - we will need to move to a design using all FPGA/CPLD/asic chips.

Minimig v1.81 FPGA cloned Amiga 500's ability to accept 3rd party Amiga 500 (68000 socket) accelerator cards, hence Minimig v1.81 can evolve with Amiga 500's accelerator cards.

I rather see Vampire V4 SA with an A1200 expansion edge connector (e.g. AP-C1200) for incoming PiStorm32/Pi 4 CM/Emu68 or stay with the built-in AC68080 V4 or use 68030/68040/68060 (with Motorola 68K MMU) accelerator cards or TF1200 Buffee or any other legacy Bizzard 060/PPC accelerator cards.

[Bruce Abbott]

Originally Posted by kamelito

MuForce is heavily based on Enforcer source code and I find quite odd that you don't provide the source code of it in the archive?

Enforcer source code is on Github. I downloaded it into my A1200 with IBrowse today. Sadly that was the last thing I was able to do on the net today, as my wireless (including phone!) was out for the whole day. Hope it works long enough to post this message!

[Gorf]

Originally Posted by Thomas Richter

MuForce is Enforcer, and it is published with agreement with its original author. Since Mike wants to sell the enforcer sources,

Not any more - he published the sources on Github himself under Apache License 2.0
https://github.com/MichaelSinz/AmigaEnforcer

I see no reason to provide sources for my modifications either.

Apache License does not force you to publish your changes of course, but now I guess I would be very much in line with the original author to make the source public, wouldn't it?

[Gorf]

Originally Posted by hammer

... replaced the uncompetitive CSG/MOS 65xx CPU road map with

There never was such a road map. CGS/MOS never promised any further development or significant improvement of the 65xx CPU line.
All changes they eventually did (65CE02, 4510) were meant for in-house products.

[grond]

Originally Posted by Gorf

There never was such a road map. CGS/MOS never promised any further development or significant improvement of the 65xx CPU line.
All changes they eventually did (65CE02, 4510) were meant for in-house products.

Remind me, what else apart from MOS/Commodore mismanagement and lack of vision kept the 65xx-CPUs and possible decendents from being chosen for the IBM-AT?

[Gorf]

Originally Posted by grond

Remind me, what else apart from MOS/Commodore mismanagement and lack of vision kept the 65xx-CPUs and possible decendents from being chosen for the IBM-AT?

You mean IBM-PC instead of IBM-AT, I assume. The AT came later and had to be compatible with the original IBM-PC, so a 65xx-CPU was out of question for the AT, if not the PC would have had such a CPU in the first place.

There were much more powerful CPUs available on the market, even before the 6502 was born (Intel 8080 in 1974).
The 6802 was designed as low-end part from the very beginning.

By the time IBM designed their "PC" there were a bunch suitable microprocessors available including IBM's own 801.
But since the team was fixated on "of the shelf" parts, the 801 was excluded from that list ...

(IBM later tried to walk this decision back with the IBM RT PC in 1986, which used the ROMP-CPU a direct descendent of the 801, but by then it was too late: the clones were taking over the market)

So for the original PC IBM had to chose between 6502, 68000, 8080, Z80 or 8086 ...
Motorola's chip was still too high-end and too expensive in 1981, the 6502 too low end ...

And it soon was clear, that the operating system would be something in the line of CP/M or a derivate of it ... so 8080 and Z80 would have been good candidates. The 8086 line's instruction set was close, so software would be easy to port, and it promised 16bit, even if IBM did choose the variant with an 8-bit bus (8088) for their first PC.

Would a 16-bit 6502 in 1980 have changed the course of history?
Maybe ... but the lack of CP/M and business software support for the 6502 was probably still the major factor.
(See the popular z80 card for the Apple II)

Was it Commodores fault?
MOS went almost bankrupt before C= stepped in ... Bill Mensch had already left before C= took over and C= bought MOS to have a steady supply of calculator chips, since calculators and typewriters was Commodores business back then...

[grond]

Yes, IBM-PC, of course.

[Promilus]

@Gorf - 16bit 6502 would not change the course of history (although it would most likely dominate home computers). 8051, Z80 - both had 16bit versions (Z80 also 32bit iirc) and it's only success was embedded applications (8051 - shouldn't be surprising, Z80 hitachi style - well that one did much better than "desktop" version from Zilog).

MOS went almost bankrupt before C= stepped in

Actually Commodore at that time wasn't in much better shape and "takeover" was done in similar fashion AMD "acquired" Xilinx. By buying off their shares with the shares of AMD.

65C816 was fair processor and something like that made by MOS might have been popular. Popular enough to dominate 16bit market, yes. Same goes with Z80 should they've made Z800 right.

[Gorf]

Originally Posted by Promilus

@Gorf - 16bit 6502 would not change the course of history (although it would most likely dominate home computers). 8051, Z80 - both had 16bit versions (Z80 also 32bit iirc) and it's only success was embedded applications (8051 - shouldn't be surprising, Z80 hitachi style - well that one did much better than "desktop" version from Zilog).

not by 1980
they all came too late

Actually Commodore at that time wasn't in much better shape and "takeover" was done in similar fashion AMD "acquired" Xilinx. By buying off their shares with the shares of AMD.

True
And Gould had to put in some more money once again...

I usually like to criticize Commodore for its bad business decisions, but here I have to admit, they did almost everything right. The step allowed them to run the calculator business a little bit longer and the KIM-I opened the door to the microcomputer business.
And while neither Tramiel or Gould were "computer guys", they listened to Chuck Peddle and invested in a totally new branch of business ...

It is very understandable in this situation, that Commodore did not have money for further CPU designs or R&D, nor was it clear at this point that this new adventure would work out at all...

So while Commodore clearly missed a lot of opportunities later on - in the early phase of their computers they made very little mistakes. At least nothing too obvious at the time.

Except maybe not getting fresh money by selling shares ... for some strange reason Commodore left the stock exchange shortly after the announcement of the PET for some months ... after the course jumpt up...
Probably some shenanigans by Irvin Gould....

65C816 was fair processor and something like that made by MOS might have been popular. Popular enough to dominate 16bit market, yes. Same goes with Z80 should they've made Z800 right.

again ... only if it would have been ready much earlier.

[nonarkitten]

Originally Posted by grelbfarlk

ARM is weak, the ARM core on the DE10 Nano was so slow compared to the Vampire core that they decided making an adaptor for it would actually slow the Vampire Core down too much. Also for the same reason adding a PowerPC to the Vampire would make it like a Vampire just sloshed in garlic and silver, it'd lurch around like a zombie because of the inferior CPU architectures slowing down the awesome power of a homebrew 68EC060 running at double the MHz of a full 68060.

- the Vampire has no relation to the DE10
- the Vampire doesn't have an ARM cpu on it
- each Cortex A9 is about 13 times as fast as the AC68080
- Vampire compares to about an 80MHz PowerPC 601

[nonarkitten]

Originally Posted by Thomas Richter

Quite frankly, if somebody would develop that, it would be not much more than a "proof of concept", but it would still not be usable for my daily work. Thus, it would not serve a practical purpose.

http://www.frogfind.com
http://68k.news

Not useful enough for say banking, but handles a pretty reasonable chunk of the internet right down to an Apple ][e. Creating a secure TLS proxy isn't impossible, but you'd need to REALLY trust the proxy.

Details of it's creation and running on everything down to a literal Apple ][e.
[ Show youtube player ]

[nonarkitten]

Originally Posted by grond

As you know (but not state) these 10% for GNGEO come from the fact that an emulator does lots of things and pixel-manipulation is just a small part of it. Thus, 10% overall gain is huge and not easily obtainable otherwise unless you can increase clock speed. The relevant AMMX function probably ran many times faster than the C generated code but if that code just consumes 11% of the overall CPU time, that's the most you can get by optimising it.

Since you are technically quite competent, I must qualify this statement as deliberate misinformation. You know quite well that bitfield instructions aren't superscalar in any 68k processor, that the 060 is the only superscalar 68k processor before the 080 and only executes two short integer instructions concurrently (under certain conditions) and that the cycle count for bitfield instructions is horrible on 020 through 060. Furthermore, even using the much stronger superscalarity of the 080, you can't saturate the 080's memory bus using only "classic" 68k integer instructions, you can only do that using AMMX.

First of all, I'm comparing bitfields on 68080 versus AMMX on 68080. Comparing AMMX on 68080 versus bitfields on a 68020 would be stupid, agreed? Bitfield instructions were pipelined from the 040 onward though and only take one cycle from then-on. So it would be fair to compare this against the 040 or 060 as well.

Many times? No. The 10% was in reference to just the rendering times.

V4 x12
27fps ammx, no-fm, 24007/1802/14225/5536
26fps no-ammx, no-fm, 26489/2319/14415/5602
20fps ammx, fm, 34289/14204/17981/6907
20fps no-ammx, no-fm, 35949/15195/18135/7005

Those four numbers are the time for the video, audio, 68k and z80, respectively. I don't remember their units, this is three years ago now. Anyway, with a fixed frame-skip of 1 and a slight 68K CPU under clock we hit 50+ fps. It's surprising how few games maxed out the 68K.

In m68k code, draw_fix_char_m68k takes about 1 to 2 cycles per pixel plus 2 loop overhead, or about 80 to 144 cycles (depending on transparency) for the whole character assuming it's cache-perfect. This is the code for one pixel. It interleaves the pixel fetch to ensure there's no pipeline stalls, so dx and dy are swapped on odd/even pixels. This is what the compiler outputs:

        bfextu d0{#12:#4},d2
        tst.b d3
        jeq .nextPixel
        move.w (a0,d3.l*2),(6,a1,d1.l)
.nextPixel

You can see the whole function here: http://franke.ms/cex/z/86T7rx

Memory overhead wise we have one 32-bit read per eight pixels, one 16-bit read from the CLUT and possibly one 16-bit write to screen depending on transparency, both per pixel. That's 1280 to 2304 bits to-from RAM.

In AMMX code, there's 32 cycles to load the palette, 6 cycles per 8 pixels, or about 80 cycles for the whole character assuming it's cache-perfect.

However, the way the "alpha" operation works, it always has to read the pixel data in. There's hidden extra work on the memory bus with AMMX. This means each cell needs the palette read, 32-bit read per eight pixels, 128-bit to read the line and 128-bit to write the line. That's 2560 bits all the time.

So the AMMX code is slightly faster instruction wise and slightly less efficient with memory.

Where AMMX does gain a bit more of an upper hand is with sprite scaling. This adds a little bit more work per pixel on both, but on AMMX, it's basically just a single VPERM per line (or ~88 total?) while the 68K needs two more opcodes per pixel, or one whole extra cycle (or ~144 to 208 total?). This only applies to the sprites being scaled and even games that use this effect, it's never on every sprite on-screen.

Combined with the fact that memory bandwidth is much less of a hit than the instructions-per-second, that's where hand-written AMMX assembly get's it's 10% boost from over naive m68k code compiled from C.

[nonarkitten]

Originally Posted by grond

And how are those not incompatible vendor lockin?

Because they were made BY Motorola?

Originally Posted by grond

Oh yes, somebody else could use the same processors. That doesn't make much of a difference in my view, though.

Yes. To you.

Originally Posted by grond

Programs relying on those processors being present still wouldn't be downward compatible. This very specific hardware configuration wouldn't be any more attractive to developers (games or demos) than the Vampires are.

Well except for two things.

1. These were established decades before the Apollo core and already had existing code on which to build. The Amiga Delphina (sp?). The Atari Falcon. The NEXT.

2. The DSP56K is way more powerful than AMMX. AMMX robs the 68080 of performance (i.e., you have to hope that the slot for AMMX is more efficient than the slot for a 68K instruction), the DSP56k only adds to it. So if the DSP56K adds 16MIPS, that's 16MIPS more than the system had before; there's no "stealing" a pipeline slot from the 68K. And a modern DSP56K runs up to 250MHz with dual cores for a supplemental 500 MIPS -- more than three times that of the Apollo core alone.
https://www.nxp.com/products/process...y-dsp:DSP56724

Yes, like everything they're sold out everywhere right now, but when they were around, they were $10-$20 a chip.

And sure, an AC68080 can brute force better than the Atari Quake demo, but this was a 68030 and 68882 at its base, the DSP56K was doing all the heavy lifting here.
[ Show youtube player ]

[Gorf]

Originally Posted by nonarkitten

However, the way the "alpha" operation works, it always has to read the pixel data in. There's hidden extra work on the memory bus with AMMX. .....

Hi!
This strikes me as most of these operations should rather be Blitter-Operations instead of CPU-Operations or in the case of alpha-blending of real sprites even at a later stage (Lisa/Denise)...
At least if we talk about a spiritual successor of the Amiga...
What do you think?

[nonarkitten]

Originally Posted by Gorf

Hi!
This strikes me as most of these operations should rather be Blitter-Operations instead of CPU-Operations or in the case of alpha-blending of real sprites even at a later stage (Lisa/Denise)...
At least if we talk about a spiritual successor of the Amiga...
What do you think?

At the time of my departure, the Blitter on Vampire was still implemented as a custom CPU interrupt not a real device on the FPGA. I think that may have changed, but I can't trust anything Gunnar claims anymore. I guess someone could test: do an FPU bench, then do an FPU bench while the Blitter is maxed out doing something.

Aside from that, handling NEOGEO's sprite engine is so unique that I would consider it an unnecessary optimization to the Blitter to support something like this. Besides, you're better off omitting a layer of inception and just running NEOGEO directly on FPGA.

[Gorf]

Originally Posted by nonarkitten

At the time of my departure, the Blitter on Vampire was still implemented as a custom CPU interrupt not a real device on the FPGA. I think that may have changed, but I can't trust anything Gunnar claims anymore. I guess someone could test: do an FPU bench, then do an FPU bench while the Blitter is maxed out doing something.

Aside from that, handling NEOGEO's sprite engine is so unique that I would consider it an unnecessary optimization to the Blitter to support something like this. Besides, you're better off omitting a layer of inception and just running NEOGEO directly on FPGA.

Well ... then you got a dedicated NEOGEO machine.
Nothing wrong with that, but it has nothing to do with Amiga (and that's why we are here, no?)

But besides that: I was talking more generally about the "AMMX" instructions ... you mentioned these operations would better be placed in an DSP-unit ... and I think you are probably right.*

I would go one step further and add some DSP capabilities to the Blitter.

*)
one valid counter argument to a dedicated DSP unit is the diminished multitasking capability of such a unit... on AmigaOS a certain task would have to be granted access to a DSP-device much like as to a channel of Paula....

[nonarkitten]

Originally Posted by Gorf

Well ... then you got a dedicated NEOGEO machine.
Nothing wrong with that, but it has nothing to do with Amiga (and that's why we are here, no?)

But besides that: I was talking more generally about the "AMMX" instructions ... you mentioned these operations would better be placed in an DSP-unit ... and I think you are probably right.*

I would go one step further and add some DSP capabilities to the Blitter.

*)
one valid counter argument to a dedicated DSP unit is the diminished multitasking capability of such a unit... on AmigaOS a certain task would have to be granted access to a DSP-device much like as to a channel of Paula....

You could actually view a DSP as being very Blitter-like in that it's an all-or nothing, stream-based co-processor dedicated to a functional subset. There are two cores on the newer DSP56K's so I suppose you could reserve one, both or neither. Since there's not a LOT that would need use of the DSP in parallel, that should be okay. Just as processes hog the Blitter from other processes, same to would be the issue with the DSP.

However, unlike AMMX, there's no need to hack AmigaOS to support the extended registers either.

But a DSP enabled Blitter, that's kind of interesting. That would almost be GPU-like but just for 2D. As fascinating as that is though, any feature set that was not found on the original Amiga *in some way* is just further narrowing an already small niche.

[Gorf]

Originally Posted by nonarkitten

But a DSP enabled Blitter, that's kind of interesting. That would almost be GPU-like but just for 2D.

Exactly ... well it probably could even do some gouraud shading, which would be useful in 3D.

As fascinating as that is though, any feature set that was not found on the original Amiga *in some way* is just further narrowing an already small niche.

Well in that case we have to drop the DSP56K for the AT&T DSP3210, which was at least in a A3000 prototype ...

https://amitopia.com/updated-dsp-321...a-3000-is-out/