Have the command modules (DIR & LS) working and the CMD module is setting up hub and passing the SD pins, serial pins+mode+baud, and the state of <lf>, and of course the command parameters. I have implemented toggling for linefeed because some terminals require it to follow <cr> and some dont. Now, its a simple matter to get all the KyeDos commands into separate modules. Makes the modules very simple, so anyone can add commands easily. Modules will be called "_XXXXXXX.CMD" so DIR becomes "_DIR.CMD". The command input module is "_CMD.CMD" and all modules return to this after completing their job.
Here is a code update...
The boot program is _DOS.BIN
All commands are _xxx.CMD
_copy and _diff do not work and I have not tried _format. _unmount reports an error.
Source is included.
Anyone wishing to try will need to edit _DOS, _hwdef, Hardware_Detect and recompile all (because I use a 6.5MHz xtal - sorry)
_DOS calls _VER and then calls _CMD. Almost all modules call _CMD when done. Drivers do not stay resident yet, but $7000-$7FFF hub is not cleared on new binaries.
External commands ver, help, mount, free, used, ls, dir, cat, test all work from limited testing.
Basically, all code is derived from KyeDOS3 by Kye & Drac - thanks guys! _DOS3_10.zip
I now have the os broken down into a lot of binary (.CMD) modules and by using Andy's PreSpin and an include file, each dos module is as simple as a subroutine in most instances. There is one main binary that sets up the hub and stdio resident cog driver. All other modules are loaded as required, such as dir. It is easy to add new modules. Only the main module determines the hardware and clock speed. My main module can automatically detect my hardware and it is easy to modify and recompile for other hardware configs.
I have modified Kyes sd driver so that it does not totally clear to the top of hub, as determined by the _hubFree long located at $7FFC. I also keep a cog map so that resident driver cogs are not reset. This all is working now when loading modules. I am just using the serial port atm, but the driver can be replaced with tv or vga and keyboard without recompiling any modules (except the main dos module for now).
The help command is a module that displays _help.txt file, so it is easy to edit for adding more commands. Then just add a new command file as a .cmd beginning with "_".
' OS Hub Definitions...
_HubFree = $7FFC ' 4 ' \ stores total hub available (typ $7800)
' | (hub is allocated to the OS above this value)
' / (eg $7000 means $0000-$6FFF is available)
' ' \ os runtime configuration parameters
_OS_COGS = $7FFB ' 1 ' | b24-31: 1= stay resident cogs (don't stop on reboot)
_OS_CLKMODE = $7FFA ' 1 ' | b23-16: saved clkmode hub byte $0004
_OS_BITS = $7FF9 ' 1 ' | b08-15: runtime config bits
_OS_LFmask = $80 ' | b15: 1= <lf> ON; 0= strip <lf>
_OS_UNDEF = $7FF8 ' 1 ' / b00-07: undefined
_OS_CLKFREQ = $7FF4 ' 4 ' saved clkfreq hub long $0000
_SDpins = $7FF0 ' 4 ' \ sd pins packed 4 bytes
' ' / Byte 3=/CS, 2=DI, 1=CLK, 0=DO
_SIOpins = $7FEC ' 4 ' \ serial pins and mode settings (and cog#)
' ' / Byte 3=cog, 2=mode, 1=SO, 0=SI
_SIObaud = $7FE8 ' 4 ' serial baud (speed typ 115,200)
_StdIn = $7FE4 ' 4 ' standard input rendezvous
_StdOut = $7FE0 ' 4 ' standard output rendezvous
_AuxIn = $7FDC ' 4 ' auxilary input rendezvous
_AuxOut = $7FD8 ' 4 ' auxilary output rendezvous
_User1 = $7FD4 ' 4 ' user 1 rendezvous
' _User2 = $7FD0 ' 4 ' user 2 rendezvous
_Hardware = $7FD0 ' 4 ' \ hardware: hi-word=company, lo-word=config
' | $0001 = Cluso99 $0001 = RamBlade 1
' | $0001 = Cluso99 $0002 = TriBlade#2
' / $0001 = Cluso99 $0003 = RamBlade3
_OSreserved = $7F80 ' 80 ' undefined (maybe serial in and serial out buffers?)
_StringBuffer = $7F00 ' 128 ' general purpose string buffer
_CogTables = $7E00 ' 256 ' \ 8*32B cog usage tables
' | TBD
' | Current thinking is...
' | 1 byte for "type"
' | 1 long for sector address to retrieve filename
' | However, could also be used as 2*16byte buffers
' / with the head+tail(s) kept in _StdIn & _StdOut
_SDbuffer = $7C00 ' 512 ' SD card i/o buffer
_SpinVector = $7800 ' 1024 ' vector table for Cluso's faster spin interpreter
_SetHubFree = $7800 ' $7800-$7FFF currently reserved by the OS
You will note I take 2KB off the top, leaving 30KB to the user program. I have allocated 1KB for my vector table I use in my faster spin interpreter. I am planning to use this shortly here, so I needed to reserve the 1KB for the vectors and they must be located on a 1KB boundary.
I have most modules working now. The hardware (pin definitions and xtal/pll) is only changed in the _hwdef.spin file, and only the OS.spin is required to be recompiled. I automatically check for a RamBlade/RamBlade3/TriBlade#2. I know it is possible to check for others, but probably not all. The other modules (such as DIR, COPY, etc) do not need recompiling for a change of hardware (pins, xtal, etc).
I did look at the great job Dave has done with Spinix. But to me, I wanted more of a DOS feel rather than unix. Because we are using different naming conventions, it should be possible to call each others OS. I already do this between PropCMD and CPM/ZiCog.
Looking good. I like the idea that your modules do not need recompiling when you change the hardware/pins.
DIR and COPY imply an SD card (or other mass storage) is fairly integral to the system. Does this mean the SD driver has to be part of the OS?
I just did a quick F8 on Kye's SD driver and it takes 2116 longs, or just over 1/4 of memory. Can you save 496 longs by preloading the SD cog driver?
And also all programs need an SD buffer so where this would normally be in the program, you have it in high ram, so you can 'reclaim' 512 bytes (128 longs) there as well.
Is a RTC part of the OS? If yes, do you need some longs reserved for the time and date? And if not, well, the RTC part of Kye's SD driver takes 188 longs and I must say I've hardly ever used this so maybe you can have the option to compile without RTC support and save a little memory there?
I presume you are preloading keyboard, serial, display drivers into cogs at startup, and so saving all that hub space for your main program?
I like the idea of displaying a help.txt file. That saves memory compared with Kyedos where the help messages are all part of the program.
Drac: Currently, there is no resident spin or cog code. But 1 cog is loaded with a serial driver. That can be replaced with 2+ cogs for TV/VGA/LCD and Keyboard/Mouse/touchscreen (i.e. any standard output and input routines. The resident cogs stay running between module loads. The kernel (if you want to call it that) is in _CMD.CMD and that is reloaded each time a module completes. Kyes code currently is in each module, so the module can be trimmed of unused methods. I plan to keep the sd driver cog loaded, and to replace it with the faster lonesock fsrw code later too.
Last night I had another look at Sphinx to see what is required there to become part of the picture. Its DIR command takes care of the ? and * parameters in the filenames, so this needs to be put into the primitive DIR command of KyeDos.
I really require the file transfer working. Michael Park has sent me the C code and exe for the PC end. It is a way simple ftf protocol.
The other part I need to get running is the RUN command - where a new binary is loaded to take over the whole prop.
Each of these are simple tasks on their own, but add up in my limited time.
You asked about loading the cogs up with drivers. Yes, they will be loaded from sd and into the cog so no space is wasted once loaded. As it stands atm I could reload the cog(s) to use keyboard and tv without any changes to the OS.
As for messages, I plan to use a disk file to store them. No wasted hub space! Use a lookup table and an error number - this is how we saved space on the minis years ago.
Drac - want to help? I've attached code in anticipation. Just edit _hwdef.spin (clock and pin numbers) and recompile _os.spin (with PropTool only, no PreSpin required for this module) to _OS.BIN You can place _OS.BIN into EEPROM.
Note only the pc is running here atm. Use PST on the pc end. If you want to use another terminal program, you may need to give the command "toggleLF" (case unimportant) to turn LF on or off. Type "ver" to get hardware info. Hel is designed to use the _HELP.TXT file so that any additions can be easily added without recompiling help.spin (I was playing with that so not sure where this is at atm). PropOS_20120324.zip
Last night I had another look at Sphinx to see what is required there to become part of the picture. Its DIR command takes care of the ? and * parameters in the filenames, so this needs to be put into the primitive DIR command of KyeDos.
Sounds a good idea. eg one thing I found when we went from the VGA to the TV version of Kyedos was that the DIR command had to be rewritten as it went from 80 to 40 cols. In your system, DIR could find out from your operating system what sort of display it had, and then adjust the number of filenames per row to suit.
At work at the moment - will check your code when I get home. Your file transfer program sounds good. I used xmodem but it could be automated more, particularly at the PC end where you could have a list of files and you could send one or many, and even do things like ask the propeller for a file list which then displays on the PC program.
Just to throw a spanner in your works, xmodem (and probably other file transfers) work quicker if the code is part of the operating system, because if the code is a separate program you have to wait for the new program to load. Only adds another couple of seconds though.
Yes, the OS needs to know the number of rows and columns, no matter what interface is used. I expect DIR to ultimately take care of this. Perhaps I will leave LS to do this so that I always have a crude DIR available until everything works fine.
The modules are loading way quicker than that! Even with the 100ms inbuilt delay to ensure all i/o buffers are cleared you cannot notice any delay. Once you start the transfer, it should be quick at 115200 baud! Michaels routine is quick and simple with an easy CRCC. Only useful for direct connections though.
Forgot before. RTC: I think the idea is to read the RTC if it exists, and then use one of the props counters to maintain the time from there on. If there is no RTC, then it should get the last time/date from a file, increment by 1 second and overwrite, display the time. The user can then choose to change this by an OS command. The OS should be able to support a number of RTC chips. So yes, we need a hub location for date/time, or else a system call to get the latest date/time (only needs to be accurate to seconds).
Here is a revised layout (not implemented yet because we will no doubt find more we need to specify). Added _OS_SECONDS and _OS_ROWS and _OS_COLUMNS for the screen sizes (for display purposes).
' OS Hub Definitions...
' ------------------
_HubFree = $7FFC ' 4 ' \ stores total hub available (typ $7800)
' | (hub is allocated to the OS above this value)
' / (eg $7000 means $0000-$6FFF is available)
_OS_COGS = $7FFB ' 1 byte ' stay resident cogs: 1= don't stop on reboot
_OS_CLKMODE = $7FFA ' 1 byte ' clkmode: saved fm hub byte $0004
_OS_ROWS = $7FF9 ' 1 byte ' \ combined <lf> and rows
_OS_LFmask = $80 ' | b7 : 1= <lf> ON; 0= strip <lf>
_OS_ROWmask = $7F ' / b0-6: no of rows on screen (0-127)
_OS_COLUMNS = $7FF8 ' 1 byte ' no of cols on screen (0-255)
_OS_CLKFREQ = $7FF4 ' 4 ' clkfreq(Hz): saved fm hub long $0000
_OS_SECONDS = $7FF0 ' 4 ' seconds since 1Jan2000 00:00:00 (ok to yr2100/2132)
_SDpins = $7FEC ' 4 ' \ sd pins packed 4 bytes
' ' / Byte 3=/CS, 2=DI, 1=CLK, 0=DO
_SIOpins = $7FE8 ' 4 ' \ serial pins and mode settings (and cog#)
' ' / Byte 3=cog, 2=mode, 1=SO, 0=SI
_SIObaud = $7FE4 ' 4 ' serial baud (speed typ 115,200)
_Hardware = $7FE0 ' 4 ' \ hardware: hi-word=company, lo-word=config
' | $0001 = Cluso99 $0001 = RamBlade 1
' | $0001 = Cluso99 $0002 = TriBlade#2
' / $0001 = Cluso99 $0003 = RamBlade3
' ^^^ may be more valuable for something else??
_AuxIn = $7FDC ' 4 ' auxilary input rendezvous
_AuxOut = $7FD8 ' 4 ' auxilary output rendezvous
_StdIn = $7FD4 ' 4 ' standard input rendezvous
_StdOut = $7FD0 ' 4 ' standard output rendezvous
_OSreserved2 = $7FC0 ' 16
_OSreserved = $7F80 ' 64 ' undefined (maybe serial in and serial out buffers?)
_StringBuffer = $7F00 ' 128 ' general purpose string buffer (maybe 2*64?)
_CogTables = $7E00 ' 256 ' \ 8*32B cog usage tables
' | TBD
' | Current thinking is...
' | 1 byte for "type"
' | 1 long for sector address to retrieve filename
' | However, could also be used as 2*16byte buffers
' / with the head+tail(s) kept in _StdIn & _StdOut
_SDbuffer = $7C00 ' 512 ' SD card i/o buffer
_SpinVector = $7800 ' 1024 ' vector table for Cluso's faster spin interpreter
_SetHubFree = $7800 ' $7800-$7FFF currently reserved by the OS
I had thought to add a long for the Screen (pinbase, pinmask, and cog(s)) but I think this can be done without using hub. Once set, we don't require it anymore. Same really applies to SD and SIO. Will need to have a config file on SD.
This question is slightly off topic - but vaguely relevant as you did mention hardware config in a text file, and I don't think you have a text editor yet, and we do have a number in CP/M, and you did mention getting the zicog working.
Ok, CP/M was so vague about its disk formats that there ended up being so many formats that none of them worked with each other. I note your comments earlier about moving files between CP/M and SD cards. Is there any reason we have to use the CP/M format at all?
Consider a Zicog emulation, or even a real Z80 interfaced to a propeller. CP/M abstracts the disk I/O to things like - "open a file", "close a file", "give me record n which is 128 bytes", or "write record n".
This seems remarkably similar to Kye's SD card driver. So if CP/M requests a particular record from a particular file, it will not know or care where this came from. Pass this request to Kye's SD driver and fetch the record.
If you want a disk full of CP/M files, use the SIMH W and R commands to move a group of files to a PC directory. Then copy onto an SD card.
Is there a catch?
If this works, would it not also make CP/M even smaller as the CP/M FAT allocation etc would not be needed.
This could certainly work. You would need a desktop utility program that transfers files between an SD card formatted as FAT16 or FAT32 and a CP/M disk image as used in the various CP/M archives and emulators.
I am unsure of what programs access CPM disks directly. The cpm disk structure is published and I used this to work out the file transfers between CPM and FAT and I use Kyes routines for this. I have CPM to FAT working properly, but the reverse is not quite debugged (need to complete the writing of the file headers to the directory structure).
I have all the common CPM disk files and I have already converted them into a CPM structure for each disk as a FAT file. That is how ZiCog works... 8x FAT files for 8x hard disks of 8MB. The disk table specifies the no of sectors and sizes and layouts of the clusters. I created these disk/fat files originally using a VB6 program I wrote, so no problems there.
BTW I am switching between ZiCog/CPM and the OS anyway, although I just created a bug and it stopped working.. oops! Postedit: Cheated... just added in the old object atm. Its working going back and forth between this OS, ZiCog, Sphinx, Catalina and Spinix.
Drac: Perhaps you could ask on the N8VEM forums whether anyone has tried to use a FAT format for CPM? (lost my access some time ago)
It uses Homespun to compile (included) and OS.BAT will compile all modules.
Windoze: Copy to a single folder and double click on OS.BAT and it will compile all modules.
Normally you will need to change the _HWDEF.SPIN file for your hardware and xtal/clock as I overclock and often forget to put it back.
This version has been compiled for 5MHz PLLx16, serial to PC on P31/30 & 115,200 baud, and SD on pins 0,1,2,3 but is untested since recompiling. Just copy *.CMD files to the SD card root directory. If you wish, program the _OS.CMD file into eeprom (it is a standard prop binary - you can copy to _OS.binary or _OS.eeprom and use PropTool to download to your eeprom.
Here is the latest update. GET (from the prop) and PUT (to the prop) does file transfers. At 115,200 baud, the maximum transfer speed is 1MB per 2 mins (0.5MB/minute), but this is slower to allow for turnaround times and outputting an update to the pc screen.
The VB6 program does the file transfer on the PC and also makes a mini terminal program on the pc. It is currently coded for COMM4 which I set within XP for my propplug. This is a crude VB6 program, but the transfer works reliably with 8MB files each way (around 45 mins for now - I started and left it running).
For the boot program in the eeprom, I just program _OS.CMD into the eeprom (you can use the older _OS.binary if you wish - it still works fine). My version is set to compile for 6.5MHz, so you will need to change this (sorry I forgot when I zipped this on my other laptop). For the SD card, you will need to copy the files *.cmd files (and preferably *.txt too).
To compile, setup a dos window, navigate to the source subdirectory, and run the batch file os.bat. I have included the homespun compiler. Note in reality, only the _os.cmd file needs to be recompiled for a new platform.
For file transfers, the files need to exist on the prop as I have not fixed the bug that requires the file to preexist even when receiving.
I also found that the copy command does not work. Have not had time to check it out yet.
Code into the boot eeprom/base/boot code a text editor that is an option native, similar to hitting the F1 or ESC key to get into the bios. Original XT platform had a eerpom that stored basic editor.
Then all origial code, spin/asm files can be included in with the complete complie as a DAT attachment (if enough space is found)
Obviously this isn't powerfull if that same text editor dosen't complile the spin/asm file.
Has anyone made a prop spin/asm editor that runs on the prop?
Or even a compiler that can complile spin/asm files on the prop?
There are a couple of simple editors that various people have done. I don't know where they are up to.
Michael Park wrote a compiler for the prop under his OS called Sphinx. He also wrote homespun (which I use to compile this OS). I have not had the time to make it use the newer Kye SD access. However, Sphinx could be called from my OS, and Michael wrote a minimal editor as well.
I wonder whether anyone would consider adding xmodem file transfers to their Spin editor?
Of course, there are lots of other options but xmodem is very simple - 128 byte packets and a single checksum and a one byte acknowledge/negative acknowledge.
It would be up to the program on the propeller what it does with the data - puts it into eeprom, onto an sd card, to external ram or to another propeller. The PC side of the program need not worry about that - all it needs to do is talk the xmodem protocol.
I've written vb.net code to do this and vb6 code is pretty simple too.
I'm going to approach the problem from the opposite angle and write a simple spin editor for the PC with xmodem, which I think is exactly where cluso99 is with post #46. I'll then probably use the command line BST or homespun to do the compilation.
But I wonder if any of the spin editor authors would consider adding this? If there was concern about clutter on the menu, maybe have a box in 'advanced options' to turn on the menu item.
I don't think we have an open source spin editor, right?
No it is in spin. I guess it draws on other pasm routines in from the serial driver object, but basically it polls the serial input, collects the bytes, does a checksum and then sends packets to the SD card object.
Could you post your xmodem spin implementation please? Are you using the CSUM 8 bit or CRC 16 bit?
BTW my intention is that whatever I/O driver(s) are used, they can e dynamically loaded/unloaded/reloaded. It is not all implemented yet, but it wiould not take too long to do. Currently, it is just one file that needs recompiling.
Because all the modules (OS commands) are located in their own binaries (called *.cmd), they can be added simply, and do not take valuable hub space.
Sounds like you are onto something clever. There are always optimisations - eg if you have TV and VGA in the same program, the pasm part of both obex objects can always be compiled separately and loaded off an SD card and into the cog and hence save code space.
I like the idea of just one file to compile. That is very clever.
Re xmodem, see the attached spin code in a zip. For kyedos, one might type XMODEM R MYFILE.TXT and then it runs the program XMODEM.EXE and that program loads the file COMMAND.TXT which is the line of text XMODEM R MYFILE.TXT and which can parse that complete command line. This way any number of command line parameters can be passed to the next program.
One question I must test one day - if a propeller chip reboots, does the ram get erased or does it stay static? If the latter, then the line of text to pass between programs could stay in high ram rather than be stored on the SD card.
This is the code from the PC end in vb.net. Xmodem in itself is a simple protocol, but it does take quite a bit of real world testing to get all the timing right, particularly with error recovery.
Sub XModemKyeSend(ByRef FName As String, ByVal Delay1 As Integer)
Dim Filenamepath As String
Dim a, j, i As Integer
Dim k As Integer
Dim LineOfText As String
Dim SerialString As String
Dim Counter As Integer
Dim ErrorString As String
Dim Packetnumber As Integer
Dim Checksum As Long
Dim OnesComplement As Byte
Dim ByteRead As Byte
Dim BinaryFileLength As Long
Dim BinaryFileCounter As Long
Dim Percent As Single
Dim ErrorCounter As Byte ' 0 to 10
Dim CPMFilename As String
Dim Timeout As Boolean
ProgressBar1.Maximum = 100
ProgressBar1.Minimum = 0
' timer restart =true for sending via menu. False for auto send
Filenamepath = FName
Packetnumber = 1 ' 1 for the first packet (not zero)
' Try
Dim Input As New FileStream(Filenamepath, FileMode.Open, FileAccess.Read)
Dim br As New BinaryReader(Input)
OpenSerialPort() ' open the serial port
Label3.Text = "Error Count"
Label2.Text = "0%"
BinaryFileLength = br.BaseStream.Length() - 1
'i = Len(Filepath) + 1 + 1 ' eg c:\n8vem and a \ = 9 and 1 more for start of name only
Call Get_CPM_Filename(Filenamepath, CPMFilename)
CPMFilename = Strings.UCase(CPMFilename)
LineOfText = "XMODEM R " + CPMFilename + vbCr
Call StringToPacket(LineOfText) '
Call ClearInputBuffer() ' clear the buffer into the PC
For i = 1 To Delay1 ' 50 for kyedos need to wait for kyedos to run the xmodem program
Sleep(100) ' wait for the xmodem text to come back so the next one is a 21
Label3.Text = Str$(i)
Call ClearInputBuffer() ' clear the buffer into the PC
Next i
Call ClearInputBuffer() ' clear the buffer into the PC
Do
SerialString = ""
If SerialPortFound = True Then
If SerialPortName.BytesToRead > 0 Then
SerialPortName.Read(InPacket, 0, 1) ' get one byte
SerialString = Chr(InPacket(0)) ' get a single character/string/byte
End If
End If
If InPacket(0) = 21 Then
ErrorString = "NAK"
Exit Do ' got a ^U
End If
If SerialString <> "" Then
'LineOfText = SerialString
'Call TextLines(LineOfText) ' print it out unless it is a chr21
End If
Counter = Counter + 10
Sleep(10) ' don't change this one - this is waiting for NAK
Label1.Text = "Waiting for NAK to start" + Strings.Str(Counter) + "ms" ' display in milliseconds
System.Windows.Forms.Application.DoEvents() ' update the label1 message
' add a counter and timeout if nothing
If Counter > 5000 Then
ErrorString = "Bypass wait for NAK - xmodem failed"
Exit Do
End If
If ErrorString <> "" Then Exit Do
Loop
Label1.Text = ErrorString
System.Windows.Forms.Application.DoEvents() ' update the label1 message
Do
' act on each byte in the buffer array here
XOut(0) = 1 'SOH ^A
XOut(1) = Packetnumber
OnesComplement = 255 - Packetnumber
XOut(2) = OnesComplement
Packetnumber = Packetnumber + 1
If Packetnumber > 255 Then Packetnumber = Packetnumber - 256
Checksum = 0
For i = 0 To 127 ' get 128 bytes from file
If BinaryFileCounter <= BinaryFileLength Then
ByteRead = br.ReadByte ' get a byte
Else
ByteRead = 26 ' pad with char 26 = hex 1A because hyperterm does this ? why but it works
End If
XOut(i + 3) = ByteRead
Checksum = Checksum + ByteRead
BinaryFileCounter = BinaryFileCounter + 1
Next
' create checksum
Do
If Checksum < 256 Then Exit Do ' work out checksum
Checksum = Checksum - 256
Loop
XOut(131) = Checksum
Call OutputXout()
System.Windows.Forms.Application.DoEvents() ' update the label
Timeout = False
Do
k = 0
Do
If SerialPortFound = True Then
j = SerialPortName.BytesToRead
End If
If j >= 1 Then
If SerialPortFound = True Then
SerialPortName.Read(InPacket, 0, 1) ' get one byte
End If
Exit Do
End If
k += 1
If k > 5000 Then
Timeout = True ' 5 second delay for timeout, must be more than the Rx side timeout
Exit Do
End If
Sleep(1) ' 1ms delay
Loop
If InPacket(0) = 6 Then Exit Do ' remote got the packet so exit
If InPacket(0) = 21 Then
' remote didn't get it so try sending again - does up to 10x
ErrorCounter = ErrorCounter + 1
Call ClearInputBuffer() ' clear the input buffer to the PC
Sleep(1000) ' let the remote get itself sorted before resending the packet
Call OutputXout() ' resend the packet
Label3.Text = "Nak: " + Strings.Str(ErrorCounter)
System.Windows.Forms.Application.DoEvents() ' update the label
End If
If Timeout = True Then
Label3.Text = "Timeout waiting for Ack"
ErrorCounter = 20 'force an exit now
System.Windows.Forms.Application.DoEvents() ' update the label
End If
If ErrorCounter >= 10 Then Exit Do ' more than 10 errors
Loop
If ErrorCounter >= 10 Then
Label1.Text = "10 or more errors - aborting"
Label2.Text = "0%"
OutPacket(0) = 24 ' send a ^X cancel
If SerialPortFound = True Then
SerialPortName.Write(OutPacket, 0, 1) ' send 1 byte
OutPacket(0) = 3 ' send a ^C
SerialPortName.Write(OutPacket, 0, 1) ' send 1 byte
End If
Exit Do
End If
If BinaryFileCounter > BinaryFileLength Then Exit Do ' finish up
Label1.Text = "Sent packet: " + Strings.Str(Packetnumber) + " = OK"
Percent = BinaryFileCounter / BinaryFileLength
Percent = Percent * 100
Percent = Int(Percent)
Label2.Text = Strings.Str(Percent) + "%"
ProgressBar1.Value = Percent
Loop
If ErrorCounter < 10 Then
OutPacket(0) = 4 ' finish byte
If SerialPortFound = True Then
SerialPortName.Write(OutPacket, 0, 1) ' send 1 byte
End If
Label2.Text = "100%"
Label1.Text = "Finished"
ProgressBar1.Value = 0 'done
Call StringToPacket(vbCrLf) ' back to kyedos
End If
Input.Close()
Sleep(200) ' wait for next file
System.Windows.Forms.Application.DoEvents() ' update the labels
'Catch ex As Exception
' Close()
' Label1.Text = Filenamepath + " not found"
' System.Windows.Forms.Application.DoEvents() ' update the labels
' Sleep(1000) ' so time to read message
'End Try
SerialPortName.Close() ' close the serial port
End Sub
One question I must test one day - if a propeller chip reboots, does the ram get erased or does it stay static? If the latter, then the line of text to pass between programs could stay in high ram rather than be stored on the SD card.
Depends on how you reboot.
A normal reboot reloads the ram from eeprom. Not sure if there is no eeprom. If it is downloaded then the remainder of hub is cleared IIRC.
You can simulate a reboot by stopping all other cogs, loading hub (from SD or wherever) including limiting the hub reload if you wish (this is how I keep the upper hub intact), then stopping any other cogs, and lastly restarting cog 0 (and stopping the current cog if it is not 0). Of course, there may be other side effects of not clearing everything that a proper reboot does, but I don't think there is anything that matters.
BTW Thanks for the xmodem code. I was looking at the specs last night. It is quite a bit simpler than I thought. I've done BiSync and SDLC back in the 80's, so this is simple. Thinking further, it can be in spin although it will be slower. Just need to put it into it's own OS command module. Postedit: Yes, it will be simple to make and xmodem module for this OS.
Update:
Here is the latest code. Note I have only included the compiled version of the MAPCPM.CMD for now (not it's source). If you compile all files using OS.BAT, remember to save MAPCMD as it will be deleted in the compile process! As normal, you only need to modify _HWREF.SPIN for your xtal freq/mode and SD pinouts and recompile _OS.SPIN which will produce _OS.CMD and _OS.BIN (identical files).
Depending on how you boot to PropOS... _OS.BIN can be programmed into your eeprom, or if you use the older and simpler boot program, then copy _OS.BIN to PROPBOOT.BIN, or change AUTOEXEC.BAT to run _OS.CMD.
cat cat <filename> ' Display the contents of a file (see TYPE)
cmd --- ' Internal use (the command interpreter)
copy copy <source_filename> <destination_filename> ' Copies a FAT16/32 file
diff diff <filename1> <filename2> ' Displays file differences
dir dir [options] ' Displays a directory of files (see DIRW, LS)
dirw dirw [options] ' Wide version of DIR
format format ' WARNING Don't use: reformats SD card (untested)
free free ' Displays FAT16/32 free space info (see USED)
getcpm getcpm <cpm_diskname> <cpm_filename> <fat_filename> ' Get (copy) a file from CPM to FAT16/32
help help ' Display help info (not uptodate)
ls ls [options] ' Displays a directory of files (see DIR, DIRW)
mapcpm mapcpm <cpm_diskname> [<cpm_filename> [-d]] ' Maps info about the CPM filesystem
mount mount ' Mount the FAT16/32 filesystem (see UNMOUNT)
os --- ' The PropOS binary file loaded to run PropOS
putcpm putcpm <fat_filename> <cpm_diskname> <cpm_filename> ' Put (copy) a file from FAT16/32 to CPM
testsd testsd ' Program to test te SD card (writes to the SD)
type type <filename> ' Display the contents of a file (see CAT)
unmount unmount ' Unmount the FAT16/32 filesystem (see MOUNT)
used used ' Displays FAT16/32 free space info (see FREE)
ver ver ' Displays info about PropOS including version
To RUN any Propeller Binary (replaces the OS completely) just enter the binary filename at the command prompt...
z3_173fx z3_173fx ' Will run ZiCog RamBlade3 V173 binary
' ..Entering HALT at the CPM prompt will reboot the prop
To recompile for your hardware, edit _HWDEF and change pinouts and clock frequency, and run the batchfile HW.BAT hw.zip
rem edit _hwdef for your hardware and clock frequency
rem _os.bin can be programmed into your eeprom to boot this os directly
rem no other modules need to be re-compiled
rem
del _os.cmd
del _os.bin
homespun _os
rename _os.eeprom _os.cmd
copy _os.cmd _os.bin
New OS commands: REBOOT, MAPCPM and DIRCPM (GETCPM and PUTCPM still to come).
TYPE replaces CAT.
Many of the commands now display their usage by typing just their command without parameters. eg COPY.
A number of errors are now checked, and information details are displayed.
The boot OS program will also be compiled to EEPROM_L.BIN so you can program this into your eeprom. (rename it EEPROM_L.BINARY for PropTool)
The default hardware is defined in _hwdef.spin so change your xtal frequency, pll mode, and pinouts here, and then compile just the _OS.spin file using hw.bat (note I use 6.5MHz xtal, so you need to change this).
The OS is can automatically detect RamBlade (aka RamBlade1), TriBlade, and RamBlade3 hardware, else it defaults to normal with serial on P30/31 and SD on P0..3.
Unfortunately I have not been able to get this OS to work with the current boot code shipped in the RamBlade. You will need to re-program the eeprom with EEPROM_L.BIN (or recompile and download _OS.spin with PropTool). I am working on a program that will do this from the SD card and will post this when I have it working.
Latest update V0.75 including many tweeks and fixes...
This is the 6.5MHz compiled version (for Ramlade/TriBlade#2/RamBlade3 or other overclocked boards) PropOS_075_6-5MHz.zip
and here is the 5MHz compiled version... PropOS_075_5MHz.zip
For those running RamBlade, here is the last compiled code (using a serial terminal) Z1_174FX.zip
and for RamBlade3 Z3_173FX.zip
Note the new xxxCPM commands which are able to access the CPM filesystem from the PropOS.
There is a new command "PROGRAM" that copies a binary file (must be 32KB) to either the lower or upper 32KB of the EEPROM
To run binaries (outside PropOS) please use...
SD:>RUN xxxxxx
where xxxxxx is the filename (excluding ".BIN")
For the time being, the binary must be compiled for the correct clock.
Here are the supported commands...
*** Propeller SD card Operating System v0.74 *** (02 August 2013)
------------------------------------------------
cmd --- ' Internal use (the command interpreter)
copy <source_filename> <destination_filename> ' Copies a file
del <filename> ' Deletes a file
diff <filename1> <filename2> ' Displays file differences
dir [mask] ' Displays a directory of files (see LS)
dircpm <cpm_diskname> ' Displays a directory of files on CPM filesystem
free ' Displays FAT16/32 used/free space (see USED)
getcpm <cpm_diskname> <cpm_filename> <fat_filename> ' Get (copy) a file from CPM to FAT16/32
help ' Display help info
ls [mask] [A] ' Displays a directory of files (see DIR)
mapcpm <cpm_diskname> [<cpm_filename> [-d]] ' Maps info about the CPM filesystem
os --- ' The PropOS binary file loaded to run PropOS
program <source_filename> [-WL][-WU] ' Program file to EEPROM L=Lower/U=Upper 32KB)
putcpm <fat_filename> <cpm_diskname> <cpm_filename> ' Put (copy) a file from FAT16/32 to CPM
reboot ' Reboot the Propeller Chip
ren <source_filename> <destination_filename> ' Rename a file
run <filename> ' Run a ".BIN" file
testsd ' Program to test the SD card (writes to the SD)
type <filename> [-h] ' Display the contents of a file
used ' Displays FAT16/32 used/free space (see FREE)
ver ' Displays info about PropOS including version
BOOTPROP.BIN '\ Boots the OS (a copy of _OS.CMD)
_OS .CMD '| Boots the OS (a copy of _OS.CMD) typically called from a user program
'/ may be programmed into EEPROM to boot the OS
To RUN any Propeller Binary (replaces the OS completely) just enter the binary filename at the command prompt...
SD:>RUN z3_173fx ' Will run ZiCog RamBlade3 V173 binary
' ..Entering HALT at the CPM prompt will reboot the prop
I was asked offline for a version of ZiCog for RamBlade without the big delay (to switch ports and get the terminal running). Here it is (untested) Z1_175FX.BIN
and RamBlade3 Z3_176FX.BIN
and TriBlade2 Z2_177FX.BIN
Comments
The boot program is _DOS.BIN
All commands are _xxx.CMD
_copy and _diff do not work and I have not tried _format. _unmount reports an error.
Source is included.
Anyone wishing to try will need to edit _DOS, _hwdef, Hardware_Detect and recompile all (because I use a 6.5MHz xtal
_DOS calls _VER and then calls _CMD. Almost all modules call _CMD when done. Drivers do not stay resident yet, but $7000-$7FFF hub is not cleared on new binaries.
External commands ver, help, mount, free, used, ls, dir, cat, test all work from limited testing.
Basically, all code is derived from KyeDOS3 by Kye & Drac - thanks guys!
_DOS3_10.zip
I have modified Kyes sd driver so that it does not totally clear to the top of hub, as determined by the _hubFree long located at $7FFC. I also keep a cog map so that resident driver cogs are not reset. This all is working now when loading modules. I am just using the serial port atm, but the driver can be replaced with tv or vga and keyboard without recompiling any modules (except the main dos module for now).
The help command is a module that displays _help.txt file, so it is easy to edit for adding more commands. Then just add a new command file as a .cmd beginning with "_".
I will post a code update in the next few days :
' OS Hub Definitions... _HubFree = $7FFC ' 4 ' \ stores total hub available (typ $7800) ' | (hub is allocated to the OS above this value) ' / (eg $7000 means $0000-$6FFF is available) ' ' \ os runtime configuration parameters _OS_COGS = $7FFB ' 1 ' | b24-31: 1= stay resident cogs (don't stop on reboot) _OS_CLKMODE = $7FFA ' 1 ' | b23-16: saved clkmode hub byte $0004 _OS_BITS = $7FF9 ' 1 ' | b08-15: runtime config bits _OS_LFmask = $80 ' | b15: 1= <lf> ON; 0= strip <lf> _OS_UNDEF = $7FF8 ' 1 ' / b00-07: undefined _OS_CLKFREQ = $7FF4 ' 4 ' saved clkfreq hub long $0000 _SDpins = $7FF0 ' 4 ' \ sd pins packed 4 bytes ' ' / Byte 3=/CS, 2=DI, 1=CLK, 0=DO _SIOpins = $7FEC ' 4 ' \ serial pins and mode settings (and cog#) ' ' / Byte 3=cog, 2=mode, 1=SO, 0=SI _SIObaud = $7FE8 ' 4 ' serial baud (speed typ 115,200) _StdIn = $7FE4 ' 4 ' standard input rendezvous _StdOut = $7FE0 ' 4 ' standard output rendezvous _AuxIn = $7FDC ' 4 ' auxilary input rendezvous _AuxOut = $7FD8 ' 4 ' auxilary output rendezvous _User1 = $7FD4 ' 4 ' user 1 rendezvous ' _User2 = $7FD0 ' 4 ' user 2 rendezvous _Hardware = $7FD0 ' 4 ' \ hardware: hi-word=company, lo-word=config ' | $0001 = Cluso99 $0001 = RamBlade 1 ' | $0001 = Cluso99 $0002 = TriBlade#2 ' / $0001 = Cluso99 $0003 = RamBlade3 _OSreserved = $7F80 ' 80 ' undefined (maybe serial in and serial out buffers?) _StringBuffer = $7F00 ' 128 ' general purpose string buffer _CogTables = $7E00 ' 256 ' \ 8*32B cog usage tables ' | TBD ' | Current thinking is... ' | 1 byte for "type" ' | 1 long for sector address to retrieve filename ' | However, could also be used as 2*16byte buffers ' / with the head+tail(s) kept in _StdIn & _StdOut _SDbuffer = $7C00 ' 512 ' SD card i/o buffer _SpinVector = $7800 ' 1024 ' vector table for Cluso's faster spin interpreter _SetHubFree = $7800 ' $7800-$7FFF currently reserved by the OSYou will note I take 2KB off the top, leaving 30KB to the user program. I have allocated 1KB for my vector table I use in my faster spin interpreter. I am planning to use this shortly here, so I needed to reserve the 1KB for the vectors and they must be located on a 1KB boundary.
I have most modules working now. The hardware (pin definitions and xtal/pll) is only changed in the _hwdef.spin file, and only the OS.spin is required to be recompiled. I automatically check for a RamBlade/RamBlade3/TriBlade#2. I know it is possible to check for others, but probably not all. The other modules (such as DIR, COPY, etc) do not need recompiling for a change of hardware (pins, xtal, etc).
I did look at the great job Dave has done with Spinix. But to me, I wanted more of a DOS feel rather than unix. Because we are using different naming conventions, it should be possible to call each others OS. I already do this between PropCMD and CPM/ZiCog.
DIR and COPY imply an SD card (or other mass storage) is fairly integral to the system. Does this mean the SD driver has to be part of the OS?
I just did a quick F8 on Kye's SD driver and it takes 2116 longs, or just over 1/4 of memory. Can you save 496 longs by preloading the SD cog driver?
And also all programs need an SD buffer so where this would normally be in the program, you have it in high ram, so you can 'reclaim' 512 bytes (128 longs) there as well.
Is a RTC part of the OS? If yes, do you need some longs reserved for the time and date? And if not, well, the RTC part of Kye's SD driver takes 188 longs and I must say I've hardly ever used this so maybe you can have the option to compile without RTC support and save a little memory there?
I presume you are preloading keyboard, serial, display drivers into cogs at startup, and so saving all that hub space for your main program?
I like the idea of displaying a help.txt file. That saves memory compared with Kyedos where the help messages are all part of the program.
Last night I had another look at Sphinx to see what is required there to become part of the picture. Its DIR command takes care of the ? and * parameters in the filenames, so this needs to be put into the primitive DIR command of KyeDos.
I really require the file transfer working. Michael Park has sent me the C code and exe for the PC end. It is a way simple ftf protocol.
The other part I need to get running is the RUN command - where a new binary is loaded to take over the whole prop.
Each of these are simple tasks on their own, but add up in my limited time.
You asked about loading the cogs up with drivers. Yes, they will be loaded from sd and into the cog so no space is wasted once loaded. As it stands atm I could reload the cog(s) to use keyboard and tv without any changes to the OS.
As for messages, I plan to use a disk file to store them. No wasted hub space! Use a lookup table and an error number - this is how we saved space on the minis years ago.
Drac - want to help? I've attached code in anticipation. Just edit _hwdef.spin (clock and pin numbers) and recompile _os.spin (with PropTool only, no PreSpin required for this module) to _OS.BIN You can place _OS.BIN into EEPROM.
Note only the pc is running here atm. Use PST on the pc end. If you want to use another terminal program, you may need to give the command "toggleLF" (case unimportant) to turn LF on or off. Type "ver" to get hardware info. Hel is designed to use the _HELP.TXT file so that any additions can be easily added without recompiling help.spin (I was playing with that so not sure where this is at atm).
PropOS_20120324.zip
Sounds a good idea. eg one thing I found when we went from the VGA to the TV version of Kyedos was that the DIR command had to be rewritten as it went from 80 to 40 cols. In your system, DIR could find out from your operating system what sort of display it had, and then adjust the number of filenames per row to suit.
At work at the moment - will check your code when I get home. Your file transfer program sounds good. I used xmodem but it could be automated more, particularly at the PC end where you could have a list of files and you could send one or many, and even do things like ask the propeller for a file list which then displays on the PC program.
Just to throw a spanner in your works, xmodem (and probably other file transfers) work quicker if the code is part of the operating system, because if the code is a separate program you have to wait for the new program to load. Only adds another couple of seconds though.
The modules are loading way quicker than that! Even with the 100ms inbuilt delay to ensure all i/o buffers are cleared you cannot notice any delay. Once you start the transfer, it should be quick at 115200 baud! Michaels routine is quick and simple with an easy CRCC. Only useful for direct connections though.
Forgot before. RTC: I think the idea is to read the RTC if it exists, and then use one of the props counters to maintain the time from there on. If there is no RTC, then it should get the last time/date from a file, increment by 1 second and overwrite, display the time. The user can then choose to change this by an OS command. The OS should be able to support a number of RTC chips. So yes, we need a hub location for date/time, or else a system call to get the latest date/time (only needs to be accurate to seconds).
' OS Hub Definitions... ' ------------------ _HubFree = $7FFC ' 4 ' \ stores total hub available (typ $7800) ' | (hub is allocated to the OS above this value) ' / (eg $7000 means $0000-$6FFF is available) _OS_COGS = $7FFB ' 1 byte ' stay resident cogs: 1= don't stop on reboot _OS_CLKMODE = $7FFA ' 1 byte ' clkmode: saved fm hub byte $0004 _OS_ROWS = $7FF9 ' 1 byte ' \ combined <lf> and rows _OS_LFmask = $80 ' | b7 : 1= <lf> ON; 0= strip <lf> _OS_ROWmask = $7F ' / b0-6: no of rows on screen (0-127) _OS_COLUMNS = $7FF8 ' 1 byte ' no of cols on screen (0-255) _OS_CLKFREQ = $7FF4 ' 4 ' clkfreq(Hz): saved fm hub long $0000 _OS_SECONDS = $7FF0 ' 4 ' seconds since 1Jan2000 00:00:00 (ok to yr2100/2132) _SDpins = $7FEC ' 4 ' \ sd pins packed 4 bytes ' ' / Byte 3=/CS, 2=DI, 1=CLK, 0=DO _SIOpins = $7FE8 ' 4 ' \ serial pins and mode settings (and cog#) ' ' / Byte 3=cog, 2=mode, 1=SO, 0=SI _SIObaud = $7FE4 ' 4 ' serial baud (speed typ 115,200) _Hardware = $7FE0 ' 4 ' \ hardware: hi-word=company, lo-word=config ' | $0001 = Cluso99 $0001 = RamBlade 1 ' | $0001 = Cluso99 $0002 = TriBlade#2 ' / $0001 = Cluso99 $0003 = RamBlade3 ' ^^^ may be more valuable for something else?? _AuxIn = $7FDC ' 4 ' auxilary input rendezvous _AuxOut = $7FD8 ' 4 ' auxilary output rendezvous _StdIn = $7FD4 ' 4 ' standard input rendezvous _StdOut = $7FD0 ' 4 ' standard output rendezvous _OSreserved2 = $7FC0 ' 16 _OSreserved = $7F80 ' 64 ' undefined (maybe serial in and serial out buffers?) _StringBuffer = $7F00 ' 128 ' general purpose string buffer (maybe 2*64?) _CogTables = $7E00 ' 256 ' \ 8*32B cog usage tables ' | TBD ' | Current thinking is... ' | 1 byte for "type" ' | 1 long for sector address to retrieve filename ' | However, could also be used as 2*16byte buffers ' / with the head+tail(s) kept in _StdIn & _StdOut _SDbuffer = $7C00 ' 512 ' SD card i/o buffer _SpinVector = $7800 ' 1024 ' vector table for Cluso's faster spin interpreter _SetHubFree = $7800 ' $7800-$7FFF currently reserved by the OSI had thought to add a long for the Screen (pinbase, pinmask, and cog(s)) but I think this can be done without using hub. Once set, we don't require it anymore. Same really applies to SD and SIO. Will need to have a config file on SD.
Ok, CP/M was so vague about its disk formats that there ended up being so many formats that none of them worked with each other. I note your comments earlier about moving files between CP/M and SD cards. Is there any reason we have to use the CP/M format at all?
Consider a Zicog emulation, or even a real Z80 interfaced to a propeller. CP/M abstracts the disk I/O to things like - "open a file", "close a file", "give me record n which is 128 bytes", or "write record n".
This seems remarkably similar to Kye's SD card driver. So if CP/M requests a particular record from a particular file, it will not know or care where this came from. Pass this request to Kye's SD driver and fetch the record.
If you want a disk full of CP/M files, use the SIMH W and R commands to move a group of files to a PC directory. Then copy onto an SD card.
Is there a catch?
If this works, would it not also make CP/M even smaller as the CP/M FAT allocation etc would not be needed.
I have all the common CPM disk files and I have already converted them into a CPM structure for each disk as a FAT file. That is how ZiCog works... 8x FAT files for 8x hard disks of 8MB. The disk table specifies the no of sectors and sizes and layouts of the clusters. I created these disk/fat files originally using a VB6 program I wrote, so no problems there.
BTW I am switching between ZiCog/CPM and the OS anyway, although I just created a bug and it stopped working.. oops!
Postedit: Cheated... just added in the old object atm. Its working going back and forth between this OS, ZiCog, Sphinx, Catalina and Spinix.
Drac: Perhaps you could ask on the N8VEM forums whether anyone has tried to use a FAT format for CPM? (lost my access some time ago)
PropOS_20120325c.zip
It uses Homespun to compile (included) and OS.BAT will compile all modules.
Windoze: Copy to a single folder and double click on OS.BAT and it will compile all modules.
Normally you will need to change the _HWDEF.SPIN file for your hardware and xtal/clock as I overclock and often forget to put it back.
This version has been compiled for 5MHz PLLx16, serial to PC on P31/30 & 115,200 baud, and SD on pins 0,1,2,3 but is untested since recompiling. Just copy *.CMD files to the SD card root directory. If you wish, program the _OS.CMD file into eeprom (it is a standard prop binary - you can copy to _OS.binary or _OS.eeprom and use PropTool to download to your eeprom.
OS_20120605.zip
The VB6 program does the file transfer on the PC and also makes a mini terminal program on the pc. It is currently coded for COMM4 which I set within XP for my propplug. This is a crude VB6 program, but the transfer works reliably with 8MB files each way (around 45 mins for now - I started and left it running).
For the boot program in the eeprom, I just program _OS.CMD into the eeprom (you can use the older _OS.binary if you wish - it still works fine). My version is set to compile for 6.5MHz, so you will need to change this (sorry I forgot when I zipped this on my other laptop). For the SD card, you will need to copy the files *.cmd files (and preferably *.txt too).
To compile, setup a dos window, navigate to the source subdirectory, and run the batch file os.bat. I have included the homespun compiler. Note in reality, only the _os.cmd file needs to be recompiled for a new platform.
For file transfers, the files need to exist on the prop as I have not fixed the bug that requires the file to preexist even when receiving.
I also found that the copy command does not work. Have not had time to check it out yet.
_os_20130208.zip
VB6miniTerm2_20130208.zip
Then all origial code, spin/asm files can be included in with the complete complie as a DAT attachment (if enough space is found)
Obviously this isn't powerfull if that same text editor dosen't complile the spin/asm file.
Has anyone made a prop spin/asm editor that runs on the prop?
Or even a compiler that can complile spin/asm files on the prop?
There are a couple of simple editors that various people have done. I don't know where they are up to.
Michael Park wrote a compiler for the prop under his OS called Sphinx. He also wrote homespun (which I use to compile this OS). I have not had the time to make it use the newer Kye SD access. However, Sphinx could be called from my OS, and Michael wrote a minimal editor as well.
Of course, there are lots of other options but xmodem is very simple - 128 byte packets and a single checksum and a one byte acknowledge/negative acknowledge.
It would be up to the program on the propeller what it does with the data - puts it into eeprom, onto an sd card, to external ram or to another propeller. The PC side of the program need not worry about that - all it needs to do is talk the xmodem protocol.
I've written vb.net code to do this and vb6 code is pretty simple too.
I'm going to approach the problem from the opposite angle and write a simple spin editor for the PC with xmodem, which I think is exactly where cluso99 is with post #46. I'll then probably use the command line BST or homespun to do the compilation.
But I wonder if any of the spin editor authors would consider adding this? If there was concern about clutter on the menu, maybe have a box in 'advanced options' to turn on the menu item.
I don't think we have an open source spin editor, right?
I forget... did you do xmodem in pasm?
BTW my intention is that whatever I/O driver(s) are used, they can e dynamically loaded/unloaded/reloaded. It is not all implemented yet, but it wiould not take too long to do. Currently, it is just one file that needs recompiling.
Because all the modules (OS commands) are located in their own binaries (called *.cmd), they can be added simply, and do not take valuable hub space.
I like the idea of just one file to compile. That is very clever.
Re xmodem, see the attached spin code in a zip. For kyedos, one might type XMODEM R MYFILE.TXT and then it runs the program XMODEM.EXE and that program loads the file COMMAND.TXT which is the line of text XMODEM R MYFILE.TXT and which can parse that complete command line. This way any number of command line parameters can be passed to the next program.
One question I must test one day - if a propeller chip reboots, does the ram get erased or does it stay static? If the latter, then the line of text to pass between programs could stay in high ram rather than be stored on the SD card.
This is the code from the PC end in vb.net. Xmodem in itself is a simple protocol, but it does take quite a bit of real world testing to get all the timing right, particularly with error recovery.
Sub XModemKyeSend(ByRef FName As String, ByVal Delay1 As Integer) Dim Filenamepath As String Dim a, j, i As Integer Dim k As Integer Dim LineOfText As String Dim SerialString As String Dim Counter As Integer Dim ErrorString As String Dim Packetnumber As Integer Dim Checksum As Long Dim OnesComplement As Byte Dim ByteRead As Byte Dim BinaryFileLength As Long Dim BinaryFileCounter As Long Dim Percent As Single Dim ErrorCounter As Byte ' 0 to 10 Dim CPMFilename As String Dim Timeout As Boolean ProgressBar1.Maximum = 100 ProgressBar1.Minimum = 0 ' timer restart =true for sending via menu. False for auto send Filenamepath = FName Packetnumber = 1 ' 1 for the first packet (not zero) ' Try Dim Input As New FileStream(Filenamepath, FileMode.Open, FileAccess.Read) Dim br As New BinaryReader(Input) OpenSerialPort() ' open the serial port Label3.Text = "Error Count" Label2.Text = "0%" BinaryFileLength = br.BaseStream.Length() - 1 'i = Len(Filepath) + 1 + 1 ' eg c:\n8vem and a \ = 9 and 1 more for start of name only Call Get_CPM_Filename(Filenamepath, CPMFilename) CPMFilename = Strings.UCase(CPMFilename) LineOfText = "XMODEM R " + CPMFilename + vbCr Call StringToPacket(LineOfText) ' Call ClearInputBuffer() ' clear the buffer into the PC For i = 1 To Delay1 ' 50 for kyedos need to wait for kyedos to run the xmodem program Sleep(100) ' wait for the xmodem text to come back so the next one is a 21 Label3.Text = Str$(i) Call ClearInputBuffer() ' clear the buffer into the PC Next i Call ClearInputBuffer() ' clear the buffer into the PC Do SerialString = "" If SerialPortFound = True Then If SerialPortName.BytesToRead > 0 Then SerialPortName.Read(InPacket, 0, 1) ' get one byte SerialString = Chr(InPacket(0)) ' get a single character/string/byte End If End If If InPacket(0) = 21 Then ErrorString = "NAK" Exit Do ' got a ^U End If If SerialString <> "" Then 'LineOfText = SerialString 'Call TextLines(LineOfText) ' print it out unless it is a chr21 End If Counter = Counter + 10 Sleep(10) ' don't change this one - this is waiting for NAK Label1.Text = "Waiting for NAK to start" + Strings.Str(Counter) + "ms" ' display in milliseconds System.Windows.Forms.Application.DoEvents() ' update the label1 message ' add a counter and timeout if nothing If Counter > 5000 Then ErrorString = "Bypass wait for NAK - xmodem failed" Exit Do End If If ErrorString <> "" Then Exit Do Loop Label1.Text = ErrorString System.Windows.Forms.Application.DoEvents() ' update the label1 message Do ' act on each byte in the buffer array here XOut(0) = 1 'SOH ^A XOut(1) = Packetnumber OnesComplement = 255 - Packetnumber XOut(2) = OnesComplement Packetnumber = Packetnumber + 1 If Packetnumber > 255 Then Packetnumber = Packetnumber - 256 Checksum = 0 For i = 0 To 127 ' get 128 bytes from file If BinaryFileCounter <= BinaryFileLength Then ByteRead = br.ReadByte ' get a byte Else ByteRead = 26 ' pad with char 26 = hex 1A because hyperterm does this ? why but it works End If XOut(i + 3) = ByteRead Checksum = Checksum + ByteRead BinaryFileCounter = BinaryFileCounter + 1 Next ' create checksum Do If Checksum < 256 Then Exit Do ' work out checksum Checksum = Checksum - 256 Loop XOut(131) = Checksum Call OutputXout() System.Windows.Forms.Application.DoEvents() ' update the label Timeout = False Do k = 0 Do If SerialPortFound = True Then j = SerialPortName.BytesToRead End If If j >= 1 Then If SerialPortFound = True Then SerialPortName.Read(InPacket, 0, 1) ' get one byte End If Exit Do End If k += 1 If k > 5000 Then Timeout = True ' 5 second delay for timeout, must be more than the Rx side timeout Exit Do End If Sleep(1) ' 1ms delay Loop If InPacket(0) = 6 Then Exit Do ' remote got the packet so exit If InPacket(0) = 21 Then ' remote didn't get it so try sending again - does up to 10x ErrorCounter = ErrorCounter + 1 Call ClearInputBuffer() ' clear the input buffer to the PC Sleep(1000) ' let the remote get itself sorted before resending the packet Call OutputXout() ' resend the packet Label3.Text = "Nak: " + Strings.Str(ErrorCounter) System.Windows.Forms.Application.DoEvents() ' update the label End If If Timeout = True Then Label3.Text = "Timeout waiting for Ack" ErrorCounter = 20 'force an exit now System.Windows.Forms.Application.DoEvents() ' update the label End If If ErrorCounter >= 10 Then Exit Do ' more than 10 errors Loop If ErrorCounter >= 10 Then Label1.Text = "10 or more errors - aborting" Label2.Text = "0%" OutPacket(0) = 24 ' send a ^X cancel If SerialPortFound = True Then SerialPortName.Write(OutPacket, 0, 1) ' send 1 byte OutPacket(0) = 3 ' send a ^C SerialPortName.Write(OutPacket, 0, 1) ' send 1 byte End If Exit Do End If If BinaryFileCounter > BinaryFileLength Then Exit Do ' finish up Label1.Text = "Sent packet: " + Strings.Str(Packetnumber) + " = OK" Percent = BinaryFileCounter / BinaryFileLength Percent = Percent * 100 Percent = Int(Percent) Label2.Text = Strings.Str(Percent) + "%" ProgressBar1.Value = Percent Loop If ErrorCounter < 10 Then OutPacket(0) = 4 ' finish byte If SerialPortFound = True Then SerialPortName.Write(OutPacket, 0, 1) ' send 1 byte End If Label2.Text = "100%" Label1.Text = "Finished" ProgressBar1.Value = 0 'done Call StringToPacket(vbCrLf) ' back to kyedos End If Input.Close() Sleep(200) ' wait for next file System.Windows.Forms.Application.DoEvents() ' update the labels 'Catch ex As Exception ' Close() ' Label1.Text = Filenamepath + " not found" ' System.Windows.Forms.Application.DoEvents() ' update the labels ' Sleep(1000) ' so time to read message 'End Try SerialPortName.Close() ' close the serial port End SubA normal reboot reloads the ram from eeprom. Not sure if there is no eeprom. If it is downloaded then the remainder of hub is cleared IIRC.
You can simulate a reboot by stopping all other cogs, loading hub (from SD or wherever) including limiting the hub reload if you wish (this is how I keep the upper hub intact), then stopping any other cogs, and lastly restarting cog 0 (and stopping the current cog if it is not 0). Of course, there may be other side effects of not clearing everything that a proper reboot does, but I don't think there is anything that matters.
BTW Thanks for the xmodem code. I was looking at the specs last night. It is quite a bit simpler than I thought. I've done BiSync and SDLC back in the 80's, so this is simple. Thinking further, it can be in spin although it will be slower. Just need to put it into it's own OS command module.
Postedit: Yes, it will be simple to make and xmodem module for this OS.
Here is the latest code. Note I have only included the compiled version of the MAPCPM.CMD for now (not it's source). If you compile all files using OS.BAT, remember to save MAPCMD as it will be deleted in the compile process! As normal, you only need to modify _HWREF.SPIN for your xtal freq/mode and SD pinouts and recompile _OS.SPIN which will produce _OS.CMD and _OS.BIN (identical files).
Depending on how you boot to PropOS... _OS.BIN can be programmed into your eeprom, or if you use the older and simpler boot program, then copy _OS.BIN to PROPBOOT.BIN, or change AUTOEXEC.BAT to run _OS.CMD.
NOTE: PropOS can also co-exist with SPINIX.
OS_20130716.zip
PropOS supported commands...
cat cat <filename> ' Display the contents of a file (see TYPE) cmd --- ' Internal use (the command interpreter) copy copy <source_filename> <destination_filename> ' Copies a FAT16/32 file diff diff <filename1> <filename2> ' Displays file differences dir dir [options] ' Displays a directory of files (see DIRW, LS) dirw dirw [options] ' Wide version of DIR format format ' WARNING Don't use: reformats SD card (untested) free free ' Displays FAT16/32 free space info (see USED) getcpm getcpm <cpm_diskname> <cpm_filename> <fat_filename> ' Get (copy) a file from CPM to FAT16/32 help help ' Display help info (not uptodate) ls ls [options] ' Displays a directory of files (see DIR, DIRW) mapcpm mapcpm <cpm_diskname> [<cpm_filename> [-d]] ' Maps info about the CPM filesystem mount mount ' Mount the FAT16/32 filesystem (see UNMOUNT) os --- ' The PropOS binary file loaded to run PropOS putcpm putcpm <fat_filename> <cpm_diskname> <cpm_filename> ' Put (copy) a file from FAT16/32 to CPM testsd testsd ' Program to test te SD card (writes to the SD) type type <filename> ' Display the contents of a file (see CAT) unmount unmount ' Unmount the FAT16/32 filesystem (see MOUNT) used used ' Displays FAT16/32 free space info (see FREE) ver ver ' Displays info about PropOS including version To RUN any Propeller Binary (replaces the OS completely) just enter the binary filename at the command prompt... z3_173fx z3_173fx ' Will run ZiCog RamBlade3 V173 binary ' ..Entering HALT at the CPM prompt will reboot the propCOMMANDS.TXTTo recompile for your hardware, edit _HWDEF and change pinouts and clock frequency, and run the batchfile HW.BAT
hw.zip
New OS commands: REBOOT, MAPCPM and DIRCPM (GETCPM and PUTCPM still to come).
TYPE replaces CAT.
Many of the commands now display their usage by typing just their command without parameters. eg COPY.
A number of errors are now checked, and information details are displayed.
The boot OS program will also be compiled to EEPROM_L.BIN so you can program this into your eeprom. (rename it EEPROM_L.BINARY for PropTool)
The default hardware is defined in _hwdef.spin so change your xtal frequency, pll mode, and pinouts here, and then compile just the _OS.spin file using hw.bat (note I use 6.5MHz xtal, so you need to change this).
The OS is can automatically detect RamBlade (aka RamBlade1), TriBlade, and RamBlade3 hardware, else it defaults to normal with serial on P30/31 and SD on P0..3.
Unfortunately I have not been able to get this OS to work with the current boot code shipped in the RamBlade. You will need to re-program the eeprom with EEPROM_L.BIN (or recompile and download _OS.spin with PropTool). I am working on a program that will do this from the SD card and will post this when I have it working.
OS_070_20130727.zip
Just replace _OS.CMD from the above post.
_OS_5MHz.zip
Here is a section from _hwdef.spin that was changed for this compile
This is the 6.5MHz compiled version (for Ramlade/TriBlade#2/RamBlade3 or other overclocked boards)
PropOS_075_6-5MHz.zip
and here is the 5MHz compiled version...
PropOS_075_5MHz.zip
For those running RamBlade, here is the last compiled code (using a serial terminal)
Z1_174FX.zip
and for RamBlade3
Z3_173FX.zip
Note the new xxxCPM commands which are able to access the CPM filesystem from the PropOS.
There is a new command "PROGRAM" that copies a binary file (must be 32KB) to either the lower or upper 32KB of the EEPROM
To run binaries (outside PropOS) please use...
SD:>RUN xxxxxx
where xxxxxx is the filename (excluding ".BIN")
For the time being, the binary must be compiled for the correct clock.
Here are the supported commands...
*** Propeller SD card Operating System v0.74 *** (02 August 2013) ------------------------------------------------ cmd --- ' Internal use (the command interpreter) copy <source_filename> <destination_filename> ' Copies a file del <filename> ' Deletes a file diff <filename1> <filename2> ' Displays file differences dir [mask] ' Displays a directory of files (see LS) dircpm <cpm_diskname> ' Displays a directory of files on CPM filesystem free ' Displays FAT16/32 used/free space (see USED) getcpm <cpm_diskname> <cpm_filename> <fat_filename> ' Get (copy) a file from CPM to FAT16/32 help ' Display help info ls [mask] [A] ' Displays a directory of files (see DIR) mapcpm <cpm_diskname> [<cpm_filename> [-d]] ' Maps info about the CPM filesystem os --- ' The PropOS binary file loaded to run PropOS program <source_filename> [-WL][-WU] ' Program file to EEPROM L=Lower/U=Upper 32KB) putcpm <fat_filename> <cpm_diskname> <cpm_filename> ' Put (copy) a file from FAT16/32 to CPM reboot ' Reboot the Propeller Chip ren <source_filename> <destination_filename> ' Rename a file run <filename> ' Run a ".BIN" file testsd ' Program to test the SD card (writes to the SD) type <filename> [-h] ' Display the contents of a file used ' Displays FAT16/32 used/free space (see FREE) ver ' Displays info about PropOS including version BOOTPROP.BIN '\ Boots the OS (a copy of _OS.CMD) _OS .CMD '| Boots the OS (a copy of _OS.CMD) typically called from a user program '/ may be programmed into EEPROM to boot the OS To RUN any Propeller Binary (replaces the OS completely) just enter the binary filename at the command prompt... SD:>RUN z3_173fx ' Will run ZiCog RamBlade3 V173 binary ' ..Entering HALT at the CPM prompt will reboot the propZ1_175FX.BIN
and RamBlade3
Z3_176FX.BIN
and TriBlade2
Z2_177FX.BIN