Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: Oldsmobile_Mike on December 24, 2015, 09:52:28 PM
-
Everybody loves new toys, right? And just in time for Christmas. From a dear friend on the forums that I've gotten some other sweet hardware from in the past. ;)
I see I'll still need to do some config work, and testing on what the best 68060 library is (just using the first one I found off http://amiga.resource.cx/exp/tekmagic2060 right now). Maybe THoR's?
Guess I'll need to update all my datatypes to 68060 versions, also.
This board has modded ROM's that allow it to automount PFS/SFS partitions, too. I was worried about that but my PFS-formatted CF card popped right up. Had to do a little more work to get it to recognize my FAT95-formatted SD card, and for some reason it's still not wanting to recognize my CD-R drive, but hey. This is why we love our Amiga's, right? :D
-
MultiCX bombed out so I'm missing some of my functionality. I wonder if that utility isn't compatible with an '060, or if maybe it's just one of the settings I have selected in there. Hrm. Also gotta figure out how to turn Copyback on in SysInfo. "CPU" says it's on.
I may very well drink about six cups of coffee and stay up all night playing with this new toy. ;)
Edit - fixed MultiCX. Just needed to be run lower in the priority after some other stuff. ;)
-
So after some tweaking everything is working great with my new toy, with one exception:
The SCSI controller doesn't seem to handle diskchanges with my removable media (I have a CD drive and a card reader). If I boot with a disk in the drive I can issue diskchange commands from the shell and it works, otherwise nada. Ejecting a disk still shows the icon on the desktop, etc.
I found some helpful tips in this forum:
http://www.verycomputer.com/2_e456fbfee836cc4c_1.htm
http://www.verycomputer.com/2_350f7f35e98dc977_1.htm
For example that I had to change my CD drive to Device ID 6 to get it recognized.
I even found comments from a couple folks who seem to be having almost the exact same problem (only they're using ZIP disks):
sure
GLK> enough, a zip cartridge will not be visibly mounted unless it
GLK> is in the drive during the boot process.
GLK> (btw, booting is very fast compared to the g-force 040!!!!)
GLK> boot without a cartridge installed, insert it after the boot
GLK> sequence, and it doesn't mount. attempting to manually mount
GLK> it, results in an message that the drive is already mounted.
GLK> but where is its icon? this never happened with the g-force
GLK> 040.
This is a quirk of the 2060 and tekscsi2.device with ZIP drives, it
happened with my old Combo 030 too, that it didn't with your g-force
just means that you were lucky. However, as long as you always have
a ZIP disk in the drive, you can swap them in and out to your heart's
content, merely issuing a diskchange command in order to see the new
ZIP disk.
This is hardly the biggest deal in the world, but on the million-to-one chance does anyone have any ideas? Or does tekscsi2.device just not like disk changes? ;)
-
Addendum to the above. I found this review: https://groups.google.com/forum/#!topic/comp.sys.amiga.reviews/-trCW_Hdb-I
That says:
My Pioneer CD-ROM drive behaves strange when attached to the
G-FORCE SCSI controller (this is the reason why I kept the GVP HCD-II+
board in my A2000).
So it appears I'm just going to have to live with it. If I care that much, I'll throw a 2091 in there. ;)
-
Slapped a heatsink on the '060 and fine-tuned the libraries a bit more. SysSpeed gives a significantly more impressive number when rating the MIPS. ;)
I've noticed that ever since adding USB, my system scores a bit lower in these kind of tests. Obviously that's the price I pay for having a USB stack running in the background. Meh, I can live with that. ;)
-
A couple of comments: First, if you get the yellow warning from the 68040.library, it means exactly what it says: You're loading the 68040.library on a 68060 system - and this cannot work. You need to load the 68060.library instead. For that, use a newer SetPatch that is aware of the 68060. Or patch an existing SetPatch to load the 680x0.library, which will again load the *right* CPU library for you. Hint: There is an installation script for all that which keeps care of the correct libraries and SetPatch. Manual installation causes risks, and these are the side-effects you're seeing. I'm *not* shipping a "dummy" library as this is an ugly and non-scalable solution. Concerning removable media: RDBs do not belong on removable media. An RDB is a boot-time configuration option allowing the hostadapter to automount the device when bootstrapping for it. It is a bad solution for removable media - if the RDB is read at all, the hostadapter has to create a new mount entry every time a medium is inserted, and it will create side-effects like the ones you have observed. Thus, stick to a static mount list for ZIPs and remove the RDB from the ZIP disks. There is one particular example for a ZIP drive mount list in Os 3.9 that came along with the ZIP tools. This mount entry should work, though it may not fit to how you configured your ZIP, so probably some adjustment is needed to read *your* formatted ZIPs. The problem is here that AmigaOs has no means of "adjusting" an existing mount once a file system has been created for a media, so it's a bad idea to enforce that. Merry Christmas!
-
A couple of comments: First, if you get the yellow warning from the 68040.library, it means exactly what it says: You're loading the 68040.library on a 68060 system - and this cannot work. You need to load the 68060.library instead. For that, use a newer SetPatch that is aware of the 68060. Or patch an existing SetPatch to load the 680x0.library, which will again load the *right* CPU library for you. Hint: There is an installation script for all that which keeps care of the correct libraries and SetPatch. Manual installation causes risks, and these are the side-effects you're seeing. I'm *not* shipping a "dummy" library as this is an ugly and non-scalable solution. Concerning removable media: RDBs do not belong on removable media. An RDB is a boot-time configuration option allowing the hostadapter to automount the device when bootstrapping for it. It is a bad solution for removable media - if the RDB is read at all, the hostadapter has to create a new mount entry every time a medium is inserted, and it will create side-effects like the ones you have observed. Thus, stick to a static mount list for ZIPs and remove the RDB from the ZIP disks. There is one particular example for a ZIP drive mount list in Os 3.9 that came along with the ZIP tools. This mount entry should work, though it may not fit to how you configured your ZIP, so probably some adjustment is needed to read *your* formatted ZIPs. The problem is here that AmigaOs has no means of "adjusting" an existing mount once a file system has been created for a media, so it's a bad idea to enforce that. Merry Christmas!
I know, I've already got all your '060 libraries installed on there now. I was going from an '040 to an '060 and I just thought that requester was funny when I powered it up for the first time prior to changing the libs. Sorry, I have a weird sense of humor. ;)
I'm not sure I understand the second half of your comment - I'm not the one using ZIP disks, that quote was just one I found in another forum from 10 years ago, that seemed similar to the problem I'm having.
To be more specific, my problem is that tekscsi2.device isn't recognizing when I change CD's (or SD cards from my card reader). So for example: if I boot with a CD in the drive, the icon will show up on the desktop. If I eject the CD, the icon for that disk will stay on the desktop. If I stick another CD in the drive, I'll have to issue a Diskchange command from the shell to get the system to recognize that I've changed the disc. Same goes for my media card reader.
I didn't have any problems with gvpscsi.device on my older '040 card; it detected disc changes properly.
Anyhow, based on my google search results, it sounds a lot of people have issues with tekscsi2.device and removable media. I'm not going to worry a whole lot about it unless someone has any suggestions?
Oh - and thanks, as always, for your awesome libraries! :D
-
Imagine if there was just one "cpu patch library" instead of the current mess.
-
Imagine if there was just one "cpu patch library" instead of the current mess.
But wouldn't that just take all the fun out of tinkering? ;)
-
So I usually play a few levels of Christmas Lemmings every year, but this year I decided to try out my new '060 board with Doom, instead. ;)
https://www.youtube.com/watch?v=eMjZDGf9WNA
Maybe I should've recorded a level where I didn't get killed so fast though, haha. :lol:
-
You're going to love your new toy Mike!!! Half the fun is figuring it out and getting it set-up just how you want it. Don't you like the way you can zip around the workbench with the 060?
-
Fantastic (vintage) hardware there. As you've found, Thor's library works perfect here (Ralph Babel wrote one too, if you want to try it). You'll also want to check out MuFastZero if you haven't already.
Although the Z2 bus is rather slow, you'll get the full 3.5 MB/s writing to a Picasso IV, which is really an excellent combo with this accelerator.
I wish I could help with the SCSI issue. I used to burn CDs with mine using 2 PlexWriters, and don't recall experiencing the diskchange problem. There was a Guru ROM intended for the TekMagic, sadly it was never released.
I know this card has a "reputation", but I always found it to be really fast and stable. (On that note, just don't overclock it!) I had a Blizzard 2060 too--sold it, and kept the TekMagic.
-
Wasn't the FPU crippled by missing patcher for missing FPU instructions (AKA Cyberpatcher in P5 060 cards) or does Thor's library fix it? Otherwise Oxypatcher would be recommended.
I remember once when trying Quake it was really crawling - I had disabled the patcher by accident.
-
Doom looks a bit jerky Mike. I don't have Zorro II, but is it smoother when running in EHB mode?
Also, can you use SysSpeed and show us the mips rating? As you know, sysinfo is pretty useless as it doesn't understand the 060.
Congrats though, you have a truly wonderful setup. :)
-
Doom looks a bit jerky Mike. I don't have Zorro II, but is it smoother when running in EHB mode?
Also, can you use SysSpeed and show us the mips rating? As you know, sysinfo is pretty useless as it doesn't understand the 060.
Congrats though, you have a truly wonderful setup. :)
Thanks! :D
That's using one of the P96 modes on my GVP Spectrum. Obviously with full screen and all the detail settings cranked up to high, I think I'm hitting the limits of the Z II bus. But it's still a heck of a lot smoother than it was with my '040, and it loads like a scalded cat in comparison to that other board. ;)
Playing around with the HSMath libraries now, I'll have to retest once I'm able to get a registered copy of those. Gotta go visit the family today but just off-hand from memory, I think SysSpeed was reporting around 65 MIPS? With my '040 it was around 24. Zoom zoom! :)
-
320x240?
-
I had an internal and external CDRW with my setup until the 2060 died, never had a problem with disk changes!
More likely your up against the clock and memory with the Spectrum. Picasso IV is much smoother.
-
Imagine if there was just one "cpu patch library" instead of the current mess.
Now, why exactly should the 68040 support go into a 68060 library? Or vice versa? And waste RAM for something that is not needed? The "current mess" is quite simple: SetPatch detects the CPU present, and loads the correct CPU library to support the mess. The 68030.library for the 030, the 68040.library for the 040 and the 68060.library for the 060. Why is that a problem?
-
Playing around with the HSMath libraries now, I'll have to retest once I'm able to get a registered copy of those. Gotta go visit the family today but just off-hand from memory, I think SysSpeed was reporting around 65 MIPS? With my '040 it was around 24. Zoom zoom! :)
Don't waste your money on that. The Os 3.9 libraries are fully aware of the 68040 or 68060 and use the math support functions from the fpsp.resource the processor support libraries install if needed. I would be astonished if there is a serious program for which these libraries provide an advantage: Any heavy math software (if there ever was such a thing) used the FPU directly anyhow...
-
Wasn't the FPU crippled by missing patcher for missing FPU instructions (AKA Cyberpatcher in P5 060 cards) or does Thor's library fix it? Otherwise Oxypatcher would be recommended.
The 68060 FPU support is in the 68060.library, but emulation through the 68060.library has to go through processor traps. *If* full FPU speed is necessary, I would not recommend Oxypatcher. First of all, it does not support all FPU codes, and second of all, it does not patch all instructions correclty (as in: "it has bugs"). Neither is it maintained anymore. Go for MuRedox. Does the same thing, except that it can really deal with *all* FPU instructions - it has a "code generator" or "just in time compiler" on board which will generate the necessary "glue logic" on the fly, and will also build on top of the fpsp.resource the CPU support libraries install. Note however: All of these programs *patch* program code during execution. While this usually does only good, several copy protection schemes may want to take checksums over running code. *If* that is the case, a patch may keep the program from running correctly. Note that this goes for any program of this sort (Oxypatcher, Cyperpatcher, MuRedox), so some care should be taken. It is not advisable to keep such programs running continuously.
-
Wasn't the FPU crippled by missing patcher for missing FPU instructions (AKA Cyberpatcher in P5 060 cards) or does Thor's library fix it? Otherwise Oxypatcher would be recommended.
I remember once when trying Quake it was really crawling - I had disabled the patcher by accident.
Always used Thor's library here and haven't encountered those issues, along with MuRedox on rare occasion (usually old demos and whatnot--the program allows you view what (if anything) has been patched, a nice feature). The original library being broken might explain why Ralph wrote another one, but that's only speculation. (I just know the library the card shipped with wasn't Ralph's, but I can't recall the author.)
I don't have Zorro II, but is it smoother when running in EHB mode?
With a graphics card, Z2 won't hinder Doom or Quake at the low resolutions those games are playable at, fortunately.
-
The original library being broken might explain why Ralph wrote another one, but that's only speculation.
The original 68040.library shipped by CBM was/is based on an old version of Motorola's fpsp package for the 68040, and this old version had a couple of bugs. Plus, Mike Sinz did not handle *some* FPU traps he should have handled. This all got fixed both by Ralph, then later by me, and Heinz also supplied a 68040.library for Os 3.9.
As for CyberPatcher, I don't know of any bugs (but that doesn't mean anything, I never used it), though I heard that it only patches "most frequently used FPU instructions", unlike MuRedox, which covers the full set (by a JITter, a completely different approach).
Oxypatcher had issues with the FBDBcc instructions it did not handle correctly. There might be a couple of other issues I'm not aware of.
-
Wow! Awesome news Mike! :) Can't wait to compare performance and configs! Now to score me an RTG card! You're one up on me but I'll soon be settling the score!!!!! :lol:
Pirate Cat says "Yaaaarrrrrrrr! Welcme to the 060 Club Matey!"
(http://i.dailymail.co.uk/i/pix/2015/12/22/10/2F90776F00000578-3370093-image-a-10_1450778714544.jpg)
-
Also, can you use SysSpeed and show us the mips rating? As you know, sysinfo is pretty useless as it doesn't understand the 060.
Here ya go! Probably still not as optimized as it could be. First column is with the '060. Second column is with my previous '040. 3rd, 4th, and 5th columns are just some of the generic built-in modules.
MIPS rating seems to fluctuate between about 65.65 and 65.85, depending on how often I hit the button. ;) I probably could've inched it up another 1 MIPS or so if I shut down my USB stack and other junk I have running in the background, first.
Catching up on that beast A3000 over there in the last column, though! My most recent battle has been with trying to get Roadshow working, I really wish I had more time for this stuff. :(
-
On an unrelated note, I seem to have fixed the problem with the TekMagic not recognizing CD disk changes by toggling the setting for "SCSI Direct" in CacheCDFS prefs. Tested it a few times with a couple discs, working good so far.
Now to figure out how to do that for my removable FAT95 SD card, LOL. ;)