Welcome, Guest. Please login or register.

Author Topic: Upgrade Ram to 1 MB Amiga 500?  (Read 17230 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline AmigaHope

  • Newbie
  • *
  • Join Date: Dec 2006
  • Posts: 41
    • Show all replies
Re: Upgrade Ram to 1 MB Amiga 500?
« on: April 18, 2010, 07:06:59 PM »
Quote from: Super TWiT;554259
So ECS apps will run on OCS hardware? Than what was the point for ecs?
OK there's a lot of misinformation in this thread! Here's the rundown:

ECS adds, to my knowledge, six new features:

WITH ONLY FAT AGNUS UPGRADE:

1. Supports larger Chip Memory (addressable by custom chipset). Old Agnus/Fat Agnus chips allowed only 512k to be addressable. ECS Fat Agnus supports 1MB in one version (most common -- shipped in late-model A500s), 2MB in the more expensive variation (this variation shipped stock in the A500+, A600, and A3000). This lets you have more audio/video data in memory without having to swap it out between fast RAM. It lets you have more and larger screens open, more windows, etc.

There are actually a small-but-significant number of games that supported improved audio quality and subtly improved graphics if you had at least 1MB of Chip (plus at least a small amount of other RAM). The improvements were small, but I've encountered some nonetheless that did do this.

Also, there's a VERY small number games (probably can count on one hand) that *require* more Chip RAM but don't require AGA. Like maybe 2-3. The only one I can remember right now is Dungeon Master II. These games were actually usually labeled as "AGA-only" by the publishers because they were worried that people with OCS systems (and people with ECS Agnus but still had only 512M Chip RAM) would be confused and not understand why it didn't work.

2. ECS Fat Agnus has a new blitter that supports blitting twice as much data in a single operation. To my knowledge, there is NO software that actually requires this feature. Also, I don't think there are any hardware-banging games that even take advantage of this feature. Software that uses OS function calls to move data around may get a small speedup from this.

3. Software programmable vertical sync. In OCS, your vertical refresh is permanently fixed at 50Hz or 60Hz, depending on whether or not you had a PAL or NTSC system. No games use this. It does, however, have the important benefit of letting you change your vertical refresh between 50Hz and 60Hz to support PAL/NTSC versions of games on opposite systems. If you have an NTSC system this lets you play PAL games without cutting off the bottom of the screen, and without vblank-timed effects (often music) from running too fast. On PAL systems it lets you run NTSC games without effects running too slow, and without "squashing" the screen onto the top of the display.

In addition, the programmable vertical refresh lets you create interesting screenmodes when you combine it with the ECS Denise (see below).

WITH BOTH ECS AGNUS *AND* ECS DENISE (shipped stock in A500+, A600, A3000):

4. Software programmable horizontal sync. OCS Denise has a fixed horizontal sync of approximately 15Khz. With ECS Denise you had full control of the sync timings, you can create arbitrary screenmodes with varying refresh rates and geometries. AmigaOS ships with a number of these -- my favorite being Euro72, which lets you have an interlaced display at 72Hz which helps reduce visible flicker.

5. High-frequency audio. Paula's maximum sample rates are determined by the rate of DMA fetches, which is determined based on the video horizontal sync rate. On the fixed OCS 15Khz sync, this allowed a maximum audio sample rate of 28Khz. With ECS Denise you can let Paula push over 56Khz audio rate if you run in a screenmode with 31Khz video  horizontal sync. This is a side-effect of how Paula works, and Paula itself has no differences between OCS and ECS. For reference, audio CDs run at 44.1Khz and DAT runs at 48Khz. Coupled with the 14-bit channel-combining hack, you can get what is *almost* CD-quality audio (2 14-bit channels at 44.1Khz) on ECS.

6. Faster pixel clock. OCS and ECS share the same maximum DMA bandwidth. OCS supported two pixel clocks -- 140ns and 70ns (called low-res and high-res). Because DMA bandwidth does not actually go up, in 140ns you could have video up to 6 bits wide (64-color EHB mode, and HAM-6) and in 70ns you could have up to 4 bits (16-color mode). 140ns mode actually had enough bandwidth for 8 bits, but Denise can only handle 6 maximum. With a full ECS chipset, there is an additional 35ns pixel clock (called Super Hi-Res) that supports a maximum of 2 bits (4-color mode). At 35ns you could have 1280+ horizontal pixels at 15Khz horizontal refresh and 640+ horizontal pixels at 31Khz horizontal refresh, etc.

AmigaOS shipped with premade screenmode definitions that took advantage of the 35ns pixel clock. These included the "Dbl" modes, "Productivity", and the "Super72" 800x600 mode. Since you're limited to only 4 colors at 35ns pixels though, in practice not many people used these modes until AGA came out with increased DMA bandwidth (allowing 8 bits at all three pixel clock rates).

...

There is basically no software out there that requires the 3 features enabled by ECS Denise, though a lot of audio software benefited immensely from the higher-bitrate audio you could get.

Upgrading:

ECS Fat Agnus and ECS Denise are drop-in replacements that work out of the box on all OCS systems except for the A1000 (which used the "Thin" Agnus -- there is no ECS Thin Agnus). Dropping them in will enable all the extra features instantly except for the extra Chip Memory.

On the A500 and A1500/A2000/A2500, the Fat Agnus socket's address lines need to be slightly reconfigured in order for the system to map the second bank of 512k on the chipmem bus into the custom chipset address space (i.e. the range that Fat Agnus can address). On older mobo revisions this involved modifying circuit traces, but on newer ones they ran the traces to jumper pads to make it easier to change.

The physical memory on the bus exists by default on the motherboard on the A1500/A2000/A2500. On the A500 this can be added via a card in the trapdoor slot, although you can also solder the chips directly to the motherboard if you want. Older A500 revisions had no provision for this, but you could hack the chips onto the bus (usually by "piggybacking" them on top of the existing RAM chips). Newer A500s have extra solder points on the motherboard specifically to accommodate the extra RAM. Generally there isn't much point of this and you might as well use the trapdoor.

A note about the trapdoor expansions/motherboard RAM. This RAM exists on the Chip Memory bus, so when the custom chipset's DMA seizes the bus for operations, the CPU can't talk to it, regardless of whether the OS considers it Chip or Fast. This means that it's not "real" Fast Memory that the CPU has exclusive bandwidth to. Because of this, the community generally refers to this memory as "Slow Memory" when it's not mapped as Chip.

Also note that the Fat Agnus socket on the A500 and A1500/A2000/A2500 does not have enough physical address lines wired to it to support 2M of Chip, regardless of how much memory is on the Chipmem bus. If you drop a 2M Fat Agnus into this socket, it will work, but it will only ever be able to address 1M.

There are, however, expansion boards out there that provide the extra address line and onboard RAM to let the 2M Agnus have its full addressable space. One example is the DKB MegaChip. The board has the 2M Agnus mounted on it and then drops into the Fat Agnus socket.

....

Hopefully these explanations help! =D
 

Offline AmigaHope

  • Newbie
  • *
  • Join Date: Dec 2006
  • Posts: 41
    • Show all replies
Re: Upgrade Ram to 1 MB Amiga 500?
« Reply #1 on: April 18, 2010, 07:35:32 PM »
Quote from: Jope;554277
Are you absolutely sure about this?

I haven't verified the pinouts myself, but I seem to remember that they are not compatible enough to just be dropped into a rev6 or earlier A500.
Hmm, you may be correct, now that I think about it, I've never actually tested it. Memory a bit fuzzy on that front.

Doesn't really matter though as why would you spend the extra money to buy a 2M one when either way you'd get no benefit over a 1M one if you're just doing a drop-in replace?
 

Offline AmigaHope

  • Newbie
  • *
  • Join Date: Dec 2006
  • Posts: 41
    • Show all replies
Re: Upgrade Ram to 1 MB Amiga 500?
« Reply #2 on: April 18, 2010, 10:03:00 PM »
Quote from: save2600;554286
For $95 shipped, I'll sell you a GVP MegaChip that includes the fattest Agnus AND the 1mb of memory...
Not what I meant. I meant if you were just buying a loose chip to plug in, even if the 2M one worked there'd be no point in spending the extra money over a 1M one since you would only get 1M chip anyway.

Obviously if you're buying a board that lets Agnus address 2M chip, then it actually makes a difference.
 

Offline AmigaHope

  • Newbie
  • *
  • Join Date: Dec 2006
  • Posts: 41
    • Show all replies
Re: Upgrade Ram to 1 MB Amiga 500?
« Reply #3 on: April 21, 2010, 09:33:34 PM »
Quote from: amigaksi;554772
So are you saying with real fast memory, the CPU can access the fast memory at the same time that custom chips access chip ram?

I usually run with only chip RAM so all the games work.  I do have an A500 with 4MB trapdoor card and an IDE board so total is 5MB (1MB chip RAM + 4MB fast RAM), but it has problems with games.  The 2MB Agnus (8375) A500 has no jumpers but uses the 1MB from trapdoor and 1MB from motherboard (rev. 8a) and that's more compatible with games.  This revision does have the ECS Denise as well.  The 1MB chip RAM A500 has normal Denise but again no jumpers.
Yes, real Fast Memory runs on a completely separate bus. The trapdoor slot runs on the custom chipset bus, so RAM there is substantially slower regardless of whether it is mapped as Chip or "Fast". You can test this yourself by running a RAM benchmarking program. If you run it in a 2 color 320x200 screen, and a 16-color 640x400 screen, you'll see that the "Fast" RAM is slowing down just like the Chip RAM, because the DMA for the screen refresh is hogging time on the bus.

If you look at the trapdoor expansion on your A500, you'll see that the board has an extra connector going to the Gary chip -- this hack is there to make sure that the memory mapping used for the expansion shows up properly on the internal bus. (Incidentally this can stop other expansions from working properly!)

If you want true Fastmem in your A500, it needs to be added to the CPU bus (either via a piggyback on the CPU socket, or the expansion slot on the left side). If you add a new CPU board that has local RAM on the expansion, this will create the best-case scenario.

I don't know why it's having problems with games, it could do with how the memory is being mapped conflicting with your IDE expansion's mapping. Also, a lot of very early badly-behaved games expected RAM to be in very specific locations, so this could be your issue. In general the original 24-bit Amiga memory map (introduced with the A1000, but the specific tweaks on the A500 became the "standard" map that a lot of people wrote for) had very specific portions of memory reserved for the trapdoor, while other parts were reserved for other parts of the system.

The "Slow RAM" portion of the memory map starts at 0x00C00000 and can be up to 1.5M in size. An additional 256k of reserved space immediately after this was sometimes appropriated for this as well. If you use UAE and drag the "Slow RAM" slider all the way to 1.8M, it's mapping into this reserved space.

Chip RAM starts at 0x00000000 and initially only was mapped up to 512k, but reserved space up to 2M was used up through ECS/AGA. Some very stupid early expansions used this space assuming it wouldn't be Chip RAM.

Pretty much all non-trapdoor expansions respect the first 512k from 0x00c00000 as reserved for the trapdoor, since just about everyone had the 512k expansion (even if it didn't get mapped there). This is why it's generally safe to have it there. They also generally respect the full 1.5M of that part of the memory map.

The first thing you should do is use a system info tool that can display your memory mapping to see where your RAM expansion is mapping itself. I believe AmigaOS 2.x and up has a built-in tool for this, but I don't remember if there's anything that comes with 1.x. You can download a third-party tool like Ranger or SysInfo to show what's there.

Try pulling out your IDE expansion and see if the games start running correctly. If not, it's probably a problem with how they see the trapdoor memory. In general trapdoor expansions beyond the generic 512k expansion should be avoided. (There were some very strange expansions for the trapdoor though, including a weird NEC-clone-CPU XT-compatible IBM-PC-clone expansion!)

If you really must put more than 512k on the trapdoor, you really should limit it to 2M. A good expansion will let you map 512k to Chip RAM and the rest to the full 1.5M of the 0x00c00000 portion of the map. When you try to do weird multi-mappings from the trapdoor (i.e. anything not a contiguous block starting from 0x00c00000), that's where the Gary hacks come in. When you start to go into that space you know you are inviting trouble.

Generally the best way to combine expansions is to not use ones that mix address space on different buses. i.e. trapdoor expansions should stick to the trapdoor Slow RAM portion of the memory map, and the CPU-only portion should go on either a CPU piggyback or on the sidecar.

CPU piggyback expansions are particularly problematic because they, by their nature, can muck with the entire memory map that the CPU sees. I strongly recommend that the only expansion you place there be a CPU card, and if it has any RAM on it it should be true 32-bit RAM that the rest of the system can't see anyway. If you put anything 24-bit on the CPU socket, don't put anything on the side expansion slot. Well-designed stuff should play nicely via autoconfig, but there's no way to guarantee this will happen. There were a few 32-bit CPU cards that went on the side slot (GVP made one, I recall). If you use any of those try to avoid putting anything on the CPU socket.

Your A500+, on the other hand, is in a very straightforward config. The trapdoor card is mapping the extra RAM to the Chipmem portion of the memory map. It's a very clean setup and should have no problems (other than incompatibility with very ancient stupid games that make hard jumps to the ROMs or demand that RAM exist at 0x00c00000). Slap a hard drive controller with some extra RAM on the side expansion port, and possibly a CPU expansion (either in the sidecar expansion or in the CPU socket, preferably one that allows 68000 fallback for particularly stupid games) and you're golden.

If you do go with a 32-bit CPU card, you can use WHDLoad installers to put the games on the hard drive (the faster CPU taking care of any WHDLoad overhead). Almost all of these have patches to make them work with a 68030, so you don't need to worry about compatibility. In practice I've found that games work best with a CPU card that runs synchronous to the chipset (14Mhz or 28Mhz, rather than 25, 33, 40, or 50Mhz).

My A500 has a "Sapphire" 14Mhz 68020 card on the CPU socket, and a GVP HD8+ hard drive controller with expansion RAM on the side expansion slot. While the CPU card has no provision for 32-bit RAM and thus the speed of the system is limited, WHDLoad stuff runs like a champ on this setup and almost everything is compatible with it and runs at good speed, and there's no lag from custom chipset waitstates since the CPU is run synchronously.

There's also a couple of CPU cards out there that use a 68000 but clock it at 16 or 28Mhz. (AdSpeed or SupraTurbo). These have the advantage of being compatible with stuff that expects the broken behaviors of the 68000 concerning 24-bit addressing and supervisor stack pointer (which was fixed in the 68010 and higher). You can use these to run some broken games without patching them. I don't recommend them, however.

Isn't this FUN? =D

On the plus side, using a real Amiga you get super-silky scrolling from your games, something that is next-to-impossible to achieve in an emulator due to the levels of abstraction in the host OS's video drivers.
 

Offline AmigaHope

  • Newbie
  • *
  • Join Date: Dec 2006
  • Posts: 41
    • Show all replies
Re: Upgrade Ram to 1 MB Amiga 500?
« Reply #4 on: April 28, 2010, 12:38:53 AM »
Any progress?