Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user eightbitswide ! (Registered 2024-12-24) You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > load + save = copy ???
2004-05-01 08:13
Rattus
Account closed

Registered: Apr 2004
Posts: 34
load + save = copy ???

Is it possible to make a program that copies files by just using kernal calls ?

Let's say I have a file that has a load address of $0900...
So when you type load "file",8,1 it is loaded to $0900 and is runnable...

But... If you load the file using kernal call LOAD... And want it to load to $4000 it goes nicely there. The problem is here: How to save the file from $4000 so, that it will load to $0900 next time you load it from BASIC ?

Are there routines in kernal to figure out files start-address, end-address, length etc... ?

It would be really nice if someone could bother helping me...
2004-05-01 12:39
yago

Registered: May 2002
Posts: 333
I hate to say it, but these Questions are way to basic to be answered here in detail. If you want better answers, you might check out the newsgroup comp.sys.cbm

If you do not load and save, but simply open that file, read the bytes, close the file, open another file, save the bytes, and close that second file, you are done.
No matter what the load-address is.

There are enough kernel-routines for this kind of stuff.

Zed Yago
--
If everything is worth money
money is worth nothing
2004-05-01 13:02
hollowman

Registered: Dec 2001
Posts: 474
dont know if there is a pretty way of getting the loadadress. anyway, this worked for me to copy a file


*= $1000

loadad = $fd
end = $fb
setnam = $ffbd
setlfs = $ffba
load = $ffd5
save = $ffd8

lda #8
ldx #8
ldy #0
jsr setlfs

lda #name2-name
ldx #<name
ldy #>name
jsr setnam

lda #$60
sta $b9
jsr $f3d5
lda $ba
jsr $ed09
lda $b9
jsr $edc7
jsr $ee13
sta loadad
jsr $ee13
sta loadad+1

lda #0
jsr load
stx end
sty end+1

lda #8
ldx #8
ldy #0
jsr setlfs

lda #sname2-sname
ldx #<sname
ldy #>sname
jsr setnam

ldx end
ldy end+1
lda #loadad
jsr save
rts
name
.text "gnu.draz"
name2

sname
.text "test7"
sname2


2004-05-01 14:58
iopop

Registered: Dec 2001
Posts: 317
This have been discussed in this topic already Saving files using Kernal

But no conculsion was find back then. One method would be to load the file. Then to save use $FFD2 to write onto disk. The first two bytes written contains the new low and high adress of the files starting adress and then the data. This method is however really slow. I used this method in ATTAC to be able to save data $0801-$ffff without any problems.
2004-05-01 19:30
Rattus
Account closed

Registered: Apr 2004
Posts: 34
Thank you...
Sorry if I have asked stupid questions, but not all people are genius...


2004-05-02 09:02
Richard

Registered: Dec 2001
Posts: 621
Quote: dont know if there is a pretty way of getting the loadadress. anyway, this worked for me to copy a file


*= $1000

loadad = $fd
end = $fb
setnam = $ffbd
setlfs = $ffba
load = $ffd5
save = $ffd8

lda #8
ldx #8
ldy #0
jsr setlfs

lda #name2-name
ldx #<name
ldy #>name
jsr setnam

lda #$60
sta $b9
jsr $f3d5
lda $ba
jsr $ed09
lda $b9
jsr $edc7
jsr $ee13
sta loadad
jsr $ee13
sta loadad+1

lda #0
jsr load
stx end
sty end+1

lda #8
ldx #8
ldy #0
jsr setlfs

lda #sname2-sname
ldx #<sname
ldy #>sname
jsr setnam

ldx end
ldy end+1
lda #loadad
jsr save
rts
name
.text "gnu.draz"
name2

sname
.text "test7"
sname2




This routine should be useful for packer routines or something like that as well as copiers, depending on where these routines go :)
2004-05-02 10:21
hollowman

Registered: Dec 2001
Posts: 474
Quote: Thank you...
Sorry if I have asked stupid questions, but not all people are genius...




i dont think the question is stupid, atleast i dont know a
smooth way of changing the startadress using
kernalroutines. perhaps yago could enlighten us?
2004-05-02 12:00
iopop

Registered: Dec 2001
Posts: 317
Quote: i dont think the question is stupid, atleast i dont know a
smooth way of changing the startadress using
kernalroutines. perhaps yago could enlighten us?


Same here. I find it very interesting to see a smooth solution to this.

Another not-that-smooth way would be too save the file with normal kernel calls. Then find the Track/Sector containing the first 254 bytes of the file. Read that sector into mem, change the first two bytes (which contains the startadress) and re-write that sector.
2004-05-02 12:54
yago

Registered: May 2002
Posts: 333
Quote: i dont think the question is stupid, atleast i dont know a
smooth way of changing the startadress using
kernalroutines. perhaps yago could enlighten us?


/me and my big mouth!
I am using a (selfwritten) crossdevelopment-tool for manipulating loadaddresses, but that does certainly not use kernal-routines!

What I tried to explain above is the following code:

Open File
Read until EOF, buffer into memory.
Close File

Change 1st+2nd byte in memory to new loadaddress
Open File
Write File from buffer
Close File


I did not want to scare rattus away, I just wanted to point him to another community, if there would be not enough answers from here.

BTW, there is a Program called "change loadaddress" (or similar) on the 1541Disk, which is delivered by cbm with every 1541 Drive. Its a Basic-Program.
2004-05-02 15:56
Graham
Account closed

Registered: Dec 2002
Posts: 990
@hollowman:

it would be better if you used jump table calls instead of direct rom calls.

$FFB4 instead of $ED09
$FF96 instead of $EDC7
$FFA5 instead of $EE13

also, you should UNTALK the device again etc.
2004-05-02 20:16
cadaver

Registered: Feb 2002
Posts: 1160
Also it should be noted that TALK/UNTALK, CIOUT etc. won't be IDE64 compatible. It'll be a bit more pain to OPEN, CHKIN/CHKOUT and then CHRIN/CHROUT the file byte by byte but at least then you're compatible and are in exact control of what happens (including startaddress).
2004-05-04 07:10
Oswald

Registered: Apr 2002
Posts: 5094
AFAIK you can set a new loadadress with the kernal save...
2004-05-04 12:57
Stryyker

Registered: Dec 2001
Posts: 468
You can Oswald? Enlighten me. I know AR had a save file with different load address.

If you are messing with something funky it can be a bit of hassle but search for start track + sector. Use the U1 and U2 command to read to drive buffer, change 2 bytes (B-P first) and write back. Maybe even spend a little time using the open command with certain thingy (I'm getting dumb!), like lda #$03,ldx #$08, ldy #thingy, jsr $ffba then open. See what drive locations are used then close, B-P then write with suitable U command. Check AR loader as this uses similar method to setup the loader. Use kernel open command then start some drive code (unsure if it uses open, then writes to drive memory then executes or what). That atleast happens with 1581 fast loader.

Bad formatting but ideas.

If your code was tidy enough, you could make something a drive mem multiple start address changer. Just dump a queue to drive and use similar filename parsing like some IRQ loaders then return.

2004-05-04 17:06
Graham
Account closed

Registered: Dec 2002
Posts: 990
@cadaver: IDE64 shouldnt use IEC device numbers then.
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
SLC
Martin Piper
Scan/House Designs
Guests online: 115
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 The Demo Coder  (9.6)
6 Edge of Disgrace  (9.6)
7 What Is The Matrix 2  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 Cubic Dream  (9.6)
3 Party Elk 2  (9.6)
4 Copper Booze  (9.6)
5 X-Mas Demo 2024  (9.5)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top Graphicians
1 Mirage  (9.8)
2 Archmage  (9.7)
3 Pal  (9.6)
4 Carrion  (9.6)
5 Sulevi  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.05 sec.