Extended BASIC G.E.M.

[Asmusr]

I see the .bin files.

[senior_falcon]

29 minutes ago, Asmusr said:

I see the .bin files.

I just looked using Windows 10 and the .bin files are there. For some reason my linux machine does not show them.

Thank you Sometimes for putting this collection of fonts together and for converting them to .bin

[senior_falcon]

Well, now that I am home, my Linux machine shows the .bin files just fine. I have no idea why it works now, but I suspect that it is some kind of level 8 error.

Edited January 17, 2020 by senior_falcon

[senior_falcon]

Making excellent progress on this project. Parts of The Missing Link are running in cartridge rom, which has freed up space in low memory for the five extra assembly subprograms GETPAT, DECHEX, GETPIX, GRAFIX and BITMAP that formerly had to be loaded into high memory and embedded in the XB program. These all seem to work but I want to do a lot of testing to be sure. There will also be CALL LINK("FONT",n) which will let you choose one of the fonts stored in rom into the TML character definitions. This will be added to XB256 and T40XB as well.

I will be working on one more major addition, which I believe is possible. That is to use the assembly loader from TI Basic's CALL LOAD in lieu of the GPL loader used by XB. This is about 20x faster. I do this in the compiler loader, but that is running from assembly. I need to figure out how to do this from GPL. One problem at a time....

[RXB]

Look at GPL SOURCE CODE of RXB CALL INIT that does it in one huge chunk with one GPL command, unlike XB that does it in 5 chunks in a loop.

That is why the XB version is slower.

That makes RXB CALL INIT  much faster and more efficient too.

[majestyx]

15 hours ago, senior_falcon said:

There will also be CALL LINK("FONT",n) which will let you choose one of the fonts stored in rom into the TML character definitions. This will be added to XB256 and T40XB as well.

 

If I am reading this right, choosing a font will be available in 40-column mode in T40XB. Or is it just in 32-column mode of T40XB? If so, this sounds great because I would like to use a different font than the only one that's available in 40-column mode.

 

[senior_falcon]

3 hours ago, majestyx said:

If I am reading this right, choosing a font will be available in 40-column mode in T40XB. Or is it just in 32-column mode of T40XB? If so, this sounds great because I would like to use a different font than the only one that's available in 40-column mode.

 

Yes, you will be able to choose any of the fonts stored in the ROMs. Many are too big to be useful in the T40 mode, but there will be more than one that will work for that mode.

[senior_falcon]

3 hours ago, RXB said:

Look at GPL SOURCE CODE of RXB CALL INIT that does it in one huge chunk with one GPL command, unlike XB that does it in 5 chunks in a loop.

That is why the XB version is slower.

That makes RXB CALL INIT  much faster and more efficient too.

???????????? 

XB uses one gpl instruction to move >600 bytes of code. I've cut that back to >04F4 bytes for a little extra speed.

But this makes virtually no difference. The problem that I hope to fix is the ultra slow XB assembly loader. The EA or MiniMemory one is about 20x faster.

[senior_falcon]

The collection of fonts that Sometimes provided has proven to be a treasurehouse. I was looking for complete fonts, with upper and lower case letters which eliminated many of the ones with just upper case characters. Some of the ones that remained were missing various punctuation marks, brackets, etc. and I filled in the blanks with generic characters taken from a couple of different fonts. The two fonts above were missing all the lower case characters and the picture above shows how they were completed. If someone feels like changing these fonts so the lower case letters were more like the upper case ones, I would include their revisions in the new cartridge.

I've included a zipped folder with these two fonts and an assembly subprogram that reads and saves fonts. To use it:

CALL INIT

CALL LOAD("DSK1.LOADSAVEFONT.OBJ")  (this only works in Classic99 and you have to check "enable long filenames"

then

CALL LINK("LDFONT","DSK1.0148.BIN") will load font 148

CALL LINK("SVFONT","DSK1.0148A.BIN") will save the font  (Append another letter so you don't overwrite the original font)

There is no error checking so any error goes unreported.  

FONTS2FIX.zip

Edited January 22, 2020 by senior_falcon

[+TheBF]

This makes me wonder if we could come up with a "standard" binary font file format that could be used by everyone in any language?

 

Can you tell us how your .bin files are organized?

Mine were just a simple VDP RAM dump of the pattern table starting at ASCII 0.

Currently I was only doing upper and lower case so >400 bytes, but of course it could be bigger for the extended characters.

 

But it begs the question, should there be a header data field with the size of the file ?

It might also need to know the first character that is being defined.

 

Or we could play it like the inventor of Forth said:  "Standards are great! Everybody should have one."

 

 

 

 

[senior_falcon]

36 minutes ago, TheBF said:

This makes me wonder if we could come up with a "standard" binary font file format that could be used by everyone in any language?

Can you tell us how your .bin files are organized?

Mine were just a simple VDP RAM dump of the pattern table starting at ASCII 0.

Currently I was only doing upper and lower case so >400 bytes, but of course it could be bigger for the extended characters.

But it begs the question, should there be a header data field with the size of the file ?

It might also need to know the first character that is being defined.

Or we could play it like the inventor of Forth said:  "Standards are great! Everybody should have one."

 

These routines copy or save VDP RAM dump from >0400 to >06FF which in XB is ASCII 32 to ASCII 127. I don't think there is a need for a header containing the size. If you set up the PAB to use a buffer with the maximum file size (for me this is >0300 bytes), if the file has only >0200 bytes that is what will be loaded.

[RXB]

On 1/20/2020 at 3:29 PM, senior_falcon said:

???????????? 

XB uses one gpl instruction to move >600 bytes of code. I've cut that back to >04F4 bytes for a little extra speed.

But this makes virtually no difference. The problem that I hope to fix is the ultra slow XB assembly loader. The EA or MiniMemory one is about 20x faster.

RXB has a command CALL BSAVE("DSK#.FILENAME") that SAVES a 8K file into lower 8K, so use CALL BLOAD("DSK#.FILENAME") for loading.

If you do a CALL INIT :: CALL LOAD("DSK#.AFILE2LOAD") :: CALL BSAVE("DSK#.FILENAME") 

This would Initialize lower 8K, load a file into lower 8K to use, lastly saves a 8K Program Image file of the lower 8K.

Thus CALL BLOAD("DSK#.FILENAME") would load that image much faster then norma XB.

 

A bonus is how I use this to load SAMS pages in my demos or using SAMS in my RXB game IN THE DARK

 

[+TheBF]

3 hours ago, senior_falcon said:

These routines copy or save VDP RAM dump from >0400 to >06FF which in XB is ASCII 32 to ASCII 127. I don't think there is a need for a header containing the size. If you set up the PAB to use a buffer with the maximum file size (for me this is >0300 bytes), if the file has only >0200 bytes that is what will be loaded.

I was thinking about a general file format for use beyond BASIC where you can redefine all 256 characters and the header would tell the loader program where to load the patterns. Without a header you have to know what is in the file before you write it to VDP RAM.

 

It's not that important of course since most of us are doing our own thing.

I was just curious if a "standard" font file could be created for TI-99.

 

 

 

[Tursi]

16 hours ago, senior_falcon said:

CALL LOAD("DSK1.LOADSAVEFONT.OBJ")  (this only works in Classic99 and you have to check "enable long filenames"

"Enable long filenames" only affects directory listings, you don't have to enable it to load files with long names. The reason is that many programs crash if they get a filename in a directory listing longer than 10 characters.

 

[senior_falcon]

3 hours ago, TheBF said:

I was thinking about a general file format for use beyond BASIC where you can redefine all 256 characters and the header would tell the loader program where to load the patterns. Without a header you have to know what is in the file before you write it to VDP RAM.

It's not that important of course since most of us are doing our own thing.

I was just curious if a "standard" font file could be created for TI-99.

 

Information could be included in the file name.  For example FONT207F would tell the loader to load starting at ASCII >20 and that it will go to ASCII >7F. An XB loader would know to put that starting at >0400. An assembly loader knows where the pattern table starts and could then determine where to start loading the characters.  FONT00FF would be contain all ASCII characters from >00 to >FF. An assembly loader could load that directly to the pattern table. An XB loader could not load that directly (you cannot start at ASCII >00 in XB plus there are too many bytes to load), so it could either reject it or else load to a buffer in VDP and move just ASCII >20 to >7F into the pattern table.

Using 4 characters for the ASCII values leaves only 6 more characters for the file name, but that should be workable.

Edited January 22, 2020 by senior_falcon

[+Vorticon]

Question Harry:

Can I compile an XB program which uses a small set of assembly routines for support via the standard CALL INIT/CALL LOAD/CALL LINK process? My guess is probably no as it will likely clobber up the compiler routines, but worth asking. Perhaps there is a protected space I could use?

[senior_falcon]

Sorry, but as you guessed, there is no provision for running assembly routines from compiled code. Although you could use CALL LOAD to load the programs in the usual location in low memory (although not from a running program), LINK is not supported.  Also the support utilities would have to be rewritten to provide NUMREF, NUMASG, STRREF, STRASG, etc.

[+Vorticon]

3 hours ago, senior_falcon said:

Sorry, but as you guessed, there is no provision for running assembly routines from compiled code. Although you could use CALL LOAD to load the programs in the usual location in low memory (although not from a running program), LINK is not supported.  Also the support utilities would have to be rewritten to provide NUMREF, NUMASG, STRREF, STRASG, etc.

Ah well... Thanks for the clarification.

[senior_falcon]

In thinking about this, I have come to believe that it might be possible. Most of the problems are tractable. LINK is pretty easy. Modifying NUMREF etc. does not seem too hard to me. One extra complication is that usually NUMREF is followed by CFI. That would have to be bypassed. NUMASG is usually preceeded by CIF, and that would have to be dealt with somehow. Another obstacle is the return to XB. In an assembly subroutine this is usually LWPI >83E0 and B @>006A and this would not return properly to the compiler.

My thinking at this time is that on startup the compiler could scan the assembly code looking for CFI, CIF, B @>006A and others and adjust the code so it functions properly. Of course, this has its own set of problems - those number sequences could be in character definitions or something else and you would not want to modify those. 

Still mulling it over and will be for some time.

[Tursi]

You might also consider - you don't need to be 100% compatible with the original XB LINK. You could force users to pass parameters via CALL LOAD instead, which would be a lot simpler to deal with than the hard coded addresses of the XB support code.

[senior_falcon]

9 minutes ago, Tursi said:

You might also consider - you don't need to be 100% compatible with the original XB LINK. You could force users to pass parameters via CALL LOAD instead, which would be a lot simpler to deal with than the hard coded addresses of the XB support code.

That works OK for numbers but strings are another story.

If this can be made to work, then The Missing Link, T40XB and others could be used with a compiled XB program.

[Tursi]

1 hour ago, senior_falcon said:

That works OK for numbers but strings are another story.

If this can be made to work, then The Missing Link, T40XB and others could be used with a compiled XB program.

The first statement I disagree with. But the second statement is good cause to pursue it!

 

[RXB]

2 hours ago, Tursi said:

The first statement I disagree with. But the second statement is good cause to pursue it!

 

Hmmm RXB has CALL MOVES that does exactly that.

Moves hex strings or strings to or from any memory to or from any String Variable.

To bad so much resistance to RXB, it has most of the solutions.

 

 

[senior_falcon]

19 minutes ago, RXB said:

Hmmm RXB has CALL MOVES that does exactly that.

Moves hex strings or strings to or from any memory to or from any String Variable.

To bad so much resistance to RXB, it has most of the solutions.

 

If I am running a compiled program (i.e. an XB program that has been converted to assembly language) exactly how would MOVES be of any use in transferring a string from the compiled program into an assembly language support subprogram?? 

[senior_falcon]

8 hours ago, senior_falcon said:

That works OK for numbers but strings are another story.

 

6 hours ago, Tursi said:

The first statement I disagree with. 

Just curious to know what part of the statement you disagree with.