epa@phobos.cis.ksu.edu (Eric P. Armstrong) (09/29/90)
I've seen a few postings lately about placing a 14mhz 68000 in a A500 and some info files were said to exist on this. Where are these info files? I would also like to hear from someone who has done this modification and can tell me the problems/benefits of doing this. Eric Paul Armstrong Kansas State University Bitnet: ericpaul@ksuvm.bitnet UUCP: Internet: epa@phobos.cis.ksu.edu rutgers!ksuvax1!phobos.cis.ksu.edu!epa
a665@mindlink.UUCP (Anthon Pang) (09/29/90)
epa@phobos.cis.ksu.edu writes: > I've seen a few postings lately about placing a 14mhz 68000 in a A500 > and some info files were said to exist on this. Where are these info files? > I would also like to hear from someone who has done this modification and can > tell me the problems/benefits of doing this. The "creator" is Leslie Ayling. If the documentation & iff picture aren't already on abcfd20, I'll ftp them there (about 5K). The "hack" has only been tested on a 500, but I believe it'll work on a 2000 as well. However, contrary to the docs, it won't work on a 1000, without a Rejuvenator (ie it needs the 28mhz output from the Fat[ter] Agnus), or at least, a few more parts :) The only problem (as noted in the "accel.doc" files, and postings from thyssen@batserver.cs.uq.oz.au & martijn@dnlunx.pttrnl.nl) are the: 1) 14mhz clock rate doubles the CIA-B timer which causes the floppy drive to step at higher rates...such that it doesn't work with normal DOS floppies. A few solutions were proposed--reprogram timer interrupts, half the clock output from the 68000 (E line), or software patch from the author. Use a D-Flip flop 74ALS74 (equivalent to 74F74). Also connect pin 14 to the 5V line. -- Now will someone please find out what additional parts are needed to get this hack running on my 1000s...and post the solution to the net :)
a665@mindlink.UUCP (Anthon Pang) (09/30/90)
yorkw@stable.ecn.purdue.edu writes: > What are the Names of those Files? and IS this really a "good" way of having > a faster amiga? If so why don't someone Develop this Idea? > with 68020 acellerators for the 500 running $700+ I'd no doubt settle > for a lesser and cheaper speed increase. > > iHopefully if this got developed it'd be 100% compatiable with a regular > amiga setup.. ( I'll ftp it as "14mhz.lzh" to abcfd20...the contents being "accel.doc", "accel.pic", and "readme.txt" (I won't include "more", "show", etc...these should already be a part of one's library of utilities). It looks like a "good" way...'cause it's cheap, compatible (still using the 68000), and several solutions are available to fix the [unwanted] floppy speed up. Of course, the 68010 is socket compatible...and save for minor compatibility problems (which can be rectified easily), it could be an alternate solution/combination. The author's benchmarks suggest a 70% speed up...anyone have more "realistic" results to report?
yorkw@stable.ecn.purdue.edu (Willis F York) (10/01/90)
a665@mindlink.UUCP (Anthon Pang) writes: >The "creator" is Leslie Ayling. If the documentation & iff picture aren't >already on abcfd20, I'll ftp them there (about 5K). The "hack" has only been >tested on a 500, but I believe it'll work on a 2000 as well. However, contrary What are the Names of those Files? and IS this really a "good" way of having a faster amiga? If so why don't someone Develop this Idea? with 68020 acellerators for the 500 running $700+ I'd no doubt settle for a lesser and cheaper speed increase. iHopefully if this got developed it'd be 100% compatiable with a regular amiga setup.. ( -- yorkw@stable.ecn.purdue.edu Willis F York ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sig? I dont' need No Stinking This Space For Rent.... Sig! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
yorkw@stable.ecn.purdue.edu (Willis F York) (10/01/90)
>> I've seen a few postings lately about placing a 14mhz 68000 in a A500 >> and some info files were said to exist on this. Where are these info files? >> I would also like to hear from someone who has done this modification and can >> tell me the problems/benefits of doing this. > Well I found 14mhz.lzh on New xanth, the project seems simple, But i basicially am a total clutz, Is anyone out ther who can (or have) do this for me? Other questions: IS this project Totally reversable, (easially also) What's this i hear about drive problems? If i use a Noral Workbench in "Fast" mode i have to EITHER ise a special prog to Slow down the Drives? or use "14mhz" formated floppies? Thus most Games will require a switch to slow mode... can ya boot up in FAST mode on a Normal "7mhz" floppie? Or do ya have to make a Custom 14mhz boot disk. ...... Somthing's awfuly confusing here.... /. . -- yorkw@stable.ecn.purdue.edu Willis F York ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sig? I dont' need No Stinking This Space For Rent.... Sig! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
danb20@pro-graphics.cts.com (Dan Bachmann) (10/02/90)
In-Reply-To: message from a665@mindlink.UUCP
There has been a lot of talk about this accelerator and I plan to try
it as soon as I get a 16MHz 68000.... I have the doc files, but could somebody
tell me if they have done this with sucess? It sounds too good to be true, yet
makes perfect sense.
I am also wondering if it will cause any trouble on my 2.5MB A500
that uses the old Spirit In-Board. I don't see why it would unless the RAM
handling stuff is too slow for it, but that should still be going at 8MHz,
right?
ProLine: danb20@pro-graphics ***************************
UUCP: ...crash!pro-graphics!danb20 * Dan Bachmann *
ARPA/DDN: pro-graphics!danb20@nosc.mil * Raritan Valley College *
Internet: danb20@pro-graphics.cts.com ***************************
U.S.Mail: 509 StonyBrook Drive, Bridgewater, NJ 08807a665@mindlink.UUCP (Anthon Pang) (10/02/90)
> danb20@pro-graphics.cts.com writes: > I am also wondering if it will cause any trouble on my 2.5MB A500 > that uses the old Spirit In-Board. I don't see why it would unless the RAM > handling stuff is too slow for it, but that should still be going at 8MHz, > right? It shouldn't...your RAM isn't "clocked". The limit would be the access time (eg 150 ns) and the width of the data bus (16 bits)...the latter being the "speed barrier".
danb20@pro-graphics.cts.com (Dan Bachmann) (10/03/90)
In-Reply-To: message from yorkw@stable.ecn.purdue.edu
well, I'm pretty sure that it will work if you don't have a slow
floppy and according to what it does, if you flip the switch back you will
have your perfectly normal A500 back.
It might be a nice idea to make the switch an electronic bounceless
switch, but I guess the hard switch will work.
I'd still like to know if anyone here in the U.S. has gotten it to
work just dandy.
ProLine: danb20@pro-graphics ***************************
UUCP: ...crash!pro-graphics!danb20 * Dan Bachmann *
ARPA/DDN: pro-graphics!danb20@nosc.mil * Raritan Valley College *
Internet: danb20@pro-graphics.cts.com ***************************
U.S.Mail: 509 StonyBrook Drive, Bridgewater, NJ 08807martijn@dnlunx.pttrnl.nl (Reinalda M.) (10/03/90)
danb20@pro-graphics.cts.com (Dan Bachmann) writes: >In-Reply-To: message from a665@mindlink.UUCP > There has been a lot of talk about this accelerator and I plan to try >it as soon as I get a 16MHz 68000.... I have the doc files, but could somebody >tell me if they have done this with sucess? It sounds too good to be true, yet >makes perfect sense. > I am also wondering if it will cause any trouble on my 2.5MB A500 >that uses the old Spirit In-Board. I don't see why it would unless the RAM >handling stuff is too slow for it, but that should still be going at 8MHz, >right? I'm not familiar with the Spirit In-Board, but if it's only function is just to expand the amiga's memory then it shouldn't give you any problems. I know for sure that it won't work in combination with the KCS PC POWER BOARD.
andrewtn@mentor.cc.purdue.edu (Trevor Andrews) (10/05/90)
In article <3357@mindlink.UUCP> a665@mindlink.UUCP (Anthon Pang) writes: >epa@phobos.cis.ksu.edu writes: >1) 14mhz clock rate doubles the CIA-B timer which causes the floppy drive to >step at higher rates...such that it doesn't work with normal DOS floppies. > A few solutions were proposed--reprogram timer interrupts, half the clock >output from the 68000 (E line), or software patch from the author. > >Use a D-Flip flop 74ALS74 (equivalent to 74F74). Also connect pin 14 to the 5V >line. I am about to implement the 14Mhz Hack and would like to know how I should half the 'E' line on the 68000. The schematics look very clean and easy but I would really rather not have my floppies overloaded. Any help or information on the 'E' line would be greatly appreciated! I'm not interested in the software patch or reprograming the timer interrupts. Unless that is a lot easier than the halving of the 'E' line. Will I lose any performace gains by keeping the 'E' line at 7Mhz? I wouldn't think so... P.S. how fast does my drive have to be so it won't experience the slow spin up problem? I have heard of someone doing the Hack and replacing his internal drive with a 5ms one! But who wants to buy a drive when the hack is less than $20? Thanks for you time, Trevor Andrews -- The Trev
mrush@csuchico.edu (Matt "C P." Rush) (10/06/90)
In article <14787@mentor.cc.purdue.edu> andrewtn@mentor.cc.purdue.edu (Trevor Andrews) writes: > >I am about to implement the 14Mhz Hack and would like to know how >I should half the 'E' line on the 68000. The schematics look very >clean and easy but I would really rather not have my floppies >overloaded. Any help or information on the 'E' line would >be greatly appreciated! I'm not interested in the software patch >or reprograming the timer interrupts. Unless that is a lot easier >than the halving of the 'E' line. Will I lose any performace gains >by keeping the 'E' line at 7Mhz? I wouldn't think so... The best suggestion I've heard for the E-clock problem is to use the other FlipFlop in the 74F74 to divide the the accelerated output from the E-clock. Is phasing likely to be an issue if this is done? Of course this would require a little extra consideration in the circuit for the speed-switch (don't divide the E-clock at normal speed). -- Matt *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* % "I programmed three days % Beam me up, Scotty. % % And heard no human voices. % There's no Artificial % % But the hard disk sang." % Intelligence down here. % % -- Yoshiko % % E-mail: mrush@cscihp.ecst.csuchico.edu % *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* This is a SCHOOL! Do you think they even CARE about MY opinions?!
martijn@dnlunx.pttrnl.nl (Reinalda M.) (10/11/90)
This how far I got with the 14MHz speedup : Halving the 28MHz clock to 14MHZ works, but the drives go way too fast. Even a fast drive won't work reliabele.. Halving the E signal doesn't work. Halving the E, VPA and VMA signals doesn't work. So, I'm stuck for the moment. BTW, I've read that there has been a discussion on this subject some time ago. Somebody knows if they got the thing going ??? Come on, there must be more hardware hackin' amiga freaks interrested in speeding up their Amigas !!!!!?!!
gt0655b@prism.gatech.EDU (gt0655b gt0655b HAARBAUER,ERIC STOWE) (11/09/90)
Could someone repost or mail me info on Leslie Ayling's 14 MHz
hack applied to an Amiga 1000? The original posts are gone.
Just a simple answer would suffice: Does it work, are the pins
different than the 500 schematic, is a steprate changer required....
Thanks
--
HAARBAUER,ERIC STOWE "Consciousness is an accident."
Georgia Institute of Technology, Box 30655, Atlanta, GA 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0655b
Internet: gt0655b@prism.gatech.edumcc@moscom.UUCP (Mike Corbett) (11/14/90)
In article <16751@hydra.gatech.EDU> gt0655b@prism.gatech.EDU (gt0655b gt0655b HAARBAUER,ERIC STOWE) writes: > > Could someone repost or mail me info on Leslie Ayling's 14 MHz >hack applied to an Amiga 1000? The original posts are gone. > > Just a simple answer would suffice: Does it work, are the pins >different than the 500 schematic, is a steprate changer required.... > >Thanks OH NO! It's another _ME TOO_ message. I also need this info, so please include me in any responses. Mike -- /// /// "Only Amiga Makes It Possible!" moscom!mcc \\\ /// \XXX/ "On the other hand, you have different fingers..." Steven Wright
cpc@sharkey.uucp (Chris Cebelenski) (12/17/90)
Two questions here:
1) I know this is old, but any caveats about that 14mhz hack that was
floating around? It involves flip-flopping a signal from the agnus
into a timing signal for the processor.
2) I just ordered Expansion Systems's BASEBOARD 4mb upgrade for my A500,
and was wondering if there are any stories about it floating around? Is
it hard to install, etc? How compatible is 100% ( :-) ) Etc,etc.
--
==========================================================================
Chris Cebelenski UUCP: portal.com!gdc!aminet!czaeap!cpc
The Red Mage Internet: czaeap!cpc@aminet.gdc.portal.com
GEnie: C.CEBELENSKI
// "Amiga - The way REAL people compute"
"Better dead than mellow" \X/
==========================================================================rudolpe@jacobs.CS.ORST.EDU (Eric Hans Rudolph) (04/13/91)
I have been trying to build the 14Mhz hack in it's various forms for a while now. I can't seem to get any of the versions to work, probably from what I think is poor thought on the designer's part. Now I think I understand that the 68k is aysynchronous, and will wait for VPA* or Dtack* or Buss Error... I know theoretically, it will wait for one of those above forever. All this business about syncing Dtack* so that the 68k will start a bus cycle on the correct clock phase is confusing me. I thought Gary monitored when the 68k entered a bus cycle and corrected it if it was in the wrong phase. Is there anyone out there who can tell me just how long I can hold off Dtack* and where I can have it asserted, assuming that the 14Mhz 68k starts the bus cycle S0 at the same time it WOULD have if it were running at 7Mhz? (is this a valid assumption? I am XORing CDAC (not inverted) with 7Mhz. ) Is it possible to get this hack to work? If I divide down the 1.4Mhz Eclock by 2 with a flip flop, the new E clock will be at a 50/50 duty cycle, assuming I can get VPA* and VMA* to work, does the 50/50 pose a problem? Any comments? I am desperate... rudolpe@jacobs.cs.orst.edu
breemen@rulcvx.LeidenUniv.nl (E. van Breemen) (04/15/91)
The last weeks there is a lot of talk (again) about the famous 14 Mhz hack. I have such a hack running for months now. To help other developers I will reveal some clues. First of all the AS* is not important for the synchronous board. Just connect it with the 68000 socket. Most important is the DTACK*. You can look at the PAK board how it is done. Last but not least: replace the VPA* and VMA* stuff by a circuit using just DTACK*. In other words my board doesn't use VPA/VMA: they are not connected to the 14 Mhz 68000. If you have to do VPA stuff just hold the DTACK for about one E-clock. The only 'bug' (if it is a bug) is that I have sometimes during the first minute a jumping mousepointer. Dave said he had encountered this also during his experiments, but couldn't say what it was. Another hint: use sometimes slower logic, how strange this may seem sometimes it helps! Currently I am working at an asynchronous board for the 68020. So the synchronous board project has more or less ended for me. The main reason is the fact that the speed advantage is minimal (1.2 not 1.7 or so) without cach memory. And the m68020 is becoming cheaper, for about $150 you can build a 68020 board. Erwin van Breemen Orega Holland.
livio@alessia.dei.unipd.it (Livio Plos) (04/16/91)
In article <1991Apr12.182537.1835@lynx.CS.ORST.EDU>, rudolpe@jacobs.CS.ORST.EDU (Eric Hans Rudolph) writes: > > Is there anyone out there who can tell me just how long I can hold off Dtack* > and where I can have it asserted, assuming that the 14Mhz 68k starts the > bus cycle S0 at the same time it WOULD have if it were running at 7Mhz? > (is this a valid assumption? I am XORing CDAC (not inverted) with 7Mhz. ) > > Is it possible to get this hack to work? > > If I divide down the 1.4Mhz Eclock by 2 with a flip flop, the new E clock > will be at a 50/50 duty cycle, assuming I can get VPA* and VMA* to work, > does the 50/50 pose a problem? > No problem, I suppose, because 8520 are built to work with processor that give them a 50% duty cycle clock, but they are so good that work also with a 60/40. > Any comments? I am desperate... > > rudolpe@jacobs.cs.orst.edu These are the timings of my hack. t1 t2 t3 t4 t5 t6 | | | | | | s2 s3 s4 s5 s6 s7 _____ _____ _____ _____ 7M _____| |_____| |_____| |_____| |_____ __ __ __ __ __ __ __ __ __ 14M |__| |__| |__| |__| |__| |__| |__| |__| |__ ___________ _____________ AS* \\\\\\\\\\\_________________________///// ___________ __________ ASD* |________________________///// _____________________ ___________ DTACK* \\\\\\\\\\______________///// ____________________ ___________ DTACKout* \____________///// These are the timings. With U2b I delay the sample of the dtack* until t2 because U2b-Q goes low only after t1 and release the U2a on the falling edge of s4 (t2). Here it samples dtack,as 68k do, and gives it availble to the 68K-14 that takes it in t3 and in t5 68k-14 read data on the data bus. In the technical reference I read that data isn't availble before 50nS of t6 so I must stay in this window, between t5 and t6 there are less than 30nS. Please pause the buliding of the New14Accel, because there is a problem with a delay of U4d or use inverter instead of U4b-c-d. I'm fixing it to use it with only 4 ic and the 68k/16. I'll post the new release. Livio P.S.:excuse me for my bad English.
breemen@rulcvx.LeidenUniv.nl (E. van Breemen) (05/10/91)
To all 14 Mhz hackers, I have received a lot of mail lately of people who asked me how I made the 14 Mhz Hack work. It is very simple, just follow the guidelines of Dave H. I know, a lot of people think they are smart and can avoid all the stuff which Dave writes about. But that the is reason why all the boards I have encountered on the network won't work. They may seem to work for 1 minute, 1 day but sooner or later they will break down. For example I had sometimes a jumping mouse pointer. First I couldn't figure it out why it jumped. The reason why it jumped is still not clear to me, but it disappeared as soon as I sampled the DTACK only at the end of S4. Before the end of S4, the DTACK is not valid. I think that the Amiga can give DTACK for example in S3 but pull it up again in the beginning of S4. So if you sample DTACK at any time, you can read an invalid DTACK. The Amiga can do this if it sees that the processor can't finish the buscycle in time (Dave correct me if I am wrong). A month ago, I found another problem. My board broke down, after a lot of AND #$..,$bfe001 instructions. This is a read/write instruction with an E-clock. First thought: the E-clock emulation is bad. Wrong! I didn't synchronize the AS. After the E-clock cycle, the Amiga sometimes didn't see a flank for sampling the AS. Result: Guru. For me the 14 Mhz started as Hack with one Flipflop and a 12.5 Mhz processor. I ended up with a 16 Mhz processor and 7 chips (no wire needed for CDAC). This is really a minimal configuration, so all the boards using just 2 or 3 chips won't work, it is sad but true. Currently I am converting the board into a SMD version, which will be published. Erwin van Breemen BTW To the designers: don't publish your board before it works 100%. It will avoid a lot of anger and disappointment.
maniac@big-joe.cs.unlv.edu (Eric J. Schwertfeger) (05/11/91)
In article <1991May10.104421.22314@rulway.LeidenUniv.nl>, breemen@rulcvx.LeidenUniv.nl (E. van Breemen) writes:
)
) For me the 14 Mhz started as Hack with one Flipflop and a 12.5 Mhz processor.
) I ended up with a 16 Mhz processor and 7 chips (no wire needed for CDAC).
) This is really a minimal configuration, so all the boards using just 2 or 3
) chips won't work, it is sad but true.
) Currently I am converting the board into a SMD version, which will be
) published.
)
)
) Erwin van Breemen
What I'd like to see is a 14 Mhz project with some fast dynamic ram on board.
After seeing the speed claims for the AdSpeed, I'm interested in a 14 Mhz 68000
with 0 wait state memory. I've even been toying with the idea of designing one
myself, but I don't have the time or the resources.
--
Eric J. Schwertfeger, maniac@jimi.cs.unlv.edubillc@cryo.UUCP (William J. Coldwell) (05/11/91)
In article <1991May10.104421.22314@rulway.LeidenUniv.nl> breemen@rulcvx.LeidenUniv.nl (E. van Breemen) writes: > >To all 14 Mhz hackers, > >I have received a lot of mail lately of people who asked me how I made >the 14 Mhz Hack work. It is very simple, just follow the guidelines of Dave H. [DTACK and E-Clock stuff deleted] >For me the 14 Mhz started as Hack with one Flipflop and a 12.5 Mhz processor. >I ended up with a 16 Mhz processor and 7 chips (no wire needed for CDAC). >This is really a minimal configuration, so all the boards using just 2 or 3 >chips won't work, it is sad but true. Not as easy as it looks, eh? Seems that CMI had the right idea after all, and even had an FPU plus a software toggle. PA's only have 8 chips and could access most ROMs at 14MHz. >Currently I am converting the board into a SMD version, which will be >published. > >Erwin van Breemen > >BTW To the designers: don't publish your board before it works 100%. It >will avoid a lot of anger and disappointment. Why? Seems to me that there is too much competition with resale PAs dropping in price, and ICD's being a hair more than new PAs. 14MHz 68Ks were a great thing 3 years ago, but with 020's and 030 prices dropping like flies it makes more sense to do a Lucas/Francis type accelerator for the 500 (IMHO). Speaking from my experience, the accelerated 68K market is d.e.a.d. -- +------+ William J. Coldwell Amiga Attitude Adjuster Cryogenic Software /| /| PLink: CRYO, BIX: wjcoldwell, UUCP:...tektronix!percy!cryo!billc +-|----+ | NAG-BBS: 503/656-7393, NES-BBX: 503/640-9337, Work: 503/254-8147 | +----|-+ // Sometimes you gotta be cool to be hot: I'm a 3-DPro Tracer. |/ |/ \X/ Amiga Call 1-800-3Dis4me (so good you can't imagine it). +------+ STD_DSCLMR "All opinions above are mine, and you can't have them."
breemen@rulcvx.LeidenUniv.nl (E. van Breemen) (05/13/91)
In article <billc.3292@cryo.UUCP> billc@cryo.UUCP (William J. Coldwell) writes: >Not as easy as it looks, eh? Seems that CMI had the right idea after all, >and even had an FPU plus a software toggle. PA's only have 8 chips and >could access most ROMs at 14MHz. They have probably used PALS for reducing the number of chips and protecting their board against copying. >>Currently I am converting the board into a SMD version, which will be >>published. >> >>Erwin van Breemen >> >>BTW To the designers: don't publish your board before it works 100%. It >>will avoid a lot of anger and disappointment. > >Why? Seems to me that there is too much competition with resale PAs >dropping in price, and ICD's being a hair more than new PAs. 14MHz >68Ks were a great thing 3 years ago, but with 020's and 030 prices >dropping like flies it makes more sense to do a Lucas/Francis type >accelerator for the 500 (IMHO). This is true, but the 14 Mhz hack will provide the needed experience to build a reliable 68020/68030 board. The Lucas/Francis boards are not reliable. You have to experiment with LS/F logic to make things work. And I don't know how the boards will perform in a heavy DMA enviroment. >Speaking from my experience, the accelerated 68K market is d.e.a.d. Commercially spoken yes, but for people who don't have enought money, say $500, it can be interesting. Erwin. PS. I have received several requests for publishing the board. I have already said before, that I will publish it when it is ready in a SMD print version (2 or 3 months).
daveh@cbmvax.commodore.com (Dave Haynie) (05/14/91)
In article <1991May10.104421.22314@rulway.LeidenUniv.nl> breemen@rulcvx.LeidenUniv.nl (E. van Breemen) writes: >I have received a lot of mail lately of people who asked me how I made >the 14 Mhz Hack work. It is very simple, just follow the guidelines of >Dave H. I know, a lot of people think they are smart and can avoid all the >stuff which Dave writes about. And there's a pretty good reason for that. No, not that I'm some kind of super wiz or anything. Mainly, these guidelines (from the '89 DevCon notes and stuff posted here) were developed by me over the course of the A2620, A2630, and A3000 development. Being that these were done by Commodore, I really didn't have the option of taking any shortcuts or being incompatible with any hardware out there that was possible to support in any way. It's doubtful that anyone hacking parttime on these goodies is going to come across some dramatically simple and elegent shortcut to compatibly get around the stuff I've been working reasonably fulltime hours on for four or so years. >They may seem to work for 1 minute, 1 day but sooner or later they will break >down. That's actually the expected behavior for the kind of failure you're likely to see when you take shortcuts, especially the more drastic and unobvious shortcuts people take when designing "asynchronous" accelerators, trying to avoid taking synchronization delays. >The reason why it jumped is still not clear to me, but it disappeared as >soon as I sampled the DTACK only at the end of S4. Before the end of S4, >the DTACK is not valid. That's actually a convention right out of the 68000 book, and the Amiga system takes full advantage of it. >I think that the Amiga can give DTACK for example in S3 but pull it up again >in the beginning of S4. So if you sample DTACK at any time, you can read an >invalid DTACK. There are actually two problems in sampling DTACK early. DTACK is managed in all pre-A3000 systems based on address space, either by Gary (A500, A2000) or a PAL that does the same thing. First of all, for a number of address spaces, DTACK is driven directly from AS, so it may come out in S2 or S3. That's the first problem. The second problem is that, for expansion space, DTACK may be controlled by an expansion board. Such a board can't start it's control logic until it sees AS. But remember, AS will be making a DTACK instantly. So by the time the expansion board has delayed (via XRDY) or taken over (via OVR) the system DTACK, it's already low. The board's timing on XRDY and OVR will get DTACK back up again long before S4. Any accelerator card that though it could sample DTACK prior to the S4/S5 edge, however, may see these false DTACKs and incorrectly handle the cycle. It's actually a little cleaner on the A3000. The only DTACK in the system is on the expansion bus. This is typically driven during S3, giving any Zorro II card a chance to OVR or XRDY before DTACK ever goes low. This is functionally the same, but makes things a little less noisy. >The Amiga can do this if it sees that the processor can't finish the buscycle >in time (Dave correct me if I am wrong). The on-board DTACK logic never asserts, then negates, DTACK on its own like that. The only wait states inserted are for Chip cycles, and the Gary or Gary equivalent knows whether a wait will be necessary before DTACK is ever sent out. The false early DTACK, as I mentioned up above, is the result of interaction with expansion cards. And a perfectly valid part of the 68000 bus protocol. >A month ago, I found another problem. My board broke down, after a lot of > AND #$..,$bfe001 instructions. This is a read/write instruction with an >E-clock. First thought: the E-clock emulation is bad. Wrong! I didn't >synchronize the AS. After the E-clock cycle, the Amiga sometimes didn't >see a flank for sampling the AS. Result: Guru. Yup, you really want to synchronize AS* and DS*. The Amiga chips themselves aren't really sensitive to this, but some of the bus control logic, like Gary, as well as expansion cards, may be very sensitive to when AS* happens. >For me the 14 Mhz started as Hack with one Flipflop and a 12.5 Mhz processor. >I ended up with a 16 Mhz processor and 7 chips (no wire needed for CDAC). >This is really a minimal configuration, so all the boards using just 2 or 3 >chips won't work, it is sad but true. Sounds good. I never sat down and figured out the proper way to do a 68000 speedup, I have only dealt with the 68020/30 bus processors. Similar rules apply for either, though. And while the A2620/30 might be optimized a bit were I to do it all over again, they could never be trivial designs and still be as compatible as they are. >BTW To the designers: don't publish your board before it works 100%. It >will avoid a lot of anger and disappointment. Really. This original 14MHz hack seems to have generated an amazing amount of news, and probably an even larger number of grumbles from people who had problems with it. At the very least, if you post something before it's been through a suitable acid test, surround it with bright red flags that indicate it may cause problems. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.
billc@cryo.UUCP (William J. Coldwell) (05/14/91)
In article <1991May13.081500.7980@rulway.LeidenUniv.nl> breemen@rulcvx.LeidenUniv.nl (E. van Breemen) writes: >In article <billc.3292@cryo.UUCP> billc@cryo.UUCP (William J. Coldwell) writes: > >>Not as easy as it looks, eh? Seems that CMI had the right idea after all, >>and even had an FPU plus a software toggle. PA's only have 8 chips and >>could access most ROMs at 14MHz. > >They have probably used PALS for reducing the number of chips and protecting >their board against copying. Yes, but board space and noise considerations are also in there. Then there is the infamous "it works in this machine, but not that one..." and the "Oh [insert your own favorite profane statement here], Commodore has just released _another_ rev motherboard that moves the [part] to a new location, causing an increased cost of a [different part]. It also breaks [other manufacturer's item] when doing [CPU or DMA action]. This in-turn causes a rush to the [name] board layout package for the changes necessary to make the [your product] work with the latest rev, reducing the meager profit margin." ;-) >>>Currently I am converting the board into a SMD version, which will be >>>published. >>[stuff deleted] >>Why? Seems to me that there is too much competition with resale PAs >>dropping in price, and ICD's being a hair more than new PAs. 14MHz >>68Ks were a great thing 3 years ago, but with 020's and 030 prices >>dropping like flies it makes more sense to do a Lucas/Francis type >>accelerator for the 500 (IMHO). > >This is true, but the 14 Mhz hack will provide the needed experience to >build a reliable 68020/68030 board. The Lucas/Francis boards are >not reliable. You have to experiment with LS/F logic to make things >work. And I don't know how the boards will perform in a heavy DMA >enviroment. The 14MHz hack will only give you a limited experience on how to deal with a syncronous CPU, while the Lucas/Francis was an async accelerator. It's reliability was about what is expected on the board of that size in a noisy A1000 running at that speed ;-). >>Speaking from my experience, the accelerated 68K market is d.e.a.d. > >Commercially spoken yes, but for people who don't have enought money, >say $500, it can be interesting. <$500 will still get a nice speedup. You can get a 25MHz Mega Midget Racer (030) for about that price. >Erwin. > >PS. I have received several requests for publishing the board. I have >already said before, that I will publish it when it is ready in a SMD >print version (2 or 3 months). SMD to me, no longer denotes a "hack". ;-) -- William J. Coldwell PLink: CRYO I'm a 3-DPro, wouldn't you Amiga Attitude Adjuster BIX: wjcoldwell like to be a 3-DPro2 ? Cryogenic Software UUCP:billc@cryo 3-D PROFESSIONAL 2.0 #define STD_DSCLMR "The above opinions are mine. You can't have them."
mmm@reaper.Chi.IL.US (Michael Marvin Morrison) (05/14/91)
In article <billc.3292@cryo.UUCP> billc@cryo.UUCP (William J. Coldwell) writes: >In article <1991May10.104421.22314@rulway.LeidenUniv.nl> breemen@rulcvx.LeidenUniv.nl (E. van Breemen) writes: >> >>To all 14 Mhz hackers, >> >>I have received a lot of mail lately of people who asked me how I made >>the 14 Mhz Hack work. It is very simple, just follow the guidelines of Dave H. > >[DTACK and E-Clock stuff deleted] > >>For me the 14 Mhz started as Hack with one Flipflop and a 12.5 Mhz processor. >>I ended up with a 16 Mhz processor and 7 chips (no wire needed for CDAC). >>This is really a minimal configuration, so all the boards using just 2 or 3 >>chips won't work, it is sad but true. > I would also suggest using a 16mhz 68010. The mere ~5% speedup you see by putting it in at the same clock speed should prove to be even greater at 14mhz. The chip is pin-for-pin compatable, so no change in design would be necessary. One question for anyone.. How does a company go about making the product software selectable between accelerated/normal? Since it's not in a slot, it doesn't have any autoconfig space to tweak a bit at.. I believe my Mega Midget writes to an address in the $c0 space that is unused on a 2000 (slow-fast ram on a 500) to switch between Fast/Normal operation, then executes a reset/stop pair. According to the guru at CSA this stops the '030 and the reset re-starts the system (it's C= reset code with a stop instruction added). I suppose on a '010 system one could use the fc0-2 lines, since on an 010 a fc0-2 of high high low (3) is reserved for user definition (unless it is currently being used by the Amiga). You could trap a 3 on the fc lines as a signal to switch to decelerated mode (using a movec to dfc I believe) -- Michael M Morrison /| |\ mmm@reaper.chi.il.us <or> | | Cash, for Cache.. | | reaper!mmm@miroc.chi.il.us \| Hmm.. sounds fair. |/
s902113@minyos.xx.rmit.oz.au (Luke Mewburn) (05/15/91)
mmm@reaper.Chi.IL.US (Michael Marvin Morrison) writes: >In article <billc.3292@cryo.UUCP> billc@cryo.UUCP (William J. Coldwell) writes: >>In article <1991May10.104421.22314@rulway.LeidenUniv.nl> breemen@rulcvx.LeidenUniv.nl (E. van Breemen) writes: >>> >>>To all 14 Mhz hackers, >>> >>>I have received a lot of mail lately of people who asked me how I made >>>the 14 Mhz Hack work. It is very simple, just follow the guidelines of Dave H. >> >>[DTACK and E-Clock stuff deleted] >> >>>For me the 14 Mhz started as Hack with one Flipflop and a 12.5 Mhz processor. >>>I ended up with a 16 Mhz processor and 7 chips (no wire needed for CDAC). >>>This is really a minimal configuration, so all the boards using just 2 or 3 >>>chips won't work, it is sad but true. >> >I would also suggest using a 16mhz 68010. The mere ~5% speedup you see by putting >it in at the same clock speed should prove to be even greater at 14mhz. The chip >is pin-for-pin compatable, so no change in design would be necessary. Small problem: Too many games are incompatible with the slight instruction set differences between the '00 and the '10. (I think the stack manipulation commands is User mode are different, or the actual set-up of User mode. Can't remember tho.) >-- >Michael M Morrison /| |\ >mmm@reaper.chi.il.us <or> | | Cash, for Cache.. | | >reaper!mmm@miroc.chi.il.us \| Hmm.. sounds fair. |/ -- ____________________________________________________________________________ | | | | Luke Mewburn (Zak) | This side for lease... | | s902113@minyos.xx.rmit.oz.au | (No disclaimer, can't afford it:-) |
tnaj2@isuvax.iastate.edu (Brian J. Cerveny) (05/15/91)
In article <mmm.1227@reaper.Chi.IL.US>, mmm@reaper.Chi.IL.US (Michael Marvin Morrison) writes: > >I would also suggest using a 16mhz 68010. The mere ~5% speedup you see by putting >it in at the same clock speed should prove to be even greater at 14mhz. The chip >is pin-for-pin compatable, so no change in design would be necessary. > I was told by a man at Motorola in the MC680x0 conference that a 16 MHz 68010 does not exist. Since his post came from Motorola I'm assuming he is correct. >-- >Michael M Morrison /| |\ >mmm@reaper.chi.il.us <or> | | Cash, for Cache.. | | >reaper!mmm@miroc.chi.il.us \| Hmm.. sounds fair. |/ ------------------------------------------------------------------------------- | ___ ___ ___ | Unclaimer: All opinions ex-| | /__/__ o__ __ / / __ __ __ __ | pressed above are probably | | / //_/ //_// / / / /_ /_// //_ / // / | my own, though I may slip | | _/__// \// // / \_/. \_//_ / \\//_ / / \/ | in an opinion expressed by | | _/ | someone else that supports | | Stat magni nominue umbra: tnaj2@isuvax.bitnet | and reinforces my own. | -------------------------------------------------------------------------------
markv@kuhub.cc.ukans.edu (05/15/91)
>>I would also suggest using a 16mhz 68010. > I was told by a man at Motorola in the MC680x0 conference that a 16 MHz 68010 > does not exist.Since his post came from Motorola I'm assuming he is correct. Yes, the fastest 68010 available is a 12MHz part. However, the difference between 12 and 14.32 Mhz is about 15% which is right on the margin of the "safety zone" built into most tolerances. I have used a 12 MHz part at 14 successfully, as have some others. The succes ratio is about 50/50 per chip. The LC parts (ceramic case) seem to do a bit better, probably because the ceramic case has some better heat dissipation. If you can keep the chip cool, like a good size direct heat sink, your probably okay since heat is what causes the most problems (witness the "IceCube" hack for a 50MHz 386). Warning, I make no claim as to the safety of trying this, however its very unlikely to hurt the machine, just fry an innocent CPU or two. Also, if your doing some heavy interrupt use (ie: fast interrupt drive I/O for one), you can benefit greatly from the 010 if you move the Exception table into fast. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bmccnnll@vax1.tcd.ie (05/16/91)
In article <1991May13.081500.7980@rulway.LeidenUniv.nl>, breemen@rulcvx.LeidenUniv.nl (E. van Breemen) writes: >>Speaking from my experience, the accelerated 68K market is d.e.a.d. > > Commercially spoken yes, but for people who don't have enought money, > say $500, it can be interesting. My thoughts exactly. Looking through ads in an Amiga magazine, I can get a 15MHz 68000 for 45 pounds, or a 17MHz 68020 for 300 pounds. There's a big difference there. I can afford the 68000. I can't afford the 68020. And if I'm going for real speed, I could spend over #1000 on a 68030 plus RAM, and would probably be better off going out and buying an Amiga 3000..... Barry.
breemen@rulcvx.LeidenUniv.nl (E. van Breemen) (05/16/91)
In article <billc.3304@cryo.UUCP> billc@cryo.UUCP (William J. Coldwell) writes: >manufacturer's item] when doing [CPU or DMA action]. This in-turn causes >a rush to the [name] board layout package for the changes necessary to make >the [your product] work with the latest rev, reducing the meager profit >margin." ;-) This is true if you are pushing your board to the edge of performance. You can do that by ignoring the specs of Commodore. It is to be expected that there are then some incompatibilities. The patch needed for repairing this will be (most of the times) something more than reprogramming a PAL. Besides that PALS are expensive if you compare them to normal logic. For example if you need flipflops to be clocked on different clocks (like in my design) you need a PAL of say $15 for a $3 logic equivalent. Cheap PALS do have flipflops, but they have to be clocked with the same clock. These PALS are of great value for address decoding and auto configuration. >The 14MHz hack will only give you a limited experience on how to deal >It's reliability was about what is expected on the board of that size >in a noisy A1000 running at that speed ;-). No, first of all you HAVE to use a datalatch for the interface to the Amiga (for an asyn. board). Certainly not some tricky delay, which depend on the kind of logic you use. Second, the FPU will also respond to MMU instructions because the interface of the CPU and the FPU is not correct. And given a noisy behaviour at 16 Mhz, you get an unreliable board. The most important lesson of the 14 Mhz hack was that you can't avoid the rules without paying a price. >>Commercially spoken yes, but for people who don't have enought money, >>say $500, it can be interesting. > ><$500 will still get a nice speedup. You can get a 25MHz Mega Midget >Racer (030) for about that price. I suppose this a board without 32bit ram. If so, you have to buy addional ram for $xxx. Otherwise, the speed increase can be little (30-40%?) because the 68020 and the 68030 will get their performance from a 32bit memory. The prices in Holland are much higher. A 68030 board without ram, will cost you at least Hfl. 1900,- ($1000). In Germany DM 1600,- with 1MB 32bit ram ($1000). In Holland, it is very difficult to get hardware besides the A500, A590 and the A2000. The drives are expensive ($300 for 3.5"). The first A3000 I have seen will cost you here Hfl. 10500,- ($5300). (BTW the Commodore support in Holland can be improved. As I asked for detailed schemes of the A500 , I got a normal commercial folder.) My point is that such a board of say $50 can be very interesting in Holland. And it is still possible to add a FPU to this cheap board. Most people don't have $1000 to spend, to accelarate a machine of $500. Why do you think I am busy building an 68020 board? I can get the components for say $150. I have (I may hope so) a knowledge of electronics and the Amiga. It should therefore be possible to build what you want. If you don't have the money, you have to use your brains instead. >SMD to me, no longer denotes a "hack". ;-) Yeap, more (I hope) a reliable board. Erwin. PS. I have received the last days many requests for a copy of the schemes. I won't send anyone a copy because: 1) It is to much work. 2) I will present the schemes in due time on the net. So, please, don't ask for schemes. I will not send it to you. Have patience for 2 months. I hope everyone can understand this. And Commodore, don't take the criticism on Commodore Nederland personal, your support on this net is great!
mmm@reaper.Chi.IL.US (Michael Marvin Morrison) (05/16/91)
In article <1991May15.103225.30756@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: >>>I would also suggest using a 16mhz 68010. >> I was told by a man at Motorola in the MC680x0 conference that a 16 MHz 68010 >> does not exist.Since his post came from Motorola I'm assuming he is correct. > >Yes, the fastest 68010 available is a 12MHz part. However, the >difference between 12 and 14.32 Mhz is about 15% which is right on the >margin of the "safety zone" built into most tolerances. I have used a >12 MHz part at 14 successfully, as have some others. The succes ratio >is about 50/50 per chip. The LC parts (ceramic case) seem to do a bit >better, probably because the ceramic case has some better heat >dissipation. If you can keep the chip cool, like a good size direct >heat sink, your probably okay since heat is what causes the most >problems (witness the "IceCube" hack for a 50MHz 386). > >Warning, I make no claim as to the safety of trying this, however its >very unlikely to hurt the machine, just fry an innocent CPU or two. > >Also, if your doing some heavy interrupt use (ie: fast interrupt drive >I/O for one), you can benefit greatly from the 010 if you move the >Exception table into fast. >-- >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >Mark Gooderum Only... \ Good Cheer !!! I made a mistake.. the electrical specs I was looking at were for an '000. Checking the '010 electrical specs says only a 12.5mhz chip max. While you should generally not overdrive a processor, it *should* work (I run my 25mhz XC '030 at 28mhz with no problems, but this chip was designed much later). I can't remember thier number, but Krueger Electronics sells most 680x0 series chips for next to nothing (ie: 8mhz 010 for $10). With a 30 day Money back guarantee to work. You should give them a call and see if they have any 12.5Mhz versions. Buy a couple. The heat-sink would be a good idea. Unless you go nuts, you probably won't burn the part, it will just quit working or act flakey at a higher clock speed that what it was designed for, and you can usually observe this in enough time to shut down. -- Michael M Morrison /| |\ mmm@reaper.chi.il.us <or> | | Cash, for Cache.. | | reaper!mmm@miroc.chi.il.us \| Hmm.. sounds fair. |/
stephane@grasp1.univ-lyon1.fr (Stephane Guillard) (05/17/91)
In article <mmm.1279@reaper.Chi.IL.US> mmm@reaper.Chi.IL.US (Michael Marvin Morrison) writes: >In article <1991May15.103225.30756@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: >>>>I would also suggest using a 16mhz 68010. >>> I was told by a man at Motorola in the MC680x0 conference that a 16 MHz 68010 >> >>Yes, the fastest 68010 available is a 12MHz part. However, the >>[...] >should generally not overdrive a processor, it *should* work (I run my 25mhz >XC '030 at 28mhz with no problems, but this chip was designed much later). >-- >Michael M Morrison /| |\ >mmm@reaper.chi.il.us <or> | | Cash, for Cache.. | | >reaper!mmm@miroc.chi.il.us \| Hmm.. sounds fair. |/ I run the 881 on my vanilla A2620 at 28Mhz although it's a 16Mhz part without any kinda problem ; many of my friends do the same on the same board (A2620). It seems to us, after a certain time spent in dealing with RotoMola components, that the '20, '30, '881 and '882 seem to be able to run at much higher freqs than what they're supposed to. We even managed to run a 16Mhz '20 at 40Mhz on a LUCAS board. Let me mention that furthermore, there ain't any kind of a temperature raise on the 881 between 14 and 28Mhz. Most benchs let us think that this combination is equivalent to a 68881 clocked at 25Mhz in terms of absolute performance, which ain't bad. But the 'plastic' parts (68000, 68010 and 68008) don't seem to be treatable that way. In terms of a 14Mhz hack, our first experience was long ago (5years), when we plugged a 16Mhz 68000 instead of the 68K on the A1000, running a 14Mhz clock from a 7474 in the 'metal shielded littel box' (you have 2 phases of 14Mhz in that box, and ONLY ONE seems to run, which to my opinion is a matter of S1/S2/S3/S4). So the hack was reduced to plugging a 16Mhz 68K w/pin 15 bent out, and a lead from this pin to a 7474 pin, and WORKED FINE with any software was available to us at this time. (for those who may ask, it was a CERAMIC packaged MC68000/16, from the french Thomson Semiconductors, and we never could find this part again). Unfortunately, we managed to burn this chip (we had only one) in another design, and had to try with a zillion plastic pkged 68000/8, and none worked. We then tried zillions 68010/12s, with no more success. Hope this helps ! PS : all of us also run our vanilia A2620's with 4 meg of 100nsDRAMS (the standard 2620 RAMS), and the jumper for 80ns/100ns selection on the 80ns position. This causes an average 10-15% performance increase again, BUT one of us had problems when his machine reached some temperature point, at which it caused random RAM read/write errors. The solution was to run the 2000 without it's cover, but this is not very good in terms of air flows between the boards. PPS : Another idea about the 2620 : one could take the 68851 (PMMU) away and replace it with an Apple-style PMMU cap (in the former 68020-based MacII, there was a socket for the 68851 (for A/UX), but there was no chip (in a $xxxyyy machine, it's a bit 'mesquin' like we say in french, and the chip was presented as a customer option :-))) Anyway, for the address bus to be translated from the 020 to the rest of the machine, there was a cap in the socket which intrinsics were... leads. This could be (to my opinion, never tried) used in 2620's instead of the 851 (I love it) fur suppressing the uncompressible 1 wait state which ALWAYS occurs on a 2620 because of the 851 (this is extracted from the Roto doc about 851 : even if the mapping is Identity (no mapping), there is 1 wait state, which is suppressed in the 030 with the integration of a subset of the 851 in it). This could lead to another 10% perf increase, I think. Problem : no more SetCPU FASTROM. Anyway : the RAM-release of KS2.0 does NOT need 851 to run in any machine (if it's still assembled at $20xxxx). I'm gonna try this in the next few days ; let me know if you're interested in the results. PPPS : Dave, I know all this AIN't respectfull to all your working hours, but I could not resist trying such things... I promise I'll sacrifice (with pleasure) a marketroid. -- \\\ Only Amiga | Stephane GUILLARD - GRASP INSA Lyon FRANCE \\\ makes it | Tel: +33 72438383 poste 5546 \\\/// possible! | eMail at : stephane@grasp1.univ-lyon1.fr \XX/
daveh@cbmvax.commodore.com (Dave Haynie) (05/23/91)
In article <billc.3326@cryo.UUCP> billc@cryo.UUCP (William J. Coldwell) writes: >In article <1991May16.093917.28260@rulway.LeidenUniv.nl> breemen@rulcvx.LeidenUniv.nl (E. van Breemen) writes: >>In article <billc.3304@cryo.UUCP> billc@cryo.UUCP (William J. Coldwell) writes: >>>manufacturer's item] when doing [CPU or DMA action]. This in-turn causes >>>a rush to the [name] board layout package for the changes necessary to make >>>the [your product] work with the latest rev, reducing the meager profit >>>margin." ;-) >>This is true if you are pushing your board to the edge of performance. You >>can do that by ignoring the specs of Commodore. It is to be expected that >>there are then some incompatibilities. 99.9% of the hacks done that violate Commodore specifications are done strictly out of designer laziness, not to "push your board to the edge". In fact, the only one I can think of who has ever pushed the limits for performance reasons is Bill Seymour, with the "PA". It has the option of talking to A2000 ROM at full speed, rather than dropping down to the normal 560ns cycle a 7.16MHz 68000 gives you. And that was a calculated risk, not some dumb hack. Most of the designs that push the edge, from the original Microbotics Hardframe (for awhile, the best and only full speed DMA driven hard disk controller) to the latest 50MHz '030 boards from GVP, are following C= specification. >There are situations that occur when other 3rd party products are mixed with >certain other 3rd party products produce unwanted results. Commodore specs >have a tendency to change when they jump from one producer of a specific part >to another. You have to understand the idea of specifications. A system specification can rarely have that much to do with reality. It's simply a ground rule. If every third party follows the ground rules, everything should work together. You might find any given Commodore system that seems to go many nanoseconds faster than the specification. That's not a problem, and not something any designer should ever count on. A specification generally says "it won't be any _slower_" or "you won't get any _less_ power", that kind of thing. These specifications are often derived from serious analysis of a system's worst case limits. You might get lucky avoiding the specifications sometimes, but you may not always get that lucky. Your luck could theoretically hold with every Commodore system you deal with, but fail with a 3rd party device, which gets closer to the worst case specification than Commodore does. Again, specs are so that everyone plays by the same rules. They don't tell you what's actually happening, they tell you what you need to know to make sure things always continue to happen \ properly. >I find it very unlikely that software would "accidently" send an FPU an MMU >command. Since the FPU is a peripheral processor, you won't have to worry >about even an FMOVE getting to it. The IEEE libs handle that very nicely >(thanks Dale!), as long as you don't try running a program specifically >compiled for 680x0/88x. As for a PFLUSH getting to an FPU, I find that >highly unlikely with the way the system is set up. Apparently not unlikely enough for the "FPU Logic Error" message from SetCPU to come up on several 68020 boards. We're not talking about 68000 peripherals here, but the 680x0 coprocessor interface. When you code an FMOVE or PFLUSH, that gets translated to a specific cpu space address. Part of that address contains the fact that the instruction is for a coprocessor, part tells which coprocessor, and part tells which command. If the 68020 board logic which generates the coprocessor chip select also responds to MMU commands (eg, it doesn't fully consider the coprocessor address), the FPU will respond to MMU instructions. I taught SetCPU to figure out when this was happening without crashing your system. I don't know if Enforcer or any of the other MMU tools are going to be as nice to such a setup. >> I can >>get the components for say $150. I have (I may hope so) a knowledge of >>electronics and the Amiga. It should therefore be possible to build what >>you want. >Don't know about building what I want... the stuff I'm working on is >finding the Amiga to be the bottleneck. If you're doing nothing but graphics manipulation, even an A3000 may appear to be a bottleneck. At some times, it's important to reconsider your algorithm rather than kick up to a faster an more expensive CPU. For instance, it doesn't make any sense to do image processing in Chip RAM. Most image processing works better in a packed pixel graphics model, and Fast RAM on an '030 system can be 10-100 times faster than Chip RAM, depending on what Chip RAM is trying to display. Other occupations, like number crunching, plain old word processing, hard disk speed, etc. has very little to do with the "Amiga" chips on an Amiga system. > William J. Coldwell PLink: CRYO I'm a 3-DPro, wouldn't you -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.
billsey@agora.UUCP (Bill Seymour) (05/24/91)
In article <21810@cbmvax.commodore.com>, Dave Haynie writes: > In article <billc.3326@cryo.UUCP> billc@cryo.UUCP (William J. Coldwell) writes: > >In article <1991May16.093917.28260@rulway.LeidenUniv.nl> breemen@rulcvx.LeidenUniv.nl (E. van Breemen) writes: > >>In article <billc.3304@cryo.UUCP> billc@cryo.UUCP (William J. Coldwell) writes: > > >>>manufacturer's item] when doing [CPU or DMA action]. This in-turn causes > >>>a rush to the [name] board layout package for the changes necessary to make > >>>the [your product] work with the latest rev, reducing the meager profit > >>>margin." ;-) > > >>This is true if you are pushing your board to the edge of performance. You > >>can do that by ignoring the specs of Commodore. It is to be expected that > >>there are then some incompatibilities. > > 99.9% of the hacks done that violate Commodore specifications are done strictly > out of designer laziness, not to "push your board to the edge". In fact, the > only one I can think of who has ever pushed the limits for performance reasons > is Bill Seymour, with the "PA". It has the option of talking to A2000 ROM at > full speed, rather than dropping down to the normal 560ns cycle a 7.16MHz 68000 > gives you. And that was a calculated risk, not some dumb hack. Well, I'm afraid I can't take the credit here... That's actually Steve Fordice and Kelly MacArthur who did the Processor Accelerator design. I only provided technical support and such for them then... I can't remember who it was that thought of running the ROM at 14MHz, but it certainly made a difference! > -- > Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > "That's me in the corner, that's me in the spotlight" -R.E.M. -Bill Seymour nesbbx!billsey@agora.uucp or nesbbx!billsey@agora.rain.com ***** American People/Link Amiga Zone Hardware Specialist NES*BILL ***** Bejed, Inc. NES, Inc. NAG BBS NES BBX BBS Home Sometimes (503)281-8153 (503)246-9311 (503)656-7393 (503)640-9337 (503) 640-0842
billc@cryo.UUCP (William J. Coldwell) (05/28/91)
In article <21810@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article <billc.3326@cryo.UUCP> billc@cryo.UUCP (William J. Coldwell) writes: >>In article <1991May16.093917.28260@rulway.LeidenUniv.nl> breemen@rulcvx.LeidenUniv.nl (E. van Breemen) writes: >>>In article <billc.3304@cryo.UUCP> billc@cryo.UUCP (William J. Coldwell) writes: > >>>>manufacturer's item] when doing [CPU or DMA action]. This in-turn causes >>>>a rush to the [name] board layout package for the changes necessary to make >>>>the [your product] work with the latest rev, reducing the meager profit >>>>margin." ;-) > >>>This is true if you are pushing your board to the edge of performance. You >>>can do that by ignoring the specs of Commodore. It is to be expected that >>>there are then some incompatibilities. >99.9% of the hacks done that violate Commodore specifications are done strictly >out of designer laziness, not to "push your board to the edge". In fact, the >only one I can think of who has ever pushed the limits for performance reasons >is Bill Seymour, with the "PA". It has the option of talking to A2000 ROM at >full speed, rather than dropping down to the normal 560ns cycle a 7.16MHz 68000 >gives you. And that was a calculated risk, not some dumb hack. [stuff deleted] Kelly McArthur and Steve Fordyce are responsible for the PA. Bill did the great job of laying out most of the boards for all of the revisions. I did the software for it (so don't blame me, it's a hardware problem...;-)). >>There are situations that occur when other 3rd party products are mixed with >>certain other 3rd party products produce unwanted results. Commodore specs >>have a tendency to change when they jump from one producer of a specific part >>to another. > >You have to understand the idea of specifications. A system specification can >rarely have that much to do with reality. It's simply a ground rule. If every >third party follows the ground rules, everything should work together. [more specification specifics deleted] >>I find it very unlikely that software would "accidently" send an FPU an MMU >>command. Since the FPU is a peripheral processor, you won't have to worry ^^^^^^^^^^ [stuff deleted] >Apparently not unlikely enough for the "FPU Logic Error" message from SetCPU >to come up on several 68020 boards. We're not talking about 68000 peripherals >here, but the 680x0 coprocessor interface. I was ;-). [0x0/88x FPU vs. MMU deleted] >>> I can >>>get the components for say $150. I have (I may hope so) a knowledge of >>>electronics and the Amiga. It should therefore be possible to build what >>>you want. > >>Don't know about building what I want... the stuff I'm working on is >>finding the Amiga to be the bottleneck. > >If you're doing nothing but graphics manipulation, even an A3000 may appear >to be a bottleneck. At some times, it's important to reconsider your >algorithm rather than kick up to a faster an more expensive CPU. You can never have enough CPU power. BillC's law: The faster the CPU you have, the more you will try to do with it simultaneously - making your total productivity only increase marginally versus exponentially. ;-) The A3000 is not necessarily the bottleneck, and makes a great platform to improve upon. Unfortunantly, there are more 2000's out there, so this setup is for the 2000. Take an '040 w/32bit SRAM/DRAM memory, add a 32bit SCSI chip, and throw in a couple ESCC serial ports, and a PI/T just to round things off. Now take a ZorroII Framebuffer/grabber/genlock with a 32bit processor/mathchip and VRAM/DRAM combo and slap all of this into your common A2000. Being 16bit causes 1 bottleneck, the custom chips cause the other. Changing an algorythm or 100 will not improve this "problem", it's just something that has to be lived with. The solution would be to make a Zorro3 graphics board and SCSI board, and to slap in a PP&S 040, but finances and market don't point that way :-(. So, my statement stands, the Amiga _in this case_ is the bottleneck (a necessary one though). > For instance, >it doesn't make any sense to do image processing in Chip RAM. Most image >processing works better in a packed pixel graphics model, and Fast RAM on an >'030 system can be 10-100 times faster than Chip RAM, depending on what Chip >RAM is trying to display. Doesn't matter, we DISPLAY_OFF (if the user wants) so that the CPU gets the maximum gas mileage. ;-) > Other occupations, like number crunching, plain >old word processing, hard disk speed, etc. has very little to do with the ^^^^^^^^^^^^^^^ >"Amiga" chips on an Amiga system. I (respectfully) disagree. Put up a 16 color HIRES|LACE and max overscan, and watch your disk performance drop. Shut it off, and watch it increase. >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" -- William J. Coldwell PLink: CRYO I'm a 3-DPro, wouldn't you Amiga Attitude Adjuster BIX: wjcoldwell like to be a 3-DPro2 ? Cryogenic Software UUCP:billc@cryo 3-D PROFESSIONAL 2.0 #define STD_DSCLMR "The above opinions are mine. You can't have them."