@mcleppa

Quote:

Ok I understand now. Needed to refresh my memory. I was aware there was a LPR driver but I don't recall testing it as my X1000 is connected to my printer over USB.

Quote:

So checked and my printer supports PCLm and ARF. PCLm looks interesting as it's some kind of PDF format. So apparently my printer is better than I thought it was for a budget home model.

Quote:

I had read about that years ago. I'm sure my HP does support it. But that is not through network so not relevant to IPP in this case.

Quote:

To my knowledge NotePad would just dump text to the printer through the driver. You could likely find out by extracting it from the prefs file it uses. But that limits it to NotePad only so other text editors printing won't use it. There's ways to find default font. I know the non-proportional default font is in GfxBase->DefaultFont after asking around, which is used by the CLI.

IntuitionText is probably the best way. I've used that to grab text sizes when calculating a layout. Text() function could be more direct but Gfx is made for bitplanes while Intuition can be used for pixmaps transparently. It can also provide a default font. But for single colour printing a bitmap may actually help. If PCLm supported basic text you could have just encapsulated it inside a basic PDF, but it looks like it has the same raster limitation.

Quote:

PS would have been accepted by earlier printers over direct connection. IIRC PS was supported before PDF. As PS was suited for being a printer PDL while PDF was suited to viewing documents on screen.

Quote:

That would create a dependence on Enhancer but these days some OS components in the OS4.0 days are now depreciated and moved into Enhancer from OS4.1.

Quote:

Ah yes, I recall using AmiPS and AmiGS to print. They aren't very well integrated in the OS. Well, an add on really. The Amiga printer system is very old. It works backwards to how things work today, as you need to manually select and install the driver. And the printer device API has no concept of what print job is. I found this out when developing my HP_Photosmart driver based on the HP printer source. I had to work around it somehow as clients tended to send discrete dumps to the printer device, so most printouts were writes of various data.

It's going back years but I recall some things about AmiGS/AmiPDF and just checked then to refresh myself. So you could chose Workbench driver or custom driver and direct device. Workbench driver would go through printer device but other drivers which included PS, PDF, images and specific printers are sent to DOS device. It defaulted to PAR: but that was rather obsolete by then. PAR was old, lol. I had some alternate called USBPRT: or something that diverted to usbprinter.device. So it sent it to the printer direct as possible without involving printer device. A NETPRT: or AIRPRT: could be conceived in the same way. AmiGS and AmiPDF are really just facades for the ghostsscript command. The way they work is rather sloppy as they invoke a CLI command to do their dirty work. That may be acceptable on an OS like Linux where it lives on CLI commands, since it wasn't designed as a desktop OS; but AmigaOS is more integrated like Windows, and there should be a library acting as driver to handle it. It was a bit of a hack and the interface was messy with needing to deal with old DOS devices.

For a number of years I wanted to write a PSPRT: DOS driver. This would have accepted PS as input but would have rasterized the output to a non-PS printer. So it would be a PS to PRT converter you could say using printer device. It would have used ghostsscript command to convert PS to a raster so would have been a bit of a hack in the same way. But I never got around to it. A few word processors could output PS and there is the Workbench PS driver. So it looks like my printer supports stripped-PDF. That's useful, but still not much sends PDF on Amiga, so would need converting from graphics to PDF I would think.

@Maijestro

Cool. I will definitely follow your channel and I look forward to you highlighting your A1222+.

Even though I have X5000, I kind of want a A1222+ as well. Maybe because of the size.

In the qemu 9 Windows 10 etc. version, the emulated restart or shutdown of the machine no longer takes place from the menu. (OS 4.1)
Probably whoever compiled the package for the Windows version forgot to include it.
In previous versions it worked.

@skynetQuote:
Once is enough to configure ram-handler.

Kind regards,

Francis

Hi,

Do you have to do this every time you start the Amiga or once is enough?

@MaijestroQuote:
Just open a Shell and enter:



That should do it.

Kind regards,

Francis

@Hypex

Quote:

Yes, this is due to my program supports only ipp at the moment, this is due to this protocol is well documented and is the best chance to support as many printers as possible. Most printers you buy today supports this protocol.

When finished and program is working fine with this protocol, I might add support for the other kanguages as well.

Quote:

Yes, most new printers does not support direct ascii printing trough ipp, but most of them support raw printing still. So I can dump text to printers trough the raw printing port, if sending text trough ipp I need to convert to rasterfile first.

You are right in that converting text to graphics require a lot of information of fonts used etc.. And f.ex printing from notepad I haven’t found a way to retrieve font information. So my plan is to just use a predefined font and size at the moment. I am using IntuitionText for converting to bitmap, which makes the work easier for me.

Quote:

Most ipp printers I have used, does not support PS, but the formats they usually support is pwg-raster and jpeg formats.

If GS this is updated trough enhancer that would be great, and then I probably haven’t installed it, because my version of GS sometimes fails converting pdf’s.

When testing and prigramming this printer device this is for me what looks like is happening:When printing from AmiPDF or AmiGS it sends command to GS trough amiga_printer device of GS and communicates trough Exec msg, GS creates graphics trough printer.device which then again is sent to the selecter printer driver. This driver decides what to do with with the graphics, in my case it is converted to raster format, this will then be transferred to a new device, in my case airprint.device this device sends it to printer in the correct format.

@pvanni

Status of airprint is that it is still under development and testing. So far you can print pdf, ghostscript and jpeg files, also printing from Odyssey. Also supports ssl now. Not bugfree yet, but works ok for most users, but experienced some crashes for some.

Progress has been going somewhat slow due to little spare time to work on it, but working on it as soon as I have time 😀

At the same time I have also been working on Airscan.

Added ssl support to that as well + some other features, this version is soon ready and will be uploaded to os4depot this month.

@dfstudiosQuote:

Where do I have to enter it in the shell, or how did you do it?

@MamePPCA1

That doesn't sound like a good omen. Giving it 7 years and say it will die. That's not how you give your customers confidence!

If your X5000 still works the hardware should still be good. But RAM, cables and HDD can degrade. Dust can accumulate. In particular RAM sticks can collect micro-grime just sitting there. Even just pulling them out and back in can help. Otherwise removing and cleaning the contacts can be good. I replaced the RAM and SATA cables in my X1000 when I saw signs of instability like crashing on boot. After replacing the battery.

While I don't think the X5000 is dying just yet, 7 years is a long enough time for mechanical wear on a harddrive. Be good to check the smart log for any issues. But OS4 only has a smartmontools command I know so having Linux with a GUI is just easier.

So you have Enhancer on CD and that should be a way you can get access to your files again. In the least it should have a working SmartFilesystem and PartitionWizard. You could try copying files or installing. Best to backup pendrive on another computer as a full image backup just in case.

SmartFilesystem should be easily found in the installation files under Kickstart drawer on CD. Then just copy over the top of the existing one. On the pendrive.

Another way, and this may be easier, is to simply install Enhancer on the pendrive. You may need to do more clicking off for options you don't need if you just want to update Kickstart. Or you can just install most or all to pendrive.

@balaton
Quote:VRAM access is slow because it's accessed in tiny parts, at best 128 bits (if the AltiVec registers are emulated with 128 bit host registers) on G4, and only 64 bits on G3 and 4x0.

Real Sam4x0, X1000, X5000 and A1222 use larger DMA transfers instead. Less PCIe overhead = much faster speed.

There are 2 ways DMA is used:
1. GPU accessing DRAM with DMA (GART).
2. CPU accessing VRAM with DMA.

1. should work with QEmu VFIO gfx cards, if Hans creates special QEmu drivers with GART enabled.
But it can only help if the GPU does all rendering, which may be the case for Warp3D and the GPU video decoding and playback library.
It doesn't help at all, except for faster command submission, for the AmigaOS mixed CPU + blitter gfx API which was created 40 years ago for 1-8 bit planar screen modes.

2. is impossible on G3 and G4 CPUs, real and emulated.
Sam4x0 real hardware uses DMA, but QEmu emulates the 4x0 DMA with memmove() and the result is that the much larger DMA VRAM accesses the guest OS is using are splitted into tiny 64 bit parts accessed by the host CPU which is extremely slow.
There is nothing you can do for G3/G4 AmigaOne/Pegasos2 emulation, but if you can fix the 4x0 DMA emulation and change it to using host DMA instead of the host CPU, as well as the other problems in the Sam460 emulation to get it working at all, VFIO would be much faster.

@balaton
Quote:
Of course it doesn't. It's the CPU and/or PCIe controller that does the merging. Whether it does or not depends on what code the JIT compiler generates.

Quote:
I could create a special test version of the driver, as Joerg suggested. Let's get some benchmark results for the host machines first, so we have some reference numbers.

Bear in mind that the driver's GART is only used for command submission and transfers done by 3D drivers. The graphics.library will still use CPU-based transfers. And, as I said, the graphics.library does a lot of CPU based rendering.

Hans

Or you get it from Aminet. The one on OS4 depot is outdated, i see.

@nikitas
There seems to be no excessive number of interrupts so it's not slowed down by that and the profile showed that most time was spent in a TB that probably accesses some VRAM. I don't know a good way to find what's in that TB. Maybe you can try 'perf mem record' as you did first but I could not parse the results you've sent so try 'perf mem report' now as we did with the perf record output, maybe that shows something.

@joerg
What you write about real G4 and 460EX doesn't apply to QEMU so it does not explain the issue. I think previously we did tests with -cpu 750cxe vs the default -cpu 7457 on pegasos2 to see how much effect AltiVec has and we got the same results so it seems it does not matter that much (at least in general, maybe some specific apps it could matter but not sure it does on QEMU; this could be tested more but both seems to work about the same now). Also alignment and cache differences between real chips don't matter, on QEMU it's all the same CPU emulation for all PPC CPUs, the only difference is the supported instructions and different MMU/exception model. The G3/G4 have an MMU where the guest passes the translations to the CPU in a table that can be looked up on TLB miss without exiting the guest code but embedded PPC needs to take an exception for that and this leads to additional synchronisation that makes it slower. This may be optimised a bit more but I think it will always make sam460ex slower than amigaone/pegasos2 or at least it is slower for now.

I don't know if the DMA engine of the CPU is used or not but that only exists on sam460ex and we could not test that as it does not work with the card tried so it's both not proven and would not help amigaone/pegasos2 machines that are otherwise faster so I'd rather find out why passed through card is slow on those and fix that instead.

Hi there,

In my quest to get an audio over HDMI solution for my A1222 setup, I've so far tried a couple of devices called HDMI audio embedders. These devices replace the HDMI's audio signal with that of another source, so I thought that I would be able to connect the audio output of the A1222 to add it in to the HDMI signal.

The first device I tried was a CYP model AU-11CA which I was able to get second hand for a decent price. It worked fine on my (full HD) TV with video and audio from the A1222, but I struggled to get a video signal on my ultra-wide monitor which has a native resolution of 3440x1440.









Granted this HDMI audio embedder is intended for full HD sources (there is also a 4K version of this device) so resolutions beyond 1920x1080 is probably asking a bit much. Lowering the screen mode resolution down allowed it to work, but I was unable to get any audio with it through my setup for some reason which I never got to the bottom of. I should probably point out that my main setup is a bit convoluted which includes a 4-way HDMI switch with audio extractor going to a sound bar via an optical TOSLINK connection.

The second device I tried (which does up to 4K) was this one which was under £40 brand new shipped from China. I don't know the brand or model for this one, but it does appear to be very well built:





The first thing that struck me about this one is how petite it is compared with the CYP one.

I had a bit more success with this one as I now had audio output to my soundbar, but alas it still didn't work with my monitor's native resolution. My guess is that these devices are more intended for TV use applications so ultra-wide resolutions may be a bit of a curve ball for them.

I also have a third device being sent out to me, so I'll see if I have any better success with that.

Kind regards,

Francis

@all

In the afternoon I discovered that the new music was way too noisy, so I realized that something must have gone wrong. It turned out that the last-minute changes to the custom converter were totally ill-advised and also buggy, so the converted music was affected by a horrible noise!
I have uploaded the fixed version now - download from the usual place: https://retream.itch.io/hertz-overload

@balaton
G3 and G4 CPUs are faster for calculations, for example unaligned (4 bytes, maybe even 2 bytes) 64 bit FPU loads/stores work, 4x0 FPU loads/stores cause alignment exceptions if an access crosses a cache-line boundary (not possible if correctly aligned, 8 bytes for double, but there was a lot of old AmigaOS software using only 4 or even 2 bytes alignment for double), have a better MMU without requiring a lot of exceptions like the TLB cache on 4x0, G4 CPUs have AltiVec which can make a big difference, etc.
But G3 and G4 CPUs are much slower than 4x0 for gfx card VRAM accesses because they don't have a DMA engine.

Some more GfxBench2D results from real hardware:
https://www.hdrlab.org.nz/benchmark/gf ... 2d/OS/AmigaOS/Result/1652 (Sam460ex, Radeon HD 7700 Series)
Copy to VRAM 300.43
Write Pixel Array 647.84
Copy from VRAM 54.09
Read Pixel Array 99.78

https://www.hdrlab.org.nz/benchmark/gf ... 2d/OS/AmigaOS/Result/2712 (A1222, Radeon RX Polaris11)
Copy to VRAM 146.82
Write Pixel Array 432.25
Copy from VRAM 6.75
Read Pixel Array 332.63

https://www.hdrlab.org.nz/benchmark/gf ... 2d/OS/AmigaOS/Result/2475 (AmigaOne, Radeon HD 7800 Series)
Copy to VRAM 50.71
Write Pixel Array 50.77
Copy from VRAM 6.33
Read Pixel Array 3.41

https://www.hdrlab.org.nz/benchmark/gf ... 2d/OS/AmigaOS/Result/2522 (Sam440EP, Radeon HD 7800 Series)
Copy to VRAM 38.85
Write Pixel Array 97.32
Copy from VRAM 26.56
Read Pixel Array 26.55

The differences between Copy to/from VRAM (CPU) and Write/Read Pixel Array (DMA, except on the AmigaOne of course) are independent of the gfx driver using GART or not, in the above results only on the A1222 GART can be used.

In the A1222 result the CPU Copy from VRAM is as slow as the fastest QEmu Pegasos2 result until now with a VFIO gfx card.
DMA Read Pixel Array is much faster on the A1222, but since there is no DMA Read Pixel Array on the QEmu Pegasos2 it's using the CPU and has the same slow speed as Copy from VRAM.

Of course the AmigaOne result is additionally slower because it only has PCI and a PCI->PCIe bridge has to be used, but it's the same on the Sam440EP and only the relative difference between DMA (none on the AmigaOne) and CPU VRAM copies are relevant.

@balaton

This time, while GfxBench2D was running its tests, I was typing those commands.

I don't know if they provide some more insights to you:

(Especially, I was typing "info irq" several times during GfxBench2D first tests)

info irq --> https://ibb.co/fD2f8P7
info mtree pt.1 --> https://ibb.co/gPSX2TW
info mtree pt.2 --> https://ibb.co/XV9rfxg
info mtree pt.3 --> https://ibb.co/vm7J2h4
info pci --> https://ibb.co/D8WCZ5m

@Hans
QEMU won't try to merge requests or set up host DMA for CPU accesses and it's probably out of scope for a JIT compiler anyway so it will try to do what the guest code does and translate that to host code. So if the guest code does byte/word reads host code will do the same. If guest code does block transfer or use the GPU's DMA then it should pass that on unless guest may use something that's not implemented and falls back to byte reads maybe. Without knowing what the guest does or which operation makes it slow it's hard to find the cause and fix it. Is there a way to enable DMA in the driver on amigaone/pegasos2 to test if that would work better? I think it was suggested before that at least on pegasos2 the chipset should handle cache coherency and at least on QEMU it should not be a problem as long as it's working on the host side so it might worth a test at least. If the sam460 version would use DMA then we could test that but it seems there are some problems with PCI emulation on that machine so that would need to be fixed first but I have no documentation on that so don't know what is wrong with it. I've tried to fix PCIe emulation on sam460ex but it would need some more work for which I have no time now.

@joerg
A DMA enabled pegasos2 build (or option to enable it) would be more useful because sam460ex does not work with vfio pass through currently and it's also slower than machines with G3/G4 due to the embedded MMU using a lot of exceptions which is slow on QEMU. I have a series posted on the QEMU list in which I tried to optimise it a bit but it did not make it much faster so it would still run slower than amigaone or pegasos2. I'm also not sure the CPU DMA engine has anything to do with this on sam460ex as the driver would use the GPU's DMA which should work with vfio as long as the IOMMU translates the addresses correctly but if the driver does not use it then QEMU will not be able to find out and do it instead of the guest. QEMU only sees guest code that it translates to host code but doesn't know what that code is doing. If it accesses emulated hardware it can know but for a passed through GPU it just sets up the BARs of the passed through card then the guest should talk to it directly. (I may be wrong as I don't know how vfio works in detail but I don't think it knows about what the guest talks with the GPU it just maps the GPU BARs into guest PCI bus and the rest is like on real machine.)