Closing a file in Assembly on the VIC-20

[Lawrence Woodman]

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]

On Thu, 17 Jun 2021 11:29:57 -0000 (UTC), Tilmann Hentze wrote:

> Lawrence Woodman <lorryw...@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

[Lawrence Woodman]

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.

[Anssi Saari]

Lawrence Woodman <lorryw...@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.

[Lawrence Woodman]

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

[Daniel Path]

Hello Lawrence.

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

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)

[Anssi Saari]

Andreas Kohlbach <a...@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.

[Lawrence Woodman]

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 <lorryw...@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/

[Daniel Path]

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

[Lawrence Woodman]

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

[Silver Dream !]

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.

[Silver Dream !]

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.