Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
|
Forum Index : Microcontroller and PC projects : Problem with binary I/O in MMBasic DOS
Author | Message | ||||
Mal_M Newbie Joined: 08/08/2011 Location: AustraliaPosts: 6 |
Firstly, a big thank you to Geoff for porting MMBasic to DOS. I thought I'd try using the DOS version to do some of my file I/O code development (as my target system is hooked up to a bunch of external hardware in the shed, and it's getting a little too cold here in Melbourne to work out there at night)... I am trying to use the following code to read from a binary file using v3.2C of MMBasic for DOS: ctr = 0;
do while not eof(#1) a = asc(input$(1,#1)) print a ctr = ctr + 1 loop However, when it reaches the hex value of 1A in the input file, it falsely triggers an EOF condition, and the loop terminates. If I delete the EOF test, I can read past the hex 1A value. But I still get an error (I get a byte sequence of 00 and 00 then the correct values in the remainder of the file). When I run the same code on MMBasic v3.2A on my UBW32, there is no error. So the problem seems to be specific to the DOS version. I know CTRL-Z (hex 1A) is EOF in some operating systems. I assume that is what is causing the problem here. I found a related problem when I ran the following test code posted by Geoff here on v32.C of MMBasic for DOS 10 OPEN "chartest.dat" FOR output AS #1
15 FOR i = 0 TO &HFF 20 PRINT #1, CHR$(i); 25 NEXT i 30 CLOSE #1 35 ' 40 OPEN "chartest.dat" FOR input AS #1 45 FOR i = 0 TO &HFF 50 IF ASC(INPUT$(1, #1)) <> i THEN ERROR 55 NEXT i 60 CLOSE #1 The above code writes a spurious hex 0D to the output file before the intended hex 0A. Similarly, when the above code throws an error when reading the file back in. Does anyone have a workaround for this? |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3194 |
Unfortunately this is caused by DOS and/or the I/O libraries used by the compiler. The core of the problem is that DOS treats CTRL-Z as EOF. I will have a look at it but I cannot set a deadline. The extra carriage return should be easier to fix. This is why writing for Windows (and even DOS) is such a pain... there are secret things going on inside the operating system that will trip you up. Geoff Geoff Graham - http://geoffg.net |
||||
Print this page |