Hi, could someone elaborate this issue for me? (is there libraries that i should check for version mismatch error?)

I am out of idea, mine rom version has a mouse pointer different than other places (like winuae).

Winaue pointer is a triangle, mine is an arrow.

anyway, if i dont have any new insight about this i will not be able to go foward.

I use aros.rom and it boots lot of non-os disks, but if i try aros ou workbench, no success, aros gave me a gray screen with the mouse pointer working, workbench the same, but blue screen.

regards,

Hi again,
I really want to boot aros, but i am having trouble.
My first doubt: what order should i concat de roms? mine, (that i dont know where i grabbed) is ext+base, is there a convention that i should use?
I had tried a rom from 05/12/2026 (dunno if its the download date or build date) and it doesnt reach the boot screen, would be really helpfull have a rom that is known to be working.

Mine priority now is make aros boot (from adf) and i have allready some good results to be questioning that is a rom fault.
Over aminet there is aros rom and adf but is from 2011, i think.

https://aminet.ne...n.68k-aros

Regards,

Have you tried that ROM in WinUAE - it's the reference. Also I don't believe you combine both file together (concat) - they are added separatelly in WinUAE configuration.

Ok, o Will try it in winuae.
The ideal would be use the same rom that it uses.(the build in rom boots the adf)

I need it merged cause its a initramfs argument. (The emulator than split it)

It seems that my old “working” rom is from a year ago.

According to the AI it was in a polling mode and the new one is irq based, but i cant rely on it yet.

I Will dig into what is happening cause i am almost sure that i cant boot the adf is the mismatch error.

Regards,
Ps: boot aros is one of the main goals of the project, so i Will prioritize this , the emulator is allready working good enough to make it work.

The new version stops after romtag init.

On WinUAE, you can also merge and use a single ROM

Hi @AMIGASYSTEM ,
I tried both way, in both i saw the boot screen, that i dont see in my emulator, but i am never sure if the boot screen is from the rom i passed or from the builtin rom.
The AI investigation goes in ways that i cant rely:

I tested new_aros.rom without any ADF attached.

Main result: the ROM hangs before disk boot matters. It prints:

romtaginit
romtaginit done

and never reaches the next resident module.

For comparison, the old src/roms/aros.rom without ADF continues past that point and calls:



So the current primary suspect is not floppy, ADF, ATA, or p96 itself. The hang happens earlier: right after romtaginit done, before the boot flow returns to initialize the next resident.

I also enabled both trace knobs:



In this harness build, the useful trace is the Rigel trace. It shows VBL/PORTS interrupts are still alive, IPL rises and drops normally, and the CPU keeps returning to the idle loop:



The OS dump is the strongest clue:



That means a task is sitting in TaskWait even though it has received a signal that matches its wait mask. It should have been moved back to TaskReady, but it was not. So this looks like an Exec scheduler/wakeup problem.

The likely technical lead is the new ROM’s Exec build mode. In AROS, the SMP path in Signal() uses:



On x86 there is a real handler for that syscall which removes the task from its old list and enqueues it on TaskReady. In the local m68k code I did not find an equivalent m68k implementation. If new_aros.rom was built with __AROSEXEC_SMP__ or --enable-target-variant=smp for m68k, that would explain the symptom: tasks receive signals, but never get rescheduled from WAIT to READY.

I updated AI_context/issues/ISSUE-0020.md with this revised conclusion. I also added harness debug support so HARNESS_OS_DEBUG_DUMP=1 prints task wait/received signal masks. The harness build passes.

Regards,

ok,
a hack could gave me the boot screen

AI:

Old ROM (Jul/2025): exec_locks.c had a && vs & bug that kept the system effectively in Forbid() the whole time during InitCode. Task switching was disabled, so getunit() was only ever called from the TD task
itself — mp_SigTask was always correct.

New ROM (May/2026): That bug was fixed (commit 06c521a903). Real task switching is now enabled during init. While the TD task holds the disk resource (e.g., during td_recalibrate delays), another task can
preempt and call beginio with IOF_QUICK. beginio calls TD_PerformIO → getunit → WaitPort(&td_druport) from the wrong task. The wakeup signal goes to mp_SigTask = TD task (not the caller). The caller sleeps forever.

Where the fix belongs: In the AROS source, getunit() at arch/m68k-amiga/devs/trackdisk/trackdisk_device.c:55:

while (GetUnit(&tdb->td_dru) == NULL) {
tdb->td_druport.mp_SigTask = FindTask(NULL); // add this
WaitPort(&tdb->td_druport);
}

The harness hack does the same thing but intercepts at the host level, which is fragile — it fires for ANY WaitPort mismatch, not just this one. The source fix is precise and permanent.


me:

But, i didnt got any serial log after the romtag init, and the adf doesnt seems to boot (even if it is recognized)
(the mouse pointer be a triangle seems to be a regression from the arrow, but its the way winuae has)

Regards, let me see if i can get better understanding of what is going on.

i will never be sure, but i really think that winuae uses the rom without problem and boot the adf.
so, lets try to fix things here (and also make me wonder if my old rom wasnt really able of boot the disk)
no idea where to begin from, but ate least now i am at updated land!

regards,

ok, confirmed:
Winuae can use the old rom (arrow pointer) and boot adf from deadwood build of 2025-07-30

So it was no versions mismatches. (back to bughunting, at least no more doubt about this, a kind of progress)

sadly i am not sure how in sync my aros sources is, but even without the source reference it should work, period.

Regards,

Aros was allready working, but no render. no visual feedback!

Dancing bananas!

Ps: thanks @deadwood and @AMIGASYSTEM

Congratulations! With WinUAE, you can even run a full version of AROS 68k, complete with graphics and tools. If you need it, I can send you a lite version of my AROS One 68k.

https://youtu.be/...

Hi @AMIGASYSTEM ,

The problem was i was reporting ecs chipset id but without the registers so the blitter was going to the void.

Now that i have gfx it doesnt made much diferences if it is workbook or full aros.

It has other stuff, like p96 and booting support (ISO and sdcard), but i was very intrigued about why i didnt got gfx response before.

I would love to have a slim version of aros 68k, i had Said that before. But, for now, have the gfx output was really a (small) Victory.

Regards,

Ps: i have updated the readme with the current status (it can also be seen as a roadmap)

https://github.co.../tree/main

As i Said before, i have other things to be done before going foward with this, i was just very anoyed of not have aros working.

Hi @AMIGASYSTEM ,
First, thanks for doing The edition, learned that now (no smiley and code quoting).

I ordered a 1tb ssd, Will have space now (i was working with no space in disk, really a bad experience)

I searched for the aros one 68k but got lost on the entries.

I have 2 Nice resources: aros one 68k and emu68 imager.

I just need the minimun setup to test the sdcard boot setup, but have a full (small) distro could be handy.

I dont know yet how i Will do but have full workflow of aros is a main goal, could you confirm what is the latest link for aros one 68k?

Not have aros workbook booting was the block, but that is allready done (it was really intriguing me). Now i can see (visual feedback) about ATA devices (CD-ROM and hd) inside the amiga env.

Regards,

Ps: i am really curious to see how fast (slow) aros Will be (i dont like The idea of aros just be fast enough on winuae. That was the motivation, even without emu68, i am curious to see how it performance as in the actual musashi setup and aiming for a future, not yet near, with emu68/multicore)