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

@Maijestro

Runs on Linux using SLIRP

https://ibb.co/Jvb94yx

photo but may not be very readable. I will add later if anyone wants to know what needs to be done.

ps

I generally use sftp and on the Raspberry Pi where I have sshd I have data to transfer using RNOXfer under AOS4
This solution is not for me and I don't need it.

So ... challenge complete
Have a nice day

If I had to buy one I would go with
https://www.paradigit.ie/lenovo-ideapa ... 3mh/80064067/product/9474

I am pretty happy with my Lenovo laptop which I bought 10+ years ago. This one has 32GB of memory, which are onboard and I doubt they can be increased but I find it plenty for a laptop.

It also has a 16" screen with 2560 x 1600 resolution, AMD Ryzen 7
3.2 - 4.7(boost) GHz and an AMD Radeon 680M gfx chip.

When I buy a laptop my price range is around 900-1200€ with the plan of keeping it for a long time. That's what I paid for the one that I still have and use all these years.

@328gtsQuote:

A great game and I would have the opportunity to play it again because I want to be first with the most gold

I'm holding off for as long as possible, but might need to buy a new laptop soon(ish).

Any recommendations for something that AmigaOS 4 on qemu works reasonably well on, is good for Linux, and isn't too expensive?

Hans

@MartinWQuote:

hey hey feel free to do what you want

They already do enough with testing real graphics cards under Qemu and we already had first successes thanks to them. And the information we gained was and is very valuable. Balaton opened the door for us with BBoot, so we shouldn't stop with it now.

It's not my first priority either, but currently I'm dreaming about using 32 bit windows with Qemu and AmigaOs4.1, which would make the emulation close to perfect.

Sooner or later this problem will be solved as well.

I also want to thank you again for supporting the Qemu project, you are doing a really good job.

Since I "only" own a MacStudio as my sole hardware I can only support with videos I upload to YouTube and show people how it already works

@MartinW @Maijestro

Ooooo... a challenge !

makes an attempt

I haven't followed this thread for a while. Can someone give a summary of where we are right now? bboot will replace pegasos2.com + BAR script? Or is a script still necessary?

@Maijestro

You too have entered the external IP spiral
there is to go crazy

I just backed up Linux.
I can make other attempts
without doing damage.

with SSH now I try to do the "reverse" and see if it works.

@Maijestro

Quote:

That sounds like a challenge

Damn. I have enough things I'm meant to be doing already!

@balaton

Thanks - I'm sure I can find the time to test with the interrupt change at some point tomorrow. I'll look at the cross-compiler packages. I have no problem looking into stuff at all. I just ran out of time tonight.

[edit]

Quote:

Will be interesting to see how things are with the inclusion of setting the interrupt line when it's 0xff because I wasn't changing the reg values in my script I don't think. But that's not for any reason other than oversight. It might well have been something I should have been doing.

@MartinW and @all
Maybe it's easier to test if you don't have to compile it so I've just made a release 0.2 with the changes from today. Apart from now should work with zip created from macOS Finder it will change 0xff interrupts but keep the 64 bit type in the register value so it should replicate what your Forth script did. Let me know if this works better.

@walkero

great stuff thanks for the update

hey guys we're really late for July so let's pick a game to play fast!

How about brakhack a great Rogue game ported to OS4.1 by walkero from http://os4depot.net/?function=showfil ... roleplaying/breakhack.lha

whoever claims the most gold wins !

@logout

Welcome,enjoy the ride and feel free to ask here what you want.

We are happy and true Amiga users!!

@MartinW
No problem, it's not urgent so just let us know when you've found out something. Apart from IRQ I've meant these numbers:

where there are two changes for each bar:
the phys.hi ss field is changed from 3 to 2 (43001810 -> 42001810)
and the reg value is changed accordingly: 9000000c -> 90000008 clearing bit for 64 bit BAR type (see https://wiki.osdev.org/PCI#Base_Address_Registers) and I'm not sure bout this second change is correct. Can somebody tell what should we do here? Changing the first value is needed for the BAR to show up and not get the cannot handle SS == 3 or similar message in AmigaOS but what should the card be programmed for in this case? Should we still program it as 64 bit BAR?

@MartinW
Regarding network, that's not 64bit BAR but ROM BAR fix which is only needed because VOF gets that wrong so it would not happen with pegasos2.rom and therefore not likely to have any effect, also because I don't think AmigaOS uses the ROM (unless the pegasos2.rom runs that ROM which breaks something but you could disable with -device rtl8139,romfile="" and test that). If anything then maybe different IRQ mappings could have an effect but don't think there are differences in that but have to check the numbers to find out.

Leave it with me. I’ve stopped for tonight and have family over this weekend so I don’t know what time I will get so it might be Sunday before I get a chance. I’ll update when I can.

@MartinW
Maybe your distro has a powerpc compiler and that could work. i only needed to install gcc-powerpc64-linux-gnu and binutils-powerpc64-linux-gnu packages.

To make it change ff to 9 as well that change should be enough howeveer there's also a difference in BAR values written for 64 bit BARs the bit meaning 64bit is cleared and the BAR is programmed as 32bit BAR. I'm not sure if that's correct or we should keep the 64bit value in the PCI register and only clear the bit in the phys.hi number for AmigaOS to see the BAR. You can test this by booting with bboot using the pegasos2.rom (you need to put the zip on the guest disk and edit bboot.fth with the zip size then boot hd:0 bboot.fth. As seen from the log bboot will reprogram the 64 bit BARs as 32bit (what you did from the script before but besides changing the assigned-addresses property also changes the value in the PCI reg). If this now broke it then we likely only have to edit the assigned addresses value and do the same when not using pegasos2.rom. I can make these changes but don't know which one is correct so that's what you should test and tell me which one works. (Or if somebody like Hans has some insight could chime in, I don't know much about graphics cards.)

Regarding the network card, I have noticed that bboot doe fix a 64bit rom bar on the emulated RTL card so I guess it’s possible that might have been causing instability