I guess you have to save as EEPROM not BINARY.
Binary has the actual size of the program, Eeprom is always 32k.
Yes, but PropellerIDE and SimpleIDE both create the binary file as actual size... The only way I could create the 32K-sized binary was to run openspin on the command-line with the "-e" option!
Maybe the PropOS Program command should do the same (allow any size smaller or equal to 32K).
Compiled versions in both Bootxxxx.EEP & Bootxxxx.eeprom formats (you need the 8+3 format for FAT16/32 SD card) plus source, batch file for compiling, and homespun.exe compiler. Compiled versions for...
* 5.00MHz x16, SD on P0-P3, serial on P30/P31 "Boot05M0.EEP/eeprom"
* 10.00MHz x8, SD on P0-P3, serial on P30/P31 "Boot10M0.EEP/eeprom"
* 12.00MHz x8, SD on P12-P15, serial on P30/P31 "BootP8X2.EEP/eeprom" (P8XBlade2 & CpuBlade7)
There is a custom version too. Just edit "_BOOT_OS.spin" changing the xtal and pins in the custom section and run the batch file to compile. The custom file is called "BootCust.EEP/eeprom".
If you need to use another compiler, then comment out the two #ifdef ... #endif sections and replace with your custom parmeters. PropTool works if you do this.
Program as before (instructions a few posts above).
FYI Version 1.10 is basically the same as v1.00. I have just added compile time options for various parameters to make it easier to produce multiple versions.
I have made some changes to streamline the interfaces and reduce code space.
Two files are attached.
The (SDfiles) version contains all the files required to be loaded onto the SD card (FAT16 or FAT32 format).
The (Source) contains all the source files to build the OS using the homespun compiler (use os.bat). I have also included the EEPROM boot code V1.10 files for my P8XBlade2, and any prop with SD on pins 0..2 with 5MHz and 10MHz xtals. The source for these files is a few post back.
The file _CMD.CMD is a copy of BOOTP8X2.EEP (required for existing P8XBlade2 eeproms).
For those of you with my P8XBlade2, they were all shipped with an older boot code. The newest boot code is V1.10 and hopefully will not require changing. You have two options...
1. Do nothing (a little slower booting)
2. After copying the new OS to your SD card, with WE shorted (enable EEPROM writing), use the OS command
SD:>PROGRAM BOOTP8X2.EEP -WL
Optionally remove the WE short.
Here is the new OS boot output...
_BOOT_OS v1.10: P8X2 sd, mount, boot _BOOT_P1.BIN, boot _OS.CMD
*** Cluso's Propeller Operating System v1.00 ***
------------------------------------------------
(see 'VER' for acknowledgements)
Hardware: Cluso's P8XBlade2
ClockFreq 096000000Hz, ClockMode $6E, Cog 0
Serial on pins 30,31, Mode 00, Baud 00115200, Cog 1
Screen size: 080 x 040
<LF> is OFF
SD card on pins 12,13,14,15
SD Driver Cog = 2
Resident Cogs : 1 2 This Cog: 0
Cogs available: 3 4 5 6 7 (=5)
Booting from SD card...
SD:>help
*** Cluso's Propeller SD card Operating System v1.00 *** (19 February 2016)
-------------------------------------------------------------------------------
clear ' Clear screen
cmd --- ' Internal use (command interpreter)
copy <source_file> <destination_file> ' Copy a file
del <file> ' Delete a file
diff <file1> <file2> ' Display file differences
dir [mask] ' Display directory of files
dircpm <cpm_disk> ' Display directory of files on CPM
dnload ' Download code Ctl-F10/F11 w/o reset
echo <text> ' Echo the line of text
free ' Display FAT16/32 used/free space
getcpm <cpm_disk> <cpm_file> <fat_file> -T/B ' Get (copy) CPM file to FAT16/32
getfat <fat_file> ' Get (copy) FAT16/32 file to PC
help ' Display help info
hubdump <addr> <bytes> ' Dump hub memory addr(hex) bytes(hex)
lf ' Toggles LF on/off
ls [mask] [A] ' Display directory of files
mapcpm <cpm_disk> [<cpm_file> [-d]] ' Maps info about the CPM filesystem
os --- ' PropOS binary file (runs PropOS)
program <source_file> [{-WL}{-WU}] ' Program to EEPROM L=Lower/U=Upper
putcpm <fat_file> <cpm_disk> <cpm_file> ' Put (copy) FAT16/32 file to CPM
putfat <fat_file> ' Put (copy) FAT16/32 file from PC
reboot ' Reboot the Propeller Chip
ren <source_file> <destination_file> ' Rename a file
run <file> ' Run a ".BIN" file (kills PropOS)
testsd ' Tests the SD card (writes to SD)
type <file> [-Hn] ' Display the contents of a file
used ' Display FAT16/32 used/free space
ver ' Display info about PropOS
-------------------------------------------------------------------------------
_OS .CMD ' Boots the OS
BOOTxxxx.EEP ' May be programmed into EEPROM to boot PropOS (v1.10)
' - runs SD program "PROP_P1.BIN" else "_OS.CMD"
xxxx = board/xtal/sdpin specific (refer to forum/website)
-------------------------------------------------------------------------------
To RUN any Propeller Binary (replaces the OS completely)...
SD:>RUN z3_174fx ' Runs ZiCog RamBlade3 V174 binary
A:>HALT ' Reboots the prop (from CPM prompt)
-------------------------------------------------------------------------------
SD:>
I have made some changes to streamline the interfaces and reduce code space.
Two files are attached.
The (SDfiles) version contains all the files required to be loaded onto the SD card (FAT16 or FAT32 format).
The (Source) contains all the source files to build the OS using the homespun compiler (use os.bat). I have also included the EEPROM boot code V1.10 files for my P8XBlade2, and any prop with SD on pins 0..2 with 5MHz and 10MHz xtals. The source for these files is a few post back.
The file _CMD.CMD is a copy of BOOTP8X2.EEP (required for existing P8XBlade2 eeproms).
For those of you with my P8XBlade2, they were all shipped with an older boot code. The newest boot code is V1.10 and hopefully will not require changing. All new P8XBlade2's will now be shipped with BOOTP8X2.EEP V1.10 pre-programmed into the EEPROM. You have two options...
1. Do nothing (a little slower booting)
2. After copying the new OS to your SD card, with WE shorted (enable EEPROM writing), use the OS command
SD:>PROGRAM BOOTP8X2.EEP -WL
Optionally remove the WE short.
For those of you with other Propeller boards, program the appropriate BOOTxxxx.EEP into your EEPROM. If you have any questions, just ask.
Here is the new OS boot output...
_BOOT_OS v1.10: P8X2 sd, mount, boot _BOOT_P1.BIN, boot _OS.CMD
*** Cluso's Propeller Operating System v1.00 ***
------------------------------------------------
(see 'VER' for acknowledgements)
Hardware: Cluso's P8XBlade2
ClockFreq 096000000Hz, ClockMode $6E, Cog 0
Serial on pins 30,31, Mode 00, Baud 00115200, Cog 1
Screen size: 080 x 040
<LF> is OFF
SD card on pins 12,13,14,15
SD Driver Cog = 2
Resident Cogs : 1 2 This Cog: 0
Cogs available: 3 4 5 6 7 (=5)
Booting from SD card...
SD:>help
*** Cluso's Propeller SD card Operating System v1.00 *** (19 February 2016)
-------------------------------------------------------------------------------
clear ' Clear screen
cmd --- ' Internal use (command interpreter)
copy <source_file> <destination_file> ' Copy a file
del <file> ' Delete a file
diff <file1> <file2> ' Display file differences
dir [mask] ' Display directory of files
dircpm <cpm_disk> ' Display directory of files on CPM
dnload ' Download code Ctl-F10/F11 w/o reset
echo <text> ' Echo the line of text
free ' Display FAT16/32 used/free space
getcpm <cpm_disk> <cpm_file> <fat_file> -T/B ' Get (copy) CPM file to FAT16/32
getfat <fat_file> ' Get (copy) FAT16/32 file to PC
help ' Display help info
hubdump <addr> <bytes> ' Dump hub memory addr(hex) bytes(hex)
lf ' Toggles LF on/off
ls [mask] [A] ' Display directory of files
mapcpm <cpm_disk> [<cpm_file> [-d]] ' Maps info about the CPM filesystem
os --- ' PropOS binary file (runs PropOS)
program <source_file> [{-WL}{-WU}] ' Program to EEPROM L=Lower/U=Upper
putcpm <fat_file> <cpm_disk> <cpm_file> ' Put (copy) FAT16/32 file to CPM
putfat <fat_file> ' Put (copy) FAT16/32 file from PC
reboot ' Reboot the Propeller Chip
ren <source_file> <destination_file> ' Rename a file
run <file> ' Run a ".BIN" file (kills PropOS)
testsd ' Tests the SD card (writes to SD)
type <file> [-Hn] ' Display the contents of a file
used ' Display FAT16/32 used/free space
ver ' Display info about PropOS
-------------------------------------------------------------------------------
_OS .CMD ' Boots the OS
BOOTxxxx.EEP ' May be programmed into EEPROM to boot PropOS (v1.10)
' - runs SD program "PROP_P1.BIN" else "_OS.CMD"
xxxx = board/xtal/sdpin specific (refer to forum/website)
-------------------------------------------------------------------------------
To RUN any Propeller Binary (replaces the OS completely)...
SD:>RUN z3_174fx ' Runs ZiCog RamBlade3 V174 binary
A:>HALT ' Reboots the prop (from CPM prompt)
-------------------------------------------------------------------------------
SD:>
OS programs use the stay-resident cogs for drivers and utilise a hardware abstraction feature. The filename format is 8+3, and begins with "_" and has the extension ".CMD".
The OS will run any "_xxxxxxx.CMD" program without modification. ie it just loads and executes the "_xxxxxxx.cmd" file.
To write your own OS program, take a simple program such as _FREE.SPIN, and rename it. Then change the internals to suit. You will notice the OS programs include a code module "__MODULE.SPIN" in the program code. This provides the interface to the drivers and the OS. Homespun is required to compile the OS programs due to the inclusion of this code module. Since the OS uses the top of hub (refer to "_HUBDEF.SPIN"), OS programs must be slightly smaller than binary programs that do not use the OS.
An OS program does not have to be an OS style program. It is just one that utilises the OS drivers that have been pre-loaded by the OS.
The Standard I/O supports an output driver "_StdOut.spin" and an input driver "_StdIn.spin". Just include these objects in your program as OBJ declarations...
OBJ
Input : "_STDIN" ' use std input driver (i/o driver loaded by _OS.CMD)
Print : "_STDOUT" ' use std output driver (i/o driver loaded by _OS.CMD)
Here are the StdIn calls...
OBJ
hub : "_hubdef"
CON
pRENDEZVOUS = hub#_StdIn
PUB Char : chr
'' Wait for an input character
repeat until chr := long[pRendezvous] 'wait until the mailbox has a character
long[pRendezvous]~ 'clear the mailbox
chr &= $FF '$100 -> $00 'extract lower 8 bits (byte)
PUB Peek
'' Returns a 0 if the buffer is empty,
'' else next character (+$100) but doesn't remove from the buffer.
'' The user routine must extract the 8 bits as the complete long is passed.
return long[pRendezvous] 'return ALL bits (long) in the mailbox
and the StdOut calls...
OBJ
_hub : "_hubdef"
_c : "_chardef"
CON
pRENDEZVOUS = _hub#_StdOut
PUB Out(chr)
'' Print a character (do not strip <lf>)
repeat while long[pRENDEZVOUS] 'wait for mailbox to be empty (=0)
long[pRENDEZVOUS] := chr | $100 'add bit9=1 (allows $00 to be passed) & place in mailbox for driver
PUB Char(chr)
'' Print a character (optionally strip <lf>)
if (chr == _c#_lineFeedCharacter) and (byte[_hub#_OS_Rows] & _hub#_LF_MASK == 0)
return 'strip <lf>
Out(chr)
PUB Str(stringptr)
'' Print a zero-terminated string
repeat strsize(stringptr)
Char(byte[stringptr++])
PUB StrCR(stringptr)
'' Print a zero-terminated string followed by CR+LF
Str(stringptr)
CRLF
PUB CRLF
'' Print CR+LF
Char(_c#_carriageReturnCharacter)
Char(_c#_lineFeedCharacter)
PUB Spaces(n)
'' Print "n" spaces
repeat n
Char(" ")
PUB Decimal(value) | _i
'' Print a decimal number
if value < 0
-value
Char("-")
_i := 1_000_000_000
repeat 10
if value => _i
Char(value / _i + "0")
value //= _i
result~~
elseif result or _i == 1
Char("0")
_i /= 10
PUB Hex(value, digits)
'' Print a hexadecimal number
value <<= (8 - digits) << 2
repeat digits
Char(lookupz((value <-= 4) & $F : "0".."9", "A".."F"))
PUB Binary(value, digits)
'' Print a binary number
value <<= 32 - digits
repeat digits
Char((value <-= 1) & 1 + "0")
PUB ASCII(chr)
' Print a visual ascii character $20..$7E, else print "."
if chr < _c#_firstPrintableCharacter '$20
Char(".")
elseif chr > _c#_lastPrintableCharacter '$7E
Char(".")
else
Char(chr)
Note the use of hub (long) mailboxes for input and output. This is how redirection is achieved.
Simply replace the input and/or output cog driver(s) to choose an alternative device, such as serial, tv, vga, keyboard, etc.
An interesting side effect of the I/O driver stubs is that sub objects can also output to the driver. All that is required is an OBJ declaration in any sub-object that requires outputting/inputting characters.
This makes it simple to output debug information from sub-objects. I have found this extremely useful in trying to debug Michael Park's Sphinx compiler which I converted to run under the OS with FAT16 & FAT32 support.
I don't know the limitations. I have the work areas greatly reduced from Michaels original values due to lots of debugging info. Once I am reasonably sure everything is fine I can remove them and recover more workspace.
You might want to look at spinix. I ported the Sphinx compiler to it back in July 2014. I had to reduce some of the workspace sizes also because I used a Spin SD driver instead of a PASM driver running entirely within a cog.
I wanted a DOS like command interface rather than unix, plus separate command programs running under the OS. This way, programs like "DIR" etc can easily be added/modified without changing the basic OS. This makes it easy for anyone to add additional commands.
The compiler uses commands "LEX", "CODEGEN" and "LINK", all of which run under the OS (rather than replace the OS and run as a binary). You can examine the output files with "TYPE <filename> -h" which displays both hex and ascii.
There is a "HUBDUMP <hub-addr> <bytes>" command that displays hub memory in the same hex and ascii format.
BTW I use a modified version of Kye's SD_FATEngine which supports FAT16 & FAT32 SD formats.
I am now looking for an Editor to modify to work with the OS. Any ideas???
I should take a look at Prop OS at some point. There are probably a lot of similarities between Prop OS and spinix. spinix also uses separate programs to implement most of the commands. DIR and TYPE could be added to it to provide a more DOS-like interface. spinix uses a section of high hub memory to provide mailboxes and storage for environmental variables.
spinix uses a modified version of FSRW for the SD driver. The Spin method API is similar to the C stdio library. In spinix's version of the Sphinx compiler "lex -l file" will automatically run lex, codegen and link. "lex -c file" will only run lex and codegen. I believe "lex file" will only run lex. I also wrote tokdump and sobdump utilities to dump the contents of token and SOB files. You might find that interesting.
spinix has three text editors -- ted, ed and vi. ed and vi are the standard unix/Linux editors. ted is a simple version of ed. I've thought about making a more user friendly version of vi that uses the arrow keys, but I never got around to it.
I should take a look at Prop OS at some point. There are probably a lot of similarities between Prop OS and spinix. spinix also uses separate programs to implement most of the commands. DIR and TYPE could be added to it to provide a more DOS-like interface. spinix uses a section of high hub memory to provide mailboxes and storage for environmental variables.
Prop OS also uses high hub memory for mailboxes, cogs used/resident, SD & serial pins, StdIn & StdOut and AuxIn & AuxOut rendezvous longs, etc. Like Spinix, it goes back a long time when we all discussing various ideas about mailboxes.
spinix uses a modified version of FSRW for the SD driver. The Spin method API is similar to the C stdio library. In spinix's version of the Sphinx compiler "lex -l file" will automatically run lex, codegen and link. "lex -c file" will only run lex and codegen. I believe "lex file" will only run lex. I also wrote tokdump and sobdump utilities to dump the contents of token and SOB files. You might find that interesting.
My OS started using fsrwfemto, then I changed to using fsrw, and again later to Kye's SD_FATEngine (because it supported FAT32 as well).
Currently I haven't coded LEX to call CODEGEN, and CODEGEN to call LINK. I think I might want to support .BAT files which would do that function as well as others. The basics are there to do it.
Definitely interested in tokdump and sobdump! Obviously I can display the contents with type, but displaying formatted data would be better. Currently I have debug hooks to display tokens and sob outputs but I need to recover the code space shortly.
You might find my hubdump & type useful as it formats it in the traditional hex and ascii and as used in PropTool. I have made it a "Print.Dump(addr,bytes)" routine.
spinix has three text editors -- ted, ed and vi. ed and vi are the standard unix/Linux editors. ted is a simple version of ed. I've thought about making a more user friendly version of vi that uses the arrow keys, but I never got around to it.
I should investigate these. I require an editor, and if I can use an existing one as the base, then any additions can be fed back too.
BTW Spinix and Prop OS can co-exist on the same SD (I tried it years ago), as well as CPM (requires SRAM support). The Sphinx Compiler was supported this way too, but of course no FAT32 which is required nowadays. CPM/ZiCog currently only runs on FAT16 - it's on my todo list. However, USB has priority next.
A minor update V1.11 files...
_lex, _codegen, _link (more workspace, modified debugging)
_dumptok, _dumpsob (dump compiler files .TOK and .SOB workfiles)
_dumphub (renamed from _hubdump)
_dumpfil (dumps file in hex+ascii format - equiv to type <file> -h16 )
_help.txt (updated help info)
OS V1.14 (08 October 2016)
Includes DUMPFIL, DUMPHUB, DUMPTOK, DUMPSOB (TOK & SOB are outputs from the modified Sphinx Spin/Pasm Compiler)
Includes EEPROM <file> to read or write from/to Lower/Upper 32KB EEPROM.
See HELP command for more info.
OSv114sd.zip contains the object files to be loaded onto the SD card.
OSv114sc.zip contains the source files
V1.11 EEPROM Boot Files... BOOT05M0.eep (5MHz PLL16 SD on P0..3)
BOOT10M0.eep (10MHz PLL8 SD on P0..3)
BOOTP8X2.eep (P8XBlade2: 12MHz PLL8 SD on P12..15)
Select one of these for your Board, program into your EEPROM. For different board configurations, build from the source using instructions from a few posts back.
V1.11 also displays SD volume label, and fixes a typo. V1.10 can still be used.
Note the EEPROM does not need to be reprogrammed from previous versions. Just overwrite the new SD files to your SD Card for the latest OS version 1.14.
A number of people have been building the POV Globe from the Instructables website using my P8XBlade2.
For those people, there is another way rather than re-programming the EEPROM.
Format your microSD card, preferably FAT32 these days, else FAT16.
Copy the OSv114sd.zip file (from 3 posts back) to your PC. Unzip them and copy those files to your microSD card.
Copy the bitmap files from the Instructables article to your microSD card.
Copy or Rename your POV binary file (the runtime file you would be programming into the EEPROM) to _BOOT_P1.BIN and then copy this file to your microSD card.
Now when my OS boots, it will search for the _BOOT_P1.BIN file, and if it finds this file, it will run it instead of my OS.
Comments
Here are the EEPROM versions
Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
Website: www.clusos.com
Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
Yes, but PropellerIDE and SimpleIDE both create the binary file as actual size... The only way I could create the 32K-sized binary was to run openspin on the command-line with the "-e" option!
Maybe the PropOS Program command should do the same (allow any size smaller or equal to 32K).
dgately
Thanks, Cluso!
Here is the whole enchilada...
Compiled versions in both Bootxxxx.EEP & Bootxxxx.eeprom formats (you need the 8+3 format for FAT16/32 SD card) plus source, batch file for compiling, and homespun.exe compiler. Compiled versions for...
* 5.00MHz x16, SD on P0-P3, serial on P30/P31 "Boot05M0.EEP/eeprom"
* 10.00MHz x8, SD on P0-P3, serial on P30/P31 "Boot10M0.EEP/eeprom"
* 12.00MHz x8, SD on P12-P15, serial on P30/P31 "BootP8X2.EEP/eeprom" (P8XBlade2 & CpuBlade7)
There is a custom version too. Just edit "_BOOT_OS.spin" changing the xtal and pins in the custom section and run the batch file to compile. The custom file is called "BootCust.EEP/eeprom".
If you need to use another compiler, then comment out the two #ifdef ... #endif sections and replace with your custom parmeters. PropTool works if you do this.
Program as before (instructions a few posts above).
FYI Version 1.10 is basically the same as v1.00. I have just added compile time options for various parameters to make it easier to produce multiple versions.
Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
Website: www.clusos.com
Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
I have made some changes to streamline the interfaces and reduce code space.
Two files are attached.
The (SDfiles) version contains all the files required to be loaded onto the SD card (FAT16 or FAT32 format).
The (Source) contains all the source files to build the OS using the homespun compiler (use os.bat). I have also included the EEPROM boot code V1.10 files for my P8XBlade2, and any prop with SD on pins 0..2 with 5MHz and 10MHz xtals. The source for these files is a few post back.
The file _CMD.CMD is a copy of BOOTP8X2.EEP (required for existing P8XBlade2 eeproms).
For those of you with my P8XBlade2, they were all shipped with an older boot code. The newest boot code is V1.10 and hopefully will not require changing. You have two options...
1. Do nothing (a little slower booting)
2. After copying the new OS to your SD card, with WE shorted (enable EEPROM writing), use the OS command Optionally remove the WE short.
Here is the new OS boot output...
Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
Website: www.clusos.com
Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
Website: www.clusos.com
Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
OS programs use the stay-resident cogs for drivers and utilise a hardware abstraction feature. The filename format is 8+3, and begins with "_" and has the extension ".CMD".
The OS will run any "_xxxxxxx.CMD" program without modification. ie it just loads and executes the "_xxxxxxx.cmd" file.
To write your own OS program, take a simple program such as _FREE.SPIN, and rename it. Then change the internals to suit. You will notice the OS programs include a code module "__MODULE.SPIN" in the program code. This provides the interface to the drivers and the OS. Homespun is required to compile the OS programs due to the inclusion of this code module. Since the OS uses the top of hub (refer to "_HUBDEF.SPIN"), OS programs must be slightly smaller than binary programs that do not use the OS.
An OS program does not have to be an OS style program. It is just one that utilises the OS drivers that have been pre-loaded by the OS.
The Standard I/O supports an output driver "_StdOut.spin" and an input driver "_StdIn.spin". Just include these objects in your program as OBJ declarations...
Here are the StdIn calls... and the StdOut calls...
Note the use of hub (long) mailboxes for input and output. This is how redirection is achieved.
Simply replace the input and/or output cog driver(s) to choose an alternative device, such as serial, tv, vga, keyboard, etc.
Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
Website: www.clusos.com
Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
This makes it simple to output debug information from sub-objects. I have found this extremely useful in trying to debug Michael Park's Sphinx compiler which I converted to run under the OS with FAT16 & FAT32 support.
Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
Website: www.clusos.com
Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
Now includes a SPIN/PASM Compiler (based on Michael Park's Sphinx Compiler).
Currently the compiler is limited to very small programs. The compiler is a 3-stage compiler...
SD:>LEX <filename.spn> [-vn]
SD:>CODEGEN <filename.spn> [-vn]
SD:>LINK <filename.spn> [-vn]
where -vn is the verbose level, n being 0-3 (9 is an extreme debug)
LEX
Takes a xxxxxxxx.spn (spin file) and generates xxxxxxxx.tok (tokenised file).
CODEGEN
A 2 pass compiler that takes xxxxxxxx.spn and xxxxxxxx.tok and generates xxxxxxxx.sob file(s).
LINK
Links the xxxxxxxx.sob file(s) and generates a xxxxxxxx.bin (executable binary file).
Files attached...
OSv110sd.zip are the files required on the SD drive.
OSv110sc.zip are the source files to build the OS.
Please note I make no claim to understand Michael's Sphinx Compiler so I cannot guarantee that I can fix any bugs.
Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
Website: www.clusos.com
Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
"very small programs" ... How small?
Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
Website: www.clusos.com
Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
I wanted a DOS like command interface rather than unix, plus separate command programs running under the OS. This way, programs like "DIR" etc can easily be added/modified without changing the basic OS. This makes it easy for anyone to add additional commands.
The compiler uses commands "LEX", "CODEGEN" and "LINK", all of which run under the OS (rather than replace the OS and run as a binary). You can examine the output files with "TYPE <filename> -h" which displays both hex and ascii.
There is a "HUBDUMP <hub-addr> <bytes>" command that displays hub memory in the same hex and ascii format.
BTW I use a modified version of Kye's SD_FATEngine which supports FAT16 & FAT32 SD formats.
I am now looking for an Editor to modify to work with the OS. Any ideas???
Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
Website: www.clusos.com
Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
spinix uses a modified version of FSRW for the SD driver. The Spin method API is similar to the C stdio library. In spinix's version of the Sphinx compiler "lex -l file" will automatically run lex, codegen and link. "lex -c file" will only run lex and codegen. I believe "lex file" will only run lex. I also wrote tokdump and sobdump utilities to dump the contents of token and SOB files. You might find that interesting.
spinix has three text editors -- ted, ed and vi. ed and vi are the standard unix/Linux editors. ted is a simple version of ed. I've thought about making a more user friendly version of vi that uses the arrow keys, but I never got around to it.
My OS started using fsrwfemto, then I changed to using fsrw, and again later to Kye's SD_FATEngine (because it supported FAT32 as well).
Currently I haven't coded LEX to call CODEGEN, and CODEGEN to call LINK. I think I might want to support .BAT files which would do that function as well as others. The basics are there to do it.
Definitely interested in tokdump and sobdump! Obviously I can display the contents with type, but displaying formatted data would be better. Currently I have debug hooks to display tokens and sob outputs but I need to recover the code space shortly.
You might find my hubdump & type useful as it formats it in the traditional hex and ascii and as used in PropTool. I have made it a "Print.Dump(addr,bytes)" routine.
I should investigate these. I require an editor, and if I can use an existing one as the base, then any additions can be fed back too.
BTW Spinix and Prop OS can co-exist on the same SD (I tried it years ago), as well as CPM (requires SRAM support). The Sphinx Compiler was supported this way too, but of course no FAT32 which is required nowadays. CPM/ZiCog currently only runs on FAT16 - it's on my todo list. However, USB has priority next.
Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
Website: www.clusos.com
Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
_lex, _codegen, _link (more workspace, modified debugging)
_dumptok, _dumpsob (dump compiler files .TOK and .SOB workfiles)
_dumphub (renamed from _hubdump)
_dumpfil (dumps file in hex+ascii format - equiv to type <file> -h16 )
_help.txt (updated help info)
Unzip and copy to your SD card. (replace = yes)
Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
Website: www.clusos.com
Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
OS V1.14 (08 October 2016)
Includes DUMPFIL, DUMPHUB, DUMPTOK, DUMPSOB (TOK & SOB are outputs from the modified Sphinx Spin/Pasm Compiler)
Includes EEPROM <file> to read or write from/to Lower/Upper 32KB EEPROM.
See HELP command for more info.
OSv114sd.zip contains the object files to be loaded onto the SD card.
OSv114sc.zip contains the source files
V1.11 EEPROM Boot Files...
BOOT05M0.eep (5MHz PLL16 SD on P0..3)
BOOT10M0.eep (10MHz PLL8 SD on P0..3)
BOOTP8X2.eep (P8XBlade2: 12MHz PLL8 SD on P12..15)
Select one of these for your Board, program into your EEPROM. For different board configurations, build from the source using instructions from a few posts back.
V1.11 also displays SD volume label, and fixes a typo. V1.10 can still be used.
Note the EEPROM does not need to be reprogrammed from previous versions. Just overwrite the new SD files to your SD Card for the latest OS version 1.14.
Enjoy :)
Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
Website: www.clusos.com
Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
Website: www.clusos.com
Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
For those people, there is another way rather than re-programming the EEPROM.
Format your microSD card, preferably FAT32 these days, else FAT16.
Copy the OSv114sd.zip file (from 3 posts back) to your PC. Unzip them and copy those files to your microSD card.
Copy the bitmap files from the Instructables article to your microSD card.
Copy or Rename your POV binary file (the runtime file you would be programming into the EEPROM) to _BOOT_P1.BIN and then copy this file to your microSD card.
Now when my OS boots, it will search for the _BOOT_P1.BIN file, and if it finds this file, it will run it instead of my OS.
Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
Website: www.clusos.com
Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)