Re: Parallel port issue, was: Re: Tr: Re: [hatari-devel] Serial port issue with windowsHi,

[hwarin@xxxxxxx]

Hi ,

 

I've not yet went to parallel port support but I promise I'll get a look once I'll have a development environment correctly operational and corrected my issues on serial. From your findings on "extra bytes", was it random bytes, duplicates bytes or fixed ones ? (for serial, I've noticed duplicated bytes and another issue, may be on timing or file repeatedly opening/closing..

 

Hervé





Tous vos emails en 1 clic avec l'application SFR Mail sur iPhone et Android - En savoir plus.


========================================

Message du : 08/04/2015 23:59
De : "perot@xxxxxxxxxxxxxxx " <perot@xxxxxxxxxxxxxxx>
A : hatari-devel@xxxxxxxxxxxxxxxxxxx
Copie à : 
Sujet : Parallel port issue, was: Re: Tr: Re: [hatari-devel] Serial port issue with windowsHi,




  

Incidentally, the parallel port has issues too (at least on Windows): Sometimes an extra random byte appears in the output. I have not had any time to look into the code, but I thought I might report it anyway. 

  

What I did: I was trying to extract my diploma thesis, which I wrote (like probably thousands of people in Germany at the time) with Signum2. I am not aware of any other software that could read Signum's format. So my solution would have been to print it within Hatari, and code a little ESC/P 24 needle matrix printer emulator that would accept Hatari's output print file and render it into a series of PNG graphics files. My program worked right away, except for a glitch that in every other thesis line the graphics (Signum printed everything as graphics like all modern word processors - it was probably the first of this kind) would be garbled. Naturally I assumed a bug my code, however a close inspection of the input data (as written by Hatari) revealed that in fact there were extra bytes in the data stream, maybe one extra in a kB. When I removed a byte in one compromised place the output turned good there. Signum at fault here is extremely unlikely, as such a bug would have rendered it more or less useless at the time. 

  

If anyone is interested and wants to look into the issue I can provide test data. 



Cheers  Peter 

--------------------------- 
A Ilúvatarinya! En ná pelecco cárinyesse. 

hwarin@xxxxxxx hat am 8. April 2015 um 17:24 geschrieben: 


Hi,

I've identified several issues for Windows environment that are easily fixable :

Bug  : Default value for serial/midi
==> Lines 525/535 of "configuration.c" : Default values as %HomeDir%/Dev/Modem ....
==> File_MakeAbsoluteSpecialName() lines 702/706 ==> File.c

Bug : Impossible to select a Win32 device
==> Lignes 675++ of File.c
==> File_MakeAbsoluteName() does not work in AmigaOS - It does not work for special devices on Windows also
==> See google "win32 device namespace" - Might work as is with \GLOBAL??\COMn style or \Device\Serialn style instead of \\.\COMn.
==> Confirmed to work with simple COMn: (with n<=9) style with whatever path before as this is a special DOS reserved filename

Bug : Impossible to select any option from command line except -W or -D (even -h/--help makes nothing)

 

I've then decided to try to fix this myself and to setup a dev environment .... So far, what I did (on Windows 7)

- Setup "Win-Builds 1.5.0" (includes MinGW, SDL, and numerous other libraries)
- Setup "CMAKE-3.2.1"
- Setup "Python-3.4.3"
- Setup "Zlib128" (as I was unable to make it work from Win-Builds"
- Setup "Tortoisehg-3.3.3"