KyeDOS - an operating system for the Propeller
Dr_Acula
Posts: 5,484
I thought I would start a new thread for Kyedos rather than hijacking Kye's SD driver thread.
This is Kye's amazing new SD card driver code with a few modifications so it works as an operating system. It is designed to be downloaded to the EEPROM as the core propeller program, from which you can run any other propeller binary file, like playing a movie.
It boots up to a command prompt, and if you type "HELP" it gives the help menu. You can list the directory and run some test commands but the exciting thing is that Kye has greatly speeded up the reboot code, so it is now practical to run other binary files as if they were commands.
As an example, attached is KyeDOS. Now, this almost fills up the memory, and I wanted to add another command to dump out file listings. No problem! I simply wrote a new program called Type (homage to CP/M, but you can rename it to Dump or List or anything if you like). Compile using F8 on the proptool, save it as a binary file, and then rename it ending in .exe. (again, that is not set in stone, and it could be .bin or .com as well).
You can see these command files if you type "dir *.exe" at the command prompt.
Now, just enter "type myfile.txt" or whatever you want to display, and it runs this program, displays the fie, then waits for a keypress, then goes back to KyeDos.
This concept can be extended to any spin program. You can switch video modes easily, or switch from programs that use the keyboard to ones that use the mouse.
Hardware requirements are any board with an sd card. If you don't have a keyboard or vga display, no problem as the program also works via the serial port to any terminal program. There are some values you can enter in the CON section to disable things - eg I would imagine almost everyone would disable the 20x4 LCD as this is using the Dracblade driver. VGA and keyboard are the standard demoboard pinouts, so to get this working all you may need is an sd card and a few 10k pullup resistors.
For those that have been following KyeDOS for a while, the big change here is the speed improvement.
Suggestions and input would be most appreciated. Any help adding more commands would also be most welcome.
This is Kye's amazing new SD card driver code with a few modifications so it works as an operating system. It is designed to be downloaded to the EEPROM as the core propeller program, from which you can run any other propeller binary file, like playing a movie.
It boots up to a command prompt, and if you type "HELP" it gives the help menu. You can list the directory and run some test commands but the exciting thing is that Kye has greatly speeded up the reboot code, so it is now practical to run other binary files as if they were commands.
As an example, attached is KyeDOS. Now, this almost fills up the memory, and I wanted to add another command to dump out file listings. No problem! I simply wrote a new program called Type (homage to CP/M, but you can rename it to Dump or List or anything if you like). Compile using F8 on the proptool, save it as a binary file, and then rename it ending in .exe. (again, that is not set in stone, and it could be .bin or .com as well).
You can see these command files if you type "dir *.exe" at the command prompt.
Now, just enter "type myfile.txt" or whatever you want to display, and it runs this program, displays the fie, then waits for a keypress, then goes back to KyeDos.
This concept can be extended to any spin program. You can switch video modes easily, or switch from programs that use the keyboard to ones that use the mouse.
Hardware requirements are any board with an sd card. If you don't have a keyboard or vga display, no problem as the program also works via the serial port to any terminal program. There are some values you can enter in the CON section to disable things - eg I would imagine almost everyone would disable the 20x4 LCD as this is using the Dracblade driver. VGA and keyboard are the standard demoboard pinouts, so to get this working all you may need is an sd card and a few 10k pullup resistors.
For those that have been following KyeDOS for a while, the big change here is the speed improvement.
Suggestions and input would be most appreciated. Any help adding more commands would also be most welcome.
Comments
Thanks,
Every time the speed gets increased I find that the layout distances get more and more fussy, and less and less of my mottly SD card collection want to play nice.
You are not being sponsored by SanDisk are you ???
I had much wire length issues on SD card's before I added in that case one100nF one 10uF caps as near SD as possible --- and to that Resistors NOT only on used signal pins but on all pins SD use as signals even them not used in Propeller type connection.
I tried all of that, a while ago, on a project. I even found that sticking freezer spray on the Prop could tip the balance as to whether the SD ran or not.
The last go with a modified Dracblade (the one built into a keyboard) I got away with pull ups on all four lines but at the Prop end of the wires rather than the SD end, the wires were about 10 cm long but widely spaced. There is a 0.1uF and a 10uF (SMs) at the PCB edge, again not quite at the SD.
I think that the real problem is that I use such a rag-tag bunch of cards.
On the plus side, Kye's latest code works with more of my SD cards than before. In fact, all of them.
One thing are important 10uF else bigger On SD side as close it as possible. You need think it is one PIC MCPU on board of SD with inbuilt XTal and for stable functioning as all other oscillators it need stable Voltage (Not possible on big length wires.) You need consider that SD even Voltage to write to it that need be stable THAT give with start of writing Voltage fail on entire SD and capacitor are for give it this little time Voltage need to stabilize.
*** New program added - Xmodem for file transfers. ***
I have also modified KyeDOS so that it does not send anything out of the serial port when running an external program, as this was upsetting xmodem.
Xmodem has been tested at 115200 baud, and not all terminal programs can handle this. Teraterm gives occ errors at 38400 and does not work faster than this. Shamcom works talking to the board but does not include xmodem. But Hyperterminal works. Set up for 115200 baud and select "none" for file transfer protocol.
One feature this demonstrates is the simplicity of command line parameters in Kyedos. For xmodem type
XMODEM R MYFILE.TXT
where xmodem is the .exe file to run, R is for Receive (or S for Send) and then the name of the file. The xmodem program then extracts out the parameters.
You need to do this in the right order eg run xmodem first on kyedos, and then use the terminal program to send the file.
For files up to about 50k, it is faster to use xmodem. For larger files, it is generally quicker to remove the sd card and copy directly. Don't forget to hit the reset button when reinserting a card that has been removed so Kyedos can reinitialise the sd card.
In themselves, these programs are not very exciting. However, they demonstrate the concept of getting around the memory limitation of the propeller by splitting things up into manageable pieces.
Xmodem's main use is from within a custom IDE that I am working on that can edit Spin, Pasm and C, both separately and hybridised together. It's most immediate application will be as a way of getting large external memory C programs onto an sd card.
Oh... Yeah... TV...
http://dl.dropbox.com/u/7557533/shared/KyeDOS3_withTV.zip
Here's a slightly patched copy of KyeDOS using a modified AIGeneric driver.
I've tried not to touch the DOS itself too much so that it maintains compatibility.
I'll pretty it up a bit more later, but if you've been using PropDOS, this is a definite upgrade.
OBC
I didn't add TV because I don't have one (my little LCD cheapie won't synch, and I can't boot the kids off my real TV long enough to test it).
So have you added a text driver? How many characters in a line? (If it is less than 80, might need to change a few bits of code so things line up ok).
Is there a new "main" code with TV added?
Just thinking about the changes which would be in these lines (all display text goes out through these two lines, which simplifies adding another display driver)
PUB PrintString(pstring)' sends pstring to the vga and serial port with no CRLF if (_VGA_Enabled) vt100.str(pstring) ' send to vga screen if (_Serial_Enabled) sio.str(0,pstring) ' send to com port if (_lcd_Enabled) lcd.str(pstring) ' send to 20x4 lCD display PUB PrintChar(c) ' sends c to vga and serial port if (_VGA_Enabled) vt100.out(c) ' send to vga if (_Serial_Enabled) sio.tx(0,c) ' send to com port if (_lcd_Enabled) LCD.out(c) ' send to LCD displayThe only thing I added to the core code was an entry in OBJ and a videopin line.
OBC
But for using this, it will be fine as you generally type a command to run another binary.
Thanks for coding this!
OBC
Do you have any problem with your code being forked a little? I'd like to do some serious mucking around in KyeDOS, but I don't want to step on any toes.
OBC
I don't think it would be 'forking' as you would be adding things in. The directory structure for instance sounds a great idea.
Hopefully by adding the TV stuff you won't run out of memory. And if you do, we can always go to BST and check that box that says 'don't compile unused spin methods'
I look forward to seeing what you add. If you post it here then that can be the latest version. I'll just do a quick check to make sure it is backwards compatible. Maybe make it version 4 and add your changes to the comments section?
Is anyone working on an executable DOS file that would load binary code to one or more cogs from an SDcard? It may be a huge step, but it would likely be a very worthwhile one.
I looked through KyeDOS 3.0 as presented herein and it seems to be oriented entirely toward reading and writing data at this point.
I am confused. The question you ask is the problem that this solves. You can load an entire startup image for the onboard memory, and then read and write to replace that as needed. Even bits and pieces if you don't want to wait for an entire new full memory replace. You can even replace code in individual cogs on demand. To be honest, this was one of my first questions, and I got a pretty good answer, but I had to figure out how to make it work in my situation. Each O/S (that we create on top of DOS) is different and has different needs.
Oh, and hi everyone. Nice to see you all again.... been away doing other things. You know, real life Smile. Now I have another prop project. Ironically it uses 4 actual propellers. The round spinning kind.
I am fairly sure that the cogs keep running when kyedos does a reboot so you could have one program that loads up some cogs, then reboot with a different program that loads different cog code.
There is certainly code in C to do what you want - I call them 'cogjects' but they have other names as well. I wrote about 10 of these by taking existing spin obex code, translating the spin part to C and then separating out the pasm part. The pasm part becomes an array in XMM C which sits in high memory, and you can load it in and out of the cogs from within software. Mouse, keyboard and some displays have been translated.
You can store the cog code within a C program or store it as a file on an SD card - it does not matter.
BTW, KyeDOS is nice. Thanks!
repeat if key.gotkey <>0 ' scan both the local keyboard and the com port result:=key.getkey if sio.rxavail(0) result :=sio.rx(0) until result <>0 ' until something comes in either portand it outputs to the serial port, to the display and to the 20x4 LCD (if you have that connected).
There is the VGA version, and Jeff Ledger rewrote it for a TV screen as well. Which screen are you using?
When you get CP/M working, you can compile it and copy the binary onto the SD card and then run it from Kyedos. I have several versions on the sd card, eg CPMTV.EXE and CPMVGA.EXE. In fact, pretty much any spin program can be put on your SD card - just rename them from .binary to .exe
I'm using a serial port. BTW, I got the KyeDOS archive from the first post in this thread.
I tried compiling cp/m with bstc, but got an error message (more on that at a later time).
So I tried with cpm.binary from the Spin-Archive-28-Aug-2010.zip file, renamed it cpm.exe and put it on the SDcard. On that card I also put the .DSK files from the Disk-archive-28-Aug-2010.zip file. It looks like this: But when I start cp/m, this is what I get: Too tired now, will test more tomorrow.
After some trial and error I found that the 'kate' editor from the KDE project can display those files.
-Tor
Use iconv to fix files: $ iconv -f UTF16 -t ASCII -c foobar.spin
-Tor
I now despise those fonts. It completely ruins the possibility to properly version control the source code. You can't do a 'diff' to get line changes. It's back to the seventies, before software version control. And why are those UTF-16 fonts used? It seems to be only to make lines in between sections, and around the MIT license comment section in some files! Whereas there are perfectly good ASCII characters to do the same, if you really want to. ASCII or UTF-8 will do fine.
So now, before I import anything into a Git repo (for example), I have to use 'iconv' to convert the files. But then the lines which should have been ordinary '----' or '====' or '____' in the first place disappears.
I humbly suggest to everybody that when you upload something into e.g. OBEX that you use '___' or something, and not those UTF-16 fonts.. it'll make it much easier for you too, because people can then create proper diffs and send patches.
-Tor
In Ubuntu iconv by default outputs to stdout. To fix that, I used this variation: Very useful.