Image Map Image Map
Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Are there any GIF libraries that will work with 16-bit x86 and CGA?

  1. #1
    Join Date
    Mar 2020
    Location
    Kansas City, KS USA
    Posts
    8

    Default Are there any GIF libraries that will work with 16-bit x86 and CGA?

    Does anyone know of any older libraries that will simplify the loading, decompression, and display of static (non-animated) GIF files in CGA mode 04h (320x200x2 bpp)? I'm specifically targeting the 8088/8086 and I'm not picky about the language - if it can decompress and display images relatively quickly I'm happy to work with Turbo C, Turbo Pascal, QuickBasic 4.5, etc...

    I've found that the earliest version of GIFLIB available on SourceForge will not compile in 16-bit Turbo C/C++ (no surprise there!) and other similar GIF libraries that target DOS programming I've found assume you're working in mode 13h or SVGA/VESA.

    Also, if there's another bitmap format that compresses as well as GIF and supports CGA mode 04h with available 16-bit libraries I'm definitely willing to use it!

    Any help would be greatly appreciated!

  2. #2

    Default

    http://www.reenigne.org/misc/giflib.zip seems to be early enough to work - it claims to work with Turbo C 2.0. I can't remember if I ever tried it. Doesn't have code to display the decompressed image on the screen, though.

    The sources of FRACTINT also have GIF encoding/decoding code.

    However, depending on your application you might find that you have better results (in code size, compression ratio and speed) rolling your own image format by using a general purpose compression/decompression library operating on the data in the format in which it is stored in the CGA's VRAM (as long as you don't mind aligning it to 4-pixel boundaries horizontally).

  3. #3

    Default

    How are you planning on handling >4 colors? Rich Geldreich's QB GIF decoder will run on an 8088 but it will be incredibly slow. I remember it being slow on a 486-25. It's also for VGA but if you know a little QB it wouldn't be difficult to add CGA support.

    There is also a real-mode assembly version that targets 386+ but it doesn't use 32-bit regs. So it probably wouldn't be too bad to modify.

  4. #4
    Join Date
    May 2009
    Location
    Connecticut
    Posts
    4,726
    Blog Entries
    1

    Default

    A Turbo Pascal version designed for EGA (but modified from a now lost Hercules implementation) can be seen at http://cd.textfiles.com/simtel/simte...IF/.index.html I think it was the basis for a more flexible version supporting other video cards so you might be able to make the same changes.

    There were a few other programs released with source code back in the 80s on CompuServe but all seems lost after the Unisys foolishness. If you want to push things, maybe contact http://hplx.pgdn.de/ and see if the author would provide source code to LxPic. High speed assembly designed for V20 and CGA might be perfect for your requirements.

  5. #5
    Join Date
    Mar 2020
    Location
    Kansas City, KS USA
    Posts
    8

    Default

    Awesome, thank you everyone!

    How are you planning on handling >4 colors?
    This is for a personal project - I'm producing all of the 4 color bitmaps myself and am only going to support mode 04h in the program. Basically, I want to target the 5150 and get something that works reasonably well on it.

    http://www.reenigne.org/misc/giflib.zip seems to be early enough to work - it claims to work with Turbo C 2.0. I can't remember if I ever tried it. Doesn't have code to display the decompressed image on the screen, though.
    This looks like v1.1. I found v1.2 soon after posting in this thread and was able to get it to compile with TCC that comes with Turbo C 2.01. So far after fiddling with it I'm able to get it to load the GIF from disk and loop through the data structures, but like you said there's nothing in this package that handles or demonstrates how to get this to video RAM. If you have any insight, that would be great, but otherwise I may just be able to kludge my way through it. There's a method that lets you decompress the image line-by-line, so worst case I should hopefully be able to loop through it and get it loaded in an interlaced buffer and then memcpy that over to B800.

  6. #6
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    6,546
    Blog Entries
    1

    Default

    Quote Originally Posted by discolando View Post
    There's a method that lets you decompress the image line-by-line, so worst case I should hopefully be able to loop through it and get it loaded in an interlaced buffer and then memcpy that over to B800.
    Or, just decode the entire thing to a buffer, then move it to b800 in an interlaced fashion (will need 200 individual moves).
    Offering a bounty for:
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  7. #7
    Join Date
    Mar 2020
    Location
    Kansas City, KS USA
    Posts
    8

    Default

    Quote Originally Posted by Trixter View Post
    Or, just decode the entire thing to a buffer, then move it to b800 in an interlaced fashion (will need 200 individual moves).
    Thanks for the tip!

    Speak of the devil, I was doing more (re)searching this morning and found this - I'm excited to take this for a test drive!

    http://www.oldskool.org/pc/lz4_8088

  8. #8
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    6,546
    Blog Entries
    1

    Default

    Actually, use this: https://github.com/emmanuel-marty/lzsa (for which I wrote the decomp code as well The LZSA1 variant beats LZ4 depending on how you tune it: Slight smaller files for the same decode speed as LZ4, or slightly faster decoding for the same size files as LZ4.
    Offering a bounty for:
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  9. #9
    Join Date
    Mar 2020
    Location
    Kansas City, KS USA
    Posts
    8

    Default

    Quote Originally Posted by Trixter View Post
    Actually, use this: https://github.com/emmanuel-marty/lzsa (for which I wrote the decomp code as well The LZSA1 variant beats LZ4 depending on how you tune it: Slight smaller files for the same decode speed as LZ4, or slightly faster decoding for the same size files as LZ4.
    Man, I am just thoroughly impressed with this. I've got it plugged into my project and am just amazed at how well the format compresses and how well this code decompresses it on the original hardware. Text files are of course just crushed down to a fraction of their original size, but even the dithered 4 color graphics I'm creating in Photoshop and then exporting to raw binary data are reduced from 16k down to as much as 8-10k depending on the degree of dithering. This is basically on par with the old GIF87a library I was working with and is significantly smaller and faster. Thanks so much.

  10. #10
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    6,546
    Blog Entries
    1

    Default

    Glad I could help. BTW, if you perform an ordered/pattern dither, they'll crush down even more because the patterns turn into repeating bytes on a scanline.
    Offering a bounty for:
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •