Luis: You are right. I have obviously not looked into Free Pascal / Lazarous deeply enough.
Are you saying that with a simple change of some settings in Lazarous BST could be compiled to use Qt? If so that is brilliant and I did not know there was that flexibility.
Now, if BST can be built for Qt it can also be built for Qt Embedded in which case X Windows is no longer required to run it on Linux. Which is basically the point I was trying to make.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
CounterRotatingProps: Running BST on Linux without X, just in the frame buffer, is a fascinating idea. Only two problems:
1) It's BradC's program so it only runs anywhere if he wants it to.
2) Despite what Luis said I'm sure getting BST to run that way is not so trivial.
So no new thread just yet...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Luis: You are right. I have obviously not looked into Free Pascal / Lazarous deeply enough.
Are you saying that with a simple change of some settings in Lazarous BST could be compiled to use Qt? If so that is brilliant and I did not know there was that flexibility.
Now, if BST can be built for Qt it can also be built for Qt Embedded in which case X Windows is no longer required to run it on Linux. Which is basically the point I was trying to make.
2) Despite what Luis said I'm sure getting BST to run that way is not so trivial.
This is a pretty key point. I've had to fix or work around a couple of bugs in the GTK2 interface (as I've had in the Win32 widget set and the Carbon interface). The main reason I chose GTK2 is it is installed by default on all my machines and the QT interface was incredibly immature when I started. There is a fair amount of testing and beating things into submission to make this stuff work seamlessly across the platforms. I've been considering a QT target compile as a bit of a test, but it will be QT targeted at X. The main reason I'm considering testing QT is on OSX, QT is using a lot of Cocoa, whereas that is a very immature interface with Lazarus.
I've had a full X install with WINE and the whole application running from a 32M flash card, so running X is not an onerous task. In addition, X supports *way* more hardware than the kernel does with an accelerated FB driver, and trust me, the VESA FB driver is _slow_. Really, really slow. You do *not* want to be using a GUI that does lots of redraws / painting on a non-accelerated driver (and the highlighter in bst does a _lot_ of repaints).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Ok I started a new thread for the Linux: Customized Linux system entirely from source. Let me know what you want for the title and I'll modify what I have so far
CounterRotatingProps: You mentioned the compiler could automatically go out the the web and OBEX2 server and get the missing object. NO - that is what I hate about Windoze - I have no control to stop this. There are all sorts of programs doing this nowadays, as well as Windoze itself. My pc has become a slug because all programs are continually looking on the web. Unfortunately, the apps I use only run on windoze, otherwise I'd use a mac.
Anyway, can we get back on topic please. I want to see what else is in Prop II and any other suggestions that would make it better. Sapeiha had to move to a seperate thread to get his point across.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Anyway, can we get back on topic please. I want to see what else is in Prop II and any other suggestions that would make it better.
Cluso: Yes, indeed -· it seemed like this was drifting too far, that's why I suggested the other thread too. (Then again, Chip mentioned a few things that opened the door pretty wide re the prop2 in considering not using or overcoming the entire OS!)
> ...automatically go out the the web and OBEX2 server and get the missing object. NO - that is what I hate about Windoze - I have no control to stop this.
Well, it would be pretty stupid for us to write such an application and not have a parm to turn this on/off at will.
I don't really think we are off topic as Chip has been tossing out ideas for us to think about - the focus on the last pages has been how we might improve the current Prop's IDE(s) in a new Prop2·version. Linux·entered the·equation at the moment the OS's·came into question.
I'm still interested in discussing the possible improvements to the IDE's·as part of the overall discussion of what might make PropII better.
Luis Digital said...
I love Linux, but I think we're off topic.
Chip must have a headache with so many things we have said.
Let's keep things simple.
Chip, why not a poll?
* IDE on Propeller II?
- No
- Yes
* Open source tools?
- No
- Yes
Or something.
No headache, at all. This discussion is interesting to me.
As for the poll, "Yes" on both.
You all needn't assume that built-in tools will come at the expense of any type of PC-based tools, nor that expensive ROM will be wasted on them. There's room for all options. I, personally, am very motivated to make a resident tool set that talks to a monitor and USB keyboard/mouse. I'd even put ALL the source code on there so that one could make mods and recompile even the compiler. The main point is that one can have full access to everything that makes it go. It will be the antithesis of a modern PC.
> What those customers want are detailed data sheets and professional-level development tools that run alongside their other
> software under Windows or, to a lesser extent, OS/X and Linux.
Absolutely right!
I'm aware that quite some of my posts look like beeing negative about the Prop or Parallax.*) Parallax does a very good job fr the educational market, but not not for the prfessional market. IMO! The Prop II has a **LOT** of potential for that market, so why not leverage it?
*) I like the Prop, or I wouldn't be around here.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
Chip said...
You all needn't assume that built-in tools will come at the expense of any type of PC-based tools, nor that expensive ROM will be wasted on them. There's room for all options. I, personally, am very motivated to make a resident tool set that talks to a monitor and USB keyboard/mouse. I'd even put ALL the source code on there so that one could make mods and recompile even the compiler. The main point is that one can have full access to everything that makes it go. It will be the antithesis of a modern PC.
I think this would be fantastic. There would be no downside for professional users - just ignore it if you do not want it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
To go back a few pages to the discussion about the counters...
Can we steal the way the PWM works in the AVR chips and add it as another mode for the counters in the propeller? That may get away from the problems Brad was having. What the AVR counters do is to have something similar to PHSA and then have another value (lets say CMPA) that is compared to PHSA every clock cycle. The result of the compare is then the output to the pin. So if we looked at the the table in the propeller manual for the counter modes we would have something like this
You would make FRQx to be powers of two and that would effectively set your resolution and speed. Of course you would need some more instructions to load CMPx but it seems like there is plenty of room for them now.
Now for audio it may actually need to be phase correct pwm instead. In that case instead of the counter just counting up and then wrapping around to zero it needs to count up to the maximum and then count back down. I've attached what the PHSx and output look like when CMPx is set to 7.
Chip must have a headache with so many things we have said.
Let's keep things simple.
Chip, why not a poll?
* IDE on Propeller II?
- No
- Yes
* Open source tools?
- No
- Yes
Or something.
No headache, at all. This discussion is interesting to me.
As for the poll, "Yes" on both.
You all needn't assume that built-in tools will come at the expense of any type of PC-based tools, nor that expensive ROM will be wasted on them. There's room for all options. I, personally, am very motivated to make a resident tool set that talks to a monitor and USB keyboard/mouse. I'd even put ALL the source code on there so that one could make mods and recompile even the compiler. The main point is that one can have full access to everything that makes it go. It will be the antithesis of a modern PC.
Very well, then case closed.
See you in a year with Propeller II.
potatohead said...
JTAG sounds like one of those things that is necessary to deal with buggy chips.
It's nothing to do with that. It's an industry standard and offers programming and debugging with a standard interface. I use it with ARMs, AVRs, XMOS, Xilinx and Altera CPLDs and FPGAs, and several other devices. It's very useful.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
It is still used for that purpose, but it's much more widely used for programming and debugging. The Propeller II will be a lot more popular for professional applications if it has JTAG.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
How much overhead would JTAG really have? Chip mention somewhere (here?) there are consequences to using it ... could it's footprint push out other more desirable features due to limited real estate?
The issue that with JTAG that Chip brought up is that every node, I/O pin, address/data bus line, register bit, that you want to include in the JTAG chain makes that node a little more complicated. That eats silicon area which could otherwise be used for something more useful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
1) Would you consider open sourcing all of the Prop I/II toolset(s)?
This would allows the community to inspect and leverage the working body of code based knowledge and create our own solutions. Parallax engineers can focus on the chip, built in-IDE lifeboat, and community engagement.
Cross platform command line tools are easier to maintain than gui based. Veteran software engineers are also familiar with command line compiler/assembler/linker toolsets. They marry nicely to mainstream IDEs (Code:Blocks, Eclipse, gvim, and etc.). The GNU toolset (like gcc) and Intel compilers are examples. A proprietary IDE in ROM or on Windows, by definition, is not familiar.
The IDE lifeboat will be nice for hobbyists-on-the-go and people using the Prop II in 2419 A.D. Although, it could limit its professional use. Some regulated devices must not have compilable code or development environments on them.
2) Consider ditching Windows by ignoring it.
A community based Windows solution is likely to crop up on its own anyways. Several already exist for the Prop I. You could consider 'certifying' the ones that meet certain quality criteria.
OS X (A certified open source BSD Unix under the hood) is worth the money for a lean and polished user experience. The pure elegance of a Unibody Macbook is hard not to admire.
Ubuntu and Fedora Linux distros are very good as a free alternative.
My main machine is a MacBook Pro with Ubuntu 9.10 and Windows XP Pro (SP3) running under VmWare Fusion (Virtual Machine). When Windows inevitably gets cagey it's deleted with a few clicks and restored from a known clean snapshot.
The only reason I use Windows XP is for Prop I development due to a lack of supported cross platform solutions. Imagine that! I prefer Imagecraft's C compiler over Catalina, for the time being. It only runs on Windows. [noparse]:([/noparse]
3) Java
It's a perversion of C/C++ and should be avoided like the plague.
Thank you so much for taking the time to engage your community! [noparse]:)[/noparse]
I've got the pin DACs redesigned to have true 75-ohm impedances, per your recommendation.
Below is an image of the SPICE output for the VGA·DAC stepping at 10ns intervals from %00000 to %11111. This is unloaded, and you'll note that the output is now 2.0V, not 3.3V. Under a 75-ohm load, the peak output drops to 1.0V, which is what the VGA monitor needs for full R, G, or B.
It took me a while to get the math worked out, because I didn't realize at first how simple it could be: just two resistors in series from 3.3V to VSS, which, if arranged·in parallel·must be 75 ohms, and at the series junction there is 2.0V. Note the internal power dissipation for this DAC - it's rather high.
Thanks for setting me straight on this. This will certainly help signal integrity.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 12/1/2009 9:17:10 AM GMT
There is a lot of talk about extending working data space beyond the Hub's ram and also having filesystem storage for multiple small programs to be loaded on demand to form a larger application.
Has there been much discussion on extending the video registers to providing for a very high speed hardware SPI interface in each Cog that can handle both send and receive data at full clock speed? May not quite be a system bus but would be able to serve the equivalent function under control of, say, the LMM kernel.
There is an opportunity to add memory protection and the likes on top of that. Again, this idea is targeted at LMM. The Cog machine code is still completely deterministic in Cog's that aren't running the LMM kernel.
I certainly agree with Phil on the necessity of having a full-featured development tools primarily for Windows, as it has the largest user base. Whether that's a good thing or not can certainly be argued.
Of course, releasing the dev tools as open source is at least a major step forward in cross-platform compatibility. It wouldn't be surprising at all to see the tools ported to Linux/OSX within months of it's release.
Chip, since you're so passionate about an alternative to the PC environment (linux/windows/mac/etc aren't all that different) an in-rom IDE is idealistically the best way to go about it. This issue obviously means so much to you, I say "DO IT!" However, come the year 2075, I think finding SPI memory or, USB/flash sticks will be impossible anyways, so what's the point?
markaeric says "linux/windows/mac/etc aren't all that different"
Ouch, a statement like that is a good way to get yourself hung drawn and quartered by fans from all sides !!
In 2075 some nut head will be simulating Propellers using his latest quantum computer just so that he can preserve, in a living way, all the great software he found in an OBEX archive. Rather like we are running CP/M on the Propeller now[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
My point was simply that most modern computers have integrated functionality that most people don't need/use, at least compared to the type of dev environment Chip was talking about. This is not a matter of "my OS is better than yours!", or anything of that nature. I see nothing wrong with wanting to do your development from the platform that you prefer, it's just that it's a matter of fact that most users will be using windows.
BTW, in response to someone's mention about qnx - I used it several years ago. They had a version that fit on a measly floppy disk. but had high-res video support (at least 256 color, but it may have even been 16-bit), a couple of basic applications, a full TCP/IP stack, and a web browser. It worked flawlessly, and played well with all of my hardware (though the drivers may not have supported all it's functionality). I also tried a more full-featured version. It worked great, but I didn't have much use for it.
Commercially, QNX is designed to be used in real-time, mission-critical embedded computer systems. For those of you who have never tried it, I think it's worth a shot. From my experience, it's certainly more stable than the various BSD and Linux distros I've tried.
BTW, QNX POSIX compliant, so in theory, unix/linux/bsd code could be ported relatively easy.
markaeric: I think you a right about PC "baggage".
Side thought: Wouldn't it be great if I could drive signals down a USB cable as easily as an old UART? All that speed and no worries about drivers. At the other end of the cable my prop sucks up data with a simple PASM program. No need for a USB serial adapter or whatever. Why can't I do that?
And why is it that there is no way to "bit-bang" data in or out of a PC ever since we lost our beloved parallel ports? The great PC designer gods have a lot of questions to answer.
Not sure about "matter of fact that most users will be using windows". I have not met, face to face, anyone writing code for anything using Windows for two years now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
Are you saying that with a simple change of some settings in Lazarous BST could be compiled to use Qt? If so that is brilliant and I did not know there was that flexibility.
Now, if BST can be built for Qt it can also be built for Qt Embedded in which case X Windows is no longer required to run it on Linux. Which is basically the point I was trying to make.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
And it's a point well taken!
It would probably be a good idea to follow Bob Lawrence's suggestion above and start a new thread about this.
(RE X being heavy - sorry, mate, that's my 60's Ami-English showing --- meant heavy as in "heavy man" ... too much for some minds (like mine) to bear
- H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1) It's BradC's program so it only runs anywhere if he wants it to.
2) Despite what Luis said I'm sure getting BST to run that way is not so trivial.
So no new thread just yet...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, yes, yes, yes...
See a complete list of supported interfaces.
But I must clarify that it is sometimes not so easy because there are bugs or things that are implemented a little differently.
Windows CE
Post Edited (Luis Digital) : 11/29/2009 11:56:41 PM GMT
This is a pretty key point. I've had to fix or work around a couple of bugs in the GTK2 interface (as I've had in the Win32 widget set and the Carbon interface). The main reason I chose GTK2 is it is installed by default on all my machines and the QT interface was incredibly immature when I started. There is a fair amount of testing and beating things into submission to make this stuff work seamlessly across the platforms. I've been considering a QT target compile as a bit of a test, but it will be QT targeted at X. The main reason I'm considering testing QT is on OSX, QT is using a lot of Cocoa, whereas that is a very immature interface with Lazarus.
I've had a full X install with WINE and the whole application running from a 32M flash card, so running X is not an onerous task. In addition, X supports *way* more hardware than the kernel does with an accelerated FB driver, and trust me, the VESA FB driver is _slow_. Really, really slow. You do *not* want to be using a GUI that does lots of redraws / painting on a non-accelerated driver (and the highlighter in bst does a _lot_ of repaints).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Ok I started a new thread for the Linux: Customized Linux system entirely from source. Let me know what you want for the title and I'll modify what I have so far
Here we go:
http://forums.parallax.com/showthread.php?p=860027
Chip must have a headache with so many things we have said.
Let's keep things simple.
Chip, why not a poll?
* IDE on Propeller II?
- No
- Yes
* Open source tools?
- No
- Yes
Or something.
Anyway, can we get back on topic please. I want to see what else is in Prop II and any other suggestions that would make it better. Sapeiha had to move to a seperate thread to get his point across.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
> ...automatically go out the the web and OBEX2 server and get the missing object. NO - that is what I hate about Windoze - I have no control to stop this.
Well, it would be pretty stupid for us to write such an application and not have a parm to turn this on/off at will.
I don't really think we are off topic as Chip has been tossing out ideas for us to think about - the focus on the last pages has been how we might improve the current Prop's IDE(s) in a new Prop2·version. Linux·entered the·equation at the moment the OS's·came into question.
I'm still interested in discussing the possible improvements to the IDE's·as part of the overall discussion of what might make PropII better.
cheers
- H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
As for the poll, "Yes" on both.
You all needn't assume that built-in tools will come at the expense of any type of PC-based tools, nor that expensive ROM will be wasted on them. There's room for all options. I, personally, am very motivated to make a resident tool set that talks to a monitor and USB keyboard/mouse. I'd even put ALL the source code on there so that one could make mods and recompile even the compiler. The main point is that one can have full access to everything that makes it go. It will be the antithesis of a modern PC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Well said!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
> software under Windows or, to a lesser extent, OS/X and Linux.
Absolutely right!
I'm aware that quite some of my posts look like beeing negative about the Prop or Parallax.*) Parallax does a very good job fr the educational market, but not not for the prfessional market. IMO! The Prop II has a **LOT** of potential for that market, so why not leverage it?
*) I like the Prop, or I wouldn't be around here.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Graham
Can we steal the way the PWM works in the AVR chips and add it as another mode for the counters in the propeller? That may get away from the problems Brad was having. What the AVR counters do is to have something similar to PHSA and then have another value (lets say CMPA) that is compared to PHSA every clock cycle. The result of the compare is then the output to the pin. So if we looked at the the table in the propeller manual for the counter modes we would have something like this
Counter Mode - Accumulate FRQx to PHSx - APin Output - BPin Output
PWM - Always - CMPx>PHSx - CMPx<PHSx
You would make FRQx to be powers of two and that would effectively set your resolution and speed. Of course you would need some more instructions to load CMPx but it seems like there is plenty of room for them now.
Now for audio it may actually need to be phase correct pwm instead. In that case instead of the counter just counting up and then wrapping around to zero it needs to count up to the maximum and then count back down. I've attached what the PHSx and output look like when CMPx is set to 7.
Very well, then case closed.
See you in a year with Propeller II.
It's nothing to do with that. It's an industry standard and offers programming and debugging with a standard interface. I use it with ARMs, AVRs, XMOS, Xilinx and Altera CPLDs and FPGAs, and several other devices. It's very useful.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Chip,
1) Would you consider open sourcing all of the Prop I/II toolset(s)?
This would allows the community to inspect and leverage the working body of code based knowledge and create our own solutions. Parallax engineers can focus on the chip, built in-IDE lifeboat, and community engagement.
Cross platform command line tools are easier to maintain than gui based. Veteran software engineers are also familiar with command line compiler/assembler/linker toolsets. They marry nicely to mainstream IDEs (Code:Blocks, Eclipse, gvim, and etc.). The GNU toolset (like gcc) and Intel compilers are examples. A proprietary IDE in ROM or on Windows, by definition, is not familiar.
The IDE lifeboat will be nice for hobbyists-on-the-go and people using the Prop II in 2419 A.D. Although, it could limit its professional use. Some regulated devices must not have compilable code or development environments on them.
2) Consider ditching Windows by ignoring it.
A community based Windows solution is likely to crop up on its own anyways. Several already exist for the Prop I. You could consider 'certifying' the ones that meet certain quality criteria.
OS X (A certified open source BSD Unix under the hood) is worth the money for a lean and polished user experience. The pure elegance of a Unibody Macbook is hard not to admire.
Ubuntu and Fedora Linux distros are very good as a free alternative.
My main machine is a MacBook Pro with Ubuntu 9.10 and Windows XP Pro (SP3) running under VmWare Fusion (Virtual Machine). When Windows inevitably gets cagey it's deleted with a few clicks and restored from a known clean snapshot.
The only reason I use Windows XP is for Prop I development due to a lack of supported cross platform solutions. Imagine that! I prefer Imagecraft's C compiler over Catalina, for the time being. It only runs on Windows. [noparse]:([/noparse]
3) Java
It's a perversion of C/C++ and should be avoided like the plague.
Thank you so much for taking the time to engage your community! [noparse]:)[/noparse]
graham
I've got the pin DACs redesigned to have true 75-ohm impedances, per your recommendation.
Below is an image of the SPICE output for the VGA·DAC stepping at 10ns intervals from %00000 to %11111. This is unloaded, and you'll note that the output is now 2.0V, not 3.3V. Under a 75-ohm load, the peak output drops to 1.0V, which is what the VGA monitor needs for full R, G, or B.
It took me a while to get the math worked out, because I didn't realize at first how simple it could be: just two resistors in series from 3.3V to VSS, which, if arranged·in parallel·must be 75 ohms, and at the series junction there is 2.0V. Note the internal power dissipation for this DAC - it's rather high.
Thanks for setting me straight on this. This will certainly help signal integrity.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 12/1/2009 9:17:10 AM GMT
Has there been much discussion on extending the video registers to providing for a very high speed hardware SPI interface in each Cog that can handle both send and receive data at full clock speed? May not quite be a system bus but would be able to serve the equivalent function under control of, say, the LMM kernel.
There is an opportunity to add memory protection and the likes on top of that. Again, this idea is targeted at LMM. The Cog machine code is still completely deterministic in Cog's that aren't running the LMM kernel.
'Just now caught your post about the DACs. It looks great! And it's really cool that the DACs are built in!
-Phil
Of course, releasing the dev tools as open source is at least a major step forward in cross-platform compatibility. It wouldn't be surprising at all to see the tools ported to Linux/OSX within months of it's release.
Chip, since you're so passionate about an alternative to the PC environment (linux/windows/mac/etc aren't all that different) an in-rom IDE is idealistically the best way to go about it. This issue obviously means so much to you, I say "DO IT!" However, come the year 2075, I think finding SPI memory or, USB/flash sticks will be impossible anyways, so what's the point?
Ouch, a statement like that is a good way to get yourself hung drawn and quartered by fans from all sides !!
In 2075 some nut head will be simulating Propellers using his latest quantum computer just so that he can preserve, in a living way, all the great software he found in an OBEX archive. Rather like we are running CP/M on the Propeller now[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
BTW, in response to someone's mention about qnx - I used it several years ago. They had a version that fit on a measly floppy disk. but had high-res video support (at least 256 color, but it may have even been 16-bit), a couple of basic applications, a full TCP/IP stack, and a web browser. It worked flawlessly, and played well with all of my hardware (though the drivers may not have supported all it's functionality). I also tried a more full-featured version. It worked great, but I didn't have much use for it.
Commercially, QNX is designed to be used in real-time, mission-critical embedded computer systems. For those of you who have never tried it, I think it's worth a shot. From my experience, it's certainly more stable than the various BSD and Linux distros I've tried.
BTW, QNX POSIX compliant, so in theory, unix/linux/bsd code could be ported relatively easy.
Side thought: Wouldn't it be great if I could drive signals down a USB cable as easily as an old UART? All that speed and no worries about drivers. At the other end of the cable my prop sucks up data with a simple PASM program. No need for a USB serial adapter or whatever. Why can't I do that?
And why is it that there is no way to "bit-bang" data in or out of a PC ever since we lost our beloved parallel ports? The great PC designer gods have a lot of questions to answer.
Not sure about "matter of fact that most users will be using windows". I have not met, face to face, anyone writing code for anything using Windows for two years now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 12/29/2009 1:55:49 PM GMT