HRD Software, LLC celebrates 1 year anniversary

There are other programs that have issues with the prolific chipsets...


http://www.weather-watch.com/smf/index.php?topic=52947.0

http://www.techsupportforum.com/forums/f299/bsod-win7pro-x64-575293.html

http://answers.microsoft.com/en-us/...e-screen/318686b2-12c7-4291-9620-9b33045f6a42

http://www.techexams.net/forums/off-topic/63226-prolific-adapter-bsod.html

http://tunerstudio.com/index.php/faqs/82-windows-bsod

http://coastalexplorer.net/forums/support/topics/37999

An app cannot cause a BSOD, only a driver at Ring 0 of the processor can. Why? Because Apps run at Ring 3 and have no direct access to the hardware. Drives run at Ring 0 and have access to the hardware.

Why does the prolific driver BSOD? It has a buffer overflow when the overlfow bit hits in the flags of the 8250 emulation in the driver. What you get that, it blows the stack and your return address gets lost. So now you have a dangling pointer, pointing to god knows where in memory. Check out the CS:IP on the screen...

Rick - W4PC

 

Dang Rick! Just let my wife read that and she got all excited! Something about the dangling pointer! What's a BSOD anyhow?



..............Bob

 

LOL

Blue Screen Of Death.

 

Rick, I am not seeing he BSOD with my situation, although it was rebooting computer on occasion, Why would the prolific chipset work with HRD on my Acer Aspire laptop without a problem? It also works on the same computer with TRX manager? Thats the puzzle to me.

 

Reboot is the same as BSOD, ring 0 device goes out into space with a NULL or danging pointer.

Acer was windows Xp, different driver for 32 bit XP than Windows 7 64 bit. Can't use a 32 bit driver on a 64 bit machine. The 32 bit driver behaves itsself better.

Ive tried to get prolific to give us the source, so we could have a branded and tester driver, they wont though.

No puzzle, it's a know fact prolific's have issues with the overflow bit, which also goes into hardware handshake. If the overflow bit hits, the driver SHOULD lower the hardware handshake line until the internal FIFO buffer clears. This is also slower due to the fact you're emulation the 8250 in software and not using a hardware latch to do it. (slower of course is relevant when you're bit banging too '))

RT Systems has a very cheap FTDI adapter for the radios. Those have 100% success rate. They also send the source, which is why Rob (RT systems) and Karin can brand their drivers..

Because HRD looks at the status of the radios more than TRX does, there will be times when the driver hits the overflow bit and causes the reboot or BSOD. Again, the list of other products having issues with prolifics (outside of the ham world) is an indication that the driver still need more tweaking.

Rick - W4PC

 

Thank You for the reply.

 

Just to update everyone, Chris has been working with AC2FO on his issues... we're close to getting them solved.

5.24.36 looks solid. And 6.0 is getting more solid day by day.

This Friday, Erin's newsletter will be on the new DX Awards in 6.0.
''

 

I respect your Info, but software Can cause a Hardware Crash when the hardware does not agree with the way the software controls it.

Software can also be written to get around hardware problems, just like it does when a ram chip or a hard drive has bad memory locations.

Why can't app software have direct access to the hardware ?

Ring 3 may be app default but that can be changed in software.

Most problems with hardware now a days is shared interrupts.

Using a Open/Unused interrupt and RS232 port Number between 1 and 4 is a fix for many systems that have problems, because 232 ports were original designed for it.

You can blame the adapter company for your problems, or you can write or setup your software to get around the problems, most of the time.
.

 

I would like to thank W4PC for helping and having Chris help even thought I have not paid for support they have given me help, you can't ask for more than that.

Yes so far I have ran HRD in demo mode and Logbook in demo modes and have not have a problem. At this point I am assuming it is my CI-V Cable and prolific chipset I will try a replacement and give it a go.

 

A well written driver shouldn't allow an application to crash the hardware. If the application tries to do something bad, the driver should refuse to cooperate. The application might then crash if it doesn't handle the error returned from the driver but the whole machine won't crash.

That's basic operating system principles. You have to go back to something like DOS running in real mode or simple embedded systems (Arduino etc) to see application code directly accessing hardware.

Not true. Application level code cannot arbitrarily run at a lower level. It can only make system calls which go down into the system, do what they're asked to do, which might involve drivers and hardware, and return to the application. It's restricted to doing what the O/S and drivers permit.

 

We're glad to help. And Im gonna make you keep your promise! LOL

Talk soon

best

Rick

 

Ross, have you written Operating System code? I did back in the 80's and it sounds like you're a Kernel guy, like me.

With PC-Mos in the 1980's, we made int 21h re-ntrant for multi user mode... even BillG was shaking his head at that one. And we wrote it 'black box'. No MSFT source was used. Once I saw the MFST source for DOS in the 90's when I contracted there, I compared the two and was amazed how optimized some of the code Rod, Stew, Marty and I did compared to MSFT.

And no, INT 4 didnt have a $ at end of it. (Old coders joke about Gary Kiddle and CP/M).

Rick W4PC

 

Cool Beans.

Sounds like the HRD group is willing to help even if a person has not paid when they have time.

That is very nice.

It will pay off for them and gain more paid users in the long run.

The new version should do good when it is released.

 

Will do, and I can't forget to thank Tim, who spent quite a bit of time with me on phone and in my computer trying to get it to work. Thanks Again Guys, The Ham Community at it's finest.

 

No, I can't claim to have written any real O/S code. I wrote plenty of Z-80 assembler back in the day, often to give the illusion of multi-tasking but that was mostly on TRS-80 and compatibles. I guess it was a form of "cooperative multi-tasking" where each task had to be written to do something quick and return to the outer loop to let something else happen and remember where it was for next time around without any real O/S to speak of. Plenty of direct hardware manipulation, mostly the screen memory but also I/O ports doing some real things in the world.

I never really got into CP/M. I played with MSX for a while which was a Microsoft O/S but not popular in the US apparently. One place I worked at used Concurrent DOS I think it was called. When PCs came along I leap into Basic and then VB and then to C# when .NET appeared. These days I've mostly left Windows behind and build web sites mostly with Drupal and another PHP framework which I really enjoy. It's kind of a different world but still plenty of curly braces. I'm about to be involved in a new web application and we're looking favorably at the Microsoft web stack.