Don't get too excited. This work is derived from various other BASIC interpreters that I wrote for P1. I'd like to try to get it to generate PASM instead of byte code this time though. I don't have any illusions that people will actually use this thing. It's just a fun project at present. I'll try to make it easy to add functions to interface to hardware though so it would be possible to use it in some of the same ways that Femto BASIC was used. However, Taqoz is much better for that. Also, as has been mentioned elsewhere, the P2 has enough RAM that more standard languages may be possible like MicroPython, Javascript, or Lua.
How does that compare with ersmith's Basic or Bean's Basic ?
Don't get too excited. This work is derived from various other BASIC interpreters that I wrote for P1. I'd like to try to get it to generate PASM instead of byte code this time though. I don't have any illusions that people will actually use this thing. It's just a fun project at present. I'll try to make it easy to add functions to interface to hardware though so it would be possible to use it in some of the same ways that Femto BASIC was used. However, Taqoz is much better for that. Also, as has been mentioned elsewhere, the P2 has enough RAM that more standard languages may be possible like MicroPython, Javascript, or Lua.
How does that compare with ersmith's Basic or Bean's Basic ?
Yes swap file is normally part of windows. If anything Linux copied the idea.
Er, no. Linux took it from Unix, and from the best method used there. Window's "swap" file was rather primitive compared to the *nix way, and still is to some degree I believe. As far as I know there's never been any idea in Windows which was later copied into Linux or Unix. There are some compatibility tools - the ability to mount Windows filesystems, and the Wine project to execute Windows binaries.
As for a RAM drive - it's possible to have RAM not generally available for the OS and use that for a RAM drive.
I sure hope Chip didn't start this thread due to some issue updating Prop Tool...
I know in the past it was said that the Prop Tool could not be updated due to some third party component...
I'm getting by with my SpinEdit, but it's nowhere near as polished as Prop Tool...
I suggested to Chip that after the P2 is fully up and running (with x-platform tools and a substantial library to get new users up and working quickly) that it might be fun for him, and appreciated by many Parallax customers, to create a P2BASIC interpreter -- a BASIC Stamp on steroids.
I suggested to Chip that after the P2 is fully up and running (with x-platform tools and a substantial library to get new users up and working quickly) that it might be fun for him, and appreciated by many Parallax customers, to create a P2BASIC interpreter -- a BASIC Stamp on steroids.
Yeah, that would be cool. Even a P1BASIC interpreter could have been a big step up from the BS2. There was a SpinStamp for a while but I don't think they ever developed a version of PBASIC that worked with it. I still have a couple that I'm about to give away.
I kinda got hung up on whether to support line numbers or not... Then realized might be over my head there... Would have to just copy Femto…
Line numbers solve the problem of needing a full-screen editor, which creates a lot of hardware dependencies. They allow you to make sensible program edits with only a dumb terminal that understands no special character except ENTER. They are also a trap of course, but it is line numbers that made it possible to implement Tiny Basic in as little as 1K of program code. (I once seriously considered porting Tiny Basic to the P1, but feature creep quickly collided with reality.)
I kinda got hung up on whether to support line numbers or not... Then realized might be over my head there... Would have to just copy Femto…
Line numbers solve the problem of needing a full-screen editor, which creates a lot of hardware dependencies. They allow you to make sensible program edits with only a dumb terminal that understands no special character except ENTER. They are also a trap of course, but it is line numbers that made it possible to implement Tiny Basic in as little as 1K of program code. (I once seriously considered porting Tiny Basic to the P1, but feature creep quickly collided with reality.)
I used a line number based editor for my P1 BASIC interpreters but the language didn't use the line numbers. It had symbolic labels. The editor could have been replaced by a GUI but I never wrote one.
kg1,
Sorry, I was wrong, it appears you can't cross compile to non-windows platforms with MSYS2, but the source code you write and compile with it should compile without issues on other platforms with gcc (or compatible) toolchains. For OpenSpin I only compile the windows binaries myself, and David Zemon's team city stuff compiles the other platforms from the same source.
I kinda got hung up on whether to support line numbers or not... Then realized might be over my head there... Would have to just copy Femto…
Line numbers solve the problem of needing a full-screen editor, which creates a lot of hardware dependencies. They allow you to make sensible program edits with only a dumb terminal that understands no special character except ENTER. They are also a trap of course, but it is line numbers that made it possible to implement Tiny Basic in as little as 1K of program code. (I once seriously considered porting Tiny Basic to the P1, but feature creep quickly collided with reality.)
I used a line number based editor for my P1 BASIC interpreters but the language didn't use the line numbers. It had symbolic labels. The editor could have been replaced by a GUI but I never wrote one.
Separating the line numbers from the function of jump and call targets helps a lot with the inevitable need for a renumbering function, but it also means you're not using mnemonic line numbers so targeting parts of the program for listing and editing becomes more arbitrary.
I kinda got hung up on whether to support line numbers or not... Then realized might be over my head there... Would have to just copy Femto…
Line numbers solve the problem of needing a full-screen editor, which creates a lot of hardware dependencies. They allow you to make sensible program edits with only a dumb terminal that understands no special character except ENTER. They are also a trap of course, but it is line numbers that made it possible to implement Tiny Basic in as little as 1K of program code. (I once seriously considered porting Tiny Basic to the P1, but feature creep quickly collided with reality.)
I used a line number based editor for my P1 BASIC interpreters but the language didn't use the line numbers. It had symbolic labels. The editor could have been replaced by a GUI but I never wrote one.
Separating the line numbers from the function of jump and call targets helps a lot with the inevitable need for a renumbering function, but it also means you're not using mnemonic line numbers so targeting parts of the program for listing and editing becomes more arbitrary.
True. I guess you could still use ranges of line numbers to partition your program even though they can't be used as GOTO targets. I guess it also would be pretty easy for me to allow line numbers for GOTO as well. One problem though is that I don't have any concept of GOSUB. All subroutines/functions are named and can take parameters and return a value. I've tried to stick with VB syntax where I can but I can't say I like it very much.
Comments
How does that compare with ersmith's Basic or Bean's Basic ?
Mike
As for a RAM drive - it's possible to have RAM not generally available for the OS and use that for a RAM drive.
I know in the past it was said that the Prop Tool could not be updated due to some third party component...
I'm getting by with my SpinEdit, but it's nowhere near as polished as Prop Tool...
MSYS2 only compiles for MS Windows?
What addition steps are necessary to produce a binary for other OS?
Line numbers solve the problem of needing a full-screen editor, which creates a lot of hardware dependencies. They allow you to make sensible program edits with only a dumb terminal that understands no special character except ENTER. They are also a trap of course, but it is line numbers that made it possible to implement Tiny Basic in as little as 1K of program code. (I once seriously considered porting Tiny Basic to the P1, but feature creep quickly collided with reality.)
Sorry, I was wrong, it appears you can't cross compile to non-windows platforms with MSYS2, but the source code you write and compile with it should compile without issues on other platforms with gcc (or compatible) toolchains. For OpenSpin I only compile the windows binaries myself, and David Zemon's team city stuff compiles the other platforms from the same source.
Separating the line numbers from the function of jump and call targets helps a lot with the inevitable need for a renumbering function, but it also means you're not using mnemonic line numbers so targeting parts of the program for listing and editing becomes more arbitrary.