TNT4882-ESP - Are there any compatibility issues with Borland Turbo C++ 3.0?

[PJL]

Hi,

I've been developing an HPIB Hard Drive emulator (Amigo protocol) using a TNT4882 ISA board which was working quite sucessfully on Borland Turbo C++ 1.0 IDE.  I found a few discrepencies with that version of IDE and I decided to move to a slightly newer version (3.0) that I had around.  I'm using a simple interrupt routine to detect incoming commands from an HP1631D logic analyser that I have, but otherwise all command and data transfers are processed via your standard ESP shell routines (namely Send and Receive) - no other interrupts, DMA or queues.  I also set up the TNT using registers directly because the Amigo protocol has a few perculiarities that are not compatible with standard talker/lister functions.

The problem is that, for some reason, data transfer is being corrupted with Borland's 3.0.  For example I can see a data byte 0x16 being transferred using my Logic Analyser, but it appears as an 0x0a in the data buffer following a Receive().  Borland 1.0 worked perfectly (at least in this area).  I've inserted various delays between commands to the TNT, but they have not helped.  I suspect that 3.0 is a little more efficient, and therefore faster, than 1.0 and this extra speed is causing the application to read the TNT registers earlier than expected.  Is there anything I can do to slow down the interface to the TNT?

I have a 533Mhz pentium PC, but I'm running in pure DOS mode (DOS is based on Win98).  TNT card is operating on IRQ11, base: 0x02c0.  Any help would be gratefully appreciated.

Regards

Peter

[Matt_S.]

Are you using the same exact hardware in both cases?

It sounds like you've hit the nail on the head when you say that you think the problems are caused by optimizations in the compiler, so delays should be helping out. One other possible thing you could do is look for optimization settings in the compiler and see if you can try to get it to match a little closer to the old compiler.

Is there a particular function that's failing more often than others?

-Matt S.

[PJL]

Hi Matt,

Many thanks for replying.  After I posted I had another go at trying to resolve the issue and found that the new(er) compiler didn't like the huge model.  I haven't found out why yet, it may be just finger trouble.  When I compiled using 'large' the problem went away and everything works as it should.

Your ESP code shell appears to be very robust, even with an old HPIB machine. (probably pre 488.1 era - just).  Trying to interface with a relatively old HPIB machine has forced me to learn a lot more than I have ever envisioned.  Each time I crack one problem there's another layer of problems lurking underneath.

Regards

Peter