Yes we need to be able to replace individual drivers which means being able to determine its cogid or else tell it to stop.
The SD driver is another matter. The raw driver needs a cog and should be resident always. It would be nice to combine the other 2 cogs into 1 but I am not sure if this is even possible as I have not looked.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Option 1 is really kind of defeating the purpose of an operating system if all you are going to do is replace everything and run ZiCog and then restart the OS after you terminate ZiCog. I like the option of connecting up ZiCog to "stdin and stdout". In regards to the SD we probably need to look at trying to make it run in one or 2 Cogs.
The terminal interface has also been bothering me as well. I think we need to stick to serial flow. I was thinking of taking PrEdit and seeing how hard it would be to change to using vt100 codes to move around the screen - essentially making it use serial instead of vga. Would still probably need an edit buffer but I think that is doable. Catalina should be straight forward I think but have not looked at it but C programs have a notion of stdin and stdout already so with the appropriate linkage it should work. I have not looked at propBasic but I would it would fall somewhere near Catalina in making it use a serial type driver.
on the differentiation of binaries - is there anywhere in the binary header of a prop binary for us to put a magic number? If not the then we can use an extension. Probably should not use .com to be confused with dos or cpm programs that could also be on the SD.
Yoda: The reason Sphinx uses 3 cogs is to get all the file handling code into cogs where it does not take up hub ram. It definately will not fit into 1 cog this way. The RamBlade and TriBlade have no problems with 3 cogs, but I think Drac is already using all cogs.
I like the stdin & stdout method too. I agree using vt100 would be the better way. After all, Wordstar does this and it works fine.
Binaries - nothing I know of to differentiate. The better solution would be a differecnt extension. Maybe ".bix" for the sphinx version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
cluso: I have not looked at the filesystem code but would think we might be able to slim it down. The other thing is do we have to stick to FAT on the SD? If we went to lower level block manipulation it would be less code and closer to true "OS like" operation. It would make interchange with PC essentially impossible. I will have to think on that, how we can make a tighter SD driver.
On the binaries, I was hoping there might be a byte in the Prop header that we might steal for a loader to detect. .bix sounds ok or maybe .spx or .sfx works too ?
Yoda said...
On the binaries, I was hoping there might be a byte in the Prop header that we might steal for a loader to detect. .bix sounds ok or maybe .spx or .sfx works too ?
You could hijack the reset bit (7) from the clock mode byte. But that gives you only 2 different types of binaries, then again maybe that's enough.
Yoda: We only use direct low level access with ZiCog once I obtain the start address of each disk file. It is remaining compatible to Sphinx that has the SD requirement.
Kuroneko: I wouldn't want to interfere with the binary code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso: Yea I know - I am just thinking whether we want to extend that concept to Sphinx. We could build a filesystem that is much simpler than FAT inside of a FAT file like we do for ZiCog. I am just pondering if that is good thing or bad thing. We would have to have tools to read and write the filesystem on a PC but that would not be too hard but I think that might make it less pleasant to use for the casual users.
Keep in mind that a simpler file system would use much less hub ram....
Yoda said...
Cluso: Yea I know - I am just thinking whether we want to extend that concept to Sphinx. We could build a filesystem that is much simpler than FAT inside of a FAT file like we do for ZiCog. I am just pondering if that is good thing or bad thing. We would have to have tools to read and write the filesystem on a PC but that would not be too hard but I think that might make it less pleasant to use for the casual users.
Yoda said...
On the binaries, I was hoping there might be a byte in the Prop header that we might steal for a loader to detect. .bix sounds ok or maybe .spx or .sfx works too ?
You could hijack the reset bit (7) from the clock mode byte. But that gives you only 2 different types of binaries, then again maybe that's enough.
You could borrow the high nybble in the clockfreq long provided you put it back when you were finished with it. In fact, you could get 5 bits if you were careful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Some discussions on the dracblade and zicog threads but I think they may fit better here. Brief summary - say you have a big program with 7 cogs each with 2k of code in a cog, and you compile that as one binary and download it and then the prop moves each of those 2k blocks into a cog, you end up with (I think) 14k of unused ram in the hub, scattered in random 2k blocks.
So, somehow, if you could reclaim this by loading the 2k blocks into a 2k buffer from an sd card or some other source (eg upper part of a 64k eeprom) then potentially you could save 12k to 14k of hub ram, which could now be used for other things - eg more code or a screen buffer or whatever.
Given a typical object (I used the keyboard object as an example) one can certainly compile the spin part and leave out the PASM part and it all works. But if you compile the PASM part without the spin part, most objects have references to hub ram locations within the code. So, you can pass those locations with a Start but it is still a bit messy and not a universal or standardised solution.
But as I understand it, Cluso is taking Sphinx and building objects which use a common location in hub ram to communicate to hub. Cluso says "In SphinxOS, the standard output has a long and the standard input has a long hub interface. ($7F80 & $7FC0). The multiple character buffers are within the cog."
This sounds very interesting, especially given a number of standard I/O objects are already coded and working - eg keyboard, serial (Cluso will no doubt update more).
This could give you the building blocks for the things you commonly need in a program - serial ports, TV, VGA, keyboard, and in a language/method that is standardised and easy to understand.
I'm still thinking through the implications of this, but it sounds intriguing.
Here is the post that Drac refers to. There were other parts that are probably better left on the ZiCog thread.
Drac said... (from DracBlade thread)
Re BST let't take a typical object - eg the attached one which is the keyboard object. How much would it take to convert that to relocatable cog DAT code that you could put in a seperate file on an SD card. (For the moment, leave all the spin code as-is and just considering PASM)
There are the VAR statements at the beginning - would they go in the cog code or stay as they are? Would you add the locations of the buffers to the Start list? And what would be the best way to get data out of buffers if those are now internal in a cog?
@cluso - yes good point re moving the thread - I'll follow it along on the zicog thread.
Drac: The implications of a seperately compiled cog code (cog objects)·is that it must be self-resident with minimal hub interaction as this must be with fixed (known location·and defined size/protocol) hub locations. This is in fact what CPM and other OSes do. We access these drivers through a defined interface. In SphinxOS, the standard output has a long and the standard input has a long hub interface. ($7F80 & $7FC0). The multiple character buffers are within the cog.
For input (i.e. a keyboard)...·as another cog/spin takes a character out and clears the hub, the driver cog looks, sees it it empty (=0) and places another character into the hub buffer (if one is available in the cog buffer). The process repeats. This method may not be quite as fast but reduces the hub footprint. The opposite works for output.
Once everything goes via this standard interface, the driver may be substituted without changing the calling program. So, you can substitute a pc serial for the keyboard, or a remote wireless connection. The calling program has no need to know.
So far, for input, we have serial, keyboard, 1-pin keyboard (almost complete). For output, we have serial, video (TV composite 3pin), with 1-pin TV as a wip.
We also have fsrw (SD card driver) but this has the whole file system interface as well BUT currently takes 3 cogs, so this·warrants some reworking.
Here is a link to SphinxOS code v006 (near the bottom of the page) http://forums.parallax.com/showthread.php?p=819353
IIRC the driver is sx---.spin and the calling interface is isx---.spin (two calling files, one input and one output). The drivers can be substituted while the calling interface remains unchanged.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
So, after loading SphinxOS, ZiCog could be loaded which utilises these drivers, but it would not have to load them, nor would it have them in it's binary (or hub space).
Now, taking this a little further (and slightly extending the boot time)...
Boot SphinxOS which loads StdIN, StOut, SD drivers
Sphinx then loads ZiCogDrv binary which·loads/starts the SRAM driver (for TriBlade/RamBlade/DracBlade, etc) and any other drivers
ZiCogDrv then·loads ZiCog which loads/starts the Z80 emulation and boots CPM. The hub does not contain any of the above drivers.
When ZiCog exits, it stops the ZiCog drivers and reloads SphinxOS
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
This looks brilliant. And having pulled apart some objects last night, I really appreciate how much complexity is going on behind the scenes, particularly with rewriting objects.
Load times would not be a problem given the huge memory advantages.
One thing I have seen is that the sd code is now taking 3 cogs. I'm using a version that takes one, and I understand there are good reasons for using 3 cogs. Is it possible to load the 3 cog driver, use that to load all the other cogs (maybe storing cogs 6 and 7 temporarily in hub ram), then load in the one cog sd driver at the end for zicog to use?
The SD driver is a big issue. ZiCog really only uses the raw fsrw driver once the files start sectors have been located. I am not sure of the best way to solve this. Certainly some of the code can be culled and maybe this would allow for the code to be reduced to 2 cogs and maybe a few overlays in hub (hub space again) but it may be the best compromise. This requires further investigation.
Certainly we could shut the SD drivers down and load our own for ZiCog. There are also other solutions, just as long as we use the Std drivers if possible.
I see that the drivers being produced for SphinxOS can also still be used for normal code development (used as objects) so all not is in vain. I guess, the best test for this will be the serial driver and the 1-pin keyboard driver.
I am not worried about the load times either. They are now fast enough. Nothing like my trusty windoze device where I get my breakfast while I wait for my 1.5GHz laptop to boot!!!
One thing I ave been thinking about is making the std objects re-usable. From this I mean, being able to have 2 instances (cogs) of say the std serial driver. This would require 2 sets of rendezvous locations, so the driver must be initialised with the rendezvous location. Currently it is fixed, so it is not possible to have 2 copies. We may want 2 TV's (1 for debugging). So I guess, we want a StdIN & StdOut plus an AuxIN & AuxOut. Extras would be specific to other programs, not the OS.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Here is a proposal for a new Hub memory layout for Sphinx.
Hopefully I have reserved enough space to allow enough base drivers. Of course others can be added by sub-programs but I thought a number of fairly standard/common devices·may be in order.
I have added space for an SD buffer. I am not sure if this is necessary. We could just allocate it in the·run-code and provide this address on calls to the SD routines. The latter way would allow re-use of hub space if cog(s) are loaded, so it could be better not to allocate an SD buffer.
Any thoughts??
P.S. Actually I think it would be better to swap the IN & OUT interfaces. Why? Because I am used to SI being P31 and SO being P30, so to me the input should be the higher one.
I'm liking more and more Andy's parameter block idea—keeping system info in hub RAM, esp. pin assignments. I see a spare 128 bytes in the proposed memory map...
I'm not so sure you have to assign fixed locations for debug, aux, etc. anyway. Maybe that info could be updated dynamically in the parameter block.
@cluso: I don't think it is a good idea for ZiCog to take over the SD. It should play well just like other programs with the OS. I think we need to start defining the next level of abstraction for the SD. I would suggest it needs of course open/close, readblock, writeblock, and seek at the lowest level. There could be a generalized read and write that sits above the readblock and writeblock. If we are doing an OS then everybody needs to play by the same rules or it is not an OS. There should be rendezvous points for these routines - I will have to ponder if the disk buffer should be exposed or not - probably will need to for performance.
ZiCog is currently using a much later version of fsrw (SD driver). Once ZiCog locates the disk files needed in this higher layer (in spin) it is not required any longer, so we could then dispense with this higher level (reuse the space). ZiCog then uses lower level pasm layer for readblock/writeblock directly. However, the SD drivers in SphinxOS use 3 cogs and this ultimately will be an issue for any OS.
ZiCog actually has it's own OS, and Sphinx would be a layer above that. I see it enormously valuable to be able to tap into the SphinxOS I/O drivers although the high level SD drivers are really not required as CPM has it's own disk format. I don't see any advantage in making CPM use a FAT16 structure - it is just too much work.
The SD disk buffer has to be in hub either way. It is just a matter if it is in a pseudo fixed location, or it varies with sub-programs (like DIR, LS, etc).
Michael:
I don't like the wasted 128 byte block but I was trying to keep the SD buffer in a relatively easy place. I think if we dynamically allocate it per sub-program it may be the better way to go. The mini-computers I know have fixed buffer space allocated for a disk buffer.
Regarding the Aux, Dbg and "spare" rendezvous slots, they could be for anything, but they should at least have a name. I am expecting that we may need up to 16 longs for the SD interface although you currently only use 11 longs. So I think we should at least pre-allocate 32 longs for all rendezvous locations. Users can always redefine or reuse them. Perhaps we should start the SD rendezvous at $7F80-7FBF (16) and leave $7FC0-7FE7 (10) free for users, plus $7FE8-7FFF (6) for Dbg(or Ax2), Aux and Std I/O. Perhaps we could then put the SD buffer at $7D80-7E7F (512 Bytes).
Comments???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Looks very good, only one suggestion at this time:
stderr_out
It would be possible to use debug out for it, however by having a separate hook for stderr, it could be logged to SD etc
Cluso99 said...
Here is a proposal for a new Hub memory layout for Sphinx.
Hopefully I have reserved enough space to allow enough base drivers. Of course others can be added by sub-programs but I thought a number of fairly standard/common devices may be in order.
I have added space for an SD buffer. I am not sure if this is necessary. We could just allocate it in the run-code and provide this address on calls to the SD routines. The latter way would allow re-use of hub space if cog(s) are loaded, so it could be better not to allocate an SD buffer.
Any thoughts??
P.S. Actually I think it would be better to swap the IN & OUT interfaces. Why? Because I am used to SI being P31 and SO being P30, so to me the input should be the higher one.
Consider this scenario...
<UL>
<LI>StdIN & StdOUT = Keyboard In, TV Out
<LI>AuxIN & AuxOUT = PC Serial
<LI>DbgIN & DbgOUT = Keyboard2 (1-pin), TV2 Out (1-pin) (debug terminal - 2 pin connection)
* spare & spare = Mouse In, Sound out
</UL>
@Cluso: I understand how ZiCog uses the SD. But you could just as easily ask the SphinxOS for a "file handle" that you can then call raw readblocks from the file. I thought SphinxOS was the underlying OS not ZiCog and ZiCog is an application running on top of SphinxOS. I see ways how this can be done and in the end may make ZiCog easier to use, by calling standard interfaces instead of embedding the SD driver in ZiCog. Also with a good seek which I think is available in the new fsrw code then you don't even require that the files be contiguous. It might me a little slower but the flexibility will out weigh the current requirements.
I agree that the buffer will still stay there - the question how much it is exposed to applications. If you think down the road it may be possible to run multiple programs (multitasking so we need to think about keeping things private and isolated)
You are correct. SphinxOS is the OS, not ZiCog. And ZiCog should use the stdin & stdout, Aux, etc (using the io port mechanism in cpm to redirect). ZiCog could use the Sphinx fswr readblock/writeblock routines (Sphinx needs the latest fsrw routines which is not insignificant to do, so later).
However, the point I am making is that Sphinx uses 3 cogs and ZiCog only uses 1 cog for fsrw. For most of us that is not a problem as we have cogs to burn. However, Drac & his followers are using all cogs. That is the dilema.
@Bill: Good suggestion for StdErr. It could couple with Mouse (in) for the next pair. Of course, these hooks could be re-used/re-defined by the user, but give a suggestion of what hooks to use for standard ports.
General:
I think it may be best not to define a buffer for SD. That way we can redirect it and multiple cogs can then use it (with appropriate locks). So we may be able to reuse some hub area for this. I will wait for a little more discussion before I update the table.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
@cluso: Yes I agree that the SD driver needs work. As long as your long term is to head in that direction I am ok with it. It has been always my observation is that once you do it that way it is hard to go back and do it the hard way. For the cog hungry people maybe we will have to start thinking about a virtual memory manager and a cog swapper to swap cogs from running cogs to SD and load another cog and resume it. That is going to take some time
@mpark: well I could imagine in the future you might more than one task running if you have free cogs. The other process might want or need access to the filesystem so you have to store file handles that store offset and filename, etc. We will have a full blown lite OS eventually. It will take some time and coordination.
@mpark: Consider you have a Sphinx aware program running in 1 cog and ZiCog in another - totally feasible. Both would require SD access at various times. In fact, IIRC ZiCog uses the SD from more than 1 cog, but never at the same time though.
@yoda: I already expect to be able to swap cog code on the fly, but not perhaps as detailed as you suggest (i.e. being able to resume a cog).
My hope is that we can switch drivers on the fly. However, this would be a sort of reloading drivers depending on what program was being run. Anyway, too much dreaming and not enough reality for now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Thanks - I really like the work you and the other guys are doing on this!
May I suggest lock 1 or 7 for your SD buffer?
I already use LOCK 0 on Morpheus for memory locking.
Heck! I propose standardizing on using LOCK 0 for XMM locking, and LOCK 1 for SD buffer locking!
Cluso99 said...
@Bill: Good suggestion for StdErr. It could couple with Mouse (in) for the next pair. Of course, these hooks could be re-used/re-defined by the user, but give a suggestion of what hooks to use for standard ports.
General:
I think it may be best not to define a buffer for SD. That way we can redirect it and multiple cogs can then use it (with appropriate locks). So we may be able to reuse some hub area for this. I will wait for a little more discussion before I update the table.
Cluso99 said...
@mpark: Consider you have a Sphinx aware program running in 1 cog and ZiCog in another - totally feasible. Both would require SD access at various times...
OK, but how many cogs are actually twiddling the SD lines?
As for locks, what is really being locked? There are several resources up for grabs here: the SD pins, the 512-byte buffer(s), the cog(s) transferring data between the buffer and the SD card.
My vague mental model of the system is that *one* cog running the low-level fsrw driver has exclusive access to the SD pins. Any cogs that want SD access have to go through the fsrw cog's rendezvous. This implies to me that the lock has to be on the rendezvous, not the buffer.
Edit: The low-level driver just read/writes sectors directly (no filesystem as such).
@mpark: Absolutely, only 1 cog has access to the SD pins. My TriBlade has a further problem because it shares pins with the sram address lines. I corrected this in the RamBlade design as it shares the sram data lines.
So, the lock only needs to be in calling the SD cog(s). Buffers should be seperate if they are required by multiple calling cogs and the user can control this. Maybe another reason not to necessarily predefine a buffer.
BTW I modified the rendezvous layout last night and compiled a new version. However, at 4am I had a bug so couldn't post the code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
Then you could kill the SD driver while leaving In and Out for ZiCog, no?
The SD driver is another matter. The raw driver needs a cog and should be resident always. It would be nice to combine the other 2 cogs into 1 but I am not sure if this is even possible as I have not looked.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Option 1 is really kind of defeating the purpose of an operating system if all you are going to do is replace everything and run ZiCog and then restart the OS after you terminate ZiCog. I like the option of connecting up ZiCog to "stdin and stdout". In regards to the SD we probably need to look at trying to make it run in one or 2 Cogs.
The terminal interface has also been bothering me as well. I think we need to stick to serial flow. I was thinking of taking PrEdit and seeing how hard it would be to change to using vt100 codes to move around the screen - essentially making it use serial instead of vga. Would still probably need an edit buffer but I think that is doable. Catalina should be straight forward I think but have not looked at it but C programs have a notion of stdin and stdout already so with the appropriate linkage it should work. I have not looked at propBasic but I would it would fall somewhere near Catalina in making it use a serial type driver.
on the differentiation of binaries - is there anywhere in the binary header of a prop binary for us to put a magic number? If not the then we can use an extension. Probably should not use .com to be confused with dos or cpm programs that could also be on the SD.
I like the stdin & stdout method too. I agree using vt100 would be the better way. After all, Wordstar does this and it works fine.
Binaries - nothing I know of to differentiate. The better solution would be a differecnt extension. Maybe ".bix" for the sphinx 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)·
· 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
On the binaries, I was hoping there might be a byte in the Prop header that we might steal for a loader to detect. .bix sounds ok or maybe .spx or .sfx works too ?
Kuroneko: I wouldn't want to interfere with the binary code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
You could borrow the high nybble in the clockfreq long provided you put it back when you were finished with it. In fact, you could get 5 bits if you were careful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
So, somehow, if you could reclaim this by loading the 2k blocks into a 2k buffer from an sd card or some other source (eg upper part of a 64k eeprom) then potentially you could save 12k to 14k of hub ram, which could now be used for other things - eg more code or a screen buffer or whatever.
Given a typical object (I used the keyboard object as an example) one can certainly compile the spin part and leave out the PASM part and it all works. But if you compile the PASM part without the spin part, most objects have references to hub ram locations within the code. So, you can pass those locations with a Start but it is still a bit messy and not a universal or standardised solution.
But as I understand it, Cluso is taking Sphinx and building objects which use a common location in hub ram to communicate to hub. Cluso says "In SphinxOS, the standard output has a long and the standard input has a long hub interface. ($7F80 & $7FC0). The multiple character buffers are within the cog."
This sounds very interesting, especially given a number of standard I/O objects are already coded and working - eg keyboard, serial (Cluso will no doubt update more).
This could give you the building blocks for the things you commonly need in a program - serial ports, TV, VGA, keyboard, and in a language/method that is standardised and easy to understand.
I'm still thinking through the implications of this, but it sounds intriguing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 2/1/2010 5:39:19 AM GMT
Drac: The implications of a seperately compiled cog code (cog objects)·is that it must be self-resident with minimal hub interaction as this must be with fixed (known location·and defined size/protocol) hub locations. This is in fact what CPM and other OSes do. We access these drivers through a defined interface. In SphinxOS, the standard output has a long and the standard input has a long hub interface. ($7F80 & $7FC0). The multiple character buffers are within the cog.
For input (i.e. a keyboard)...·as another cog/spin takes a character out and clears the hub, the driver cog looks, sees it it empty (=0) and places another character into the hub buffer (if one is available in the cog buffer). The process repeats. This method may not be quite as fast but reduces the hub footprint. The opposite works for output.
Once everything goes via this standard interface, the driver may be substituted without changing the calling program. So, you can substitute a pc serial for the keyboard, or a remote wireless connection. The calling program has no need to know.
So far, for input, we have serial, keyboard, 1-pin keyboard (almost complete). For output, we have serial, video (TV composite 3pin), with 1-pin TV as a wip.
We also have fsrw (SD card driver) but this has the whole file system interface as well BUT currently takes 3 cogs, so this·warrants some reworking.
Here is a link to SphinxOS code v006 (near the bottom of the page) http://forums.parallax.com/showthread.php?p=819353
IIRC the driver is sx---.spin and the calling interface is isx---.spin (two calling files, one input and one output). The drivers can be substituted while the calling interface remains unchanged.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Drac: The building blocks are already being extended (see http://propeller.wikispaces.com/Sphinx·)
The way SphinxOS works is it loads the drivers. Then it can load another binary to either...
So, after loading SphinxOS, ZiCog could be loaded which utilises these drivers, but it would not have to load them, nor would it have them in it's binary (or hub space).
Now, taking this a little further (and slightly extending the boot time)...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Load times would not be a problem given the huge memory advantages.
One thing I have seen is that the sd code is now taking 3 cogs. I'm using a version that takes one, and I understand there are good reasons for using 3 cogs. Is it possible to load the 3 cog driver, use that to load all the other cogs (maybe storing cogs 6 and 7 temporarily in hub ram), then load in the one cog sd driver at the end for zicog to use?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Certainly we could shut the SD drivers down and load our own for ZiCog. There are also other solutions, just as long as we use the Std drivers if possible.
I see that the drivers being produced for SphinxOS can also still be used for normal code development (used as objects) so all not is in vain. I guess, the best test for this will be the serial driver and the 1-pin keyboard driver.
I am not worried about the load times either. They are now fast enough. Nothing like my trusty windoze device where I get my breakfast while I wait for my 1.5GHz laptop to boot!!!
One thing I ave been thinking about is making the std objects re-usable. From this I mean, being able to have 2 instances (cogs) of say the std serial driver. This would require 2 sets of rendezvous locations, so the driver must be initialised with the rendezvous location. Currently it is fixed, so it is not possible to have 2 copies. We may want 2 TV's (1 for debugging). So I guess, we want a StdIN & StdOut plus an AuxIN & AuxOut. Extras would be specific to other programs, not the OS.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Hopefully I have reserved enough space to allow enough base drivers. Of course others can be added by sub-programs but I thought a number of fairly standard/common devices·may be in order.
I have added space for an SD buffer. I am not sure if this is necessary. We could just allocate it in the·run-code and provide this address on calls to the SD routines. The latter way would allow re-use of hub space if cog(s) are loaded, so it could be better not to allocate an SD buffer.
Any thoughts??
P.S. Actually I think it would be better to swap the IN & OUT interfaces. Why? Because I am used to SI being P31 and SO being P30, so to me the input should be the higher one.
Consider this scenario...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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) : 2/1/2010 9:20:30 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I'm not so sure you have to assign fixed locations for debug, aux, etc. anyway. Maybe that info could be updated dynamically in the parameter block.
Dave
ZiCog is currently using a much later version of fsrw (SD driver). Once ZiCog locates the disk files needed in this higher layer (in spin) it is not required any longer, so we could then dispense with this higher level (reuse the space). ZiCog then uses lower level pasm layer for readblock/writeblock directly. However, the SD drivers in SphinxOS use 3 cogs and this ultimately will be an issue for any OS.
ZiCog actually has it's own OS, and Sphinx would be a layer above that. I see it enormously valuable to be able to tap into the SphinxOS I/O drivers although the high level SD drivers are really not required as CPM has it's own disk format. I don't see any advantage in making CPM use a FAT16 structure - it is just too much work.
The SD disk buffer has to be in hub either way. It is just a matter if it is in a pseudo fixed location, or it varies with sub-programs (like DIR, LS, etc).
Michael:
I don't like the wasted 128 byte block but I was trying to keep the SD buffer in a relatively easy place. I think if we dynamically allocate it per sub-program it may be the better way to go. The mini-computers I know have fixed buffer space allocated for a disk buffer.
Regarding the Aux, Dbg and "spare" rendezvous slots, they could be for anything, but they should at least have a name. I am expecting that we may need up to 16 longs for the SD interface although you currently only use 11 longs. So I think we should at least pre-allocate 32 longs for all rendezvous locations. Users can always redefine or reuse them. Perhaps we should start the SD rendezvous at $7F80-7FBF (16) and leave $7FC0-7FE7 (10) free for users, plus $7FE8-7FFF (6) for Dbg(or Ax2), Aux and Std I/O. Perhaps we could then put the SD buffer at $7D80-7E7F (512 Bytes).
Comments???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
stderr_out
It would be possible to use debug out for it, however by having a separate hook for stderr, it could be logged to SD etc
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
I agree that the buffer will still stay there - the question how much it is exposed to applications. If you think down the road it may be possible to run multiple programs (multitasking so we need to think about keeping things private and isolated)
Dave
You are correct. SphinxOS is the OS, not ZiCog. And ZiCog should use the stdin & stdout, Aux, etc (using the io port mechanism in cpm to redirect). ZiCog could use the Sphinx fswr readblock/writeblock routines (Sphinx needs the latest fsrw routines which is not insignificant to do, so later).
However, the point I am making is that Sphinx uses 3 cogs and ZiCog only uses 1 cog for fsrw. For most of us that is not a problem as we have cogs to burn. However, Drac & his followers are using all cogs. That is the dilema.
@Bill: Good suggestion for StdErr. It could couple with Mouse (in) for the next pair. Of course, these hooks could be re-used/re-defined by the user, but give a suggestion of what hooks to use for standard ports.
General:
I think it may be best not to define a buffer for SD. That way we can redirect it and multiple cogs can then use it (with appropriate locks). So we may be able to reuse some hub area for this. I will wait for a little more discussion before I update the table.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
@mpark: well I could imagine in the future you might more than one task running if you have free cogs. The other process might want or need access to the filesystem so you have to store file handles that store offset and filename, etc. We will have a full blown lite OS eventually. It will take some time and coordination.
@yoda: I already expect to be able to swap cog code on the fly, but not perhaps as detailed as you suggest (i.e. being able to resume a cog).
My hope is that we can switch drivers on the fly. However, this would be a sort of reloading drivers depending on what program was being run. Anyway, too much dreaming and not enough reality for now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
May I suggest lock 1 or 7 for your SD buffer?
I already use LOCK 0 on Morpheus for memory locking.
Heck! I propose standardizing on using LOCK 0 for XMM locking, and LOCK 1 for SD buffer locking!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
OK, but how many cogs are actually twiddling the SD lines?
As for locks, what is really being locked? There are several resources up for grabs here: the SD pins, the 512-byte buffer(s), the cog(s) transferring data between the buffer and the SD card.
My vague mental model of the system is that *one* cog running the low-level fsrw driver has exclusive access to the SD pins. Any cogs that want SD access have to go through the fsrw cog's rendezvous. This implies to me that the lock has to be on the rendezvous, not the buffer.
Edit: The low-level driver just read/writes sectors directly (no filesystem as such).
Post Edited (mpark) : 2/2/2010 8:12:22 PM GMT
So, the lock only needs to be in calling the SD cog(s). Buffers should be seperate if they are required by multiple calling cogs and the user can control this. Maybe another reason not to necessarily predefine a buffer.
BTW I modified the rendezvous layout last night and compiled a new version. However, at 4am I had a bug so couldn't post the code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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