I have created a piece of code which replicates the problem below if
anyone has any ideas where I'm going wrong I'd be very grateful.
; Basic Stub
TOK_SYS = $9E ; SYS token
.byt $01, $10 ; Load address ($1001)
* = $1001
.word basicEnd ; Next Line link, here end of Basic program
.word 1 ; The line number for the SYS statement
.byt TOK_SYS ; SYS token
.asc " "
.asc "4110" ; Start of machine language
.byt 0 ; End of Basic line
basicEnd .word 0 ; End of Basic program
; KERNEL/BASIC ROM Routines
CLOSE = $FFC3
SAVE = $FFD8
SETLFS = $FFBA
SETNAM = $FFBD
main
lda #$07 ; Length of file name
ldx #<filename ; Low byte of file name location
ldy #>filename ; High byte of file name location
jsr SETNAM ; Set the name
lda #$08 ; Logical file number
ldx #$08 ; Device number
ldy #$01 ; Secondary address - $01 because saving
jsr SETLFS ; Set above parameters
lda #<flash ; Low byte of start of memory block to save
sta $C1
lda #>flash ; High byte of start of memory block to save
sta $C2
lda #$C1 ; Pointer to location of start address
ldx #<(flashend+1) ; Low byte of (end of memory block + 1)
ldy #>(flashend+1) ; High byte of (end of memory block + 1)
jsr SAVE ; Perform save
lda #$08 ; Logical file number
jsr CLOSE ; Close the file
Lawrence Woodman <lorrywoodman@gmail.com> wrote:
I have created a piece of code which replicates the problem below if
anyone has any ideas where I'm going wrong I'd be very grateful.
[code snipped]
main
lda #$07 ; Length of file name
ldx #<filename ; Low byte of file name location
ldy #>filename ; High byte of file name location
jsr SETNAM ; Set the name
lda #$08 ; Logical file number
ldx #$08 ; Device number
ldy #$01 ; Secondary address - $01 because saving
jsr SETLFS ; Set above parameters
I'd switch the two previous blocks around, so that you first set up the channel and then set the file name.
[code snipped]
lda #$08 ; Logical file number
jsr CLOSE ; Close the file
Looks good to me. Perhaps it will work with the first mentioned change?
On Thu, 17 Jun 2021 11:29:57 -0000 (UTC), Tilmann Hentze wrote:
Lawrence Woodman <lorrywoodman@gmail.com> wrote:
I have created a piece of code which replicates the problem below if
anyone has any ideas where I'm going wrong I'd be very grateful.
[code snipped]
main
lda #$07 ; Length of file name
ldx #<filename ; Low byte of file name location
ldy #>filename ; High byte of file name location
jsr SETNAM ; Set the name
lda #$08 ; Logical file number
ldx #$08 ; Device number
ldy #$01 ; Secondary address - $01 because saving
jsr SETLFS ; Set above parameters
I'd switch the two previous blocks around, so that you first set up the
channel and then set the file name.
Thanks for the suggestion. I gave it a go but unfortunately it still
gives the same result.
[code snipped]
lda #$08 ; Logical file number
jsr CLOSE ; Close the file
Looks good to me. Perhaps it will work with the first mentioned change?
Sadly not. However, I'm not sure that a CLOSE is necessary as I noticed
in other code examples that it isn't used. I've tried without it and
also checked for errors via a carry after the SAVE but still no joy. If
you or anyone else has any ideas I'd love to get this working.
Hello Everyone,
I've been trying to save some memory on the VIC-20 to a file on disk but
seem to be having some problems when it comes to close the file. At the moment the file saves the data properly from assembly but I have to use 'CLOSE 8' from basic to prevent it having an asterisk next to the name in
the directory entry.
Lawrence Woodman <lorrywoodman@gmail.com> writes:
Hello Everyone,
I've been trying to save some memory on the VIC-20 to a file on disk but
seem to be having some problems when it comes to close the file. At the
moment the file saves the data properly from assembly but I have to use
'CLOSE 8' from basic to prevent it having an asterisk next to the name in
the directory entry.
I assembled with xa and ran in Vice but I don't get an asterisk in the directory entry. Other than the obvious file name issue I see nothing
wrong but I'm hardly an expert.
On Fri, 18 Jun 2021 10:48:21 +0300, Anssi Saari wrote:
Lawrence Woodman <lorrywoodman@gmail.com> writes:
Hello Everyone,
I've been trying to save some memory on the VIC-20 to a file on disk but >>> seem to be having some problems when it comes to close the file. At the >>> moment the file saves the data properly from assembly but I have to use
'CLOSE 8' from basic to prevent it having an asterisk next to the name in >>> the directory entry.
I assembled with xa and ran in Vice but I don't get an asterisk in the
directory entry. Other than the obvious file name issue I see nothing
wrong but I'm hardly an expert.
Thanks for trying. I have got it running now, the problem was that I was automating this and wasn't leaving it long enough before checking the directory. It's all working now :-)
On Thu, 17 Jun 2021 18:56:16 -0000 (UTC), Lawrence Woodman wrote:
On Thu, 17 Jun 2021 11:29:57 -0000 (UTC), Tilmann Hentze wrote:
Lawrence Woodman <lorrywoodman@gmail.com> wrote:gives the same result.
I have created a piece of code which replicates the problem below
if anyone has any ideas where I'm going wrong I'd be very
grateful.
[code snipped]
main
lda #$07 ; Length of file name
ldx #<filename ; Low byte of file name location
ldy #>filename ; High byte of file name location
jsr SETNAM ; Set the name
lda #$08 ; Logical file number
ldx #$08 ; Device number
ldy #$01 ; Secondary address - $01 because
saving jsr SETLFS ; Set above parameters
I'd switch the two previous blocks around, so that you first set up
the channel and then set the file name. Thanks for the suggestion.
I gave it a go but unfortunately it still
in other code examples that it isn't used. I've tried without it[code snipped]
lda #$08 ; Logical file number
jsr CLOSE ; Close the file
Looks good to me. Perhaps it will work with the first mentioned
change? Sadly not. However, I'm not sure that a CLOSE is necessary
as I noticed
and also checked for errors via a carry after the SAVE but still no
joy. If you or anyone else has any ideas I'd love to get this
working.
I've managed to track down the problem. Because I was automating some
of the testing around this I hadn't left a long enough delay
before displaying the directory. It turns out that it takes a little longer than I expected for the SAVE command to complete the write.
Once I left a bigger delay before checking the directory everything
was fine. It also appears that there is no need to call CLOSE either.
And the delay when physically writing a file does not occur in
emulators. That's why it worked in VICE right away.
Hmm, VICE has "true drive emulation". I wonder what happens if activated...
18 Jun 21 06:56, you wrote to you:
On Thu, 17 Jun 2021 18:56:16 -0000 (UTC), Lawrence Woodman wrote:
On Thu, 17 Jun 2021 11:29:57 -0000 (UTC), Tilmann Hentze wrote:
Lawrence Woodman <lorrywoodman@gmail.com> wrote:
I have created a piece of code which replicates the problem below
if anyone has any ideas where I'm going wrong I'd be very
grateful.
[snip]
I've managed to track down the problem. Because I was automating some of the testing around this I hadn't left a long enough delay
before displaying the directory. It turns out that it takes a little longer than I expected for the SAVE command to complete the write.
Once I left a bigger delay before checking the directory everything
was fine. It also appears that there is no need to call CLOSE either.
and what are you coding? :)
On Fri, 18 Jun 2021 20:54:46 +1200, Daniel Path wrote:
18 Jun 21 06:56, you wrote to you:
On Thu, 17 Jun 2021 18:56:16 -0000 (UTC), Lawrence Woodman wrote:
On Thu, 17 Jun 2021 11:29:57 -0000 (UTC), Tilmann Hentze wrote:
Lawrence Woodman <lorrywoodman@gmail.com> wrote:
I have created a piece of code which replicates the problem below
if anyone has any ideas where I'm going wrong I'd be very
grateful.
[snip]
I've managed to track down the problem. Because I was automating some >> LW> of the testing around this I hadn't left a long enough delayand what are you coding? :)
before displaying the directory. It turns out that it takes a little >> LW> longer than I expected for the SAVE command to complete the write.
Once I left a bigger delay before checking the directory everything
was fine. It also appears that there is no need to call CLOSE either. >>
I'm creating an article and video about various ways to load and save
memory on the VIC-20. I wrote the assembly code that I posted a while
ago and was sure it worked previously. As it turned out there was
nothing significantly wrong with the code, it was purely a testing
issue. I can post the URLs to the article/video once finished if
you're interested?
On Fri, 18 Jun 2021 20:54:46 +1200, Daniel Path wrote:
18 Jun 21 06:56, you wrote to you:
On Thu, 17 Jun 2021 18:56:16 -0000 (UTC), Lawrence Woodman
wrote:
On Thu, 17 Jun 2021 11:29:57 -0000 (UTC), Tilmann Hentze wrote:
Lawrence Woodman <lorrywoodman@gmail.com> wrote:
I have created a piece of code which replicates the problem
below if anyone has any ideas where I'm going wrong I'd be
very grateful.
[snip]
I've managed to track down the problem. Because I was
automating some of the testing around this I hadn't left a long
enough delay before displaying the directory. It turns out
that it takes a little longer than I expected for the SAVE
command to complete the write. Once I left a bigger delay
before checking the directory everything was fine. It also
appears that there is no need to call CLOSE either.
and what are you coding? :)
I'm creating an article and video about various ways to load and save memory on the VIC-20. I wrote the assembly code that I posted a while
ago and was sure it worked previously. As it turned out there was
nothing significantly wrong with the code, it was purely a testing
issue. I can post the URLs to the article/video once finished if
you're interested?
21 Jun 21 08:12, you wrote to me:
I'm creating an article and video about various ways to load and save memory on the VIC-20. I wrote the assembly code that I posted a while ago and was sure it worked previously. As it turned out there was nothing significantly wrong with the code, it was purely a testing issue. I can post the URLs to the article/video once finished if
you're interested?
sure i am! thanks Lawrence :)
good luck and have fun!
main
lda #$07 ; Length of file name
ldx #<filename ; Low byte of file name location
ldy #>filename ; High byte of file name location
jsr SETNAM ; Set the name
lda #$08 ; Logical file number
ldx #$08 ; Device number
ldy #$01 ; Secondary address - $01 because saving
jsr SETLFS ; Set above parameters
I'd switch the two previous blocks around, so that you first set up the channel and then set the file name.
lda #<flash ; Low byte of start of memory block to save >> sta $C1
lda #>flash ; High byte of start of memory block to save >> sta $C2
lda #$C1 ; Pointer to location of start address
ldx #<(flashend+1) ; Low byte of (end of memory block + 1)
ldy #>(flashend+1) ; High byte of (end of memory block + 1)
The high byte should probaly only increment, when the low byte is $ff.
jsr SAVE ; Perform save
lda #$08 ; Logical file number
jsr CLOSE ; Close the file
Looks good to me.
And the delay when physically writing a file does not occur in
emulators. That's why it worked in VICE right away.
Hmm, VICE has "true drive emulation". I wonder what happens if activated...
| Sysop: | Gate Keeper |
|---|---|
| Location: | Shelby, NC |
| Users: | 764 |
| Nodes: | 20 (0 / 20) |
| Uptime: | 40:39:28 |
| Calls: | 11,275 |
| Calls today: | 1 |
| Files: | 5,288 |
| D/L today: |
81 files (10,064K bytes) |
| Messages: | 521,283 |