I'm writing a library for "running" co-processors
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.
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
damn, I'm not a Catholic.
:-) 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.
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.
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).
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.
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.
Haha! love it!
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.
My email address is in the image at mdfs.net/jgh.