I was idly looking at a keyboard and thinking, surface mount the chips, a couple of SD cards and perhaps some smaller lith batts - one self contained (perfectly disguised) office prop plaything.
And another thing ..
Is it possible to have the #IFDEFs and #ELSEs to "light up" as partners ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Is it possible to have the #IFDEFs and #ELSEs to "light up" as partners ???
Yes, I'll second that. The ifdef function in BST (and homespun) is proving so useful that it is now being pushed way beyond its initial intention. Some ifdefs are nested 3 deep and span several pages and it gets quite hard to trace the code.
PRI FindSDblock | i, n, r 'read blockno of file for count into buffer
r := sd.startSD(@ioControl) 'start the SD routines
UART.str(string("SD started..."))
CheckError(not r)
r := sd.mount_explicit(spiDO,spiClk,spiDI,spiCS) 'mount the SD
UART.str(string("SD mounted..."))
CheckError(r)
Which prints "SD started..." on the screen and then hangs.
I've change the pins so my pins should be correct.
spiDO = 13
spiClk = 14
spiDI = 15
spiCS = 9
I think it then jumps to sd.mount_explicit which is;
What is the circuit again? The little board looks like a Blade2 with the ram, latch etc. (Similar to the one that Cluso is going to shrink down to the size of a pinhead!). What is the bigger board?
Also how long did it take to make these and did it take long to get it onto a single sided board? Was that handrouted?
The little one is a bare blade2 (half meg) and works, thank you all, it has mesed up address and data orders to make tracks simpler.
The board next to it is the same ( with tweeks) plus a "DemoBoard" version of the PropCMD and regs etc. So it is nothing more than a blade3 free ....
Tomorrow there should be some output from it, I have drilled half the holes, before pretending I still care (do I need therapy... ) and having to lever out my 2, of 3, props from other things.
I wasn't showing off(ish) I just wanted to point out that I could make things(ish) (ish).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Toby: Very nice. Congratulations and welcome to the club
James: sd.mount_explicit makes cs low.
sd.start just passes the variable iocontrol so I can find out the sector address - this is where this routine stores the next sd sector address.
I have had some things to take care of back in Gosford :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
To someone used to coding basic, I think this is something like
if brlong$="FAT1" then startBlk=0
But it seems a hard way to do things for a high level language. Everything has to be grouped into groups of 4 bytes and it uses a lot more characters to describe what you want to do. My personal opinion is that if it is going to be this hard to do strings, may as well do them in assembly. I've written string compare routines in Z80 assembly that are easier to understand than this.
Anyway, gripe over. My goal is to find the code that makes the CS line low. Then I can put a halt after that line and test if indeed it went low.
The routine
pub mount_explicit(DO, Clk, DI, CS)
calls this
if initSDCard(DO, Clk, DI, CS)
abort -string("InitSDCard mount")
Which then jumps out of the fsrwfemto_rr001.spin object and goes to the sdspifemto.spin object. Which has the alias of ldr in the main spin program...
Which takes us to this code also called initSDCard()
PUB initSDCard(DO,Clk,DI,CS) | t '' Initialize SD card access
t := cnt
repeat while long[noparse][[/noparse]control][noparse][[/noparse]0] & ioTestRdy ' Wait for previous I/O to finish
long[noparse][[/noparse]control] := 0
long[noparse][[/noparse]control][noparse][[/noparse]0] := ioSpiInit << 24 | DO << 18 | Clk << 12 | DI << 6 | CS
repeat while long[noparse][[/noparse]control][noparse][[/noparse]0] & ioTestRdy ' Wait for this to finish
return (long[noparse][[/noparse]control][noparse][[/noparse]0] & ioTestErr) <> 0 ' Return any error code
But I can't see anywhere there that outputs a high or a low to a pin.
So, rather than ask how to do this (part of this is a learning exercise!), can I ask whether there is a way I can add in little bits of code that send debug messages back to the PC?
eg, in the main program, one could add
UART.str(string("Test point 1"))
Is it possible to add these sorts of debug messages in other (what I would call subroutines, but I think are called objects), eg in sdspifemto.spin? And, what would be even more useful, in the middle of PASM code in some way?
Or maybe another option is a completely new program, stripped right back to the bare essentials that opens a file on an SD card, writes"A" to the file and closes it. Just to test the card actually works.
long enough you will see that what it is really doing is a comparison between two longs. The one on the right hand side being a constant that is calculated at compile time not at run time. Much faster than doing a string comparison at run time.
As you know its not possible to put PASM inline with Spin so unless the whole thing is rewritten in PASM (and it fits in a COG) it's not really possible to do much better.
Can't really help with the CS thing much but I'm sure you will find some PASM code somewhere in the low level SD driver that is monitoring the content of the "control" structure and performing whatever commands are written there by the Spin code. Like for example the line:
long[noparse][[/noparse]control][noparse][[/noparse]0] := ioSpiInit << 24 | DO << 18 | Clk << 12 | DI << 6 | CS
which looks like it is writing an initialization command into the "control" array including the CS bit. Some where I'm sure there is some PASM that sees that ioSpint command and starts to tweak CS etc with some OUTA instructions.
Also looks like when the PASM has completed the command it will write ioTestRdy back to the "control" array to tell the Spin that the command is done and that it may continue hence the:
repeat while long[noparse][[/noparse]control][noparse][[/noparse]0] & ioTestRdy ' Wait for this to finish
in Spin which is waiting for PASM to say done with ioTestRdy equal true.
Arranging for debug messages from PASM is tough. Hence I debugged ZiCog initially by just lighting/flashing a LED or two with OUTA.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thanks heater. I have so much working on the board - vga, keyboard, low level PASM to read and write bytes to a ram chip. Just need to pull it all together. It is a bit frustrating as Cluso said that the SD card would be the easy bit - just change the pins over to whatever you are using, but it is turning out to be the really hard part. And the SD card is the reason I'm over here at the prop forum as it has defeated all but one member of the N8VEM group (Juha seems to have disappeared though he did leave us with some SD card code in Z80. But no-one else understands it). So in a way, the SD card code that the prop uses is rather unique.
The triblade code has some initialisation code that switches between the SD card and the ram, and this might be a problem. The only thing is that I can't find where this code might be being called from. As far as I can trace, it jumps straight into the SD card code before even thinking about talking to the ram. But then again, one would have expected Cluso's triblade code to at least tristate the ram chip out before attempting to talk to the SD card.
Re Arranging for debug messages from PASM is tough. Hence I debugged ZiCog initially by just lighting/flashing a LED or two with OUTA.
I was kind of hoping that wasn't the case. But since that is the way to do things, I at least do have some PASM code to flash a led on this particular board:
' **********************************************************************************************************
LedHigh ' turn led on, leave other pins low, assumes setup already done
mov outa,HC138A16_18 ' set data lines to zero, gate high and select A16-18 latch
or outa,#8 ' turn the led bit on 00001000
andn outa,GateHigh ' set gate low
or outa,GateHigh ' set it high again
LedHigh_ret ret
Tracing through SD code that doesn't work is going to be very tedious as I don't know what it is supposed to be doing! It may be easier to go back to the Z80 code and build an SD card reader/writer for the N8VEM. Though if it can just get to the stage of selecting the /CS line the rest ought to work.
I think you might be right in that it puts the data into an array, then reads it out somewhere else. Hopefully Cluso will have some ideas. I think he was looking at a complete new set of faster sd code anyway.
Arranging for debug messages from PASM is tough. Hence I debugged ZiCog initially by just lighting/flashing a LED or two with OUTA.
I've always found debugging from PASM _really_ easy. I either use tv_text or a serial port, and just have one cog sitting there pulling data from a long or series of longs in a defined place in ram. The code I'm debugging just does wrlongs with the data I want to see. That does rely on you having at least one cog spare. If you only have _one_ cog spare, then run simple serial and a loop in spin, otherwise use fdx or tv_text.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
heater said...
Brad, that's what I meant by tough[noparse]:)[/noparse]
Sorry, I missed the sarcasm.
I use the LED too, but now I have a reasonable DSO it's pure luxury [noparse]:)[/noparse]
I still use TV_TEXT and FDX. Particularly now I have the integrated terminal that I don't need to switch into and out of, serial debugging with F10 is much easier.
For TX_TEXT I have PiP in the top right of my PC monitor, so I just pop the NTSC in there and get it all on one screen.
I recently went back to a PIC for a project and really missed the ease of firing up a debug cog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Actually I was not meaning to be so sarcastic. I was just used to the idea that when debugging ZiCog the only serial port I had was tied up with the CP/M console emulation. The Spin the ran that was waiting on the emulation PASM that I was trying to debug. So it got a bit tougher that normal.
As it is I ended up with a single step mode in the emulation such that pretty much anything could be dumped to HUB by the PASM which then halted emulation and hence the Spin could display it along with regular Z80 register dumps.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Exactly what are you trying to do? Are you tyring to eliminate the /CS that Cluso put in or do something else? If it is the former, why not take the stock SD code instead of the one Cluso modified for the SD routines.
James: The code you are looking at is talking via the long to another cog running pasm. Once this cog executes the command, it returns a value in that hub long, allowing the spin code to continue. It is a fairly common method used for inter-cog communication. I have not delved that much into this code. It is an object that works, save for the bit that did not release the DO pin once CS was released. That was the only patch I had to do.
I guess what you are trying to do is be able to understand how the SD card works.
If you want to write a Z80 routine to access the SD card, unfortunately, since I didn't write any of the SD access routines, I cannot help you here.
If you are trying to get it to work on the prop board with all the latches you designed, then providing the 4 SD pins are not shared with or on a latch, then the SD routines should just work. Here I would suggest you go back to something simpler and get the basics working. Try PropCmd or PropDOS to get the SD running first. This will prove the driver. That is what I did and it was a walk in the park.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
If you are trying to get it to work on the prop board with all the latches you designed, then providing the 4 SD pins are not shared with or on a latch, then the SD routines should just work.
Hi Cluso,
No, unfortunately it doesn't work.
The hardware is very simple. 4 propeller pins to 4 pins on a standard sized SD card. Those pins don't go to anything else so there are no conflicts.
I tried a very simple bit of PASM code just to prove that the wires connecting the propeller to the SD card were connected.
' ********************************************************************************************************
CSLow ' set /CS pin low on the SD card for testing purposes /CS=pin9, CLK=pin14, /DI=Pin15 (and DO=13 HiZ)
SDLowDirect long %00000000_00000000_11000010_00000000 ' direction of pins
mov dira,SDLowDirect ' set pins as outputs
SDLow long %00000000_00000000_00000000_00000000 ' set /CS, DI and Clk low
mov outa,SDLow
CSLow_ret ret
This at least works - the volts go to the card and can be set high or low.
I looked at PropDOS but it appears to use a TV driver rather than VGA. I couldn't find PropCMD.
I guess what I need is to single step the fsrwFemto code one step at a time till it sets /CS low. In the Zicog code is a very useful debug routine;
UART.str (string("Test point"))
So I had a idea of putting that in the fsrw code:
pub mount_explicit(DO, Clk, DI, CS) | startBlk, sectorspercluster, reserved, rootentries, sectors
{{
' Mount a volume. The address passed in is passed along to the block
' layer; see the currently used block layer for documentation. If the
' volume mounts, a 0 is returned, else abort is called.
}}
UART.str (string("mounting SD card "))
But it gave an error in the compiler. So - is there a way of outputting text from within other objects?
Re Yoda If it is the former, why not take the stock SD code instead of the one Cluso modified for the SD routines.
Yes, the idea I'm working on is putting CP/M into one propeller. Latest schematic attached. That means latches for the ram chip and hence slower code, but the upside is lower cost. I'm not 100% sure what Cluso changed in the SD driver code - a clue is a comment "'' RR20090917 _rr001 mount --> mount_explicit " but I'm not sure which bit. Do you have a link for the stock SD code by any chance?
James: Here is the original PropDos (it is in the obex).·Yes it uses the TV.·VGA is not that difficult to substitute, just a few calls need to be added to VGA spin and call the object TV. It's probably even easier to use FDX and just add the extra routines - I think I already did that for you with my FDX_rr004.
However, it may be easier in the long run to just run the first bit of the ZiCog spin code to read the SD card. I suspect you are not getting that far but maybe looking at other stuff which is not important. Strip what you dont want and use FDX to give you feedback.
BTW, you will still require my mods for passing the correct pin numbers (mount_explicit). At least you can compare the changes I have done.
I suspect you have a hardware design problem. Do you have 10K pullups on all 4 SD signals? You should have pullups. Have you supplied GND to both pins on the SD (the uSD only has 1)? Have you got DI and DO reversed? DI is not D1 and DO is not D0(zero)? OK
re VGA & TV. I suspect if you joined VGA pins 3 & 13 together and fed them into an RCA plug with GND and put them into a TV, you could use the TV object using pin group P16-19 (P16 not connected) it would work, just crazy colors! Presuming of course you can swipe the family TV.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Just got the Blade2 and PropCOMM2 going, so I have a self contained SBC now.
I tried to get cheap and just use one Xtal, as the two props were so close together. Big mistake. I never realized that the Xtal osc gets interupted whilst the prop is reset/ programmed, general confusion for a bit but now the second Xtal has been grafted on.
Also I have found it useful to read the software setups. Jeff has the Tx/Rx on P8 + P9, I thought it was on the usual P30 + P31 pair, a bit more air wire.
Anybody know how fast PropCOMM can be fed ? I have slowed the Blade2 to 38400.
PS I don't have pullups on the SD cards.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 11/3/2009 10:50:57 PM GMT
Re "Strip what you dont want and use FDX to give you feedback.", what is FDX?
Actually, what I really need is the ability to output a short message back to the terminal for debugging purposes. I guess to write this in basic, one would use PRINT "Got to test point 1". Then in another subroutine, PRINT "Got to test point 2". I'm not sure how to translate that to spin, as the UART object works from the main routine but not from within other objects. So my understanding of the fundamentals of spin is obviosly flawed, as I was expecting spin calls to work from within other spin calls, not just from the 'main' rountine. And I presume that if that is the case, then it wouldn't matter whether you are sending text to the PC terminal or to a VGA or a TV object. Or maybe there is a way around that. (I know now it is not possible to drop in a line of spin code to print a message in the middle of PASM code). I guess I'm a guy who likes to pull things to bits to see how they work!
Re pullups on SD pins, since no other code is using the pins, would they not be left either high or low (never tristate)? Or could there be problems in the brief moment when the propeller restarts and the pins are tristated (and possibly oscillating at 50/60Hz from mains nearby?). I found this www.parallax.com/Portals/0/Downloads/docs/prod/comm/32313-SDCardAdapter-v1.0.pdf which has pullups. Is there a board that plugs into and some simple code to demonstrate how to use an SD card? Indeed, I did a bit of a search of google and found a few promising leads, but is there an example anywhere of a project that uses a standard sized sd card, with some simple code, and some photos of how the pins are connected and a schematic? It might have been a year or two ago before people moved on to the tiny micro sd cards?
I *think* the pinout is correct, ie the first pin is pin 9, then pin 1 etc. But some of the unused pins are floating and maybe need pullups as per that application note above. I'll put in the pullups once I can put a halt after the code that pulls /CS low.
Post edit: This is a darn fast forum. I post something asking for an SD card example, and as soon as I post, the post right above mine has an example! Toby, I see you have not just one, but *two* sd cards. Do you have a schematic for that and maybe a closeup photo of the connections round the sd card? Thanks++ in advance.
Toby: Nice work and congratulations · Another running ZiCog/CPM addict.
James: I know some have used the SD card without pullups. I certainly would put one on the /CS pin. The other 3 pins should be tristated when you leave the SD routine, but from recent discussion, you are not reaching this point.
FDX = FullDuplexSerial.spin object (or my slightly modified version)
AFAIK technically there should be no difference to the SD and microSD use by software, although the SPI interface is optional in the microSD implementation.
Try this thread for more info on the new fsrw object by lonesock & rokicki http://forums.parallax.com/showthread.php?p=824166· I have posted simple code there to test the drivers so you may find that useful.
As for debugging using FDX from a lower level in the chain, I am unsure. You could basically duplicate the tx routine to put a character directly·into the hub buffer and increment the pointer·so FDX transmits it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The warm, self satified glow only lasted overnight. This morning I realize that via PropCOMM I can't switch drives, ok via PST, so there must be some character passing that isn't the same between the two (looks ok on its screen). It winges about "Must be a hard disk" spits out register values and then spits out its dummy.
I put the chips back into the stand alone Blade2 board and even then the survey on A> gives SD errors at the end of the Port reports. I think I may have done the EEPROM an injustice.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Toby: James uses TeraTerm on the pc to do the VT100 emulation and wordstar ran great. So maybe go back to that point.
BTW Provided you wired as per my circuit, which appears to be the case in the photo, you do have pullups on the SD card - they are via the resistor network on the latch. I presume you have the extra 2 pullup resistors on P28 & P29 for the eeprom.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
As I was sat in the morning traffic jam I wondered if you were gettint one of the sme problems as I had, when I tried PropDos etc at first Then none of the "SD" cards I tried would mount. I had an 8MB, a 16MB and a 32MB cards kicking around. All were formatted to FAT (not FAT32, not that that size would allow it) but none of the would work. I nicked a 512MB from a camera and had instant success. That is why there are two simular cards in the photo, they are the only two that seem to operate. Pullups didn't change anything.
Clusso is right,·knock up a simple PropDos/ PropCOMM on a demo board etc get that going, and then change things.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I am getting closer to the quest for a debug statement.
As I understand it the Main program calls Objects. These might then call sub-objects The main routine defines objects in the "obj" section. A main routine then can use these objects in the form myobject.xxx. So far, so good and all very simple and objects can be used to encapsulate tasks (like printing to a PC terminal program) with a single command. However, these objects only appear to be able to be called from the main program. You can't call them from within other objects?
So, in BASIC, PRINT "Hello World" might call an object PRINT which sends something to the screen. Or perhaps it is easier to describe in C, which uses the printf(). These are commands that you get used to using and they always work. But not, it appears, in spin. These functions only work from the main program.
BUT, I found a clue!! Inside the fsrwFemto_rr001.spin object are calls to a sub-object called ldr. This is not mentioned anywhere in the obj list of the main program. But it does appear in the object list of the sub fsrw object.
SO - in the obj section of the fsrw object I added the uart object:
obj
'
' The object that provides the block-level access.
'
ldr : "sdspiFemto" ' SPIN program loader and support routines
UART1 : "FullDuplexSerial_rr004" 'FDX v1.2 with mods
And then I added this:
pub startSD(ioControl)
UART1.str (string("Starting SD in fsrwFemto")) ' added code to test where it is up to
return ldr.start(ioControl)
At least this does not give an error any more from the compiler. It doesn't actually print anything from that sub object, but it is one step in the quest for a PRINT "HELLO" from within an object.
So I think I am getting close to building a simple debugging system. Any help would be very much appreciated.
Addit: @Toby, I'm using 512Mb cards. My task list is to 1) print "Hello" from any nominal line in the spin code (not just from the Main spin code), then 2) trace out the code in the fsrw object to find where it sets /CS low, then 3) find where it sets the Clock and /DO lines low, and test those go out to the correct pins on the SD card, and then 4) add in the pullup resistors and then 5) hopefully read or write a file off the SD card.
Addit addit: More info - I think the above test starting two instances of uart means they will clash. (there was one extra bit of code to start the second uart too). Anyway, I'll leave the quest for debugging statements for the moment in search of actual debugging.
PRI FindSDblock | i, n, r 'read blockno of file for count into buffer
r := sd.startSD(@ioControl) 'start the SD routines
PUB start(ctrlBlk) | t '' Start the I2C I/O driver (standalone)
control := ctrlBlk '' using address of 2 longs for control
stop ' Stop a previous copy
computeTimes
long[noparse][[/noparse]control][noparse][[/noparse]0] := 0 ' Initialize the control block
long[noparse][[/noparse]control] := 0
cog := cognew(@i2cEntryPoint,control) + 1 ' Start a new cog with the I2C driver
return cog > 0 ' Indicate success
and printing out the value it returns a value of -1
I tried making cog a nominal value (eg 5) and changing the last line to 'return cog' and it returned the number. But what does the '> 0' mean? And what does the value of -1 mean - is this a fail on the part of starting the sd card access, or is it a fail on the part of finding a spare cog?
Yes, my version of Blade2 is just as your design apart from the jumbled up addr (not A0-A7)·and data orders. The SD card's /CE is from the latch so will not require a pullup anyway. The PropCOMM SD is on P0-P3 and has no pullups but I suppose that it would be better to give its /CE one at least.
I'll get a chance to play more tonight, last night was a rework because of my mistake in trying just the one Xtal and having the Blade2 XO driving the PropCOMM's XI. Works on AVRs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
James: The return cog >0 returns true or false to the calling routine. If a cog was started then cog will usually be set to the cog number +1. So if cog=0 then no cog was started and a false is returned.
Toby: I know a number of people are not using pullups on CLK, DI, DO lines. Without intimate circuit implementation, resistors are safer. The SD /CS will not require a pullup since the line is always driven by the latch, and the input to the latch has a pullup. RamBlade uses the data lines for CLK, DI & DO. The reason I chose the Address lines on the TriBlade was that I expected the address lines to already be outputs when I designed the card. However, in practice, they are tristated and a different cog drives the sd card lines, so nothing was gained.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
And another thing ..
Is it possible to have the #IFDEFs and #ELSEs to "light up" as partners ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Yes, I'll second that. The ifdef function in BST (and homespun) is proving so useful that it is now being pushed way beyond its initial intention. Some ifdefs are nested 3 deep and span several pages and it gets quite hard to trace the code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
I'm trying to trace program execution. I get this
UART.str (string("Starting Hdisks... ")) crlf blockno := 0 count := 8192 FindSDblockthen
PRI FindSDblock | i, n, r 'read blockno of file for count into buffer r := sd.startSD(@ioControl) 'start the SD routines UART.str(string("SD started...")) CheckError(not r) r := sd.mount_explicit(spiDO,spiClk,spiDI,spiCS) 'mount the SD UART.str(string("SD mounted...")) CheckError(r)Which prints "SD started..." on the screen and then hangs.
I've change the pins so my pins should be correct.
I think it then jumps to sd.mount_explicit which is;
pub mount_explicit(DO, Clk, DI, CS) | startBlk, sectorspercluster, reserved, rootentries, sectors
By this time, should /CS be low?
I'm going back to 'r := sd.startSD(@ioControl) 'start the SD routines'
Does this set /CS low? What is @iocontrol?
I'm trying to work at a very simple level - where is the code that sets /CS low for the first time?
Help would be most appreciated as I'm getting lost in amongst the code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
(I made the mistake of trying hairspray instead of PCB lacquer, used to work when I was a kid)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
What is the circuit again? The little board looks like a Blade2 with the ram, latch etc. (Similar to the one that Cluso is going to shrink down to the size of a pinhead!). What is the bigger board?
Also how long did it take to make these and did it take long to get it onto a single sided board? Was that handrouted?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
The board next to it is the same ( with tweeks) plus a "DemoBoard" version of the PropCMD and regs etc. So it is nothing more than a blade3 free ....
Tomorrow there should be some output from it, I have drilled half the holes, before pretending I still care (do I need therapy... ) and having to lever out my 2, of 3, props from other things.
I wasn't showing off(ish) I just wanted to point out that I could make things(ish) (ish).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
James: sd.mount_explicit makes cs low.
sd.start just passes the variable iocontrol so I can find out the sector address - this is where this routine stores the next sd sector address.
I have had some things to take care of back in Gosford :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
But now I'm really stuck. To be totally frank, Spin has me completely confused. I see code like this:
if (brlong(@buf+$36) == constant("F" + ("A" << 8) + ("T" << 16) + ("1" << 24))) startBlk := 0To someone used to coding basic, I think this is something like
But it seems a hard way to do things for a high level language. Everything has to be grouped into groups of 4 bytes and it uses a lot more characters to describe what you want to do. My personal opinion is that if it is going to be this hard to do strings, may as well do them in assembly. I've written string compare routines in Z80 assembly that are easier to understand than this.
Anyway, gripe over. My goal is to find the code that makes the CS line low. Then I can put a halt after that line and test if indeed it went low.
The routine
calls this
if initSDCard(DO, Clk, DI, CS) abort -string("InitSDCard mount")I think that then jumps to this
Which then jumps out of the fsrwfemto_rr001.spin object and goes to the sdspifemto.spin object. Which has the alias of ldr in the main spin program...
Which takes us to this code also called initSDCard()
But I can't see anywhere there that outputs a high or a low to a pin.
So, rather than ask how to do this (part of this is a learning exercise!), can I ask whether there is a way I can add in little bits of code that send debug messages back to the PC?
eg, in the main program, one could add
UART.str(string("Test point 1"))Is it possible to add these sorts of debug messages in other (what I would call subroutines, but I think are called objects), eg in sdspifemto.spin? And, what would be even more useful, in the middle of PASM code in some way?
Or maybe another option is a completely new program, stripped right back to the bare essentials that opens a file on an SD card, writes"A" to the file and closes it. Just to test the card actually works.
Help would be most appreciated!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 11/2/2009 11:38:20 AM GMT
if (brlong(@buf+$36) == constant("F" + ("A" << 8) + ("T" << 16) + ("1" << 24)))long enough you will see that what it is really doing is a comparison between two longs. The one on the right hand side being a constant that is calculated at compile time not at run time. Much faster than doing a string comparison at run time.
As you know its not possible to put PASM inline with Spin so unless the whole thing is rewritten in PASM (and it fits in a COG) it's not really possible to do much better.
Can't really help with the CS thing much but I'm sure you will find some PASM code somewhere in the low level SD driver that is monitoring the content of the "control" structure and performing whatever commands are written there by the Spin code. Like for example the line:
which looks like it is writing an initialization command into the "control" array including the CS bit. Some where I'm sure there is some PASM that sees that ioSpint command and starts to tweak CS etc with some OUTA instructions.
Also looks like when the PASM has completed the command it will write ioTestRdy back to the "control" array to tell the Spin that the command is done and that it may continue hence the:
in Spin which is waiting for PASM to say done with ioTestRdy equal true.
Arranging for debug messages from PASM is tough. Hence I debugged ZiCog initially by just lighting/flashing a LED or two with OUTA.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The triblade code has some initialisation code that switches between the SD card and the ram, and this might be a problem. The only thing is that I can't find where this code might be being called from. As far as I can trace, it jumps straight into the SD card code before even thinking about talking to the ram. But then again, one would have expected Cluso's triblade code to at least tristate the ram chip out before attempting to talk to the SD card.
Re Arranging for debug messages from PASM is tough. Hence I debugged ZiCog initially by just lighting/flashing a LED or two with OUTA.
I was kind of hoping that wasn't the case. But since that is the way to do things, I at least do have some PASM code to flash a led on this particular board:
' ********************************************************************************************************** LedHigh ' turn led on, leave other pins low, assumes setup already done mov outa,HC138A16_18 ' set data lines to zero, gate high and select A16-18 latch or outa,#8 ' turn the led bit on 00001000 andn outa,GateHigh ' set gate low or outa,GateHigh ' set it high again LedHigh_ret retTracing through SD code that doesn't work is going to be very tedious as I don't know what it is supposed to be doing! It may be easier to go back to the Z80 code and build an SD card reader/writer for the N8VEM. Though if it can just get to the stage of selecting the /CS line the rest ought to work.
I think you might be right in that it puts the data into an array, then reads it out somewhere else. Hopefully Cluso will have some ideas. I think he was looking at a complete new set of faster sd code anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
I've always found debugging from PASM _really_ easy. I either use tv_text or a serial port, and just have one cog sitting there pulling data from a long or series of longs in a defined place in ram. The code I'm debugging just does wrlongs with the data I want to see. That does rely on you having at least one cog spare. If you only have _one_ cog spare, then run simple serial and a loop in spin, otherwise use fdx or tv_text.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Sorry, I missed the sarcasm.
I use the LED too, but now I have a reasonable DSO it's pure luxury [noparse]:)[/noparse]
I still use TV_TEXT and FDX. Particularly now I have the integrated terminal that I don't need to switch into and out of, serial debugging with F10 is much easier.
For TX_TEXT I have PiP in the top right of my PC monitor, so I just pop the NTSC in there and get it all on one screen.
I recently went back to a PIC for a project and really missed the ease of firing up a debug cog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
As it is I ended up with a single step mode in the emulation such that pretty much anything could be dumped to HUB by the PASM which then halted emulation and hence the Spin could display it along with regular Z80 register dumps.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Exactly what are you trying to do? Are you tyring to eliminate the /CS that Cluso put in or do something else? If it is the former, why not take the stock SD code instead of the one Cluso modified for the SD routines.
Dave
I guess what you are trying to do is be able to understand how the SD card works.
If you want to write a Z80 routine to access the SD card, unfortunately, since I didn't write any of the SD access routines, I cannot help you here.
If you are trying to get it to work on the prop board with all the latches you designed, then providing the 4 SD pins are not shared with or on a latch, then the SD routines should just work. Here I would suggest you go back to something simpler and get the basics working. Try PropCmd or PropDOS to get the SD running first. This will prove the driver. That is what I did and it was a walk in the park.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Hi Cluso,
No, unfortunately it doesn't work.
The hardware is very simple. 4 propeller pins to 4 pins on a standard sized SD card. Those pins don't go to anything else so there are no conflicts.
I tried a very simple bit of PASM code just to prove that the wires connecting the propeller to the SD card were connected.
' ******************************************************************************************************** CSLow ' set /CS pin low on the SD card for testing purposes /CS=pin9, CLK=pin14, /DI=Pin15 (and DO=13 HiZ) SDLowDirect long %00000000_00000000_11000010_00000000 ' direction of pins mov dira,SDLowDirect ' set pins as outputs SDLow long %00000000_00000000_00000000_00000000 ' set /CS, DI and Clk low mov outa,SDLow CSLow_ret retThis at least works - the volts go to the card and can be set high or low.
I looked at PropDOS but it appears to use a TV driver rather than VGA. I couldn't find PropCMD.
I guess what I need is to single step the fsrwFemto code one step at a time till it sets /CS low. In the Zicog code is a very useful debug routine;
UART.str (string("Test point"))So I had a idea of putting that in the fsrw code:
pub mount_explicit(DO, Clk, DI, CS) | startBlk, sectorspercluster, reserved, rootentries, sectors {{ ' Mount a volume. The address passed in is passed along to the block ' layer; see the currently used block layer for documentation. If the ' volume mounts, a 0 is returned, else abort is called. }} UART.str (string("mounting SD card "))But it gave an error in the compiler. So - is there a way of outputting text from within other objects?
Re Yoda
If it is the former, why not take the stock SD code instead of the one Cluso modified for the SD routines.
Yes, the idea I'm working on is putting CP/M into one propeller. Latest schematic attached. That means latches for the ram chip and hence slower code, but the upside is lower cost. I'm not 100% sure what Cluso changed in the SD driver code - a clue is a comment "'' RR20090917 _rr001 mount --> mount_explicit " but I'm not sure which bit. Do you have a link for the stock SD code by any chance?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 11/3/2009 12:39:50 PM GMT
However, it may be easier in the long run to just run the first bit of the ZiCog spin code to read the SD card. I suspect you are not getting that far but maybe looking at other stuff which is not important. Strip what you dont want and use FDX to give you feedback.
BTW, you will still require my mods for passing the correct pin numbers (mount_explicit). At least you can compare the changes I have done.
I suspect you have a hardware design problem. Do you have 10K pullups on all 4 SD signals? You should have pullups. Have you supplied GND to both pins on the SD (the uSD only has 1)? Have you got DI and DO reversed? DI is not D1 and DO is not D0(zero)? OK
Here is the SD pinout http://pinouts.ru/Memory/sdcard_pinout.shtml
1=/CS, 2=DI, 3&6=GND, 4=3V3, 5=CLK, 7=DO, 8&9=nc
I suspect you may have missed the fact that pin 9 is the short in, then comes pins 1 to 8 ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I tried to get cheap and just use one Xtal, as the two props were so close together. Big mistake. I never realized that the Xtal osc gets interupted whilst the prop is reset/ programmed, general confusion for a bit but now the second Xtal has been grafted on.
Also I have found it useful to read the software setups. Jeff has the Tx/Rx on P8 + P9, I thought it was on the usual P30 + P31 pair, a bit more air wire.
Anybody know how fast PropCOMM can be fed ? I have slowed the Blade2 to 38400.
PS I don't have pullups on the SD cards.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 11/3/2009 10:50:57 PM GMT
Re "Strip what you dont want and use FDX to give you feedback.", what is FDX?
Actually, what I really need is the ability to output a short message back to the terminal for debugging purposes. I guess to write this in basic, one would use PRINT "Got to test point 1". Then in another subroutine, PRINT "Got to test point 2". I'm not sure how to translate that to spin, as the UART object works from the main routine but not from within other objects. So my understanding of the fundamentals of spin is obviosly flawed, as I was expecting spin calls to work from within other spin calls, not just from the 'main' rountine. And I presume that if that is the case, then it wouldn't matter whether you are sending text to the PC terminal or to a VGA or a TV object. Or maybe there is a way around that. (I know now it is not possible to drop in a line of spin code to print a message in the middle of PASM code). I guess I'm a guy who likes to pull things to bits to see how they work!
Re pullups on SD pins, since no other code is using the pins, would they not be left either high or low (never tristate)? Or could there be problems in the brief moment when the propeller restarts and the pins are tristated (and possibly oscillating at 50/60Hz from mains nearby?). I found this www.parallax.com/Portals/0/Downloads/docs/prod/comm/32313-SDCardAdapter-v1.0.pdf which has pullups. Is there a board that plugs into and some simple code to demonstrate how to use an SD card? Indeed, I did a bit of a search of google and found a few promising leads, but is there an example anywhere of a project that uses a standard sized sd card, with some simple code, and some photos of how the pins are connected and a schematic? It might have been a year or two ago before people moved on to the tiny micro sd cards?
I *think* the pinout is correct, ie the first pin is pin 9, then pin 1 etc. But some of the unused pins are floating and maybe need pullups as per that application note above. I'll put in the pullups once I can put a halt after the code that pulls /CS low.
Post edit: This is a darn fast forum. I post something asking for an SD card example, and as soon as I post, the post right above mine has an example! Toby, I see you have not just one, but *two* sd cards. Do you have a schematic for that and maybe a closeup photo of the connections round the sd card? Thanks++ in advance.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 11/3/2009 11:12:39 PM GMT
James: I know some have used the SD card without pullups. I certainly would put one on the /CS pin. The other 3 pins should be tristated when you leave the SD routine, but from recent discussion, you are not reaching this point.
FDX = FullDuplexSerial.spin object (or my slightly modified version)
AFAIK technically there should be no difference to the SD and microSD use by software, although the SPI interface is optional in the microSD implementation.
Try this thread for more info on the new fsrw object by lonesock & rokicki http://forums.parallax.com/showthread.php?p=824166· I have posted simple code there to test the drivers so you may find that useful.
As for debugging using FDX from a lower level in the chain, I am unsure. You could basically duplicate the tx routine to put a character directly·into the hub buffer and increment the pointer·so FDX transmits it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I'll draw up something and post later today.
The warm, self satified glow only lasted overnight. This morning I realize that via PropCOMM I can't switch drives, ok via PST, so there must be some character passing that isn't the same between the two (looks ok on its screen). It winges about "Must be a hard disk" spits out register values and then spits out its dummy.
I put the chips back into the stand alone Blade2 board and even then the survey on A> gives SD errors at the end of the Port reports. I think I may have done the EEPROM an injustice.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
BTW Provided you wired as per my circuit, which appears to be the case in the photo, you do have pullups on the SD card - they are via the resistor network on the latch. I presume you have the extra 2 pullup resistors on P28 & P29 for the eeprom.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
As I was sat in the morning traffic jam I wondered if you were gettint one of the sme problems as I had, when I tried PropDos etc at first Then none of the "SD" cards I tried would mount. I had an 8MB, a 16MB and a 32MB cards kicking around. All were formatted to FAT (not FAT32, not that that size would allow it) but none of the would work. I nicked a 512MB from a camera and had instant success. That is why there are two simular cards in the photo, they are the only two that seem to operate. Pullups didn't change anything.
Clusso is right,·knock up a simple PropDos/ PropCOMM on a demo board etc get that going, and then change things.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
As I understand it the Main program calls Objects. These might then call sub-objects The main routine defines objects in the "obj" section. A main routine then can use these objects in the form myobject.xxx. So far, so good and all very simple and objects can be used to encapsulate tasks (like printing to a PC terminal program) with a single command. However, these objects only appear to be able to be called from the main program. You can't call them from within other objects?
So, in BASIC, PRINT "Hello World" might call an object PRINT which sends something to the screen. Or perhaps it is easier to describe in C, which uses the printf(). These are commands that you get used to using and they always work. But not, it appears, in spin. These functions only work from the main program.
BUT, I found a clue!! Inside the fsrwFemto_rr001.spin object are calls to a sub-object called ldr. This is not mentioned anywhere in the obj list of the main program. But it does appear in the object list of the sub fsrw object.
SO - in the obj section of the fsrw object I added the uart object:
And then I added this:
pub startSD(ioControl) UART1.str (string("Starting SD in fsrwFemto")) ' added code to test where it is up to return ldr.start(ioControl)At least this does not give an error any more from the compiler. It doesn't actually print anything from that sub object, but it is one step in the quest for a PRINT "HELLO" from within an object.
So I think I am getting close to building a simple debugging system. Any help would be very much appreciated.
Addit: @Toby, I'm using 512Mb cards. My task list is to 1) print "Hello" from any nominal line in the spin code (not just from the Main spin code), then 2) trace out the code in the fsrw object to find where it sets /CS low, then 3) find where it sets the Clock and /DO lines low, and test those go out to the correct pins on the SD card, and then 4) add in the pullup resistors and then 5) hopefully read or write a file off the SD card.
Addit addit: More info - I think the above test starting two instances of uart means they will clash. (there was one extra bit of code to start the second uart too). Anyway, I'll leave the quest for debugging statements for the moment in search of actual debugging.
calls this
which calls this
and printing out the value it returns a value of -1
I tried making cog a nominal value (eg 5) and changing the last line to 'return cog' and it returned the number. But what does the '> 0' mean? And what does the value of -1 mean - is this a fail on the part of starting the sd card access, or is it a fail on the part of finding a spare cog?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 11/4/2009 11:47:16 AM GMT
Yes, my version of Blade2 is just as your design apart from the jumbled up addr (not A0-A7)·and data orders. The SD card's /CE is from the latch so will not require a pullup anyway. The PropCOMM SD is on P0-P3 and has no pullups but I suppose that it would be better to give its /CE one at least.
I'll get a chance to play more tonight, last night was a rework because of my mistake in trying just the one Xtal and having the Blade2 XO driving the PropCOMM's XI. Works on AVRs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Toby: I know a number of people are not using pullups on CLK, DI, DO lines. Without intimate circuit implementation, resistors are safer. The SD /CS will not require a pullup since the line is always driven by the latch, and the input to the latch has a pullup. RamBlade uses the data lines for CLK, DI & DO. The reason I chose the Address lines on the TriBlade was that I expected the address lines to already be outputs when I designed the card. However, in practice, they are tristated and a different cog drives the sd card lines, so nothing was gained.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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