[DSP-10] additional testing of UHF3 / UHFA / XP
Bob Larkin
boblark at proaxis.com
Fri Dec 19 03:21:22 EST 2008
Great work, Roger, Mike and Ernie!
I have not attempted to make this go with XP but I will.
For now though, I am trying to understand the pointer table problem. I
looked at the code in UHF3_33.EXE, and it seems OK. I see the proper "JMP
START" at location 0, and the pointer table location is at location 1 ---
all proper. I assume that EZLD is getting this all loaded.
The problem may be in the reading back the program memory from the
DSP. This involves the PC requesting the 24-bit word at a particular
location, waiting a few milliseconds, and then reading the data from the
serial port as part of the status bytes. It may well be that longer delays
are needed here, as well in order for the serial data to have arrived. The
error message says that the wrong value is being read from location 37
which is always set to the hex value 12 34 56.
If someone wants to play with changing the C-code, fine. But other wise
don't worry about it, I will try to get a chance to add some delay and see
if it works.
Meanwhile, a couple of functions may not work, the biggest being the
SCRL-F4 filter design.
For those with interest as to why this is done, the DSP linker moves code
around to optimize memory usage. This causes data tables, like filter
coefficients, to move about. To make it possible to alter the DSP code
from the PC program (while the radio is running), a table is maintained in
the DSP memory with pointers to all the data tables. The location of this
pointer table can also move, so a pointer to its location is sandwiched
into the startup vectors at location 1. This latter code must always be
left by the linker at a fixed location. Once the initial pointer is read
into the PC, the DSP memory map can be figured out.
73, Bob W7PUA
At 09:38 PM 12/18/2008 -0800, Roger Hayward wrote:
>Mike:
>
>This experiment was presented to the DSP-10 group way back in August
>2007. I stumbled across the code-change while trying to get a full-blown
>windows port running. I found the same timing issue with the control
>program ported under windows. Once I cracked the issue open, the
>motivation to complete the windows port seemed somewhat futile. (One of
>the underlying goals was to not branch the code away from Bob's code
>base....so seeing Bob's application run native under DOS was deemed a
>better feature to keep than to earn the dubious job of maintaining a
>windows port for the next 10-20 years!)
>
>Quite literally, the only change to the UHF3_33x code is in about 2 lines
>of code. Bob's UART receive code is very unforgiving. He complies to the
>written RS-232 specification. Unfortunately MS-Windows method for
>handling the double-buffers of the RS-232 does NOT fully comply the
>specification. So the forgiveness timers in the DSP board were extended
>from microseconds to milliseconds, which gave Windows the time to complete
>a context switch between characters. Something like that.
>
>I encountered some of the similar nuances you have experienced, but did
>not chase them down very far. We have binaural exciters at home this
>year, so that is taking quite a bit of our bandwidth this
>year. <http://picasaweb.google.com/ka7exm>http://picasaweb.google.com/ka7exm .
>
>73 for now. Thanks for finally noticing the code and checking it out.
>
> Roger KA7EXM
>
>
>On Thu, Dec 18, 2008 at 9:24 PM, kd7ts
><<mailto:kd7ts at aceweb.com>kd7ts at aceweb.com> wrote:
>>I let the box run for about 3 hours, tested everything I could think of,
>>and all seems fine.
>>
>>After shutting down the UHFA program but leaving UHF3_33x running, it did
>>not want to
>>start again. I had to remove power from the DSP-10 box and let it boot
>>from the eprom,
>>and reload using the batch file from the floppy. Then everything was OK
>>again.
>>
>>I tried using windows 98 also, but this required some effort to get
>>going. There seems to
>>be some issue with getting the pointers. After UHF3_33x was loaded, I
>>just kept
>>hammering on UHFA, and it finally got the pointers.
>>
>>Next trial was just using UHF3_33x and UHFA in DOS which works normally.
>>
>>Since I have laptop computers dedicated to DOS I will continue in the
>>same old fashion.
>>
>>W7LHL also tried XP and Vista. XP worked fine, and it appears Vista might
>>work, but there
>>is some issue with the screen driver. Ernie has a wide screen. Everything
>>loads, so the
>>com port seems to be OK, it just doesn't like the wide screen somehow.
>>
>>I have not tried putting the files on the hard drive. Ernie did, and it
>>worked fine for him.
>>
>>Way to go Roger !! It works great. Thanks again..
>>
>>73 Mike KD7TS
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qth.net/pipermail/dsp-10/attachments/20081219/27e22b17/attachment.htm
More information about the DSP-10
mailing list