Daedalus2097

The reset pin at the CPU has been checked: it's not asserted. And from experience, if the power on reset delay isn't there, the machine will still boot just fine most of the time.

Yeah, it's worth replacing the Gary socket as all sorts of weird things can go on when Gary's not quite right. And there's a fair chance it'll stop working further down the line if it's bad. Likewise for the Agnus socket, though that's a little more fiddly to replace.

CIA-B uses INT6, so it's possible there's an issue with the traces on that line somewhere. INT6 is pin 21 of CIA-B, and it goes to Paula pin 18 as well as the side expansion port. It should also have a 10k pull-up resistor to 5V, so check continuity between those pins and resistance to ground and 5V, see if anything is amiss. The Paula socket sometimes gets corroded when there's been a leaky battery - the Gary socket is usually far worse, but it might be that the Paula socket needs to be changed.

Yes, that's normal, though as I said before, that voltage is a little high for comfort. The clock and data signals are both held high on the motherboard. It's possible I guess, but not something I've ever seen. I've seen lots of pre-KS3 machines stall at a grey/white screen because of faulty interrupts though, and the keyboard behaviour (other than the power LED) is consistent with an interrupt failure. Yep, but /Reset isn't being asserted so it's unlikely to be the reset circuit.

Indeed, it's suspiciously similar alright. So much so that one might wonder why they went to all that trouble and expense to design their own, when they could buy a tablet with the exact same spec for $85 a piece

So what's special about this tablet that puts it head and shoulders above other generic Android tablets then? Why go to the massive cost and effort of designing your own tablet? What's the regulatory status of your tablet? How do you plan to recoup those massive NRE costs? What else do you manufacture at "your" factory? Or by "designed", do you mean specced and using an off-the-shelf base design?

The schematics I linked to before will show you which pins are for power to Paula. Another option to look at is getting a DiagROM, which is a replacement ROM that you fit in the Kickstart socket for diagnostics. It's excellent because it can work even when most of the computer is dead. It includes interrupt checking functions. The serial driver chips can be replaced by functionally equivalent chips if needed, but if it's faulty and causing the issue, simply removing the chip will allow the machine to work (without serial of course). You don't need to source a chip until you know it's faulty. The specifications for the 5V rail include a 5% tolerance, which means 4.75V to 5.25V. Now, it's always a good idea to not completely trust the readings from a multimeter unless it's been calibrated, but chances are the voltage on the 5V rail is a little high, which may or may not be causing problems.

Hmmm, to be honest, 5.24V is too high. As a supply voltage, it's borderline within spec but realistically it should be a bit lower, and most signals will be a bit lower than the supply voltage. Can you check the exact 5V level at the floppy power connector? U38 has a +12V and -12V supply rather than a 5V supply. We've already established that the keyboard is working, and it's the CPU that's not servicing the keyboard's requests. With both /Reset and /Halt signals high and a grey or white screen, I'm next pointed towards an interrupts failure. Without interrupts, the machine will boot to a grey or white screen and then hang just before showing the insert floppy screen. Swapping the CIA chips around as suggested above is worth doing to see if the problem changes, or it could also be a problem with Paula or the connections to Paula. Check all the power pins to Paula, and the Paula socket for any tarnished or damaged contacts.

Okay, there are a couple of issues here. The Amiga pinout is quite wrong for a start. Pin 6 is button 1, pin 9 is button 2 and pin 7 is +5V. The 7800 has a kinda funky controller pinout that's designed to be backwards compatible with the 2600 (both buttons act as button 1 in that case), but that will cause problems with Amiga use unless the Amiga software provides explicit support for the controller. It should be possible to construct an adaptor that allows 2-button use on the Amiga without modifying the controller itself. From the top of my head, the adaptor would wire 7800 controller pin 6 to Amiga pin 8 (ground), controller pin 9 to Amiga pin 6 and controller pin 5 to Amiga pin 9. It might also need controller pin 8 to Amiga pin 7 (+5V). Note that I haven't tried this...

Cool, well a multimeter can tell you what level these signals are sitting at, it just can't show you any rapid changes that occur. It's possible as well that you have a short from what you're saying, and anything like that on the address or data buses will likely prevent the machine from booting. Check the CIAs (and all the chips) for correct fitting and alignment too, in case any previous work has resulted in one of them being positioned incorrectly. For the reset and halt lines, these can be checked at the CPU, pins 18 and 17 respectively. Both should be high (close to 5V) during normal operation. If either one is low (close to 0V), it will prevent the machine from starting. You can find some schematics for the Rev. 6 A500 board here: https://www.amigawiki.org/doku.php?id=en:service:schematics Note that there are significant differences between the Rev. 5 and Rev. 6, particularly when it comes to ROM and RAM, but the key signals at the CPU and between the custom chips will generally be the same so it can be used to check pin numbers for example.

Okay, the caps lock thing is an indication that the CPU isn't running. Either it has detected a serious fault and halted, something is holding the reset line low, or there's something more significant going on with the board. Without the CPU running the Kickstart code, the floppy drive won't do its ticking thing either, so don't worry about that for now - it could be fine. I'm not sure what diagnostic gear you have there, but the first thing to look at is the /Reset line to see if it's being held low. It should be held low for maybe 1 second after power on, then go high. If that's the case, the next thing to look at is the /Halt line. That's similar, it should go high right after startup and stay there, but if it's low it means some fundamental issue occurred, like the CPU can't read the ROM properly or something. U38 is one of the serial driver chips IIRC. If that's damaged, it could be causing issues for one of the CIAs too, which in turn prevent the CPU from running. I don't think they get particularly hot, especially when idle, so that's a good place to start. You can remove it completely to eliminate it; the machine doesn't need it present to work.

Let's clear some stuff up here: If a MOD player is basing its timing on the screen refresh rate, then it's a pretty bad MOD player. Timing should be independent of the screen refresh rate, and the MOD player Games where the graphics are synchronised to the refresh rate and all actions are calculated on the refresh rate will of course feel very different to play. Not many games compensate for the difference, but some do. NTSC screenmodes have a different pixel aspect ration than PAL screenmodes, so artwork can appear stretched or squashed when played on one but intended for the other. Where personal preference comes into it is whether you prefer to play a game as the developers intended or not. But more often than not the developers will have developed for one or the other, and designed the game movements, speeds, artwork and so on for that speed.

Yeah, RGB doesn't care about colour encoding, which is a key compatibility issue when using composite or S-Video connections. But the refresh rate will still be an issue, since PAL over RGB is 50Hz and NTSC is 60Hz. Almost all modern TVs will handle both however, so once your SCART adaptor supports 50Hz (and it sounds like it does if you've got UK Speccies working through it). The Amiga has native RGB output (intended for connecting to a monitor), though it's a non-standard connector. RGB output is the best quality you can get from an Amiga without putting in additional hardware. You need an Amiga RGB-SCART cable. There are a few sources for these, some better quality than others, but I believe Retro Computer Shack cables are known good ones and are available on eBay. Or, if you wanted to go all out on the cable, RetroReady have high end ones with genuine 23-pin connectors. Both are shipping from the UK, so shipping costs might be high to the US. Adding a hard drive is a little more complex for the Amiga 500 than it is for the A600 and A1200, which have built-in IDE ports. The simplest way of playing games that aren't on floppy disk is to replace the floppy drive with a Gotek or similar floppy emulator. You can put the floppy disk images on a USB flash drive and feed them to the machine that way. Adding a hard drive is possible though, and realistically would also need a RAM upgrade as running a hard drive and OS setup needs a bit more RAM than booting from floppy. There are various options available, the ACA500+ from Individual Computers is an excellent Swiss-Army device that adds CF cards as hard drives, as well as including updated OS, ROMs, RAM, faster CPU and other features. It fits externally to the side expansion port on the Amiga 500. If you'd prefer an internal solution, there are various accelerators available. The TF536 for example gives you a massive boost in CPU power and RAM, and includes a laptop-style IDE port for hard drives or CF/SD cards. You'd likely also need to upgrade the ROM to 3.1 or newer. There are also simpler devices, such as the M508 which just includes extra RAM and IDE (so no CPU upgrade), though it appears to be out of stock everywhere...

Well, no offence meant, but at this stage the "actual" Commodore is no different to all the other old names you refer to, all of which were also "actual" Commodore at one point or another. I genuinely wish you all the best with it, and look forward to being pleasantly surprised by something other than rebranded generic hardware. I guess my point about posting here is that if you were trying to raise awareness of an Amiga game jam, a far better place to start might be one of the many active Amiga forums. It might be worth noting that we've just seen the completion of a big Amiga game jam that has run for 6 months, so launching another one so soon afterwards that has a more corporate aim might not generate as high a level of interest or standard of entry as you might hope for. It's also slightly odd that the focus is on the Amiga, given that the Amiga branding is separate from Commodore, and is also chaotic and has seen many doomed attempts by people to register the name and become the "actual" Amiga. Cloanto being just the latest claimant of the "actual" Amiga crown, and also Italian BTW - have you discussed this effort with them?

The IP was always owned by someone - just who that entity is or was at any point in time can be confusing. And, of course, neglected trademarks can easily be registered by anyone in some regions. So a Commodore brand can easily exist and be legitimate, but also have nothing to do with actual, original Commodore (as we've also seen with the various Amiga branding shenanigans over the years). After all we have had all the Commodore branding being bandied about with things like rebadged generic mobile phones and tablets, Commodore USA PCs and other tenuous efforts. It'll be interesting to see if this incarnation / licencee is any different. If the entire marketing effort so far is just a couple of posts by a randomer on a by-the-way board on an *Atari* forum, then I wouldn't hold much hope.

There are many different variants of the 1084 family of monitors, and they vary in the sync requirement. Some require H-sync and V-sync, others require composite sync. The two systems aren't compatible - if your monitor requires composite sync, using just H-sync or V-sync will result in a rolling or flickering image, likewise if the monitor requires H-sync and V-sync and you only provide composite sync. Ideally a cable would connect all three sync signals so it would work with any variant, but sadly that's not the case. Old ones crop up from time to time in Amiga groups and on eBay, and a few of the Amiga resellers sell cables, but it would be good to figure out what exactly your monitor needs. If you're checking out your cable, pin 7 is composite sync, pins 8 and 9 are the H- and V-syncs. According to the 1084S-D1 service manual, composite sync only is needed for RGB operation, so if your cable connects the other two instead, it won't work.

Also, as pointed out in the list, the excellent WHDLoad also adds multibutton support to many games which otherwise were limited to single-button support, including remapping jump to an extra button in some platformers that otherwise use up on the stick. Since the A500 Mini uses WHDLoad to access the installed games, you should be able to take advantage of multi-button support in most games where it makes sense.

Very nice

Yeah, I saw that posted elsewhere, looks very interesting!

There are many different "distros" out there like AIAB, ClassicWB, BetterWB, AfA and so on. Some of them really are excellent, but they can also be problematic if you don't really know your way around the OS because they typically use a house of cards of patches. If you then go to change something or install something and it doesn't work as it should, it can be very tricky to tease out what exactly is going on. The screenshots look good With the power of an RTG true colour screenmode and a fact CPU / WinUAE, MagicMenu supports textured menus and even semitransparent menus - obviously a matter of personal preference, but on my real A1200 with a graphics card I have a subtle texture, and on WinUAE I use the semitransparent effect. Also a couple of other personal preferences of mine: I prefer to have no border on the Workbench window (as AIAB is set up), and to do that you select the Backdrop option from the Workbench menu. If you want to keep the setting, use the Window->Snapshot->Window menu item to save it. The other thing that I do before anything else is enable the ClickTo Front commodity. This lets you double-click anywhere in a window to bring it to the front, and I'm lost without it. It's not a single click like Windows or Linux, so you can still keep overlapped windows when you want. Best of both worlds IMHO. (You enable commodities like that by dragging them from Tools->Commodities into the WBStartup directory. Any program in there gets run as soon as Workbench starts.) Yes, there are plenty of options for Basic on AmigaOS. Some are interpreted, but most have at least the option of a compiler. Whatever you do though, avoid the official AmigaBASIC that shipped with early versions of the OS. It's Microsoft BASIC so is competent from a capabilities and compatibility perspective, but it's coded terribly and will give you massive headaches on anything newer than a stock A500 (or emulated equivalent). There are a couple of stand out languages that were the big hitters for Basic back in the day: HiSoft BASIC, AMOS and Blitz Basic: HiSoft has a primarily system-friendly focus and is a solid, professional-feeling package but is limited in capability and so wasn't as popular as the other two, and has largely been forgotten in more recent times. Very little was released that I know of that was developed with HiSoft BASIC. The HiSoft BASIC environment is quite decent from memory, it's all system-compliant and uses the standard OS interface, which should be nice on a graphics card screen, though I haven't ever tried it on one. AMOS is the Amiga version of STOS for the Atari ST, and is primarily aimed at games creation. It has some nice support for things like animation and virtual sprites / BOBs, but is poor for system-friendly software and has little-to-no support for newer machines with AGA chipsets. There's talk of some updates being worked on over the past while, but nothing major has come of it as far as I'm aware. Development is done in its own semi-system-friendly environment, and by default is interpreted, but a compiler option is available (AMOS Pro). There were many PD games made with AMOS, to the point where the games often had an AMOS "feel" to them, and that wasn't always looked upon favourably. Still, it's probably the easiest language to get stuck into for games. One of the big releases that used AMOS was Valhalla, which will give you an idea of the capability, and Super Foul Egg was a very popular AMOS PD game. Blitz BASIC was created to be the all-rounder, and so supports system-friendly coding for applications, and hardware-banging code for games. The command libraries have lots of commands for both options, and many extensions are available, but you can also access the OS directly as you would in C, or include in-line assembly language for extreme performance. It supports perhaps the most modern syntax of the three, and includes many constructs similar to C as well as a semi-object-orientated approach for many tasks, so is probably the closest you'll find to FreeBASIC or VB. Compilation is mandatory; there's no interpreter option, but you compile and run directly from the IDE without any faffing with command lines or anything like that. The default editor isn't great, but it was intended for A500-class machines. It shipped with a replacement editor on the Extras floppy that was much better, as well as better command libraries and debugger, and various components were updated after that. 2.1 is the last commercial release, but there's an Ultimate Blitz CD image that was created in the last couple of years to include all the latest updates. I can't find a download link right now though... Blitz was open-sourced some time ago, and there's a continuation called AmiBlitz that's in active development, currently at version 3.8. This has a totally revamped editor with some quite nice features like syntax highlighting, code completion and inline help, and has some really good include files for doing OS-friendly stuff, but needs a more powerful Amiga as a result, and benefits from a larger screenmode. This doesn't really affect the executables though - if you write something that only uses A500 features, it should run on an A500 no problem. For examples of what Blitz BASIC can so, have a look at the games Worms (yes, *that* Worms), Super Skidmarks and Foundation. And applications-wise, HD-Rec is an insanely complex and heavyweight DAW package written in Blitz. <shameless plug>I did the Amiga port of Dodgy Rocks in Blitz . Personally, I've been coding Blitz Basic for decades now and will recommend it over the other BASICs. With WinUAE, AmiBlitz 3.8 makes a lot of sense. There's built-in AmigaGuide documentation (press Shift+Help with the cursor on a keyword to open the documentation on the page), and the original Blitz 2 manual, while it wasn't great, is also available in AmigaGuide format from the editor. Documentation-wise, these older languages are never terribly great, but a good source of material is old magazines, which often ran tutorial series on different languages, often accompanied by a demo version on the coverdisk. amr.abime.net is a good source of magazine scans, and for Blitz, a couple of years ago I wrote a series of tutorials for the Amiga Future magazine (which still exists!) <another shameless plug>. They've made them freely accessible along with lots of other workshops here. Oh, and finally there's also AQB, which is a new project that started out as similar in concept to Microsoft's QuickBasic and has similar constructs and syntax. It's early days yet, but might be worth playing with if you like that sort of environment or want to be involved in the development of the language itself.

Well, the spreadsheet programs can usually import and export to a certain extent - you'll have no problem getting raw data in and out, though you might have to resort to CSV format files. It's things like fancy formatting, graphs and the likes that won't transfer well or at all. Cool - it's my pixel art package of choice. It does most of what Deluxe Paint can do, but the added support for many image formats and the excellent colour reduction methods put it ahead of DPaint for me. Oh, you haven't played Settlers? It's one of my favourites from the Amiga years. It's excellent! Gorgeous detail in a low-res screen. Download the manual though because identifying icons and building might be tricky without it, and the game doesn't give you tooltips. Settlers 2 for PC/Mac is really good too, and has a special 10-year anniversary edition that shows up for next to nothing sometimes. As a game genre, it was the start of something new - like you say, a cross between Sim City and Warcraft. You don't control the people directly, whereas in Foundation you do. Indeed, Settlers was actually sold under the name Serf City in the US Incidentally, a couple of my Amiga friends were saying they didn't play it much because they couldn't understand it (no manual with pirated versions ), so we were talking about doing a tutorial stream at some point... I might post details here if it happens. Nice ?

Oh, just remembered that I didn't mention any spreadsheet programs Like the main word processors, spreadsheets on the Amiga still work quite well on their own, but their ability to share data with modern applications is limited. There were a couple of good ones back in the day: TurboCalc was one that I used from a magazine cover CD, and it was pretty decent. FinalCalc was its main competitor so should be of similar quality. Both should be easy enough to find. There is a "modern", independent spreadsheet package that was developed recently. I've fired it up under OS4 and it looks good, but I haven't used it in anger. It's called Ignition and might be worth checking out. Since you're interested in graphics, I can recommend a couple of packages. You probably already know PersonalPaint, which is similar to DPaint but offers some nice additional features like working well with graphics cards (albeit still up to 256 colours), and loading and saving almost any image format. Version 7.3 is commercial, but the last Cloanto version (7.1) is still free to download (scroll to the bottom). TVPaint 3.59 was made free for the Amiga when the developers left for other markets, but I can't find the download handy now. I'm sure it can easily be found. That supports 24-bit drawing on a graphics card with some layer support. Photogenics was an excellent, commercial 24-bit paint package for use on a graphics card, but was abandoned some time ago - I'm sure it can be found... Art Effect is still sold, and is another very capable 24-bit package that makes good use of a graphics card. 3D graphics are worth a look too with what is essentially an insanely fast Amiga. Lightwave is the obvious go-to, and was a super high-end product back in the day. The interface is hard-coded for a native resolution though, so while I think it can use a graphics card screen, it doesn't take full advantage. Cinema 4D on the other hand, makes full use of a graphics card screen and has a surprisingly modern feel to it. It was released on a magazine cover CD when they left the Amiga market in the late '90s - I think the serial number was included in the magazine itself so you might need to hunt, but it's worthwhile because IIRC the magazine also ran a series of tutorials for it. Edit again: Finally, some recommendations for "modern" Amiga games that really needed a powerful machine to run, so not many people played them back in the day. You should be able to find them, and if you can find full CD images (including audio tracks) as opposed to just the data track, that will improve things as the soundtracks will be missing otherwise. Payback is an excellent GTA-style game with a great soundtrack and some very nice touches. Be sure to install the update because it fixes many gameplay issues found on the original CD version. Napalm is a very nice RTS game, steep difficulty curve but well worth checking out. Exodus: The Last War is another nice RTS game, slightly quirky at times but worth a look anyway. Foundation is a sort of Settlers / C&C hybrid that's great but can be frustrating and unforgiving at times. The Director's Cut or Gold edition includes updates and tweaks to the gameplay. OnEscapee is a very nice Flashback-style platform adventure/puzzler. There are some very good PC ports too, though there's not a huge point in running them on the Amiga emulation other than "just because": Doom and Quake obviously, Earth 2140 is excellent, Descent: Freespace is good but needs 3D acceleration, Shogo: MAD and Wipeout 2097 are very good too but require PPC and 3D accleeration.

No worries Like I said, under emulation it will make little difference unless you want to emulate older Zorro-II peripherals... Because the earlier CPUs were limited to 16MB of address space, those Zorro-II 8MB are reserved for hardware add-ons because the CPU can't physically reach addresses above 16MB. If something uses half that space up (e.g. a graphics card), then an 8MB RAM expansion can't work so it would have to be 4MB instead, for example. 32-bit-addressing CPUs like the full 68020 and up don't have that limit, so all Zorro-III stuff can fit in the 2GB of space above that 16MB. The virtual graphics card of WinUAE sits in Zorro-III space, as does the 64MB of fast RAM. The OS situation is a little funky alright, but here's a little run-down of the versions, largely ignoring the politics etc.: Back in the day (mid-'90s), the intention was to follow Apple's path and move to PPC CPUs as the 68K line ended with the 68060. (incidentally, the 68060 was a beast of a chip for its time - I had one back then and still have a couple in my Amigas.) To this end, a roadmap was laid out to upgrade the OS to better match upgraded Amigas, with a goal of eventually porting it to PPC. This PPC version was to be Amiga OS 4.0, so 3.5 and then 3.9 were created as stepping stones. 3.5 introduced the new Workbench, icon system, and a massive rework under the hood for things like large hard drive support, CD-ROM & printer support, basic internet suite, optional PPC support, better datatypes, longer filenames and a new GUI engine. 3.9 improved on this by fixing bugs and adding more user-facing features like customisable menus, dockbar, automatic filetype identification, GUI archive unpacker, new Shell, comprehensive Zip drive support, file search, better image datatype handling, asynchronous Workbench operations and things like CD audio players, MP3 players and even a video player. OS 4.0 is essentially an elaborate PPC port of 3.9, but it has grown since then. A dwindling Amiga userbase, delays with OS 4, and then Apple moving away from PPC meant that OS 4 received a lot less attention than desired, and development slowed to a crawl (though it's still ongoing). Since then, there has been a resurgence in interest in the lower end of Amiga computing (along with the rest of the retro computing world). As a result, there was interest in a new update of the 68K versions of the OS (the "Classic" line). The rights of much of OS 3.9 had since defaulted back to the various creators and developers, so updating that wasn't really a runner. In addition, with the more retro vibe going on, there was less interest in a system like 3.9, which was seen by some, perhaps unfairly, as a bit bloated. So a new update was planned that was intended to fix a few of the glaring issues with 3.1, such as large hard drive support. This update, 3.1.4, used many of the core components of 3.9 however since the developer of those parts also worked on 3.9. So it got the new Workbench, new icons, large hard drive support, better CrossDOS and CD support and a few other upgrades, but was closer in feel and weight to 3.1. The new, colourful icons were optional instead of default as they were with 3.9. Finally, 3.2 took 3.1.4 and re-added some of the key 3.9 features like filetype recognition, the GUI engine, asynchronous Workbench operation and more, including some OS 4 features backported. This is the most up-to-date version of the classic OS, but it still lacks some of the more visual 3.9 features and some people using it have created a sort of hybrid version with some parts of 3.9 brought over into 3.2. Starting with the replacement icon.library is a good option if you're sticking with 3.1. Read the documentation as it's not as straightforward to install on 3.1 as it is on later releases. With the newer icon system from 3.5+, you can simply drag it into SYS:Libs/ and reboot, whereas 3.1 needs it to be loaded during the boot process with a special command. Additionally, 3.1 lacks some of the relevant preferences available in later versions, such as icon colour precision etc. It shouldn't matter much on a graphics card screen however...

Yeah, it wasn't long before I bought a hard drive for my Amiga, and it was a game changer (literally). Not only was the OS an immense pleasure to use, but being able to start a game in a couple of seconds that usually took far longer and a couple of disk swaps was a breath of fresh air. Not having the disk swaps on big games, or long loading times between levels or screens was great too. Applications were greatly enhanced too, being able to swap data between programs was so much quicker and didn't require disk swaps. Regarding PC graphics cards, it depends on what you're doing with it. Some people want to run in 4K at >144Hz, and with many games that can take all the muscle you can throw at it. Personally, my main monitor is 1920x1200@60Hz and I'm not that bothered by slower framerates, so my 970 still serves me well.

Welcome along Emulation is certainly a convenient way of doing things, allowing you to have pretty much any Amiga of your liking. First point though, the RAM setup you have doesn't really matter in emulation terms, but the 8MB is Zorro-II RAM. This is the area of RAM that can be accessed by all CPUs, whereas the Zorro-III RAM area can only be accessed by fully 32-but CPUs. Some Amigas, e.g. any with a 68000 CPU and the A1200 with its 68EC020 CPU, only have a 24-bit address bus which limits them to 16MB of total address space, of which 8MB is typically used for RAM cards on the A1200. On a real A1200, Zorro-III RAM is only available when you also fit a 32-bit CPU, which is how most accelerators offer more than 8MB, and in the emulation it simply means selecting a full 68020 or higher. Performance-wise, on an emulation it won't make a difference, but I prefer to just use Zorro-III RAM for my emulated setups since it's in a single chunk. Regarding customisations, one of the first things to note is that there have been several updates of the OS since 3.1. There were two major updates towards the end of the '90s (3.5 and 3.9), and then two major updates in the past couple of years (3.1.4 and 3.2). All of these options will give you a revised look with updated icon support as well as massive changes under the hood for a nicer Workbench experience. 3.9 is an evolution of 3.5, and is the OS I've been using on my main Amiga for >20 years now. 3.2 is an evolution of 3.1.4, which is a more stripped back update to 3.1 than 3.9, but includes many of the same core components, including the updated Workbench and icon systems. Icon-wise, there were two main extensions to the original icon format and style that people used on 3.1. These were MagicWB and NewIcons. MagicWB made good use of 8-colour screenmodes to get nice looking Workbench screens on the native chipset. NewIcons patched the icon system to allow more colourful icons, and also introduced a forced isometric style not unlike BeOS. 3.5/3.9 introduced the "GlowIcons" format for icon files as well as a new icon artwork style, and there are many collections of GlowIcons that will typically match this style (these will usually be called 3.5 or 3.9 GlowIcons). The icon system also supports the older formats mentioned above. 3.9 example: Amiga OS4 (which is a different beast entirely) also uses the GlowIcon format but a different art style, but some people still use them on their OS 3.x setups. OS4 example: 3.1.4 and 3.2 use the GlowIcons format as well, but introduced a revised version of the 3.5/3.9 look. 3.2 example: If you do intend to stick with 3.1, installing the replacement icon.library 46.4 will give you compatibility with all of the icon styles above so you can still use them. I would suggest deciding on whichever icon style you prefer, then looking for packs specifically in that style. That should narrow your search somewhat. Aminet can indeed be overwhelming, but it's a great resource and sometimes worth spending a bit of time browsing and trying a few things out. Text editors are something that the Amiga has a lot of, and some are better than others. OS 3.9 comes with a decent but basic editor, 3.2 comes with an excellent editor. Personally I use Redit for most things. It's small, fast and lightweight with basic but useful features. At the top end of the scale, you have editors like CygnusEd, which is very sophisticated and has lots of features for developers, but it's commercial. GoldEd is similar, and also very good (and is commercial), but I don't think that can be found for sale (legitimately) - the author's website has disappeared. For visual updates to all versions of the OS, there are a few options, all of which patch the system but are mostly well behaved. MagicMenu gives you customisable drop-down menus. Arq or ReqAttack will give you customisable requesters. VisualPrefs will let you customise the appearance of many aspects of the GUI, like window borders, gadgets, etc. Birdie lets you apply bitmap patterns to the window borders. All of these benefit greatly from a nice graphics card screen. Finally, for games it really depends on how you want to handle it. Most games will run on any Kickstart, but some older games are troublesome with anything above 1.3 (or the AGA chipset, or a fast CPU). Having a separate WinUAE setup for an A500 is probably a safe bet, and also the most compatible. But for running games on upgraded Amigas (including emulated machines), there's a package called WHDLoad that patches games to make them hard drive installable as well as compatible with higher CPUs, newer Kickstarts and chipsets. Many games also include optional patches for trainers, improved controller support and a key for quitting back to the OS. Installing games from scratch with WHDLoad requires the game-specific installer and the original disks (so in many cases, the ADFs, which are typically images of cracked disks, won't work. Fortunately, you can easily find most games pre-installed so you can just unpack to your Amiga's hard drive and run them. Some might need tweaking, but for the most part they should just work. Personally, WHDLoad is the way I play most of the floppy-only games.