• power supply (5V & 3V3 regulators)
• PropPlug equivalent (USB to serial with reset capability)
• Blade #1: Propeller chip with options for EEPROM, VGA, TV, Keyboard, Mouse, 512KByte SRAM using a latch, and 1-8MByte SPI Flash chip. Some options preclude others. It has a PropPlug input header.
• Blade #2: Propeller chip with options for EEPROM, 2 x 512KByte (2 x 2MByte with very expensive chips) SRAM, latch for address decoding and resets to Blades #1 & #3, microSD socket, 1-8MByte SPI Flash chip. It has a PropPlug input header. The only external connection is via the 2 pin I/O which is also on the PropPlug header as all I/Os are used with the SRAM, etc.
• Blade #3: Propeller chip with options for EEPROM and various header pins for connections to the unused I/Os. It has a PropPlug input header and another 2 wire (serial) connection to #2.

Now for the interconnection and programmability...

• I have designed the pcb with the objective that #2 can reprogram #1 & #3 so an EEPROM is not required for #1 and/or #3.
• It is not required to fit all options, nor all props, nor the internal PropPlug (external PropPlug OK).
• So the pcb is EXTREMELY flexible although that is not apparent from the circuit.
• I have a 2 wire bus that can be linked between #1 - #2 - #3 (P30 & P31) so that they can communicate via a 2 wire protocol. I envisage an ultra high speed serial (as Beau has proved) >1MBytes/s protocol between the 3 Blades (props). So far, I only have connected 2 blades together so have just used plainf FullDuplexSerial at 115200 baud.
• #2 can boot a propeller binary from the uSD card with appropriate code in the EEPROM (working). The binary can be PropDos, ZiCog + CPM, or any other prop binary (working).

So, to answer your question, the props on the TriBlade are seperate AND able to interact, AND yes one prop can instruct/command/program the others (via #2).

You may also like to see the RamBlade and TwinBlade threads, although progress has been slow due to other constraints.

Post Edited (Dr_Acula (James Moxham)) : 8/4/2009 2:25:27 PM GMT

I have just posted updated code to the top of the thread. It consists of all source plus the homespun v024 compiler which is used to compile the code. "z.bat" is a DOS batch file to compile the code. The code also contains the binary, so there is no requirement to compile.

This code loads into Blade #2 and runs ZiCog v009 (TriBlade v091). It uses the serial pins P30/P31 (via the PropPlug circuit) at 115,200 baud to communicate with the PC running PropTerminal. You CANNOT substitute the Keyboard and TV or VGA objects as these may not be connected to Blade #2. Blade #1 can be used for this and I will post this code later.

I have also posted two files which contain the files required to be on the microSD card to run CPM 2.2 & CPM 3 (Note CPM 3 is not working properly).

Posted here is a "Draft" version of the Assembly Instructions for the TriBladeProp board. Also included is a section to format the microSD card on the PC and files to copy to it.

  Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)

  Search the Propeller forums (via Google)

My cruising website is:  www.bluemagic.biz   MultiBladeProp is: www.bluemagic.biz/cluso.htm

Post Edited (Cluso99) : 8/5/2009 9:18:00 AM GMT

Image Attachment : TBP_B2.JPG   135KB (image/pjpeg) This image has been viewed 32 time(s).

Image Attachment : TBP_B2r.JPG   104KB (image/pjpeg) This image has been viewed 35 time(s).

Image Attachment : tribladeprop_a1d.JPG   186KB (image/pjpeg) This image has been viewed 40 time(s).

File Attachment :
TriBladeProp Assembly Instructions.txt   5KB (text/plain)

This file has been downloaded 34 time(s).

Errata for building the TriBladeProp board.

The suggested modification for swapping the serial lines over between Blades #1 and #2 should be preferably done by using 150R resistors (to replace the green wires shown). Be careful not to allow the resistors to short.

  Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)

  Search the Propeller forums (via Google)

My cruising website is:  www.bluemagic.biz   MultiBladeProp is: www.bluemagic.biz/cluso.htm

Post Edited (Cluso99) : 8/5/2009 8:55:20 AM GMT

Image Attachment : tribladeprop_a1a.JPG   63KB (image/pjpeg) This image has been viewed 36 time(s).

Image Attachment : tribladeprop_a1c.JPG   93KB (image/pjpeg) This image has been viewed 36 time(s).

Image Attachment : SuggestedTBPmod_20090427.JPG   71KB (image/pjpeg) This image has been viewed 32 time(s).

File Attachment :
tribladeprop_errata_rev_a1.pdf   26KB (application/pdf)

This file has been downloaded 25 time(s).

As you may have gathered, I have Blade #2 running on the newly built TriBlade, plus the power supply and propplug sections (see photos above). Ross - did you hear that :-)

Post Edited (Dr_Acula (James Moxham)) : 8/5/2009 11:00:44 AM GMT

I see you are running v06x. I posted v091 today which incorporates heaters v009 ZiCog.

Have you done a DIR on all drives A..H then a SURVEY ??

Re CR+LF, it would be simpler to modify PC_Text.spin to add 10 after every 13.

Hi All,

CR+LF probably should be in a #define crlf because this problem will exist in various terminal emulations, so I see this as common ground.

Other modifications, as Heater said, should be clearly identified at the top of the code and the filename should reflect this, at least for now.

While my RamBlade uses different hardware mapping, this will be taken care of in another driver. This is because ram access is 75%+ faster. Remember, my objective is emulation speed first, simplicity second, then minimal cost, in that order.

FYI the v090 code had #define 8080 set (cannot recall exact name) instead of Z80. "baud" has been defined, but lower code objects also require changing. v090+ has faster SD access on the TriBlade because I had to do a reset/reload of the cog for each SD access to avoid a hardware conflict with the older v021 TriBlade driver. The fix in the sdspi driver to release the SD D0 pin just sends out a lot of clocks which is slow and happens at the end of each read/write of an SD sector. By using the new SD driver by lonesock/rokiki we should get much faster access, although the TriBlade and RamBlade hardware will preclude read ahead and write behind due to bus conflicts - otherwise latching has to be used which imposes r/w penalties with EVERY ram access. Oh for some more prop pins

I did not complicate the v091 release with PropDOS/PropCMD which allows the booting of any prop program. I have had this working. This will be great to also load Ross's Catalina C project and also Heaters' MoCog (Motorola 6809) emulation. It will be nice to load all these from a Prop command prompt.

James, are you using RS232 for your link to the PC? If you have a USB on the PC, you will happily get 115,200 over 2m. Improves development imensely

Post Edited (Dr_Acula (James Moxham)) : 8/6/2009 1:42:18 AM GMT

James: The changes from debug to TV were done for a reason but cannot remember why. I think the TV was changing intercepting characters and I was downloading code. I will have a new look at this later. It was a quick fix at the time.

I am using PropTerminal because I can switch between the IDE and it easily. As soon as I switch to bst I think I can move to this completely as there is a terminal window in the bst IDE as well. CRLF will require more thought to simplify and standardise it.

We could do a baud #define I suppose. Once again, more thought needed. I was not aware that the prop could be loaded at other than 115,200 even though it is quite tolerant (it is using internal clocking). Anyway, I don't expect to be reprogramming the eeprom. Perhaps baud could therefore be defined here and CRLF as well.

We will need some form of Terminal program for Blade #1 such as PockeTerm - not sure of Vince's license - but there are objects around for this.

Disks: The 32MB files are just copies of the 1MB disks into the first 8MB with the remainder of the space unused. This is so the files can remain contiguous. Heater does not have the 2 x 8 MB hard disks working yet (??). However, it may be better to just jump in and change the floppy driver in CPM to use 8MB floppies and forget the hard disks altogether. Heater - any ideas/suggestions?? I have done a format of one of the disks a while ago and then used PIP to copy files. Drive G is a copy of Drive A, so if A gets modified too much, it can be fully restored.

SD speed: Have you tried v091 yet. The initialisation is much faster but I am not sure about CPM boot time and access. Perhaps you can time this for me. Not sure when I will get time to use the new SD driver.

Ram Disk: I started out with a 960KB disk image plus 64KB of Z80 Ram before I got the SD working. As for 5V SRAM, I think the resistors could impact ram access times. After Windows, the load time is not a problem for me, but I like the idea of being able to run a ram disk. However, RamBlade will only have 512KB and may even be restricted to 128KB or 256KB if it is a single prop solution. Don't forget, we want 256KB for CPM3 bank switching.

Yoda: Yes sounds good to me

CPM3: Yes it runs but there is an I/O problem in that each character you enter requires it to be hit twice on the keyboard. Otherwise I did a dir. Just change the #define and recompile.

SPEED: Overclocking should give us a 6MHz equivalent Z80   And we can probably still optimise ZiCog and the spin code. BTW Some of the spin code should be PASM = more speed.