I think I mentioned it but could it be possible to copy from the Listing window into the clipboard (cmd+C/ctrl+C) ?
And another feature request can we upload a file using the serial terminal ? That could be handy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL, pPropQL020 and OMU for the pPropQL/020 at omnibus.uni-freiburg.de/~rp92
Hi Brad, is there is way in bst to do what the Prop Tool does where you can hold down the alt key while dragging an area (however wide) downwards, and the highlighter only highlights the area wide you choose, versus highliging all text on the subsequent rows?
It would be wonderful to be able to calculate stack usage properly rather than guess it or use stack checker code (which will only be accurate if your tests are good enough to generate calls to the maximum depth).
You're already putting an object tree in the listing and reporting the 'extra' stack for each method. How about adding a full call tree and calculating the total stack depth for each path ?
It would be wonderful to be able to calculate stack usage properly rather than guess it or use stack checker code (which will only be accurate if your tests are good enough to generate calls to the maximum depth).
You're already putting an object tree in the listing and reporting the 'extra' stack for each method. How about adding a full call tree and calculating the total stack depth for each path ?
It gets complex when you start doing inter-object calls inside repeat and case statements. That is starting to leave the realm of the compiler and enter the realm of the interpreter. I would then need to educate the compiler on the stack usage implications of every spin construct and have it walk every possible path.
I guess it does not sound complex until you try and do it.
It might be easier if the compiler builds some form of call tree for it to walk. But it doesn't.
All I'll say is I'll think about it. Off the top of my head I certainly can't think of an easy way to do it, but if I come up with something workable I might look at it harder.
As far as the todo list goes, it's not even on the radar.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
I guess it does not sound complex until you try and do it.
Ah, but I'm an armchair designer
Maybe I should try postprocessing the list file - I think everything's in there, and in a nice regular format (less work checking syntax). It would be a smaller job to construct the tree from that than try to attempt to retrofit it.
Is there a fixed stack overhead associated with each call that should be added to the 'extra stack' listing ?
I have only just tried your IDE for the first time on my Ubuntu Jaunty system and I am very impressed, well done. I especially like the listing view.
One problem though and I can't see anything in the configuration (and it's a enormous thread) but the tool is not detecting my Prop. Some of my Prop USB links use the RTS instead of the DTR especially the older Silabs based links. Is there anything I can do?
*Peter*
EDIT: What am I saying! The unit that is not being detected is based on an FT232R and uses the DTR but it's optically isolated. I will check it later.
Post Edited (Peter Jakacki) : 6/9/2009 10:47:38 PM GMT
I have only just tried your IDE for the first time on my Ubuntu Jaunty system and I am very impressed, well done. I especially like the listing view.
One problem though and I can't see anything in the configuration (and it's a enormous thread) but the tool is not detecting my Prop. Some of my Prop USB links use the RTS instead of the DTR especially the older Silabs based links. Is there anything I can do?
*Peter*
EDIT: What am I saying! The unit that is not being detected is based on an FT232R and uses the DTR but it's optically isolated. I will check it later.
I don't have a configuration option for RTS rather than DTR as I don't have any devices here to test it with so I never bothered.
Is the tool even finding the ports to try and detect a prop?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
TChapman said...
Hi Brad, is there is way in bst to do what the Prop Tool does where you can hold down the alt key while dragging an area (however wide) downwards, and the highlighter only highlights the area wide you choose, versus highliging all text on the subsequent rows?
Thanks
There isn't right now, however I'll make sure it's added before 0.18. The Editor is capable, I just don't have a method to access it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
I don't have a configuration option for RTS rather than DTR as I don't have any devices here to test it with so I never bothered.
Is the tool even finding the ports to try and detect a prop?
Ok, I've just got back and checked it again and it worked the first time after which I can see it reseting the Prop but it fails to detect it. Timing issue I guess.
BTW, My DTR from the FT232R goes straight to the OPTO as an active low and appears as an active low coupled directly into the Prop's reset through a 0.1uf then a 100K pullup. Works everytime on the Spin tool.
Ok, I've just got back and checked it again and it worked the first time after which I can see it reseting the Prop but it fails to detect it. Timing issue I guess.
BTW, My DTR from the FT232R goes straight to the OPTO as an active low and appears as an active low coupled directly into the Prop's reset through a 0.1uf then a 100K pullup. Works everytime on the Spin tool.
It's entirely possible my DTR pulses don't precisely match the Parallax generated ones (They are probably too short). This is because I developed mine purely by experimentation with the tools I had available at the time.
Since I wrote that code I've acquired a 400Mhz DSO. If the Propeller Tool timings work for you, prior to the next software update I'll measure the Parallax timings and correct mine to suit.
<Edit>
Ok, I see the problem.
The Propeller Tool pulls the DTR line low for 25ms, it is the following low to high transition that triggers the reset circuit on the Parallax Boards. Your board will reset on the high to low edge and on the Propeller Tool that falls within the timing tolerances.
bst[noparse][[/noparse]lc] Pulls the DTR line low for 50ms prior to allowing it to reset the device. This falls outside the tolerance of your circuit and therefore won't work. I'll look at what is required to bring this timing into line with the Parallax tools. Note that bst will pull the DTR line low again when you use the serial terminal (ON OSX & Win32). This is an unfortunate artefact of the way the serial driver works on OSX and the way I manipulate the port on Win32 (Linux will be fine). This works fine on Parallax hardware as the reset occurs on the low to high transition, however it will probably reset your board again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
TChapman said...
Hi Brad, is there is way in bst to do what the Prop Tool does where you can hold down the alt key while dragging an area (however wide) downwards, and the highlighter only highlights the area wide you choose, versus highliging all text on the subsequent rows?
Thanks
There isn't right now, however I'll make sure it's added before 0.18. The Editor is capable, I just don't have a method to access it.
That would be nice. It would be even nicer if that group of selected text could then all be aligned. I wouldn't have to guess how many spaces to add before each line of comments!
It seems that the IDE is asserting DTR during detection it's just not releasing it afterwards. I have to disconnect the USB and reconnect to release the DTR.
It seems that the IDE is asserting DTR during detection it's just not releasing it afterwards. I have to disconnect the USB and reconnect to release the DTR.
*Peter*
Looking at the output of the FT232 chip on my scope here, both IDE's behave exactly the same excepting my low going pulse is 50ms and the Parallax one is 25ms. Both pull the DTR low, then pull it high (which is the part that resets the chip on the Parallax hardware). In my tests here, both IDE's leave the DTR high after the load.
I'm assuming given you are directly capacitively coupled to the reset pin, the pin will go low on the high->low transition at the start of the reset sequence. The Parallax hardware on the demo board and prop plug outputs a very stable 50uS reset pulse on any rising edge of the DTR line.
On bst the falling edge is 50ms too early, while on the propeller tool it is 25ms too early (and within the bootloader timing tolerance). Both tools wait an average of 95ms from the rising edge of the DTR to the transmission of the first bit. The propeller tool has a more variable timing here (between about 85-102 ms) but then I'm running it inside a VM.
<Edit> the DTR is not released afterwards as by holding it high the subsequent open by any serial terminal will force it low (and this will not reset the propeller using the Parallax reset circuit). This allows a smooth transition from download to serial terminal without having the propeller reset.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eccles : How do I open the door?
Bluebottle : You turn the knob on your side
Eccles : I haven't got a knob on my side!
Ok, the problem I was having was while I was in Linux so I rebooted into windows and tried your window's version and it worked fine. However, the Linux version is sticking on the DTR.
Even running the Spin tool in Windows through VirtualBox on top of Ubuntu I find that this mostly works. By mostly I mean that there is that occasional timeout but not very often.
I'm not quite sure what you are saying in your post-edit though.
Peter Jakacki said...
Ok, the problem I was having was while I was in Linux so I rebooted into windows and tried your window's version and it worked fine. However, the Linux version is sticking on the DTR.
Even running the Spin tool in Windows through VirtualBox on top of Ubuntu I find that this mostly works. By mostly I mean that there is that occasional timeout but not very often.
I'm not quite sure what you are saying in your post-edit though.
*Peter*
The "sticking" on the DTR is by design. Unfortunately each OS has completely differing ways of dealing with the ports and varying levels of POSIX compatibility.
bst configures the port on linux not to touch the handshaking pins on open or close, so they stay precisely where the IDE set them.
It's supposed to do that on OSX also, but OSX ignores the relevant flags in the termios structure and resets the port completely every time it is closed.
Windows does about half and half, but it works and I've not dived into it much further.
Re-reading the bootsequence.spin file posted by Chip a while back
BOOT SEQUENCE
-------------
PC: set 115200-8-N-1
DTR low
wait at least 10ms
DTR high
wait 100ms (+-10% tolerance)
send $F9 (%0100111111 timing calibration)
Now the Propeller tool waits 25ms and bst waits 50ms. Both tools leave the DTR line high after the chip is programmed. If BST is not doing that on Windows then it's a bug and I'll have to fix it, but that is the documented method of communicating with the propeller.
If the DTR pin is initially low on linux, after bst has been at it, it will be left high as that is the safest place to leave it to work with the Parallax provided reset circuits. Any inadvertent high->low transition is not going to reset the device, and some serial terminal programs do this on open.
On OSX you get this
F7 Detect propeller -> Open Port -> DTR Low - bst pauses 50ms - DTR High - Talk to Propeller - Close Port -> DTR stays high.
When you open the port under any circumstance, OSX pulls the DTR low again and this does not cause the propeller to reset. It resets the first time the terminal is closed as OSX forces the DTR high again.
This is the behaviour I'd observed on Windows also which was consistent with what I believed was happening.
I only really test on Windows when I really have to and I certainly don't use it often, but the behaviour on OSX and Linux is consistent (aside from the longer DTR low period) with what the Propeller Tool does.
When you say it's "sticking on the DTR", is it leaving it low or high (as measured directly at the FT232) ?
It *should* be leaving it high. If it's not then there is a bug.
<Edit> I'm fairly convinced the problem you are seeing on Linux is related to the DTR low period being much longer than the Propeller Tool. I will get that fixed and get a test version out to you asap.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eccles : How do I open the door?
Bluebottle : You turn the knob on your side
Eccles : I haven't got a knob on my side!
timx8 said...
Registered for the forum just so I could add my thanks for this great tool!
Here's my bug report on v 0.17 (osx 10.5.7 on a g5):
-font size 13 doesn't work very well, characters get lost when scrolling or selecting
Yes, this is/was a known problem and should be fixed in the latest snapshots. 0.18-pre8 is the latest from memory. If you download that one the font rendering should be much, much better.
timx8 said...
And a feature request:
-Association marks for repeat/if structures, like in the propeller tool.
Block indicators is something I've played with on and off for a while. I had a functional prototype at one stage but I never got the little rendering errors worked out of it. It's on the todo list, but it's not going to happen any time soon I'm afraid.
Thanks for the kind words. I'm having a lot of fun writing it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eccles : How do I open the door?
Bluebottle : You turn the knob on your side
Eccles : I haven't got a knob on my side!
Trying to compile the following code results in a mangled progress indicator showing for a long time followed by the Compile Error dialog box. However no errors are reported.
PUB start
DAT
test a,b wc, w
a long 0
b long 0
BST 0.18-Pr8
BSTC 0.15-Pre6
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Trying to compile the following code results in a mangled progress indicator showing for a long time followed by the Compile Error dialog box. However no errors are reported.
That happens when the compiler crashes. It's a little more informative now.
Thanks for that, I'll get it fixed [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eccles : How do I open the door?
Bluebottle : You turn the knob on your side
Eccles : I haven't got a knob on my side!
Great. Thanks for the feedback. Does it go away at point size 12 or 14?
I've just tested here and it's b0rked on Windows and Linux at 13 point also, so it's a problem with the Parallax Font.
Yes, I've only noticed it at size 13 on parallax font. Just noticed that it also happens for Geneva font, all sizes (using version 0.17).
I've just tested Geneva on 0.18-Pre8 here on OSX 10.5 PPC and while it's got larger spacing than it should have it does render properly.
Monaco is my preference on OSX if you are not using the Parallax font as it's a monospaced font and I do test with it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eccles : How do I open the door?
Bluebottle : You turn the knob on your side
Eccles : I haven't got a knob on my side!
heater said...
Bug: Incorrect memory allocation in DAT
PUB start
DAT
first BYTE 0
second BYTE 0
third BYTE 0
fourth BYTE 0[noparse][[/noparse]fourth - first]
last BYTE 0
The bytes fourth and last have the same address !!
They do, yes its a bug and yes I'll figure out how to fix it. However, try compiling that under the propeller tool and looking at the binary. I'm not sure it does what you think it does.
(hint - the addresses given by fourth and first are long addresses (cog addressing) not hub addresses. It won't compile as is as fourth is not long aligned. When you pad it out so it does compile fourth - first == 1. I think what you wanted was BYTE 0 [noparse][[/noparse]@fourth-@first]. I may be wrong however.
I can't reproduce the "bst_bug - Bytecode of object exceeds size of memory - Report this bug please" bug here with my current code. Which version are you using?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eccles : How do I open the door?
Bluebottle : You turn the knob on your side
Eccles : I haven't got a knob on my side!
"...wanted was BYTE 0 [noparse][[/noparse]@fourth-@first]. I may be wrong however."
No you are not wrong, I just realized my mistake here.
What I really want to do is put some padding bytes into DAT such that the next label is 1024 (or whatever) bytes up from a given label. Like so:
DAT
first BYTE 1
second BYTE 2
...
...
...
padding BYTE 0[noparse][[/noparse]1024 - (@padding - @first)]
tstbyte BYTE 1 'This should be 1024 bytes up from "first"
But I want to use $ instead of the "padding" label. Haven't managed to get it to work any way yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
It has been a while since I've used it but yes, that was handy.
Rich H
I think I mentioned it but could it be possible to copy from the Listing window into the clipboard (cmd+C/ctrl+C) ?
And another feature request can we upload a file using the serial terminal ? That could be handy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL, pPropQL020 and OMU for the pPropQL/020 at omnibus.uni-freiburg.de/~rp92
I've got that one already [noparse];)[/noparse]
Just a straight ASCII upload? I've been looking at X and Y-Modem but I'm not there yet. ASCII upload I could probably manage fairly easily.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL, pPropQL020 and OMU for the pPropQL/020 at omnibus.uni-freiburg.de/~rp92
Thanks
It would be wonderful to be able to calculate stack usage properly rather than guess it or use stack checker code (which will only be accurate if your tests are good enough to generate calls to the maximum depth).
You're already putting an object tree in the listing and reporting the 'extra' stack for each method. How about adding a full call tree and calculating the total stack depth for each path ?
It gets complex when you start doing inter-object calls inside repeat and case statements. That is starting to leave the realm of the compiler and enter the realm of the interpreter. I would then need to educate the compiler on the stack usage implications of every spin construct and have it walk every possible path.
I guess it does not sound complex until you try and do it.
It might be easier if the compiler builds some form of call tree for it to walk. But it doesn't.
All I'll say is I'll think about it. Off the top of my head I certainly can't think of an easy way to do it, but if I come up with something workable I might look at it harder.
As far as the todo list goes, it's not even on the radar.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Maybe I should try postprocessing the list file - I think everything's in there, and in a nice regular format (less work checking syntax). It would be a smaller job to construct the tree from that than try to attempt to retrofit it.
Is there a fixed stack overhead associated with each call that should be added to the 'extra stack' listing ?
I have only just tried your IDE for the first time on my Ubuntu Jaunty system and I am very impressed, well done. I especially like the listing view.
One problem though and I can't see anything in the configuration (and it's a enormous thread) but the tool is not detecting my Prop. Some of my Prop USB links use the RTS instead of the DTR especially the older Silabs based links. Is there anything I can do?
*Peter*
EDIT: What am I saying! The unit that is not being detected is based on an FT232R and uses the DTR but it's optically isolated. I will check it later.
Post Edited (Peter Jakacki) : 6/9/2009 10:47:38 PM GMT
I don't have a configuration option for RTS rather than DTR as I don't have any devices here to test it with so I never bothered.
Is the tool even finding the ports to try and detect a prop?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
There isn't right now, however I'll make sure it's added before 0.18. The Editor is capable, I just don't have a method to access it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Ok, I've just got back and checked it again and it worked the first time after which I can see it reseting the Prop but it fails to detect it. Timing issue I guess.
BTW, My DTR from the FT232R goes straight to the OPTO as an active low and appears as an active low coupled directly into the Prop's reset through a 0.1uf then a 100K pullup. Works everytime on the Spin tool.
*Peter*
It's entirely possible my DTR pulses don't precisely match the Parallax generated ones (They are probably too short). This is because I developed mine purely by experimentation with the tools I had available at the time.
Since I wrote that code I've acquired a 400Mhz DSO. If the Propeller Tool timings work for you, prior to the next software update I'll measure the Parallax timings and correct mine to suit.
<Edit>
Ok, I see the problem.
The Propeller Tool pulls the DTR line low for 25ms, it is the following low to high transition that triggers the reset circuit on the Parallax Boards. Your board will reset on the high to low edge and on the Propeller Tool that falls within the timing tolerances.
bst[noparse][[/noparse]lc] Pulls the DTR line low for 50ms prior to allowing it to reset the device. This falls outside the tolerance of your circuit and therefore won't work. I'll look at what is required to bring this timing into line with the Parallax tools. Note that bst will pull the DTR line low again when you use the serial terminal (ON OSX & Win32). This is an unfortunate artefact of the way the serial driver works on OSX and the way I manipulate the port on Win32 (Linux will be fine). This works fine on Parallax hardware as the reset occurs on the low to high transition, however it will probably reset your board again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Post Edited (BradC) : 6/10/2009 3:04:01 AM GMT
That would be nice. It would be even nicer if that group of selected text could then all be aligned. I wouldn't have to guess how many spaces to add before each line of comments!
Rich H
It seems that the IDE is asserting DTR during detection it's just not releasing it afterwards. I have to disconnect the USB and reconnect to release the DTR.
*Peter*
Looking at the output of the FT232 chip on my scope here, both IDE's behave exactly the same excepting my low going pulse is 50ms and the Parallax one is 25ms. Both pull the DTR low, then pull it high (which is the part that resets the chip on the Parallax hardware). In my tests here, both IDE's leave the DTR high after the load.
I'm assuming given you are directly capacitively coupled to the reset pin, the pin will go low on the high->low transition at the start of the reset sequence. The Parallax hardware on the demo board and prop plug outputs a very stable 50uS reset pulse on any rising edge of the DTR line.
On bst the falling edge is 50ms too early, while on the propeller tool it is 25ms too early (and within the bootloader timing tolerance). Both tools wait an average of 95ms from the rising edge of the DTR to the transmission of the first bit. The propeller tool has a more variable timing here (between about 85-102 ms) but then I'm running it inside a VM.
<Edit> the DTR is not released afterwards as by holding it high the subsequent open by any serial terminal will force it low (and this will not reset the propeller using the Parallax reset circuit). This allows a smooth transition from download to serial terminal without having the propeller reset.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eccles : How do I open the door?
Bluebottle : You turn the knob on your side
Eccles : I haven't got a knob on my side!
Even running the Spin tool in Windows through VirtualBox on top of Ubuntu I find that this mostly works. By mostly I mean that there is that occasional timeout but not very often.
I'm not quite sure what you are saying in your post-edit though.
*Peter*
The "sticking" on the DTR is by design. Unfortunately each OS has completely differing ways of dealing with the ports and varying levels of POSIX compatibility.
bst configures the port on linux not to touch the handshaking pins on open or close, so they stay precisely where the IDE set them.
It's supposed to do that on OSX also, but OSX ignores the relevant flags in the termios structure and resets the port completely every time it is closed.
Windows does about half and half, but it works and I've not dived into it much further.
Re-reading the bootsequence.spin file posted by Chip a while back
BOOT SEQUENCE ------------- PC: set 115200-8-N-1 DTR low wait at least 10ms DTR high wait 100ms (+-10% tolerance) send $F9 (%0100111111 timing calibration)Now the Propeller tool waits 25ms and bst waits 50ms. Both tools leave the DTR line high after the chip is programmed. If BST is not doing that on Windows then it's a bug and I'll have to fix it, but that is the documented method of communicating with the propeller.
If the DTR pin is initially low on linux, after bst has been at it, it will be left high as that is the safest place to leave it to work with the Parallax provided reset circuits. Any inadvertent high->low transition is not going to reset the device, and some serial terminal programs do this on open.
On OSX you get this
F7 Detect propeller -> Open Port -> DTR Low - bst pauses 50ms - DTR High - Talk to Propeller - Close Port -> DTR stays high.
When you open the port under any circumstance, OSX pulls the DTR low again and this does not cause the propeller to reset. It resets the first time the terminal is closed as OSX forces the DTR high again.
This is the behaviour I'd observed on Windows also which was consistent with what I believed was happening.
I only really test on Windows when I really have to and I certainly don't use it often, but the behaviour on OSX and Linux is consistent (aside from the longer DTR low period) with what the Propeller Tool does.
When you say it's "sticking on the DTR", is it leaving it low or high (as measured directly at the FT232) ?
It *should* be leaving it high. If it's not then there is a bug.
<Edit> I'm fairly convinced the problem you are seeing on Linux is related to the DTR low period being much longer than the Propeller Tool. I will get that fixed and get a test version out to you asap.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eccles : How do I open the door?
Bluebottle : You turn the knob on your side
Eccles : I haven't got a knob on my side!
Post Edited (BradC) : 6/10/2009 5:57:23 AM GMT
Here's my bug report on v 0.17 (osx 10.5.7 on a g5):
-font size 13 doesn't work very well, characters get lost when scrolling or selecting
And a feature request:
-Association marks for repeat/if structures, like in the propeller tool.
Thanks again, I was so excited when I discovered BST yesterday, and 10 times more excited when I tried it and found it completely functional!
Yes, this is/was a known problem and should be fixed in the latest snapshots. 0.18-pre8 is the latest from memory. If you download that one the font rendering should be much, much better.
Block indicators is something I've played with on and off for a while. I had a functional prototype at one stage but I never got the little rendering errors worked out of it. It's on the todo list, but it's not going to happen any time soon I'm afraid.
Thanks for the kind words. I'm having a lot of fun writing it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eccles : How do I open the door?
Bluebottle : You turn the knob on your side
Eccles : I haven't got a knob on my side!
Great. Thanks for the feedback. Does it go away at point size 12 or 14?
I've just tested here and it's b0rked on Windows and Linux at 13 point also, so it's a problem with the Parallax Font.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eccles : How do I open the door?
Bluebottle : You turn the knob on your side
Eccles : I haven't got a knob on my side!
Trying to compile the following code results in a mangled progress indicator showing for a long time followed by the Compile Error dialog box. However no errors are reported.
PUB start DAT test a,b wc, w a long 0 b long 0BST 0.18-Pr8
BSTC 0.15-Pre6
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That happens when the compiler crashes. It's a little more informative now.
Thanks for that, I'll get it fixed [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eccles : How do I open the door?
Bluebottle : You turn the knob on your side
Eccles : I haven't got a knob on my side!
Yes, I've only noticed it at size 13 on parallax font. Just noticed that it also happens for Geneva font, all sizes (using version 0.17).
Yes, I've only noticed it at size 13 on parallax font. Just noticed that it also happens for Geneva font, all sizes (using version 0.17).
I've just tested Geneva on 0.18-Pre8 here on OSX 10.5 PPC and while it's got larger spacing than it should have it does render properly.
Monaco is my preference on OSX if you are not using the Parallax font as it's a monospaced font and I do test with it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eccles : How do I open the door?
Bluebottle : You turn the knob on your side
Eccles : I haven't got a knob on my side!
PUB start DAT first BYTE BYTE 0[noparse][[/noparse]1024 - $ + 1] last BYTE 1BST is asking me to report this:
"bst_bug - Bytecode of object exceeds size of memory - Report this bug please"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The bytes fourth and last have the same address !!
|===========================================================================|
Object DAT Blocks
|===========================================================================|
0018(0000) 00 | first BYTE 0
0019(0000) 00 | second BYTE 0
001A(0000) 00 | third BYTE 0
001B(0000) 00 | fourth BYTE 0[noparse][[/noparse]fourth - first]
001B(0000) 00 | last BYTE 0
|===========================================================================|
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
They do, yes its a bug and yes I'll figure out how to fix it. However, try compiling that under the propeller tool and looking at the binary. I'm not sure it does what you think it does.
(hint - the addresses given by fourth and first are long addresses (cog addressing) not hub addresses. It won't compile as is as fourth is not long aligned. When you pad it out so it does compile fourth - first == 1. I think what you wanted was BYTE 0 [noparse][[/noparse]@fourth-@first]. I may be wrong however.
I can't reproduce the "bst_bug - Bytecode of object exceeds size of memory - Report this bug please" bug here with my current code. Which version are you using?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eccles : How do I open the door?
Bluebottle : You turn the knob on your side
Eccles : I haven't got a knob on my side!
"...wanted was BYTE 0 [noparse][[/noparse]@fourth-@first]. I may be wrong however."
No you are not wrong, I just realized my mistake here.
What I really want to do is put some padding bytes into DAT such that the next label is 1024 (or whatever) bytes up from a given label. Like so:
But I want to use $ instead of the "padding" label. Haven't managed to get it to work any way yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.