HDTenEightyP/NetNews huggingface dataset:
From: ab245@cleveland.Freenet.Edu (Sam Latonia)
Newsgroups: comp.sys.cbm
Subject: For Sale Commodore 10/6/92
Date: 6 Oct 1992 08:46:56 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: slc4.ins.cwru.edu


                 BRAND NEW & USED EQUIPMENT PRICE LIST  10/6/92

(1) COMMODORE C128 COMPUTER - NEW - NOT USED - WITH POWER SUPPLY

    $125 - WITH OWNERS MANUAL - TV ADAPTOR & CABLE & TUTORIAL/UTIL DISKS

(1) COMMODORE C128 COMPUTER - USED BUT LIKE NEW CONDITION - POWER SUPPLY

    $100 - WITH CMD JIFFYDOS INSTALLED WITH OWNERS MANUALS & DISKS

(1) COMMODORE C128 COMPUTER - USED BUT LIKE NEW CONDITION - POWER SUPPLY

    $75 - WITH OWNERS MANUAL - TUTORIAL & CPM DISK

(1) COMMODORE C64C COMPUTER BRAND NEW IN THE BOX - WITH POWER SUPPLY

    $100 - WITH OWNERS MANUAL AND SEALED GEO'S PACKAGE FROM COMMODORE

(1) COMMODORE C64C COMPUTER USED BUT IN LIKE NEW CONDITION POWER SUPPLY

    $75 - WITH OWNERS MANUAL & HINGED KEYBOARD COVER & NEW TENIX C64C CASE

(2) COMMODORE 1571 DSDD DISK DRIVE - BRAND NEW IN THE BOX

    $125 EACH - WITH SERIAL CABLE & UTILITY DISK

(1) COMMODORE/AMIGA 1084SD STEREO MONITOR - BRAND NEW IN THE BOX

    $240 WITH ALL CABLES & BOOKS - MADE BY TOSHIBA NOT MAGNAVOX!

(1) COMMODORE 1351 MOUSE NEW NOT USED WITH OWNERS MANUAL

    $35

(1) COMMODORE 1350 MOUSE NEW NOT USED WITH OWNERS MANUAL

    $30

(1) C.M.D. SWIFT LINK CARTRIDGE - WITH THE EXTRA $6 TECH MANUAL FOR $35

(2) C64 POWER SUPPLIES - USED BUT LIKE NEW CONDITION $20 EACH

(1) AVATEX 1200HC EXTERNAL RS232 MODEMS - USED BUT IN LIKE NEW CONDITION

    $35 EACH WITH BOOKS BOX & CABLE

(1) AVATEX 2400HC EXTERNAL RS232 MODEMS - USED BUT IN LIKE NEW CONDITION

    $75 -  WITH BOOKS BOX & CABLES

(2) PPI 2400SA EXTERNAL RS232 MODEMS NEW - NEVER USED

    $75 EACH - BOOKS - BOX & CABLES - FULL 1 YEAR WARRANTY

(2) OKIDATA OKITEL 9600 EXTERNAL RS232 MODEM - V.32 V.42 V.42BIS

    $250 EACH - WITH 5 FULL YEARS FACTORY WARRANTY - THROUGHPUT TO 38.4 BPS

**************************************************************************

SOFTWARE - ALL FACTORY PACKAGES WITH MANUALS AND INSTRUCTIONS

C128 BERKELEY GEOS WITH GEOS FONTPACK 1 $30

C128 FONT MASTER 128 $30

C128 WORD WRITER 128 $30

C64 CERTIFICATE MAKER $15

C64 CERTIFICATE LIBRARY VOLUME #1 $10

C64 TEST DRIVE GAME $10

C64 ARRAYS INC. PHONE CALL TERMINAL & BBS PROGRAM $10

C64 FLIGHT SIMULATOR II $5

C64 PRACTICALC 64 $5

C64 THE DISK SURGEON C64 PRO $5

C64 DI-SECTOR V3.0 $5

C64 ULTRABYTE DISK NIBBLER PRO C64 $5

C64 THE COMPUTER ARTIST/FRAME IT/SPRITE BUILDER $5

C64 SCREEN EDITOR C64 $5

C64 HOME MANAGER/WORD PROCESSOR/DATA MAGIC/CALCULATOR/MEMO PAD $5

C64 SEGA STAR TREK CARTRIDGE $5

C64 BEACH HEAD II U.S.M.C. GAME $5

C64 EASY SCRIPT/WORD PROCESSOR $5

ALL PRICES ARE ROCK SOLID- PLUS SHIPPING COST IF NEEDED:

 

If interested please reply in private e-mail, thank you...
From: emzx@vax5.cit.cornell.edu
Newsgroups: comp.sys.cbm
Subject: C-64 system sold
Date: 6 Oct 92 22:48:01 EDT
Distribution: comp
Organization: Cornell University

The following items:

C-64
1541
Excelerator Plus Disk Drive
Sanyo Color Monitor
Panasonic 9-pin printer
Printer Interface
Fast Load
all necessary cables

Have been sold.

Thank you for your interests.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Start strong, end strong, and look for opportunities in the middle."
                              -S. O'Nan

Sung J. Woo, Secretary of The International Gridlocker Society

emzx@CORNELLA.cit.cornell.edu
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Newsgroups: comp.sys.cbm
From: drudetb@infonode.ingr.com (Ted B. Drude)
Subject: Re: C-64 gives Out of Memory errors on power up - ideas?
Organization: Intergraph Corporation, Huntsville, AL.
Date: Mon, 5 Oct 1992 15:41:20 GMT

Just in case anyone has followed this thread from it's start,  I finally
got my old C-64 fixed. If you remember,  I was getting an "Out of Memory in
line 0 ?" error when I powered the system up. The ancient (1986) "Commodore
Diagnostician" chart that I had identified it as an indication of a bad
RAM chip.  I no idea as to how to further diagnose the problem, and
someone suggested it could also be a bad PLA.  

Having had some experience with bad PLAs before, I thought that was a good
place to start first, so I de-soldered it (wasn't in a socket of
course, ... Commodore is so cheap!), soldered in a new 28-pin socket, and 
swapped in a different, known-good PLA. But that did not solve the problem.  

So I went back to some POKEing and PEEKing around in low memory to find
where the Kernal RAMTAS routine had set the top of memory to (this
location is documented in the Programmer's Reference Guide).  Turned out
that it had set the top of memory to the byte right before the RAMTAS test
fails. The location was in the middle of screen memory (1424 dec.) and I also
noticed that about in the middle of the screen the same character (a
zero) was always displayed when I did a clear screen. 

So I wrote a BASIC routine to test that memory location,  by POKEing and
PEEking all values from 0-255 into it. (First I had to manually set the BASIC
pointers to get enough free RAM to write and run the program.) Turns
out bit 4 was always stuck low at 1424.  I re-wrote the BASIC program to
test all RAM from 1024-2048.  Bit 4 was also  bad at some other
locations.  So I unsoldered U23 (the bit 4 RAM chip) and replaced it 
with a new 4164 RAM chip (in a socket).  Voila!  Problem solved. 

Fortunately, only one bit was bad in a few memory locations.  If several
bits were bad throughout the memory map,  it could have been a little
harder to diagnose. I suppose I should have taken the "Commodore
Diagnostician"'s word for it and tested the RAM to begin with.  Live and 
learn. Anyway, if someone else has a similar problem,  this may be of
help.

- Ted Drude
Newsgroups: comp.sys.cbm
From: zembrod@informatik.uni-freiburg.de (Philip Zembrod)
Subject: Re: C-64 1541 disk drive -> amiga?
Organization: Institut fuer Informatik der Universitaet Freiburg, Deutschland
Distribution: comp
Date: Tue, 6 Oct 92 14:55:22 GMT

lundman@kauri.vuw.ac.nz (L Lundman) writes:

>I had a friend in Denmark who had a cable to connect his 1541 to his amiga
>so he could read/write disks with the amiga c64 emulator.

>	Does anyone know how to make such a cable? Can someone please inform
>me what pins I need to connect. (I think the cable used the parallel port on
>the amiga, but I'm not sure... )

You'll probably need 5 pins of the parallel port, namely DATA IN, DATA OUT,
COLCK IN, CLOCK OUT and ATN OUT (they don't have those names on the port, of
course, that's their functions for the serial IEC-bus). The XX OUT pins
must be connected to the bus pins via open-collector-driver (7406 or 7407),
the XX IN pins directly or via an inverter (7404). Which of the two depends
on weather the emulator uses direct or inverted logic on the port pins.
Which port pins the emulator uses for which function, I also don't know.

Not much information, but perhaps it helps ...

Philip


--
: whoisit?  ( -- )
 ." Philip Zembrod "  ( zembrod@informatik.uni-freiburg.de ) ;
From: gobeski8618@iscsvax.uni.edu (Steve 'Gobes' Gobeski)
Newsgroups: comp.sys.cbm
Subject: Re: big RELs
Date: 30 Sep 92 12:49:21 -0500
Organization: University of Northern Iowa


In article <egZuRB1w164w@jwt.UUCP>, bbs-artmoore@jwt.UUCP (arthur moore) writes:
> The 1541 creates 6 side sectors when you create a relative file to point 
> to the 664 blocks on the disk...How do the 1571 and 1581 approach 
> relative files?  More side sectors?  Surely you can create a relative 
> file on these higher capacity drives that will cover more than 720 
> sectors...
>  
> 
> ( ( Art Moore  | Usenet bbs-artmoore@jwt.uucp
>  ) )           |  -or-  bbs-artmoore@jwt.oau.org
> ( (            | Fidonet CBM  -  Arthur Moore
>  ) )__Ask me about the C64 qwk offline reader!__

The 81, at least, has "super side-sectors" (or something like that) in its REL
structure, to allow for really big REL files.

On a slight tangent, is there any way to copy a REL file from a 41 to an 81
(since the file structure is different?).  The program I'm interested in doing
this doesn't have any support for doing this.  (it's in basic, though, so once
I port the database it should still work).

-- Steve 'Gobes' Gobeski // GOBESKI8618@iscsvax.uni.edu
From: fred@cbmvax.commodore.com (Fred Bowen)
Newsgroups: comp.sys.cbm
Subject: Re: Zmodem implementation
Date: 29 Sep 92 14:32:09 GMT
Reply-To: fred@cbmvax.commodore.com (Fred Bowen)
Organization: Commodore, West Chester, PA

In article <--2nqxg.fuzzy@netcom.com> fuzzy@netcom.com (Fuzzy Fox) writes:
>andrew@zone4.ocunix.on.ca (Andrew Low) writes:
>
>>I'd argue that the 71 and 81 in 'burst' mode would be all we need
>>to get the transfer speed.  Wasn't there something about being able
>>to use them in this mode when talking to the 64?
>
>The burst mode is only accessible from 128 mode, because one of the
>things that happens when you switch to 64 mode is you lose the ability
>to receive data in burst mode.  At least, that's how I understand it.
>Maybe Fred Bowen can clear this up for me.  :)

Once upon a time, I used a hardware hack to 'trick' a C128 into leaving
various 128 modes active in 64 mode.  For example, the only way the
'fast serial' curcuitry knows which mode it's in is by the state of the
128/64 and FSDIR lines at one gate (U8 pins 9 & 10).  Of course, you'd
need to install your own fast serial driver on the 64 side to implement
the protocol.  Standard disclaimer- hack your system at your own risk.

Now that I think about it, there was an easier way than that, and much
less daunting for those not technically inclined.  Several years ago I
built a 'fast serial' cartridge which tapped signals available at the
user and cassette ports (well, except for one jumper if I recall),
giving any C64 fast serial through the standard serial port.  I think I
even had a C64 ROM in which I replaced the cassette stuff with the fast
serial stuff.  That work was the basis of the C64+, which of course
never came to be.  If it's any consolation, I did implement fast serial
in both modes of the C65, which never came to be, either.
-- 
Fred Bowen			uucp:	{uunet|rutgers|pyramid}!cbmvax!fred
				domain:	fred@cbmvax.commodore.com
				tele:	215 431-9100

Commodore Electronics, Ltd.,  1200 Wilson Drive,  West Chester,  PA,  19380
Organization: Penn State University
Date: Tue, 29 Sep 1992 00:39:15 EDT
From: Chris Stoy <CMS129@psuvm.psu.edu>
Newsgroups: comp.sys.cbm
Subject: Re: Viruses for the 64
 <Bv5yM8.BAB@news.cso.uiuc.edu> <92092820053@zone4.ocunix.on.ca>
 <1992Sep28.112702.1@pembvax1.pembroke.edu>


In article <1992Sep28.112702.1@pembvax1.pembroke.edu>,
duck@pembvax1.pembroke.edu says:
>
>In article <92092820053@zone4.ocunix.on.ca>, andrew@zone4.ocunix.on.ca (Andrew
>Low) writes:
>
>It sounded to me as if he ment the cassette buffer as there is no such thing
>as
>a drive buffer in the C64 (there's a 1 byte buffer in the '128...)...
>  ^^^^^^^^^^^^^^^^^^^^^^^

Well, in a way your right. There are no drive buffers in the 64. However, the
1541 has internal buffers used for moving data back and forth to the computer.
You CAN write a program that could live in one of these buffers and then "come
alive" when the drive is accessed.  Fastload routines are a good example of
this.  There's no reason you can't have it do other things as well.

Just thought I'd add a little fuel to the virus debate.

-----------------------------------------------------------------------
Chris "Slothman" Stoy |  "It is in the nature of the mind to forget
cms129 at psuvm       |   and in the nature of man to worry over his
cms129@psuvm.psu.edu  |   forgetfullness"    (I dunno, sounded cool)
-----------------------------------------------------------------------
From: gobeski8618@iscsvax.uni.edu (Steve 'Gobes' Gobeski)
Newsgroups: comp.sys.cbm
Subject: Wrong is Write - bug report
Date: 27 Sep 92 21:19:07 -0500
Organization: University of Northern Iowa

I recently downloaded WrongIsWrite from ccosun(?sp) and quickly discovered a
major bug:  the program fails to check for end-of-file on the source file!  I
was doing 2.1->1.1 conversions, if that helps anyone.  Anyway, I ended up
killing the conversion by turning off the computer (not anything I want to have
to count on needing to do!).  The "converted" files were readable, and (for all 
I know) were converted ok, there was just 50+ blank pages tacked on.

-- Steve 'Gobes' Gobeski // GOBESKI8618@iscsvax.uni.edu

PS.  The GEOS system file was 1.3 (I think) and this was running on a 1541
drive.  Hopefully this info will find its way to the author.
From: EAO102@psuvm.psu.edu (Ernie Oporto)
Newsgroups: comp.sys.cbm
Subject: Re: GEOS (64) applications & compatibility with versions of GEOS
Date: 29 Sep 92 15:00:37 GMT
Article-I.D.: psuvm.92273.110037EAO102
Organization: The Pennylvania State University

In article <1992Sep29.031222.6656@pdnfido.fidonet.org>,
ckunz@pdnfido.fidonet.org (Charles Kunz) says:
>
>Currently I own GEOS64 v1.2, which came with geoWrite 1.1 and geoPaint 1.1,   h
>bot
>of which I am content with.  However, I feel I am falling behind when it comes
>to the deskTop and kernal, and I am reluctant to get any new applications for
>fear that they are incompatible with 1.2 (ie., most of these applications or
>desk accessories say "for 1.3 and higher").  I would like to upgrade to GEOS  0
>2.
>-however- I have many geoWrite documents that I would like to keep.  These
>doc files were created with geoWrite 1.1.  I also have many photo scraps in
>photo albums that I would like to keep, also.  Basically my question is this:
>Will geoWrite 1.1 work with GEOS versions higher than 1.2 or will there be
>problems?  Will my photo scraps work with versions higher than 1.2?  What
>about my photo albums?

All of your GEOS files should be compatible with the next higher
upgrade of any programs.  geoWrite 1.1 should be loaded by 2.0, as
should 1.2.  The same can be said about geoPaint and any others that
you have.  Make the conversion!  =)

  _____)           ______        _)       _)  EAO102@PSUVM.PSU.EDU
                               __       __    OPORTO@CORVETTE.ECE.PSU.EDU
______    ______            ___      ___      Ernie "SHOKK" Oporto
                               __       __    Computer Lab Attendant
(_______ _      _ ________ _     _) _     _)  for PSU's CAC Department
From: bbs-artmoore@jwt.UUCP (arthur moore)
Newsgroups: comp.sys.cbm
Subject: Re: relative file format
Date: 1 Oct 92 04:03:26 GMT
Reply-To: bbs-artmoore@jwt.UUCP
Organization: The Matrix

fred@cbmvax.commodore.com (Fred Bowen) writes:
> It's explained in the manual- the only reason to add 96 to the channel
> number is to be compatible with the DOS in the older PET/CBM IEEE drives.
> 
> BTW, on the same page of the manual is the following warning:
> "To avoid the remote possibility of corrupting relative file data, it is
> necessary to give record pointer commands twice- once before a record is
> read or written, and again immediately afterwards".  It's good advice.
> -- 

Although I'd be the last to argue your technical info, there is no 
mention of this in my manual.  I have the ALPS mechanism, and the manual 
is dated 9/82.
Thanks.
 

( ( Art Moore  | Usenet bbs-artmoore@jwt.uucp
 ) )           |  -or-  bbs-artmoore@jwt.oau.org
( (            | Fidonet CBM  -  Arthur Moore
 ) )__Ask me about the C64 qwk offline reader!__
From: ac803@cleveland.Freenet.Edu (Michael W. Kelley)
Newsgroups: comp.sys.cbm
Subject: Re: 1541 drives?
Date: 28 Sep 1992 14:53:17 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: ac803@cleveland.Freenet.Edu (Michael W. Kelley)
NNTP-Posting-Host: hela.ins.cwru.edu


In a previous article, as232@cleveland.Freenet.Edu (Michael Lerner) says:

>
>A friend is looking for a way to buy 1541 drives in quantity.  I remember
>reading about a mail-order group called "Tenex" or some such, does anyone
>have any info on this, or better ways to get ahold of new 1541's?  Thanks.
>Please E-mail responses.
>
>Mike
>-- 
>
Tenex Computer Express
56800 Magnetic Drive
Mishawaka, IN  46545
(219) 259-7051
1-800-776-6781
-- 
Basic Bits Commodore Group, No. Ridgeville, Ohio
Quantumlink - RidgeRunr
Light Of Day Commodore Sysop (216) 327-1603, 9600 baud
                             (216) 327-1423, 2400 baud
From: fred@cbmvax.commodore.com (Fred Bowen)
Newsgroups: comp.sys.cbm
Subject: Re: cpm cartridge wanted for c64
Keywords: wanted, cpm
Date: 30 Sep 92 16:31:23 GMT
Reply-To: fred@cbmvax.commodore.com (Fred Bowen)
Distribution: comp
Organization: Commodore, West Chester, PA

Edgar.Estrada@bbs.oit.unc.edu (Edgar Estrada) writes:
>6500hage@ucsbuxa.ucsb.edu (William F. Hagen) writes:
>>
>> Wanted, CPM cartridge for c64  [...]
>
>I had one for my old 64 but I could never get it to work without the 64
>locking up. I called commodore and they told me that the 64 had to have
>one of the original roms for ithe cartridge to work. I was also told
>that there was no way to get a copy of the original rom.
>
>In other words the catridge was useless. I thought you might want to know.

That is incorrect (the old ROM bit, not the useless part :-)

You need a really really old VIC chip, before some timing changes were
made.  But be aware, replacing a new-ish VIC with an old one might make
your CP/M card work, but now your 1764 REU will be flakey.

Better to get a used C128, which has a built-in Z80 and runs a newer
version of CP/M better, faster, with a larger TPA, and 40 or 80 columns.
-- 
Fred Bowen			uucp:	{uunet|rutgers|pyramid}!cbmvax!fred
				domain:	fred@cbmvax.commodore.com
				tele:	215 431-9100

Commodore Electronics, Ltd.,  1200 Wilson Drive,  West Chester,  PA,  19380
Newsgroups: comp.sys.cbm
From: cloos@theory.TC.Cornell.EDU (James H. Cloos Jr.)
Subject: Kermit, VDC, 6 Character sets
Organization: Cornell Information Technologies, Ithaca, NY 14853
Distribution: comp
Date: Sat, 3 Oct 1992 09:44:46 GMT

I'm presently doing using my 128 (unused since '87) as a vt100
emulator via kermit 2.2, and would like a better character set loaded
into the vdc's ram.

I found an old file that loaded a new set into the vdc's ram, but
found that kermit copies the rom set over when it boots up.

Is there any way around this?  Has anyone hacked kermit to use a
better set.  (Preferably in 16 pixel high mode.)

-JimC
--
James H. Cloos, Jr.		include <std/disclaimers.h>
Cloos@Theory.TC.Cornell.EDU     include <std/qotd>
Cloos@Batcomputer.UUCP 		Phone:  +1 716 866-5249
Cloos@CrnlThry.BITNET 		Snail:  POBox 1111, Amherst, NY 14226-1111

--
James H. Cloos, Jr.		include <std/disclaimers.h>
Cloos@Theory.TC.Cornell.EDU     include <std/qotd>
Cloos@Batcomputer.UUCP 		Phone:  +1 716 866-5249
Cloos@CrnlThry.BITNET 		Snail:  POBox 1111, Amherst, NY 14226-1111
Newsgroups: comp.sys.cbm
From: ad945@yfn.ysu.edu (Brent Busby)
Subject: Re: Help identify computer
Reply-To: ad945@yfn.ysu.edu (Brent Busby)
Organization: St. Elizabeth Hospital, Youngstown, OH
Date: Wed, 30 Sep 1992 11:50:09 GMT


In a previous article, fred@cbmvax.commodore.com (Fred Bowen) says:

>The P500 was also called the C128-40, PET-II, or P-series.  It was a
>B-series computer (6509, 6551, IEEE, BASIC 4.0) with a VIC chip (replacing
>the 6845) and SID chip.  It did not have a 1541-type serial interface, tho.
>
>I did some work on adding graphic commands (and new garbage collect) to
>its BASIC (VSP), but that never got out the door (the graphic commands
>did make it into the Plus-4, so it wasn't a total waste of time).  After
>the Plus-4 'fiasco', the project was revived, and that machine became
>the C128 most of you know and, I presume, love.
>-- 
>Fred Bowen			uucp:	{uunet|rutgers|pyramid}!cbmvax!fred
>				domain:	fred@cbmvax.commodore.com
>				tele:	215 431-9100
>
>Commodore Electronics, Ltd.,  1200 Wilson Drive,  West Chester,  PA,  19380

Is there a text file or some other such thing that I could obtain that gives
a COMPLETE list of specifications like these on all Commodore computer models?
I'm just wondering if something like this would be available, especially to
help with identifying the older models, but newer ones up to and including
Amigas would be helpful too.
From: CMS129@psuvm.psu.edu (Chris Stoy)
Newsgroups: comp.sys.cbm
Subject: Re: Is it possible to hook up a Coleco Adam Printer to a 64?
Date: 30 Sep 92 19:10:12 GMT
Organization: Penn State University

You might want to be careful with doing this.  I seem to remember hearing that
the Adam's power supply was located in the printer and if you hooked it up
wrong yu'd fry your 64.  Of course, I could be wrong since it's been five
years since I thought of doing it.

Another thing you need to find out is what type of interface does the Adam's
printer use (serial or parrallel or does it use some wierd one that Colleco
came up with just for their system).  After you figure this out you need to buy
or make an interface so your 64 can talk to it.

All in all, your probably better off going out and buying a cheap dot matrix
printer and be assured it will work.  However, if anyone out there has managed
to hook up the Adam's printer to their 64, please let us know.  I've been known
to be wrong before.


-----------------------------------------------------------------------
Chris "Slothman" Stoy |  "It is in the nature of the mind to forget
cms129 at psuvm       |   and in the nature of man to worry over his
cms129@psuvm.psu.edu  |   forgetfullness"    (I dunno, sounded cool)
-----------------------------------------------------------------------
From: fred@cbmvax.commodore.com (Fred Bowen)
Newsgroups: comp.sys.cbm
Subject: Re: ZMODEM for the C64
Date: 29 Sep 92 14:35:38 GMT
Reply-To: fred@cbmvax.commodore.com (Fred Bowen)
Organization: Commodore, West Chester, PA

In article <l-2nx3h.fuzzy@netcom.com> fuzzy@netcom.com (Fuzzy Fox) writes:
>duck@pembvax1.pembroke.edu writes:
>
>>Serial Devices? I'd say forget 'em as they tend to hog up too much computer
>>time and re-writing the code to fit in the space would be a royal pain
>
>Unless you enjoy writing disk code.  :)

Piece of cake.  Or is it pie?
-- 
Fred Bowen			uucp:	{uunet|rutgers|pyramid}!cbmvax!fred
				domain:	fred@cbmvax.commodore.com
				tele:	215 431-9100

Commodore Electronics, Ltd.,  1200 Wilson Drive,  West Chester,  PA,  19380
From: fred@cbmvax.commodore.com (Fred Bowen)
Newsgroups: comp.sys.cbm
Subject: Re: ZMODEM for the C64
Date: 29 Sep 92 16:10:17 GMT
Reply-To: fred@cbmvax.commodore.com (Fred Bowen)
Organization: Commodore, West Chester, PA

csbruce@neumann.uwaterloo.ca (Craig Bruce) writes:
>fuzzy@netcom.com (Fuzzy Fox) writes:
>>cdminter@icaen.uiowa.edu (Corey D Minter) writes:
>>
>>>So many questions, just one more:  When implementing a protocol, how do I tell
>>>the difference between a real 0 recieved and nothing being recieved NULL
>>>(do I check ST)?
>>
>>The usual method is to compare receive head/tail pointers.  If they are
>>the same, no data is received; else there is data.  Hmm.  Maybe the
>>carry flag might be set for receiving bogus data, but the head/tail
>>comparison is the prevalent method, I think.
>
>I don't actually know about this either, but doesn't the GETIN routine return
>with .Z=1 if there was no character available and .Z=0 if a character is
>available?  I know that this is not documented, but I remember taking
>advantage of this before.

Checking the processor's carry or zero flags is not reliable.  You could
compare buffer pointers, but the system does that for you anyway- after
a call to GETIN, check the I/O STatus.  If the buffer was empty, the
accumulator will be $00 and bit 3 of the status byte is set (ST and 8)=1.
If the carry flag is set, it means there was a non-I/O related error.

-- 
Fred Bowen			uucp:	{uunet|rutgers|pyramid}!cbmvax!fred
				domain:	fred@cbmvax.commodore.com
				tele:	215 431-9100

Commodore Electronics, Ltd.,  1200 Wilson Drive,  West Chester,  PA,  19380