F18A programming, info, and resources

[matthew180]

You will have to unlock the F18A before you can use any of the enhanced color capabilities.  You can set T80 mode while the F18A is locked, but it is restricted to the original T80 functionality, i.e. one FG/BG color for all the tiles.

 

Once you unlock the F18A, you can then use the enhanced T80 features.  I'm sure some examples of doing this have been posted, let me see if I can find one.  Also note that when the F18A is unlocked, poorly written software can corrupt the VDP registers.  Also, if you use console routines you will have to follow the console rules for the VDP, as Lee pointed out already; that is why you had to put a copy of VR01 into memory location >83D4.

[GDMike]

Just fyi only, I am currently happy with Text mode only as post #697 suggests, but in the future I will be hitting color management a bit harder in my quest. 

And the current program using only text isn't complete yet, maybe by E.O.Y., of course I'm very happy with the F18A. It's just a learning curve I've got to carve out, like I had with learning SAMs.

[+RXB]

RXB 2021 has CALL POKER(vdp-register-number,value) this was increased for using the F18 from RXB.

Register number allows 0 to 63 registers.

The value ranges from 0 to 255.

 

          Programs
 
          This sets text mode.              | >100 CALL POKER(7,244,1,240)
          This is a delay loop.               | >110 FOR L=1 TO 500 :: NEXT L
          This sets multi color mode      | >120 CALL POKER(1,232)
          This is a delay loop.               | >130 FOR L=1 TO 500 :: NEXT L
          This sets bit map mode.         | >140 CALL POKER(0,2,1,2)
          This is a delay loop.               | >150 FOR L=1 TO 500 :: NEXT L
          This sets normal XB mode.     | >160 CALL POKER(0,0)

 

I do not know the values to make the F18 work for modes so will wait for people using BETA of RXB 2021 to tell me.

[+TheBF]

1 hour ago, RXB said:

RXB 2021 has CALL POKER(vdp-register-number,value) this was increased for using the F18 from RXB.

Register number allows 0 to 63 registers.

The value ranges from 0 to 255.

 

          Programs
 
          This sets text mode.              | >100 CALL POKER(7,244,1,240)
          This is a delay loop.               | >110 FOR L=1 TO 500 :: NEXT L
          This sets multi color mode      | >120 CALL POKER(1,232)
          This is a delay loop.               | >130 FOR L=1 TO 500 :: NEXT L
          This sets bit map mode.         | >140 CALL POKER(0,2,1,2)
          This is a delay loop.               | >150 FOR L=1 TO 500 :: NEXT L
          This sets normal XB mode.     | >160 CALL POKER(0,0)

 

I do not know the values to make the F18 work for modes so will wait for people using BETA of RXB 2021 to tell me.

You could try plugging these ones in Rich.   

I got them from TurboForth and tried them in my system with a color change.  It comes up in 80 columns with black on cyan text.

\ HEX values 
       04   \ VR1
       70   \ VR2
       03   \ VR3
       E8   \ VR4
       01   \ VR5
       06   \ VR6
       00   \ VR7
       17   \ VR8
       88   \ VR9
       00   \ VR10
       00   \ VR11
       00   \ VR12
       94   \ VR13
       10   \ VR14
       00   \ VR15

 

[+RXB]

5 minutes ago, TheBF said:

You could try plugging these ones in Rich.   

I got them from TurboForth and tried them in my system with a color change.  It comes up in 80 columns with black on cyan text.

\ HEX values 
       04   \ VR1
       70   \ VR2
       03   \ VR3
       E8   \ VR4
       01   \ VR5
       06   \ VR6
       00   \ VR7
       17   \ VR8
       88   \ VR9
       00   \ VR10
       00   \ VR11
       00   \ VR12
       94   \ VR13
       10   \ VR14
       00   \ VR15

 

Hex values or Decimal?

Will give it a try after I convert them

 

 

Edited December 3, 2021 by RXB
missing text

[+RXB]

Ok there is a issue you are changing to 80 column and XB has only a 40 column editor and I get a error as you would expect.

This also changes the memory map so of course crashes anything in XB as you have moved tables needed for XB to function.

 

I think you could use the F18 as long as you do not try to move memory around much after all XB has to have places coded to be used.

I was thinking you could do things like sprite commands or color pallets using CALL POKER as long as you do not make huge memory changes.

Edited December 3, 2021 by RXB

[Tursi]

5 hours ago, RXB said:

Ok there is a issue you are changing to 80 column and XB has only a 40 column editor and I get a error as you would expect.

This also changes the memory map so of course crashes anything in XB as you have moved tables needed for XB to function.

 

I think you could use the F18 as long as you do not try to move memory around much after all XB has to have places coded to be used.

I was thinking you could do things like sprite commands or color pallets using CALL POKER as long as you do not make huge memory changes.

Yeah, it seems like a tricky thing to use, but never underestimate how tricky someone can be with the right tool!

 

One nice effect of this is the ability to use the GPU from RXB, which could be used to accelerate all sorts of things. Just POKEV the program into VDP somewhere safe, then POKER to start it. Since XB doesn't have access to the extra 2k of GPU memory, you could even just POKEV your program into video or character memory and then let the GPU move it out of the way by itself. (Actually, in character memory I guess you could even just CALL CHAR it ).

 

 

Edited December 4, 2021 by Tursi

[+TheBF]

18 hours ago, RXB said:

Hex values or Decimal?

Will give it a try after I convert them

 

 

Would there be any point in giving RXB a HEX() function?  (Like INT() but accepts HEX integer text)

It's pretty ham dandy in other languages.  

[+RXB]

5 hours ago, TheBF said:

Would there be any point in giving RXB a HEX() function?  (Like INT() but accepts HEX integer text)

It's pretty ham dandy in other languages.  

We'll see what you can do with this:

 

 

 

RXB 2021 BETA.zip

[+TheBF]

1 hour ago, RXB said:

We'll see what you can do with this:

RXB 2021 BETA.zip 8.57 MB · 3 downloads

Man that is a lot of system. Well done.

 

I see the CALL HEX() but I was wondering about something like this:

CALL PEEK(-31878,N) ! normal  XB

CALL PEEK(HEX(837A),N) ! Better XB

I don't know if you can create functions as extensions to the language versus sub-programs. 

I'm clueless about XB internals.

[+RXB]

22 minutes ago, TheBF said:

Man that is a lot of system. Well done.

 

I see the CALL HEX() but I was wondering about something like this:

CALL PEEK(-31878,N) ! normal  XB

CALL PEEK(HEX(837A),N) ! Better XB

I don't know if you can create functions as extensions to the language versus sub-programs. 

I'm clueless about XB internals.

Yea I have CALL HEX in RXB but working on a change so you can do VAL(">FEAD") using hex values just like XB3 does.

And may add it to other things down the line.

 

Example is like CALL PEEK(">A9BC",N) would use convert to -22084 thus all inputs could be either Decimal or Hex.

This would allow CALL LOAD, LINK, or most things to be either Decimal or Hex.

 

[ralphb]

Matthew, I have a feature request for the F18A:  Would it be possible to support more than two colors in text mode (40 and/or 80 columns)?  Since almost all applications use text mode, I think it would be really nice if we could, e.g., highlight or dim text on screen or set color accents that help with understanding and navigation.

 

I think the simplest solution (at least conceptually) would be to apply the graphics mode 1 color handling to text mode.  That way, one could create a second, third, ... charset in a different color.  A more advanced approach would be to mark individual rows or regions on the screen to show a different color, with a rather low limit on regions, to achieve something like a modern console with ANSI colors.

 

Do you think something like this would be possible and worthwhile?

[Asmusr]

2 hours ago, ralphb said:

Matthew, I have a feature request for the F18A:  Would it be possible to support more than two colors in text mode (40 and/or 80 columns)?  Since almost all applications use text mode, I think it would be really nice if we could, e.g., highlight or dim text on screen or set color accents that help with understanding and navigation.

 

I think the simplest solution (at least conceptually) would be to apply the graphics mode 1 color handling to text mode.  That way, one could create a second, third, ... charset in a different color.  A more advanced approach would be to mark individual rows or regions on the screen to show a different color, with a rather low limit on regions, to achieve something like a modern console with ANSI colors.

 

Do you think something like this would be possible and worthwhile?

It's already possible to add color using position based attributes.

[ralphb]

52 minutes ago, Asmusr said:

It's already possible to add color using position based attributes.

That's great, but could you elaborate on that, e.g., by giving an example?

[+9640News]

2 hours ago, ralphb said:

That's great, but could you elaborate on that, e.g., by giving an example?

 

I can't say with absolute certainty what "video mode" is being used, but @jedimatt42's Telnet program supports color ANSI and may be a start for an example.

[TheMole]

There's a spreadsheet attached to the first post outlining what all the registers do, that has been my main reference for everything F18A and has served me pretty well, but you do need to know what to look for.

 

Assuming you've already enabled 80 column mode (same as on the yamaha chips), then to be able to choose individual colors per character you need to enable "positional attributes" by setting the second least significant bit of VDP register 50 (0x32) to 1. The color table in VRAM then becomes the positional attribute table. Every byte in the positional attribute table then maps to a byte in the name table, one-to-one. So the positional attribute table will be exactly as large as the name table (80x24 bytes, in the case of 80 column text mode). Every byte in the positional attribute table in text mode represents the foreground and background colors: the high nibble contains the foreground, the low nibble contains the background.

 

So, to get in this mode, just do the following:

1. Enable 80 column text mode (the value for the bits denoted by a '?' will depend on other features you might need, such as VDP interupts. Use zeroes if you're not sure😞
   1. write 0x00011100 to VDP register 57 twice in a row (to unlock the F18A features and allow access to registers > 7)
   2. write 0x000?0100 to VPD register 1
   3. write 0x00?10000 to VDP register 2 (2 and 3 are to set 80 column mode)
   4. write 0x00000010 to VDP register 50 (to enable positional attributes)

 

Then, once in this mode to write text to the screen, you need to not only write a byte to the right location in the nametable (the character you want to display), you also need to write a byte to the positional attribute table (the foreground and background colors for the character).

 

Edited May 12 by TheMole

[ralphb]

9 minutes ago, TheMole said:

So, to get in this mode, just do the following: [...]

Thanks a lot, that really helps!  I was looking at the register list, but didn't really notice the POS_ATTR bit (nor would I have known what it does).

 

Edit: Also, it says ECM, which I thought does not apply to text mode.

Edited May 12 by ralphb

[matthew180]

@ralphb

Sorry for the late replay, but It looks like you got some answers.  The text modes cannot used the enhanced colors, but as noted there are per-tile attributes.  Once enabled you effectively have two name tables, one is the normal name table to specify what tile to show at each location.  The other is a parallel table that holds a byte to specify the fg/bg color for each tile position (i.e. each tile position on the screen has its own fg/bg color), but it does mean you have to manage both buffers when you move tiles around.

 

I realize the documentation is lacking, and I still cling to the idea that I will write some docs in time to still be useful to people.

 

Since I cannot cite a post number any more, here is a link back in this thread where Rasmus posted some photos of his demos:

 

https://forums.atariage.com/topic/207586-f18a-programming-info-and-resources/?do=findComment&comment=3226600

 

In the middle is an example of the position attributes for the T80 mode.  IIRC, Tim's terminal program also supports full ANSI using T80 and tile-attributes, and JediMatt did something with it as well (but clearly my memory sucks).

 

[SteveB]

Given the 16 bit architecture of the CPU, wouldn't be a two byte per character table more efficient? First byte the character and second byte the colors?

[+jedimatt42]

The VDP is only attached to 8 of the bits on the data bus, so it isn't as better as it might be without a new motherboard.

 

Then there would be other tradeoffs. From routines to write text, to changing the screen color...

 

It would be hard to tell if was a win-win without redesigning the 4A.

[matthew180]

12 hours ago, SteveB said:

Given the 16 bit architecture of the CPU, wouldn't be a two byte per character table more efficient? First byte the character and second byte the colors?

 

For the technical reason jedimatt42 already pointed out, as well as compatibility.  Making the attributes a separate page in VRAM, rather than interleaving tile, attribute, tile, attribute..., means you can enable the tile-attributes, set all attribute bytes to the same fg/bg values, and still have compatibility with existing T40 and T80 mode software (as also mentioned by jedimatt42).  You can then add the new attribute capabilities on top of previously working code.

 

I thought a lot about this decision, especially since the PC EGA text modes use a two-byte tile, attribute arrangement in memory, but I decided compatibility with existing software and what people already know how to do with the 9918A was a better way to go.

 

The enhanced colors are implemented in a similar way, i.e. with parallel pages in memory adding additional color bits to each tile (this configuration is very common in other hardware of the era to add more colors per pixel).  This allows you to use existing patterns, turn on ECM, and add additional color data in phases.