@all

Just changed the thread title to make it clear where the A1-X1000 is located. That way a Kiwi or Aussie looking for an OS4 machine is more likely to see it...

Hans

@Hypex

Quote:

That would be awesome.

It would also be great if a totally new user bought the X1000.

That said, I'm also happy to sell it to someone who already has an OS4 machine.

Hans

@all

This machine is still idle, waiting for a new owner.

Given shipping costs, it would best suit someone in New Zealand or Australia.

Hans

@smarkusg

Quote:

Does your x86 qemu system configure the RadeonRX card to use PCIe v3 by any chance? That would give you a big bandwidth advantage over the A1-X1000, and its PCIe v1 slot.

@derfs

Quote:
That might have been in the draft too.

What about other data buffers, such as shader constants? IIRC, you could bulk upload data to the GPU, and then let the shaders read from anywhere within the buffer. In this situation, you only know the data layout when it's actually being used by a shader.

Being able to share pointers and data directly between CPU & GPU is really nice, from an API perspective, because it simplifies things (handling the different address spaces was a driver nightmare). From memory, Apple's Metal API has this thanks to a unified memory architecture where both the CPU and GPU use the same address space. Unfortunately, this is only possible if the CPU and GPU use the same endianness, and have MMUs set up to match each other. So the hardware needs to be designed for it.

Hans

@derfs

[quote]Thanks Hans. The endianness is handled by byte-swap at SPIR-V load time, and SPIRV-Cross outputs GLSL text for the GPU path, so W3DN/OGLES2 takes it from there.[/quot]
bte-swapping the SPIR-V code s piss easy. Handling the vertex, and data bufers is where things get compicated.

everythig is fine so long as you use 32-bit data everywhere. Then you just 32-bit byte-swap all the buffers as you transfer to/from the GPU. Truble starts once a developer packs other data types in, to minimise bandwidth use and push the performance. For example, using vertex data with 8/16-bit data types, plus 32-bit ones. at that point, the APi needs some kind of data descriptor that maps out the datatypes. Otherwise, the drivers simply don't have the ino needed to do the conversion properly.

When I looked at the draft Vulkan spec, there weren't any descriptors giving the ino needed (unless I missed something).

hans

@kas1e

Congrats on solving the problem that likely prevented the original X1000 ethernet driver from ever being released.

Hans

@LiveForIt, @derfs

Quote:
It's an internal API. You'd have to ask A-EON for access to it.

An interim option would be to ditch gles2 as a go-between and run Vulkan through Warp3D Nova directly. Warp3D Nova's design is influenced by the draft Vulkan spec that was available back then (it was still a work-in-progress back then). So, the APIs are a closer match than Vulkan to OpenGL.

I'm pleasantly surprised that you got it working, because I thought Vulkan's design and the GPUs being of opposite endienness to the CPU would be a massive headache. I remember looking at it early on, and it looked like you were writing directly into GPU buffers, without enough info about how the data is structured (needed for endianness conversion). Warp3D Nova's API has functions to specify the data layout specifically to handle this.

Hans

I'm selling my A1-X1000, because I'm currently living outside NZ (and have an A1-X5000 and A1222 locally).

Apart from being a "First Contact" X1000, this one was also my main graphics driver development machine for years. It's been part of the RadeonHD/RX journey, both 2D and 3D. So, a small piece of history.

Asking price: $1800 NZD

Specifications:

* CPU: PA6T dual-core PowerPC
* RAM: 2 GB
* Storage: 1 TB HDD
* Optical: DVD drive
* Graphics: Sapphire Radeon HD 7770 1 GB (Device ID: 0x1002 / 0x683D)
* Network: Realtek 8169
* Case: Fractal Design Define R3 with the official A1-X1000 front plate (and back-plate). I personally epoxied the front panel...
* Cooling: Quiet case fans with fan-controller

NOTES:

* The hard drive has been wiped, because it contained confidential information (such as the RadeonHD and RadeonRX driver source-code, Warp3D Nova, etc.)
* AmigaOS 4.1 is included. I'll transfer the registration key to you, so that you can download the latest OS version
* The OS itself only comes with lite 2D drivers. You'll need to buy the full drivers from A-EON

Interested? Contact me directly by clicking here, and we can calculate shipping. I've given up on TradeMe and eBay, so we're going direct.**

Hans


** TradeMe blocked me from selling because I'm out of the country, and eBay gave up on NZ years ago, and doesn't support NZ sellers (e.g., "domestic shipping" is within the USA).

@all

Interesting discussion. My first reaction to this thread's title was "of course not!" However, I see that the discussion is much more nuanced.

Adding essential modern OS features will definitely need a backward-compatibility break. But, that doesn't mean that we can't maintain the ability to run old AmigaOS software via a sandbox of some sort.

I put some thought into how this could be done a while ago, and recorded it in my "Saving AmigaOS" series. I see some similar ideas being thrown around here. The "Saving AmigaOS" series is part of the Kea Campus Archive, which is available here.

Hans

@tekmage

I did a quick skim-read of your blog post, and was impressed with your attempt to solve the biggest problem with AI code generation for AmigaOS: the lack of good example AmigaOS source-code. LLMs are only as good as their training data. They generate decent code for common software tasks that match code in their training data. They suck with novel stuff, and anything for which they haven't been trained.

Your solution is to directly give the AI agent AmigaOS-specific example code.

Did you find enough example code for this to work?

Hans

@kas1e

Quote:
Yes, that's correct. The original listing didn't sell. Then TradeMe decided to cut me off, and block me from relisting because I'm not physically in New Zealand right now. Zero consideration for my situation. Just rule idiots executing company policy.

Hans

@afxgroup

Nice!

@all

Sooo. My post in the FB group is still in stuck in "needs admin approval," and it seems that there are very few kiwis on this forum.

Any Aussies in the house that want an X1000? I think that they can ship it across the ditch without breaking it.

My biggest concern with shipping internationally is the chance that it arrives broken. Yes, I know there's shipping insurance, but a broken X1000 is still a broken X1000, even if we've been financially compensated for the breakage.

Hans

@daveyw

Thanks.

@NinjaCyborg

Ebay exists in NZ, but TradeMe owns most of the market. Ebay gets a tiny fraction of the traffic that TradeMe gets (in NZ, not globally).

Listing on eBay may well be the next step.

Hans

@daveyw

I don't have Garran's contact details (no idea who he is).

Hans

I'm still trying to sell my A1-X1000. My preference is for the machine to stay in NZ.

Unfortunately, that's being made extra difficult. TradeMe cut me off after selling the Sam460 because I'm not in NZ.

I tried to post a message about the machine to the Amiga Facebook page. Alas, it's been waiting for admin approval for days. So, if you know someone who is an admin there, could you please ask him to approve it?

Or, if you're interested in buying the machine yourself, then please contact me here. Here's a link to the original listing.

Hans

@ldg72

Congrats on getting it working.

@AlexC

Quote:
Interesting question. My first thought would be that LLMs probably wouldn't be effective with such a huge code-base. Second thought, maybe someone should try it.

I've been testing out using AI coding assistants. There are times when they're surprisingly good. For example, the auto suggestions for DebugPrintF() calls are pretty good at guessing what debug output I want to print, and writing out the code correctly. Being able to write that code with a single TAB certainly saves time.

Other times, the code suggestions are dead wrong, and I write out the code manually.

Code generated via chatting with the LLM is also sometimes impressive, and sometimes utter garbage. I review any code generated line by line, because it gets a lot of stuff wrong, puts magic numbers all over the place, and likes to over-use comments. I do have to do a fair bit of cleanup to make the code higher quality. This does make me wonder about the quality of the code that it was trained on...

I find it very useful to learn how to use 3rd party libraries that I'm unfamiliar with (even large ones). This is especially true, with poorly documented libraries. That might be one of the biggest time savings.

AI code assistants do allow me to write code faster, but I think that being an experienced programmer is essential to keeping the code quality high, and structuring the code well.

@smarkusg

Copyright infringement is indeed a concern with AI. I'm sure that they've slurped up the public parts of my website in their entirety, without my permission. Not much that I can do about it.

If you're using an AI code assistant to work on proprietary code, then you do need to use the settings to exclude GPL licensed ccode (or similar).

I'd love to build my own private LLM code assistant. Alas, I don't have the money to buy hardware sufficiently powerful to run a sufficiently large LLM.**

Hans


** From what I've seen, small LLM models can't even code a working to-do list program.

@3VILC

Quote:
Great that you've got it up and running.

USB devices can be a bit hit or miss with OS4 machines in general. I've never tried booting off USB (I installed the OS using the DVD drive).

Hans

@joerg

If it doesn't sell on TradeMe (unlikely), then I'll consider putting it on ebay so that people in other countries can buy.

I'm not so keen to ship internationally, because it increases the risk of damage. It would be the buyer's risk.

Hans