Differences PCBasic to GWBasic for an user

[Anonymous]

Dear users of PCBasic

I was looking for a new way to use my old gwbasic 3.23 program files on my PC with Windows 7 instead of the complicated way with „Windows XP Mode“. I am living in Austria and therefore I am using a keyboard with central European character set. (Therefore also please forgive my bad English)

PCBasic seems to be a good choice but there are some differences which makes changes in gwbasic-programs necessary:

1) the path structure:

GWBasic can be run from a different path than the path of the program files

A batch-file as

cd d:
cd d:\Data\DatasetA
c:\utilitie\gwbasic d:\Data\ program.bas

starts GWBasic working in folder d:\Data\DatasetA with the .bas-program in folder d:\Data

PCBasic has to be run from the folder with its program-files otherwise you get the respond that some *.dll files are not found. So you can start PCBasic from the program-folder for example d:\pcbasic and then change to the subdirectory d:\pcbasic\Data\DatasetA with the
command lines : 10 chdir Data
20 chdir DatasetA

The much simpler command line 10 chdir Data\DatasetA doesn´t work in my system at least as there is no way to bring the \ into the command line with my keyboard. Even chr$(92) doesn´t work in any combination.

A command line as

30 open”D:\AAA\data.txt” for append as #1

after 10 and 20 as above automatically makes the respond “file not found” or “syntax error”

2) lprint and chr$(10)

In GWBasic the command line

40 lprint “ABCD”
50 lprint “”
60 lprint”abc”

Brings the result
ABCD

abc

to the LPT1.printer ant therefore on the paper.

In PCBasic it works different. First you have to set LPT1=printer: in the \pcbasic\info\pcbasic.ini file and then printing starts when you exit pcbasic and then it prints

ABCDabc

on the paper because the end of the command line lprint”ABCD” doesn´t automatically include CR, so you have to add lprint chr$(10) on each line.

3) lprint and character-set

In GWBasic

10 print “ÄÖÜ”
20 lprint “ÄÖÜ”

shows ÄÖÜ at the monitor and prints ÄÖÜ on the paper of the LPT1-printer

In PCBasic it shows ÄÖÜ on the monitor but strange symbols on the paper, even if you try to make changes in the \pcbasic\info\pcbasic.ini file line codepage

4) lprint and tab()

In GWBasic the command line

50 LPRINT TAB(15);B2;TAB(25);B3;TAB(34);B4;TAB(41);USING "######.##";B5-B6;B6: LPRINT CHR$(10)

prints string B2 on position TAB(15) and string B3 on position TAB(25) etc. If string B2 is longer so it automatically adds CR and starts in the next line on position TAB(25)

but in PCBasic it starts with string B2 on position TAB(15) and if string B2 is longer so it automatically starts at the next position TAB(34) so a chart (or table) looks totally different

5) EOF

In GWBasic the command lines

10 OPEN"text.dat" FOR APPEND AS #1
20 WRITE#1,DATE$,"a","b"
30 WRITE#1,DATE$,"A","b"
40 CLOSE#1

When running twice, it produces a file text.dat with the content

"12-12-2014","a","b"
"12-12-2014","A","b"
"12-12-2014","a","b"
"12-12-2014","A","b"
and here at the end of file is the EOF-Symbol

But in PCBasic it produces a file with the content

"12-12-2014","a","b"
"12-12-2014","A","B"
"12-12-2014","a","b"
"12-12-2014","A","B"
* means that at both places you will find the EOF-Symbol

So you can see the EOF-Symbol also in the middle of the file and this makes the file unusable for further calculations.

Problems 1) to 4) needs changes in the program lines but problem 5) makes the resulting files unusable and so PCBasic produces not useable results with my GWBasic programs.

So I am looking forward for any help,

Peter from Vienna, Austria

[Rob Hagemans]

Hi Peter, thank you very much for your careful bug report. This is very useful information.
5) Looks like a bug in PC-BASIC which is fairly easy to solve for the next release.
4) Can you please send me a program that prints a table showing this problem? From your description alone I can't solve it as I cannot print from GW-BASIC so it's not clear to me what the expected behaviour is.
3) What strange symbols do you see? Could you try printing to a file (set lpt1=FILE:filename) and send the result over to me, so I can analyse the issue.
Which codepage setting do you use for pcbasic and which codepage is set in Windows?
2) I can't reproduce this behaviour and LPRINT definitely sends chr$(13);chr$(10) at the end of the string. Not sure what causes your issue here. Can you print text files from Notepad correctly? Could you print to a text file and send the program and the result over?
1) There are several different issues here.
1a)Not being able to run from outside the directory is definitely undesirable; it works correctly in the source version so I wasn't aware of this. I'll have to look into whether and how it can be solved for the Windows executable.
1b) Not being able to type the backspace is strange, as Windows should send a backspace to PCBASIC when you press that key on your keyboard. Or does your keyboard not have a backspace key? What happens if you enter a backspace as you would in Windows? chr$(92) should definitely work as a replacement, so there is another issue here, probably 1c):
1c) By default pc-basic will map your current directory to "C:\" and not map anything else. If you want your drive letters the way Windows sees them, enable the map-drives option (it may be called windows-map-drives in your version). Try enabling this and see if it solves your problem.
1d) With the command that you give, is it File not found or Syntax error that you get? Which command produces which error message?

Thanks again for the report and please provide the additional information needed to solve 1)--4).

Rob

[Rob Hagemans]

As a workaround, if you need pcbasic to start in d:\dataset\data, run it with the mount option. E.g. as follows:
pcbasic.exe D:\data\program.bas --mount=C:D:\dataset\data or by setting mount=C:D:\dataset\data in PCBASIC.INI. PC-BASIC now maps the folder with your files to C:\ and makes it the current directory.

[Rob Hagemans]

I suspect (3) may be caused by Notepad not recognising the text to be printed as UTF-8 and instead using some other encoding; perhaps Latin-1. (I'm not sure because on my Windows installation Notepad interprets it correctly as UTF-8.)

If this is the case, instead of ÄÖÜ you would see six characters, the first, third and fifth being Ã. Is that what you see?

For the next release, I've added a byte-order mark to force Notepad to see UTF-8. That should fix this issue if this was indeed the cause.

[Rob Hagemans]

I cannot reproduce 1a); starting pc-basic from another folder works perfectly on my installation.

Could you let me know what version of PC-BASIC you are using?

[Anonymous]

Dear Rob

1) the path structure:

You are right, it was my fault

2) and 3) and 4) lprint and chr$(10) and character set and tab()

The program tabprint.bas produces daten.txt if in pcbasic.ini lpt1=file:daten.txt
But if lpt1=printer: in pcbasic.ini, my printer produces one long line with data, ignoring tab-commands and LF

Also you can see the strange symbols instead of ÄÖÜ

5) EOF
I am looking forward for the next release

Best wishes
Peter from Vienna, Austria

[Anonymous]

next attachment

[Anonymous]

next attachment

[Anonymous]

Sorry, not Data.txt but test.dat

[Anonymous]

More informations:
PCBasic release 3.23
Windows codepage (CHCP on DOS-Prompt) 850
PCBasic codepage in pcbasic.ini 850
Notepad works perfect and prints what you see on the monitor on the paper
Notepad print of Test.dat on the paper is ok but printing from pcbasic with lpt1=printer: produces P1010517.jpg as above
Thanks again,
Peter

[Rob Hagemans]

Hi, thanks; as for the version, it won't be displayed on the screen when you start; 3.23 is not the version number I mean (it just refers to the GW-BASIC version that's emulated). It should be something like PC-BASIC 3.23 release 14.xx.x with numbers for the x's. Either do pcbasic -v on the DOS prompt or open the file info\VERSION in the PC-BASIC folder to find it.

[Rob Hagemans]

Thanks, that is extremely useful information. The photo tells me that indeed what we're seeing is UTF-8 misinterpreted as another encoding. I think the change I made to include a UTF-8 byte order mark will solve this issue for you.

The missing newlines are strange, I can't reproduce them; but I made another fix for the next release that solved an issue with double newlines for someone else; I'd like to try and see if it also solves your missing newlines.

Have you opened TABPRINT.BAS and Test.dat in Notepad, by any chance? I'm asking because they are both encoded as Windows-1252, which isn't even supported by PC-BASIC. So the files as saved by PC-BASIC would be different. It may be that your web browser has changed the encoding when uploading the file, or my web browser when downloading it.

Similarly, I'm confused by Data.txt; it looks to me that it contains the text ÄÖÜ, but encoded in Codepage 437. This is the standard codepage for PC-BASIC and GW-BASIC; it would be the output if you did:

OPEN "data.txt" for OUTPUT AS 1 PRINT#1, "ÄÖÜ" CLOSE 1

in either GW-BASIC (at least the US version) or PC-BASIC without any codepage settings.

However, printing LPRINT "ÄÖÜ" with LPT1 redirected to a file should give a text file in UTF-8 encoding... How exactly did you produce this file?

Since the encoding of the files is all-important, could you re-send the text files and the program to me but all together as a ZIP-file? That would make sure that our browsers do not change the encoding. Also please make sure you do not edit the files in any other way between producing them with BASIC and sending them on: even if it looks the same in Notepad it may have changed the encoding.

Finally, could you please confirm the exact version of PC-BASIC you use. You can find it by executing pcbasic -v on the command line. Please give the exact string that is returned if you execute this; it will help me find the cause of the issue.

[Anonymous]

Hello, I am using PCBasic release 14.10.1 and attached the rar-file,
Peter

[Rob Hagemans]

Thanks! These are indeed in codepage 437 (or 850, in your case; it makes no difference for these characters).

[Anonymous]

Hello and sorry, but your suggestion is not correct. If you open the file TABPRINT.BAS extracted from basictest.rar with Word it will ask you which coding. Answering MS-DOS Western European (DOS) will bring you to my real input at the keyboard:
10 LPRINT"A"TAB(8)"vvv"TAB(15)
20 LPRINT"Ö"TAB(8)"1234567890"TAB(15)"abc"

So you can see that the first symbol in line 20 is an Ö but PCBasic changes the coding and lprint changes everything completely, TAB() cannot be used
Peter

[Rob Hagemans]

Peter,

MS-DOS Western European is the same as codepage 850.

[Anonymous]

and here the print to paper

[Rob Hagemans]

Please try the attached version which implements some bug fixes relating to printing on Windows. I hope this fixes the issues you encounter; let me know how it goes and I'll include the fixes in the next 'official' release.

[Anonymous]

Hello Rob,
your new pcbasic-peter doesn´t bring any development for me.
I still cannot put / on the screen with my german keyboard, what is possible in gwbasic.
lprint "ÄÖÜ" still produces strange symbols at the paper
open"file" for append as #1: print#", "DATA"
still produces confusion in the file #1, EOF-symbol is still in the old position, then comes "Data" in the next line and EOF in the last line again, see attachment as a picture from the screen when opening file#1 with Word.

I cannot understand your statement "MS-DOS Western European is the same as codepage 850." When I open an unformatted program.bas-ASCII-file with Word the program asks me in MS-DOS-mode or in Windows-mode, in both cases I can say Western Europe just with difference Western Europe(DOS) or Western Europe(Windows) the data on the screen looks different, only Western Europe(DOS) is correct.

Hope this helps and many thanks for your work and good luck,
Peter

[Rob Hagemans]

Apologies, I attached the wrong file. I've attached the correct one to this post.

Don't worry about the code pages, it's not important. Western Europe (DOS) should indeed be correct for the BAS file.

[Anonymous]

Hello, I can report some progress:
lprint"ÄÖÜ" brings ÄÖÜ on the paper
and
lprint"ÄÖÜ"
lprint"ABC"

brings
ÄÖÜ
ABC
on the paper so at the end of a lprint"DATA" line it includes CR or LF

but \ still doesn´t come from the keyboard to the monitor
and EOF still doesn´t work:
open"file" for append as #1: print#", "DATA"
the EOF-symbol is still in the old position, then comes "Data" in the next line then new, another empty line, and then EOF in the last line again, see attachment as a picture from the screen when opening file#1 with Word.

[Rob Hagemans]

It is strange that EOF doesn't work, because I could reproduce the bug, corrected the code and with the version I sent you it now works correct for me. Could you please double check whether it works if you write twice to a new file, so a file name that doesn't exist yet in the directory.

I'll think about the backslash issue, I misunderstood your earlier message and I thought that was solved. Where is the backslash located on your keyboard? Do other keys work correctly, in particular the Z and the Y? (I'm assuming you use a German keyboard, let me know if it's a different layout for Austria).

Also, out of curiosity, can you type the eszett into PC-BASIC?

[Anonymous]

Hello, print#1 works correct now as you can see in the file attached. But often I also use write#1, and this still makes problems.
All the keys of my keyboard work with PCBasic, indeed also ÄÖÜß, but for typing \ I have to press "ALT GR" and "ß" together, and this combination doesn´t work
Peter

[Rob Hagemans]

1) For the WRITE# issue, could you send me the whole program that produces the incorrect output, so that I can try for myself in GW-BASIC and PC-BASIC? It would help solve this more quickly; right now I don't quite understand what is going on there.

2) For the keyboard, can you type other keys that require AltGr, such as (I think) the square brackets [] ?

[Rob Hagemans]

I think I may know what is going on with the backslash. It appears that under Windows, the AltGr key sends the same scancode as right-Alt (of course the AltGr key usually takes the place of the right Alt, but they're functionally different keys.) Therefore PC-BASIC sees your backslash as Alt-Backslash, which has no meaning and is ignored.

That's an annoying situation; I have to think about what is the best solution. I'll probably have to create a new option to force the right Alt key to be seen as an AltGr key rather than an Alt key.