The following code compiles fine if the included file "nops.bin" is exactly 16K and the complete program it lives in has 3288 LONGS free.
BUT adding just a single byte to the included file "nops.bin" causes the compilation to fail with
"Object exceeds 32K"
This clearly cannot be. I was expecting an error about the FIT failing.
CON
zpu_memory_size = (16 * 1024) 'The size of ZPU memory area
DAT org 0
zpu_memory
file "nops.bin"
padding byte 0[noparse][[/noparse](zpu_memory_size) - (@padding - @zpu_memory)]
zpu_memory_end
fit (zpu_memory_size) / 4
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
I think I found another wee buggee:
The following code compiles fine if the included file "nops.bin" is exactly 16K and the complete program it lives in has 3288 LONGS free.
BUT adding just a single byte to the included file "nops.bin" causes the compilation to fail with
"Object exceeds 32K"
This clearly cannot be. I was expecting an error about the FIT failing.
CON
zpu_memory_size = (16 * 1024) 'The size of ZPU memory area
DAT org 0
zpu_memory
file "nops.bin"
padding byte 0[noparse][[/noparse](zpu_memory_size) - (@padding - @zpu_memory)]
zpu_memory_end
fit (zpu_memory_size) / 4
Umm.. it looks like you are doing this..
zpu_memory_size = 16384
Your file size is 16385
byte 0[noparse][[/noparse]16384 - 16385]
which becomes byte 0[noparse][[/noparse]4294967295]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
BradC: Good point, that's not the bug but this is :
CON
zpu_memory_size = (16 * 1024) 'The size of ZPU memory area
DAT org 0
zpu_memory
'file "nops.bin" 'A 16Kb file
byte 0[noparse][[/noparse]zpu_memory_size] 'A 16Kb array
file_end
byte 0[noparse][[/noparse]100] '<------- THIS SHOULD CAUSE FIT TO FAIL
zpu_memory_end
fit (zpu_memory_size / 4)
As above with the "file" statement commented out it correctly fails "PC exceeds cog memory by 25 longs"
BUT uncomment the "file" statement and comment the line below and it does not fail the FIT any more.
The file is 16K
heaterl@ddt:~/zog$ ls -l nops.bin
-rw-r--r-- 1 heater heater 16384 Feb 10 09:16 nops.bin
michael@ddt:~/zog$
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
By the way the error "PC exceeds cog memory by 0 longs" is disturbing until you realize 1 BYTE is 0.25 LONGS which rounds to 0 longs [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ahh yes, I see. When bstc imports binary data from FILE command, it omits incrementing the COG address pointer. I need to do some tests to see what the Parallax compiler might do in some odd alignment cases and have a closer look at fixing it.. Thanks! [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Second, I have a question.
In the installation guide (http://www.parallax.com/tabid/828/Default.aspx) it is mentioned that the serial adapter driver from FTDI must be installed.
Despite of this, here is what I've done:
(I use Kubuntu 9.10, 2.6.31-19-generic #56, x86_64)
So I tought that my kernel supports the chip.
So I installed the btc tool.
And found out that it worked, I was able to download programs to the propeller, as far I tried.
Is this means, that the guide is somewhat outdated at least for this kernel version, or I must install the driver from FTDI to ensure proper operation?
The guide on the Parallax site was written by Parallax and is geared toward Macintosh users.
As a rule, most Linux distributions manage to release kernels with working ftdi drivers out of the box, so there is no need to install anything to make it work. Provided your distribution has udev set up correctly then bst should find your prop plug out of the box. If you can detect your Propeller then you are good to go.
Linux and Mac users do have to install the proper font though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Ok, so the changes got too major to justify an 0.18.5 release, therefore we skipped straight to 0.19.
Changelog in top post as usual.
Major changes :
PropBasic Integration!
This would not have happened without the support of Bean (it is his compiler after all!), JonnyMac, Brian Riley, Mike Green and Anthony McGraw.
Any errors not related to the actual generation of correct SPIN code from BASIC source are probably mine, so don't go bugging Bean about it!
You need the -bst PropBasic binaries as there are some minor internal changes that mean it *WILL NOT WORK* with Bean's standard binaries. (Don't try, really.. bst will just stare at you blankly with that "Whatchoo talkin' 'bout Willis?" look on its face)
These are found at www.fnarfbargle.com/PropBasic and are versioned by Beans compiler revision with my svn commit number appended to the end. (I may do a number of intermediate releases in between Beans official releases as things develop).
You will need to go to Tools -> IDE Preferences -> PropBasic and select the path of your PropBasic-bst binary. If you select a binary it does not like, bst will simply ignore you. If you give it what it wants, you will be rewarded with a little pop up box telling you the revision number of the PropBasic compiler you have selected.
The only major missing features for this release are Syntax Highlighting and Archiving. They will both be implemented in a later release.
This release sees some behavioural changes required to get the integration as smooth as possible. One of these is with regard to syntax highlighting.
Previously bst would try and highlight any file you opened. Now, it will only apply spin highlighting to files with a .spin extension. This means if you were using .spinx or .pasm or any other extension, your files will no longer highlight as spin files. I'm considering a possibility for a user generated list of file extensions to recognise as spin files, but for this release I'm afraid it's fixed.
Unlike spin files, PropBasic files *must* be saved to disk prior to compiling. The compiler is a separate binary and will only read files from the disk. To make this as seamless as possible, when you try any form of Basic Compile, bst will save every tab with a modified basic file in it.
PropBasic can't cope with Unicode, so bst will convert any unicode characters it finds into '?' when the file is saved to disk. It will pop up a message box telling you it is doing this so you know your file has been changed. The process of the conversion means you *will* lose the undo history in any tab that has code that was converted, so make sure you know what you want to do before saving your file!
There is a "Compile Basic to Spin" item in the compile menu. This compiles the Basic code and opens (or refreshes if they are already open) the spin code in new tabs. These tabs are marked read-only and are not automatically saved to disk. If you save and modify these tabs, when you next perform a basic compile the code in the tabs will be refreshed from the new compile, and the tabs re-marked read-only.
The bst integration of PropBasic tries to follow the general "drop and run" philosophy of bst, so there are no intermediate files generated. There should be nothing left behind after a basic compile, and provided the spin code generated has no errors in it, you should not even know it was there. An F10 on a tab containing Basic code should compile and download seamlessly the same way Spin code does. If it doesn't, then I'd like to hear about it.
The other real major change is the way the Propeller Font is rendered under Windows XP. It *should* look a lot nicer now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
MacIntosh Users of BST may want to take a look at my tutorial on installing the new setup. I revised the old AppNote and renamed it AN-PROP002, complete with new screenshots, etc.
I have a downloadable Zip file which offers, in effect, 'one stop shopping.' It's 11.3 MB and has the bst/propbasic executables (bst 0.19/propbasic 80, the correct modified-for-Mac Parallax.ttf font file and the standard objects from the 1.2.7 Propeller Tool, with FloatString upgraded all in a folder structure ready to drop on your Applications folder.
The tutorial/AppNote and download links can be found at
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Brad: I just downloaded 0.19 and I thoughT my glasses were dirty. The new font is slightly fuzzy. Just to be sure, I ran the old version 0.18.5 and sure enough the font was crisp.
BTW is the latest compiler still 0.15.4-pre3 ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
Brad: I just downloaded 0.19 and I thoughT my glasses were dirty. The new font is slightly fuzzy. Just to be sure, I ran the old version 0.18.5 and sure enough the font was crisp.
Yes, I changed the way the fonts were rendered using Microsofts "ClearType". Wonderful isn't it?. Unfortunately it appears that different versions of windows handle it differently. Which one are you running?
BTW is the latest compiler still 0.15.4-pre3 ?
Yes it is, although Bean just pointed me at a bug I have to fix, so I'll be on that this weekend. I'll also revisit the font rendering *again* when I can get hold of some win32 machines to test on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Cluso99 said...
Brad: Vista. When I get time I will try it on my XP laptop.
If you could that would be great. I have access to a laptop now that dual boots Vista & XP so I can try some tweaks.
Back when bst was in its infancy there was a switch implemented in the IDE Preferences to enable/disable anti-aliased rendering. Somewhere along the line the original purpose for that got lost, but I noticed that Vista improved the font rendering by actually performing smoothing while XP just would not. When we were in the throes of 0.19-pre Jon observed that the font rendering on XP was naff (which it had always been) so I fiddled about until I got ClearType enabled and that seemed to fix things. Obviously it has made it noticeably worse on Vista.
What I've done is re-tweaked the "anti-alias editor fonts" switch in the IDE prefs, so in the next version you'll be able to turn that off and get back to the way things were in Vista pre 0.19.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
1. Permit Ctl-F10 to also compile and load (same as F10) so as to be compatible with PropTool. Any implications in this??
2. Could you do a "key" option (F12 ??) for compile, if no errors download to Ram and then automatically switch to your Terminal window (presuming it was previously opened).
3. Otherwise (for 2.) could you implement a "key" option (F12 ??) to switch to your terminal window.
For 2 & 3 above, I am always doing this manually, so it would be a real nice feature
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Hrm.. I've been meaning to implement the whole "top file" thing for a while now. Maybe I need to just sit down and do it.
As for the terminal window, I was thinking if the terminal was open and connected, it should automatically come to the front as soon as the download is complete. Maybe a setting in the terminal menu to determine if you want it to pop forward after a good compile/download. I kinda think it should just happen by default, otherwise why do you have it open and connected anyway?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
BradC: Having the terminal window step forward after a download is an excellent idea. It's one of those niggley things that I had in mind to suggest but didn't as I know you have a lot else to be doing.
Also it would be great if F10 would work, compile and download, when the terminal has focus. Quite often when stepping through ZiCog/Zog, whatever code, I found myself wanting to restart it. As I don't load the EEPROM every time or perhaps there is not even one connected, the "Reset Prop" thing is not enough.
Details, details....
By the way, I had a little fight with the "type" of data included with a "file" statement.
If I set up a simple loop to print elements of the included file then it is treated as an array of BYTEs or WORDs or LONGs depending on what was declared immediately before the "file" statement.
That's OK one can always put a dummy, empty, declaration immediately prior to the "file" and the file data will assume that type.
Is that the same behavior as in the Prop Tool?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
BradC: Yes, having the terminal window step forward after a successful download would be excellent.
Would it be possible for you to add a clearscreen command for the terminal if $00 and/or $18 was received. I note a lot of use of $00, but in those old days $18 (can) was used. I have implemented both in my simple terminal interface within the 1-pin TV driver.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
heater said...
BradC: Having the terminal window step forward after a download is an excellent idea. It's one of those niggley things that I had in mind to suggest but didn't as I know you have a lot else to be doing.
Also it would be great if F10 would work, compile and download, when the terminal has focus. Quite often when stepping through ZiCog/Zog, whatever code, I found myself wanting to restart it. As I don't load the EEPROM every time or perhaps there is not even one connected, the "Reset Prop" thing is not enough.
Hrm.. that has been bugging me for a while actually. Just F10 I reckon.. no point passing the other compile options through.
heater said...
By the way, I had a little fight with the "type" of data included with a "file" statement.
If I set up a simple loop to print elements of the included file then it is treated as an array of BYTEs or WORDs or LONGs depending on what was declared immediately before the "file" statement.
That's OK one can always put a dummy, empty, declaration immediately prior to the "file" and the file data will assume that type.
Is that the same behavior as in the Prop Tool?
Well, a symbol has an alignment. It is the symbol that has the alignment. File " xxx " just imports bytes wherever you put it, so if you have a long symbol then a FILE command it will just squirt that data straight into the DAT section, but if you reference the symbol from spin it will be referenced as a long symbol.
I've just checked and the Prop Tool does what I think is logical, so I'd suspect bst[noparse][[/noparse]c] does the same.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Cluso99 said...
BradC: Yes, having the terminal window step forward after a successful download would be excellent.
Yeah, I have that working nicely here now. I need to verify it on OSX and Windows though. They have oddities with focus for me sometimes.
Cluso99 said...
Would it be possible for you to add a clearscreen command for the terminal if $00 and/or $18 was received. I note a lot of use of $00, but in those old days $18 (can) was used. I have implemented both in my simple terminal interface within the 1-pin TV driver.
It's a hack I guess. $00 is NUL and $18 is CAN. Neither of those mean "clear the screen"..
I suppose I could build a PST compatible mode in you could activate using a switch. I would not want junk coming in the port start clearing the screen by default.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
BradC: Yes, NUL is a hack that I first saw here. CAN was used by ICL from 1969 through to 1999 on the System Ten and System 25 minis. IIRC, CAN was used by some other terminals. Goodness knows why Dec introduced those long escape sequences.
Given you have a long buffer, and currently you display a "?" for $0 (threw me for a while), perhaps converting it to 2 <cr> would be nice. I guess it's not that important as I can always use TerraTerm or similar to act as a terminal when I need it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Given you have a long buffer, and currently you display a "?" for $0 (threw me for a while), perhaps converting it to 2 <cr> would be nice. I guess it's not that important as I can always use TerraTerm or similar to act as a terminal when I need it.
I convert all non-printable characters to '?'. The garbage was far more confusing (and it had a propensity to make it go down in flames).
I'm quite happy to do a full blown PST compatible mode, I'll just have it switchable. It might make me get off my backside and finish the VT100 parser too. That could be an alternative mode.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
BradC: I think there are many other more important things than VT100 emulation for now. A switch to convert $00 to $0D <cr> would be nice.
I have been looking for where the "?" was coming from for a while now on different projects. Never looked too closely till now.
A file transfer function would be more useful than VT100 because I am always transferring files on the SD card. Something along the lines of Michael's (mpark) GET/PUT. Usually I am transferring the binary just compiled. Anyway, I am sure you have more pressing things to do.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Istead of have fast codes for Terminal can You maybe have Configurable secqences in Terminal properties for -
Blank and Cursor control and some others that are diferent in some Terminal programs.
Maybe Sequence for - Generating NEW line to for strobing it by LF, CR else CR/LF.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Comments
The following code compiles fine if the included file "nops.bin" is exactly 16K and the complete program it lives in has 3288 LONGS free.
BUT adding just a single byte to the included file "nops.bin" causes the compilation to fail with
"Object exceeds 32K"
This clearly cannot be. I was expecting an error about the FIT failing.
CON zpu_memory_size = (16 * 1024) 'The size of ZPU memory area DAT org 0 zpu_memory file "nops.bin" padding byte 0[noparse][[/noparse](zpu_memory_size) - (@padding - @zpu_memory)] zpu_memory_end fit (zpu_memory_size) / 4▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Umm.. it looks like you are doing this..
zpu_memory_size = 16384
Your file size is 16385
byte 0[noparse][[/noparse]16384 - 16385]
which becomes byte 0[noparse][[/noparse]4294967295]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
CON zpu_memory_size = (16 * 1024) 'The size of ZPU memory area DAT org 0 zpu_memory 'file "nops.bin" 'A 16Kb file byte 0[noparse][[/noparse]zpu_memory_size] 'A 16Kb array file_end byte 0[noparse][[/noparse]100] '<------- THIS SHOULD CAUSE FIT TO FAIL zpu_memory_end fit (zpu_memory_size / 4)As above with the "file" statement commented out it correctly fails "PC exceeds cog memory by 25 longs"
BUT uncomment the "file" statement and comment the line below and it does not fail the FIT any more.
The file is 16K
heaterl@ddt:~/zog$ ls -l nops.bin
-rw-r--r-- 1 heater heater 16384 Feb 10 09:16 nops.bin
michael@ddt:~/zog$
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
First of all, I'd like to thank your work!
Second, I have a question.
In the installation guide (http://www.parallax.com/tabid/828/Default.aspx) it is mentioned that the serial adapter driver from FTDI must be installed.
Despite of this, here is what I've done:
(I use Kubuntu 9.10, 2.6.31-19-generic #56, x86_64)
I plugged the propeller to my laptop.
So I tought that my kernel supports the chip.
So I installed the btc tool.
And found out that it worked, I was able to download programs to the propeller, as far I tried.
Is this means, that the guide is somewhat outdated at least for this kernel version, or I must install the driver from FTDI to ensure proper operation?
Thanks,
Daniel
G'day Daniel, I appreciate that, thanks.
The guide on the Parallax site was written by Parallax and is geared toward Macintosh users.
As a rule, most Linux distributions manage to release kernels with working ftdi drivers out of the box, so there is no need to install anything to make it work. Provided your distribution has udev set up correctly then bst should find your prop plug out of the box. If you can detect your Propeller then you are good to go.
Linux and Mac users do have to install the proper font though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Thank you.
Changelog in top post as usual.
Major changes :
PropBasic Integration!
This would not have happened without the support of Bean (it is his compiler after all!), JonnyMac, Brian Riley, Mike Green and Anthony McGraw.
Any errors not related to the actual generation of correct SPIN code from BASIC source are probably mine, so don't go bugging Bean about it!
You need the -bst PropBasic binaries as there are some minor internal changes that mean it *WILL NOT WORK* with Bean's standard binaries. (Don't try, really.. bst will just stare at you blankly with that "Whatchoo talkin' 'bout Willis?" look on its face)
These are found at www.fnarfbargle.com/PropBasic and are versioned by Beans compiler revision with my svn commit number appended to the end. (I may do a number of intermediate releases in between Beans official releases as things develop).
You will need to go to Tools -> IDE Preferences -> PropBasic and select the path of your PropBasic-bst binary. If you select a binary it does not like, bst will simply ignore you. If you give it what it wants, you will be rewarded with a little pop up box telling you the revision number of the PropBasic compiler you have selected.
The only major missing features for this release are Syntax Highlighting and Archiving. They will both be implemented in a later release.
This release sees some behavioural changes required to get the integration as smooth as possible. One of these is with regard to syntax highlighting.
Previously bst would try and highlight any file you opened. Now, it will only apply spin highlighting to files with a .spin extension. This means if you were using .spinx or .pasm or any other extension, your files will no longer highlight as spin files. I'm considering a possibility for a user generated list of file extensions to recognise as spin files, but for this release I'm afraid it's fixed.
Unlike spin files, PropBasic files *must* be saved to disk prior to compiling. The compiler is a separate binary and will only read files from the disk. To make this as seamless as possible, when you try any form of Basic Compile, bst will save every tab with a modified basic file in it.
PropBasic can't cope with Unicode, so bst will convert any unicode characters it finds into '?' when the file is saved to disk. It will pop up a message box telling you it is doing this so you know your file has been changed. The process of the conversion means you *will* lose the undo history in any tab that has code that was converted, so make sure you know what you want to do before saving your file!
There is a "Compile Basic to Spin" item in the compile menu. This compiles the Basic code and opens (or refreshes if they are already open) the spin code in new tabs. These tabs are marked read-only and are not automatically saved to disk. If you save and modify these tabs, when you next perform a basic compile the code in the tabs will be refreshed from the new compile, and the tabs re-marked read-only.
The bst integration of PropBasic tries to follow the general "drop and run" philosophy of bst, so there are no intermediate files generated. There should be nothing left behind after a basic compile, and provided the spin code generated has no errors in it, you should not even know it was there. An F10 on a tab containing Basic code should compile and download seamlessly the same way Spin code does. If it doesn't, then I'd like to hear about it.
The other real major change is the way the Propeller Font is rendered under Windows XP. It *should* look a lot nicer now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Post Edited (BradC) : 2/15/2010 11:41:50 PM GMT
I have a downloadable Zip file which offers, in effect, 'one stop shopping.' It's 11.3 MB and has the bst/propbasic executables (bst 0.19/propbasic 80, the correct modified-for-Mac Parallax.ttf font file and the standard objects from the 1.2.7 Propeller Tool, with FloatString upgraded all in a folder structure ready to drop on your Applications folder.
The tutorial/AppNote and download links can be found at
www.wulfden.org/TheShoppe/prop/index.shtml
cheers ... BBR
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
The Shoppe at Wulfden
www.wulfden.org/TheShoppe/
The binary header, bytes $0->$F.
Does the Propeller tool include that in the tally?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
And to Brian too (not that I am a Mac user) as this opens up the audience
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
It is only > Help>About that have problems.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Thanks Sapieha, that clears that up. I'm afraid you might have to give me a day or two to see if I can figure out what I broke.
Appreciate the feedback, thanks!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
BTW is the latest compiler still 0.15.4-pre3 ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Yes, I changed the way the fonts were rendered using Microsofts "ClearType". Wonderful isn't it?. Unfortunately it appears that different versions of windows handle it differently. Which one are you running?
BTW is the latest compiler still 0.15.4-pre3 ?
Yes it is, although Bean just pointed me at a bug I have to fix, so I'll be on that this weekend. I'll also revisit the font rendering *again* when I can get hold of some win32 machines to test on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
If you could that would be great. I have access to a laptop now that dual boots Vista & XP so I can try some tweaks.
Back when bst was in its infancy there was a switch implemented in the IDE Preferences to enable/disable anti-aliased rendering. Somewhere along the line the original purpose for that got lost, but I noticed that Vista improved the font rendering by actually performing smoothing while XP just would not. When we were in the throes of 0.19-pre Jon observed that the font rendering on XP was naff (which it had always been) so I fiddled about until I got ClearType enabled and that seemed to fix things. Obviously it has made it noticeably worse on Vista.
What I've done is re-tweaked the "anti-alias editor fonts" switch in the IDE prefs, so in the next version you'll be able to turn that off and get back to the way things were in Vista pre 0.19.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
1. Permit Ctl-F10 to also compile and load (same as F10) so as to be compatible with PropTool. Any implications in this??
2. Could you do a "key" option (F12 ??) for compile, if no errors download to Ram and then automatically switch to your Terminal window (presuming it was previously opened).
3. Otherwise (for 2.) could you implement a "key" option (F12 ??) to switch to your terminal window.
For 2 & 3 above, I am always doing this manually, so it would be a real nice feature
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 2/22/2010 8:06:27 AM GMT
As for the terminal window, I was thinking if the terminal was open and connected, it should automatically come to the front as soon as the download is complete. Maybe a setting in the terminal menu to determine if you want it to pop forward after a good compile/download. I kinda think it should just happen by default, otherwise why do you have it open and connected anyway?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Also it would be great if F10 would work, compile and download, when the terminal has focus. Quite often when stepping through ZiCog/Zog, whatever code, I found myself wanting to restart it. As I don't load the EEPROM every time or perhaps there is not even one connected, the "Reset Prop" thing is not enough.
Details, details....
By the way, I had a little fight with the "type" of data included with a "file" statement.
If I set up a simple loop to print elements of the included file then it is treated as an array of BYTEs or WORDs or LONGs depending on what was declared immediately before the "file" statement.
That's OK one can always put a dummy, empty, declaration immediately prior to the "file" and the file data will assume that type.
Is that the same behavior as in the Prop Tool?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Would it be possible for you to add a clearscreen command for the terminal if $00 and/or $18 was received. I note a lot of use of $00, but in those old days $18 (can) was used. I have implemented both in my simple terminal interface within the 1-pin TV driver.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Hrm.. that has been bugging me for a while actually. Just F10 I reckon.. no point passing the other compile options through.
Well, a symbol has an alignment. It is the symbol that has the alignment. File " xxx " just imports bytes wherever you put it, so if you have a long symbol then a FILE command it will just squirt that data straight into the DAT section, but if you reference the symbol from spin it will be referenced as a long symbol.
I've just checked and the Prop Tool does what I think is logical, so I'd suspect bst[noparse][[/noparse]c] does the same.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Yeah, I have that working nicely here now. I need to verify it on OSX and Windows though. They have oddities with focus for me sometimes.
It's a hack I guess. $00 is NUL and $18 is CAN. Neither of those mean "clear the screen"..
I suppose I could build a PST compatible mode in you could activate using a switch. I would not want junk coming in the port start clearing the screen by default.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Given you have a long buffer, and currently you display a "?" for $0 (threw me for a while), perhaps converting it to 2 <cr> would be nice. I guess it's not that important as I can always use TerraTerm or similar to act as a terminal when I need it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I convert all non-printable characters to '?'. The garbage was far more confusing (and it had a propensity to make it go down in flames).
I'm quite happy to do a full blown PST compatible mode, I'll just have it switchable. It might make me get off my backside and finish the VT100 parser too. That could be an alternative mode.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I have been looking for where the "?" was coming from for a while now on different projects. Never looked too closely till now.
A file transfer function would be more useful than VT100 because I am always transferring files on the SD card. Something along the lines of Michael's (mpark) GET/PUT. Usually I am transferring the binary just compiled. Anyway, I am sure you have more pressing things to do.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
It is maybe to much work for You BUT.
Istead of have fast codes for Terminal can You maybe have Configurable secqences in Terminal properties for -
Blank and Cursor control and some others that are diferent in some Terminal programs.
Maybe Sequence for - Generating NEW line to for strobing it by LF, CR else CR/LF.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha