|Re: Parallel port issue, was: Re: Tr: Re: [hatari-devel] Serial port issue with windowsHi,|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: Parallel port issue, was: Re: Tr: Re: [hatari-devel] Serial port issue with windowsHi,
- From: hwarin@xxxxxxx
- Date: Thu, 9 Apr 2015 11:23:02 +0200 (CEST)
- Authentication-results: sfrmc.priv.atos.fr; dkim=none (no signature); dkim-adsp=none (no policy) header.from=perot@xxxxxxxxxxxxxxx
- Message-context: email-message
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..
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.
A Ilúvatarinya! En ná pelecco cárinyesse.
hwarin@xxxxxxx hat am 8. April 2015 um 17:24 geschrieben:
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"