Is it possible to have colored text like a C64?

[Heaven/TQA]

but you could easily use gr.1 or gr. 2 to get coloured chars.

[Goochman]

10x10 text screen isnt like the C64

 

Those chuky modes made games look 70ish IMHO

[SeaGtGruff]

This was one thing that I really hated not having on the 8bit way back - I was just a Basic coder so getting colored text was really difficult

Even though they "just" use GRAPHICS 0, the USR routines I mentioned are (in my humble but admittedly biased opinion) very cool, since they let any Atari BASIC programmer set the foreground/background colors for any row of GRAPHICS 0 text, along with "auxiliary" foreground/background colors on each row-- without having to know about DLIs, VBIs, or PM graphics! As soon as I figure out what's wrong with the box-drawing routine, I'll post the code, with some screenshots to show the sorts of things you could do with it.

 

Michael

[ZylonBane]

You're very limited with GR. 0 thanks to the badlines.

"Badlines"?? Get your mind out of the C64, kid.

[supercat]

"Badlines"?? Get your mind out of the C64, kid.

 

Does the Atari's display controller not have to do 40 extra cycles at the start of each row of text? Unless the machine is wasting those 40 cycles on every scan line (for a total of 80) I don't see any alternative.

[ZylonBane]

I have no idea. Mainly my point is that "badlines" is C64 terminology.

[Rybags]

Kid? I think I'm older than almost everyone here.

 

Badline might be a C-64 term but it's equally as valid as calling PMGs sprites.

 

The Atari loses 49 cycles minimum on a Gr. 0 line. Potentially, the worst case DMA penalty is 105 cycles (of 114 available) in the case of a Vscrolled line (VSCROL=7) in widescreen or HSCROLL mode with the following line having an LMS instruction, and PMGs enabled:

 

48 character fetches

48 charset bitmap fetches

3 DList fetches

5 PMG fetches

1 refresh cycle

 

The C-64 suffers less although it's CPU only has one cycle corresponding per character cell where Atari has 2.

 

But the C-64 can also have a bad badline if you throw sprites into the equation.

Edited February 23, 2007 by Rybags

[SeaGtGruff]

Okay, I fixed the problem with my "USR" routines-- it was a single incorrect byte (20/$14, which was supposed to be 200/$C8/"INY"). Here are the programs, in "LIST" format, so you can view them in a text editor, and "ENTER" them into your Atari or emulator from your PC hard drive. I modified the filenames by tacking on a ".TXT" extension, to make sure the AtariAge web site didn't have a fit when I uploaded them, so you'll need to remove the ".TXT" extension. I suggest "SAVE"ing the files with ".BAS" extensions after you've "ENTER"ed them into your Atari-- except for the assembly listing, of course.

 

JAZZING0.LST.TXT (JAZZING0.BAS)

 

This program contains the data for creating the "USR" routines. It reads the data and writes each byte to a disk file named "JAZZING.USR," which can then be loaded by your Atari BASIC programs so you can call the "USR" routines in your programs.

 

JAZZING1.LST.TXT (JAZZING1.BAS)

 

This is just a skeleton program, which you can use as a template for creating your own Atari BASIC programs that use the "USR" routines. It contains a "USR" routine named "MEMLOAD" which is used to load the other "USR" routines into memory. You can also use the "MEMLOAD" routine to load other binary files into memory if you wish-- e.g., custom character sets.

 

If you use the "JAZZING1.BAS" program as a skeleton or template, you must add the lines for your own Atari BASIC code between lines 2 and 32699, noninclusive (i.e., from 3 through 32698).

 

You can also run the "JAZZING1.BAS" program by itself if you want to play with the "USR" routines in the immediate command mode.

 

JAZZING2.LST.TXT (JAZZING2.BAS)

 

This is a little demo program that randomly sets the colors for each line, and draws boxes of color on the screen. There's a screenshot below showing how the screen looks after I let the program run for a little while.

 

JAZZING3.LST.TXT (JAZZING3.BAS)

 

This is another little demo program that displays 97 different colors on the screen-- 4 colors on each of the 24 rows, plus the border color. There's a screenshot below showing how the screen looks.

 

JAZZING.ASM.TXT (JAZZING.ASM)

 

This is a 6502 assembly listing of the "JAZZING.USR" file, in a DASM-compatible format, so you can study the code if desired.

 

GENERAL INFORMATION AND INSTRUCTIONS

 

The names of the "USR" routines can be changed to suit your preferences; the only reason I gave them names at all was to make it easier to call them, since it's easier to remember a symbolic name than to remember a 5-digit memory address.

 

The "JAZZING.USR" routines are loaded at address 37888 ($9400). The top of available memory is lowered to 36864 ($9000).

 

MEMLOAD

 

As stated above, this "USR" routine isn't contained within the "JAZZING.USR" file. Instead, it's found in the "JAZZING1.BAS" skeleton or template, and is used to load the "JAZZING.USR" routines into memory. The "MEMLOAD" routine is stored in a string variable. To use the "MEMLOAD" routine for loading other things into memory-- e.g., character sets-- use the following commands:

OPEN #file_number,4,0,"file_name"

dummy_variable=USR(MEMLOAD,file_number,starting_address,length)

CLOSE #file_number

 

INSTALL

 

This routine modifies the "GRAPHICS 0" display list so that a display list interrupt will be performed for each row of text, then sets up the player/missile graphics, and sets up the display list interrupt and vertical blank interrupt. It takes no parameters, and it (as well as the other "USR" routines) will abort if an incorrect number of parameters is passed to it. It will also abort if "GRAPHICS 0" isn't the current display mode. After it successfully sets up everything for the "USR" routines, it falls through into the next routine ("ENABLE"). If you change display modes in your program, and then want to switch back to the "GRAPHICS 0" mode and use the "USR" routines, you'll need to reinstall them with the following commands:

GRAPHICS 0

dummy_variable=USR(INSTALL)

 

ENABLE

 

This routine activates the player/missile graphics, display list interrupt, and vertical blank interrupt after they've been set up. If you deactivate them using the next routine ("DISABLE"), and then want to reactivate them again, you can use the following command:

dummy_variable=USR(ENABLE)

 

DISABLE

 

This routine temporarily deactivates the player/missile graphics, display list interrupt, and vertical blank interrupt, without actually destroying the modifications to the "GRAPHICS 0" display list, etc. Note that this doesn't wipe out any of the colors you've set for the individual text rows, nor does it change any of the inverse character bits or player/missile bits, so if you deactivate the routines, and then reactivate them later, all of the colors and player/missile pixels will reappear just as they were before-- although the inverse character bits may be different, depending on any changes you may have made to the screen display. To temporarily deactivate the routines, use the following command:

dummy_variable=USR(DISABLE)

 

SCREEN

 

This routine sets the color (hue and luminance) of the background (or screen), for a range of text rows. Note that the rows are numbered from 0 (topmost row) to 23 (bottommost row). If you want to change just one row, then specify the same row number as both the starting and ending row. Note that the row numbers should be given in increasing order (i.e., if the starting row number is greater than the ending row number, then only the starting row will be changed). The color can be expressed as a decimal value, or as a mathematical expression. The syntaxes for this routine are as follows:

dummy_variable=USR(SCREEN,color,starting_row,ending_row)

dummy_variable=USR(SCREEN,16*hue+luminance,starting_row,ending_row)

 

TEXT

 

This routine sets the luminance of the foreground (or text), for a range of text rows. Note that the foreground color doesn't have a separate hue of its own in "GRAPHICS 0"-- the foreground is always the same hue as the background. You can try to specify a different hue if you want to, but the hue value will have no effect. Otherwise, the syntax is the same as for the "TEXT" routine:

dummy_variable=USR(TEXT,luminance,starting_row,ending_row)

dummy_variable=USR(TEXT,color,starting_row,ending_row)

dummy_variable=USR(TEXT,16*hue+luminance,starting_row,ending_row)

 

PLAYER

 

This routine sets an alternate background color using the player/missile graphics. The alternate (or second) background color can have a different hue and luminance than the "SCREEN" color, but the text will always have the luminance specified by the "TEXT" color, so you need to be sure that the alternate background (or "PLAYER") color has a different luminance than the "TEXT," otherwise any text you type on that row will be "invisible" when using the "PLAYER" color. The syntax is the same as for the "SCREEN" and "TEXT" routines:

dummy_variable=USR(PLAYER,color,starting_row,ending_row)

dummy_variable=USR(PLAYER,16*hue+luminance,starting_row,ending_row)

 

AREA

 

This routine is different than the three preceding routines, in that it doesn't set any colors. Instead, it draws a rectangular area or box on the screen by setting the appropriate inverse character bits and the player/missile bits. In other words, it draws a highlight area on the screen. Note that if the colors are set differently for the various rows encompassed by the "AREA," then the "AREA" will be drawn with different colors on the rows. You should be careful when using the "AREA" routine, because it can affect any text you enter on the screen, and any text you enter (or "PRINT") on the screen can affect the "AREA," depending on whether or not you've drawn an "AREA" using inverse characters. Furthermore, scrolling the screen can also affect the "AREA," since the inverse bits will scroll as the text scrolls, but the display list interrupt colors will not scroll. Thus, the best way to use this routine is to "PRINT" your text on the screen first, then use the "AREA" routine to highlight the desired portions of your text. You can draw four "AREA" types, numbered 0 to 3-- normal text that has the inverse character bits and player/missile bits turned off (type 0); inverse text that has the player/missile bits turned off (type 1); alternate-colored text that has the inverse bits off but the player/missile bits on (type 2); and alternate-colored inverse text that has both the inverse and player/missile bits turned on (type 3). The syntax is as follows:

dummy_variable=USR(AREA,type,starting_column,starting_row,ending_column,ending_row)

 

EXPERIMENTING WITH THE ROUTINES

 

If you want to play around with the routines in the immediate command mode, you should first "RUN" the "JAZZING0.BAS" program to create the "JAZZING.USR" file, then "RUN" the "JAZZING1.BAS" program to load, install, and activate the routines. Then you can start entering commands on the screen to see what happens.

 

SCREENSHOTS

 

After letting "JAZZING2.BAS" run for a few seconds...

 

 

After running "JAZZING3.BAS"...

 

 

After running "JAZZING1.BAS" and then entering some immediate commands...

 

 

Michael

JAZZING0.LST.TXT

JAZZING1.LST.TXT

JAZZING2.LST.TXT

JAZZING3.LST.TXT

JAZZING.ASM.TXT

[Rybags]

Just had a quick look at your ASM routine.

 

No need to PHP/PLP - In VBlank the OS caller doesn't care. In DLI the RTI takes care of it.

 

I assume you're using PMGs in the traditional sense (ie getting ANTIC to fetch the images from memory).

 

You could be tricky and just have a 5x24 byte bitmap array and plug the graphics registers yourself in the DLI - timing might be an issue, but you'd save on RAM usage.

[SeaGtGruff]

Just had a quick look at your ASM routine.

 

No need to PHP/PLP - In VBlank the OS caller doesn't care. In DLI the RTI takes care of it.

 

I assume you're using PMGs in the traditional sense (ie getting ANTIC to fetch the images from memory).

 

You could be tricky and just have a 5x24 byte bitmap array and plug the graphics registers yourself in the DLI - timing might be an issue, but you'd save on RAM usage.

I haven't tried to optimize the code since I wrote it many years ago, but I saw tonight that there's at least one spot where I could save a byte by using BEQ (right after a BNE) instead of JMP. I'm sure there might be other places where I can optimize.

 

My memory is hazy, so I don't remember if I actually tried using the 5x24 PM trick, but I know that I did think about using it. In fact, I haven't looked carefully to see if I'm doing that here or not. It's possible that I tried it and ran into the timing problem you mentioned. I do know that I mulled it over, and one advantage of using the standard PM graphics is that characters could use both color sets within a single character-- such as the top half of the character using the normal background color, and the bottom half using the PM color. I'm not sure how useful that would be, but it could look pretty neat if the colors weren't too different (since too much difference might detract from the readability of the text).

 

I also thought about a variation where the players would have their own colors, and could also be positioned individually instead of having set positions, but there could be timing problems there as well. I did see that used in a type-in text adventire in one of the Atari computer magazines, with the PM graphics used to get different colored "windows" on the screen for things like the inventory list, the location or "room" description, the list of possible exits, and the command window-- but in that case, the windows were stationary, and the colors didn't change from line to line in the window, so there was no need for DLIs.

 

Michael

[SeaGtGruff]

I don't remember if I actually tried using the 5x24 PM trick, but I know that I did think about using it. In fact, I haven't looked carefully to see if I'm doing that here or not.

Duh, of course I'm not using that here, I can tell just by looking at the DLI! I think maybe I did try it, because I thought it was a really clever trick-- but then ran into timing problems.

 

This wasn't my first machine code on the Atari, but it was certainly the most ambitious thing I did, and I was quite pleased with the results-- more so because it was kind of difficult for me to do back then. (The harder something is to do, the more satisfying it is to accomplish!) Plus, I learned a lot while doing it-- how to do VBIs and DLIs, how to write USR routines, etc. My main goal, aside from the obvious one of getting more colors in GRAPHICS 0, was to do it in such a way that it would be easy for anyone to use in their own Atari BASIC programs. Hopefully I succeeded.

 

Michael

[+Larry]

Okay, I fixed the problem with my "USR" routines-- it was a single incorrect byte (20/$14, which was supposed to be 200/$C8/"INY"). Here are the programs, in "LIST" format, so you can view them in a text editor, and "ENTER" them into your Atari or emulator from your PC hard drive. I modified the filenames by tacking on a ".TXT" extension, to make sure the AtariAge web site didn't have a fit when I uploaded them, so you'll need to remove the ".TXT" extension. I suggest "SAVE"ing the files with ".BAS" extensions after you've "ENTER"ed them into your Atari-- except for the assembly listing, of course.

 

(snip...)

 

 

I thought that having only 128 colors then 256 colors was limiting. And now I won't have to stand on my head...

 

Actually, thanks so much for the nice routines and pics. WELL DONE!!!

 

-Larry

[SeaGtGruff]

thanks so much for the nice routines and pics.

You're welcome! I should point out in case it wasn't obvious, that in the BASIC programs where you see PRINT " ", you should replace it with PRINT "{clear_screen}", because the Atari {clear_screen} character didn't translate into ASCII text. Also, I'll see if I can optimize the routines and make them relocatable, and document the memory addresses used for the color tables, etc.

 

Michael

[Cybernoid]

My Ansiterm will do 40 column text with 16 colors for the foreground color and 16 colors for the background color. It uses Antic mode E and a 4 pixel wide font (similar to the software 80 column trick with Antic mode F). It also used interlaced mode (flipping between 2 screens for the 16 colors), however you could easily produce a 40 column screen with 4 colors for the foreground and 4 colors for the background.

 

For example, you could have white, red, blue and black colors, then you can have foreground/background like red on black, blue on white, etc...

 

 

Executible w/ R:handler

http://www.atariage.com/forums/index.php?a...st&id=67655

[Gunstar]

Yes, it's totally possible to display full color text, even more colorful than the C64, without annoying color bars, but the example I have isn't in a text mode, and it probably took a lot of work and tricks, but it looks damn good to me. the example is the menu screen of T-34 The Battle, from Mirage, a Polish developer (T-34 is a famous Russian tank):

[Rybags]

That's just Antic mode E (Gr. 15)

 

The text looks better because they've used a variable size font, ie-more than 3 pixels wide for letters like "M" that need it.

Edited March 14, 2007 by Rybags

[TMR]

Yes, it's totally possible to display full color text, even more colorful than the C64, without annoying color bars, but the example I have isn't in a text mode, and it probably took a lot of work and tricks, but it looks damn good to me.

 

The original question was about mode 2, in the C64 equivalent it is possible to change both the foreground and background colours independently of each other every eight pixels. In multicolour bitmap mode, the C64 can replicate pretty much everything bar the specific palettes in that screenshot whilst the CPU stands idle.

[Shawn Jefferson]

I think Atari should have stepped up with a color text mode when they released the XL series. Would have helped them compete with Commodore at that time, and made possible a bunch of other things. oh well.

 

[+Larry]

I think Atari should have stepped up with a color text mode when they released the XL series. Would have helped them compete with Commodore at that time, and made possible a bunch of other things. oh well.

 

 

It would be interesting to know what Atari's thinking and overall plan was. Although the XL series is slightly more capable than the 400/800 series, it still strikes me as a short-term upgrade of their product line, "on-the-cheap."

 

-Larry

[Rybags]

The problem with Atari was that they didn't really do anything new aside from the ST in the 1980s.

 

The XL and XE were progressive upgrades that didn't exactly require engineering genius. 5200 just a cutdown 400, 2600jr just natural progress of smaller componentry.

 

And the 7800, Jag and Lynx were picked up from outside sources and just packaged and marketed by Atari (albeit rather badly marketed).

 

 

As for extra text capability - they would have done well to have left out the descender mode (3) and used it instead as a special "colour buffer" mode.

 

Use the first scanline to read in background colour information and buffer it, second scanline for foreground colour information and buffer it.

 

Then have a normal 8 lines of Gr. 0 mode, using the previously buffered colour information allowing any combination of bg/fg colour per character cell.

 

Problem is, they would have needed a workaround for the 2 luminences of 1 colour problem.

[Allas]

I've always seen map colors as a artifact hardware that give more colors to break the 40 bytes barrier per line.

 

C64s have the 12-bit data bus video that improve this technique.

 

I think Atari don't need the map color as enhancement, only needs to enhacen the speed memory to let transfers at 80 bytes per line. With this the ANTIC could represent new modes with more colors per line. In med-res 89 colors per line, and hi-res 4 colors per line. Text modes would be improve with extra bytes per line, displaying more colors.

[Fröhn]

I think Atari don't need the map color as enhancement, only needs to enhacen the speed memory to let transfers at 80 bytes per line.

The Antic uses exactly the same technology in character mode as the C64 to transfer 80 bytes per line. It would have been a minor change to use the same circuitry also for bitmap mode and interpret screen matrix data as color data.

[Rybags]

The method is a bit different. The 6510 is clocked at half the memory speed so that bitmap/charmap accesses are transparent, and in character mode the colour nybbles are synchronous with the character matrix pointers.

 

Still would have been a good idea for Atari to be able to use a matrix in bitmap modes - combine that with 16 palette entries so that you get a variety of combinations. 4 colour modes could assign 4x4 registers allowing independant colour sets for each pixel value.

[tebe]

Is it possible to have colored text like a C64?

similar, but not identical

[Gunstar]

I think Atari should have stepped up with a color text mode when they released the XL series. Would have helped them compete with Commodore at that time, and made possible a bunch of other things. oh well.

 

 

It would be interesting to know what Atari's thinking and overall plan was. Although the XL series is slightly more capable than the 400/800 series, it still strikes me as a short-term upgrade of their product line, "on-the-cheap."

 

-Larry

 

Atari's ORIGINAL overall plan was to release the Atari 1000/1000XL, the "sweet sixteen" computer that there is a thread about it's motherboard on AA right now. Though I still don't think it had color text, it would have had so much else over the C64 that colored text would have been a non-issue. But it was scaled back to the 1200XL which is essentially what the 800XL is too. But with the 800XL the included the rear expansion bus just in case they wanted to bring back some of the 1000's original advancements in modular form, which also never happened, but proto-types do exist. It became "on-the-cheap" later, it wasn't planned from the beginning. Then the Tramiels came along and focused on the 16-bit line and went with a PLANNED "on-the-cheap" product line (which was even lower quality than the XL's). But I do think that the design of the original 1000 would have had the possibility of upgrading to color text with ease, with an add-on card.

Edited March 17, 2007 by Gunstar