Here's my proposed organisation:
1. It is divided into at least three separate bodies and participation in each garners a different monthly/annual fee,
- Public relations - Raising awareness in the broader computing market
- Software foundations - Working on development of new APIs, SDK, development knowledgebase, for AxRuntime and AROS
- Hardware foundations - Working on prototypes and bringing up hardware such as add-ons for existing Amiga and Amiga-likes, and hobby boards using 68x (extended 68k)
2. It would organise XPRIZE style initiatives and hackathons to spike developments in SW or HW
3. It would work with education institutions to help students hack solutions with HW and SW that improves their school
4. It would work with NGOs to help solve problems in developing countries
5. It would look to form alliances with other technology companies and startups that are interested in solving the same problems

WOCO - World Open Computing Organisation

How's that for keeping it on topic? - Ed.

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

_________________
All the way, with 68k

@matthey

Quote:

matthey wrote: cdimauro Quote: I know, but usually it's very low: 2-3 cycles. L1 cache access latency is extremely important for performance. The L1 latency matters far more than later multi-level caches. L1 caches use SRAM which allow single cycle access and size increase is the biggest reason the latency has increased. cycle latency | L1 cache sizes | CPU 1 8kiB Pentium 2 16kiB Pentium Pro-Pentium 3 4 32kiB Pentium 4-Intel Core i7 I believe they are pipelining the cache accesses which has advantages and disadvantages.

Indeed. Because 4 cycles for the last i7s is too much: 3 cycles should have been expected (like AMD's Zens, AFAIR).
Quote:

I would have thought faster transistor switching and shorter lines from chip process improvements would have improved timing to allow a single cycle latency 16kiB access or at least a 3 cycle 32kiB access but it is common that set associative ways have been increased which also increases access latency. I expect the biggest factor behind increased ways is supporting multi-threading which increases address aliasing but there may be other factors too.

Plus, a bit higher latency could be balanced by OoOE.
Quote:

cdimauro Quote: 4 times looks too much to me: do you've some data about it? Please recall the RISC-V research I have posted several times before. The RISC-V Compressed Instruction Set Manual Quote: The philosophy of RVC is to reduce code size for embedded applications and to improve performance and energy-efficiency for all applications due to fewer misses in the instruction cache. Waterman shows that RVC fetches 25%-30% fewer instruction bits, which reduces instruction cache misses by 20%-25%, or roughly the same performance impact as doubling the instruction cache size.

I recall it very well, but that's something different. See below.
Quote:

Assuming the 68k has 50% better code density than PPC, a 68k 8kiB I cache would have a miss rate similar to a PPC 32kiB I cache. This is an effective quadrupling of the code in the 68k I cache compared to a similar size PPC I cache.

OK, I see, but here you're talking of something which is completely different: Instruction cache performances related to code density. And I've nothing to say about that.

However, the original context was just code density AKA space used for storing the code:

"the 68060 8kiB L1I can contain as much code as a PPC CPU with 32kiB L1I"

I know that you talked about code density / I$ vs performance in the statement before that one, but in the above one you clearly and undoubtedly were referring to purely code density = space used for storing the code. Hence, my question.
Quote:

I don't know the best way to measure decoding efficiency but x86(-64) is the only variable length encoded architecture I know of that has consistently tried to avoid decoding stages with uop caches, trace caches and instruction delimitation markers in instruction caches.

I've no idea neither. However and AFAIR POWER/PowerPC and some ARM microarchitectures used some uops.
Quote:

Otherwise, the code compression seems worthwhile kind of like a simple on the fly decompressor can increase bandwidth when reading from slow I/O with little or no increase in latency.

Exactly. But I expect some more latency because instructions decoding could require more pipeline stages. However, it's greatly worth the benefit of the higher code density which is achievable and which almost all "RISC" architectures used to implement (compressed instructions).
Quote:

cdimauro Quote: No, this isn't a trace cache (like the one on the Pentium 4), but the usual instruction cache tag bits which were used to put additional and useful metadata. In this case they just add one bit to know when an instruction starts, but more bits might be used to flag other information (e.g.: branches). x86/x64 OoO processors used a significant amount of tag bits in the instruction cache for this purpose. With the introduction of L0 caches (like the trace cache) I expected that they aren't used anymore (or at least significantly reduced). It is more resource usage to avoid the x86(-64) decoding tax. It is smart of Intel to move the decoding tax from a performance and power impediment to a resource hog because transistors are cheap after all. Well, those extra transistors still use more power limiting how low x86(-64) can scale but RISC still can't match CISC performance.

Mostly correct. Yes, more transistors are need for the uop cache, but such uops are much easier to be decoded, so they don't draw so much power compared to the regular x86/x64 decoders.

The x86 tax is only related to the decoders, but it's more or less fix / static how Hammer reported.
Quote:

Too bad there is not a more efficient CISC architecture competing. I would look for one that has competitive performance with x86, better code density, less decoding tax and better power efficiency.

My NEx64T matches all of that. I could share some charts / slides of a technological presentation that I've created (for marketing reasons) which show some relevant statistics on those topics.
Quote:

cdimauro Quote: It depends on how the 16-bit encoding is organized. The one for the 68k family is quite complicated, with a lot of exceptions to be taken into account. A 16 bit variable length encoding is optimal as a compromise for alignment vs code density. Byte encodings have alignment penalties vs 16 bit encodings but can have better code density as exhibited by the Cast BA2x processors but x86 is not optimal and x86-64 is much worse. A 32 bit variable length encoding has better alignment characteristics but horrible code density. Most variable length CPU encodings are 16 bit today (68k, ARM Thumb, RISC-V C) and even intermediate byte codes often changed to 16 bit encodings (Java byte code translation to Dalvik 16 bit encoding for example) while sometimes still called byte codes.

That's why I've adopted it for my NEx64T. And, before that, for WPython (my CPython fork); BTW, Google moved to a 16-bit ISA for its Android after some years from WPython...
Quote:

cdimauro Quote: On the exact opposite, an 8-bit encoding could be easier to decode. x86/x64 is a complicated ISA, but with a simple 32 bytes LuT you can quickly and easily catch its prefixes, for example. Similarly, you can see if instructions have memory references. And so on. You can't do it with the 68k, because using LuTs is too much expensive. Emulators do it because it's "cheap", but hardware-wise it's not possible. It would be interesting to know how Gunnar implemented it on its 68080. Decoding on the 68k is likely more challenging in an FPGA. https://www.eecg.utoronto.ca/~jayar/pubs/kuon/kuonfpga06.pdf Quote: More recently, a detailed comparison of FPGA and ASIC implementations was performed by Zuchowski et al. They found that the delay of an FPGA lookup table (LUT) was approximately 12 to 14 times the delay of an ASIC gate. Their work found that this ratio has remained relatively constant across CMOS process generations from 0.25 μm to 90 nm. ASIC gate density was found to be approximately 45 times greater than that possible in FPGAs when measured in terms of kilo-gates per square micron. Finally, the dynamic power consumption of a LUT was found to be over 500 times greater than the power of an ASIC gate. Both the density and the power consumption exhibited variability across process generations but the cause of such variability was unclear. The main issue with this work is that it also depends on the number of gates that can be implemented by a LUT. In our work, we remove this issue by instead focusing on the area, speed and power consumption of application circuits. Many decoding choices are bad for FPGAs but not ASICs. In the case of the Apollo core, the FPGA disadvantage is partially offset by a fairly modern fab process (28nm) and the relatively low clocked Apollo core in the Cyclone V FPGA.

I see. And shows why sticking to FPGAs isn't the best solution for emulating CPUs. Unless future FPGAs specifically provide cheap & fast LuTs support / implementation.
Quote:

The Apollo core was still able to achieve a reduction in EA calculation time from the similarly clocked 68060 by reducing the EA calc time of (bd,An,Xi*SF) and (bd,PC,Xi*SF) using a full extension word format from 1 cycle to 0 cycles effectively making all addressing modes except double memory indirect modes free. The full extension word format has the most choices and is therefor the most difficult to decode, especially in FPGA,

I agree. That's why I've completely removed them from my 64-bit 68k-inspired ISA (C64K).
Quote:

However, it is not commonly used with 32 bit addressing so has minimal performance impact even with the extra cycle of EA calc on the 68060.

It depends on the specific application. For example, I've used them a lot on my 80186 emulator written for 68020+.
Quote:

With 64 bit addressing, these addressing modes are more useful and reworking and reencoding them would be beneficial anyway. Removing double indirect modes in a 64 bit mode would be a simplification and reduce max instruction length simplifying decoding. While max instruction length is long for the 68k, the common and average instruction length are shorter than x86 and much shorter than x86-64 which grew due to inadequate encoding space (more of x86 encoding space should have been reencoded for x86-64).

Indeed. As I've said several times, x86-64 is a horrible patch over x86...
Quote:

The 68k has more free encoding space to begin with, a separate 64 bit mode frees up more encoding space and is optimal with 2 bits for byte (8b), word (16b), long (32b), quad (64b) integer datatype sizes instead of using a prefix (likely justified to also add more registers for Gunnar's infatuation to increase registers despite Gunnar wanting to use 2 bits for the size field but finding it incompatible without a separate 64 bit mode).

I fully agree: a 64-bit 68k ISA should better re-encode the instructions, properly using the Size field.
Quote:

cdimauro Quote: Well, the only 64-bit 68k extension is 68080 and I expect a very poor code density if some application is compiled (or assembled) using 64-bit data & address registers, since a 16-bit prefix is used in this case; some improvements can come as well, because ternary operations are enabled (AFAIK). Yes, I would expect Gunnar sacrificed 64 bit code density but maybe not worse than x86-64.

It could be better only if 32-bit instructions are used most of the time. This also depends on the code to be compiled.
Quote:

Most new features or accessing the new registers likely requires the prefix, not that I've studied it as it is too painful for me. Really not much new as far as addressing for 64 bit either.

I've studied it, and the major weak point for 64-bit addressing is how address registers are loaded / handled. AFAIR dealing with 64-bit pointers (address registers, memory accesses) always require the prefix and this will kill code density, of course.
Quote:

Better PC relative addressing would be very valuable like (d32,PC) which can be very cheap and even (d64,PC) through the full extended word format would simplify compilers even though rarely used.

64-bit offsets and/or absolute addresses are very unlikely, so I would forget them.
Quote:

We really needed AmigaOS development with it though for something like fully PC relative 68k64 libraries without wasting base relative pointers.

A 64-bit port of Amiga o.s. could only be possible IIF Cloanto wins the legal battle and releases its source.

However I don't think that is has that much value, unless for being used as a reference.

AROS has already 64-bit support and it's the ideal candidate for a 64-bit 68k ISA.
Quote:

cdimauro Quote: No. But I doubt that they could be compatible with a $1-3 SoC. Didn't I say $3-$7 SoC ASIC was a target? That gets a huge transistor budget.

With all such amount if SRAM it might go beyond that. But still under $10. Which should be acceptable.

However you started with a $1 budget and quickly moved by an order or magnitude. The appetite comes with eating...
Quote:

cdimauro Quote: Yes, but with the DDR5 we reached 32 times that data rate of SDRAMs. So, a bit far away, even of the first DDR memory... Supporting the newest DDR memory available makes sense for a new ASIC with external memory as older DDR types become EOL and eventually more expensive and difficult to source. It may be nice if the on chip memory controller could support LPDDR memory as well for lower power embedded use but I don't know if this is possible. The Amiga standard spec could call for DDR over LPDDR though.

LPDDR4 could be a good compromise. DDR4 at least, if DDR5 is (still) too much expensive.

Having a lot of bandwidth is beneficial in several areas.
Quote:

cdimauro Quote: I made a search and I've found that it's much more expensive: https://ultimatemister.com/product-category/ultimate-mister/ https://misteraddons.com/products/mister-bundles https://amigastore.eu/en/866-mister-mini6-128mb-fpga-computer.html The lowest cost is $425. And all of them are bundled with only 128MB of SDRAM. If you have other sources where to buy a standalone & complete MiSTer, please let me know. Trust me, the price of the base board was $140 not long before the Covid crisis and supply disruptions. The base board is the main constraint and out of stock almost everywhere. Eventually, the base board should be restocked although it will likely be $150+ which is reasonable considering current inflation. The producer may have caught on to the fact that the MiSTer base board has become very popular too. The price of assembled MiSTer units has increased (nearly doubled?) but are still available. MiSTer stores which sell them likely bought up base boards when they discovered them low in stock and assembled them with stocks of optional boards so they weren't left with dead inventory of optional boards while the base boards were out of stock. There are lots of MiSTer specific stores as well as sales on Amazon, Ebay, Walmart, Newegg. It really was big business compared to the Amiga, at least before base boards were out of stock.

OK, but... nowadays is what counts and MiSTer is too much expensive. Let's see if next here the chips shortage is over and prices drop down again to acceptable levels.
Quote:

cdimauro Quote: Regarding a MiniPC, here's one of the many (and with good enough quality): https://store.chuwi.com/products/chuwi-herobox-pro Just $180, and it also includes Windows 10. It uses the latest low-power Intel's Tremont microarchitecture: https://en.wikipedia.org/wiki/Tremont_(microarchitecture) which has very good performance (definitely much better than my Silvermont MiniPC, which was already enough for Amiga AGA emulation using Blitter immediate in WinUAE). Too much x86 tax on resources.

x86 here is likely the smallest slice of the cake, taking a look at the overall MiniPC specs.
Quote:

A Pi Zero 2 W at $15 should be able to do descent emulation but in order RISC cores are notoriously horrible performance.

Indeed. At least Tremont is OoO and blows away any RPi.

Unfortunately the Amiga emulation requires a lot of resources and an OoO processor makes a lot of difference.
Quote:

I sure wish we had more efficient in order CISC CPUs that could scale down further than x86-64 like the 68060 using a modern chip processes.

Something like Bonnell? Or like 68080?

@OneTimer1

Quote:

I don't care how much JIT is better than a interpreter at the end your code will run slower than a code compiled directly for the CPU it's running on

That's not actually true. HP discovered this with their dynamo project decades ago. Benchmarks ran faster on a JIT emulation of their own CPU running on itself than they did running directly on the CPU. As much as this sounds like an an over-unity promise, it does have a pretty simple explanation.

Statically compiled code can be full of branching logic that depends on conditions that may actually be invariant at runtime. A well engineered JIT folds these out because it evaluates the path taken. If that path depends on a condition that's always true at runtime (e.g it's a branch dependent on a set once variable) the result is linear code without the test that the statically compiled code has to execute every time.

_________________
Doing stupid things for fun...

@agami

Quote:

agami wrote: @ferrels Quote: Believing that the Amiga will make a comeback is as ludicrous as believing that landline phones will make a comeback. Poor analogy. A proverbial Amiga comeback would not be the literal reintroduction of the computer system from the late '80s and early '90s. I the same way the Apple and Mac had a comeback with the launching of a then modern incarnation of a Mac computer, capturing the essence of the original Mac but contextualized for the late '90s with the Bondi Blue iMac. Also Mac OS experienced a comeback with Mac OS X. It took an operating environment which was seeing a reduction in support from application vendors, to one that has has seen continued growth in vendor support over the years, into the second mainstream platform. Unlike the recent growth in the interest of valve-based amps, vinyl records and turntables, a successful Amiga comeback will require reinvention. Resulting in a NEW system that fits in a contemporary use-case and user context, which embodies some of the essence of the original Commodore Amiga and pays homage with a re-implementation of some if its more familiar aspects.

A completely new system will be quite different from the Amiga o.s..


@kolla

Quote:

kolla wrote: @cdimauro Exactly why are you complaining about “only 128MB SDRAM”?

The context, kolla, you've to look a the context.

Matt: The whole MiSTer base board only cost $140 at one time and that not only included the FPGA but also an ARM SoC, 1GiB of memory, etc.


@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Karlos Compilation usually is CPU intensive, it might be a small pike, it can slow things horribly, if it happens at the wrong places wherry often.

AoT or special JIT caching could avoid it.
Quote:

Putina JIT on 233Mhz / 604e was able to emulate a 68060 @ 50 Mhz, this why Hyperion figured out, no point multi-processing, (back then there where no SMP, so it meant waiting for other CPU) beside context switched between two CPU will kill performance/cache. But the point is that a 233Mhz 604e does not becomes 68060 @ 233Mhz, there is lots of loss. Yes, does gain some speed by native API’s and addons.

Then it's a Petunia (I know that Putin is better known) problem...


@OneTimer1

Quote:

OneTimer1 wrote: @Karlos Quote: Let me let you into a secret. JIT is native. I don't know why people think it's an emulation. JIT compilation is also used in some emulators, in order to translate machine code from one CPU architecture to another. https://en.wikipedia.org/wiki/Just-in-time_compilation I don't care how much JIT is better than a interpreter at the end your code will run slower than a code compiled directly for the CPU it's running on.

HP's Dynamo already proved the opposite some decades ago.

More recently, in some contexts / examples PyPy's JIT was able to outperform a C++ application compiled with the best optimization for generating the binary,


@matthey

Quote:

matthey wrote: PPC 32 GP registers aren't convenient to hold 68k 16 GP registers because of PPC register partitioning between caller save, callee save and system specific (global, base, zero, stack, reserved etc.).

All PowerPC registers could be used on an emulator, under proper conditions.
Quote:

It's funny that the 68k 16 GP registers was able to hold the 8 x86 registers in DOSBox though (in 8 data registers).

It doesn't look optimal. On my 80186 emulator for 68020+ I've mapped only a few 8086 registers on some 68k's data registers because some spare data registers are always needed for internal operations.
Quote:

It was sometimes worthwhile to use SWAP on the 68000 to effectively double the number of registers because memory accesses were so expensive. As memory accesses became cheaper and cached, this trick was less of an advantage. When pipelining and result forwarding/bypassing came about, this trick could also cause partial register stalls and should generally be avoided.

Exactly. Partial register usages cause stalls. At least when working with registers the full register size should be always used.

Data on memory could have smaller sizes and this isn't a problem since years thank to proper memory load/store instructions (MOVZX and MOVSX on 80386+).


@Hans

Quote:

Hans wrote: @matthey I'm well aware of the situation. I simply don't share your interests or goals.

Fair enough. Which makes sense: anyone has his own interests.
Quote:

EDIT: To clarify further, I don't expect anybody to unite behind any particular AmigaOS variant, and wasn't interested in debating which variants are dead, and which ones should be "the future." Classic enthusiasts will likely stick with 68K, MorphOS fans will likely stick with MorphOS, etc., Hence my suggestion to have a common API standard for intercompatibility. Hans

Realistic...


@agami

Quote:

agami wrote: Here's my proposed organisation: 1. It is divided into at least three separate bodies and participation in each garners a different monthly/annual fee, - Public relations - Raising awareness in the broader computing market - Software foundations - Working on development of new APIs, SDK, development knowledgebase, for AxRuntime and AROS - Hardware foundations - Working on prototypes and bringing up hardware such as add-ons for existing Amiga and Amiga-likes, and hobby boards using 68x (extended 68k) 2. It would organise XPRIZE style initiatives and hackathons to spike developments in SW or HW 3. It would work with education institutions to help students hack solutions with HW and SW that improves their school 4. It would work with NGOs to help solve problems in developing countries 5. It would look to form alliances with other technology companies and startups that are interested in solving the same problems WOCO - World Open Computing Organisation How's that for keeping it on topic? - Ed.

@Karlos

Quote:

Karlos wrote: @OneTimer1 Quote: I don't care how much JIT is better than a interpreter at the end your code will run slower than a code compiled directly for the CPU it's running on That's not actually true. HP discovered this with their dynamo project decades ago. Benchmarks ran faster on a JIT emulation of their own CPU running on itself than they did running directly on the CPU. As much as this sounds like an an over-unity promise, it does have a pretty simple explanation. Statically compiled code can be full of branching logic that depends on conditions that may actually be invariant at runtime. A well engineered JIT folds these out because it evaluates the path taken. If that path depends on a condition that's always true at runtime (e.g it's a branch dependent on a set once variable) the result is linear code without the test that the statically compiled code has to execute every time.

Exactly!

Quote:

BSzili wrote: @MEGA_RJ_MICAL Now that's what I call a ZORRAM moment!

Unfortunately,
friend BSzili,

this one was lost in time,
like tears
in rain.

Time,
to VVVVVVOOOOOOOOOOOOOOOORRRRRRRRRRRRRRRRRRRRRR.

UNTIL THE NEXT,
friend BSzili.

Until the next.


/mega

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

@cdimauro

Quote:

Quote: kolla wrote: @cdimauro Exactly why are you complaining about “only 128MB SDRAM”? The context, kolla, you've to look a the context. Matt: The whole MiSTer base board only cost $140 at one time and that not only included the FPGA but also an ARM SoC, 1GiB of memory, etc.

Yeah, so why do you have your panties in a twist over “only” 128MB SDRAM.

Maybe you’re just ignorant about systems you haven’t tinkered with first hand?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@amigang

It depends on what the website offers to people who sign up. A poll is pointless when there aren't enough details to make an informed decision. There isn't much to disuss or even speculate on at this stage and that's probably why the thread has largely veered off into one of the usual three man arguments.

I'm not sure how he hopes to get the number of people he needs to sign up. Amigas sold in the millions but how many actually own, use or emulate one these days, and how do you even reach enough of them to make this viable?

@Rob

Quote:

A poll is pointless when there aren't enough details to make an informed decision. There isn't much to disuss or even speculate on at this stage and that's probably why the thread has largely veered off into one of the usual three man arguments.

I find your lack of faith disturbing! Polls can change the world! David Pleasance NEEDS us to rubber stamp his 'mission statement'!

What would he do without our seal of approval in poll form? Retire to America? I'd miss him on the Amiga circuit but sometimes we need the Wozniak/Jay Miner guy before the Steve Jobs/David Pleasance guy!

Last edited by BigD on 07-Sep-2022 at 10:32 PM.
Last edited by BigD on 07-Sep-2022 at 10:31 PM.

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

@cdimauro

Quote:

A completely new system will be quite different from the Amiga o.s..

Correct.
About as different as early Mac OS X was from Mac System 7.x
It's called progress.

Last edited by agami on 08-Sep-2022 at 01:48 AM.
Last edited by agami on 08-Sep-2022 at 01:41 AM.
Last edited by agami on 08-Sep-2022 at 01:40 AM.

_________________
All the way, with 68k

Time to repost this thing, a drawing from the beginning of this discussion, back in 1996…

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Quote:

agami wrote: Here's my proposed organisation: 1. It is divided into at least three separate bodies and participation in each garners a different monthly/annual fee, - Public relations - Raising awareness in the broader computing market - Software foundations - Working on development of new APIs, SDK, development knowledgebase, for AxRuntime and AROS - Hardware foundations - Working on prototypes and bringing up hardware such as add-ons for existing Amiga and Amiga-likes, and hobby boards using 68x (extended 68k) 2. It would organise XPRIZE style initiatives and hackathons to spike developments in SW or HW 3. It would work with education institutions to help students hack solutions with HW and SW that improves their school 4. It would work with NGOs to help solve problems in developing countries 5. It would look to form alliances with other technology companies and startups that are interested in solving the same problems WOCO - World Open Computing Organisation How's that for keeping it on topic? - Ed.

MAXIMUM ALERT

MAXIMUM ALERT

OUR PRECIOUS FRIEND AGAMI HAS BEEN KIDNAPPED AND/OR HACKED BY, POSSIBLY:

- AMIGABLITTER
- DAVID UNPLEASANT
- KIMMOK
- TREVOR DICK IN SON

LET'S JOIN THE FORCES...
...TO FREE HIM FROM HIS CAPTORS.



(mega)

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

@cdimauro

Quote:

Are you using a FreeSync or GSync monitor? This makes a HUGE difference.

Many Amiga games are timed using PAL 50 Hz, hence it wouldn't fit with NTSC based 60 Hz timings. The Amiga gaming scene is mostly European.

50 hz is within the FreeSync/GSync ranges. I agree with FreeSync or GSync monitor makes a significant experience difference.

_________________
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: cdimauro wrote: The context, kolla, you've to look a the context. Matt: The whole MiSTer base board only cost $140 at one time and that not only included the FPGA but also an ARM SoC, 1GiB of memory, etc. Yeah, so why do you have your panties in a twist over “only” 128MB SDRAM.

Simply because what I've found was quite different from the description, in price and bundled memory, and I've highlighted both.
Quote:

Maybe you’re just ignorant about systems you haven’t tinkered with first hand?

No, it's just you that have serious problems understanding / keeping track of discussions and the precise contexts, since USING a system on THIS specific context was not even taken into account...

This is not the first time that happens. Was Mother Nature bad with you as well?


@agami

Quote:

agami wrote: @cdimauro Quote: A completely new system will be quite different from the Amiga o.s.. Correct. About as different as early Mac OS X was from Mac System 7.x It's called progress.

Which should have been happened already 20 years ago, for such big changes.

The post-Amiga community seems to be viscerally bounded to the original system and all its quirks that a completely new system, albeit having similarities, wouldn't look attractive.
Quote:


https://images02.military.com/sites/default/files/styles/full/public/2019-08/rambolastblood1050.jpg?itok=uPalbUT2

Time is passing...


@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Are you using a FreeSync or GSync monitor? This makes a HUGE difference. Many Amiga games are timed using PAL 50 Hz, hence it wouldn't fit with NTSC based 60 Hz timings. The Amiga gaming scene is mostly European.

Indeed. But this is where FreeSync and GSync comes to help, fortunately...

@cdimauro

Well, my MiSTer has only 32MB of SDRAM, since I barely use it for anything else than the Minimig core, the 128MB would be rather pointless.

Why is this do you think?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: @cdimauro Well, my MiSTer has only 32MB of SDRAM, since I barely use it for anything else than the Minimig core, the 128MB would be rather pointless. Why is this do you think?

What's not clear to you that I've only pointed-out the fact that price and memory size that I've found aren't the ones that Matt reported?

It was just that: no thinking outside of that simple analysis / comparison.

while True:
print("It's just a matter of verifying the reported info")

@cdimauro

You’re REALLY thick in your skull sometimes…

The DE-10 nano comes with 1GB of onboard DDR RAM.

SDRAM is ADDED (a smal board that plugs into GPIO pins), because a lot of cores/systems cannot use DDR. In Minimig context, SDRAM is currently only needed for chipram. Which is why I never bothered to upgrade from 32MB.

But of course you know all this, from your in-depth research :rolleyes:

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@BSzili

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"!

Last edited by BigD on 08-Sep-2022 at 07:52 PM.

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

@BigD

Silence,
scum.

Go throw yourself on your knees
in front of a couple pieces of wood taped together.

YOUR TORCHLIGHT IN THE DARKNESS,
MEGA_RJ_MICAL

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

@kolla

Quote:

kolla wrote: @cdimauro You’re REALLY thick in your skull sometimes…

Let's see... below.
Quote:

The DE-10 nano comes with 1GB of onboard DDR RAM. SDRAM is ADDED (a smal board that plugs into GPIO pins), because a lot of cores/systems cannot use DDR. In Minimig context, SDRAM is currently only needed for chipram. Which is why I never bothered to upgrade from 32MB.

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.
Quote:

But of course you know all this, from your in-depth research :rolleyes:

Care to quote where I've said anything like that, dear mystifier?

Because I NEVER said it. I've just said that I've read the specs. Full stop.

So, either you have memory problems or functional illiteracy or you're deliberately putting words on my mouth that I've never written.

But whatever is the case, it's YOUR problem, liar.

Regarding this:
Quote:

SDRAM is ADDED (a smal board that plugs into GPIO pins), because a lot of cores/systems cannot use DDR.

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...

@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

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC