[N8VEM: 20208] Fuzix on N8VEM SBC V2?

[Ken Worster]

Hi all,

I've ordered up the boards for the N8VEM SBC V2, Prop I/O V2, and the ECB
backplane. While waiting for the parts for assembly to arrive, I've been
looking at the various options for software to run. I saw the discussion
on Fuzix on this list and looked at its Git repo. It appears there is work
going on to support the Mark IV board, but nothing for the N8VEM SBC V2.
Someone mentioned that Fuzix should be able to run on this board in an
earlier conversation on this list and I'm wondering if that's accurate.
Looks like timers and interrupt control might have to be added to the
system. Any thoughts on this would be greatly appreciated. Thanks.

[Alan Cox]

Post by Ken Worster
Hi all,
I've ordered up the boards for the N8VEM SBC V2, Prop I/O V2, and the ECB
backplane. While waiting for the parts for assembly to arrive, I've been
looking at the various options for software to run. I saw the discussion on
Fuzix on this list and looked at its Git repo. It appears there is work
going on to support the Mark IV board, but nothing for the N8VEM SBC V2.
Someone mentioned that Fuzix should be able to run on this board in an
earlier conversation on this list and I'm wondering if that's accurate.
Looks like timers and interrupt control might have to be added to the
system. Any thoughts on this would be greatly appreciated. Thanks.

The only interrupt you *need* is for the timer. The serial interrupt
and RTC are nice if you have devices that need long periods with
interrupts off (eg DMAless floppies).

It's a pity the PropIO can't supply an IRQ to the N8VEM v2 or Zeta
Mark 1 easily, as it's ideally suited to the job, perhaps with an
extra wire.

An N8VEM mark 2 port would be a somewhat different port to the Mark 4,
but very similar in design to the other 32K/32K split platforms - eg
the TRS80, Dragon NX32 etc. The original Bourne shell just about runs
in 32K on Z80 and 6809.

For both the Zeta Mark 1 and N8VEM v2 I think you can also pull
another trick, if using the PropIO and not using the UART port as
well. That is to stick the 16550A at a low baud rate and set TX empty
interrupts on and big FIFO watermarks. Now at boot and every serial
interrupt you fill the FIFO with anything, and the UART will happily
clock it out into oblivion before interrupting you again a nice
reliable number of bit times later 8). Fuzix will sample the seconds
on the RTC chip regularly if told to do so and use that to keep the
time for sliding too far off. (We don't use the RTC directly as most
are slow, 0.1 second accurate at best and often not Y2K safe on old
8bitters)

You could probably use the uart port with most devices and output a
mix of nuls and data but that would get pretty foul.

[Max Scane]

I haven't played with Fuzix for a while. What's the current state?

Do you have a native C compiler as yet?

Are you able to build apps locally now?

Cheers!

Max

Post by Ken Worster

Post by Ken Worster
Hi all,
I've ordered up the boards for the N8VEM SBC V2, Prop I/O V2, and the ECB
backplane. While waiting for the parts for assembly to arrive, I've been
looking at the various options for software to run. I saw the

discussion on

Post by Ken Worster
Fuzix on this list and looked at its Git repo. It appears there is work
going on to support the Mark IV board, but nothing for the N8VEM SBC V2.
Someone mentioned that Fuzix should be able to run on this board in an
earlier conversation on this list and I'm wondering if that's accurate.
Looks like timers and interrupt control might have to be added to the
system. Any thoughts on this would be greatly appreciated. Thanks.

The only interrupt you *need* is for the timer. The serial interrupt
and RTC are nice if you have devices that need long periods with
interrupts off (eg DMAless floppies).
It's a pity the PropIO can't supply an IRQ to the N8VEM v2 or Zeta
Mark 1 easily, as it's ideally suited to the job, perhaps with an
extra wire.
An N8VEM mark 2 port would be a somewhat different port to the Mark 4,
but very similar in design to the other 32K/32K split platforms - eg
the TRS80, Dragon NX32 etc. The original Bourne shell just about runs
in 32K on Z80 and 6809.
For both the Zeta Mark 1 and N8VEM v2 I think you can also pull
another trick, if using the PropIO and not using the UART port as
well. That is to stick the 16550A at a low baud rate and set TX empty
interrupts on and big FIFO watermarks. Now at boot and every serial
interrupt you fill the FIFO with anything, and the UART will happily
clock it out into oblivion before interrupting you again a nice
reliable number of bit times later 8). Fuzix will sample the seconds
on the RTC chip regularly if told to do so and use that to keep the
time for sliding too far off. (We don't use the RTC directly as most
are slow, 0.1 second accurate at best and often not Y2K safe on old
8bitters)
You could probably use the uart port with most devices and output a
mix of nuls and data but that would get pretty foul.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/d/optout.

[Alan Cox]

Post by Max Scane
I haven't played with Fuzix for a while. What's the current state?

Z80 is now feeling pretty stable, 6809 likewise. 6502 is on hold for the moment.

A reasonable amount of the main utilities are there, including the
genuine Bourne shell, which pretty much defines the Unix "interface".
Multiple consoles are supported on boxes with enough resources and
graphics mode switching is now working, with actual graphics drawing
stuff being debugged. Lots of performance work needs doing yet -
directory scanning needs looking at in depth and some disk layout
algorithms improving.

Mostly at the moment people seem to be concentrating on stability and
polishing up the 6809 ports, in part as it's by far the nicest 8bit
CPU to work with in terms of toolchain, emulation and instruction set.

Post by Max Scane
Do you have a native C compiler as yet?

No and it's a very low priority to me, certainly behind getting the
utilities in a better state, manual pages, and TCP/IP networking
support. For Z80 in particular I'm not sure how much sense it makes.
While people have squashed a CP/M ANSI C compiler into 60K TPA or so
in about 5 passes it's very hard to generate good Z80 code and I don't
know of any way to get close to what SDCC can do without cross
compiling. I actually have BASIC higher up the TODO list than C ...
6809 may be a bit more doable.

Post by Max Scane
Are you able to build apps locally now?

on 6809 I can build them in assembler but not C, and really that's
just been playing around to see what is needed and how it might work.
The first steps for anyone who wanted to do it would probably be to
get a suitably compact Z80 assembler built and port one of a choice of
small link tools. I guess small-C might then fit to begin with. For
6809 it might be possible to jump up and down on bcc a lot to get a
K&R compiler to fit.

Or there is Forth, which David Given seems to be doing and we will I
hope have an ECMA55 style BASIC in time.

Alan

[Ian May]

Hi Alan,
Would a system with 2 6809Es running out of phase, each with a private
address space and a shared address space, be of any value for Fuzix?
(Motorola application note AN-892 describes such a system). The simplest
solution would be to give one CPU I/O tasks and use the other as the "main"
CPU but you could also give each CPU its own MMU and share tasks between
them.

At the moment you seem to be adapting your code to work with existing
hardware. Would you consider making a "hardware wish list" of features that
would make your software task easier or code run faster? More sophisticated
MMUs and hardware interrupt vectoring on a 6809 come to mind. Developing an
"Alan Cox Fuzix Hardware Platform" may result in a much more capable system
than forcing software to "jump through hoops" with sub-optimal hardware.

Cheers, Ian.

Post by Alan Cox

Post by Max Scane
I haven't played with Fuzix for a while. What's the current state?

Z80 is now feeling pretty stable, 6809 likewise. 6502 is on hold for the moment.
A reasonable amount of the main utilities are there, including the
genuine Bourne shell, which pretty much defines the Unix "interface".
Multiple consoles are supported on boxes with enough resources and
graphics mode switching is now working, with actual graphics drawing
stuff being debugged. Lots of performance work needs doing yet -
directory scanning needs looking at in depth and some disk layout
algorithms improving.
Mostly at the moment people seem to be concentrating on stability and
polishing up the 6809 ports, in part as it's by far the nicest 8bit
CPU to work with in terms of toolchain, emulation and instruction set.

Post by Max Scane
Do you have a native C compiler as yet?

No and it's a very low priority to me, certainly behind getting the
utilities in a better state, manual pages, and TCP/IP networking
support. For Z80 in particular I'm not sure how much sense it makes.
While people have squashed a CP/M ANSI C compiler into 60K TPA or so
in about 5 passes it's very hard to generate good Z80 code and I don't
know of any way to get close to what SDCC can do without cross
compiling. I actually have BASIC higher up the TODO list than C ...
6809 may be a bit more doable.

Post by Max Scane
Are you able to build apps locally now?

on 6809 I can build them in assembler but not C, and really that's
just been playing around to see what is needed and how it might work.
The first steps for anyone who wanted to do it would probably be to
get a suitably compact Z80 assembler built and port one of a choice of
small link tools. I guess small-C might then fit to begin with. For
6809 it might be possible to jump up and down on bcc a lot to get a
K&R compiler to fit.
Or there is Forth, which David Given seems to be doing and we will I
hope have an ECMA55 style BASIC in time.
Alan
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/d/optout.

[Alan Cox]

Post by Ian May
Hi Alan,
Would a system with 2 6809Es running out of phase, each with a private
address space and a shared address space, be of any value for Fuzix?
(Motorola application note AN-892 describes such a system). The simplest
solution would be to give one CPU I/O tasks and use the other as the "main"
CPU but you could also give each CPU its own MMU and share tasks between
them.
At the moment you seem to be adapting your code to work with existing
hardware. Would you consider making a "hardware wish list" of features that
would make your software task easier or code run faster? More sophisticated
MMUs and hardware interrupt vectoring on a 6809 come to mind. Developing an
"Alan Cox Fuzix Hardware Platform" may result in a much more capable system
than forcing software to "jump through hoops" with sub-optimal hardware.

Jumping through hoops is half the fun.

There really is very little it needs other than a timer interrupt, a
reasonable I/O device and some banked memory. Most interrupts except
serial are surprisingly useless (and the same seems to be true up to
PC/AT class machines with real Unix). Even serial interrupts for
transmit complete turn out to be a lose because at most baud rates the
IRQ enter/exit cost exceeds the cost of a 1MHz CPU sitting on its butt
polling the 'tx ready' flags for the next byte.

The Zeta V2 (if you add IDE) is pretty close to ideal except it has no
graphics. For 6809 at the moment the closest to perfection is probably
the Tandy COCO3 with an IDE controller.

Using multiple CPUs would I think be hard. FUZIX single threads a lot
of the kernel, in particular the disk I/O, as did the UZI codebase it
comes from. For a small single CPU machine that turns out to be a
brilliant trade off because it simplifies the code immensely without
any real hit as these are machines which generally can't do DMA disk
I/O and even if they can the DMA controller simply boots the CPU off
the bus for the transfer anyway. The tiny penalty you pay for the I/O
single threading is paid back in vastly simpler, smaller and thus
otherwise faster I/O because all the nasty races go away.

Alan

[J. Alexander Jacocks]

Sergey,

I think that is a good suggestion for you: add basic graphics to the Zeta!
I really love the small form factor, and the all-in-one nature of the board.

- Alex

Post by Ian May

Post by Ian May
Hi Alan,
Would a system with 2 6809Es running out of phase, each with a private
address space and a shared address space, be of any value for Fuzix?
(Motorola application note AN-892 describes such a system). The simplest
solution would be to give one CPU I/O tasks and use the other as the

"main"

Post by Ian May
CPU but you could also give each CPU its own MMU and share tasks between
them.
At the moment you seem to be adapting your code to work with existing
hardware. Would you consider making a "hardware wish list" of features

that

Post by Ian May
would make your software task easier or code run faster? More

sophisticated

Post by Ian May
MMUs and hardware interrupt vectoring on a 6809 come to mind. Developing

an

Post by Ian May
"Alan Cox Fuzix Hardware Platform" may result in a much more capable

system

Post by Ian May
than forcing software to "jump through hoops" with sub-optimal hardware.

Jumping through hoops is half the fun.
There really is very little it needs other than a timer interrupt, a
reasonable I/O device and some banked memory. Most interrupts except
serial are surprisingly useless (and the same seems to be true up to
PC/AT class machines with real Unix). Even serial interrupts for
transmit complete turn out to be a lose because at most baud rates the
IRQ enter/exit cost exceeds the cost of a 1MHz CPU sitting on its butt
polling the 'tx ready' flags for the next byte.
The Zeta V2 (if you add IDE) is pretty close to ideal except it has no
graphics. For 6809 at the moment the closest to perfection is probably
the Tandy COCO3 with an IDE controller.
Using multiple CPUs would I think be hard. FUZIX single threads a lot
of the kernel, in particular the disk I/O, as did the UZI codebase it
comes from. For a small single CPU machine that turns out to be a
brilliant trade off because it simplifies the code immensely without
any real hit as these are machines which generally can't do DMA disk
I/O and even if they can the DMA controller simply boots the CPU off
the bus for the transfer anyway. The tiny penalty you pay for the I/O
single threading is paid back in vastly simpler, smaller and thus
otherwise faster I/O because all the nasty races go away.
Alan
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/d/optout.

[Ian May]

Thanks Alan, I'll shelve the quad 2MHz 6809 design until later :) What
level of graphics are you suggesting? Simple black and white, greyscale or
some level of colour, i.e. how much graphics memory and what resolution?
Cheers, Ian.

Post by Ian May

Post by Ian May
Hi Alan,
Would a system with 2 6809Es running out of phase, each with a private
address space and a shared address space, be of any value for Fuzix?
(Motorola application note AN-892 describes such a system). The simplest
solution would be to give one CPU I/O tasks and use the other as the

"main"

Post by Ian May
CPU but you could also give each CPU its own MMU and share tasks between
them.
At the moment you seem to be adapting your code to work with existing
hardware. Would you consider making a "hardware wish list" of features

that

Post by Ian May
would make your software task easier or code run faster? More

sophisticated

Post by Ian May
MMUs and hardware interrupt vectoring on a 6809 come to mind. Developing

an

Post by Ian May
"Alan Cox Fuzix Hardware Platform" may result in a much more capable

system

Post by Ian May
than forcing software to "jump through hoops" with sub-optimal hardware.

Jumping through hoops is half the fun.
There really is very little it needs other than a timer interrupt, a
reasonable I/O device and some banked memory. Most interrupts except
serial are surprisingly useless (and the same seems to be true up to
PC/AT class machines with real Unix). Even serial interrupts for
transmit complete turn out to be a lose because at most baud rates the
IRQ enter/exit cost exceeds the cost of a 1MHz CPU sitting on its butt
polling the 'tx ready' flags for the next byte.
The Zeta V2 (if you add IDE) is pretty close to ideal except it has no
graphics. For 6809 at the moment the closest to perfection is probably
the Tandy COCO3 with an IDE controller.
Using multiple CPUs would I think be hard. FUZIX single threads a lot
of the kernel, in particular the disk I/O, as did the UZI codebase it
comes from. For a small single CPU machine that turns out to be a
brilliant trade off because it simplifies the code immensely without
any real hit as these are machines which generally can't do DMA disk
I/O and even if they can the DMA controller simply boots the CPU off
the bus for the transfer anyway. The tiny penalty you pay for the I/O
single threading is paid back in vastly simpler, smaller and thus
otherwise faster I/O because all the nasty races go away.
Alan
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/d/optout.

[Alan Cox]

I'm trying to make the kernel graphics code fairly dumb to such stuff.
The graphics ops the kernel implements are just mode changes,
querying, copy to/from video memory (I need to add swap having read
the Blit terminal paper), and a game style run length encoded graphics
put ( basically takes each source byte and ands it with a byte then
xors with the next, so its tiny code and can do most graphic ops).

I do need to add a bitblt but doing that well and compactly is not fun
on 8bit processors. Volunteers welcome 8)

Right now the graphics code is mostly getting it first testing on the
6809 boxes (dragon-nx-32 - classic 6847/SAM and coco3).

Alan

[Ken Worster]

Post by Ken Worster

Post by Ken Worster
Hi all,
I've ordered up the boards for the N8VEM SBC V2, Prop I/O V2, and the

ECB

Post by Ken Worster
backplane. While waiting for the parts for assembly to arrive, I've

been

Post by Ken Worster
looking at the various options for software to run. I saw the

discussion on

Post by Ken Worster
Fuzix on this list and looked at its Git repo. It appears there is work
going on to support the Mark IV board, but nothing for the N8VEM SBC V2.
Someone mentioned that Fuzix should be able to run on this board in an
earlier conversation on this list and I'm wondering if that's accurate.
Looks like timers and interrupt control might have to be added to the
system. Any thoughts on this would be greatly appreciated. Thanks.

The only interrupt you *need* is for the timer. The serial interrupt
and RTC are nice if you have devices that need long periods with
interrupts off (eg DMAless floppies).
It's a pity the PropIO can't supply an IRQ to the N8VEM v2 or Zeta
Mark 1 easily, as it's ideally suited to the job, perhaps with an
extra wire.
An N8VEM mark 2 port would be a somewhat different port to the Mark 4,
but very similar in design to the other 32K/32K split platforms - eg
the TRS80, Dragon NX32 etc. The original Bourne shell just about runs
in 32K on Z80 and 6809.
For both the Zeta Mark 1 and N8VEM v2 I think you can also pull
another trick, if using the PropIO and not using the UART port as
well. That is to stick the 16550A at a low baud rate and set TX empty
interrupts on and big FIFO watermarks. Now at boot and every serial
interrupt you fill the FIFO with anything, and the UART will happily
clock it out into oblivion before interrupting you again a nice
reliable number of bit times later 8). Fuzix will sample the seconds
on the RTC chip regularly if told to do so and use that to keep the
time for sliding too far off. (We don't use the RTC directly as most
are slow, 0.1 second accurate at best and often not Y2K safe on old
8bitters)
You could probably use the uart port with most devices and output a
mix of nuls and data but that would get pretty foul.

Alan, thanks for the reply. The N8VEM SBC v2 also appears to have a
48k/16k banked mode available via a jumper setting. I don't know if that
would be better or worse for Fuzix. It doesn't look like a lot of the
popular roms (ROMWBW in particular) support it.

[Alan Cox]

Alan, thanks for the reply. The N8VEM SBC v2 also appears to have a 48k/16k
banked mode available via a jumper setting. I don't know if that would be
better or worse for Fuzix. It doesn't look like a lot of the popular roms
(ROMWBW in particular) support it.

The bigger the switched area the better (within reason). Having a 16K
window on banked space is really good for some single tasking
applications with a smart C compiler (or some really fun hacks to
SDCC) but not fun for multiple processes in my experience.

Alan