Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: trekiej on March 05, 2010, 11:01:11 PM
-
Wikipedia says it is 150 MB/sec, I assume theoretical.
What do you think?
Did any card ever use that close to that much bandwidth?
http://en.wikipedia.org/wiki/List_of_device_bandwidths
-
Wikipedia says it is 150 MB/sec, I assume theoretical.
What do you think?
Did any card ever use that close to that much bandwidth?
http://en.wikipedia.org/wiki/List_of_device_bandwidths
http://en.wikipedia.org/wiki/Amiga_Zorro_III
Although the Zorro III bus has a theoretical bandwidth of 150 MByte/s (32-bit x 37.5 MHz), the real transfer speed between the system and a Zorro III card is less than 20 MByte/s due to the limitations of the Buster chip. This is also the limiting factor with PCI expansion boards like e.g. Elbox Mediator PCI or the Matay Prometheus PCI (about 12 MByte/s PCI to 68k-system). DMA transfers between two Zorro III cards (or PCI cards on an PCI expansion board) can be much faster.
-
Wikipedia says it is 150 MB/sec, I assume theoretical.
What do you think?
Did any card ever use that close to that much bandwidth?
http://en.wikipedia.org/wiki/List_of_device_bandwidths
With Buster 11, writing to a PIV (for example) is just under 10MB/s. In practice, I doubt you'll get anywhere near 20MB/s.
-
Buster is a prime candidate for modernized FPGA replacement. I hope Jens Schoenfeld or the Natami guys are working on it.
-
Buster is a prime candidate for modernized FPGA replacement. I hope Jens Schoenfeld or the Natami guys are working on it.
Would it be possible to put a drop-in replacement for buster to
1) fix stupid bugs
2) make it auto-magically faster?
-
Would it be possible to put a drop-in replacement for buster to
1) fix stupid bugs
2) make it auto-magically faster?
From my non-technical understanding, yes. But Michael Böhmer of E3B would know with more certainty.
-
I remember that somebody made his A4000 a lot faster by downgrading the crystal of the motherboard to something like 27 Mhz or so and that did speed up the fps of Quake a lot, though normal motherboard things screwed up so he could only use this trick when using the gfx card and soundcard ....
-
From my non-technical understanding, yes. But Michael Böhmer of E3B would know with more certainty.
With the usual trouble finding 5V tolerant FPGAs...
-
No-one is going to make one. It is not economically viable.
-
Would it be possible to put a drop-in replacement for buster to
1) fix stupid bugs
2) make it auto-magically faster?
I've imagined exactly this before. Since Jens has the ability to actually do it, I'm hopeful that he or someone else who can, does. Is there enough market for it to make commercial sense? Not sure about that part...
For socketed Buster motherboards, yes, you can do those two things. Think something like the 2MB Chip Ram things that fit into the Agnus socket. perhaps even have something else in the FPGA if there's room and something useful to do.
For SMT Buster motherboards, you need something to attach the FPGA thing to. And you can't disable Buster like you can disable 68000 for accelerator systems, you'd need to remove the SMT soldered Buster chip and put a socket in its place. Doable, but not necessarily anyone at home installing that.
-
With the usual trouble finding 5V tolerant FPGAs...
Put some level shifters on the PCB, a voltage regulator perhaps. Not a problem.
-
I remember that somebody made his A4000 a lot faster by downgrading the crystal of the motherboard to something like 27 Mhz or so and that did speed up the fps of Quake a lot, though normal motherboard things screwed up so he could only use this trick when using the gfx card and soundcard ....
... probably just slowed down the stopwatch for measuring the fps... The 28 MHz clock drives the chipset and the CIAs housing the system timers. If the CPU clock doesn't change (like it wouldn't in a 4000) it appears to run faster because of the time warp.
I'd overclocked my A500 back in '89 with a 32 MHz crystal. It did work nicely but my RGB monitor was literally screaming from the increased scan rate - and the integrated clock was running quite fast.
-
cool
-
No-one is going to make one. It is not economically viable.
But surely nothing is economically viable in the Amiga world these days.
Some people will pay whatever it costs. The others could never afford it.
-
I'd overclocked my A500 back in '89 with a 32 MHz crystal. It did work nicely but my RGB monitor was literally screaming from the increased scan rate - and the integrated clock was running quite fast.
Zorro3 can be overclocked to 33Mhz too but real amiga video and sound will probably suffer.
-
Zorro3 can be overclocked to 33Mhz too but real amiga video and sound will probably suffer.
Hmm - Zorro III doesn't actually have a clock, it's all asynchronous...
-
So it seems perfectly possible to install a jumper that allows you to run the 33 Mhz once the drivers for gfx card and sound card are loaded so the standard video and sound won't be used anymore ?! I thought the way to do this was to use a slower crystal and not faster ...
-
So it seems perfectly possible to install a jumper that allows you to run the 33 Mhz once the drivers for gfx card and sound card are loaded so the standard video and sound won't be used anymore ?! I thought the way to do this was to use a slower crystal and not faster ...
How's overclocking the chipset supposed to have any impact on Zorro III operations? Zorro II might be another story since its clock is derived from the 28 MHz clock, but Z3 is much faster anyway.
And how does a slower crystal speed up things???
-
One of the parts of the Asynchronous 68000 bust transfer is the wait states that are added while waiting for /DTACK. /DTACK can be created by a counter that is activated by /AS which is active low Address Strobe. The clock counts for a number of cycles then applies /DTACK.
What is also interesting is the circuits used to interface SDRAM. The address gets multiplexed by a counter to do the two sets of address reads, that is from the cpu to sdram. This is done after /AS and before /DTACK.
-
What is nice about Asynchronous timing is that the cards can work at different speeds.
*
DMA, and then CPU accessing the the PIC's memory maybe where the clock comes in to play, to speculate.
-
One of the parts of the Asynchronous 68000 bust transfer is the wait states that are added while waiting for /DTACK. /DTACK can be created by a counter that is activated by /AS which is active low Address Strobe. The clock counts for a number of cycles then applies /DTACK.
It could be worth mentioning that /DTACK cannot be generated by a counter or just at will. For reads, /DTACK is asserted by the slave to indicate that the valid data is on the bus. For writes, the /DTACK is again asserted by slave as soon as it has latched the data from the bus. That's why writes from CPU to external memory can be faster then reads.
-
One of the parts of the Asynchronous 68000 bust transfer is the wait states that are added while waiting for /DTACK. /DTACK can be created by a counter that is activated by /AS which is active low Address Strobe. The clock counts for a number of cycles then applies /DTACK.
What is also interesting is the circuits used to interface SDRAM. The address gets multiplexed by a counter to do the two sets of address reads, that is from the cpu to sdram. This is done after /AS and before /DTACK.
Yet another post that goes right over my head :)
Excellent.
-
@ tnt23
What I am refering to is that a memory chip does not or appear to not have that ability but a PIC ( add-on card )does/could. I do not know of any SDRAM chips that have ability, the author did not specify that.
The author shows a counter that counts to a specified amount of time and aserts a /DTACK. The counter is started by /AS. It appears that it does not guarantee that data has made it safely.
I believe that there is a situation after so many wait-states that under the right circumstances the read/write can be repeated. That is something I have to look up.
I am not trying to say that the wait is arbitrary. Looking at the timing diagram, I believe 3 things can happen, success, bus error, or repeat.
Sure, from /AS to /DTACK is X number of cycles for which this would all happpen.
I hope this clears up what I mean.
-
@ tnt23
What I am refering to is that a memory chip does not or appear to not have that ability but a PIC ( add-on card )does/could. I do not know of any SDRAM chips that have ability, the author did not specify that.
The author shows a counter that counts to a specified amount of time and aserts a /DTACK. The counter is started by /AS. It appears that it does not guarantee that data has made it safely.
Sorry I must have completely missed the design you guys discuss. I thought it was about speeding up Zorro cycles by automating /DTACK generation.
-
@Zac67
I mean overclocking the entire motherboard. Perhaps just the buster part could be overclocked, I don't know. My friend Frank Brana overclocked his A2000 denise (and fried a pair of them) and got 31Khz video (but he told me demos didn't look good)
-
No problem, I need to further investigate where the clock comes in to play.
Before studying the 68000 the clock is/was used to time everthing, it seems, at least in appearance, that one could get away with using R/W and ENable lines for timing.
That is me speculating.
-
I mean overclocking the entire motherboard. Perhaps just the buster part could be overclocked, I don't know. My friend Frank Brana overclocked his A2000 denise (and fried a pair of them) and got 31Khz video (but he told me demos didn't look good)
Buster runs off the CPU clock, so raising that would overclock the CPU section and Buster. The chipset section has its own (28 MHz) clock and runs asynchronously.
Overclocking will speed up things (like CPU, bus, ...) while getting you closer to the edge. Once you've exhausted the tolerances in your system and exceeded the inherent speed limit you're outa luck and crash the system. On the 3000 the probable first point of failure is the SCSI adapter - don't try with your 'good' drive.
Depending on whether the Z3 bus is the bottleneck for a given operation and how the PIC copes with the higher speed, your system might get faster - or not.
IMHO, a much better approach to speeding up the system is to look at current limits. E.g. I've been told that you can significantly speed up motherboard fast RAM by using 50 ns or 'very good' 60 ns RAMs and setting Ramsey to 16 MHz mode, thus bypassing a wait state. Probably this would also speed up Z3 DMA and PIO operations.
-
@Zac67
You know more about that than I do, humble grin.
As far as I can tell, and to speculate, to slow the system down to get more performance reminds me of an accordion effect.
The accordion effect is like a string of cars going over a speed bump. They get bunched up at the speed bump. Then they pick after the speed bump. It is as fast as the slowest chip or function.
IMHO, lol
-
Hmm...
Actually lowering a clock speed can't speed up anything (apart from the rare occasion where you profit from a quicker sync on asynchronous bus operations).
The only thing speeding up might be perceived speed in the case of slowing the stopwatch while not changing the speed of the actually gauged hardware. That would be the case if you underclock the chipset while keeping the same CPU speed.
-
I was wandering if I should answer the above post.
Here goes, I do not buy PC hardware except for those rare times I buy PC hardware.
That is how it sounds.
-
Just imagining a 10x potential speed increase across the Zorro bus :)
It took 457 of us to raise $29,656 for some documentary, if someone talented like Michael Böhmer could be convinced to make
a fully working Buster in FPGA, surely we could raise an equal amount to make the Holy Grail of A3000/A4000 upgrades a reality.
-
No-one is going to make one. It is not economically viable.
Then find someone to do it for reasons other than making lots of money.
http://opencores.org/project,zorro_to_wishbone_bridge
-
Before actually re-inventing Super Buster it's probably a more promising approach to leave out Zorro III altogether (sorry Dave) and directly interface to PCI/PCIe with an appropriate new daughterboard, ideally 1x video, 2x Z3/PCIe shared, 1x Z3/PCI shared.
If you also include a faster-than-motherboard (which is an '030 bus), direct PCI(e) interface for future accelerator cards, you've completely circumvented the ancient bottlenecks. Just add a somewhat modern 1 Gig graphics card for RAM and you're set. Anyone? :D ;)
-
Are you sure you need to "re-invent" a bus when the CSPPC and BZPPC have a "on accelerator" PCI bus used for a video card?
-
Exactly - but that's limited to that single video card. Adding a modern gfx card plus maybe a fast SCSI or SATA adapter and a GE NIC would be so much nicer, wouldn't it? Btw, I'd include USB, SATA, and Ethernet right on the daughterboard - while we're at it...
-
Isn't that a firmware issue and not a hardware limitation?
-
Maybe the question to ask is, what to keep from the old architecture and why?
-
?
-
I think the logic of producing an updated Buster is that all our existing cards would benefit from a speed increase, as would 3000Ts and 4000Ts where there is no replaceable daughterboard.
Of course producing a completely new PCIe bus would provide better performance, but we're probably looking at a whole new machine at that point - and several efforts (NatAmi, other FPGA Amigas, etc.) on that front are already underway.
-
im not sure if the cards would be able to take advantage of updated speed.
-
im not sure if the cards would be able to take advantage of updated speed.
The biggest beneficiary is probably the Mediator busboard, all cards using it at the moment are crippled by Buster limitations from a achieving anywhere near their full potential.
Also ZorroIII based cards like ZorRAM, and any future cards like the upcoming BigRamPlus from Individual computers would also see a significant speed increase.
-
im not sure if the cards would be able to take advantage of updated speed.
No, not at all. Probably it'd be wise to stick at the current speed for compatibility reasons.
My intention in talking about PCI/e was that once you pick up this task you should do the job thoroughly - without adding too much complexity, PCI soft cores are around.
Step 1: You could redo the Buster, maybe speeding it up a bit, but most of all removing the bugs.
Step 2: Integrating a PCI port opens the door for replacing the daughterboard with one carrying any mix of Z3, PCI or PCIe slots, connected to the Buster PCB by a ribbon cable. Better PCI performance without messing with Z3.
Step 3: The daughterboard has yet another connector for hooking up an accelerator board directly to the PCI world. Except for the Bvision port danbeaver mentioned all other solutions require the - fast - accelerator to go over the - slow - motherboard bus to reach a - fast - PCI busboard. Obvious where the bottleneck sits.
At the same time the '030-to-PCI bridge we built into Buster starts to work the other way around, interfacing the accelerator to the motherboard, removing some complexity from accelerator design.
Step 4: Why use an expensive and hard-to-get 68060 CPU? Better take a cheap, fast and cool(!) ARM CPU with integrated PCIe and 68k emulation in firmware. You won't see a difference except that it's faster. The 5V adaption problem has already been solved with the Buster replacement.
-
If using an ARM with 68k software emulation and make use of it's PCI bus. What's left? ;)
Regarding "Buster" how any transistors (gates) does it use?
In what ways can Buster explicitly be improved to boost Z3 speed without casuing incompatibilities?
-
WTF? 150 MB/sec Zorro3! Wiki is full of BS! :lol:
Super Buster doesn't run from a 37.5 MHz clock. It runs from CPUCLK and CLK90. These are normally 25 MHz clocks. You can overclock it but you will only get a small performance boost because Zorro3 cards are asynchronous and run from their own clock.
Dave Haynie posted on comp.sys.amiga (a long time ago) that Zorro3 had a theoretical transfer rate of 20 MB/sec but C= never made a Super Buster or a Zorro3 card which could operate at this speed.
-
I think it was theoretically max 133 MB/s burst speed.
-
... probably just slowed down the stopwatch for measuring the fps... The 28 MHz clock drives the chipset and the CIAs housing the system timers. If the CPU clock doesn't change (like it wouldn't in a 4000) it appears to run faster because of the time warp.
IIRC, it was Redrumloa.
I was curious about his claim and wrote a PPC based timer that would measure a delay using GetSysTimePPC(), which is independent of the EClock. It measured (from the PPC side) EClock based delays, after calibrating for context switch overhead and such and got him to test it. It definitely seemed that it introduced a "time dilation" effect in most 68K benchmarking tools - any operation taking constant time would require fewer EClock ticks as the system clock was slowed down. Since the software assumed the rate was unchanged, this caused a corresponding increase in the reported performance.
This doesn't discount his original claim that some things got faster, but it definitely casts a question over the quantitative results.
-
WTF? 150 MB/sec Zorro3! Wiki is full of BS!
The 150 MB/s (burst) figure comes directly from Dave Haynie. It assumes a 'perfect' implementation which Super Buster is far from.
Getting to or somewhere near this speed in any present Amiga won't be possible. The '030 bus of the motherboard and the memory bottleneck will definitely prevent it from reaching anything far beyond 20 MB/s. Many existing Z3 cards may also become problematic when raising the bus speed significantly. You can't even blame the developers - there simply is no platform to test them against.
-
No, not at all. Probably it'd be wise to stick at the current speed for compatibility reasons.
My intention in talking about PCI/e was that once you pick up this task you should do the job thoroughly - without adding too much complexity, PCI soft cores are around.
Step 1: You could redo the Buster, maybe speeding it up a bit, but most of all removing the bugs.
Step 2: Integrating a PCI port opens the door for replacing the daughterboard with one carrying any mix of Z3, PCI or PCIe slots, connected to the Buster PCB by a ribbon cable. Better PCI performance without messing with Z3.
Step 3: The daughterboard has yet another connector for hooking up an accelerator board directly to the PCI world. Except for the Bvision port danbeaver mentioned all other solutions require the - fast - accelerator to go over the - slow - motherboard bus to reach a - fast - PCI busboard. Obvious where the bottleneck sits.
At the same time the '030-to-PCI bridge we built into Buster starts to work the other way around, interfacing the accelerator to the motherboard, removing some complexity from accelerator design.
Step 4: Why use an expensive and hard-to-get 68060 CPU? Better take a cheap, fast and cool(!) ARM CPU with integrated PCIe and 68k emulation in firmware. You won't see a difference except that it's faster. The 5V adaption problem has already been solved with the Buster replacement.
i agree in full. actually what we are talking about is a complete new pci busboard along with z3 slots for compatibility. this board might plug into buster socket, as i assume if we remove booster as it is now we remove the bottleneck. or perhaps is there any other good place to hook up? i mean, a socket or connector most of amiga boards provide, not just some of them or some of accel cards. also an arm accel with 68k emu is what i am advocating since ever, even if x86 might currently still be better choice because of jit.