 |
|
 |
| Parallax Forums > Public Forums > Propeller Chip > TriBladeProp PCB: Uses 3 Propeller ICs for a Single Board Computer (SBC) | Forum Quick Jump
|
 |  Dr_Acula Registered Member

       Date Joined Dec 2008 Total Posts : 606 | Posted 9/20/2009 6:28 PM (GMT -8) |   | | | |
      |  Cluso99 We live onboard

       Date Joined Apr 2008 Total Posts : 2276 | Posted 9/21/2009 11:57 PM (GMT -8) |   | | | |
              |  Cluso99 We live onboard

       Date Joined Apr 2008 Total Posts : 2276 | Posted 9/22/2009 6:48 PM (GMT -8) |   | | TriBlade Description
The TriBlade board is very powerful and has many options available, which makes describing the board difficult.
However, there are two things important to the building.
1) If you build the propplug section, note the orientation of the transistor (photos on page 6 of the TriBlade thread)
2) Use the errata at the last (or next to last) page of the TriBlade thread. You must use the -OE modification to the SRAM(s) and fit the 74HC573.
There is a complete parts list at the top of the thread with part numbers from Digikey for most parts. The sram is from Future Electronics with that part number.
Each Blade circuit, the propplug section, and the I/O may be built independantly. The recent photos show this on my new TriBlade, where I just built the power supply and partially build Blade #2. I have also built the PropPlug section but this is entirely optional.
Yesterday I added the TV (video output section) and wired it to Blade #2 P12-P14 (using the holes on the unfitted SRAM) using temporary jumpers (they are not soldered!!). The same may be done for the VGA section, Keyboard section and Mouse section. They can all be independent sections. Care must be taken when linking these to Blade #2 to ensure no bus contention can happen. If you have any concerns, just ask.
Blade #1 is also just as powerful in a different way. As far as I know, noone is using the SRAM on this prop.
A few people have asked about R23 & R24. They are unused, uncommitted resistors just there in case we want to use them in a circuit. Therefore, do not fit them.
There are 3 uncommitted LED circuits which may be helpful in debugging and basically can be jumpered to any pin to show it's status. I use a red, a green and a blue LED.
My current TriBlade has the following fitted... (photo a few posts back)
* Power supply section
* PropPlug section
* Blade #2...
* Prop and xtal (upgraded to 6MHz yesterday -> 96MHz) (Sapeiha's running 15MHz -> 120MHz for 6 months)
* U23 is fitted with 512KB sram
* U25 is fitted with 74HC573 (could use 74LVC573) and Resistor Network RN1
* J22 microSD socket
* U22 is fitted with 24LC512 (64KB) - only required for storing your program instead of downloading
* Do not forget the -OE modification !!!
* Yesterday I jumpered P12-14 to the TV section (temporary testing of video 80x25 using potatohead's code)
* TV section (Resistors 17,18, 19 and J15) and temporary jumpers to Blade #2
Links to other interesting threads:
| | Back to Top | | |
  |  potatohead 640 Pixels... :)

       Date Joined Sep 2006 Total Posts : 1338 | Posted 9/22/2009 7:35 PM (GMT -8) |   | | | |
 |  Cluso99 We live onboard

       Date Joined Apr 2008 Total Posts : 2276 | Posted 9/22/2009 7:48 PM (GMT -8) |   | Operation of ZiCog for Hard Disk DMA...
CPM uses 128 byte sectors. The hard disks are held under FAT16 on the SD (microSD) card as seperate file images (must be contiguous), one for each drive, as packed 4 x 128 byte sectors per SD sector. ZiCog takes care of the packing/unpacking. When used, the Floppy images are held as 128 bytes per 512 byte SD sector.
refresh_hd_cache
This routine has it's own 512 byte buffer. Each time a read or write is called the cache is checked to see if it contains the current 512 byte sector in it's buffer. If so, it just returns. If not, then it will read this SD sector into the buffer and then return.
in_hdiskport_read
This routine reads a 128 byte sector as required by CPM. It calls the refresh_hd_cache routine to ensure it is in the buffer and then copies, using block mode, the whole relevant 128 byte sector to the CPM Ram. This is called DMA, but it really means it is copied in a block, rather than each byte seperately like the floppy does.
in_hdiskport_write
This routine writes a 128 byte sector as required by CPM. It calls the refresh_hd_cache routine to ensure it is in the buffer and then it copies, using block mode, the whole relevant 128 byte sector from the CPM Ram. This is called DMA. Then, the whole 512 byte sector is written back to the SD card.
If there are any questions, please ask Links to other interesting threads:
| | Back to Top | | |
 | 849 posts in this thread. Viewing Page : | | Forum Information | Currently it is Friday, November 20, 2009 10:59 PM (GMT -8) There are a total of 393,737 posts in 55,521 threads. In the last 3 days there were 82 new threads and 702 reply posts. View Active Threads
| | Who's Online | This forum has 17687 registered members. Please welcome our newest member, mark09. 57 Guest(s), 6 Registered Member(s) are currently online. Details Peter Verkaik, BradC, Harley, Chris Savage (Parallax), Rich_W8VK, potatohead |
Forum powered by dotNetBB v2.42EC SP2.02 dotNetBB © 2000-2009 |
|
|