@derfsQuote:

That could be possible if someone wanted to create the 68k emulator for amd64.

@NinjaCyborgQuote:



And then you’re back to limiting hardware. The main goal is to future proof and allow for a larger audience. I can buy an arm itx board for less than $200 with 8 gigs of ram. Currently I have a rock 5 itx but there are others.

@NinjaCyborg

That’s not the scope of this… however there is talks of a pcie fpga card for that purpose.

@LiveForIt

Yes tianocore has been ported to many boards. Plus many boards are coming with uefi installed by default.
[*]Raspberry Pi 4 UEFI Firmware Images: This repository offers UEFI firmware for the Raspberry Pi 4, facilitating the use of UEFI-based operating systems.
[*]Raspberry Pi 5 UEFI Firmware Images: This repository provides UEFI firmware images for the Raspberry Pi 5, supporting boot from USB and SD card, HDMI display output, and limited ACPI support.
[*]Raspberry Pi 3 UEFI Firmware Images: This repository offers UEFI firmware for the Raspberry Pi 3, enabling UEFI-based operating system support.
[*]Raspberry Pi 4 UEFI Firmware by shift: This repository provides UEFI firmware images for the Raspberry Pi 4, facilitating the use of UEFI-based operating systems.
[*]Raspberry Pi 4 UEFI Firmware by doubleu-labs: This repository offers UEFI firmware images for the Raspberry Pi 4, enabling UEFI-based operating system support.
[*]64-bit Tiano Core UEFI Firmware Port for Raspberry Pi 4: This repository provides a 64-bit UEFI firmware port for the Raspberry Pi 4, based on Tiano Core.
[*]Raspberry Pi 4 UEFI Firmware by kramelec: This repository offers UEFI firmware images for the Raspberry Pi 4, facilitating the use of UEFI-based operating systems.

@walkero

Quote:

Not all, and they default to LE on boot which is where the ACPI tables are initially setup.



https://arace.tech/products/radxa-orion-o6

:)

@orgin

Thanks,

It might be a little too technical is but the crux of it all is essentially a modern cross between the Draco and Amithlon setup.

https://discord.com/channels/784428461 ... 98752/1322464794418221140

As this isn't specific to AROS and more to 68K I figured it would be safe to get opinions about it here too.

Porting Emu68 to EFI

Overview

This project is focused on adapting Emu68 to function in an EFI environment by splitting it into two distinct applications: a loader and the emulator itself. The loader will handle EFI compliance and initialization, while Emu68 will operate as a standalone 68K emulator. Additionally, a test program will be developed to validate ACPI data under Emu68.

Objectives

Develop an EFI Loader.

Create a compliant EFI application responsible for initializing and loading Emu68.

Ensure the loader handles hardware abstraction and passes necessary configuration data to Emu68.

Implement Basic Support for ACPI Table Parsing.

Parse ACPI tables provided by EFI.

Convert Little Endian ACPI data to Big Endian for compatibility with the 68K environment.

Split Emu68 and Loader into Two Applications.

Develop a standalone EFI loader to initialize and load Emu68.

Keep Emu68 focused solely on emulation tasks, with no direct hardware initialization.

Develop a Test Program for ACPI Data Validation.

Create a 68K-compatible program that runs under Emu68.

Validate ACPI table parsing and endian conversion.

Ensure compatibility and correctness of ACPI data for future use by AmigaOS/AROS.

Implementation Plan

Step 1: Develop an EFI Loader

Loader Responsibilities:

Create a standalone EFI loader responsible for:

Locating and loading the Emu68 binary.

Setting up the execution environment, including memory allocation and passing necessary configuration data to Emu68.

Use EFI protocols to handle hardware abstraction, such as accessing ACPI tables.

Basic System Initialization:

Ensure the loader initializes system resources like memory and storage using EFI services.

Set up a mechanism to pass ACPI and other hardware details to Emu68.

Debugging Support:

Include debug outputs in the loader to verify the correct setup of the execution environment.

Step 2: Refactor Emu68 for EFI Integration

Standalone Emulator:

Remove any bare-metal initialization tasks from Emu68, delegating these to the loader.

Ensure Emu68 operates solely as a 68K emulator, relying on the loader for execution context and data.

ACPI Table Parsing in Emu68:

Add support for parsing ACPI tables passed by the loader.

Implement endian conversion for compatibility with the 68K environment.

Ensure parsed ACPI data can be utilized by future AmigaOS/AROS 68K integration.

Execution Environment:

Verify Emu68 functions correctly within the environment established by the loader.

Step 3: Develop a Test Program for ACPI Validation

68K Test Program:

Create a test program compatible with Emu68 to validate ACPI data parsing and endian conversion.

Include routines to check the integrity and correctness of ACPI tables.

Integration Testing:

Run the test program under Emu68 in the EFI environment.

Log results for debugging and verification.

Deliverables

A standalone EFI loader application.

A refactored Emu68 emulator.

A 68K test program for ACPI validation.

Documentation for:

EFI loader and Emu68 integration.

ACPI table parsing and endian conversion routines.

Test program usage and expected outputs.

@interrogative

you may be interested in this.

https://eab.abime.net/showthread.php?t=119461

@terminills

Good news gpu pass through seems to work, bad news I only have one display card 😂😂😂

@Maijestro

it's a glorified command builder. I don't have amigaos currently so I posted it for others to test with.


helps build your pci passthrough config , download and extract the pegasos rom, and since it's available as a trial I did add the ability to download morphos(this can't be done for AmigaOS obviously.) so people can at least try it and hopefully help fix my bugs :D. However for my personal goal I'm trying to run as much hardware native as possible so I did not add HD image support.

Currently I'm trying to get it to automatically pass through as much hardware as possible otherwise all of your devices are selectable. Added logging to help debug my unbinding issues right now.

I have an end goal of being able to run it on a bare arch linux system and have it auto configure everything for you.

@walkero

here's a little script that I fumbled through and I'm sure it needs some love.

https://github.com/terminills/qemu_scripts/blob/main/run_qemu.sh

@walkero

I'm planning on testing a minimal linux distro and passing PCIE for my graphics cards, NVME drive and a sata drive this weekend. I will post my results.

@Maijestro

I guess I’ll be testing as long as I know what to buy. I have about 6 rx 480’s laying around those are supported? And then what version of aos4 do I need to buy? I have a spare amd ryzen 3900 system laying around too. 🤷‍♂️

@Hans

All of the detection etc is part of the ipp everywhere spec. A newer version of Ghostscript goes a long way towards implementing the required formats.


“ Required: IPP/2.0, DNS-SD, PWG Raster and JPEG JFIF file formats (JPEG only required for color printers)
Recommended: PDF, IPP-USB”

The bigger issue is compatibility with the printer.device for legacy software. Finalwriter uses its own print system so we’re able to choose how we communicate.

@Maijestro

Does pci pass through work?

@HansQuote:

You don’t need all of cups just enough to support ipp correctly. ipp everywhere requires all printers to support pwg raster format so therefore implementing ipp proper with pwg raster output you now support all of the modern “driverless” printers.

https://ftp.pwg.org/pub/pwg/candidates ... er10-20120420-5102.4.docx

@trixieQuote:

Well it’s not quite that simple. Finalwriter implements ipp everywhere and ijs while being built to use a newer Ghostscript.

@BSzili

In all fairness I’ve been using my copy for years 😂😂

@livebyfaith74

that was only the second pic of it running on AOS4. only a week ago it would close right after choosing the screenmode.

@afxgroup


technically it is a mui app now and it will be such due to compatibility with all platforms.