Jump to content
Opry99er

Bitmap image conversions

Recommended Posts

ah thanks, will try soon.

 

-

 

I am not sure but I think the SD itself is inaccessible from the TI-side as there is no DSR (?)

Share this post


Link to post
Share on other sites

Bugfix update posted today -- the F18A palette and scanline palette files were saving the palette in the wrong order, meaning viewers wouldn't load them correctly. This has probably been the case for quite a while.

 

I don't think anyone was using those modes except me, so if you have any saved off, I recommend reconverting. If you have a lot of them or can't reconvert, contact me. I wrote a little tool to fix up my own collection. It's hacky but it works, assuming you have the files on a PC.

 

Convert9918 v 166

•improvement to quality of ordered dither 1 - far less color shift

•more minor speedups

•fix order of palette output for F18A - to fix old files, remove index 2 and insert at index 14

 

http://harmlesslion.com/software/convert9918

  • Like 2

Share this post


Link to post
Share on other sites

Posted version 168 of Convert9918 today -- lots of tweaks over the last couple of years, but the big changes are all the ordered dithering modes (which are being tested against the world over in the Dragon's Lair thread ;) ). Also an important fix to deal with Windows screen scaling... now that I have a higher resolution monitor, it started to matter. The GUI should draw much more correctly regardless of a monitor's scale setting.

 

I dunno what happened to 167, maybe I didn't announce it ;)

 

http://www.harmlesslion.com/software/convert9918

  • Like 4

Share this post


Link to post
Share on other sites
On 2/18/2011 at 9:26 AM, Tursi said:

Forgive me for not getting this all to production quality before going to bed, but it's 6:30am and I do have stuff to do in the daylight if I can! ;)

 

XBTEST.zip 8.17 kB · 37 downloads

 

Drop this bad boy into Classic99, load and run through Extended BASIC. Press "Enter" to exit.

 

I'd like to know if it works on other emulators/real machines - and most importantly, whether disk access works on them after the program exits. (ie: just try to OLD another program). I did a little code to take disk into account but haven't tested it yet.

 

I tested that it chains successfully in Classic99 but it made a bad demonstration, so I changed the RUN "DSK1.TEST2" to a PRINT "SUCCESS".

 

More to come after sleep.

Has anything changed in Classic99 since this (now nearly 9 year old program) was added? I ask because when I run it in Classic99 QI399.013 using the TI Extended BASIC cartridge, after pressing ENTER, it locks up the emulator with the following screen:

 

image.thumb.png.327b4813746ce15b7d6a73599d71d41b.png

 

The reason I ask is because I'm wanting to add an opening title screen to my latest project and am trying to figure out how to accomplish this using XB... well, senior_falcon's T40XB.

 

EDIT: I was able to get it to work with the latest version of the Convert9918 Tool and a picture I wanted to use, but it looks like the resulting program messes with where T40XB is stored, as I was kind of thinking might happen. It's okay - my title screen wasn't very exciting anyway!

Edited by majestyx
  • Sad 1

Share this post


Link to post
Share on other sites

You should be able to do this. The LOAD program should be the title screen using Tursi's program. After displaying the picture the program should RUN "DSK1.T40XB". T40XB should RUN "DSK1.YOURMENU" or whatever the first part of your program is.

In XB 2.8 G.E.M. I hope to have the subprograms CALL TML, CALL T40XB, and CALL T40XB so you can activate any of these from within an XB program. This would have to be followed immediately by RUN, RUN line number, or RUN "DSK1.PROGRAM" to get the XB pointers set properly. I think this will work, but won't know until I test it out.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Yeah, no guarantee my code will work anywhere but stock Extended BASIC - it's not very smart about how it abuses VDP RAM.

 

Share this post


Link to post
Share on other sites
19 hours ago, senior_falcon said:

You should be able to do this. The LOAD program should be the title screen using Tursi's program. After displaying the picture the program should RUN "DSK1.T40XB". T40XB should RUN "DSK1.YOURMENU" or whatever the first part of your program is.

In XB 2.8 G.E.M. I hope to have the subprograms CALL TML, CALL T40XB, and CALL T40XB so you can activate any of these from within an XB program. This would have to be followed immediately by RUN, RUN line number, or RUN "DSK1.PROGRAM" to get the XB pointers set properly. I think this will work, but won't know until I test it out.

I tried it using option 2 (Extended BASIC+). It loads the picture, then loads T40XB. When T40XB loads my program, my program ends with SUBPROGRAM NOT FOUND IN 20.

 

20 GOSUB 2000::CALL LINK("T40")::CALL LINK("COLOR",16,2)

 

The screen is now cyan instead of the grey it would normally be when running T40XB from disk. When I list it, there are garbage characters in place of lowercase letters.

 

Here is one of the garbage lines:

image.thumb.png.2ec0be73caa939941e8b910578903f8a.png

 

And here is the actual code:

 

100 CHO=2::CHO$(1)="Letters"::CHO$(2)="A story"::MXL=7::GOSUB 2300

 

I appreciate your input. It's not a big deal if I can't get it working. I tried converting an image using Tursi's conversion tool, but it didn't turn out looking very good (limits of the TI's color & resolution) so I'll likely skip it.

 

Share this post


Link to post
Share on other sites

Myarc Extended Basic seemed to allow one to load some graphics around if I recall, and I know Geneve Advanced Basic had a lot more options if you are looking for something just for yourself.  If for others, then probably not the route.

 

I would think with a FinalGrom, you could store the graphics in memory pages and with an assembly routine, call and move the display data around avoiding disk drive calls.  That may give you some more memory space to use within extended basic.

 

Beery

 

 

 

Share this post


Link to post
Share on other sites
4 hours ago, majestyx said:

I tried it using option 2 (Extended BASIC+). It loads the picture, then loads T40XB. When T40XB loads my program, my program ends with SUBPROGRAM NOT FOUND IN 20.

20 GOSUB 2000::CALL LINK("T40")::CALL LINK("COLOR",16,2)

The screen is now cyan instead of the grey it would normally be when running T40XB from disk. When I list it, there are garbage characters in place of lowercase letters.

 

I'm guessing that your program does a CALL INIT. That would make T40 unavailable, plus in XB+ CALL INIT turns off the interrupt at >83C4. Without the interrupt the color reverts to cyan.

The characters will be garbled by the bit mapped title screen. I will have to test a little to see what happens when the bit mapped title screen runs another program and then another. But XB should reset the character definitions when the program breaks. I will look into this.

 

  • Like 1

Share this post


Link to post
Share on other sites

I did some testing and found that it is possible to load a picture, then press enter to go past the picture to load and run T40XB and from there run a simple program using T40XB. Everything works as expected, except the lower case letters are not reset. Somehow this is caused by Tursi's bit mapped picture loader. When you just use that and return directly to XB the same problem exists. I do not yet understand why this happens. Normally when an error occurs or a program ends all the characters from 32 to 127 are reset. After Tursi's picture loader runs only the characters from 32 to 95 are reset. 

We'll figure this out...

 

Share this post


Link to post
Share on other sites

I have been using Vorticon's Stratego title screen for my testing. As Tursi notes, there is a lot of erratic behavior when returning to XB. I always thought that when you RUN a program all the important memory locations are reset to the proper values, but evidently that is not the case. 

@ Tursi: There are two things you can try that might tame this beast.

1 - Don't do anything that modifies the scratchpad. It looks like most of low memory is available, so put your workspace there as well as any temporary variables.

2 - Copy the XB system area from v0370 to v03EF into a buffer in low memory. Restore this memory area when returning to XB

3 - Return to XB with LWPI >83E0 then B @>006A (I'm sure you know this)

No guarantees....

(Edit) Another thing that would be nice would be to set the screen to >80, clear the pattern for asc 80, set the colors for ascii 80 to black on cyan and set the screen color to cyan. This should get rid of the colorful screen that exists when running an XB program from the loader.

(Edit2) The VDP registers are reset properly, but it looks like nothing in the VDP ram is being returned to the default XB values. If low memory is available, you could just copy vdp ram from >0000 to >0A00 to low memory, then restore it when returning to XB.

Edited by senior_falcon

Share this post


Link to post
Share on other sites
2 hours ago, senior_falcon said:

I have been using Vorticon's Stratego title screen for my testing. As Tursi notes, there is a lot of erratic behavior when returning to XB. I always thought that when you RUN a program all the important memory locations are reset to the proper values, but evidently that is not the case. 

@ Tursi: There are two things you can try that might tame this beast.

1 - Don't do anything that modifies the scratchpad. It looks like most of low memory is available, so put your workspace there as well as any temporary variables.

2 - Copy the XB system area from v0370 to v03EF into a buffer in low memory. Restore this memory area when returning to XB

3 - Return to XB with LWPI >83E0 then B @>006A (I'm sure you know this)

No guarantees....

(Edit) Another thing that would be nice would be to set the screen to >80, clear the pattern for asc 80, set the colors for ascii 80 to black on cyan and set the screen color to cyan. This should get rid of the colorful screen that exists when running an XB program from the loader.

(Edit2) The VDP registers are reset properly, but it looks like nothing in the VDP ram is being returned to the default XB values. If low memory is available, you could just copy vdp ram from >0000 to >0A00 to low memory, then restore it when returning to XB.

I won't be able to do anything for the next couple of weeks, but I fully documented exactly what this does in the Convert9918A documentation (that is the tool that creates these programs). There are three text files inside the "examples.zip" which is in turn in the Convert9918.zip:

 

XB_Bitmap.a99.txt is the source code for the assembly portion

XB_Bitmap_Notes.txt describes what it does in detail (or at least what it's supposed to be doing ;) )

XB_Program.txt is just a listing of the XB side of it.

 

http://harmlesslion.com/software/convert9918

 

It was never meant as more than a quick hack for a title screen in front of an XB program, but if it's possible to make it cleaner, I'm game. ;)

 

  • Like 2

Share this post


Link to post
Share on other sites
15 hours ago, senior_falcon said:

I'm guessing that your program does a CALL INIT. That would make T40 unavailable, plus in XB+ CALL INIT turns off the interrupt at >83C4. Without the interrupt the color reverts to cyan.

The characters will be garbled by the bit mapped title screen. I will have to test a little to see what happens when the bit mapped title screen runs another program and then another. But XB should reset the character definitions when the program breaks. I will look into this.

 

No CALL INIT anywhere in the program. It stops at line 20. There is only one line before it:

 

10 DIM EQU$(10),CLU(26),DED(25),CHO$(4)

 

I was just looking for a simple way to add a little flash/polish to the game and thought this picture loader would be an easy way to do so. I'll concentrate on the rest of the game and will worry about adding some flash, if at all, once it's completed. I was aiming for something like RETURN TO PIRATE'S ISLE, with some pictures near the top of the screen, or maybe even just a picture loaded here and there. Since I'm using XB+ and with 40 columns, I'm guessing this might be tough to do.

Share this post


Link to post
Share on other sites

The picture loader leaves XB in a somewhat unstable state. For example, after loading the Stratego picture I pressed enter and returned to XB. I then typed CALL COLOR(1,5,5) and got a syntax error. I'm pretty sure my suggestions will fix this so everything works as expected.

 

There is another possibility that may be useful. I was sure that I posted this back in 2014, but can find no evidence that I actually did this. This lets you load pictures to the upper 2/3 of the screen with text in the lower 1/3. Maybe this would do what you want. I will post the program tonight. I just posted the program.

Click on the link to see the animated GIF.

 

On 1/8/2014 at 10:22 PM, senior_falcon said:

I have been making some adjustments to The Missing Link so it is better suited for the type of graphic adventure mentioned by Retrospect. This demo shows a picture being loaded into the top 2/3 of the screen, then text is displayed in the lower 1/3 of the screen in 48 columns. (Yes, that was 48 columns, not 40) The filenames of several pictures are entered and the pictures are displayed in the top 2/3 of the screen. This is all done in XB with assembly subroutines providing the bit mapped support. This should be all the tools that you need to write your own graphic adventure. I can post the modified version of TML if anyone is interested. Note that this updated version has 9 rows of text.

 

tmladventure.gif.09d06bed291f31cf7edf81be6bf18c41.gif

Edited by senior_falcon

Share this post


Link to post
Share on other sites

TML Graphics Adventure:

This is an XB program that you run first and it sets up TMLGA.  Then you can type in your XB program and save as usual.  The full TML package is at the Atariage site, and the manual for that will be helpful.

 
Image subprograms:
CALL LINK("LOADP","DSK1.PICNAME")  loads a TI Artist format picture
CALL LINK("SAVEP","DSK1,PICNAME")  saves a picture in TI Artist format
CALL LINK("LOAD23","DSK1.PICNAME") loads top 2/3 of picture in missing link format
CALL LINK("SAVE23","DSK1.PICNAME") saves top 2/3 of picture in missing link format
 
So you would convert by writing a program to:
CALL LINK("LOADP","DSK1.PICNAME")
CALL LINK("SAVE23","DSK1.PICN23")  (use a different filename for this picture to avoid overwriting original)
When all the pictures are converted you can load them as desired into your adventure using LOAD23
 
CALL LINK("SCROLL")  forces a scroll of the bottom 1/3 of screen - everything is moved up 7 pixels
CALL LINK("INPUT",ROW,COL,A$)  You can input a string at row,col - note that these are pixel rows and cols.
You probably want to input at 185,1, but experimentation will be worthwhile.
CALL LINK("SINPUT",ROW,COL,A$) scrolls bottom 1/3 of screen, then inputs as above.  
This uses a 5x7 font for 9 rows and 48 columns.  I think it is quite legible - see what you think.  We can go back to a 6x8 font if that works better.
CALL LINK("PRINT",ROW,COL,A$)  prints at row,col.  word wrap is always on and if it tries to print off the bottom a scroll will happen.  
 
Sprites are available plus all the graphics features of TML except for the turtle graphics which had to go to make room.
Myarc controller not supported.  I suppose it could be if anyone cared.
 

 

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

Another one of your amazing programming tools for the assembly-averse TI programmer! Thanks for pointing me in this direction. I must admit, I don't have much in the way of graphics for the game, just a few random pics. I'll read the documentation and see if this is more the way to go.

 

Does TI Artist work in Classic 99? I thought the real thing came with a touchpad. I don't have it, but am guessing it's easily found as a download if it does work in Classic 99. I'm really out of the loop on TI stuff beyond 1985, as that's when I got an Apple //c and sold the TI to one of my friends.

Share this post


Link to post
Share on other sites

TI Artist was one of my early test programs for Classic99. It works, but the only available input devices are the keyboard and joystick.

 

  • Thanks 1

Share this post


Link to post
Share on other sites
8 hours ago, majestyx said:

No CALL INIT anywhere in the program. It stops at line 20. There is only one line before it:

 

10 DIM EQU$(10),CLU(26),DED(25),CHO$(4)

 

I was just looking for a simple way to add a little flash/polish to the game and thought this picture loader would be an easy way to do so. I'll concentrate on the rest of the game and will worry about adding some flash, if at all, once it's completed. I was aiming for something like RETURN TO PIRATE'S ISLE, with some pictures near the top of the screen, or maybe even just a picture loaded here and there. Since I'm using XB+ and with 40 columns, I'm guessing this might be tough to do.

If T40XB can run your program successfully when not preceded by the picture loader, then that is where the problem lies. Once it has been modified so as to return to XB properly then it will be possible to use it without having the unstable behavior it now has.

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