..unless one of those features is being able to add external RAM. IMHO, given the overall power of the design, it's always going to be RAM constrained.
I am hopeful that the 1.5 die could be used in the 1.0 parts, even if not initially. Otherwise Parallax will not get the volumes to achieve continuous price reductions which inevitably must happen to compete.
@Bill: For a combined AND & SHIFT instruction, it would likely not require an extra cycle because the barrel shifter would be gated to force certain bits to 0. It is possible some of this logic may already be in the barrel shifter.
MOVEB INDIRB[noparse][[/noparse]0-3],INDIRA[noparse][[/noparse]0-3]
MOVEW INDIRB[noparse][[/noparse]0-1],INDIRA[noparse][[/noparse]0-1]
I presume from what you have said, the src and dst would be fixed to be INDIRA and INDIRB and thus not take any of the src and dst fields. You would however require an extra bit for src and dst fields to determine if autoincrement was to be done. I am not sure how this is going to work with say an instruction
MOVEB INDIRB,INDIRA where INDIRA is the register INA i.e. we are reading a byte from the IO pins into a cog location.
We would also want to do the opposite where INDIRB is OUTA i.e. we are writing a byte from a cog location to the IO pins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I like the idea of using the 1.5 die in dip 40 a lot.
I strongly prefer my moveb/movew to and&shift, as a separate OR would still be required.
You are correct, this revised suggestion has INDIRB as dst, and INDIRA as src, hard writed.
Good catch re/ two more bits for auto-inc of indir a&b, I intended that, but did not document. I blame not having any coffee yet today [noparse]:)[/noparse]
Cluso99 said...
I am hopeful that the 1.5 die could be used in the 1.0 parts, even if not initially. Otherwise Parallax will not get the volumes to achieve continuous price reductions which inevitably must happen to compete.
@Bill: For a combined AND & SHIFT instruction, it would likely not require an extra cycle because the barrel shifter would be gated to force certain bits to 0. It is possible some of this logic may already be in the barrel shifter.
MOVEB INDIRB[noparse][[/noparse]0-3],INDIRA[noparse][[/noparse]0-3]
MOVEW INDIRB[noparse][[/noparse]0-1],INDIRA[noparse][[/noparse]0-1]
I presume from what you have said, the src and dst would be fixed to be INDIRA and INDIRB and thus not take any of the src and dst fields. You would however require an extra bit for src and dst fields to determine if autoincrement was to be done. I am not sure how this is going to work with say an instruction
MOVEB INDIRB,INDIRA where INDIRA is the register INA i.e. we are reading a byte from the IO pins into a cog location.
We would also want to do the opposite where INDIRB is OUTA i.e. we are writing a byte from a cog location to the IO pins.
I was wondering about this external RAM implementation.
a) Is it something that a COG can access more or less directly with some special instructions. Presumably it cannot just extend the COG address space as that is limited by the 9 bit src/dest fields.
b) Is it something that is accessed as a HUB OP with rdlong, wrlong and friends (or similar).
Scenario a) would allow very fast access to ext RAM but probably limited to only one COGs use.
Whereas b) allows extension of HUB RAM address space into ext RAM and means access speed per COG is limited by the HUB round robin cycle time.
If b) can all COGs share this ext RAM just like HUB RAM?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think there's a danger in providing a direct DRAM interface, BTW, since it may rely on chips from a commodity market that's in constant flux. Who's to say that the DRAM protocol it supports will even exist three years down the road -- or even when the Prop II hits the shelves? I'd be much more inclined to include a plain vanilla address/data bus interface (multiplexed is okay) and provide the DRAM support with an external controller.
Frankly, it would be pretty powerful with just that - 3x faster than not having the strobes. Think mobile sdram, 32 bit wide, burst mode, prop 2 instructions:
obviously it could be even faster by using more registers per burst, or using two interleaved cogs bursting - heck close to 640MB/sec may be attainable with two cogs!
Chip mentioned 1080p more than a few times... let's do a bit of math:
1080p @ 60Hz = 1920x1080x60 = 124,416,000 pixels per second
Packed 24 bit would be a PAIN, so assuming one long per pixel we have more than enough bandwidth @ 640MB/sec!
heater said...
So Bill, that sounds like it's not external RAM through a HUB OP but via some modification of the COGS pin I/O logic.
Basically a souped up version of the external RAM methods we have now.
Having 1080p is a cool idea and probably a necessary differentiator going forward.
I look forward to the day when I can use a Propeller with a native, standardized,
and optimized 32MB+ SDRAM interface in conjunction with fast non-volatile storage.
Then we could focus less on crazy hardware solutions and more on software.
Now, if only we could only build a PASM native GNU tool chain
I've been quietly designing LMM2 for Prop2, based on most current available information.
20MIPS (LMM) appears to be a piece of cake for hub based code; combine with VMCOG2 [noparse]:)[/noparse] and we would even have an MMU, at close to 20MIPS.
Let's see... 32 bit RISC target, with MMU, and stack - gcc should be portable.
Dare I say the 'L' word?
(Faster may be possible using the read quad/octo long's, but I still have to wrap my brain around it. It would be much simpler to target 20MIPS)
jazzed said...
Having 1080p is a cool idea and probably a necessary differentiator going forward.
I look forward to the day when I can use a Propeller with a native, standardized,
and optimized 32MB+ SDRAM interface in conjunction with fast non-volatile storage.
Then we could focus less on crazy hardware solutions and more on software.
Now, if only we could only build a PASM native GNU tool chain
Since on a prop1.5 die there would be almost twice as many pads, could a prop1.5 fit into the q44 and m44 packages and have room for the legs to tie to the now very different pad layout? If so, I think it is a VERY good idea. It could be a drop in replacement, and only some software would have to change. Has anybody been using that portb register? I wish this idea came up 2 years ago when we were asked by Ken what we wanted.
Can somebody explain what "silicon shuttle" is?
PropII sound's like a arm killer! SDRAM interface....well then the sky is the limit!....well those 506 resisters too, but who's counting ;^)
The shuttle is the first piece of silicon which AFAIK yields about 20 pcs.
With Prop II, the cycle time will be 6.25ns (160MHz). There may be a nop required between the accesses as described by Bill to achieve the uatomatic strobes. Otherwise access may be 2x160MHz = 3.125ns. I do not expect any tie-in with the hub so contention will be required to be controlled by software. I do not consider this an issue as we will deal with it. You need to be mindful of just what we are doing. We are not exploiting the parallelism in the way an Intel chip does with unix/windows.
The Prop II will be used in a very different way to the Prop 1, with the exception of course of us nuts making retro computers (which should really rock!!!) and those of us wanting modern standalone (micro)computers, or should I say nanocomputers.
One place I can see the Prop II in commercial use is in such things as TV/Video players, recorders, etc. With Phil's RF circuitry it would be interesting to see a whole HDTV driver with a USB memory stick or microSD. We could make some cool recorders and playbacks here almost with a single Prop II and SDRAM and microSD.
@Phil: Yes, I would expect just the tools for the strobe and multiplexing and we would be using a timer to determine refresh, perhaps automatically.
@Bill: Dont forget with 1080p we also need time for the update access to the sdram. I have not done the numbers. The Prop II will be 8x faster per instruction so that is a big gain, and with being able to generate strobes, and autoincrement instructions, this should make fetching a block a much easier solution. Many SDRAMs have an internal address autoincrement too. So I do not expect it will be a bottleneck. With all this power, we will run out of cogs first!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
One problem with the proposed propeller 1.5 is that because it has 64 I/O pins, it will probably not be in a DIP format, which i think Parallax may want to avoid. Some people just are not that handy with soldering SMT components( I know i am not). The DIP format opens up way larger possibilities for the new hobbyist. You can stick 'em in breadboards and you can't do that with any SMT device. Of course, you might say that parallax would offer a "demo board" for the Prop 1.5, but that would just drive up costs and it would annoy the people who only wanted individual chips. I say Parallax should go full steam ahead with the Prop 2.0, which i hope will also be offered in a DIP format.....Just a thought.
Cluso99 said...
The shuttle is the first piece of silicon which AFAIK yields about 20 pcs.
A shuttle run (multi-project wafer) is a facility offered by silicon foundries that allows several customers to combine their prototype designs on a single wafer; it's a bit like the pooling facility for PCB prototyping, and has similar cost benefits. They typically only have about three such runs a year.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Well, even if the prop 2.0 does not come in a DIP format, it is going to be way more useful than the Prop 1.5, which is basically a Prop 1, plus 32 extra I/O pins. Besides, i am sure Parallax will offer some sort of a low cost demo board that will be the main device for hobbyist, who does not want to hand solder SMT chips. I was kinda hoping that the Prop 2 would be in a DIP format and it would still have the same number of I/O pins as the Prop 1. One of The advantage of the new prop would be the extra ram, which in some cases would eliminate the need for external ram, thereby eliminating the need for Extra I/O pins. I think the DIP form of the Prop 1 was one of the deciding factors in the success of the unit. No other Parallax chip has been offered in only Non-DIP packages. I wonder if this new chip will succeed in breaking the mold.
This is not directly related to the possible Prop II instruction set.
My experiments with the ZPU virtual machine/emulator/interpreter show at least that it is possible to have a small byte code interpreter that able to support C/C++ on the Prop. Performance is not so far behind that of Spin.
This suggests that the Prop II should include a new byte code interpreter that can effectively support C/C++. I'm sure clever minds can come up with something better for the Prop than the ZPU/ZOG byte code.
Or perhaps a Java bytecode interpreter would be a better choice, it is accepted that Java be interpreted which is not the case for C.
I feel that Parallax's resources would be better directed to something standard rather than the "not C" C lookalike they are proposing at the moment.
It has been said that such an interpreter built into the PropII ROM is not necessary, after all we can always load up whatever we like. This is true but having it in ROM makes it a standard that everyone would have. Being able to boot directly into C or Java would be great simplification.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater: Yes, probably a good idea to have it in rom. There is probably a little time left to have code placed in ROM. Even if it does not work, there is probably space, and if written correctly, a soft patch can be applied. This is what Apple did for the Mac.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Looks like there are still licensing issues with a Java VM. See this story here www.betaversion.org/~stefano/linotype/news/110/ and that Android uses a different VM to run it's Java code, the "Dalvik" VM, as a consequence.
I would not recommend the ZPU byte code (as in Zog) as the performance is not quite there. What with being stack based and all. (Thinks - why is stack based a problem? The original Java VMs were stack based I believe.)
Having read around your and others work on the Spin interpreter, not that I follow most of the technicalities, it seems the Spin interpreter could be extended to give good C support as well.
I recall your alternative Spin efforts include moving the dispatch table out of the COG to HUB RAM and now implementing rarely used operations into LMM.
Well don't forget the dispatch table can as well be in the ROM as can any LMM replacement code or extensions. So it looks to me as if the Spin VM could well be extended to give good C support by using some of the Prop II's ROM space.
That only leaves creating a C compiler targeted at the new Spin VM. Ideally that would be a new target addition to GCC.
All in all still quite a big development effort that could hold up Prop II release.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think there will be plenty of space in the ROM from what Chip had said, so anything in there that could be used would be worthwhile to develop with, so long as it was not relied upon for subsequent rom codes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
@Bill: For a combined AND & SHIFT instruction, it would likely not require an extra cycle because the barrel shifter would be gated to force certain bits to 0. It is possible some of this logic may already be in the barrel shifter.
MOVEB INDIRB[noparse][[/noparse]0-3],INDIRA[noparse][[/noparse]0-3]
MOVEW INDIRB[noparse][[/noparse]0-1],INDIRA[noparse][[/noparse]0-1]
I presume from what you have said, the src and dst would be fixed to be INDIRA and INDIRB and thus not take any of the src and dst fields. You would however require an extra bit for src and dst fields to determine if autoincrement was to be done. I am not sure how this is going to work with say an instruction
MOVEB INDIRB,INDIRA where INDIRA is the register INA i.e. we are reading a byte from the IO pins into a cog location.
We would also want to do the opposite where INDIRB is OUTA i.e. we are writing a byte from a cog location to the IO pins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
-Phil
I strongly prefer my moveb/movew to and&shift, as a separate OR would still be required.
You are correct, this revised suggestion has INDIRB as dst, and INDIRA as src, hard writed.
Good catch re/ two more bits for auto-inc of indir a&b, I intended that, but did not document. I blame not having any coffee yet today [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
a) Is it something that a COG can access more or less directly with some special instructions. Presumably it cannot just extend the COG address space as that is limited by the 9 bit src/dest fields.
b) Is it something that is accessed as a HUB OP with rdlong, wrlong and friends (or similar).
Scenario a) would allow very fast access to ext RAM but probably limited to only one COGs use.
Whereas b) allows extension of HUB RAM address space into ext RAM and means access speed per COG is limited by the HUB round robin cycle time.
If b) can all COGs share this ext RAM just like HUB RAM?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
-Phil
As I recall, he is implementing the ability to provide an external strobe when the port is written, and another when it is read.
This by itself is a huge win.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Basically a souped up version of the external RAM methods we have now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Frankly, it would be pretty powerful with just that - 3x faster than not having the strobes. Think mobile sdram, 32 bit wide, burst mode, prop 2 instructions:
'start clocks
mov reg0,ina
mov reg1,ina
mov reg2,ina
mov reg3,ina
mov reg4,ina
mov reg5,ina
mov reg6,ina
mov reg7,ina
'stop clocks
wroctlong reg0,hubptr
add hubptr,#32
obviously it could be even faster by using more registers per burst, or using two interleaved cogs bursting - heck close to 640MB/sec may be attainable with two cogs!
Chip mentioned 1080p more than a few times... let's do a bit of math:
1080p @ 60Hz = 1920x1080x60 = 124,416,000 pixels per second
Packed 24 bit would be a PAIN, so assuming one long per pixel we have more than enough bandwidth @ 640MB/sec!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I look forward to the day when I can use a Propeller with a native, standardized,
and optimized 32MB+ SDRAM interface in conjunction with fast non-volatile storage.
Then we could focus less on crazy hardware solutions and more on software.
Now, if only we could only build a PASM native GNU tool chain
Cheers [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
20MIPS (LMM) appears to be a piece of cake for hub based code; combine with VMCOG2 [noparse]:)[/noparse] and we would even have an MMU, at close to 20MIPS.
Let's see... 32 bit RISC target, with MMU, and stack - gcc should be portable.
Dare I say the 'L' word?
(Faster may be possible using the read quad/octo long's, but I still have to wrap my brain around it. It would be much simpler to target 20MIPS)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Can somebody explain what "silicon shuttle" is?
PropII sound's like a arm killer! SDRAM interface....well then the sky is the limit!....well those 506 resisters too, but who's counting ;^)
With Prop II, the cycle time will be 6.25ns (160MHz). There may be a nop required between the accesses as described by Bill to achieve the uatomatic strobes. Otherwise access may be 2x160MHz = 3.125ns. I do not expect any tie-in with the hub so contention will be required to be controlled by software. I do not consider this an issue as we will deal with it. You need to be mindful of just what we are doing. We are not exploiting the parallelism in the way an Intel chip does with unix/windows.
The Prop II will be used in a very different way to the Prop 1, with the exception of course of us nuts making retro computers (which should really rock!!!) and those of us wanting modern standalone (micro)computers, or should I say nanocomputers.
One place I can see the Prop II in commercial use is in such things as TV/Video players, recorders, etc. With Phil's RF circuitry it would be interesting to see a whole HDTV driver with a USB memory stick or microSD. We could make some cool recorders and playbacks here almost with a single Prop II and SDRAM and microSD.
@Phil: Yes, I would expect just the tools for the strobe and multiplexing and we would be using a timer to determine refresh, perhaps automatically.
@Bill: Dont forget with 1080p we also need time for the update access to the sdram. I have not done the numbers. The Prop II will be 8x faster per instruction so that is a big gain, and with being able to generate strobes, and autoincrement instructions, this should make fetching a block a much easier solution. Many SDRAMs have an internal address autoincrement too. So I do not expect it will be a bottleneck. With all this power, we will run out of cogs first!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 7/1/2010 1:45:42 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller + Picaxe = Romeo & Juliet
-Phil
A shuttle run (multi-project wafer) is a facility offered by silicon foundries that allows several customers to combine their prototype designs on a single wafer; it's a bit like the pooling facility for PCB prototyping, and has similar cost benefits. They typically only have about three such runs a year.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 7/1/2010 3:09:34 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller + Picaxe = Romeo & Juliet
My experiments with the ZPU virtual machine/emulator/interpreter show at least that it is possible to have a small byte code interpreter that able to support C/C++ on the Prop. Performance is not so far behind that of Spin.
This suggests that the Prop II should include a new byte code interpreter that can effectively support C/C++. I'm sure clever minds can come up with something better for the Prop than the ZPU/ZOG byte code.
Or perhaps a Java bytecode interpreter would be a better choice, it is accepted that Java be interpreted which is not the case for C.
I feel that Parallax's resources would be better directed to something standard rather than the "not C" C lookalike they are proposing at the moment.
It has been said that such an interpreter built into the PropII ROM is not necessary, after all we can always load up whatever we like. This is true but having it in ROM makes it a standard that everyone would have. Being able to boot directly into C or Java would be great simplification.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I would not recommend the ZPU byte code (as in Zog) as the performance is not quite there. What with being stack based and all. (Thinks - why is stack based a problem? The original Java VMs were stack based I believe.)
Having read around your and others work on the Spin interpreter, not that I follow most of the technicalities, it seems the Spin interpreter could be extended to give good C support as well.
I recall your alternative Spin efforts include moving the dispatch table out of the COG to HUB RAM and now implementing rarely used operations into LMM.
Well don't forget the dispatch table can as well be in the ROM as can any LMM replacement code or extensions. So it looks to me as if the Spin VM could well be extended to give good C support by using some of the Prop II's ROM space.
That only leaves creating a C compiler targeted at the new Spin VM. Ideally that would be a new target addition to GCC.
All in all still quite a big development effort that could hold up Prop II release.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz