GUI terminals would be nice.· However, there is a lot of basic stuff needed first before a remote GUI interface could be implemented.· I would be interested in getting some information on OS9.
I do plan on adding some scripting capability to the shell.· This will allow it to run a startup script to set the path and maybe load some drivers.
I have mostly been working with FSRW trying to add directory support.· I can now CD into a directory and create files in it.· I can also create files that act like a directory.· I just need to change the attributes so it looks more like a standard FAT directory.
I'm hoping to post a new and improved version of the OS in a few days.
jazzed said...
@humanoido, what shell do you prefer? I suppose bourne shell would be easiest to implement.
jazzed: the screen image shows exactly what I want for the Propeller chip. Whatever it takes to implement, extra memory, prop coprocessor, etc., it would be a revelation.
I added a few things to spinix so I thought I would post version 0.14.· I figured out how to add subdirectories to FSRW so I added routines to create a directory and change from one directory to another.· I also added routines to modify the attibute bits and to rename files.· I used the same pointers that FSRW used for the root directory, so this restricts subdirectories to the first 2 GB of the SD card.· The subdirectories are also restricted to a single cluster in size.· A single 32K cluster can hold 1024 directory entries.· I'll fix this in the future to be more flexible.
I added a few more programs to the bin directory.· I added "more" and "chmod", and I fixed mv, cd, mkdir and cp.· I moved the diagnostic commands out of the shell and put it in a program called diag.· Run diag and type help to see the commands.· I added the capability to run simple script files from the shell.· A script file must contain the characters #she at the beginning of the file.· Spin executable programs must contain the letters SPIN at the begininng of a binary executable file.· This is done by setting _xinfreq = $4E495053 in the Spin source file.
The "x" attribute bit must be set to execute a script file or Spin program.· I map the FAT archive bit to the execute bit.· I noticed that that's how the bits are mapped between·the linux and Windows machines at work.
I have attached two zip files.· The spinix014_bin.zip file contains only the binary files.· The spinix014.zip file contains all of the source plus the binary files.· Only the binary files are needed to install spinix on a Prop.· The bootsd.binary file should be programmed into the Prop's EEPROM.· The contents of the "files" directory should be copied to the root directory of a blank SD card.· The "bin" directory and it contents must also be copied.· The root directory of the SD card will contain the three files shell, loadi2c and startup, and it will also contain the subdirectory "bin".
The first time you boot up spinix it will prompt for the pin numbers of the four SD lines.· This will be written back into the EEPROM for subsequent bootups.· The pin configuration can be changed by hitting the ESC key at bootup.
After bootup type the "set" command to see the aliases that have been initialized.· These were set up by the startup script.· Type "cat startup" to see the contents of the startup file.· You can use "ed" to edit the startup script, or you can create another script file.· Script files must start with #she.
I also added the "kill" command.· Type a "ps" command to see the processes that are running.· Look for the I2C Driver, and you can kill that process.· The I2C driver is used by the boot program to write the SD card pin settings, and it is used by some of the commands in the diag utility.· You can reload the I2C driver by running loadi2c.· Run ps to see how the process list is changed by kill and loadi2c.· Note that the ps program also appears in the list of processes.
Dave
Post Edited (Dave Hein) : 7/19/2010 4:21:14 AM GMT
I've been trying to make spinix014 work. The bootsd code works, but all I get is "~" after that and no response if I enter a command like "ls". Any ideas on debugging this?
The "~" means that it could not malloc enough memory to run the shell program. If you use the binary files I built you should be able to run spinix OK. If you have to rebuild the binary files you'll need to use BST and enable all the optimizations to save memory.
The problem with the way version 14 boots is that boot program and the shell must fit in memory at the same time. The shell then kills the boot program to free up memory. I have a later version where I moved the loader to the fileio process. In the later version, the boot program requests the resident loader to terminate the boot program and then load the shell.
I got sidetracked for a while working on the Spin bytecode assembler, which I got working. However, then I got sidetracked on a completely unrelated project, and I never posted my updates. I'll try to get the updates posted today or tomorrow.
Here is version 0.18, which is the latest version I have from about 3 weeks ago. You should copy the contents of the "Files" directory to the root directory of your SD card. I noticed that I have later versions of "shell" and "loadi2c" at the top level directory, so you may want to use those files instead of the older copies that are in the "Files" directory.
I'm sorry if this is confusing, but that's how I left it the last time I worked on it. I don't have my Prop here at work, so I can't test it here. I'll check it when I get home tonight.
I also have spasm in this zipfile, which is the Spin bytecode assembler I was working on. However, it needs some other files that I have on my SD card. I need to clean all that up and post a new version with all the files.
Let me know if you have any problems with version 0.18.
Note, you will need to set the archived bit on all the binaries to be able to run them. The archived bit is used as the executable attribute under spinix. This always get's set when I drag files to the SD card using Windows, but there may be cases where it doesn't get set. The shell will run without the executable bit, but none of the other programs will.
What's the biggest program possible to run? I see diag is 6700+ bytes and while running diag, malloc returns 7000+ free.
One thing to consider would be adding a personalization file to the bootsd build something like pindefs.spin. I always use 115200 on serial comm for example.
I'm not sure what you mean by the archive bit. Do I have control over that in linux? All the files/bin contents have -rw-r--r--. Of course spinix ls shows -rwx.
The archive bit is bit 5 in the FAT attribute byte. It is/was used by backup programs to tag files that have been backed up. Incremental back ups would not include files that already had the archive bit set. There are some issues with this method, and I think that most backup programs do not rely on this bit anymore.
We have Linux and Windows machines at work. If I look at the attributes of a file from Linux and Windows I see that the archive bit in Windows is intepreted as the executable bit in Linux. I decided to adopt the same convention for spinix.
With the shell running there is a little less than 14,000 bytes available. spasm is 18,000 bytes, and you will get a message that there is not enough memory if you try to run it. The shell takes up about 8,000 bytes, so without it running there are 22,000 bytes available.
I added a special "&&" operator to kill the shell and execute a program. You can run spasm by typing "spasm &&". Without any command line parameters spasm will print a "usage" message and then exit. spasm tells spinix to reload the shell when it exits.
You can also do this with the diag program. Type "diag &&" and then run "ps". You will see that the shell is no longer running. Make sure you reload the shell before exiting diag. diag doesn't automatically restart the shell.
The pindefs.spin file is a good idea. The values could be changed later in the EEPROM if needed, just like I currently do for the SD pins assignments.
I found a few problems with version 0.18, so I am posting 0.19 here. I included the files for spasm, but it's not quite ready for prime time. It will assemble the file hello.spa and produce an executable file named hello.bin.
spasm must be run using the "&&" operator, which kills the shell before executing it. The command-line parameters are contained in the shell's memory space, and I haven't implemented support for passing the command-line parameters when the shell is killed. So I have hardcoded the input file in spasm to be "hello.spa" for now.
You have to do a "chmod +x hello.bin" to be able to execute it. It will print out "Hello World" and then spin in an infinite loop. I haven't added the code to hello.spa to properly exit when done.
I finally realized that with the Prop Plug (and maybe other USB port devices) that flow control must be NOT set to Hardware. Now I'm happily using RB and Hyperterm from a PC for ymodem file transfers. Maybe I can get minicom to work also.
How hard would it be to create a load/run program that would allow a binary to take over the chip completely? I'm hoping to launch large external memory programs for example after download using ymodem.
I know you can kill the shell with "program.bin &&" but that still looks for a "SPIN" signature at address 0 and some memory is still used by the O/S.
Have a look at Zogs run_zog.spin. That has a loader in PASM in a COG that moves things around in HUB memory a bit, like the ZPU executable, and the starts a Zog interpreter in the same Cog. End result being that the entire HUB RAM is given over to the ZPU executable and only one Cog is running.
Ultimately I want run_zog to be workable with external memory ZPU execution.
Not sure if that's relevant to Spinix and ext RAM experiments, just a thought.
How hard would it be to create a load/run program that would allow a binary to take over the chip completely? I'm hoping to launch large external memory programs for example after download using ymodem.
I know you can kill the shell with "program.bin &&" but that still looks for a "SPIN" signature at address 0 and some memory is still used by the O/S.
It should be fairly easy to load and run a normal Spin program as long as it is less than 22K in size. The kernel would load the binary into memory stating at location zero, kill all the cogs, and then run the program. It will be more complicated if the binary is larger than 22K. That would require an additional step where a special PASM loader program would have to be loaded first.
It's been a while since I worked on spinix, but I recently added the capability to load PropGCC programs and stand-alone Spin programs. If you have a Prop board with an SD card give it a try. I currently don't support the C3 card, but I hope to add that soon. Look at the readme.txt file in the zip file for details on installing spinix.
The attached version of spinix now supports the C3 board. Specify the SD pin numbers 10, 11, 9 and 25 when using the C3 board. The serial port operates at 115,200 baud.
Dave: I have just been having a look at what you have achieved with Spinix. You certainly have done a lot of work here. Seems I should have looked at this a couple of months ago.
I have been working on an OS version using Dracs KyeDos3 as a basis so that I could use Kye's SD driver. I like all the upper support for FAT16 & FAT 32 and subdirectories. I broke the dos into modules like you have done, and then removed all the common code into a separate include file (and use Andy's PreSpin program to compile). I would like to ultimately replace the SD pasm code with lonesocks because it is faster. However, your code is way more advanced and where I would like to head.
Seems to me that I may be better off extending your work rather than doing my own thing.
So, would you like to explain how you are using (allocating) hub memory? How much hub is used for the OS and what is this used for?
BTW I love your use of the clkfreq to declare SPIN to identify an object. Perhaps this could be expanded so the OS knows when to perform the "&&" function automatically.
The src directory in the zip file contains all the source for the OS and the Spinix apps. The file sysdefs.spin defines the memory locations that are used for the driver mailboxes. It also defines the location of the process table, or "cogtable". The process table has one entry per cog, for a total of 8 entries. Each entry consist of 24 bytes, and stores information about the process type, name, starting address of hub memory used and the amount of hub memory used.
Hub memory is controlled by the heap manager in cmalloc.spin. Memory is allocated from the high end of memory toward the low end. The kernel sits in high memory, just below the process table and mailboxes. The shell is normally located just below the kernel. The kernel provides file I/O as well as run and kill functions. The shell provides the user interface. Apps are normally loaded below the shell, unless the && modifier is used, which unloads the shell to provide more memory. After the app exits, the kernel will reload the shell if needed.
Apps can be run in a background mode by typying a single & character on the command line. A user can load several background apps until there are either no more cogs available or no memory available.
I am thinking of making the && mode the standard mode of operation. It adds a short pause of less than a second after an app completes, and the shell is reloaded. I'll probably make this mode configurable.
Thanks Dave. Am I correct in assuming that an app need not necessarily be loaded into the bottom of hub. i.e. it is relocatable?
I had looked at various source modules including the sysdefs. The kernel doesn't look like it takes much space. The shell does take a bit more though you can free it if required.
I will run this up and give it a try. I presume to change the clock I only need to recompile the eeprom binary? I will try this first and if necessary I will change xtal back to 5MHz.
A Spin app can be loaded anywhere in memory, and not just at location 0. The relocatable attribute of Spin binaries is fundamental to Spinix. That is why the kernel and shell can run while the app is running. A C app is more restrictive, and it must run at location 0.
The kernel is currently 8,880 bytes in size. The shell is 8,024 bytes. When they are running each one is allocated an additional 800 bytes for the stack. The shell can be unloaded when running an app, but the kernel must remain in memory. Large programs can be run in a stand-alone mode where they have access to the entire hub memory. The only limitations on stand-alone programs is that they must be less than 31.5K in size and they have to be built with a clkfreq of 80 MHz. The 31.5K limit isn't a practical limitation since programs need space for the stack. I'll remove the 80MHz limitation in the next update. As long as you don't run stand-alone programs you currently just have to rebuild bootsd for a different clock rate, and burn it into the EEPROM.
I've uploaded Spinix 0.72, and attached it to this post. I cleaned up the ls command, and added -a and -e options. The -a option will show the hidden files starting with "," or "_". The -e option displays the file type of executable files.
I also added support for terminal programs that don't do an automatic line-feed with a carriage-return. Line-feeds can be enabled and disabled with the "linefeed" command by typing "linefeed on" or "linefeed off". The default is "linefeed off". If you need the line-feeds enable you should add it to the _startup file using ed as follows:
ed _startup
a
linefeed on
.
w
q
I also improved the operation of stand-alone apps by passing some system information to them when they are started. I pass the line-feed state, the SD pin numbers, and the current directory to them. This information is contained directly after the last argv parameter when using the standard (argc, argv) arguments.
I ported a more advanced version of the Spasm assembler to Spinix. This version supports a few more Spin features than the previous one.
EDIT: For those not familiar with the ed editor, an easier way to add "linefeed on" to the _startup file would be as follows:
It just happens that I've been working on adding vi and a more complete ed editor to Spinix for the past couple of days. I worked on the vi editor several months ago, but I never posted it. I updated it to make it work with Spinix. I added a "T" command to set the terminal mode for either the PST, ANSI or dumb terminal. It currently doesn't use many of the features of the PST or ANSI terminal, but it works slightly better than in the dumb mode where it redraws the entire screen on each keypress.
The different terminal modes are selected by typing ":Tn", where n is 0 for dumb terminals, 1 for PST and 2 for ANSI. The number of lines are set by typing "Vn", where n is the number of lines on the screen.
The ed editor is now much more complete, and it has a psuedo-visualization mode where it prints the lines before and after the current line. This is enabled with the "V" command. I renamed the old ed editor to ted, for Tiny EDitor.
Some other new features are as follows:
- wildcard filename expansion using the "*" and "?" characters for echo, ls, rm, cp and cat
- Added dos2unix and unix2dos
- Added a simple version of grep
- Added !string to executed the previous command that matches "string"
I've updated Spinix to version 0.90. This version contains the following new features:
- Added the Spinit Spin compiler to the spasm directory
- Improved ANSI support for the vi editor
- Added the "." repeat command to vi
- Fixed the "/" and "?" text search commands in vi
- Fixed a few problem in the Spasm assembler
- Added console terminal type and number of lines to the config command
The biggest change is the addition of the Spinit Spin compiler. This compiler is restricted to simple Spin programs, but it can produce useable programs. It outputs Spasm code, which can be assembled with the Spasm assembler. It does not support PASM code, but that will come in a future update. Also, programs must consist of a single object. Multiple objects will be supported later with a Spin object linker utility.
Please let me know if you see any problems with the vi ANSI support. It works OK with the Windows Hyper Terminal and Putty. Make sure the ^H backspace is enabled when using Putty.
Some time ago, I re-implemented a compiler-compiler called Meta2 for the Propeller under Sphinx. It produced Spin source and would compile itself. In the past, it's been used to write a simple Pascal compiler and an Algol-W compiler, so it's potentially robust. It can produce LMM assembly language with a few changes or even Spin byte codes in assembly form and might be a nice addition to Spinix. I don't have time now to work on it, but will probably have some time in 2 or 3 months. A linker will be very handy
Comments
I do plan on adding some scripting capability to the shell.· This will allow it to run a startup script to set the path and maybe load some drivers.
I have mostly been working with FSRW trying to add directory support.· I can now CD into a directory and create files in it.· I can also create files that act like a directory.· I just need to change the attributes so it looks more like a standard FAT directory.
I'm hoping to post a new and improved version of the OS in a few days.
@humanoido, what shell do you prefer? I suppose bourne shell would be easiest to implement.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-- Terry
http://forums.parallax.com/showthread.php?p=901234
http://forums.parallax.com/showthread.php?p=898075
I added a few more programs to the bin directory.· I added "more" and "chmod", and I fixed mv, cd, mkdir and cp.· I moved the diagnostic commands out of the shell and put it in a program called diag.· Run diag and type help to see the commands.· I added the capability to run simple script files from the shell.· A script file must contain the characters #she at the beginning of the file.· Spin executable programs must contain the letters SPIN at the begininng of a binary executable file.· This is done by setting _xinfreq = $4E495053 in the Spin source file.
The "x" attribute bit must be set to execute a script file or Spin program.· I map the FAT archive bit to the execute bit.· I noticed that that's how the bits are mapped between·the linux and Windows machines at work.
I have attached two zip files.· The spinix014_bin.zip file contains only the binary files.· The spinix014.zip file contains all of the source plus the binary files.· Only the binary files are needed to install spinix on a Prop.· The bootsd.binary file should be programmed into the Prop's EEPROM.· The contents of the "files" directory should be copied to the root directory of a blank SD card.· The "bin" directory and it contents must also be copied.· The root directory of the SD card will contain the three files shell, loadi2c and startup, and it will also contain the subdirectory "bin".
The first time you boot up spinix it will prompt for the pin numbers of the four SD lines.· This will be written back into the EEPROM for subsequent bootups.· The pin configuration can be changed by hitting the ESC key at bootup.
After bootup type the "set" command to see the aliases that have been initialized.· These were set up by the startup script.· Type "cat startup" to see the contents of the startup file.· You can use "ed" to edit the startup script, or you can create another script file.· Script files must start with #she.
I also added the "kill" command.· Type a "ps" command to see the processes that are running.· Look for the I2C Driver, and you can kill that process.· The I2C driver is used by the boot program to write the SD card pin settings, and it is used by some of the commands in the diag utility.· You can reload the I2C driver by running loadi2c.· Run ps to see how the process list is changed by kill and loadi2c.· Note that the ps program also appears in the list of processes.
Dave
Post Edited (Dave Hein) : 7/19/2010 4:21:14 AM GMT
I've been trying to make spinix014 work. The bootsd code works, but all I get is "~" after that and no response if I enter a command like "ls". Any ideas on debugging this?
Thanks,
--Steve
The problem with the way version 14 boots is that boot program and the shell must fit in memory at the same time. The shell then kills the boot program to free up memory. I have a later version where I moved the loader to the fileio process. In the later version, the boot program requests the resident loader to terminate the boot program and then load the shell.
I got sidetracked for a while working on the Spin bytecode assembler, which I got working. However, then I got sidetracked on a completely unrelated project, and I never posted my updates. I'll try to get the updates posted today or tomorrow.
Dave
Here is version 0.18, which is the latest version I have from about 3 weeks ago. You should copy the contents of the "Files" directory to the root directory of your SD card. I noticed that I have later versions of "shell" and "loadi2c" at the top level directory, so you may want to use those files instead of the older copies that are in the "Files" directory.
I'm sorry if this is confusing, but that's how I left it the last time I worked on it. I don't have my Prop here at work, so I can't test it here. I'll check it when I get home tonight.
I also have spasm in this zipfile, which is the Spin bytecode assembler I was working on. However, it needs some other files that I have on my SD card. I need to clean all that up and post a new version with all the files.
Let me know if you have any problems with version 0.18.
Note, you will need to set the archived bit on all the binaries to be able to run them. The archived bit is used as the executable attribute under spinix. This always get's set when I drag files to the SD card using Windows, but there may be cases where it doesn't get set. The shell will run without the executable bit, but none of the other programs will.
Dave
What's the biggest program possible to run? I see diag is 6700+ bytes and while running diag, malloc returns 7000+ free.
One thing to consider would be adding a personalization file to the bootsd build something like pindefs.spin. I always use 115200 on serial comm for example.
I'm not sure what you mean by the archive bit. Do I have control over that in linux? All the files/bin contents have -rw-r--r--. Of course spinix ls shows -rwx.
I look forward to trying spasm.
Thanks,
--Steve
We have Linux and Windows machines at work. If I look at the attributes of a file from Linux and Windows I see that the archive bit in Windows is intepreted as the executable bit in Linux. I decided to adopt the same convention for spinix.
With the shell running there is a little less than 14,000 bytes available. spasm is 18,000 bytes, and you will get a message that there is not enough memory if you try to run it. The shell takes up about 8,000 bytes, so without it running there are 22,000 bytes available.
I added a special "&&" operator to kill the shell and execute a program. You can run spasm by typing "spasm &&". Without any command line parameters spasm will print a "usage" message and then exit. spasm tells spinix to reload the shell when it exits.
You can also do this with the diag program. Type "diag &&" and then run "ps". You will see that the shell is no longer running. Make sure you reload the shell before exiting diag. diag doesn't automatically restart the shell.
The pindefs.spin file is a good idea. The values could be changed later in the EEPROM if needed, just like I currently do for the SD pins assignments.
spasm must be run using the "&&" operator, which kills the shell before executing it. The command-line parameters are contained in the shell's memory space, and I haven't implemented support for passing the command-line parameters when the shell is killed. So I have hardcoded the input file in spasm to be "hello.spa" for now.
You have to do a "chmod +x hello.bin" to be able to execute it. It will print out "Hello World" and then spin in an infinite loop. I haven't added the code to hello.spa to properly exit when done.
Cheers.
--Steve
I know you can kill the shell with "program.bin &&" but that still looks for a "SPIN" signature at address 0 and some memory is still used by the O/S.
Thanks,
--Steve
Have a look at Zogs run_zog.spin. That has a loader in PASM in a COG that moves things around in HUB memory a bit, like the ZPU executable, and the starts a Zog interpreter in the same Cog. End result being that the entire HUB RAM is given over to the ZPU executable and only one Cog is running.
Ultimately I want run_zog to be workable with external memory ZPU execution.
Not sure if that's relevant to Spinix and ext RAM experiments, just a thought.
It should be fairly easy to load and run a normal Spin program as long as it is less than 22K in size. The kernel would load the binary into memory stating at location zero, kill all the cogs, and then run the program. It will be more complicated if the binary is larger than 22K. That would require an additional step where a special PASM loader program would have to be loaded first.
I have been working on an OS version using Dracs KyeDos3 as a basis so that I could use Kye's SD driver. I like all the upper support for FAT16 & FAT 32 and subdirectories. I broke the dos into modules like you have done, and then removed all the common code into a separate include file (and use Andy's PreSpin program to compile). I would like to ultimately replace the SD pasm code with lonesocks because it is faster. However, your code is way more advanced and where I would like to head.
Seems to me that I may be better off extending your work rather than doing my own thing.
So, would you like to explain how you are using (allocating) hub memory? How much hub is used for the OS and what is this used for?
BTW I love your use of the clkfreq to declare SPIN to identify an object. Perhaps this could be expanded so the OS knows when to perform the "&&" function automatically.
Hub memory is controlled by the heap manager in cmalloc.spin. Memory is allocated from the high end of memory toward the low end. The kernel sits in high memory, just below the process table and mailboxes. The shell is normally located just below the kernel. The kernel provides file I/O as well as run and kill functions. The shell provides the user interface. Apps are normally loaded below the shell, unless the && modifier is used, which unloads the shell to provide more memory. After the app exits, the kernel will reload the shell if needed.
Apps can be run in a background mode by typying a single & character on the command line. A user can load several background apps until there are either no more cogs available or no memory available.
I am thinking of making the && mode the standard mode of operation. It adds a short pause of less than a second after an app completes, and the shell is reloaded. I'll probably make this mode configurable.
I had looked at various source modules including the sysdefs. The kernel doesn't look like it takes much space. The shell does take a bit more though you can free it if required.
I will run this up and give it a try. I presume to change the clock I only need to recompile the eeprom binary? I will try this first and if necessary I will change xtal back to 5MHz.
The kernel is currently 8,880 bytes in size. The shell is 8,024 bytes. When they are running each one is allocated an additional 800 bytes for the stack. The shell can be unloaded when running an app, but the kernel must remain in memory. Large programs can be run in a stand-alone mode where they have access to the entire hub memory. The only limitations on stand-alone programs is that they must be less than 31.5K in size and they have to be built with a clkfreq of 80 MHz. The 31.5K limit isn't a practical limitation since programs need space for the stack. I'll remove the 80MHz limitation in the next update. As long as you don't run stand-alone programs you currently just have to rebuild bootsd for a different clock rate, and burn it into the EEPROM.
I also added support for terminal programs that don't do an automatic line-feed with a carriage-return. Line-feeds can be enabled and disabled with the "linefeed" command by typing "linefeed on" or "linefeed off". The default is "linefeed off". If you need the line-feeds enable you should add it to the _startup file using ed as follows:
ed _startup
a
linefeed on
.
w
q
I also improved the operation of stand-alone apps by passing some system information to them when they are started. I pass the line-feed state, the SD pin numbers, and the current directory to them. This information is contained directly after the last argv parameter when using the standard (argc, argv) arguments.
I ported a more advanced version of the Spasm assembler to Spinix. This version supports a few more Spin features than the previous one.
EDIT: For those not familiar with the ed editor, an easier way to add "linefeed on" to the _startup file would be as follows:
echo linefeed on >>_startup
The different terminal modes are selected by typing ":Tn", where n is 0 for dumb terminals, 1 for PST and 2 for ANSI. The number of lines are set by typing "Vn", where n is the number of lines on the screen.
The ed editor is now much more complete, and it has a psuedo-visualization mode where it prints the lines before and after the current line. This is enabled with the "V" command. I renamed the old ed editor to ted, for Tiny EDitor.
Some other new features are as follows:
- wildcard filename expansion using the "*" and "?" characters for echo, ls, rm, cp and cat
- Added dos2unix and unix2dos
- Added a simple version of grep
- Added !string to executed the previous command that matches "string"
Version 0.80 is attached below.
Rick.
- Added the Spinit Spin compiler to the spasm directory
- Improved ANSI support for the vi editor
- Added the "." repeat command to vi
- Fixed the "/" and "?" text search commands in vi
- Fixed a few problem in the Spasm assembler
- Added console terminal type and number of lines to the config command
The biggest change is the addition of the Spinit Spin compiler. This compiler is restricted to simple Spin programs, but it can produce useable programs. It outputs Spasm code, which can be assembled with the Spasm assembler. It does not support PASM code, but that will come in a future update. Also, programs must consist of a single object. Multiple objects will be supported later with a Spin object linker utility.
Please let me know if you see any problems with the vi ANSI support. It works OK with the Windows Hyper Terminal and Putty. Make sure the ^H backspace is enabled when using Putty.