Cluso99 said...
@CassLan: Rick, not sure how this would fit with your code, but have you thought about holding your text for menu's on the SD. I presume you are using the fsrw 1.6. If so, I pickup the file first sector address for ZiCog and use this directly plus offsets to read the sectors. You could use this and an index to pick up strings. There is plenty of room on the disk, so use a fixed length and truncate with '0'.
I'm already using a trick like that to use a swap file for editing, all static info like menu's/help/fonts will be on the SD for sure. This means no limits on editing file size, but doesn't allow you to open a file from one SD Card, then insert a 2nd SDCard and save.
@OBC
@mpark- Its not you, its an inside joke. At the last Expo I was fortunate enough to win a PPDB in the raffle. The only thing that doesn't include is a DIP prop. If you recall this was during the great Prop Dip shortage of 09 . But if I was going to find a·Prop Dip ANYWHERE it would be at this Expo right? So I asked Gadget Gangster, he only had them as part of kits and also had limited Dip inventory,·he said OBC was planning to purchase a kit containing a Prop Dip, and maybe he didn't need the Dip so much as he needed the kit. So I saw OBC later that day when he was getting his kit from Gadget Gangster and explained that I'd won the PPDB and could I buy his Dip off him that he'd gotten in this kit IF he already had some Dips at home.
I could actually see the light bulb above his head · he looked at me and told me to keep my $$, he would grant me this·rare Prop Dip in exchange for PrEditor , and I gladly agreed.
re your file copying between SD cards. I am sure we can solve this via a seperate program under SphinxOS that would use the available hub space to do the copying between cards.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I have been working on a serial replacement driver for the kbd & tv drivers (StIn and StOut).
It occurred to me that we need a StIn and StOut (or is that StdIn and StdOut?) interface driver(s) and then seperate drivers which can be substituted. So only the SphinxOS program needs to know about the cog code to load, be it kbd, tv, 1-pin versions, fdx, vga or whatever, plus of course fsrw.
If anyone is interested, here is the unbuffered fdx (serial) code. It needs the interface changing to allow all 256 char codes to be send (i.e. -1 = empty, not 0).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Attached is the first working version of a new Sphinx TV driver that provides for random display access, scrolling, area fill, changing display colors, reading from the display buffer, all with the display buffer in the cog. It can also display all 256 characters using the ROM font tables. I've included a version of FemtoBasic using the new driver for testing purposes. It uses some non-standard I/O pin assignments, but these are all listed in the beginning of the FemtoBasic.spin file and can be changed easily. The TV driver can easily be used in other programs as well. The file with the assembly driver is TV_CogOnly.spin. The user interface file is Text_TV.spin. Note that TV_CogOnly.spin includes the Text_TV.spin object and passes on the user calls to Text_TV.spin. When the Sphinx OS is started, it will use TV_CogOnly.spin. User programs that run under Sphinx will only use Text_TV.spin since the TV driver will already be loaded and running in a cog.
I'm making this available for people to experiment with. Next steps:
1) Change the start method to use more meaningful pin/mode parameters
2) Change the out method to use ANSI control sequences
3) Integrate the driver into Sphinx
4) Work on a text editor for Sphinx using this driver
Great work Mike. OBC and I were only discussing another video driver early this morning and now it's almost done!
I will have a look at your code later when I switch laptops. The user interface TV-Text.spin hopefully should be the same as a standard StOut driver to talk to any of the TV drivers or fdx (serial). I will post what I think the user interface should look like for comments (hopefully tonight).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I looked at your interface. I was thinking more along the lines that the StIn and StOut (kbd and TV or serial) would be just that, the passing of a byte/long·through the interface. "-1" would be used to indicate no character available/no space available. Other -ve values would be used to indicate errors. The TV cog would handle any sequences required, such as ANSI codes or whatever.
So, the StOut would support the "OUT" call. Other higher level calls·may be supported in the upper level driver (compiled into the sub-programs) such as str, hex, dec, bin, but these could be optional for space saving.
Likewise, the StIn would support the "IN" and "PEEK" calls. "IN" is the equivalent of key (returns -1 if no key) and "PEEK" is "IN" but does not clear the character from the buffer. The upper level driver may also support the getkey equivalent, being a repeating IN while <0.
Would this work with your extended commands in the TV cog driver? I realise the editor would require access to more functions than a normal program using an "output" device.
What are your thoughts???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99,
I don't think what you want is doable without giving up some functionality in the TV driver. There's just not enough memory available to hold the display buffer and the code needed. I suspect there's some intermediate point where everything could be done via a single byte channel and there would be a bit more functionality than the existing Sphinx driver, but it would be much slower for some editing purposes than what I've just posted.
It just occurred to me that using -1 to signify empty might be a problem because the program loader clears hub memory above the program. It's better to keep using 0 for empty and pass bytes (incl. 0) in a long with, for example, the high bit set (or whatever, just to make the long non-0).
Everything else uses 0, so this'll maintain consistency.
I have made a serial driver for Sphinx that works with PropTerminal and other Terminals.
I/O byte passing works with the same RENDEZVOUS variables as TV and Keyboard. I replace $00 by $100, and make an
AND $FF after reading from the variable, so no need for a -1 for empty.
The output driver installs a cog with a full duplex serial code based on JDCog-Serial. The driver has 640 bytes FIFO in CogRam for RX and TX !
The Input driver needs no additional cog, but expects that also the output driver is started. This means you can't mix TV output and Terminal input, or PS2 Input and Terminal output.
In the ZIP is also an adapted Sphinx top object (sphinx_pc.spin), which uses the terminal as console.
I have added 2 commands GET and PUT for File up- and download with PropTerminal, but they don't work yet.
@mpark
To integrate Sphinx in my Operatingsystem, I had to make a special version, which has moved the RENDEZVOUS variables 128 bytes downwards ($7F7F instead of $7FFF). That was necessary because my OS needs the end of the HubRam to pass some pin configurations and a commandline.
Perhaps it may be a good idea to reserve a little HubRAM at the end also in the original Sphinx, so the Sphinx-compiler can be used as a Subsystem in an other OS, which needs also some sort of RENDEZVOUS area.
I know, this is a big change, all files must be recompiled. But it's the best if it is done in this early stage of Sphinx.
The one thing that I believe is extremely important is that all binary codes from $00-$FF must be transparent and usable. Therefore, an empty/clear must be another code and to me -1 seems perfectly reasonable, being $FFFFFFFF. Should other codes be defined, they may be extras, but the simplistic code should use $00-$FF.
Anyone else care to comment??
Andy,
I will have a look later, but sounds good. We could probably disable either the tx or rx section, but I cannot think where we would really want that. I can understand the substitution of various video drivers or keyboard drivers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I guess it depends on what you mean by "transparent and usable."
What I suggested is what Andy just implemented (just a different bit) and it does allow for all bytes 0-$ff.
OK, I agree, we set the $1xx bit on for passing characters so we can get all 256 codes across. $0 will be clear for next character/command. For standard In & OUT we will not worry about status back from the cog driver, so we don't need to check for anything other than $0. Is this OK?
Now, for possible further extensions, we can easily allow the cog driver to check for >$1FF for commands.
I would like to propose a command requesting the cog number. This could be used for the alive request like Michael first did. In response to the command, the cog would reply with cogid as the character. Why? So we can find out the cogid to stop the driver and reload a new driver · Any suggestions as to the command code? Do we use -1 ($FFFFFFFF) or something else??
I think it would be nice to also have the ability to turn off the TV driver (also like Michael did) so that an editor can use an alternative driver with a hub based buffer. Otherewise, we just stop the cog and reload after the editting program terminates. Of course, this precludes the screen being a pc screen instead of the TV connection. Comments??? CassLan???
Postdit: I meant to ask. Should we take the hex/dec/bin/str out of the interface driver and add it as a support routine??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I think it would be a good idea to take the conversion routines (dec/hex/bin/str and maybe a fixed size dec) out of the I/O driver interfaces and put them in a separate object. There might even be an extended object that includes additional conversion routines as well as the basic ones. An additional parameter would contain the address of the cog parameter long so these routines could directly send data to the I/O driver via this "universal" mechanism.
CLuso99 said...
I think it would be nice to also have the ability to turn off the TV driver (also like Michael did) so that an editor can use an alternative driver with a hub based buffer. Otherewise, we just stop the cog and reload after the editting program terminates. Of course, this precludes the screen being a pc screen instead of the TV connection. Comments??? CassLan???
The way I have it set up right now is you change one constant in the begining of the program (DisplayChoice) to either 1,2,3,4. And this is how you choose what display driver you want. And also comment the OBJ section of the other drivers your not going to use. If your asking does it do VGA and TV..yes definately. It would have to run on its own though, I only have ~300 longs left at the moment. I'm hoping to have a beta out today or tommorow.
Here is a later (interim) version of Ariba's code with the pinouts defined at the top level. It works for TriBlade and although not checked should work for RamBlade (change definitions at the top level).
There are some issues when using the bst terminal program. Backspace does not work. Currently, it is not easy to switch back to the kbd and tv (to come soon).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Ariba said...
...
To integrate Sphinx in my Operatingsystem, I had to make a special version, which has moved the RENDEZVOUS variables 128 bytes downwards ($7F7F instead of $7FFF). That was necessary because my OS needs the end of the HubRam to pass some pin configurations and a commandline.
Perhaps it may be a good idea to reserve a little HubRAM at the end also in the original Sphinx, so the Sphinx-compiler can be used as a Subsystem in an other OS, which needs also some sort of RENDEZVOUS area.
I know, this is a big change, all files must be recompiled. But it's the best if it is done in this early stage of Sphinx.
Andy
Hi Andy.
The rendezvous stuff is just for the Sphinx "OS" parts. If you have your own OS, shouldn't you port just the compiler parts to your system and forget the Sphinx OS bits? I mean, do we really want an OS inside an OS??
Hi Andy.
The rendezvous stuff is just for the Sphinx "OS" parts. If you have your own OS, shouldn't you port just the compiler parts to your system and forget the Sphinx OS bits? I mean, do we really want an OS inside an OS??
I have ported the compiler to my OS without the OS part of Sphinx. My understanding is, that the components of the Compiler (lex,codegen,linker) need also the Rendezvous area to work together, so I had to change all these files.
What I suggest is: Define a little safe HubRAM user-area which is not touched by the compiler (and other sphinx components). The simplest solution is at the end of the HubRAM.
This lets everybody extend the shared parameters between applications for specific use.
I don't want an OS inside an OS. But it would be nice if my OS can use Sphinx compatible Applications without changes, and vice versa. But this is only possible if they don't conflict.
An alternative to a user area, would be to define some parameter extensions to the Sphinx Rendezvous variables. For me these are the most important:
- SD card pins (4 bytes)
- Clock frequency and mode (1 long + 1 byte)
- The Display mode and I/O device (1..2 bytes)
All other configuration parameters can be in a file on the SD card.
...I have ported the compiler to my OS without the OS part of Sphinx.
You did? That's awesome! What exactly is your OS?
Ariba said...
My understanding is, that the components of the Compiler (lex,codegen,linker) need also the Rendezvous area to work together, so I had to change all these files.
...
They only use the rendezvous to talk to the I/O drivers (i.e., the "OS" part). If your OS provides file and console I/O, just make lex/codegen/link use your OS and forget the Sphinx rendezvous stuff!
I vote to leave the rendezvous as is. Andy, if you need extra rendezvous areas then take them downwards after the metadatabuffer. Parameters can now be obtained simply from the SD card. Of course, we need a filename and definition standard.
Here is·sample code with the "isx" drivers seperated for standard IN and OUT routines. I am using Andy's modified JDSerial, modified again.
I wanted to post the idea of the "isx" drivers being removed from the physical cog driver(s) for IN & OUT, be they keyboard, serial or whatever & TV, LCD, serial or whatever.
So the isx_in.spin & isx_out.spin (& .spn) should·NOT require any changes for the underlying cog drivers.
Note there is a bug - no characters being output (so it does not work!).· Character echos only work first time (so if you type DIR, DIR is echoed first time but not the second time even though it still does a dir.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
My OS is called ApropOS and works more like PropDOS than Sphinx. It has no common I/O or file drivers. It just passes a parameter block in the HubRAM to a started application. This block contains Clock settings, Pin configuration, a commandline and a "Return-application" which should be started when the application terminates. I prefere this over a standard I/O system, because every application needs only to implement the minimal necessary drivers and can use all resources of the Propeller.
The goal is that ApropOS ready applications can run on different platforms without recompiling.
My adaption of the Sphinx compiler works like this:
If compile in ApropOS is executed then I start an interface application which installs the Sphinx file and I/O drivers and translates the commandline to the Sphinx format and file. Then it just starts the compiler or linker like sphinx.bin. When the compiler terminates or aborts it returns not to sphinx.bin but to my "Return-application" (which can vary). To protect the ApropOS stuff in HubRAM, I have moved the Rendezvous area of Sphinx 128 bytes down. Further I replaced the output driver of Sphinx with one that collects the text in a RAM buffer instead of printing it to the TV. So I can pass the last (Error)-message back to the Return-Application and there it is shown on the current used Display.
As you see, I have changed nothing inside the lex/codegen/link code, only the entry and exit part is ported to my OS.
I thinked about extending the Rendezvous area under the metadata buffers, but they are variable depending on the number of file instances. And from bottom up it can be overwritten by the generated code. So I found the only safe area is behind the rendezvous stuff.
I don't really need this safe area for my OS. I anyway will adapt the applications so that they use the advantages of the OS. I just was thinking, Sphinx would be a little bit more future proof if there is a little free user area behind the rendezvous vars for extensions.
So that's ApropOS! I remember the name from a while ago and wondered what happened to it. I'm beginning to understand the usefulness of your parameter block idea. Very interesting.
I'm a little confused about the Return-application. I assume it's the name of a file to load and run from the SD card, but that implies that every ApropOS program has to bring along its own SD card file system, right? So the parameter block doesn't have to live in RAM; Cluso's idea of putting them on the SD card would work.
On the other hand, moving the rendezvous area down 128 bytes isn't much of a hardship.
I'd like to learn more about ApropOS. Andy, is ApropOS available to try out?
Maybe some of ApropOS' ideas can be mixed in with SphinxOS.
Just thinking out loud here, but instead of a fixed safe area, what if there were a way to specify rendezvous locations at run time? I don't know if it's possible, but would it be useful?
Just realized that parameters have to be in RAM, because when ApropOS launches a program, the program doesn't know what pins the SD card is on until it looks at the parameter block, right? That's the whole point, isn't it.
As I tried to say in one of the previous posts: The parameter block can be on SD card, but the SD pin numbers must be known. And also the clockfrequency and PLL settings should be known (otherwise you need to run the file driver with RCfast to load the parameter block). ApropOS provides this informations in HubRAM and EEPROM.
Yes the return-application is a name of a file which should be started to terminate the application (like you execute sphinx.bin to return to the console). But making this name variable allows nested applications, a bit like a subroutine call, only that you pass a return name, and not a return address. An Editor can be started from the console and returns to the console, the same editor can be started from an application and returns to this application. OK the return-application is restarted and not continued from the point where it has started the editor, so the subroutine analogy is not perfect.
If an application has no SD driver included and can not execute the return application, then it should make a reboot to return to the root application of the OS via boot from EEPROM. For such applications I want pass the parameter block also in RAM, because you need no EEPROM or SD driver to get the pin numbers for the TV, VGA, Keyboard and so on.
Is ApropOS available? Good question... I work on and with it a long time now, but I fear to release it because I can then not change anymore the basic parameters. From time to time this is necessary for example to include things like Touch screen support since I have Raymans LCDs. So it's a bit to early to release it to the public, but I can prepare a ZIP with some examples and docu for you - what Boards with SD card do you have, and what kind of Monitor(s) ?
I have advanced to the next stage where I have the standard IN & OUT working and am now looking at how other programs will run (interact)·under SphinxOS.
Now, for ZiCog, I have two choices. Either run ZiCog and totally take control of the OS (i.e. stop the Sphinx drivers), or, use the Sphinx standard In & Out drivers plus the SD driver(s). The first option means that I now must have ZiCog stop all other cogs first. The second option means I use the standard In & Out drivers (a good benefit) but the downside is that the SD drivers in Sphinx uses 3 cogs whereas in ZiCog we only use 1 but more hub ram and spin code. In either mode, ZiCog can relaunch SphinxOS whe exiting.
I believe this will also apply to other programs (PrEditor, Catalina, PropBasic, etc).
There is another issue that needs to be considered and that is the terminal screen for editors. In my RamBlade & TriBlade there is normally no direct screen buffer as I use a serial to communicate to another prop.
I am still convinced this is the best strategy to get lots of pins and functions available on a second prop. That is,·use the first prop for the "processor" and the second for the "intelligent I/O".
Does anyone have any comments???
Should we differentiate between binaries that require the Sphinx drivers (say ".com"??)·and those that run standalone (".bin") ??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
@OBC
@mpark- Its not you, its an inside joke. At the last Expo I was fortunate enough to win a PPDB in the raffle. The only thing that doesn't include is a DIP prop. If you recall this was during the great Prop Dip shortage of 09
I could actually see the light bulb above his head
Rick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
NYC Area Prop Club
Prop Forum Search (Via Google)
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
re your file copying between SD cards. I am sure we can solve this via a seperate program under SphinxOS that would use the available hub space to do the copying between cards.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
It occurred to me that we need a StIn and StOut (or is that StdIn and StdOut?) interface driver(s) and then seperate drivers which can be substituted. So only the SphinxOS program needs to know about the cog code to load, be it kbd, tv, 1-pin versions, fdx, vga or whatever, plus of course fsrw.
If anyone is interested, here is the unbuffered fdx (serial) code. It needs the interface changing to allow all 256 char codes to be send (i.e. -1 = empty, not 0).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I'm making this available for people to experiment with. Next steps:
1) Change the start method to use more meaningful pin/mode parameters
2) Change the out method to use ANSI control sequences
3) Integrate the driver into Sphinx
4) Work on a text editor for Sphinx using this driver
Should we get organized and set up a sourceforge thingamajig or whatever? I have no experience in this area but it might be interesting.
I will have a look at your code later when I switch laptops. The user interface TV-Text.spin hopefully should be the same as a standard StOut driver to talk to any of the TV drivers or fdx (serial). I will post what I think the user interface should look like for comments (hopefully tonight).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I looked at your interface. I was thinking more along the lines that the StIn and StOut (kbd and TV or serial) would be just that, the passing of a byte/long·through the interface. "-1" would be used to indicate no character available/no space available. Other -ve values would be used to indicate errors. The TV cog would handle any sequences required, such as ANSI codes or whatever.
So, the StOut would support the "OUT" call. Other higher level calls·may be supported in the upper level driver (compiled into the sub-programs) such as str, hex, dec, bin, but these could be optional for space saving.
Likewise, the StIn would support the "IN" and "PEEK" calls. "IN" is the equivalent of key (returns -1 if no key) and "PEEK" is "IN" but does not clear the character from the buffer. The upper level driver may also support the getkey equivalent, being a repeating IN while <0.
Would this work with your extended commands in the TV cog driver? I realise the editor would require access to more functions than a normal program using an "output" device.
What are your thoughts???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/13/2010 11:49:21 AM GMT
I don't think what you want is doable without giving up some functionality in the TV driver. There's just not enough memory available to hold the display buffer and the code needed. I suspect there's some intermediate point where everything could be done via a single byte channel and there would be a bit more functionality than the existing Sphinx driver, but it would be much slower for some editing purposes than what I've just posted.
Seems like we will require a different driver for edit programs versus other programs, as Michael has done.
For normal programs, I really think we need a standard input and output driver(s) which don't care what is underneath (keyboard, serial, tv, 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
Everything else uses 0, so this'll maintain consistency.
Post Edited (mpark) : 1/14/2010 3:51:13 PM GMT
I/O byte passing works with the same RENDEZVOUS variables as TV and Keyboard. I replace $00 by $100, and make an
AND $FF after reading from the variable, so no need for a -1 for empty.
The output driver installs a cog with a full duplex serial code based on JDCog-Serial. The driver has 640 bytes FIFO in CogRam for RX and TX !
The Input driver needs no additional cog, but expects that also the output driver is started. This means you can't mix TV output and Terminal input, or PS2 Input and Terminal output.
In the ZIP is also an adapted Sphinx top object (sphinx_pc.spin), which uses the terminal as console.
I have added 2 commands GET and PUT for File up- and download with PropTerminal, but they don't work yet.
@mpark
To integrate Sphinx in my Operatingsystem, I had to make a special version, which has moved the RENDEZVOUS variables 128 bytes downwards ($7F7F instead of $7FFF). That was necessary because my OS needs the end of the HubRam to pass some pin configurations and a commandline.
Perhaps it may be a good idea to reserve a little HubRAM at the end also in the original Sphinx, so the Sphinx-compiler can be used as a Subsystem in an other OS, which needs also some sort of RENDEZVOUS area.
I know, this is a big change, all files must be recompiled. But it's the best if it is done in this early stage of Sphinx.
Andy
The one thing that I believe is extremely important is that all binary codes from $00-$FF must be transparent and usable. Therefore, an empty/clear must be another code and to me -1 seems perfectly reasonable, being $FFFFFFFF. Should other codes be defined, they may be extras, but the simplistic code should use $00-$FF.
Anyone else care to comment??
Andy,
I will have a look later, but sounds good. We could probably disable either the tx or rx section, but I cannot think where we would really want that. I can understand the substitution of various video drivers or keyboard 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
Post Edited (Cluso99) : 1/15/2010 10:40:15 AM GMT
What I suggested is what Andy just implemented (just a different bit) and it does allow for all bytes 0-$ff.
OK, I agree, we set the $1xx bit on for passing characters so we can get all 256 codes across. $0 will be clear for next character/command. For standard In & OUT we will not worry about status back from the cog driver, so we don't need to check for anything other than $0. Is this OK?
Now, for possible further extensions, we can easily allow the cog driver to check for >$1FF for commands.
I would like to propose a command requesting the cog number. This could be used for the alive request like Michael first did. In response to the command, the cog would reply with cogid as the character. Why? So we can find out the cogid to stop the driver and reload a new driver
I think it would be nice to also have the ability to turn off the TV driver (also like Michael did) so that an editor can use an alternative driver with a hub based buffer. Otherewise, we just stop the cog and reload after the editting program terminates. Of course, this precludes the screen being a pc screen instead of the TV connection. Comments??? CassLan???
Postdit: I meant to ask. Should we take the hex/dec/bin/str out of the interface driver and add it as a support routine??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
IIRC there is already an object for these methods.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
NYC Area Prop Club
Prop Forum Search (Via Google)
·
There are some issues when using the bst terminal program. Backspace does not work. Currently, it is not easy to switch back to the kbd and tv (to come soon).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Hi Andy.
The rendezvous stuff is just for the Sphinx "OS" parts. If you have your own OS, shouldn't you port just the compiler parts to your system and forget the Sphinx OS bits? I mean, do we really want an OS inside an OS??
I have ported the compiler to my OS without the OS part of Sphinx. My understanding is, that the components of the Compiler (lex,codegen,linker) need also the Rendezvous area to work together, so I had to change all these files.
What I suggest is: Define a little safe HubRAM user-area which is not touched by the compiler (and other sphinx components). The simplest solution is at the end of the HubRAM.
This lets everybody extend the shared parameters between applications for specific use.
I don't want an OS inside an OS. But it would be nice if my OS can use Sphinx compatible Applications without changes, and vice versa. But this is only possible if they don't conflict.
An alternative to a user area, would be to define some parameter extensions to the Sphinx Rendezvous variables. For me these are the most important:
- SD card pins (4 bytes)
- Clock frequency and mode (1 long + 1 byte)
- The Display mode and I/O device (1..2 bytes)
All other configuration parameters can be in a file on the SD card.
Andy
You did? That's awesome! What exactly is your OS?
They only use the rendezvous to talk to the I/O drivers (i.e., the "OS" part). If your OS provides file and console I/O, just make lex/codegen/link use your OS and forget the Sphinx rendezvous stuff!
Here is·sample code with the "isx" drivers seperated for standard IN and OUT routines. I am using Andy's modified JDSerial, modified again.
I wanted to post the idea of the "isx" drivers being removed from the physical cog driver(s) for IN & OUT, be they keyboard, serial or whatever & TV, LCD, serial or whatever.
So the isx_in.spin & isx_out.spin (& .spn) should·NOT require any changes for the underlying cog drivers.
Note there is a bug - no characters being output (so it does not work!).· Character echos only work first time (so if you type DIR, DIR is echoed first time but not the second time even though it still does a dir.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/19/2010 7:05:44 AM GMT
The goal is that ApropOS ready applications can run on different platforms without recompiling.
My adaption of the Sphinx compiler works like this:
If compile in ApropOS is executed then I start an interface application which installs the Sphinx file and I/O drivers and translates the commandline to the Sphinx format and file. Then it just starts the compiler or linker like sphinx.bin. When the compiler terminates or aborts it returns not to sphinx.bin but to my "Return-application" (which can vary). To protect the ApropOS stuff in HubRAM, I have moved the Rendezvous area of Sphinx 128 bytes down. Further I replaced the output driver of Sphinx with one that collects the text in a RAM buffer instead of printing it to the TV. So I can pass the last (Error)-message back to the Return-Application and there it is shown on the current used Display.
As you see, I have changed nothing inside the lex/codegen/link code, only the entry and exit part is ported to my OS.
Andy
I thinked about extending the Rendezvous area under the metadata buffers, but they are variable depending on the number of file instances. And from bottom up it can be overwritten by the generated code. So I found the only safe area is behind the rendezvous stuff.
I don't really need this safe area for my OS. I anyway will adapt the applications so that they use the advantages of the OS. I just was thinking, Sphinx would be a little bit more future proof if there is a little free user area behind the rendezvous vars for extensions.
Andy
I'm a little confused about the Return-application. I assume it's the name of a file to load and run from the SD card, but that implies that every ApropOS program has to bring along its own SD card file system, right? So the parameter block doesn't have to live in RAM; Cluso's idea of putting them on the SD card would work.
On the other hand, moving the rendezvous area down 128 bytes isn't much of a hardship.
I'd like to learn more about ApropOS. Andy, is ApropOS available to try out?
Maybe some of ApropOS' ideas can be mixed in with SphinxOS.
Just thinking out loud here, but instead of a fixed safe area, what if there were a way to specify rendezvous locations at run time? I don't know if it's possible, but would it be useful?
As I tried to say in one of the previous posts: The parameter block can be on SD card, but the SD pin numbers must be known. And also the clockfrequency and PLL settings should be known (otherwise you need to run the file driver with RCfast to load the parameter block). ApropOS provides this informations in HubRAM and EEPROM.
Yes the return-application is a name of a file which should be started to terminate the application (like you execute sphinx.bin to return to the console). But making this name variable allows nested applications, a bit like a subroutine call, only that you pass a return name, and not a return address. An Editor can be started from the console and returns to the console, the same editor can be started from an application and returns to this application. OK the return-application is restarted and not continued from the point where it has started the editor, so the subroutine analogy is not perfect.
If an application has no SD driver included and can not execute the return application, then it should make a reboot to return to the root application of the OS via boot from EEPROM. For such applications I want pass the parameter block also in RAM, because you need no EEPROM or SD driver to get the pin numbers for the TV, VGA, Keyboard and so on.
Is ApropOS available? Good question... I work on and with it a long time now, but I fear to release it because I can then not change anymore the basic parameters. From time to time this is necessary for example to include things like Touch screen support since I have Raymans LCDs. So it's a bit to early to release it to the public, but I can prepare a ZIP with some examples and docu for you - what Boards with SD card do you have, and what kind of Monitor(s) ?
Andy
Edit: I see you got it while I was writing...
Yes, I'm a bit slow but I eventually got there. My sleeping mind realized my mistake and actually woke me up (it's the middle of the night here).
If you have some ApropOS documentation, I'd love to see it. I don't think I need to actually run it at this point.
Now, for ZiCog, I have two choices. Either run ZiCog and totally take control of the OS (i.e. stop the Sphinx drivers), or, use the Sphinx standard In & Out drivers plus the SD driver(s). The first option means that I now must have ZiCog stop all other cogs first. The second option means I use the standard In & Out drivers (a good benefit) but the downside is that the SD drivers in Sphinx uses 3 cogs whereas in ZiCog we only use 1 but more hub ram and spin code. In either mode, ZiCog can relaunch SphinxOS whe exiting.
I believe this will also apply to other programs (PrEditor, Catalina, PropBasic, etc).
There is another issue that needs to be considered and that is the terminal screen for editors. In my RamBlade & TriBlade there is normally no direct screen buffer as I use a serial to communicate to another prop.
I am still convinced this is the best strategy to get lots of pins and functions available on a second prop. That is,·use the first prop for the "processor" and the second for the "intelligent I/O".
Does anyone have any comments???
Should we differentiate between binaries that require the Sphinx drivers (say ".com"??)·and those that run standalone (".bin") ??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 1/23/2010 6:24:41 AM GMT