Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
113 user(s) are online (75 user(s) are browsing Forums)

Members: 0
Guests: 113

more...

Headlines

Forum Index


Board index » All Posts (smarkusg)




Re: Sam460 which file systems can be used
Not too shy to talk
Not too shy to talk


@balaton

Not working
here you have a screen - qemu 8.1.5
SFS with ES does not initiate

Resized Image

Go to top


Re: Sam460 which file systems can be used
Not too shy to talk
Not too shy to talk


@joerg

Thank you for your information.
I may not agree with it, but you are the creator of SFS and owner of the rights to it, and I accept what you wrote and your decision.
I am grateful that you wrote it directly. There is also a version of SFS which you have made available on aminet/os4depot which can be used.

I also hope that all the things you described will eventually end in a happy ending for everyone.

Go to top


Re: Sam460 which file systems can be used
Not too shy to talk
Not too shy to talk


@joerg

If I understood correctly SFS could be run on the specific machines that AmigaOS 4 was running on.
I came across a topic on another forum where one of the new x5000 users has to edit the AOS4FE install CD to add SFS with ES to make it work for him.
JXFS has no restrictions and no assignment to the specific processor it can run on. This is also your file system.
Would it not be possible to remove this from SFS and make versions available as part of an ES update?
You are the rights holder for SFS , you have the source code.... I just don't know if you want to do this.

Thanks for the information regarding the NGFS author.
I will try to ask him somehow about the possibility of testing NGFS.
However, there may be a problem with this
I came across a thread in the hyperion forum about NGFS
The older version was only temporary for the X5000 as an alternative to SFS.
The second version as an update is available for X5000 and possibly A1222 owners.
It will not work on other machines.
NGFS is supposed to be available for other machines as AmigaOS 4.2.

If NGFS is again assigned to specific processors and machines in a few years, the problem will return like with SFS when a new machine or emulator is created.
Unless AmigaOS 4.2 is released or the restrictions are removed.

If I have misunderstood something or I am wrong about something please correct me

Go to top


Re: Sam460 which file systems can be used
Not too shy to talk
Not too shy to talk


@joerg

I have checked using the AOS4 FE Sam460 installation CD by modifying the files and changing the options related to diskcache.library.
SFS AmigaOS 3.x/m68k option works. The system installed correctly.
Checking the same thing several times sometimes comes in handy

It's a pity that SFS doesn't work in the version for AOS4. but it's good that the option with the one from AmigaOS 3.x is available.

Resized Image

Just a question.
> Ask the author of NGFS if you can get a current version of it.
Who is the author of NGFS ? Out of curiosity, I would ask if a version is available for testing. It doesn't even have to be the latest version.


Thanks for your help

Go to top


Re: Sam460 which file systems can be used
Not too shy to talk
Not too shy to talk


@joerg

Thank you for the information. I know I have already done the work but ...
I will do everything again according to your checklist - it's always better to check 10 times
- AOS4FE SAM460 installation CD , SFS with ES without diskcache
- Clean installation on FFS, replacement of previous versions from OS4Depot(2007) with and without diskcache.library.
- SFS replacement with AmigaOS 3.x/m68k and

If this list should contain anything else, please let me know
Thanks for your help

Go to top


Re: Sam460 which file systems can be used
Not too shy to talk
Not too shy to talk


@joerg

The problem is , it does not work on QEMU emulation Sam460.
I do not own pirated versions , I have legally zakuipony system for Sam460 and ES.
Believe me , it works everything even JXFS in write mode (without swapping binary files so that it is not that I have a broken system)
SFS does not work. I have checked almost everything possible.
If it is not a secret is something that can cause ze SFS does not work where other systems even yours (JXFS) works ?

Thank you for the information

*) about the consequence of using JXFS as a system partition I know. I've written in the past that it is purely my whim. I learned to use it by learning its problems.

Resized Image

Go to top


Re: Qemu GTK/SDL display problems
Not too shy to talk
Not too shy to talk


@Hans

OK. In that case, I won't disturb or clutter the thread.
Have a successful work and completion of the driver.
I wish you a nice day

Go to top


Re: Qemu GTK/SDL display problems
Not too shy to talk
Not too shy to talk


@Balaton

I would recommend that you first ask on some ubuntu formu.
If @Hans stardowefo kernel from the distribution and standard settings I think that someone can immediately verify whether he also has this problem.

Of course, there must be a description whether it is a "color" ubuntu such as Kubuntu, Xubuntu, Lubuntu if it uses any variation.
What graphics card (hopefully not nvidia) , what kernel, whether X11 or Wayland.... what desktop environment gnome, kde ...


I have checked at my place - all the problems that @Hans described (if they do not apply to what @Hans - Virtio is working on) do not occur at my place.

I remembered one topic, that a few months ago @Hans was thinking about changing his laptop and also had some problems... maybe jsete this is related to the current problems ?

Go to top


Re: Qemu GTK/SDL display problems
Not too shy to talk
Not too shy to talk


@Hans


I have no idea what kind of errors these are.
For a test, I quickly converted qemu with gtk,sdl,ppc options to x86_84
Test results - except for one case everything works

I do not know - maybe I do something wrong or it depends on the host ?

You wrote earlier , that you are not able to share your driver even if you wanted to for the test publicly because the owner of the rights is A-EON.
If there is no driver then there is nothing to check so generally speaking. You can only guess.


---
 
QEMU 8.2.1  na Linux x86_64 X11 "Ubuntu 20.04.6 LTS x86_64"
 
CPUIntel i5-3360M (4) @ 3.500GHz 
 GPU
Intel 3rd Gen Core processor Graphics Controller 
  
  
./configure --prefix=/usr/local/src/k/new-2022/qemu-8.2.1/bin --target-list=ppc-softmmu,x86_64-softmmu --disable-dbus-display  --enable-slirp
 
  1. qemu
-system-ppc 
  
  
#no virtio driver in the system, only sm501
  #  -display gtk,gl=on 
  # /usr/local/src/k/new-2022/qemu-8.2.1/bin/bin/qemu-system-ppc  -machine pegasos2 -rtc base=localtime -m 512 -device sm501  -kernel ./bboot -initrd ./Kickstart.zip -serial stdio  -vga none   -drive format=raw,if=none,id=rdb,file=/home/markus/Dokumenty/FS-UAE/Hard\ Drives/jxf.hdf -device ide-hd,drive=rdb,bus=ide.0 -netdev user,id=mynet0  -device rtl8139,netdev=mynet0 -L pc-bios -drive format=raw,if=none,id=rdb2,file=/home/markus/Dokumenty/FS-UAE/Hard\ Drives/AOS41.hdf  -device ide-hd,drive=rdb2,bus=ide.1 -append "os4_commandline serial munge debuglevel=7" -drive   file=fat:rw:/tmp/win32,id=ufat,format=raw,if=none -device usb-storage,drive=ufat   -display gtk,gl=on  -device virtio-gpu-pci
  
everything worksthe mouse works properly
 
 
#no virtio driver in the system, only sm501
 # -display sdl,gl=on  -device virtio-gpu-pci
 #/usr/local/src/k/new-2022/qemu-8.2.1/bin/bin/qemu-system-ppc  -machine pegasos2 -rtc base=localtime -m 512 -device sm501  -kernel ./bboot -initrd ./Kickstart.zip -serial stdio  -vga none   -drive format=raw,if=none,id=rdb,file=/home/markus/Dokumenty/FS-UAE/Hard\ Drives/jxf.hdf -device ide-hd,drive=rdb,bus=ide.0 -netdev user,id=mynet0  -device rtl8139,netdev=mynet0 -L pc-bios -drive format=raw,if=none,id=rdb2,file=/home/markus/Dokumenty/FS-UAE/Hard\ Drives/AOS41.hdf  -device ide-hd,drive=rdb2,bus=ide.1 -append "os4_commandline serial munge debuglevel=7" -drive   file=fat:rw:/tmp/win32,id=ufat,format=raw,if=none -device usb-storage,drive=ufat   -display sdl,gl=on  -device virtio-gpu-pci
 
 
everything worksthe mouse works properly
  
  
  
 
#no virtio driver in the system, only sm501
 #  -display gtk,gl=on  -device virtio-gpu-gl-pci
 # /usr/local/src/k/new-2022/qemu-8.2.1/bin/bin/qemu-system-ppc  -machine pegasos2 -rtc base=localtime -m 512 -device sm501  -kernel ./bboot -initrd ./Kickstart.zip -serial stdio  -vga none   -drive format=raw,if=none,id=rdb,file=/home/markus/Dokumenty/FS-UAE/Hard\ Drives/jxf.hdf -device ide-hd,drive=rdb,bus=ide.0 -netdev user,id=mynet0  -device rtl8139,netdev=mynet0 -L pc-bios -drive format=raw,if=none,id=rdb2,file=/home/markus/Dokumenty/FS-UAE/Hard\ Drives/AOS41.hdf  -device ide-hd,drive=rdb2,bus=ide.1 -append "os4_commandline serial munge debuglevel=7" -drive   file=fat:rw:/tmp/win32,id=ufat,format=raw,if=none -device usb-storage,drive=ufat   -display gtk,gl=on  -device virtio-gpu-gl-pci

everything worksthe mouse works properly
 
 
#no virtio driver in the system, only sm501
 #display sdl,gl=on  -device virtio-gpu-gl-pci
  # /usr/local/src/k/new-2022/qemu-8.2.1/bin/bin/qemu-system-ppc  -machine pegasos2 -rtc base=localtime -m 512 -device sm501  -kernel ./bboot -initrd ./Kickstart.zip -serial stdio  -vga none   -drive format=raw,if=none,id=rdb,file=/home/markus/Dokumenty/FS-UAE/Hard\ Drives/jxf.hdf -device ide-hd,drive=rdb,bus=ide.0 -netdev user,id=mynet0  -device rtl8139,netdev=mynet0 -L pc-bios -drive format=raw,if=none,id=rdb2,file=/home/markus/Dokumenty/FS-UAE/Hard\ Drives/AOS41.hdf  -device ide-hd,drive=rdb2,bus=ide.1 -append "os4_commandline serial munge debuglevel=7" -drive   file=fat:rw:/tmp/win32,id=ufat,format=raw,if=none -device usb-storage,drive=ufat   -display sdl,gl=on  -device virtio-gpu-gl-pci

everything worksthe mouse works properly
 
 2. qemu
-system-x86_64
 
#-device virtio-gpu-pci  -display gtk,gl=on
#./qemu-system-x86_64 -accel kvm -m 2G -cpu max  -cdrom /home/markus/Pobrane/Commodore/Fedora-Workstation-Live-x86_64-39-1.5.iso -device virtio-gpu-pci  -display gtk,gl=on

everything worksthe mouse works properly
 
 
#-device virtio-gpu-gl-pci  -display gtk,gl=on
#./qemu-system-x86_64 -accel kvm -m 2G -cpu max  -cdrom /home/markus/Pobrane/Commodore/Fedora-Workstation-Live-x86_64-39-1.5.iso -device virtio-gpu-gl-pci  -display gtk,gl=on

everything worksthe mouse works properly
 
 
#-device virtio-gpu-gl-pci  -display sdl,gl=on
 # ./qemu-system-x86_64 -accel kvm -m 2G -cpu max  -cdrom /home/markus/Pobrane/Commodore/Fedora-Workstation-Live-x86_64-39-1.5.iso -device virtio-gpu-gl-pci  -display sdl,gl=on
gl_version 0 compat profile
WARNING
running without ARB/KHR robustness in place may crash
qemu
-system-x86_64: ../src/dispatch_common.c:863epoxy_get_proc_addressAssertion 0 && "Couldn't find current GLX or EGL context.\n" failed.
 
doesn't work . it also doesn't work with gl=es =gl=corMaybe I'm missing something in the system

#-device virtio-gpu-pci  -display sdl,gl=on
# ./qemu-system-x86_64 -accel kvm -m 2G -cpu max  -cdrom /home/markus/Pobrane/Commodore/Fedora-Workstation-Live-x86_64-39-1.5.iso -device virtio-gpu-pci  -display sdl,gl=on

everything works, the mouse works properly

#-device  virtio-vga-gl   -display sdl,gl=on
#./qemu-system-x86_64 -accel kvm -m 2G -cpu max  -cdrom /home/markus/Pobrane/Commodore/Fedora-Workstation-Live-x86_64-39-1.5.iso -device  virtio-vga-gl   -display sdl,gl=on 

everything works, the mouse works properly
 
-----

Go to top


Re: Qemu GTK/SDL display problems
Not too shy to talk
Not too shy to talk


@Maijestro

Quote:
Edit:Here you can see the "-display Cocoa,gl=on" zoom-to-fit in full screen.


Yes there was a problem on QEMU macOS and Cocoa. MacOS SDL works fine on all machines and those running AmigaOS4.1.
SDL I also checked macOS with Fedoera Linux "./qemu-system-aarch64 -machine virt,accel=hvf -cpu host -smp 4 -m 4G -device virtio-gpu-gl-pci -device virtio-keyboard -device virtio-rng -display sdl,gl=core"
no problems.

I guess the problem on macOS and Cocoa was fixed already in the git version because I saw on the mailing list that you helped the developer to fix it. Thanks!!!

Go to top


Re: Qemu GTK/SDL display problems
Not too shy to talk
Not too shy to talk


@Hans
Linux - SLD works without any problem, there is no slowdown. Just don't know why you have "show-cursor=on" because then there are two indicators.


Resized Image

Go to top


Re: AmiUpdate 2.50
Not too shy to talk
Not too shy to talk


@samo79
I was once forced to learn Russian at school and it has nothing to do with the Polish language, starting with the spelling and ending with a completely different definition of words.
This is neither the time nor the place for a polemic on this topic, so I think I can end it this way.

Go to top


Re: AmiUpdate 2.50
Not too shy to talk
Not too shy to talk


@Rigo
Quote:
My aging memory tells me there /was/ a Polish translation, although how recent it is, I've no idea.

I couldn't find a translation anywhere.

@Maijestro
Quote:
Otherwise there is a Russian translation we could use, it is not your language but has similarities.

oj hurt ..very ..... very. such a statement.
You can not speak about religion, history and politics on the forum.
I can only write you , that it is absolutely not true and I encourage you to read.
No offense of course because maybe you were never interested in it.
Anyway, thank you for your willingness to help

I have already prepared the entire translation from scratch. even made the installer

https://github.com/smarkusg/amiupdate_pl/releases

but there are a lot of words that may not correspond or differ and errors.
Therefore, it was my request for people who know my language to verify it before uploading to os4depot.

Go to top


Re: AmiUpdate 2.50
Not too shy to talk
Not too shy to talk


I hope that I will not jam this thread with this entry.
I noticed that there was never a Polish localization of AmiUpdate.
I have prepared for the latest version - only I have a request to contact a person from my country or knowing my language who could verify its correctness.

Resized Image

Thank you

Go to top


Re: SDL2
Not too shy to talk
Not too shy to talk


@Capehill

First of all
Please note that I have an emulation so my test may not reflect the correct operation at all. However, it is possible that the problem is not emulation related and you may find this useful - that is why I am sending it to you.


I normally use via-ac97 in QEMU where I have the problem. I added another sb128 card (ES1370) as a test.
On the via-ac97 card the pt-clone and your AHI_DeviceAPI_RecordTest.lha test crashes.

On the sb128 card the pt-clone does not hang and your RecordTes spits out rubbish on - but there is something going on . On SDL 2.28 the system hangs when closing sampling on 2.30 everything works fine. It is possible, as you wrote some , that you fixed something extra.

here is a video of what it looks like on sb128 and SDL 2.30 rc2 (video quality may be poor)

https://streamable.com/bvlyc4


Hope it will be useful for you

Go to top


Re: SDL2
Not too shy to talk
Not too shy to talk


@Capehill
Quote:
I don't know, please test it ("works for me"). I fixed something but then there is some other driver (guess) issue, DoIO gets stuck, also with Martin Blom's test program. If you use HD Audio driver, you need to choose 16-bit recording.


I checked - I rebuilt the application to make it work SDL 2.30.0 RC2 .so

it continues to hang. I am not able to force the mode you asked about and I don't have HD Audio driver


-
HandleMouseMotionX:797 Y:908ScreenX797 ScreenY908
[OS4_RestoreSdlCursorForWindowCalled
[OS4_SetPointerObjectOrTypeForWindowSetting pointer object 0x60A6DC94 (type 16) for window 0x60A6A6A8
[OS4_HandleMouseMotionX:797 Y:907ScreenX797 ScreenY907
[OS4_RestoreSdlCursorForWindowCalled
[OS4_SetPointerObjectOrTypeForWindowSetting pointer object 0x60A6DC94 (type 16) for window 0x60A6A6A8
[OS4_HandleMouseButtonsX:797 Y:907 button:1 state:1
[OS4_HandleMouseMotionX:797 Y:907ScreenX797 ScreenY907
[OS4_RestoreSdlCursorForWindowCalled
[OS4_SetPointerObjectOrTypeForWindowSetting pointer object 0x60A6DC94 (type 16) for window 0x60A6A6A8
[SDL_SYS_WaitThreadWaiting for 'SDLAudioC3'
--

Go to top


Re: SDL2
Not too shy to talk
Not too shy to talk


@Capehill

Thanks!!!

Currently all the apps I build I try to link from shared library SObjs:libSDL2.so
How is your new update right away I am able to quickly check.

So far everything is working properly.

I have a question - in the list of changes I saw "Improve audio recording."
Has the recording problem you found been fixed yet ?

https://www.amigans.net/modules/newbb/ ... id=144820#forumpost144820

Thank you for the information

Go to top


Re: Do we have fast, accelerated, bug-free, supporting scaling SNES emulator ?
Not too shy to talk
Not too shy to talk


@Maijestro

about weak card using SDl2 I meant mainly hardware acceleration

https://wiki.libsdl.org/SDL2/SDL_RendererFlags

Here it is fairly well described in the first part of what is involved.

https://dev.to/noah11012/using-sdl2-2d-accelerated-renderering-1kcb

"The release of SDL2 added the ability to use the GPU. All this time, we've been doing software rendering which is where the CPU is doing all the graphics calculations. The CPU is fast but is not optimized for the doing the necessary calculations to output graphics onto the screen."

dIn addition, as I noticed myself with sm502 on qemu is still 16bit -> 32bit.
You can have a look in those files I sent @kas1e are executable files:
dgen = sdl1
dgen-sdl2 = sdl2
you will run the rom from them in the console. in my case sdl2 does not look terribly tragic it is around 33 frames.
sdl1 i have 54 frames. You will get this information when you close the application window in the console.
sdl1 will make you swich mode and sdl2 will stretch the window to the native screen. This is where you see the slowdown caused by using sofrware render.

I hope I have now explained it well.

and as for the "test" version - I will make the rest for myself regarding paths and other things
surely someone is able to do it better so anyone can do it who has the knowledge and desire.
everything is given on the platter


and as for the GUI if someone has the time and inclination it's very cool how they do

edit: 17.02.2024

https://github.com/smarkusg/dgen/releases





Edited by smarkusg on 2024/2/17 22:44:24
Edited by smarkusg on 2024/2/17 22:45:35
Edited by smarkusg on 2024/2/17 22:52:37
Go to top


Re: Do we have fast, accelerated, bug-free, supporting scaling SNES emulator ?
Not too shy to talk
Not too shy to talk


@kas1e

I have not changed anything in the sources yet. I compiled as it was originally for the test.
Added amigaos.c amigaos.h and started writing something, and have been playing around with compilation flags to see if it speeds up the program. But that's just testing...
It needs to be adapted for AOS4, e.g. the "Unix" paths need to be replaced with Amiga ones, etc. I did not have too much time to do it yet.
It currently runs only from the console.

But no problem if you need the source - here is the link

https://we.tl/t-hlT1j4DnvE

There is ./dgen and dgen-12(sdl2). I don't know how it will work for you.
DGEN under sdl1 is built with my sdl compilation where I have ALT+ENTER rigidly added - it currently conflicts with dgen sources where this sktórt also occurs.
dges-12(SDL2) is built by sdl12-compat - it works for me. But I don't know how it works on real hardware.

You can check or rebuild dgen on your libraries.

As for the version under SDL2 on sm502 under qemu it runs slow. But that's obviously not a SDL2 problem just a weak 2D graphics card.

Resized Image

Go to top


Re: Do we have fast, accelerated, bug-free, supporting scaling SNES emulator ?
Not too shy to talk
Not too shy to talk


@kas1e

I don't know anything about the SDL2 version. I can recompile this version I have on sdl2 via sdl12-compat and check.
But I only know if it's worth it. SDL2 runs slower on weaker machines.

I will let you know

Go to top



TopTop
« 1 2 (3) 4 5 6 ... 14 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project