Re: [MiNT] lp driver patch for the Firebee to extend the parallel port strobe duration

[Alan Hourihane <alanh@fairlite.co.uk>]

On 04/10/15 07:45, Vincent Rivière wrote:
> On 03/10/2015 22:35, markus@mubf.de wrote:
>> please find attached a patch to MiNT's lp driver.
>
> Very good, this was the thing to do.
>
> However, a few remarks:
>
> 1) Your strobe_delay() routine takes the parameter from the stack, and
> cleans up the stack by itself. That's not the standard C convention,
> anyway it doesn't matter in assembler code. However, inside the
> routine, you immediately put the parameter into d0. It would have been
> more efficient to pass directly the parameter in d0, and document it
> in the function header. That would also get rid of the confusing stack
> usage.
>
> 2) FreeMiNT is compiled with gas (the GNU assembler). By design, gas
> doesn't automatically shorten the branches. This means that "bne" will
> always be 4 bytes, while "bne.s" would be 2 bytes only. Usually, the
> rule is: "use .s when possible". Ideally, the gas "jbne" macro should
> be used where possible, since it automatically choses the best branch
> size. Same with jbra, jbsr, etc. However such macros are currently
> never used in FreeMiNT, probably by design to avoid using too much gas
> specificities (which is a nonsense since the current code can' be
> compiled with anything else than gas, anyway).
>
> Of course, the 2 above points are not critical, since speed doesn't
> matter in this case. But as a general rule, it is good to avoid
> suboptimal or misleading code.
>
> 3) AFAIK, "lp" is just a spooler which creates the /dev/lp device.
> Even without it, it should always be possible to print through the
> /dev/centr BIOS device (or its /dev/prn alias). So patching the "lp"
> driver is good, but be sure that the BIOS device also works. IIRC,
> Roger recently patched EmuTOS for that.
>
> And to answer Alan's question:
>> Why can't this problem be entirely fixed within the FPGA and not resort
>> to these additional requirements ?
>
> Fixing the FPGA would slow down the transitions 1->0 and 0->1, but
> would not change the actual delay where the strobe line is hold at 0.
> Increasing the transition time would just be an undesired side effect.
> Increasing the delay in the code is the right thing to do. Using nops
> is not very good, but as Markus said that's acceptable in this case.
>
Right, but to repeat the question, I'm thinking of compatibility outside
of MiNT too, where applications are running under FireTOS, and for that
matter, possibly EmuTOS ?

Alan.