Qbasicnews.com

I am a little hesitant posting this question here because while it is about FB, it is in an indirect way.

I am looking at a job in a very rural part of the US as a science teacher (I don't have it yet, just thinking about how to do some things IF I do get it). One of my major interests in science education is bringing computational techniques to a high school level. This is how I found FB in the first place! During my interview the principal and I talked a little bit about this idea. He said that while the school did have a couple of newer computer labs (looked like ~800mhz pents) that I could use… on a first come, first serve basis (Not idea for daily or spur of the moment work). However, the 'tech' guy had several old 386's that I could have for my classroom if I wanted. If the students were just going to program on (hamsters start to spin) ... This leads to the questions (sorry for being long winded today).

I know I can get a *nix distro to run on these, but is there anyway to get the gfxlib to run too? Ideally all I'd need/want for my students is primitive graphics, pset, line, circle, and maybe paint. I seriously doubt these machines will ever be able to run X.

How small of a machine has anyone tried to run FB on?

One thought was to have the machines become X terminals and beg, borrow, or donate a newer machine to run the server on and then let the old machines connect as thin clients... but my knowledge of all of this is extremely limited and comes from hacking around by myself (damn it Jim! I'm a physicist, not a computer scientist!). I might have a couple of weeks to get it hacked together but during that time I’d also be getting ready for school. It would be great if I could just throw a distro on the machines, slap FB on there… and go.

I know I could get DOS to run on these machines with a QB environment running but that would be pushing a legal limit (I have a copy of DOS 6 but not 10-20). And besides this way the students could have all of the tools they’d need to work with for free.

Perhaps I could even get a hold of a collection of donated machines for students that don’t have one. They wouldn’t play Doom3 or get online, but they could learn with them (I started on a C64, so I don’t want to hear any complaining from the students :-)).

Any ideas?

Yeah, it would be possible if the compiler and the runtime/gfx library are recompiled to run in 386's.

With the compiler it's matter of changing the "-arch 486" in the makefile to "-arch 386" so no 486-specific instructions are used (set# for example), but it would still generating code for 486+ CPU's, so the FB.DEFAULTCPUTYPE constant in fb.bi would have to be changed too.

The gfx lib will only use MMX if the CPU supports it, that's checked at run-time.

GCC would use 486-specific instructions when the optimizations level was set to -O3, now both libraries use -O2, i'm not sure about the code generated, the -O could be removed from the rt and gfx lib makefiles too.

Using any include file would be painful slow though, i wouldn't recommend doing that ;).

You could run FreeDOS ( http://www.freedos.org ) rather than MS-DOS. It's quite good from what I've found from using it on a 486.

The FB DOS gfxlib is not quite ready yet, but it should be done sometime in June.

The compiler (or rather the GNU binutils) are pretty slow, though... be prepared for more than a minute for assembling and linking something simple like examples/hello.bas.

Currently Linux FB gfxlib needs an X server to work; calling SCREEN will fail if no X server is running underneath.
At present time there are two Linux gfxlib drivers: a raw Xlib one for pixel work and another to provide OpenGL support, also using Xlib. Nothing excludes another console mode driver could be added in the future... I was already thinking about a FrameBuffer or SVGAlib console driver, but the lack of time and interest so far has put me off of it. Also, what stops me from adding a Linux console gfx driver is the bloatness factor: if such a driver is added, Linux gfxlib EXEs will become fatter by yet another 5-10K, and since almost everyone nowadays use X, that sounded like a waste to me.
Note, this is not my final word on the subject: I may change my mind later and write the driver when I have the time... :wink:

Quote:GCC would use 486-specific instructions when the optimizations level was set to -O3, now both libraries use -O2, i'm not sure about the code generated, the -O could be removed from the rt and gfx lib makefiles too.

What about "-march=i386" or did I got you wrong? (you could still optimize pipelining etc. for more moden CPUs using -mtune=i686 (or -mcpu=i686 on gcc < 3.3).

keeling, the thin client idea is good. But I really recommend DOS. I had a 386 a while back and though it ran Linux quite nicely, X didnt run. I had very little RAM. Anyway, DOS 6.0+ or FreeDOS would run at a good speed and it would have the necessary support for graphics too. I guess SCREEN 1 , SCREEN 2 would work fine.

Yeah i would also recommend using FreeDos if it runs FBC for dos. Getting a graphics library going with the basics and then your set.