Yes Cluso99, I do have a new version! Sorry about taking a year to answer your post though.
Ok, what I have done is taken the TV version and updated it. Removed all the references to the 20x4 LCD display as the "car reversing" displays are now so cheap and available in such a range of sizes that they work out a much better way of displaying text (and graphics).
Also I tidied up the serial output.You can disable the TV and keyboard, and just use this with the Proptool's F12 terminal. So if you want to use Kyedos in this minimalist way, the only hardware that is needed is an SD card (plus 4 10k pullup resistors and a 0.1uF and 22uF capacitor).
The reason I updated this is that I am working on multiple propellers, and I need a way of easily sending files to all those propeller chips. There is working code to send a binary file from an SD card to a slave propeller, so what I then needed was a way of getting the file from the PC to the SD card. I've written an Xmodem program (that can be run from kyedos, like any compiled binary program), and in conjunction with the command line compilation of BST, it is possible to compile a spin program, xmodem it to the SD card (using a program written in .net, or indeed from most terminal programs) and then send it out to the slave propellers. This saves time plugging and unplugging the SD card.
This is all part of the grand abstract design of a propeller chip with 24 cogs and 90 pins.
Hi richaj45, the displays are car reversing displays - go to ebay and search for car reverse monitor. You don't need the camera, just the display. There are many under $20. Sort by lowest price and then by buy it now. They usually come with 3 sockets - yellow RCA (video), white RCA (audio, not used) and red DC 12V input (11-14V). They are standard TV displays and work with the propeller 3 resistor TV circuit. All seem to accept both NTSC and PAL and I tend to use NTSC as it is a little crisper.
eg http://www.ebay.com.au/itm/3-5-TFT-LCD-Car-Rear-View-VCR-DVD-CCTV-Reversing-Camera-Monitor-/310604118248?pt=AU_Car_Parts_Accessories&hash=item485172b8e8
Drac:
Those displays have 2 composite video inputs, yellow and white. One is the reversing camera and the other is for video when there is no reversing video i.e. priority. They are great and I have just seen (on hackaday???) where someone pulled one apart and found that their one had a touch panel which was not connected. I have done a 5pin prop code for touch panels. I need to pull mine apart and check for the touch panel.
I pulled apart your older KyeDos and put the various command calls such as DIR, LS etc, into separate loadable files, and made a resident code section. This makes adding various additional OS commands extremely simple. I recently added FTF (file transfers) using a simple mechanism similar to what Michael Park (homespun & Sphinx) had done, together with a VB program. This can be an alternative to xmodem. Please take a look at what I have done. It is not specific to any hardware other than requiring an SD card and connection. Serial or keyboard/screen should be simple to implement and change on the fly. All modules can be recompiled with a batch file and homespun, although it should only be necessary to add the additional command files if they change. It can also call programs such as ZiCog/CPM and Catalina and normal Prop binaries.
Here is the link (see the latest post for the latest code) http://forums.parallax.com/showthread.php/138251-A-Propeller-OS-that-can-run-on-multiple-hardware...?highlight=propeller os
Ah - so that is what the white socket does! Thanks Cluso99
Re your code, I'll check that out. The latest kyedos TV version also can have the TV and keyboard disabled and just work via the propeller F12 debug screen, which makes it simpler. In general terms, input can come from various places - keyboard, serial port, maybe touchscreen keyboard even, and output goes to various places, TV, serial port, VGA etc. Add in the software objects as needed.
In an ideal world, the specific hardware setup would be stored somewhere, maybe on an SD card file, and programs like DIR would be able to read this file and work out where to send the data. I'll have to think about this some more...
The ideal is that you use a messagebox or whatever you want to call it to get input and send output. This way, redirection can be done on the fly, and no recompiles are necessary. Then it is only necessary for the boot code to determine which I/O is being used. This can be defined by a .bat type file or .cfg file. If possible, the boot code should be able to test for what I/O connections are available. I am already able to detect my hardware (TriBlade, RamBlade, RamBlade3 automatically).
re the Text Editor, take a look at Sphinx - Michael did an editor there. Also, search for Preditor on the forum too. There may be others too.
Sounds interesting. Not sure I quite understand though. Say you have one system that is TV and a different system that is VGA. Do you compile a single program that has both VGA and TV code in it and only run what is needed? Do you selectively load cogs depending on TV or VGA?
I can see a way to do this in C that would work well as code size is not such an issue, but for Spin if you added all those objects and only used some, it would result in larger programs. It may not matter given kyedos can reload spin programs, but still, an SD driver plus a VGA driver plus a keyboard driver plus a TV driver plus a serial object will use ? 2/3 of program memory.
I can see a big advantage to having one program with settings in a config file rather than multiple recompiles for different hardware setups so I am very interested in what you have done.
No, you only load the object for TV or the object for VGA. In fact, you can (needs to be done) unload one and reload the other. No recompiling of other programs required.
All standard programs use the stdin and stout interface.
Comments
Ok, what I have done is taken the TV version and updated it. Removed all the references to the 20x4 LCD display as the "car reversing" displays are now so cheap and available in such a range of sizes that they work out a much better way of displaying text (and graphics).
Also I tidied up the serial output.You can disable the TV and keyboard, and just use this with the Proptool's F12 terminal. So if you want to use Kyedos in this minimalist way, the only hardware that is needed is an SD card (plus 4 10k pullup resistors and a 0.1uF and 22uF capacitor).
The reason I updated this is that I am working on multiple propellers, and I need a way of easily sending files to all those propeller chips. There is working code to send a binary file from an SD card to a slave propeller, so what I then needed was a way of getting the file from the PC to the SD card. I've written an Xmodem program (that can be run from kyedos, like any compiled binary program), and in conjunction with the command line compilation of BST, it is possible to compile a spin program, xmodem it to the SD card (using a program written in .net, or indeed from most terminal programs) and then send it out to the slave propellers. This saves time plugging and unplugging the SD card.
This is all part of the grand abstract design of a propeller chip with 24 cogs and 90 pins.
So what display did you use an were did you get it?
Thanks
cheers,
rich
eg http://www.ebay.com.au/itm/3-5-TFT-LCD-Car-Rear-View-VCR-DVD-CCTV-Reversing-Camera-Monitor-/310604118248?pt=AU_Car_Parts_Accessories&hash=item485172b8e8
Those displays have 2 composite video inputs, yellow and white. One is the reversing camera and the other is for video when there is no reversing video i.e. priority. They are great and I have just seen (on hackaday???) where someone pulled one apart and found that their one had a touch panel which was not connected. I have done a 5pin prop code for touch panels. I need to pull mine apart and check for the touch panel.
I pulled apart your older KyeDos and put the various command calls such as DIR, LS etc, into separate loadable files, and made a resident code section. This makes adding various additional OS commands extremely simple. I recently added FTF (file transfers) using a simple mechanism similar to what Michael Park (homespun & Sphinx) had done, together with a VB program. This can be an alternative to xmodem. Please take a look at what I have done. It is not specific to any hardware other than requiring an SD card and connection. Serial or keyboard/screen should be simple to implement and change on the fly. All modules can be recompiled with a batch file and homespun, although it should only be necessary to add the additional command files if they change. It can also call programs such as ZiCog/CPM and Catalina and normal Prop binaries.
Here is the link (see the latest post for the latest code)
http://forums.parallax.com/showthread.php/138251-A-Propeller-OS-that-can-run-on-multiple-hardware...?highlight=propeller os
Re your code, I'll check that out. The latest kyedos TV version also can have the TV and keyboard disabled and just work via the propeller F12 debug screen, which makes it simpler. In general terms, input can come from various places - keyboard, serial port, maybe touchscreen keyboard even, and output goes to various places, TV, serial port, VGA etc. Add in the software objects as needed.
In an ideal world, the specific hardware setup would be stored somewhere, maybe on an SD card file, and programs like DIR would be able to read this file and work out where to send the data. I'll have to think about this some more...
re the Text Editor, take a look at Sphinx - Michael did an editor there. Also, search for Preditor on the forum too. There may be others too.
I can see a way to do this in C that would work well as code size is not such an issue, but for Spin if you added all those objects and only used some, it would result in larger programs. It may not matter given kyedos can reload spin programs, but still, an SD driver plus a VGA driver plus a keyboard driver plus a TV driver plus a serial object will use ? 2/3 of program memory.
I can see a big advantage to having one program with settings in a config file rather than multiple recompiles for different hardware setups so I am very interested in what you have done.
All standard programs use the stdin and stout interface.