Jeff's Retrocomputer

Dr_Acula · 2012-06-11 17:19

I've been checking out Jeff's board and Basic over on Gadget Gangster http://www.gadgetgangster.com/news/56-jeffs-shop/546-retro-style-pocket-mini-computer.html

All pretty nifty!

Looking at the code, it looks like there is 12k free for code space. Considering space is needed for the VGA buffer and all the code running things, that is pretty impressive given the memory constraints of the propeller memory.

Is the source for the Basic interpreter available? On the links I could only find binary files.

All in all a very clever propeller demo. Well done to all those involved.

kuroneko · 2012-06-11 17:48

Dr_Acula wrote: »

Is the source for the Basic interpreter available? On the links I could only find binary files.

PropellerPowered Files Archive

Oldbitcollector (Jeff) · 2012-06-11 17:55

Thanks @kuroneko!

More specifically, here

Dr_Acula · 2012-06-11 18:03

Thanks - that looks great. I see you shoehorned in TinySynth as well.

What an amazing project!

The 'core' of the program is the texec function - that processes all the lines.

I've just been writing a whole lot of string drivers for the touchscreen board. It has taken a few weeks and hasn't been very exciting as there is nothing to really show for it as yet. But there is now a library of string drivers that work with external ram. Some things like loading a file off SD card and into a string array can be done with one instruction. Useful for reading files into a text editor, or reading in and processing .ini type files. External string arrays are very useful as there is up to a megabyte of space for strings. I've got this idea that instead of the code in this thread fetching each line from hub ram, it can fetch each line from external ram. That is just one instruction per line to fetch. Programs could be thousands of lines long.

And another crazy idea - many lines of code in Basic are rather similar to Spin. There could be scope for a spin interpreter as well. It could be one path to big (albeit slow) spin.

Back to coding...

David Betz · 2012-06-12 08:12

Is this a FemtoBasic variant or a new implementation of Basic for the Propeller?

jazzed · 2012-06-12 09:06

Doing nice things with credit to predecessors:

'' Propeller VGA BASIC COLOR V2.2
'' By Jeff Ledger
''
'' Do not attempt to grab objects from this package as many have been
'' altered to remove methods which were not used in this project to
'' conserve all possible memory for the BASIC enviroment.
''
''This software would not have been possible without help and contributions from:
''* Mike Green (FemtoBASIC)
''* Tomas Rokicki (FemtoBASIC, & FSWR)
''* Marko Lukat (Despair & Hope VGA driver)
''* Pat Daderko (Wii Controller driver)
''* Johannes Ahlebrand (TinySynth)
''* Michael Park (Edit)

Maybe Andre' can use it.

Oldbitcollector (Jeff) · 2012-06-12 09:18

From the first page of the PDF manual..

PROPELLER COLOR BASIC V2
 Introduction:
PROPELLER COLOR BASIC is a software &#8220;fork&#8221; of a project called FemtoBASIC,
written by Mike Green.This version of BASIC is remarkably different from the Femto
 project as it includes capabilities which have become available after its original release.
 This project has many contributors who have shaped the capability of this release.
 Without their code contributions, Propeller Color Basic wouldn&#8217;t have been possible.
 &#8226; Mike Green
 &#8226; Tomas Rokicki
 &#8226; Marko Lukat
 &#8226; Pat Daderko
 &#8226; Johannes Ahlebrand
 &#8226; Michael Park

I really felt it was important to credit all of the code contributions up front. If I've missed anyone, please let me know.

I'm seriously considering a version of this which uses the 32K SRAM for program storage, but I've got two other required projects to finish as well as three other demo projects on my list before I'll get to it. One of the interesting things that the SRAM addition would do is create the necessity for PEEK, POKE, and DATA statements, so I'm pretty excited about getting into it soon.

OBC

David Betz · 2012-06-12 09:39

jazzed wrote: »

Doing nice things with credit to predecessors:

'' Propeller VGA BASIC COLOR V2.2
'' By Jeff Ledger
''
'' Do not attempt to grab objects from this package as many have been
'' altered to remove methods which were not used in this project to
'' conserve all possible memory for the BASIC enviroment.
''
''This software would not have been possible without help and contributions from:
''* Mike Green (FemtoBASIC)
''* Tomas Rokicki (FemtoBASIC, & FSWR)
''* Marko Lukat (Despair & Hope VGA driver)
''* Pat Daderko (Wii Controller driver)
''* Johannes Ahlebrand (TinySynth)
''* Michael Park (Edit)

Maybe Andre' can use it.

Maybe. Does it have dynamic strings? Does it support floats? Does it have modern control structures and functions/subroutines with parameters? Will it run on the dsPIC33?
Andre' has quite a long list of requirements. :-)

David Betz · 2012-06-12 09:40

Oldbitcollector (Jeff) wrote: »
From the first page of the PDF manual..
PROPELLER COLOR BASIC V2
 Introduction:
PROPELLER COLOR BASIC is a software &#8220;fork&#8221; of a project called FemtoBASIC,
written by Mike Green.This version of BASIC is remarkably different from the Femto
 project as it includes capabilities which have become available after its original release.
 This project has many contributors who have shaped the capability of this release.
 Without their code contributions, Propeller Color Basic wouldn&#8217;t have been possible.
 &#8226; Mike Green
 &#8226; Tomas Rokicki
 &#8226; Marko Lukat
 &#8226; Pat Daderko
 &#8226; Johannes Ahlebrand
 &#8226; Michael Park
I really felt it was important to credit all of the code contributions up front. If I've missed anyone, please let me know.

I'm seriously considering a version of this which uses the 32K SRAM for program storage, but I've got two other required projects to finish as well as three other demo projects on my list before I'll get to it. One of the interesting things that the SRAM addition would do is create the necessity for PEEK, POKE, and DATA statements, so I'm pretty excited about getting into it soon.

OBC

I noticed that you credited Mike Green so I assume it has some relationship with FemtoBasic but I was wondering if the actual Basic engine itself was FemtoBasic or if you've done substantial rework of the interpreter? I guess I should look at the code and find out for myself! :-)

Oldbitcollector (Jeff) · 2012-06-12 09:46

I haven't touched the engine yet... That'll happen when I start adding the SRAM support.

OBC

schill · 2012-06-12 09:49

Oldbitcollector (Jeff) wrote: »

I'm seriously considering a version of this which uses the 32K SRAM for program storage, but I've got two other required projects to finish as well as three other demo projects on my list before I'll get to it. One of the interesting things that the SRAM addition would do is create the necessity for PEEK, POKE, and DATA statements, so I'm pretty excited about getting into it soon.

Take your time. As long as it's all done in time to demo at UPEC.

David Betz · 2012-06-12 09:51

Oldbitcollector (Jeff) wrote: »
From the first page of the PDF manual..
PROPELLER COLOR BASIC V2
 Introduction:
PROPELLER COLOR BASIC is a software &#8220;fork&#8221; of a project called FemtoBASIC,
written by Mike Green.This version of BASIC is remarkably different from the Femto
 project as it includes capabilities which have become available after its original release.
 This project has many contributors who have shaped the capability of this release.
 Without their code contributions, Propeller Color Basic wouldn&#8217;t have been possible.
 &#8226; Mike Green
 &#8226; Tomas Rokicki
 &#8226; Marko Lukat
 &#8226; Pat Daderko
 &#8226; Johannes Ahlebrand
 &#8226; Michael Park
I really felt it was important to credit all of the code contributions up front. If I've missed anyone, please let me know.

I'm seriously considering a version of this which uses the 32K SRAM for program storage, but I've got two other required projects to finish as well as three other demo projects on my list before I'll get to it. One of the interesting things that the SRAM addition would do is create the necessity for PEEK, POKE, and DATA statements, so I'm pretty excited about getting into it soon.

OBC

The version that uses the 32k SRAM sounds very cool. In fact, this whole project sounds very nice. Unfortunately, I don't have the VGA board to try it.

Ahle2 · 2012-06-12 12:59

@OBC

199: 'FILTER
                 a:=expr
                 fil:=a*21

That doesn't make any sense! What's up with "fil:=a*21" ?
"fil:=a" makes more sense, but only a value of 0 to about 12 gives audiable results. more than 12 will give a cutoff frequency so low that almost nothing will get trough.

I can't see a token to set the decay rate, that's more important than be able to set the attack rate.

Btw, did I say that I really like this project?

pedward · 2012-06-12 13:07

Oldbitcollector (Jeff) wrote: »

From the first page of the PDF manual..

I'm seriously considering a version of this which uses the 32K SRAM for program storage, but I've got two other required projects to finish as well as three other demo projects on my list before I'll get to it. One of the interesting things that the SRAM addition would do is create the necessity for PEEK, POKE, and DATA statements, so I'm pretty excited about getting into it soon.

OBC

I would recommend staying away from the SRAM, since it's not part of most Prop boards. However, I think it would be useful to make it use the upper 32KB of EEPROM that most boards *do* have.

If you wrote a smart cache driver for it, you could get reasonable performance.

If you tokenized the BASIC first, then stored the tokens, and when editing it, "decompile" the tokens into the editor, that would save space.

Oldbitcollector (Jeff) · 2012-06-12 13:11

Ahle2 wrote: »
@OBC
199: 'FILTER
                 a:=expr
                 fil:=a*21
That doesn't make any sense! What's up with "fil:=a*21" ?
"fil:=a" makes more sense, but only a value of 0 to about 12 gives audiable results. more than 12 will give a cutoff frequency so low that almost nothing will get trough.

I can't see a token to set the decay rate, that's more important than be able to set the attack rate.

Btw, did I say that I really like this project?

LOL! Thanks for the feedback! There is a token to set decay, but it's buried in a another section above the other commands. (It replaced an original Femto command which I retired)

I need to find a way to get the newer version of your TinySynth into this. I'm counting every byte as this point.

OBC

Ahle2 · 2012-06-12 13:17

Even if you can set the decay rate somewhere, I can't understand how it can make any difference.... see snippet below

197: 'NOTEOFF
                 synth.noteOff(0)

LOL

Oldbitcollector (Jeff) · 2012-06-12 13:36

Very true.. Thinking about that.. yes, that deserves a fix!

Would you like to collaborate on the fixes? I'm musical enough to play bananas, but that's about the extent of my expertise..

Edit Fixed! http://forums.parallax.com/showthread.php?140194-PROPELLER-COLOR-BASIC-(was-VGABASIC)

Dr_Acula · 2012-06-12 22:23

@pedward

If you tokenized the BASIC first, then stored the tokens, and when editing it, "decompile" the tokens into the editor, that would save space.

That sounds interesting. I think that might have been how Micro-Soft MBASIC worked back in the 1970s. The conversion to tokens would be done as each line is entered on the editor so the time delay would not be great there. I recall you could save and load off the disk in the tokenized format (faster) or as proper text (slower and larger but able to be edited by another text editor). I think it was SAVE "MYFILE" or SAVE "MYFILE",A and loading would read either format.

OBC already has tokens in the code with the numbers he uses.

pedward · 2012-06-12 22:43

It wasn't until QBasic that programs were stored as ASCII, my recollection is that all previous MS basic variants used a tokenized binary format (basica, gwbasic, etc).

Jeff's Retrocomputer

Comments