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 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

rts

filename .asc "FLASH"

;=================================
; Block of memory to save
;=================================
flash lda $900F ; Record initial screen border/background combo
ldx #$FF ; First combo is $FF
setcombo stx $900F ; Set screen border/background combo

; Time delay
ldy #$FF
delay dey
bne delay

dex ; Next combo
bne setcombo
sta $900F ; restore initial screen border/background combo
flashend rts

Thanks in advance

Lorry

---
Advanced Use of .LBR Files on CP/M
https://techtinkering.com/articles/advanced-use-of-lbr-files-on-cpm/

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.

> ; 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

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. Perhaps it will work with the first mentioned change?

Best regards,
Tilmann.

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.

Best wishes

Lorry

---
Advanced Use of .LBR Files on CP/M
https://techtinkering.com/articles/advanced-use-of-lbr-files-on-cpm/

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.
>>>
>>> [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.

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.

Best wishes

Lorry

---
Advanced Use of .LBR Files on CP/M
https://techtinkering.com/articles/advanced-use-of-lbr-files-on-cpm/

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 :-)

Best wishes

Lorry

---
Advanced Use of .LBR Files on CP/M
https://techtinkering.com/articles/advanced-use-of-lbr-files-on-cpm/

On Fri, 18 Jun 2021 08:04:07 -0000 (UTC), Lawrence Woodman wrote:
>
> 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 :-)

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...
--
Andreas

PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0

Hello Lawrence.

18 Jun 21 06:56, you wrote to you:

LW> 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.
>>>>
>>>> [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.

LW> 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 delay
LW> 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.
LW> Once I left a bigger delay before checking the directory everything
LW> was fine. It also appears that there is no need to call CLOSE either.

and what are you coding? :)

--
Daniel

.... BBS: Uptime is 02d 20h 42m 32s (BT-Uptime/OS2, V1.5)

Andreas Kohlbach <ank@spamfence.net> writes:

> And the delay when physically writing a file does not occur in
> emulators. That's why it worked in VICE right away.

Unless emulators actually emulate the drive? Not sure if you think I'm
stupid or not. Anyways, drive emulation is often needed on 8-bit
Commodores since the drives are "smart", in effect computers in
themselves.

> Hmm, VICE has "true drive emulation". I wonder what happens if activated...

Disk access is authentically slow if activated. I usually have it on and
had for this. I find my little retro fun is more fun with that. Vice
even emulates drive sounds if requested but that gets tiresome pretty
fast.

On Fri, 18 Jun 2021 20:54:46 +1200, Daniel Path wrote:

> 18 Jun 21 06:56, you wrote to you:
>
> LW> 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]
>
> LW> 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 delay
> LW> 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.
> LW> Once I left a bigger delay before checking the directory everything
> LW> 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?

Best wishes

Lorry

---
Basic Line Storage on the VIC-20
https://techtinkering.com/articles/basic-line-storage-on-the-vic-20/

On Mon, 21 Jun 2021 08:12:46 -0000 (UTC), Lawrence Woodman wrote:
>
> On Fri, 18 Jun 2021 20:54:46 +1200, Daniel Path wrote:
>
>> 18 Jun 21 06:56, you wrote to you:
>>
>> LW> 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]
>>
>> LW> 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 delay
>> LW> 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.
>> LW> Once I left a bigger delay before checking the directory everything
>> LW> 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?

I'd be interested.
--
Andreas

Hello Lawrence.

21 Jun 21 08:12, you wrote to me:

LW> On Fri, 18 Jun 2021 20:54:46 +1200, Daniel Path wrote:

>> 18 Jun 21 06:56, you wrote to you:
>>
>> LW> On Thu, 17 Jun 2021 18:56:16 -0000 (UTC), Lawrence Woodman
>> LW> 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]
>>
>> LW> I've managed to track down the problem. Because I was
>> LW> automating some of the testing around this I hadn't left a long
>> LW> enough delay before displaying the directory. It turns out
>> LW> that it takes a little longer than I expected for the SAVE
>> LW> command to complete the write. Once I left a bigger delay
>> LW> before checking the directory everything was fine. It also
>> LW> appears that there is no need to call CLOSE either.
>>
>> and what are you coding? :)

LW> I'm creating an article and video about various ways to load and save
LW> memory on the VIC-20. I wrote the assembly code that I posted a while
LW> ago and was sure it worked previously. As it turned out there was
LW> nothing significantly wrong with the code, it was purely a testing
LW> issue. I can post the URLs to the article/video once finished if
LW> you're interested?

sure i am! thanks Lawrence :)
good luck and have fun!

--
Daniel

.... 10:23pm up 6 days, 11:23:31, load: 69 processes, 275 threads.

On Mon, 21 Jun 2021 20:28:44 +1200, Daniel Path wrote:

> 21 Jun 21 08:12, you wrote to me:
>
> LW> I'm creating an article and video about various ways to load and save
> LW> memory on the VIC-20. I wrote the assembly code that I posted a while
> LW> ago and was sure it worked previously. As it turned out there was
> LW> nothing significantly wrong with the code, it was purely a testing
> LW> issue. I can post the URLs to the article/video once finished if
> LW> you're interested?
>
> sure i am! thanks Lawrence :)
> good luck and have fun!

The article and video about saving and loading memory on the VIC-20 are
live on my TechTinkering website/YouTube channel.

The article is at:
https://techtinkering.com/articles/saving-and-loading-memory-on-the-vic-20/

The video is at:
https://www.youtube.com/watch?v=sOBrRV6p82w

I hope you like it

Lorry

---
Retro Computers, Programming, CP/M, VIC-20
https://techtinkering.com

On 17.06.2021 13:29, Tilmann Hentze wrote:

>> 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.

Shouldn't make any difference. The order of the two preparatory calls is
interchangeable.

>> 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.

I am not sure what are you trying to say here. This takes LO/HI bytes of
an address. Assembler takes care of both being correct.

>
>> jsr SAVE ; Perform save
>
>> lda #$08 ; Logical file number
>> jsr CLOSE ; Close the file

One needs to CLOSE() (or CLALL() in some cases) files that were
previously OPEN(). Not needed for SAVE().

> Looks good to me.

LGTM too.

On 18.06.2021 21:47, Andreas Kohlbach wrote:

> 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...

Then it emulates the real machine's behaviour at much more accurately.
Keep it set.