crash@ckctpa.UUCP (Frank J. Edwards) (10/08/90)
I'm not sure where the problem with this is, but the MSDOS-compatibility
programs don't like my 3000. I presume its due to CPU timing loops which
are being thrown off by the '030. Does anyone know of fixes/patches/etc
to either CrossDos or MSH that would fix the problem?
Thanks much; I need to be able to xfer files with my office and I *DON'T*
want to use a MessyDOS machine at all if I don't have to...
-----
Frank J. Edwards ComputerKnowledge Corp
Phone: (813) 786-3675 (214) 385-9700 / (800) 227-9700
An A3000 with 16M of SCRAM and 2M of CHIP memory... Glorious!!!
-- Mejil@cs.iastate.edu (James Lathrop) (10/09/90)
ls MSH:
dir MSH:
copy MSH:*.* to sys:temp all
work fine. Another problem is that messyfmt hangs the 3000, so you have
to format your disks on an MS/DOS machine.
-- Jimrhialto@cs.kun.nl (Olaf Seibert) (10/10/90)
In article <08Oct90.151432.944@ckctpa.UUCP> crash@ckctpa.UUCP (Frank J. Edwards) writes: >I'm not sure where the problem with this is, but the MSDOS-compatibility >programs don't like my 3000. I presume its due to CPU timing loops which >are being thrown off by the '030. Does anyone know of fixes/patches/etc >to either CrossDos or MSH that would fix the problem? I can't speak for CrossDOS, only for MSH since I wrote it. There are certainly no timing loops in MSH. In fact, there is no timing in MSH at all. (There is only a case of please-start-the-dma-as-soon-after-an- index-interrupt, and onviously the faster this goes the better). The problem might be that MSH uses some disk custom registers directly (though as little as possible) instead of through trackdisk.device. Furthermore it only supports 1.3-type packets, though I don't think this should really matter. It also installs disk index and disk block interrupt handlers though a not-really documented way. If you find out what the problem is, please let me know. >Frank J. Edwards ComputerKnowledge Corp -- Olaf 'Rhialto' Seibert rhialto@cs.kun.nl How can you be so stupid if you're identical to me? -Robert Silverberg -- Olaf 'Rhialto' Seibert rhialto@cs.kun.nl How can you be so stupid if you're identical to me? -Robert Silverberg
zerkle@iris.ucdavis.edu (Dan Zerkle) (10/11/90)
In article <08Oct90.151432.944@ckctpa.UUCP> crash@ckctpa.UUCP (Frank J. Edwards) writes: >I'm not sure where the problem with this is, but the MSDOS-compatibility >programs don't like my 3000. I presume its due to CPU timing loops which >are being thrown off by the '030. Does anyone know of fixes/patches/etc >to either CrossDos or MSH that would fix the problem? I have been able to get MSH to read but not write (or format). I also got one very nasty crash when unarchiving a .zip file with PKAZIP to the hard drive. It did it in the middle of a write, so the hard drive was corrupted. Any hints on how to write much appreciated! Dan Zerkle zerkle@iris.ucdavis.edu (916) 754-0240 Amiga... Because life is too short for boring computers.
rhialto@cs.kun.nl (Olaf Seibert) (10/12/90)
In article <7811@ucdavis.ucdavis.edu> zerkle@iris.ucdavis.edu (Dan Zerkle) writes: >In article <08Oct90.151432.944@ckctpa.UUCP> crash@ckctpa.UUCP (Frank J. Edwards) writes: >>[MSH does not work on a 3000] > >I have been able to get MSH to read but not write (or format). I think that the messydisk.device indefinitely waits for an index interrupt. The way these things are installed is not really documented, as far as I know, except by suggestive names in a structure. What usually is the problem when messydisk can't write, is that the IndexIntCode doesn't get called for some reason. (Usually these are hardware problems, so not my problem ;-) The ~~~ marked part is what is questionable. But if it can read, the block interrupt works, so why doesn't the index interrupt work? Specifically, what I do is the following: (file devio.c excerpted) /*- * $Id: devio.c,v 1.30 90/06/04 23:18:52 Rhialto Rel $ -*/ struct DiskResource *DRResource;/* Argh! A global variable! */ void *CiaBResource; /* And yet another! */ _SafeEnableICR: move.l _CiaBResource,a6 move.b 4+1(sp),d0 jsr _LVOSetICR(a6) ; clear pending interrupt move.b 4+1(sp),d0 or.b #$80,d0 ; then enable it jsr _LVOAbleICR(a6) rts ;;;; ; ; Disk index interrupt code. ; is_Data (A1) is the value to stuff into the DSKLEN register. ; A0 points to the custom chips already. ; It then enables the disk block interrupt and disables the ; index interrupt. _IndexIntCode: ; movem.l A2-A4/D2-D7,-(sp) move.w #dskdmaoff,Dsklen(a0) move.w a1,Dsklen(a0) move.w a1,Dsklen(a0) ; this enables the DMA move.w #intf_setclr|intf_dskblk,Intena(a0) move.l _CiaBResource,a6 move.b #ciaicrf_flg,d0 jsr _LVOAbleICR(a6) ; disable index interrupt ; movem.l (sp)+,A2-A4/D2-D7 rts ;;;; ; ; Disk DMA finished interrupt code. ; (a1) is the task to Signal, 4(a1) is the signal mask to use. ; Disables the disk block finished interrupt. _DskBlkIntCode: move.w #dskdmaoff,Dsklen(a0) ; disable disk DMA move.w #intf_dskblk,Intena(a0) ; disable the interrupt move.w #intf_dskblk,Intreq(a0) ; clear 'diskblock finished' flag move.l 4(a1),d0 ; signal mask move.l (a1),a1 ; task to signal jsr _LVOSignal(a6) rts struct { struct Task *task; ulong signal; } tasksig; tasksig.task = FindTask(NULL); tasksig.signal = 1L << unit->mu_DmaSignal; (this is done once on the initialisation of the device's unit:) unit->mu_DRUnit.dru_Index.is_Node.ln_Pri = 32; /* high pri for index int */ unit->mu_DRUnit.dru_Index.is_Code = IndexIntCode; unit->mu_DRUnit.dru_DiscBlock.is_Code = DskBlkIntCode; unit->mu_DRUnit.dru_Index.is_Data = (APTR) ((WLEN >> 1)|DSKDMAEN| dskwrite); unit->mu_DRUnit.dru_DiscBlock.is_Data = (APTR) &tasksig; /* Clear signal bit */ SetSignal(0L, tasksig.signal); /* Allocate drive and install index and block interrupts */ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GetDrive(&unit->mu_DRUnit); /* Select correct drive and side */ /* Set up disk parameters */ /* Set up disk buffer address */ /* Enable disk DMA */ /* Enable disk index interrupt to start the whole thing. */ SafeEnableICR((int) CIAICRF_FLG); Wait(tasksig.signal); FreeDrive(); void * GetDrive(drunit) register struct DiskResourceUnit *drunit; { Basically just GetUnit(drunit); Note no AllocUnit() is done, because trackdisk already has done this so we fail if we try. } void FreeDrive() { GiveUnit(); } > Dan Zerkle zerkle@iris.ucdavis.edu (916) 754-0240 -- Olaf 'Rhialto' Seibert rhialto@cs.kun.nl How can you be so stupid if you're identical to me? -Robert Silverberg -- Olaf 'Rhialto' Seibert rhialto@cs.kun.nl How can you be so stupid if you're identical to me? -Robert Silverberg
jms@tardis.Tymnet.COM (Joe Smith) (10/13/90)
In article <08Oct90.151432.944@ckctpa.UUCP> crash@ckctpa.UUCP (Frank J. Edwards) writes: >I'm not sure where the problem with this is, but the MSDOS-compatibility >programs don't like my 3000. I presume its due to CPU timing loops which >are being thrown off by the '030. Does anyone know of fixes/patches/etc >to either CrossDos or MSH that would fix the problem? Dos-2-Dos version 2.0 (1987) does not work on an A3000. It hangs when it tries to access the disk (both internal and external 3.5 and external 5.25). Extras:PCUtil/PCFormat does not work on an A3000 with 5.25 disk, even when booted up with AmigaDOS-1.3. It turns DF2's motor on and hangs with: "Verifying Track 26", "Tracks Remaining -2". CrossDOS 4.00a (July 10, 1990) works correctly on an A3000. The package now comes with the "2.0 compatible" sticker. I had to purchase CrossDOS when all the other programs failed me, it works great. -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C41 | BIX: smithjoe | 12 PDP-10s still running! "POPJ P," San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga 3000 speaks for me."
rbabel@babylon.UUCP (Ralph Babel) (10/15/90)
In article <1285@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: > Dos-2-Dos version 2.0 (1987) does not work on an A3000. Try V3.4. Ralph
joseph@valnet.UUCP (Joseph P. Hillenburg) (10/15/90)
jms@tardis.Tymnet.COM (Joe Smith) writes: > In article <08Oct90.151432.944@ckctpa.UUCP> crash@ckctpa.UUCP (Frank J. Edwar > >I'm not sure where the problem with this is, but the MSDOS-compatibility > >programs don't like my 3000. I presume its due to CPU timing loops which > >are being thrown off by the '030. Does anyone know of fixes/patches/etc > >to either CrossDos or MSH that would fix the problem? > > Dos-2-Dos version 2.0 (1987) does not work on an A3000. It hangs when it > tries to access the disk (both internal and external 3.5 and external 5.25). > > Extras:PCUtil/PCFormat does not work on an A3000 with 5.25 disk, even when > booted up with AmigaDOS-1.3. It turns DF2's motor on and hangs with: > "Verifying Track 26", "Tracks Remaining -2". > > CrossDOS 4.00a (July 10, 1990) works correctly on an A3000. The package > now comes with the "2.0 compatible" sticker. > > I had to purchase CrossDOS when all the other programs failed me, it works > great. > -- > Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.co > BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms > PO Box 49019, MS-C41 | BIX: smithjoe | 12 PDP-10s still running! "POPJ P," > San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga 3000 speaks for me." So when the hell are we going to see LapLink/Amiga? I'd really like to use that, considerinng it'd blow away Dos-2-Dos. (And Mac-2-Dos if it had the right tools) -Joseph Hillenburg UUCP: ...iuvax!valnet!joseph ARPA: valnet!joseph@iuvax.cs.indiana.edu INET: joseph@valnet.UUCP
rhialto@cs.kun.nl (Olaf Seibert) (10/15/90)
I tried to mail this to zerkle@iris.eecs.ucdavis.edu, but it failed. It is of more general interest anyway. You wrote about the devio.c source file: > I notice the recent (June) date on that. Is this a fix for the 3000, > or this this source just for other people to work on? I would love to > get MSH: fully working on the 3000, and you are the one to do it. This is what I am currently using. It looks reasonable to me, but is not documented, and I suspect it is this part that gives trouble on the 3000. I hope someone will tell me what the documented way to do this is. And that should then fix the problem. I hope. Maybe you could help somewhat by verifying my theory. If you have Xoper or some other task monitor program, you could try to write to a disk and then look at the status of MSH: and the messydisk.device. If the device remains waiting for a signal when it should be writing to the disk, this confirms my theory. If you can, please let me know the results with all details of such a test. > -Dan -- Olaf 'Rhialto' Seibert rhialto@cs.kun.nl How can you be so stupid if you're identical to me? -Robert Silverberg
stefanb@cip-s03.informatik.rwth-aachen.de (Stefan Becker) (10/16/90)
jms@tardis.Tymnet.COM (Joe Smith) writes: >In article <08Oct90.151432.944@ckctpa.UUCP> crash@ckctpa.UUCP (Frank J. Edwards) writes: >Dos-2-Dos version 2.0 (1987) does not work on an A3000. It hangs when it >tries to access the disk (both internal and external 3.5 and external 5.25). Dos-2-Dos V3.4 does work on an A3000 with WB2.0. Stefan Mail : Stefan Becker, Holsteinstrasse 9, W-5100 Aachen /// Only Phone : +49-241-505705 FIDO: 2:242/7.6 Germany /// Amiga makes Domain: stefanb@cip-s02.informatik.rwth-aachen.de \\\/// it possible.. Bang : ..mcvax!unido!rwthinf!cip-s02!stefanb \XX/ -->A3000/25<--
jesup@cbmvax.commodore.com (Randell Jesup) (11/08/90)
In article <2286@wn1.sci.kun.nl> rhialto@cs.kun.nl (Olaf Seibert) writes: >>>[MSH does not work on a 3000] >I think that the messydisk.device indefinitely waits for an index >interrupt. The way these things are installed is not really documented, >as far as I know, except by suggestive names in a structure. What >usually is the problem when messydisk can't write, is that the >IndexIntCode doesn't get called for some reason. (Usually these are >hardware problems, so not my problem ;-) The ~~~ marked part is what is >questionable. But if it can read, the block interrupt works, so why >doesn't the index interrupt work? Specifically, what I do is the >following: (file devio.c excerpted) I've verified at the hardware level that the index signal occurs (at least going into the 8520). I didn't see anything obviously wrong with your code, but nothing that affects such things should have changed. Note that timing may be different, for example from the 32-bit chip memory access, processor speed, etc. However, properly written code shouldn't care. Does it work on an A3000 under 1.3, or is it broken on both 1.3 and 2.0? -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
bruce@zuhause.MN.ORG (Bruce Albrecht) (11/09/90)
>In article <15704@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article <2286@wn1.sci.kun.nl> rhialto@cs.kun.nl (Olaf Seibert) writes: >>>>[MSH does not work on a 3000] > Does it work on an A3000 under 1.3, or is it broken on both 1.3 and >2.0? I have not been able to get MSH 1.30 to work on my 3000 under 1.3 and 2.0. In either case it tells me that the drive is unreadable. MSH 1.5 reads and writes on my 3000 under 1.3, and will read under 2.0, but hangs with the drive active when I try to write. CrossDOS works fine on 2.0 (haven't installed it on 1.3). Although the CrossDOS documentation doesn't indicate that you can do this, I appended the CrossDOS mountlist to the devs:MountList, and used the system Mount command to mount the CrossDOS device (which I renamed to A:). -- bruce@zuhause.mn.org
ST00482@auvm.auvm.edu (11/09/90)
Sorry to pop in on this thread without reading it before, so excuse me if I repeat something said before. MSH runs fine on my 3000. All I did was copy the mountlist, handler , and filesystem to the proper places. No problems. dan.
jil@cs.iastate.edu (James Lathrop) (11/10/90)
ST00482@auvm.auvm.edu writes: >Sorry to pop in on this thread without reading it before, so excuse me if >I repeat something said before. >MSH runs fine on my 3000. All I did was copy the mountlist, handler , and >filesystem to the proper places. No problems. >dan. What version of the operating system are you using? I cannot write without hanging the disk. I cannot 'cd' to MSH: or messyfmt drive 0. Any help on detailed information about your system would be helpful.\ Thanks, jil@atanasoff.cs.iastate.edu (jim)
jdutka@wpi.WPI.EDU (John Dutka) (11/10/90)
In article <jil.658179449@judy.cs.iastate.edu> jil@cs.iastate.edu (James Lathrop) writes: >What version of the operating system are you using? I cannot write >without hanging the disk. I cannot 'cd' to MSH: or messyfmt drive 0. Boot up in 1.3 and use MSH then. It only works for me on my KS V2.01 machine that way... -- | husc6!m2c!wpi!jdutka | "Hey, baby - wanna do some HEAT TRANSFER? | | jdutka@wpi.wpi.edu | Heh, heh, heh!" | | John Dutka, Jr. | -Mechanical Engineers On The Prowl | | jdutka%wpi.wpi.edu%mitvma.bitnet __________________________________________| -- | husc6!m2c!wpi!jdutka | "Hey, baby - wanna do some HEAT TRANSFER? | | jdutka@wpi.wpi.edu | Heh, heh, heh!" | | John Dutka, Jr. | -Mechanical Engineers On The Prowl |
haeb@ibmpcug.co.uk (Harry Broomhall) (11/11/90)
In article <15704@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: > In article <2286@wn1.sci.kun.nl> rhialto@cs.kun.nl (Olaf Seibert) writes: > >>>[MSH does not work on a 3000] > [stuff deleted] > > I didn't see anything obviously wrong with your code, but nothing that > affects such things should have changed. Note that timing may be different, > for example from the 32-bit chip memory access, processor speed, etc. However, > properly written code shouldn't care. > > Does it work on an A3000 under 1.3, or is it broken on both 1.3 and > 2.0? > I have tried this on our 3000. It works fine using 1.3, but fails on any write on 2.01 (CBM UK don't seem to have 2.02 yet). When I say on any write 'Delete' doesn't work either. Typical results are anywhere from hang to fireworks! Regards, Harry. -- Automatic Disclaimer: The views expressed above are those of the author alone and may not represent the views of the IBM PC User Group. --