| Re: [hatari-devel] Problem with printer output? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
Am Freitag, den 03.02.2012, 23:00 +0200 schrieb Eero Tamminen:
> Hi,
>
> On perjantai 03 helmikuu 2012, Matthias Arndt wrote:
> > > This works fine for TOS v1.00, v3.06, v4.04
> > > and EmuTOS.
> > >
> > > However, Hatari creates no printer output file
> > > when same test program is run within TOS versions
> > > v1.02 - v2.06.
> >
> > I can't remember on which TOSes I tested the output back then.
> > For the moment I cannot confirm v2.06. It works here for TOS v2.06 with
> > my standard Satandisk config.
> >
> > I only clicked on "Print" on the desktop for NEWDESK.INF
>
> Ah, that's a good test.
>
> If I use TOS "Print screen" option after running MINIMAL.PRG,
> then I get "printer-out" file, which grows very slowly, 4KB
> at the time.
>
>
> When looking at the code, printer.c has a minor issue
> compared to midi.c:
> * It buffers the output for 2kB which is flushed at every VBL
> and when Hatari is exited normally.
> * However, it doesn't tell C-library to disable buffering, so
> writes will be buffered also in the C-library, for whatever
> amount is the optimal size for the filesystem. In my case
> that's apparently 4kB.
>
> -> The code should either let C-library do the buffering
> (i.e. data will be flushed automatically at fclose(),
> or disable C-library buffering.
>
>
> And the init code is peculiar:
> ---------
> if (strlen(ConfigureParams.Printer.szPrintToFileName) <= 1)
> {
> const char *psHomeDir;
> psHomeDir = Paths_GetHatariHome();
>
> /* construct filename for printing.... */
> if (strlen(psHomeDir)+1+strlen(PRINTER_FILENAME) <
> sizeof(ConfigureParams.Printer.szPrintToFileName))
> ---------
>
> I.e. user can use a filename with one letter or one that's longer
> than home+hatari.prn. E.g. /tmp/print.out isn't tolerated.
The printer.c file is probably still of Winston heritage. I didn'T touch
it back then, only replaced some few lines to make it Unix and libc
compatible. Feel free to change anything to make it more compatible and
sane.
> However, these don't explain why the file isn't even opened with
> TOS versions v1.02 - v2.06.
>
> On assumption that they do some internal buffering, I replaced
> the TEXT file with Hatari's "video.c" (144kB), but that didn't
> help anything. There's still no printer-out file with TOS v2.
>
>
> Then I tried Gdb.
>
> In TOS v2, running MINIMAL.PRG didn't result in any
> Printer_TransferByteTo() calls, but "Print screen" did.
>
>
> On the listed working TOS versions, MINIMAL.PRG running results
> in Printer_TransferByteTo() calls though.
>
> When I printed in psg.c, the PORTA value, during the printing...
>
>[...]
>
> I.e. the bits 0x4 and 0x2 are being toggled, although the code checks
> for bit 0x20 being toggled:
> -------------
> if (ConfigureParams.Printer.bEnablePrinting)
> {
> /* Bit 5 - Centronics strobe? If STROBE is low and
> the LastStrobe was high,
> then print/transfer to the emulated
> Centronics port.
> */
> if (LastStrobe && (
> (PSGRegisters[PSG_REG_IO_PORTA]&(1<<5)) == 0 ))
> {
> /* Seems like we want to print something...
> */
> Printer_TransferByteTo(PSGRegisters[PSG_REG_IO_PORTB]);
> -------------
>
>
> [1] TOS Print screen gives same PORTA output as I get for Fwrites
> to PRN: in the working TOS versions.
>
>
> Any idea what's wrong?
Not really. Back then I simply asume as soon as the STROBE is set, a
byte needs to be send to the printer. If that is wrong, ofocurse the
whole thing was whacky from the first commit. I never claimed it was a
perfect 100% solution, just a hack, that worked for the time being.
BTW. I wanted to keep the handling really on I/O port level and not on
TOS software assumptions. TOS always only was one possible OS for the
Atari ST.
> - Eero
Matthias
--
Matthias Arndt <marndt@xxxxxxxxxxxxxx>
PGP-Key: http://www.final-memory.org/files/marndt.asc
Jabber: simonsunnyboy@xxxxxxxxxxxxxxxx