@samo79Quote:

Copy that. And if you have Sam440ep-flex with PCIe HD card, it is even bigger need ( SDL is relatively slow there ).

And I don't know how complex is it, but very nice bonus is also have some native acceleration ( except SDL ) with amiGfx. ( like MorphOS have functional parameters "amiga.use_overlay=yes" and "sdl.use_gl=yes"

Only idea form non-coder

@kas1e

For now AmiGFX version is almost mandatory on Sam machines, SDL version runs but a bit jerky expecially in some bigger games or when running AmigaOS 3.1 even with JIT enabled. maybe it will faster with SDL2

@kas1e

Well, I can’t do what I want to do with SDL, so choice is simple.

@LiveForIt
Quote:

Probabaly because those who works on, were expected that SDL will be the main one, and ditch amigfx one.

Honestly speaking, our SDL2 today is absolutly native os4 library, so maybe it worth just to migrate to SDL2, and not worry with AmiGFX anymore.. Through maybe AmiGFX is good for very old machines..

@kas1e

Quote:

SDL is fine, but not AmiGfx, don't know why that is.

@kas1e

Quote:

Already done in mplayer, so maybe not a lot of work, if we only need cut & paste a bit.

Quote:

Not sure, maybe it does, it does detach the bitmap from window, so maybe less interference from intuition. Primarily it stretches output to screen, so it fits so does matter what resolution you pick.
And allows you to resize the window, if you think graphics is bit too small.
Technically its extra work, but only done on VSync, so does not add a lot of extra work, and the operation is a GPU operation, so does not effect CPU emulation much.

@LiveForIT

Quote:

Is there anything wrong with ? I currently checked and my os3.2 runs in fullscreen 1920x1080 on x5000 via euae. That of course via SDL, maybe amigfx have issue with ?

Quote:

You mean when in amycgx mode ? Because SDL one have iconify already.

Quote:

You mean usuall os4 gadget called "rezie to screen" ? Or you want to make special button somewhere ?

Having scaling algos will be nice as well (i.e to have old demos to run on 1920x1080).. But that all already a lot of work.

Is added compositing improve anything in terms of speed and whole rendering ?

@kas1e

Yeh.. I was thinking about spending some time on it, it shamefully bad.

The native GFX was always a lot faster than SDL build, don't know why..

the native GFX build lacks P96 Gfx emulation, that needs to be added.

On my list:

* Add drag & drop support for ADF.
* Get EUAE to remember last floppy path from ASL.
* Look at P96 emulation.
* look at BSDScoket emulation.
* Look at SCSI emulation, never got CDROM auto detected.
* Smart refresh, active / none active window (different task pri, frame skip.)
* Iconify button in window frame.
* Fullscreen button in the window frame.

Don't know I will successful on all, any improvment is improvment.

what I will not do, is spend time on updating the EUAE core, chipset emulation etc.

Quote:

Maybe, some of the CGX stuff in it, maybe its causing problems.
Should maybe be removed and cleaned up.

Quote:

Almost all of that is done already.
Pretty sure common parts are ok, so I don’t need to look at this.. only the Amiga parts can be sloppy.

@LiveForIT
Find out that you've been tinkering with the EUAE for now, and see that you already use the latest version with the ppcjit and salas00 addons, and that you added compositing support there.

So I want to ask: do you wish to spend some time on it, or is it just for your own pleasure to add a few bits and be done with it?

I ask because some things irritated me for a long time in our old UAE, but one in particular stands out even now:

When you run anything in EUAE in fullscreen mode and then switch to the workbench and scroll the workbench down, graphics output from EUE just stops. You can also move the workbench screen up and down to make it work. When it stops, EUAE's graphics output stops as well. I feel like a MS-DOS app rather than an AmigaOS4 app. :) Maybe that's already fixed automatically when you add compositing?

And, while I understand that no one wants to spend that much time on it, there needs to be a lot of cleanup of the entire EUAE source code: to open and close libs in the correct places, to initialize all unitialized values, to build it using gcc 11.3 and fix all of the warnings it throws, and to replace depricated functions too.

More of it: I always dreamed that it would be really good if one could just put the current SDL1 code out of the code mess into some separate file and then create another one for SDL2. So, to make it easy to completely ditch SDL1 in favor of SDL2, That will bring a lot of new functionality and auto-fix some bugs, and you will most likely be able to use compositing over it in places where your own didn't work, for example.

Here I did a test with Browservice
with Odyssey to use HTML5
If anyone is interested, I'd appreciate it.
Now it is stable I have to make other changes always for WinUAE
Works well, now the base is ready

Browservice now uses the audio of your PC directly.
The card is completely disabled in WinUAE
this increases the speed.
Other small changes also on Odyssey because in this case many functions are useless.

Clearly something would be needed to make better use of "Vulkan.dll"

Or something similar to a plugin that can interact with WinUAE from the graphical side.

You really need an external plugin, at least that's my idea.

Thank you

https://www.youtube.com/watch?v=Qls2boXEI4g&t=700s

Thanks for the bug report. I can confirm this has now been fixed and we will get the updated version out on Updater tool soon.

We will always try to fix any bugs swiftly to maintain a high standard for the Commands

@Reynolds

You are right about SLB. It's installed as part of partitioning the drive for OS4. Is the drive supposed to have OS4 installed? Because here it looks blank. There is no bootblock found on it.

I agree with sailor about serial debug. Unfortunately these machines aren't very user friendly at times and require you to act like a hardware engineer if the hardware develops a fault. If there is an issue like unsupported video card it won't give you an error.

One thing to check is the date in UBoot with date command. It may need resetting. You can also use the help command to give info on other commands while in UBoot.

I think all the talk about IDE settings is confusing the issue. Which may have been set correctly in the beginning. You can use the UBoot menu and avoid the command line. Typing "menu" to bring it up is what I like to do. You may need to quickly press return as it likes to attempt booting. You can then check out the settings including IDE and change them in a more easier way. Why this isn't suggested more I don't know.

Also checking the IDE cables is a good idea. Despite transfer mode UDMA cables should be used with IDE socket and device in proper place. And in this case master only set. UBoot reads the devices fine so that should be good. If you see it hunting and printing dots on screen looking for IDE devices then it is suspect.

Is the RAM installed known to be working before? If it has been changed it needs to be compatible. Unfortunately locating the correct ram may be rare these days. Technically these are server boards in design so need server ram. It should be ECC and registered if you can find it. They can take up to the full 2GB in 2x 1GB sticks. But that is a rare working example.

You can also test this I released years ago. BootMemTester. In case it detects some ram issues. Can write to a DVDRW or USB stick as examples. But USB needs formatting as Amiga first.

http://os4depot.net/?function=showfil ... ardware/bootmemtester.lha

You can also use the Linux net installer I compiled for a quick memory test as well. Why I suggest this is that the Linux kernel is good at detecting memory faults. You can write this directly to CD/DVD or USB. If you have a spare USB key around you can erase for testing then easiest may be using any program to write the image directly to USB key. Insert in a working USB port, reboot to Uboot if needed, then type:


https://sourceforge.net/projects/amiga ... x/files/debian-installer/

@LiveForIt

Good idea. Played with AUX shell in the 68k days.

Yes my solution is to also use the standard version. The AmigaKit version is unofficial anyway. They might as well have used AROS as source since it's not the real original Dir.

It's awkward as I don't think it can keep a white list but I tick off all the extra commands when updating with Updater.

@kas1e

Quote:
Yes, that's right.

@abalaban

thats not a problem, its not blocked.

using TCP you have no password protection,
I think also if the TCP connection is broken, then the shell is closed.

@LiveForIt

I did the same using TCP: instead of AUX: thus leaving the serial for debug purpose

@MigthyMax

install putty on your pc,
and get null modem cable, if don't have one.

i have usb to rs232 adapter in PC.
speed is: 115200

@Raziel

Quote:

That's the plan.

Quote:

I don't know. I haven't studied the compatibility topic. AFAIK SDL3 API is not stable yet, so it's not for end users. Maybe in 3.2.0?

As to Quake 2 i am currently preparing an update.

Features:

- mods work again, currently i have installers for 18 mods
Plus 3 level packs - more mods will come later but focussing
On the update now
- ogg vorbis music playback added
- full AmigaInput support added
- several bugfixes
- hopefully cd audio fixed (working on that right now)
- hopefully gles renderer (still on my todo list) additional
To the old style minigl renderer

Best regards,
Steffen

AUX console device to serial port. So you can can use shell via serial. Afaik.