Help - A8 image converter most closely matching C= Plus/4 modes?

[oky2000]

I am doing a little video to show that colour resolution (per basic hardware limitation not CPU/custom assist per scanline with palette swaps) is more important than actual image pixel resolution for 8 bit systems.

 

So far I have converted a sample image to ZX Spectrum, Amstrad CPC, Commodore 64 and Plus/4. In the case of Amstrad and Commodore formats I have done an image both for the 40 column mode (320x200) and 20 column multicolor mode (160x200 double width pixels). As I suspected the TED multicolour display was the most impressive so far due to the excellent 121 colour palette and the acceptable colour resolution limitations/quirks in 4x8/8x8 pixel blocks. I want to see what you could do in BASIC on an Atari 800XL, i.e. 256 colour palette of GTIA, because it will definitely be interesting BUT I don't understand how the colours per screen/character block 8x8/4x8 pixel block work and it's too many palette colours for a regular paint program to be used for hand converting approximate images.

 

What I am after is a program to generate the standard PAL or NTSC display of 384 x height in pixels (192?) pixels and the double width pixel multicolor modes of 192 pixels wide in full color (not shades of a single colour or colours from a single luma) from a standard PNG image. It must be possible to display the screens using only BASIC and no palette swaps using DLIs no interlaced palette swaps per frame etc just something you could load into a graphic adventure you wrote in BASIC on the host machines.

 

The only program I know is Technicolor Dream but that works on a lower resolution mode for the test, want to keep the 40/20 column pixel width constant for comparisons. Any suggestions?

 

(I am trying to create a fake 1983/1984 computer shop demo for a display of the various machines, the VIC20 is excluded as I have no program and the 16k RAM left for BASIC if you put it into a 28-30 column mode and also the Acorn 8bits that have a rubbish 8 colour RGB 1bit palette).

[Rybags]

In some cases you can just simulate a best-case scenario using tools like Posturize in PhotoShop.

 

What are you saying for target display generation?  Basic with no DLI assist allowed?  That doesn't offer much to Atari pictures, it would rule out modes like TIP and APAC which are where the most colour fidelity is on offer.

 

And the resolution we can do - it's more like 352 hires pixels in wide mode, we get some truncation + bus noise and not the actual full 384 pixels that wide mode data can provide.  Vertical up to 240 (actually more is possible but it's PM graphics only with graphics registers loaded by the CPU so not greatly useful.

 

Also - I'm not aware of any Atari side program that allows using PNG.  I've generally just used BMP since it's close to raw data and easy to deal with.

Edited December 19, 2021 by Rybags

[bfollett]

In the graphic mode you want to use you only get 9 colors but they can be placed anywhere on screen without restriction.

[Irgendwer]

Just because it fits somewhat to the topic (not to your request while CPU is assisting) here some quick Plus/4 => A8 conversions:

 

pets_rescue_01.xex mos_01.xex the_lands_of_zador_title.xex

[oky2000]

So ANY 9 colours chosen from 256 colour palette 160x200 resolution image is possible?

 

What about 40 column.320x200 image displays in "hi-res" mode?

 

Think of it like the picture of the Parrot Wikipedia uses on the 8 bit computer palettes page thing. It is not about what brute force you can use to overcome problems with machine code, for 1984 new home computer owners to incorporate into their own BASIC graphic adventure if you like.

 

Basically I need a mode that closely matches 320x200 pixel resolution and 160x200 as well, if this means only 9 colours for the entire screen then that's something I can work on in a paint program via a 256 color GTIA palette as a source.

 

[oky2000]

 

On 12/19/2021 at 6:35 AM, Rybags said:

Also - I'm not aware of any Atari side program that allows using PNG.  I've generally just used BMP since it's close to raw data and easy to deal with.

Yeah BMP is fine, I just don't use JPEGs as my source image format. I can write out BMPs, PNGs etc etc from Paintshop Pro.

[oky2000]

OK well I found a 256 colour GTIA palette and used that to render a 160x200 style resolution image with just those colours, then reduced the total colours to 9 and did a pixel resize to the original resolution (because it's a double width pixel mode being used so that's how it would be displayed on the TV).

[Gunstar]

No, the 9 color mode is 92x192 or possibly 92x240 with overscan? But I don't think overscan is accessible by BASIC.

 

The problem with your restrictions for image conversion is that unlike every other 8-bit micro out there, the 8-bit Atari's were specifically designed for DLI's and mixing graphic modes to get the best graphics out of the system and more color than any other 8-bit. There are TONS of converters that use mixed graphic modes and other purposely built-in Atari graphic "tricks" to get the best out of Atari graphics and color palette/depth. The restrictions you require are not fair to the Atari and the way it was engineered to work, and if you stick with the very basics, it has both hands tied behind it back and of course other weaker graphic machines will look comparable or better than Atari under your restrictions. 

 

You might just as well be asking for C64 SID music conversions to compare to Atari's Pokey and other micro's sound chips, but say that the music has to be restricted to half the SID's Octaves and use only square wave, then compare to other 8-bit sound conversions of the same tune with no restriction to their sound chips.

 

Edited December 20, 2021 by Gunstar

[oky2000]

I am doing a video on home computer graphic chips and how a person writing their own BASIC programs could have used their machine back in 1982-1984 to display digitized images as people with ST's and Amigas were doing 3-5 years later. All I care about is approx 40 column by 24 rows or 20 column by 24 rows minimum resolutions. Below this resolution it is not detailed enough.

 

I will assume A8 highest resolution 40 column type screens (to display 320 pixel wide pictures) are limited to 2 colours per scanline and 4 colour per scanlines for double width fat pixels. This is something I can not replicate without a specific image converter even if the resulting DLI heavy images could be displayed in Atari built in BASIC without using any CPU time allowing for a complex parser to be run on the CPU. So I would need a tool for that. 

 

I am aware of palette swapping per scanline and even interlacing palettes, they are possible on almost all colour capable computers. I am the person who designed the 32 colours per even scanline 640x512 resolution 60hz palette interlace custom Amiga 1000 screen mode I designed.

 

 

[_The Doctor__]

I am totally confused as to what is being done or requested... Atari BASIC allows for ml routines to be used, either by character strings method or pokes... back 1980 we were doing this... it's the reality of it's universe... you have a multitude of artifacted graphics choices in conjunction with those other choices as well as players and missiles to help in coloration as well, also use-able through BASIC

 

 

[Mrshoujo]

APAC "mode" creates a screen display of 16 colors and 16 luminances interleaved. Pro: simulates 256 colors. Con: it's basically 80 column Graphics 9 in horizontal resolution.

 

Jeff Potter's GIF ('jiff') viewer programs can do RGB separation even up to the 160×192 resolution and then quickly flip between the 3 colored screens, but that yields 64 colors. Whereas in APAC ('All Points, All Colors'), it can appear to wiggle up and down by 1 scan line.

 

[oky2000]

40 minutes ago, _The Doctor__ said:

I am totally confused as to what is being done or requested... Atari BASIC allows for ml routines to be used, either by character strings method or pokes... back 1980 we were doing this... it's the reality of it's universe... you have a multitude of artifacted graphics choices in conjunction with those other choices as well as players and missiles to help in coloration as well, also use-able through BASIC

 

 

What every person in 1982/83 who bought a home computer to write their own programs in BASIC wanted to display, that's what I am doing

[oky2000]

34 minutes ago, Mrshoujo said:

APAC "mode" creates a screen display of 16 colors and 16 luminances interleaved. Pro: simulates 256 colors. Con: it's basically 80 column Graphics 9 in horizontal resolution.

 

Jeff Potter's GIF ('jiff') viewer programs can do RGB separation even up to the 160×192 resolution and then quickly flip between the 3 colored screens, but that yields 64 colors. Whereas in APAC ('All Points, All Colors'), it can appear to wiggle up and down by 1 scan line.

 

The task is to load pictures in and to display from within your BASIC program. No machine code must be needed, no little extra programs that did not exist in the home computer boom of 1983 (in the UK but most of EU too). If it is not per scanline based image that needs to be generated I can simulate the results with my paint program (although not ideal it's how I did the Amstrad ones with a 27 colour reference palette used). Again, not too sure but I think you can define a display list from Atari BASIC so that would also be OK if you can load in a bitmap into memory after setting up a display list once for each image to be loaded. If you can't do that in Atari BASIC in 1983/84 etc then it's of no use to people buying home computers to write their own graphic adventure games using the built in BASIC etc (obviously you can't write arcade games worth a crap in BASIC!!!)

 

From BASIC it would appear it is 320x192 in any 2 colours, and 160x192 it is any 4, I think it's quad pixel width for the 16 shades of single luminance or 16 luminance levels of 1/16 colours too I think for GTIA (which was on later 800s not just XL). The last mode there would be useful for 16 greyscale images for a monochrome graphic adventure. Again I am assuming those last two modes are freely manipulated in Atari BASIC for people who just bought a home computer to use.

 

 

[glurk]

There were LOTS of people doing things in Atari BASIC well BEFORE 1983/1984 that were quite advanced.  Some using PEEK and POKE, some more advanced using ML routines.  The magazines of the day were FULL of stuff like that, quite early.

 

[stepho]

Back in the day, it was common for BASIC programs to have a small machine code routine encoded as DATA statements.
The BASIC program would read these and then store them in some free RAM.
Or sometimes it would encode them as strings.

The BASIC program would then write a custom display list that causes the machine code routine to be called.
The routine would typically change the colour palette and exit quickly (ie short and sweet).

It was a pain in the backside to have to do hand assembly into numbers and then add these as DATA statements but it was all doable from BASIC and a bit of determination.
I learnt this technique circa 1984 from reading magazines.
For the readers who didn't want to handle assembly, the articles would just say "change the 78 in position 5 and the 92 in position 10 to the colours of your choice".
Easy!

 

But as you said, practically all platforms of the day did similar to get around limitations.

[Gunstar]

2 hours ago, oky2000 said:

What every person in 1982/83 who bought a home computer to write their own programs in BASIC wanted to display, that's what I am doing

Well, I was using BASIC and displaying pictures in 160x192, 4 colors per scan-line, up to 128 colors on screen at once in BASIC not only running a display list, but changing that display list on the fly 96 times per screen refresh. That's what the machines were made to do and could do, easily, in the Basic program while doing many other things. That's what I wanted and did display, in my own Basic programs. I didn't get my Atari until 1985, but what I did with it in Basic anyone else could do on an Atari 2-3 years before me. And that can be displayed on-screen slightly truncated at the bottom to allow for several lines of text, in a Basic text adventure game running a parser.

 

The problem is you have no understanding of Atari graphics and how Atari display lists work, it can easily do stuff, even in Basic that other computer's graphics, however they are displayed, just simply cannot do, period, let alone in their Basic's.

 

We've been attempting to explain this to you but you just aren't getting it, like it's too unbelievable for you to comprehend an 8-bit computer from 1979 could do, because the machines you grew up with couldn't.

 

Do you not know that the Atari 8-bit computer was designed by Jay Miner and is the predecessor to the Amiga that you are such and expert of and it's graphics that you made your own display mode?!? This should be easy for you to comprehend as the Amiga has many graphic traits that started on the Atari 8-bit computer and before it on the Atari 2600 that was also designed by Jay Miner. The Amiga was originally being designed for Atari as their next computer and/or console until Atari was sold to Jack Tramiel and all the players switched teams.

 

 

It reminds me of the story about when Christopher Columbus first found the new world, and could be easily seen by someone from shore, but for the native American's such things as ships were so other-worldly and unbelievable to them that they couldn't even see them right in front of them, their minds block the ships out instead of admitting to something so fantastic and out of the universal view to them. Only the tribe's wise man had a mind open enough to register what he was seeing and he had to specifically point them out to the rest before their "eyes were open."

Edited December 21, 2021 by Gunstar

[Gunstar]

@oky2000

Quote

Do you not know that the Atari 8-bit computer was designed by Jay Miner and is the predecessor to the Amiga that you are such and expert of and it's graphics that you made your own display mode?!? This should be easy for you to comprehend as the Amiga has many graphic traits that started on the Atari 8-bit computer and before it on the Atari 2600 that was also designed by Jay Miner. The Amiga was originally being designed for Atari as their next computer and/or console until Atari was sold to Jack Tramiel and all the players switched teams.

If Atari had not sold out and stayed in business, and if Jack had not been ousted from Commodore, and purchsed Atari, not only would the Amiga have been an Atari machine, but the ST line, designed by the Commodore engineers that were a part of the Vic-20 and C64 computer design teams, which is the actual spiritual successor to the VIC and C64, would have basically been what Commodore's next computer would have been if Jack and the engineers were still there. Though it would have been better, because if it were designed under the Commodore brand, it could have had a SID II and a VIC III for sound and graphics and would have given the Atari Amiga a real run for it's money. But they didn't have the time at Atari, with only months to throw something together to compete with the Amiga that was in design for years, or the rights at Atari for those MOS custom chips, so they had used off-the shelf sound and graphic hardware instead that paled to the Amiga's graphics and sound. (once people knew how to tap Amiga's graphic potential). The ST, though lacking the incredible graphics and sound hardware of the Amiga, is actually quite amazing in it's own right considering how quickly it was designed. But I'd still rather have an Amiga any day.

 

Jay Miner RULZ!

 

P.S. I still laugh when I read the old ST ads from back then. The old "We built it for you America" ads with Sam Tramiel's quote "We promised, we delivered. With pride, determination, and good-old ATARI know-how."

 

Uhh...wouldn't that be good-old COMMODORE know-how? LOL! It's my understanding that Commodore bought "good-old ATARI know how" when they got the Amiga computer from paying off Amiga's debts to Atari.

 

Elvis has left the building...and Cat Steven's has entered...

Edited December 21, 2021 by Gunstar

[Irgendwer]

9 hours ago, oky2000 said:

I am doing a video on home computer graphic chips and how a person writing their own BASIC programs could have used their machine back in 1982-1984 to display digitized images as people with ST's and Amigas were doing 3-5 years later.

Like others said, it was quite common even in that period to have small ML routines allowing to display 256 colors with interleaving or interlaced techniques.

(E.g. see the type in listings in this German magazine for a 256 color paint program and Mandelbrot-fractal creator: Happy Computer 2. Atari Sonderheft)

 

But if you ask for a plain graphics mode, without any restriction or ML (sub-)programs, the most natural way for displaying digitized images was using "GRAPHICS 9": 80x192 (quadruple wide) pixels in 16 shades of grey.

 

Edited December 21, 2021 by Irgendwer

[drpeter]

8 hours ago, oky2000 said:

The task is to load pictures in and to display from within your BASIC program. No machine code must be needed, no little extra programs that did not exist in the home computer boom of 1983 (in the UK but most of EU too). If it is not per scanline based image that needs to be generated I can simulate the results with my paint program (although not ideal it's how I did the Amstrad ones with a 27 colour reference palette used). Again, not too sure but I think you can define a display list from Atari BASIC so that would also be OK if you can load in a bitmap into memory after setting up a display list once for each image to be loaded. If you can't do that in Atari BASIC in 1983/84 etc then it's of no use to people buying home computers to write their own graphic adventure games using the built in BASIC etc (obviously you can't write arcade games worth a crap in BASIC!!!)

 

From BASIC it would appear it is 320x192 in any 2 colours, and 160x192 it is any 4, I think it's quad pixel width for the 16 shades of single luminance or 16 luminance levels of 1/16 colours too I think for GTIA (which was on later 800s not just XL). The last mode there would be useful for 16 greyscale images for a monochrome graphic adventure. Again I am assuming those last two modes are freely manipulated in Atari BASIC for people who just bought a home computer to use.

 

You can obviously set the constraints of your project how you like.

 

I would however make the following observations:

 

1) Programming a decent graphic adventure game from scratch in BASIC is no enterprise for a novice programmer, regardless of how the graphics are loaded and displayed, so stipulating that advanced graphic programming techniques are barred seems possibly somewhat inconsistent.

 

2) The way the Atari hardware is designed makes it (relatively) straightforward to set up advanced multi-mode graphics and CPU-assisted 'on-the-fly' graphics techniques from BASIC while occupying minimal CPU bandwidth.

 

3) The use of player-missile graphics (hardware sprites) from Atari BASIC allows the introduction of up to 5 extra colours to areas of an image at up to 160x192 resolution, even without invoking 'on-the-fly' CPU techniques.

 

4) Given that any BASIC program is in any case dependent on calling numerous machine language OS routines 'under the hood', proscribing the use of widely-used and available non-OS machine language calls might be somewhat arbitrary

 

All that said, if one were to display graphics at the most rudimentary level of BASIC programming, one would be limited to 320x192 in 1 hue and 2 luminances; 160x192 in 4 colours displayed independently in any pixel from a palette of 128 (NTSC) or 120 (PAL); 80x192 in 9 colours displayed independently in any pixel from a palette of 128 (NTSC) or 120 (PAL); 80x192 in 16 luminances of one from 16 (NTSC) or 15 (PAL) hues, or 80x192 in 1 (of 8 ) luminances and 15 (NTSC) or 14 (PAL) hues, plus black.

 

For displaying digitised images, the monochrome 80x192 mode is probably going to be the most successful.

 

However, loading and displaying any high-res images in a timely manner from BASIC would require calling a custom machine code loader or some advanced jiggery-pokery using OS routines....  you can see where this is going.  There is no Atari BASIC command that will simply load and display an image from file.  I doubt the other systems mentioned have such a command either....

 

See the Altirra Hardware Reference Manual for more details

Edited December 21, 2021 by drpeter

[+Philsan]

9 hours ago, oky2000 said:

I am doing a video on home computer graphic chips and how a person writing their own BASIC programs could have used their machine back in 1982-1984 to display digitized images as people with ST's and Amigas were doing 3-5 years later.

Not very related to your original question, but here's how A8 could display Amiga graphics:

 

 

Images are converted on PC and there's no real background music, but that could be added (interrupted while loading).

[bfollett]

14 hours ago, oky2000 said:

OK well I found a 256 colour GTIA palette and used that to render a 160x200 style resolution image with just those colours, then reduced the total colours to 9 and did a pixel resize to the original resolution (because it's a double width pixel mode being used so that's how it would be displayed on the TV).

The converted image you posted is over 7400 colors.  A couple of notes.  The standard Display list has 192 lines.  If you want a 200 line image you'd have to create a custom display list(That can be done from Basic).  Second the 9 color mode has a 128 colors in its palette not 256.  It has the same hues but half the lumens of the 256 color palette.

[zzip]

11 hours ago, oky2000 said:

The task is to load pictures in and to display from within your BASIC program. No machine code must be needed, no little extra programs that did not exist in the home computer boom of 1983 (in the UK but most of EU too). If it is not per scanline based image that needs to be generated I can simulate the results with my paint program (although not ideal it's how I did the Amstrad ones with a 27 colour reference palette used). Again, not too sure but I think you can define a display list from Atari BASIC so that would also be OK if you can load in a bitmap into memory after setting up a display list once for each image to be loaded. If you can't do that in Atari BASIC in 1983/84 etc then it's of no use to people buying home computers to write their own graphic adventure games using the built in BASIC etc (obviously you can't write arcade games worth a crap in BASIC!!!)

 

From BASIC it would appear it is 320x192 in any 2 colours, and 160x192 it is any 4, I think it's quad pixel width for the 16 shades of single luminance or 16 luminance levels of 1/16 colours too I think for GTIA (which was on later 800s not just XL). The last mode there would be useful for 16 greyscale images for a monochrome graphic adventure. Again I am assuming those last two modes are freely manipulated in Atari BASIC for people who just bought a home computer to use.

 

 

I used to program lots of Atari stuff back in the 80s.  It was much easier to integrate DLI machine language routines into your basic code than it was to write a loader for the graphics formats that you are talking about.   The Display lists themselves could be manipulated in BASIC without any machine language.

 

In fact I would say the new BASIC programmer who just brought the computer home was either writing games using ATASCII graphics, or using PLOTS and DRAWTOs in bitmapped modes.   That was much easier than loading in bitmapped graphics, or using DLIs since both were rather advanced graphics topics for the time.

[zzip]

10 hours ago, stepho said:

For the readers who didn't want to handle assembly, the articles would just say "change the 78 in position 5 and the 92 in position 10 to the colours of your choice".

exactly this type of routine was what, 10 bytes give or take for a data statement?  And it effectively created new color registers that you could manipulate from BASIC the same way as any of the built-in color registers

[bfollett]

Here's a 9 color conversion at 80X200 resolution:

[zzip]

12 hours ago, oky2000 said:

If you can't do that in Atari BASIC in 1983/84 etc then it's of no use to people buying home computers to write their own graphic adventure games using the built in BASIC etc (obviously you can't write arcade games worth a crap in BASIC!!!)

The easiest approach to graphic adventure games in BASIC would be top down, such as Ultima, Apshai, 2600 Adventure.   You would use one of the character modes and redefine the character set to be graphical.   Two of the multi-color character modes give an extra color to work with.  You could use P/M graphics for the player and monsters, or stick with the character set like Ultima does.

 

The type of text/graphics adventure that you might be thinking of is a bit more challenging.   I tried to make one.   Problem one was getting a loader that could load in the bitmap formats that the paint program I used could export.   I did write write a loader for Koala painter format, but in BASIC that was slow.   So I rewrote it in assembly.

 

But the other issue was there really wasn't enough disk space to store that many images for a lot of locations,  even with a compressed format like Koala.   It would require a fair bit of disk swapping.

 

I noticed a lot of the commercial graphic adventures did not use bitmapped graphics formats at all, instead they stored all the PLOT/DRAWTO/FILL coordinates and would draw the image in realtime.   I'm sure this saved a lot of diskspace, but you would need a paint program that operated in this way to create the images.