@kas1e
It seems there's a usb/uhci.c in the SmartFirmware sources but its missing the actual driver methods. You probably need to implement at least device_request method or whatever else is needed like is already in ohci.c then it should also work for UHCI. There is some documentation here.

@smarkusg
Right. So it mean bPlan just wrote UHCI driver, and the OHCI one which were in smartfirmware by default just for additional PCI boards (through, even then it wasn't mean for mass-storages support in firmware itself, just for boards detection).

@kas1e
Quote:
I have no idea, but I remembered one thing. I think there were two newer beta versions of the firmware for the PEG2.
A while back, a user on the MorphOS forum who had a PeG2 with that firmware wrote that it improved USB performance.

The PEG2 definitely has UHCI USB 1.1. Your post on the Hyperion and lspci forum
https://forum.hyperion-entertainment.com/viewtopic.php?t=5019

@smarkusg
Quote:

Hm, in original smartfirmware code they only have OHCI implemented, but latest versions from bPlan for sure can detect USB keyboard, and to some extent usb-stick: it shows just like /pci@80000000/usb@C,3/scsi@1 , but nothing else, so seems they simple didn't implement massstorage support before, just were in the progress.

Which also mean, that seems bPlan fully implement UHCI , and Smartfirmware's OHCI were done for additional USB PCI controllers ?

@kas1e
Peg2 only has a USB: v1.1 UHCI controller on the motherboard.
By adding this "-device pci-ohci" to the QEMU command line, you “add” an additional USB PCI controller to the motherboard.
It will only be recognized if the operating system supports it.
Just like in this video, where it’s paired with a real PEG2 (at 55 seconds)> https://youtu.be/oE42AX1F2LY?t=46
The video is pretty cool overall. It’s great to see that someone is still playing with a real PEG2 these days.

The PCI-OHCI driver for QEMU has received minor updates for QEMU-11
https://www.amigans.net/modules/newbb/ ... id=159592#forumpost159592

@Balaton
As far as i see pegasos2's VIA VT8231 support USB1.1 , but when we do -usb-storage in qemu, it by default seems to take not OHCI , but UHCI route, right ?

I just find that smartfirmware have support of OHCI already, but it only will works then if i will run qemu with something like :



But the default "-device usb-storage,drive=usbstick" will not work in smartfirmware, just only on the OS later.

Not that it problem of course, just some thing i notice

@Balaton
Yeah, with virtual coms it was pain to make it works (i were only able to redirect output from one com to another, but once i start interract with like keypresses then everything freezes).

So i simple go :



and rewrite scripts to use TCP instead of com, so it works too.

@kas1e
I don't know Windows but in QEMU you can define -chardev options I think and connect serial to those so you could redirect serial port not only to stdio or file but also to tcp port or whatever else so maybe you could interact with one of those in your scripts rather than making a virtual serial port.

I've had a Catweasel MK4 for some time and figured it was time to put it to good use.

I put it in a PCI slot on my x5000, found that catweasel.device was already in the DEVS: directory. I got a straight through floppy cable and hooked up the drive which shows up as drive 1.

I set my prefs in the Catweasel setup under PREFS to Drive 1, PC HD drive and set pin 34 to RDY.

I tried to take DF0: out of Storage and throw into devs to use it as an Amiga drive. This didn't seem to work or mount anything, so I modified the list for device 1 instead and still nothing.

I used the Super Image tool, and it attempts to write and fails after the first block no matter what I do.

I DID try the catweasel.device that Ian created and was able to write most of a disk under the Super Image tool but it died at the last block (might be a bad disk). In all cases, if it failed it would send up the Grim Reaper.

I guess my question here.. what is the proper way to set one of these up? Use the drivers that are part of the OS, use the drivers that Ian created or other?

Maybe it wasn't based on WinUAE because the WinUAE sources are a mess and it's hard to port anything from there. I've looked at the cirrus-vga that they have some fixes for but the commit history is just random changes without description and the device emulation was changed to glue it into WinUAE so not compatible with QEMU even though it originally comes from there. I think the Voodoo in WinUAE also comes from the same source as this port but ultimately all of these go back to MAME but that had a licence change at one point so it could not be used any more. So maybe Bochs or whoever was first adding Voodoo had a fork from before the licence change and implemented the missing parts and then the rest took that GPL version.
I think it's a waste of time because the result is limited and cannot be upstreamed in QEMU so it's of limited use but it's a waste of AI not the author's time so could be done. As I see it he did a lot of experiments and this one turned out to be somewhat working so he's pushing it now but if it won't be better than Wazp3D then there's not much point in doing it.
I don't understand what your problem was but if you just needed a way to boot your broken install I guess you could have solved that easier by creating a small boot disk image with the proper Kickstart.zip and boot from that instead of your SYS: volume and that should have worked with whatever driver you put in the new Kickstart.zip. Or if nvme pass through does not need the pegasos2.rom (I think only GPU needs it for the BIOS emulator) then you could just boot with -kernel bboot -initrd Kickstart.zip without the GPU and only the nvme passed through and fix your Kickstart.zip on the nvme. That way you didn't need a patched QEMU build for this.

@joerg
Quote:
Most likely, the WinUAE driver would only work with AmigaOS PPC.
From what I can see, the author also wants it to work on both x86 and PPC, covering all systems.
You’ll surely point out that WinUAE uses QEMU to emulate the PPC CPU when running AmigaOS4 PPC on classic hardware (yes, WinUAE uses QEMU, in case anyone didn’t know). But that’s a very old version… very old. I think it comes from QEMU 3 if I remember correctly, and it was definitely stripped down to work properly with WinUAE under the CPU. I have no idea if it also emulates Voodoo.

This emulation QEMU voodoo has come in handy for me twice recently—even though it doesn’t work perfectly.

Example 1:
As you’re reading this thread, @balaton has released a new driver for QEMU (ATI).
I tested it under Sam460ex emulation. It didn’t work. Under QEMU (with PCI passthrough enabled), only the SM501/502 is available.
If I didn’t have the Voodoo driver for QEMU, the scope of troubleshooting potential issues would be very broad.
After verifying that the Voodoo driver for QEMU works on Sam460ex, a possible issue was u-boot. It checks if the connected card is ATI and configures various settings. It’s possible that QEMU (ati) doesn’t work correctly yet on Sam460ex after disabling this, but I think @balaton is already looking into that.

Example 2:
As you know, I have QEMU PCI passthrough with a Radeon card. I also connected an NVMe drive to use as my main system drive.
The system using PCI passthrough is Pegasos2. Here, to start the PCI passthrough itself, you need to use bboot.
“pegasos2.rom” boots on its own, then bboot.fth is launched. It runs Kickstart.zip and boots the system.
This doesn’t happen automatically, so you have to bypass the restriction on booting the Pegasus2 emulation from ROM. Give it the commands… I’ll skip the rest of the details.
By accident, I added a “REM” for the RadeonHD driver in Kicklayout. The system wouldn’t boot. I didn’t have a modified version of Kicklayout where the SM501 driver would also be loaded.
I was in for a real ordeal. Connecting the monitor (My new monitor doesn't support resolutions lower than 800x600) to an X86_64 machine with PCI passthrough. Enabling the Intel card. Launching some X11/Wajland session and running QEMU without PCI passthrough from some system image to rebuild Kickstart.zip.
I hadn’t removed “MODULE Kickstart/3dfxVoodoo.chip” in Kicklayout, so the test was simple.
Booting the system with Voodoo via a remote “VNC" (Available as a QEMU video output option) session, correcting the entries in the running system in Kicklayout for RadeonHD, and rebuilding
Kickstart.zip.

Example 2 is very extreme, but it shows that the Voodoo driver can save your butt

I disagree that the author’s work on the Voodoo driver is unnecessary.
It’s not perfect, but it’s not a waste of time...
It comes in handy in everyday life (for me).

The thing which i currently not very well understand , is why there needs for different amigaboot.of and loader.of. I mean, should't it all be just done inside of amigaboot.of ? Becaues for now, it looks like this:

- amigaboot.of = disk reader
- loader.of = linker/loader

amigaboot check for block devices, and load loader.of, which, then, doing another things like claim memory for modules and co and load them from the memory areas to which amigaboot.of load them.

Why ? Why simple not doing that all in amigaboot : read from disk , load to the memory, once all done, we done, os4 boots, why complicate things with all this different binaries ?

@smarkusg
Quote:Why wasn't the Voodoo emulation from WinUAE used as base for the QEmu implementation?
The AmigaOS Voodoo drivers, both 2D and 3D, are working with it.

But even if everything works like in WinUAE it's still a bad choice, even compared to 2D only hardware emulation like UAEGFX, SM501/502 and ati-vga:
- Voodoo has too few VRAM for AmigaOS 4.x.
- It's HW 3D is only supported in 16 bit modes, and probably isn't much faster, if at all, compared to a software only Warp3D reimplementation like Wazp3D on UAEGFX, SM501/502 and ati-vga.

@All

Is there anyone who tried to setup real (but virtual) serial port when use qemu ? I just tried to use com0com which create for me virtual com4/com5 ports, but when i simple do for qemu "-serial COM4" and then putty on com5, i can see that things start to throws on com port, through slower than expected, and after a while simple freezes.

Is there better alternatives or maybe i do something wrong ?

The point is to have EXACTLY com port after i run qemu to which i can connect via putty/scripts to acts with it as i act with real serial port.

Thanks!

@AmigaOldskooler

Gotta start somewhere eh Thanks for joining in! Hopefully more will start playing as May comes around

@balaton
Quote:
I corrected the post; it was translated incorrectly—my apologies. It’s not better; it’s actually worse—it’s slow and doesn’t have 3D yet, but it would make installation easier.

@joerg
Quote:
How could I do that if I don't know what the graphics/rtg library does and there's no source to check? But the GfxBench2D test just copies blocks on the screen around and there's a difference in that with ati-vga and sm501 so I'd try to understand that first.

@smarkusg
What binary patch and what GPL driver? Doesn't it use the 3dfxVoodoo.chip driver that comes with AmigaOS? Then you should not need any patch for that but it may need an actual 3dfx ROM for the card which may not be distributable again. If it comes with a separate driver then does 3D work? If not what is better about it than other 2D cards? Maybe it's slow because you have NOBLITTER=Yes so it's just used as a frame buffer? I think Voodoo is quite limited by the capabilities of that old card so it's probably a dead end anyway.

Maybe amigaboot does not check bootable flag because that's for something else. A bootable partition is what can be SYS: but the Kickstart files can live on a separate boot partition like on pegasos2 where the firmware can't read the file system used by AmigaOS so it may need boot a partition for Kickstart. That boot partition is probably not set bootable because it's not the SYS: volume but amigaboot still has to read Kickstart from there.

@balaton
Quote:
Yes. There is a problem with that. Some minor issues have already been fixed.
The driver isn't fast, but since it's probably the only one under the GPL license, it could be added (created) as a binary patch to the PEG2 and A1 installation discs. After purchasing the license,
you can download the ISO file, add the binary patch (Add monitor preferences), and boot the system.
Any System updates do not interfere with the operation of the system or the Voodoo3 driver.
Even if the Voodoo3 is slow, you could upgrade the system to U3 via updates and then install whatever you want.


One issue is the patch for QEMU. For now, the author is creating binary versions of QEMU (unofficial)
Time will tell how this plays out