Some of you might appreciate a brief intro to the version 4 VMS
debugger. DEBUG works with all VMS languages, so C, BASIC, FORTRAN and
MACRO32 programmers can use it (even with mixed language programs). It
is a powerful debugger, but quite wordy, which can sometimes be rather
annoying. One of the best things about the debugger is screen mode
monitoring. In order to make full use of the screen mode, you need to
compile your programs /LIS/DEBUG and link them /DEBUG. This will cause
symbols and references to the listing file to be loaded in the
executable. DEBUG reads commands from DBG$INPUT and writes its output to
DBG$OUTPUT which are, by default, assigned to SYS$INPUT and SYS$OUTPUT
respectively. If your program expects input from SYS$INPUT and writes
output to SYS$OUTPUT AND you re-assigned them to other than your
terminal, you'll need to 

    $ ASSIGN SYS$COMMAND DBG$INPUT
    $ ASSIGN SYS$COMMAND DBG$OUTPUT

sometime before you start your debugging. The debugger will
automatically startup when you run your program if you've linked it
/DEBUG. The only module it will know about will be the first one
specified in the link command. For example, a LINK command $ LINK
ONE,TWO,THREE/DEBUG would create an image, ONE, with three modules in
it: ONE, TWO and THREE. The debugger would know that there are 3
modules, but wouldn't know about any symbols and such about any but ONE.
You need to type a SET MODULE xxx to the DBG> prompt to get additional
modules. For you C programmers, debug becomes case sensitive at startup
so you need to type module names in UPPERCASE or it'll give you a
rasberry. DEBUG will attempt to open and execute a startup file
pointed to by DBG$INIT (if any) so you can create a file putting in it
any/all SET MODULE command(s) or anything else and point to it with
DBG$INIT to speed things up a bit. (Note: most commands and options can
be abbreviated to 3 characters, some can be abbreviated to 1 char such
as EXAMINE, STEP, GO, etc.) You can break execution of your running
program at anytime by typing ^Y (unless your program has disabled ^Y's)
and typing DEBUG to DCL's $ prompt. 

Breakpoints:

    By setting breakpoints, you can suspend program execution at
specified locations. The breakpoint is taken before the instruction at
the specified address is executed. You set breakpoints with the SET
BREAK command: 

    DBG>SET BREAK [/qualifier] [address_expression -
    	[,address_expression...]] [WHEN (expression)] -
    	[DO (command_list)]
    DBG>CANCEL BREAK [/qualifier] [address_expression -
    	[,address_expression...]]

    The qualifiers allowed on the SET/CANCEL BREAK are:

    	/ALL		!valid on CANCEL BREAK only
    	/AFTER:n	!break only after n occurances
    	/BRANCH		!break on all branches (no address_exp allowed)
    	/CALL		!break on all CALL's (no address_exp allowed)
    	/EXCEPTION	!break on all exceptions
    	/INSTRUCTION	!break on all instructions (single step macro)
    	/INSTRUCT=(op_code,...) !break on selected instructions
    	/LINE		!break on each line (single step hll)
    	/MODIFY		!break on any memory write
    	/RETURN		!break on all RET instructions (subroutine return)
    	/[NO]SILENT	!displays no message when watchpoint hit
    	/[NO]SOURCE	!displays the source line that caused the hit
    	/TEMPORARY	!watchpoint is cancelled after first activated

    A breakpoint is a program location where the debugger performs the 
following actions: 1) Suspends program execution; 2) Checks the /AFTER 
count and resumes execution if the specified number of activations 
has not been reached; 3) Evaluates the WHEN clause (if any) and resumes 
execution if it evaluates FALSE in the current language; 4) Displays 
the name or address of the location where program execution has been 
suspended; 5) Executes the commands in the DO clause if one was 
specified; 6) Issues the DBG> prompt (if a DO command was not GO).

Tracepoints:

    A TRACEPOINT is identical to a BREAKPOINT except that program 
execution always continues after the trace is reported. The syntax and 
options on the SET TRACEPOINT are the same as for the SET BREAK:

    DBG>SET TRACE [/qualifier] [address_expression -
        [,address_expression...]] [WHEN (expression)] -
    	[DO (command_list)]
    DBG>CANCEL TRACE [/qualifier] [address_expression -
    	[,address_expression...]]

See the details on the SET BREAK command.

Watchpoints:

    By setting a watchpoint, you can cause the program to stop whenever 
a particular variable or other memory area has been modified. When a 
watchpoint in your program is activated, the debugger suspends 
execution and reports the location of the variable modified, the 
initial and changed values of the variable and the instruction that 
caused the modification:

    DBG>SET WATCHPOINT [/qualifier] address_expression -
        [,address_expression...] [WHEN (expression)] -
    	[DO (command_list)]
    DBG>CANCEL WATCHPOINT [/qualifier] [address_expression -
    	[,address_expression...]]

    The qualifiers allowed on WATCHPOINTS are
   
    	/AFTER:n	!begin trace/watch after n occurances
    	/[NO]SILENT	!displays no message when watchpoint hit
    	/[NO]SOURCE	!displays the source line that caused the hit
    	/TEMPORARY	!watchpoint is cancelled after first activated

WATCHPOINTS sound neater than they actually are. They only report on 
accesses that MODIFY locations, you cannot watch a location for READ 
access. The debugger causes the hardware to detect these modifications 
by setting the write protection on the location in question. A serious 
problem occurs due to the fact that the VAX's memory protection is 
effective to a granularity of 512 bytes (1 page). The modification is 
reported to DEBUG by the hardware via an ACCESS VIOLATION FAULT. Debug 
examines the addresses involved in the fault and decides whether it 
really is a fault or not. If the variable in question is surrounded by 
rapidly changing data, there will be many many faults making your 
program run V-E-R-Y S-L-O-W. There are further complications if you
happen to have a disk buffer (or any buffer used by a VMS function) in
the vacinity of a watchpoint variable. What happens in this instance is
that VMS is given the ACCESS VIOLATION FAULT and it gives up with
INVALID USER BUFFER which can really be misleading (Gee...what does
"invalid user buffer" mean? and besides, it worked a couple of minutes
ago...). 

Screen Mode Debugging:

    Type PF3 on a CIT-101 or VT100 to put the debugger in screen mode.
You'll notice that it creates 3 windows. The top window displays the
source (from the LIST file) including LINE numbers and is labled on
the very top line with: 

    ---SRC: module file_name --source-scroll-----

The SRC labels the window, the "module file_name" indicates the file 
from where the currently displayed source came, the "source" flags the 
contents of the window as being source data and "scroll" means that the 
scroll keys will operate on this window (typing a keypad 3 will move 
the scroll word to the OUT window).

The middle window is for debugger output and is labled with: 

    ---OUT---output-------------------------------

The bottom window is for command input. The pointer on the left side of
the top window points to the next instruction that will be executed. The
keypad has some predefined keys to do some useful things. Some of the 
most often used keys are listed here:

    (Gold = PF1, Blue = PF4, HELP = PF2, HELP = Gold/PF2, HELP = Blue/PF2)

    PF3 = Set mode screen	!to setup in screen mode
    Gold/PF3 = Set mode noscreen !to turn off screen mode
    8 = scroll window up	!up_arrow function
    2 = scroll window down	!down_arrow function
    3 = toggle scrolling from SRC to OUT !move scroll function to other window
    5 = examine/source .0\%PC	!display source at current PC
    - = make SRC window full screen
    Blue/- = put SRC and OUT windows up
    0 = step to next instruction 
    Gold/0 = step into subroutine !default is to step OVER subroutines
    Blue/0 = step over subroutine !if you changed the default to step/into
    , = GO

There are tons and tons of options avaliable. The DEBUG manual is about the
size of a Wards catalog, but you are welcome to brouse through it and 
order up all that you take a liking to.    

Happy debugging
ds


From:	KIM::VICKERS      23-OCT-1985 11:26:35.33
To:	@ODDGRP,RAINS,VANELDREN,MARGOLIN,ALBAUGH
CC:	
Subj:	Hummer

			Project Proposal - Hummer/Synkazoo


1. Brief Description

	This is a small hand-held musical instrument which analyzes the pitch
and amplitude of humming, singing, or whistling, and controls the corresponding
parameters of a built-in polyphonic synthesizer (Yamaha chip.)  The user would
be able to listen to a click track and overdub drum, bass, lead guitar, and
various other instruments, turning the vocalist into a 1-man band.  

	There would be output jacks for connecting the device to a home stereo
or a guitar amplifier, and there would possibly be a built-in speaker.  Also
there would be a MIDI music synthesizer serial output, so that musicians could
control their synthesizers with their voice.  The instrument would preferably
be powered by either batteries or an external transformer lump. 

	Other features could include the option of quantizing each note to the
nearest semi-tone, for people who aren't that great at singing or humming in
tune.  In this mode, vibrato could be selected, to substitute for the voice's
natural vibrato.  There could be an octave select switch, so you could play
much higher or lower than you can hum.  And there could be speed select as
well, so you could hum a fast part slowly and double the speed on playback. 

	The voice is the most expressive musical instrument, and with this
product, it can be used to directly control a variety of synthesized
instruments. 

2. Market

	A. Musical toy users - these people would be attracted to the idea of a
hand-held 1-man band electronic kazoo.  These are the people who buy $200 Casio
keyboards with built-in tacky rhythm, Mattel Syn-Drums, etc.

	B. Vocalists - these people could turn themselves into any instrument
of the orchestra.
	
	C. Synthesizer owners - would view this as an inexpensive accessory
that would allow them to do new and vastly more expressive effects.

	D. Other musicians - composers could try out how different musical
lines work together, without having to write the music out and multi-track it.
Players of other orchestral instruments could use those instruments to 
control the synthesizer.

	It seems like there is potentially a huge market, both fad- and non-fad-
oriented, depending on the price.

3. Price - very rough estimates

	6502	$1.50
	RAM	 8.00
	ROM	 1.50
	Yamaha	 9.00	(this is a smaller chip, 3 FM voice + built in GI
				chip which could be used for drums and click-
				track, plus a monophonic DAC)
	A-D	 2.00
	Mic	 2.00
	Speaker	 1.50
	Display	 2.00
	Switches 2.00
	Electr.	 7.00	misc. electronics
	Package	10.00
		_____

	       $46.50
	    X	    4	consumer markup
		_____

	      $186.00	

	The general consensus that was reached with people I've talked to is
that the product probably needs to be under $200 to reach the broadest market.
Future models could include more voices, more memory, more features, for more
money.

4.	Potential Problems

	A. Technical
	
		The only real technical difficulty other than cost-reduction is
	the pitch-tracking.  There are many waveforms for which the pitch is
	undefined, and the 1.7 mHz 6502 has to figure out the pitch in real 
	time.  The issues are - how many pitch errors will be made, how 
	objectionable will they be, will there be a noticable delay between
	when you hum and when you hear the output, and can it be done in real
	time.  There is a product being sold for the Atari 800 which does
	many of these functions in real time, using only an external ADC, and
	using the 1 mHz 6502 to do the analysis.  Fortunately, singing or
	humming	is more strongly pitched than spoken voice, so the pitch
	analysis can be somewhat simpler.  My feeling is that the technical
	difficulties will not be limiting factors. 

	B. Legal

		Atari Inc. Corporate Research at one time long ago was talking
	about a similar idea (but without the MIDI-out or the advantage of
	being able to multi-track with a polyphonic Yamaha chip.)  But you
	can't patent an idea, and although it would be tacky for us to use
	the same name, Hummer, that they were using, so sue us.

		A thornier problem is the fact that our current Yamaha contract,
	and presumably any future one we sign to purchase the cheaper chip,
	explicitly prohibits us from competing with Yamaha in the consumer
	music market.  Ideally what would happen would be that we would design
	the product, do a non-disclosure agreement with them, demonstrate the
	product, and market the product as a joint venture using Yamaha's name
	and distribution channels.  This is tricky, but I'm naive enough to
	think it could happen this way.  The obvious question is what keeps
	them from taking the idea and doing it on their own, and the obvious
	answer is - not much.  Still, we would be saving them from having to
	waste time going through the whole engineering development cycle.  
	They've used independant programmers in the U.S before to write
	computer music software that they could have written themselves.

		We wouldn't be in much of a bargaining position concerning 
	price, but we could always bluff that we could use some other chip
	that's almost as good.  If worst came to worst, we could either find 
	some other chip that's almost as good, or market the device primarily 
	as a MIDI-controller.  At least we would still have a product, although
	the market would be smaller. 

5.	Resources and time frame

	I currently have time-domain pitch and amplitude analysis software
running on the Sound Processing System.  This would need to be considerably
tightened up and tested, and the algorithms transferred to 6502.  Most of the
6502 development could be done with a System I or System II board, with an A-D
input added.  Final development would need the actual target hardware, with the
cheap Yamaha chip in place of the one we are currently using.  Dennis Harper is
interested in doing the 6502 code, fortunately, and I can do most of the
hardware design, as long as there are real engineers around to answer questions.

	1. Project initiation meeting, and demonstration of
		humming, analysis, resynthesis and
		overdubbing with the Yamaha chip	   -	2-3 weeks

	1. Modification and testing of analysis algorithms -	1-2 months
	
	2. 6502 development (concurrent with hardware)	   -	3 months?

	3. Slack					   -	1-2 months

								__________

								~6 months