Shop OBEX P1 Docs P2 Docs Learn Events
ErNa's starting point — Parallax Forums

ErNa's starting point

ErNaErNa Posts: 1,752
edited 2016-02-18 15:31 in Propeller 1
I use this discussion as a starting point for the current project: create a multi process environment that allows standardized communication between cogs and props.
In parallel to these contributions I create a documentation using CMapTools. This documentation is stored on a server submesh.de. CMap Tool allow collaboration, the software is available for free and for those, which only want to take a look there is a web representation with limited abilities. Native access is to prefer.

This is a notepad for links I have to follow
forums.parallax.com/discussion/163160/help-create-the-spin-standard-library/p3
forums.parallax.com/discussion/128397/callbacks-and-method-pointers-in-spin
forums.parallax.com/discussion/162771/forcing-spin-to-not-use-the-first-512-bytes
forums.parallax.com/discussion/120467/procedure-variables-or-callbacks-in-spin
forums.parallax.com/discussion/163289/quickstart-compatible-cpu-board-prime/p1
orrtech.us/propdos/index.html OldBitCollector's eeprom based OS. Has to be analyzed
forums.parallax.com/discussion/131610/appnote-content-input-request-propeller-to-propeller-communication/p1 Had forgotten, that ever existed
forums.parallax.com/discussion/123055/what-should-a-propeller-os-have-sphinx-sphinxos-propdos-propcmd-fatengine/p4 Very interesting question!

As I see, there are efforts on the way to create a standard for SPIN, but the thread now is already 5 pages, a lot to study

Comments

  • ErNaErNa Posts: 1,752
    In a first step I have installed Cluso's Prop-OS. I now can attach a terminal (PST) and run the commands. I see, that 5 cogs are availabe.
    Now, as I have some CP/M experiences, I have to understand, how to write programs. The CP/M commands will give some advice, how to use the OS. But I do not know for now, if there is something comparable to the BIOS jump table and how the BDOS entry is made.
    A first goal is to attach an ADC and stream the data to a file.
  • Heater.Heater. Posts: 21,230
    Certainly there is a BIOS jump table in CP/M. All the source code for the CP/M we use is available from http://schorn.ch/altair.html

    We did make some changes to the BIOS at least to run under the emulator on the Prop. I'm sure Cluso has all that. My versions are stashed away somewhere I can't get to easily just now.
  • Cluso99Cluso99 Posts: 18,069
    ErNa,
    Do you want to run CPM or PropOS?
    My OS uses upper hub to store values and mailboxes. But it is not like CPM's BIOS. Take a look at _hubdef.spin for the list of used/reserved locations - it is fairly descriptive.
  • ErNaErNa Posts: 1,752
    Hi Cluso, this question is to answer yes, yes. CP/M I want to run due to the fact: it remembers me of the old times, when I could rule the microcomputer ;-) AND: computer history now becomes science and young people, that restore old microcomputers, need to have hands on experience before the vintage systems are running. And later too. But in my current project I have to aquire data, store them to a memory, make some filter processes, display them locally and send them to the net. And I want to do it from scratch with the propeller. In a first step I have to understand all the efforts already done (list in my first post), to do this I create some CMaps.
    Spinneret more or less seems to be dead, the wiznet board for quickstart is depricated. That gives me a push into the Tachyon direction. So hopefully in the end everything will fit together.
  • Cluso99Cluso99 Posts: 18,069
    CPM runs on my RamBlade using heater's ZiCog (emulates the Z80 instructions). The SD is divided into 8 x 8MB HDDs.
    The RamBlade has a 512KB (512Kx8) 55ns SRAM and an SD disk. Two spare Prop pins remain for either serial or 1-pin TV and 1-pin PS2-Keyboard, or whatever else you can do with 2 pins.

    CPM 2.2 runs with my PropOS. The OS runs a ZiCog binary (replaces the OS). When you are finished running CPM, type EXIT at the command prompt and it reboots PropOS.

    The HDD drives are 8 separate contiguous 8MB files built under FAT16/32. My OS had programs that can map (dir display) the CPM drives, and transfer files back and forth between CPM and FAT16/32, as well as the PC.

    If you want to take a look at the CPM files, I can email you one of the HDD images (FAT file) and you can copy to an SD card and display the directory contents using the MAPCPM command (perhaps I should have called it DIRCPM?)

    Note ZiCog is not quite a complete Z80 emulation so there are a few complex CPM programs that do not work. MBASIC and WORDSTAR are known to work.
  • kwinnkwinn Posts: 8,697
    ErNa wrote: »
    Hi Cluso, this question is to answer yes, yes. CP/M I want to run due to the fact: it remembers me of the old times, when I could rule the microcomputer ;-) AND: computer history now becomes science and young people, that restore old microcomputers, need to have hands on experience before the vintage systems are running. And later too. But in my current project I have to aquire data, store them to a memory, make some filter processes, display them locally and send them to the net. And I want to do it from scratch with the propeller. In a first step I have to understand all the efforts already done (list in my first post), to do this I create some CMaps.
    Spinneret more or less seems to be dead, the wiznet board for quickstart is depricated. That gives me a push into the Tachyon direction. So hopefully in the end everything will fit together.

    Instead of creating yet another emulator to run CPM 8080/Z80 code why not duplicate the commands and functionality of CPM with spin and pasm, and at the same time upgrade it to make use of current hardware.

    That would create a more useful system that is familiar to a lot of us old...um...er long time computer users.
  • David BetzDavid Betz Posts: 14,516
    I don't really have much desire to go back to CP/M. I liked it at the time but I don't think I could deal with a filesystem without subdirectories anymore. I'd like to see this turn into a modern OS, not a clone of some obsolete one.
  • yetiyeti Posts: 818
    David Betz wrote: »
    I don't really have much desire to go back to CP/M. I liked it at the time but I don't think I could deal with a filesystem without subdirectories anymore. I'd like to see this turn into a modern OS, not a clone of some obsolete one.
    Add subdirs and call it DOS... that replicates the way history already has gone before...
  • kwinnkwinn Posts: 8,697
    David Betz wrote: »
    I don't really have much desire to go back to CP/M. I liked it at the time but I don't think I could deal with a filesystem without subdirectories anymore. I'd like to see this turn into a modern OS, not a clone of some obsolete one.

    Subdirectories were definitely included in the "upgraded" part of my post, as is a modern file system that can deal with large sd cards, and if possible also USB drives.
  • David BetzDavid Betz Posts: 14,516
    kwinn wrote: »
    David Betz wrote: »
    I don't really have much desire to go back to CP/M. I liked it at the time but I don't think I could deal with a filesystem without subdirectories anymore. I'd like to see this turn into a modern OS, not a clone of some obsolete one.

    Subdirectories were definitely included in the "upgraded" part of my post, as is a modern file system that can deal with large sd cards, and if possible also USB drives.
    Sounds good but why continue to link this with CP/M at all? In fact, ErNa wants distributed processing across multiple Propeller chips and that's about as far from CP/M as I can imagine.

  • kwinnkwinn Posts: 8,697
    David Betz wrote: »
    kwinn wrote: »
    David Betz wrote: »
    I don't really have much desire to go back to CP/M. I liked it at the time but I don't think I could deal with a filesystem without subdirectories anymore. I'd like to see this turn into a modern OS, not a clone of some obsolete one.

    Subdirectories were definitely included in the "upgraded" part of my post, as is a modern file system that can deal with large sd cards, and if possible also USB drives.
    Sounds good but why continue to link this with CP/M at all? In fact, ErNa wants distributed processing across multiple Propeller chips and that's about as far from CP/M as I can imagine.

    Mainly because ErNa posted his desire to run CPM. My suggestion was for him to port/adapt the software to run as native spin/pasm code rather than emulated 8080/Z80 code, and adapt it to modern hardware.
  • ErNaErNa Posts: 1,752
    Hello, thanks for discussion. Yes, there are so many ways the can not all be followed. So CP/M to me is a basic OS, that show principles like jump table to reach the BIOS and call function with function # to call higher level entrys. This in fixed place starting from low addresses, and higher level functions located at high address space leaving usable memory inbetween. Then there were build in functions and loadable functions. In these principles nothing changed. But in the past it was a mistake to change the names of functions (in my eyes) because this makes it more or less impossible to switch between different systems. If nowadays I call a command "HELP" I expect to get help and I should not care, how this is implemented. I hope we can streamline much of the work done over the years by learning what was done why and bringing it to a common format. And this is not another river going to the desert. ;-)
  • David BetzDavid Betz Posts: 14,516
    ErNa wrote: »
    Hello, thanks for discussion. Yes, there are so many ways the can not all be followed. So CP/M to me is a basic OS, that show principles like jump table to reach the BIOS and call function with function # to call higher level entrys. This in fixed place starting from low addresses, and higher level functions located at high address space leaving usable memory inbetween. Then there were build in functions and loadable functions. In these principles nothing changed. But in the past it was a mistake to change the names of functions (in my eyes) because this makes it more or less impossible to switch between different systems. If nowadays I call a command "HELP" I expect to get help and I should not care, how this is implemented. I hope we can streamline much of the work done over the years by learning what was done why and bringing it to a common format. And this is not another river going to the desert. ;-)
    You're right. It would be best to follow convention if possible. I'm not sure CP/M would be my model. Maybe Unix/Linux would be better for a system that is supposed to handle mulitple asynchronous processes.

  • ErNaErNa Posts: 1,752
    I worked with TurboDos. This was a rewrite of CP/M, composed of about 30 modules you could create simple slaves, simple masters, file and printer servers... A standard workstation had about 20 modules and was running in multitasking console i/o, file system, printer, printer spooler. More: this workstation had a node/line address and there could be attached a network driver to create a computer network (or better: Network computer). I remember to first saw semaphores and understood to use them.
  • msrobotsmsrobots Posts: 3,709
    kwinn wrote: »
    ...

    Mainly because ErNa posted his desire to run CPM. My suggestion was for him to port/adapt the software to run as native spin/pasm code rather than emulated 8080/Z80 code, and adapt it to modern hardware.

    You are missing something here @kwinn.

    The emulation of a Z80 does provide access to a lot of software already written for Z80 running CP/M. So technically @Heater, @Cluso99, @Pullmoll, @DR_Acula and other propellerheads where able to run a C compiler FIRST on a propeller. Before Catalina, PropGCC and Imagesoft.

    Even WordStar and to @Heaters disappointment even Bill Gates Basic...

    Besides hoping that we ever will get something like a P2 I really hope that @heater will start on ZiCog2. Just for the fun of it.

    @ErNa

    I am not sure about Peters Tachyon, but Sal's PropForth already did the part of seamlessly integrate multiple propeller Chips into one CMD interface. Run something on COGx of PROPy.

    Since Peter is working on some multiple prop project now he might already has implemented something there also, but I am not so up to date with FORTH at all, never could wrap my head around that language.

    SPIN/PASM do not support multiple Props per se and as far as I can see Catalina and PropGCC do not support this either.

    Beau made a nice attempt to use multiple Props by having a part of HUB memory shared by multiple Props by circulating it around at pretty fast speed between different Props so HUB mailboxes can be used between different Props.

    But no really support for this in the tool chains.

    @Heater showed with one of his FFT implementations that PropGCC can use OpenMP or whatever it was called to automagically parallelize C code on different COGs of one Prop. Would be a interesting question if it would be able to enhance that to use more as one Prop and still do that.

    Enjoy!

    Mike

  • kwinnkwinn Posts: 8,697
    Cluso had some good ideas in his propeller os thread. The "Rendezvous" location in particular seems like a good replacement for the Bios jump table.
  • David BetzDavid Betz Posts: 14,516
    edited 2016-02-19 22:14
    msrobots wrote: »
    I am not sure about Peters Tachyon, but Sal's PropForth already did the part of seamlessly integrate multiple propeller Chips into one CMD interface. Run something on COGx of PROPy.

    Since Peter is working on some multiple prop project now he might already has implemented something there also, but I am not so up to date with FORTH at all, never could wrap my head around that language.
    I know what you mean about that but I'd still like to try again some day. It's quite impressive what Forth can do with limited resources and it sure beats the original BASIC!

  • kwinnkwinn Posts: 8,697
    @msrobots

    Re:

    You are missing something here @kwinn.

    The emulation of a Z80 does provide access to a lot of software already written for Z80 running CP/M. So technically @Heater, @Cluso99, @Pullmoll, @DR_Acula and other propellerheads where able to run a C compiler FIRST on a propeller. Before Catalina, PropGCC and Imagesoft.

    That's a very good point, and I am not suggesting that it is a bad choice if you want an os with a lot of software available. I ran a business with CPM for quite a while so am familiar with what could be accomplished.

    What I am suggesting is that it may be better to provide a familiar user interface using the languages and hardware the propeller provides. While the P1 is somewhat memory limited compared to the 8080/Z80 I think taking full advantage of the P1 architecture and currently available add on hardware would provide a much more useful system. Multitasking and even a simplified windowing system should be possible.
  • Cluso99Cluso99 Posts: 18,069
    The prop is a very different animal compared to the likes of Z80 and x86 (and 6502).

    There were a few reasons to go the way CPM did.
    Compilers were expensive.
    A lot of code was written by hand in assembler and simply compiled.
    Extracting a lot of common code and placing it in stay-resident code and using jump tables made sense.

    In the prop...
    We have 8 cores.
    We are (now) limited with hub space.

    IMHO a better way is to have single "character" output and input objects totally decoupled from the actual driver. They connect to a character mailbox in hub to their actual cog drivers that handle the physical/hardware interface.

    An example of this is _StdIn.spin and _StdOut.Spin (the character input and output objects compiled into your code) and _PCSIO.spin as the cog driver performing the serial driver. _PCSIO.spin can be substituted with OnePinKeyboard.spin and OnePinTVText.spin, or any other character driver(s), all without the user software knowing.

    These character interfaces utilise a single long mailbox / rendezvous location to pass characters in a single direction. You will note there is no hub buffer. But _PCSIO utilises a tailored version of FullDuplexSerial with 2 x 160 long cog buffers. _PCSIO fills/empties the buffers during unused cog time in between outputting and inputting serial "bits". This is just what the prop's cogs were designed to do.

    There are at least 3 versions of SD Drivers that I am aware of. All use different interface methods making them very specific for use. IMHO Kye's SDFATEngine is the best because it provides support for FAT16 & FAT32, SD & SDHC, and a lot of general access methods and file handling. However, the interface to the user program is not well suited to being a separate stay-resident cog driver. I am working on this and it has taken a long time! The hub interface is way too large and needs to be reduced.

    Sphinx was a basic OS and compiler written by Michael Park. It utilises the rendezvous mailboxes that we all were discussing at the time. However, Michael uses a version of FSRW, again with a largish hub interface. But it only supports FAT16 and may have some form of SD bug as cards seem to be corrupted from time to time. It has taken me ages to try and replace FSRW with a modified version of Kye's SDFATEngine. Two of the three compiler programs translated easily (LEX and LINK), but the main one (CODEGEN) is proving to be a real PITA.

    But one advantage to using the _StdOut stub is that any object in the CODEGEN chain can simply output a debug message by including the stub in that object. Because the stub is PUBs only (no VAR or DAT) there is no code penalty as it is already in use in the main object. So, just add OBJ Print: "_StdOut" and you are good to use Print.Char, Print.Str, etc. This is a difficult task, if not almost impossible, using an object such as FullDuplexSerial !!!

    BTW Catalina supports it's own version of rendezvous/mailboxes and works fine with other spin/pasm cogs.

    Unfortunately, every attempt in the past 8 years to get consensus about mailboxes failed miserably. Most comments were negative and why do we need it!
  • Heater.Heater. Posts: 21,230
    Wait a minute. The whole CP/M on the Propeller was a deviant aberration on my part. In no way recommended for serious use.

    I was curious to play with the Prop and as an exercise decided to write a 8080 emulator in PASM. See PropAltair. As at test program Bill's 4K BASIC was an obvious candidate.

    Then I got curious about the history of CP/M, which I used back in the day. Seeing as the source for CP/M is now open there was no turning back until it was running in the Prop. Which of course leads to having the first C compiler for the Prop, BDSC. Still the only one that actually compiles C programs on the Prop itself! And Wordstar and so on.

    Somewhere along the line it was decided that extending the 8080 emulation into a Z80 would be a nice idea. Not needed for most CP/M programs but there we go. There are a couple of missing Z80 opcodes still, EX, EXX and some bit twiddling operations that no one ever uses. Must get round to fixing those one day.

    Then came the external memory additions so we could have a full up 64K RAM CP/M system....

    Then came Pullmoll and his excellent qZ80 emulator for the Propeller. Which has been used to recreate Sinclair and other machines.

    Some thoughts:

    One could implement CP/M commands and file system on the Prop without an actual Z80 emulator. I'm not sure I see the point. A Propeller does not need an operating system and we have FAT file systems for SD cards if we need storage. The end result would not really be any CP/M but only look and feel a bit like it. Do we really want that?

    I was recently thinking that I'm not much interested in reworking the PASM ZiCog emulator to run on the Prop 2. There are some pretty lean and mean Z80 emulations in C out there. The P2 has a huge memory space and a lot more speed. Let's just use a Z80 emulator in C.

    The P2 has a huge memory space. Compared to CP/M systems of back in the day. CP/M on there makes little sense.











  • Cluso99Cluso99 Posts: 18,069
    There were a lot of good CPM programs out there. Nice editors, spreadsheets, etc. Lots of languages including Basic, Pascal, etc.

    While I can transfer files between CPM and FAT, what would be really nice would be to change the CPM BIOS to use the FAT (FAT32) fie system. IMPOSSIBLE I SAY !!! ;)
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-02-20 03:02
    Many times I see mention of SD and FAT16 support but isn't that a bit like offering floppy and FAT12 support these days? I can't buy a card off the shelf that is less than 4GB with 8G and 16G good value and they are all SDHC or more and FAT32 or exFAT.
  • kwinnkwinn Posts: 8,697
    @Cluso99
    The prop is a very different animal compared to the likes of Z80 and x86 (and 6502).

    In the prop...We have 8 cores...We are (now) limited with hub space.[/quote]

    Exactly so. We need to take advantage of the cog ram to save hub ram. The speed boost and flexibility that provides is an added bonus.
    IMHO a better way is to have single "character" output and input objects totally decoupled from the actual driver. They connect to a character mailbox in hub to their actual cog drivers that handle the physical/hardware interface.

    I agree 100%. Makes for a minimal hub ram interface that is flexible enough to be used for many languages.
    While I can transfer files between CPM and FAT, what would be really nice would be to change the CPM BIOS to use the FAT (FAT32) fie system. IMPOSSIBLE I SAY !!!

    FAT32 is definitely the way to go.

    @Heater
    Wait a minute. The whole CP/M on the Propeller was a deviant aberration on my part. In no way recommended for serious use.

    I wasn't suggesting we replace our PC's with a propeller and cpm, but it could make a great hardware troubleshooting and development tool. Look at all the interface and communications options already in the obex. Imagine carrying them all in one small package.

    @Peter
    Many times I see mention of SD and FAT16 support but isn't that a bit like offering floppy and FAT12 support these days? I can't buy a card off the shelf that is less than 4GB with 8G and 16G good value and they are all SDHC or more and FAT32 or exFAT.

    Absolutely. FAT32 is the way to go. Most compatible and a good fit for this purpose.
  • yetiyeti Posts: 818
    edited 2016-02-20 13:14
    Cluso99 wrote: »
    While I can transfer files between CPM and FAT, what would be really nice would be to change the CPM BIOS to use the FAT (FAT32) fie system. IMPOSSIBLE I SAY !!! ;)
    Very impossible: ;-D
    http://runcpm.blogspot.de
    http://cpmduino.blogspot.de

    ...and Single-User-Multitasking kinda is in MP/M... just configure it for only 1 terminal...
    (-: ...just in case this is the next topic... ;-)

    You easily can try that out with http://schorn.ch/altair.html and the MP/M diskimages from there...
Sign In or Register to comment.