@joerg

I suppose I could monitor the issued commands. Maybe Media Toolbox or format is using TD instead of TD64 commands. I do recall that I saw some in my logs. That would explain a 2TB limit.

@Raziel

There's no conclusive evidence yet which part of the system is to blame. It can be the filesystem, Media Toolbox or even the driver.

Unfortunately I do not have such a large drive available for testing (yet).

Nevertheless, the Media Toolbox should be fixed to support > 512 LBA size.

Edit: The "disk full"error after formatting happens when there has been write errors to the file system administration on disk. Happened to me as well while developing the NVMe driver

@Raziel

Those two blocks sizes are unrelated.

Trackdisk64 standard allows you to access a 64bit address range.

An SSD/HDD is not address with bytes but with logic blocks. This logic block size is traditionally 512 bytes. So instead of writing an amount of bytes starting at a certain address, you write an amount of logic blocks starting at a certain block number. This means that the file system needs to address the SSD/HDD and transfer data in multiples of logic blocks. This is called logical block addressing (LBA). A Nvme drive can address 64bit of those LBAs meaning a theoretical maximum storage size of 64+9=73bit in case of a 512 block size.

Now the file system itself can use a different block size as data container to organize the storage size of a partition. The only restriction here is that the file system block size must be a multiple of the SSD/HDD LBA size.
Larger containers are more efficient from a transfer speed point of view. But will also lead to more waste of storage because you get more containers that are not fully occupied with valid data.

Trackdisk64 might be able to address a 64bit address space. Bit apparently the SFS2 partition size is addressed with 32bit. 32bit with a file system block size of 512 bytes results in a maximum partition size of 41bit (=2TB). A block size of 1024 bytes results in a limit of 4TB and so on.

Modern sata drives and Nvme drives might also support logical blocks of different sizes. For example 4096 bytes. I actually have a Nvme drive which allows me select 4096 bytes LBA. But unfortunately Media Toolbox doesn't allow me to create partitions in that case. Because it does not support any other LBA size then 512 bytes.


The size that Media Toolbox shows you is reported by the driver. That's simply amount of LBAs x LBA size.
The partition size limit could be the result of another unknown limit inside Media Toolbox.

You could try FFS2 instead. Just to be sure.

@Raziel

There is disk physical block size which you cannot change in the drive geometry window. Because this a property of the disk itself. And Media Toolbox only support 512 bytes anyways.

But you can change the filesystem blocksize when you create a partition.

@TSK

https://phoboslab.org/wipegame/

Just click on either version and the game will start in your browser.

@kas1e

I've just tried the browser version in Chrome on my Win10 PC with Radeon RX570 and the framerate is in the range of 2600-5000 fps.

I couldn't find a pre-build windows version.

So we have a loooong way to go.

Edit: To make it worse for your notebook. Even mij Samsung phone does 600 - 1200 fps

@kas1e

As you can read in the linked blog post in #4, this source is basically a complete rewrite of the leaked source code already. So a bit more adjustments to what's available on our system wouldn't hurt

Afteral, the pc version manages >2000fps.

@HunoPPC

This version works as well. Framerates are a little higher compared to the one from @SinanSam460: 33-50fps in the first level

@Hans

The issue with the SDK in general is that the authors assume that the audience is familiar with the complete history of RKRMs or Amiga programming in general. And that the autodocs and wiki are a guide to what's changed since the 68k era.

In this case, it's the names of the fields in combination with the contents of the autodoc that are confusing.

From the autodoc:


The "Physical" field is only mentioned in combination with MEMORY SPACE ACCESS.

It tells me that I have to take the "physical address range" into account by obtaining the "Physical" field. It was my assumption that it tells me something about the actualy physical size of the BAR instead of allocated size (Size field). Some cards allow to use the unallocated/unused BAR memory as user defined memory. So up to now, I've ignored this value and always used the BaseAddress. For my drivers, there's no need for the physical address of a BAR anyways. Because PCIe cards come with their own DMA engine which you have to feed with the physical address of a buffer in main memory. Card to card transfers are in general not used/possible with PCIe.

Maybe the physical address is needed for a gfx card if you want to use the host DMA engine to transfer data from host memory to GFX memory. And if it was, I would have obtained it from the MMU in supervisor mode. Just like i do to obtain the physical memory address of a buffer in main memory.

But if you look at this structure in pci.h, the comment makes it clear that it's not a range but a "Physical base address of the range"

@SinanSam460

I can confirm that your binary is running on a X5000.

Framerates in the range of 29-48 on a RX580.

But overall very playable.

@HunoPPC

I still get an alignment error while loading the game on my X5000.

@MigthyMax

You're reading the extended capabilities within configuration space. You're not in BAR space.

If the virtio device is handled correctly by the target firmware then reading BARs should work.

At least for VFIO you can access the BARs of physical PCIe cards. But there was an issue with 64bit bars for a Pegasos2 target. This requires some fiddling with scripts or the altenative firmware called BBOOT. The SAM460 target doesn't emulate the PCI buses correctly.
But I do not know how the virtio devices are handled in that target.

@MigthyMax

Unfortunately the autodocs don't contain information about the difference between Physical and BaseAddress.

I can imagine that "Physical" is the address in PCI space and BaseAddress is the address in CPU space. They can be the same but this is not always the case.
It could also be that Physical is meant for Memory space BARs only because they have to be mapped in a physical memory range where IO BARs can be mapped beyond physical memory range and can have any address.

Anyways, someone should update the autodocs

Why it isn't working in QEMU is probably because you are trying to access a device on a bus that is not properly emulated.

@MigthyMax

Use resourceRange->BaseAddress to obtain the BAR base address.

And then add the offset to your registers of interest.

@Maijestro

Most likely not. Because I've removed the codec discovery routines and added profiles for known codecs. Partly to speedup initialisation and partly because it turned out that some codecs use custom verbs. And you can only get this knowledge from reading their data sheets.

@sTix

The last publically available version will not be available for download anymore. I'm currently upating the drivers and once beta tested, the new drivers will be made available again.

The hdaudio driver will receive a rather big update from software effort pov, so it might take a while.

@MartinW

There's also this GUI frontend called virt-manager on Linux. This one seems also tailored towards running Windows in QEMU kvm.

@MartinW

I use a 300mm cooler master riser cable (MCA-U000C-KPCI30-300) to connect the Gpu with the X5000. And that works just fine with the other PCIe cards in any slot.

Now that you mention it. It indeed doesn't have a reset switch.
Normally I use alt+alt+ctrl to force a hardware reset. In case this reset isn't available, I press the power button to switch it off. In case of a complete crash, I press and hold the power button for 10 seconds to force it off.

@MartinW

Gpu fans are controlled by the gfx card firmware. There's no Amiga software to control the fan speed manually.

Like others, I've replaced the cpu FAN with a Nortua Fan.

My X5000 is mounted in a cooler master sl600m. It comes with a fan controller. The two bottom 200mm fans are replaced with 2x 200mm Noctua fans.

Primary reason for the Cooler master sl600m is that it allows for mounting the RX580 gfx card vertically. This enables the x4 slot. The two bottom fans help to cool the vertical mounted gfx card as well. This is probably why they spin at a low speed.
Overall the solution is very very quiet. At the lowest fan setting, the main board temperature remains below 60degC.

From Trevor's blog:
" Fast forward to 2021, and I’m pleased to report that our graphics guru, Hans der Ruiter picked up where Stephen left off and has produced a new beta version of DvPlayer which is currently under test."

Hans added hardware accelerated vaapi support for HD and RX cards