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

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

124

Comments

  • msrobots wrote: »
    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).

    dgately

  • Cluso99 wrote: »
    OOPS! Sorry guys,
    Here are the EEPROM versions

    Thanks, Cluso!
  • Cluso99Cluso99 Posts: 18,066
    Boot program for EEPROM v1.10

    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.
  • Cluso99Cluso99 Posts: 18,066
    Propeller OS Version 1.00

    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:>
    
  • Cluso99Cluso99 Posts: 18,066
    Cluso99 wrote: »
    Propeller OS Version 1.00

    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:>
    

  • Cluso99Cluso99 Posts: 18,066
    How to write an OS program

    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.
  • Cluso99Cluso99 Posts: 18,066
    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.
  • Cluso99Cluso99 Posts: 18,066
    edited 2016-03-04 10:21
    OS V1.10 Release

    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.
  • Thanks for doing this. Sphinx originally could only handle FAT16 and 2GB and smaller cards are getting scarcer.

    "very small programs" ... How small?
  • Cluso99Cluso99 Posts: 18,066
    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.
  • Cluso99Cluso99 Posts: 18,066
    Dave, you did a really nice job with Spinix.

    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.
  • Cluso99Cluso99 Posts: 18,066
    Dave Hein wrote: »
    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.

  • Cluso99Cluso99 Posts: 18,066
    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)

    Unzip and copy to your SD card. (replace = yes)
  • Cluso99Cluso99 Posts: 18,066
    Version V1.14...

    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 :)
  • A propeller based DOSish OS, that is something to commend. Nice work.
  • Cluso99Cluso99 Posts: 18,066
    Thanks David. Best of luck going off-line. Not something I would like to do anymore.
  • Cluso99Cluso99 Posts: 18,066
    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.
  • May I present my own fork of this 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.
  • Cluso99Cluso99 Posts: 18,066
    Fantastic :smiley::smiley::smiley:
    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.

  • Wuerfel_21Wuerfel_21 Posts: 4,351
    edited 2019-05-01 03:22
    Cluso99 wrote: »
    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.
    Cluso99 wrote: »
    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 :smile: )

    Cluso99 wrote: »
    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)
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-05-01 05:50
    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.


  • Cluso99Cluso99 Posts: 18,066
    edited 2019-05-01 04:57
    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.
  • hinvhinv Posts: 1,252
    edited 2019-05-04 04:35
    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 :smile: )

    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!
  • hinvhinv Posts: 1,252
    Cluso99 wrote: »
    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.

    What about dual 20MHz Quad SPI feeding whole bytes at a time like http://www.rayslogic.com/Propeller/Products/FlashPoint/FlashPoint.htm ?

  • Cluso99Cluso99 Posts: 18,066
    Supercalc was what launched the Apple ][ onto the desks of accountants. This was not on CPM back then although that did come rather quickly.

    With SRAM we were able to emulate a 4MHz Z80. You wont get near that with any other method.
  • 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.
  • Cluso99Cluso99 Posts: 18,066
    The problem is that the additional instructions required to test for cache is more than the savings.
Sign In or Register to comment.