Sorry again, I cruised past the documentation to fast to spot that page.
SOB=Spin Object Binary, as I guessed.
So why do we want a library of binary blobs. If anyone wants to keep their code closed source, well, I feel they can keep their code on their own WEB site.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@heater,
I think OBC was going for the convenience of having the objects pre-compiled (saving time), but certianly both yourself and mpark have pointed out that providing the source code is the best solution.
Having worked many traumatic years as a technical writer, I have very little confidence in my ability to convey information effectively. Nevertheless, I have done my duty and written Sphinx documentation, which is now available at www.sphinxcompiler.com. I welcome all questions and comments.
Also on the site, some new downloads: a slightly improved ed, a bug fix for del, and some Sphinx-PC file transfer programs in C#.
I haven't yet tried it out, but it sound's great! I agree with rockicki's comment about a spin interactive shell.
My question is this: What happens to the assembly code in the DAT section? I haven't seen reference to this yet?
Does it actually assemble too?
What happens to the 8bit fonts that have schematics/etc in them? Is this stuff in unicode that is not handled by sphinx and has to be edited out ahead of time?
It does assemble PASM in DAT sections. It can compile, for example, the Parallax tv and graphics drivers, both full of PASM.
Sphinx can't handle files containing those fancy schematic characters, sorry. I haven't looked into Unicode support but maybe I should, at least for the compiler. But then ed would need updating, and who knows about Preditor? So for now just stick with ASCII.
Love this mpark. Spent a good part of the last couple of days playing with it. Just a quick question though. Any to make it work with pal tvs? The display I'm using will display ntsc but only in greyscale. I tried changing the mode in sxtv to set up pal but it didn't work (looked like it lost sync). Any other suggestions?
I was hoping to maintain PAL compatibility (though I have no way to test) but I guess I failed. Sxtv is a hacked version of the standard tv driver so in theory it should do PAL just as well as the tv object does. I tried to leave all the low-level NTSC/PAL stuff alone, but in the process of modifying it I know I messed things up. Unfortunately, I don't understand the details well enough to figure out where I went wrong.
Basically my only suggestion would be to do a diff between tv and sxtv and look for differences in the video generation code. There's a point where I have to set the Z flag explicitly rather than let the code figure it out from the mode; maybe if you can find out why and correct that, the PAL parts will fall into place too..? Oh, there are some places where I commented out some xors and such. Those are probably more important for PAL.
I guess another possibility would be to start with a working copy of tv and step-by-step transform it into sxtv, making sure it still works at each step.
mpark said...
Scripts would be nice but I don't know how to implement them. Keep in mind that Sphinx doesn't have a real "operating system" (it kinda looks like it does, but it's faking it). I should look into how a real OS does it and see if I can fake it in Sphinx. Largos might be ready before I get to it, though.
I had been thinking about the "batch processing," and have tried to think of a good suggestion.
[noparse][[/noparse]Edit:]You could·change the main sphinx appliction to read the keyboard input or loaded in from a batch file and look for a DOS-like "errorlevel" to be returned in a rendezvous point of some kind (so that it knows to either continue processing, or stop).· Something like that might at least·get a·"make.bat" for compiling.
To keep the buffer as small as possible, if it was executing a batch file, you could have the system possibly store a pointer to where it was in the file, and read in the "next command" (filling the keyboard buffer automatically) as needed [noparse][[/noparse]Edit:] maybe 4 longs (8 bytes for batch file name (minus the '.BAT'), with a word for position, and another errorlevel?)· When it reached the 'end' of the batch file, you could have it clear the 'name' (as an indication that the batch file was completed), and go back to keyboard input.
May I fork your project for a PropDOS version of this? I'm not as interested in the specialized
drivers as I am interested in it's ability to compile binaries for direct us with the standard driver sets.
Just let me know what limitations you would like me to stay in on this...
@OBC,
Are you planning on just including 'LEX" / "CODEGEN" / "LINK" as commands in PropDOS? If they will all 'fit' in a specialized version then that would work, but might be tight on memory.
You might want to consider some of the SphinxOS concepts, like having 'OS Aware' applications that can read the command line. Supporting command-line arguments (etiher the Sphinx method - via a file, or via a memory location, as suggested by Ariba a long time ago)·could help reduce the memory 'overhead.'·Having PropDOS managing the video (SphinxOS-style) for 'OS Aware' (console) applications would at least give the "feel" of a command shell.
Although, they cut out the part where Mike says,"..OK I've prepared some slides..let me open Propeller Point.." at which point he then types PP and hits enter at his prop terminal and it opens up to his presentation!
FYI ...
There's a bug in DEL, possibly other utilities where ReadString reports "string too long" for file names on the command line that are maximum size ("12345678.123"). I think ReadString includes the terminating zero byte in the maximum byte count.
Work in progress ...
I almost have the Meta2 Compiler-Compiler running under Sphinx. I think it'll take a couple of days to finish and test it.
I guess this is a good time for a public service announcement: Copy important files off the SD card regularly. You never know what Sphinx will do to them.
As Mike says, it *should* work. Unfortunately, there is the occasional weirdness. I am beginning to suspect that my code might not be 100% perfect. Maybe one day I'll figure out what's what, but for now, be prepared to reformat.
Mike Green said...
FYI ...
There's a bug in DEL, possibly other utilities where ReadString reports "string too long" for file names on the command line that are maximum size ("12345678.123"). I think ReadString includes the terminating zero byte in the maximum byte count.
Work in progress ...
I almost have the Meta2 Compiler-Compiler running under Sphinx. I think it'll take a couple of days to finish and test it.
A big thank-you to Dr. Mike for finding several Sphinx bugs. Del and dir were easy to fix, but Meta2 revealed a serious problem in the compiler, now (hopefully) fixed.
Here are the files needed to run Meta2 under the revised Sphinx compiler. There's a Read-Me file that shows how to use it. It behaves now like a true compiler-compiler in that it can compile itself (like the Sphinx compiler) through multiple generations (compile its source to Spin, compile and link the Spin, use the new binary file to do the next compile). What's useful about this is that Meta2 has been used to bootstrap other compilers like an extended Pascal compiler.
The concept is simply brilliant, with the rendevouz at the top of hub. The driver cogs remain resident and the main·buffers are inside the cog.
Why almost?
Well, it has a flaw. The parameter passing (specifically characters to the tv and from the kbd) use $0 to indicate done. This precludes substituting a serial interface as $0 cannot be used. I haven't examined the source yet. I am hoping it is actually using a word/long so we can use·-1 instead, so we can pass $0 as a valid character.
With the above resolved, we have a fantastic minimal footprint usable system where StdIn and StOut could be used for the kbd and tv or it's replacement, whatever that may be.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I have spent the afternoon getting Sphinx running on the TriBlade hardware and playing with it. It is FANTASTIC
Warning: I used the tv and keyboard connected to TriBlade's RAM pins, so this would cause a conflict. The same applies to RamBlade.
@mpark: Michael, this is simply brilliant. May I ask you to add to the·thread title·something similar to "Prop OS & compiler etc".
The only issue I can see is $00 is stripped in the keyboard and tv drivers which precludes using a serial port for these.
I am working on a 1-pin tv driver (just modifying the existing 1-pin driver·to suit) and a 1-pin keyboard driver. BTW, tv works with just the first 2 pins connected (white on black) for the sphinx screen - didn't try it to see what happens for "ed".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
SOB=Spin Object Binary, as I guessed.
So why do we want a library of binary blobs. If anyone wants to keep their code closed source, well, I feel they can keep their code on their own WEB site.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think OBC was going for the convenience of having the objects pre-compiled (saving time), but certianly both yourself and mpark have pointed out that providing the source code is the best solution.
Also on the site, some new downloads: a slightly improved ed, a bug fix for del, and some Sphinx-PC file transfer programs in C#.
I haven't yet tried it out, but it sound's great! I agree with rockicki's comment about a spin interactive shell.
My question is this: What happens to the assembly code in the DAT section? I haven't seen reference to this yet?
Does it actually assemble too?
What happens to the 8bit fonts that have schematics/etc in them? Is this stuff in unicode that is not handled by sphinx and has to be edited out ahead of time?
Thanks,
Doug
Sphinx can't handle files containing those fancy schematic characters, sorry. I haven't looked into Unicode support but maybe I should, at least for the compiler. But then ed would need updating, and who knows about Preditor? So for now just stick with ASCII.
Basically my only suggestion would be to do a diff between tv and sxtv and look for differences in the video generation code. There's a point where I have to set the Z flag explicitly rather than let the code figure it out from the mode; maybe if you can find out why and correct that, the PAL parts will fall into place too..? Oh, there are some places where I commented out some xors and such. Those are probably more important for PAL.
I guess another possibility would be to start with a working copy of tv and step-by-step transform it into sxtv, making sure it still works at each step.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Forum Search (Via Google)
with UTF-16 is always a pain.
Yeah, not smart. I blame my late-night alter ego. He's always leaving me strange bugs in the morning.
[noparse][[/noparse]Edit:]You could·change the main sphinx appliction to read the keyboard input or loaded in from a batch file and look for a DOS-like "errorlevel" to be returned in a rendezvous point of some kind (so that it knows to either continue processing, or stop).· Something like that might at least·get a·"make.bat" for compiling.
To keep the buffer as small as possible, if it was executing a batch file, you could have the system possibly store a pointer to where it was in the file, and read in the "next command" (filling the keyboard buffer automatically) as needed [noparse][[/noparse]Edit:] maybe 4 longs (8 bytes for batch file name (minus the '.BAT'), with a word for position, and another errorlevel?)· When it reached the 'end' of the batch file, you could have it clear the 'name' (as an indication that the batch file was completed), and go back to keyboard input.
Thoughts?
Post Edited (trodoss) : 7/8/2009 5:38:38 PM GMT
May I fork your project for a PropDOS version of this? I'm not as interested in the specialized
drivers as I am interested in it's ability to compile binaries for direct us with the standard driver sets.
Just let me know what limitations you would like me to stay in on this...
Thanks
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
@OBC, my understanding of the MIT license is that you can do whatever you like as long as you give credit where it's due, so by all means, go nuts.
Are you planning on just including 'LEX" / "CODEGEN" / "LINK" as commands in PropDOS? If they will all 'fit' in a specialized version then that would work, but might be tight on memory.
You might want to consider some of the SphinxOS concepts, like having 'OS Aware' applications that can read the command line. Supporting command-line arguments (etiher the Sphinx method - via a file, or via a memory location, as suggested by Ariba a long time ago)·could help reduce the memory 'overhead.'·Having PropDOS managing the video (SphinxOS-style) for 'OS Aware' (console) applications would at least give the "feel" of a command shell.
[noparse][[/noparse]Edit:] Ariba's post(s), mentioning his solution to passing command line arguments in RAM
http://forums.parallax.com/showthread.php?p=732656
http://forums.parallax.com/showthread.php?p=732725
Post Edited (trodoss) : 7/8/2009 9:59:11 PM GMT
Gee, the prop has really taken some fantastic strides in the past few months !!! Well done all
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1986 Chevy EL Camino·· No prop yet
1984 Suzukie GS1100GK No prop yet
http://www.youtube.com/watch?v=pqBEhP_ISlc
Although, they cut out the part where Mike says,"..OK I've prepared some slides..let me open Propeller Point.." at which point he then types PP and hits enter at his prop terminal and it opens up to his presentation!
That was awesome Mike!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Forum Search (Via Google)
There's a bug in DEL, possibly other utilities where ReadString reports "string too long" for file names on the command line that are maximum size ("12345678.123"). I think ReadString includes the terminating zero byte in the maximum byte count.
Work in progress ...
I almost have the Meta2 Compiler-Compiler running under Sphinx. I think it'll take a couple of days to finish and test it.
Original thread: http://forums.parallax.com/showthread.php?p=692011
However I have a strange bug for you.
I've copied dir.spn to dri.spn, and added a little bit of spin.
k: "isxkb"
in the obj section
and
cn++
if cn//13==0
term.str( @pressakey )
k.getkey
term.out( 13 )
in PrintDir, also adding cn local variable [noparse]:)[/noparse]
and when I try
cl dri
it gives the error
illegal character (UNICODE?)
1,38,'JJJJJJJJJ9RQ'
it has then corrupted dri.spn, to some random file.
I've added the whole file, just in case you can get it working on yours. ( I'll see if it works like this, if not I'll attach the file )
Cheers,
Baggers.
SXTVRENDEZVOUS = $8000 - 4 SXKBRENDEZVOUS = SXTVRENDEZVOUS - 4 SDSPIRENDEZVOUS = SXKBRENDEZVOUS - 3 * 4 SXFS2RENDEZVOUS = SDSPIRENDEZVOUS - 4 * 4 ' four rendezvous variables SXFSRENDEZVOUS = SXFS2RENDEZVOUS - 4 * 4 ' four rendezvous variables METADATABUFFER = SXFSRENDEZVOUS - 512 _free = ($8000 - METADATABUFFER) / 4 obj term: "isxtv" f: "sxfile" k: "isxkb" pub main | err err := \try if err > 0 term.str( err ) term.out( 13 ) elseif err < 0 term.str( string("error ") ) term.dec( err ) term.out( 13 ) f.Close f.Open( string("sphinx.bin"), "R" ) f.Execute( 0 ) con ARGSTRINGLENGTH = 12 ' 8 + . + 3 DIRSTRINGLENGTH = 11 ' 8 + 3 var byte argstring[noparse][[/noparse]ARGSTRINGLENGTH + 1] ' + null byte dirstring[noparse][[/noparse]DIRSTRINGLENGTH + 1] ' + null (terminator not strictly necessary, but convenient for debug printing) pri try f.Open( string("args.d8a"), "R" ) if f.ReadByte f.ReadString( @argstring, DIRSTRINGLENGTH ) else bytemove( @argstring, string("*.*"), 4 ) f.Close ExpandWildcards MyMount PrintDir pri ExpandWildcards | i, j i~ j~ bytefill( @dirstring, " ", DIRSTRINGLENGTH ) dirstring[noparse][[/noparse]DIRSTRINGLENGTH]~ repeat while argstring[noparse][[/noparse]j] if argstring[noparse][[/noparse]j] == "*" if i < 8 repeat dirstring[noparse][[/noparse]i++] := "?" until i == 8 elseif i < 11 repeat dirstring[noparse][[/noparse]i++] := "?" until i == 11 else abort string("bad wildcard") elseif argstring[noparse][[/noparse]j] == "." if i =< 8 i := 8 else abort string("filename too long") else if i < DIRSTRINGLENGTH dirstring[noparse][[/noparse]i++] := argstring[noparse][[/noparse]j] else abort string("filename too long") ++j con pCommand = SDSPIRENDEZVOUS pParam = pCommand + 4 pBlockno = pCommand + 8 pri readblock(n, b) ' ' Read a single block. The "n" passed in is the ' block number (blocks are 512 bytes); the b passed ' in is the address of 512 blocks to fill with the ' data. ' long[noparse][[/noparse]pParam] := b long[noparse][[/noparse]pBlockno] := n long[noparse][[/noparse]pCommand] := "R" repeat while long[noparse][[/noparse]pCommand] if long[noparse][[/noparse]pParam] abort long[noparse][[/noparse]pParam] return 0 pub writeblock(n, b) ' ' Write a single block. Mirrors the read above. ' long[noparse][[/noparse]pParam] := b long[noparse][[/noparse]pBlockno] := n long[noparse][[/noparse]pCommand] := "W" repeat while long[noparse][[/noparse]pCommand] if long[noparse][[/noparse]pParam] abort long[noparse][[/noparse]pParam] return 0 con SECTORSIZE = 512 SECTORSHIFT = 9 DIRSIZE = 32 DIRSHIFT = 5 con { long } _length = 0 { long } _leftInFile = 4 { long } _sopDir = 8 ' sector/offset "pointer" to directory entry { long } _sopTail = 12 ' sector/offset "pointer" to last cluster# in FAT chain { word } _cluster = 16 { word } _sector = 18 ' sector# within cluster; ranges from 0 to sectorsPerCluster-1 { word } _bp = 20 ' byte pointer (actually an index into the sector buffer); range [noparse][[/noparse] 0..511 ] _buffer = 24 SIZEOFIOBLOCK = SECTORSIZE + 24 dat long myMetadataBuffer byte 0[noparse][[/noparse] 512 ] myMetadataSector word -1 dirty byte 0 clusterShift byte 0 pri ReadMetadataSector( s ) if myMetadataSector == s return readblock( myMetadataSector := s, @myMetadataBuffer ) var word bytesPerSector byte sectorsPerCluster word reservedSectors byte numberOfFats word sectorsPerFat word numberOfRootDirectoryEntries long fat1[noparse][[/noparse] 0 ] long fatSector0 long dirSector0 long dataregion[noparse][[/noparse] 0 ] long dataSector0 pri PrintDir | s, p, c, cn s := dirSector0 repeat numberOfRootDirectoryEntries >> 4 p := @myMetadataBuffer repeat 16 ReadMetadataSector( s ) ifnot byte[noparse][[/noparse]p] return if byte[noparse][[/noparse]p] == $e5 p += 32 next if byte[noparse][[/noparse]p][noparse][[/noparse]$0b] & $0f == 0 and Match( p, @dirstring, 11 ) repeat 11 term.out( byte[noparse][[/noparse]p++] ) p -= 11 cn++ if cn//13==0 term.str( @pressakey ) k.getkey term.out( 13 ) term.out( " " ) term.dec( PeekL( p + $1c ) ) term.out( 13 ) p += 32 ++s pri Match( p, q, n ) | c1, c2 repeat n c1 := byte[noparse][[/noparse]p++] c2 := byte[noparse][[/noparse]q++] if "a" =< c1 and c1 =< "z" c1 += "A" - "a" if "a" =< c2 and c2 =< "z" c2 += "A" - "a" if c2 == "?" next if c1 <> c2 return false return true pri MyMount | pbrSector ,i pbrSector~ repeat ReadMetadataSector( pbrSector ) if bytecomp( @myMetadataBuffer+$36, string("FAT16"), 5 ) quit if pbrSector abort -20 ' not FAT16 pbrSector := PeekL( @myMetadataBuffer + $1c6 ) bytesPerSector := PeekW( @myMetadataBuffer + $0b ) sectorsPerCluster := myMetadataBuffer[noparse][[/noparse]$0d] clusterShift := >| sectorsPerCluster - 1 reservedSectors := PeekW( @myMetadataBuffer + $0e ) numberOfFats := myMetadataBuffer[noparse][[/noparse]$10] sectorsPerFat := PeekW( @myMetadataBuffer + $16 ) numberOfRootDirectoryEntries := PeekW( @myMetadataBuffer + $11 ) fatSector0 := pbrSector + reservedSectors dirSector0 := fatSector0 + numberOfFats * sectorsPerFat dataSector0 := dirSector0 + numberOfRootDirectoryEntries >> 4 pri bytecomp( p, q, n ) repeat n if byte[noparse][[/noparse]p++] <> byte[noparse][[/noparse]q++] return return true pri PeekW( a ) return byte[noparse][[/noparse]a++] + byte[noparse][[/noparse]a] << 8 pri PeekL( a ) return byte[noparse][[/noparse]a++] + byte[noparse][[/noparse]a++] << 8 + byte[noparse][[/noparse]a++] << 16 + byte[noparse][[/noparse]a] << 24▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I guess this is a good time for a public service announcement: Copy important files off the SD card regularly. You never know what Sphinx will do to them.
So I'm guessing your file driver doesn't like fragmented files?
Baggers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
A big thank-you to Dr. Mike for finding several Sphinx bugs. Del and dir were easy to fix, but Meta2 revealed a serious problem in the compiler, now (hopefully) fixed.
New versions of del.spn, dir.spn, codegen.bin, and methods.spn are available at http://www.sphinxcompiler.com/Home/downloads.
I have hopes of someday fixing the file system weirdness.
This is almost what I am after with a Prop OS
The concept is simply brilliant, with the rendevouz at the top of hub. The driver cogs remain resident and the main·buffers are inside the cog.
Why almost?
Well, it has a flaw. The parameter passing (specifically characters to the tv and from the kbd) use $0 to indicate done. This precludes substituting a serial interface as $0 cannot be used. I haven't examined the source yet. I am hoping it is actually using a word/long so we can use·-1 instead, so we can pass $0 as a valid character.
With the above resolved, we have a fantastic minimal footprint usable system where StdIn and StOut could be used for the kbd and tv or it's replacement, whatever that may be.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Warning: I used the tv and keyboard connected to TriBlade's RAM pins, so this would cause a conflict. The same applies to RamBlade.
@mpark: Michael, this is simply brilliant. May I ask you to add to the·thread title·something similar to "Prop OS & compiler etc".
The only issue I can see is $00 is stripped in the keyboard and tv drivers which precludes using a serial port for these.
I am working on a 1-pin tv driver (just modifying the existing 1-pin driver·to suit) and a 1-pin keyboard driver. BTW, tv works with just the first 2 pins connected (white on black) for the sphinx screen - didn't try it to see what happens for "ed".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm