Index of /~baker/devices/projects/kelnat

kelly ran more pieces of code to try to get the internal read buffer to go back to the
begining. nate finished plugging in the parport side into the alsa side. despite the sparse
alsa documentation, it was suprisingly easy to attach our functions. we hooked up the driver
into the alsa modules config and /etc/init.d/alsasound'ed the thing to life. we have "write to the
device" working just fine. when we went to read, the process went into a loop and never came out.
we were so happy we did i little jig in the networking lab for lucy and her lab partner. then we went home.

we are thinking that we need to tie in an interrupt into the trigger function. but we were too tired to
go to deep into it. more tomorrow.

spent alot of time today, despite the huricane, from our respective homes, nate trying to grok the
minimally documented alsa drivers, kelly testing his theories about how the box comunicates.
kelly has the midi out working fine. the midi in however, is funky. something is wrong with the
initialization tests such that the module (load time probe()?) hangs when the input buffer is full
and being over run with data from the outside port. kelly is working off a stable enough module
loader to use for tests. again, nate is trying to grok the alsa.
sleep....

reworking of the main driver. loading and unloading is clean. composition of the get and set functions.
new reworkings are the note1.2 directory.
new get and put char ops are in note1_get_put.c with headers note1_get_put.h

we are on to the file operations. see ya tomorrow.

we've also decided that since we know how to make a character device and that we know how to test a character device
we should write it as one first. ten we can port it to alsa, either with more module stacking or as a native 'card'.

We've established a page on the alsa-wiki for the web based log class requirement for the development of this driver.

Lets review what has been happening for te last week.

Reviewing qemu parallel port trace logs we've discovered the mechinism for read and write for the note/1.
this looks rally bad in a kerned font.

Here is a snapshot of the code that stacks on to parport, so far written by nathan.
WARNING
THESE ARE SNAPSHOTS AND DI NOT WORK YET!!! THis warning will go away eventually....

K: reviewing output of the patched qemu parallel port driver.
N: more parport stackage-ing code.

day off

generated more logs using qemu from bsd. there are some differences in the way bsd and linux appear on the ports.

we wer bout to give up on this thing. no data. noting we would say to it seemed to have any effect.
we finally got a working DOS image on the hard disk, ran the programs off of turtle beach's web site and the device
tested ok. it turns out the MIDITEST.EXE sends itself some sequence of sysex midi messages and then sees if
they come in on the in port. For some reason they don't seem to get recieved correctly in emulation. We consider the
issue of the emulator's ability to pass through irq signals. Nate set to work laying in printf-s into the parport handler routines
of qemu. We generated bunches of data. the most useful turning out to be pplog3.txt and pplog4-recieving.txt.

spent the day at all saints with a tascem us-122 and the parport of nate's IBM laptop trying to send signals
between the two. NOTHING. figured out that the HP-49g+ calculator speaks kermit. considered the process
of making a driver for the HP that represents it as a block device though the underlying structute is a KERMIT session.

sending random signals to the parallel port of the note/1 produced a midi 'reset' message from the note/1.