No problem, I believe we can figure it out with a bit of explanantion


Ah yes, this mention of bare metal is one of /my/ confusions.

If I read the description of the github page "A bare metal generic Amiga machine emulation for raspberry pi 3B " then this
implies (for me) that some piece of software (in this case bellatrix) is running bare metal on the raspberry pi.


After this part of your message and some other post you made I now understand that the baremetal that was mentioned is not entirely the truth. Perhaps from the point of view of bellatrix it is running baremetal but in that case not directly bare on the pi itself but via/through a layer (that what I named an abstraction layer).

The abstraction layer being emu68.

Thus, as far as I understood, bellatrix does not communicate directly with the raspberry pi hardware but does so indirectly by using
that abstraction layer.

As I wrote earlier that does not make it less difficult but a lot more convenient to try and develop for example a driver because such an
abstraction layer has proficiencies in place that makes it easier to communicate with the underlying hardware that bellatrix runs on.

That is, assuming that there are no errors present in such provided abstraction layer.

So this caused the confusion on /my/ part as I interpreted the github description as bellatrix being the first thing that gets booted on/at the pi.

Those are two separate situations and hence why you do not (have to) use any /direct/ communication with the pi hardware (bellatrix does this indirect).

From that I /guess/ you have never seen any arm assembly instructions in any of the bellatrix code itself at all ?



Hopefully I was able to explain that with the above reaction.

In case not: An abstraction layer is a part of the code that hides the nitty gritty details and presents a (more) easy to understand interface that make things easier to communicate with.

see also wikipedia: https://en.wikipe...tion_layer


I am not in a position to write anything related to jit and IRQ timings. I can only tell that any protocol is
usually very strict about timing.


Although I don't like to use AI for my own work (and so I do not use it for that) I do understand that it is able to offer
solutions such as in your case. I think it is a nice intitiative and can be used to learn a lot about several things. Especialy if your not that familiar with coding.


Yes, I know and that is why I never use it myself :-)

In case of any question(s) left please do not hesitate to ask or if inclined to correct me in case I wrote something stupid.

regards,
Ron.

Not entirely

If you have a lot of details to let a specific part of code work (let's take your example of platform specific code) then each platform
has it's own specific implementation while an abstraction layer would hide this platform specific details from use.

So let's say for example you want to save a file and each operating system/platform has it's own individual (incompatible) API for saving a file. You could make a function that saves a file using each individual platform API but the end-code uses only one single function that can save a file but without bothering you with all those details (those details could for example differ for each platform compilation).

The above is just a simple example of abstraction.

An abstraction layer usually provides a bunch of such abstractions for instance to implement a specific interface. As long as you specify that interface and use a more or less consistent approach overall then it is usually easier to accomplish complicated things with simple instructions (read : functions).

AROS itself is for example in principle an abstraction layer of/for the Amiga API.

PS: programming, it is boring so never try to make a hobby out of it

Hi @magorium , you understood ok, but we can split emu68 in 2 things:
-the bare metal setup of the pi
-the jit emulator

I am not using an abstraction layer, i am reusing emu68 code for the pi setup (where it exists), but not where it doesnt (but that is not the challenge in the AI perspective. It can bring up raspberry from the ground)

But emu68 is very pistormcentric, and that is a challenge.

I did made emu68 emulation work, but with real bad performance (for sure wrong integration)

With musashi i got a better performance.

Dunno if this explains better.
It has no abstraction layer, like for usb or bluetooth. I am reusing Emu68 code cause it makes sense. Its allready there.

The problem is integrate the emu68 jit. I first was thinking of just make the chipset, but that wasnt enough.

So bellatrix is a machine emulation to glue the chipset with the cpu.

Its an early approach. I dont have the Skills to pimpoint expected behaviours, só i did a full machine, but it can evolve to have less machine, and the chipset is a portable library, so could be used in a wine kind of emulation to give hw calls an adress to hit.

But this 2 scenarios are more advanced than i can handle, so i did a basic approach, with coherence but uncoupled, to have space for such evolutions.

In a dream aros could be the OS, and as subsystem emu68 the cpu emulation and rigel the chipset (without bellatrix, the machine) (big speculation assumption here)

As far as i could understood.

Regards,

I don't think that you can easily "glue" together your chipset emulator with Emu68.
Emu68 assumes that it's running on a real Amiga, with all chips that are "intercepting" the chipset accesses coming from the CPU, and acting accordingly.
So, Emu68, as the CPU emulator, has to do nothing: when accessing $DFF****, for example, it just reads from or write to the specific address. Then it's responsibility of the Amiga system logic to "route" the access to the chipset range, and then one of the three custom chips gets activated to handle the proper request (e.g.: putting something on the data bus for a read request, or picking it and doing something on a write request).
With your emulator you should do the same, and intercepting all CPU accesses on the chips address ranges is basically not possible without changing Emu68, because there's no "monitoring" service that the ARM CPU can offer you which does all this work (e.g.: intercepting a request from Emu68 and dispatching it to some handler which triggers your code).

BTW, that's why Emu68 draws circles around WinUAE: the latter has to emulate everything on a single core (only dispatching some "side work" to another core), so the CPU emulations got severely affected by this process. Whereas Emu68 assumes that there's a system already running, and it only has to take care of emulating the CPU at the maximum speed.

That is exactly the issue, i would like to have this talk before ask AI to do this. 🙂

The idea which is floating around from long time (I'm very passionate about computer architectures & emulation) is this:
- map all chips address ranges with the PMMU so that a page fault is generated when Emu68 is trying to access some of those locations;
- set your page fault handler;
- when a page fault exception is generated, on your handler you check the address to see to which chip it was directed;
- decode the load (reading) or store (writing) instruction that caused it;
- "emulate" it by storing the value which came from the chip to the proper CPU register (load/reading) or by passing the CPU value (from register of the store instruction) to the proper chip handler;
- resume the execution from the next instruction (skipping the "offending" one: you've already done all work that is performed by the instruction).

I don't know how Emu68 works, so you need to talk with Michal and check if it's feasible. Maybe this solution does not demand any change to Emu68, since ON PAPER it's you that install the page fault handler, before running Emu68. And you handle all the logic behind. But, please, check it.

Yes, i would love to talk to Michal, but i am not at the pistorm discord anymore (ai phobia).

I started to explainig what i want to do, to have some guidance o how to do it, but it was much talk of a person who doesnt know what is doing, so i started it Anyway.

As i said i had it working, and i almost sure that there was regressivo from my initial hook to the actual. (Bellatrix was not the initial idea and AI doesnt handle well the dinamics of change the path)

But, as i said, now i have some others stuff to be done before i can continue with this.

For sure integrate with emu68 is the heart of the project, but how to do this is yet an open question.

The idea of use the bus as synch protocol got problem with some access done that doesnt pass by the bus, i think

The idea is to minimize the fault handler triggering.

The chipset library was done with pistorm protocol in mind, but nothing stop me from change emu68 to have a propper integration api (i doesnt need to relly on the bus access to know what is going on, like pistorm)

But that is not something i can dig now. It was much more work than i first though. As i said, i have now initial code on most fields needed: the bare metal, the chipset and in the integration.

Musashi was good to have the chipset emulation running, and the emu68 integration was done using the minimal changes possible to emu68

It would be cool if at least emu68 was not pistorm centric as it is now.

It would produce cleaner hooks, at least.

Regards,

Hey, just to be clear, it was not any thing bad from Claude or Michal, they are very very patience, but it is a pistorm server and some people there hates AI and i dont have the same level of knowledge to talk about (and i cant rely on AI background).

But, the skeleton of the project is up. It still needs lots of polishiment, i Will return to it when i have time.

Regards,