Parallax Forums
  HomeLog InRegisterCommunity CalendarSearch the ForumHelp
   
Parallax Forums > Public Forums > Propeller Chip > TriBladeProp PCB: Uses 3 Propeller ICs for a Single Board Computer (SBC)  Forum Quick Jump
 
New Topic Post Reply Printable Version
849 posts in this thread.
Viewing Page :
 
[ << Previous Thread | Next Thread >> ] | Show Newest Post First ]

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
 
   Posted 9/20/2009 5:59 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Same bug with zipm2_noauto :-(

Drac: Could you repost a SD drive file with wordstar on it please.


Links to other interesting threads:
Back to Top
 

Dr_Acula
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 2008
Total Posts : 606
 
   Posted 9/20/2009 6:28 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Ok, will do when I get home tonight.


www.smarthome.viviti.com/build

Back to Top
 

Dr_Acula
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 2008
Total Posts : 606
 
   Posted 9/21/2009 12:02 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Wordstar hard disk attached. This is working on the simh, but it doesn't seem to work properly on the zicog.

A quick question - are altair simh hard drives compatible with zicog drives?

If yes, then TYPE on a text file should work. But it doesn't. Try TYPE WSPRINT.TST and it should print some text (works on the simh) but it types rubbish characters and eventually crashes.

There are two ways to make a hard drive file on the zicog.

1) Copy an altair simh hard drive file (? does this work)
2) PIP *.* from a floppy drive image. (not working on all files due to the 'big file' bug)

So - 1) doesn't seem to work so I tried 2) and is how I found the big file bug in the first place. So - making a wordstar hard drive image is not possible right now!

Maybe there is an incompatability issue between altair and zicog hard drive images and since they seem so close (DIR partially works for instance), it would be worth working out a way. So I'm posting this file and maybe someone can replicate this problem.

Addit: Something is definitely wrong with the drive image. LS displays all the files but DIR leaves about half out:

G>LS

Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes
VIDATT  Z80    2K ! WSCHANGEOVR   12K ! WSPRINT OVR   74K ! WSU     COM    4K
WS      COM    4K ! WSCHHELPOVR   16K ! WSPRINT TST    4K
WS      OVR   26K ! WSHELP  OVR   14K ! WSREADMETXT   16K
WSCHANGECOM   18K ! WSMSGS  OVR    8K ! WSSHORT OVR    2K
13 File(s), occupying 200K of 984K total capacity
236 directory entries and 784K bytes remain on G:
G>DIR

G: VIDATT   Z80 : WSMSGS   OVR : WSPRINT  TST : WSSHORT  OVR
G: WSU      COM : WS       COM
G>


www.smarthome.viviti.com/build

Post Edited (Dr_Acula) : 9/21/2009 8:09:15 AM GMT



File Attachment :
Wordstar.zip   256KB (application/zip)
This file has been downloaded 10 time(s).
Back to Top
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
 
   Posted 9/21/2009 12:16 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Drac: Our hard disks are compatible with SIMH. For pip to work with floppies you have to compile with floppy support (unless you mean on SIMH which will work), although we are going to remove this for V1.0. We will just keep a version in the background that can do this.

PIP of files >28K (probably 32K) fails. I have seen other failures which are possibly due to the same bug, whatever it is. When I pip a 40K file it recovers after the garbage which is fairly consistent, but the file copied is corrupted.

I thought it may have been a conflict with the sram on triblade, but all the calls out of ZiCog Pasm to the upper spin code seem to have the correct bus release statements. The 25K version of CPM2.2 does pip correctly.

Drac, Do you remember I spoke of an additional chip... Well, I have just found a way in software to achieve the same speed increase without it :-)

 


Links to other interesting threads:
  Search the Propeller forums (uses advanced Google search)
My cruising website is:  www.bluemagic.biz   MultiBladeProp is: www.bluemagic.biz/cluso.htm

Post Edited (Cluso99) : 9/21/2009 8:22:23 AM GMT

Back to Top
 

Dr_Acula
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 2008
Total Posts : 606
 
   Posted 9/21/2009 12:32 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Hmm - more experiments are needed. I need to eat dinner, then I'm going to start with a blank hard drive on the simh and copy one file across. Then do the same on the zicog and then compare the binary images.


www.smarthome.viviti.com/build

Back to Top
 

Dr_Acula
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 2008
Total Posts : 606
 
   Posted 9/21/2009 1:08 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Right, refuelled and ready to go:

Take a blank drive image on the simh and then on the zicog and PIP a single file from drive A.

Two screenshots of the two files side by side in a hex editor. Zicog at the top. SIMH at the bottom.

First difference is in the FCB with a byte 04 vs 08. This is the first byte of the disk allocation map so maybe there is something different in the disk parameters?

Second difference is the location of the data - at 8000 vs E000, which probably reflects the different disk allocation map.


www.smarthome.viviti.com/build

Post Edited (Dr_Acula) : 9/21/2009 9:15:18 AM GMT


Image Attachment :
Image Preview
FCB.jpg
  249KB (image/jpeg)
This image has been viewed 21 time(s).
Image Attachment :
Image Preview
Data_Location.jpg
  246KB (image/jpeg)
This image has been viewed 16 time(s).
Back to Top
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
 
   Posted 9/21/2009 3:11 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Drac: Could just be the different hdp being different causing the location to be different on the hard disk image???


Links to other interesting threads:
Back to Top
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
 
   Posted 9/21/2009 11:57 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Just upped the TriBlade clock to 96MHz (6MHz xtal) WHOOPEE jumpin jumpin jumpin jumpin jumpin jumpin


Links to other interesting threads:
Back to Top
 

Dr_Acula
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 2008
Total Posts : 606
 
   Posted 9/22/2009 1:43 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Cool, faster!

Is heater around? There are so many programs not working on the hard drives (that were working before) and I think we need his expert opinion about where to begin. I was thinking about taking drive images with lots of files and comparing the binaries with the simh, but got stuck on the first file. So next plan is to start putting UART.str comments through the spin code and try to track it down that way. Back to coding...


www.smarthome.viviti.com/build

Back to Top
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
 
   Posted 9/22/2009 2:22 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Might be worth compiling with the floppies and see if that works. Not sure if I will get time tonight.
It seems to be just the 64K build causing problems.

Drac: Will the programs that fail run in 25K. If so, can you compile this version (uses ZIPM2.DSK - see the FindDriveBase section) and try the programs ?


Links to other interesting threads:
  Search the Propeller forums (uses advanced Google search)
My cruising website is:  www.bluemagic.biz   MultiBladeProp is: www.bluemagic.biz/cluso.htm

Post Edited (Cluso99) : 9/22/2009 10:33:27 AM GMT

Back to Top
 

Dr_Acula
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 2008
Total Posts : 606
 
   Posted 9/22/2009 2:45 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Not sure about how to compile with ZIPM2.DSK, can you pls explain that one a bit more? Does it need a change in the spin code?

I'm using a large (100k) text file.

Xmodem from the PC to drive A works fine and I can then take that zicog drive image and copy it off the sd card and put it back into the Altair SIMH and it is all there.

I can also do a TYPE on that large file and it all comes through.

PIP to another drive fails as we have found. I was thinking it was the 'write' but that would not explain why programs like wordstar that simply read large files then fail. Now I think it is the 'read' because I've just had it crash half way through a DUMP of the same large text file. So now I need to create a text file with numerical labels so I can see exactly which byte it fails on...

I've added this little bit of trace code to PRI refresh_hd_cache | r

  uart.dec(sd_block_number)
  uart.str(string(":"))
  uart.dec(current_block_number)
  uart.str(string(", "))


www.smarthome.viviti.com/build

Back to Top
 

heater
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Feb 2008
Total Posts : 1832
 
   Posted 9/22/2009 2:55 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Hi Guys, I'm back, with a vengeance. My Blade 2 is running at, wait for it, 104.857 6 MHz !!
Yep a 6.5536MHx XTAL and 16 times PLL. Cluso, hit the gas:)

OK. Sorry, as you see I have been busy collecting TriBlade parts and assembling it. The state of the art here is:

Power supply. Only has 3.3v reg, the 5v reg is bypassed and the whole thing driven from 4 rechargeable AA batteries.

The LED's work :)

Blade 2. Has Prop and EEPROM, latch and XTAL. Fitted the 10uF Tantalum and a 100nF ceramic to the back side. The ceramic is the only thing of the correct value that fits the holes that I could find around here quickly. Is it OK Cluso? What is an X7R anyway?

Question: Will this 104MHz speed be too much for the external RAM?

TODO:
The delicate RAM chopping and fitting.
Lash an SD card to it.

I don't have the SD card socket so somehow I have to hang it off the board with a ribbon cable as I did for my demo board.

A cunning plan: Now that I have a Blade running I'm prepared to read the last rights to my home made demo board. That board has a strong resemblance to the Flying Spaghetti Monster and I'm surprised it has lasted so long.

What I want to do is recycle its body parts for Blade 1. I'm thinking I could install it's Prop there and (with no RAM) hang it's SD card of the same Prop pins as the usual Demo Board attachment. This way I have a Triblade 2 and Prop Demo Board configuration for ZiCog all on the TriBlade:).

I've been following your pain with the crashy BIOS. Hopefully I can get onto that real soon now.


For me, the past is not over yet.

Back to Top
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
 
   Posted 9/22/2009 2:58 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
A little more info on the bug....

PIP >32K works on version 122 when compiled with #define FloppySupport. This boots a 64K version of the floppy A drive. Pip to I: works and the file is correctly copied because a text file of 40K was copied and TYPE used to display it. PIP works both ways, so the caching is working. :-)
 
This means that the problem must be to do with the 64K CPM boot code version (hdisk).


Links to other interesting threads:
  Search the Propeller forums (uses advanced Google search)
My cruising website is:  www.bluemagic.biz   MultiBladeProp is: www.bluemagic.biz/cluso.htm

Post Edited (Cluso99) : 9/22/2009 11:06:36 AM GMT

Back to Top
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
 
   Posted 9/22/2009 3:23 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Nice work heater :-) Almost 105MHz.

I have not checked the exact timing specs but don't worry for now. The ceramic should be fine. The X7R is a tighter tolerance under temperature variation.

I just put in a 6MHz xtal and I have not fitted any caps under the processor yet. I want to see where this becomes critical. Now I want to get to 120MHz like Sapeiha has had running for 6mths, but this will have to wait for the correct xtals.

Drac: Do you have a 6MHz xtal ? If not I'll post you one. Not sure if you noticed, but today I had potatohead's TV running 80x25 characters on my TV today at 96MHz (on the TriBlade #2 - SRAM deselcted due to potential bus conflict. (jumpered without soldering the 3 pins from SRAM U24 to the links beside the TV resistors on the pcb. Guess I should have taken a photo hey - done.


Links to other interesting threads:
  Search the Propeller forums (uses advanced Google search)
My cruising website is:  www.bluemagic.biz   MultiBladeProp is: www.bluemagic.biz/cluso.htm

Post Edited (Cluso99) : 9/22/2009 11:34:47 AM GMT


Image Attachment :
Image Preview
TriBlade_TV80x25.JPG
  54KB (image/pjpeg)
This image has been viewed 23 time(s).
Back to Top
 

Dr_Acula
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 2008
Total Posts : 606
 
   Posted 9/22/2009 3:47 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
More experiments.
1)
For the moment I've uncommented

    hdskWrite:
      UART.str(string("hdsk write"))


Interesting that it writes when you change drives and on warm boots. I didn't know that.

2)
Just for the moment I have the 3 second delay on bootup. I had this commented out for a while, and about 1 in 10 bootups were not loading the hard drives. Maybe they are related, maybe not. I'll keep testing that, but perhaps there needs to be a delay for other reasons, eg the sd card needs to stabilise the power supply? I'll do more testing, but maybe a small delay is always needed there, and maybe a comment about that could find its way into the code?

3) It is cool watching the code reading - ie read in 512 bytes and store in a temp array and if already have a 128 byte sector then read from the buffer. Watching the reads, it mostly is reading contiguous sectors. When doing a dump, every 16k it seems to go back and read about 10 of the sectors it reads on bootup.

4) I think the fail on DUMP of the large text file was a one-off. It is DUMPing 100k text files and also 100k random byte files with no problems at the moment.

5) re faster speed, I'd really like to get it working first before overclocking. But down the track...


www.smarthome.viviti.com/build

Back to Top
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
 
   Posted 9/22/2009 3:53 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
So have you seen where PIP fails?


Links to other interesting threads:
Back to Top
 

Dr_Acula
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 2008
Total Posts : 606
 
   Posted 9/22/2009 4:09 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Not really. I can print out the disk blocks as they go through but I don't know what they relate to. Not even sure about the 32k thing either. And there is a lot of inconsistent behaviour where things are not repeatable. So lots of going back and starting with totally clean drive images. Very tedious.

I'm also trying to work out how the dma thing works. This is from the PRI in_hdskport_write | r

'#ifdef RamHDisk ?????     <=============================

  'read the block in from Z80 sram
  r := tbp2.DoCmd("R", @disk_buff + block_offset, hdsk_dma, 128) 'Virtual "DMA" the sector from DMA buffer from SRAM
  CheckError(r)

  r := tbp2.idle                                        'give up the bus
  CheckError(r)

  r := sd.initSDcard(spiDO,spiClk,spiDI,spiCS)          'init the SD
  CheckError(r)

  ' this method relies on the SD file using contiguous sectors !!! Packed 4 x 128 bytes per 512 byte sectors
  err := \sd.writeSDCard(sd_block_number, @disk_buff, 512)   'write the block! (complete 512 bytes)
' CheckError(err)


So you read 128 bytes off the ram chip, but you write 512 bytes to the sd card. Where did the other 384 bytes come from? What wrote them? Where in ram is this buffer? What else can access that buffer? What is the order of reading and writing to the buffer?

Addit: Answered one of those - hdsk_dma is in spin. I have no idea what sets it
5:
hdsk_dma := io_data '5th byte is LOW of the DMA address
hdsk_command_pos++
6:
hdsk_dma := hdsk_dma + (io_data << 8) '6th (and last) byte is HIGH of the DMA address
And there is mention of the CP/M DMA (which is fixed. but this is a variable)

I guess debugging this is hard without fully understanding the code!!


www.smarthome.viviti.com/build

Post Edited (Dr_Acula) : 9/22/2009 12:23:02 PM GMT

Back to Top
 

heater
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Feb 2008
Total Posts : 1832
 
   Posted 9/22/2009 4:27 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
There is nothing fixed about DMA in CP/M. (Well, depending on your BIOS I guess)

The boot loaders "DMA" the stuff they load dirctly to the RAM location they want it to be at finally. There is no loading to a fixed DMA buffer then copy to the final destination.

Similarly the warm boot code in CBIOSX points the DMA address at wherever it wants to load stuff.

True that when CP/M is up and running normally the CBIOS always loads (DMAs) from disk to the same sector buffer.

P.S. Blade One is up and running at 104MHz as well.


For me, the past is not over yet.

Back to Top
 

Dr_Acula
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 2008
Total Posts : 606
 
   Posted 9/22/2009 4:30 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
This is an intriguing clue:

I started with a brand new blank drive image. (drive C)
Did a PIP of a 104k file from drive A and it worked fine
Did a PIP of the same file again and it worked fine again.
Did a PIP of a different large file (100k) and it fell over about one third of the way through and started printing rubbish on the screen.


www.smarthome.viviti.com/build

Back to Top
 

Dr_Acula
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 2008
Total Posts : 606
 
   Posted 9/22/2009 4:38 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
And yet, do the same thing to drive D and it falls over on the very first PIP. Intriguingly, the rubbish on the screen was from the previous file that was PIP'ed to drive C. I think this is why I need to understand the dma buffers and where bytes are being stored. Both in spin and in CP/M.


www.smarthome.viviti.com/build

Back to Top
 

heater
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Feb 2008
Total Posts : 1832
 
   Posted 9/22/2009 6:33 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
I now have my RAM installed to Blade Two.

What's the latest/best RAM test to use prior to attempting to run ZiCog ?


For me, the past is not over yet.

Back to Top
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
 
   Posted 9/22/2009 6:48 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
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
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
 
   Posted 9/22/2009 7:09 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Code to test the SRAM is posted on this thread, page 3, second top post :-)

Drac: I will explain the dma shortly but I think you are looking at a commented out section.


Links to other interesting threads:
Back to Top
 

potatohead
640 Pixels... :)



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Sep 2006
Total Posts : 1338
 
   Posted 9/22/2009 7:35 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
:)

Color is coming soon. Man, I kind of want to build one of these!

(soon...)


Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!

Back to Top
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
 
   Posted 9/22/2009 7:48 PM (GMT -8)    Quote This PostAlert An Admin About This Post.

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 :p


Links to other interesting threads:
Back to Top
 
[ << Previous Thread | Next Thread >> ]
New Topic Post Reply Printable Version
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