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.
Changes include (I think there's at least a couple that are worth merging back):
- Replaced almost all unsafe stringCopy/stringAppend functions with safe versions
- Default STDOUT is now a new 40x25 NTSC COLOUR TV driver
- QWERTZ (german) PS/2 Keyboard driver
- Better _CMD_: Can't erase over the prompt anymore, lol
- Optimized DIR (over 600% faster sorting)
- Improved VER: Paginate credits, show MIT license, make Bil Herd proud
- New build system: Works on Windows and Linux, requires no user input, compiles entire OS in under 3 seconds, breaks automatically on errors
- Organized files into folders (lib, modules,modules_light,help,temp,out)
- New HELP system: Instead of reading a long file with all the commands, HELP now shows a compiled-in "Quick help" or a specific module's help string
- Modules now have a "Footer" (like a header, but at the end of the file) that contains the ABI version, a timestamp, a build description and the aforementioned HELP string.
- Returning -2 from executeCommand triggers display of the HELP string
- OFF command for shutting down the OS
- RUN can now preload a 23LC1024 if a RAM file with the same name as the BIN file exists
- "RUN SOMETHING" can now be abbreviated to "#SOMETHING"
- A bunch of other minor tweaks, bugfixes and optimizations
- Some things I forgot
Note that I haven't tested all the included modules (especially the CP/M related ones, as I can't figure out where to get the latest and greatest in terms of Z80 emulation), but I don't see why they shouldn't work.
Also note that I versioned it "1.14.1" when "1.15" or "2.0" would have been more appropriate, but I don't know if we want to keep our version numbers in sync.
Fantastic
Go right ahead. It's MIT and based on lots of others work too. I suggest you call it V2.0 so if I do any updates to my code I have somewhere to go, but I'm more likely to look at extending your code since it's now doing a lot more.
There have always been lots of things I wanted to do.
Redoing Kye's SD driver was one of them as it restricted a lot of what I wanted to do.
Speed to me was never an issue, and compilation was done with a batch file and homespun, so no problems for me.
Always other things to do meant never enough hours in the day
Unfortunately the compiler was never really put to much testing. I needed to dissect Michael Park's Sphinx to make it work under my OS. Hopefully you can give it some more love and attention.
The other thing on my agenda was to recompile ZiCog & CPM to run in say 24KB of hub instead of the external SRAM. This way we could switch back and forth with ease without requiring additional hardware and limiting the I/O. Another never enough time
There are two Z80 emulations. The first is ZiCog by heater and a little by me. Code is on the ZiCog forum (there are a couple of threads) and if not, then I have a copy. The other is QZ80 by Juergen Buchmueller which also implements the few Z80 instructions that heater missed. I have his code but it doesn't run on any of my boards and I never researched why. If you need any help just sing out.
One last thing...
You will note that the STDIN and STDOUT drivers can be substituted without the OS realising. I presume you've done this with the color NTSC driver and keyboard.
Redoing Kye's SD driver was one of them as it restricted a lot of what I wanted to do.
What issues were you having in particular? I have a version with rudimentary LFN support kicking around somewhere and I think the read speed could be easily increased by dropping in a 20Mhz read routine.
The other thing on my agenda was to recompile ZiCog & CPM to run in say 24KB of hub instead of the external SRAM. This way we could switch back and forth with ease without requiring additional hardware and limiting the I/O. Another never enough time
CP/M in 24K sounds not good. I don't think they made CP/M computers with less than 64K? Gotta have that 128K for those big spreadsheets. I wonder how well serial SRAM would do (compared to a C128 with it's 2Mhz Z80 on a bus shared with the video chip )
You will note that the STDIN and STDOUT drivers can be substituted without the OS realising. I presume you've done this with the color NTSC driver and keyboard.
Infact, there's a prompt before entering _CMD_, where if you press X, it kills the TV and keyboard and starts up the serial driver instead (which has been modified to ignore the special control codes the TV driver takes)
I wanted to split the SD routines differently so the base could stay resident in a better form. Its a bit hazey now as ive been doing P2 SD.
A lot of the spin is intertwined and the breakup needs to be better split.
CPM used to run originally in 8KB 16KB RAM and maybe 4KB ROM IIRC. 64KB was a real luxury back in the day. Bank switching, while present in CPM2.2, wasn’t all that significant until CPM3. IIRC the Msoft CPM card for the Apple //e and /// had 64KB of which the top was ROM. Used it back in the mid 80’s with the 5MB Profile HDD.
Serial SRAM will not cut it
Regarding the terminal, it should be possible to reload/restart the cog(s) with new drivers without needing to reload the OS. Being able to switch using a key sequence is also a great idea.
Always wanted to spend some time tweeking the Z80 ZiCog to increase the emulation speed. Never had the time tho. I used SRAM driven directly from P1 pins without latches after my first latched design. That’s why I built the RamBlade. BTW it also runs Catalina C with 512KB XMM.
There’s no way serial will perform anywhere near satisfactory IMHO.
CP/M in 24K sounds not good. I don't think they made CP/M computers with less than 64K? Gotta have that 128K for those big spreadsheets. I wonder how well serial SRAM would do (compared to a C128 with it's 2Mhz Z80 on a bus shared with the video chip )
Did you have full spreadsheet capabilities on CPM? All the way back then? I would really love a spreadsheet that I could use in the palm of my hand. I remember back in the day when I really loved my HP48SX. RPN was quite a steup up from the old TI calculators. Then I got a HP200LX, with Lotus123, and I was hooked. It was awesome! If you could get me that kind of functionality again, on a little prop, I would be quite pleased!
Always wanted to spend some time tweeking the Z80 ZiCog to increase the emulation speed. Never had the time tho. I used SRAM driven directly from P1 pins without latches after my first latched design. That’s why I built the RamBlade. BTW it also runs Catalina C with 512KB XMM.
There’s no way serial will perform anywhere near satisfactory IMHO.
Potentially caching? i.e. have a 16K cache of, say, 16 byte cache lines in Hub and if that misses, fetch/store from whatever slow memory there is. Potentially optimize string copies (8080 / Z80 has those, right???) or smth.
Comments
Here are the EEPROM versions
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.
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...
_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...
Here are the StdIn calls... 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.
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.
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.
"very small programs" ... How small?
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???
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.
_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)
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
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.
Changes include (I think there's at least a couple that are worth merging back):
- Replaced almost all unsafe stringCopy/stringAppend functions with safe versions
- Default STDOUT is now a new 40x25 NTSC COLOUR TV driver
- QWERTZ (german) PS/2 Keyboard driver
- Better _CMD_: Can't erase over the prompt anymore, lol
- Optimized DIR (over 600% faster sorting)
- Improved VER: Paginate credits, show MIT license, make Bil Herd proud
- New build system: Works on Windows and Linux, requires no user input, compiles entire OS in under 3 seconds, breaks automatically on errors
- Organized files into folders (lib, modules,modules_light,help,temp,out)
- New HELP system: Instead of reading a long file with all the commands, HELP now shows a compiled-in "Quick help" or a specific module's help string
- Modules now have a "Footer" (like a header, but at the end of the file) that contains the ABI version, a timestamp, a build description and the aforementioned HELP string.
- Returning -2 from executeCommand triggers display of the HELP string
- OFF command for shutting down the OS
- RUN can now preload a 23LC1024 if a RAM file with the same name as the BIN file exists
- "RUN SOMETHING" can now be abbreviated to "#SOMETHING"
- A bunch of other minor tweaks, bugfixes and optimizations
- Some things I forgot
Note that I haven't tested all the included modules (especially the CP/M related ones, as I can't figure out where to get the latest and greatest in terms of Z80 emulation), but I don't see why they shouldn't work.
Also note that I versioned it "1.14.1" when "1.15" or "2.0" would have been more appropriate, but I don't know if we want to keep our version numbers in sync.
Go right ahead. It's MIT and based on lots of others work too. I suggest you call it V2.0 so if I do any updates to my code I have somewhere to go, but I'm more likely to look at extending your code since it's now doing a lot more.
There have always been lots of things I wanted to do.
Redoing Kye's SD driver was one of them as it restricted a lot of what I wanted to do.
Speed to me was never an issue, and compilation was done with a batch file and homespun, so no problems for me.
Always other things to do meant never enough hours in the day
Unfortunately the compiler was never really put to much testing. I needed to dissect Michael Park's Sphinx to make it work under my OS. Hopefully you can give it some more love and attention.
The other thing on my agenda was to recompile ZiCog & CPM to run in say 24KB of hub instead of the external SRAM. This way we could switch back and forth with ease without requiring additional hardware and limiting the I/O. Another never enough time
There are two Z80 emulations. The first is ZiCog by heater and a little by me. Code is on the ZiCog forum (there are a couple of threads) and if not, then I have a copy. The other is QZ80 by Juergen Buchmueller which also implements the few Z80 instructions that heater missed. I have his code but it doesn't run on any of my boards and I never researched why. If you need any help just sing out.
One last thing...
You will note that the STDIN and STDOUT drivers can be substituted without the OS realising. I presume you've done this with the color NTSC driver and keyboard.
CP/M in 24K sounds not good. I don't think they made CP/M computers with less than 64K? Gotta have that 128K for those big spreadsheets. I wonder how well serial SRAM would do (compared to a C128 with it's 2Mhz Z80 on a bus shared with the video chip
Infact, there's a prompt before entering _CMD_, where if you press X, it kills the TV and keyboard and starts up the serial driver instead (which has been modified to ignore the special control codes the TV driver takes)
A lot of the spin is intertwined and the breakup needs to be better split.
CPM used to run originally in 8KB 16KB RAM and maybe 4KB ROM IIRC. 64KB was a real luxury back in the day. Bank switching, while present in CPM2.2, wasn’t all that significant until CPM3. IIRC the Msoft CPM card for the Apple //e and /// had 64KB of which the top was ROM. Used it back in the mid 80’s with the 5MB Profile HDD.
Serial SRAM will not cut it
Regarding the terminal, it should be possible to reload/restart the cog(s) with new drivers without needing to reload the OS. Being able to switch using a key sequence is also a great idea.
There’s no way serial will perform anywhere near satisfactory IMHO.
Did you have full spreadsheet capabilities on CPM? All the way back then? I would really love a spreadsheet that I could use in the palm of my hand. I remember back in the day when I really loved my HP48SX. RPN was quite a steup up from the old TI calculators. Then I got a HP200LX, with Lotus123, and I was hooked. It was awesome! If you could get me that kind of functionality again, on a little prop, I would be quite pleased!
What about dual 20MHz Quad SPI feeding whole bytes at a time like http://www.rayslogic.com/Propeller/Products/FlashPoint/FlashPoint.htm ?
With SRAM we were able to emulate a 4MHz Z80. You wont get near that with any other method.