RELEASE: GIF 99 Viewer for V9938/58 Systems v1.05 by O.P.A.

[+InsaneMultitasker]

re: the Geneve.  I took a quick look at the source and saw at least two places where CRU bit 5 (base 0x0000) is tested.  The bit test closes the file depending on the status. 

 

There might be other /4a-specific trickery besides this direct scan that needs to be removed.

[Gary from OPA]

36 minutes ago, InsaneMultitasker said:

re: the Geneve.  I took a quick look at the source and saw at least two places where CRU bit 5 (base 0x0000) is tested.  The bit test closes the file depending on the status. 

 

There might be other /4a-specific trickery besides this direct scan that needs to be removed.

hmm. i will review it tomorrow and see, not sure why there might be some /4a trickery involved. problem with 30 year old source code, never know what was the original idea behind it!

[+InsaneMultitasker]

3 minutes ago, Gary from OPA said:

hmm. i will review it tomorrow and see, not sure why there might be some /4a trickery involved. problem with 30 year old source code, never know what was the original idea behind it!

I'm guessing it was just a quick way to abandon the file load once you saw enough of the picture - or decided to go on to the next one - without calling the kscan routine.

[+mizapf]

Some examples created via GIMP (first 256x192, others 256x212). Obviously, the more color contrast, the better. Or you have to back off your monitor by some meters.

 

I tried to convert them with PICT, but when I save them with MSAVE, the program crashes. Below is also the zip file containing the pictures.

 

Edit: Added some more example pictures from my photo gallery.

 

 

pictures.zip

[+mizapf]

Correction: The PICT program does not crash; it just takes quite long to convert the picture. Eventually, it saves a MyArt picture, but 6 screen lines at about 1/4 of the height from above are garbled. This already happens when the saves begins (maybe PAB data or buffer?).

 

Here is the image.

 

Load PICT in MDOS, then USE <gif-filename>, then DISPLAY, then MSAVE <myart-filename>.

pictrans.dsk

[+9640News]

2 minutes ago, mizapf said:

Correction: The PICT program does not crash; it just takes quite long to convert the picture. Eventually, it saves a MyArt picture, but 6 screen lines at about 1/4 of the height from above are garbled. This already happens when the saves begins (maybe PAB data or buffer?).

 

Here is the image.

 

Load PICT in MDOS, then USE <gif-filename>, then DISPLAY, then MSAVE <myart-filename>.

pictrans.dsk 360 kB · 0 downloads

You didn't know that was feature scrambling a few lines????

 

There is a solution.  Use a script file.

 

The script file avoids the graphic display returning back to a text mode display, then back to a graphics mode display that destroys those lines.

 

 

[+mizapf]

Hmm, OK, will try. Seems as if the author forgot to copy the contents to a buffer when changing modes.

 

Maybe I'll add such a GIF conversion feature to a future release of TIImageTool.

[Nick99]

10 minutes ago, mizapf said:

Hmm, OK, will try. Seems as if the author forgot to copy the contents to a buffer when changing modes.

 

Maybe I'll add such a GIF conversion feature to a future release of TIImageTool.

A GIF conversion would be great.

If you succeed with PICT converting please let me know how it's done.

[+9640News]

I've tested, and PICT will convert, but only do it correctly if you use a script instead of typing the commands manually.

 

I have disassembled the source, however, someplace in the code, there is what I suspect a security check over a section of code.  

[+mizapf]

OK, this worked for the Golden Gate picture.

 

The myconv script looks like this:

 

USE GOLDENG_G
DISPLAY
MSAVE GOLDENG
EXIT

 

Type "PICT MYCONV" in MDOS.

gifconv.dsk MYCONV GOLDENG_G GOLDENG

[+InsaneMultitasker]

@9640News and @mizapf try the attached version "GIFG" on the Geneve. 

I removed the three instances where the 9901 CRU bit is polled and then modified the graphics mode bank 14 register setup from >03 to >00 (GIF_DATA, label IY, register 14). 

The Geneve's "/4a" emulation forces dsr-based vdp transfers into bank 0 versus writing the data to whatever bank is active. I'm not going to pursue a change to the OS at this time.

I don't know if the program will at some point overwrite the PAB but I was able to load two pics in succession. I loaded the program via EXEC.

 

 

GIFG

[+mizapf]

Yes, seem to work, although it does not properly draw the 212 lines pictures (squeezed to 192 lines?). They are reported correctly before loading, though. Or is it a PAL aspect?

[+9640News]

I had already tried something similar, however did not understand nor realize the impact of the vdp bank issue, so VERY GOOD CATCH!  

I was stumped why line 366 in GIF-SUBS was generating the error on a read and that explains it.

 

I made the extra changes and both the files BEERY and GREG display fine, however LOU is in Graphics Mode 6, interlaced mode.  In that mode, it looks like the 128 byte record buffer creates a 1/2 row update on the screen while the rest of the display is written.  I am writing this for @Gary from OPA 's benefit.

 

This should not be an issue with MDOS mode on the Geneve as it has the ability to buffer in CPU ram versus buffering in VDP.  This will give me a chance to convert the necessary pieces over to a MDOS application.

 

Thanks again Gary, and Tim for isolating the issue with running the code on the Geneve.

 

Beery

 

 

[Gary from OPA]

9 minutes ago, 9640News said:

I had already tried something similar, however did not understand nor realize the impact of the vdp bank issue, so VERY GOOD CATCH!  

I was stumped why line 366 in GIF-SUBS was generating the error on a read and that explains it.

 

I made the extra changes and both the files BEERY and GREG display fine, however LOU is in Graphics Mode 6, interlaced mode.  In that mode, it looks like the 128 byte record buffer creates a 1/2 row update on the screen while the rest of the display is written.  I am writing this for @Gary from OPA 's benefit.

 

This should not be an issue with MDOS mode on the Geneve as it has the ability to buffer in CPU ram versus buffering in VDP.  This will give me a chance to convert the necessary pieces over to a MDOS application.

 

Thanks again Gary, and Tim for isolating the issue with running the code on the Geneve.

 

Beery

 

 

Hmm. Never thought of that before with the Geneve forcing to VDP bank 0. Plus back when I owned a working geneve and was testing software on it, was during the days of pre M-Dos with the GPL mode as system/sys plus I wrote my own custom direct to timode no M-DOS boot up as well. Never used the amazing newer more complete M-Dos system, only for a tiny bit used one of the first just before pre 1.x M-Dos which was still very basic.

 

As for lou picture screwing up yes now the VDP pab and data transfer gets in the way. So cpu transfer would be needed which I don't think sadly the /4a mode in Geneve supports.

 

Time I guess to fix up some of the leftover GPL timode problems. But of course having this app as native M-Dos program is better.

Edited May 4 by Gary from OPA
crappy spelling when on mobile

[+InsaneMultitasker]

18 minutes ago, Gary from OPA said:

Time I guess to fix up some of the leftover GPL timode problems

I am pretty sure this particular 9938 bank mask was intentional, to minimize program/dsr interference.  This is the first /4a program that I know of that moves the pab to a different bank.  I will note it in the os dev topic as this really isn’t a GiF program issue.    

[Gary from OPA]

Since GIMP mentioned in this thread, thought it would be good place to mention this script plugin that used for MSX2 graphics but can work for those with v9938 ti99 systems as well.