breemen@rulcvx.LeidenUniv.nl (E. van Breemen) (06/20/91)
Leiden, The Netherlands, Wed Jun 19 20:07:10 1991 Today we finished our home-build 68020/68881 accelerator board for the Amiga 500. It's a 14.3 MHz synchronous system, the successor of our 68000 14.3 MHz hack. It's also possible to switch back to the old 68000. Lot's of fun for just $125! Everything worked fine (thanks Dave for your advice) the first time we plugged it in. All software that should work with a '020 works 100%. However, we encountered two problems: Problem I SetCPU V1.6 locks up the machine completely. Maybe this is caused when SetCPU executes a MMU instruction. Our board only responds to FPU instructions, because it decodes the FCx lines and A13 through A19. The '020 probably never receives a *DSACKx and will wait forever... Has anyone encountered this problem? Are there official guidelines that solve this kind of problems? Problem II The other problem occurs when booting a Promigos harddisk. This hd starts up, but after a few startup-sequence commands, it crashes (guru 4). Since all other software works great, we suspect the hd-device driver software to cause the problem. The Promigos harddisk is build around a 5527 OMTI controller. We like to know if anyone else out there uses a Promigos harddisk or another OMTI controlled harddisk with a '020 accelerator without problems. All hints are very welcome, please e-mail! Thanks in advance. Greetings, Raymond Hoving en Erwin van Breemen.
daveh@cbmvax.commodore.com (Dave Haynie) (06/27/91)
In article <1991Jun19.192747.6888@rulway.LeidenUniv.nl> breemen@rulcvx.LeidenUniv.nl (E. van Breemen) writes: >Problem I >SetCPU V1.6 locks up the machine completely. Maybe this is >caused when SetCPU executes a MMU instruction. Our board >only responds to FPU instructions, because it decodes the >FCx lines and A13 through A19. The '020 probably >never receives a *DSACKx and will wait forever... >Has anyone encountered this problem? Are there official >guidelines that solve this kind of problems? That shouldn't be a problem, because SetCPU is clever about the way it asks for an MMU. It runs a supervisor mode MMU instruction which maps as a valid user-mode FPU instruction. If the MMU is present, the code takes a privilige violation. If the MMU isn't there and the FPU is quiet, the code takes an F-line exception (all coprocessor space codes are F-line). If the FPU responds as an MMU, no exception is taken. I don't think you have to do anything special to get the F-line to happen in the absence of the MMU. For the missing FPU, you need to decode FPU space and generate a bus error to get an F-line exception, but the FPU is a slave coprocessor, while MMUs are master coprocessors and generally take care of everything themselves. I never built one without the MMU, so I'm a little unclear on that part of the coprocessor protocol. >Problem II >The other problem occurs when booting a Promigos harddisk. >This hd starts up, but after a few startup-sequence commands, >it crashes (guru 4). Since all other software works great, >we suspect the hd-device driver software to cause the problem. If this is a DMA-driven hard disk controller, you may have some marginal timing in your bus arbitration logic, but in general, bus arbitration mess ups result in hanging, not crashing. The most common result of hardware related memory corruption is the level 3 and 4 exceptions, which can result in a DMA system if one device gets on the bus before the current master gives it up. On the other hand, if you're dealing with a programmed I/O hard disk, I would suspect the software before anything else. Most driver code these days is tight coded assembly code, they have been having "speed wars" in the hard disk business. That's a bit more prone to errors and 680x0 family compatibility problems than the C or M2 used for many application programs. Alternately, you may have some 68000 bus timing disagreement between your board and the disk controller hardware. You might be marginally off the 68000 timings, or they may be counting on observed behavior of a particular 68000 production run (eg, what their development system looked like on the 'scope), rather than the spec sheet. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "This is my mistake. Let me make it good." -R.E.M.
breemen@rulcvx.LeidenUniv.nl (E. van Breemen) (06/27/91)
In article <22708@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article <1991Jun19.192747.6888@rulway.LeidenUniv.nl> breemen@rulcvx.LeidenUniv.nl (E. van Breemen) writes: > >everything themselves. I never built one without the MMU, so I'm a little >unclear on that part of the coprocessor protocol. We have decoded the FPU completely. The problem is that if you address an non existing MMU, the M68020 will wait for DSACK forever (the FPU won't respond to it) and the machine 'hangs'. > >If this is a DMA-driven hard disk controller, you may have some marginal >timing in your bus arbitration logic, but in general, bus arbitration mess Our board works just fine with an A590 harddrive, so DMA is not the problem. > >On the other hand, if you're dealing with a programmed I/O hard disk, I would >suspect the software before anything else. Most driver code these days is We have been able to patch the driver software by adding some nop's and everything works just fine. >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > "This is my mistake. Let me make it good." -R.E.M. Erwin van Breemen and Raymond Hoving.
daveh@cbmvax.commodore.com (Dave Haynie) (06/27/91)
In article <1991Jun27.084032.28883@rulway.LeidenUniv.nl> breemen@rulcvx.LeidenUniv.nl (E. van Breemen) writes: >In article <22708@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>In article <1991Jun19.192747.6888@rulway.LeidenUniv.nl> breemen@rulcvx.LeidenUniv.nl (E. van Breemen) writes: >>everything themselves. I never built one without the MMU, so I'm a little >>unclear on that part of the coprocessor protocol. >We have decoded the FPU completely. The problem is that if you address an non >existing MMU, the M68020 will wait for DSACK forever (the FPU won't respond to >it) and the machine 'hangs'. But if there's no MMU (or other coprocessor in any particular coprocessor slot), you're supposed to get an F-line exception for that instruction, rather than an infinite wait for a non-existant device. I'm pretty sure SetCPU works just fine in this respect for CSA and Ronin/Imtronics 68020 boards. Wiping a fine layer of dust off of my 68020 book, I find that you need to generate a bus error for any coprocessor access cycle that doesn't match with an existing coprocessor. In other words, when you see a coprocessor 0 cycle (for MMU), you should be generating a BERR*, which will then cause the 68020 to take an F-line exception. Done thusly, everything becomes shiny and clear. >We have been able to patch the driver software by adding some nop's and >everything works just fine. Oh, a software timing problem. One of my favorite kinds of bugs. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "This is my mistake. Let me make it good." -R.E.M.