Prevent buffer overflow on HP82240B Simulator

[Christoph Giesselink]

There's an update of the HP82240B Simulator to prevent a buffer overflow in connection with the Virtual HP-IL oo82162A Printer Simulator printing barcodes.

From design the display update of the HP82240B Simulator is normally fast enough to print the output of the calculators. For the case of the HP49G+ or HP50G with the USB interface, delivering data much faster, the HP82240B simulator got a 64KB input buffer, which should be large enough to print even larger RPL programs.

A recent version of Mikes oo82162A Printer Simulator has the ability to print barcodes on the HP82240B simulator over UDP. So as HP82162A simulator it interprets the barcode printing commands from the calculator and generating barcode graphic data send to the HP82240B. Barcode graphic produce a very large amount of data, in this case generated by a fast PC program and not by a dedicated slow hardware or hardware simulation of a calculator. In this case the output of oo82162A was faster than the drawing speed of the HP82240B and so the internal 64KB buffer overrun with the result of a data loss, because of no feedbeck channel to signal this overrun condition.

Just remember, we are taking about slow simulation, but the original HP88240B printer has a printing speed of 1.8s per line battery driven and 1.2s per line with external power supply which is much slower.

So back to HP82240B simulation, increasing the into buffer from 64KB to an higher size wouldn't help, because when you print larger programs, the barcode data size grows and so it's only a question of time when the data size is big enough to generate the next overflow. The only suitable way is to increase the drawing speed of the HP82240B simulation. With HP82240B v1.16 the display output is now faster then the data rate of the oo82162A Printer Simulator send by UDP.

The UDP protocol as interprocess communication between two programs was chosen, to simulate the one way behavior of sending IR data over the Redeye protocol. When you send data over infrared from a calculator, it depends if there's an infrared printer able to receive the data and print them. If there's no printer, the send data get lost without noticed by the transmitter. This is similar to the UDP protocol. A UDP transmitter client sends data to a UDP server without knowing if a server is running fetching the data.

A sent UDP packet has the overall size of the payload size + 20 bytes of IPv4 and UDP header. The normal payload size is 1 byte with the printing character, so 21 bytes are sent to transfer one data byte. The current HP82240B binary distribution only acept IPv4 UDP frames, IPv6 frames aren't supported which would have a 48 bytes IPv6 and UDP header. Compiling the sources with VS2005 or later, a IPv4/IPv6 dual stack server is enabled.

To test the transfer speed of the HP82240B simulation, I wrote a client program send data directly from disc to the UDP port byte per byte. The UDP Server inside the HP82240B simulation has a 16 (15 until v1.15) byte receive buffer which allows to receive UDP packes with max. 16 bytes payload.

Increasing the payload of each datagram reduces the protocol overhead for each data byte. With a payload of 6 bytes per UDP datagram the simulator is still faster at drawing the received data. With a payload of 7 up to 16 bytes the transfer is faster than drawing and the input buffer of now 128KB has to buffer the input data. I see this condition, when the client transmitter program is earlier finished then the printing program still prints data. So with sending only one byte of data in the UDP datagram, you're on the safe side that the drawing is faster than the data transfer.

Finally a drawing issue in the Graphic Window with a large data file with barcode graphic from above was fixed.