This page has my running notes on the construction of the DSP-10. Obviously, the first place to go is Bob Larkin's web site dedicated to construction hints, code releases, updates, corrections, etc.
Throughout the construction of my DSP-10, I hit my own set of snags. These will be discussed here, along with additional code, procedures, etc., that helped me get my unit running. All the standard disclaimers come with the information you retrieve from this site: This info is free. Steal with pride. (If you didn't get the joke, what I'm trying to say is it's all free, and please don't hound me if you blow up your lab bench while reading the web pages!)
Note: I still consider this experimental. I'm hoping to find a few operators who would like to try this out and verify operation beyond my own spot-tests.
The issues discussed on the [dsp-10] news group involve the communication link between the PC and the target (the DSP-10 itself). I have experienced similar behavior: Once the program has loaded and is running, the target appears very selective at what characters it sees.
The target application expects six-byte commands from the PC. The uart receiver code has two safety timers in it. The first one is a 2ms timer, designed to make sure that any single character completes within 2ms. Since a 9600 baud character takes (roughly) 1ms to transmit, this is a good timer to have. The second timer says that the six bytes need to arrive in a very tight time-packet. Each subsequent character must arrive within the 2nd safety timer's time window. Otherwise, the entire 6 byte packet is thrown out.
For my own experience, I noted that my character-to-character transmit interval was usually 2.6ms. This indicates that my serial port code was not properly double-buffering characters. (Part of this is Windows, part of this is my need to fix my driver). But it also alerted me to the UHF3 code. What I found was the 2nd timer was also set to only 2 ms. So unless all 6 characters arrive in one tightly clumped bundle (as it probably would under true, native DOS operation), the packet might not be parsed properly by the DSP-10.
When we boot DOS (prior to running windows), there are no other drivers between the application and the serial port. Sending a character means it gets sent. Sending another character means DOS waits for the first one to complete before the next one is queued out. (The typical UART is double-buffered). Once windows is loaded (under win3.1, win95 or win98/me), the serial port is serviced through a .VXD (a "Virtual Device Driver") in windows. So DOS "box" applications behavior can be held up by the VXD's ability to service the port. Data integrity is guaranteed; timing integrity is not. (Windows 2000 and Windows XP do not use VXD's. They use another driver model called WDM. For our discussion, this is irrelevant.
Because windows wants to allow your virus-scanning software, Outlook, iTunes and Google Desktop to all rob valueable cycles from your high-end x86 CPU, everyone gets a time slice. In the days of Win95, a context switch (changing from one application to another) could take up to 10ms. So if the DOS box is in the middle of sending 6 characters and something deemed "more important" needs the CPU, it will be at-least 20ms before your application gets to run again. On the serial port, this could mean that you would see 2 bytes go out, a 30ms idle time, followed by the remaining 6 bytes. Since the link is asynchronous, this is acceptable behavior by the standards. Perhaps this meant that the UHF3 application needed to be a little more forgiving when servicing the incoming serial port.
As an experiment, I raised the timeout timer within the DSP-10 UHF3 code up to 1 second. This provided the timing relief I needed. The DSP-10 target was now extremely forgiving, and six-byte packets were being parsed and acknowledged in a prompt manner.
As a side-benefit, I realized (quite by mistake) that I could now run UHFA from a command prompt, under Windows-XP, without having to adjust anything else. I simply opened up a command prompt (Start->Run->"cmd"<CR>) and then typed UHFA 1<CR>. I'm noting that the graphical window maximizes the screen (so it doesn't run in a "box" yet). I believe I tested this against UHFA version 3.80.
If you are interested in trying this out, feel free to download my experimental UHF3 binary. It is called UHF3_33x.exe. This is identical to the EZKIT-LITE. You can load it with EZLOAD or EZFAST. Just replace the file name in your startup script and you should be set. To keep up with the spirit of the GNU_GPL, the one source code file is part of the bundle (this is built on top of the W7PUA UHF3_32 code).
Previous links, photos, etc.:
Feel free to send constructive feedback (and you know who I'm talking about!). Keep experimenting!
ka7exm at gmail dot com