Peter,
Over on the PropBasic thread you mentioned perhaps putting Basic language support over the top of Forth in Tachyon. IMHO this would be a big boost for those of us who would prefer Basic over Forth. Perhaps Spin support might be interesting too???
' 1- ( n1 -- n1-1 )
DEC test $,#1 wc
' 1+ ( n1 -- n1+1 )
INC sumc tos,#1 ' inc or dec depending upon carry (default cleared by doNEXT)
jmp unext
$ is the "here symbol".
So DEC works only if it is on an odd address, or not ???
$ gives the register contents, not the address,
since "test" performs an AND of the $ register contents with literal #1
the instruction at <here> has the 1 in the S field which gives a 1 after the AND and wc gives the parity which is 1 so C is set
a bit tricky ;-)
so
test $,#1 wc
is equivalent to a SETC instruction which does not exist
Peter,
Over on the PropBasic thread you mentioned perhaps putting Basic language support over the top of Forth in Tachyon. IMHO this would be a big boost for those of us who would prefer Basic over Forth. Perhaps Spin support might be interesting too???
Well if Tachyon Basic was designed to always work with SD then I could add a lot of extra features to it for sure including source code editing and perhaps autocompletion or hinting. So it would be a Prop resident Basic much like Mike Green's Basic. I would also think that I would like to make it a structured Basic along with named functions which means we don't need GOTO or GOSUB as they would be implied by reference. Also would we bother making this a floating point Basic with all the limitations of speed and precision or would we maybe go to a 64-bit integer model that supported a "floating decimal point" instead? I like Basic for some things but I hate the limitations of number bases, peek and poke, and it's lack of extensibility whereas Forth is inherently extensible in that you can extend not only the language but also the way it compiles.
Anyway the thing is to start somewhere and this could even be a traditional non-structured Basic complete with line numbers as I would just treat these as labels anyway. This would be the easiest to get going although it would be a lot simpler if we enforced whitespace as "A = B + C" rather than "A=B+C" at least for starters.
Since it would be built on Tachyon Forth infrastructure it would also be possible to mix code too and of course the whole environment would be interactive. At present I have the simple 40x15 text VGA built in as this takes up very little memory but for another 2k RAM this could be upgraded to 80x25 or more. Tie in a PS/2 keyboard or my wireless Logitech using the nRF24L01 and we have a complete stand-alone system if we include the SD.
Hi Peter,
can't find this in your dropbox.
wanted to have a look at your nRF24L01 code.
we talked about it long time ago,
but then ESP866 came around ...
so I didn't proceed with the nRF24L01,
but still have 10 of them here waiting for a use.
All languages evolve, even the ones we speak, there are many redundancies when there are improvements. So VARIABLE was nice like 40 years ago or so but I prefer to say what type of variable and how many of them or specify a list:
BYTE flag
BYTE flag,options,state
10 BYTES states
WORD jellybeancounter
LONG beancounter
DOUBLE sandcounter
(also an alternative specifying an org for a data segment)
BUFFERS ORG
1 DS flag
1 DS flags,options,state
10 DS states
2 DS beancounter
etc
But as for WORDS it does print every word however your terminal may be at fault if it is sending back characters during the listing. WORDS, QWORDS and QW all respond to SPACE as a pause/step, ENTER as continue, and ESC as escape. I use minicom or TeraTerm without any handshake.
Sorry, that's possible but only if it was a really early example perhaps. But all the CTR stuff is embedded in EXTEND.fth anyway and normally part of an Explorer build. The
CTR stuff covers modes, frequency generation using HZ..MHZ etc and DAC outputs and even blinky lights.
It might not be the most current version there as an update is driven by needs and balanced by testing. But I will try and check this again soon although some of the Explorer versions had extras such as auto-scan 1-wire, SPLAT etc.
Thanks Peter. I seem to recall you mentioning the VGA routines also able to handle a TV text display. Is this correct and how would I write to a TV text display?
Thanks Peter. I seem to recall you mentioning the VGA routines also able to handle a TV text display. Is this correct and how would I write to a TV text display?
There is so much packed into Tachyon that I tend to forget what I have Yes, the "text" VGA is a minimal footprint VGA that really only takes about 1k RAM arranged as 40x15 but it also includes a "big digit" mode which I use for easy viewing from a distance such as timers etc.
The VGA is selected as a streamed output just like the serial console so it's just a matter of switching it with the VGA word then you can PRINT" HELLO WORLD" and send control codes etc. Use CON to switch back to the serial console.
More amazing than all the stuff that is packed into Tachyon and all that it does on even a basic Prop is that more people aren't using it especially since it is so interactive too.
I've taken a big step and purchased the VGA accessory pack for the Propeller Proto Board (#32212); have the parts mounted and would like to know where I can find the source code to allow me to understand how to use the VGA feature. I don't see it in the Tachyon Links Page, or my old eyes might have missed it. It would be fun to play around with the VGA monitor now connected to this board!
The Explorer version I have loaded starts with TEXTBOX, so I must be getting close?
I've taken a big step and purchased the VGA accessory pack for the Propeller Proto Board (#32212); have the parts mounted and would like to know where I can find the source code to allow me to understand how to use the VGA feature. I don't see it in the Tachyon Links Page, or my old eyes might have missed it. It would be fun to play around with the VGA monitor now connected to this board!
The Explorer version I have loaded starts with TEXTBOX, so I must be getting close?
Yep, try typing VGA as that will now redirect all the Forth output to the VGA monitor and I think it does an automatic init with !VGA but I will have to go and check.
Hi Peter. Okay ... tried VGA and output does go to the VGA monitor (with a rather large font!) and I can type CON to get back to the other console I use for programming. The question remains ... I see plenty of nice words in this Explorer version, but don't know where to find the source, so I can see how to use them.
I haven't tried it yet but maybe I'll get time to try it on Prop 2
don'T wait so long
you miss a lot of fun you can have already with Tachyon on the P1
I just converted a beginning Arduino user to Tachyon/P1 with a few interactive demonstrations and unbeatable interactive development speed.
After he understood the stack it went all quite fast for a programming newbi
Hi Peter. Okay ... tried VGA and output does go to the VGA monitor (with a rather large font!) and I can type CON to get back to the other console I use for programming. The question remains ... I see plenty of nice words in this Explorer version, but don't know where to find the source, so I can see how to use them.
see Peter's footer - DROPBOX and there EXTEND.fth
there is the Explorer source
and in subdirectories the source for some special extensions
I haven't tried Forth yet but what I hear is good bit that's just all words. Soon I'll see how it stacks up to other languages. (my attempt at a Forth joke) LOL
seriously, I have to wait because I have too many projects in various stages + Prop 2 learning and Smart Pascal etc. I'm sure I'll like it when I do try it though. I don't understand the difference versions available for the Prop . However, Peter is doing a great job with TACHYON and I may go that route. Also, earlier this week I did download the free Forth book(PDF) and had a quick look.
I haven't tried Forth yet but what I hear is good bit that's just all words. Soon I'll see how it stacks up to other languages. (my attempt at a Forth joke) LOL
seriously, I have to wait because I have too many projects in various stages + Prop 2 learning and Smart Pascal etc. I'm sure I'll like it when I do try it though. I don't understand the difference versions available for the Prop .
Ha ha
However just remember this one little big thing, Forth is not just a "language", it is a target resident interactive environment and development system. Whoa!
So because of this the joke is rather that other "languages" just don't stack up to Forth
How many times have you written your code on the PC and compiled and downloaded it into the Prop? Stacks? (pun) Later on though after you have taken it off the bench and buried it into a project but something is not right or needs to be improved.... back to the PC to edit/compile/download and cross your fingers. Forth though is not like that as you can continue to talk to your routines and the Forth system even with a smartphone and even though it is buried in a project. You say to your unit "FAST FORWARD 100 STEPS" and it does just what you asks. See where I'm going?
As to the "Forths" that are available I can honestly say with first hand experience and knowledge that Tachyon is the only one built for speed, compactness, and for actual USE (because I use it for commercial projects). Yeah that bold type is to remind us that it is all very good having something like a Forth but like many "Forths" on different processors including the Prop they all seem to be incomplete or academic. Like the bicycle lane that suddenly ends in bush before you have really gone anywhere, leaving it up to you to do the actual hard part.
So I wrote my own Forth that could be compiled in one step using the Prop tool and to be really useful it had to be fast yet it couldn't take a lot of memory as I find it's not a bad thing to have some memory left over to actually use for doing something useful
Besides all the speed and compactness packed into the Prop's tiny little EEPROM I have paved a cycle path through the bush to some really interesting places, places such as virtual memory access of FAT32 files, FTP and web servers etc, stacks of I/O devices and even a built-in VGA too. The list goes on but it means you can get to where you want to go really quickly and all you have to do is learn to ride a bike so to speak. Once you do you never forget.
Thanks, MJB! I'll give it a look and see what I can understand.
It can go quite fast:
Today I had a lazy afternoon and was showing the Arduino beginner more of Tachyon. And set up a breadboard Prop DIP40 for him.
He had a DHT11 temperature & humidity sensor in his Arduino test kit.
We tried the DHT22 code from EXTEND.fth
and it worked intermittedly.
So I explained Peter's source code line by line and after checking the DHT11 datasheet we changed some timing and adapted to the fact that the DHT11 does NOT provide the after comma decimals, the DHT22 returns.
pub DHT11 ( pin -- rh temp ) \ rh in %, temp in full °C
runtime @ httime @ - 2000 => --- don't poll more than once every 2 seconds
IF
runtime @ httime ! --- mark runtime when this was polled
htck C~
DUP MASK 3 COGREG!
DUP LOW 20 ms DUP FLOAT --- Generate reset pulse
DHTBIT DROP --- wait for start of response
DHTBIT 3 / 2* htref W! --- use start bit as reference
DHTBYTE DHTBYTE DROP --- 2 bytes humidity reading
DHTBYTE DHTBYTE DROP --- 2 bytes temperature reading
htck C@ DHTBYTE = --- if checksum does not match then use last reading
IF htsav W! rh W! ELSE 2DROP THEN --- latch readings if valid
THEN
DROP rh W@ htsav W@ --- return with latest valid result
;
pub .DHT11 ( pin -- )
DHT11
." Temp = " .
." Degrees Celcius RH = " . ." %" CR ;
pub LOOPDHT11 ( pin -- )
BEGIN
DUP
.DHT11 5 seconds
KEY
UNTIL
DROP
;
Completely written from the ground up to suit the way I use Tachyon. So the only real PASM is just the SPIRD and SPIWR instructions and a small PASM module that gets loaded for block read and write.
The other thing is that I don't pull-up CS for the SD card as I detect the pull-up in the card itself so I can't use an external pull-up if I want this feature.
Did you write it or is it based on one of the existing SD drivers?
Hi Cluso,
to make it faster for you here Peter's code:
\ in the kernel !
{ *** SPI *** }
' SPI INSTRUCTIONS
{HELP SPIWR ( data -- data2 )
Simple fast, bare-bones SPI - transmits 8 bits MSB first
- data must be left justified - data is not discarded but rotated by number of shift operations used
Usage: $1234 SPIWR16 'transmit 16 bits
SPIWR ( data -- data<<8 ) send the MSByte
SPIWRB ( data -- data<<8 ) send the LSByte
SPIWR16 ( data -- data<<16 ) send the LSWord
SPIWRX permits variable number of bits if spicnt is set directly with @SPICNT COGREG! and those bits are shifted to MSBit before
}
SPIWR16 rol tos,#24 '
mov ACC,#8 ' force a 16-bit transfer
SPIWRB rol tos,#24 ' left justify and write byte to SPI (2.8us)
SPIWR add ACC,#8 ' code execution time of 2.25us + overhead
SPIWRX andn outa,spice ' always activate the chip enable (saves time in HL)
SPIwrlp rol tos,#1 wc ' assume msb first (140208 update now rotates)
muxc OUTA,spiout ' send next bit of data out
xor OUTA,spisck ' toggle clock
xor OUTA,spisck ' toggle clock
djnz ACC,#SPIwrlp
jmp unext
' Receive data and shift into existing stack parameter
' If MOSI needs to be in a certain state then this should be set beforehand
' Clock will simply pulse from it's starting state - normally low
' Useage: 0 SPIRD SPIRD SPIRD SPIRD 'read 32-bits as one long
' SPIRD ( data -- data<<8 ) ' 2.8us
SPIRD mov spicnt,#8 ' always read back 8-bits
SPIRDX andn outa,spice ' always activate the chip enable (saves time in HL)
SPIrdlp xor OUTA,spisck ' toggle clock
test spiinp,INA wc ' read data from device
rcl tos,#1
xor OUTA,spisck ' toggle clock
djnz spicnt,#SPIrdlp
jmp unext
\ loadable modules
{HELP SDRD ( dst char -- firstPos charcnt \ read block from SD into memory while scanning for special char )
dst is a 32 bit SD-card address 0..4GB, char is the character to scan for while, reading in the block.
NOTE: ensure MOSI is set as an output high from caller by 1 COGREG@ OUTSET
This is just the low-level block read once the SD card has been setup, so it just reads a sector into the dst
There is also a scan character that it will look for and return it's first position and how many were found
}
org _RUNMOD
_SDRD
mov X,tos+1 ' dst --> X
mov R2,dst1 '$200 ' R2 = 512 bytes
SDRDSClp mov R1,#8 ' 8-bits
SDRDSCbits andn OUTA,sck ' clock low
test miso,INA wc ' test data from device while clock is low
rcl R0,#1 ' now assemble data (also setup time for mosi)
or OUTA,sck ' clock high
djnz R1,#SDRDSCbits
andn OUTA,sck ' leave with clock low
wrbyte R0,X ' write byte to destination
and R0,#$FF ' only want to compare a byte value
cmp R0,tos wz ' compare byte with char unsigned for equality
if_z add ACC,#1 ' found one and increment count
if_z cmp ACC,#1 wz ' if match and count = 1 (first occurrence)
if_z mov tos+1,X ' then save dst (tos+2) to firstpos (tos)
add X,#1 ' dst = dst+1
djnz R2,#SDRDSClp ' next
call #POPX ' discard "char"
jmp #PUSHACC ' push char count and clear ACC
' SD MODULE
org _RUNMOD
' Write a block to the SD card - 512 bytes
' SDWR ( src cnt -- ;write block from memory to SD )
_SDWR
or DIRA,mosi
SDWRlp rdbyte R0,tos+1 ' read next byte from source
add tos+1,#1 ' increment source address
shl R0,#24 ' left justify
mov R1,#8 ' send 8 bits
SDWRbits andn OUTA,sck ' clock low
shl R0,#1 wc ' assume msb first
muxc OUTA,mosi ' send next bit of data out
or OUTA,sck ' clock high
djnz R1,#SDWRbits
andn OUTA,sck ' leave with clock low
djnz tos,#SDWRlp ' next byte
jmp #DROP2
Thanks MJB.
What I was really interested in was whether Peter had written another interface, or used one of the existing 3 interfaces.
Unfortunately, all the pasm drivers use a different interface mechanism which makes swapping them a nightmare.
Comments
Over on the PropBasic thread you mentioned perhaps putting Basic language support over the top of Forth in Tachyon. IMHO this would be a big boost for those of us who would prefer Basic over Forth. Perhaps Spin support might be interesting too???
since "test" performs an AND of the $ register contents with literal #1
the instruction at <here> has the 1 in the S field which gives a 1 after the AND and wc gives the parity which is 1 so C is set
a bit tricky ;-)
so is equivalent to a SETC instruction which does not exist
Well if Tachyon Basic was designed to always work with SD then I could add a lot of extra features to it for sure including source code editing and perhaps autocompletion or hinting. So it would be a Prop resident Basic much like Mike Green's Basic. I would also think that I would like to make it a structured Basic along with named functions which means we don't need GOTO or GOSUB as they would be implied by reference. Also would we bother making this a floating point Basic with all the limitations of speed and precision or would we maybe go to a 64-bit integer model that supported a "floating decimal point" instead? I like Basic for some things but I hate the limitations of number bases, peek and poke, and it's lack of extensibility whereas Forth is inherently extensible in that you can extend not only the language but also the way it compiles.
Anyway the thing is to start somewhere and this could even be a traditional non-structured Basic complete with line numbers as I would just treat these as labels anyway. This would be the easiest to get going although it would be a lot simpler if we enforced whitespace as "A = B + C" rather than "A=B+C" at least for starters.
Since it would be built on Tachyon Forth infrastructure it would also be possible to mix code too and of course the whole environment would be interactive. At present I have the simple 40x15 text VGA built in as this takes up very little memory but for another 2k RAM this could be upgraded to 80x25 or more. Tie in a PS/2 keyboard or my wireless Logitech using the nRF24L01 and we have a complete stand-alone system if we include the SD.
can't find this in your dropbox.
wanted to have a look at your nRF24L01 code.
we talked about it long time ago,
but then ESP866 came around ...
so I didn't proceed with the nRF24L01,
but still have 10 of them here waiting for a use.
Danke!
I fear this is a silly question:
VARIABLE seems not to exist? And WORDS does not print every word.
Many thanks!
Christof
BYTE flag
BYTE flag,options,state
10 BYTES states
WORD jellybeancounter
LONG beancounter
DOUBLE sandcounter
(also an alternative specifying an org for a data segment)
BUFFERS ORG
1 DS flag
1 DS flags,options,state
10 DS states
2 DS beancounter
etc
But as for WORDS it does print every word however your terminal may be at fault if it is sending back characters during the listing. WORDS, QWORDS and QW all respond to SPACE as a pause/step, ENTER as continue, and ESC as escape. I use minicom or TeraTerm without any handshake.
The ctr example uses VARIABLE, so I did think I made some mistakes....
Christof
CTR stuff covers modes, frequency generation using HZ..MHZ etc and DAC outputs and even blinky lights.
There is so much packed into Tachyon that I tend to forget what I have
The VGA is selected as a streamed output just like the serial console so it's just a matter of switching it with the VGA word then you can PRINT" HELLO WORLD" and send control codes etc. Use CON to switch back to the serial console.
More amazing than all the stuff that is packed into Tachyon and all that it does on even a basic Prop is that more people aren't using it especially since it is so interactive too.
Cool!
re:TACHYON O/S
I haven't tried it yet but maybe I'll get time to try it on Prop 2
The Explorer version I have loaded starts with TEXTBOX, so I must be getting close?
Yep, try typing VGA as that will now redirect all the Forth output to the VGA monitor and I think it does an automatic init with !VGA but I will have to go and check.
you miss a lot of fun you can have already with Tachyon on the P1
I just converted a beginning Arduino user to Tachyon/P1 with a few interactive demonstrations and unbeatable interactive development speed.
After he understood the stack it went all quite fast for a programming newbi
see Peter's footer - DROPBOX and there EXTEND.fth
there is the Explorer source
and in subdirectories the source for some special extensions
re:don'T wait so long
I haven't tried Forth yet but what I hear is good bit that's just all words. Soon I'll see how it stacks up to other languages. (my attempt at a Forth joke) LOL
seriously, I have to wait because I have too many projects in various stages + Prop 2 learning and Smart Pascal etc. I'm sure I'll like it when I do try it though. I don't understand the difference versions available for the Prop . However, Peter is doing a great job with TACHYON and I may go that route. Also, earlier this week I did download the free Forth book(PDF) and had a quick look.
Ha ha
However just remember this one little big thing, Forth is not just a "language", it is a target resident interactive environment and development system. Whoa!
So because of this the joke is rather that other "languages" just don't stack up to Forth
How many times have you written your code on the PC and compiled and downloaded it into the Prop? Stacks? (pun) Later on though after you have taken it off the bench and buried it into a project but something is not right or needs to be improved.... back to the PC to edit/compile/download and cross your fingers. Forth though is not like that as you can continue to talk to your routines and the Forth system even with a smartphone and even though it is buried in a project. You say to your unit "FAST FORWARD 100 STEPS" and it does just what you asks. See where I'm going?
As to the "Forths" that are available I can honestly say with first hand experience and knowledge that Tachyon is the only one built for speed, compactness, and for actual USE (because I use it for commercial projects). Yeah that bold type is to remind us that it is all very good having something like a Forth but like many "Forths" on different processors including the Prop they all seem to be incomplete or academic. Like the bicycle lane that suddenly ends in bush before you have really gone anywhere, leaving it up to you to do the actual hard part.
So I wrote my own Forth that could be compiled in one step using the Prop tool and to be really useful it had to be fast yet it couldn't take a lot of memory as I find it's not a bad thing to have some memory left over to actually use for doing something useful
Besides all the speed and compactness packed into the Prop's tiny little EEPROM I have paved a cycle path through the bush to some really interesting places, places such as virtual memory access of FAT32 files, FTP and web servers etc, stacks of I/O devices and even a built-in VGA too. The list goes on but it means you can get to where you want to go really quickly and all you have to do is learn to ride a bike so to speak. Once you do you never forget.
It can go quite fast:
Today I had a lazy afternoon and was showing the Arduino beginner more of Tachyon. And set up a breadboard Prop DIP40 for him.
He had a DHT11 temperature & humidity sensor in his Arduino test kit.
We tried the DHT22 code from EXTEND.fth
and it worked intermittedly.
So I explained Peter's source code line by line and after checking the DHT11 datasheet we changed some timing and adapted to the fact that the DHT11 does NOT provide the after comma decimals, the DHT22 returns.
All the source I have written is in the Dropbox folders specifically:
- SD card and virtual memory layer
- FAT32 Filesystem
Any Tachyon cog simply executes the code directly.
The other thing is that I don't pull-up CS for the SD card as I detect the pull-up in the card itself so I can't use an external pull-up if I want this feature.
Hi Cluso,
to make it faster for you here Peter's code:
\ in the kernel ! { *** SPI *** } ' SPI INSTRUCTIONS {HELP SPIWR ( data -- data2 ) Simple fast, bare-bones SPI - transmits 8 bits MSB first - data must be left justified - data is not discarded but rotated by number of shift operations used Usage: $1234 SPIWR16 'transmit 16 bits SPIWR ( data -- data<<8 ) send the MSByte SPIWRB ( data -- data<<8 ) send the LSByte SPIWR16 ( data -- data<<16 ) send the LSWord SPIWRX permits variable number of bits if spicnt is set directly with @SPICNT COGREG! and those bits are shifted to MSBit before } SPIWR16 rol tos,#24 ' mov ACC,#8 ' force a 16-bit transfer SPIWRB rol tos,#24 ' left justify and write byte to SPI (2.8us) SPIWR add ACC,#8 ' code execution time of 2.25us + overhead SPIWRX andn outa,spice ' always activate the chip enable (saves time in HL) SPIwrlp rol tos,#1 wc ' assume msb first (140208 update now rotates) muxc OUTA,spiout ' send next bit of data out xor OUTA,spisck ' toggle clock xor OUTA,spisck ' toggle clock djnz ACC,#SPIwrlp jmp unext ' Receive data and shift into existing stack parameter ' If MOSI needs to be in a certain state then this should be set beforehand ' Clock will simply pulse from it's starting state - normally low ' Useage: 0 SPIRD SPIRD SPIRD SPIRD 'read 32-bits as one long ' SPIRD ( data -- data<<8 ) ' 2.8us SPIRD mov spicnt,#8 ' always read back 8-bits SPIRDX andn outa,spice ' always activate the chip enable (saves time in HL) SPIrdlp xor OUTA,spisck ' toggle clock test spiinp,INA wc ' read data from device rcl tos,#1 xor OUTA,spisck ' toggle clock djnz spicnt,#SPIrdlp jmp unext \ loadable modules {HELP SDRD ( dst char -- firstPos charcnt \ read block from SD into memory while scanning for special char ) dst is a 32 bit SD-card address 0..4GB, char is the character to scan for while, reading in the block. NOTE: ensure MOSI is set as an output high from caller by 1 COGREG@ OUTSET This is just the low-level block read once the SD card has been setup, so it just reads a sector into the dst There is also a scan character that it will look for and return it's first position and how many were found } org _RUNMOD _SDRD mov X,tos+1 ' dst --> X mov R2,dst1 '$200 ' R2 = 512 bytes SDRDSClp mov R1,#8 ' 8-bits SDRDSCbits andn OUTA,sck ' clock low test miso,INA wc ' test data from device while clock is low rcl R0,#1 ' now assemble data (also setup time for mosi) or OUTA,sck ' clock high djnz R1,#SDRDSCbits andn OUTA,sck ' leave with clock low wrbyte R0,X ' write byte to destination and R0,#$FF ' only want to compare a byte value cmp R0,tos wz ' compare byte with char unsigned for equality if_z add ACC,#1 ' found one and increment count if_z cmp ACC,#1 wz ' if match and count = 1 (first occurrence) if_z mov tos+1,X ' then save dst (tos+2) to firstpos (tos) add X,#1 ' dst = dst+1 djnz R2,#SDRDSClp ' next call #POPX ' discard "char" jmp #PUSHACC ' push char count and clear ACC ' SD MODULE org _RUNMOD ' Write a block to the SD card - 512 bytes ' SDWR ( src cnt -- ;write block from memory to SD ) _SDWR or DIRA,mosi SDWRlp rdbyte R0,tos+1 ' read next byte from source add tos+1,#1 ' increment source address shl R0,#24 ' left justify mov R1,#8 ' send 8 bits SDWRbits andn OUTA,sck ' clock low shl R0,#1 wc ' assume msb first muxc OUTA,mosi ' send next bit of data out or OUTA,sck ' clock high djnz R1,#SDWRbits andn OUTA,sck ' leave with clock low djnz tos,#SDWRlp ' next byte jmp #DROP2What I was really interested in was whether Peter had written another interface, or used one of the existing 3 interfaces.
Unfortunately, all the pasm drivers use a different interface mechanism which makes swapping them a nightmare.