So, in my recent quests to acquire accelerators for my A1200 and A2000, I have discovered that 68030-based accelerators (Other than C= ones) can often address up to 128MB FastRAM, yet no 68040 ones seem to. They tend to be capped at 64MB or even 32MB -- Anyone here able to shed some light on this? My only assumption is that you can't get sufficiently fast (50ns) 72pin SIMMs that are that large.
FastRAM oddities.
- Thread starter AndyLandy
- Start date
- Replies 12
- Views 2730
playgeneration
New member
Re: FastRAM oddities.
I would have thought that a lot of the 040 cards are older designs than the 030 ones that do take 128mb. The 030 was cheap so continued to have cards made based on it, the 060 came out and became the high end cpu, the 040 is a bit lost inbetween.
Oh and the later 040 cards for 1200 and 2000 do take 128mb, the early ones just like the earlier 030's take less ram. And its not hard to see why, 128mb (as one or two simms) was incredibly expensive at the time, and the vast majority of users would never even need that much anyway. Do you even need 128mb now? or just want it because it sounds cool (nothing wrong with that mind, I'm the same!)
I would have thought that a lot of the 040 cards are older designs than the 030 ones that do take 128mb. The 030 was cheap so continued to have cards made based on it, the 060 came out and became the high end cpu, the 040 is a bit lost inbetween.
Oh and the later 040 cards for 1200 and 2000 do take 128mb, the early ones just like the earlier 030's take less ram. And its not hard to see why, 128mb (as one or two simms) was incredibly expensive at the time, and the vast majority of users would never even need that much anyway. Do you even need 128mb now? or just want it because it sounds cool (nothing wrong with that mind, I'm the same!)
Re: FastRAM oddities.
@Harrison
The 060 CPU is the worst-compatible one. The 040 is only a bit less compatible than a 030.
But the 060 run obscene and outrageously faster than the 040, what explain its "desireability".
@Harrison
The 060 CPU is the worst-compatible one. The 040 is only a bit less compatible than a 030.
But the 060 run obscene and outrageously faster than the 040, what explain its "desireability".
Re: FastRAM oddities.
Ahhhh the good'ol memory question -
go put the kettle on, make yourself a good hearty brew... come back get into a nice comfy chair and read on --
Motorola 680xx series CPU's
ALL (NON EC* thats Embeded Controllers) Motorola CPU's can address in 32bit, even the humble 68000, so why all these crazy limmitations?
Well firstly 32bit Fast ram (thats outside the 8MB Zorro Addressing Space) is only limmited by the controller thats been designed / implemented by the product vendor.
In the case of the Apollo 030 Mk3 thats 64MB in two 32MB sticks of ram, where as the Blizzard 030Mk4 can have upto 128MB, and with the SCSI daughter board, that can be increased to 256mb with another 128MB of ram.
Now why do they not just use a unified controller.... well this comes down to the price of logic at the end of the day.
Logic me this.... Logic me that -
Logic in the sense of Hard *glue* Logic, which is very cheap but limmited in space and power cost and it counter part - Programmable Logic, which is expensive in software development, component and testing are the limmiting factors here.
If a company has previously designed a controller that can use upto 32MB then why re-invent the wheel... we are talking about a time when the Operating system only used 880KB of ram, 32MB of the stuff is arguably over kill...
Phase 5/ DCE, is one of the few companies that re-designed their memory controller(s) from 32MB to 64MB and then onto 128MB. and they implemented this for their 030/040 and 060 range of cards (although the latter 2 are the same card just different cpu)
What kinda Matrix does the memory have?
Another limmiting factor of the day was Standards, and the serious lack of them! today we enjoy so many well documented memory standards it truly is awesome.... however, this was no so.... pre 2000 we had so many types and then fundemental differences of series in those types....
for instance.... 64pin SIMMS, apple had some.... GVP had some.... none of them were compatible with each other....
72pin SIMMS, some were parity, some were not.... and now we get to the best bit.... the Memory Matrix (sounds cool eh?)
now Imagine a memory stick is organized like a spread sheet, it has rows and columns.... now Memory Matricies can be made up of Y rows and X columns, so if we have one thats the same number of rows as columns, thats know as a SQUARE matric 1024 cells by 1024 cells.
However IF we had a Memory Matrix of [Y]2048 by [X]1024 cells, this would be a Narrow matrix and Finally if we had a memory matrix [Y]1024 by [X]2048 then this is a WIDE matrix....
this might seem quite simple to understand, but your memory controllers logic would have to deal with the above, and as so it will make it furtherly complicated requriring more logic etc etc...
Now if you compound the above by adding Parity and ECC check bits you are in for a nightmare trying to create a generic memory controller..
you see, back in the day theres was only two ways to create a memory controller...
1. Brute force... this writes a sump of data in memory locations and reads them back and then it will allocate to the ammount that returned correct. (you can already see the issues this has with WIDE and NARROW memory Matrices)
2. Probe SIMM... this feature although was designed early in the life of the 72Pin SIMM and was part of the reason to adopt the PS2 72pin simm standard, however although the 72pin allowed greater size, the PROBE lines (theres 4 of them) were adopted VERY late in its life, as such PROBING SIMM's was almost worthless as there was not data to draw back from.
Refresh Speeds
Ahhh whats better 50ns / 60ns / 70ns or 80ns.... want to know the answer.?
the simple answer is ANY SPEED that has NO WAIT STATES, to achive this its a calculation of the cpu cycle speed and the memory cycle speed, if you can match these togther you have Zero Wait State.... kinda like the Optimum fuel-air mixture in a car,
really crap anology -
lets imagine a seesaw, the cpu on one side and the memory on the other. data is collected by one of them as they are bounced up to the top with the other going low to the ground. this is a Wait State approach as one has to wait until the other has collected.
So rather than each of them going up and down with the cycles to exchange data (Wait State Approach) if there cycles are carefully balanced (the seesaw is level) both parities will be able to deal with data without any waiting caused by either party.
Now... whats all this nano-second refresh worth then?.... well the goal is to have Zero Wait, to do this processors have different cycle times, memory controllers have different latching times and RAM's have different refreshing times... so... IF you can achive a SIMM that will refresh quicker than your card cycles then you have achived a Zero Wait State.
by far the easiest to achieve Zero Wait State is using a Syncronus clock (i.e. clocking the memory at the same speed as the processor) this gives you a much clearer logic path and hence simpler to create, Syncronus clocking may still need to introduce a wait every other tick or so to keep the cycles correct (this could be a processor tick and do nothing).
The problem here is that the Memory HAS to run at the same speed as the CPU, this bottle-necks the CPU as memory just cannot be run that fast. 50ns refresh will bottom out and not keep up with any more than 38-45mhz direct clock and this doesn't include the cycles need to instagate the Column and Row refreshes
so what else can we do? well
Asyncronus (differing speeds), this will free up the processor to actually process, and the RAM to be ram... with clever logic and the right speed of RAM's you can achive a Zero Wait state with carfull design of the cycles and there number of cycles between ticks, as you can imagine its a whole lot more complicated, and hence.... pricy in both devlopment and implementation.
so.... there you have it =D
AndyLandy said:
Ahhhh the good'ol memory question -
go put the kettle on, make yourself a good hearty brew... come back get into a nice comfy chair and read on --
Motorola 680xx series CPU's
ALL (NON EC* thats Embeded Controllers) Motorola CPU's can address in 32bit, even the humble 68000, so why all these crazy limmitations?
Well firstly 32bit Fast ram (thats outside the 8MB Zorro Addressing Space) is only limmited by the controller thats been designed / implemented by the product vendor.
In the case of the Apollo 030 Mk3 thats 64MB in two 32MB sticks of ram, where as the Blizzard 030Mk4 can have upto 128MB, and with the SCSI daughter board, that can be increased to 256mb with another 128MB of ram.
Now why do they not just use a unified controller.... well this comes down to the price of logic at the end of the day.
Logic me this.... Logic me that -
Logic in the sense of Hard *glue* Logic, which is very cheap but limmited in space and power cost and it counter part - Programmable Logic, which is expensive in software development, component and testing are the limmiting factors here.
If a company has previously designed a controller that can use upto 32MB then why re-invent the wheel... we are talking about a time when the Operating system only used 880KB of ram, 32MB of the stuff is arguably over kill...
Phase 5/ DCE, is one of the few companies that re-designed their memory controller(s) from 32MB to 64MB and then onto 128MB. and they implemented this for their 030/040 and 060 range of cards (although the latter 2 are the same card just different cpu)
What kinda Matrix does the memory have?
Another limmiting factor of the day was Standards, and the serious lack of them! today we enjoy so many well documented memory standards it truly is awesome.... however, this was no so.... pre 2000 we had so many types and then fundemental differences of series in those types....
for instance.... 64pin SIMMS, apple had some.... GVP had some.... none of them were compatible with each other....
72pin SIMMS, some were parity, some were not.... and now we get to the best bit.... the Memory Matrix (sounds cool eh?)
now Imagine a memory stick is organized like a spread sheet, it has rows and columns.... now Memory Matricies can be made up of Y rows and X columns, so if we have one thats the same number of rows as columns, thats know as a SQUARE matric 1024 cells by 1024 cells.
However IF we had a Memory Matrix of [Y]2048 by [X]1024 cells, this would be a Narrow matrix and Finally if we had a memory matrix [Y]1024 by [X]2048 then this is a WIDE matrix....
this might seem quite simple to understand, but your memory controllers logic would have to deal with the above, and as so it will make it furtherly complicated requriring more logic etc etc...
Now if you compound the above by adding Parity and ECC check bits you are in for a nightmare trying to create a generic memory controller..
you see, back in the day theres was only two ways to create a memory controller...
1. Brute force... this writes a sump of data in memory locations and reads them back and then it will allocate to the ammount that returned correct. (you can already see the issues this has with WIDE and NARROW memory Matrices)
2. Probe SIMM... this feature although was designed early in the life of the 72Pin SIMM and was part of the reason to adopt the PS2 72pin simm standard, however although the 72pin allowed greater size, the PROBE lines (theres 4 of them) were adopted VERY late in its life, as such PROBING SIMM's was almost worthless as there was not data to draw back from.
Refresh Speeds
Ahhh whats better 50ns / 60ns / 70ns or 80ns.... want to know the answer.?
the simple answer is ANY SPEED that has NO WAIT STATES, to achive this its a calculation of the cpu cycle speed and the memory cycle speed, if you can match these togther you have Zero Wait State.... kinda like the Optimum fuel-air mixture in a car,
really crap anology -
lets imagine a seesaw, the cpu on one side and the memory on the other. data is collected by one of them as they are bounced up to the top with the other going low to the ground. this is a Wait State approach as one has to wait until the other has collected.
So rather than each of them going up and down with the cycles to exchange data (Wait State Approach) if there cycles are carefully balanced (the seesaw is level) both parities will be able to deal with data without any waiting caused by either party.
Now... whats all this nano-second refresh worth then?.... well the goal is to have Zero Wait, to do this processors have different cycle times, memory controllers have different latching times and RAM's have different refreshing times... so... IF you can achive a SIMM that will refresh quicker than your card cycles then you have achived a Zero Wait State.
by far the easiest to achieve Zero Wait State is using a Syncronus clock (i.e. clocking the memory at the same speed as the processor) this gives you a much clearer logic path and hence simpler to create, Syncronus clocking may still need to introduce a wait every other tick or so to keep the cycles correct (this could be a processor tick and do nothing).
The problem here is that the Memory HAS to run at the same speed as the CPU, this bottle-necks the CPU as memory just cannot be run that fast. 50ns refresh will bottom out and not keep up with any more than 38-45mhz direct clock and this doesn't include the cycles need to instagate the Column and Row refreshes
so what else can we do? well
Asyncronus (differing speeds), this will free up the processor to actually process, and the RAM to be ram... with clever logic and the right speed of RAM's you can achive a Zero Wait state with carfull design of the cycles and there number of cycles between ticks, as you can imagine its a whole lot more complicated, and hence.... pricy in both devlopment and implementation.
so.... there you have it =D
Re: FastRAM oddities.
Excellent post, my friend. You always amaze me with your knowledge, humility and patience to write such a long post in a way that even a knob like me will understand.
Just a minor correction: the 68000 (any version used in Amiga), 68010 and 68EC020 have a 24 bit address decoder.
24bit means 16777216 individual address can be accessed at a time. Due limitations in the Amiga design the first 8Mb address space is reserved for ROM, chip RAM, autoconfig devices (Zorro) and even the (in)famous 1.8Mb Ranger memory, among other things. Notice that all that stuff is in the first 23bit address area (yes, space doubles for each address bit added).
The 24th address bit is the called Zorro-II RAM area and is 8Mb wide.
________________________________________________
The 25th to 32th bits in 68020 CPU onwards (including EC, LC, etc versions) carry the leftover of the (theoretical) 4Tb(!!!) address space and is where the 32-bit Fast RAM is located.
Excellent post, my friend. You always amaze me with your knowledge, humility and patience to write such a long post in a way that even a knob like me will understand.
Just a minor correction: the 68000 (any version used in Amiga), 68010 and 68EC020 have a 24 bit address decoder.
24bit means 16777216 individual address can be accessed at a time. Due limitations in the Amiga design the first 8Mb address space is reserved for ROM, chip RAM, autoconfig devices (Zorro) and even the (in)famous 1.8Mb Ranger memory, among other things. Notice that all that stuff is in the first 23bit address area (yes, space doubles for each address bit added).
The 24th address bit is the called Zorro-II RAM area and is 8Mb wide.
________________________________________________
The 25th to 32th bits in 68020 CPU onwards (including EC, LC, etc versions) carry the leftover of the (theoretical) 4Tb(!!!) address space and is where the 32-bit Fast RAM is located.
Re: FastRAM oddities.
@rkauer
LOL, i dont always get it right either lol, this might interest you thought the MC68000 is infact 16/32bit addressing BUT as you said its a 24bit encoder... why is that?.... I personally believe it comes down to the adressing mode(s) available
only having a 24bit address encoder/decoder but the ability to address in 32bits =D within that 24bit memory space.
@rkauer
LOL, i dont always get it right either lol, this might interest you thought the MC68000 is infact 16/32bit addressing BUT as you said its a 24bit encoder... why is that?.... I personally believe it comes down to the adressing mode(s) available
only having a 24bit address encoder/decoder but the ability to address in 32bits =D within that 24bit memory space.
Re: FastRAM oddities.
Software written by good coders is compatible with most of it, sometimes you have to turn this or that cache off. Old software can be hard to get running on a platform/combo that didn't exist yet, and new software often fails as a result of bad code, bad compiler or "not testing on this or that combo of hardware".
Every single CPU model has existed for decades, so it's silly to blame the hardware for errors in software that came afterwards... on my PPS-040 I find that most old software is super-reliable with 68040, for a handful you have to turn off the copyback cache.
If you mean the FPU, well, if the math-intensive app assumes things about which FPU you have and on top of that doesn't use libraries... well, shrug. Real3D etc works fine here.
Back on topic: unless it's a special design, a 68040@25 to 33 MHz runs fine on up to 80ns RAM, a waitstate or two doesn't affect performance noticably. Edit: probable reasons some don't support 128+ MB SIMMs is they were probably made for the biggest SIMMs at the time, or wanted to not use a mapping window, I guess.
Uninformed and a bit off topic, really. They're as bad as all other add-onsHarrison said:
Software written by good coders is compatible with most of it, sometimes you have to turn this or that cache off. Old software can be hard to get running on a platform/combo that didn't exist yet, and new software often fails as a result of bad code, bad compiler or "not testing on this or that combo of hardware".Every single CPU model has existed for decades, so it's silly to blame the hardware for errors in software that came afterwards... on my PPS-040 I find that most old software is super-reliable with 68040, for a handful you have to turn off the copyback cache.
If you mean the FPU, well, if the math-intensive app assumes things about which FPU you have and on top of that doesn't use libraries... well, shrug. Real3D etc works fine here.
Back on topic: unless it's a special design, a 68040@25 to 33 MHz runs fine on up to 80ns RAM, a waitstate or two doesn't affect performance noticably. Edit: probable reasons some don't support 128+ MB SIMMs is they were probably made for the biggest SIMMs at the time, or wanted to not use a mapping window, I guess.
Re: FastRAM oddities.
For productivity software it is true that most software will run across all CPUs. However I was referring more to games compatibility where it is common knowledge that most games that run on a standard 020 A1200 will also run perfectly on an 030 or 060 accelerated one. However not so many games will work with an 040.
For productivity software it is true that most software will run across all CPUs. However I was referring more to games compatibility where it is common knowledge that most games that run on a standard 020 A1200 will also run perfectly on an 030 or 060 accelerated one. However not so many games will work with an 040.
Re: FastRAM oddities.
Lot's of games had specific Patches to run on 040's back in those glorious days. Unfortunately, alot of these patches were drowned with the demise of BBS boards & few survived. :sigh:
Kin
Lot's of games had specific Patches to run on 040's back in those glorious days. Unfortunately, alot of these patches were drowned with the demise of BBS boards & few survived. :sigh:
Kin
