Announcing PASos(Beta)... Propeller App System.

Ravenkallen · 2011-07-21 09:40

Well, after countless weeks of on and off programing and error after error, comes the fruit of my labor. PASos(Beta) is now available for download and testing. NOTE, this is just the beta version and it will be buggy and un-commented(Even though i tried to eliminate problems)... Also! All features are not yet enabled. The system does not yet support the memory test or renaming files, but it soon will... SO... the big question is, what is PASos? And what does it do?

What is PASos?

PASos stands for "Propeller Application System". It is a very basic program loader that simplifies loading programs by using a small and easy to use GUI. It will also be the first step in a larger project development, whose eventual goal is to have a whole "Mini -Computer" system running on the C3. Future programs will include: A text editor, a calculator program, many games, a WAV player and a in- system programming editor among other things...

What kind of hardware do i need?

In order to provide a easy to understand experience, we will try to use the smallest amount of external hardware possible... You will need.

1: A Parallax C3 board.
2: A PS/2 keyboard
3: A TV with video input
4: A SD card with the appropriate FAT format
5: A text on the SD card file called "System.txt" which stores your settings.
6: You can download the PASos SPIN program directly onto the EEPROM or you can use the mini-loader utility, which makes it easier for PASos to
function along side other OS's.

How do you use it?

Option 1:

Use is very simple. Just load the program to the lower EEPROM like you would do any other program and wait for it to boot up... You will then be greeted by the welcome screen. Then, depending on PAS settings, the system will check for a SD card and preform a keyboard test(Just press enter). Navigation is also simple. Just move the arrow keys(Left and right) to navigate the main menu. Sub menus will mostly use the up and down arrow keys... Press enter to go into sub menus or proceed through sections...Once in a sub menu the RIGHT arrow key will go back to the menu(Or the sub menu of a sub menu...etc ). Instructions about special input methods will be displayed on screen...

Option 2:

Just download the program called "microload" to the Propeller EEPROM like you would any other program. The system will look for a file called "autoexec.bin" and load up whatever program is on the file. To make the system boot up to a different OS, just change the name of the PASos file and name the new program/os "autoexec.bin" instead.

So... How do you load a program?

There are two ways to load a program in PASos. The first option is the most flexible but requires more work. The second will automatically find programs for you(AS long as they are named with the proper parameters that PASos requires)

The first method:

First you must find a program that you want to put on a SD card. Once you found one that is compatible with the C3 hardware, you must save that program as a EEPROM file and name it anything(AS long as it is shorter than or equal to 8 letters and has the BIN file extension). You can then load the file to the SD card and power up the C3 board. Navigate to the "options" menu. Go down to "search". Enter the exact file name of the desired file and press enter. If you typed in the file name correctly, you should see the size of the file(Round to the nearest kilobyte) and the type of file... Below that you will see a list of four options(One of which is not yet supported). Go down to "Run Program"... Watch as your new program loads up:)

The second option:

This option is a little more involving at first, but it is very easy to use later. Follow the steps above about saving your program as a EEPROM file and naming it with a BIN file type...Now you must find the file that you saved as a BIN file type and rename the extension to either a "gam" file type or "app" file type. NOTE! It is imperative that you name the file with a BIN extension FIRST and then rename it with a different file type directly after. The new file name also has to be 8 character big ONLY. A smaller name will NOT be registered by PASos(A temporary limitation). After you are done with that, just power up the C3 and navigate to the "Tools" menu, If the extension you chose was named "app". OR go to "Games" if you named it "gam". Press enter and the system will find the first file on the card with the respective file type and display it onscreen. Press the left arrow to find more files. Right arrow will exit and enter will load the program...

What does the "system.txt" file do?

This file simply stores your settings on the SD card. It is a four character(Four byte) text file and the size of the file MUST stay exactly four bytes big.. These settings can be changed anytime by opening up a text editor and changing any of the 4 uppercase "Y" characters to uppercase "N" characters... The order of settings is as follows:

Character 1(Byte 0) = Sound. A "Y" will turn the sound on and a "N" will turn it off.

Character 2(Byte 1) = SD check... The system will normally check for a SD card before going to the menu. You can disable it by writing a "N" to the second character .

Character 3(Byte 2) = Boot LED... The system will blink the serial TX LED three times to signify that the system booted correctly. You can turn this off by writing a "N" to the third character

Character 4(Byte 3) = Keyboard check... This can be disabled by writing a "N" to character number 4

Remember! The system.txt file MUST be kept at exactly four bytes!

Community assistance...

The Parallax community has been very helpful in making this project a reality, but the work is far from over. ANY comments/ help would be greatly appreciated...Also. The same goes for me. If you need help, please ask me and i will do my best:)

Donations

If you enjoy this program or want it to develop further, please consider donating a couple bucks.. ANY amount will not be turned away and will be greatly appreciated... The top 2 donators will be have their name put in the credits section of the first real release of the software.. A little will go a long way to help a struggling programmer:

Mission

The mission of PASos is to provide a Propeller OS newbie a easy way to start into the more complex world of Propeller
usage... It's secondary goal is to utilize the C3 as a mini-computer and offer enough flexibility to run along side other OS's

Short term goal

Our current short term goal is to be watching for bugs and fixing them as we go. Our next area of focus will be on a text editor and a memory test program.

Update (7/23/11)
I am now working on cleaning the code up and adding a few new features. Before i started trimming my code there was only 1,148 longs left. I hope to free up a lot more space:).... I also included a BIN of a newer version of Spaceace! to put on the SD card. You should rename the extension to a "gam" file so that the game menu will recognize it.

Update (8/8/11)
PASos V1.1 is now available for download. It features a few bug fixes and has some of the excess fat trimmed off. EEPROM file and source will be provided...
Microload(The mini program loader) is also available for download.

Update (8/14/11)
Real work has begun on the new text editor program, which i have affectionately called "PASos Notepad"... It will load up to 64 kilobytes of text from a TXT file(On a SD card) and display it on screen. Editing to the text can be done and can be saved back onto the SD card if wished...

Planned features:

1: Blinking cursor, with multiple colors for text.
2: Arrow keys to scroll up and down through text(Left and right will move the cursor also)
3: A "hide-able" menu, that can disappear once a button is pressed(Or reappear)
4: A separate text file that will store options and data needed by the text editor

Update (9/5/11)
More work is being done(Slowly) on the new text editor program. I have the SD loading up small chunks of data, which is then written to the SRAM and displayed on screen. A bunch of real text editing functions have also been implemented(Like being able to scroll through text with the arrow keys) Estimated time of completion is 1-2 weeks...

Update (9/16/11)
A VERY basic demo version of PASos notepad is available for download. This is an extremely early version and only supports a text file with 950 characters(950 bytes), so far... Simply load it the ram, type some stuff in, press escape to access the menu and right arrow key to navigate, then "save" it as a 8.3 txt file. You can then load the file back with the "open" option.. More detailed instructions will be available when i release the full version, which will support 64 Kilobyte long txt files. Please let me know what you think or if you found any bugs:)

Ravenkallen · 2011-07-21 10:02

This post will contain future PASos programs...

File 1 = PASos Notepad demo

Cluso99 · 2011-07-21 19:02

Ravenkallen: Sounds great.

Have you thought about just having a simple boot program in EEPROM that only knows about the SD card pin locations? This boot program then loads a program from SD card.

This is what I do with the RamBlade and is described on that thread, plus MIT source. Basically it looks at AUTOEXEC.BAT to find the binary to boot on the SD card, so it can be changed by prop software. I used PropDos & PropCmd as a base, although Sphinx & KyeDos would also provide a good mix too. This way I can boot into CPM and ZiCog.

The advantages are that once the EEPROM is programmed, it is no longer necessary to have a propplug, since you can copy files to the SD (microSD) on the laptop/pc using a card reader or USB-uSD adapter. The benefit of PropDos, PropCmd, Sphinx as against KyeDos (as I understand it) is that the OS programs/commands are all separate programs (binaries) so anyone can extend the OS commands. This is how CPM was developed.

So, if you had a simple LIST program/command filed as LIST.BIN then at the command prompt you type "LIST" then that command lists the files on the SD card. Now, someone else decides they want a better formatted list of files with sizes, they just write a program/command called LIST2.BIN and copy it to the SD card. Now at the prompt all the user needs to do is type "LIST2" to get this listing. The old "LIST" still remains.

Now, Sphinx took this to a further extension where it pre-loaded device drivers and uses standard "rendezvous" locations for the standard input and standard output devices, located in upper hub ram (see the Sphinx thread). This means these new programs/commands will work with almost any hardware, as long as device drivers were supplied. These device drivers can even be changed on the fly by the user.

Ravenkallen · 2011-07-21 19:56

@Cluso.... Thanks for taking interest:)... I actually did think of something similar to the idea of having a little program(Loader) reside on the EEPROM and based upon some basic user input, it would be able to launch different parts of the OS at a time, instead of having it all on the same program. The basic program would have to be a little "Smarter" to provide video and keyboard I/O enough to communicate with the loader.... As it is, i will probably have to offload some of the OS code to another program, because i am running out of room. Like i will probably have the memory test function be located as a different program.....

Maybe i am missing the gist of your micro loader program though. I understand how it would work in theory, but how would you communicate with it, if it only knew how to interface to the SD? How would you get it to chose one program over the other? There would need to be some basic human input to get it to work?

One feature that i hope to implement in a future version is something along the lines of letting a run program be able to write the desired file name(Of a new file to load and run) in the SPI SRAM. It would then reboot back into the OS and there would be a special line of code that would read the RAM first(Before continuing into the menu...etc) and it would load that new program instantly. It would give a new flexibility to programs. They could literally boot back and forth and you could "chain" programs together in this method to provide more memory space. There would of course be a small delay as the SD card cannot boot instantly...But! With some clever coding, you could put the timing critical functions all on one program and non time sensitive stuff on the other programs

Cluso99 · 2011-07-22 04:52

Ravenkallen wrote: »

Maybe i am missing the gist of your micro loader program though. I understand how it would work in theory, but how would you communicate with it, if it only knew how to interface to the SD? How would you get it to chose one program over the other? There would need to be some basic human input to get it to work?

The idea is that the eeprom is only a dumb minimalistic program. All it does is to run a boot program on the SD card. So, it does not know anything about the hardware except the SD card from which it will locate the binary to run. So it only knows the pin numbers of the SD card, and of course has the FAT driver too. The way it works (thanks to PropCmd, etc) is that it looks for an AUTOEXEC.BAT file on the SD card. If found, it opens that file and reads the first 8.3 filename and runs it. If either the autoexec.bat does not exist, or the file it names does not exist, it runs another prenamed binary (I forget what it is called - something like BOOTPROP.BIN). This means you should never change the eeprom contents! I preprogram my RamBlades with this code and the eeprom has writes disabled by default (by hardware WP pin).

This method works well. And the user can change the card contents with Notepad on a PC (thats what I do, and transfer files to the card on the pc). No propplug is really necessary this way.

Keep your comand programs short and simple, like PropDos, etc. You should at least look at these to get some ideas. Lots of individual programs to execute the OS commands makes a lot of sense because many can add to the OS this way.

Sariel · 2011-07-22 05:33

Oh this is wonderfull news. Ravenkallen, your timing could not be better. I have been searching for the past couple days for something like this, and have not really settled on any one choice. I am working on the next rev of my auto tester already, and I think this is exactly what I am looking for. I plan on using it so that operators can select thier test program from a micro SD card, and I have already integrated the TV out and other similar goodies into my design. My first questions for you are...

Does this load programs into the Prop's RAM, then does a reboot and load from there? I really can't have my EEPROM's overwritten every time someone goes to use the tester, and again when they load up a different test program.

At this point, I don't have the IO's free to add the extra SPI RAM and flash chip that the C3 has to offer, so if I can avoid that, I will. Are they used by your application?

Can the code be easilly modified so that instead of using a standard keyboard, it just uses a custom 4-way directional arrow with an enter button, if I use the option to select the files from a list? It is just a simple little board that I made up out of tactile switches and a few resistors. We are concerned with tooling footprint, and would like to have the least amount of space taken up on a work bench, all the while keeping my design portable so the operator does not have to mess with any more attachments than absolutely needed.

If it comes right down to it, I can figure out a way to decrease the amount of IO's that I am using for the LED's and pushbuttons, and add in the keyboard and/or SPI RAM, But I would rather not re-invent the wheel at this stage of the game.

Ravenkallen · 2011-07-22 09:33

@Cluso.... OHHHH, i think i get it now:). Your little program really wouldn't affect PASos at all. All the little loader does is search for a special file that holds the NAME of a file to run. That name could be anything you want it to be and you could run every program from the RAM. Nice idea. I don't know why i didn't think of that. Plus, like you said, you could just change the file you want to boot with a simple text editor on a PC. That way if somebody wanted to use a different OS or loader, they could just change the file name... I will be putting that in the next revision for sure... Maybe i could even do a upgraded version that would have that feature i talked about, where it another program could tell the little loader to boot up another program... Thanks for help dude:)

@Sariel....Thanks for your interest. No, the program does not overwrite the EEPROM every time. It loads it into the hub RAM and the EEPROM goes unaffected... Right now, PASos does not use any of the C3's special memory options(SPI RAM, FLASH, or even the 64K EEPROM), so the only thing you will need will be a board with a SD card and a TV(Plus some form of input device)... BUT!!! The SD's access to the C3 utilizes a special "Device selector". That means that all the C3's memory is controlled by the SPI bus, BUT the CS(Chip select) to each device is controlled by a counter type chip, so that each device can share common I/O pins, but can only be selected one at a time by the counter chip. The SD card is located on channel 5 of the counter. What that means to you is that you will have to take out the code that controls the counter and put the CS pin of the SD card back to where you want it...... As for a 4 button switch control, it should not be to hard to modify my code. Just take out the part where it uses a PS/2 keyboard and add your own simple button interface. The Game and Tools menus require only basic user input and could be very easily implemented.

Oldbitcollector (Jeff) · 2011-07-22 09:59

Good work!

A thought: How about implementing a "starting pin or zero" instead of a "y/n" in your system.txt file. You might need to create a quick program to create the proper file on the PC, but instead of byte 0 being a "y", it would be a ascii character 10 (or 11). Byte 3 would be ascii character 26, or zero if not present. Your file creator could be a dos program, or even a quick spin program.

OBC

Ravenkallen · 2011-07-22 10:11

@OBC... I don't really get what you mean?? Sorry:(. I was going to have a option later on where you can change the settings in-system. I will probably put that in the first real release(Among other things). Thanks for looking:)

Oldbitcollector (Jeff) · 2011-07-22 10:18

Here's what I'm thinking. By making each byte the starting I/O of the device, you could expand compatibility with other Propeller boards and configuration. If Byte 0 is ascii 10, the setting is assumed that sound is on pin 10. One of my boards actually has sound on Pin 5, so I would simply change byte 0 to a five.

In a sneaky kind of way, I'm re-introducing the idea of a configuration file. With a well thought out file, we could support all kinds of devices, but I think a "top ten" would be a good start.

If you wanted to get even more devious, you could scrap the idea of a file, and store the 10 bytes (for 10 devices) at the end of your program in the EEPROM.

OBC

jazzed · 2011-07-22 10:31

I think it's great that you are implementing your own system.
It is a sign of your progress toward the "ultimate propeller geek" realm.
We all learn from each other

Here's my first contribution in this area: http://forums.parallax.com/showthread.php?105412-A-Configurable-Propeller-Boot-loader&p=740800&viewfull=1#post740800

Cluso99 · 2011-07-22 16:25

Great Ravenkallen. Now you understand that, take a look at sphinx and sphinxos threads - see my signature for a link. If you base a lot of your work on what has already been achieved, it will make you life easier and we all can contribute to making a better system. Remember, this was all done way back in the CPM days (from which the pcs DOS really evolved). We now have the benefit of hindsight to jump over some of the mistakes, but the CPM system 2.2 was a nicely refined concept.

So, just to reitterate, all the os type commands should be separate program modules and should be hardware independant. That way everyone can contribute a command quite simply. So, if someone does not like your editor, they can write their own. We may end up with half a dozen, and the best will survive.

KyeDos derserves a look into too. FWI understand, KyeDos has all the commands inbuilt. If this is so, this is a mistake. They should be separate commands. Then we can use the batch concept (this is what autoexec.bat was used for in msdos and drdos - to chain some programs together - check google). When a command (really means program) completes, it merely re-loads the original os program. In our case, we have other cogs running various device drivers, etc, and they just keep running. A nice command addition would be to be able to load/reload/kill a cog with an object. Drac has this type of functionality running under Catalina. These should all be able to co-exist.

Remember, from the command line, I can launch (run) ZiCog and CPM. Sphinx has a prop executable compiler.

With a command program that knows about the disk structure of CPM we could copy files to/from CPM to FAT32. What would this achieve....??? We could use all the programs in ZiCog/CPM particularly to edit (source) files. How... We copy our source file to CPM, boot ZiCog/CPM, edit the file under CPM, boot back to the prop os, copy the file back from CPM to FAT32. This should be capable by launching a XXXX.BAT file which contains the chain command sequence to do this automatically.

Can you see how this would get us lots of functionality quickly

Dr_Acula · 2011-07-22 17:22

KyeDos derserves a look into too. FWI understand, KyeDos has all the commands inbuilt. If this is so, this is a mistake. They should be separate commands.

Not quite - There are some inbuilt commands eg Help, a few renaming commands and running a .exe program when you type the name. But there are also programs that behave as if they are new commands, eg "Type.exe" and "Xmodem.exe", and the movie players, and CP/M.

Kyedos fills the memory so any additional commands will have to be done as extra programs. You can pick any extension but I think it can't be longer than 3 characters, so .binary is not allowed. I figured that if I was going to change the extension from .binary to something else, why not make it .exe rather than .bin? But you can pick anything you like really.

I have had kyedos on the eeprom for nearly a year now and have never put anything else on the eeprom. Debug programs into ram with F10 (including C programs), and when a program is debugged, put in on the sd card as an .exe.

Future programs will include: A text editor, a calculator program, many games, a WAV player and a in- system programming editor among other things...

A big YES to the text editor. At the very least, then you would be able to edit your own system.txt file on the propeller itself.

With a command program that knows about the disk structure of CPM we could copy files to/from CPM to FAT32. What would this achieve....??? We could use all the programs in ZiCog/CPM particularly to edit (source) files. How... We copy our source file to CPM, boot ZiCog/CPM, edit the file under CPM, boot back to the prop os, copy the file back from CPM to FAT32. This should be capable by launching a XXXX.BAT file which contains the chain command sequence to do this automatically.

We have talked about that one before. Sooner or later, one (or more) of us needs to write such a program. It would open up all the text editors written in CP/M.

I have tried hacking into W.COM and R.COM (the programs that do just this exact thing in the SIMH) but they are not that easy to understand.

Cluso99 · 2011-07-22 18:53

Drac: I am firmly of the opinion you do not want KyeDos or any other program in eeprom. Just a basic boot program to boot KyeDos or whatever from the SD card. That way, we would never require to change the eeprom, so it could be preprogrammed as I do on RamBlade. That removes the requirement for a propplug! The only change then required to this eeprom code is the pinout for the SD card. My code is on the RamBlade thread and is MIT (IIRC basically it is a stripped PropDos).

As for file transfers, I believe it would be simpler in spin for both directions since (as you know) each CPM disk is actually a FAT16/32 file. So, it is only necessary for the spin program to understand the CPM disk structure which is well documented. If we wanted to cheat initially, we could just use one of the CPM disks as a complete contiguous file and just overwrite it.

Dr_Acula · 2011-07-22 19:31

Yes, one problem that comes up is how do you write an operating system for multiple hardware platforms. At the simplest level, do you define the pins for a keyboard in the code, or do you define them in a .sys or a .txt file on an sd card?

I'm tending to use the Propeller Demo Board pinouts but if one uses the C3, then some things will be different. Speaking of the C3, does anyone have a link to the high resolution schematics (I'm sure I once saw some that were higher resolution than the ones in the manual).

Re CP/M, Kye's SD driver has all the nuts and bolts to open up a large binary file (eg an 8Mb CP/M disk image) read and write various blocks and close it. So it would be a matter of writing a Spin program that can read and write files. Reading might be easier than writing.

I'm playing around with various LCD TV displays. The 40 column single color TV spin object is just on the threshold of being hard to read on a 3.5" display. I have some larger TV displays coming from Hong Kong - one is a 7" display, and so hopefully can report soon which are the easiest to read.

Cluso99 · 2011-07-22 20:31

Drac: The pinouts for keyboards etc need to be specified somehow. That is why Michael's Sphinx had some great concepts. That way, all the device drivers could be substitued, even on the fly. That way, we at least could initially provide a binary compiled for the specific platform, and later extend this to get the pin definitions from a file.

There is no problem in reading and writing files using spin. The more complex section is in the understanding of the internal CPM file system. I don't think it is too bad though. and if we had a large contiguous file within CPM that we could just overwrite, that kludge would work for starters. ZiCog locates the file and does this by reading and writing directly.

I just wish all the separate os work could be combined instead of the fragmented development that is happening. We would get a lot further ahead more quickly. Unfortunately, I have lacked the time to push this way forward.

Ravenkallen · 2011-07-22 22:06

Interesting discussion so far and i am doing my best to follow what is happening. I have only briefly looked at CM/P, KyeDOS, PropDOS or any other DOS:), so i am still pretty ignorant of their functions. I will do more research, but i am assuming they are program loaders/ OS's of some sort? My goal of PASos was to provide a easy to use/ setup program loader. Functionality was not my initial goal, but i was hoping it would get more people interesting in the Propeller as a potential mini-computer(Complete with Text editor, WAV player, calculators...stuff like that). A stand alone machine of sorts. A user could create a program and simply stick it on a SD card and watch it run. OR even eventually be able to create programs in-system. BUT i can see that my OS in it's current incantation would be a hindrance to the other designers. I will be implementing the above mentioned "Mini-Loader" as soon as possible. Does anybody have a working version of it? I will not copy the whole thing exactly, but i would like to glean some code off of it if i can? Would that help to make PASos more friendly to other OS's?

Cluso99 · 2011-07-22 23:03

Ravenkellen: My loader is on my RamBlade thread (see signature below). You are welcome to it (its MIT) and you will notice it is really other peoples code combined/stripped. There you will also find the modified PropCmd code as well.

Seems you may not know... PropDos, PropCmd, KyeDos and Sphinx are all propeller OSes. CP/M is an old 80's OS used on 8080 and Z80 machines before the PC was released. ZiCog is the prop program written by heater to emulate the Z80 and this runs CPM 2.2 from microSD. Sphinx has a spin/pasm compiler.

The loader is the easy bit. So maybe you should look at KyeDos and get that running first. It is the best documented code which is why I suggest it first. Seems a lot of what you are intending is already done, so using that as a base would allow you to get to the next level.

Dr_Acula · 2011-07-22 23:08

I don't think what you are doing is a hindrance.

How about this for an idea. Multiple operating systems, each configured for different hardware. Eg I have a kydos version for VGA and Jeff did one for TV. You need different OS's for each hardware, because you need to be able to type something on a screen to tell the user what to do.

BUT - how about this - each program you write (a .bin file, or whatever extension we choose) will run on multiple platforms. They do this by reading in a settings file, like ravenkallen's system.txt file.

That file might grow. It might contain things like whether a board is VGA or TV, which pins those are on.

This is nothing particularly new, but it might be a way of bringing things together rather than us all heading off in different directions.

Perhaps what we could think about is system.txt being written in text, rather than with binary numbers. Much like system.ini in windows - something you can edit with any text editor.

The downside to such a concept is that every program you write has to have the sd card driver, and that can take half the available prop memory. Is this problem already solved? eg a 'preloader' that reads system.txt into somewhere permanent (a cog for instance), then loads the actual program (which might not need an sd card reader in its code).

I absolutely agree that the prop can become a "mini computer".

Cluso99 · 2011-07-23 00:11

Dr_Acula wrote: »

I absolutely agree that the prop can become a "mini computer".

Too late... I think it is already... just that it runs CPM under emulation!!!

Ravenkellen: I just re-read your first post. You have done a GUI to navigate the program which is fantastic. This could be mixed with KyeDos (or the others) to become the default first launched program after to raw eeprom boot program, provided autoexec.bat did not exist or pointed to a non-existant program, or pointed to this program. This would also permit the use of other commands (which already exist), such as list, print, ren (rename), etc.

BTW Did you use some of the GUI info on Parallax Semi's App Note? There is a GUI app note for anyone who doesn't know.

It is certainly getting close to making one combined OS version done that puts all the good parts of Sphinx, PropCmd, PropDos, KyeDos (and others including hopefully Catalina), your GUI, plus a few other ideas together, and finally make a proper propeller os that we can all extend simply without reinventing the wheel.

Drac has also done a GUI and has it running with Catalina.

Ravenkallen · 2011-08-08 10:46

Sorry it took so long to respond. It has been a busy past couple of weeks... The new loader program is called microload and it is working very well. ALSO, PASos also had a few bug fixes and some minor cosmetics done to it. Please keep the comments coming. I read every one of them with interest:)

idbruce · 2011-08-08 12:45

Very nice Ravenkallen, keep up the good work.

Bruce

Ravenkallen · 2011-08-08 15:06

idbruce wrote: »

Very nice Ravenkallen, keep up the good work.

Bruce

Thanks man:).... Have you tried it yet?

idbruce · 2011-08-09 02:49

@Ravenkallen - I guess my post was a tad bit misleading. Sorry to say that I have not tried it, but I definitely would if I had all the right parts. However I did find the thread quite interesting, so please continue with your work. When I have all the proper parts in front of me, I will definitely explore it further.

Bruce

Ravenkallen · 2011-08-14 11:45

@Bruce... Okay, let me know what you think:).

@All... Has anybody actually tried it yet? Anybody found any bugs or anything?

Ravenkallen · 2011-09-15 21:29

I just uploaded a very basic version of the PASos Notepad... Give me a holler if you find anything weird:)

Dr_Acula · 2011-09-15 22:01

That sounds interesting - is that a text editor?

Ravenkallen · 2011-09-16 18:48

@Dr_Acula... Yes, it is. I have a little more info about it in the first post, but the actual code is in the second post.

Ravenkallen · 2011-10-04 13:41

I am slowing down the progress of this project to a halt temporarily... Lack of interest and other projects are the primary factor. I will release a another version of the PASos Notepad, which will use internal RAM instead of the SPI SRAM on the C3 board. SpaceAce is still being fine tuned, but don't expect another release to soon. Hope this doesn't affect anybody?

Ravenkallen · 2011-11-29 22:07

Well, guess who?:) I have decided to start back to working on this project. There are a few MAJOR changes, the first and most important being,

PASos's main hardware is now the ASC(From Martin Hodge), with a Video and keyboard shield and a SD Arduino compatible shield from Sparkfun(Version 2 with the built in 3.3V I/O line protecting circuitry). First factor when considering the switchover from the C3:
$35 for the ASC, $15 for the adapter, and $15 for the SD shield(That comes to $65). This seems to be a lot more reasonable than the $129 that Parallax wants for their C3
Second factor:

While the expanded memory options of the C3 were nice, the board seemed to be to complicated for its own good. The SPI channel select feature was a brilliant way to add all the memory to the same bus to save I/O lines, but created a bottleneck, that not only reduced speed, but complicated drivers. The ASC model is just a SD card, which seemed to be the only memory resource that PASos truly needed anyways.
Third factor:

The shear number of boards that are made to be Ardunio shield compatible is absolutely staggering. Xbee shields, motor driver shields, sd shields, LCD shields...
I chose the ASC for it's flexibility with a proven modular system.

The C3 was a nice board, but it is to expensive and not to many forum members have one.

Other changes will be a more flexible OS, with a lot more built in features(Such as auto communication with other PASos devices). Wireless(Xbee) support will also be added in future. I think i will also add the ability to control and view PASos over a serial terminal? I don't know if i can fit all that in the program though:)

I am thinking about adding a little more flexibility to the boot loader program. Maybe it could have basic video and keyboard support like a "real" BIOS type program. Another feature will be a permanent install option, that will write PASos to the EEPROM if the user desires. I have more little ideas i can share if anybody cares, such as renaming the System.txt file, to something like Configos.txt and the file will be a lot larger and can store more detailed system settings...
I have worked more on SpaceAce!! and the notepad program as well. Any ideas, complaints or comments?:)

Announcing PASos(Beta)... Propeller App System.

Comments