I'll try to find out. It's a little difficult to pin-point the exact surplus data byte, one byte in a stream of graphics encoding bytes ... ;-)
hwarin@xxxxxxx hat am 9. April 2015 um 11:23 geschrieben:
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"
From that, I've been able to retrieve sources and got something compiled .. but I'm unable to link properly : "CMakeFiles\hatari.dir/objects.a(file.c.obj):file:(.text+0x2e1): undefined reference to 'gzopen'
.... If someone could help - feeling a bit stuck there.
Hervé
Tous vos emails en 1 clic avec l'application SFR Mail sur iPhone et Android - En savoir plus.
========================================
Message du : 06/04/2015 22:31
De : hwarin@xxxxxxx
A : "hatari-devel" <hatari-devel@xxxxxxxxxxxxxxxxxxx>
Copie à :
Sujet : Tr: Re: [hatari-devel] Serial port issue with windowsHi,
Hi, all
If this can help, we can manage a meeting and I can arrange a shared session to show my findings and the issue in details. I'm usually available on week days from 9 or 10 PM FT
Regards - Hervé
Tous vos emails en 1 clic avec l'application SFR Mail sur iPhone et Android - En savoir plus.
========================================
Message du : 06/04/2015 19:47
De : "Eero Tamminen " <oak@xxxxxxxxxxxxxx>
A : hatari-devel@xxxxxxxxxxxxxxxxxxx
Copie à :
Sujet : Re: [hatari-devel] Serial port issue with windowsHi,
Hi,
Is there anybody on the list who ows Windows setup and could take a look at
this?
- Eero
On sunnuntai 05 huhtikuu 2015, hwarin@xxxxxxx wrote:
> I'm very new at Hatari usage but I think I've put the finger over a "bug"
> on serial port handling on windows systems. I've understood that support
> of this very nice emulator is mostly done on "pingu-based" environment.
>
> I'm searching a good Atari emulator, running over windows (any version)
> and able to operate correctly with serial ports. I'm more experienced
> with Gemulator that I've been practicing since it's DOS version - but
> forget with that, I've just discovered Hatari and found that it suits
> all my needs except that I've been unable to have a proper serial
> communication on Windows. I was not so surprised as some posts there or
> there were warning about that it was not working ...
>
> In fact, after hours of searching, I think that I've pointed out the
> issue what seems to be only on the file selector ! I explain : When one
> goes to the F12 menu and goes to the device submenu, you have to browse
> to select a file, what is an incorrect solution for windows as you'll
> never find any serial port in this way (and defaults to
> %homedir%\/dev/modem ... notice the \ /). Any selection will cause an
> error at reboot (logged in STDERR) and RS232 is disabled.
>
> Then, I've went to the "hatari.cfg" for a little bit of hacking and I've
> finally found a setting that starts to work .. You need to have at least
> 2 physical serial ports, say COM1 and COM2. If you force usage of COM1:
> in szOutFileName nd COM2: in szInFileName, you have no more error at
> boot time and the emulation is about to work on serial port, sending
> data over COM1: and receiving data from COM2: .... that is far from
> perfect but could be usable ... if one byte over ten was not gardage.
>
> After that, I've tried to use direct device names (\\.\COM1) instead of
> COMx: but it failled ... with an interesting message from STDERR showing
> that the name used was not the name provided in "hatari.cfg", the dot
> was removed as a "\", resulting in an invalid name ....
>
> To sumarrize, there is
> - One problem with the "device setup" box that always add something as
> "%homedir%" - One problem with the parsing of hatari.cfg, removing dots
> and double \ [I would be able to setup something as \\.\COM1 or
> \\.\PIPE\VMWAREDEBUG or \\.\CNCA0] - One problem with the handling of
> characters transmitted (may be file openned/closed repeatedly) .... and I
> suspect the same issue for MIDI emulation
>
> I would be glad to help solving this - but unfortunately, I have no
> development environment allowing me to recompile and only very few
> programming skills. If someone is interested to work on the subject, I
> can make all possible testings and, with some guidance, setup a
> development environment on the subject.
>
> Regards - Hervé
>
>
>
>
> Tous vos emails en 1 clic avec l'application SFR Mail sur iPhone et
> Android - En savoir plus.