Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (joerg)

Bottom

(1) 2 3 4 ... 110 »

joerg

Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!

Posted on: Yesterday 18:28 #1

Home away from home

@Hypex
Quote:

So for the OS3.9 example it looked a bit sloppy. The Kickstart loads up, DOS boots and then an OS patch loads and reboots the machine. The reboot was a bit messy. And it wasn't a true soft Kick image, just patching existing OS3.1 in memory.

Wrong, OS3.9 includes updated, complete kickstart modules like exec, scsi.device, FFS, etc. which replace the old 3.1 ROM versions, it doesn't patch the OS 3.1 versions.
expansion.library starts only one kickstart module, the one with the highest struct Resident rt_Version, if several kickstart modules with the same rt_Name name are installed, ROM and RAM in case of OS3.9.

There are tools to extract the kickstart modules from "DEVS:AmigaOS Rom Update" and use them to build a 3.9 ROM, for example http://wiki.classicamiga.com/Kickstart_3.9
To get enough space for the larger, updated 3.9 kickstart modules you may have to remove something from the 3.1 ROM. For example removing workbench.library is no problem since it's not in the 3.1 ROM of the A4000T either but in LIBS: instead.

But it's getting way too of topic now, this thread is about CFE.

Topic | Forum

joerg

Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!

Posted on: 5/13 16:52 #2

Home away from home

@Hypex
Quote:

I recall the "SuperKickstart" disk. Though by that stage a Kickstart on floppy, especially larger one, would have looked slow and annoying.

I never had an A3000, but AFAIK it's ROM (Kickstart 1.4) can load the SuperKickstart (Kickstart 2.x) from a HD connected to the internal SCSI controller as well (a file in DEVS: on the boot partition), not only from a floppy.

Quote:

I don't quite recall the "LinuxOne" but just having that code looks like the catalyst for the myth.

Both Eyetech and bPlan/Genesi sold Linux PPC versions of their AmigaOS/MorphOS PPC systems.
Can't find a link to a Eyetech LinuxOne page, the other one was https://web.archive.org/web/2008051407 ... ww.genesi-usa.com/odw.php

Topic | Forum

joerg

Re: question about sii3512ide.device on pegasos2 and other amigaos4 hw

Posted on: 5/12 18:38 #3

Home away from home

@kas1e
Quote:

Find out today, that my sii3512ide while can detect on os4 fine 2 disks, can't detect 3rd disk (the one i use usually in ide2sata port of pegasos2 to boot from), with output like:

A 3rd disk on a SII 3[15]12? WTF?
The SII 351*2* and SII 311*2* are 2 port SATA controllers. Only the SII 311*4* controllers support more SATA ports: 4.
While there are some hardware revisions of the 3112 and 3512 which do have both internal and external (eSATA) ports, those are mutually exclusive, you can only use one of both for each of the 2 ports.

OTOH if you are able to lend out some ancient Amiga hardware from a computer museum like a VOB SpeedUp board (which I used about 35-40 years ago on my A1000s), or even just a much newer IDE-fix (Elaborate Bytes/Individual Computers), FastATA (Elbox), etc. converter, with matching PATA<->SATA converters/cables, you might be able to use 4 ports even on a 2 port controller, like with the 2 ports A1200 and A4000[T] motherboard PATA which can drive 4 ports with such adapters

Topic | Forum

joerg

Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!

Posted on: 5/11 15:05 #4

Home away from home

@Hypex
Quote:

The disk based Kickstart was more like the A1000 Kick, where it was loaded into memory from disk and locked in place. But, lacking the AmigaOS imagery of asking for Kick disk, as well as any minimal OS components such as Exec and trackdisk device driver.

It's not limited to the Amiga (later called "A1000") with it's 256 KB WORM for the KickStart, the A3000, at least early versions of it, used a "SuperKickstart" floppy disk for booting a 512 KB version AmigaOS (IIRC some 1.4 Betas and the 2.0 and 2.1 release versions) as well.
IIRC for my A1000s I had several modified Kickstart floppies with a 512 KB OS (256 KB original kickstart 0.9-1.4 + 256 KB added tools, extended features, debugging, tools, etc.) which used the 256 KB WORM + the 256 KB TrapDor RAM expansion for it.

Quote:

On top of this, people used to talk about the magic code in UBoot that booted AmigaOS, as if it was secretly hidden.

I never understood where that myth came from...
Maybe because of the (cheaper?) "LinuxOne" PPC systems sold by EyeTech as well?
Same hardware as the AmigaOne, just with a different U-Boot version which can only boot Linux but doesn't include the AmigaOS 4.x booting parts.

It was always, since about 25 years, secretly hidden in the public U-Boot sources

Official Denx U-Boot repository and several copies of it like
https://github.com/u-boot/u-boot/blob/ ... /AmigaOneG3SE/cmd_boota.c
https://github.com/u-boot/u-boot/blob/ ... t-1_0_0/disk/part_amiga.c


* (C) Copyright 2001

Edited by joerg on 2026/5/11 16:46:45

Topic | Forum

joerg

Re: Emergency Boot Partition

Posted on: 5/8 16:07 #5

Home away from home

@emeck
On the backup boot partition create a text file


:Kickstart/BootDevice

with the content "DH1" (without quotes), and add


MODULE Kickstart/BootDevice

to it's :Kickstart/Kicklayout file.
That way if you load the kickstart modules from DH1: AmigaOS will be booted from DH1: as well, without it only the kickstart modules would be loaded from DH1: but AmigaOS would still boot from DH0: and use it as SYS:.

The boot priority of the backup boot partition has to be lower than the one of the main DH0: one in Media Toolbox.
For example if the boot priority of DH0: is 0 you can use -1 for DH1:.

In U-Boot make sure the boot menu is displayed, most of the firmwares do have something like a "quiet", and/or a "(menu) timeout", env variable, which skips displaying it's boot menu and directly boots from the partition with the highest boot priority, but I don't know the variable names used in the A1222+ version of U-Boot.

Topic | Forum

joerg

Re: Make May AI Data-type month for OS 4

Posted on: 5/3 16:21 #6

Home away from home

@LiveForIt
Quote:

Not sure what, multiview support regarding font size, bold, and italic and so on, while you can read markdown no problem, you might want to generate a image format, to support UTF8 and all the formatting, but that is kind of a memory hungry solution. Or maybe you just want something converts it into ASCII 8bit encoded text, that can be loaded as a readable format without all that.

AmigaOS 4.x supports 32 bit Unicode text rendering incl. the usual bold, italic, underline, strike-trough, etc. styles, as well as subpixel rendering (unless the locale is set to USA or Canada or something else where patents regarding it apply and prevented enabling it in AmigaOS).
Check for example my text functions in OWB, using only AmigaOS 4.x functions (diskfont and graphics.library), no external libraries like libfreetype used/required.

Even more than 30 years ago Unicode and outline fonts with all styles were already supported, IIRC since AmigaOS version 2.1, but limited to 16 bit Unicode in the included AGFA Intellifont font engine (bullet.library).
What both AmigaOS 2.1+ and 4.x are missing is support for colour outline fonts. Required for example for current web browsers to display coloured emoji, but for a lot of other use cases the B/W implementations might still be enough.

Topic | Forum

joerg

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 5/2 20:04 #7

Home away from home

@smarkusgQuote:

Ranger

Another tool which can display a lot of internal AmigaOS data, more than Ranger, is Scout, but since it wasn't updated since about 20 years anymore you have to be prepared that using about every 2nd function of it on current AmigaOS versions does illegal accesses and crashes.

Much older, similar but even more detailed tools like XOper which were the best ones on AmigaOS 1.x/2/x.3.x m68k are unlikely to work at all on AmigaOS 4.x PPC.

Topic | Forum

joerg

Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!

Posted on: 5/2 19:23 #8

Home away from home

@Hypex
Quote:

It also looks like SLB had access to UBoot support for Ext2 where as amigaboot.of using the OF interface has no support for filesystems so handles it all itself.

Yes, SLB_v2 calls U-Boot functions for the ext2fs support.
There were 2 main reasons for the "SLB" boot method used on the AmigaOne SE/XE/etc.:
- Too small EEPROM for PPCBoot/U-Boot + additional AmigaOS file system loading and AmigaOS booting implementations, etc., even much worse on the µA1 with it's onboard R7000 GPU without a ROM, the BIOS for it is included in the U-Boot image instead (AFAIK compressed, but I don't know if gzip, bzip2 or something else, and maybe even other U-Boot parts had to be compressed on the µA1 as well to include everything required in the small EEPROM).
- Licence reasons. U-Boot is GPL and therefore closed source code, like the implementations for all AmigaOS file systems and ISO9660, couldn't be included in U-Boot itself but had to be moved into a separate binary (SLB/SLB_v2).

Adding an ext2fs implementation in AmigaBoot, if it can't use firmware functions for it like SLB_v2 does, may be problematic since no GPL code, for example nothing from the Linux nor GRUB ext2fs sources, can be used in AmigaBoot.
OTOH there may be other, free and usable for AmigaBoot implementations of ext2fs instead, for example in Net/Free/Open/DragonFly BSD.

Topic | Forum

joerg

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/30 15:01 #9

Home away from home

@smarkusg
Quote:

I corrected the post; it was translated incorrectly—my apologies. It’s not better; it’s actually worse—it’s slow and doesn’t have 3D yet, but it would make installation easier.

Why wasn't the Voodoo emulation from WinUAE used as base for the QEmu implementation?
The AmigaOS Voodoo drivers, both 2D and 3D, are working with it.

But even if everything works like in WinUAE it's still a bad choice, even compared to 2D only hardware emulation like UAEGFX, SM501/502 and ati-vga:
- Voodoo has too few VRAM for AmigaOS 4.x.
- It's HW 3D is only supported in 16 bit modes, and probably isn't much faster, if at all, compared to a software only Warp3D reimplementation like Wazp3D on UAEGFX, SM501/502 and ati-vga.

Topic | Forum

joerg

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/29 18:00 #10

Home away from home

@balaton
Quote:

The ati-vga currently does not run async (that's for future enhancement) but the sm501 also doesn't and it has similar usage of pixman and fallbacks so I don't understand why they behave differently. Either there's something the sm502 driver does differently or it's because of some difference between the sm501 and ati-vga that might be fixed if we found out what it is.

You should investigate the reason for the way too low VRAM usage with ati-vga.
graphics.library and the p96 .card/.chip drivers do support an unlimited amount of bitmaps swapped out to DRAM, but for using any of the HW accelerated functions of gfx drivers the bitmaps have to be moved to VRAM first, and constantly swapping bitmaps between VRAM and DRAM can explain huge slowdowns, especially for operations using large bitmaps.

Topic | Forum

joerg

Re: X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.02 NEW!

Posted on: 4/29 17:50 #11

Home away from home

@Hypex
Quote:

I can see it makes no sense from a user point of view to include non-bootable devices. Of course the boot flag predates a bootable Kickstart. I don't see any obvious variables it looks for. Perhaps they would consider adding this as an option.

What an ugly mess...
And i thought the old "SLB" method used on the AmigaOne SE/XE/µA1 and Sam4x0, which can no longer be used on newer systems for various reasons, was a bad hack already

But compared to what AmigaBoot.(ub|of) seems to do, like ignoring the RDB bootable flags of the partitions, it was an easy method that actually worked, across all possible boot methods supported by the hardware and firmware (TFPT, PATA, SATA, USB, CF, MicroSD, ..., supporting lots of different file systems, not only at least 8 AmigaOS ones but for example ext2fs for Linux booting as well, and ISO9660 El Torito for any OS, etc.)
Even the much worse method used for booting AmigaOS 4.x PPC on classic Amigas, with AmigaOS 3.0/3.1 m68k used as "Firmware", seems to be better than what AmigaBoot is doing on the Peg2, X1000, X5000 and A1222+ 🤷

Topic | Forum

joerg

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/28 16:23 #12

Home away from home

@balaton
Quote:

I guess you can test that with setting NOBLITTER in the monitor icon which should disable the driver functions and use the AmigaOS defaults

Yes.
Quote:

but I did not try that. But especially for larger blits doing it host side with native routines should be faster.

Depends on how the ati-vga emulation is implemented in QEmu.
If it's using an own thread running in parallel of the CPU and other guest hardware emulation it should be faster.
But if it's executed in the same thread, which seems to be the case for most hardware emulation in QEmu, i.e. stopping the emulated guest code, executing some host code, and restarting the guest CPU emulation, it's probably slower than guest code doing the same.

Topic | Forum

joerg

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/27 16:44 #13

Home away from home

@balaton
Quote:

There's something with BlitBitMap that I don't understand and could not find out what could cause this. It seems that smaller blits are faster with ati-vga but larger ones are slower which does not make much sense as sm501 is also using pixman similar to how ati-vga uses it and while ati-vga is a bit more complex it does not depend on size of the blit that is just passed to pixman. Without pixman ati-vga is a bit faster for me but the same slow down for larger areas still happen so it's not pixman related but don't know yet what it may be.

Did you implement all of the BoardInfo->Blit*() functions in your driver?
AFAIK nearly all BoardInfo functions in a P96 driver can be set to NULL on AmigaOS 4.x and a fallback function in graphics.library is used instead. For example for a very simple framebuffer driver. On real hardware with HW acceleration it's usually slower, but for emulation the graphics.library functions might be faster.
IGNOREMASK should be enabled (=YES), no matter if real hardware or emulation, which requires using a matching DEVS:Monitors, or using Kickstart/p96Config (not sure if that's enabled on all systems, or only used on Classic Amigas).
Might also depend on the AllocCardMem() and/or AllocBitMap() functions, which should return at least 32 bit aligned (or more if the (emulated) gfx hardware requires it) memory.

Simple example of the required VRAM for a FullHD Workbench screen:
1920*1080*4(32 bit)*4(4 images, see below)/1024/1024 = nearly 32 MB VRAM.
1st "image": The screen bitmap itself, i.e. the final result displayed on the monitor.
2nd: The Workbench screen backdrop image.
3rd: The Workbench root window image.
4th: The Workbench drawer window images.
Add some more screens of other applications and even without using anything requiring even much more VRAM like 3D or compositing, just using plain old 2D, you can easily exceed the 64 MB VRAM of a R7000 like the onboard one in the Teron Mini/AmigaOne µA1.

Edited by joerg on 2026/4/27 17:14:45

Topic | Forum

joerg

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/25 16:25 #14

Home away from home

@balaton
Even if it may not required because of DCC/EDID support it can still help to have a DEVS:Monitors icon disabling some gfx library/P96 parts QEmu doesn't emulate (yet):
- In @smarkusg's screenshot the "Dragable" bit is enabled, which doesn't work in your driver according to your docs (drag down a screen and display parts of another one, maybe using another resolution, or even different depths like 8/15/16/24/32 bit modes, behind it).
- DISABLEFAKENATIVE (not enabled in @Maijestro's screenshot) should be disabled with DISABLEFAKENATIVE=YES, as long as 8 bit CLUT modes aren't supported completely.
- INTERRUPT=YES, or the probably still supported alternative NOINTERRUPT=NO, shouldn't be used for gfx drivers without VBLANK interrupt support.

Topic | Forum

joerg

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/25 16:25 #15

Home away from home

Topic | Forum

joerg

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/25 15:05 #16

Home away from home

@balaton
Quote:

I think your monitor icon is likely ignored as I found it has to match the driver name so it should be Radeon with CMPLENGTH=6

That's only for Hans' RadeonHD.chip and RadeonRX.chip drivers.
Using CMPLENGTH=6 only checks the "Radeon" part and therefore works with both of them.

With the AmigaOS 4.x ATIRadeon.chip it may be BOARDNAME=ATIRadeon instead, and with your version it seems to be BOARDNAME=Qemu ati-vga according to @Maijestro's screenshot. Or maybe BOARDNAME=qemu ati-vga (file name in DEVS:Monitors), I don't know if it's a case sensitive or case insensitive compare.

Topic | Forum

joerg

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/24 16:40 #17

Home away from home

@balaton
Quote:

Everything else is handled by the default AmigaOS PCIGraphics.card which I haven't replaced so it might work with any version that recognises the Radeon 7000 PCI card which is the oldest Radeon so should work with most versions.

The MAI Teron Mini/EyeTech AmigaOne µA1-C (the µA1-I version was never produced) includes a Radon 7000 with 32 MB VRAM, but no BIOS ROM, it's included in the U-Boot binary of it instead, probably a GZip or Bzip2 compressed image.
Not sure any more, but the µA1-C might have used AGP instead of PCI for the onboard R7000 chip.
The only way to get even worse gfx support on AmigaOS 4.x is using the SM501/502 with QEmu (16 bit only) or on a real Sam4x0 without any PCI(e) gfx card installed, or Classic Amiga emulation (WinUAE) with Voodoo3/4/5: (Warp)3D supported, but like on original hardware only in 16 bit modes, and limited to 4-16 MB VRAM...

Topic | Forum

joerg

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/24 15:17 #18

Home away from home

@balaton
Quote:

Quote:
@joerg
Quote:
Does it depend on anything from AmigaOS 4.1 "FE"?
How would I know if I don't even know what's the proper API? I had to reconstruct the header file from P96 so I don't know what different versions of AmigaOS 4 had only that it roughly corresponds to older P96 versions.

It just depends on the min. library version you are using in IExec->OpenLibrary() calls in your ATIRadeon.chip driver, if you'd use for example V54 for opening expansion.library (for the PCI functions) it will AFAIK only work with AmigaOS "FE" Update 3 (or newer), if you use V52 or V53 it should work with any AmigaOS 4.1 version and when using V50, and you don't use any functions added later, it will even work with AmigaOS version 4.0 (incl. developer pre-releases of it).

The only relevant change from AmigaOS 4.0 to current versions for ATIRadeon.chip, and only theoretically as you don't support it yet, is the compositing function which IIRC was added in AmigaOS 4.1 (not "FE") in the .chip driver API and may not have been available in AmigaOS 4.0 yet.
For gfx drivers not supporting it in HW, i.e. all of the about 20 P96 .chip drivers except for the original ATIRadeon.chip, RadeonHD.chip and RadeonRX.chip, the AmigaOS 4.x graphics.library uses a software fallback function.

Quote:

(For which the headers are also removed from their site and not available any more.)

https://source.mnt.re/amiga/zz9000-dri ... ob/master/rtg/boardinfo.h
(__REG[AD][0-7]() macros not required on AmigaOS 4.x PPC, the standard SysV PPC ABI is used, only required for AmigaOS 2.x/3.x m68k.)

Topic | Forum

joerg

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/23 17:28 #19

Home away from home

@balaton
Quote:

QEMU v11.0.0 is released. I've updated my page (link in signature), see News section where you might find something useful for somebody.

Congratulation!
That much for the usual "implementing an AmigaOS 4.x gfx driver is impossible because of missing documentation" (although it's 99,9% identical to the ancient and well documented P96 .chip and .card driver API ) mimi mimi excuses

Does it depend on anything from AmigaOS 4.1 "FE"?
If not I might finally dig out some of the ancient backups of the latest AmigaOneXE version of AmigaOS 4.1 I have (probably Update 3 or 4, not "FE" or an update of it!) and use it with QEmu.
You can ignore the overlay/PIP parts, at least in case you are able to implement HW/QEmu accelerated compositing, which can be even faster than overlay/PIP YUV modes for video playback.

Topic | Forum

joerg

Re: Git 2.45 for AmigaOS4

Posted on: 4/20 16:28 #20

Home away from home

@afxgroup
Quote:

2) I have only an encoding problem on 1 file

Even just trying to convert UTF-8 to an AmigaOS incompatible charset like Windows 1252 is a bug.
I'd leave it at UTF-8, there are enough editors for AmigaOS with UTF-8 support now.
If you want to convert UTF-8 files to an 8 bit charset it has to be an AmigaOS compatible one like the default ISO 8859-15, but of course even much better use the one of the current locale.

Topic | Forum

Top

(1) 2 3 4 ... 110 »