Slideshow99

[Tursi]

Omega has asked for this for a long time, so I finally got it done. This takes the old demo slideshow program I made ages ago and makes it a little more generally useful.

 

This is a simple slideshow program that displays images created by Convert9918 (or anything else). It supports five types of image:

 

-Monochrome TI-Artist Bitmap

-Color TI-Artist Bitmap

-Half-multicolor (bitmap and multicolor flicker)

-F18A Paletted Bitmap (F18A only)

-F18A Scanline Palette Bitmap (F18A only)

 

You can freely mix and match the images, it will auto-detect the type as it's loading. It should work, in theory, with any device that offers a standard directory, but note I have only tested under Classic99, Classic99 with TI controller, and the CF7.

 

It will allow you to specify up to 12 paths to search for images, and supports random and looping display with configurable timeout. Also supports pressing 'space' for next image and 'back' to return to the entry screen.

 

The only restriction is files need to be named in the TI format, that is, ending with _P, _C and _M. My Convert tool saves with ".tiap", ".tiac" and ".tiam" respectively, but that's just because Windows works a lot better with extensions than without. Classic99 will automatically remap these names, for other systems you may need to rename them manually.

 

There's one minor gotcha too... if you have really large directories (typically talking about hundreds of files here, more than a floppy can manage), the seek time for the later images can get long. The image will stay on screen for the three standard bitmap modes, but it has to go blank for half-multicolor and scanline palette, because otherwise the disk activity overwrites the visible display. Just a warning that sometimes the screen will stay on during the initial disk seek and sometimes it will turn off, in case you notice.

 

There's one other gotcha, not related directly to this program. Testing this revealed a bug in Convert9918 where the F18A paletted modes were exporting the palette in the wrong order. I've fixed this, so if you have a version of Convert9918 earlier than today's (v166), you should update before you start converting!

 

Anyway, hope you enjoy. Grab from http://harmlesslion.com/software/slideshow99

 

[Omega-TI]

Excellent news here Tursi. I can't wait to get home from work tonight... I'm gonna play!

I know it'll be great. Thank you so much.

[Omega-TI]

As soon as I got home, I headed straight for the den, used Tursi's TMS9918A converter to bust out a few images, then renamed the extensions as per instructions and tossed them onto an HFE image. This is what I saw...

 

- VIDEO REMOVED -

Visit: https://www.youtube.com/channel/UCG9DQSFtPij9PXz7aq9uqog

To see the updated video and all my others.

 

... it's so cool to be able to display decent 'home grown graphics' on the TI!

 

THANKS TURSI!!!

Edited October 5, 2016 by --- Ω ---

[Omega-TI]

Tursi,

What are your top 10 'scanline palette bitmap F18A' images? Care to post them here? I'll be having a conversion frenzy over the next few days. Hopefully I'll have some cool stuff to share as well.

[Tursi]

While I have over 800 images saved off, they're all standard bitmap format. A personal goal of this tool was always to see how far I can push the base graphics chip, to see "what might have been" thirty years ago. Scanline palette mode was a test to see if I could push Matt's chip, I like his reaction when I talk about abusing it.

 

They can be made so close to the original image I don't test to save them off when I do play with them, I figure I can re-convert it any time I need to.

 

I didn't mention that I posted an update to the slideshow program -- the change was to work around a bug in the HDX catalog function that returns the size of a file 1 sector less than the TI disk controller does. (The disk controller includes the FDR in the count - it's a hard coded +1 in the directory code. I got called out for that in Classic99 a couple years ago, else I wouldn't have known either, hehe. ) So the program can check for the expected size, or the expected size minus 1, and that seems to work.

 

I've posted samples before, but always happy to do a few. I'll randomly select a handful of images here...

 

Even a monkey can work this one, and a random house fox.

 

Meerkat from San Francisco Zoo, and got to have a lion!

 

Sorry, had to sneak in one pony, and got a picture a few weeks ago with Elvira!

 

Hometown of Penticton, BC and my old car.

 

A pic from my work in Shanghai and finally a 99/4.

 

In the attached zip.

pics.zip

Edited October 5, 2016 by Tursi

[Omega-TI]

Nice! I'm going to add a couple of those to my active directory.

[Omega-TI]

Those of you using F18A's, here are some great pictures to use with the slideshow program.

 

SLIDE-F18A.zip

[Asmusr]

Nice pics. Reminded me that the F18A Scanline Palette Bitmaps were not working in http://js99er.net, but this has been fixed now in v ersion 5.6.1. Well, almost fixed, because there is still a bit of a timing issue, to do with how the scanline numbers are reported, I think.

[Tursi]

I don't remember the details anymore, but Matt and I went back and forth over this a bit when I was developing the scanline palette code. The main gotcha for me was that the way the end of a scanline is reported is not exactly the way older systems did it. Unfortunately, I don't remember the exact details, but somewhere in this description I think you'll find the truth. Matt may come correct me later.

 

When the F18A renders a scanline, it does so by writing to an internal line buffer. When the line buffer is finished, the F18A indicates this to the program -- I believe that this is when the line index changes. However, the buffer has not necessarily been completely scanned out to the monitor yet. The line buffer stores color indexes, so the color palette is still relevant until the scan out is completed.

 

The idea was to give the program more time between scanlines for scanline effects, as the F18A renders the line much faster than the monitor scans it out -- in fact palette changes are the only thing that doesn't benefit from this early notification (and it is why I use two palettes alternately, to reduce the timing dependencies). I believe that when the blanking bit is set, then it's truly in monitor hblank.

 

That's partly from memory and partly from looking at my own code.. I might have those two reporting locations reversed. But hopefully that helps!

[Asmusr]

I don't remember the details anymore, but Matt and I went back and forth over this a bit when I was developing the scanline palette code. The main gotcha for me was that the way the end of a scanline is reported is not exactly the way older systems did it. Unfortunately, I don't remember the exact details, but somewhere in this description I think you'll find the truth. Matt may come correct me later.

 

When the F18A renders a scanline, it does so by writing to an internal line buffer. When the line buffer is finished, the F18A indicates this to the program -- I believe that this is when the line index changes. However, the buffer has not necessarily been completely scanned out to the monitor yet. The line buffer stores color indexes, so the color palette is still relevant until the scan out is completed.

 

The idea was to give the program more time between scanlines for scanline effects, as the F18A renders the line much faster than the monitor scans it out -- in fact palette changes are the only thing that doesn't benefit from this early notification (and it is why I use two palettes alternately, to reduce the timing dependencies). I believe that when the blanking bit is set, then it's truly in monitor hblank.

 

That's partly from memory and partly from looking at my own code.. I might have those two reporting locations reversed. But hopefully that helps!

 

There are two issues, one is the blanking, but since my emulator is single threaded it's interleaving drawing of a scanline and executing CPU/GPU code. So the code sees the blanking bit set all the time. An alternative to using polling of the blanking (in >7001) is to use the HSYNC trigger that was introduced in F18A 1.6. This is easier to emulate :-)

 

The other issue is where on the screen different scanline numbers are reported (in >7000). I'm sure Matthew has told me already, but I'm no longer sure. My emulator is drawing the screen as 240 scanlines with a 24 line top/bottom border in 24 row mode (and no border in 30 row mode). I'm reporting scanline number 0 at the first *visible* line in both cases (but I'm not sure that's right). You are testing for scanline 255, but that never happened in my previous implementation. But as the code is now it's reporting line 255 as the last line of the top border, so not much time for any vsync code.

[Tursi]

Always set shouldn't hurt it... it checks for scanline change then waits for the blanking bit. If it's already set that should be fine.

 

I am pretty sure 0 is the first visible line -- the trick with line 255 is there is more than one of them. The 8-bit counter clamps at reporting 255 for lines 255-261 (there are 262 lines on the screen). My code just uses it to detect the end of frame, there are plenty of ways I could have done it but I was already reading the line counter.

 

I'm not entirely sure where those lines fall, I guess they must roll into the top border since I'm pretty sure line 0 is the first visible.

[Asmusr]

Always set shouldn't hurt it... it checks for scanline change then waits for the blanking bit. If it's already set that should be fine.

 

I am pretty sure 0 is the first visible line -- the trick with line 255 is there is more than one of them. The 8-bit counter clamps at reporting 255 for lines 255-261 (there are 262 lines on the screen). My code just uses it to detect the end of frame, there are plenty of ways I could have done it but I was already reading the line counter.

 

I'm not entirely sure where those lines fall, I guess they must roll into the top border since I'm pretty sure line 0 is the first visible.

 

262 scanlines in one byte is too much for me. I think we need Matt's input.

[Tursi]

 

262 scanlines in one byte is too much for me. I think we need Matt's input.

 

hehe, sure, but that one's a fact. the register will report line 255 for the last 8 lines.

[matthew180]

I can't believe you guys are going to make *me* remember all of this...

 

I just looked it all up, and checked the F18A testing / development thread for notes and found this:

 

1. The scan line reported at >7000 changes "before" the line is buffered. So, for example, when you see a change from 2 -> 3, you have 1 VGA scan line (about 32us) to change VRAM and VRs before the line is buffered.

2. When the blanking bit at >7001 changes from 0 -> 1, it is safe to change the PRs for the line reported in >7000, which in this example would be for line 3. Changing PRs prior to the blanking bit will cause the previous line to be affected (line 2 in this example).

3. The line reported at >7000 will continue counting and clamp at 255 during the vertical and possible top-border period (there is no top border if ROW30 is enabled). This lets you easily detect a change to line 0, or any other line for that matter.

 

The blanking bit at >7001 changes from 0 -> 1 at VGA horizontal count 640, i.e. right at the end of the visible display, for odd VGA scan lines only. Here is a slightly modified diagram I found:

Fat   VGA                         >7000             >7001
line  line                        changes here      changes here
                                   1 <-------------> 640 <---------> 799  VGA horizontal count

255   46    show buf1            255 -> 0 (can change VRAM/VRs for line 0)
            fill buf0 (not used)
255   47    show buf1              0                  0 -> 1 blank for line 0, change PRs here
            fill buf0 (line 0 data)

--- visible area begins

  0   48    show buf0              0 -> 1 (can change VRAM/VRs for line 1)
            fill buf1 (not used)
  0   49    show buf0              1                  0 -> 1 blank for line 1, change PRs here
            fill buf1 (line 1 data)

  1   50    show buf1              1 -> 2 (can change VRAM/VRs for line 2)
            fill buf0 (not used)
  1   51    show buf1              2                  0 -> 1 blank for line 2, change PRs here
            fill buf0 (line 2 data)

I hope this helps.

[Tursi]

Thanks, Matt! Saving that information off

[Omega-TI]

For those who don't go into the development section on a regular basis, I thought I'd give you a heads up on an update. Tursi updated his PC program called Convert 9918. It's hidden in a topic called "Bitmap image conversions" so it can be easily overlooked.

So click << HERE >> to get the program. It goes together like milk & cookies with the Slideshow99 program that runs on real iron.

[Tursi]

http://harmlesslion.com/software/convert9918

[Omega-TI]

http://harmlesslion.com/software/convert9918

 

^

Good idea... and so they don't have to hunt for Slideshow99 either, they can also << CLICK HERE >>.