[comp.sys.cbm] Random files problem w/sprites enabled on C64

mfs@edison.GE.COM (Martin Sant) (01/18/88)

Over the weekend I was pulling out my hair over a strange quirk I
discovered while using random files on my C-64/FSD setup.  I found
that the computer would 'hang-up' if I tried to use the 'b-p:'
command while I had sprites enabled.  I tried to read and write data
to the disk buffer and things would just quit after a random number
of block pointer messages.  (I am using ua: and ub: for the sector
read and writes)  I could regain control using RUN/STOP RESTORE.
After I disabled the sprites, things worked fine.  Can someone out
there in the net ether answer:

1) Why does this happen ?

2) Is it particular to the FSD or does the 1541 do this too ?

3) Random files in general; I can use all of the sectors on the disk
   can't I ?  I don't need to store any 'real' DOS files. Can I write
   over the sectors where the directory, etc. are stored ?  Is there
   a difference between the ua:/ub: and the u1:/u2: commands ?

4) The JIFFY DOS stuff that was mentioned on the net several weeks 
   ago:  Does it work ok with random files ?

   Thanks in advance.
-- 
Mar Tan 
GE Fanuc Automation 
Charlottesville, VA 22901

bryce@hoser.berkeley.edu (Bryce Nesbitt) (01/19/88)

In article <1293@edison.GE.COM> mfs@edison.GE.COM (Martin Sant) writes:
>I found
>that the computer would 'hang-up' if I tried to use the 'b-p:'
>command while I had sprites enabled...

"Doctor, it hurts when I do this..."
"Then don't do that."

Sorry, Folks.  Sprites and the serial bus don't mix.  If ANY sprites
are on and you do ANY serial bus access the computer WILL hang every
so often.

This is due to a minor, easy to fix bug.  Easy, that is, except 
for upgrading all X million Commodore-64's.

Moral: Blank the sprites.

|\ /|  . Ack! (NAK, SOH, EOT)
{o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (or try "cogsci")
 (")
  U	"As an engineer, I only set the value of a product... not the cost."
	-Bryce Nesbitt

randy@athena.mit.edu (Randall W Winchester) (01/19/88)

In article <1293@edison.GE.COM> mfs@edison.GE.COM (Martin Sant) writes:
>Over the weekend I was pulling out my hair over a strange quirk I
>discovered while using random files on my C-64/FSD setup.  I found
>that the computer would 'hang-up' if I tried to use the 'b-p:'
>command while I had sprites enabled.  I tried to read and write data
>to the disk buffer and things would just quit after a random number
>of block pointer messages.  (I am using ua: and ub: for the sector
>read and writes)  I could regain control using RUN/STOP RESTORE.
>After I disabled the sprites, things worked fine.  Can someone out
>there in the net ether answer:
>
>1) Why does this happen ?
>
>2) Is it particular to the FSD or does the 1541 do this too ?

I had a program I was trying to debug for the longest time, and it
behaved the same way described here.  I tried it on both a C64 with
1541, and a C128 with a 1571.  I found that using sprites with random
files will result in random crashes.  There seems to be no rhyme or
reason to how long the program would run before hanging.  Using BASIC
AID, I found that it always stopped on a line that printed to the
file.

>3) Random files in general; I can use all of the sectors on the disk
>   can't I ?  I don't need to store any 'real' DOS files. Can I write
>   over the sectors where the directory, etc. are stored ?  Is there
>   a difference between the ua:/ub: and the u1:/u2: commands ?

No need to store any 'real' DOS files.  Just make sure you don't write over the BAM (track 18, sector 0).  You might want to put a message on the first directory sector, something to the effect that "this disk contains random files."  Format the message like file names.  Then when you list the directory, you'll have fair warning before writing to the disk with DOS commands.

-------------------------------------------------------------------------------
 Randy Winchester	randy@athena.mit.edu | If at first you don' succeed,
 P.O. Box 1074				     | you are running about average.
 Cambridge, MA  02142			     |    - M.H. Alderson
-------------------------------------------------------------------------------

randy@athena.mit.edu (Randall W Winchester) (01/19/88)

In article <1293@edison.GE.COM> mfs@edison.GE.COM (Martin Sant) writes:
>Over the weekend I was pulling out my hair over a strange quirk I
>discovered while using random files on my C-64/FSD setup.  I found
>that the computer would 'hang-up' if I tried to use the 'b-p:'
>command while I had sprites enabled.  I tried to read and write data
>to the disk buffer and things would just quit after a random number
>of block pointer messages.  (I am using ua: and ub: for the sector
>read and writes)  I could regain control using RUN/STOP RESTORE.
>After I disabled the sprites, things worked fine.  Can someone out
>there in the net ether answer:
>
>1) Why does this happen ?
>
>2) Is it particular to the FSD or does the 1541 do this too ?

I had a program I was trying to debug for the longest time, and it
behaved the same way described here.  I tried it on both a C64 with
1541, and a C128 with a 1571.  I found that using sprites with random
files will result in random crashes.  There seems to be no rhyme or
reason to how long the program would run before hanging.  Using BASIC
AID, I found that it always stopped on a line that printed to the
file.

>3) Random files in general; I can use all of the sectors on the disk
>   can't I ?  I don't need to store any 'real' DOS files. Can I write
>   over the sectors where the directory, etc. are stored ?  Is there
>   a difference between the ua:/ub: and the u1:/u2: commands ?

No need to store any 'real' DOS files.  Just make sure you don't write
over the BAM (track 18, sector 0).  You might want to put a message on
the first directory sector, something to the effect that "this disk
contains random files."  Write the message as file names.  Then
when you list the directory, you'll have fair warning before writing
to the disk with the usual DOS commands.

>4) The JIFFY DOS stuff that was mentioned on the net several weeks 
>   ago:  Does it work ok with random files ?
>
>   Thanks in advance.
>-- 
>Mar Tan 
>GE Fanuc Automation 
>Charlottesville, VA 22901

-------------------------------------------------------------------------------
 Randy Winchester	randy@athena.mit.edu | If at first you don' succeed,
 P.O. Box 1074				     | you are running about average.
 Cambridge, MA  02142			     |    - M.H. Alderson
-------------------------------------------------------------------------------

fred@cbmvax.UUCP (Fred Bowen) (01/20/88)

In article <1293@edison.GE.COM>, mfs@edison.GE.COM (Martin Sant) writes:
> Over the weekend I was pulling out my hair over a strange quirk I
> discovered while using random files on my C-64/FSD setup.  I found
> that the computer would 'hang-up' if I tried to use the 'b-p:'
> command while I had sprites enabled...
> After I disabled the sprites, things worked fine...
> 1) Why does this happen ?

	The serial bus timing (slow or fast) is critical.  Enabled sprites
	cause the VIC to kick the processor off the bus longer than usual
	at "random" times (depending upon the placement of spites on the
	screen) in order to fetch sprite display data.  Should this
	inordinately long VIC DMA occur during sensitive timing operations
	(or even edge-sensitive triggers) the system will not work right.
	This is rather well known, at least among old time hackers and
	developers.  For this reason, the C128 kernel temporarily disables
	sprites during critical timing loops.

> 2) Is it particular to the FSD or does the 1541 do this too ?

	It does not have anything to do with the drive- it is a problem
	on the host side.

> 3) Random files in general; I can use all of the sectors on the disk
>    can't I ?  I don't need to store any 'real' DOS files. Can I write
>    over the sectors where the directory, etc. are stored ?  Is there
>    a difference between the ua:/ub: and the u1:/ub commands?

	Technically you can use the entire disk, system sectors and
	all, but I would recommend against it- it would be difficult to
	manage, backup, etc. without a functioning directory.  If you
	need more room, perhaps the 1571 (340K) or 1581 (790K) drives
	would suit your application better.

	There is no difference between U1 and UA commands; the DOS simply
	ANDs both of them with $0F to form an index into the user function
	dispatch table.

> 4) The JIFFY DOS stuff that was mentioned on the net several weeks 
>    ago:  Does it work ok with random files ?

	Sorry, I did not see that posting.  The RAMdisk does not support
	direct access commands such as these, but it does support REL
	files.

> Mar Tan 
> GE Fanuc Automation 
> Charlottesville, VA 22901
--
-- 
Fred Bowen			uucp:	{ihnp4|rutgers|caip}!cbmvax!fred
				arpa:	cbmvax!fred@RUTGERS.EDU
				tele:	215 431-9100

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