Jump to content
IGNORED

Bitmap image conversions


Opry99er

Recommended Posts

  • 3 months later...

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

  • 1 year later...

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

  • 2 years later...
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
Link to comment
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
Link to comment
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.

 

Link to comment
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

 

 

 

Link to comment
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
Link to comment
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...

 

Link to comment
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
  • Thanks 1
Link to comment
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
Link to comment
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.

Link to comment
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
Link to comment
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
Link to comment
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.

Link to comment
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.

Link to comment
Share on other sites

  • 2 months later...
On 1/8/2020 at 8:04 AM, senior_falcon said:

@ 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 (LWPI WKSP)  there as well as any temporary variables.

2 - Copy the XB system area from v0370 to v03EF  >0000 to >0A00 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.

Hi Tursi:

Just wondering if you had a chance to look at this?

 

Link to comment
Share on other sites

1 hour ago, senior_falcon said:

Hi Tursi:

Just wondering if you had a chance to look at this?

 

No, I've been travelling almost continuously since January 7th.

 

Supporting this hack isn't really super high on my interest list - frankly I'd rather people use TML to get pictures in XB. ;)

Link to comment
Share on other sites

So looking at your suggestion list... the only scratchpad usage is registers 0-4 plus 11 of GPLWS (>83E0), which I assumed was safe (although I don't do that much XB LINKing). The only XB utility I use is KSCAN at >201C. All temporary (and image!) data is stored in high RAM above the program itself, so I don't think moving it to low RAM would make any difference?

 

I deliberately didn't back up program controllable items, like the screen or character set, since the XB code could deal with those as the instructions say with a CALL CLEAR::CALL CHARSET (well, the uppercase part anyway). But you make a good point that low RAM is unused and I wouldn't suggest people add a lot of extra assembly code to one of these programs... ;) But I do backup 88 bytes from the top of VRAM pointer - without that XB crashed a lot (but it was only needed if CALL FILES was large enough to overwrite the bitmap screen - as it is by default). So I need both?

 

The return is just a B *R11 -- isn't that the correct return from a CALL LINK?
 

EDIT: (I checked the B* R11 - it returns to the end of the XML function handler at >61C, which is just a JMP to >5E4, which is a B @>0070.  ;) So I guess a return is a return is a return... ;) )

 

Edited by Tursi
Link to comment
Share on other sites

It seems a bit more stable. I took the opportunity to optimize the code (very) slightly and it's about the same performance wise despite backing up a few more k. Also updated the documentation to give away the CALL LOADs needed to change which key it exits on (and even make it exit on any key and retrieve which one it was - but no filtering. It's one or all as it stands.)

 

It's on v171 so apparently I haven't noted a number of releases. ;)

 

In detail, I changed the backup/restore code to backup VDP >0000->0A00 as suggested, and rather than the math I used to do to backup the minimum at the top, I just grab a fixed 1k from there too, >3400 to >3800 (above that doesn't matter as I don't overwrite it). I moved the scratchpad to 8-bit RAM and unrolled the loops once to compensate, plus used registers a little more, so speed is good. I kept the B *R11 return to avoid depending on ROM addresses but did clear the GPL status bit first, which I didn't before. And then I documented from a CALL LOAD level how to manipulate the keypress it waits for.

 

Thanks for the suggestions Senior Falcon!

 

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

 

Edited by Tursi
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

On 10/1/2016 at 10:34 PM, Tursi said:

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

 

Thanks, Tursi, for another great tool.

 

I've been using it on some space images in F18A palette mode. The palette of 15 colors is perfect for combining images with other graphics in the other 48 palette slots.

 

These images are from Astronomy Picture of the Day. There is an F18A palette version and sometimes a 9918A bitmap version.

 

Apollo 17 at Shorty Crater

 

moonshorty_apollo17_gray_F18A.png.43bae00d5949a8b606d8d53436fa6a56.png     MOONSHORTY_APOLLO17_9918A.png.4192fb786620d74083632eac0c8a66e0.png

 

Apollo 16 Exploring Plum Crater 

Scaling the original 509x385 leaves black border

 

Apollo16plum_F18A.png.ff0713b57555c3772ce400b937335c1f.png      plum_apollo16_9918A.png.4a9cbc83f37bd2d4078e07c9283b93be.png

 

Apollo 14 Heads For Home

 

ApolloHeadsForHome_F18A.png.10b7e25c56a4a067782104ffa35d8809.png     ApolloHeadsForHome_9918A.png.d0510ae83372f9079903d880a16a1d7c.png

 

Mimas in Saturnlight

 

Mimas_F18A.png.7b48121c9066fba0e7a983c80ffddd8d.png     Mimas_9918A.png.05180425200069ccac10209d43f67493.png

 

An Apollo 15 Panorama: Astronaut Exploring

hillpan_apollo15_big_F18A.png.cfb3eff48a3cdf8288168fda23ede0ed.png      hillpan_apollo15_big_9918A.png.614e171d45a9cc5843dbd3cc18db0323.png

 

 

Sunrise at Tycho

 

tychoCentralPeaks_lro_F18A.png.b706d2803862fbd8bdbe01d69ff0f1d4.png      tychoCentralPeaks_lro_9918A.png.66823128fff15288b9df3f4ee6857123.png

 

Dwarf Planet Ceres

 

20151022_ceres_rc3_haulani_cowartC_F18A.png.5d38d624eae9e9beab696b350578a9af.png      20151022_ceres_rc3_haulani_cowartC_9918A.png.65bb018efc54e4d5e56ab0388141c5a7.png

 

 

Saturn's Iapetus: Painted Moon

 

iapetus3_cassini_960_F18A.png.3a4411c442cd2c3fc7f9e42bd578d1e8.png     iapetus3_cassini_960_9918A.png.cd49d7adcc609eb082f9bea759607a65.png

 

Phobos: Doomed Moon of Mars

 

Phobos_Viking1_960_F18A.png.694da2929f4f2b6193799c90622a9452.png     phobos_Viking1_960_9918A.png.94837597cc66ef7bbdc425b38fb79a0f.png

 

Apollo 13 Lunar service Module Damage

Apollo13_lunar_service_module_F18A.png.eedd99cbf450ac0ee6697fd372c72736.png     Apollo13_lunar_service_module_9918A.png.c7079ae05936175adb590e0b8514c804.png

 

Lunar Orbiter Views Crater Copernicus

 

copernicus_lunarorbiter_c720_F18A.png.ed361c69935f055526cb5edc292e01a5.png     copernicus_lunarorbiter_c720_9918A.png.0e23bb81888a64a69b48a8fffa85e698.png

 

Odysseus Crater on Tethys

 

tethys_Cassini_960_F18A.png.27a8234046185900814522914ade18d0.png     tethys_Cassini_960_9918A.png.dfe941e9d2b8198443a40ab51d12489e.png

 

Astronaut Exploring: An Apollo 15 Panorama

 

hillpan_F18A.png.85b6ea7e6b9dc157b492963a1fd4f6c5.png     hillpan_apollo15_9918A.png.d409d8fd865ef478b0fd3b34e0a94449.png

 

 

 

 

 

plum_apollo16_F18A.png

Edited by FarmerPotato
More pictures plus 9918A versions
  • Like 3
Link to comment
Share on other sites

Looks great! For the astronaut one, you have a bit of black border at the left which is causing the first column of pixels to look stretched (as the black is considered more important to preserve than the detail in the moon's surface) - crop out the black border and it should convert better. 

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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