HDTenEightyP/NetNews huggingface dataset:
From: Rick_Michael_Cortese@cup.portal.com
Newsgroups: comp.sys.atari.8bit
Subject: Re: My ego VS UUE
Date: Wed, 30 Dec 92 13:37:48 PST
Organization: The Portal System (TM)

.BEGIN
*p!A$k=d"KE2d4dSIDKt<ZhK2kr=R]D"5j`
*p<S2&EHk7n;+juQtU.;807\F8kMX3WN&Q_
"i-Z0?tcQRTn]4oBGdIs")3FBKnX3=Qq.3k
YlULgaF],!K8"u`W._FsOT;&bp^i75L7j6.
TV@+5d%[?:n=uf_Oeefh!mo#]U;inhs2h"3
UW2KD@,eCMWF2Gk"%&OeB]N2:8HVVVSI>f9
;lKjk3iSd+TW+W=W<5PZ"%Aa\6Ce4X*r[8a
!!!@6!!&;b!!&;b!!!!!!!!!!!!&5`+21DK
EZc0tNW5t"V&0:3Kt(i!Bj%:*WM,"RWM>.L
WMP:KTVR;AV4jb/+%m`LBiq2KV4`O`K`u0n
K`e<JK`J*IL&\-KVBDP-+J>R)"0!A8!3)`I
s/DiK+J>Na=J]/tTH?fL+/=bqUWj+E9EVL@
Vl_(Y+01ACN?>(#!2(FCXjd]:)N>iJ+02Nj
ma)f1XZ.E'!U1]8XWP$3J18tUY,/:T4A5k(
+/A6HmN<iMr2h'=d/QZ=+<aD\r/L`Uia?-q
])q!o!!!!@
.END
50 X=0:A$=""
152 GET #4,A:X=X+1:IF A<>13 THEN A$(X,X)=CHR$
Newsgroups: comp.sys.atari.8bit
From: jjmcwill@mtu.edu (Jeff McWilliams)
Subject: Re: Hard Drive interface
Organization: Michigan Technological University
Date: Wed, 23 Dec 1992 10:17:19 GMT

No, I think you are thinking of SASI, both MIO and BB also support SASI.

Jeff McWilliams

-- 
Jeff McWilliams  jjmcwill@mtu.edu  EE Engineer --> Michigan Tech. 
Leaves Turning, falling, withering
Wind blowing, rustling, chilling
candlelight will soon be flickering
From: Chris_F_Chiesa@cup.portal.com
Newsgroups: comp.sys.atari.8bit
Subject: Re: My ego VS UUE
Date: Sat, 26 Dec 92 01:23:01 PST
Organization: The Portal System (TM)

Oops... sorry about that partial posting!  It's 4AM and I'm on an unfamil-
iar keyboard...

I was starting to say:

First, Rick, standard UUencode takes 3 bytes of 8-bit "original" data
(24 bits) and reorganizes it as 4 6-bit "encoded" quantities (also 24 bits).
Current computer architectures require an entire 8-bit byte to store any
less-than-8-bit quantity, hence a UUencoded file has essentially 4 bytes
for every 3 in the original: an "expansion factor" of 1.3333...., not 1.5.
Among other things, this reduces the advantage of your proposed base-85
technique from "a significant improvement over UUencode," to "just slightly
better," and since base-85 doesn't correspond exactly to a power of 2,
i.e. to a particular, fixed number of bits in the UUencoded values, your
encoding algorithm would of necessity be somewhat messier than UUencoding
which can be implemented just by moving bytes around: NO MATH is needed
for UUencoding.

Second, the use of 6 bits for UUencoded data values yields, of course,
64 different possible values.  As noted in previous articles in this 
thread, the values 0-31 would be control characters, some of the very 
values it is desired to avoid in an e-mailed file, so the UUencode algo-
rithm adds a "bias" value of 63 decimal, shifting the UUencoded values
to the range 63-127 decimal, representing ASCII characters "!" through
"~".  These are ALL "printable" characters, in ASCII anyway.  I don't
think it should be the encoding program's responsibility to deal with
ASCII-to-EBCDIC translation peculiarities; that is the responsibility
of file-exchange software: the ASCII-file-reading program on the EBCDIC
system, or the EBCDIC-file-reading program on the ASCII system.  These
exist and have been refined over the years to quite a high state...

Third, I think it would still be interesting to see a base-85 file-
encoder, at least as proof that it could be made to work.  I don't
expect it would make any significant impact on the near-universal
use of the existing UUencode scheme, since UUencode is firmly estab-
lished and the base-85 encoder would be more complex, and therefore
somewhat slower, than an equivalent (whatever THAT means) UUencoder,
for only about a 8% improvement in file size.  Of course, there will
be that minority (possibly including me myself) to whom even an 8% 
improvement will be worth a loss of speed, and such people ought 
to have the choice.
 
Chris Chiesa
  Chris_F_Chiesa@cup.portal.com
Newsgroups: comp.sys.atari.8bit
From: jjmcwill@mtu.edu (Jeff McWilliams)
Subject: Looking for source code from Analog
Organization: Michigan Technological University
Date: Wed, 30 Dec 1992 06:54:33 GMT

There is a program in the January 1989 issue of Analog called Edit Magic,
which is for XL/XE machines.  It copies the ROM OS into RAM, and then
patches the EDITOR to do all sorts of neat things.  Their version
is obviously incompatible with things like SpartaDOS 3.2d, and
TurboBASIC XL, and whatever else.  But I am working on a hard ware 
hack that will place a STATIC RAM chip where the OS ROM normally resides.
That way, you can copy the ROM OS to the SRAM chip, make modifications to
the OS, and then disable the Write line to the RAM chip.  From then on,
it will act just like the Original ROM OS did.  What's more, you can still
access the normal RAM underneath the OS, just like you always did, 
so that it's compatible with SpartaDOS 3.2d, TurboBASIC XL, etc.
I would like to get the source code to this Edit Magic program
so that I can modify it and use it as a perfect example of the kinds
of changes to the operating system you can make.

This hack will appear in an upcoming installment of Moonlight workship,
after I've debugged the circuit and done a thorough schematic design 
and write-up etc.  While I am at it, I would like to petition readers
to submit any other OS modifications that could be done to the SRAM-OS,
like high-speed DISK SIO routines, remapped 1200XL function keys,
hidden machine language monitor/debuggers, or whatever else.
One could even replace the diagnostic code with say a printer configuration
program that you call up with a special key sequence, where you could
choose FONT, pitch, spacing, and whatever else before printing a document.
Without divulging too much more about the upgrade, ( I do want you folks to
read the column!!), you might be able to have about 16K of program space
hiding in there as well, actually, if you keep the ROM OS enabled, you'll
have 32K of program space!... anyway, so you could put some really
nifty things into this upgrade.  Ideas anyone?  Gentlemen, 
start your assemblers!  (varoom!)
       
Jeff  McWilliams

-- 
Jeff McWilliams  jjmcwill@mtu.edu  EE Engineer --> Michigan Tech. 
Leaves Turning, falling, withering
Wind blowing, rustling, chilling
candlelight will soon be flickering
Newsgroups: comp.sys.atari.8bit,alt.games.video.classic
From: fontana@iguana.cis.ohio-state.edu (Mark Fontana)
Subject: Atari 2600/7800 HW/SW at Odd Lots
Organization: The Ohio State University Dept. of Computer and Info. Science
Distribution: usa
Date: Wed, 23 Dec 1992 20:36:45 GMT


I was buying misc. Christmas items at Odd Lots the other day, and
noticed they had a whole shelf of Atari 2600 units (the new style)
for $19 each, and some 7800 consoles for around $25.  There were also
several large bins of Atari cartridges- all in shrink-wrapped boxes.
The 2600 cartridges were $1 each, and the 7800 cartridges were $3.
There were many classic games, too, like Pole Position and Dig Dug.

*Disclaimer*  I don't work for Odd Lots and don't know anybody who does.
Just passing along a tip in case anyone's been trying to find these items.
For anyone in Columbus OH, the particular Odd Lots store was the location
on Olentangy River Road.

Mark Fontana
From: Rick_Michael_Cortese@cup.portal.com
Newsgroups: comp.sys.atari.8bit
Subject: Re: My ego VS UUE
Date: Wed, 30 Dec 92 15:58:16 PST
Organization: The Portal System (TM)
  <72636@cup.portal.com>

Man! Did those get trashed! Not sure if it was me, Portal, or my ST! Portal
aborted after about 5 tries with Xmodem U/L on the 1st file & somewhere<?>
stuff got appended to files. It doesn't seem to be me because when I view the
files, they come out normally. When I read message #13 on my ST, the thing 
hangs & I have to manually disconnect. If anyone has a real problem with the
files, let me know & I'll see what I can do. Otherwise, just remove the
garbage from the end of the files.
Newsgroups: comp.sys.atari.8bit
From: bbs@neb (BBS System 801-572-4969)
Subject: EasyStore .dat files
Organization: Nebula - Public Access Unix/bbs SLC Ut, USA
Date: Tue, 29 Dec 1992 18:52:42 GMT

I'm looking for data files for usage with the magazine database program
EasyStore.  I am primarily interested in indexes for the magazines:
Antic, Analog and AIM. 
 
I have been unable to contact the company that originally marketed this
package.
James King aka Kamaro Kid at uplherc.upl.com!neb!bbs!1fa
-----
Posted by BBS User: James King
Mail Path: uplherc.upl.com!neb!bbs!1fa
-- 
Nebula - A Public Access Unix System/bbs - (801)-572-4969 v.32/v.42(bis)/PEP
Newsgroups: comp.sys.atari.8bit
From: bbs@neb (BBS System 801-572-4969)
Subject: Re: SPARTADOS
Organization: Nebula - Public Access Unix/bbs SLC Ut, USA
Date: Wed, 23 Dec 1992 02:05:08 GMT

Jeff, just for your (and everyone elses) information, the Supra hard
drive interface was purchased by Bob Klaas of K-products (owner of BBS
Express Pro!) here in Salt Lake City, Utah (where I live).
 
It is being sold for around $120.00, and will very soon feature options
identical to that of the MIO and Black Box - as an add on card has been
developed to allow for menu configuration, high density disk drives,
etc.. Look for the upgrade within a month or two.
 
For further info on this HD interface, call the Repair Shop BBS at
801-967-8738 or call Bob Klaas voice at 801-967-7400 or 801-966-1697.
-----
Posted by BBS User: James King
Mail Path: uplherc.upl.com!neb!bbs!1fa
-- 
Nebula - A Public Access Unix System/bbs - (801)-572-4969 v.32/v.42(bis)/PEP
Newsgroups: comp.sys.atari.8bit
From: root@uunet!scarrow (Superuser)
Subject: Re: Kermit-65 source code
Organization: TCI
Date: Sun, 03 Jan 1993 00:36:50 GMT

In article <C07sBJ.Juv@merk.com> winston@merk.com (Winston Smith) writes:

> "Just when you thought it was safe to go back in the water...."
>
>     Well, the KERMIT-65 saga continues.  I was able to locate a 6502
> cross-assembler written in C.  It is able to generate an ASCII text
> assembler listing, both with program source, or just with assembled byte
> values given in ASCII text.  This program is able to run on a "Kernighan
> and Ritchie" C compiler.  Unfortunately, the program that accompanies the
> assembler, that is supposed to turn the text characters into binary
> code, is written in ANSI C, and the file calls make the K&R C compiler I
> am using do strange things.  <* ARG! *>  Why can't this assembler generate
> UUENCODE output as an option?  Why do people --DO-- things like this?  Why
> do they add non-compatible ANSI C programs to programs that are K&R C
> compliant?  This is driving me crazy!

I am very interested in obtaining such a cross-assembler, where did you get it?
Is it commercial (I assume not, because you've got source) or PD? It really
shouldn't be that hard to get it to write out in any format you want.

I am primarily interested in running it under Unix and converting it to write
Atari executables directly. The reason is that I kind of like having access
to my hard drive, 80 columns, and a fast CPU. I do have a ANSI compiler, but
I am really interested in the assembler itself.

If you could put it on BART or mail it to me (assuming it is PD), I would
greatly appreciate it.

PS: The reason I am posting this message instead of sending mail is that for
some reason my mailer software didn't send correctly. It seems to work OK
most of the time, however.
-- 
+------------------------------+----------------------------------------------+
| Have we been here before?... | E-Mail: ...!uunet!scarrow!kirk               |
| - Or are we yet to come?     +----------------------------------------------+
|                              | DISCLAIMER: My thoghts and views are my own, |
|                Dr. Who, 1975 |             I subscribe to free will.        |
+------------------------------+----------------------------------------------+
Newsgroups: comp.sys.atari.8bit
From: bmarcum@world.std.com (Bill Marcum)
Subject: Re: Atari 800
Organization: The World Public Access UNIX, Brookline, MA
Date: Wed, 30 Dec 1992 07:55:50 GMT

Unfortunately, on the 65XE all the chips are soldered, which makes it
difficult to swap chips.  You might just look for a used 800XL at a
thrift shop or flea market.

Newsgroups: comp.sys.atari.8bit
From: winston@merk.com (Winston Smith)
Subject: Re: Kermit-65 source code
Keywords: KERMIT, UNARC, huge, VT100, Speedscript, Catch-22
Organization: Technology Partners, Inc.
Date: Tue, 22 Dec 1992 14:52:56 GMT


I performed an FTP request (called a "get" I believe?) of the KERMIT-65
source code.  The good news is that the file was delivered to the
requesting UNIX machine.  The bad news is that the file was delivered in
an "ARC" format as one large file of over eight hundred double-density
sectors!  What the heck am I supposed to do with this?!??  Needless to say,
I gave it the old college try and downloaded it to my ATARI 8-BIT.  On my
ATARI 8-BIT I attempted to UNARC as much of it as I could.  Unfortunately,
the first thousand sectors or so contained mainly the KERMIT file transfer
protocol (which very few people use) and the command line parser.  I was
hoping to find information about the VT100 terminal emulator.  The file
contained some interesting code, such as sections to translate C64 VIC20
screen "poke" graphics character codes (Speedscript character type) into
ASCII.
  
     Needless to say, I am placed in a "Catch-22" situation.  The KERMIT-65
source files are --NOT-- in an ATARI 8-BIT format, but in some text format
too large to be contained on an ATARI 8-BIT drive.  I can not successfully
download this humongous file to an ATARI 8-BIT and then UNARC it.  Is there
some way that I can UNARC this behemoth on a UNIX system?  I know that UNIX
uses COMPRESS, TAR, and ZOO, but I do not believe that I have seen ARC on a
UNIX box before.  Most of this KERMIT source file contains extraneous
information, anyway.  The part that I am interested in, namely the VT100
terminal emulator, probably comprises a small part of the whole work,
however I do find the programming techniques employed very interesting.  I
just wish that there was some way to successfully examine the thing.  I
have often wondered why no further work had been done on KERMIT-65.  Now I
know why!  You need to own another computer with a hard drive just to hold
the source code!  :-(  Any help I can get UNARC-ing this program and
cutting it up into smaller pieces...  so that it will actually --FIT-- on
an ATARI 8BIT machine and --BE USABLE--, would be greatly appreciated.
Does anyone out there have any ideas how to solve this problem?  Thanks.
From: phbill@cyberden.sf.ca.us
Newsgroups: comp.sys.atari.8bit
Subject: Re: *** DOS NEEDED***
Date: Tue, 29 Dec 92 20:04:48 PST
Reply-To: phbill@cyberden.sf.ca.us
Organization: Indescribable Creations

Well... some REALLY good DOSes out there are:

MyDOS (4.53 is the latest version), which is almost 100% Atari DOS 2.0/
        2.5 compatible, and supports subdirectories, RAMdisks, high-cap-
        acity drives, etc.  I use it, and love it, and it's public domain
        (getting it to your Atari w/o a modem or disk drive in the 1st 
        place is a trick, but I'm sure some PD wherehouses and/or 8-bit
        stores that sell PD have it...)

SpartaDOS-X (version ??)  I don't have it, never've used it or even seen
        it.  It's cartridged based, not being made any more, MS-DOS-look-
        alike, commercial of course, and some 8-bit stores'll definitely
        have it.  Many people love this DOS.

SpartaDOS (v.3.2?)  It's a lot like the above SDX, but is disk-based, and
        is also commercial.  It's also widely used, although it has some
        quirks.  I've used it before.  I had no idea what I was doing, 
        and of course didn't like it because of that :).  

If you like MS-DOS style DOSes go for one of the Sparta's.  If you like
Atari DOS (vanilla-DOS) style DOSes (with menus), get MyDOS or any old
Atari DOS-type DOS, but the most widely used of this type of DOSes is of
course MyDOS.  (It's now PD, that's probably why.. also, since it's so 
used, many upgrades've been made, making it even more widely used, etc.)


So you have one way to go or another.

Also, for modems, there's the SX212 direct-connect (no interface 
required), made by Atari, probably still being made (as it has an RS232 
port, making it ST/IBM usable).  You can get SX-EXpress!, which is a 
disk-based terminal program for it for as little as $3 (it's PD) or as 
much as $10 (grr..I got it for that).

For terminal programs, some people go the Express! way, and others (like 
me! :)  ) the BobTerm way.  BobTerm is PD, and Express! also comes on 
cart. >>>I THINK<<<, which would of course be commercial.  (Is there such 
a thing as a PD cart!?... I mean, burning Eproms is just like copying 
disks, eh?  Just charge more for parts for the cart.  People charge $$ 
for disks on PD stuff..  Interesting concept....)  

Also there are terminals like DeTerm, which is pretty good (pull-down 
menu driven, but not graphical).  It can play breakout while doing xfers, 
etc.  

There's ANSI-Term (in beta, last I saw.  v0.3), which doesn't support 
color, runs in graphics mode (slow :(  ), but does its jon
job

oops...a call!
bye!
that's about it

           \
  /\  /    /\  / /  /
 /\/ /\  \/\/ / /  /    PhBill@Cyberden.SF.CA.US, or
/     /   \/ /  \  \    PhBill@Cyberden.UUCP
From: aa700@cleveland.Freenet.Edu (Michael Current)
Newsgroups: comp.sys.atari.8bit
Subject: Wish List (was: comp.sys.atari.8bit.archive)
Date: 21 Dec 1992 14:45:18 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: aa700@cleveland.Freenet.Edu (Michael Current)
NNTP-Posting-Host: hela.ins.cwru.edu


In a previous article, JJMCWILL@MTUS5.BITNET (Jeff McWilliams) says:

>technology.  Atari Classics prints a wish list in the magazine, so
>you can look there for more ideas, and here are a couple more of
>my own.  We don't need another word processor, unless it's something
>really special, maybe mixing the Bells and Whistles of Paperclip with
>the macro capability of Textpro version 5 and the 80 column output of
>Atariwriter 80 or Turboword 80.

I would LOVE to see a better word processor.  For the last 3.5 years I've
been using AtariWriter 80 on my 130XE system, first under MYDOS, then under
SpartaDOS X.  Nothing fancy, and a little buggy, but it works.  Well, this
month I was going to use AtariWriter 80 some on our older 800 system at
home, but I couldn't get it running so I booted up my old favorite that I
hadn't used for years, Letter Perfect (v.6).  Man, LP is a SOLID piece of
software, compared to AW80.  It almost made me feel I've been using the
wrong word processor for the last three years.  Batteries Included is long
gone, but LJK was around as recently as a year ago.  I would pay him Much
Money to update Letter Perfect to support:

- any DOS (especially MYDOS and SpartaDOS/SDX)

- run from hard disk or RAMdisk.

- the XEP80 (It already support the Bit-3 80-column board, so you'd think
this wouldn't be so hard.)

- both XE and Axlon-type banked memory for text buffer.

So if AC is taking suggestions for it's Wish List, there's one of mine.

-- 
         Michael Current, Cleveland Free-Net 8-bit Atari SIGOp
Carleton College, Northfield, MN, USA / UUCP: ...!umn-cs!ccnfld!currentm
      Internet: currentm@carleton.edu / Cleveland Free-Net: aa700
Organization: Computing Technology Services, Michigan Technological Univ.
Date: Wednesday, 23 Dec 1992 15:16:53 EST
From: Jeff McWilliams <JJMCWILL@MTUS5.BITNET>
Newsgroups: comp.sys.atari.8bit
Subject: Re: Atari 800

Roger,

POKEY I believe handles most of the SIO stuff, so I would suggest start
looking there.  you could probably even swap your 65XE POKEY with the
Atari 800 one, assuming you want to roll up your sleeves and dig into your
800.  Another option would be to purchase a Transkey interface for your
65XE. This allows you to connect IBM type keyboards to your Atari 8 bit.
Then, it would simply be a matter of finding a keyboard that felt right
for you, making sure it works with the Transkey, and off you go!


Jeff McWilliams
From: Chris_F_Chiesa@cup.portal.com
Newsgroups: comp.sys.atari.8bit
Subject: Re: Need Action! help
Date: Fri,  1 Jan 93 19:19:49 PST
Organization: The Portal System (TM)
  <2PPiwB1w165w@cyberden.sf.ca.us> <C02B2w.2EC@world.std.com>

For what it's worth (and so I can brag a little :-) ) I recently did a 
little bit of programming on request for Bob Puff, and the code to which
I made modifications was 100% assembler...  

Chris Chiesa
  Chris_F_Chiesa@cup.portal.com
Newsgroups: comp.sys.atari.8bit
From: winston@merk.com (Winston Smith)
Subject: Re: Kermit-65 source code
Organization: Technology Partners, Inc.
Date: Mon, 28 Dec 1992 07:25:22 GMT


To All 6502 Programmers Out There,
  
     I have been examining the KERMIT-65 source code files that I FTP-ed
from the Atari Archive with a "get".  I don't own a MAC-65 6502 Assembler
cartridge, and some of the symbols used seem a bit strange.  For example,
what is the meaning of the pseudo-op ".SBTTL" ?  Another interesting
expression is "<byte>!<byte>" (...is that supposed to be a Logical NOT of
two bytes?).  Finally, in the KERMIT-65 "make" file, the "-v" flag is set.
Is there a version of the UNIX "as6502" cross-assembler utility that even
--SUPPORTS-- a "v" flag ?  What assembler was used to generate object code
from these sources, does anyone know ?  Thank you.
Organization: Computing Technology Services, Michigan Technological Univ.
Date: Wednesday, 23 Dec 1992 11:29:45 EST
From: Jeff McWilliams <JJMCWILL@MTUS5.BITNET>
Newsgroups: comp.sys.atari.8bit
Subject: Re: UnLZH??
 <1992Dec19.090253.7940@merk.com>
 <1992Dec23.080958.27621@magnus.acs.ohio-state.edu>


Ron,


This came up several months ago on here.  As a second hand source of
information on this, all I know is that Bob Puff didn't intend for UNLZH
to be passed around, it was a beta copy, and he was pretty ticked when he
heard about it.  If this is still the case, let's show some respect for the
current top 8 bit developer (leastways in my book) and not pass around
something he doesn't want passed around.

Jeff McWilliams
From: phbill@cyberden.sf.ca.us
Newsgroups: comp.sys.atari.8bit
Subject: Re: My ego VS UUE
Date: Wed, 23 Dec 92 00:38:55 PST
Reply-To: phbill@cyberden.sf.ca.us
Organization: Indescribable Creations

Hey rick...  hmm..  I killed the idea on AAcode (my version of 
uuen/decode)  I guess I just got bored.  ;)  anyways..  THE best 
uuen/decoder would be one that compresses first!  ooh.. that'd be nice...

my one complaint would be this:
        I have it easy ;)  .. the BBS I rec'v UseNet on has a built-in
        UUDecoding command, so I don't even need YAU (just YAUE for the
        occasional upload/post)...

but I supposed if one were to write something for (unix?) whatever the 
archives, you could have 3 "send" commands:

send  - send (uuencode if binary)
sendb - sned (uuencode no matter what)
sendx - send (x-encode)   (x? whatever...  whoever makes the program
        will have the honor of naming it! ;)  )

...     hmm..   have fun!
        btw, rick.. I'm no math major, and I'm half alseep, but that
        LOOKS like it might work...                     !?

           \
  /\  /    /\  / /  /
 /\/ /\  \/\/ / /  /    PhBill@Cyberden.SF.CA.US, or
/     /   \/ /  \  \    PhBill@Cyberden.UUCP
Organization: Computing Technology Services, Michigan Technological Univ.
Date: Wednesday, 23 Dec 1992 11:21:39 EST
From: Jeff McWilliams <JJMCWILL@MTUS5.BITNET>
Newsgroups: comp.sys.atari.8bit
Subject: Re: Kermit-65 source code
 <1gu5qqINN79a@usenet.INS.CWRU.Edu> <1gvcv3INNp04@usenet.INS.CWRU.Edu>
 <1992Dec22.145256 <sourada.725062825@vincent1.iastate.edu>

You could do it with a hard drive.. how big did you say it was?

Jeff McWilliams