Brad, I tried the bst-0.18.5-Pre1-test5 version with my VPN up. It still showed an empty white box while it was scanning all the shares. Then, when it finally finished, there was a whole flurry of window updates just before the box disappeared. I think maybe the drawing is all being deferred until the event loop cycles on the Mac, and that's not happening while the code is walking the filesystem.
It's very curious that sample and vmmap can't dissect the bst process. What is bst written in?
Nak said...
Brad, I tried the bst-0.18.5-Pre1-test5 version with my VPN up. It still showed an empty white box while it was scanning all the shares. Then, when it finally finished, there was a whole flurry of window updates just before the box disappeared. I think maybe the drawing is all being deferred until the event loop cycles on the Mac, and that's not happening while the code is walking the filesystem.
Most interesting, however not entirely surprising. I have had huge problems with the carbon event queue and getting the OS to properly process events while the process is busy. I ended up having to put the compiler and loader into a separate thread so OSX would properly update the GUI while they were churning. Now I have a defined way to reproduce it I can try to work on it a bit more. I've nfs mounted a share from my linux server onto my G4 PPC Mac, but I send the packets around the world to give me about a 400ms delay. It's slowed the filesystem _right_ down nicely.
Nak said...
It's very curious that sample and vmmap can't dissect the bst process. What is bst written in?
Pascal. It does not use carbon or cocoa services for anything other than the GUI elements. All the back end filesystem code uses a POSIX interface. Perhaps that is part of the issue in tracing things.
The reason it does not happen again if you close and re-open bst is Darwin is very good about caching mounted nfs filesystem data. unmount/remount the filesystems to empty the cache (or reboot) and it should do it again.
Thanks for the system info, that might help me a bit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
I'm just going to post a little comment here to say thanks for the BST program. I've been using it every day for the last week, sometimes for many hours at a stretch and it is a pleasure to program in this environment. My productivity has risen considerably as a result of this tool. Thanks Brad!
Dr_Acula said...
I'm just going to post a little comment here to say thanks for the BST program. I've been using it every day for the last week, sometimes for many hours at a stretch and it is a pleasure to program in this environment. My productivity has risen considerably as a result of this tool. Thanks Brad!
heater said...
I second that. Again. BST is a fantastic achievement.
Thanks guys, I appreciate that.
I must be doing something wrong though, as I still see posts on the forum from time to time from Linux/Mac users struggling to get the Propeller Tool running under WINE. Aside from the block indent markers, is there any 5 star feature that the Prop tool has people find lacking in bst?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
BradC said...
Aside from the block indent markers, is there any 5 star feature that the Prop tool has people find lacking in bst?
I only recently started using bst. I kind of got used to the PropTool F8 summary screen (hexdump etc). OK, not exactly a 5 star feature but maybe something to put on the ToDo list (unless it can be enabled and I just haven't found it)? Thanks.
BradC said...
Aside from the block indent markers, is there any 5 star feature that the Prop tool has people find lacking in bst?
I only recently started using bst. I kind of got used to the PropTool F8 summary screen (hexdump etc). OK, not exactly a 5 star feature but maybe something to put on the ToDo list (unless it can be enabled and I just haven't found it)? Thanks.
Actually, I never did a hex dump as everything I struggled to find in the Prop Tool hexdump is clearly laid out in the list file. Do you really get some use from the hex dump that's not satisfied by the listing?
I can put it on the todo list, sure.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
BradC said...
Actually, I never did a hex dump as everything I struggled to find in the Prop Tool hexdump is clearly laid out in the list file. Do you really get some use from the hex dump that's not satisfied by the listing?
OK, no problem there from my side. I guess I just get used to the listing [noparse]:)[/noparse] Any chance of assigning a shortcut to this function (Compiler listing)?
BradC: "I must be doing something wrong though,...."
Nothing wrong just perhaps not enough marketing.
"Mac/Linux/Windows IDE" May not be immediately recognizable to newcomers as a Prop Tool.
Where as "Propeller Tool Clone for Mac, Linux and Windows" might do the trick better. At the risk of being a bit "in the face" to Parallax which you may not want to do.
Actually I've always wondered how Parallax feels about BST basically obsoleting the Propeller Tool for so many of us.
I know you were not keen on releasing the source for BST but I'm wondering if you are up to releasing binaries for more platforms?
Specifically ARM. I'm looking forward to getting one of these beagleboard.org/. Not to mention the possibility of running on ARM based mobile phones, tablets and some net books.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I guess Parallax is in a unique position here. There is BradC and mpark and RossH and a cast of thousands investing their time and effort into building support for the Propeller chip and making it all available to the user community for free.
In the old days people like Bill Gates and Co wanted a lot of money for much lesser tools.
So that should make Parallax very happy and convince them they are doing something right.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
BradC said...
Actually, I never did a hex dump as everything I struggled to find in the Prop Tool hexdump is clearly laid out in the list file. Do you really get some use from the hex dump that's not satisfied by the listing?
OK, no problem there from my side. I guess I just get used to the listing [noparse]:)[/noparse] Any chance of assigning a shortcut to this function (Compiler listing)?
View -> Compiler Listing
Just leave it open in the background and it gets updated with every successful compile.
heater said...
Actually I've always wondered how Parallax feels about BST basically obsoleting the Propeller Tool for so many of us.
I don't think they particularly care to be honest. Does not matter what tools one uses, in the end they sell Propellers.
heater said...
Nothing wrong just perhaps not enough marketing.
It's a effort/reward thing. I'd rather spend what time I have available fixing those 6 legged insects in the code (the little buggers are nesting!).
heater said...
I know you were not keen on releasing the source for BST but I'm wondering if you are up to releasing binaries for more platforms?
It's something I've thought about, but I currently have multiple machines for each platform I support (I actually bought one of the Mac's to support bst specifically - it sits in the corner burning Watts otherwise). I'd be interested in getting an ARM box if it would be useful. I've got a couple of iPAQ's running Linux somewhere that I had planned to play with using X remotely, but if there is a low-budget dedicated ARM box that will do the thing out of the box I'd sure have a go at it.
I'm not making any guarantees however, as I'm unsure at the moment of the level of support the fpc/lazarus toolchain has for ARM GUI stuff. Only one way to find out though.
The beagleboard kinda sounds interesting, but most of the netbooks are still x86 based, so it's a common platform to target. If I can get an ARM based netbook with SSD and 20 hours battery life, I'm there [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Slightly off topic here, but there is another thread running asking whether the propeller could ever compile programs on itself. I see that the BST compiler is written in Pascal, and it is possible to run an older version of Pascal on the Propeller under CP/M. (No GUI but the BST command line compiler is also just text). Maybe this is possible, or perhaps it is one of those things that is possible but not very practical as would be too slow.
Just as a guide, how many lines of code is the command line BST program? And where did it come from - was it originally from parallax or did you write it all from scratch?
Just as a guide, how many lines of code is the command line BST program? And where did it come from - was it originally from parallax or did you write it all from scratch?
I did have a couple of PM's with Chip when I was trying to figure out why the Parallax compiler and my code generated 1LSB difference in floating point constants.
Linking bstc
13219 lines compiled, 6.4 sec
If you want Propeller on Propeller, Sphinx is really the tool you are looking for.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Nak said...
Brad, I tried the bst-0.18.5-Pre1-test5 version with my VPN up. It still showed an empty white box while it was scanning all the shares. Then, when it finally finished, there was a whole flurry of window updates just before the box disappeared. I think maybe the drawing is all being deferred until the event loop cycles on the Mac, and that's not happening while the code is walking the filesystem.
I've just uploaded -test6. I discovered a fantastic little OSX tool in the CHUD package that allows me to completely flush the filesystem cache without having to resort to a reboot for this sort of testing. I've realised quite a marked improvement in behaviour here with a few bits of code refactoring. If you have some time, I'd be interested in seeing if this does anything to improve things for you. I've been testing on 10.6.1 and 10.4.11. Can't reproduce the problem on 10.4.11 though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Just uploaded bst-0.18.5-Pre1-test7 which should fix this bug.
I've finally replaced my aging "chewing gum and duct tape" version control scripts with svn, so I should now be able to do these fixes from the office and release builds from my compile machine at home remotely. Let's see if it works 'eh ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
So, while the remote version control stuff worked great, of course I could not properly test the serial terminal under load without a board to connect it to.
Under load I found another bug in the hex display that only manifested itself with a fast data stream.
This one rolls up all the bits 'n bobs in all the last -test releases and hopefully will make the loader far more stable on Windows (particularly). I still can't make it misbehave on Vista, but I'm sure there are people who can.
I'd be particularly interested in hearing from any Mac users who get the white screen of death on startup with large remote filesystems. I have not been able to reproduce that reliably locally.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
As a side note, on my Ubuntu 9.10 setup, as of yesterday, there was a kernel update, but the functioning of BST has not been resolved. Still can not find the port.
Rsadeika said...
As a side note, on my Ubuntu 9.10 setup, as of yesterday, there was a kernel update, but the functioning of BST has not been resolved. Still can not find the port.
Yeah, I've been watching the kernel source as they update it, but no fix to the ftdi driver.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Cluso99 said...
Brad: I did not want to hijack the *nix thread.
Yes I realised the Zipit Z2 was alreading linux and they hacked it to open it up.
Would bst run on it??? Could be a nice field development platform Only 40 chars tho'.
"nice field development platform"?!?. I'd more describe it as "a tiny device requiring various forms of contortionism to get anything done at all". It is cute though.
bst? no. bstc, possibly. Its serial port has no DTR or RTS line and requires various forms of device hacking to bring it out. Its USB port is a Gadget, not a Host. So with no way to talk to a Propeller, a battery life of ~4 hours and 450g weight, I'm not seeing a lot of potential.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Those of us that may want to update in the field could either...
1. Use a miniSD to microSD and transfer files that way (if the prop has SD/miniSD/microSD)
2. Use the serial port. Nicer if we could use it as a PropPlug to download code, but serial would work in some cases.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
BradC, I keep getting an error message with BSTC's download feature. It's inconsequential to me since
the code seems to download fine, but it is somewhat annoying. Just thought to let you know in case you
haven't seen it. The PC is a core-duo 2GHz Vista laptop.
bstc -ls -d COM12 -p0 -L"..\BMADebugger_Demo_V1_6" pjvm.spin
Brads Spin Tool Compiler v0.15.4-pre2 - Copyright 2008,2009 All rights reserved
Compiled for i386 Win32 at 15:07:01 on 2009/12/05
...
Compiled 3718 Lines of Code in 0.526 Seconds
We found a Propeller Version 1
Ram verify error
Propeller Load took 3.65 Seconds
That is most odd. Does it do that every time? That message indicates the response we got back from the Propeller was not the one we wanted to see. I'll see if I can get ahold of a Windows machine to do some testing with.
Thanks for the headsup.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Comments
It's very curious that sample and vmmap can't dissect the bst process. What is bst written in?
Most interesting, however not entirely surprising. I have had huge problems with the carbon event queue and getting the OS to properly process events while the process is busy. I ended up having to put the compiler and loader into a separate thread so OSX would properly update the GUI while they were churning. Now I have a defined way to reproduce it I can try to work on it a bit more. I've nfs mounted a share from my linux server onto my G4 PPC Mac, but I send the packets around the world to give me about a 400ms delay. It's slowed the filesystem _right_ down nicely.
Pascal. It does not use carbon or cocoa services for anything other than the GUI elements. All the back end filesystem code uses a POSIX interface. Perhaps that is part of the issue in tracing things.
The reason it does not happen again if you close and re-open bst is Darwin is very good about caching mounted nfs filesystem data. unmount/remount the filesystems to empty the cache (or reboot) and it should do it again.
Thanks for the system info, that might help me a bit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thanks guys, I appreciate that.
I must be doing something wrong though, as I still see posts on the forum from time to time from Linux/Mac users struggling to get the Propeller Tool running under WINE. Aside from the block indent markers, is there any 5 star feature that the Prop tool has people find lacking in bst?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Actually, I never did a hex dump as everything I struggled to find in the Prop Tool hexdump is clearly laid out in the list file. Do you really get some use from the hex dump that's not satisfied by the listing?
I can put it on the todo list, sure.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Nothing wrong just perhaps not enough marketing.
"Mac/Linux/Windows IDE" May not be immediately recognizable to newcomers as a Prop Tool.
Where as "Propeller Tool Clone for Mac, Linux and Windows" might do the trick better. At the risk of being a bit "in the face" to Parallax which you may not want to do.
Actually I've always wondered how Parallax feels about BST basically obsoleting the Propeller Tool for so many of us.
I know you were not keen on releasing the source for BST but I'm wondering if you are up to releasing binaries for more platforms?
Specifically ARM. I'm looking forward to getting one of these beagleboard.org/. Not to mention the possibility of running on ARM based mobile phones, tablets and some net books.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
They feel relieved,
because no more users complain about the lack of tools for Mac OSX/Linux.
because while they have not the resources to do it and they would like to do it, they do not have to do it anymore
because they can fire up any linux box and program their propellers again while their windows machines go belly-up.
Just my 3 cents
(the same can be said about mpark's homespun).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
In the old days people like Bill Gates and Co wanted a lot of money for much lesser tools.
So that should make Parallax very happy and convince them they are doing something right.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
View -> Compiler Listing
Just leave it open in the background and it gets updated with every successful compile.
I don't think they particularly care to be honest. Does not matter what tools one uses, in the end they sell Propellers.
It's a effort/reward thing. I'd rather spend what time I have available fixing those 6 legged insects in the code (the little buggers are nesting!).
It's something I've thought about, but I currently have multiple machines for each platform I support (I actually bought one of the Mac's to support bst specifically - it sits in the corner burning Watts otherwise). I'd be interested in getting an ARM box if it would be useful. I've got a couple of iPAQ's running Linux somewhere that I had planned to play with using X remotely, but if there is a low-budget dedicated ARM box that will do the thing out of the box I'd sure have a go at it.
I'm not making any guarantees however, as I'm unsure at the moment of the level of support the fpc/lazarus toolchain has for ARM GUI stuff. Only one way to find out though.
The beagleboard kinda sounds interesting, but most of the netbooks are still x86 based, so it's a common platform to target. If I can get an ARM based netbook with SSD and 20 hours battery life, I'm there [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Just as a guide, how many lines of code is the command line BST program? And where did it come from - was it originally from parallax or did you write it all from scratch?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 11/28/2009 8:23:06 AM GMT
I did have a couple of PM's with Chip when I was trying to figure out why the Parallax compiler and my code generated 1LSB difference in floating point constants.
If you want Propeller on Propeller, Sphinx is really the tool you are looking for.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
I've just uploaded -test6. I discovered a fantastic little OSX tool in the CHUD package that allows me to completely flush the filesystem cache without having to resort to a reboot for this sort of testing. I've realised quite a marked improvement in behaviour here with a few bits of code refactoring. If you have some time, I'd be interested in seeing if this does anything to improve things for you. I've been testing on 10.6.1 and 10.4.11. Can't reproduce the problem on 10.4.11 though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
I do not know if it was previously reported, but I found the following:
- Send more than 16 bytes
repeat i from 0 to 17
Serial.tx(i)
- Receive data with the option "Display Hex", result:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
11
After the byte number 16, missing the next byte (10). The bug was repeated at the end of each line.
No, not previously reported. Thanks for that, I'll get it fixed in the next -pre release. (ie, asap)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
1. Serial.tx($01)
2. Serial.tx(i+1)
so that you can see if the $10 is the culprit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
No, I can reproduce the problem here just using local echo. It's a bug.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
I've finally replaced my aging "chewing gum and duct tape" version control scripts with svn, so I should now be able to do these fixes from the office and release builds from my compile machine at home remotely. Let's see if it works 'eh ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
So, while the remote version control stuff worked great, of course I could not properly test the serial terminal under load without a board to connect it to.
Under load I found another bug in the hex display that only manifested itself with a fast data stream.
This one rolls up all the bits 'n bobs in all the last -test releases and hopefully will make the loader far more stable on Windows (particularly). I still can't make it misbehave on Vista, but I'm sure there are people who can.
I'd be particularly interested in hearing from any Mac users who get the white screen of death on startup with large remote filesystems. I have not been able to reproduce that reliably locally.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
In the following:
cmp rtoken, #CT_LRESET: nopThe error is reported on the nop line.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Bewdy. Fixed, thanks [noparse]:)[/noparse]
bstc-0.15.4-pre2 & bst-0.18.5-Pre3 uploaded.
No other fixes, not an essential upgrade.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Post Edited (BradC) : 12/5/2009 7:09:25 AM GMT
FYI
Ray
Yeah, I've been watching the kernel source as they update it, but no fix to the ftdi driver.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Yes I realised the Zipit Z2 was alreading linux and they hacked it to open it up.
Would bst run on it??? Could be a nice field development platform
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
"nice field development platform"?!?. I'd more describe it as "a tiny device requiring various forms of contortionism to get anything done at all". It is cute though.
bst? no. bstc, possibly. Its serial port has no DTR or RTS line and requires various forms of device hacking to bring it out. Its USB port is a Gadget, not a Host. So with no way to talk to a Propeller, a battery life of ~4 hours and 450g weight, I'm not seeing a lot of potential.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
1. Use a miniSD to microSD and transfer files that way (if the prop has SD/miniSD/microSD)
2. Use the serial port. Nicer if we could use it as a PropPlug to download code, but serial would work in some cases.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
the code seems to download fine, but it is somewhat annoying. Just thought to let you know in case you
haven't seen it. The PC is a core-duo 2GHz Vista laptop.
Thanks for the headsup.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.