Hi @magorium and @cdimauro ,
I could boot aros for the first time using emu68.

I had wraped the fault handler/data abort approach and it worked.

Now i Will try a real api, that is what i have in mind, and its what i mentioned before, i dont need to trap the bus as i am not in pistormland, dunno how it will perform but that is what i have in mind.

https://github.co...lic_api.md

Regards,

That should be enough, from what I've read from the technical document that you've shared.

Looking forward...

Hi @cdimauro ,

Me too 😁

Unffortunelly i Will have to stall again, but things are getting shape.

In the worst case scenario we Will have a musashi based bare metal emulator, and with AI no option is out of the desk, almost erverything is a possibility.

Btw, i cant atm, but i made hdmi audio work (and in the same repo has some code about gpu for 3d) that maybe could help for aros native drivers.

Regards,

But for this part you should rely/use the work that Michal already did with Emu68.

I am trying @cdimaiuro , but if i cant sucede i can try the winuae arm jit.

And im doing in C cause the amiga community, my idea was use rust, i am doing it step by step, i got a initial shape.

Emu68 is very pistorm centric, it was my initial goal and i allready have something, but how things Will evolve , in a near future, become more self directioned by a/b tests.

One good thing of rely on others projects is being updating, but there are blockers that maybe i cant remove.

All i am doing i try to be module, so, one direction dont block another option.

The best thing would be to contact Michal, in case that emu68 doesn't offer some solution to your (concrete) problems: it's also on his interest to expand the audience/usage of his project.

Hi @cdimauro , i am almost crying here kkkk

Ok, i talked with Claude (pistorm author) and got a better understanding, but i just reach a point where what worked before does no long works.

And you was right, the fault handler should be embraced, not avoided.

You was right about the 2 things: use emu68 and use the fault handler approach.

Now i have a better understanding, so i can have a more correct design, but i will need time and patience to make it work again.

Also he pointed me an uae version that has lot of insprations to a better chipset emulation.

Really, i am tired. I dont know what is wrong, but i have much more “resources” now, but i dont want to get over this for a while. I tried to register the best that i could for a later resume, but now my head is melted, need to rest.

(I had bluetooth working, a better expansions setup, but something broked, maybe is the multicore refactoring, maybe was the better support for the mmu stuff, in the worst scenario i will spent some time bisecting, but not soon)

I really tried to left the codebase in a working state, but couldnt.

Anyway, thanks for the support and incentive, Lets see what will emerge.

Regards,

Hi @cdimauro ,
Ok, the code got really messy, but clean it up make me understood much better the situation.
I was confusing the fault handler as a sync feature (like how to drive the cycles of cpu/chipset), but it is more a dispatch router for the adresses.
So my idea was to have an api (that could control cycles quantum) to replace the fault handler, that was a major missunderstood.

Now, i will try to clean the mess, with a much better understandig of the desirable design, but still not very confident how thing are drived (i got a real -strange- bad performance with musashi or emu68, but that i should attack after i clean up the mess.

the fault handle stays as the dispatch (MMIO) router, but how the system is driven is not yet solved. (and the api idea i am not sure if its still all wrong, even if it can hurt emu68 performance).

regards,

ps: pistorm doesn use cycles api, it has bus contentios and stuff to drive the system, but i am not sure how to drive the system, i just know that its not working like it was supposed to be (i allready got fast perfomance, but out of sync, bad feel)

ps2: the repo is again in a "working" state! (now, my deserved rest )

Hi @cdimauro ,

I have update the docs to reflect the actual stage of the codebase and my understood of the things.

If someone has a better understanding of this things i am open for sugestions on how things should work,

Regards,

Ps: I had published a page that is a lab. (Its in portuguêse, but i will translate it sometime), The idea is to see what is in the ai context (what the ai has in it “memory”)

Ps2: i am not sure that this way of explaining is the better one, but probably it is the major block atm (and it has allways be as i never had clear idea how i would do that): how to drive/sync the emulation

https://github.co...handler.md

Good that you've sorted out your problems and progressing.

Regarding your question:

"should Rigel's clock instead be driven by its own timer on its own core (Core 2 already runs a ~250 kHz event stream), independent of whatever the CPU is doing, with CPU/MMIO contact only used to observe or stamp chipset time rather than drive it?"

To me it is/should be yes. The CPU and chipset emulation should run on two completely independent cores, with proper synchronization when needed. This to allow the CPU core to run at maximum speed, and gaining much better performance compared to the "interleaved" (CPU & chipset) approach used on UAE.

Hi @cdimauro , infact i got a great regression caused by my mistake (the fault handler stuff)

How the emulation should be driven and sync is not something that i really know.

But yes, there was some advances, like the z3 support that was missing.

Now i have all the pieces and bits that i would liked packaged togheter, even if its not working, or working with the regression status.

The regression fix will demand time and patience, its a testing flow with the real machine in the loop plus each variant and configuration matríce. But from what i had in mind the idea is now closed, só it is a kind of advance.

https://github.co...v0.0.2-rc1

From aros perspective, that is the subject here, it sermos it is stoping at the low level library (i allready had that and fixed once, but regression).

I hope that now the readme is better:

https://github.co.../README.md

Even if the iso part is not fully correct.

I allready use the lide device for hdf and iso support (using the ODFilesystem), and used to work. Not under aros, but under ks20, for example, an it indeed boot a cu magazine iso. (Another regression)

I couldnt do any more teste, but in theory the v0.0.2-rc1 has USB, Bluetooth , rtg and sdcard features built in it.

I couldnt test it so o dono know exactly what is the state there.
(Unfortunelly cause of the regression se are not celebrating this release, a bitter taste)

I dont know when i can look into it again, thats why i released it anyway.

It damm show and broked, but it is what it is. The initial shape is placed and evolve will be time consuming, time that i dont have in the moment to give.

Kind regards, and thank you for the orientation, that design about how to drive and sync the emulation will be needed when we return to it.

In the source there is allready flags for sparsed deadlines and to toogle between timelines modes.

Also claude pointed me a version of uae that i could use to try to optimize the chipset performance

https://github.co.../teensyuae

I think that the poc is “done” but will need love and care and time …

Great. The readme LGTM, however while reading it and thinking about this:
"i could use to try to optimize the chipset performance"
I suggest you to use the core #1 solely for the Blitter emulation, to completely offload all its work from the chipset core.
In this way you've the CPU and the Blitter, which are the most important elements for performance in the system, that can run 100% isolated and taking full advantage of the core. One core for the chipset emulation is good enough (I was thinking about moving the display logic on another core, but this never takes an entire core for processing the raw data and generating the final output).

P.S. I've very limited time, so I try to help when/if I can.

Hi @cdimauro ,

Yes, we can play with the cores, but the real data, as the link i pasted shows, is that even 1 core can perform a full real time emulation.

That is the point, the baseline.

The real data would be to measure stuff, but even there i am lost. Probably it is just bad code or to much fine grained emulation, cant say yet.

Well, about the time, if there are others persons involved it May appear News, otherwise it will be stalled for a while. Anyway, the code is there. For me and for anyone interested in the subject.

Regards,