[comp.sys.amiga.hardware] Speed of HardFrame/2000 and Quantum Q105S

clemon@lemsys.UUCP (Craig Lemon) (11/28/90)

	This has been something that's been bugging me for a long time
now....   In the near past I have heard people with low-cost type HD
controllers (even for the 500) giving performances of around 500K/sec
(KBytes), even when used with lower cost drives (ie. Seagate).  Some
people with better controllers on stock 2000s have given speeds of
900K/sec.  (ie. HardFrame/2000 and Quantum Drive).  I have a REV 4.2 B2000
with a HardFrame/2000 and Q105S and since the day I installed it I've
gotten the following performance :

--
DiskPreformance - V3.0 - 03/21/89

Testing drive dh0: with big files (harddisk mode)

File create/delete:     create 12 files/sec, delete 40 files/sec
Directory scan:         102 entries/sec
Seek/read test:         114 seek/reads per second

r/w speed:      buf  1024 bytes, rd 104509 byte/sec, wr  47880 byte/sec
r/w speed:      buf  8192 bytes, rd 204268 byte/sec, wr 122401 byte/sec
r/w speed:      buf 32768 bytes, rd 227951 byte/sec, wr 140434 byte/sec
--

	What is wrong with this picture?  Just now (as I write this article),
the performance with small files (floppy mode) has dropped to 65 K/sec read 
and 17 K/sec writes.  I got no documentation with my drive and I am using 
whatever defaults were set by RDPrep.  I have a
capacity of 102MB so I lost some space somewhere, but I'm not worried
about that right now.  Could my 64KB read ahead cache be disabled?  (I
also heard people mentioning that the Amiga never uses the cache.  Is this
true?)  What about SCSI termination?  Hardframe/2000 ROMS?  If needed my
full sys.config is :

B2000 REV 4.2
KS 1.2
WB 1.3.2
A2088 Bridgecard (ancient model)
2x2052 memory (4MB total)
68010
Hardframe/2000 (obviously)
Quantum Q105S
Miniscribe 30MB (BRIDGECARD)  with some controller

	I thought that it was possible that the Bridgecard was having some
effect (ie. eating cycles for the bus or something) but I've run the test
without the Bridgecard installed and it still gives these numbers.  I
believe I even tried it without the memory.  This is what RDPrep says the
settings are for my Rigid Block setup :

Existing Partitions on this disk. 
block 27, Name "DH0" 
 TableSize : 16 
 SizeBlock : 128 
 SecOrg : 0 
 Surfaces : 1 
 SectorPerBlock : 1 
 BlocksPerTrack : 201 
 Reserved : 2 
 PreAloc : 0 
 Interleave : 0 
 LowCyl : 1 
 HighCyl : 1018 
 NumBufers : 5 
 BufMemType : 5 
 MaxTransfer : 131072 
 Mask : 0x0fe
 BotPri : 3 
 DosType : "DOS^A"

	What about my MaxTransfer setting?  Could this be the culprit? 
I've left it at default as well.  I haven't tried playing with it because
I haven't got a backup of this drive and I don't want to accidently do
something or encounter a power out at the worst possible time or something
like that.  (BTW, I use addbuffers dh0: 30 in my startup).  One thing I do
notice is that when I access a very large file (ie. copying Maker from
DvideoIII, about 500K, and copying it to RAM: or something, disk access
consists of about 3-5 very short bursts about 0.75-1.0 seconds apart.  If I
could line these bursts up into one big burst, then I'd be happy.

	What about the 68010?  I can't see any effect that it would have. 
I don't autoboot from my drive (KS 1.2 until 2.01 is released) so that
explains my bootpri.


	While I have you, one more Hardframe guru question.  If I set my
bootpri as high as it will go to the hardframe, will I still be able to
boot from floppy if one is inserted.  This may sound stupid but I have
heard of controllers that won't let you unless you disable it.

--
 Craig Lemon - Kitchener, Ontario. Amiga B2000/10--2400 bps--AmigaUUCP 1.03D
 clemon@lemsys.UUCP   or   lemsys!clemon@xenitec.on.ca
 ....!{uunet}!watmath!xenitec!lemsys!clemon

jma@beach.cis.ufl.edu (John 'Vlad' Adams) (11/28/90)

That mount list entry is PRETTY strange.
SizeBlock 128?  Also, it's using the 1 surface let the SCSI figure
it out option.  If you can find the surfaces/cylinders/blockspertrack/
etc etc etc and put it it, there won't be any lag time for translation
(at least from what I've heard FOAF :)  I only have the info for a
Quantum ProDrive 40S, else I'd post it.  Of course, my advice
is to get a Kronos!  :)
--
John  M.  Adams   --**--   Professional Student on the eight-year plan!     ///
Internet:   jma@beach.cis.ufl.edu   -or-   vladimir@maple.circa.ufl.edu    ///
"We'll always be together, together in electric dreams" Moroder & Oakey \\V//
Sysop of The Beachside.   FIDOnet 1:3612/557.   904-492-2305  (Florida)  \X/

rcj2@cbnewsd.att.com (ray.c.jender) (11/28/90)

	Ummm, I thought a unique feature of the Microbotics Hardframe
	was that it did not need a Mountlist.....An I missing
	something here?

lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/29/90)

In <1990Nov28.152054.20769@cbnewsd.att.com>, rcj2@cbnewsd.att.com (ray.c.jender) writes:
>	Ummm, I thought a unique feature of the Microbotics Hardframe
>	was that it did not need a Mountlist.....An I missing
>	something here?

It doesn't _need_ a mountlist, but rdprepx can generate the equivalent of a
mountlist for you so that you can (a) see what it's doing, and (b) use the
generated file to make changes to the parameters.

-larry

--
The only things to survive a nuclear war will be cockroaches and IBM PCs.
+-----------------------------------------------------------------------+ 
|   //   Larry Phillips                                                 |
| \X/    lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips |
|        COMPUSERVE: 76703,4322  -or-  76703.4322@compuserve.com        |
+-----------------------------------------------------------------------+

lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/29/90)

In <3989.659757130@lemsys.UUCP>, clemon@lemsys.UUCP (Craig Lemon) writes:

>KS 1.2
>WB 1.3.2

This is not a good idea, in general. Mixing releases can lead to all sorts of
subtle problems.

>This is what RDPrep says the
>settings are for my Rigid Block setup :
>
>Existing Partitions on this disk. 
>block 27, Name "DH0" 
> TableSize : 16 
> SizeBlock : 128
> SecOrg : 0 
> Surfaces : 1 
> SectorPerBlock : 1 
> BlocksPerTrack : 201 
> Reserved : 2 
> PreAloc : 0 
> Interleave : 0 
> LowCyl : 1 
> HighCyl : 1018 
> NumBufers : 5 

Good idea here would be to increase the number of buffers, at least a little.

> BufMemType : 5 
> MaxTransfer : 131072 

Unless Microbotics has changed their hardware, this value is just a little
high. The most you should have here is 130560 (128K-512 bytes). This limitation
is because of the limitations in the SCSI chip and the DMA controller.

> Mask : 0x0fe

This is most likely to be the biggest factor in your lack of speed. Tha mask
value is used to determine where host adapter is allowed to use DMA, and where
it has to use programmed IO. With the value set as you show it here, the
HardFrame will only DMA into even addreses between $00 and $fe. _ALL_ accesses
to or from FAST memory, or to CHIP memory above $fe, will be done using
programmed IO.

The proper value here is 0xfffffe for a 2000, which says that the host adapter
may DMA to any even address in the natural addressing range.

> BotPri : 3 
> DosType : "DOS^A"
>
>	What about my MaxTransfer setting?  Could this be the culprit? 
>I've left it at default as well.

The rdprep program has gone through several revisions. One of the revisions may
have changed this value to 130560. At any rate, it should be reduced to this
value.

>  I haven't tried playing with it because
>I haven't got a backup of this drive and I don't want to accidently do
>something or encounter a power out at the worst possible time or something
>like that.

Do yourself a favour. Make a backup, then play with the figures. Changing
MaxTransfer and Mask will not destroy your data, but any time you are playing
around with drive stuff like this, a small mistake could cause problems.

-larry

--
The only things to survive a nuclear war will be cockroaches and IBM PCs.
+-----------------------------------------------------------------------+ 
|   //   Larry Phillips                                                 |
| \X/    lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips |
|        COMPUSERVE: 76703,4322  -or-  76703.4322@compuserve.com        |
+-----------------------------------------------------------------------+

cs472119@umbc5.umbc.edu (cs472119) (11/29/90)

Interleave that sucker, now!  I don't know about maxtransfer, but the short
pulses you see when loading a large file are caused by the computer
having to wait for disk latency.  

Say it reads from the first sector, but the controller can't keep up with
the drive to read the sector immediately following that one, so it waits
until the disk spins around again to get to that next sector.

If you interleave by say 1, consecutive sectors will be seperated from
eachother by sectors.  If you were to strecth out a disk with 8 sectors,
it might look like this:

   1 ! 5 ! 2 ! 6 ! 3 ! 7 ! 4 ! 8

   Read  Read    Read    Read
       ^      ^        ^      ^
      lag    lag      lag    lag

instead of this:

   1 ! 2 ! 3 ! 4 ! 5 ! 6 ! 7 ! 8

 Read   don't want...don't want..
      ^                         :
     lag                        :
                                :
.....Read    don't want.....
          ^                :
         lag               :


   This change will require you to reformat your Hard drive, and to choose
the interleave.  Be sure to explore the MAXtransfer thing first.

Hope this helped.
-Larry

blgardne@javelin.es.com (Blaine Gardner) (11/29/90)

clemon@lemsys.UUCP (Craig Lemon) writes:

[Tales of high speeds with cheap hardware deleted]

[The bottom line on a Hardframe/Quantum 105]
>r/w speed:      buf 32768 bytes, rd 227951 byte/sec, wr 140434 byte/sec

You should be seeing numbers a LOT higher than this. With a CDC Wren III
I was getting about 600-700 KB/sec (measured with DiskSpeed, it's a lot
more accurate and consistant than anything else out there). With a
Quantum 105 it's about 750-850 KB/sec. This is with a Hardframe and the
A2620 card, for a 68010 the numbers will be a little lower.

First guess is that the interleave on the drive is set to something
other than 1:1. The only way to change this is to back up the drive, and
run the low-level format again.

Second guess is fragmentation, it can easily cut your speed in half.

-- 
Blaine Gardner @ Evans & Sutherland  580 Arapeen Drive, SLC, Utah 84108
blgardne@esunix.UUCP                       BIX: blaine_g
{decwrl, utah-cs}!esunix!blgardne          PLink: BlaineG
DoD #0046                          My other motorcycle is a Quadracer.

blgardne@javelin.es.com (Blaine Gardner) (11/29/90)

jma@beach.cis.ufl.edu (John 'Vlad' Adams) writes:

>  Also, it's using the 1 surface let the SCSI figure
>it out option.  If you can find the surfaces/cylinders/blockspertrack/
>etc etc etc and put it it, there won't be any lag time for translation

Since SCSI only knows blocks, not drive geometry, it makes no difference
at all how many heads and cylinders you use, as long as the total is
correct. Quantum probably knows better than anyone what the ideal
numbers are for their drives, and the 1 head/bazillion cylinders is what
the drive reports.
-- 
Blaine Gardner @ Evans & Sutherland  580 Arapeen Drive, SLC, Utah 84108
blgardne@esunix.UUCP                       BIX: blaine_g
{decwrl, utah-cs}!esunix!blgardne          PLink: BlaineG
DoD #0046                          My other motorcycle is a Quadracer.

blgardne@javelin.es.com (Blaine Gardner) (11/29/90)

clemon@lemsys.UUCP (Craig Lemon) writes:
>This is what RDPrep says the
>settings are for my Rigid Block setup :

Ok, I took a closer look at your mount list, and found a few odd things
(my entries are below yours):

> SizeBlock : 128 
BytesperBlock = 512

Howcome the half sized data blocks? This will slow you down some.

> MaxTransfer : 131072 
MaxTransfer = 130560

You'll be a little safer to drop this down to 130560 to prevent possible
problems.

> Mask : 0x0fe
Mask = 0xfffffe

This looks like you are restricing DMA into a tiny little bit of Chip
RAM. No wonder things are slow! If you fix this, things will be a LOT
faster.


Here's what the latest version of RDPrep reports for my Q105. There's a
lot of difference between yours & mine, so I'd guess your running an old
version. The new RDPrep with the graphic interface is well worth the
upgrade fee.

/* RigidDiskBlock. */
QUANTUM LP105S 5100393102.3 :   disk = HardFrame.device
                Unit = 0
                BytesperBlock = 512
                Cylinders = 2097
                Heads = 1
                BlocksPerTrack = 98
                CylinderBlocks = 98
                RDBlow = 0 ; RDBhi = 195
                MinCyl = 2 ; MaxCyl = 2096
                Interleave = 1
                HiLun = TRUE
                HiID = TRUE
                HiDrive = TRUE
                Reselect = FALSE
#
/* Partition. */
DH0:    device = HardFrame.device
                Unit = 0
                Flags = 0x1
                FileSystem = Quantum0:devs/FastFileSystem
                StackSize = 4096
                Surfaces = 1
                BlockSize = 512
                BlocksPerTrack = 98
                Reserved = 2
                Interleave = 0
                LowCyl = 2 ; HighCyl = 1049
                PreAlloc = 0
                Buffers = 100
                BufMemType = 1
                DOSType = 0x444f5301
                MaxTransfer = 130560
                Mask = 0xfffffe
                GlobVec = -1
                Mount = 1
                /*! Bootable = 1 */
                /*! ReadOnly = FALSE */
                BootPri = 1
                Priority = 10

-- 
Blaine Gardner @ Evans & Sutherland  580 Arapeen Drive, SLC, Utah 84108
blgardne@esunix.UUCP                       BIX: blaine_g
{decwrl, utah-cs}!esunix!blgardne          PLink: BlaineG
DoD #0046                          My other motorcycle is a Quadracer.

swalton@solaria.csun.edu (Stephen Walton) (11/29/90)

In article <3989.659757130@lemsys.UUCP>, clemon@lemsys (Craig Lemon) writes:

>Hardframe/2000 (obviously)
>Quantum Q105S

I have such a setup--well, I have a Q80S here.  Diskspeed is right up there.
Craig, what version of RDBPrep do you have?  Updates are available from
Microbotics.

Your RDB looks  a bit strange.  In particular, MaxTransfer on my HardFrame/
Quantum combo is 130560.  You *should* be able  to change that safely
without reformatting, but back up anyway.

>(BTW, I use addbuffers dh0: 30 in my startup).

30 buffers isn't much for such a large drive.  I use 1000.

>	What about the 68010?  I can't see any effect that it would have. 

Nor  do I.

>	While I have you, one more Hardframe guru question.  If I set my
>bootpri as high as it will go to the hardframe, will I still be able to
>boot from floppy if one is inserted.

Yes.   The highest RDBPrep will let you set the HF bootpri to is 4, and
floppies come in at 5.  My son boots Faery Tale Adventure from floppy
all the time :-).
-------------------------------
Stephen Walton, Dept. of Physics & Astronomy, Cal State Univ. Northridge
   I am srw@csun.edu no matter WHAT the stupid From: line says!

daveh@cbmvax.commodore.com (Dave Haynie) (11/30/90)

In article <3989.659757130@lemsys.UUCP> clemon@lemsys.UUCP (Craig Lemon) writes:

>	What is wrong with this picture?  [...]

> Mask : 0x0fe

^^^^^^^

According to this, you're limiting direct DMA transfers to the word aligned
buffers in the first 256 bytes of Chip RAM.  So basically, you are never 
going to get DMA speed what that setup; even for transfers to Chip memory,
the disk will DMA into its private buffer and CPU copy to the destination.
What you really want here is a mask value of 0x00fffffe.

> Craig Lemon - Kitchener, Ontario. Amiga B2000/10--2400 bps--AmigaUUCP 1.03D

-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
		      ONLY 230 MILES TO GO

daveh@cbmvax.commodore.com (Dave Haynie) (11/30/90)

In article <1990Nov29.045524.4226@javelin.es.com> blgardne@javelin.es.com (Blaine Gardner) writes:
>clemon@lemsys.UUCP (Craig Lemon) writes:
>Ok, I took a closer look at your mount list, and found a few odd things
>(my entries are below yours):

>> SizeBlock : 128 
>BytesperBlock = 512

>Howcome the half sized data blocks? This will slow you down some.

I'm not sure about rigid disk blocks, but normal Amiga device environment
vectors store the block size in longword units, not bytes.  So that part of
the report is probably correct.  Parameters like BytesPerBlock get translated
into longwords before the environment is created, for sure.

The Mask value was the same thing I flagged as being bogus; that would result 
in every transfer being done by CPU copies after DMAs, about the slowest 
possible configuration.

>Blaine Gardner @ Evans & Sutherland  580 Arapeen Drive, SLC, Utah 84108

-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
		      ONLY 230 MILES TO GO

dzenc@gnu.ai.mit.edu (Dan Zenchelsky) (11/30/90)

In article <2279@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
>In <3989.659757130@lemsys.UUCP>, clemon@lemsys.UUCP (Craig Lemon) writes:
>
>>KS 1.2
>>WB 1.3.2
>
>This is not a good idea, in general. Mixing releases can lead to all sorts of
>subtle problems.
>
>-larry
>
>|   //   Larry Phillips                                                 |

While I agree with you that, in general, mixing versions is a "Bad Thing," it 
is quite safe to mix KS 1.2, and WB 1.3.x.  In fact, the changes between
Kickstart 1.2 and 1.3 are so small, that Commodore refers to Kickstart 1.3
as Kickstart 1.2.1 in its technical documentation.

To quote from the _Native Developers Update 1.3_:

          VERSION:                                                
                                                                  
                  Kickstart version number is bumped to 34.4 .    
                                                                  
          FEATURES:                                               
                                                                  
                  V1.2.1  is an incremental kickstart release.  It
          is  designed  to  maintain V1.2 compatiblity throughout,
          while  adding  two  important  features to the operating
          system.   These  features are 1) autoboot from ROM-based
          expansion  devices and 2) a larger preferences structure
          for future expansion.

-Dan
--
 ___________________________________________________________________________
|  _______                         |________________________________________|
| ||    |o|     Dan Zenchelsky     |                                        |
| ||____| |                        |    Any sufficiently advanced bug is    |
| |  ___  |  dzenc@gnu.ai.mit.edu  |    indistinguishable from a feature.   |
| |_|___|_|                        |______________-- Rich Kulawiec__________|
|__________________________________|________________________________________|

clemon@lemsys.UUCP (Craig Lemon) (11/30/90)

In a message posted on 28 Nov 90 15:20:54 GMT,
rcj2@cbnewsd.att.com (ray.c.jender) wrote:
r>
r>
r>	Ummm, I thought a unique feature of the Microbotics Hardframe
r>	was that it did not need a Mountlist.....An I missing
r>	something here?

	This is my RigidDiskBlock mountlist.  The one that is read from
the disk at Bindrivers.  The HardFrame uses this list to automount the
drive.  It needs a mountlist, just not a devs:mountlist.  It's kept on the
disk.

--
 Craig Lemon - Kitchener, Ontario. Amiga B2000/10--2400 bps--AmigaUUCP 1.03D
 clemon@lemsys.UUCP   or   lemsys!clemon@xenitec.on.ca
 ....!{uunet}!watmath!xenitec!lemsys!clemon

clemon@lemsys.UUCP (Craig Lemon) (11/30/90)

In a message posted on 28 Nov 90 20:42:18 GMT,
cs472119@umbc5.umbc.edu (cs472119) wrote:
c>
c>Interleave that sucker, now!  I don't know about maxtransfer, but the short
c>pulses you see when loading a large file are caused by the computer
c>having to wait for disk latency.  

	I know about interleaving.  I always thought you didn't need to do
it on the Amiga (let alone the HardFrame).  The manual specified not to
interleave it because the controller could keep up with ANY drive.

c>   This change will require you to reformat your Hard drive, and to choose
c>the interleave.  Be sure to explore the MAXtransfer thing first.

	When I change any of those parameters, I have to "delete" the
partition and then "add" a partition.  Will all my data be intact after
this process?


c>Hope this helped.
c>-Larry

---
--
 Craig Lemon - Kitchener, Ontario. Amiga B2000/10--2400 bps--AmigaUUCP 1.03D
 clemon@lemsys.UUCP   or   lemsys!clemon@xenitec.on.ca
 ....!{uunet}!watmath!xenitec!lemsys!clemon

peterk@cbmger.UUCP (Peter Kittel GERMANY) (11/30/90)

In article <2279@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
>In <3989.659757130@lemsys.UUCP>, clemon@lemsys.UUCP (Craig Lemon) writes:
>
>>KS 1.2
>>WB 1.3.2
>
>This is not a good idea, in general. Mixing releases can lead to all sorts of
>subtle problems.

Sorry Larry, you're normally right, but not in this point. It was
officially stated by Commodore that you may mix KS 1.2/1.3 with WB 1.2/1.3
in every possible combination! The only disadvantage with KS 1.2 is the
loss of autoboot ability with a HD.

This was though an exception. It will NOT apply to KS/WB 2.0 mixing with
its predecessors, that's impossible.

-- 
Best regards, Dr. Peter Kittel  // E-Mail to  \\  Only my personal opinions... 
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk

johnhlee@hermod.cs.cornell.edu (John H. Lee) (12/01/90)

In article <4027.659945134@lemsys.UUCP> clemon@lemsys.UUCP (Craig Lemon) writes:
>	I know about interleaving.  I always thought you didn't need to do
>it on the Amiga (let alone the HardFrame).  The manual specified not to
>interleave it because the controller could keep up with ANY drive.

You're right.  The HardFrame is fast enough that you should leave it at 0.

>	When I change any of those parameters, I have to "delete" the
>partition and then "add" a partition.  Will all my data be intact after
>this process?

Yes.  If you make sure the partition start and end at the exact same place.
If all you change is the MaxTransfer or some parameter that doesn't relocate
the partition or change it's size, you shouldn't need to reformat.  When
I "retuned" my HardFrame after a month's use (changed the buffers and
MaxTransfer) I deleted the partition info, reentered it with the changes, and
rebooted--the changes took effect and no data was lost.  Of course, I *did*
backup my drive before, just in case.  As a matter of fact, I discovered that
I had goofed on the first partition's ending cylinder but everything was fine
after I fixed it and rebooted.

-------------------------------------------------------------------------------
The DiskDoctor threatens the crew!  Next time on AmigaDos: The Next Generation.
	John Lee		Internet: johnhlee@cs.cornell.edu
The above opinions of those of the user, and not of this machine.

jayward@eecs.cs.pdx.edu (Jay Ward) (12/01/90)

In article <600@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes:
>In article <2279@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
>
>Sorry Larry, you're normally right, but not in this point. It was
>officially stated by Commodore that you may mix KS 1.2/1.3 with WB 1.2/1.3
>in every possible combination! The only disadvantage with KS 1.2 is the
>loss of autoboot ability with a HD.
>

I believe that there is a problem in mixing the 1.3 printer.device with the 1.2
printer drivers.  I remember hearing (quite a long time ago) that this
particular mix-and-match combination would NOT work.  It seems that at least
one commercial program (DeluxePrint II) was released with this combo before
anyone even realized the problem.

>
>-- 
>Best regards, Dr. Peter Kittel  // E-Mail to  \\  Only my personal opinions... 
>Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk


----------------------------------------------------------------------------
Jay Ward --> jayward@eecs.cs.pdx.edu | if TrailBlazers > Opponents then      
                                     | 		TrailBlazerWins++
----------------------------------------------------------------------------

andy@cbmvax.commodore.com (Andy Finkel) (12/01/90)

In article <806@pdxgate.UUCP> jayward@eecs.UUCP (Jay Ward) writes:
>I believe that there is a problem in mixing the 1.3 printer.device with the 1.2
>printer drivers.  I remember hearing (quite a long time ago) that this
>particular mix-and-match combination would NOT work.  It seems that at least
>one commercial program (DeluxePrint II) was released with this combo before
>anyone even realized the problem.

In general, you could mix 1.2 and 1.3 printer device with printer drivers.
However, EA did a custom version of the 1.2 printer.device/drivers which
was not compatible with the directions we went in 1.3.

That was what was on the Deluxe Print disk, and they later switched to
standard 1.3 printer drivers, or so I've been told.

		andy
-- 
andy finkel		{uunet|rutgers|amiga}!cbmvax!andy
Commodore-Amiga, Inc.

"It is much easier to suggest solutions when you know nothing about the
 problem."

Any expressed opinions are mine; but feel free to share.
I disclaim all responsibilities, all shapes, all sizes, all colors.

clemon@lemsys.UUCP (Craig Lemon) (12/01/90)

In a message posted on 29 Nov 90 16:59:00 GMT,
daveh@cbmvax.commodore.com (Dave Haynie) wrote:
DH>In article <3989.659757130@lemsys.UUCP> clemon@lemsys.UUCP (Craig Lemon) writes:
DH>
DH>>	What is wrong with this picture?  [...]
DH>
DH>> Mask : 0x0fe
DH>
DH>^^^^^^^
DH>
DH>According to this, you're limiting direct DMA transfers to the word aligned
DH>buffers in the first 256 bytes of Chip RAM.  So basically, you are never 
DH>going to get DMA speed what that setup; even for transfers to Chip memory,
DH>the disk will DMA into its private buffer and CPU copy to the destination.
DH>What you really want here is a mask value of 0x00fffffe.
DH>
DH>> Craig Lemon - Kitchener, Ontario. Amiga B2000/10--2400 bps--AmigaUUCP 1.03D
DH>
DH>-- 
DH>Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
DH>   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
DH>		      ONLY 230 MILES TO GO

	OK.  I'm the process of sumarizing my thoughts of replies thus far
and responding to them in public.  I thought I'd better get this out
because I've seen many replies about just this in particular.  Snap
incorrectly copied my screen from RDPrep.  My mask is set correctly. 
Thanks for trying anyways.

--
 Craig Lemon - Kitchener, Ontario. Amiga B2000/10--2400 bps--AmigaUUCP 1.03D
 clemon@lemsys.UUCP   or   lemsys!clemon@xenitec.on.ca
 ....!{uunet}!watmath!xenitec!lemsys!clemon

lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/02/90)

In <600@cbmger.UUCP>, peterk@cbmger.UUCP (Peter Kittel GERMANY) writes:
>In article <2279@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
>>In <3989.659757130@lemsys.UUCP>, clemon@lemsys.UUCP (Craig Lemon) writes:
>>
>>>KS 1.2
>>>WB 1.3.2
>>
>>This is not a good idea, in general. Mixing releases can lead to all sorts of
>>subtle problems.
>
>Sorry Larry, you're normally right, but not in this point. It was
>officially stated by Commodore that you may mix KS 1.2/1.3 with WB 1.2/1.3
>in every possible combination! The only disadvantage with KS 1.2 is the
>loss of autoboot ability with a HD.
>
>This was though an exception. It will NOT apply to KS/WB 2.0 mixing with
>its predecessors, that's impossible.

I stand corrected, though if I were to run 1.2 KS and 1.3 WB, I would be
holding my breath most of the time, regardless of the assurances.  :-)

-larry

--
The only things to survive a nuclear war will be cockroaches and IBM PCs.
+-----------------------------------------------------------------------+ 
|   //   Larry Phillips                                                 |
| \X/    lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips |
|        COMPUSERVE: 76703,4322  -or-  76703.4322@compuserve.com        |
+-----------------------------------------------------------------------+