Hi! I finally have a working C64/1541 disk copier but not a file copier. The working disk copier is Online Copy. Any suggestions for file copiers? I have an NTSC C64C and a plain 1541 drive.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Saturday, March 4, 2017 at 2:25:19 PM UTC-5, Andreas Kohlbach wrote:

LOAD "SOME_PROGRAM",8,1

Swap disks.

SAVE "SOME_PROGRAM",8,1

;-)

Uhh...will that work on ML programs loaded and run as BASIC? If so, that may be all I need. :)

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Fri, 3 Mar 2017 12:42:28 -0800 (PST), Harry Potter wrote:

Hi! I finally have a working C64/1541 disk copier but not a file
copier. The working disk copier is Online Copy. Any suggestions for
file copiers? I have an NTSC C64C and a plain 1541 drive.

LOAD "SOME_PROGRAM",8,1

Swap disks.

SAVE "SOME_PROGRAM",8,1

;-)
--
Andreas
You know you are a redneck if
the highlight of your family reunion was your sister's nude dancing debut.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Saturday, March 4, 2017 at 2:59:51 PM UTC-5, Harry Potter wrote:

Uhh...will that work on ML programs loaded and run as BASIC? If so, that may

be all I need. :)

It worked! Thank you! :D

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Saturday, March 4, 2017 at 3:41:47 PM UTC-5, Harry Potter wrote:

On Saturday, March 4, 2017 at 2:59:51 PM UTC-5, Harry Potter wrote:

Uhh...will that work on ML programs loaded and run as BASIC? If so, that

may be all I need. :)

It worked! Thank you! :D

One problem: I just tried to copy a file that's too big to fit in memory--I forgot about that--and got an Out of Memory error. I need another way to copy this file. :(

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 05.03.2017 00:53, Harry Potter wrote:

On Saturday, March 4, 2017 at 3:41:47 PM UTC-5, Harry Potter wrote:

On Saturday, March 4, 2017 at 2:59:51 PM UTC-5, Harry Potter wrote:

Uhh...will that work on ML programs loaded and run as BASIC? If so, that may be all I need. :)

It worked! Thank you! :D

One problem: I just tried to copy a file that's too big to fit in memory--I

forgot about that--and got an Out of Memory error. I need another way to copy this file. :(

Hi!

The reason for this is that the file is over 159 blocks long, so Basic
is not able to save the file because name does not fit into memory.

Easy solution for this is a wery small m/l program. I made one, and its
size is just 40 bytes. Only problem is that the name is always same, but
1541 dos allows you to change the name afterwards.

Create a program like this and place it into 679 onwards (I used 53200
on my c64, but i had another program that was trouble if I used 679).
Also tape buffer is not suitable for your program, because you might
want to copy from tape also.

Assembler code:


*=679

.lda #1..;logical address
.tay..;set same as secondary
.ldx #8..;devnum (you can change this, if want)
.jsr $ffba.;SETLFS routine, kernal
.lda #2..;name length
.ldx #<name.;name low address
.ldy #>name.;name high address
.jsr $ffbd.;SETNAM routine, kernal
.lda #54..;turn BASIC off
.sta $1..;store to CPU register
;now we can store the area from 2049 to 53247, but of course we save
;only the data that is needed, not more.
.lda #$2b.;we save from Basic start
.ldx $2d
.ldy $2e..;to Basic end, since Basic load
;has set the variables start (this makes the trouble when trying to
;save something over 159 blocks!)
.jsr $ffde.;call Kernal save routine
.lda #55
.sta $1..;return Basic interpreter
.rts..;return to Basic
name.!tx "na".;name for Kernal


Since the Kernal save routine does not need Basic interpreter, you can
safely turn it off. This routine is also Jiffydos or another turbo
compatible.

Now, the usage:

1. Load this tiny program to memory. After loading, give command NEW or
reset the c64. Dont worry, this software survives even hard reset
(sys64738 or reset switch!).
2. Load the program from the media you want to copy (turbo tape, disk, whatever). Only thing is that you need to use LOAD command or compatible
way to load it.
3. Put the destination disk to your disk drive and type SYS 679. The
disk drive starts its slow process, and after the process READY prompt
comes to screen. If you need more copies, just repeat SYS 679 with
another disk.
4. Type NEW.
5. Load the disk directory and you will see a program named NA on the disk.
6. Rename the program to whatever you want. For example: open1,8,15,"r0:gianasisters=na":close1

This program can save also shorter programs than 160 blocks, its maximum
being 201 blocks. Only short is that you have to rename the file
afterwards, but it is only tiny price if you need to copy files.

If your file size is over 201 blocks, you need to use special program
for it.








.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Sunday, March 5, 2017 at 6:42:29 AM UTC-5, Harry Potter wrote:

Thank you! I think the program in question is short enough. :)

Uhh...I use cc65's assembler for C64 assembler. Is there another, simpler assembler I can use?

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Thank you! I think the program in question is short enough. :)

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

I tried your program on BASSEM. For some reason, the program immediately dumps
me back to BASIC without saving the file. I tested the program on WinVice 3.0.
I used the monitor, and the code is there, so I don't know what's wrong. :(

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Sat, 4 Mar 2017 14:53:54 -0800 (PST), Harry Potter wrote:

On Saturday, March 4, 2017 at 3:41:47 PM UTC-5, Harry Potter wrote:

On Saturday, March 4, 2017 at 2:59:51 PM UTC-5, Harry Potter wrote:

Uhh...will that work on ML programs loaded and run as BASIC? If so, that may be all I need. :)

It worked! Thank you! :D

One problem: I just tried to copy a file that's too big to fit in
memory--I forgot about that--and got an Out of Memory error. I need
another way to copy this file. :(

Back in the day we had mostly nibbler copy programs. But they didn't copy
file by file. And most other programs only copied a whole disk rather
than asking what file(s) to copy. Cannot remember to have ever ran into
your problem though.
--
Andreas
You know you are a redneck if
momma taught you how to flip a cigarette.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

I just looked at my docs. and found out why your progra didn't work: the kernal
SAVE routine is at $FFD8, *not* $FFDE. I'll change it now.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Sunday, March 5, 2017 at 3:59:31 PM UTC-5, Harry Potter wrote:

I just looked at my docs. and found out why your progra didn't work: the

kernal SAVE routine is at $FFD8, *not* $FFDE. I'll change it now.

Performed the change. It works now! :)

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Pekka Takala <pekka.NOtakala@pihSPAMtisoft.fi> writes:

If your file size is over 201 blocks, you need to use special program
for it.

How do those special programs work, other than flipping disks multiple
times? I remember early on in the 80s there was this file copy program
called copy57.5K or something like that. Presumably it was able to do
57.5 kB at a time but how?

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Monday, March 6, 2017 at 7:16:31 AM UTC-5, Anssi Saari wrote:

How do those special programs work, other than flipping disks multiple
times? I remember early on in the 80s there was this file copy program
called copy57.5K or something like that. Presumably it was able to do
57.5 kB at a time but how?

I presume it uses the memory behind the ROMs and I/O to store the information.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 05.03.2017 23:08, Harry Potter wrote:

On Sunday, March 5, 2017 at 3:59:31 PM UTC-5, Harry Potter wrote:

I just looked at my docs. and found out why your progra didn't work: the kernal SAVE routine is at $FFD8, *not* $FFDE. I'll change it now.

Performed the change. It works now! :)

Yeah, wrote it when awfully tired. but glad you got it working :)

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Harry Potter <rose.joseph12@yahoo.com> writes:

On Monday, March 6, 2017 at 7:16:31 AM UTC-5, Anssi Saari wrote:

How do those special programs work, other than flipping disks multiple
times? I remember early on in the 80s there was this file copy program
called copy57.5K or something like that. Presumably it was able to do
57.5 kB at a time but how?

I presume it uses the memory behind the ROMs and I/O to store the

information.

Well sure but how do you do that?

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Monday, March 6, 2017 at 3:22:31 PM UTC-5, Anssi Saari wrote:

Harry Potter <rose.joseph12@yahoo.com> writes:

I presume it uses the memory behind the ROMs and I/O to store the

information.

Well sure but how do you do that?

By switching out the memory areas. Look at your docs. at memory location $01.
It will give you more information. :)

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Anssi Saari <as@sci.fi> wrote:

Well sure but how do you do that?

The 6510 CPU used by the Commodore 64 has built in 6-bit GPIO port,
which is accessable through device registers at memory locations 0000
and 0001. Address 0000 is the data direction register and determines
whether each GPIO line is a input or output. Address 0001 is the data
port and is where GPIO lines are read from and writen to. Bits 0, 1,
2 are named LORAM, HIRAM and CHAREN respectively and their lines are
connected to circuitry that maps ROM, RAM and I/O space in and out of the
C64's 64K address space. By setting LORAM and HIRAM to 0 (the state of
CHAREN doesn't matter) the entire 64K address space is mapped with RAM.
A notable exception are two device registers at 0000 and 0001 which as
they're built into the CPU can't be mapped out.

So presumably copy57.5K switches to the memory map where everything is
RAM and does the copy using the remaining 6.5K of RAM to store the code
that does the copying.

.....Ross Ridge

--
l/ //. Ross Ridge -- The Great HTMU
[oo][oo] rridge@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

rridge@csclub.uwaterloo.ca (Ross Ridge) writes:

So presumably copy57.5K switches to the memory map where everything is
RAM and does the copy using the remaining 6.5K of RAM to store the code
that does the copying.

Yes, presumably. But it's just a little bit hard to do I/O if you switch
I/O out of your memory space so that's not the thing to do, exactly. One
could use RAM to RAM copy to fill the RAM under I/O. But I wonder,
Pekka's routine was just 40 bytes using ROM routines so 6.5K (or 5.5K
since the program was actually copy 58.5k) RAM seems excessive. The
whole operating system is just 8K. So maybe the program skipped the I/O
area?

The other question is, what all do you need to take care of if you're
going to get rid of the kernal and still be able to load stuff into RAM
below and also get the kernal back later? But with a quick look it looks
like disabling interrupts is enough.

BTW, I think I found the program, it was COPY 58.5K and it's on a disk
image at http://www.commodoreserver.com/PublicDiskDetails.asp?DID=BABE16C933E24BE9A89B8743E4F56D2C

Maybe I'm going to try and figure out exactly how it works. Looks like
it's 11 blocks so 2.75K but it might be compressed.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 07.03.2017 12:17, Anssi Saari wrote:

rridge@csclub.uwaterloo.ca (Ross Ridge) writes:

So presumably copy57.5K switches to the memory map where everything is
RAM and does the copy using the remaining 6.5K of RAM to store the code
that does the copying.

Yes, presumably. But it's just a little bit hard to do I/O if you switch
I/O out of your memory space so that's not the thing to do, exactly. One could use RAM to RAM copy to fill the RAM under I/O. But I wonder,
Pekka's routine was just 40 bytes using ROM routines so 6.5K (or 5.5K
since the program was actually copy 58.5k) RAM seems excessive. The
whole operating system is just 8K. So maybe the program skipped the I/O
area?

The other question is, what all do you need to take care of if you're
going to get rid of the kernal and still be able to load stuff into RAM
below and also get the kernal back later? But with a quick look it looks
like disabling interrupts is enough.

BTW, I think I found the program, it was COPY 58.5K and it's on a disk
image at http://www.commodoreserver.com/PublicDiskDetails.asp?DID=BABE16C933E24BE9A89B8743E4F56D2C

Maybe I'm going to try and figure out exactly how it works. Looks like
it's 11 blocks so 2.75K but it might be compressed.

The load and save routines in stock kernal are not able to switch off
roms. But if you want to use whole memory, then you are able to open the
file as normal sequential file. When you need to get under ROMS, you
switch them off temporarily, read the byte and then switch them back on.
Only thing to remember is that when you switch ROMS off, the interrupt
vectors has to be taken account (especially NMI). On c64, if cpu writes
onto area of ROM, it writes the byte into underneath RAM. So you can
program the RAM memory beforehand using write-through method. When
reading, just turn ROMS off, read byte and then turn them back on. For
example:

; Copy 256 bytes from under Kernal Rom

; we copy the string to 60000, that is under KERNAL ROM.
; We output the string to screen using kernal routines. Same method can
; be used when outputting to disk - just open the file and select it.
; Without a string copied to 60000, this program copies whatever garble
; there is.

.ldx #00.;pointer
.loop.sei
.ldy #53.;turn ROMS off
.sta $1
.lda 60000,x
.ldy #55.;turn ROMS on
.sta $1
.cli.;enable interrupts
;now we have the read byte from under Kernal in accu.
.jsr CHROUT.;chrout is label for Kernal chrout routine
.inx
.bne .loop


My program uses simplest possible method to save memory. It turns off
the BASIC interpreter, so it wont interfere with data in ram of its
area. The program is suitable for almost any pirated game program
copying, since if you load over 53247, you WILL have problems with your
video chip (since it garbles). That is why this tiny program is so
handy- it is small enough to be in memory, and it turns the basic
interpreter off. The basic interpreter is not needed when Kernal
routines are used, so you can safely turn it off. This tiny program
returns the basic interpreter after it has done its duties, so that you
have the shell control of the computer.

If you want to save using sequential file method, here is the pseudocode:

open file,P,W to disk drive
output start address LO,HI (f. ex 01, 08) mode
output data
close file

I have made a datagenerator, that made a basic program to disk. It was
able to load a m/l program, and then create basic for - read- poke- next
loop and data lines for it. It made tokenized code, and calculated all
needed line links and everything. It output the program using sequential
file mode, and the resulted file was normally loadable on c64. The
program itself was written in Basic, and it output basic program :D

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Anssi Saari <as@sci.fi> wrote:

Yes, presumably. But it's just a little bit hard to do I/O if you switch
I/O out of your memory space so that's not the thing to do, exactly.

You can either swap the I/O space in and out as each byte is read or
keep it mapped and have 4K less RAM to store the program.

One could use RAM to RAM copy to fill the RAM under I/O. But I wonder, >Pekka's routine was just 40 bytes using ROM routines so 6.5K (or 5.5K
since the program was actually copy 58.5k) RAM seems excessive.

I'm assuming it would be using some sort of "fastloader" code to improve
speed so it wouldn't use the kernal ROM.

......Ross Ridge

--
l/ //. Ross Ridge -- The Great HTMU
[oo][oo] rridge@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

rridge@csclub.uwaterloo.ca (Ross Ridge) writes:

Anssi Saari <as@sci.fi> wrote:

Yes, presumably. But it's just a little bit hard to do I/O if you switch >>I/O out of your memory space so that's not the thing to do, exactly.

You can either swap the I/O space in and out as each byte is read or
keep it mapped and have 4K less RAM to store the program.

One could use RAM to RAM copy to fill the RAM under I/O. But I wonder, >>Pekka's routine was just 40 bytes using ROM routines so 6.5K (or 5.5K
since the program was actually copy 58.5k) RAM seems excessive.

I'm assuming it would be using some sort of "fastloader" code to improve speed so it wouldn't use the kernal ROM.

The program is 1983 vintage and doesn't seem to use a fastloader or compression. Disk is read and written a byte at a time using kernal's
ACPTR and CIOUT routines. The program is delightfully straightforward:
it starts by setting screen and border colors, then puts a preformatted
message on screen and starts polling for keyboard input.

After going through the disassembly I eventually found the code which
reads a byte from RAM ($0d19) and writes a byte to RAM ($0d08):

0d00: S0d00 sei
0d01: ldy #$34
0d03: sty $01
0d05: ldy #$00
0d07: rts
0d08: S0d08 jsr S0d00
0d0b: sta ($22),y
0d0d: L0d0d inc $22
0d0f: bne L0d13
0d11: inc $23
0d13: L0d13 ldy #$37
0d15: sty $01
0d17: cli
0d18: rts
0d19: S0d19 jsr S0d00
0d1c: lda ($22),y
0d1e: jmp L0d0d

So, in the end that's all there is to it... Disable interrupts, switch
ROMs and I/O out. Display is blanked during disk reading and writing
too. Still not quite clear why the size limit is 58.5K but for copying a
whole disk in three passes it's enough. Limit for number of files seems
to be 32.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Monday, March 6, 2017 at 12:33:45 PM UTC-5, Pekka Takala wrote:

On 05.03.2017 23:08, Harry Potter wrote:

On Sunday, March 5, 2017 at 3:59:31 PM UTC-5, Harry Potter wrote:

I just looked at my docs. and found out why your progra didn't work: the

kernal SAVE routine is at $FFD8, *not* $FFDE. I'll change it now.

Performed the change. It works now! :)

Yeah, wrote it when awfully tired. but glad you got it working :)

Uhh...does it work for programs stored in other areas of memory, i.e. at $C000 or $8000? Or itself?

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

LOAD "SOME_PROGRAM",8,1

Swap disks.

SAVE "SOME_PROGRAM",8,1

Does this work for SEC files? I spent about an hour looking up any info I
could to find a way to copy just a single SEC from a disk. I couldn't get it to work or even really load it.

--- Mystic BBS v1.12 A33 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (3:770/100)

LOAD "SOME_PROGRAM",8,1

Swap disks.

SAVE "SOME_PROGRAM",8,1

Does this work for SEC files? I spent about an hour looking up any info I ->could to find a way to copy just a single SEC from a disk. I couldn't get it ->to work or even really load it.

This only works for PRG type files, and not SEQ, REL and USR type files.

PRG = Programs.
REL = RELative (aka random access) data files -- often used for databases.
SEQ = SEQuential files. Often PETSCII based text files used for configuration data, etc.
USR = USeR type files. USe varies depending on application.

However, to copy files between disks, I would use a file copy program that is usually available on one of the test/demo disks that come with the 1541, 1571 and 1581 drives.



...If at first you don't succeed, put it out for beta test.
---BapStats Module (bsDBASE v6.1 Build 1)

* Origin: Neptune's Lair - Olive Branch MS - winserver.org (1:116/18)

SEEN-BY: 154/10 280/464 154/120 130 140 30 0

On Sunday, May 14, 2017 at 10:13:38 AM UTC-4, Robert Wolfe wrote:

However, to copy files between disks, I would use a file copy program that is usually available on one of the test/demo disks that come with the 1541, 1571 and 1581 drives.

I believe I have the 1541 test/demo disk. If I don't, I could always ask the people at 64hdd.com to make one for me. Now, which program is the file copy program?

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

I believe I have the 1541 test/demo disk. If I don't, I could always ask the ->people at 64hdd.com to make one for me. Now, which program is the file copy ->program?

Been years since I've used that disk. Can always do a LOAD "$",8 and LIST to see the files on the disk :)



...I tried switching to gum but I couldn't keep it lit.
---BapStats Module (bsDBASE v6.1 Build 1)

* Origin: Neptune's Lair - Olive Branch MS - winserver.org (1:116/18)

SEEN-BY: 154/10 280/464 154/120 130 140 30 0

On Sunday, May 14, 2017 at 2:32:05 PM UTC-4, Robert Wolfe wrote:

I believe I have the 1541 test/demo disk. If I don't, I could always ask

the

people at 64hdd.com to make one for me. Now, which program is the file

copy

program?

Been years since I've used that disk. Can always do a LOAD "$",8 and LIST to see the files on the disk :)

Okay. I'll look when I get the chance. :)

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

This only works for PRG type files, and not SEQ, REL and USR type files.

PRG = Programs.
REL = RELative (aka random access) data files -- often used for
databases. SEQ = SEQuential files. Often PETSCII based text files used for configuration data, etc.
USR = USeR type files. USe varies depending on application.
However, to copy files between disks, I would use a file copy program
that is usually available on one of the test/demo disks that come with
the 1541, 1571 and 1581 drives.

Thank you Robert.

I've been having some fun with c64 disks.
I think I will figure out how to unhide some files that I can't see. I have
an Infocom game called Spellbreaker and the prg file is 3 blks or 3
something. I know it has to be larger than that because if I copy just the
prg flle to another disk. It doesn't run.

Its a stretch for me basically using DOS from the start. Yeah I had a c64 but the things I did was play games or write really small programs then save them to disk.

--- Mystic BBS v1.12 A34 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (3:770/100)