presentation for SVFIG

[fox@xxxxxxxxxxxxxxxxxxx (Jeff Fox)]

Hello MISC mail list readers,

I guess I have been offline from the list for several months.  I thought
I would send a message with an update.

Yesterday I took the F21 in a mouse that I made with an F21d prototype
down to do a demo for the Silicon Valley chapter of the Forth Interest
Group.  I gave a presentation for about 45 minutes ending with a demo
of the simulated virtual digital osciloscope on the F21 I put in a mouse.

I covered in my notes the stuff I had found in testing chips in the
last few months.  I haven't been working on testing recently as I
have a regular job working on something else.  But last month I finished
up testing the video coprocessor and wrote a few demo programs. 

The last demo I did involved taking apart an old mouse and removing the
6805 micro inside.  I put the F21 board in instead and ran a jumper from
the mouse wheel encoders to the parallel port on F21.  I wrote a program
to display the bits and said, "Oh, it looks like 00, 01, 11, 10 when
you roll the wheels." Then I wrote a routine to check for movement and
linked it to an arrow sprite.  

I grabbed some graphics from a virtual osciloscope in labview demo version
on the web, (btw: labview is a neat program. I would like to do something 
like it for F21.  It is a virtual instrument construction kit.  And the
F21 could do what the PC does except with the high speed analog on F21
it could run much faster.  ;-) moved them into F21, and wrote a
trivial demo.  

You begin in GUI with a simulated desktop with an icon
of the scope. (the only program for now) If you point to it it launches
a big scope image with control buttons. You can start or close it. 
When started it simply animates a display.  It isn't a real virtual
oscilocsope because I haven't even tested the analog coprocessor
on F21 yet.  A real scope, or real virtual osciloscope would make
the testing easier.  If I had an F21 that was already tested I
could use it a virtual lab instrument but...

Anyway I wanted to show that the system was simple enough that the
code to boot from ROM to DRAM, setup the video coprocessor to
generate 768x482 RGB video, load a couple of hundred K words of DRAM 
(programs or images or whatever) from ROM, read the mouse on the
pport, generate an arrow sprite and bit block transfer images to
video only takes a few hundred words of code.  This class of application
can operate on only a few hundred words of OS code.  In the first demo
I did with this program I didn't say it was running on my chip.   I just
showed the desktop and the application controled by the mouse.  I asked
if the person assumed it was running on a PC with Windows and the answer
was yes.  I pointed out that there was no PC, just a mouse and the monitor.

I mentioned that I had updated the emulator with versions 2 and 3 that
used 640x480 video to simulate the center of the 768x482 video display.
I get all 768x482 on the RGB monitor and on an old NEC B/W display I
have but my big Toshiba TV monitor only shows 640x440.  Version 2 and 3
of the emulator also support saving ROM files.  In addition to the
768 pixel video mode these versions can be modifed to emulate the
640,576,540,512, and 480 video modes with some of the versions of
the boot code and different input clocks that I have tested.  The
aspect ration is very close on 640x480 and will appear a bit stretched
in the vertical on the emulator in emulating those lower resolution video 
modes.  Version 3 of the emulator added the some keys to simulate the
inputs I have in the F21 in a mouse.  It lets you use the cursor keys
as simulted mouse encoder input and a few buttons as mouse buttons
on the simulated pport input on the simulated F21.  So you can load
the ROM of the simulated virtual osciloscope and run it on the
emulator.  It was the same ROM image that I used for the demo for
the Forth Interest Group.

I mentioned the numbers I had seen for speed and power consumption.
It was slower than expected below 5V and faster than expected above
5V.  The speed and power consumption dropped off very low at low
voltage.  The various video formats each requires a different
minimal voltage to sustain an video image without video jitter.
I am use 70ns DRAMs on this board and so faster ones might do
better.  The DRAMs heat up when you do offpage access at high
speed and high voltage and you need a fan to keep them happy to
really run programs in the 768 pixel video mode.  The system
really needs SRAMs to be able to generate that resolution video. 
The lower res video is more practical for a DRAM only system.

I would rather use 2x 1Mx16 DRAM on the next board I do for F21d.
We may do an F21e before too long if things work out. The plan is
for .35 and an SDRAM interface.  This should about double the
sustained performance level on stack code to about 400 mips.  Perhaps 
more, it depends on what speed we get in .35 and which speed SDRAM
is used.

But before I get to that I plan to get a real osciloscope and test
the analog coprocessor on F21. Then with more than one f21 board,
or some other sophisticated test instrument I will test the serial/
network coprocessor.  so far almost everything has worked as
expected.

Jeff Fox