Re: [hatari-devel] Problem with printer output?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On torstai 09 helmikuu 2012, David Savinkoff wrote:
> On Wednesday 08 February 2012 13:55, Eero Tamminen wrote:
> > Either there shouldn't be buffering at all, like with midi.c,
> > or if it should be buffered, I would prefer relying on C-lib
> > and removing the manual buffered.  See the attached (non-tested)
> > patch.

I commited that as it seems to work fine.


> > I'm not sure what's the point in closing the printer file if
> > there hasn't been any printing for 4s.  Does anybody know why
> > it does that?
> 
> Thomas and I did a few things to the printer a few years ago.
> 
> I did not care for the buffering, but said nothing because:
> 1) It really didn't matter then.
> 2) The printer interface IS a printer emulator (with buffer).
> 
> I would prefer instant output like MIDI has.

I left the normal C-library FILE buffering still there, but
that's now trivial to disable, just call:
	setvbuf(fp, NULL, _IONBF, 0);


> Furthermore,
> the port could be improved to transmit data whenever
> the port is Addressed (non Centronics) in addition to
> Strobed (Centronics).

I'll leave that to somebody else. :-)


> > Does somebody have a real Atari machine with TOS v1.02 - v2.06
> > *and* a printer, and if yes, could you try whether booting with
> > the attached floppy disk contents[1] produces any printer output?
> > 
> > [1] which just has minimal.prg + small test text in auto/ folder.
> 
> I tested with TOS 2.06 UK and Hatari 1.6.1:
> 
> 1) I had to put TEXT into the AUTO folder with MINIMAL.PRG because
>     MINIMAL.PRG otherwise does not find TEXT.

When the program is run from AUTO-folder at boot, root directory
is the working one i.e. TEXT is found fine.  It needs to be in program
directory only when running the program directly from desktop.


> 2) The disk doesn't create a print file when booting. HOWEVER, the
>     print file IS created if I manually run MINIMAL.PRG
> 
> I think there is a conflict between real tos and patched bios/gemdos.
> Maybe some real tos variable is not as expected.

Hatari doesn't patch BIOS.  When using floppy image, GEMDOS isn't
patched either, so I think those cannot explain this issue.


I tried several of the failing TOS versions and with all of them,
printing fails when it's done from AUTO folder or from DESKTOP.INF,
but succeeds when it's done after TOS has fully booted up.

In both cases the GEMDOS and BIOS level calls were identical.


With TOS 1.00, printing with GEMDOS works also from floppy image
AUTO folder and with EmuTOS and TOS 3 & 4 it works also from
DESKTOP.INF (tested with GEMDOS emu).



> I don't have the appropriate real ST to test with.

Anybody?

The main thing to test is whether the test program prints anything
to printer when one boots ST (with TOS v1.02 - v2.06) and floppy
runs the minimal.prg from AUTO folder.

If it prints something, Hatari printer emulation is buggy
and needs to be fixed.

If it doesn't print anything, good, you saved paper and I need
to use something else than printing in Hatari TOS tester.

(Would be nice to know why things work differently from
DESKTOP.INF or from desktop after boot has finished though.)


	- Eero