Shop OBEX P1 Docs P2 Docs Learn Events
Cluso's Propeller OS V1.14 - now with SPIN/PASM Compiler, EEPROM Read/Write :) - Page 2 — Parallax Forums

Cluso's Propeller OS V1.14 - now with SPIN/PASM Compiler, EEPROM Read/Write :)

245

Comments

  • Cluso99Cluso99 Posts: 18,069
    edited 2012-03-05 17:55
    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.
  • Cluso99Cluso99 Posts: 18,069
    edited 2012-03-06 03:19
    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
  • Cluso99Cluso99 Posts: 18,069
    edited 2012-03-21 06:16
    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 "_".

    I will post a code update in the next few days :
  • Cluso99Cluso99 Posts: 18,069
    edited 2012-03-23 05:50
    Here is my revised Hub Definitions...
    ' 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.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-03-23 15:48
    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.
  • Cluso99Cluso99 Posts: 18,069
    edited 2012-03-23 18:05
    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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-03-23 19:51
    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.
  • Cluso99Cluso99 Posts: 18,069
    edited 2012-03-23 22:06
    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).
  • Cluso99Cluso99 Posts: 18,069
    edited 2012-03-23 23:45
    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.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-03-24 17:26
    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.
  • Mike GreenMike Green Posts: 23,101
    edited 2012-03-24 19:47
    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.
  • Cluso99Cluso99 Posts: 18,069
    edited 2012-03-24 22:39
    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)
  • Cluso99Cluso99 Posts: 18,069
    edited 2012-03-25 03:32
    Latest code build attached. See a few posts back to select your hardware and xtal.

    PropOS_20120325c.zip
  • Cluso99Cluso99 Posts: 18,069
    edited 2012-06-04 21:44
    Here is my latest version of the OS...

    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
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-02-09 18:16
    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.

    _os_20130208.zip
    VB6miniTerm2_20130208.zip
  • Clock LoopClock Loop Posts: 2,069
    edited 2013-02-16 04:02
    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?
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-03-18 19:34
    clockloop: Sorry I must have missed your post.

    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.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-03-18 20:30
    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?
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-03-19 02:45
    Michael Park has a basic editor in Sphinx.

    I forget... did you do xmodem in pasm?
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-03-19 03:49
    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.
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-03-19 04:42
    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.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-03-19 06:44
    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
    
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-03-19 17:44
    Dr_Acula wrote: »
    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.
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-07-03 19:06
    Time for a shameless bump of this thread for those new forum members looking for a simple propeller os
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-07-15 16:01
    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.

    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 prop
    
    
    COMMANDS.TXT

    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
    
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-07-26 23:16
    Here is the latest update v0.70.....

    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
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-07-27 18:28
    Here is a compiled 5MHz version with SD on P0..3
    Just replace _OS.CMD from the above post.

    _OS_5MHz.zip

    Here is a section from _hwdef.spin that was changed for this compile
    CON
    '' Configure your hardware settings here...
    '' Note: 1. If you have a RamBlade, RamBlade3 or a TriBlade#2(second prop),
    ''            the code will automatically detect the hardware except for
    ''            the clock setting, so you must change this. (default 6.5MHz xtal)
    ''       2. For other boards, change the clock setting appropriately.
      _XINFREQ_     = 5_000_000     ' \ default setting
      _CLKMODE_     = xtal1 + pll16x' /
    '  _XINFREQ_     = 6_500_000     ' \ set for RamBlade/RamBlade3/TriBlade#2
    '  _CLKMODE_     = xtal1 + pll16x' /
    
      _SIpin        = 31            ' \ usual serial input pin  (from TXD on pc)
      _SOpin        = 30            ' |              output pin (to   RXD on pc)
      _SIOmode      = 0             ' | usual mode
      _SIObaud      = 115200        ' / common baud (serial speed)
      _SIOpins      = _SIOmode << 16 | _SIpin << 8 | _SOpin
      _SDpin_CS     = 3             ' \ SD card pins: CS  (active low)
      _SDpin_DI     = 2             ' |               DI  (to SD)
      _SDpin_CLK    = 1             ' |               CLK (to SD)
      _SDpin_DO     = 0             ' |               DO  (fm SD)
    ' _SDpin_CD     = -1            ' | card detect   (can be DI)
    ' _SDpin_WP     = -1            ' / write protect (can be CLK) (not on microSD cards)
      _SDpins       = _SDpin_CS << 24 | _SDpin_DI << 16 | _SDpin_CLK << 8 | _SDpin_DO
      _RTCpin_DAT   = -1            ' \ RTC (clock chip - often shared with EEPROM)
      _RTCpin_CLK   = -1            ' /
      
      _EEPROM_DAT   = 29            ' \ EEPROM
      _EEPROM_CLK   = 28            ' /
      _EEPROM_SIZE  = 64            ' 32/64/128KB
      _EEPROMpins   = _EEPROM_DAT << 8 | _EEPROM_CLK
      _KBDpin_CLK   = 27            ' \ PS2 Keyboard
      _KBDpin_DAT   = 26            ' /
      _KBDpins      = _KBDpin_CLK << 8 | _KBDpin_DAT
      _MOUSE_CLK    = 25            ' \ PS2 Mouse
      _MOUSE_DAT    = 24            ' /
      _MOUSEpins    = _MOUSE_CLK << 8 | _MOUSE_DAT
      _AUDIO_1      = -1            ' \ Audio out (chan 1 stereo or mono)
      _AUDIO_2      = -1            ' /           (chan 2 stereo)
      _AUDIOpins    = _AUDIO_2 << 8 | _AUDIO_1
      _TVbasepin    = 12            ' \ TV (composite video)
      _TVpinmask    = $07           ' |   output pin mask
    ' _TVmode       = tbd           ' /   tbd: PAL/NTSC, timing?
      _VGAbasepin   = 16            ' \ VGA
      _VGApinmask   = $FF           ' |   output pin mask
    ' _VGAmode      = tbd           ' /   tbd: timing?
      _SCREENROWS   = 40            ' \ Screen display size for text  (max 127)
      _SCREENCOLS   = 80            ' /                               (max 255)
    
    
    
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-08-02 04:28
    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
    
    
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-08-02 05:04
    Looks brilliant. Will be perfect for my hybrid Z80/Prop board :)
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-08-02 16:12
    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
Sign In or Register to comment.