@dMajo: the movs/movd/movi instructions can set the z flag if the result is 0.
Location $0 should definately not be used. We use this to store offset tables so that we do not have to add an offset to the start of the table. As I said above...
org $0
table jmp #next
long $xx
long $yy
.....
next mov table, table0 'place the first table into $0
.....
mov offset, #10 'set the table offset into offset
jmp offset 'indirect jump to the decoded routine
If you were to overwrite $0 then we would have to add the table location to offset as well.
@Chip: You can use 6 different resistors on a single pin to give 6 different states by testing the input using the internal 10K & 1K5 pullups and pulldowns. Values are approximately 20K, 5K 680R as either pullup or pulldown. This could be used to determine a boot option such as order to boot, internal IDE, etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I've also missed a COG_RESTART instruction sometimes. This is just a kind of
very simple interrupt possibility. I will give you 3 examples where it can be useful:
1) Debugging! With my Assembly code debugger (PASD) it is not possible to stop the
execution, manually and look at the register values. In Prop1, the only way to stop is
COGSTOP and then COGINIT which reloads all the cog ram, and the current values at stop
are lost.
A COGRESTART would allow to keep the values in the cog ram.
2) Break an assembly loop, which is as fast as possible. I tried to sample some pins to
a circular buffer as fast as possible (for a scope). With a cogrestart, it would be
possible to break this sampling loop by another cog, when a specific trigger occures,
and let the cog then write the sampled data from cog ram into hubram.
Now this is only possible with polling in the loop, which slows down the sampling loop.
3) Timeout at WAITPEQ, WAITPNE, WAITVID and other endless loops. You can write a
<jump to the timeout-handler> in cog addr 0, and then start another cog for the timeout
before the critical loop.
When the second cog reaches the timeout, it restarts cog1 which has the effect of a jump
to the timeout handler.
With Prop2, which is 8 times faster, point 2) may be not so important. And point 3) is
solved for WATPxx, as I read before in this thread.
But for debugging, and when you go to the limits of speedy loops, the use of a second cog,
to interrupt the first one (without loosing the data in cog ram) would be very useful.
Since you are implementing 3 x 32 bit ports and an 8 bit port for "D", could D be fully implemented as 32 bits, but only 8 with external drivers? This way we would have 24 bits on port D for cog to cog communications. Another use could be the counters where currently we have to output on one pin as a clock which gets used internally, but wastes a pin.
And what about having an address to which cog to send a message and a kind of arbitration, so you just output (address/value). Like the links in good old transputers?
Sapieha, I have thought 0 is ok but it could be configurable or it could be the last one (eg. 495 actually on prop1).
Have you read my considerations about this? In your idea will the CogReset· reset also dir/out registers or only PC. Isn't better just to "cont-inue" a cog that have self-paused?
org 0
jmp next
halt: pause ; waits till some other cog execute continue
next: program code
.
.
.
.
<mov dira, #0> ; optional
<mov outa, #0> ; optional
jmp halt
Isn't this equivalent? And have several applications
BTW: @Chip, how is the instruction fetching of the new PropII made? It will be still necessary to interpose a line between the modifier and the modified code lines?
Yes, when you modify an instruction ahead, you must execute one in the middle, like this:
@Chip: You can use 6 different resistors on a single pin to give 6 different states by testing the input using the internal 10K & 1K5 pullups and pulldowns. Values are approximately 20K, 5K 680R as either pullup or pulldown. This could be used to determine a boot option such as order to boot, internal IDE, etc.
That's a neat idea! What I'll try to do is make some graduated resistances for the pull-ups/pull-downs, and also have a proper VDD/2 threshold sensor. Then, like you said, a single resistor could provide perhaps 4 levels, or two bits, then doubling that for high vs. low. I think we could get 3 bits out of one pin that way. Eight basic configuration options for the IDE should be enough. So, one pin is all that's needed.
...In thinking about this more: over process, temperature, and voltage, we could not rely on the chip having better than +/-20% absolute tolerance, which is pretty poor. However, if rather than make the graduated values follow an R, 2R, 3R, 4R...) pattern, we could do (R, 2R, 4R, 8R...) and easily get 16 levels per high or low resistor attached. 5% tolerant resistors would be fine, too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/26/2009 5:04:15 PM GMT
Hi Chip, congratulations to you and your team for a magnificent device that truly breaks the mould. do you have any tentative dates yet for the PII release?
My resistor calculations didn't make complete sense, because I forgot to account for the impedance of the tristrate resistor drivers. They add the extra ohms that would result in a 1.0V output at DAC level $30.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/26/2009 11:56:58 PM GMT
A way to measure the difference between two signals could be prepared: I face the problem to measure a high voltage (battery 24V) and the current through a high side shunt. How to do that? As the battery voltage is only changing slowly, while the shunt voltage changes fast, I use two of the props ADC's. Now I connect a low pass to the compensating output of the battery ADC. The pulses are integrated and the cap charges to a voltage proportional to the battery voltage, but negative in relation to the comparator level of the input. This voltage is fed into the shunt ADC, so the ADC is measuring the difference between the shunt terminals. The precision is mainly effected by the precision of the input resistors, the resolution is not to high, but we have a "differential" input. Maybe, the low pass can be integrated if there is a way to do it with a little capacitor.
ErNa
tonyp12 said...
>Chip Gracey (Parallax) said..
>From what I gather, the toggle rate for such is in the GHz. That's beyond our 3.3V I/O capability.
Lowest pixel clock rate for hdmi is 25Mhz,
so if you somehow could get Waitvid to be programmed to send burst of 10bit data at 25mhz
But this would mean a bit rate of 250MHz if the pixel rate was 25MHz, right? I think the most interesting modes are going to require bits rates at over 1GHz.
When we could have 720x480p of pure digital display.
PropII will be around to 2020, Analog VGA and PS2 etc will long gone by then.
ErNa said...
A way to measure the difference between two signals could be prepared: I face the problem to measure a high voltage (battery 24V) and the current through a high side shunt. How to do that? As the battery voltage is only changing slowly, while the shunt voltage changes fast, I use two of the props ADC's. Now I connect a low pass to the compensating output of the battery ADC. The pulses are integrated and the cap charges to a voltage proportional to the battery voltage, but negative in relation to the comparator level of the input. This voltage is fed into the shunt ADC, so the ADC is measuring the difference between the shunt terminals. The precision is mainly effected by the precision of the input resistors, the resolution is not to high, but we have a "differential" input. Maybe, the low pass can be integrated if there is a way to do it with a little capacitor.
ErNa
On the next Propeller there are very accurate delta-sigma ADCs built into every pin. With some precision voltage dividers and filter caps, you could do this differential measurement on two pins, with each using two resistors for the divider and a cap for the low-pass filter.
dMajo said...
@Chip, what about my question here http://forums.parallax.com/showthread.php?p=858929. I am specially interested in movs/movd instructions. You have put together a magnificent assembler and more an as more I familiarize with it and its sefl-modifyng possibilities the more I love it. Now (hope you have understood the way I'd like these two instructions to work with and without the wc flag set - source selector switch, Carry flag not modified) when I execute a line (where the destination was modified by previous instruction) and next execution is based upon the result of this line you can save a lot of lines with this. Here is an example:
This is possible to do using the wc, though it creates an ugly exception. It could be covered up by adding, as someone suggested, a MOVSD and MOVDD instruction which could affect the 'wc' opcode bit. The deal would be that MOVS, MOVD, MOVSD, and MOVDD would no longer allow for 'wc', as·its state·would now be determined by the instruction·mnemonic.
Spreader said...
Hi Chip, congratulations to you and your team for a magnificent device that truly breaks the mould. do you have any tentative dates yet for the PII release?
I suppose a year, but I said that a year ago, too.
I need that for one more posiblity.
In my programs that I work on to some customer I need have one SUPERVISOR COG that can control all others (You said simple interupt) it is more as that.
BUT has same function and many usages. As I reuse area of HUB memory that COG code reside with start ... I cant simply reload it (and it take to much time)
And as You said with system that is in Propeller I. I lose all data stored in COG's Variable bufer that was colected in some time and COG wil after RESTART USE it ........... Important that this data are from last RUN.
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.
I need that for one more posiblity.
In my programs that I work on to some customer I need have one SUPERVISOR COG that can control all others (You said simple interupt) it is more as that.
BUT has same function and many usages. As I reuse area of HUB memory that COG code reside with start ... I cant simply reload it (and it take to much time)
And as You said with system that is in Propeller I. I lose all data stored in COG's Variable bufer that was colected in some time and COG wil after RESTART USE it ........... Important that this data are from last RUN.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95 Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Hi Chip, congratulations to you and your team for a magnificent device that truly breaks the mould. do you have any tentative dates yet for the PII release?
I suppose a year, but I said that a year ago, too.
If you rush the chef you get a lousy meal!
Chip, it looks like you are adding quite a few new assembler instructions. How are you massaging things to fit them into the existing 32 bit opcode structure, or have you changed the opcode structure?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Hi Chip, congratulations to you and your team for a magnificent device that truly breaks the mould. do you have any tentative dates yet for the PII release?
I suppose a year, but I said that a year ago, too.
If you rush the chef you get a lousy meal!
Chip, it looks like you are adding quite a few new assembler instructions. How are you massaging things to fit them into the existing 32 bit opcode structure, or have you changed the opcode structure?
I took one regular S,D-type instruction space and used the S field to define the functionality while the·D field·declares the register to work on. With 512 immediate S possibilities, there's lots of space for these new instructions. Many of them take a partial span of this space to declare some embedded constants.
...In thinking about this more: over process, temperature, and voltage, we could not rely on the chip having better than +/-20% absolute tolerance, which is pretty poor. However, if rather than make the graduated values follow an R, 2R, 3R, 4R...) pattern, we could do (R, 2R, 4R, 8R...) and easily get 16 levels per high or low resistor attached. 5% tolerant resistors would be fine, too.
Yes. This circuitry would only be required on the top pin (if it is complex) which would be used as a configuration pin. And it can still be used as an output later. 5% tolerance (although 1% are pretty much the norm) and yes, would have to allow for 20% process variation. This is an extremely simple mechanism to select boot options. In a proto board, 3 machine pin sockets would allow various resistors to be plugged in.
Have you thought about the nr option writing to a register/cog location. Further thoughts, $1FF might be the easiest as a set of 9 'OR' gates on the write address or'd with the nr bit. An exception would be the read/write hub instructions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Fair enough but it was the "licensed for ... encrypted signals." that worries me. I have a gut feeling we should not be supporting that stuff in anyway let alone paying licence fees for it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Please consider Unix(OS X)/Linux as the cross development platform of choice.
We'll probably first support Windows, because we don't know any better, but anything else could follow.
Chip, if you really want to break away from Windows you just have to do it. Stop using the excuse of "because we don't know any better." Parallax is a collection of very smart people who do know better. Start infesting the office with a few boxes running the other operating systems and let the process begin organically.
I'd suggest doing exactly what BradC is doing by decoupling the IDE, compiler, and loader. If you can only make the IDE on Windows at first then so be it. But if there's a Parallax-sanctioned command-line compiler and loader available for the Prop II on OS X and Linux from day one, it will make things a lot easier for your ever-growing corps of non-Windows users. We can implement the IDE on our platforms.
-Steve
This thread is exploding in a half-dozen different directions at once and I can't keep up so please forgive me if this post is redundant.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ OS-X: because making Unix user-friendly was easier than debugging Windows
With the Propeller I many made that suggestion, but did not agree Parallax. Then, as they gave some information and was achieved through reverse engineering to make several compilers and emulators.
Lost Parallax? On the contrary, won more users.
What I think they should do with the next version is to give all the specifications, in order to create all kinds of tools.
All businesses are opening up their data, because the time to pay $ 1000.00 by a compiler or just use Windows has passed.
Sure, they can continue with its model because it is better for them to support and write the documentation, but it is important to give information to create other tools.
I'd suggest doing exactly what BradC is doing by decoupling the IDE, compiler, and loader. If you can only make the IDE on Windows at first then so be it. But if there's a Parallax-sanctioned command-line compiler and loader available for the Prop II on OS X and Linux from day one, it will make things a lot easier for your ever-growing corps of non-Windows users. We can implement the IDE on our platforms.
bstc was spawned from the interpreter source being posted. I figured if I had that and knew precisely what it was doing with the bytecodes I could write a compiler to compile them. That, and I really don't like windows. I did originally ask for some information to try and enhance WINE to run the propeller tool.
It is a bit of a shame that nobody outside of this forum knows you can develop for the propeller outside of a windows environment though.
I don't particularly agree that the IDE, compiler and loader are decoupled though. The IDE has some very, very deep hooks into the compiler to allow access to the symbol table so that when you click on a symbol in the editor you get some information about it down the bottom (plus a few other funky background bits). As I had no experience previously providing cross platform tools, I wrote the loader first as a test, then the compiler and then the IDE followed. They are still published as separate tools as I find it useful to have command line tools, but in the IDE they are as tightly coupled as you could get. There is no way to separate out the compiler and substitute it for example.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
I'm not going to get started on this one, but really, why on earth would Parallax switch to making compilers for OS's that are simply a geek fad that will be soon outdated and then to keep up with technology will have to get as stuffed up as Windows? It is OK to have both compilers, but why switch entirely? If you switched OS's on compilers, then me allong with several others would have to backup all our data and change Operating Systems on our programming computers. I vote to stick with windows but to also put up 3rd party Linux and Mac compilers on your download page listed as 3rd party. This way compilers like Brad's could be used by non forum users/viewers too.
Don't let this thread turn into an OS battle, though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Computers are microcontrolled.
dMajo said...
BTW: @Chip, how is the instruction fetching of the new PropII made? It will be still necessary to interpose a line between the modifier and the modified code lines?
Chip Gracey said...
Yes, when you modify an instruction ahead, you must execute one in the middle ...
Thank goodness this "feature" will propagate to the P2. It's what makes coroutine implementation drop-dead simple!
Comments
Location $0 should definately not be used. We use this to store offset tables so that we do not have to add an offset to the start of the table. As I said above...
org $0
table jmp #next
long $xx
long $yy
.....
next mov table, table0 'place the first table into $0
.....
mov offset, #10 'set the table offset into offset
jmp offset 'indirect jump to the decoded routine
If you were to overwrite $0 then we would have to add the table location to offset as well.
@Chip: You can use 6 different resistors on a single pin to give 6 different states by testing the input using the internal 10K & 1K5 pullups and pulldowns. Values are approximately 20K, 5K 680R as either pullup or pulldown. This could be used to determine a boot option such as order to boot, internal IDE, etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
very simple interrupt possibility. I will give you 3 examples where it can be useful:
1) Debugging! With my Assembly code debugger (PASD) it is not possible to stop the
execution, manually and look at the register values. In Prop1, the only way to stop is
COGSTOP and then COGINIT which reloads all the cog ram, and the current values at stop
are lost.
A COGRESTART would allow to keep the values in the cog ram.
2) Break an assembly loop, which is as fast as possible. I tried to sample some pins to
a circular buffer as fast as possible (for a scope). With a cogrestart, it would be
possible to break this sampling loop by another cog, when a specific trigger occures,
and let the cog then write the sampled data from cog ram into hubram.
Now this is only possible with polling in the loop, which slows down the sampling loop.
3) Timeout at WAITPEQ, WAITPNE, WAITVID and other endless loops. You can write a
<jump to the timeout-handler> in cog addr 0, and then start another cog for the timeout
before the critical loop.
When the second cog reaches the timeout, it restarts cog1 which has the effect of a jump
to the timeout handler.
With Prop2, which is 8 times faster, point 2) may be not so important. And point 3) is
solved for WATPxx, as I read before in this thread.
But for debugging, and when you go to the limits of speedy loops, the use of a second cog,
to interrupt the first one (without loosing the data in cog ram) would be very useful.
Andy
And what about having an address to which cog to send a message and a kind of arbitration, so you just output (address/value). Like the links in good old transputers?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away
Have you read my considerations about this? In your idea will the CogReset· reset also dir/out registers or only PC. Isn't better just to "cont-inue" a cog that have self-paused?
org 0 jmp next halt: pause ; waits till some other cog execute continue next: program code . . . . <mov dira, #0> ; optional <mov outa, #0> ; optional jmp haltIsn't this equivalent? And have several applications
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
>From what I gather, the toggle rate for such is in the GHz. That's beyond our 3.3V I/O capability.
Lowest pixel clock rate for hdmi is 25Mhz,
so if you somehow could get Waitvid to be programmed to send burst of 10bit data at 25mhz
When we could have 720x480p of pure digital display.
PropII will be around to 2020, Analog VGA and PS2 etc will long gone by then.
http://www.hdmi.org/download/HDMISpecification13a.pdf
········ add····
········ nop···· 'better yet, something useful
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
...In thinking about this more: over process, temperature, and voltage, we could not rely on the chip having better than +/-20% absolute tolerance, which is pretty poor. However, if rather than make the graduated values follow an R, 2R, 3R, 4R...) pattern, we could do (R, 2R, 4R, 8R...) and easily get 16 levels per high or low resistor attached. 5% tolerant resistors would be fine, too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/26/2009 5:04:15 PM GMT
My resistor calculations didn't make complete sense, because I forgot to account for the impedance of the tristrate resistor drivers. They add the extra ohms that would result in a 1.0V output at DAC level $30.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/26/2009 11:56:58 PM GMT
ErNa
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away
Chip Gracey
Parallax, Inc.
I've still got the Propeller walnuts you gave me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away
I need that for one more posiblity.
In my programs that I work on to some customer I need have one SUPERVISOR COG that can control all others (You said simple interupt) it is more as that.
BUT has same function and many usages. As I reuse area of HUB memory that COG code reside with start ... I cant simply reload it (and it take to much time)
And as You said with system that is in Propeller I. I lose all data stored in COG's Variable bufer that was colected in some time and COG wil after RESTART USE it ........... Important that this data are from last RUN.
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
If you rush the chef you get a lousy meal!
Chip, it looks like you are adding quite a few new assembler instructions. How are you massaging things to fit them into the existing 32 bit opcode structure, or have you changed the opcode structure?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
This would give you the ability to do HDMI Output easily and the option to get licensed for the TFP510 for encrypted signals.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board coming soon. $21.99 has backlight driver and touch sensitive decoder.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Have you thought about the nr option writing to a register/cog location. Further thoughts, $1FF might be the easiest as a set of 9 'OR' gates on the write address or'd with the nr bit. An exception would be the read/write hub instructions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board coming soon. $21.99 has backlight driver and touch sensitive decoder.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board coming soon. $21.99 has backlight driver and touch sensitive decoder.
Chip, if you really want to break away from Windows you just have to do it. Stop using the excuse of "because we don't know any better." Parallax is a collection of very smart people who do know better. Start infesting the office with a few boxes running the other operating systems and let the process begin organically.
I'd suggest doing exactly what BradC is doing by decoupling the IDE, compiler, and loader. If you can only make the IDE on Windows at first then so be it. But if there's a Parallax-sanctioned command-line compiler and loader available for the Prop II on OS X and Linux from day one, it will make things a lot easier for your ever-growing corps of non-Windows users. We can implement the IDE on our platforms.
-Steve
This thread is exploding in a half-dozen different directions at once and I can't keep up so please forgive me if this post is redundant.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
links:
My band's website
Our album on the iTunes Music Store
Post Edited (SSteve) : 11/27/2009 5:03:08 PM GMT
With the Propeller I many made that suggestion, but did not agree Parallax. Then, as they gave some information and was achieved through reverse engineering to make several compilers and emulators.
Lost Parallax? On the contrary, won more users.
What I think they should do with the next version is to give all the specifications, in order to create all kinds of tools.
All businesses are opening up their data, because the time to pay $ 1000.00 by a compiler or just use Windows has passed.
Sure, they can continue with its model because it is better for them to support and write the documentation, but it is important to give information to create other tools.
bstc was spawned from the interpreter source being posted. I figured if I had that and knew precisely what it was doing with the bytecodes I could write a compiler to compile them. That, and I really don't like windows. I did originally ask for some information to try and enhance WINE to run the propeller tool.
It is a bit of a shame that nobody outside of this forum knows you can develop for the propeller outside of a windows environment though.
I don't particularly agree that the IDE, compiler and loader are decoupled though. The IDE has some very, very deep hooks into the compiler to allow access to the symbol table so that when you click on a symbol in the editor you get some information about it down the bottom (plus a few other funky background bits). As I had no experience previously providing cross platform tools, I wrote the loader first as a test, then the compiler and then the IDE followed. They are still published as separate tools as I find it useful to have command line tools, but in the IDE they are as tightly coupled as you could get. There is no way to separate out the compiler and substitute it for example.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Don't let this thread turn into an OS battle, though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Computers are microcontrolled.
Robots are microcontrolled.
I am microcontrolled.
But you·can·call me micro.
Want to·experiment with the SX or just put together a cool project?
SX Spinning light display·
Want cheap wholesale electronic parts?
Transistor parts wholesale
-Phil