Once I see the documentation I'll be able to determine if it makes sense to use the ROM monitor functions. One thing I'm looking at currently is a way to download files to the SD card from loadp2. Currently I have to first load a program that can write to the SD card, and then I send the file. If I can use the SD functions in the monitor I might be able to reduce the size of the download program.
Thanks. I can try using one of these functions but Dave will have to decide if he wants his library to use them.
(Re)using 'ROM' functions sounds good, but they are not really running in ROM, so the tools need to make that optional.
ie Tools also need some means to 'keep away' from the RAM where the 'ROM' is actually residing, after being unzipped, as well as protect the VAR spaces each ROM function expects to use.
Once I see the documentation I'll be able to determine if it makes sense to use the ROM monitor functions. One thing I'm looking at currently is a way to download files to the SD card from loadp2. Currently I have to first load a program that can write to the SD card, and then I send the file. If I can use the SD functions in the monitor I might be able to reduce the size of the download program.
I don’t have an SD write routine, nor file creation, in ROM.
Maybe TAQOZ might support this but i don’t know if you can call it.
Once I see the documentation I'll be able to determine if it makes sense to use the ROM monitor functions. One thing I'm looking at currently is a way to download files to the SD card from loadp2. Currently I have to first load a program that can write to the SD card, and then I send the file. If I can use the SD functions in the monitor I might be able to reduce the size of the download program.
I don’t have an SD write routine, nor file creation, in ROM.
Maybe TAQOZ might support this but i don’t know if you can call it.
TAQOZ is in low memory so that might be a problem. I don't think it's callable either. Too bad it couldn't have been relocated to high memory during the time between V1 and V2.
TAQOZ has to be in the bottom 64KB otherwise all the little calls would require an extra instruction to add an offset. Would be a big loss in performance.
TAQOZ has to be in the bottom 64KB otherwise all the little calls would require an extra instruction to add an offset. Would be a big loss in performance.
In my opinion, that would be a small price to pay for something that could remain in memory and coexist with a user program. The on-board language doesn't really have to be super high performance. It will mostly be used for poking at hardware during bringup. A high performance Tachyon interpreter can be loaded for real applications.
Taqoz is a possibility. I could have loadp2 reset the P2, invoke Taqoz, and then download a small Forth program to receive the file and write it to SD. I'll have to look into that.
TAQOZ has to be in the bottom 64KB otherwise all the little calls would require an extra instruction to add an offset. Would be a big loss in performance.
In my opinion, that would be a small price to pay for something that could remain in memory and coexist with a user program. The on-board language doesn't really have to be super high performance. It will mostly be used for poking at hardware during bringup. A high performance Tachyon interpreter can be loaded for real applications.
I think the other aspect was code size, not so much performance.
TAQOZ is now zipped/unzips to pack the absolute max into the serial ROM space.
The ROM serial IO routines sound like they will be useful in many cases, certainly for low rate terminal input from a user's keyboard etc. Main issue I see is at higher speed without buffering the application will have to call getch fast enough to avoid character drops. That needs to be factored in when choosing to use them or not. The string read mode being line buffered may allow faster rate data without drops if there are sufficient delays between lines for the application to process the line. Some terminal programs do allow line delays to be added in after each transmission which could help there too.
I think I found the problem with p2gcc and ebasic3. The linker isn't resolving a function address correctly that is being assigned to a function pointer. I have compiled other programs that use function pointers, but the functions were in the same file. It should be a simple fix, but I need to study it a bit more.
I think I found the problem with p2gcc and ebasic3. The linker isn't resolving a function address correctly that is being assigned to a function pointer. I have compiled other programs that use function pointers, but the functions were in the same file. It should be a simple fix, but I need to study it a bit more.
Thanks for the update. I'm afraid I got sidetracked on the p2gcc build working on the fastspin one. Ultimately, I'd like to get both working. My goal is to then work on an XBYTE-based byte code interpreter. I already have a PASM interpreter for P1 so I'll translate that. Then, once I understand XBYTE and its other associated instructions I'd like to tackle getting MicroPython working on the P2 with an XBYTE-based VM.
Oh yes that XBYTE thing is tempting. I am waiting for @Chip to work on Spin2 again, and hope to see some sources. By now I hadn't had time to investigate myself, I am still stuck with using smart pins, but getting there, this is fun.
It really would be nice if fastspin could compile to @Chip's bytecodes for P1 and P2 but I think that is very low on the list for fastspin.
And getting e-basic running would add a nice tool to the P2 toolset.
Oh yes that XBYTE thing is tempting. I am waiting for @Chip to work on Spin2 again, and hope to see some sources. By now I hadn't had time to investigate myself, I am still stuck with using smart pins, but getting there, this is fun.
Just as an FYI, there is an XBYTE interpreter for the ZPU instruction set at https://github.com/totalspectrum/zog, in the zog_p2.spin file. It's written for the old FPGA board and hasn't been updated for P2-ES; I don't think any code changes would be necessary, except perhaps for setting the clock speed and such.
(To make it somewhat relevant to this thread, I'm sure ebasic3 could be compiled with GCC for the ZPU and run on that emulator ).
It really would be nice if fastspin could compile to @Chip's bytecodes for P1 and P2 but I think that is very low on the list for fastspin.
I have a very long list for fastspin and not much time, I'm afraid .
I checked in a fix to p2link.c that fixes a problem with function pointers and functions in separate files. I can now run programs in ebasic3. There still seems to be a problem if an error is detected after typing "run". It prints out an error message that looks corrupted, and the whole basic program is cleared. Maybe a problem with setjmp/longjmp? I'll look into it.
EDIT: I compiled and ran it on my PC, and it has the same error message, and then it exits the program.
I checked in a fix to p2link.c that fixes a problem with function pointers and functions in separate files. I can now run programs in ebasic3. There still seems to be a problem if an error is detected after typing "run". It prints out an error message that looks corrupted, and the whole basic program is cleared. Maybe a problem with setjmp/longjmp? I'll look into it.
EDIT: I compiled and ran it on my PC, and it has the same error message, and then it exits the program.
That's great news! Can you post the program that produced the error?
I just typed in "10 for i=1", and then typed "run". I wanted to intentionally introduce an error to see what happens. However, I saw your posts on the fastspin thread, so now I understand the results. Running on the PC it does the right thing. It prints the "^" character instead of "s", and the program exits. Running with p2gcc it prints "s" and then restarts the program. I suspect there's an issue with setjmp/longjmp.
I wasn't familiar with using an "*" in the printf format. I Googled it, and it looks like a useful feature.
When I run that program fragment I get the error message with the errant "s" and then get dumped back in the editor where I can type "run" or "list" again or modify the program.
So what is the correct action? Should it exit the program or jump back to the editor?
EDIT: When I run it on the P2 it prints the error message, and then prints "ebasic3" as if the program restarted. The basic program is also cleared.
It should go back to the editor. Have you updated from GitHub recently? I get different behavior from what you describe. I don't see the whole program restart and print "ebasic3" again.
I got your latest code from GitHub, and it now returns back to the editor after printing the error message. The basic program is also retained. So everything looks good, except for maybe the positioning of the "^". Thanks.
I got your latest code from GitHub, and it now returns back to the editor after printing the error message. The basic program is also retained. So everything looks good, except for maybe the positioning of the "^". Thanks.
I'll work on the positioning of the "^". Thanks for your help in getting this working!
I fixed the caret on error messages printed by ebasic3. I didn't do it by fixing my implementation of vsprintf though. I just used the broken version differently.
VM_printf(" %*s^\n", c->tokenOffset, "");
Here is the result:
ebasic3 v0.01
10 for i=1
run
error: Expecting 'TO', found '<EOL>'
line 0
for i=1
^
OK
Edit: Looks like I still have a bug to fix though. The line number shouldn't be 0.
Comments
ie Tools also need some means to 'keep away' from the RAM where the 'ROM' is actually residing, after being unzipped, as well as protect the VAR spaces each ROM function expects to use.
Maybe TAQOZ might support this but i don’t know if you can call it.
I think the other aspect was code size, not so much performance.
TAQOZ is now zipped/unzips to pack the absolute max into the serial ROM space.
It really would be nice if fastspin could compile to @Chip's bytecodes for P1 and P2 but I think that is very low on the list for fastspin.
And getting e-basic running would add a nice tool to the P2 toolset.
Enjoy!
Mike
(To make it somewhat relevant to this thread, I'm sure ebasic3 could be compiled with GCC for the ZPU and run on that emulator
I have a very long list for fastspin and not much time, I'm afraid
EDIT: I compiled and ran it on my PC, and it has the same error message, and then it exits the program.
I wasn't familiar with using an "*" in the printf format. I Googled it, and it looks like a useful feature.
EDIT: When I run it on the P2 it prints the error message, and then prints "ebasic3" as if the program restarted. The basic program is also cleared.
VM_printf(" %*s^\n", c->tokenOffset, "");Here is the result:ebasic3 v0.01 10 for i=1 run error: Expecting 'TO', found '<EOL>' line 0 for i=1 ^ OKEdit: Looks like I still have a bug to fix though. The line number shouldn't be 0.