@kas1e

There will still need to be an emulation layer over the top of the shader for the CIA timers and Paula and so on. That shouldn't need to be in the library though.

A full thick emulation layer could still use the shader routine to boost the speed of the graphics emulation. The planar to chunky conversions would still need to take place in the thick emulator application, for example, so incorporating CIAgent and Nalle Puh or something similar shouldn't kill the performance.

I think the important thing is to keep the emulation thin by mapping old functionality into the modern equivalents as closely as possible.

@retro

I decided to go with Power2People.org since AmigaBounty is OS4 only and doesn't require that the code be released as open-source. AROS has Gallium3D drivers working right now and once OS4 gets the Gallium drivers it should be easy to port from there to here. If nobody accepts the bounty right away, then writing both versions in parallel should be possible.

BTW, the Radeon 7000 chips in a MicroA1 won't be able to run shader programs. They use what's called a "fixed-function pipeline" that works differently. It'll need thick emulation on the MicroA1 or else use the hack to allow a graphics card to plug into the PCI slot.

Easier? Maybe, but it would also be DEAD SLOW. E-UAE does thick emulation. Thin emulation would be executable by the shaders in the graphics card and would run much faster since it would leave the CPU alone for executing the actual code and the JIT besides.

On the SAM 440 series, the graphics cards or on-board chips are fast but the CPU is not very fast by today's standards. The SAM 460 fixes the CPU speed problem partially but still has underutilized graphics capabilities on its graphics card. Only an AmigaOne X1000 would have the brute force to make thick emulation work.

Thick emulation works well on MicroA1-c machines because the Radeon 7000 chips have no shader capabilities. On modern graphics cards, the chips can be programmed to run simple programs on each pixel displayed so that some Copper-style capabilities can be regained by the system.

For example, Total Chaos AGA runs dog slow on my Intel Mac running E-UAE even though the JIT is active. The reason for this is that the chipset emulation is much slower than the processor emulation. I suspect P-UAE would be more compatible but still slow. I want chipset emulation on NextGen Amigas to be uniquely capable of emulation of Classic capabilities that even WinUAE struggles with. Of course DirectX is more able than OpenGL in this regard so I want to close the gap.

@DAX

Preferably as a shared library so that software could run from a common source code with people writing software for Classic Amiga. EUAE could access it among others programs.

There is a Wikipedia article about Gallium3D drivers.

Gallium3D drivers are slated to come in a future version of AmigaOS 4.x.

I'm talking about code that will bypass OpenGL and access the graphics drivers directly to implement AGA chipset features.

This is getting a little bit off topic but I'll comment a little about Gallium drivers.

The NVIdia graphics cards that work on the Gallium drivers on AROS should work on OS 4 if there is no endian-specific code in them. There are Radeon Gallium3D drivers as well, but LLVM is required by those. I've already accepted a bounty to port LLVM to AROS but if it is successful, I could try porting to AmigaOS 4.x as well.

I posted on AW.net some time back and got a few supportive responses about thin emulation. Now I'm wondering if it would be a good bounty for Power2People or AmigaBounty to have Classic Amiga graphics chipset capabilities written in the form of a fragment shader program for Gallium drivers.

Here's how it would work: It would open up 256-color palette-mapped layers using 8-bit alpha-only framebuffer objects. Some values of the palette would correspond to a 1-dimensional texture indexed by the Y coordinate of the screen to produce copper-rainbow effects. The 0 value of all of the framebuffers would pass through to the lower-priority framebuffers in the background. If the fragment shader program defining this could handle up to 10 layers, it would make all of the sprite/playfield capabilities of the Classics available to high-end graphics card systems such as the SAM 4x0 series and AmigaOnes.

The catch is, it won't work efficiently layered on top of Mesa or OpenGL since all framebuffers are 16 or 32-bits. Gallium3D supports 8-bit framebuffers though. This could make emulators much MUCH faster because it would offload most of the capabilities of the AGA chipset onto the graphics card.

Does anyone think this would make a good bounty? (And before anyone asks, I've got my hands full with existing projects to do it myself.)

Wow! Hard to believe I never signed up for the temporary site. I can post again now!

My favorite Amiga is the A1200. I'm hoping that the NatAmi MX will replace it someday though.

Maybe someday I'll find enough desk space to set up my MicroA1 and A1200. It's a pity to have to be stuck on only mainstream computers most of the time.

@Coder

http://piumarta.com/software/peg/ is the parser generator that Sidewinder and I were adapting for use with the Mattathias project before we sidelined it. It is written in C and should compile out of the box on OS 4 assuming you have unistd.h . It is much, MUCH easier to use than Lex and YACC and their descendents.

@ChrisH

5. If you don't like GPL 3 code dependencies, you can switch to LLVM's UIUC Public License. (Not a big deal for most of us but maybe a big deal to Hyperion.)

6. If you're developing on a Classic Amiga and nobody will apply your patches to the mainline to make the 68k backend of GCC better, you can switch to LLVM where patches are welcome.

@angelheart

Quote:

See also http://www.libcpu.org/ for translating assembly to LLVM Bitcode. The AROS team has already got a bounty going for an LLVM backend to produce machine language for AROS x86 and other backends are sure to follow. Perhaps somebody would be willing to produce an LLVM backend for OS 4 on the PPC based on the PPC Linux backend on the LLVM archives.

As far as being universal, we'll need some universal runtime libraries as well. This brings us back to the subject.

Would it, by the way, be possible for IDLTool to generate extern directives for each function so that an automated build script could link code to the library skeleton instead of creating an empty one?

@Renoir

That sounds like what HolyMonkey is looking for! 640x400 doesn't work in regular HAM mode on an A2000 so it must be a copper-list with the graphics.

I'll make sure he checks up on this thread in a timely fashion as well.

-edit-
Update. There was a review of it in AUI in May of 1988 according to Amiga Magazine Rack. They don't have scans of the review though.

@kvasir

The bad news is you'll need a scan doubler but the good news is that the cheap ones with SVideo inputs will work with AmigaManiac's RGB to SVideo adapter.

@Thread

Just to bring this thread up to par with the one on Amiga.org, the screenmode was called SHAM (Sliced HAM). It was a conventional bitmap with a copper list stored alongside the bitplanes.

@Raziel

It looks like he edited his post since you read it.

@thread

If Hyperion plans on porting LLVM to get the XCore-enhancements into AmigaOS, a better use of effort would be to check into SafeCode for LLVM on some currently-supported LLVM-based system.

@Mrodfr

Taken from the Classic Retro Remakes FAQ:
Quote:

@Rigo

Quote:

Amiga has always been multicore, just not symmetric multicore. Custom chips always were able to do things in parallel.

Quote:

If SDL software can be recompiled for OS 4 it can be recompiled for anything. This even includes several OS 3 compatible systems planned.

Quote:

I seldom get nostalgic myself. That's why I use my Mac every day and my MicroA1c hardly ever. It already supports dual-core architecture but I only use that feature for parallel builds compiling large software. There's a lot of large software around too!

I think the key to the future is keeping things slim and trim. The long pipelines in the processor are the product of inefficient MMU hardware capabilities. A short pipeline may be slower sometimes but is usually more responsive.

Managed code is the way of the future but there is no AmigaOS 4-compatible solution that can compete with the likes of .NET, Mono, and Java. Even if there were, most software for the Amiga is still written in C and C++. If Amiga was about the future we'd be breaking from the trends of the present and moving on. No MMU necessary for managed code to run on it. We'd need something that would not only compete with Windows but ditch the Windows comparisons altogether in favor of comparisons to Microsoft SingularityOS.

@vox

My OS4 box (which I hardly ever use anyway) is a MicroA1c. It's graphics chips are Radeon 7000 with 32 megs of video RAM. It was a good step up from standard AGA but a good step down from FPGA-based Amiga clones like NatAmi.

My A1200 with Blizzard 1230 accelerator (which I also hardly ever use any more) can run loads more software than OS 4 when you eliminate the low-performance EUAE emulator. I see OS 4 as a supplement to OS 3 rather than a replacement for it, especially when I can get better performance out of my Intel Mac Mini than I can from any currently existing OS 4 model (including the new ones coming out).

I view the retargetable graphics setups as a kludge to buy time until Amiga graphics chips became available again. I have a similar view of PowerPC processors relating to the new 68k softcores like the N68050 in the NatAmi. The AHI drivers are designed around software mixing by the CPU and were (BY DESIGN no less) a temporary kludge until Commodore (or whomever) came up with an official solution.