retro: serial & other problems

[Tom Novelli]

On Sun, Aug 01, 1999 at 11:26:57AM -0400, Paul Dufresne wrote:
> -there is a include of uvars.inc that does not seems to exist in pmode.inc

oops! fixed.  Those are going to be the variables for each
user/task/process.  Hmm, "user variables" is from ITS, but that's back when
most timesharing systems only let each user run 1 job.  ITS let you run as
many as you wanted, like Unix, but it called each job a "user" :)  Maybe
"process variables" (pvars) or "job descriptors" (jdesc)...?

It's tricky.. retro is gonna have cooperative multitasking, so you could
have 5 programs running on different consoles, all with the same TSS and
page tables.  Sure those programs aren't safe & secure from each other, but
it's faster.  Forth programs can PAUSE (switch to next task) when they're
not using any registers, so the context switch only involves saving &
restore EBP & ESP.

> -now that I added your link on kbd_dv.map for keymap file, I am afraid
> that the next time I'll commit to Retro, everyone will use Dvorak
> (there a M before keymap when I do update command, need a way to
> tell cvs to not commit this file)

hehe, I just thought of that yesterday.  I put 'keymap' in .cvsignore.  I
hope that does't cause any OTHER problems.

> -For now I need to do make clean ; make because boot.bin does not
> depends on serial.asm. Do renaming my serial.asm to serial.inc would
> fix it? I know I must do it correctly for cvs. I am not good at
> understanding Makefile(s).

I just added serial.asm, serial.mac, terminal.asm to SERIAL_DEPS in the
Makefile.  Any file used to build the kernel needs to be listed in BOOT_DEPS
so the kernel will be rebuilt when the file changes.

> -hum, I think I did something wrong like wrapping init-com (now a
> forth word) between pusha popa, please recall me what registers
> I must take care not to modify, ebx? (oops I wrapped almost all my
> forth words in serial.asm between push ebx and pop ebx, but they
> seem to work! :-)). Is there any other registers I must not touch,
> like esi?

Don't touch EBP, that's the data stack's pointer.  Well, if you know what
you're doing, you can touch it. :)

It's ok to use PUSHA/POPA if your routine leaves the same number of items on
the stack.  init-com doesn't touch the stack, so it's ok.  If you pull one
item and push one item, then it's ok.  If you pull one item and don't push
any, you can't use pusha/popa.

I heard there are some buggy CPU's that don't handle PUSHA/POPA correctly,
that you shouldn't use it at all.  Usually I use:
	mpush	eax,ebx,ecx,edx,esi,edi
	...
	mpop	eax,ebx,ecx,edx,esi,edi


> -when serial.asm was a module (not included in pmode.asm), the code
> at the beginning was executed automatically, now I have to run
> init-com in forth before using the other serial related words

Call it from pmode.inc, near the top, where you see the other init_* things
being called.

> -about set-rx-handler and set-error-handler, they call stuff from
> inside the uart interrupt, so it does not looks like a good idea
> to call forth from there, so I'll keep them to call an assembler
> routine (even in assembler, you must take care not doing much!).
> For now I'll write my mouse driver in bforth.fo and later I will
> translate it in assembler and use set-rx-handler to call the
> assembler version of the mouse driver

In this case, I'd stick to assembler.  You could call Forth functions from
an interrupt.. you can even use the stack, as long as the stack diagram
looks like this: ( -- )  Only problem.. what if the interrupted routine
isn't a Forth program, and it's using EBP for something else?  We'd need to
allocate a small stack area for ISR's written in forth, so the machine code
would look like this:
	push	ebp
	mov	ebp, [ISR_stack_pointer]
	CALL	some_forth_word
	...
	pop	ebp
	iret

Hey, now that we have graphics you can actually do something with your mouse
driver!  At this rate we'll have a GUI pretty soon... not that I'll use it.

> -since that words.inc have already synonyms for ior to be inb,
> and iow to be outb, I suggest that we use it in bforth.fo
> I used these words only for debugging until now, let's make this
> change as soon as possible, while it is easy.

Done.

> -hum, to write some terminal stuff in Forth I'd need key?, and ideally
> a way to read F1-F12, I think we don't have this in Forth yet.

I'll put it on my list in kernel/Notes.txt.. "finish up keyboard stuff" or
something :)  I've also gotta allow keys that call Forth commands, like BOOT
when you press ctrl-alt-del (right now, Pause is hardcoded to reboot).  That
could come in handy.

Whew, that was a lot.. heh, just keep nagging me about this little things
and I'll take care of them sooner.

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