@Cluso99,
On the Sphinx project page mpark had C# console apps for file transfer, which can be used for GET/PUT on the PC. As you were saying in that thread, a simple checksum would be about the only thing that might be nice to add.
With a CONFIG.SYS and (eventually) batch support, Sphinx will be quite the little OS.
@Dr_Acula,
I think Oldbitcollector had implemented a form of XMODEM on his terminal program. It appears other protocols have already been implemented on the Prop already. Certianly a number of command-line file transfer utilities could be built, including a stand-alone GET and PUT.· I agree with Cluso99 that, due to complexity of some of the protcols (ZMODEM/Kermitt),·they should be stand-alone, and not built into the shell.
All: I think an XModem (or variant) would be great for SphinxOS as a standalone. GET & PUT will be there, but standalone, not inbuilt, just like DIR.
However, what I was thinking was if BradC was up to it, it would be a nice feature in bst to have the GET & PUT routines in there. This way we would have a minimal terminal program with file transfer built in to the IDE which runs on most platforms. By using the simple GET & PUT routine, anyone could embed it into their own spin/pasm programs. Xmodem is much more complex, so I wouldn't propose it could be embedded in anyone's programs.
Mike: That is great. Just need to add it as a SphinxOS aware program. I will discuss a little later with you once a few other things in SphinxOS are done. Perhaps you can liase with Drac with the problems he has found.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Interesting how it ends up shorter in Spin than in both Z80 assembly and vb.net. I know Cluso has said xmodem is really complex but that code shows it isn't all that difficult.
I guess for use in an operating system one would pass the name of the file you want to save it as?
This is the receive half. From memory the transmit half was easier to code. In CP/M xmodem is one program and you send it the filename and also 'R' or 'S' to receive or send. So it could be one program and you pass two parameters, or you could split it into two programs - a receive and a send.
@mpark: I found a bug in execute in sxfs2.spin where the filesize is checked against 32KB. It needs to also check the c flag. I have changed the load & clear to limit it to 56 * 512 = 28KB so that the upper hub is preserved. No check is made for larger programs so they will react abnormally.
Download the Sphinx1.zip file, extract·and copy to the microSD card.
Download and copy the sphinx.bin file to the microSD card.
Do not change the EEPROM. It·contains minimal boot code so it does not require to be changed.
AUTOEXEC.BAT is replaced which is set to automatically run SPHINX.BIN on powerup.
To run ZiCog from SphinxOS type "RUN ZICOG150". Note the ".BIN" is not required.
Sphinx is set (for now) to use the serial port to the pc with·a termial program.
The serial port is on P23 (rxd) and P22 (txd)
For other boards...
Download the Sphinx1.zip file, extract·and copy to the microSD card.
Download the sphinxos zip file
Edit the _hwdef.spin file with your hardware parameters
You can also change the CONstant OPTION = x in the SphinxOS_011c file if you want to try the 1-pin TV and 1-pin Keyboard out (you can use a board with normal TV and Keyboard connections - it will just ignore those extra pins). Note: This DOES NOT WORK on RamBlade as I have a keyboard timing bug with the xtal 6.5MHz (6MHz xtal is fine).
Compile SphinxOS_011c with PropTool, homespun or bst and save the binary
Now copy SphinxOS_011c.BIN to sphinx.bin (replacing it) on your SD card
Download and copy the sphinx.bin file to the microSD card.
You can program the EEPROM with SphinxOS_011c or
You can download the PropBoot_SD_V1-00 zp file and edit your hardware parameters and program into your EEPROM. This is the code I use in the RamBlade to boot from the SD card.
Now, for all boards...
SphinxOS·supports the following (for now)
DIR
COGCHECK
DEL
COPY
You will note that DIR.BIN and COGCHECK.BIN do not exist yet on your microSD. You need to compile and link them on your prop as follows...
At the Sphinx prompt SD> enter each of the following and wait until the prompt returns. This compiles and links the programs DIR, COGCHECK, DEL and COPY·on your RamBlade (cl stands for compile and link)··
cl dir
cl cogcheck
del
copy
Once done you can run both of these programs. At the prompt enter either
dir
cogcheck
copy autoexec.bat temp.txt
del temp.txt
You will see a directory of the files or the cogs that are busy and free.
These programs are using the drivers loaded by Sphinx, and will return to Sphinx after completion.
Note other programs do not work yet, such as ED (wip), ECHO (not sure why this one doesn't)
Many thanks to mpark for these great programs. Sphinx has a compiler written by mpark (author of homespun) which compiles on the Propeller. I have been adding features to SphinxOS (the operating system) section to support multiple drivers and make it more independent from the actual device.
Additional info...
When you want to run a program under SphinxOS (that uses the loaded drivers - 3 cogs for the SD drivers + 1 or more cogs for the I/O drivers.. pc=1, kbd=1, tv=1) you just enter "filename"·and it runs and should return to the OS when it completes (see DIR.SPN for an example of how it returns).
When you want to run a program, replacing SpinxOS (stopping all cogs) you enter "RUN filename". Currently ZiCog (v150) must be run this way.
Question...
Sphinx differentiates whether to run a program under sphinx by just entering the filename or terminate and run the program by entering run filename (standalone). It appends .BIN or .EEP to the filename. No other distinguishing feature is present. This leads me to question if we should identify the difference of there two types of files to save confusion. So, we do not know if FRED.BIN runs under sphinx or standalone.
How should we differentiate these two different filetypes? I have thought about using a different extension, say ".BIX" for sphinx programs, but this means we have to rename them after compilation. Further thoughts are that maybe we should just use a filename prefix of "_" for sphinx programs. This way, although we can then only really·use 7 character filenames, all such files would be grouped. So "DIR.BIN" would be "_DIR.BIN". This way the "RUN" command would be optional. If we entered "DIR" sphinx would first try to execute "_DIR.BIN" as a sphinx aware program, otherwise it would try "DIR.BIN" as a standalone program. (I have ignored ".EEP" files).
Please report any bugs or successes... Enjoy·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I'm a bit behind the times, still stuck on "classic" Sphinx, but I did find the longstanding bug in the file system that caused duplicate files. I don't know if fixing it will also fix the file corruption issue as I have not been able to repro the corruption.
I have rolled up all the little fixes since the original release and uploaded a new .zip archive to www.sphinxcompiler.com.
If you just want the duplicate file bug fix, it's the line marked "duh" in sxfs.spin:
I don't know anything about Windows 7, but what I would do is search for a file called csc.exe. I bet it's on there somewhere. Then open a command prompt and run "csc get.cs" and "csc put.cs" to produce get.exe and put.exe.
Hi Michael,
I did not find the isxkb.spn- file in your download archives.
This would be interesting, because ther is not so much doku....
Best regards
Christof
Comments
On the Sphinx project page mpark had C# console apps for file transfer, which can be used for GET/PUT on the PC. As you were saying in that thread, a simple checksum would be about the only thing that might be nice to add.
With a CONFIG.SYS and (eventually) batch support, Sphinx will be quite the little OS.
@Dr_Acula,
I think Oldbitcollector had implemented a form of XMODEM on his terminal program. It appears other protocols have already been implemented on the Prop already. Certianly a number of command-line file transfer utilities could be built, including a stand-alone GET and PUT.· I agree with Cluso99 that, due to complexity of some of the protcols (ZMODEM/Kermitt),·they should be stand-alone, and not built into the shell.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Game(s) Mythic Flight
Utilities Font Editors (AIGeneric, Potato_Text, etc.)
Post Edited (trodoss) : 2/23/2010 3:17:23 PM GMT
CON XM_soh = 1 ' Start of packet XM_eot = 4 ' End of transmission XM_ack = 6 ' Acknowledge XM_nak = 21 ' No acknowledge XM_can = 24 ' Cancel XM_pad = 26 ' Padding at end of file XM_init = 0 ' Initial Xmodem state XM_recv = 1 ' Actively receiving file XM_done = 2 ' Finished receiving normally VAR byte xbuf[noparse][[/noparse]128] PRI xmodemRecv | crc, pktNum, mode, temp, retry, addr, i pktNum := 1 retry := 0 mode := XM_init repeat 80 ' Wait for Xmodem to start ser.tx(XM_nak) if ser.rxtime(250) == XM_soh mode := XM_recv quit addr := 128 repeat while mode == XM_recv crc := 0 ' Open the file to receive temp := ser.rx if temp < pktNum-1 or temp > pktNum mode := XM_init quit pktNum := temp if ser.rx ^ pktNum ' Check 1's complement packet # mode := XM_init quit repeat i from 0 to 127 ' Get packet temp := ser.rx crc += temp ' Accumulate CRC xbuf[noparse][[/noparse] i ] := temp if ser.rx <> crc ' Check CRC if retry++ < 10 ser.tx(XM_nak) repeat if ser.rx == XM_soh ' Check for new packet quit else mode := XM_init ' Too many retries quit else fsrw.writeFile(@fcb,@xbuf,128)' Write the packet pktNum++ addr += 128 ser.tx(XM_ack) repeat case ser.rx XM_eot: ser.tx(XM_ack) waitcnt(clkfreq/10 + cnt) ' Wait 100ms ser.tx(XM_ack) mode := XM_done quit XM_can: mode := XM_init quit XM_soh: quit if mode == XM_done repeat temp from 127 to 0 ' Trailing padding? if xbuf[noparse][[/noparse]temp] <> XM_pad quit addr -= 127 - temp ' Adjust total length return addrIt uses a simple checksum even though there's a CRC variable. The return value is the length of the file received.
However, what I was thinking was if BradC was up to it, it would be a nice feature in bst to have the GET & PUT routines in there. This way we would have a minimal terminal program with file transfer built in to the IDE which runs on most platforms. By using the simple GET & PUT routine, anyone could embed it into their own spin/pasm programs. Xmodem is much more complex, so I wouldn't propose it could be embedded in anyone's programs.
Mike: That is great. Just need to add it as a SphinxOS aware program. I will discuss a little later with you once a few other things in SphinxOS are done. Perhaps you can liase with Drac with the problems he has found.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 2/23/2010 9:05:02 PM GMT
Interesting how it ends up shorter in Spin than in both Z80 assembly and vb.net. I know Cluso has said xmodem is really complex but that code shows it isn't all that difficult.
I guess for use in an operating system one would pass the name of the file you want to save it as?
This is the receive half. From memory the transmit half was easier to code. In CP/M xmodem is one program and you send it the filename and also 'R' or 'S' to receive or send. So it could be one program and you pass two parameters, or you could split it into two programs - a receive and a send.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
What is the norm for initiating an xmodem transfer, the sender or the receiver? Or can either?
Possibly in SphinxOS it would be one program and you would do..
XMODEM S,filename
else as seperate programs
XMODEMS filename
What do you think?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
C flag? Why?
For RamBlade...
For other boards...
Now, for all boards...
SphinxOS·supports the following (for now)
You will note that DIR.BIN and COGCHECK.BIN do not exist yet on your microSD. You need to compile and link them on your prop as follows...
Many thanks to mpark for these great programs. Sphinx has a compiler written by mpark (author of homespun) which compiles on the Propeller. I have been adding features to SphinxOS (the operating system) section to support multiple drivers and make it more independent from the actual device.
Additional info...
When you want to run a program under SphinxOS (that uses the loaded drivers - 3 cogs for the SD drivers + 1 or more cogs for the I/O drivers.. pc=1, kbd=1, tv=1) you just enter "filename"·and it runs and should return to the OS when it completes (see DIR.SPN for an example of how it returns).
When you want to run a program, replacing SpinxOS (stopping all cogs) you enter "RUN filename". Currently ZiCog (v150) must be run this way.
Question...
Sphinx differentiates whether to run a program under sphinx by just entering the filename or terminate and run the program by entering run filename (standalone). It appends .BIN or .EEP to the filename. No other distinguishing feature is present. This leads me to question if we should identify the difference of there two types of files to save confusion. So, we do not know if FRED.BIN runs under sphinx or standalone.
How should we differentiate these two different filetypes? I have thought about using a different extension, say ".BIX" for sphinx programs, but this means we have to rename them after compilation. Further thoughts are that maybe we should just use a filename prefix of "_" for sphinx programs. This way, although we can then only really·use 7 character filenames, all such files would be grouped. So "DIR.BIN" would be "_DIR.BIN". This way the "RUN" command would be optional. If we entered "DIR" sphinx would first try to execute "_DIR.BIN" as a sphinx aware program, otherwise it would try "DIR.BIN" as a standalone program. (I have ignored ".EEP" files).
Please report any bugs or successes... Enjoy·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 2/25/2010 7:13:13 AM GMT
I'm a bit behind the times, still stuck on "classic" Sphinx, but I did find the longstanding bug in the file system that caused duplicate files. I don't know if fixing it will also fix the file corruption issue as I have not been able to repro the corruption.
I have rolled up all the little fixes since the original release and uploaded a new .zip archive to www.sphinxcompiler.com.
If you just want the duplicate file bug fix, it's the line marked "duh" in sxfs.spin:
mov q, pFilename ' matching filename? Done. mov n, #11 call #ByteComp if_e mov sopDir, sop ' 2010-02-23 duh if_e jmp #:quitquestion:
What exactly must I do to run get.cs and put.cs with windows7?
Thank you very much!
Christof
Great thing, Sphinx!
Christof
I did not find the isxkb.spn- file in your download archives.
This would be interesting, because ther is not so much doku....
Best regards
Christof
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz