XBSDUMP - XB Screen capture

[Bones-69]

I am a big fan of Magellan and pretty much everything I do these days starts of with a Magellan screen. As I am sure everyone knows, Magellan will export the screen to XB. When it does this it uses a draw method to put each of the 768 characters in its place one at a time (pretty slow). Each of the 768 characters are exported by their ASCII value. The amount of data required to define a full screen is therefore anywhere between 1,536 bytes and 2,304 bytes depending on the mix of character values.

 

For some time I have been using Magellan to draw a screen then attaching a little program to scan the screen and turn it into actual characters which were saved to disk. So it basically took screen data originally drawn by;

DATA 33,33,65,33 and turned it into DATA "!!A!". To draw a screen I would use DISPLAY AT and then fill in the blanks for column positions 1,2,31 & 32 with the same type of data (consisting of 96 characters), but using CALL HCHAR here.

 

Excited by the XB compiler I realised I can not use this method to get a screen from Magellan into the XB Compiler due to it not currently supporting disk files. The problem didn't seem difficult to overcome because I was happy to copy/paste this data into a text editor and get it sorted from there (I just can't go back to programming complicated screens with endless call HCHAR/VCHAR statements only to spend hours trying to get it right, I just won't!). So when I started to copy/paste my data from the disc files across to Notepad (using Ti99Dir) in order to prepare it for copying into a program to be XB Compiled, I realised that it was corrupting all characters from 127 onwards. If I wrote a file which contained character 128 and above it would bring it over to my text editor as character 46 and my data was lost.

 

In order to overcome this problem I wrote a program I have named XBSDUMP. It will scan the screen and remove any character under 32 and over 128 (and also character 33, the quote). These excluded characters are put into a string/s for writing to the screen with an additional process. Initially I decided that each excluded character would need to take up to 7 bytes to in order to be redrawn (2 for the row, 2 for the column and up to 3 for the actual character being excluded). When I started to work this it became apparent pretty quick it was not beneficial. If for example there were 200 excluded characters found in a single screen then it would take up to 1,400 additional bytes just to record this additional data, potentially there exists the opportunity for the entire screen to be filled with exempt characters so I needed something a little better.

 

To get around the problem I shifted characters above 126 ASCII down in value by 33 and saved the character this reflected instead. Character 127 became 94, character 159 became character 126 - these are characters which can be copied/pasted with no problems. At the other end of the scale for characters 0-31 (and character 34), these were shifted up 43 positions so again they could be accurately preserved. For ROW/COLUMN, a value of 1 is represented by character 78 through to 32 which is represented by character 109. This results in data which rather than looking like DATA 10,22,134 now becomes DATA "Wc=". So I was at least able to store 3 values into the space occupied by no more than 3 bytes.

 

The reason for the explanation is that while the program works in every instance I have tested, Screen shots with a lot of excluded characters will result in larger files, which may or may not be a issue. For each additional excluded character in any screen there are 3 additional bytes of programming space that will be taken. In a native XB environment this will also add additional processing time drawing the extra characters, but once compiled it becomes very smooth and depending on the screen, somewhat instant.

 

How to use.

 

-This program was designed with Magellan in mind. To use with Magellan, copy/paste the program into the exported Magellan XB program.

-To capture any screen, either import into the current program or execute a RUN "DSK1.XBSDUMP" once the screen you wish to capture is displayed (it can also be run at the prompt). Originally I had planned for this program to be smaller so MERGING into any program wouldn't be much of a concern but it quickly grew to a few hundred lines of program so in many instances RUN "DSK1.XBSDUMP" will be the best option if memory is getting tight (The program itself uses almost nothing to run).

-Once the screen has been processed a file is created with the name you choose. In this file are two programs which can then be viewed/copied with Ti99Dir and then pasted into Classic99. These programs and are ready to be XB compiled and contain no illegal Syntax. OR - the results can be pasted to a text editor without corrupting those problem characters.

 

User settings

Because this program processes the screen it is presented with, all user setting can be found in lines 8009 - 8018 (The default setting for these values are listed in line 8008).

 

LN = Program line number start

 

LI = Program number Increment

 

DLN = Data line start (LI is used for data line increment)

 

SPE = This value will allow you to choose is character 31 should be reproduced as character 31 (more programming space/data required), or if it can be recorded as character 32 which saves programming space.

 

LM = Magellan line number for CALL SCREEN data. Only useful if merging into Magellan exported program. For a 24x32 exported Magellan XB program using defaults, this line number is 900.

 

CDR = Choose if character definitions are required in exported program/s.

 

WC = Gives the option to reduce programming space by shrinking char characters down where possible. ie- "00FF0000000000" is recorded as "00FF". This setting is only applicable for the Program #1 in the exported file. Program #2 defaults to sprite style character definition to assist with speed under XB only conditions.

 

EC$ = In Magellan, characters which are simply blaked out are not exported as "0000000000000000" but rather they are skipped. So if you want to display a CALL MAGNIFY(3) Sprite, and any of the 4 characters are supposed to be blank, the Magellan data will not cater for this and they will remain pre-defined. I get around this problem by specifically defining a blank sprite as a chosen character. Then using a CALL CHARPAT command I can search for such characters and have them correctly defined as a blank character. If this function is to be used then set EC$ to a character of your choosing and if discovered it will be defined as blank. I personally tag my blank characters with this little guy "3C5ADBFF18244281".

 

D = Disk drive number for output files (There will be two files, one contains two programs which can be copied/pasted, the second with extension "-S" is a scratchpad and also contains formats of data which may be useful).

 

FN$ = File name

 

* Please note I have not included any error checking. If any of the above values have not been correctly set then the program will crash or may give unexpected results.

 

* Any character between 0-159 will be displayed to screen if found, however character under 32 and over 143 will not be hex defined. The characters go up to 159 to support RXB users, although this shouldn't be required as RXB users have file access plus some additional commands which largely obsolete this program.

 

* It takes a long time to complete a screen scan. I haven't timed it but guess it is probably 15 minutes. Much better to run in CPU overdrive....

Edited January 29, 2013 by Bones-69

[Bones-69]

Program is attached. Look forward to if anyone finds it useful. Now I can get on with some cool compiling.

 

Edit - Sorry to anyone who downloaded, I had some old stuff in there I didn't tidy up. Attached is the corrected file.

XBSDUMP.zip

Edited January 29, 2013 by Bones-69

[sometimes99er]

So it basically took screen data originally drawn by;

DATA 33,33,65,33 and turned it into DATA "!!A!".

 

First I thought about expanding Magellan to do more or less what you do, of course in a split second, or output in a MERGE format (TIFILES) to maybe allow a bigger character range, or at least skip/shorten the wait while pasting.

 

But then, - isn't it so, that Wilhelm's compiler is actually quite happy with DATA 33,33,65,33, both keeping it compressed and fast (in the compiled version) ?

[senior_falcon]

It sounds like the screen you are trying to save is in XB. If so there is a much easier way to accomplish this task. You can use "VREAD" in C-XTRAS to read the screen, then create a MERGE format disk file containing the strings created by VREAD. Merge the program lines into your XB program and you're done!

 

To load C-XTRAS type CALL INIT, then CALL LOAD("DSK1.C-XTRAS")

 

Here's one way to write the program:

10010 OPEN #1:"DSK3.MTEST",DISPLAY,VARIABLE 163,OUTPUT

10020 FOR I=0 TO 5::CALL LINK("VREAD",I*128,128,A$)

10025 LNG$=STR$(I*128)

10030 L$=CHR$(40)&CHR$(I)&CHR$(147)&CHR$(200)&CHR$(LEN(LNG$))&LNG$&CHR$(179)&CHR$(199)&CHR$(128)&A$&CHR$(0)

10040 PRINT #1:L$::NEXT I

10050 A$=CHR$(255)&CHR$(255)::PRINT #1:A$::PRINT #1:A$::CLOSE #1

 

(This is copied from the screen in Classic 99 - I checked, but there could be typos!)

 

You could save this in MERGE format, then merge it into your program and have your program go to 10010. This program creates a merge format disk file with 6 entries as follows:

10240 DATA 0,string with a length of 128

10241 DATA 128,string with a length of 128

and so on...

 

Merge this into the XB progam that you're writing, then you can set the screen with a simple line of code: 100 FOR I=1 TO 6::READ VADR,SCRN$::CALL LINK("VWRITE",VADR,SCRN$)::NEXT I

 

Here's what's contained in L$ created in line 10030:

CHR$(40)&CHR$(I) = line number (40*256+I)

CHR$(147) = token for DATA

CHR$(200) = token for ????

Length byte and string for VDP address

CHR$(179) = token for comma

CHR$(199) = token for string constant

CHR$(128) = length byte for string

128 byte string read from VDP

CHR$(0) = end of program line

 

The XB line editor is happy to display the lines containing these strings, but will squawk if you try to edit them.

 

In the compiler docs is a list of VDP addresses for things such as sprite table, pattern definitions, color table, etc.

 

If you want to explore creating merge format lines, you can write a simple one line progam and save it in merge format, then read it with an XB program and see what bytes are in the line.

[sometimes99er]

Thanks Harry (senior_falcon), very beautiful.

 

Magellan could easily output the above MERGE file. Maybe with options to set screen start and end positions (for grabbing screen effects), and lineno. to start with in the MERGE output file (easily merging many chunks). I guess some effects (splashes) can be done with DISPLAY AT instead of VWRITE, you wouldn't need to load C-XTRAS, and in fact making this usable for plain old XB (besides Harry's compiler).

 

Yet another distraction. I'm looking into it (Magellan). Filip (retroclouds), I'll contact you when I run into problems.

Edited January 31, 2013 by sometimes99er

[Tursi]

(This is copied from the screen in Classic 99 - I checked, but there could be typos!)

 

(just a little OT to save you some time: next time you can try: LIST "CLIP", then paste directly )

 

[senior_falcon]

Thanks Tursi - that sure makes it easy. One of these days I'm gonna RTFM!

[sometimes99er]

I am a big fan of Magellan and pretty much everything I do these days starts of with a Magellan screen. As I am sure everyone knows, Magellan will export the screen to XB. When it does this it uses a draw method to put each of the 768 characters in its place one at a time (pretty slow).

 

If you haven’t noticed, then the latest version of Magellan (link here) will export the screen in a XB MERGE friendly TIFILES file format. There’s a 28 column output for direct use with DISPLAY AT. And there’s a full 32 column output for use with Wilhelm’s Compiler, C-XTRAS’ VWRITE. Both will take characters out of normal range (so don't try and edit the resulting DATA statements).