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,

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,

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.

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

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.

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,

[quote name=CoolCat5000 post=12495]@CoolCat5000 - Oh, o think i understant now @magorium , 🙂
You mean the abstraction layer … that is the place in the code that you need to adapt for each plataform Port.
🙂[/quote]
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

[quote name=CoolCat5000 post=12494]@CoolCat5000 - Hi @magorium ,
Im not sure if i understood you.
[/quote]
No problem, I believe we can figure it out with a bit of explanantion

[quote]
Bellatrix is a bare metal emulator build on top of emu68 (i reuse the emu68 raspberry setup)
[/quote]
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.

[quote]
In the case of the vídeocore, emu68 does the setup and i use the framebuffer pointer. But the AI could do this, im using the EMU68 setup cause it hás simd(neon) stuff and específico irq stuff, and i want to use the EMU68 JIT on the emulator. (And rely on the emu68 setup gives me updates for free 🙂)
[/quote]
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 ?


[quote]
What do you mean about extraction layer?
[/quote]
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.wikipedia.org/wiki/Abstraction_layer

[quote]
(Btw, i could have an IRQ based blutooth handler, but i didnt cause i am afraid of messy the jit)
[/quote]
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.

[quote]
It is my iniciative, but its full AI coding (2 blinds, me and the AI)
[/quote]
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.

[quote]
(Ps: móbile auto correction is a hell 😒)
[/quote]
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.

Oh, o think i understant now @magorium , 🙂

You mean the abstraction layer … that is the place in the code that you need to adapt for each plataform Port.

🙂

Hi @magorium ,

Im not sure if i understood you.
Bellatrix is a bare metal emulator build on top of emu68 (i reuse the emu68 raspberry setup)

In the case of the vídeocore, emu68 does the setup and i use the framebuffer pointer. But the AI could do this, im using the EMU68 setup cause it hás simd(neon) stuff and específico irq stuff, and i want to use the EMU68 JIT on the emulator. (And rely on the emu68 setup gives me updates for free 🙂)

(Btw, i could have an IRQ based blutooth handler, but i didnt cause i am afraid of messy the jit)

It is my iniciative, but its full AI coding (2 blinds, me and the AI)

What do you mean about extraction layer?

Regards,
(Ps: móbile auto correction is a hell 😒)

[quote name=CoolCat5000 post=12471]@CoolCat5000 - Strange, you can acesso the sdcard without the USB....
[/quote]
Not saying that I am able to recall everything a 100% correct as it has been over a decade (at that time there were no drivers, everything was closed source or only a binary blob and the openfirmware implementation for the pi did not exist yet)

But ... I think I made a mistake as I interpreted your earlier message as you refering to native code while the code you (later on with the repo) seem to refer to what looks to me as an abstraction layer (as in not being bare-metal).

A raspi boots using the video-core and at that time there isn't a cpu (yet). This requires a complete other approach than what I was able to locate in the bellatrix repo (unless I missed something, though I am also not up-to-date with regards to the (current) pi boot process).

Not saying that what you seem to be doing is simple but it is a lot easier to address things when there is an actual abstraction layer in place. The benefit of such an layer is that you can concentrate on an actual implementation of/for a driver.

What I am not sure about (I was unable to tell from the repo on such short notice not to mention github being an arse lately) is where that extraction layer is coming from, is that your (own) doing @CoolCat5000?

Hi @deadwood , i dont know if it is something i could handle (upstream code), i can try to make things work (AI alucinates a lot, but on the end it work somehow)

Atm im having a lot of going foward and Back with bluetooth. I hope that i can bring the experience with the emulator to aros code, but its not a real bet (the chipset code it mostly did all the way again, the same mistakes than before)

Probably i Will try to make it work and show on mine repo for a good review.

I had think of try to add big endian support to cherryusb, but i am not sure. It make BE support for it in my project, but its diferent when is a consolidate project.

Lets ser how it Goes, atm bluetooth (its a living hell thing, it messyes the serial output. Some times i can scan entries, but nothing realiable yer)

Anyway i would love to contribute to AROS development, but it couldnt follow a regular workflow. First i need to make it work and than evaluate if its working properlly for upstream grade.

This project is a kind of school for me, and i think it (the AI) can generate working code for AROS, but from this to be something upstreamable it would be another class of learning.

Regards,
Ps: its not a thing that i can discuss (AI opinions are not realiable, i can only trust in the results and from there the code would need to be reviewed)

You May see that its not vaporware

https://github.com/JJDSNT/bellatrix

But its still labs in the learning sense of the word

FYI: This guys is working on AROS for RasPi - he has a number of development/fixing branches. Maybe try contacting him and see if you can help/support him. Would be great if he can join the forum and start showing his work to wider audience.

[url]https://github.com/bsek/AROS[/url]

Strange, you can acesso the sdcard without the USB, but i Will take a look when i build it (atm fighting with bluetooth, really, low level is quite a strange land … )

I want to finish this (arm support) and hope the experience can help the AI to handle the AROS scenario.

(I am using external libraries for usb and bluetooth, but i have even use the AROS code to give some light on the usb bring up 😁)

Regards,

[quote name=CoolCat5000 post=12468]@CoolCat5000 - Wow, that is News for me.
Aros never fully boots on aarch64 native?
[/quote]
Let me be cautious with wording in order to not discredit all the efforts and/or other people... it never did for me (pi3) but might have worked for the developer back then (I do not recall exactly but maybe the original aros-exec forum posts are able to shed a light on that topic).

[quote]
(Dunno why i thought it was missing only the drivers, like usb etc)
[/quote]
It did missed the drivers initially but one of the issues here is that in order to boot AROS (the workbench) you'd need access to the USB (technically the postoffice protocol) to be able to actually load something of disk (SD-card in this instance).


@miker: yeah indeed, it was basically michal (together with kalamatee) who was working on ARM support for AROS back then but he got sidetracked a little (nice little sidetrack though) :-)

[quote name=magorium post=12467]@magorium - [quote name=cdimauro post=12466]@cdimauro - [quote name=magorium post=12465]@magorium - fwiw:
Emu68 for PiStorm?[/quote]

Yeah, that's the name indeed. Thank you very much @cdimauro for that (it really escaped from memory).[/quote]

Michal Schulz was working on AROS then he started to develop Emu68. :-)

Wow, that is News for me.
Aros never fully boots on aarch64 native?
(Dunno why i thought it was missing only the drivers, like usb etc)

Anyway, i would like to try the build some day (not today, that i need to take care of projects not related to amiga and aros)

I hope this week to close the arm side support of the emulator (missing bluetooth and sound. USB working hid and msc, but not a cheap and old keyboard, thought)

That should be enough to make the first version of the readme. (No sense have an emulator that you cant interact with 😬)

Regards,

[quote name=cdimauro post=12466]@cdimauro - [quote name=magorium post=12465]@magorium - fwiw:
Emu68 for PiStorm?[/quote]

Yeah, that's the name indeed. Thank you very much @cdimauro for that (it really escaped from memory).

[quote name=magorium post=12465]@magorium - fwiw:
The native (32-bit) version of AROS for ARM never managed to boot all the way through. The developer at that time took another route and started working on the PI to be included in a native Amiga as an accelerator (sorry, the exact name of this hardware eludes me at time of writing this).[/quote]
Emu68 for PiStorm?

fwiw:
The native (32-bit) version of AROS for ARM never managed to boot all the way through. The developer at that time took another route and started working on the PI to be included in a native Amiga as an accelerator (sorry, the exact name of this hardware eludes me at time of writing this).

One of the issues with the native version for the PI is the firmware of that specific hardware, as it changes all the time and back then broke things on a regular base. No idea if that is still the case though.

The hosted version however worked as intended back then on a 32 bit-linux host. It should still work but haven't tried for ages as somewhere along the line something broke for the 32-bit ARM AROS hosted version in that I was unable to build it (the nightly builds failed as well back then). I have not ran this version since then.