PC-BASIC incorrectly inserts CRLF in written file
A free, cross-platform emulator for GW-BASIC, PCjr & Tandy BASIC
Brought to you by:
robhagemans
Menu
▾
▴
I encountered a problem running one of my GW-BASIC programs, so I tried to track down the issue and found the cause of the problem: PC-BASIC will incorrectly insert CRLF in the middle of the written file if the total string length is greater than 255. Below is the very simple GW-BASIC program that will reproduce the problem in PC-BASIC:
10 A$=STRING$(128,"0")
20 OPEN "O",#1,"TEST.DAT":PRINT #1,A$;A$:CLOSE #1
After executing the program in PC-BASIC the TEST.DAT file will contain 128 zeroes followed by CRLF and then followed by another 128 zeroes. But CRLF will not be inserted if the program is executed by GW-BASIC, or if I change the number 128 in line 10 to any number smaller than it (e.g. 127). I consider this a bug in PC-BASIC and hope it will be fixed, thanks!
Thanks for your bug report and demonstration program! Since the behaviour is different from GW-BASIC it is indeed to be considered a bug. I'll try and track down the issue.
I believe this is fixed now in the git code. Please let me know if you find other bugs on file output (or indeed anything else).
Thanks for the fix. Indeed, I have found another bug on file output. If I try to write a character of ASCII code 8 to a file in PC-BASIC, not only it will not be written, but it will also delete the previous character. This would not occur in GW-BASIC. Below is a demo program to reproduce the problem in PC-BASIC:
10 A$="AB"+CHR$(8)
20 OPEN "O",#1,"TEST.DAT":PRINT #1,A$:CLOSE #1
After running the above program in PC-BASIC, the TEST.DAT file will only contain a single character "A", but it will contain "AB" as well as CHR$(8) when the program is run by GW-BASIC.
As for other problems, I have found issue with the PEEK command. For example, when running the following simple program in GW-BASIC, it will show "ALT pressed." when I press the ALT key. But it will show nothing in PC-BASIC when the ALT key is pressed:
10 DEF SEG=64:SR1=PEEK(23):DEF SEG:IF SR1<>SR2 THEN SR2=SR1:IF SR1 AND 8 THEN PRINT "ALT pressed."
20 I$=INKEY$:IF I$<>CHR$(27) THEN 10
OK, thanks, that's useful - do you have more programs that use various PEEK reads that would be worth emulating? I don't really have a good list of the most-used memory addresses for BASIC programs so I'm just implementing what ever I encounter in test programs.
Note that implementation of PEEK and POKE is only ever going to be very limited, if programs need a lot of machine access you really need a full machine emulator like DOSBox. But I do want to emulate the ones that are most used - for example, currently you can read the keyboard buffer with INP(&h60) as that's often used in games.
I don't really have a lot of programs that use PEEK or POKE, but I do have one which will calculate the value of PI to required number of decimal places, and this program certainly relies on the result of PEEK and POKE. I have uploaded the program (named CALCPI.BAS).
Hmm, it looks like that just uses the memory directly as storage - that can be made to work.
That's a brilliant piece of old-fashioned ugly BASIC hacking, by the way. This stuff isn't easy to find on the internet - I'm starting to wonder if it may be worth setting up a site where people can share their old BASIC programs...
The latest git version should treat chr$(8) correctly and be able to run CALCPI, though not yet your alt-key example. Cheers!
Thanks! The alt-key example is taken from the program made by myself previously called MEDIT.BAS, a simple text file editor. This program has a menu bar with menus such as "File", "Edit" and "Search". The user can use the Alt key (either alone or with key combination such as Alt+F) to access the menu. Besides the Alt key issue, I have found another (major display) issue when the program is ran by PC-BASIC, and by attempting to track down the issue I found the problem is related to the use of PRINT TAB(80);" " in line 130 and 200 of the program, but it won't occur in GW-BASIC. I have uploaded this MEDIT program.
Hi, thanks for your program! It appears there's an issue in PC-BASIC with scrolling when printing on line 25. I'll investigate further.
The latest version in git solves the display glitch and implements the &h40:&h17 memory address that you read for ALT. MEDIT now responds correctly, although for some reason it's dreadfully slow to respond to ALT, ESC or function keys (10s delay on my netbook). Not sure why.