Re: MISC-d Digest V97 #2

[jfox@xxxxxxxx (Jeff Fox)]

>How are words like CATCH, THROW, and DEPTH implemented in a stack machine such
>as F21 where the return and data stack pointers are not accessible?
>
>-Dave

I think there are three possibilities.  It is an issue because as you  note
there is no way to read the value from the internal stack pointers.
If your Forth implementation uses stack in memory there is no problem.  That
is the way P21Forth is implented.  You can use whatever threading model and
if you have stacks in memory like most implementations then you can easily
implement DEPTH etc.
If you implement something closer to the hardware and use the on chip 
stacks you are dealing with what Chuck likes to call "Machine Forth."
The Machine Forth on F21 does not include any way to read the internal
stack pointer registers.  Yet there remains two alternatives.
One can place a tage of one or more words on the stack.  This takes
up some of your precious stack space.  It does provide a way to flush
the stack to memory and search it for the marker.  This is what I did
on the first subroutine threaded Forth implementation for the simulated
F21.
One can also provide depth information in the compiler and provide some
way to deliver depth information at runtime.

>From: Juergen Pintaske <jp@mixed-mode.de>
>To: MISC-request

I thought MISC-request was just for control information and I didn't
information sent to request to be sent on to overyone.

>Subject: MISC Chips in VHDL
>Message-ID: <32E563A7.3722@mixed-mode.de>
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Please inform us if there is any chip available as VHDL. We as
>Designhouse in Germany look for RISC Cores to be designed into ASICs and
>FPGAs and Forth includes the software needed.

Dr. Ting is working on a P16 on FPGA at the moment.  I don't know about
availability.  One would have to check with Offete Enterprises Inc.

>From: Andrew Sieber <asieber@hotmail.com>
>To: misc
>Subject: Re: Mup21, features
>
>Somebody please correct me if I'm wrong, but I believe that a standard
>composite video signal carries no sound information.  For broadcasting,
>the composite signal is amplitude-modulated on a 60-or-so megahertz
>carrier (carrier frequency being of course dependent on which channel
>you are using.)  Then the audio information is frequency-modulated and
>sent along with the separate video signal, and a TV is really a TV and
>FM radio combined into one, because it decodes two separate signals: the
>AM video signal and the FM audio signal.  The MuP21 can produce a
>composite
>video signal, but you can't put sound on this signal.  You could,

Quite right except that a P21 can produce sound with very little external
hardware and that sound could be fed to a TV RF-modulator (one with a
sound input of course).  Yes there is no sound in "video" and the
P21 coprocessor outputs video not TV.

A D/A on a latched output port on P21 can easily generate sound with a
little software.  A timed input source that could be read by P21 would
be handy for tight timing.  Even a single bit can be used with modulation
to produce N bits of audio out.

I had wanted to add sound i/o to P21Forth but never did.

>however,
>use another P21 with an extremely slow "video" clock (like 22kHz) and
>put
>digitized sound information where the "video" signal for the DMA D/A
>converter is supposed to be.  This P21 would then produce an audio
>signal
>that you could actually amplify and hook to a speaker and directly
>listen
>to.  You could hook the video signal to a TV and the audio signal
>to your stereo system.  Or you could AM modulate the video signal and
>FM modulate the audio signal, and send both of these signals to the
>antenna jack on your TV and it would display the video and emit the
>audio.

Yes one could.

>>I came accross something interesting in a jornal the other day, it was
>>called NVSRAM I think, by a company called Simtek, I think they used to
>>produce 6502 chips.  The company claimed that they were non-volatile,
>>operated at 25ns, something I can't rember but it led led me to beleive they
>>were not flash and did not have limited write cycles, and available is sizes
>>upto 256KB.  Well this was very interesting, a chip that could replace
>>bother rom and ram in a design?  

They make non-volitile SRAMs that are nothing more than a very low power
cmos sram with a tiny battery.  They fit in the same socket as a standard
large SRAM or ROM so one can drop one into a P21 board already.  You can
also use anything else that looks like a ROM or SRAM.

P21 handles DRAM and SRAM (or ROM) chips in very different ways.  You
COULD populate the DRAM space on P21 with SRAM chips, but I don't know
of anyone except Chuck who has run SRAM chips in the DRAM space.  If you
used SRAM chips in the DRAM space you would not need to bother with
refresh generation.  Also you would still get DRAM timing out of P21.
That is access off a 1K DRAM page would always add 100ns to the timing
on the memory interface.  The SRAM (ROM) memory has fixed timing on
P21, 250ns or ~50ns access in the slow and fast SRAM (ROM) address 
spaces. 

I have taken a PCMCIA SRAM card and used it with a jumper in the Offete
Kit in the ROM socket.  If you give it write enable you can use the ROM
socket to write to FLASH, SRAM, NVSRAM, or whatever.

>>If the 256KB was available in 32-bit
>>version (some srams are) then one NVSRAM and MUP21= 1 computer
>>(simplictically speaking).  If in 8-bit versions, 3*8-bit NVSRAM= 256kwords
>>of memory.
>Are you talking about battery-backed sram?  There are sram chips made
>that actually have a battery inside the plastic package for the chip,
>and automatically battery-back the sram when power to the chip is
>removed.
>These batteries can often last for a decade, so what you get is
>effectively
>a super-high-speed-write eeprom with unlimited write cycles.  You don't
>have to deal with an external battery or support circuitry because it is
>all integrated right into the chip's package.  Jameco sells a 256kB
>version
>for $27.95 (according to my late-1996 catalog.)  Dallas Semiconductor
>makes
>the chip that Jameco sells.

I haven't tried one but I think it would work on the second and third
P21 boards from Offete.

>I've got two questions about the MuP21 myself.
>1: The S21 simulator program will execute a jmp-if-T=0 if the T register
>contains a 000000 OR a 100000.  It appears to be ignoring the carry bit!
>Is this a fluke in the simulator, or is this actually how P21 operates?

T=0 is jump on bits 0-13 (hex) =0.  Bit 14 hex ( 21 decimal) was meant
for carry and memory addressing, it is ignored by T=0.  that is what
C=0 is for.

>2: The T=0 instruction says that if you have an instruction before a
    ^^^^^^^^^^^^^^^^^^^^^^^^
 No, the T=0 instruction performs a conditional branch, it doesn't
 "say" anything.  Now some documentation that you have somewhere on
 some version of P21 from some source might indeed say that, I don't
 know what documentation you might have.

 I can tell you that there are lots of examples in OK and in P21Forth
 where we use an instruction in front of a T=0 or C=0 where the stack
 is changed so I would not believe that documentation.  Look at the
 examples.  There are examples if XOR IF     or  XOR UNTIL etc.

>jump-if-T=0 instruction in the same word, that first instruction may not
>change the T register.  If it does, the condition for the T=0 will
>depend
>on the state of T BEFORE that first instruction is executed.  Well this
>seems rather useful: since the IF instruction in Forth consumes the
>flag, while jump-if-T=0 does not, you could have a word that does this:
>drop jmp-if-T=0 aaaaa aaaaa
>where the a's are the address to jump to.  This would result in a
>jmp-if-T=0
>instruction that DOES consume the flag.  The same would be the case for
>the jmp-if-carry=0.  Will this trick actually work?

No the state of the T register should be valid at the end of an
instruction before a T=0.  The exceptions are of course + and +* which
may not provide valid results in one instruction time.  But with
any other instructions you can say
 Whatever Until     or whatever if     or whatever -until    or whatever -if
where -until and -if compile C=0 while until and if compile T=0

These are not the same as a normal Forth UNTIL or IF because as you point
out they do not consume the top of stack.  They are the equivalent of
DUP UNTIL   or DUP IF  in standard Forth.

    Jeff Fox
    jfox@dnai.com              Ultra Technology Inc.
    jeff@itvcorp.com           the iTV Corporation
    http://www.dnai.com/~jfox/