I'm writing a library for "running" co-processors

edited November 2010 in Chit chat
Crossposted at amibay and classicamiga.

Well the point of this library is that a user can take control over a co-processor (that may be either emulated or real). This has a use when you want to launch a binary on a specific architecture (an example is being developed in parallel by me that loads a CP/M executable onto a Z80 and translates syscalls to the native ones on the host operating system) (other uses include running binaries on your system's GPU. I imagine in the future we could have java and flash etc implemented in hardware or FPGA).

I'm looking for people that can help with development. At the moment what you need is imagination and a knowledge of C. And a willingness to learn my very simple API. And an almost fanatical devotion to the pope.

This software at the moment builds on linux only (and probably *BSD et al.) as far as I know, but I hope in the future it will become cross-platform.

You can get the source code at amibay (not sure if you have to have a log in to download it). This source code is available under the GNU Public License.
Post edited by wilsonsamm on

Comments

  • edited November 2010
    wilsonsamm wrote: »
    Crossposted at amibay and classicamiga.

    Well the point of this library is that a user can take control over a co-processor (that may be either emulated or real). This has a use when you want to launch a binary on a specific architecture (an example is being developed in parallel by me that loads a CP/M executable onto a Z80 and translates syscalls to the native ones on the host operating system) (other uses include running binaries on your system's GPU. I imagine in the future we could have java and flash etc implemented in hardware or FPGA).

    I'm looking for people that can help with development. At the moment what you need is imagination and a knowledge of C. And a willingness to learn my very simple API. And an almost fanatical devotion to the pope.

    This software at the moment builds on linux only (and probably *BSD et al.) as far as I know, but I hope in the future it will become cross-platform.

    You can get the source code at amibay (not sure if you have to have a log in to download it). This source code is available under the GNU Public License.
    YES, I've a great imagination, well versed in C and...

    damn, I'm not a Catholic.
    I wanna tell you a story 'bout a woman I know...
  • edited November 2010
    This sounds like a fascinating project and would have loved to be involved had I had more spare time and my ever increasing work load.
    I wanna tell you a story 'bout a woman I know...
  • edited November 2010
    karingal wrote: »
    This sounds like a fascinating project
    Thanks!
    karingal wrote: »
    and would have loved to be involved had I had more spare time and my ever increasing work load.
    :-) Well if you know someone that might be interested... give me or him a shout or tell me where to crosspost it. I also need advice on how to reach the interested people.
  • edited November 2010
    You might want to see how the Tube is implemented on the BBC Micro, this sounds like a similar concept. (In fact, the BBC Micro was designed as the 'I/O processor' for a larger system. Most BBCs sold were just the 'I/O processor', but you could get second CPUs, for example a second 6502 and later an ARM or a Z80).
  • edited November 2010
    Winston wrote: »
    You might want to see how the Tube is implemented on the BBC Micro, this sounds like a similar concept. (In fact, the BBC Micro was designed as the 'I/O processor' for a larger system. Most BBCs sold were just the 'I/O processor', but you could get second CPUs, for example a second 6502 and later an ARM or a Z80).

    That's quite interesting. Has linux ever been ported to this ARM coprocessor? Then I suppose libasmp (that's "library for asymmetric multiprocessing" -- unless someone can think of a better name) can be used to dispatch jobs to the 6502, perhaps to write some hardware drivers that need to run on the 6502 for I/O access to the hardware.
  • edited November 2010
    wilsonsamm wrote: »
    That's quite interesting. Has linux ever been ported to this ARM coprocessor? .

    Doubt it, given it was an ARM2 and I don't think had an MMU and certainly not a great deal of memory. Programs on the second CPU would use the BBC Micro's OS calls to communicate with the "I/O processor" (the BBC Micro itself), the usual OSWORD/OSBYTE/etc. calls (in fact if you wrote your program "cleanly", i.e. going via the OS* calls rather than poking at hardware directly, it would run without modification on the Tube on a 6502 second processor).
  • edited November 2010
    There's a new ARM7 CoProcessor and there was a discussion about porting linux to it a bit ago. The A500 ARM Development System was used to develop ARX, a Unixy ARM OS for the Archimedes range, before Acorn ran out of time and launched with Arthur. Acorn then developed BSD UNIX on ARM as RiscIX, and there are GNU/Linux builds for modern ARM systems nowadays. PanOS on the 32016 CoPro was also sort-of-Unixy.

    I'm interested in helping out. I have C programming experience, have written a Z80 emulator in both ARM code and C, and have extensive Tube CoProcessor expertise, have written PDP11 and 6809 CoPro client code and reimplemented the Tube protocol using a single port link, such as used by a serial link.

    ---
    NOBODY expects the MACRO ARGUMENT INQUISITION! Our chief weapon is unexpected addressing modes... unexpected addressing modes and local branches out of range. Our two weapons are unexpected addressing modes and local branches out of range and quoted argument lists. Our three weapons are unexpected addressing modes, local branches out of range, quoted argument lists, and an almost fanatical devotion to the pope. Amongst our weapons are such elements as unexpected addressing modes, local branches out of range... I'll come in again.
  • edited November 2010
    jgharston wrote: »
    I'm interested in helping out.

    brilliant. do you want to trade email addresses so that we can correspond? And if you don't have it I'll send you my source code so far.
    jgharston wrote: »
    NOBODY expects the MACRO ARGUMENT INQUISITION! Our chief weapon is unexpected addressing modes... unexpected addressing modes and local branches out of range. Our two weapons are unexpected addressing modes and local branches out of range and quoted argument lists. Our three weapons are unexpected addressing modes, local branches out of range, quoted argument lists, and an almost fanatical devotion to the pope. Amongst our weapons are such elements as unexpected addressing modes, local branches out of range... I'll come in again.
    Haha! love it!
  • edited November 2010
    jgharston wrote: »
    There's a new ARM7 CoProcessor and there was a discussion about porting linux to it a bit ago. The A500 ARM Development System was used to develop ARX, a Unixy ARM OS for the Archimedes range, before Acorn ran out of time and launched with Arthur. Acorn then developed BSD UNIX on ARM as RiscIX, and there are GNU/Linux builds for modern ARM systems nowadays. PanOS on the 32016 CoPro was also sort-of-Unixy.

    Does anyone have such a system? After porting libasmp* to it, maybe work can start on providing so called "engines" for these slave CPUs. (engine is what i'm calling the objects that are loaded at runtime by libasmp that either drive a physical CPU or emulate one.)

    * libasmp, that's "library for asymmetric multiprocessing". Unless anyone can come up with a better name.
  • edited November 2010
    wilsonsamm wrote: »
    Does anyone have such a system?
    I have an ARM7 CoPro, and it's also available emulated in BeebEm. BTW, I've also written 6502 and PDP11 CoProcessor emulators, and am working steadily through porting BBC BASIC to the PDP-11 ;)

    My email address is in the image at mdfs.net/jgh.
Sign In or Register to comment.