PROP OS (operating system) - how do we get there? Sphinx already does it :-)

Cluso99 · 2010-01-01 18:59

·pdate: Sphinx already does most of what I want and more. See http://forums.parallax.com/showthread.php?p=819353

We are rapidly aproaching being able to put an operating system on an SD drive. However, there are some key issues that need to be resolved. While there has been discussion, I don't think anything has been resolved. Please correct me if I missed something.

So we are approaching what CPM did years ago.

We need...

Standard Input Driver
Standard Output Driver
We have an SD driver already thanks to lonesock & rokicki

Somehow we need to decouple compiled programs from these drivers. What do we need to do this?

It is easy enough to change pin numbers. But take the case where we have·VGA or TV or Serial. I haven't even considered the various implementations of each. Therefore, we need·standard output interface calls... out/tx/chr, str, hex, dec, bin, crlf/cr/lf, etc. We also·need standard input interface calls... rx/getkey, rxcheck/key,· rxavail/present/gotkey, rxtime, rxflush/clearkeys, etc. We also need to know where the hub buffers are and their length. The absolute minimum we require is standard call naming.

Some ideas...

We could load pasm directly into a cog·from an SD file (leaves more space for hub ram)

Some problems...

How do we load hub with spin routines (standalone)? These would be the standard spin drivers and their buffers.

Any comments, suggestions, etc???

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Post Edited (Cluso99) : 1/3/2010 8:36:20 AM GMT

Mike Green · 2010-01-01 19:39

This has been done several times, first with a Propeller OS that I wrote a couple of years ago that worked with TV, VGA, keyboard, and a simple EEPROM file system. The OS was the initial program loaded. It checked whether the assembly cogs were running already by looking for a unique value in upper RAM set by its initialization routine. If this value was absent, all the I/O routines were loaded into cogs and started. There was a command interpreter which then got control in either case. The TV and VGA drivers were written so they'd be interchangable other than the different screen sizes and different memory and cog requirements.

All the I/O routines were separated into two portions, the assembly driver and a Spin program interface. These communicated via small work areas in upper RAM. The Spin interfaces were provided as objects to be included in a user program along with a definitions object with the addresses of the work areas defined as constants. There were a few small methods that were part of the definitions object for simple memory allocation and for marking which cogs were in use (so they'd be left alone by the program loader).

There's a posted copy of this linked on the Graham Stabler's Pretty Good Thread list.

Since this, several others have used the same sort of idea, most recently mpark's Sphinx system

I'd suggest we standardize on ANSI display sequences for the standard output driver, probably the best way to support TV / VGA / VT100 PC Emulator output. Hub buffer addresses (and sizes) could be provided via methods in the Spin interface.

If we do the Spin interfaces properly, we could also use a layer to provide different input or output editing routines for any kind of character stream device. You might have one object that provides only simple DEC, HEX, BIN, STR conversions and another that adds a PRINTF-like output editor or perhaps also adds floating point and the user would include one of a set of objects. Similarly on input, there would be a basic set of interface routines in one object and other objects would add other methods for decimal, hexadecimal input conversions, etc. or possibly floating point input.

Bill Henning · 2010-01-01 20:06

In the Largos prototype, dec(), hex() etc sit on top of putchar() and getchar()

Mike Green said...
This has been done several times, first with a Propeller OS that I wrote a couple of years ago that worked with TV, VGA, keyboard, and a simple EEPROM file system. The OS was the initial program loaded. It checked whether the assembly cogs were running already by looking for a unique value in upper RAM set by its initialization routine. If this value was absent, all the I/O routines were loaded into cogs and started. There was a command interpreter which then got control in either case. The TV and VGA drivers were written so they'd be interchangable other than the different screen sizes and different memory and cog requirements.

All the I/O routines were separated into two portions, the assembly driver and a Spin program interface. These communicated via small work areas in upper RAM. The Spin interfaces were provided as objects to be included in a user program along with a definitions object with the addresses of the work areas defined as constants. There were a few small methods that were part of the definitions object for simple memory allocation and for marking which cogs were in use (so they'd be left alone by the program loader).

There's a posted copy of this linked on the Graham Stabler's Pretty Good Thread list.

Since this, several others have used the same sort of idea, most recently mpark's Sphinx system

I'd suggest we standardize on ANSI display sequences for the standard output driver, probably the best way to support TV / VGA / VT100 PC Emulator output. Hub buffer addresses (and sizes) could be provided via methods in the Spin interface.

If we do the Spin interfaces properly, we could also use a layer to provide different input or output editing routines for any kind of character stream device. You might have one object that provides only simple DEC, HEX, BIN, STR conversions and another that adds a PRINTF-like output editor or perhaps also adds floating point and the user would include one of a set of objects. Similarly on input, there would be a basic set of interface routines in one object and other objects would add other methods for decimal, hexadecimal input conversions, etc. or possibly floating point input.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller

Cluso99 · 2010-01-01 20:13

Mike. Thanks for the info - I will take a look.

You are correct of course that the output only requires a single call (chr) and the rest can be done in an object library. Likewise, input should be just two calls (chr, avail). IIRC someone has an object for this in the obex.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Rayman · 2010-01-02 00:32

I've been thinking about writing an OS for the upcoming PSB device... I suppose the main thing an OS should do is launch binary files from the SD card. And, fortunately we have Femtobasic routines to do that already.

As far as what pins are used and what devices are present and so forth, I was thinking that a "config.sys" file on the SD card would be a good idea... That way the only thing that needs hard coding is the SD card pins. And, that's fixed for the PSB anyway...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

mikediv · 2010-01-02 01:06

Rayman what is the PSB system???

Rayman · 2010-01-02 02:02

Glad you asked [noparse]:)[/noparse]· look here:

http://www.rayslogic.com/Propeller/Products/PSB/PSB.htm

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

Ariba · 2010-01-02 02:53

We had this discussion about what is needed for an OS before. See here:
http://forums.parallax.com/showthread.php?p=732725
There are many different ideas of what an OS needs, and as you can see again in the thread above:
too many cooks spoil the broth.

I still think the same as I described in that thread:
- No standard I/O routines in MainRAM or in Cogs. This is good for CPM or MSDOS like system, but a Propeller can do
much more (Graphics, GUI, many different connected devices for different applications).
- Instead, just define a way to pass the hardware configuration (pins and clock settings), and a commandline to every
startet application. So every application can include the optimal drivers, and no cogs or RAM is wasted.
- Define a clipboard file to pass data between applications.

Andy

hinv · 2010-01-02 03:14

Hey Ray,

Your PSB looks good. I was just looking at the screens you sent me and was wondering how hard it would be to design around it...then there it is.
How did you mount that screen? Is there anything under it?
ETA?

Thanks,
Doug

RossH · 2010-01-02 03:49

@All,

I've done a bit of investigation of various "free" multitasking kernels, and also done a small amount of work on porting one to the Prop (I don't mean a simple LMM kernel, I mean a true multi-tasking kernel). Once you have such a kernel, generating an OS is primarily a matter of adding a user interface (which can be quite trivial) plus the necessary device drivers and utilities.

However, I've stopped work on that in favour of something even simpler - essentially just a more sophisticated program launcher (with simple command line parsing capabilities and more transparent multi-CPU support) plus a C-based multitasking library somewhat similar to Posix threads (but lighter). The result will be be called "Catalyst". I hope to have something to post by February (but no doubt I'll be late as usual).

I stopped work on the general-purpose kernel/OS idea for 2 main reasons:

1. It would duplicate some of the work currently being attempted by others - e.g. Bill's Largos, or the push to get Gcc/Linux on the Prop, which (if successful!) would be far more useful; and

2. Overall, I'm beginning to think a Prop (mk I) just does not have enough resources to justify even a "mini" kernel - let alone what most of us would think of as a true OS (and yes, I'm aware this is inconsistent with reason 1 - but I always maintain that consistency is a crutch for weak minds!)

For me, the essence of an OS is that it allocates and manages resources for you - this is easier than having to do it yourself within each program, but it is also less efficient. The main reason for doing it is usually to allow multiple programs to run at once - but that brings its own complications since you then incur additional overheads for resource sharing and inter-program comms. I just don't think this is a realistic proposition on a Prop mk I.

My experience with Catalina is that you run out of resources so quickly that even losing one kb of Hub RAM or one cog would make the whole thing self-defeating - many applications that the Prop would otherwise be able to run quite happily would no longer be feasible - just because of the kernel/OS overhead! And I don't think you can get away with using much less than one cog and a couple of Kb of Hub RAM (for buffers and the like) - but of course every time I say something can't be done on the Prop I get proven wrong almost immediately (that's one of the things I like about this forum!)

Bill's Largos may be an exception, since he is able to use the additional XMM RAM to make up for some of the resource limitations inherent in the Prop I - but I think Largos will mostly be useful on Morpheus (or other similar systems) with both multiple CPUs and lots of XMM RAM. For single CPU Props without XMM - which is probably 99% of all Props sold - I think a common program launcher plus a set of standard and platform independent utility functions is probably as much as we could usefully use.

Of course, on the Prop mk II it will be a different matter. So perhaps getting a "true" OS working on the Prop I will be worthwhile even if the overhead turns out to be so high it is not yet very useful!

Ross.

P.S.

Rayman: Very interesting board! Intended perhaps as a "Propeller DS"? Or possibly an "iProp"?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

Cluso99 · 2010-01-02 06:25

Gee, a lot of good threads have come out of the woodwork that I did not know existed.

Here is an excellent one Standards for hardware, file types and OS features, please chime in· http://forums.parallax.com/showthread.php?p=732725

After skimming these threads, and some time in ZiCog and CPM, my 2c is...

SD card use mandatory for this OS (its now cheap and easily obtainable and on more newer pcbs)
Need a BIOS for the card (minimum supports SD, StdIn, StdOut)
- loaded (by the OS) near the top of hub ram and remains loaded
- compiled for the user's minimum hardware
- StdIn supports .getchr and .avail only (or .rx debate?)
- StdOut supports .putchr only (or .tx/out debate?)
- Advantages
  - Compile once for the hardware
  - Stays resident
  - StdIn could be FDX or KBD, etc
  - StdOut could be FDX, TV, VGA, etc
Other objects could be added to the BIOS and recompiled.
- objects like secondary ports, timers, debug port, etc
Need to be able to load other objects (binaries) to do things like CPM did
- e.g. DIR is an object (DIR.BIN)·and so does not need to be part of the resident OS
- Advantages
  - Allows extra services to be easily added to the OS by anyone
  - Only resident when being used, so more hub available
- Disadvantages
  - Slower as it has to load from SD and execute

Now, I understand the objects can be relocated. I am unsure of how this would be done.

I think we need to define a simpler starting point where sections (objects) can be built by many rather than by the few controlling the OS. So·IMHO, we need to define how this simpler BIOS can be achieved.

Does this make sense???

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Dr_Acula · 2010-01-02 11:05

Hi Cluso,

This has got me thinking - what are the components you need.

I've got a couple of 'newbie' questions first:
1) If you have some pasm code in the hub and you start a cog and put that code into the cog to run, and that cog keeps running the code forever, and you pass variables to and from that cog, then do you ever need the code to stay in hub once you have done that?

If not - well then could pasm code go from sd card to (temp store in hub) to a cog?

2) When people talk about PropDos, does this include what you and I would call a BIOS - ie instead of sending a character via .str or .out to a spin method, you place that character into a fixed ram location, or in some other way you pass that to a BIOS, and the BIOS handles where they go - ie to a display, to a serial port etc? If not, well, a BIOS is something that might be useful. BIOS would handle things like - output and input to serial ports, to keyboard, to display(s), open a file, close a file, write a record, read a record.

Ok, next musing, if you want an operating system, the first thing you need is a huge amount of free memory to move programs in and out. How small could you make an operating system? 10k, leaving 10k for programs? Or do 'programs' only ever fit into a cog? (but they have clever ways of passing variables to the next program??)

There are certain things that you can load and discard - eg setup parameters.

The Dracblade software is starting to answer some of these questions. I thought it might be useful to plot a pie chart of where the memory goes. See attached. Only problem - there isn't much room left for programs!

Maybe you could do cunning things and save some memory.

Given the ram limitations of the prop, I'm inclined to think this is quite a daunting task. Worth brainstorming though.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller

Cluso99 · 2010-01-02 11:48

Drac: answers as follows...
1. No (so we could load directly from SD and keep the hub space free)
2. No. PropDos and PropCmd is just a program that does DIR, DEL and a few other functions that Dos (or CPM) does. But there is no BIOS or StdIn/StdOut. This is something to be done.

Spin code has to be resident in hub, but I am thinking it can be loaded when needed as a self-contained object. Don't forget we have ram as well, but of course this cannot be used by multiple cogs. But if you look at the old OSes like CPM and DOS they only had one processor so if we reserved the ram use for one processor, and used the cogs to do the BIOS I/O drivers, much like we do in ZiCog, then we can expand things.

DIR, LS, SURVEY are all transient programs, loaded when needed to run. There is no point in the PropOS having these built-in and always loaded. A transient load to execute is fine, and then lots of standalone programs such as edit, compile, Basic, C, etc can be done without the worry of other things, just like CPM or DRDOS does. We just need the hooks (BIOS) to be defined.

You mention the ram limitations. That is why I have been pushing the SRAM. Also, don't forget I have advocated using 2 props, and that would go a long way towards this, as the I/O would live in another prop, so by necessity, the StdIn/StdOut seperation is forced upon the code. Here is where RamBlade shines, as it is a little smt pcb that just plugs into any other prop pcb with 2 wires plus power.

So I guess what I am saying is that there are 2 possibilities here,
· 1.· Single Prop
· 2.· Multiple Prop, one as the SD/SRAM/Prop with the PropOS, and the other as the intelligent I/O

Your pie chart is very interesting..
Now if we hive off VGA 25%, KBD 5%, LCD 3% (33%) onto another Prop, we are left with 67% of which 39% is ZiCog(13%) and Main(26%) combined. ZiCog is an emulation. So these numbers look very interesting and we have SRAM to play with here. Your serial(9%) is quite large, but I would expect that to remain, given we would want the ultra-fast serial between the props with decent buffers.

Just my thoughts and running with the extensions..

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

ErNa · 2010-01-02 16:53

My 2c:
it will take some time, until a OS is done. PropII will then be alive. What will be urgent is a message passing system to interconnect chips. As a standard will create some overhead, we have to accept, that a solution will waste some memory, but we should try to keep it to a minimum.
The MMI should be object oriented, to allow different data sources to communicate in parallel without interference

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away

Oldbitcollector (Jeff) · 2010-01-02 17:27

I've been quietly following this thread and feel like it's time to play devil's advocate...

Why do we want to waste resources by having functions like DEL, DIR, etc sitting
in memory when I'm running another program or game? I agree this is what
would separate a real OS from Propdos, but what is the advantage here?

I'm not crazy about having PropDOS in sitting in EEPROM the way it works now,
and considering a way to combine both PropDOS, BASIC, or an editor (Preditor?)
into a larger EEPROM, or combination of EEPROMS. A new version of Propdos
has been in the works, but I'm waiting for Kye's new fsrw driver for some
directory functions.

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Visit the: The Propeller Pages @ Warranty Void.

Ariba · 2010-01-02 18:10

OBC

I'm fully with you, but instead of using a larger EEPROM you can have all on SD card.

Clusso

You really need to study SPHINX. www.sphinxcompiler.com/
This makes exactly what you describe.
Extending Sphinx would be the easiest way to get an OS, with Console and Standard I/O. It needs a VGA driver,
which works the same as the TV drivers (perhaps also a Serial driver to a Terminal on the PC), and a better Editor.
Sphinx has already:
- a console with some included commands
- starts little helping applications for DIR, COPY, DEL and so on.. (TV, Keyboard, SD driver remain running in separate cogs)
- a Spin compiler
- an Editor
- a lot of objects to program your own applications

Andy

Cluso99 · 2010-01-02 18:28

Ariba:

Thanks for the heads up on Sphinx. I had totally forgotton about it (and not looked at it since I was busy at the time). WOW!!

· As you say, it's almost exactly what I (dare I say we?)·are after, plus a lot more (compiler, linker and mini-editor). Only issue I see is the use of $0 preventing using that as a character value. Otherwise, we could substitute the keyboard and tv drivers to serial or whatever. I am sure there is a solution for this.

OBC:

I am with Andy, forget eeprom, use SD. And yes, the DIR etc functions should be seperate mini-programs just like CPM. Sphinx has·achieved this. Have you looked at PropCmd? - localroger added a lot of file functions to ProDos for this version.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

hippy · 2010-01-02 19:26

@Cluso99 : I think that rather than a bottom-up approach you need to be top-down. Decide what you are hoping to deliver, what it will do, why, and who for, before getting into the intricacies of the how. Is this to simply be a reinvention of the home computer systems of the 70's or something more ?

At the very minimum I'd expect there to be some command line interface to launch programs which support a keyboard and TV/VGA, a BIOS to handle that and a file system to handle SD Card. I'd expect to be able write programs ( either on the platform or cross-compile on a PC and drop them on SD Card ready to execute ) which can utilise the BIOS and File System abilities.

That's the retro-computer reinvented but what of the things which drove people to use PC's, Linux, Mac and Windows ? The ability to multi-task and run multiple applications, the ability to add other I/O devices and extend file systems. If I have an ENC28J60 I should be able to control the command line through Telnet ? I should be able to access my PC's disks from the Propeller OS via Ethernet and access files on a USB Storage Device ? If I have a Telnet connection to a command line, then why not two, or more ? Surely I can run a web server as a TSR or parallel task while running an IM client ? It's not so much about whether I will ever actually be able to do that but having an OS design which can allow that possibility.

With my "interested in buying one" hat on, I don't really care how it works, just that it does and can do what I want. With my "Applications programmer" hat on I don't care what goes on underneath the surface just that there's a clean, abstracted, extensible API which I 'just use', and easily change to use new capabilities added to the OS. As long as my program can write to SD card or PC over Ethernet with a simple drive letter or root directory name change that's what I want. TBH, that it's a Propeller ceases to be important, simply that being so dictates an 'unusual programming language' to use, and not even that if C available.

Apart from the development itself an OS has very little to do with the underlying hardware platform so, we go full circle to the beginning; I think the important questions to ask when embarking on an OS are "why" and "what for".

Cluso99 · 2010-01-02 20:55

@Hippy: As usual, you ask very pertinent questions.

What I want is...

a·simple OS, not Windows/Mac/Linux
Prop based·(yes, it could be on other processors, but that is not what i want)
minimum hardware (SD plus StdIn and StdOut)
a modern version of the old CPM or DRDOS/MSDOS
able to be standalone
- with keyboard and TV/VGA/LCD
- or serial (replace the keyboard and TV/VGA/LCD drivers only)
- serial can be connected to a PC or another prop with keyboard and TV/VGA/LCD, etc
able to simply add other specialised hardware such as ethernet (ENC28J60), wireless, sensors, etc via·drivers
able to compile programs on this prop

To date Sphinx comes the closest to what I am after...

minimal hardware: SD, keyboard, TV
abstracted drivers for SD (& filesystem), keyboard, tv
compiles on the platform
can transfer files to/from pc over serial
just requires a little mod so we can substitute the keyboard and tv drivers

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Mike Green · 2010-01-02 21:42

Cluso99,
I've been writing a new video driver for Sphinx that would allow support of an editor and the usual ANSI display controls. It doesn't quite work yet, but you might be interested in using something like this for your "base system". It also allows for the display of all 256 character codes.

TV_CogOnly is the initialization routine executed by the boot routine. It launches the video cog allows use of the display by the boot routine (for error messages, etc.)
Text_TV is the start of an ANSI display controls interpreter and interface to the video cog and is intended to be included in any Spin program that uses the display. A simpler version (much like what's already written) could be supplied to just do a new line operation, backspace, and a few other controls.

Post Edited (Mike Green) : 1/3/2010 4:35:28 PM GMT

Cluso99 · 2010-01-02 23:18

Mike:

That will be a great addition

However, Sphinx strips the $00 code as it uses this to signify the idle condition. If we are going to make the display and keyboard able to be substituted (particularly by a serial port) then we need to be able to pass all 256 character codes. A cursory look at Sphinx looks as though it passes a long so it would be relatively easy to change to using -1 for idle.

Why might I want to do this? Because I may want to use a PC (or a terminal board or another prop pcb) via a serial link. Now, I may want to send an ASCII sequence down the line to switch from the video to a program running xmodem or some other thing to do binary transfers. Sphinx would allow this except for stripping all $00 sequences in both directions. This is what I would like to overcome. I think Sphinx solves everything else and more, plus room for growth.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Cluso99 · 2010-01-03 04:39

Update: Sphinx already does most of what I want and more. See http://forums.parallax.com/showthread.php?p=819353

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

rjo_ · 2010-01-03 05:49

Sphinx is not for idiots... I know because I am one. I have now gone to the website twice and can't even figure out what to download[noparse]:)[/noparse]

As an idiot, the reason I like the Prop is precisely because the Prop doesn't have an operating systems. The Prop is exactly predictable. I don't have to write code to anyone's specs. I don't have to modify my code because someone else modified his.

I don't want pascal or c or ada... Spin and PASM are all I really need.

Having said all of this... I have been working on the guts of an automaton... to create a PropPhone capable of going places that I don't want to take stereo pictures and send them back to me. There are so many sub-systems involved, it was immediately obvious that I was going to need an operating system.

What I eventually decided was to use Oldbit's PropDos... a really well documented template for an operating system. It boots in about 500 milliseconds... it runs binaries and the only thing I need to do is compile my little programs to binary form, load them up to an SD card, bring up PROPDOS.spin in my Spin Tool, hit F11 and I'm ready to go.

I love the concept of Sphinx. Just as soon as "Sphinx for Idiots" gets released, I'll be one happy camper[noparse]:)[/noparse] The idea of leaving my computer at home is almost too much to hope for.

Rich

Cluso99 · 2010-01-03 06:51

rjo: Have you looked at the website recently? There is a complete guide to how it works and the steps to loading it on your hardware. Sphinx can compile on the prop too!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

rjo_ · 2010-01-03 07:06

I was there tonight[noparse]:)[/noparse]

I told you I am idiot[noparse]:)[/noparse]

I'll go back and suffer through it... one download. That's what I want. There are files all over the place.

mpark · 2010-01-03 07:59

Yes, sorry, it's a bit of a mess. I should clean it up. Just start with the zip file. You can ignore the other files until you get going.

Cluso99 · 2010-01-03 08:31

It's fine michael. I found your website easy and detailed.

rjo: The seperate files are just later updates of those in the zip file. And don't forget it's free!

We have the problem with all software these days that they want to download everything when there is an update instead of just the bits required.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

CassLan · 2010-01-03 15:55

When I first DLd Sphinx I was also expecting to hit F11 in Proptool and be done, but I found it cool that you had to actually "build" Sphinx...with Sphinx [noparse]:)[/noparse] This is important for people with different pins/xtals etc.
That was a while ago though maybe there is a ready to go set of binaries now.

Rick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

NYC Area Prop Club

Prop Forum Search (Via Google)

·

simonl · 2010-01-03 21:50

For me, I'd just be happy with interchangeable code - so I can use serial / TV / VGA etc for output (and serial / keyboard etc for input) without having to change my code. For this to work, we'd need to get some sort of standard / minimum "API". Looks like that's the way you're heading, Clusso, so I'll be watching this thread closely (even if I don't know if I need an OS!).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon

www.norfolkhelicopterclub.com

Announcement: To cut costs in the current economic climate, we have switched-off the light at the end of the tunnel.

PROP OS (operating system) - how do we get there? Sphinx already does it :-)

Comments