@kas1e
Quote:BBoot is GPL v2, therefore it never can get any support for my AmigaOS SFS versions.

Adding support for old SFS versions like 1.84, for example using the AROS GPLed SFS 1.84 sources, would be possible (after porting the AROS code back to AmigaOS), but since such old versions aren't compatible to current AmigaOS SFS versions any more that may not work either.

Results of a quick test with 8.1.0 rc.

Radeon 4850 results in a crash of the RadeonHD driver right after the workbench screen shows up on the display.
Radeon RX 560 results in a crash of QEMU.
Will post more details tomorrow.

@smarkusg
Thank's for your job.

Would you like to try SSH with AmiCygnix ?

I've tried everything and I haven't succeeded.

I log into the Linux terminal
but I can't open the Display inside AmiCygnix

Would you like to try ?

Since AmigaOldskooler seems to be offline lately (hopefully he's well) I've setup the competition thread for this month since we're starting later than usual.

Have fun with Breakhack & don't forgot to send a donation to walkero if you enjoy the game

Welcome to a new contest here on Amigans.net!

For the month of July & August as we started late in July, we'll be enjoying a Rogue like game called Breakhack.

The game is available for free on OS4Depot. It was ported by walkero recently. If you enjoy the game please consider sending walkero a donation.

http://os4depot.net/index.php?functio ... roleplaying/breakhack.lha

The rogue with highest gold wins this months gaming competition! Let’s play the Standard Game option. As usual post a screenshot of your high score here.

Good luck to all participants! Have Fun!


-----( Current Standings )-----

1. walkero -2,860.08
2. 328GTS -2,161.20
3. MartinW -1,734.76
4. Maijestro - 412.46
5.
6.
6.

@Maijestro

perhaps use wireshark to see whats happens.

@HansQuote:

Exactly with the same configuration I had tested yesterday last when I failed.



I could also use another FTP client I am not bound to FileZilla. It was just my first choice under MacOs. Since some could confirm that it works I will try it again later with another FTP client for MacOs. Maybe something that supports more the older standard protocols.

@Maijestro

On Macos and Windows it can be difficult. Although who knows - it might be possible.
On Linux, iptables comes to the rescue - here you can do all sorts of things with port forwarding and ip address masking ....

I changed the ports in ZitaFtpServer from 9000:9004 to 7000:7004
I don't know why since AOS4 it was showing that port 900x was busy


I didn't want to use "root" so ports < 1024 are out.
port forwarding 20 and 21 to 8020 and 8021

any client that supports PASV, and as port 8021 and ip 127.0.0.1

device rtl8139,netdev=mynet0 -netdev user,id=mynet0,hostfwd=tcp:127.0.0.1:8021-:21,hostfwd=tcp:127.0.0.1:8020-:20,hostfwd=tcp:127.0.0.1:7000-:7000,hostfwd=tcp:127. 0.01:7001-:7001,hostfwd=tcp:127.0.0.1:7002-:7002,hostfwd=tcp:127.0.0.1:7003-:7003,hostfwd=tcp:127.0.0.1::7004-:7004,hostfwd=tcp:127.0.0.1:7005-:7005

iptables (would need to be fine-tuned):
iptables -t nat -A OUTPUT -p tcp --dport 7004 -j REDIRECT --to-port 7004
iptables -t nat -A OUTPUT -p tcp --dport 7003 -j REDIRECT --to-port 7003
iptables -t nat -A OUTPUT -p tcp --dport 7002 -j REDIRECT --to-port 7002
iptables -t nat -A OUTPUT -p tcp --dport 7001 -j REDIRECT --to-port 7001
iptables -t nat -A OUTPUT -p tcp --dport 7000 -j REDIRECT --to-port 7000
iptables -t nat -A POSTROUTING -o lo -p tcp -j MASQUERADE

simply translated.
The client makes the connection by giving a non-localhost ip, the server sends him its ip 10.x.x.x. so he is not seen by the host. communication is redirected via iptables and fw qemu to the ftp server.

@Hans
For WinUAE and/or QEMU the best will be the one having single core to be fast as possible. Like 4ghz or so, but so far i for myself found only notebook with 3.5ghz single core which doing things fine.

Through, now i thinking about maybe getting the other one : the one having 2 gfx cards, and second one to be in something which will works with RadeonHD/RX drivers, and which then i can use as passthrough and have fully hardware accelerated emulation with all stuff like warp3dnova, etc. working.

This kind of emulation (with passthrough) will help to understand if we have issues with speed with w3dnova/ogles2 in some parts because of hardware, or because of drivers. At least it should point on something after some tests.

@balaton
Oh my ! bboot 0.2 works fine on real pegasos2 ! I can boot amigaos4 with it just fine, the same as it happens with amigaboot.of. That the output i have on serial:



And then usual output from the os4 kernel.

I compare time wise the execution, and with my IDE2SAta adapter and Sata disk i got this:

Amigaboot 54.9 (10/27/2022) - 36 seconds once amigaboot start execution of modules till working Workbench.

Bboot - 27 seconds once i type "boot hd:0 bboot.fth" till working Workbench.

10 seconds faster !

Those figures with debug level enabled, so without it will be even faster.

Waiting now for the PCI to PCIE adapters to arrive to check with RadeonHD/RX. But so far it works with real pegasos2 for sure, which mean that users will have no needs for manual BAR fixes then.

Will check if it is possible from forth calculate size of the Kickstart.zip to avoid manual typing.

Did i understand right, that needs for kickstart.zip to be in the boot ffs partition and not the same as for amigaboot.of to be in the kickstart directory on the SFS disk, because bboot can't work with SFS ? only that ?

Probably a stupid idea but have you tried to set in hosts a domain for the localhost and use that with FileZilla? It might trick it and think that this is an external server.

ok, I'll try the release candidate.

One thing that I do not understand in the Pegasos2 interrupts discussion is the whole edge sensitivity. PCI interrupts are level sensitive. Therefore the emulated legacy interrupts consist of a begin and end interrupt message.

@Maijestro

I have good news and bad news.

Good: it does actually work with port-forwarding. I can upload files with curl
Bad: it doesn't work with Filezilla

Here's my hostfwd parameters: hostfwd=::21-:21,hostfwd=::9000-:9000,hostfwd=::9001-:9001,hostfwd=::9002-:9002,hostfwd=::9003-:9003,hostfwd=::9004-:9004

The problem is that Filezilla uses the PASV command for establishing a data connection. ZitaFTP tells it to connect to 10.0.2.15:900x (the emulated machine's IP), which is obviously wrong from the host machine's point-of-view. Filezilla detects that this is wrong, but for some reason doesn't connect to :127.0.0.1:900x instead. It's supposed to handle this case (it's common with NAT routers), but it doesn't seem to work with localhost.

The curl command notices that ZitaFTP supports the EPSV command** and uses that instead. Therefore it works. Filezilla should be able to use EPSV too, but seems to stick with PASV for IPv4. I haven't found a way to make Filezilla use EPSV, or correctly use the same IP address for control and data (which it's supposed to).

Hans


** Advertised as the "nat6" extension feature.

As for QEMU the faster single core performace is the better which may be hard to find in a laptop where energy efficiency is usually more valued than performance. And to have all that not expensive may be difficult. You know the saying: good, cheap, fast - pick two. But maybe some gaming laptop could have good performance but then not cheap or practical as a laptop so maybe you have to live with lower performance but otherwise convenient usage.

@geennaam
Quote:
Nobody knows until somebody tries. Try with qemu 8.1-rc0 or git master without any patches first then if it still has problems we can try patching IRQs. BBoot does not handle IRQs it will just set IRQ 9 for any devices not having an IRQ yet which is what pegasos2.rom seems to do as well but we never understood what exavtly causes the freeze so that's the next thing to debug. BBoot at least provides infos on how the PCI devices are configured at boot and we can compare those with different settings.

@geennaam

Unknown at the moment but I would say yes, you would because I don't think this changes any of that, the big benefit to us is that we should no longer need to mess about with Forth scripts. There are other benefits of course.

The only reason I'm not so sure is because it looks like bboot is patching a bit extra compared to what I was doing in Forth.

I'm not going to get time to test until after work this evening now.

@MartinW

Do I also need to apply this interrupt patch? Or is building from the latest sources enough.

Yes, that’s the idea. Bboot + VOF does all the hardware config and OS module loading. At the moment I don’t think it has worked for either of us that have tried on actual hardware yet but Balaton made a change last night that I’m hopeful will work. I’ll test shortly.

Dell 9500.. Forget anything else..

I'm sure what they mean by not too expensive, but a MacBook Air M1/M2 certainly wouldn't go amiss and you probably won't get anything better in this price range. From 900$

However, this LapTop is a bit small and whether it could cover your needs I don't know. We already know that the M1/M2 is very fast and would be perfect for Qemu.

On the other hand you could not use Linux, but there is already a project called Asahi Linux which is making a lot of progress and runs natively on Apple M1. I have already tested it myself, it works via dualboot and the most important things already work very well. The installation of Asahi Linux is very simple and automated.

If this would be interesting for you here is some information about it:

https://asahilinux.org/

Of course Linux ARM can also be virtualized under MacOs via third party software e.g. UTM. Which is really very fast and convenient, so you can use well known Linux distributions. Here is a selection of what is currently supported by UTM.

https://mac.getutm.app/gallery/

I use it myself with Parallels Desktop and Windows 11 ARM and it is really fast.

https://www.youtube.com/watch?v=SsiGzh4b7sg