Fuzix

links:

What's Fuzix?  Its a Unix clone for small 8 and 16 bit computers.  I've ported it to the CoCo3.

fuzix_img


Fuzix working the CoCoNIC Card

posted Sep 27, 2016, 10:42 AM by Brett Gordon

ok... In a few hours I was able to get hack working to demo Jim's new CoCoNIC card.
Here is a diagram showing the uIP incorporated into the fuzix system via Fuzix's "net-native" socket interface.  Noticed I side-stepped the kernel to go directly to Jim's card.  This is a quick hack, but definately must be revised, once I figure out how to make a proper network device driver for Fuzix.

And a youtube of it in action:

CoCoNIC in Action



A NIC card from Jim Brain

posted Sep 20, 2016, 2:17 PM by Brett Gordon

Yesterday I received a prototype NIC (network interface card) from Jim Brain, http://store.go4retro.com/, for my CoCo2 / 3.  After a long day of getting a cassette booter made for Fuzix, I finally got booted up and played with the card via Spiffy Forth, my favorite hardware dabbling enviroment.  In about 10 minutes, I got the card to return the product ID, and got the LinkLed to blink.


A Proglet: windows bmp viewer

posted Jul 3, 2016, 6:44 AM by Brett Gordon   [ updated Jul 3, 2016, 4:00 PM ]

I hacked a small program to use Fuzix's direct video transfer ioctls.  Having some previous experience with the window .bmp format, I decided to try for a simple bmp viewer.  Window bmp files are actually pretty flexible, allowing for 1,2,4,8,16,32 bits pixel encodings.  Current Fuzix's (Dragon, CoCo3 ports, as of this writing ) support only a basic 1 bpp (bit-per-pixel) screen, so the first logical step is to get the viewer to display a taylor-made 1 bpp bitmap I created via Gimp:


Not bad... but what if we want to view a bmp in a higher bbp?  So I added a simple transposer for a 8 bit color depth.  Basic process is a follows:  get a 8 bit pixel datum, use it as a index to 24 bit color value from the .bmp's color table.  Convert the 24 bit RGB to an intensity:  

 uint8_t intensity( struct bmp_palette *p ){
uint16_t c;
c = (p->red * 2);
c += (p->green * 5);
c += p->blue;
return c/8;
}

This formula is a "I have no fast divide" approximation of this formula (from wikipedia): Y = .3R + .6G + .1B.  If the resultant intensity is greater than 127 then plot the pixel as a 1, else plot it as a 0.  This is the results:


Yup... the down sampling worked - Let's add some super-simple dithering by taking the quantization error for each pixel and adding it to the next pixel processed in the line:

Yay!  Ken almost has a face again!  Not bad - this method is still fairly fast, but produces simple dithering's characteristic pin-striping. For the cost of some addition math and a couple error buffers we can add some Floyd-Steinberg Dithering:
 

Now this is coming close to The Gimp's dithering as seen in the first screenshot.  It looks like gimp is narrowing the contrast somewhat.  It takes 45 seconds to render this bitmap on a CoCo3 running at 1.79 Mhz !  

Oh... why is it in Blue ?  We don't have the paletting kernel interface designed yet! :)

And for comparison: here is the source file, a 8bpp image:

 

Support for 2 and 4 bpp shouldn't be too hard or different than above.  Support for 24 bit images is probably silly, as these formats take nearly an entire floppy disk to store, and would be sort of impractical to bother with.

-- several hours later --

Whoops:  Inexact file format specs lead me to miss interpret the color/palette format.  Now here's our 8 bpp image again using the correct colors. Notice the ceiling highlights are starting to pop out.  Contrast is still pretty heavy:



OK... I have refactored the code, and these are the supported formats:

-- paletted modes --
1 bpp  (fast)
2 bpp  (hardly ever found in wild)
4 bpp  
8 bpp
-- RGB modes --
16 bpp
24 bpp
32 bpp**
no compression is supported.

I also added a "-d" command line option for turning *off* the dithering.

** seems to work, but the 192k large file I'm using to test this format is broken.  I'm assuming our host to target file system maker (ucp) is writing bad large files, because previous tests with large, native (>1M) tar files did work.  A "od -hx" reveals the file content's past the 137th line are all zeros.

Another "release"

posted Jun 12, 2016, 9:21 AM by Brett Gordon

I have posted new root and boot disks for the latest coco3 fuzix.  

* Up to 2M of RAM is usable now. (Me)
* More bug fixes for the DriveWire4 subsystem
* Man pager (*with* a real-life man page!)  (Neal)
* A few tty bugs have been fixed ("vi" works better)  (Me and Tormod)
* Disk drivers now can write directly to user-space offering much faster program load times. (Me)
* Drivewire Drives 0-255 supported now. (Tormod)

Updated image for CoCoFest 2016

posted Apr 22, 2016, 7:11 AM by Brett Gordon

* Alan's newly ported Scott Adam's text adventures ( 26 in total ) are built.
* "Colossal Caves", aka "advent" is playable
* dwterm and dwgetty.  telnet to port 4242 to remote login.
* A fuzix friendly version of bfc (Brett's Forth Compiler), and a simple resultant Forth is in /root
* Fortunes
* more V7 cmds have been compiled (not at all tested)

My Forth for Fuzix: I couldn't help myself.

posted Apr 15, 2016, 7:49 AM by Brett Gordon   [ updated Apr 15, 2016, 7:50 AM ]

ok. I couldn't help myself.  I know David has a near hayes/ANS compliant forth for fuzix, but I went ahead and rolled my own anyway.  I simplified my forth cross compiler (written in C) so it would work in fuzix.  The compiler spits out assembler for as09 to compile.  The source file for the compiler was fully written using "levee".  I have the ability to make immediate words, so technically the cross compiler's job is done, and the rest can be programmed in the target forth itself :)   This should make it handy to really test out Kernel calls interactively.

Cross Compiler: 14k bytes
Cross Compiler source: 4k bytes
Resultant Forth:  2.5k


New Disk Images Posted. Lamp Gotten.

posted Mar 17, 2016, 7:49 PM by Brett Gordon

New images are posted above. Here's a look at what's in these new images:

'umount' works better.
'tar' exists now - seems to be mostly compatible with linux's tar.
key repeating on keyboard (yay!).
freed up more cache buffer space.
'kill' fixed.
'ls' supports extracting/displaying hard links.
Some old bugs have been addresses in init.
Alan ported a PC version of the classic of classic's "Colossal Cave". See "advent".

fuzix running "Colossal Cave"

The Glamorous 'tar'

posted Dec 17, 2015, 11:25 PM by Brett Gordon

'tar', the basic unix tape archiver, isn't quite as bedazzling as ANSI graphics, but it's been a fun 48 hour hack.  I didn't really see and simple implementations of tar around, so I rolled my own.  It has some rough edges, and some suspicious lack of options, but it does extraction, creation, and listing of archives.  Probably the funnest part was the recursion algo for grabbing directories.   This lil' guy is easy on file descriptors, so the cost of each directory level on the stack is somewhere in the 130 byte range... most of which is the filename buffer.   He should weigh in some where 'around 17k in code-size if I stay away from ctime() for directory listings.... which is smaller than our 'ls'.  I backup'ed up my entire root drive today: It was ~850k, and took about 2 minutes.  Interestingly, there wasn't much difference in speed if the cpu was set for 33 Mhz as compare to the regular 1.7 Mhz.   


There's a few more "features", like extracting specified files, I'd like to add, and maybe someday better creation support for hardlinks. This tar does seem to open and extract tars made by gnu's tar in Linux, but I'm uncertain whether tar-files produced by it are readable from other tar implementations.  Here is a tar-untar cylce:


Still Mudding

posted Dec 5, 2015, 3:02 PM by Brett Gordon

Today I added a proper line mode into dwterm.  Unfortunately, we can't use FUZIX's canonical tty mode, because this defeats backspace. Canon mode is fine if you don't mind blocking, but for a terminal proggie, blocking just doesn't work.  So I had to buffer input from the tty into a output buffer, translating BS and CR's... but it works.  Here's dwterm connected to nostalgiamud, ran and written by William Astle.  Line editing works nicely now. 


BBS/MUD'ing with Fuzix

posted Nov 27, 2015, 9:04 AM by Brett Gordon

I have fixed a few bugs with the drivewire serial drivers for fuzix, and incorporated a vt100 to vt52 translater into a fuzix program called "dwterm".  Now I can BBS and MUD via fuzix!

I think my unix-foo levels have gone up with this project:

* termios (which flag turned off nl->nlcr translation again?!?!!??)
* NDELAY opens ( there's no select() in fuzix, yet)
* ANSI escape sequences / vt52 sequences

The VT100/ANSI part was easy programming, basically its RPN VT52... so parameters are prefix no postfix (forth vs. lisp), other than that the state machine needed for vt100 is no more complicated than Fuzix's vt52 code.



screen shot of vert.synchro.net

And here's the same BBS as seen via a regular linux terminal via 'telnet':
same bbs, but a linux term...




1-10 of 16