6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Apr 20, 2024 1:07 am

All times are UTC




Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Thu Feb 18, 2010 4:15 pm 
Offline

Joined: Mon Dec 23, 2002 8:47 pm
Posts: 70
For my port of EHBASIC I have needed (and attempted to implement) LOAD and SAVE commands that took string arguments. I'm not really getting it to work right, probably because I'm missing something incredibly simple and stupid. :/

This is because my target is a disk system (I am running it under an OS).


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Feb 18, 2010 6:52 pm 
Offline

Joined: Mon Dec 23, 2002 8:47 pm
Posts: 70
(Feel free to lock, I figured it out - it was JSR LAB_EVEX. I'm still working on the graft though.)


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 09, 2014 3:18 pm 
Offline
User avatar

Joined: Wed Sep 03, 2003 6:53 pm
Posts: 150
Location: Long Island, NY
All --

I know this is an old thread, but I'm up to the point where I'm writing the "disk" save and load commands on my implementation of SBC2. I've seen several recommended methods to get a string parameter, but none seem to work. The command is {DSAVE "filename"} with a maximum string length of 16 characters (due to limits in Commodore DOS). The "str_xx" variables are my own. The SETNAM routine is a DOS routine that sets the file name parameters for DOS.

Code:
DSVE0
   JSR   LAB_EVST   ; evaluate string
   sta   str_ln      ; save string length
   STX   str_pl      ; save string pointer low byte
   STY   str_ph      ; save string pointer high byte
   cmp   #$11      ; max filename length is 16 bytes (>=)
   bcs   SVSYNER      ; string too long error
   JSR    SETNAM      ; A=len; YX=ptr
brk

When I look at the string that's pointed to by the registers upon returning from LAB_EVST, it points to "Ready". Clearly that's not right. I've tried the other methods, with no success. At this point, I'm a bit stuck. There must be a step that I'm missing somewhere. I've looked at some of the other string-based commands for ideas, but that's not helping either. Maybe someone with more experience can point to where I'm going wrong.

Thanks again!

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 09, 2014 3:53 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1678
Location: Sacramento, CA
Hi Rich,

I am including a copy of my routines I use to interface EhBASIC to my DiskOS. I used it to pass load and save parameters back and forth. The pscan routine scans through an EhBASIC program to find the end, and then sets EhBASIC's pointers properly.

Hope this helps.

Daryl


Attachments:
File comment: EhBASIC Load/Save support
basldsv.asm [2.36 KiB]
Downloaded 379 times

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 09, 2014 4:26 pm 
Offline
User avatar

Joined: Wed Sep 03, 2003 6:53 pm
Posts: 150
Location: Long Island, NY
8BIT wrote:
Hi Rich,

I am including a copy of my routines I use to interface EhBASIC to my DiskOS. I used it to pass load and save parameters back and forth. The pscan routine scans through an EhBASIC program to find the end, and then sets EhBASIC's pointers properly.

Hope this helps.

Daryl


Thanks Daryl. The version you sent is different than what I have so I will look more closely. I guess what I'm not getting is when you enter <DSAVE"FILENAME"> from BASIC, where can I get the string within the quotes? The addresses I can access in memory...I just can't get the string.

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 09, 2014 7:01 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1678
Location: Sacramento, CA
The input line should still be at ibuffs. You may need to parse it to find the start quote and end quote. I zero out the ibuffs as I read it to prevent EhBASIC from trying to execute the rest of the line after the save command is executed. It's been a while since I worked on that code, but I think that's all there was to it. In my case, the syntax was SAVE filename<cr>. I could add a path prefix also, SAVE /sub/filename<cr>. EhBASIC's parser replaced the / with $B9 so my code put the / back in.

You can have the SAVE command just jump to you monitor then you can view the memory contents at ibuffs to confirm my description. It's possible the EhBASIC parser is moving the quoted filename to some string buffer if it's not still at ibuffs. I would expect there to be a pointer in the ibuffs area to that string, but I never dug that deep into EhBASIC.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/


Top
 Profile  
Reply with quote  
PostPosted: Mon Mar 10, 2014 9:33 am 
Offline

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany
RichCini wrote:
...The "str_xx" variables are my own...
...When I look at the string that's pointed to by the registers upon returning from LAB_EVST, it points to "Ready"...

No, str_pl & str_ph are not your own!

They are also used in ehbasic to print "Ready" at the end of a direct command, hence they obviously will point at "Ready" when you look at them after a direct command.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5


Top
 Profile  
Reply with quote  
PostPosted: Mon Mar 10, 2014 11:53 am 
Offline
User avatar

Joined: Wed Sep 03, 2003 6:53 pm
Posts: 150
Location: Long Island, NY
Klaus2m5 wrote:
RichCini wrote:
...The "str_xx" variables are my own...
...When I look at the string that's pointed to by the registers upon returning from LAB_EVST, it points to "Ready"...

No, str_pl & str_ph are not your own!

They are also used in ehbasic to print "Ready" at the end of a direct command, hence they obviously will point at "Ready" when you look at them after a direct command.


Thanks Klaus. I did look back at my code and my "...variables are my own..." comment is actually wrong. I confused the variable name when typing the posting. However, what you describe is what's happening. I am using the "str_xx" variables as inputs to a routine which takes the string pointed to by YX as the filename string.

So, I'm at least using the wrong string variables from the parser. So, what is the right routine to use to parse a string in quotes (or not...I don't have to use quotes) from the command line and get a pointer to it?

Thanks.

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org


Top
 Profile  
Reply with quote  
PostPosted: Mon Mar 10, 2014 12:50 pm 
Offline

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany
The first question is, if you really need to go through a full string evaluation, as you would probably never allow a string variable as a parameter of a SAVE or LOAD. Parsing a simple string constant should be easy, as you just need to look for an opening quote. The string should then be at Bpntrl/h + 1 and is terminated by closing quotes. See LAB_INPUT, how ehbasic prints a string constant if available.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5


Top
 Profile  
Reply with quote  
PostPosted: Mon Mar 10, 2014 1:45 pm 
Offline
User avatar

Joined: Wed Sep 03, 2003 6:53 pm
Posts: 150
Location: Long Island, NY
Klaus2m5 wrote:
The first question is, if you really need to go through a full string evaluation, as you would probably never allow a string variable as a parameter of a SAVE or LOAD. Parsing a simple string constant should be easy, as you just need to look for an opening quote. The string should then be at Bpntrl/h + 1 and is terminated by closing quotes. See LAB_INPUT, how ehbasic prints a string constant if available.

Klaus --

You are correct, it's a string constant. What I was missing was the correct system variable to use. Thanks again!

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org


Top
 Profile  
Reply with quote  
PostPosted: Mon Mar 10, 2014 3:09 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1922
Location: Sacramento, CA, USA
Klaus2m5 wrote:
The first question is, if you really need to go through a full string evaluation, as you would probably never allow a string variable as a parameter of a SAVE or LOAD ...

Menu-program launching and semi-automated chaining come to mind ...

Mike


Top
 Profile  
Reply with quote  
PostPosted: Mon Mar 10, 2014 4:16 pm 
Offline

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany
A LOAD in EhBASIC requires a subsequent RUN. So keeping variables between chained program parts is not possible. However, chaining itself would still be possible if you can manage to inject a RUN, just not with a filename stored in a variable.

Same goes for a program menu. You just can't pass variables back and forth.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 26, 2017 11:58 am 
Offline

Joined: Sun Dec 28, 2014 11:04 pm
Posts: 81
Location: Munich, Germany
Hi there,

there seems to be quite a lot of mixed information about how to deal with string arguments in LOAD and SAVE. I'd like to present the way I came up with:
At the beginning of either LOAD and SAVE, i call a subroutine that gets the string argument using LAB_EVEX and opens the file:
Code:
openfile:
                jsr LAB_EVEX
                lda Dtypef
                bne @go
                ; not a string, trigger syntax error
                ldx #$02
                jsr LAB_XERR
@go:
                ldy #$00
@l:
                lda (ssptr_l),y
                beq @open
                cmp #'"'
                beq @term
                iny
                bne @l
@term:
                lda #$00
                sta (ssptr_l),y
@open:
                lda ssptr_l
                ldx ssptr_h
                jsr krn_open
                bne     io_error
                rts
io_error:
                pha
                jsr     krn_primm
                .asciiz "io error: "
                pla
                jmp krn_hexout


As it seems, after calling LAB_EVEX, ssptr points to the string given as parameter including the closing ", which I overwrite with $00 to be compatible with my open routine, which expects the address of a null terminated string.
In another thread, it was suggested to pop the string from the descriptor stack using LAB_22B6, which in my case resulted in ut1_ph/l not pointing to the string, but anywhere in the area of $exxx, where my os resides. So I went for the above approach. It works, but it feels rather dirty due to the overwriting of the closing ". At this point, I am open for suggestions.

EDIT:
BTW, my first approach was to just use Bpntrl as suggested above but this way SAVE always gave me a Syntax Error after having saved the file anyway. As this gave me a really hard time to track down, I went for the somewhat oversized approach using LAB_EVEX together with a bit of dirt as described above.

/thomas


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 30, 2017 7:57 pm 
Offline

Joined: Sun Feb 22, 2004 9:01 pm
Posts: 78
Old post, but this is my code, jumped to via SAVE_VEC and LOAD_VEC:
Code:
; LOAD and SAVE
BBCLOAD
   LDA   #$FF      ; $FF=load
   JSR   BBCFILE
   LDA   #<LAB_RMSG   ; "READY"
   LDY   #>LAB_RMSG
   JSR   LAB_18C3
   JMP   LAB_1319   ; relink program and clear variables
BBCSAVE
   LDA   #$00      ; $00=save
BBCFILE
   PHA         ; save operation
   JSR   LAB_EVEX   ; evaluate string
   JSR   LAB_EVST   ; test it is a string
   ; XY=>string, A=length
   blah blah

_________________
--
JGH - http://mdfs.net


Top
 Profile  
Reply with quote  
PostPosted: Thu May 03, 2018 8:37 pm 
Offline

Joined: Sun Dec 28, 2014 11:04 pm
Posts: 81
Location: Munich, Germany
jgharston wrote:
Old post, but this is my code, jumped to via SAVE_VEC and LOAD_VEC:


Thanks, that really helped to make my version a lot less messy :-)


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: