Okay here it goes, When at SCREEN 6 is loaded with an image, afterwards the ASCII table seems to be disrrupted (ALT 246 = ÷ )...
You can use this program and I'll give you any image as attachment:
10 CLEAR ,,,65535!: SCREEN 6
20 DEF SEG = &HB800
30 BLOAD "MOUNTAIN.PIC",0
40 WHILE INKEY$ = "": WEND
50 DEF SEG: SCREEN 0: END
I see no difference before and after. PRINT CHR$(246) prints ÷ in both cases, which is the character for that code point in codepage 437. What do you expect to see?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
...and what I see is that the character CHR$(222) is insted of any other character asked for in screen (except for kbd inputs). Since I can't used the options with the file: PCBASIC.INI, I use the above options in the Command Line. I thought you will be able to see it too. But, I'm guessing that it's only me, I'll assume that it's because of the way of the input of the options.
In any case, thank you for trying. :-) Until next.
Ronald.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sorry, I have no idea what you're trying to tell me. Are you sure you're no BLOADing the file into SCREEN 0? Because that would produce a lot of strange characters on the screen.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understand what your saying, but it isn't an incorrect screen. Actually the program that I paste you above can also trigger the error:
Windows 7 (64)
PCBASIC (with no PCBASIC,INI) and only with the command options above (please simulate it).
The above program that runs normally in SCREEN 6 and a normal ending.
In any screen, use PRINT CHR$(xxx) and will appear char. ASCII #222 (similar to 221, but is 222).
If after simulating the above configuration won't give you the error, I don't know what else will do or to say. It appears as I have provide the circumstances to reproduce the error, but is out of our hands. That will not stop me to test over things, thou.
Maybe is the way that I'm using the command line options, instead of the PCBASIC.INI file. And we know that if I use and alter the PCBASIC.INI it will crash with a red screen border, unable to do more test or using the platform. Good Luck at Godspeed. :-)
Your friend,
Ronald.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry - I've tried 15.08.4 on a 64-bit Win 7 VM with your settings on the command line, run your program and I still can't see anything strange. ? chr$(221) produces a left half-square, ?chr$(222) produces a right half-square and chr$(246) produces a division sign, just as I would expect...
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, here's what's going on: the BSAVE statement in L-SCAPES.BAS saves a block of memory that is larger than necessary. This includes the region where PC-BASIC (and GW-BASIC on IBM PC or Tandy machines) store the 8-bit font for characters with code points 128 and above. You don't see this if you BSAVE the picture in PC-BASIC because it will include the font in the right position in the saved file.
However, your example file MOUNTAIN.PIC was apparently saved on another kind of machine (was it a PCjr?). Presumably, these store thair font somewhere else; I wouldn't know where. So the area where the font is stored is overwritten with the data in that file, which is all &h1F in this case. As a consequence, the whole font is overwritten with that byte which leads to the white rectangles taking the place of characters 128 and above.
Not sure this can be solved, unless we know what the location for the font on a PCjr is.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Answering your question, it was done with GWBASIC (Tandy 3.2) on screen 6, I think. Maybe that's why the misplacement messing the font in memory. I tryied to use PCBASIC --preset=tandy option, but it do the same too. Since, I don't have a working PCjr, I either can't tell whats the length or the address that your looking for. I have observed that the BSAVE statement (in L-SCAPES as you metioned) is: 1390 BSAVE PIC$,0,&HB800 which I think, too, that (47,104b) is to large for an image for SCREEN 6, right? So, I used 32,768b an that should do the trick with enough space for the image.
So, thank you very much for letting me know how to work around with this thing. :-)
Ronald.
Last edit: Ronald Herrera 2016-03-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You may want to fix the ASCII table. See ya!
Ron.
Please, forget the above message... I'll report you later on what's going on. Thanks.
Ron.
Okay here it goes, When at SCREEN 6 is loaded with an image, afterwards the ASCII table seems to be disrrupted (ALT 246 = ÷ )...
You can use this program and I'll give you any image as attachment:
10 CLEAR ,,,65535!: SCREEN 6
20 DEF SEG = &HB800
30 BLOAD "MOUNTAIN.PIC",0
40 WHILE INKEY$ = "": WEND
50 DEF SEG: SCREEN 0: END
Ronald.
I see no difference before and after. PRINT CHR$(246) prints ÷ in both cases, which is the character for that code point in codepage 437. What do you expect to see?
Okay! I have the settings as default, with the default codepage except for the preset of these options:
--current-device=C
--preset=pcjr
--mount=C:C:\USERS\ALEKOR\MYDOS\DOSTEST\BASIC
--run=\PRIVADO\CHDIR4.BAS
--scaling=native
--max-reclen=255
...and what I see is that the character CHR$(222) is insted of any other character asked for in screen (except for kbd inputs). Since I can't used the options with the file: PCBASIC.INI, I use the above options in the Command Line. I thought you will be able to see it too. But, I'm guessing that it's only me, I'll assume that it's because of the way of the input of the options.
In any case, thank you for trying. :-) Until next.
Ronald.
I'm sorry, I have no idea what you're trying to tell me. Are you sure you're no BLOADing the file into SCREEN 0? Because that would produce a lot of strange characters on the screen.
I understand what your saying, but it isn't an incorrect screen. Actually the program that I paste you above can also trigger the error:
If after simulating the above configuration won't give you the error, I don't know what else will do or to say. It appears as I have provide the circumstances to reproduce the error, but is out of our hands. That will not stop me to test over things, thou.
Maybe is the way that I'm using the command line options, instead of the PCBASIC.INI file. And we know that if I use and alter the PCBASIC.INI it will crash with a red screen border, unable to do more test or using the platform. Good Luck at Godspeed. :-)
Your friend,
Ronald.
Sorry - I've tried 15.08.4 on a 64-bit Win 7 VM with your settings on the command line, run your program and I still can't see anything strange.
? chr$(221)produces a left half-square,?chr$(222)produces a right half-square andchr$(246)produces a division sign, just as I would expect...Rob
Ok, the key is in the actual BLOAD file. I used slightly a different one, apparently. I ca now see what you mean.
OK, here's what's going on: the
BSAVEstatement inL-SCAPES.BASsaves a block of memory that is larger than necessary. This includes the region where PC-BASIC (and GW-BASIC on IBM PC or Tandy machines) store the 8-bit font for characters with code points 128 and above. You don't see this if youBSAVEthe picture in PC-BASIC because it will include the font in the right position in the saved file.However, your example file
MOUNTAIN.PICwas apparently saved on another kind of machine (was it a PCjr?). Presumably, these store thair font somewhere else; I wouldn't know where. So the area where the font is stored is overwritten with the data in that file, which is all&h1Fin this case. As a consequence, the whole font is overwritten with that byte which leads to the white rectangles taking the place of characters 128 and above.Not sure this can be solved, unless we know what the location for the font on a PCjr is.
Answering your question, it was done with GWBASIC (Tandy 3.2) on screen 6, I think. Maybe that's why the misplacement messing the font in memory. I tryied to use PCBASIC --preset=tandy option, but it do the same too. Since, I don't have a working PCjr, I either can't tell whats the length or the address that your looking for. I have observed that the BSAVE statement (in L-SCAPES as you metioned) is: 1390 BSAVE PIC$,0,&HB800 which I think, too, that (47,104b) is to large for an image for SCREEN 6, right? So, I used 32,768b an that should do the trick with enough space for the image.
So, thank you very much for letting me know how to work around with this thing. :-)
Ronald.
Last edit: Ronald Herrera 2016-03-10