Quote:

BigD wrote: @BSzili Don't feed the troll! ZoRam has one 'R' and is a mem

ZORRAM!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!







Regards,
MRJM

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@cdimauro

Quote:

a completely new system, albeit having similarities, wouldn't look attractive.

Well not with that attitude.

Last edited by agami on 09-Sep-2022 at 04:29 AM.

_________________
All the way, with 68k

cdimauro Quote:

The specs from all links that I've posted report "SDRAM" for the memory and there's no mention about other memory (the DDR one). Plus, the DE-10 Nano specs report also this: https://www.intel.com/content/www/us/en/developer/topic-technology/edge-5g/hardware/fpga-de10-nano.html 1 GB DDR3 SDRAM (32-bit data) So, I was thinking that the SDRAM mentioned on the 3 links is that memory, but in lower quantity for some reason, since there's also no mention about this additional integrated board.

The DE-10 Nano board always comes with 1GiB DDR3 SDRAM. It is a standard Intel/Altera developer board with a FPGA designed for embedded markets but MiSTer use may now may be a significant portion of that market. The 128MiB SDR SDRAM board is an optional memory board for MiSTer (smaller memory sizes used to be available). Both DDR3 and SDR memory are SDRAM but they are not compatible with substantially different commands and timings. The DDR3 memory bus is shared with the SoC, GPU and ARM CPU running a cut down (embedded) Linux so real time timings can't be maintained necessary for some chipset memory (the GPU is using SoC memory bus cycles for video output).

https://github.com/MiSTer-devel/Main_MiSTer/wiki/Cores-that-use-SDRAM

The Amiga chipset used some of the cheapest chip memory possible more on par with 8 bit systems so doesn't have as much of a memory timing issue as some other retro systems.

Acorn Archimedes 126MHz
Apple Macintosh Plus 65MHz
Atari ST/STe 96MHz
Commodore 64 63MHz
Commodore Amiga 57MHz
IBM PC/XT 50MHz
Sharp X68000 80MHz
Neo Geo MVS/AES 97MHz
NES 86MHz
Sega Genesis/Mega Drive 107MHz

Some 8 bit systems like the C64 and NES require higher speed SDRAM to simulate their chipsets. CBM left the Amiga with 8 bit memory performance even with AGA as they continued to try to turn the Amiga into a C64, which ironically has a little faster memory access. This doesn't show memory access width (comparable for 68000 systems) but still gives an idea of CBM cheapness and why the Amiga lost competitiveness. Low chip memory bandwidth and no fast memory on most stock Amigas made the Amiga chipset and the 68k look bad. Jay Miner's Ranger VRAM request was denied.

cdimauro Quote:

I don't see any reason why a core/system couldn't use that memory whereas other can. SDRAM implemented this way might also run at low frequencies, so severely reducing the memory bandwidth. In short: additional cost for something which is much worse than the already available DDR. Only MiSTer can make it possible...

The DDR3 memory is accessible and using it is no worse than using a CPU emulator but some gamers want more accurate real time memory access like the original hardware. More memory bandwidth from more modern memory doesn't solve the problem and it is more work to convert commands and extract the needed data from the wider memory returned. The big issue may be the SoC DDR3 memory usage locking out FPGA memory access for too long to meet real time constraints. A 5GHz CPU and DDR5 memory won't fix this problem either. A separate memory bus fixes it though. A SoC designed for this purpose could probably solve this issue too without a sandwich of boards.

Speaking of Amiga community unity or rather disunity, there is a Vampire thread on EAB that added many pages over a few days. There are lots of abused people by the Vampire cult in the thread like Thomas Richter (AmigaOS developer), nonarkitten (Buffee project), meynaf, Chucky and Gorf.

Gorf from http://eab.abime.net/showpost.php?s=9e636ce45bd748911af4ad6a9a2458e9&p=1563440&postcount=725 Quote:

Well - Thomas is not the only one ... Gunnar also told lies about me in a public forum and banned me from his forum, for pointing out some obvious errors on his part, only to address these errors shorty after he realized I was right, but without ever apologizing or rehabilitating me. He certainly has a way of alienating people, even those who only wanted to help as in my case... So for me it is now really hard to justify becoming a customer of such a person, but I try to stay objective on the technical part and as I said: I actually do like many things the Vampire does. The lack of a version for the A3000 makes it easy for me to not buy one Not beeing significantly faster than my CyberstormPPC is an other good reason ...

Most of these people are respected developers still being attacked in the EAB thread. Conversation eventually starts comparing the Apollo core and 68060. Nonarkitten still thinks the Apollo core is based on a Freescale ColdFire released core which I strongly think she is wrong. I believe Jens wrote nearly all of the N68k core (I have the VHDL source with no copyrights attributed to Gunnar as I recall), Chris wrote the FPU and Thomas wrote SAGA. Why they let Gunnar run the show and be the PR piss everybody off guy I don't know. Anyway, the 68060 only being able to fetch 4 bytes/cycle was brought up again and some people think this means it can only execute 4 bytes/cycle. This led to a discussion about instruction lengths you may find interesting as Bruce Abbott posted several results.

http://eab.abime.net/showpost.php?s=9e636ce45bd748911af4ad6a9a2458e9&p=1563961&postcount=898

On average, nearly 50% of his 68k Amiga program instructions are 2 bytes. These are super easy to decode as the instruction length is known from reading the word. About 90% of instructions are 4 bytes or less. He doesn't give addressing mode breakdowns like ADisStats but it is pretty obvious these are also easy to decode as most are (d16,An), #d16 or (xxx).w. The only modes where the length is not known from the first word are (d8,An,Xn), (bd,An,Xn), (d8,PC,Xn), (bd,PC,Xn) which are not common and they are known from fetching the next word for 4 byte instructions. The 6 byte instruction frequency only average 5%-10% and most of those would be #d32 or (xxx).L with the instruction length known from the first word. Admittedly, instruction decoding of move (ea),(ea) with both ea modes using (d8,An,Xn), (bd,An,Xn), (d8,PC,Xn), (bd,PC,Xn) is inefficient and requires examining 3 words with data between but these instructions will almost always be at least 6 bytes and usually more. The percentage of instructions using more than 6 bytes is only something like 1%-2%. Realistically, I would expect at least 95% of 68020 code instructions on the Amiga can be fully decoded from the first word and worst case decoding is less than 1% of instructions. The way the 68060 is designed with the instruction buffer decoupling the fetch pipeline from the execution pipeline, the fetch and predecoder spending a few cycles on worst case instruction decoding isn't going to make much difference when they are 1% of instructions. In fact, since the 68060 could only fetch 4 bytes/cycle, it spent multiple cycles on all longer instructions and not just hard to decode ones but this had little affect on performance because most instructions are short.

The 68000 was easier to decode because the instruction length was always known from the first word as (bd,An,Xn) and (bd,PC,Xn) did not exist leaving (d8,An,Xn) and (d8,PC,Xn) of known length as the only options. The Apollo core ISA is the most difficult to decode because it takes everything the 68020 has and adds a prefix word. Worst case is up to 4 words that need to be examined for decoding which is starting to look more like x86 (uses a loop to iterate through prefixes and instruction bytes?). This is bad for code density as well and with all the extra registers the 68k is now fatter than PPC which Freescale couldn't par down to compete with ARM for embedded use. Perfect for competing on the desktop I suppose and PPC Amiga users love those registers. Maybe it is the perfect replacement for Amiga PPC hardware.

Last edited by matthey on 10-Sep-2022 at 10:45 PM.
Last edited by matthey on 09-Sep-2022 at 07:29 PM.

@MEGA_RJ_MICAL

Do you ever even own an Amiga? We know absolutely nothing about why you even have a passing interest in the platform. Did you put one on your Christmas list once and got bought an Amstrad? That would explain a lot!

Last edited by BigD on 09-Sep-2022 at 08:14 AM.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@BigD

Quote:

Don't feed the troll! ZoRam has one 'R' and is a memory board. It has nothing to do with a protest against a derailed thread. He can burn a bra at home for all I care his cause is pointless and his methods inane IMHO! How is p!$$ing around with the start of each page anything other than petty? Violent Ken says, "DeeeeNNeeeeb" Oh yeah, and that means "free Tibet"!

Don't worry, I wouldn't feed trolls like this Violent Ken fellow. I'm only here to catch up with my good friend MRJM

_________________
This is just like television, only you can see much further.

@BigD

My thick-skulled friend,

I made the Amiga.
Well at least Amiga's first windowing system and UI engine.

DOES THAT QUALIFY ME AS AN AMIGAN IN YOUR BOOK?


- Franko

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@kolla

Quote:

kolla wrote: @cdimauro Quote: SDRAM board (recommended expansion) – This small board plugs into the GPIO0 connector of the DE10-nano board. Whilst the DE10-nano has fast DDR3 memory, it cannot be used to emulate a retro EDO DRAM due to a high latency and shared usage from the ARM side. This SDR SDRAM on a daughter board is required for most cores to emulate a retro memory module. And this isn’t the case just for MiSTer. But when you’re using Minimig with RTG/RTA and close to no chipram in use, it really doesn’t matter. There’s been talks every now and then about moving chipram to DDR as well, but that would mean a deeper departure from the other Minimig cores (MiST etc), lots of work for very little gain. https://github.com/MiSTer-devel/Main_MiSTer/wiki https://github.com/MiSTer-devel/Minimig-AGA_MiSTer

Now I've spent a lot of time seeking for the documentation of the DE10 Nano board and MiSTer.

In short: accessing the DDR comes through the two ARMs functional block (which is separated from the FPGA one), so there seems to be some complications (for which unfortunately I've found no clear information).

The DDR3 isn't, by itself, a problem. In fact, the DDR memory has better latencies compared to the best SDR (133Mhz), as you can see from this table: https://en.wikipedia.org/wiki/CAS_latency#Memory_timing_examples
Specifically, you can take a look at the values for First word, Fourth word and Eighth word.
Assuming that the DDR3 used on the DE-10 is 1600 (which makes sense, since the ARM processors are running at 800Mhz) and even taking into account the highest CAS (11), you can clearly see that the ns values for the above 3 types of memory accesses are way way better compared to the SDR.

Anyway, without details it's difficult to understand that's the real problem with the DE-10 Nano board and MiSTer.


@matthey

Quote:

matthey wrote: cdimauro Quote: The specs from all links that I've posted report "SDRAM" for the memory and there's no mention about other memory (the DDR one). Plus, the DE-10 Nano specs report also this: https://www.intel.com/content/www/us/en/developer/topic-technology/edge-5g/hardware/fpga-de10-nano.html 1 GB DDR3 SDRAM (32-bit data) So, I was thinking that the SDRAM mentioned on the 3 links is that memory, but in lower quantity for some reason, since there's also no mention about this additional integrated board. The DE-10 Nano board always comes with 1GiB DDR3 SDRAM. It is a standard Intel/Altera developer board with a FPGA designed for embedded markets but MiSTer use may now may be a significant portion of that market. The 128MiB SDR SDRAM board is an optional memory board for MiSTer (smaller memory sizes used to be available). Both DDR3 and SDR memory are SDRAM but they are not compatible with substantially different commands and timings. The DDR3 memory bus is shared with the SoC, GPU and ARM CPU running a cut down (embedded) Linux so real time timings can't be maintained necessary for some chipset memory (the GPU is using SoC memory bus cycles for video output).

So I assume that the SoC, GPU and ARM cores take priority over the FPGA memory requests.
Quote:

https://github.com/MiSTer-devel/Main_MiSTer/wiki/Cores-that-use-SDRAM The Amiga chipset used some of the cheapest chip memory possible more on par with 8 bit systems so doesn't have as much of a memory timing issue as some other retro systems. Acorn Archimedes 126MHz Apple Macintosh Plus 65MHz Atari ST/STe 96MHz Commodore 64 63MHz Commodore Amiga 57MHz IBM PC/XT 50MHz Sharp X68000 80MHz Neo Geo MVS/AES 97MHz NES 86MHz Sega Genesis/Mega Drive 107MHz Some 8 bit systems like the C64 and NES require higher speed SDRAM to simulate their chipsets.

I saw it during my research and, frankly speaking, I was wondering how it was possible.

The SDR has a 16-bit bus size and runs at up to 133 (or a bit more, sometimes) Mhz. So, there's plenty of memory accesses & bandwidth available for all those retro systems.

How is it possible that the C64 core requires the SDR running at 63Mhz when the original system had a 2Mhz 8-bit access (each cycle. One cycle for the VIC-II and one for the 6510) to the memory? Same thing for the Amiga, which had a 3,5MColorClocks = 7Mhz 16-bit memory (64-bit for AGA).

Similar considerations could be made for all other systems, because their original specs regarding memory were almost an order of magnitude inferior.

It's too strange...
Quote:

cdimauro Quote: I don't see any reason why a core/system couldn't use that memory whereas other can. SDRAM implemented this way might also run at low frequencies, so severely reducing the memory bandwidth. In short: additional cost for something which is much worse than the already available DDR. Only MiSTer can make it possible... The DDR3 memory is accessible and using it is no worse than using a CPU emulator but some gamers want more accurate real time memory access like the original hardware. More memory bandwidth from more modern memory doesn't solve the problem and it is more work to convert commands and extract the needed data from the wider memory returned. The big issue may be the SoC DDR3 memory usage locking out FPGA memory access for too long to meet real time constraints. A 5GHz CPU and DDR5 memory won't fix this problem either. A separate memory bus fixes it though. A SoC designed for this purpose could probably solve this issue too without a sandwich of boards.

I agree: it could explain it.
Quote:

Speaking of Amiga community unity or rather disunity, there is a Vampire thread on EAB that added many pages over a few days. There are lots of abused people by the Vampire cult in the thread like Thomas Richter (AmigaOS developer), nonarkitten (Buffee project), meynaf, Chucky and Gorf. Gorf from http://eab.abime.net/showpost.php?s=9e636ce45bd748911af4ad6a9a2458e9&p=1563440&postcount=725 Quote: Well - Thomas is not the only one ... Gunnar also told lies about me in a public forum and banned me from his forum, for pointing out some obvious errors on his part, only to address these errors shorty after he realized I was right, but without ever apologizing or rehabilitating me. He certainly has a way of alienating people, even those who only wanted to help as in my case... So for me it is now really hard to justify becoming a customer of such a person, but I try to stay objective on the technical part and as I said: I actually do like many things the Vampire does. The lack of a version for the A3000 makes it easy for me to not buy one Not beeing significantly faster than my CyberstormPPC is an other good reason ... Most of these people are respected developers still being attacked in the EAB thread. Conversation eventually starts comparing the Apollo core and 68060.

Yes, I saw the thread. It's interesting somehow, but I had not time to read the last 8 pages. I'll try to keep up today.
Quote:

Nonarkitten still thinks the Apollo core is based on a Freescale ColdFire released core which I strongly think she is wrong.

Indeed. She's absolutely wrong on that. I don't understand how she could reach out those conclusions just by reading the thread on Freescale's forum.
Quote:

I believe Jens wrote nearly all of the N68k core (I have the VHDL source with no copyrights attributed to Gunnar as I recall),

I also have it, because you gave it to me via email when I was involved on the TiNA project.
Quote:

Chris wrote the FPU and Thomas wrote SAGA. Why they let Gunnar run the show and be the PR piss everybody off guy I don't know.

What it's surprising me is why Jens hasn't continued with its N050 softcore to at least complete it.

Or, why someone else hasn't used it to continue this project, if Jens has lost interest / has not time for it.
Quote:

Anyway, the 68060 only being able to fetch 4 bytes/cycle was brought up again and some people think this means it can only execute 4 bytes/cycle (actually 2x6bytes for the two integer pipes). This led to a discussion about instruction lengths you may find interesting as Bruce Abbott posted several results. http://eab.abime.net/showpost.php?s=9e636ce45bd748911af4ad6a9a2458e9&p=1563961&postcount=898 On average, nearly 50% of his 68k Amiga program instructions are 2 bytes. These are super easy to decode as the instruction length is known from reading the word. About 90% of instructions are 4 bytes or less. He doesn't give addressing mode breakdowns like ADisStats but it is pretty obvious these are also easy to decode as most are (d16,An), #d16 or (xxx).w. The only modes where the length is not known from the first word are (d8,An,Xn), (bd,An,Xn), (d8,PC,Xn), (bd,PC,Xn) which are not common and they are known from fetching the next word for 4 byte instructions. The 6 byte instruction frequency only average 5%-10% and most of those would be #d32 or (xxx).L with the instruction length known from the first word. Admittedly, instruction decoding of move (ea),(ea) with both ea modes using (d8,An,Xn), (bd,An,Xn), (d8,PC,Xn), (bd,PC,Xn) is inefficient and requires examining 3 words with data between but these instructions will almost always be at least 6 bytes and usually more. The percentage of instructions using more than 6 bytes is only something like 1%-2%. Realistically, I would expect at least 95% of 68020 code instructions on the Amiga can be fully decoded from the first word and worst case decoding is less than 1% of instructions. The way the 68060 is designed with the instruction buffer decoupling the fetch pipeline from the execution pipeline, the fetch and predecoder spending a few cycles on worst case instruction decoding isn't going to make much difference when they are 1% of instructions. In fact, since the 68060 could only fetch 4 bytes/cycle, it spent multiple cycles on ll longer instructions and not just hard to decode ones but this had little affect on performance because most instructions are short. The 68000 was easier to decode because the instruction length was always known from the first word as (bd,An,Xn) and (bd,PC,Xn) did not exist leaving (d8,An,Xn) and (d8,PC,Xn) of known length as the only options.

Impressive! Thanks for reporting this information because it was absolutely interesting and shows how this thread was useful, despite the original topic and the angry row.

The only problem with such data is that unfortunately they are available only for the 68k. For some makes sense, because they are written in assembly. Some others are compiled, but without the sources, the compiler used, and the compilation options used, it's not possible to generate code for other architectures and making comparisons.

Anyway, what looks very strange to me is that most of the compiled applications used a lot of single 16-bit word as the most common case. Which is really surprising, since I expect that immediates, memory references, and more complicated instructions should have dominated the numbers.

Another thing is that we don't know if compilers were too much limited on the code generation and much more simple, 16-bit, instructions were emitted instead of less and longer instructions. If this is the case, then it could be not so good because the processor has to execute more instructions.

I'll report those data on the code density thread which I've opened time ago.
Quote:

The Apollo core ISA is the most difficult to decode because it takes everything the 68020 has and adds a prefix word. Worst case is up to 4 words that need to be examined for decoding which is starting to look more like x86 (uses a loop to iterate through prefixes and instruction bytes?).

Indeed. But checking for this prefix should be much easier and more efficient, because it just requires a comparison of a few bits against a specific sequence of them.
Quote:

This is bad for code density as well and with all the extra registers the 68k is now fatter than PPC which Freescale couldn't par down to compete with ARM for embedded use. Perfect for competing on the desktop I suppose and PPC Amiga users love those registers. Maybe it is the perfect replacement for Amiga PPC hardware.

In fact. But versions of the ISA with a reduced number of registers could be realized in future, if the embedded market is something which the Apollo Core want to address.

It would be more or less similar to the RISC-V ISA for the embedded world, which uses only 16 registers.


@agami

Quote:

agami wrote: @cdimauro Quote: a completely new system, albeit having similarities, wouldn't look attractive. Well not with that attitude.

What could improve the situation?

@cdimauro

Quote:

Anyway, without details it's difficult to understand that's the real problem with the DE-10 Nano board and MiSTer.

There isn’t any problem per se, it just requires work and changes. The MiSTer project very much came from MiST, the MiST firmware (which again came from Minimig) was ported to Linux, where it runs as an ordinary process, and then cores could easily be ported over. It made sense to use same RAM as on MiST (also why first addon cards were just 32MB). After some initial chaos, a more robust and strict framework for all cores was established, and MiSTer started taking over for MiST. Some cores needed more RAM, 64MB addons came around, and then some games for the NeoGeo core needed 128MB. Eventually, the need for extra ram board may vanish, but there’s no rush, noone is bothered, cost is low and it simplify many things, so low priority. If it happens, you won’t need any addon to use the Minimig core, just the de10-nano.

Meanwhile, some cores were given the option of getting some of the DDR ram as well. This is why Minimig core currently can have 384MB of fast ram.

Last edited by kolla on 09-Sep-2022 at 12:17 PM.
Last edited by kolla on 09-Sep-2022 at 12:05 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

Quote:

Some 8 bit systems like the C64 and NES require higher speed SDRAM to simulate their chipsets. CBM left the Amiga with 8 bit memory performance even with AGA as they continued to try to turn the Amiga into a C64, which ironically has a little faster memory access. This doesn't show memory access width (comparable for 68000 systems) but still gives an idea of CBM cheapness and why the Amiga lost competitiveness. Low chip memory bandwidth and no fast memory on most stock Amigas made the Amiga chipset and the 68k look bad. Jay Miner's Ranger VRAM request was denied.

Commodore was looking for yet another external technology injection from HP's PA-RISC.


Amiga ECS move mirrored Commodore 128's aging C64 gaming hardware with low color count/high resolution "business" mode.


Commodore's internal "nextgen" R&D before the external Amiga technology injection was the crap Commodore 900. The project was initiated in 1983 by Commodore systems engineers Frank Hughes, Robert Russell, and Shiraz Shivji. Manufacturing was to commence in 1985 at Commodore International's West Germany plant.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@kolla

Quote:

kolla wrote: @cdimauro Quote: Anyway, without details it's difficult to understand that's the real problem with the DE-10 Nano board and MiSTer. There isn’t any problem per se, it just requires work and changes. The MiSTer project very much came from MiST, the MiST firmware (which again came from Minimig) was ported to Linux, where it runs as an ordinary process, and then cores could easily be ported over. It made sense to use same RAM as on MiST (also why first addon cards were just 32MB). After some initial chaos, a more robust and strict framework for all cores was established, and MiSTer started taking over for MiST. Some cores needed more RAM, 64MB addons came around, and then some games for the NeoGeo core needed 128MB. Eventually, the need for extra ram board may vanish, but there’s no rush, noone is bothered, cost is low and it simplify many things, so low priority. If it happens, you won’t need any addon to use the Minimig core, just the de10-nano. Meanwhile, some cores were given the option of getting some of the DDR ram as well.

OK, understood. So, it might be that the SDRAM could be removed in favor of using only the DDR.
Quote:

This is why Minimig core currently can have 384MB of fast ram.

Are the remaining 640MB reserved to Linux?

@amigang

In one sense I could see this as an easier way to share ports, which would be nice.

The flaw is that the stakeholder involvement from all the camps can never be balanced so putting money into a pool to allocate to a stakeholders preferred project and so many will not be interested in the concept. Since "Amiga" is so many banners right now, it doesn't seem equitable. Plus every banner is at a entirely different level that needs something different.

So funding individual projects seems to make the most sense under each respective banner. Such as the new video drivers created from the bounty.

Last edited by Matt3k on 09-Sep-2022 at 07:21 PM.

@Matt3k

Well firstly I don’t think CAGA aim is to stop individuals from raising funds, it might provide an alternative but it might be let’s say a Kickstarter or bounty to get something ported / made is just shy of funding, CAGA could come in and push it over the edge, or provide the connections / promotions so that not as much money would be maybe required to get the project going.

Plus things like sponsoring shows are to the befit of all Amiga users, very few show would tell one camp or another their not welcome (in fact I don’t know if that ever happened?) if anything more the merrier to make the little meet ups and shows successful.

And finally let’s not forget the freebies,(1 ebook, 2 documentary, a music cd, game and discounts to future products for £30) David could of made this bundle and had all the money go to his back pocket, instead he basically saying all the money raised will go into future Amiga projects, wich I think is pretty cool shame I own and back most of the content but it’s a no brainier to me if you don’t own any of the stuff offered.

Last edited by amigang on 09-Sep-2022 at 08:50 PM.

_________________
AmigaNG, YouTube, LeaveReality Studio

@cdimauro

Yes, 640MB for Linux, running the MiSTer «firmware» program.

I’ve put up a disk image with Gentoo userland too, to host and run all the stuff that the project’s distro lacks, like rshd, telnetd, various proxies etc. that are useful from the Amiga side, as well as my own spins of sshd, zsh, vim etc. Yes, I build it all from source on the MiSTer.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: @cdimauro Yes, 640MB for Linux, running the MiSTer «firmware» program. I’ve put up a disk image with Gentoo userland too, to host and run all the stuff that the project’s distro lacks, like rshd, telnetd, various proxies etc. that are useful from the Amiga side, as well as my own spins of sshd, zsh, vim etc. Yes, I build it all from source on the MiSTer.

Got it. However 640MB of RAM used only for that (I saw some videos with the OSD interface that is displayed) looks overkill to me.

It would be interesting to have an AROS port for MiSTer / DE-10 Nano: to me it's the perfect (small) o.s. for these kind of projects.

@cdimauro
Quote:

cdimauro wrote: @agami Quote: agami wrote: @cdimauro [quote]a completely new system, albeit having similarities, wouldn't look attractive. Quote: Well not with that attitude. What could improve the situation?

There are many different things that can be done to satisfy even the most ardent Amiga OS UI fans.

Historically, vendors have offered the ability to skin a new version of an OS to have the look of the previous one, e.g. Windows has done this a bunch of times. These are minor changes and work when an OS is improving incrementally every so many years, but capturing the UI and more importantly the workflow of a '90s computing paradigm 30 years later, would require additional work.

The completely new system would have a flexible UI framework and a set of new APIs. One of the APIs would be dedicated to Amiga OS compatibility mode. The UI presentation layer would of course be very flexible to allow a very high degree of customization.

Unlike the customization options available today in KDE/Plasma and Gnome, the completely new system would take it a degree further to customize and "theme" workflows (the Z-axis of UX). It's one thing to change the way a window frame and widgets look, it's another to change what options are available when right clicking on an icon, or what default actions are available when double-clicking or drag & dropping an item.

Out of the box, the completely new system could be made to look like a fancy version of Amiga OS 3.x (bordering on Amiga OS 4.x). Then we apply a bit of the James Bond (Q) factor and reveal contemporary options, hidden in plain sight or right beneath the surface. It would be like the "Sleeper PC" of UIs. Looks and behaves like Amiga OS 3.x + add-ons, but with simple actions or gestures it can reveal a modern workflow and UX.

I expect most Amigans who aren't complete romantics will very quickly abandon the old workflow and transition to the modern workflow. But the flexibility in the UI layer is not there to just enable the bipolar Amiga UX, it is there to allow for greater workflow adaptability of the completely new system to various use cases. Something Windows, macOS, Linux WMs, Android, iOS et al, all do very poorly.

Last edited by agami on 10-Sep-2022 at 07:14 AM.
Last edited by agami on 10-Sep-2022 at 07:13 AM.

_________________
All the way, with 68k

@ZORRAM!

Quite a bit off topic, though I bet I could link it if I really wanted to:
In an alternate timeline where Commodore didn't go bankrupt and Amiga maintained its position as the 3rd commercial consumer computing platform into the present day, what do you think the built-in virtual assistant would be called?

Amazon have Alexa, Microsoft have Cortana, Apple have Siri, Google unimaginatively didn't name theirs, and Samsung have Bixby.

Would Amiga's assistant be female only, or would there be a male variant?

Actually, Zorram might not a bad assistant name. Has that feeling of a mystic oracle. But it can be confused with the slavic name Zoran, so maybe not the best.

I would definitely have both male and female assistant names out of the box, and maybe even offer both with slightly different personalities, depending on your mood (configurable).

Alcazar for the male assistant (direct and straight to the point)
Abienta for the female assistant (likes to contextualize answers in story form)

or

Agami as a unisex name for the assistant

_________________
All the way, with 68k

@agami: then you should give a look (and maybe use it) deadwood's AX Runtime, which to me could fit on your proposal / scenario.

@cdimauro

Quote:

cdimauro wrote: @agami: then you should give a look (and maybe use it) deadwood's AX Runtime, which to me could fit on your proposal / scenario.

I am looking at AX Runtime very closely. The project has a lot of potential.

It's also why in my proposed global org I would rally behind AX Runtime and AROS. I'm not interested in fence-sitting. Pick one and run with it.
MorphOS is gonna MorphOS, AmigaOS 4 is gonna Hermans. The only OS that gives the community the freedom of hardware options and future directions and speed (with sufficient funding) is AROS, and promising projects like AX Runtime.

_________________
All the way, with 68k

@agami

Quote:

Actually, Zorram might not a bad assistant name. Has that feeling of a mystic oracle. But it can be confused with the slavic name Zoran, so maybe not the best.

No one knows slavic.





/mega!

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

But, regardless,
PADDING

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK