Jump to content
senior_falcon

Extended BASIC G.E.M.

Recommended Posts

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

  • Like 1

Share this post


Link to post
Share on other sites

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 by senior_falcon
  • Like 1

Share this post


Link to post
Share on other sites

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....

  • Like 7

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

 

  • Like 1

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

FONTSTOFIX.thumb.JPG.f8cd99cc8c2eac15f0118cfd86575106.JPG

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 by senior_falcon
  • Like 3

Share this post


Link to post
Share on other sites

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." :)

 

 

 

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

 

Share this post


Link to post
Share on other sites
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.

 

 

 

Share this post


Link to post
Share on other sites
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. :)

 

  • Thanks 2

Share this post


Link to post
Share on other sites
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 by senior_falcon
  • Like 1

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...