• Closing a file in Assembly on the VIC-20

    From Lawrence Woodman@lorrywoodman@gmail.com to comp.sys.cbm on Thursday, June 17, 2021 08:55:50
    From Newsgroup: comp.sys.cbm

    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/
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Tilmann Hentze@0xcafe@directbox.com to comp.sys.cbm on Thursday, June 17, 2021 11:29:57
    From Newsgroup: comp.sys.cbm

    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.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lawrence Woodman@lorrywoodman@gmail.com to comp.sys.cbm on Thursday, June 17, 2021 18:56:16
    From Newsgroup: comp.sys.cbm

    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/
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lawrence Woodman@lorrywoodman@gmail.com to comp.sys.cbm on Friday, June 18, 2021 06:56:52
    From Newsgroup: comp.sys.cbm

    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/
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Anssi Saari@as@sci.fi to comp.sys.cbm on Friday, June 18, 2021 10:48:21
    From Newsgroup: comp.sys.cbm

    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.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lawrence Woodman@lorrywoodman@gmail.com to comp.sys.cbm on Friday, June 18, 2021 08:04:07
    From Newsgroup: comp.sys.cbm

    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/
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Andreas Kohlbach@ank@spamfence.net to comp.sys.cbm on Friday, June 18, 2021 15:47:28
    From Newsgroup: comp.sys.cbm

    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
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam.Daniel.Path@nospam.Daniel.Path@f52.n371.z2.fidonet.org (Daniel Path) to Lawrence Woodman on Friday, June 18, 2021 20:54:46
    From Newsgroup: comp.sys.cbm

    Hello Lawrence.

    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.

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

    and what are you coding? :)

    --
    Daniel

    ... BBS: Uptime is 02d 20h 42m 32s (BT-Uptime/OS2, V1.5)
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Anssi Saari@as@sci.fi to comp.sys.cbm on Saturday, June 19, 2021 15:03:20
    From Newsgroup: comp.sys.cbm

    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.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lawrence Woodman@lorrywoodman@gmail.com to comp.sys.cbm on Monday, June 21, 2021 08:12:46
    From Newsgroup: comp.sys.cbm

    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?

    Best wishes


    Lorry

    ---
    Basic Line Storage on the VIC-20 https://techtinkering.com/articles/basic-line-storage-on-the-vic-20/
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Andreas Kohlbach@ank@spamfence.net to comp.sys.cbm on Monday, June 21, 2021 06:01:17
    From Newsgroup: comp.sys.cbm

    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:

    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 delay
    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. >>
    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
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam.Daniel.Path@nospam.Daniel.Path@f52.n371.z2.fidonet.org (Daniel Path) to Lawrence Woodman on Monday, June 21, 2021 20:28:44
    From Newsgroup: comp.sys.cbm

    Hello Lawrence.

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

    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?

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

    --
    Daniel

    ... 10:23pm up 6 days, 11:23:31, load: 69 processes, 275 threads.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lawrence Woodman@lorrywoodman@gmail.com to comp.sys.cbm on Thursday, June 24, 2021 08:08:05
    From Newsgroup: comp.sys.cbm

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

    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!


    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
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Silver Dream !@silverdr@nospam.net to comp.sys.cbm on Wednesday, June 30, 2021 10:49:10
    From Newsgroup: comp.sys.cbm

    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.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Silver Dream !@silverdr@nospam.net to comp.sys.cbm on Wednesday, June 30, 2021 10:51:08
    From Newsgroup: comp.sys.cbm

    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.
    --- Synchronet 3.18b-Win32 NewsLink 1.113