but isn't this project in alpha stage anyways? Wouldn't there be multiple core versions that will meet everyone's meet in the long rung?
Actually, I do not think that this would be a good choice. The argument is again the same as above: If a user would have to decide between software for N different versions, I would expect a lot of trouble. This is very much the same reason why I believe that adding new instructions is not a good choice, at least not without further understanding what is actually needed and what is not.
Look, what I want to avoid is a "software mess" where we have half a dozend of different CPU cores and a user does not know which version of the software to install nowadays. Adding more versions is not helping.
Wouldn't there be issues at first, then as we progress we fix these issues later? Much like PS 4 operating system, linux, windows, etc. All of them have issues at release and get patched as days come by.
Oh yes, but these patches do not impact compatibility. Surely enough, the FPGA core will alsa have bugs - this is normal and not unexpected - and these will also be fixed later, also without impacting compatibility.
But what should not happen at this point is to create a "new core" that defines instructions we do not even know about at this point whether they will find applications.
ONE OF THE GREATEST pleasure is patching my hardware in my A500 through workbench in my A500 itself. I mean, guys discuss (in civilized way) but whatever concern, issue, etc...aren't all of these will be resolved by downloading a 10 MB compressed zip file and then flashing the card with the new firmware?
Well, yes. If we are talking about bugs, yes. But would you end up with software that says "must flash the core to version 3.4x first, and avoid branch 4A5". Look, with Amiga software (!) we have today the problem that we have (unfortunately) quite a number of extensions and "improvements" that cause problems by mutual incompatibility. Certain programs cannot be used togehter with certain other programs, authors probably did not know better, or decided that an "enhanced interface" would be better, but did not consider side effects.
Now, by moving "software into the hardware", a thing an FPGA core does, we run very much into the danger that the same problem appears again, but on a lower level. Namely, authors (not Gunnar alone) are creating mutual incompatible CPU cores that work almost, but not quite alike. Leading to "unexpected behavior" in some situations. The average user will not be able to resolve such a situation.
Thus, at this point is seems to be very necessary to build on a very stable, and accepted ground. And that is the 68K ISA "as designed by Motorola", and not some "self made" extension. Maybe this extension is even useful, but it is still the wrong start for a project like this.
I guess the only suggestion I would like to add to biggun if he is willing to listen to me :$ if possible could you add a tiny mini PCI or something that can fit inside the A500 case that allows the person to upgrade the RAM from 128 to say 1 GB or 2 GB RAM.
Actually, to disappoint you: Gunnar is "only" programming the core. He does not build or design the hardware. So, not the right address. But if you want my two cents: Currently, this would make the project only more expensive and would create more costs, probably also more support costs by folks using incompatible or untested RAM. I would suggest against this, at least now.
I discovered in OS 4.1 that 128 MB is nothing...so from experience I will find 128 MB to be too limiting...especially if I want to do DOSBox, heavy emulation in my A500 etc.
Well, but look. Os 4.1 is PPC, which has a lower code density, and which is a more "elaborate" design than AmigaOs. I doubt we will see any browsers soon, or any memory extensive program. Once that happens, be ready for extensions. This is not the final project, it is a start.
