Booting AROS fails - Githubissues

dirkwhoffmann commented 5 years ago

When booting with the Aros Rom installed, vAmiga gets stuck in an infinite loop:

dirkwhoffmann commented 5 years ago

Infinite loop was caused by Kickstart ROM addressing bug.

Still hanging (Interesting: Hangs before the Copper is being activated):

dirkwhoffmann commented 5 years ago

Just learned that Aros needs two Roms (Kickstart replacement + extended ROM) 🤭.

Stupid question: If I had an original Amiga, where would I have to plug the extended ROM in? Is there a special chip socket for this? I don't find any 🙄.

dirkwhoffmann commented 5 years ago

Extended Rom is up and running. We are still in an infinite loop though:

....
[415] ( 34,217)  FE15CE --BD 202C 0029 UART: peekSERDATR() = 2000
[415] ( 35, 15)  FE15E2 --BD 202C 0029 UART: pokeSERDAT(123)
[415] ( 35, 98)  FE15CE --BD 202C 0029 UART: peekSERDATR() = 0
....
[415] ( 36, 30)  FE15C8 --BD 202C 0029 UART: Transmission continues with packet 1E
[415] ( 36, 30)  FE15C8 --BD 202C 0029 UART: fillShiftRegister(123)
[415] ( 36, 30)  FE15C8 --BD 202C 0029 UART: Triggering TBE interrupt
....

The loop reads from the serial interface. Hence, let's do #49 first.

dirkwhoffmann commented 5 years ago

OMG, Aros is not weird, it tried to talk to me all the time 😯. Because video output is not working, the poor thing tried to seek help by sending messages through the serial port (digital version of a bottle mail, I guess). Considering the huge of amount of messages sent so far, it must be very desperate by now.

....
[EXEC] InitCode: calling InitResident (40 81 "amigamouse.hidd")
[EXEC] InitCode: calling InitResident (39 81 "disk.resource")
[EXEC] InitCode: calling InitResident (35 81 "trackdisk.device")
[EXEC] InitCode: calling InitResident (30 81 "input.device")
[EXEC] InitCode: calling InitResident (9 81 "amigavideo.hidd")

################################################################################
#                               Software Failure!                              #
#                    Task : 0x00C122F8 - Exec Bootstrap Task                   #
#       Error: 0xC2038002 - graphics.library could not open library hidd       #
################################################################################
PC   : 0x00FD8232

Now I'm in real trouble: Who to rescue first... the princess or the cat 🤔.

dirkwhoffmann commented 5 years ago

For reference: While booting, Aros writes into the following non-OCS registers:

[314] ( 87,113)  FA93E6 --B- 202C 0021 Memory: WARNING: pokeCustom16(DFF1FC [FMODE (AGA)]): NO OCS REGISTER
[349] ( 15,132)  FD7962 --BD 602C 0001 Memory: WARNING: pokeCustom16(DFF1FC [FMODE (AGA)]): NO OCS REGISTER
[349] ( 15,172)  FD7982 --BD 602C 0001 Memory: WARNING: pokeCustom16(DFF106 [BPLCON3 (ECS)]): NO OCS REGISTER
[349] ( 15,182)  FD798A --BD 602C 0001 Memory: WARNING: pokeCustom16(DFF10C [unused]): NO OCS REGISTER

Todo: Check if these registers are written by SAE, too. Maybe, Aros thinks vAmiga has an ECS or AGA chipset.

dirkwhoffmann commented 5 years ago

Further findings: Aros requires more than 512 Ram (does not boot in SAE if slow mem is disabled)

dirkwhoffmann commented 5 years ago

There might be an issue with the POTGO register. Needs investigation.

SAE log:

amiga.js:295 Input.POTGO() $0f00
amiga.js:295 Input.POTGO() $ff00
amiga.js:295 Input.JOY0DAT() 0000
amiga.js:295 Input.POTGOR() $5500
amiga.js:295 Input.JOY0DAT() 0000

vAmiga log:

[325] (259,159)  FEC6AC --B- 602C 0001 Paula: pokePOTGO(F00)
[325] (260, 34)  FD39CE --B- 602C 0001 Paula: pokePOTGO(FF00)
[325] (260, 55)  FD39E2 --B- 602C 0001 Denise: peekJOY0DATR() = $0000 (0)
[326] (  3,192)  FD3788 --B- 602C 0021 Paula: peekPOTGOR = FF00
[326] (  3,211)  FD379C --B- 602C 0021 Denise: peekJOY0DATR() = $0000 (0)

dirkwhoffmann commented 5 years ago

It was not due to POTGOR. I have to start from scratch.

What I found out so far:

0xFF4D68: Jump to init code of various modules
0xFD465C: Start of video module init
- 0xFD466C: Audio init
- 0xFD5952: Bitplane registers

The tst.w statement sets the Z flag. This means that we're running on a non-AGA Amiga which is correct.

dirkwhoffmann commented 5 years ago

I'm giving up on this for now.

At the moment, it makes more sense to focus on errors with a clearly definable root cause. Maybe we can search the Fish disks for smaller programs that don't work. It'll be best if the source code is included.

dirkwhoffmann commented 5 years ago

After the helpful people in the EAB forum pointed me to the Aros source code, I can narrow down the error a bit:

The error occurs in this code fragment:

It corresponds to this C source fragment:

OOPBase = csd->cs_OOPBase;
csd->cs_HiddBitMapBase = OOP_GetMethodID(IID_Hidd_BitMap, 0);
csd->cs_HiddGfxBase = OOP_GetMethodID(IID_Hidd_Gfx, 0);

csd->cs_UtilityBase = TaggedOpenLibrary(TAGGEDOPEN_UTILITY);
if (!csd->cs_UtilityBase)
    Alert(AT_DeadEnd | AN_Hidd | AG_OpenLib | AO_UtilityLib);
csd->cs_GfxBase = TaggedOpenLibrary(TAGGEDOPEN_GRAPHICS);
if (!csd->cs_GfxBase)
    Alert(AT_DeadEnd | AN_Hidd | AG_OpenLib | AO_GraphicsLib);

The second call to TaggedOpenLibrary fails.

The function itself looks as follows:

  if(tag > 0)
    {
    /*
        Try to open the library. If it opened, return.
    */
    if((lib = OpenLibrary(libnames[tag-1], 0))) return (APTR)lib;

    /*
        If it didn't open, FindResident(), InitResident(), and then
        try to open it again.
    */
    if(!(res = FindResident(libnames[tag-1]))) return NULL;
    InitResident(res, BNULL);
    if((lib = OpenLibrary(libnames[tag-1], 0))) return (APTR)lib;
    }

In vAmiga, FindResident fails and the functions returns 0.

dirkwhoffmann commented 5 years ago

I stepped through the FindResident() function which looks like this:

IPTR *InternalFindResident(const UBYTE *name, IPTR *list)
{
    if (list)
    {
        while (*list)
        {
            /*
             * On amiga, if bit 31 is set then this points to another list of
             * modules rather than pointing to a single module. bit 31 is
             * inconvenient on architectures where code may be loaded above
             * 2GB. on these platforms we assume aligned pointers and use bit
             * 0 instead
             */
            if (*list & RESLIST_NEXT)
            {
                list = (IPTR *)(*list & ~RESLIST_NEXT);
                continue;
            }

            if (!(strcmp( ((struct Resident *)*list)->rt_Name, name)))
                return list;

            list++;
        }
    }
    return NULL;
    }

I noticed that the pointers that are handed over to strcmp are misaligned w.r.t. the Rom. E.g., here (string comparison pointer is in red):

I guess the pointer should point to the start address of "amigavideo.hidd..."

I immediately thought that my two Aros Roms (ext rom and std rom ) don't fit together, but their version numbers match:

This the Rom I use:

00000000  11 14 4e f9 00 f8 00 fc  00 00 ff ff 00 2e 00 0c  |..N.............|
00000010  00 2e 00 0c ff ff ff ff  41 52 4f 53 20 52 4f 4d  |........AROS ROM|
00000020  20 4f 70 65 72 61 74 69  6e 67 20 53 79 73 74 65  | Operating Syste|
00000030  6d 20 61 6e 64 20 4c 69  62 72 61 72 69 65 73 00  |m and Libraries.|
00000040  43 6f 70 79 72 69 67 68  74 20 a9 20 31 39 39 35  |Copyright . 1995|
00000050  2d 32 30 31 39 20 00 54  68 65 20 41 52 4f 53 20  |-2019 .The AROS |
00000060  44 65 76 65 6c 6f 70 6d  65 6e 74 20 54 65 61 6d  |Development Team|
00000070  2c 20 00 41 6c 6c 20 52  69 67 68 74 73 20 52 65  |, .All Rights Re|
00000080  73 65 72 76 65 64 2e 00  31 38 2e 30 32 2e 32 30  |served..18.02.20|
00000090  31 39 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |19..............|

This is the Ext Rom I use:

00000000  11 14 4e f9 00 f8 00 02  00 00 ff ff 00 2e 00 0b  |..N.............|
00000010  00 2e 00 0b ff ff ff ff  41 52 4f 53 20 45 58 54  |........AROS EXT|
00000020  20 45 78 74 65 6e 73 69  6f 6e 20 4c 69 62 72 61  | Extension Libra|
00000030  72 69 65 73 00 43 6f 70  79 72 69 67 68 74 20 a9  |ries.Copyright .|
00000040  20 31 39 39 35 2d 32 30  31 39 20 00 54 68 65 20  | 1995-2019 .The |
00000050  41 52 4f 53 20 44 65 76  65 6c 6f 70 6d 65 6e 74  |AROS Development|
00000060  20 54 65 61 6d 2c 20 00  41 6c 6c 20 52 69 67 68  | Team, .All Righ|
00000070  74 73 20 52 65 73 65 72  76 65 64 2e 00 31 38 2e  |ts Reserved..18.|
00000080  30 32 2e 32 30 31 39 00  00 00 00 00 00 00 00 00  |02.2019.........|

I am running out of ideas 🙁.

niklasekstrom commented 5 years ago

Hi Dirk,

Maybe this is a naive (stupid) idea, but can you try booting with those ROM files in WinUAE and see if that works? If it works maybe you can step through the code in its debugger and see at what point the execution deviates from running in vAmiga?

dirkwhoffmann commented 5 years ago

If it works maybe you can step through the code in its debugger and see at what point the execution deviates from running in vAmiga?

This is how I found out that vAmiga fails in function InternalFindResident(). SAE does not fail here. The problem is that the boot sequence is very sensitive to the actual hardware configuration (at least if Kick 1.2. or 1.3 is loaded). Depending on the config, Kickstart is moving data and modules to different memory locations, so the boot sequences start to differ very early. Luckily, no disk drive is involved. In that case, it's nearly impossible to do a one-to-one comparison, because the head position cannot be predicted.

I'll try to check in SAE if the same odd memory locations are addressed when calling strcmp()...

hth313 commented 5 years ago

As you found out AROS 68K normally has two 512K ROMs, the kickstart replacement and extension ROM. However, there is a single 512K kickstart replacement version of it too, for original machines intended for being a free replacement of Amiga kickstart 1.x.

If you use the two ROM version, be very sure to use a matching pair from the same build, as any change can alter offsets between them.

The most common way to load AROS today is probably use the relocatable version of AROS kickstart (aros.elf) and AROSBootstrap which allows for loading it to another location (in RAM) when started from an existing Amiga OS installed kickstart. This results in different locations than if the ROM was used.

The serial port bottle mail is common for early low level debugging of operating systems. You can disable it in you AROS build if you want to. Or you can enable more detailed debug in many places.

I believe that this resident thing is to find modules present in the ROMs, which have special identifiers (ROMTags) to identify them. The ROMs are scanned and a list of them built. That list is being searched in the code you show.

Where did you find the AROS ROMs?

dirkwhoffmann commented 5 years ago

Håkan, thanks a lot for your detailed explanation! This clarifies a lot 👍.

Where did you find the AROS ROMs?

If I remember correctly, I peeked where SAE downloads the Roms when the Aros option is checked and then downloaded them manually from that URL. They had the usual names:

aros-amiga-m68k-ext.bin
aros-amiga-m68k-rom.bin

However, there is a single 512K kickstart replacement version of it too, for original machines intended for being a free replacement of Amiga kickstart 1.x.

This is exactly what I am looking for, because vAmiga is intended to emulate OCS Amigas only. I want to include the Roms for convenience. The replacement will be used by default until the user (buys and) installs an original Rom.

Where can I obtain that Rom? Is it the Aros.elf that you mentioned in your post?

hth313 commented 5 years ago

I am not sure where that single 512K image can be found, I asked for it but no answer so far. I believe it is mainly used in emulation and is not anything that people request on a regular basis. Emulator makers are the ones that want it and include it in their package to have a ready to use package free from illegal ROMs.

AFAIK it is not built on a daily basis, but I will get back to you if I find out more information or find it myself.

The aros.elf is the dual ROM in a relocatable form that can be loaded to different memory locations (the .bin pair only works at the real ROM addresses).

dirkwhoffmann commented 5 years ago

but I will get back to you if I find out more information or find it myself.

That's great! I really appreciate your help.

hth313 commented 5 years ago

I have not found that 512K ROM yet. It thought it was included with fs-uae, but it uses the dual ROMs https://github.com/FrodeSolheim/fs-uae/tree/master/share/fs-uae

The 512K was made back around 2011 mainly by Toni Wilen and Jason McMullan http://eab.abime.net/showthread.php?t=56211

You could try to contact either of them (Toni is the maintainer winuae).

Maybe you can just use the dual ROM as it is being maintained and built daily. It may not matter in an emulator as you should have plenty of memory, it would be a different matter if you had a physical socket in a machine. Daily builds can be obtained from http://www.aros.org/nightly1.php or https://www.amigadev.com/ports/aros-mirror

dirkwhoffmann commented 5 years ago

Thanks a lot, Håkan. Eventually the dual ROMs will do for me, because memory is not an issue. I guess they are not working in my emulator due to some silly bug I am not aware of yet. But with a little patience, I'm sure I can hunt it down.

dirkwhoffmann commented 5 years ago

Update: After fixing #144 (reset vector bug), the initialisation procedure looks better know, although not running through:

Resident modules (addr: pri flags version name):
+ 00fe0b20:  127 02   3 "kernel.resource"
+ 00f81d30:  120 01  51 "exec.library"
+ 00fa2eda:  110 82  41 "expansion.library"
+ 00fa8b9a:  105 82   2 "debug.library"
+ 00ff23a6:  105 01  41 "diag init"
+ 00f9f560:  103 81  41 "utility.library"
+ 00f8ea88:  101 81  41 "aros.library"
+ 00f814ae:  100 01  41 "mmu"
+ 00fe5b16:  100 01   1 "task.resource"
+ 00fec700:  100 81  41 "potgo.resource"
+ 00ff2386:  100 01  41 "bootloader.resource"
+ 00fe51fe:   99 01   2 "processor.resource"
+ 00fa1b42:   94 81  43 "oop.library"
+ 00fc3674:   92 81   1 "hiddclass.hidd"
+ 00fec048:   80 01   0 "cia.resource"
+ 00fed006:   80 01   1 "FileSystem.resource"
+ 00fe09d0:   70 81  41 "battclock.resource"
+ 00fd0ef4:   66 81  45 "gfx.hidd"
+ 00fa9ea8:   50 81  41 "timer.device"
+ 00ff1c56:   48 81  41 "card.resource"

....

+ 00fb84b2: -124 04  41 "con-handler"
+ 00fc27a2: -125 04   1 "ram-handler"
[EXEC] InitCode: calling InitResident (110 82 "expansion.library")
configchain
configchain done
adding ram boards
ram boards done
[EXEC] InitCode: calling InitResident (105 82 "debug.library")
[EXEC] InitCode: leave InitCode(0x02, 0)
[EXEC] InitCode: enter InitCode(0x01, 0)
[EXEC] InitCode: kickmemptr=0x00000000 kicktagptr=0x00000000 kickchecksum=0x00000000
[EXEC] InitCode: calling InitResident (120 01 "exec.library")
[EXEC] InitCode: calling InitResident (105 01 "diag init")
callroms
callroms done
00c00000: 00c00000 - 00c80000 00001705 -5 'memory'
00000400: 00000400 - 00080000 00001703 -10 'chip memory'
00c010e8: 00f80000 - 01000000 00000400 -128 'Kickstart ROM'
00c01108: 00e00000 - 00e80000 00000400 -128 'Kickstart ROM'
[EXEC] InitCode: calling InitResident (103 81 "utility.library")
[EXEC] InitCode: calling InitResident (101 81 "aros.library")

....

[EXEC] InitCode: calling InitResident (39 81 "disk.resource")
[EXEC] InitCode: calling InitResident (35 81 "trackdisk.device")

The emulator enters an infinite loop in the initialisation code of track disk device.

There are two possibilities:

vAmiga still has a general issue related to the CPU (IRQ triggering, vectors etc.)
vAmiga's disk controller is buggy.

My feeling is that 2 is more likely than 1. Hence, #143, #60, and #90 should be fixed before coming back here...

dirkwhoffmann commented 5 years ago

More findings:

SAE maps the extended Rom to 0x00e00000 (like a CD32 Amiga) and not to 0x00f00000 (like a CDTV Amiga)
SAE grabs the reset vector from the extended Rom. This means that if extended Rom is present, it is overlayed onto the lower memory banks instead of the standard Kickstart Rom.

dirkwhoffmann commented 5 years ago

This seems to happen in Initresident(trackdisk.device) in SAE:

amiga.js:295 CIA A read PRA: fc  /WPRO = 1 /CHNG = 1 (not protected, no disk change)
amiga.js:295 CIA A read PRA: fc
amiga.js:295 CIA B read PRB: ff
amiga.js:295 CIA B write PRB: ff
amiga.js:295 CIA B write PRB: ff
amiga.js:295 CIA B write PRB: f7 Select drive df0:
amiga.js:295 CIA B read PRB: f7
amiga.js:295 CIA B write PRB: f7
amiga.js:295 CIA A read PRA: e0  /WPRO = 0 /CHNG = 0 (protected, disk change)
amiga.js:295 CIA A read PRA: e0
amiga.js:295 CIA B read PRB: f7
amiga.js:295 CIA B write PRB: f5
amiga.js:295 CIA A read PRA: e0
amiga.js:295 CIA B read PRB: f5
amiga.js:295 CIA B write PRB: f4
amiga.js:295 CIA B read PRB: f4
amiga.js:295 Stepping up to cylinder 1

vAmiga doesn't reach the point where the drive head steps. The problem is likely to be related to the WPRO or CHNG signal which seems to be handled wrong in vAmiga.

dirkwhoffmann commented 5 years ago

This is likely the corresponding C source file: AROS/arch/m68k-amiga/devs/trackdisk/trackdisk_device.c

static void TD_DevTask(struct Task *parent, struct TrackDiskBase *tdb)
{
...
  /* Initial check for floppies */
    for (i = 0; i < TD_NUMUNITS; i++) {
        struct TDU *tdu = tdb->td_Units[i];
    if (tdu) {
        getunit(tdb);
        td_select(tdu, tdb);
        td_motoroff(tdu, tdb);
        tdu->tdu_broken = td_recalibrate(tdu, tdb) == 0;
        if (tdu->tdu_broken)
        bug("DF%d failed to recalibrate!?\n", i);
        else
        D(bug("DF%d initialized\n", i));
        tdu->tdu_DiskIn = td_getDiskChange(tdu, tdb) ? TDU_DISK : TDU_NODISK;
        tdu->tdu_ProtStatus = td_getprotstatus(tdu,tdb);
        tdu->tdu_hddisk = ishd(GetUnitID(i));
        tdu->tdu_sectors = tdu->tdu_hddisk ? 22 : 11;
        tdu->tdu_disktype = DT_UNDETECTED;
        td_deselect(tdu, tdb);
        giveunit(tdb);
    }
    }

    tasig = 1L << tdb->td_Port.mp_SigBit;
    tisig = 1L << tdb->td_TimerMP->mp_SigBit;

    /* Reply to startup message */
    Signal(parent, SIGBREAKF_CTRL_F);

    tdb->td_TimerIO->tr_node.io_Command = TR_ADDREQUEST;
    tdb->td_TimerIO->tr_time.tv_secs = 2;
    tdb->td_TimerIO->tr_time.tv_micro = 500000;
    SendIO((struct IORequest *)tdb->td_TimerIO);

    /* Endless task loop */
    for(;;)
    {
    sigs = 0L;
    sigs = Wait(tasig | tisig);  /* Wait for a message */
    /* If unit was not active process message */
    if (sigs & tasig) {
        /* We received a message. Deal with it */
        while((iotd = (struct IOExtTD *)GetMsg(&tdb->td_Port)) != NULL) {
        /* Execute command */
        if (TD_PerformIO(iotd, tdb)) {
            /* Finish message */
            ReplyMsg((struct Message *)iotd);
        }
        }
    }
...

}

dirkwhoffmann commented 5 years ago

SAE (at the beginning of trackdisk.device init):

In IRQ level 2 handler:

INTENAR: 602C
INTREQR: 8
INTREQ(8)

vAmiga:

[335] ( 82,108)  FE25B2 --B-D- 602C 0009 Memory: peekCustom16(DFF01C [INTENAR]) = 602C
[335] ( 82,125)  FE25BE --B-D- 602C 0009 Memory: peekCustom16(DFF01E [INTREQR]) = 8
[335] ( 86,100)  F860F4 --B-D- 602C 0009 Memory: pokeCustom16(DFF09A [INTENA], 4000)

vAmiga is not acknowledging the interrupt (as SAE does), thus retriggering the same interrupt a couple of instructions later 🙈.

@naTmeg you are my last hope 😩. Is it possible to turn on CPU tracing in SAE? I need to see the next 100 or 200 instructions after I reach the position mentioned above. Please please please let tracing be possible. Unfortunately, the CPU implementation in xAE is all over my head and I didn't figure out myself how to do it.

mithrendal commented 5 years ago

I am just searching ... in SAE/cpu.js . There are some disassemble functions in there. But I have no clue how to activate them... But if you just need the next 100 instructions then maybe the next 100 executed adresses processed are enough ? You could patch m68k_cycle or the specific functions in cpu.js named runPrefetch000 or runNormal (depending on compatibility settings) to just dump out the program counter (PC register) where SAE is traveling along ...

to dump out just do a console.log(getPC()) maybe?

dirkwhoffmann commented 5 years ago

You could patch m68k_cycle or the specific functions in cpu.js named runPrefetch000 or runNormal

I patched run_normal to dump out the PC. At some point, SAE branches away, because D3 contains a different value than vAmiga. This is bad news, because the missing IRQ acknowledge is just a symptom and not the cause. This bug is a real nightmare. Running out of ideas... 😒

dirkwhoffmann commented 5 years ago

@naTmeg, how difficult do you think it is to extract the CPU from UAE and integrate it into vAmiga as a second CPU engine? vAmiga currently uses the Musashi core, because of its speed and very high code quality. To find a bug like this, it might be helpful to have two CPU engines side-by-side and a selection option in the hardware preferences.

I am a little bit afraid, because UAE appears kind of monolithic to me. Furthermore, there is this issue with my small head which is just not big to understand the UAE code. I would mainly have to port it as a black box.

dirkwhoffmann commented 5 years ago

Just had a brief look at the UAE and FSUAE code. It's not even clear to me which files belong to the CPU. By looking at the headers of some CPU related files I've seen that they pull in nearly all of UAE. Monolithic software design at its best.

I've checked that Aros works in WinFellow as well:

So why not add the WinFellow CPU as a second engine? WinFellow has a much cleaner code base than UAE.

naTmeg commented 5 years ago

Hi Dirk,

Is it possible to turn on CPU tracing in SAE?

Tracing is not implemented :/

how difficult do you think it is to extract the CPU from UAE and integrate it into vAmiga as a second CPU engine?

Not too easy. At least WinUAE does create the CPU-code from a definition-file. I dunno about other xAE. For SAE, I wrote the CPU-core for myself and just ported some high-level functions..

If you have an address, you could just disassemble the code from that offset. SAE has a builtin disassembler. Take a look at disass.js for how to fire it up or visit sae.net/disass.htm

After reading this thread, I think you may have a bug in the disk-code. Iirc, you also mentioned somewhere, that diskchange isn't working correctly. Could be coherent. Maybe do a search for "INTREQ" in disk.js and compare where SAE fires an interrupt, compared to your code.

dirkwhoffmann commented 5 years ago

Hi Rupert,

Thanks for the clarifications.

Not too easy.

Yeah, that's what I expected when I looked at the code yesterday. I should keep my fingers off the UAE code. No offense to the UAE team, but their programming philosophy and mine just don't go together.

At least WinUAE does create the CPU-code from a definition-file.

By the way, Musashi does the same thing. But that's no big deal, because everything is so clearly modularized and documented that it's really simple.

I wonder if the same could be achieved by using C++ templates. All template constructs are resolved at compile time. Therefore, the C++ compiler can be used as a code generator if cleverly done. Similar to the handcrafted code generators in UAE and Musashi, but much more elegant. Maybe at some point I'll write my own CPU... 🤔

After reading this thread, I think you may have a bug in the disk-code.

vAmiga has bugs all over the place. 😂

Regarding the Aros nightmare, I think it’s something general. My current suspects are (in this order):

The IRQ hander (interaction between Musashi and Paula)
Some subtle CIA timer bug

Regarding 1., there are still some ambiguities I need to figure out. For example, what happens if the CIA timer triggers an interrupt and the IRQ bit is not cleared in the CIA interrupt register but in INTREQ? Is the INTREQ still one in this case? In other words: Is Paulas CIA interrupt input edge triggered or line triggered. I expect something like this to be the issue. In a quiet moment I try to write some test cases...

dirkwhoffmann commented 5 years ago

Shh, please be quiet.... the little kitten is so young and just woke up 🤫.

Isn't she a sweetie 🥰?

Hmmm, she does looks a little grim though, doesn't she?

Wait wait wait... I've seen this cat before...

But where? .... 🤔

OMG, I knew I've seen her before 😳:

Pet_Sematary_(2019_poster)

Sorry guys, I didn't mean it 🙄.

naTmeg commented 5 years ago

Nice, you did it!

mithrendal commented 5 years ago

What was it? the CIAs I think ... as it was the last thing you investigated in ...

dirkwhoffmann commented 5 years ago

What was it?

Culprit was the interaction between the CIA interrupt line and the corresponding IRQ bit in INTREQ.

There are five new tests in the vAmigaTS repo exhibiting the relationship (timer1 to timer5). I'm not sure if my new code does mimic a real Amiga to 100%, but at least all 5 tests pass.

dirkwhoffmann commented 5 years ago

One bug fixed, another detected...

When I insert the original Amiga2000 WB disk, vAmiga seems to enter an infinite loop right after the real-time clock is read:

In SAE, booting succeeds, but I don't see any disk icons. There is nothing I can do (clicking the menu doesn't reveal any menu item).

mithrendal commented 5 years ago

What happens when you insert it into A500MMSE? Does it hang too?

dirkwhoffmann commented 5 years ago

What happens when you insert it into A500MMSE?

I can't test this, because it requires the Aros Roms. What I did in the emulator is to use the Aros Roms and boot the standard A2000 WB disk.

In the meantime I found out that SAE behaves as weird as vAmiga if the OCS chipset is selected.

Maybe there are special Aros Workbench disks needed? 🤔

naTmeg commented 5 years ago

Maybe there are special Aros Workbench disks needed? thinking

Try https://sourceforge.net/projects/aros/files/nightly2/20190831/Binaries/AROS-20190831-amiga-m68k-boot-floppy.lha/download

dirkwhoffmann commented 5 years ago

Try ...

🥴

naTmeg commented 5 years ago

Hmm, it seems the latest version isn't working anymore.

But http://scriptedamigaemulator.net/db/tools/AROS%20Bootdisk.adf does work?!

Edit: maybe we need the latest AROS-rom too?

dirkwhoffmann commented 5 years ago

This version wants me to insert a "CD" 🤭.

Although my 3.5" disk drive is virtual, I don't think I can put in a CD 😬.

maybe we need the latest AROS-rom too?

Well, maybe. But I have no idea where to get them. The Aros website appears a bit cryptical to me. I originally got the Roms by spying on SAE and looking where it loads them from 😟.

naTmeg commented 5 years ago

Just press 'Cancel' to get to the WB.

But I have no idea where to get them.

https://sourceforge.net/projects/aros/files/nightly2/20190831/Binaries/AROS-20190831-amiga-m68k-boot-iso.zip/download

The roms are in .iso/boot/amiga

I'm just testing....

Edit: Does also not work with the latest roms :/

dirkwhoffmann commented 5 years ago

Just press 'Cancel' to get to the WB.

Oh yes, that makes sense. It's like Windows where you have to press 'Begin' to shut down.

Now I'm in an infinite loop. It refreshes the screen every second or so, but doesn't continue 😢.

dirkwhoffmann commented 5 years ago

I've just run the latest Roms (from Sourceforge) together with the boot disk you've mentioned above in FS-UAE. After hitting 'Cancel' in the Live-CD requester, it reboots, asks again, reboots, asks again etc. To make a long story short: Broken.

We should first find a reliable combination of Aros Roms and boot disks that works let's say in the latest version of WinUAE. Once we have that, we should check that combination in SAE. (Forget about vAmiga at the moment, because it's not a serious emulator yet).

dirkwhoffmann commented 5 years ago

I did run WinUAE 4.2.0 to test the latest Roms from

AROS-20190907-amiga-m68k-boot-iso

in combination with the latest boot disk

AROS-20190907-amiga-m68k-boot-floppy

It doesn’t work. When hitting Cancel in the Live-CD requester, it reboots, thus entering an infinite loop. Same happens when booting the original Workbench.

I also tried to load Barbarian with the Aros Roms. This worked.

To be honest, I still don’t get the idea what Aros is all about.

Hypothesis 1: It meant to be a serious OS as an alternative to state-of-the-art operations systems such as macOS or Linux. This would explain the issues with the OCS Amiga version, because most users might be interested in Aros for other platforms. If this hypothesis is true, what is the unique selling point? What does Aros make better than Linux or macOS?
Hypothesis 2: It is meant to be a way to get around the licensing issues of the original Amiga Roms. If this hypothesis is true, why is there a Linux version of Aros?

If anyone can enlighten me, please do.

With respect to vAmiga, there two choices now:

Option 1: Install the Aros Roms automatically if no original Roms are found. This was my original plan. The problem here is that the Roms seem to have issues (at least the versions for OCS Amigas).
Option 2: On start, automatically open the Rom preferences if no Roms are found. This approach has been taken with VirtualC64.

naTmeg commented 5 years ago

The main reason was to get away from m68k/PPC and going towards x86, as by the time AROS was developed it became obvious, that the PPC-platform was a dead-end road. The second reason was to make a license-free clone of AmigaOS and Kickstart and to rewrite anything in C/C++, as the original OS is mostly written in m68k-assembler, at least the core parts.

Maybe we should contact the AROS-team and tell them about the boot-problem, because I'm not sure if they are aware of it, as the x64-bootloader or the live-cd doesn't require the 512k-roms. They are only used by legacy-hardware or emulators.

There is an older and working version of the roms and WB from Feb.2019 on sae.net, which does successfully boot.

I would go the way that WinUAE does. Have the AROS-roms preinstalled as fallback and the original roms (if found) as option.

dirkwhoffmann commented 5 years ago

Ohhhh, I didn't know the Aros WB can be selected in SAE next to Games and Demos 😯.

But when I boot that thing, I get this screen:

I can move the mouse and the menu bar flickers every second (presumably updating the displayed info). But I cannot do anything else. The window doesn't vanish and I cannot resize it 😢.

In vAmiga, it's exactly the same 🙈.

naTmeg commented 5 years ago

It's working here. Select "AROS Bootdisk" from "Tools".

I've made a screenshot, but GitHub doesn't let me post a png-image?!

Edit: I mailed you the screenshot. Try to minimize the window. Maybe the WB has already loaded behind..

dirkwhoffmann commented 5 years ago

😎 OK, seems like Aros requires FastRam. 512 Chip + 512 Slow isn't enough.

dirkwhoffmann commented 5 years ago

GitHub doesn't let me post a png-image?!

We do this all the time. Their servers must be glowing already by the huge amount of PNGs we drag in here 😂. BTW, I hope there is no quota per project 🤔.

dirkwhoffmann / vAmiga

Booting AROS fails #14