Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
154 user(s) are online (103 user(s) are browsing Forums)

Members: 0
Guests: 154

more...

Headlines

Forum Index


Board index » All Posts (Samurai_Crow)




Re: Thin emulation?
Just popping in
Just popping in


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.

Go to top


Thin emulation?
Just popping in
Just popping in


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.)

Go to top


Re: Wow, the Amigans.net is back!
Just popping in
Just popping in


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

Go to top


Re: Favourite Amiga
Just popping in
Just popping in


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.

Go to top


Re: Good parser generator for OS4
Just popping in
Just popping in


@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.

Go to top


Re: Creating an AmigaOS4 library
Just popping in
Just popping in


@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.

Go to top


Re: Creating an AmigaOS4 library
Just popping in
Just popping in


@angelheart

Quote:

angelheart wrote:

We need a UNIVERSAL AMIGA Assembly language that uses XML to port to different CPUS.

This way we can use C -> UAA -> ppc/68k/??

PPC/68k asm -> UAA -> C conversion

tools to exist on windows :
http://www.mpsinc.com/asm68k2c.html


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?

Go to top


Re: What was the name of THAT painting program?
Just popping in
Just popping in


@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.


Edited by Samurai_Crow on 2010/10/4 17:53:40
Go to top


Re: Flatscreen TV issues.
Just popping in
Just popping in


@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.

Go to top


Re: What was the name of THAT painting program?
Just popping in
Just popping in


@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.

Go to top


Re: The Amiga Man Website is LIVE!
Just popping in
Just popping in


@Raziel

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

Go to top


Re: Did anyone trying to port Valgrind ever ?
Just popping in
Just popping in


@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.

Go to top


Re: New Games possible?
Just popping in
Just popping in


@Mrodfr

Taken from the Classic Retro Remakes FAQ:
Quote:
Q: I'm running Linux, have a MacIntosh, or another non MS Windows PC. Can I play the games?

A: Unfortunately, no. Not unless you know how to emulate Windows on your non-Windows PC.

Go to top


Re: 68k OS getting close to OS 4.x
Just popping in
Just popping in


@Rigo

Quote:

Rigo wrote:
@Samurai_Crow

As we move on to multi-core support, more and more backwards compatibilities will break, and good riddance I say.

If I wanted to cling onto OS3, I'd fire up my A4000 again, after 8 years it could probably do with a blowout.


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

Quote:
The original compatibility layer was present in the system to give the users and developers a way to run software that may have been required in those days. Luckily, a lot of that software has been recreated for OS4, and can easily be recompiled to account for any subsequent changes in the system.


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:

If I really get nostalgic, I'll fire up UAE to run something, but I've never had need so far in 8 years, I very much doubt I'll start now.

In short, OS4 is not about the past, but about the future. Once the software library is big enough I'm hoping the "compatibility" is simply disabled and we can really get on with moving forward.


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.

Go to top


Re: 68k OS getting close to OS 4.x
Just popping in
Just popping in


@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.

Go to top


Re: 68k OS getting close to OS 4.x
Just popping in
Just popping in


@mechanic

Quote:

mechanic wrote:
@Samurai_Crow

Quote:

Samurai_Crow wrote:
OS 4 is geared toward the people that dream that Amiga can compete with PC hardware by using it themselves (eg. PCIe graphics cards).


Is that ALL OS4 people ?


All but the OS 4 for classics!

Go to top


Re: 68k OS getting close to OS 4.x
Just popping in
Just popping in


@thread

The NatAmi team has said that they will ship their system with AmiKit. This includes a distribution of AfaOS which is AmigaOS 3.9 with large tracts of AROS code added throughout. They are not going to lobby for an AOS 4.x port especially since its memory system requires an MMU thus making it unsupportable on the 68050 softcore. Even if Hyperion WANTED to backport OS 4 to the classics they couldn't do it because too much PowerPC-specific features have been added to that version of the OS.

They are not even geared toward the same markets any more. OS 4 is geared toward the people that dream that Amiga can compete with PC hardware by using it themselves (eg. PCIe graphics cards). OS 3 can run loads of software that a modern PC requires a performance-sucking emulator for. IMO, if I wanted to do anything modern I wouldn't use an Amiga to do it with.

Go to top


Re: Lightspark: a faster alternative to Gnash?
Just popping in
Just popping in


@ChrisH

Quote:

ChrisH wrote:
@emeck
While what you state might be possible, I thought the general idea was simply to provide unified exectuable code generation (for both compilers & JIT). Rather than generating 68k or x86 or PPC assembler, you generate LLVM assembler, and it then does the job of creating an executable your CPU can understand.

I think one problem with your suggestion is that the LLVM "intermediate code" might be CPU independant, but it won't be OS independant!


It all depends on which programming language you use to generate your IR code. Mattathias will be an install-script away from installing on any LLVM-supported OS but we'll have to write the installer scripts in a system-specific way. C++, on the other hand, compiles system-specific macros in its preprocessor headers making it difficult to write truly cross-platform IR code. Flash and Java players built on LLVM will be cross platform assuming that the player itself was written cross platform.

Lightspark seems to be written for Linux but if we can port it to AmigaOS then that would be great!

Go to top


Re: Lightspark: a faster alternative to Gnash?
Just popping in
Just popping in


@Hans

Quote:

Hans wrote:

What would be required to get LLVM's JIT running on OS 4?


Since the Apple people have already written a PowerPC backend for LLVM it shouldn't be too hard. There are some rough instructions about writing an LLVM backend so the work of writing an LLVM backend will mostly be related to porting the system class to do all of the things the Mac and Linux do.

The JIT part of it will have to be able to write to main memory with the executable bit set in AmigaOS so the memory allocation parts may need some tweaking. Keep in mind, though, that the LLVM JIT already runs on PPC Macs so it shouldn't need a whole lot of work.

The most blatant problem in getting the backend to work is that the TableGen utility only has some fundamental documentation so finding out the rest of the functionality of the utility may be difficult. I've found a searchable web frontend to the LLVM Developers' mailing list to be quite helpful.

I hope this helps!

Go to top


Re: Lightspark: a faster alternative to Gnash?
Just popping in
Just popping in


@ChrisH

According to this post on the LLVM mailing list LightSpark uses LLVM's JIT as well as OpenGL. If the next version of the OS 4 SDK supports LLVM it might be possible to port to OS 4.

-edit-
According to the LightSpark webpage it requrires GLSL shaders also. This means that until we get a full implementation of MESA or OpenGL, this product is a no-go. If the next version of the OS 4 SDK supports shaders then there is a chance.

Go to top



TopTop
« 1 2 3 (4) 5 6 7 ... 9 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project