@MigthyMax

The instructions are buried somewhere deep in this thread. You need to tailor it to your hardware. I'll see if I can dig up the script I used.

Hans

@geennaam

Quote:
I guess it's assumed that, if you're writing driver code, then you know what virtual and physical memory are. The BaseAddress is the virtual address (i.e., the address you use in code running on the CPU). The physical address is where the PCI card is located in physical address space.

It may be a little confusing that the physical address is 32-bit, when the actual physical address space is 64-bit. This is for legacy reasons, and is also rather limiting.

Hans

@MigthyMax

Are you emulating a Pegasos II? If so, be aware that the Pegasos II kernel couldn't handle 64-bit BARs. So, the memory BAR would be missing for virtio devices. I say "couldn't" because I have fixed the kernel PCI scanning code.

In the meantime, there are workarounds to get it to work which basically involves changing the OpenFirmware device properties to make the 64-bit BAR look like a 32-bit one. I have a boot script that does this (which I don't need any more). No idea if BBoot does the patching automatically.

Quote:
Yes, they are.

Hans

@all

Has anyone written updated instructions for installing on AmigaOS 4.1 on Qemu that uses BBoot? AFAIK, that's the currently best way to get OS4 up and running on Qemu.

Hans

@geennaam

Quote:
Do you need help with this?

Hans

@skygecko

Quote:
You're welcome. I'm glad you've got your system up and running again.

@nbache

Quote:
Good idea, although you don't necessarily need a separate partition. I create a backup sub-directory in SYS:Kickstart, and copy all kickstart modules into there. I know they're working, because I booted with that kickstart. Next, I open up SYS:Kickstart/Kicklayout, and create a copy of the existing layout. I rename that one as "AmigaOS 4.1 Backup", and update the path for all the modules to Kickstart/Backup/*. A quick reboot will confirm if the backup version works or not.

Due to my work on drivers, I also have an "old RadeonHD/RX" kicklayout that only uses the backup versions of of the graphics drivers. That way I can recover quickly from a bad test driver.

Hans

@skygecko

Quote:
Very strange. As I said, the RadeonHD.chip driver should *NOT* interfere with the RadeonHD.chip driver. The only possibility I can think of, is if you have both cards plugged in, and UBoot picks the X1950 Pro as primaary card.
Quote:
Would be nice, but the graphics system has no way of prioritizing drivers.

I personally keep a backup copy of kickstart on my system so that I can easily undo mistakes. It would be useful if an automated kickstart backup system existed...

Quote:
Start by commenting out the RadeonHD.chip driver, and try booting with just the Radeon RX 550 plugged in. Or, copy the RadeonHD.chip from your installation CD (yes, the "lite" driver). Assuming that gets your system back to booting, then you can download the RadeonHD.chip v3 driver via AmiStore.

Or, you could try the Java based AmiStore client that someone created.

Hans

@skygecko

Quote:
It should go before. What it does is comment out the driver, so it won't be loaded.

Specifically which graphics card do you have? You say you have a Radeon RX (i.e. Polaris card), in which case the RadeonHD.chip driver would be irrelevant. The RadeonHD.chip driver does NOT interfere with cards that use the RadeonRX.chip driver. It makes me wonder what else changed on your system...

Quote:
Sorry about that. I updated the "REQUIREMENTS" section in the readme with the supported cards list, but didn't notice the bit in the about section or the installer. Nobody else did either, until now...

Hans

@Maijestro

Quote:
ZitaFTP Server doesn't provide realtime transfer info (except for the status docky). The server doesn't know how big an upload is going to be,** so showing a progress bar for uploads isn't possible.

Hans

** There is an ALLOcate command to tell the server how much space is needed, but I don't know of any FTP client that actually uses it.

@LiveForIt

AFAIK, WritePixelArray is a straight copy into a bitmap. No pixel format conversions whatsever.

When it comes to 16-bit modes, please check which mode you actually have. Older Radeon cards support big-endian 16-bit, whereas newer Radeon HD (Southern Islands) and Radeon RX cards don't. The Picasso96 driver API doesn't allow the driver to do any automatic conversion. So, your software had better check what screen-mode it's running on. We've had trouble in the past with software assuming that big-endian 16-bit modes are available.

This is also why Wipeout 2097 can't be used in full-screen mode with newer hardware...

Hans

@Maijestro

As Joerg said, AmigaOS commonly has a Work: partition. That's the way all of the machines are/were delivered. ZitaFTP Server uses Work: as a default location for some stuff (e.g., logs), if it exists.

The problem was that the code to suppress those "please insert X" DOS requesters was run too late. By default, the DOS library will pop up that requester if a program touches a non-existent volume/assign. Yes, even if a program just checks if a path exists.

I've fixed this, and the next ZitaFTP Server update won't have this problem any more.

Hans

@Maijestro

Quote:

Sorry about that. I found the root cause for that recently, but have yet to publish a bug-fix release.

The workaround for now would be to add the following to S:startup-sequence (before the network-startup is run):
assign Work: SYS:

That should shut it up.

Hans

@Maijestro

I'm surprised that Emotion kind of froze with the video. Have you checked Emotion's frame-skipping settings?

It looks like DVPLayer's frame-skipping might be a bit too drastic. Please submit a bug report to here. No idea when I (or someone else) will have time to look at it, but the issue needs to be recorded in the bug tracker.

@joerg

Yes, A-EON ended up contracting me to write the hardware accelerated update to DVPLayer. Stephen was too busy, and they couldn't find anyone else. That's a shame, because we really need more developers working on stuff rather than getting the same few people to do almost everything.

Hans

@Maijestro

Quote:
Good news! I found an easy way to get Filezilla working with ZitaFTP (or any FTP server) when it's behind a NAT router. No code changes needed. Details here:
https://keasigmadelta.com/blog/connect ... a-nat-router-the-easy-way

Hans

@kas1e et al.

Raylib isn't really a fully blown game engine, but rather a game/multimedia library with which you could write your own game engine and game. It's great for learning game engine programming, and could also be a starting point for a custom game engine. But, it's not a full-blown game engine that you can drop in your game assets, and script up a game.

I've been playing with it over the last year. You can watch me piece together the code for a proto platform game here. You can see that I have to write my own code to load and display a tile-map, get the physics working, etc.

The Raylib community is growing rather quickly, so it could become more interesting over time. There are a few high quality games that use Raylib, such as the one that davebraco linked to.

Hans

@MartinW

Quote:
The tricky part is getting SDL2 and libangle installed. After that, you can follow the tutorials. IIRC, kas1e managed to gee the tutorial code running on OS4. We have SDL2, and libangle can be ditched because we have OpenGL ES 2.

@kas1e
Quote:
Not yet. Afxgroup's clib2 needs to be manually installed. Not only that, it has to be installed over the top of the original clib2. That's messy, and potentially causes trouble when linking to libraries compiled with the old clib2. That's messy.

I don't need to think with newlib, because it's the default C runtime.

It would be game over for newlib, if afxgroup's clib2 got bundled in the SDK ready to go, and became the default runtime.

I still prefer newlib, and would rather see it updated. But, if that's not going to happen, then replacing it is the only viable way forward.

Hans

@MartinW

Quote:


Yeah, didn't take long to go 100% off-topic. In everyone's defense, you seeded the off-topic discussion with your original post.

I hope that your Raylib port will be finished off, including audio. And preferably also be buildable with newlib too. I appreciate afxgroup's work, but would rather avoid having to manually replace the existing clib2.

Hans

@joerg

Quote:

I'd certainly welcome an updated newlib. However, if it's incompatible with the existing one, then we end up with an even bigger mess: 4 incompatible C runtime libraries.

The key problem we've had with the runtime libraries, is that the small closed-source part means that only Hyperion can update it. And, Hyperion haven't been able to update it in line with what developers need. If newlib had been updated with full POSIX compliance (or at least the most needed bit), then I doubt anyone would be using clib2 let alone creating their own forks.

Hans

@MartinW

Congratulations on getting Raylib working on AmigaOS (albeit minus sound at this stage)! Nicely done.

MY apologies for my contribution to the confusing array of libraries. I'll do my best to outline how it all fits together.

Newlib/Clib2/Afxgroup's New Clib2

Newlib and clib2 are C runtime libraries that implement the C standard library. Clib2 gets statically compiled into your binary, while newlib relies on a newlib.library. This results in smaller binary files, because the bulk of code is in a shared library.

AFAIK, the intention was for newlib to become the *only* C runtime library. Unfortunately, that never happened. I'm not sure exactly why, but clib2 remained available, and there were some features that newlib missed (and vice versa).

Fast-forward by a decade or so, and both newlib and clib2 are missing features people want to aid porting software from the posix world. Some argue that POSIX compliance is beyond the scope of the C runtime libraries, but both newlib and clib2 already had some POSIX functionality. The newlib.library is closed source, so only Hyperion can update it. Those updates are rather slow to happen. The AmigaOS clib2 project suffered from having to support older versions of AmigaOS as well as OS4.

So, afxgroup created his own fork of clib2, made it OS4 only, and added the features that he and others needed.

Hence, we now have 3 C runtime libraries. They're incompatible with one another, so if you use newlib, then you need all static link libraries to be compiled with newlib as well.

Yes, it's more complicated than needed, but it's where we're at. I really wish we could get newlib brought up to standard, and make that *the* C runtime library that's usable for everything.


GL4ES Ogles2.library MiniGL Warp3D Nova, and Warp3D

Warp3D is the original 3D API for AmigaOS, and was based on the capabilities of 3D graphics cards of the time (e.g., no support for shaders or even hardware accelerated Transformation, Clipping, and Lighting (TCL)). MiniGL (and StormMESA) provided OpenGL 1.3ish compatibility. Performance was hampered by the lack of TCL and other problems.

Warp3D Nova is a (relatively) modern shader based 3D graphics system. It's incompatible with its namesake (Warp3D) out of necessity. There was no way to add shaders to the old API in an efficient manner. Instead, it's design is based on how modern GPUs work (with some inspiration drawn from Vulkan, and the original Warp3D).

Obviously, we need OpenGL compatibility. To get there faster, we decided the best path forward was to implement the OpenGL ES 2/3 API. Hence, the ogles2.library. OpenGL ES ditches a whole lot of old functionality that you shouldn't be using any more, making it much more doable. The plan was to use something like the angle library to get full desktop OpenGL compatibility on top of the ogles2.library. Kas1e found that the GL4ES project was a better fit.

What about backward compatibility for old software? I wrote NovaBridge for that. It provides the backward compatibility layer to let old MiniGL/Warp3D software work on newer graphics cards.

Unfortunately, NovaBridge is currently available as a separate purchase, so it isn't bundled in on all machines with Warp3D Nova capable hardware. So, the confusion I hoped to eliminate with NovaBridge remains. That should disappear in future, when it comes bundled with all new machines.

Development-wise, it's a bit messy because GL4ES is a separate download. Ideally, it would be bundled in with the ogles2.library and Warp3D Nova's SDKs, along with clear documentation.

In brief, here's how the libraries fit together:



NOTE: You don't have to use GL4ES. If the ogles2.library has everything you need, then use it directly. You could even use Warp3D Nova directly if you wanted.

The legacy graphics (lower half) should fade away over time.

I hope that helps clarify things.

Hans

@Templario
Quote:
Thanks for the reminder. I tend to forget about AmiCygnix and software that runs on it, because I prefer "fully native" software, and AmiCygnix is a *nix X windows environment. It does bring us some useful software...

Hans