Messages

I suppose every arithmetic operation unit has usually only a few of these memory cells? Not >20?

From a purely functional standpoint you'd only need enough memory cells to save your intermediate results.
Since most instructions only use 1, 2 or 3 word-sized inputs and produce 1 or 2 word-sized outputs, 1 to 3 word-sized memory cells should be enough for most instructions.
It wouldn't make any sense to allocate more physical space on the chip to private memory cells you won't ever need during a calculation, you'd better use that for actual registers or to increase cache sizes.

That makes sense.
But how can the cpu store that second part? Is the result stored in the cache and then transported to the ram?

Well, this brings us really deep into how a processor actually works, but I'll try to explain at a higher level what they taught me at school.
Small disclaimer: it's been 5 years since I had the course that taught this stuff and it was given in different language than English, so I might be wrong on some things or in some terminology - please someone correct me when I'm wrong.

Basically the part of a processor that is responsible for a multiplication (or pretty much any other arithmetic operation) has some sort of small memory cell that's part of the actual circuit for that operation.
This memory cell is used to store intermediate results of an operation and most of the time has a size equal to the word-size of the processor (eg 32-bit or 64-bit). In the case of a multiplication or division this could be 2 different cells, or just a single 2-word sized memory cell.
You could look at this as a sort of private cache/register that only that arithmetic operation can use before it passes its result to the rest of the CPU's pipeline.

As an example imagine you would implement a bit-shift circuit that performs bit-shifting one bit at a time, one bit every cpu-cycle.
If you want to bit-shift 3 bits that means you'd need 3 cycles to execute that operation, so you can't finish it in a single operation. That means you need to somewhere store your intermediate results (bit-shift by 1 and bit-shift by 2), hence the memory cell.

Also note that you can't just use the regular old registers to store these temporary results because most processors these day are superscalar out-of-order processors which basically means they execute multiple different instructions at the same time, so you might have multiple operations processing during a same cycle that each have their own intermediate results they need to store. (If you want to know more about this, please use google or take a course, it would be too much for me to explain :P).

Lastly I'd like to point out that final results of simple operations are never stored directly in RAM but in registers (unless you specified a memory indirection, but again this would be given via a register) because registers are memory INSIDE the processor itself and thus the fastest to do operations on.
When talking about processors we're basically talking about operations that take MICROseconds, whilst asking something to RAM would take several MILLIseconds, so lots and lots slower.
That's why we have caches in CPUs (and several layers of them, with L1 the smallest but fastest layer to access, and e.g. L3 the biggest, slowest memory layer). They aren't used to store results from operations, but rather to store copies of data in RAM so we can access that data faster (preferably in the MICROsecond range) than when we would go to RAM.

That last part brings us a bit of topic, but I would like to point it out cause I noticed you mixed up some things in your comment.

If I remember correctly, on a regular old 32-bit x86 processor the result is simply stored in two registers

e.g: mul src would result in edx:eax = src * eax
where edx stores the most significant bits of the 64-bit result and eax stores the least significant bits.
I'm gonna guess that x64 processors do the same thing.

Apparently RISC architectures like ARM do the same thing, except you need to use a special instruction to keep the most significant bits (i.e. the default mul command assumes the result will fit in a 32-bit register).

@C# : They are very early version(s)... so they don't do much yet... (I keep procrastinating...) I recall displaying text and being able to edit it with  full compression. (Regenerates char tables)... and I also had maps displayed, but they weren't editable. (I was working on that at one point, though.) - One of the ones showing text editing capability was posted here http://forum.goldensunhacking.net/index.php?topic=2560.msg44428#msg44428 ... but I think I had another version elsewhere. (And then I have another version I don't think I posted on this site... but mainly because it is unfinished... that shows the tilesets/tiles used/etc. in map... part of my progress toward map editing.)

I checked the link out, but except for the compression code you shared I can't actually download the files you linked there.
Why not just put the code on github? Even if it's unfinished, it sounds like you got a lot working already and it might prove useful or at the very least educational for some people.

Who knows someone might even fork it and finish what you started but seem to keep postponing :P

Dark Dawn might still be interesting for anything that is similar to the original GS games... as far as data goes, though. And assuming DS games usually have labels and stuff... could even possibly help with some of the terminology for some stuff. (if any)... Like that time with the M&L games.

Do you mean that the compiler they used for DS games left some things in the assembly that references the original source code?
That does sound interesting... However, DD and the original games were written by completely different teams and I doubt very much that the new team would research the old code before starting on DD, so their code base probably looks completely different (even if only because code written in the 90s wouldn't get past code reviews of today's standards)

Might you have the qualifications to do that? :P (AKA: Do you have any hacking experience at all?

I'm more of a high-level programming guy (probably the main reason I'm excited about OGS).
But I'm no stranger to assembly, so I guess there could be some ROM hacking skills in there... somewhere :P

I think Balanced Age is one of the currently most active project being posted on here... My signature does have links to GS docs, though... (GS2 having better documentation than GS1.; Feel free to edit./Guests can edit.)

Having lurked on this forum for about 5 year I do know about the balanced age and I've looked at the golden sun docs in your signature a couple of times while trying to understand the editor's code.

...and there might be some open-source alpha versions of my GS editor stashed somewhere on this site... (Not really worth mentioning about, as of current.)

Now this sounds interesting to me! Having looked at Atrius' editor I have to say: what it does it does well but the code is... well... a huge mess (*please don't hit me*).
The editor could probably use a rewrite, but I do wonder if there are still people who would be interested in this, considering OGS will allow us to do way more than the editor would ever allow and changing/adding stuff would presumably be way easier because we could code it in some high-level language instead of having to write GBA assembly and worry about space requirements.
That being said: where could I find this editor of yours? I wouldn't mind taking a look at it, but I don't seem to find it anywhere.

Welcome to the forums!

Thanks!

Five years???
Wow...

Crazy right?

Activity is kinda low. Projects you want to hear about? Depends a bit on what you like.
We've had this person drawing a map a few weeks ago for example.

I have checked out the map, I love how much work that person put into it! I also enjoy reading the GS stories and theories people have posted here.
Basically: I'm all ear for everything GS related, be it something technical (internals/hacks) or lore/story-wise.
The only exception being if it's Dark Dawn related.... I like to imagine DD happened in an alternate, non-cannon universe or just was never made...

Hello to whoever is reading this!

So I've been looking at the posts on this forum every now and then for probably the last 5 years, but never really felt any reason to create an account here.
Golden Sun 1 & 2 are one of my most favourite games of all times, but over the years I kinda lost interest in them (probably because life got in the way)... Until recently...
Ever since I learned about Open Golden Sun, I've had this huge desire to replay the games, get back into the lore and even took some time to look at TLA Editors' source code.

I've also looked at some other golden sun communities but of all those I have to say that the posts I read here, even after all those years, seem to hit home the most for me. I'm under the impression the people here are REALLY into golden sun.
So I thought: Why not just register an account and we'll see what happens. I probably won't post as much as I lurk around, but at least I hope it shows that there are still people outside of this community who still love golden sun as much as you guys do.

That being said:
Can someone fill me in on how active this community still is?
Are there still any running projects I should be interested in/other stuff I need to know/read?