RFC-3: Enhance EhBASIC?

[netzerohero]

Hello Rumbledethumps and the Picocomputer community.

I'm hoping to encourage thoughts and discussion on enhancing EhBASIC for the picocomputer system.

Rumbledethumps has an initial ehbasic repo in the picocomputer Github project. (Thank you!)
And he has built-out two fundamental picocomputer capabilities: SDK/file-io and VGA-graphics. (Thank you!)

Is there an interest in bringing BASIC-program file SAVE/LOAD and graphics-support to EhBASIC?

1. SAVE / LOAD: EhBASIC, written in assembler, has the hooks for SAVE / LOAD from the BASIC-prompt. rp6502-sdk provides file-io within C. Adding SAVE & LOAD would enhance EhBASIC's user experience.

2. BASIC-Graphics: Adding point and line plotting graphics to EhBASIC would open-up the picocomputer's EhBASIC to a wealth of BASIC code available from the retro-computer domain. Unclear to me how adding plot and line graphics that might be approached within EhBASIC. Historically BASICs "back-in-the-day" provided 'USR hooks' to assembly routines. EhBASIC appears to also provide USR() functionality.

And importantly from my perspective (as I am new to Git / Github, but know the importance of good CM practices) is the setup and management of repo workflows:

3. CM-Workflow: How should the two above candidate enhancements be tracked/organized within this project or set-up in another git-hub project? (e.g., github issue in the ehbasic repo, git forks/branches, pull-requests etc.)?

Thank you for your consideration.

[rumbledethumps]

Today, I got EhBASIC working with CC65 and all the other tools I built. Save and load would be awesome. I looked at it briefly and it wasn't hooked up much beyond having keywords.

[vruumllc]

I got it built. Fun, thanks! Brings back memories.

[netzerohero]

Thank you both - for the EhBASIC / CC65 repo updates and recent tooling & (re)build verification.

For item (1) SAVE / LOAD above: I created an (enhancement) issue-#1 in the local ehbasic repo. On that tracker/issue, I've been gathering related notes to aid implementation.

For item (2) BASIC-Graphics: The EhBASIC Reference Manual includes guidance (pgs 27-29) on how-to-add graphics point-plotting using the BASIC CALL command. @vruumllc 's Tetricks efforts should prove to be a helpful example for adding point-plotting to EhBASIC. I created a 2nd ehbasic enhancement issue on adding graphic point-plotting.

[n9jcv]

Just to let you know, FOR SURE there is interest in file save and load from within ehbasic. I personally do not have the skills to do it, and from reading this thread, i can see it is more complex than one might first think. Just letting you know I ( and most likely) others would definitely appreciate it!

[netzerohero]

@rumbledethumps merging of Assembly and C environments should be a big help with Save/Load. The graphics-plotting enhancements I put together used that merging and "peaceful coexistence" of EhBasics' assembly and C - taking the 1st 'baby-steps' - as long as one keeps in mind the memory-map usage. The challenges are across each of the three domains and their parameter-interfaces:

• (a) user-land's EhBASIC runtime;
• (b) EhBASIC's assembly-source and its existing capabilities/limitations;
• (c) any C-code implementation (using stdio file-i/o library). And perhaps a fourth domain:
• (d) the RIA-pico's provided capabilities (such as file i/o).

I think the graphics-plotting enhancements (purposefully) start simple, yet provide example across each of those three or four domains. IMHO: Any initial save/load efforts, hopefully using only ascii-source (non-tokenized), should focus initially on (b) / (c), leaving (a) and (d) aside for the moment.

I understand @linuxplayground has also taken a stab at this and the (b) / (c) cross-parameter domains and has encountered some of those challenges (some mentioned below).

But, heck, how hard can this be? After all, it worked (file save/load) on my Apple-II back in the late-70s / early-80s - before the days of C and IDEs. (tonge-in-cheek) :-)

[netzerohero]

I have been thinking about approaches to the two proposed EhBASIC enhancements for the RP6502 Picocomputer.

Analysis:

For item (2) - adding BASIC-Graphics:
For "inspiration" - see related efforts underway on the Neo6502 SBC-target:

• https://github.com/marobi/Pico_6502_v4_ehbasic

There, example may be found in extending BASIC's assembly source with added graphics commands in EhBASIC.
However note: The "runtime environment" in this Neo6502 case, as is the current case of EhBASIC for the RP6502 Picocomputer, remains assembly; it is unaware of the filesystem. Runtime environment is not C, with its added strength of its C-libraries, including access to the Picocomputer's FatFs. Conclusion: good for adding graphics commands to EhBASIC; yet challenges remain in building-out SAVE/LOAD commands and enabling BASIC's access to the FatFs filesystem accessible via the RP6502's std-c library and it file-io functions like (raw) open/close, read()/write(); or (higher-level) fread()/fwrite().

For item (1) - enabling SAVE / LOAD:
Building-out the SAVE/LOAD commands using raw read()/write() or buffered fread()/fwrite() via the RP6502's std-c library accessing tinyusb and FatFs is a significant strength of the RP6502 Picocomputer's architecture. See file-system access code in the Colossal Cave Adventure repo for a good example. To do this, EhBASIC would need to be "elevated" to co-exist alongside the std-c lib environment within the memory footprint - and have the compiler & linker do the heavy-lifting in resolving symbols between both EhBASIC's assembly source and the std-c libraries.

[rumbledethumps]

Including the C runtime is a hard sell in terms of memory cost. The OS calls are designed to be useful without a C runtime and you can still compile and call C functions without the C runtime. But I can help remove the C runtime later if you think it'll speed up development to have it available.

The other extreme would be to go all-in on CC65 abstraction, stdio for io and tgi for graphics. This will cost some kilobytes but might expose the effort to a larger audience. I think the RP6502 is the only platform in CC65 with a filesystem and no basic, so that larger audience might not exist.

The 6502-facing filesystem is based on FatFs. Littlefs is used internally for config data.

[netzerohero]

Thank you for your response and helpful dialog. I stand corrected regarding FatFs vs Littlefs; I see that now. I've updated my post above.

Re:

I think the RP6502 is the only platform in CC65 with a filesystem and no basic...

Well it DOES have a BASIC...
...but currently it is text only w/o user-level file-system (minimally SAVE/LOAD) access within EhBASIC and w/o graphics.
SAVE/LOAD is the harder of the two problems. It seems that graphics within EhBASIC can be incrementally added over time: first via basic's "CALL" hooks; then as others in the broader community are demonstrating (i.e., extending EhBASIC assembly with graphics commands); and perhaps as you suggest - eventually using tgi for graphics.

I agree with your insight:

Including the C runtime is a hard sell in terms of memory cost.

I did not mean to imply that; I may be misusing the term "C runtime" for the RP6502. I understand: one can still compile and call C functions and use OS-calls without the C runtime.

So it seems an approach (specification?) to adding SAVE/LOAD may be coalescing:

"..go all-in on CC65 abstraction, stdio for io..."

...and as the EhBASIC's originator Lee Davison suggested in the Forum exchanges on 6502.org back in 2012 (distilled for clarity):

1. For SAVE/LOAD, use "ASCII format as it's far more portable";
2. "...to save the program as ASCII you should (a) redirect the character output vector to write to your filesystem and then call LIST. Doing this can also allow you to specify line numbers or ranges as with LIST. (b) The output vector should be restored and the file closed when LIST returns or an error is encountered."
3. "To load an ASCII program, (a) redirect the character input vector to read from your filesystem and return to the main interpreter loop. (b) The input vector should be restored and the file closed when the file end is reached or an error is encountered."
4. Initially the SAVE/LOAD filename can be "hardcoded" to something like "BASICPROG.BAS".
   (This enables getting the fundamentals up-and-running before figuring-out how to extract a filename within BASIC's line-input-buffer).
5. Later, extracting a filename string within BASIC's runtime was suggested in the forum:
   "Call the evaluate following expression routine, LAB_EVEZ, and look for a string by testing if the data type flag, Dtypef, is negative. If it is, the string descriptor is on the descriptor stack so don't forget to pop it off there by calling LAB_22B6 once you're done with it."

[netzerohero]

Hyenadae commented in https://github.com/picocomputer/ehbasic/issues/2#issuecomment-1843810300

Not sure if you've had any time to think or plan this out further, but what do you think about:

1. The usage/mixture of C and Source files for extending BASIC functionality (ie, do we just re-link in C and hope the compiler-assembler ties things in despite BASIC taking over the whole machine, as said in the memory map thread)

2. Should we try to re-implement loose versions of graphics functions from other BASICS, ie, Applesoft basic has the 'H' modes and syntax, ...

There's a lot of good thoughts and ideas to unpack in that post. In response to the two items above:

1. I have been thinking how to approach adding EhBASIC SAVE/LOAD (or file-io) and EhBASIC graphics. I don't have the answers, but in my mind it is better to think about these two challenges individually (hence two distinct issues) in order to progress. I've started to suggest approaches to each, on each issue thread separately.

I'd suggest prioritizing in adding SAVE/LOAD to EhBASIC as "traditional c" file-i/o is integrated into the cc65 environment. IMHO that seems manageable, once a clear understanding of (a) the memory map is available -and- (b) a clear understanding-of and skills-available on the assembler/compiler/linker/IDE tool-chain (i.e., map-files, interim assembly-from-c build-files, CMake, etc.) . In general, I'm not a stranger to these concepts, though I'm not agile (yet) in these specific rp6502 tools as others.

"Mixing C and [EhBASIC assembly] source" seems the way to go, as example source pieces are available in C and assembly. Importantly EhBASIC's source is assembly, and others have provided example in how to add new commands to EhBASIC at the assembly level. So focus on mixing assembly and C seems necessary.

Re:

do we just re-link in C and hope the compiler-assembler ties things in...?

IMHO, I think a clear understanding of both the C- and EhBASIC- memory maps, along with their shared memory resources (zero-page and page-FF) is a prerequisite.

Finally,
2. IMHO if SAVE/LOAD (or general file-i/o in EhBASIC) is solved as above, then adding graphics to basic will more easily fall out afterwards.

In other words: crawl, walk, then run....

[rumbledethumps]

I think you're underestimating the amount of work needed to mix C code with EhBASIC. I recommend some exploration before you make further plans. There's already vectors for SAVE and LOAD. Try calling puts() from one of those. i.e. Type SAVE and it prints Hello from C.

https://github.com/picocomputer/ehbasic/blob/32a2a04e4b047c6a751fa41cea36a9f24361dd5f/src/init.s#L58-L60

[linuxplayground]

Would it be simpler to implement save and load in assembly rather than having to include the c runtime?

My worry is that there will be overlap between the c runtime zeropage. First 20 bytes or so if I recall correctly.

At the very least the functions will have to back up zeropage before calling c functions.

I reckon it will be easier to just manipulate the ria registers in assembly...

[Hyenadae]

https://github.com/picocomputer/ehbasic/issues/2#issuecomment-1846239249

[netzerohero]

Hmm. Well... in-light of above comments, it may be better to code any EhBASIC enhancements in assembly. Locate them above EhBASIC's executable (above Label AA_end_basic but below $FF00. Initially the graphics plot enhancements can be coded in separate assembly file for possible inclusion w/ EhBASIC repo, then user can use BASIC's CALL command at runtime; example framework in EhBASIC manual pgs 27-29. Similar approach for SAVE/LOAD commands; hooks already available in init.s. Code the added SAVE/LOAD commands in assembly; locate above EhBASIC's executable. Should probably move EhBASIC's .org and Ram_top down from $D000 to something like $C000, providing ~5-kbyte enhancement-code space. Enhancement-code examples could first be coded in C (e.g., simpler versions of vruumllc's bitmap_graphics.c/h in his tetricks), then their interim assembly code inspected and reverse-engineered as a step prior to coding directly into assembly.

Here's an illustration of the affected memory map:

[linuxplayground]

Ram top at C000 is fairly common. Ehbasic is quite big already. Around 10kb IIRC. 16k may end up not being enough for all the graphics lib stuff. Would have to see.

I do miss memory banking on the picicomputer. The additional libs could be banked in when needed...

It's not terribly difficult to add new tokens to ehbasic. So instead of using call to access the new functions they can be implemented as builtin functions.

I've done it for BYE and CLS on my homebrew

[Hyenadae]

I did more messing around / thinking out loud back on the other thread,
https://github.com/picocomputer/ehbasic/issues/2#issuecomment-1848859588 in the next two posts.

So for the assembly filesizes, we should be able to fit in the functions to

1. Create variables to hold COLOR (xram write value), XPos and YPos
2. Set RIA address and addr STEP value
3. Clear XRAM fully using a 16-write-block loop
4. Preset color+pos to test values in new variables
5. Re-Set RIA write address to screen position with an offset (see num4)
6. Write color value to XRAM

Within... well, that ROM is 590 bytes before any work done to hook it into BASIC, so within ~700 bytes for those set to be tied in?

Now, if we include the code needed to actually init the screen for output, we create an additional 650 byte ROM
This one performs:

1. Set XREG for canvas size
2. Use/Call xram0_struct_set for vga_mode3_config (disable wrap, set xy offset pos to 0, set width and height to 320x180, set Xram data ptr & pallette)
3. Set xreg again for Mode 3

So, we could use up to 1500 bytes of our 'additional' 4K bytes just to finally have enough code to write to the screen. I'm assuming converting it from C-memory space assumption to BASIC will add or remove a few instructions for memory stuff and obviously addresses.
At least from there, we can recall the draw_pixel equivalent function for many of the future features

[netzerohero]

Great comments here and on the other EhBASIC graphics issue thread; great detective work!

Hyenadae - our thoughts are similar... only you're moving a lot faster! (I'm getting bogged-down in the IDE trying to get vscode-IDE/CMake turn on options like assembler listfiles and linker mapfiles.)
FWIW, I was able to get build-tools spit-out both an EhBASIC assembler listfile and linker mapfile to refine the memory map efforts:
cl65 -l listfile -m mapfile -vm XXX ~==~ ca65 -l listfile XXX ; ld65 -m mapfile -vm XXX
...so that may be of help to you especially for inspecting assembler code being generated if/as/when we add enhancement assembler-code above EhBASIC's executable. (Currently there is ~1600-bytes of spare available above EhBASIC.)

Refining my thoughts on approaching the two enhancements to EhBASIC:

1. Should move EhBASIC executable down in RAM from $D000 to $C000. (Provides over 5700-bytes for new assembly.)
2. Tabling SAVE/LOAD efforts for now;
3. Focusing on adding minimal graphics support (a. screen/canvas-init & b. minimal point-plot). These graphics-efforts can inform later SAVE/LOAD efforts.
4. As in days-of-old-before-C: EhBASIC will "own the machine" when running; no need to worry about co-existing with c-code/libraries once EhBASIC starts as a user-session.
5. Code-up in assembly two minimal graphics routines in a new fifth assembly Ehbasic sourcefile 'graphics.s'. Originate new code at $F900 (if using EhBASIC as-is at $D000.) In it have the two routines you've been distilling -- I'll use the old Apple-II commands just to represent the thoughts (new BASIC commands need not be these; BASIC tokens can be solved later): HGR -to initialize-graphics and HPLOT to plot-a-colored-point (see your earlier cross-post and this reference on Hi-Res Graphics).
6. Invoke the two new routines via BASIC CALLs per the initial guidance of the EhBASIC user guide. E.g.,
   10 LET HGR = <address of new HGR assembly routine provided via listfile>
   20 LET HPLOT = <address of new HPLOT assembly routine provided via listfile>
   30 LET MYCOLOR = <whatever value that works>
   40 CALL HGR : REM enable graphics mode/canvas, clears screen
   50 CALL HPLOT, MYCOLOR, 160, 90 : REM display a single pixel in center of mode-3 screen

That will allow us to focus on just that new graphics.s assembly file. (Adding new BASIC commands/tokens is easy enough as linuxplayground has mentioned; but that can be done later.)

7. Once we get the above in-place, iterate-and-refine. I'm sure a lot a stuff will start falling into place one we get these most fundamental of enhancements in-place.

[netzerohero]

Attached is initial attempt at "learning to crawl" following steps 2 - 7 above.
Adds a CLS command to demonstrate concepts; readme and test-program illustrate. EhBASIC remains located at $D000 as per memory-map.

Thanks extended to: @rumbledethumps, @Hyenadae, @linuxplayground, James-HoneyBadger and WojciechGw whose online dialog helped get to this point. Hope is: distilling @vruumllc example bitmap_graphics c-code can aid in filling out the graphic details. :)

EhBASIC_testcode_20231212.zip

[rumbledethumps]

https://github.com/picocomputer/ehbasic/tree/cc65mix (merged to main)
I made C code compatible with EhBASIC for only 118 bytes of runtime plus the C stack which I set for 256 bytes. This is only lightly tested.

[linuxplayground]

I had the same idea. Moved ram top down to c000 and then tried to implement load and save. I needed stdio which uses another 138bytes or so. I think I got save working but struggled with load.
I suspect I need to become a better C programmer.
It doesn't help that cc65 doesn't have ftell() so it's hard to figure out the size of the files.
We need that for fread(). I tried with looping over fgetc until eof but I don't think have my pointers arranged properly. I'd love to see you try it out.

You need to save data from the address pointed to by smeml up to address pointed to by svarl - 1.

To load a prg (tokenized basic) you start writing to address pointed to by smeml and then update svarl to be the last address written to + 1.

At the end of the load you have to call LAB_1477 to reset the exec pointers etc.

[netzerohero]

Interesting; sounds like some great progress! Curious, you decided to approach save/load using tokenized BASIC rather than ASCII? Would using ASCII help with the EOF at the end of a text-file BASIC source, so you'd would not need to know the "size of the files"? As I've been thinking about it (above 5-steps), I was contemplating using ASCII (mainly from a portability standpoint - ignoring speed of i/o, in today's world, tokenizing for saving bytes on large thumbdrives not an issue as when we had 140kbyte floppies.) SAVE using BASIC's internal LIST command; LOAD using ASCII-reads to BASIC's input-line-buffer line-by-line, terminate file-read upon EOF.

If it would be helpful to have a 2nd pair-of-eyes look over your c-code, I don't mind reading...

[linuxplayground]

I chose the memory dump option over the stream LIST to file because i thought it would be simpler. Maybe I'll have another look at it later today. Im just not sure how to go about it.

The LIST routine calls VecOUT which is a jump vector to aciaout defined in min_mon.s. I suppose I could alter acia_out to accept a stream pointer which will be stdout by default?

[netzerohero]

I'd think so: redirect the VecOUT/acia_out to however characters get sent to the file-system performed by the RIA. (The harder part in my current understanding.)

I started to think on this by taking "baby-steps" - I tinkered with coding-in-c the most simple of (for SAVE): open(), write(), close(). And also the buffered/stream version: fopen(), fwrite(), fclose() - for clues. Then reverse-engineer the resulting assembly, for eventual tie-in to EhBASIC assembly source. The hardest part I envision is having EhBASIC perform the "the file-system" set-up (open) and clean-up (close); I figured the redirecting BASIC's character output would be easy once the fundamental "write" c-calls were understood by redirecting character output vector to the RIA-HW. Going the other way in my mind would be symmetric; but would load via the line-input-buffer character-by-character (just as is done when loading via cut-n-paste on the console.

I "re-vectored" my efforts to study the simpler graphics-plot, to 1st improve my understanding of the c / assembly on this arch and the tools (which has been challenging). I'm viewing the symmetry of the two problems as nearly equivalent: set-up-resource, do-the-activity, clean-up-resource. I figure it would be first easier to get a point-on-screen via BASIC, than getting a character in a file, given my lack-of-understanding of the RIA-gatekeeper to each resource.

Now that @rumbledethumps merged the assembly / C worlds for EhBASIC...the problem of tying tightly-distilled-c routines with EhBASIC assembly should be easier; though I haven't wrapped-my-head fully around that yet.

Sorry for the long response; I hope it stimulates some constructive ideas....

[linuxplayground]

So for save all I did was add a savefile() routine in main.c. You can call any c function that's compiled with the code from assembly by adding an underscore to the name thusly : jsr _savefile

I went with a void function to start with to keep it simple and had my savefile() prompt for a filename.

Then the finickity part where you have to read pointers out of zeropage from within C.

Doing it this way keeps ehbasic modifications to a minimum. Just add _savefile to the save vector and import _savefile in the top of min_mon.s

[rumbledethumps]

It doesn't help that cc65 doesn't have ftell() so it's hard to figure out the size of the files.

All of stdio.h works.

[linuxplayground]

I must have been doing it wrong then.

[rumbledethumps]

I removed all the layers that supported EhBASIC being part of "a system of EPROMs" which recovered about 55 bytes for C/ASM. That allowed me to move everything out of page 2, where I recovered 256 bytes for BASIC. 48639 bytes free now. Up from 48383.

All the stuff that's low hanging fruit for me is done. I'll let you guys figure out connecting the internals.

Anyone needing to adjust the memory map should start in basic.cfg. This is the magick what weaves the two universes together.

[netzerohero]

I studied the new memory footprint for EhBASIC and its peaceful coexistence w/ C. Nice! (Really - that was a nice piece-of-work w/ the toolset.) Adding enhancements to EhBASIC should be much easier via C + linker instead of only using assembler.

I updated the memory-map spreadsheet.

[netzerohero]

Demonstration-code of initial graphic-plotting support to EhBASIC uploaded at cross-post.

Four new commands are available using EhBasic's "CALL" keyword. Plotting command callable from EhBASIC. The commands are:

• HGR - initialized the 320h x 180v x 8-bpp mode.
• HPLOT,x,y,color - paint a pixel of 'color' at x,y on the screen.
• TEXTMODE - return VGA-screen back to console/text mode
• CLS (or HOME) - clear the console/text screen.

[linuxplayground]

The earlier versions of min_mon.asm used a small vector table to reference monitor functions for input, output, load and save. The benefit of this approach is that the programmer should be able to change the values in the table to have basic go someplace different for those functions. This is especially easy to.do.on the picocomputer because it's all RAM.

My idea was to write a stub function that writes a byte given by an argument to an open file whose handler is a global variable.

Then a save routine could open the file for writing, change the input vector in the jump table to point to the file write byte function, call LAB_LIST and when that returns go ahead and revert the input vector to what it was to begin with.

I tried this out but once again I must have been missing something obvious.

[rumbledethumps]

You'll need the file descriptor for saving, which if 1 is STDOUT. No need to change vectors, just a file descriptor. If you want indirection, I recommend doing it in min_mon now. Let cc65 own it like the rest of page 2.

I checked in a stub for playing with USR(). The pdf manual has examples for this that might help you learn more about the internals.

[linuxplayground]

Yeah, I don't quite understand how I'm going to allocate a file descriptor and then some how update what sta RIA_TX is doing to use it. Because when LAB_LIST is called, it is going to use the standard voutp function from min_mon.
I'll wait for someone smarter than me to demonstrate how that works.

[netzerohero]

Previously (in the 'original' basic.s) the I/O structure was the following:

;  ...in a previous basic.s version....
; system dependant i/o vectors
; these are in RAM and are set by the monitor at start-up

V_INPT
      JMP   (VEC_IN)          ; non halting scan input device
V_OUTP
      JMP   (VEC_OUT)         ; send byte to output device
V_LOAD
      JMP   (VEC_LD)          ; load BASIC program
V_SAVE
      JMP   (VEC_SV)          ; save BASIC program

But the current (21-Dec-2023) version of min_mon.s has the following:

.export V_INPT, V_OUTP, V_LOAD, V_SAVE

V_OUTP:                       ; byte out to simulated ACIA
      BIT   RIA_READY
      BPL   V_OUTP            ; wait for FIFO
      STA   RIA_TX            ; save byte to simulated ACIA
      RTS
V_INPT:                       ; byte in from simulated ACIA
      BIT   RIA_READY
      BVC   LAB_nobyw         ; branch if no byte waiting
      LDA   RIA_RX            ; get byte from simulated ACIA
      SEC                     ; flag byte received
      RTS
LAB_nobyw:
      CLC                     ; flag no byte received
V_LOAD:                       ; empty load vector for EhBASIC
V_SAVE:                       ; empty save vector for EhBASIC
      RTS

What I think is being suggested is that there was value in the original indirection methods. Such indirection:

V_OUTP
      JMP   (VEC_OUT)         ; send byte to output device

...provides the versatility and flexibility that is being sought after.
Then VEC_OUT can be swapped as needed for routine character-output to the console; or for outputting to a file.

Likewise for each of the other hooks: VEC_IN, VEC_LD, and VEC_SV. Correct?

[linuxplayground]

Yeah and it's not hard for me to add the indirection back. It probably not necessary if I do the save and load in C.

I'm still lost as to how to reassign stdout's file descriptor to that of a file. Google suggests dup2() which is not implemented in cc65.

But yeah, have a look at this writeup.

https://www.steckschwein.de/post/ascii_save_ehbasic/

They have fat32 in their bios and its a handy kernel call for them.

[rumbledethumps]

You don't assign file descriptors, you get them from open() or unistd.
fd=STDOUT_FILENO; // unistd.h
fd=open("foo.bas",O_WRONLY|O_CREAT|O_EXCL);
bw=write(fd,&ch,1); // or write_xstack()

https://www.techytalk.info/linux-system-programming-open-file-read-file-and-write-file/

[rumbledethumps]

Troy Schrapel got EhBASIC doing save/load and gfx on his "56" project.
https://github.com/visrealm/hbc-56/tree/c99cf4b46f9de9c8820305d4d438bf4ade1c400f/code/6502/basic

His internals aren't useful to us, but how he hooked them up is.

[linuxplayground]

Yeah, he has a magic memory address at $7F05 which he can read from or write to which accesses the next byte on the open file.

[rumbledethumps]

picocomputer/ehbasic@main...saveload (merged)

SAVE is working on the saveload branch but without any error checking yet.

[netzerohero]

@n9jcv - good thinking trying another repo/build (Adventure) for fault isolation. You mentioned your environment is Windows (broken builds), but we know linux environment works. I also noticed in the python-script diffs mods related to CR / LF (though I'm far from a python expert). So this seems to reinforce issue is between Windows-environment and linux. So you may try inspecting the diffs in the python script for clues. (To this day we are cursed with those long-ago decisions of CP/M / unix / linux having one way vs MS going another way for end-of-lines and the slash \ back-slash for file directories.)

[n9jcv]

@netzerohero thanks for the tips. I am trying different things and MAY be closer now. I am a newbie at all this.

I took the basic.rp6502 that was released, installed it and ran basic. Now basic says - Enhanced BASIC 2.22p5. When I try save or load however I get a syntax error. Not sure why???

Should the command just be;
Save test.bas
?

[netzerohero]

Put double-quotes around the filename:

SAVE "TEST.BAS"

same for LOADing - use double-quotes.

[n9jcv]

AHHH thank you!!! @netzerohero @rumbledethumps

I FINALLY can compile and run ROMS. I added n9jcv to the version and it displayed as proof. Save and Load are GREATLY appreciated!!

I stayed up very late last night working to get a good dev environment. Ended up restoring my machine to a point before all this fun started. Went thru the setup again, trying to check each step. Had to reboot a few times, Restart vscode and eventually I got this clean compile. Thank you both for listening and I am sorry to have created such a wall of text here LOL 😆

[netzerohero]

Super! - Glad you persevered and it all worked out.

[netzerohero]

SAVE is working...
Load works too.

Snapshot combining above w/ experimental plotting working; binaries here.

[rumbledethumps]

Do you want to release this from ehbasic-plus?

[netzerohero]

Yes. I wanted to capture and do-a-release from what I initially know and have working -- before I wrap-my-head around new (to me) git/GitHub-workflow mechanics. I recognize there were some changes on the new ehbasic-plus (albeit minor) and didn't want to have too many changes all at once. Now I can start thinking on working within the ehbasic-plus framework.

[netzerohero]

Do you want to release this from ehbasic-plus?

Accomplished.

[vruumllc]

@netzerohero, I finally got a chance to check out the plotting. Good job!

Could you get rid of the 8-bit parameter limit if you made them keywords, rather than use the CALL mechanism?
If so, I'd vote for doing that.

But really, what you have already is very nice. And SAVE and LOAD are wonderful, @rumbledethumps.

[netzerohero]

Thanks! I leaned heavily on your graphics library, stripping it to the barest minimum to figure the display out. So thanks for that. The vga-pico canvas/plane programmer's interface is difficult; not user-friendly; albeit versatile. I eventually got my 1-dot on the screen, playing tetricks when I needed a break. :)

Yes - using keywords rather than CALL will get beyond the 8-bit parameter limit.