retro...

[Tom Novelli]

I'll Cc: this to the list to inform other people of the project status.

On Mon, Aug 23, 1999 at 08:46:17PM -0400, Paul Dufresne wrote:
>  
> > I'd like to work on some basic "GUI" stuff, at our leisure... windows or
> > "panes" or "tiles", window/console switching, an efficient keyboard
> > interface.  I'm also starting a drawing program.. it'll do both bitmap and
> > vector graphics (CAD), and eventually word processing, databases, etc.. in
> > other words, an all-around "editing environment" that's totally open &
> > extendable.
> >
> All in Forth? Retro Forth? Seems to me that Retro-Forth is too incomplete
> to do that now. Maybe you do it all in Nasm.
> I think we should do window/console switching. In assembler I guess.
> Later it will still be time to do a tree of window to build the GUI
> system. In Forth I guess. But personally, I see the GUI step done much
> later.

This is just to play with, when I get bored with the important stuff like
disk & memory management... it's down at the bottom of the list right next
to sound card drivers :)  Besides, I'll need some programs to guide me in
designing the graphics system, and to test it.  NEVER separate "operating
systems" and "applications".

> What did you thought of the proposition of Fare to have someone look
> how to include the OS toolkit modules, or Linux drivers in Retro?
> Do you think that xcom loader will make that easy?
> It looks like stuff that could easily make Retro very big, but I don't
> feel like doing drivers for every hardware. 

I don't see much useful in oskit that isn't in Linux or FreeBSD or XFree86
or SVGAlib... but yeah, there are some drivers I'd like to compile under
Unix, link into XCOM format, and load in Retro... if they interface cleanly. 
I WILL NOT make Retro conform to Unix.  If a driver won't interface cleanly,
I'll rewrite it using the original code as a guide.  It sounds like a lot of
rework but it's nothing compared to my day job :(

> If I am right, bforth.fo is not read from the DOS floppy right now, but
> incbin in forth.inc, although that kernel.bin is read from DOS floppy. It
> is unclear how far we are from reading any DOS file on the floppy. I did
> not seen general FAT reading yet but just some kind of hack in dosboot.asm
> to read only kernel.bin.

heheh, I'm about 5 minutes away :)  On Sunday I had it parsing the MBR and
boot block, searching the root directory for the filename, and almost
loading the file's clusters.. unfortunately I had to stop and haven't had
time to work on it since.  Once that's done at least we'll have a simple way
to load programs and drivers, instead of putting everything in the kernel. 
There's more: 1) subdirectories.. :)   2) Writing files to disk (and write a
file editor)   3) Organize the disk/file system in general.

> Yeah, it is too many projects at the same time. :-)
> What would you think about announcing the project on comp.lang.forth to
> get a bit of help. There was already a guy there that was willing to do
> a 32 bit x86 OS around Forth. So I wrote him a private e-mail and explain
> him how to find Forth from the Tunes OS page. I have others fields of
> interest, and that could limit the time I can put on Retro, so external
> help could be usefull.
> 
> I never used GASM. I like the way NASM see by the context which size
> it is. mov [var],eax or mov [var],ax But mov [var],5 need
> some precision. I think I am saying I prefer nasm and mov dword.
> But if you insist I choose between movl and mov.l, I think I will
> choose movl. Sorry, I don't like the idea of changing a convention.
> movl is not used only in GASM, I think I saw this on the assembler
> of the 16F84 microcontroller. So it begin to look like the normal
> stuff to me.

It's familiar 'cause it's AT&T syntax :)
Intel:		mov	dword dest, src
AT&T:		movl	src, dest
Motorola:	mov.l	src, dest
Forth-style:	dest src dword mov  (?)

> I would have hoped that we could have taken a simple Forth-like
> assembler from an other project, putting time on stuff more
> Tunes like, like persistence.

There's PASM486 (in Win32Forth), which does regular 'prefix' assembler in
addition to 'backwards' Forth-style assembler.. I'd need a more complete
Forth implementation in Retro (which I'll do sooner or later anyway), but
that would be easier than writing a whole assembler.  I'm sorta interested
in writing one just for the hell of it, though.  I have some unorthodox
things in mind.

I'm getting away from the Tunes stuff for a while.. but I did think of a
simple way to mix FORTH, LISP, and a FORTRAN-style syntax.  Persistence is
still high on my agenda; DOS FAT support is no substitute :)  I'm just
laying the groundwork, hoping for some deep insight in the meantime (to make
it more "scaleable").

> Hey, it is slow now to boot from floppy, about 15 seconds.

I hardly noticed a difference.. kernel.bin loaded in 2 seconds on my 486. 
Maybe it's your BIOS?  When the protected-mode file loader is ready, see if
it's faster.  It doesn't use the BIOS.  Either way, the bootsector needs
improvement.

> And my mouse stuff was not in the 'dos' version, but it was
> there in the raw version I made previously. But I can't make
> raw again because make rawfloppy request image, and depend
> on modules that is now commented out. But I guess it should
> be part of the image because it is supposed to be included
> in forth.inc. Hum, I need to figure out this.

Oh, edit your 'options' file and uncomment the BETA thing.  The 'dos' and
'raw' versions are identical except for the boot sector.  The mouse stuff is
only included when BETA is defined.  I'll get rid of that when I can load
them mouse driver from a file.

> When booting, my FUJITSU disk appears as UFIJST U. I guess you saw
> this and did not cares much, but it should be on a list of bugs
> to fix.

Oh... wrong endianness!  Little bug reports like that really help.  I didn't
notice when my WDC AC2120 showed up as DW CCA1202.. either way it's just a
number :)


To sum things up, here's my current agenda:
1. Disk/file system
2. Memory management
3. XCOM loader
4. Assembler
5. Graphics routines & drivers (I'll see what I can do with GGI/KGI)
6. Debugging....

-- 
Tom Novelli <tcn@tunes.org>
http://bespin.tunes.org/~tcn