Headlines |
-
nodeamiga.lha - development/language
Jun 14, 2026
-
openjpeg.lha - development/library/graphics
Jun 14, 2026
-
super_trevor_land.zip - game/platform
Jun 14, 2026
-
hwp_apng.lha - library/hollywood
Jun 14, 2026
-
hwp_iconic.lha - library/hollywood
Jun 14, 2026
-
hwp_oggtheora.lha - library/hollywood
Jun 14, 2026
-
hwp_svg.lha - library/hollywood
Jun 14, 2026
-
hwp_tiff.lha - library/hollywood
Jun 14, 2026
-
hwp_vectorgfx.lha - library/hollywood
Jun 14, 2026
-
hwp_xad.lha - library/hollywood
Jun 14, 2026
|
|
|
|
|
Re: New distribution based on 3.1 and P96 in development
|
|
Just popping in 
|
@AMIGASYSTEMQuote: AMIGASYSTEM wrote:@NinjaCyborg
AROS 68k binaries are of the ‘ELF’ type and therefore incompatible with Amiga OS.
On the contrary, OS 3.1 binaries are compatible with AROS 68k.
AROS 68k is based on Amiga OS3.1 and therefore does not support Amiga OS 3.2/3.9.
Regarding Zune, there is a native Amiga OS 3.9 version of ZUNE, which you can find installed on the AfA OS extension.
I am attaching an old screenshot of mine where you can see the difference in the ModExplorer GUI on OS3.9 AfA OS, first running with MUI and then with ZUNE.
https://www.amiganews.it/forum/downloa ... 3489a4bdb27&mode=view.jpg
AROS 68k is a system that requires a powerful machine. If you run AROS 68k on a real Amiga, it will be too slow to use. You should probably verify before stating as fact. First AROS builds default to elf however all AROS MC68K apps can be run through elf2hunk to produce AmigaOS compatible Hunk files. Second of AROS main goal is AmigaOS 3.1 API compatibility not limited to.
|
|
|
|
|
|
Re: Odyssey 3.0 Alpha vs 1.23r5
|
Posted on: 2025/11/1 19:28
#2
|
Just popping in 
|
@afxgroup what ever happened to this? I would assume this would be a perfect test case for it. 
|
|
|
|
|
|
Re: Trying to get some feedback.
|
Posted on: 2025/1/5 0:08
#3
|
Just popping in 
|
@derfsQuote: derfs wrote:@terminills
Is it in your plans to allow emu68 for arm to be 'swapped out' for another emu-cpu? e.g. would it be possible to use the same EFI codebase for UEFI on amd64 with a 'emu68 for amd64' ?
Sorry if this was already mentioned as the formatting was difficult for me to follow Just wondering if your plans are dedicated to arm only or include other architectures in the future. That could be possible if someone wanted to create the 68k emulator for amd64.
|
|
|
|
|
|
Re: Trying to get some feedback.
|
Posted on: 2025/1/5 0:07
#4
|
Just popping in 
|
@NinjaCyborgQuote: NinjaCyborg wrote:if anyone makes a pcie fpga card they should make sure it's OS4 compatible too... in which case just put the ARM CPU on there as well, or use a pi compute. 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.
|
|
|
|
|
|
Re: Trying to get some feedback.
|
Posted on: 2025/1/4 19:29
#5
|
Just popping in 
|
@NinjaCyborg
That’s not the scope of this… however there is talks of a pcie fpga card for that purpose.
|
|
|
|
|
|
Re: Trying to get some feedback.
|
Posted on: 2025/1/3 15:38
#7
|
Just popping in 
|
@walkero Quote: walkero wrote:Quote:Convert Little Endian ACPI data to Big Endian for compatibility with the 68K environment.
If you plan to use ARM-based systems, maybe this one is not needed, as I believe those supports both endians. But I might be wrong. 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:)
|
|
|
|
|
|
Trying to get some feedback.
|
Posted on: 2025/1/1 18:56
#9
|
Just popping in 
|
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.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/19 3:53
#11
|
Just popping in 
|
@terminills
Good news gpu pass through seems to work, bad news I only have one display card 😂😂😂
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/18 19:26
#12
|
Just popping in 
|
@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.
Edited by terminills on 2023/6/19 2:49:30 Edited by terminills on 2023/6/19 2:51:09
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/13 20:29
#14
|
Just popping in 
|
@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.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/12 17:54
#15
|
Just popping in 
|
@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. 🤷♂️
|
|
|
|
|
|
Re: What is the current situation with printing in OS4 on real hardware?
|
Posted on: 2023/6/12 11:31
#16
|
Just popping in 
|
@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.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/11 11:36
#17
|
Just popping in 
|
@Maijestro
Does pci pass through work?
|
|
|
|
|
|
Re: What is the current situation with printing in OS4 on real hardware?
|
Posted on: 2023/6/11 11:01
#18
|
Just popping in 
|
@HansQuote: Hans wrote:@all
I really wish that there were a developer or two (other than me) interested in improving the printer system. Printing systems have become a bit more standardized, so creating something new based on CUPS ia feasible. We don't necessarily need a CUPS port; just make something using the same APIs, or at least the underlying standards (e.g., IPP & PPD).
Hans 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
|
|
|
|
|
|
Re: What is the current situation with printing in OS4 on real hardware?
|
Posted on: 2023/6/11 10:43
#19
|
Just popping in 
|
@trixieQuote: trixie wrote:@Primax
Apparently, terminillis has had Gutenprint ported as part of the FinalWriter project. I wonder if that could be of any help once the OS4 port of FinalWriter is finished? Well it’s not quite that simple. Finalwriter implements ipp everywhere and ijs while being built to use a newer Ghostscript.
|
|
|
|
|
|
Re: Word processing
|
Posted on: 2023/6/4 14:44
#20
|
Just popping in 
|
@BSzili
In all fairness I’ve been using my copy for years 😂😂
|
|
|
|
|