
	x*oscope infinite TODO list, in rough order of suggestion

	This is a the original text of (most) everything that's been
	thought up or suggested along with my comments and any status
	updates.  Things that are mostly done have now been moved to
	TODO.old for historical reference.  I don't know how many of
	the remaining ones will ever get done or if some of them are
	even practical without major work.

	If you have suggestions not listed here, or have strong
	opinions on the priorities of some of these features, please
	let me know!  --Tim Witham <twitham@pcocd2.intel.com>


1	16 bit sampling			(Jeff_Tranter@Mitel.Com)

	Oscope would just divide by 256 to show 1/1 scale.  The
	obvious advantage to this is better clarity when you zoom in
	on signals of small amplitude, or for use with x10 probes.
	For math to work, the size of everything would need doubled
	from 16 to 32 bits to avoid overflow.

v1.1: I made a hardware solution for amplifying x10 probes.  See
HARDWARE and buff.*.  16-bit would still be useful though.


3	envelope mode			(Jeff_Tranter@Mitel.Com)

	This only applies at slower sweep speeds, right?  See #23.


4	make drawing area mouse aware	(Jeff_Tranter@Mitel.Com)

	Be able to drag signals up and down for example.


7	smarter maximum sample rate	(twitham@pcocd2.intel.com)

	If your sound card can do greater than 44kHz, oscope won't
	currently take advantage of it.  It should determine the
	optimum rate at run-time.  I used 44kHz because it was the
	most my card could do at a one sample per pixel screen
	resolution.  But, for example, if your card can do 88kHz it
	could plot every other sample until you zoom in to get 1:1.


8	trigger on math or memory	(twitham@pcocd2.intel.com)

	You could hide 1 and 2 and use an external command as input.
	Also allows you to trigger when 1 equals 2 or whatever.


9	show pre-trigger samples	(twitham@pcocd2.intel.com)

	Let user position trigger horizontally.  Remember samples
	until we find trigger, then capture h_points - pos more.

v1.4: Of course this wouldn't work with ProbeScope since we have no
samples before trigger.


10	external command history	(twitham@pcocd2.intel.com)

	Remember previous commands and make them available in a list.
	Possibly record them all to the data file.


11	vertical scale calibration	(Grant_Siemers@ccm.fm.intel.com)

	Ask user to apply a signal of known amplitude and use the
	result to correctly label voltage on the Y axis.  I wonder how
	many folks could actually do this?

v1.4: ProbeScope voltage is labeled correctly, no calibration needed.


12	channel colors			(Grant_Siemers@ccm.fm.intel.com)

	Let user customize the colors of the channels.


15	autosetup			(Sean_Eilert@ccm.fm.intel.com)

	Auto-find one period and set the time scale appropriately.


22	increase time/div range		(twitham@pcocd2.intel.com)

	Currently, the slowest sweep speed is 1 sample per pixel for
	one screen full.  Slower sweeps could be done by skipping
	samples, averaging, etc.  Will need to plot a fraction of the
	screen then sample and plot more beyond the first, instead of
	the current gather all, plot all loop.

v1.3: Oscope can now skip samples but nothing fancier.

v1.4: If we don't have enough sample depth for the screen, then only
part of the screen is plotted.  This feature would never be useful for
ProbeScope since we'll never have more than 128 samples past trigger.


23	more acquisition modes		(twitham@pcocd2.intel.com)

	With #22, we could do various modes like peak detect,
	envelope, average.  I'm thinking all samples could really be
	stored in memory in which case these would really be display
	modes.  That is, how you see a combination of samples
	represented at one horizontal pixel position on the screen.


25	separate sample / display buffers	(twitham@pcocd2.intel.com)

	Internally, collect samples in a different buffer and then
	move them into a separate waveform buffer.  This would greatly
	simplify implementation of several of the above features.

v1.3: I've re-written the display routine to understand arbitrary
sample rates.  Well, anything below 44000 for now.  So maybe this
won't be necessary.

v1.4: The display now works with rates up to 20,000,000 S/s.


26	sound pipe input device		(james@albion.glarp.com)

	James Feeney suggested a variation to #18: the ability to send
	an audio file or command output into a running oscope process.
	This may be doable through /dev/dsp if it could be opened
	non-exclusively.  Oscope or the player process would need to
	work with the current sample rate instead of each trying to
	set it.  Or this could be done through a named pipe (FIFO) in
	the filesystem.  It can already sort of be done through the
	external command interface.  A command could just disregard
	the input and send a new signal in to one of Channel 3 - 8.


27	time/frequency and amplitude cursors	(twitham@pcocd2.intel.com)

	Cursors similar to Radio Shack's ProbeScope software would be
	useful.  A key could toggle them on/off like freq does, then
	the keyboard would have an alternate layout to move them.  Of
	course mouse support, #4, would be nicest.  The display could
	replace the auto-measurements in this mode.


28	Fix voltage measurements for ProbeScope	(twitham@pcocd2.intel.com)

	Since I don't know the GND level of ProbeScope input, I didn't
	bother to turn amplitude measurements into voltages.  The
	peaks could be referenced to a level other than the center.
	But, at least the peak-to-peak could read in literal volts.


30	BitScope support (www.bitscope.com)

	I plan to write this in the year 2000 when I will finally have
	time, unless someone sends me the code to do it before then.

	The BitScope is a "Mixed Signal Capture Engine."  Way cool
	programmable hardware that aquires data and makes it available
	through a serial port.  With its 2 analog channels and 8
	digital, it has the potential to turn xoscope into a real
	combined digital scope and logic analyzer at up to 100 MHz!
	My rough initial plan of attack is:

	+ 2 way serial communications to the device

	+ modularized programming and I/O functions

	+ a new channel display mode that instead of drawing one
	analog line draws 8 digital ones.  This way the existing
	buffer memory capabilities will work for the LA too.

	+ the keyboard interface may need replaced with some sort of
	on-screen menu system to organize the many features, similar
	to the menus of real DSOs.

	+ this likely will be a separate configuration at build-time,
	completely separate from soundcard and probeScope devices
	since the hardware is so much more sophistocated.  In other
	words, it will produce a separate program, for BitScope only.

	Obviously this will not be trivial but will be very well worth
	the effort.  Sorry I never had time to do it yet.  I am still
	looking forward to using BitScope with xoscope on Linux.
