Porting Fuzix to the 6502 CoPro?

discussion of beeb/electron applications, languages, utils and educational s/w
Post Reply
User avatar
BigEd
Posts: 2101
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Porting Fuzix to the 6502 CoPro?

Post by BigEd » Sun Nov 13, 2016 10:35 pm

Elsewhere, Dave and I have been playing with a version of the Matchbox CoPro which has 1MByte of RAM available (using a simple banking system.) I wondered aloud if this might be a good platform for Alan Cox's new small OS, Fuzix. And it seems possible that it might be - he's previously made a 6502 port of Fuzix targeting the TGL6502, which is a wonderful ARM-based embedded emulation system.

So, Alan let us know of his Virtual65 simple emulator project, and asked a couple of questions:
Q1: what's the actual clock and wait states for main memory and for external memory on the matchbox with these changes ?
Q2: does someone who speaks BBC tube innards have a bit of time to knock up the lowest level bits needed for talking to the tube, character I/O, disk I/O and timers remembering that we are bank switching so the NMI using parts might be a little exciting

User avatar
hoglet
Posts: 7523
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by hoglet » Sun Nov 13, 2016 10:43 pm

EtchedPixels wrote: Q1: what's the actual clock and wait states for main memory and for external memory on the matchbox with these changes ?
When external RAM is accessed, 4 wait states are added, which is possibly a bit conservative.
EtchedPixels wrote: Q2: does someone who speaks BBC tube innards have a bit of time to knock up the lowest level bits needed for talking to the tube, character I/O, disk I/O and timers remembering that we are bank switching so the NMI using parts might be a little exciting
I wonder whether we can try to re-use the existing Beeb MOS interface that lives at F800-FFFF.

Disk I/O could then be implemented via OSWORD &7F:
http://mdfs.net/Docs/Comp/BBC/Osword/Osword7F
This is how other OS's on the Co Pro (like CP/M) work.

In terms of timers, the OSBYTE 14, 4 enable the 50Hz VSYNC event, which can be intercepted on the Co Pro side with the Event Vector (&220).

Dave

EtchedPixels
Posts: 23
Joined: Mon Feb 23, 2015 11:39 pm
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by EtchedPixels » Sun Nov 13, 2016 11:50 pm

Ok I've updated the emulator to match 64MHz, 4 wait states on higher RAM banks and 50Hz clock.

You probably need a cache 8)

I did look a little at the existing interface (in fact I even left the top 8K bank free) however it doesn't look like it's going to take kindly to disappearing into the OS timer interrupt and not coming back out. That's a problem because we task switch so we need to enter the timer interrupt in one bank and return to a different context in another bank.

For disk I/O the closer to the standard it can use the better as OSWORD 7F and OSWORD 72 seem to cover most things, and Fuzix speaks SASI/SCSI (although not yet 256 bye sector sizes). The downside appears to be that we then can't access the IDE disk and get all 512 bytes/sector (and thus interoperate properly).

Some of the other stuff also makes sense - so it's probably worth having some kind of special driver for doing oscli, osbyte, osword as root in order to poke at BBCish bits from within the OS (Possibly the first time anyone will need to add special handling for *cmd to the Bourne shell !)

Alan

User avatar
tricky
Posts: 2784
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by tricky » Mon Nov 14, 2016 10:33 am

I'm not saying I would do anything with it, but talking of bank switched 6502s, have you looked at the Nintendo 2a03? I think it also has basic DMA, but I could be confusing it with something else ;)

EtchedPixels
Posts: 23
Joined: Mon Feb 23, 2015 11:39 pm
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by EtchedPixels » Mon Nov 14, 2016 11:30 am

2A03/2A07 doesn't have banking. The NES/Famicon does but that's through mappers in the cartridges.

There were a few banking solutions for the BBC- the Master and + effectively have some bank switching for the shadow screem amd related areas, plus all the BBCs have the sideways space. I've also got a Watford card sitting somewhere that adds second banks to the BBC over the low 32K which I think predates the Acorn shadow stuff. The Applie II also got this right (Two banks on the Apple card, lots on the Ramworks). Most of the other machines are less useful (E.g. Atari 8bit) because they have a single small window that can be used to access all the rest of memory. That's ideal for a large single tasking game, pants for a multi-tasking OS.

You could in theory get Fuzix to run on a BBC master at least, maybe even on a BBC micro just about, but it would need someone to add bank switching support and automatic bank switch code generation to the cc65 linker and you'd certainly need IDE or some kind of external RAMdisc fo swap. I've not tried any of these but have done the maths to see what fits.

The basic ingredients you need are
- two reasonable sized banks of RAM for the 6502 (or fix the linker)
- a fast I/O device (or as with the matchbox - lots of RAM to hide the relatively poor I/O)

The 65C816 doesn't help much either because while banked the stack has to be in bank 0 which means you can't just work with 16bit pointers but have to do everything 24bit, at which point it's horrible.

The 6509 was nice, but the odds of actually finding a 6509 part to play with and breadboard are about nil, although the extra logic on the 6509 can be faked with a 6502 and a little bit of glue logic or a CPLD. It's got a pair of 4bit bank registers ZP:0 and ZP:1 plus some logic that spots an instruction fetch for B1 or 91. the first bank register is used in all cases except when you do the STA/LDA indirect Y, in which case the final operation occurs via bank 1. Thus you've got far read/write and bank switching. It's rather elegant in the usual 6502 "less is more" fashion and all without touching the actual 6502 die design proper.

Alan
Last edited by EtchedPixels on Mon Nov 14, 2016 11:43 am, edited 1 time in total.

User avatar
BigEd
Posts: 2101
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by BigEd » Mon Nov 14, 2016 11:41 am

I like the idea of using the new Matchbox and (maybe in the future) the PiTubeDirect copros, because they are affordable and available and high performance, but they feel authentically Beeb-like. There are all sorts of projects which one might build, but these two actually have a user base!

We've seen with PiTubeDirect that we can increase performance more than we expected by the appliance of great ingenuity - and then, everyone gets to benefit. I'm sure the same is true with the Matchbox - a faster system could be made on the current platform, and if it were, everyone could upgrade. But at present, we have something up to 64MHz which might run at say 12MHz in practice when a large memory model is in play - still three or four times faster than the original copro offerings and nearly as fast as current custom silicon.

User avatar
BigEd
Posts: 2101
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by BigEd » Mon Nov 14, 2016 12:23 pm

I ran some quick benchmarking of the matchbox with the 64MHz matchbox copro, on a Beeb with Basic2:
  • With only fast RAM in play, clocksp reports 65.33MHz
  • Moving Basic from fast RAM to slow RAM: 17.48MHz
  • Also moving &2000 to &8000 to slow RAM: 17.37MHz
  • Also moving PAGE up to &2000: 17.10MHz
  • Moving everything from &0000 up to &E000 to slow RAM: 13.09MHz
  • Moving only the &0000 to &2000 area: 29.58MHz
  • Moving only the &0000 to &2000 area and setting PAGE to &2000: 30.57MHz
So, with slow RAM in play everywhere, we get 13MHz, more or less as expected. If we can keep page zero and the stack in fast RAM, we're up to 17MHz, which is substantially faster. If by magic or the application of effort we could run our code from single-cycle on-chip cache, but only the code, we might get 30MHz.

User avatar
jgharston
Posts: 3217
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by jgharston » Mon Nov 14, 2016 4:10 pm

hoglet wrote:
EtchedPixels wrote: Q2: does someone who speaks BBC tube innards have a bit of time to knock up the lowest level bits needed for talking to the tube, character I/O, disk I/O and timers remembering that we are bank switching so the NMI using parts might be a little exciting
I wonder whether we can try to re-use the existing Beeb MOS interface that lives at F800-FFFF.
Yes, why re-invent a pre-exiting and long-term tested wheel? All nonBBC-style OSs on second processors talk to the host hardware by just issuing BBC MOS API calls to the Tube Client.

With the paging system, as long as bank 7 is always paged in to the page that holds the Tube Client MOS it should work. I say "should" as the environment state is in zero page in bank 0. As long as the correct state is present in zero page (let's call it &E0-&FF for a bit of flexibility) it should work. So, it just needs the task switching that swaps banks to copy correct info across to the newly-paged-in bank 0. That's the same problem I had with working out a Z80 paging system.

The mentioned paging system uses 8K pages, so that would be all of &E000-&FFFF remaining paged to the MOS bank, a la pdp11 Unix. The Tube Client MOS is only 2K, &F800-&FFFF. So you could also have other premanantly-resident code in &E000-&F7FF to implement the Fuzix system.

As for the file system, you could just translate Fuzix pathnames to native pathnames and use whatever filing systems happen to be available on the host, eg fopen("/fred/jim/sheila.ext") is translated to OPENIN("$.fred.jim.sheila/ext") just like various emulators that access the host system (eg the Unix module in !PDPTube).

I started writing Unix for the PDP-11 Tube that did just this. I thought I'd lost it, but it's here, I never got around to listing it on an index page.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

EtchedPixels
Posts: 23
Joined: Mon Feb 23, 2015 11:39 pm
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by EtchedPixels » Mon Nov 14, 2016 5:25 pm

jgharston wrote:
hoglet wrote:
EtchedPixels wrote: I wonder whether we can try to re-use the existing Beeb MOS interface that lives at F800-FFFF.
As far as possible certainly. It's not too large and it does most of the job. Even if it's not sufficient due to the task switching issues it's still going to be something very close to that code. I imagine it can also be sped up quite a bit here and there with host side mods by trimming delays given it's a 64MHz parasite. I'm talking about wrapping the existing code or tweaking it a bit not much more except for downloading some IDE 512 byte/sector support with as fast a transfer as possible and writing the driver code to sit on it for block I/O, character I/O and timers.
With the paging system, as long as bank 7 is always paged in to the page that holds the Tube Client MOS it should work. I say "should" as the environment state is in zero page in bank 0. As long as the correct state is present in zero page (let's call it &E0-&FF for a bit of flexibility) it should work. So, it just needs the task switching that swaps banks to copy correct info across to the newly-paged-in bank 0. That's the same problem I had with working out a Z80 paging system.
The mentioned paging system uses 8K pages, so that would be all of &E000-&FFFF remaining paged to the MOS bank, a la pdp11 Unix. The Tube Client MOS is only 2K, &F800-&FFFF. So you could also have other premanantly-resident code in &E000-&F7FF to implement the Fuzix system.
I don't think you even need to pin that part of the address space. it's probably simpler if there's enough other fixed code to avoid wasting space.
As for the file system, you could just translate Fuzix pathnames to native pathnames and use whatever filing systems happen to be available on the host, eg fopen("/fred/jim/sheila.ext") is translated to OPENIN("$.fred.jim.sheila/ext") just like various emulators that access the host system (eg the Unix module in !PDPTube).
I think that is a fundamental misunderstanding. Fuzix is a Unix clone OS, it's not a partial glue layer pretending to implement some subset of Unix file system semantics. It implements a file system of its own with full Unix properties and which is portable. There's something to be said for tools for accessing other file systems but what it primarily wants is to reuse all the existing block level I/O interfaces to TurboMMC, floppies, IDE, etc.

Alan

User avatar
flynnjs
Posts: 801
Joined: Tue Jul 06, 2010 9:33 pm
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by flynnjs » Mon Nov 14, 2016 6:33 pm

EtchedPixels wrote: There's something to be said for tools for accessing other file systems but what it primarily wants is
to reuse all the existing block level I/O interfaces to TurboMMC, floppies, IDE, etc.
Alan
As Dave says OSWORD &7f and other OSWORD friends. Whether you choose to use the standard Tube code
or nuke that and write your own which matches the protocol. Ultimately you could even replace the host
handler too but other Tube OSs didn't do this.

I suspect there could be benefits to rewriting on the parasite side. The original Tube hardware resets into
code which copies itself into RAM and then makes the RAM Read Only. We could tweak that in the Matchbox
so the IRQV could be overwritten by Fuzix to allow a better handler once booted over the Tube.

EtchedPixels
Posts: 23
Joined: Mon Feb 23, 2015 11:39 pm
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by EtchedPixels » Mon Nov 14, 2016 9:27 pm

Some questions

1. Are you currently enforcing the F800-FFFF read only from the original copro, and if so is that an address based enforcement or can I just remap the bank lower and patch it 8)

2. From the docs I've seen and the code am I right in assuming NMI based transfers are always part of a parasite initiated activity. That is we call oswhatever then any NMI will begin after the call and end before the os call returns ? That's important from a banking perspective.

3. The host to parasite interrupt (not NMI) doesn't have a timing constraint ?

(1 means I can patch the code to make the irq handling cleaner, although if not I think making IRQ1V push a fake RTI frame and then jump to the old handler is sufficient to pick it up.)

2. Is pretty much essential given the NMI timing constraints

3. means I've got time to bank switch the MOS code holding E000-FFFF page to 0-1FFF as well so that there's a private IRQ stack and ZP for the MOS interface to use and all the zero page variables are free without expensive copying. $FC while needed in each bank is only used to save and on the return to the right bank restore A.


Other unrelated question: are the bank registers r/w or write only ?

Alan

User avatar
BigEd
Posts: 2101
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by BigEd » Mon Nov 14, 2016 10:38 pm

I can tell you the bank registers are write only, at present. That's the sort of thing we could change if it were a useful improvement to do so.

If the whole top bank (bar the I/O) isn't writeable, we could easily make it so. But I don't immediately see anything in the VHDL which makes it write protected, once the ROM has been punted out. You just need to be careful to populate the replacement before mapping it in.

User avatar
jgharston
Posts: 3217
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by jgharston » Tue Nov 15, 2016 12:38 am

flynnjs wrote:As Dave says OSWORD &7F and other OSWORD friends.
And OSGBPB then you can access the block device as an image on your native filing system instead of having to trash whatever disk you are using. That's how all the non-BBC-OS-on-CoPros work, OSWORD &72/&7F for raw floppy access to foreign-OS floppies and OSGBPB for "hard drive" access to an image file containing the hard drive.
flynnjs wrote:I suspect there could be benefits to rewriting on the parasite side.
The 6502 client in particular is very tightly written and there would be little benefit in rewriting it. I've done a couple of bugfixes for v1.11, but that's at the high level not at the low level API-to-host level.
flynnjs wrote:The original Tube hardware resets into code which copies itself into RAM and then makes the RAM Read Only.
On what platform does it do that? On all the 8-bit platforms the ROM is copied into RAM then the whole memory map is made read/write.

A quick check seems to confirm that on the 80x86 and 320xx the ROM is fixed in the memory map and the client code is executed from ROM.
EtchedPixels wrote:1. Are you currently enforcing the F800-FFFF read only from the original copro, and if so is that an address based enforcement or can I just remap the bank lower and patch it 8)
&F800-&FFFF isn't read-only, if it was the system would fail; the hardware reset code modifies itself to make itself a warm entry to the supervisor, data transfers modify the NMI vector to point to the required NMI routines.
EtchedPixels wrote:2. From the docs I've seen and the code am I right in assuming NMI based transfers are always part of a parasite initiated activity.
No, all data transfers are initiated by the host. Mostly the host will initiate them in response to the client asking for something, for example during an OSFILE call, but a data transfer can happen at any time. You could have something on the host ticking away in the background and doing a data transfer whenever it wants.
EtchedPixels wrote:3. The host to parasite interrupt (not NMI) doesn't have a timing constraint ?
(1 means I can patch the code to make the irq handling cleaner, although if not I think making IRQ1V push a fake RTI frame and then jump to the old handler is sufficient to pick it up.)
In what way is the IRQ handler "dirty"? It's as minimal as it needs to be, very quick check for Tube interupts, then if not Tube dispatches as fast as possible to IRQ2V.
EtchedPixels wrote:3. means I've got time to bank switch the MOS code holding E000-FFFF page to 0-1FFF as well so that there's a private IRQ stack and ZP for the MOS interface to use and all the zero page variables are free without expensive copying. $FC while needed in each bank is only used to save and on the return to the right bank restore A.
Zero page locations &E0-&FF(*) are reserved for the Tube MOS, everything else is free, so only &E0-&FF is needed. &FD/E/F are readable by programs as the FAULT pointer and the ESCAPE flag.

(*)I've only seen Tube MOSes using &EC-&FF, but documentation says &E0-&FF, so stick to the documentation.

Edit: Plus, of course, page 2 is also owned by the MOS as that's the vectors and string and host error buffer.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 3217
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by jgharston » Tue Nov 15, 2016 1:04 am

I've been trying to look into Fuzix, is https://github.com/EtchedPixels/FUZIX the correct place? That was the first search match.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
flynnjs
Posts: 801
Joined: Tue Jul 06, 2010 9:33 pm
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by flynnjs » Tue Nov 15, 2016 5:59 am

> And OSGBPB then you can access the block device as an image on your native filing system instead of having to trash whatever disk you are using.
That's fine if you want your FS in an image but a PITA for moving media to other platforms.

> The 6502 client in particular is very tightly written and there would be little benefit in rewriting it.
It was well written for the timing on a 3/4MHz parasite CPU. There's a alot of other ways to slice the cake when you have 64MHz.

> On all the 8-bit platforms the ROM is copied into RAM then the whole memory map is made read/write.
Sorry, yes, ROM is paged out for reads, not RAM made readonly.

EtchedPixels
Posts: 23
Joined: Mon Feb 23, 2015 11:39 pm
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by EtchedPixels » Tue Nov 15, 2016 10:25 am

jgharston wrote:I've been trying to look into Fuzix, is https://github.com/EtchedPixels/FUZIX the correct place? That was the first search match.
Yes

EtchedPixels
Posts: 23
Joined: Mon Feb 23, 2015 11:39 pm
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by EtchedPixels » Tue Nov 15, 2016 10:38 am

EtchedPixels wrote:2. From the docs I've seen and the code am I right in assuming NMI based transfers are always part of a parasite initiated activity.
No, all data transfers are initiated by the host. Mostly the host will initiate them in response to the client asking for something, for example during an OSFILE call, but a data transfer can happen at any time. You could have something on the host ticking away in the background and doing a data transfer whenever it wants.
Ok but at a higher level looking at the calls they all do something and return. An OSWORD 7F or OSWORD 72 returns after the data has been copied. So the host should only need to initiate the NMI transfers as a result of the osword call and would complete the transfer before sending the message to complete the osword.
In what way is the IRQ handler "dirty"? It's as minimal as it needs to be, very quick check for Tube interupts, then if not Tube dispatches as fast as possible to IRQ2V.
It's not, but it doesn't do bank switching and if doesn't handle multi-tasking, so if for example we get an event from the host for a 50Hz timer we want to switch tasks and banks in the IRQ handler - in effect it disappears into one IRQ and comes out in another
context. That really requires wrapping the IRQ handler so that it runs the tube servicing, which causes events, the events may flag a pre-emption and when it does the RTI it actually returns to a wrapper which saves the old context, switches stacks and returns.
EtchedPixels wrote: (*)I've only seen Tube MOSes using &EC-&FF, but documentation says &E0-&FF, so stick to the documentation.
Will do - although if I can map the $E000 page to $0 as well while handling tube it can have its own stack and ZP.

Edit: Plus, of course, page 2 is also owned by the MOS as that's the vectors and string and host error buffer.
Yes I realize that, I can begrudge MOS 256 bytes 8-)

Alan

Code: Select all

EDITED by flynnjs to fix Quote borkage

User avatar
BigEd
Posts: 2101
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by BigEd » Tue Nov 15, 2016 10:49 am

EtchedPixels wrote:
jgharston wrote: (*)I've only seen Tube MOSes using &EC-&FF, but documentation says &E0-&FF, so stick to the documentation.
Will do - although if I can map the $E000 page to $0 as well while handling tube it can have its own stack and ZP.
Indeed, you can map the same page in two places at once.

User avatar
sweh
Posts: 1962
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by sweh » Tue Nov 15, 2016 3:18 pm

EtchedPixels wrote:The NES/Famicon does but that's through mappers in the cartridges.
Funnily enough, this came through my twitter feed yesterday: http://scarybeastsecurity.blogspot.com/ ... sktop.html

It talks about the NES paging works (4Kb chunks, mediated via 0x5ff8->0x5fff) and how a bug in gstreamer means we can write 6502 code to pwn a linux desktop. Cute!
Rgds
Stephen

User avatar
hoglet
Posts: 7523
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by hoglet » Tue Dec 13, 2016 2:46 pm

Hi Guys,

Not 6502 yet, but I've just built a version of Fuzix from the latest source tree for the CoCo3 target (FPGA version, on the Altera DE1 board).
IMG_0797.JPG
IMG_0791.JPG
IMG_0793.JPG
IMG_0796.JPG
The README here is actually very good:
https://github.com/EtchedPixels/FUZIX/t ... form-coco3

It's surprisingly snappy.

The disk images are mounted remotely over a 115,200 baud serial link, using a server (in Java) called DriveWire4:
https://sites.google.com/site/drivewire4/

There is a SD Card slot on the DE1 board, but it doesn't seem like the Fuzix drivers for this exist yet (not 100% sure about that).

Unix running on an 8-bit system is very cool!

Dave

User avatar
BigEd
Posts: 2101
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by BigEd » Fri Apr 28, 2017 4:55 pm

EtchedPixels wrote:The 6509 was nice, but the odds of actually finding a 6509 part to play with and breadboard are about nil, although the extra logic on the 6509 can be faked with a 6502 and a little bit of glue logic or a CPLD. It's got a pair of 4bit bank registers ZP:0 and ZP:1 plus some logic that spots an instruction fetch for B1 or 91. the first bank register is used in all cases except when you do the STA/LDA indirect Y, in which case the final operation occurs via bank 1. Thus you've got far read/write and bank switching. It's rather elegant in the usual 6502 "less is more" fashion and all without touching the actual 6502 die design proper.
hoglet wrote:... I've just built a version of Fuzix from the latest source tree for the CoCo3 target (FPGA version, on the Altera DE1 board)...
So, drifting just a little off topic here, we seem to have three routes to Fuzix on Acorn:
  • - on the 6502 CoPro with the 8x8k banking as presently available on Matchbox and on Pi coprocessors.
    - on a CoCo3 model, so perhaps on a (new) banked extension of the existing 6809 CoPro as found in Matchbox and Pi implementations.
    - on a 6509 model, which we don't presently have, but "how hard can it be" as I often hear people say, just before they start digging. Might be 50MHz on a PiTubeDirect, perhaps.
I'm supposing these are all about the same, in needing some kind of shim to offer Fuzix kernel services using the Tube's API back to the host.

Does a 6509 coprocessor seem appealing as a Fuzix target? It means locations &00 and &01 take on a special meaning, but otherwise would be 6502 compatible.

(At present, the Pi-based copro PiTubeDirect is more available and more actively developed than the Matchbox.)

EtchedPixels
Posts: 23
Joined: Mon Feb 23, 2015 11:39 pm
Contact:

Re: Porting Fuzix to the 6502 CoPro?

Post by EtchedPixels » Sun Jun 24, 2018 1:47 pm

The 6809 is by far the better processor for code compactness and programmability. Hopefully nobody here will burn my house down for saying that 8) but the native code density is something like 30% better than Z80 or 6502. It had other problems - Motorola never got it to go above about 2MHz and in fact went back to the simpler 6800 based cores for 68HC11 and their other stuff.

Architecturally I still think the biggest problem is the tube itself. You could I am sure hand tune raw disk I/O routines that used the tube for maximum performance but you really want the kernel running on the host, just as the filesystems for the BBC normally do so that you don't do a ton of gratuitous data transfers and burn all your precious tube bandwidth and host 6502 clocks moving bytes to the parasite for it to throw many of them away.

I just don't know enough BBC innards to do this. I'm not a BBC wizard and unlike most other 8bit micros the BBC has enough OS and actual software architecture you can't/don't want to just throw it all out.

If I had infinite time and beer I'd probably try and make the Fuzix kernel run on the host and re-arrange things so that system calls are tube messages and do no pre-emptive multitasking host side. On the parasite you have a thin kernel layer that just turns syscalls into mesages, deals with replies, does pre-emption and has a few other bits of glue for signals, process creation/destruction and maybe swapping.

That would also let you use a lot of the existing services as MOS intended.

However I don't have infinite time or beer so...

(and if you've got a PI you can just run Linux on your BBC and be done with it - like on the Apple II with the Apple Pi card.)

Alan
PS: The COCOFPGA SD card should be supported - but ask Brett about that not me
Last edited by EtchedPixels on Sun Jun 24, 2018 1:48 pm, edited 1 time in total.

Post Reply