(a) you reverse engineer the application writing or reading the file. Even without fully understanding the application it can give you valuable information about the format (e.g. "The application calls fwrite in a for loop ten times, maybe those are related to the ten elements that I see on the screen").
(b) you reverse engineer only the file. For example, you change one value in the application and compare the resulting output file. Or the opposite way: you change one value in the file and see what happens in the application when you load it.
I wonder how much faster the ARM2 would have been compared to the 68k in a first-generation Amiga. The Amiga's chip memory only delivered 7 MBytes/s, shared between the CPU and the chipset! With its 32-bit instruction words, the ARM2 would have been very far from its theoretical performance.
ARM2: from 6 to 10 million instructions per second, depending on instruction mix
68000: 1.4 MIPS typical.
(For comparison: Intel 8086 at the same speed, something like 300 Whetstones, 0.5 MIPS. So either of them stomped all over a comparable x86 machine from that time.)
So, very roughly, ARM2 was between 2-3x faster in typical use.
Note:
. Neither CPU could do FP in hardware.
. Neither had cache memory.
. The Amiga had a lot of complex hardware acceleration for graphics; the original ARM2 machines from Acorn (Archimedes A2305, A310, A400) had essentially none.
So, Amiga games could do things that on the Arc required raw CPU, typically done careful hand-coded assembler.
Yes, but that's my point: the ARM2 cannot get faster than 1.25 MIPS in an Amiga because of the memory bandwidth (assuming that the CPU uses 5 MBytes/s of the available 7 MBytes/s that it has to share with the graphics chipset).
That is defently the limitation that you need to improve over time. And eventually you likely split the graphcis memory off from the main memory.
To improve performance you need to start to add cache in or around your CPU/MMU and you need an increasingly clever memory chip to arbitrate memory access.
But you are right, you always going to run into limitations. As RAM is the most expensive part of the BOM, literally anything you can do to get maximum utilily of out of the memory bandwith is where you need to spend design time.
Like ARM did a 16 bit encoding for your 32 bit RISC would have been a great design feature to further reduce the how intensive it is to keep the CPU active. Of course nobody had thought of that combination, that was an early 90s thing.
RAM is just so expensive back then, you build your machine around sharing it as well as you can and living with the downsides.
There was never any ARM-based Amiga from Commodore or any Commodore partner.
Any CPU performance is 100% theoretical because there was no such hardware.
The 68000 performance numbers I cited are from contemporary benchmarks and they _favour_ the 68K. The real chip in real Amigas ran slower.
The Acorn Archimedes used the ARM2; the ARM was developed for the Archimedes range. Its display, sound, memory controller, etc. are all pretty much unaccelerated.
Now there are Arm-based Amigas but they run the Amiberry emulator on top of Linux.
Whole idea behind ARM was running at full speed of ram. Amiga had very little Ram BW to spare for CPU so ARM2 would be throttled by narrow slow ram bus in the Amiga.
Well, yes, but that is only half the story, so on its own, it does not add up.
The whole idea of ARM2 (that specific version, not ARM1, not ARM3) was that clever use of the RAM bus meant it could run at full DRAM speed.
But the other side of the coin comparing with the Amiga is that the whole idea of the Amiga was that ~5 years earlier, it was possible to do amazing unprecedented general stuff for gaming purposes in sound and video chipsets that no other computer at the time could do...
Leaving the CPU almost irrelevant. Which is in part why The Next Amiga, the Hombre, simply discarded the 68000 altogether and switched to PA-RISC.
Which infuriated the fans even back then because they wanted their backwards compatibility.
The core concept of the Amiga and Hombre is "in 1982, what amazing non-dedicated sound and video can we do in hardware for a mass market price"?
By the time it was a product, this was contaminated with "it's also a general-purpose computer" and "look at us, we have multitasking" and "look, it's a 680x0 machine, but with multimedia!" and "look, it can emulate a Mac!" and "look, it can run Unix!"
Different selling points selling in different directions.
Given the raw computer power of the Archimedes, it didn't need any fancy chipsets. They became irrelevant. Sure, yes, the Amiga could do stereo digital sound and multiple bit plane colour 2D graphics and still have enough power left over from a 7-and-a-bit-MHz 68K to run game logic.
The Archimedes looked at that, and went "how about we just do all that in software?" And bundled a solid shaded 3D demo for free. Never mind the bouncing ball, never mind the Juggler, this you could play.
The Mac was "in 1984, how much Lisa can we keep for how little money?"
The ST was "in 1985, how cheap can we make something that looks and works like a Mac but can do colour and sound, so it can play games?"
The Archimedes was "in 1986, can we do a 32-bit RISC machine so cheap and simple we can compete in the same market with Commodore, Atari and the PC compatibles?"
To this day my pet peeve is that Commodore didn't ship Amigas with a tiny amount of scratch RAM independent of the shared bus. Would have been so useful.
A large amount of Fast Ram would have been even more useful, but if you are cost optimizing the BOM, just a tiny sliver of it (it being Fast RAM) would have been effectively a "manual cache" managed by the developer and would have been incredibly useful for anything computation intense, like flight simulators, spreadsheets, anything not involving just blitting graphics really.
And it wouldnt even be that hard, just two 2kx8 SRAMs (like the ones in every NES/Famicon) and CS line going from the chipset to map it somewhere high outside the range of the chipset was very logical, easily doable in 1987 and most importantly cheap. Those 6116 srams were below $2 retail in 1987 (Byte magazine retail prices), so $4 for big performance boost.
Hell, smart Commodore would design A500 with second trapdoor near the CPU. Ship unpopulated but offer official Commodore "turbo ram" expansion carts:
- $25 4KB version. $8 BOM, 2x $1.95 6116
- $40 8KB. $12 BOM, 2x $3.5 6264
- $100 64KB. $28 BOM, 2x $12 62256
- Extreme $400 256KB. $120 BOM, 8x $12 62256. Would stick out due to big PCB so make it an attractive piece of plastic with cool logo and "EXTREME" design.
Map it at D80000 (potential 256KB of space for activities) and let software vendors auto detect fitted option by running quick memory test. Easy speed boost and easy extra money for Commodore.
You are not saying "there was no uncontended RAM in the Amiga", which is what I understood you to mean. You are saying "the Amiga did have uncontended RAM but it did not ship with any as stock."
Is that right?
If so, yes, true, but the key things here IMHO are:
1. The Amiga was designed and built as a games console, one which happened to be able to do other things. It was primarily marketed and sold as a games machine.
And the comments are from slightly baffled readers asking if this is any good for running their old Amiga games, or how this makes gaming any easier.
(It is not and it does not, but that is what people perceive the Amiga as being for in the 21st century.)
2. In the real 1980s market, the Amiga's glory was to a large extent stolen by the Atari ST. The ST was a much more limited machine but it was vastly better than any 8-bit machine, and an entry-level ST was more usable than an entry-level Amiga.
ST games were pretty good for the mid-1980s when a lot of people still had ZX Spectrum or Commodore 64 level kit.
Many games companies targeted the lower-end machine and ported to the higher-end one.
The Amiga was competing with the cheaper, simpler ST in the market, and keeping the costs down became imperative. That's why Commodore didn't add more hardware or more RAM to the base-level Amiga. In fact for the Amiga 600 took the spec of the A500 and cut it down.
I am not arguing that some Fast RAM as stock wouldn't have been good. It would. But probably irrelevant to most gamers, and probably would have hurt the machine's sales.
I am convinced as little as 32 bytes of uncontested (fast-ram) would have made wonders. It would almost have been like doubling the number of data registers on the 68000. Either an extra chip with address decoder and this scratch memory could have been placed on the 68000 memory bus... this would 100% have worked.
Or much better, the Agnus chip could have had this scratchpad added into it. It should have been feasible - it had about 20k transistors IIRC and a few hundred more should have been doable. I am fairly certain this would have worked but I'm not completely sure, it depends on if that addition would have complicated multiplexing and/or internal bandwidth demands, but the 68000 ran at 7MHz at the time, so it doesn't seem too difficult to me, armchair designer.
Thanks for the article! It's always nice to see AROS and Amiga get some love. :)
Achschully AROS m68k can be helpful for playing your old Amiga games in an otherwise open source way. You don't have to buy or pirate the official Kickstar ROM images if you use an AROS m68k ROM instead. But on the other hand, realistically you would probably pirate that old Amiga game to begin with, it's not like you have your old floppies lying around and if you did, you'd need a floppy drive to read them anyways...
This view is at odds with reality of 1 in 5 Amiga games already not working at all without third party trapdoor ram expansion. And those were the good games everyone wanted to play. Games would support or even require fast ram if Commodore made adding it easy and cheap like they did with chip ram trapdoor. That means either small SRAM scratchpad or build in fast ram DRAM controller so you are only adding ram on simple PCB instead of being forced into $500 a590 kitchen sink.
On the other hand braindead lack of planning making early Amigas 1MB limited resulted in less than ~10 games ever using more than 1MB. Rare exceptions are for example Wing Commander loading some additional animations with >1MB available. There were also games that hardcoded check for exactly _1MB_ and refused to run with more :)
Yes Amiga was a gaming machine first. Chipset independent scratch SRAM would do wonders for games _IF_ it was introduced together with first A500 like trapdoor ram was.
Running code from 7MHz fast ram bumps amiga from 0,57 to 0,75 Mips, 30% speed bump.
Why bother? The 14MHz mod alone gives a diminutive but _free_ bump from 0,57 to 0,62 Mips, but marrying together 14MHz and running from SRAM fast ram bumps us into 1,51 Mips https://www.youtube.com/watch?v=2nlG8dGvq-U thats 20% faster than 5 years older Amiga 1200.
Even 8KB of dedicated fast ram would be ideal for small fast loops, and there is plenty of those in games.
Lets not mention Commodore being so incompetent they couldnt find/wouldnt pay for an ASIC designer to update Paula PLL in order to support HD floppies :| Plenty of low hanging fruits nobody at Commodore bothered or knew how to make happen.
That accelerator is amazing, thanks for sharing. It upgrades the A500, released in 1989* to be faster than the A1200, released in 1992. The design is "time period correct" too, it doesn't do anything that couldn't have been done back then.
But... how is that possible? The Amiga 1200 has a 32 bit wide bus and is also 14MHz?! Commodore did the stupid thing again and didn't put any fast-RAM on the machine.
* The Amiga 500 is basically a cost optimized Amiga 1000, released in 1985.
Well - I used Archimedes computers with ARM2 and owned an Amiga 500+ and honestly, I couldn't tell you the Arcie was faster. It certainly didn't have the custom chips, so it is probably not a fair comparison.
There are several scientific publications on this. But I don't think the latest models are available as convenient plugins for IDA or Ghidra. Guessing variable and function names are considered as relatively easy nowadays. Types and structures are the challenges now.
I think they mean MicroEmacs. Despite its name, it was not Emacs, but it had Emacs-like keyboard shortcuts, multiple buffers, and macros, which was quite neat for a free 1986 application on a home computer.
Sources generally seen as authoritative (Duden, Wahrig etc.) estimate that the German everyday language has between 250,000 and 500,000 words (depending how you count), without counting technical terms.
I have not found any study published after 2020 (the year when the French minister made the statement) that advises against ibuprofen for COVID-19. But I'm not a doctor, so I'd be interested to know your source.
Fascinating and annoying problem, indeed. In Java, the correct way to iterate over the characters (Unicode scalar values) of a string is to use the IntStream provided by String::codePoints (since Java 8), but I bet 99.9999% of the existing code uses 16-bit chars.
This does not fix the problem. The emoji consists of multiple Unicode characters (in turn represented 1:1 by the integer "code point" values). There is much more to it than the problem of surrogate pairs.
(a) you reverse engineer the application writing or reading the file. Even without fully understanding the application it can give you valuable information about the format (e.g. "The application calls fwrite in a for loop ten times, maybe those are related to the ten elements that I see on the screen").
(b) you reverse engineer only the file. For example, you change one value in the application and compare the resulting output file. Or the opposite way: you change one value in the file and see what happens in the application when you load it.
reply