F18A programming, info, and resources

[Omega-TI]

The issue about the nanoPEB - F18A compatibility makes me wonder: Is it possible for a device on the side port to write to VDP RAM directly, bypassing the CPU?

 

What a concept! If possible, that would open up some amazing things.

[matthew180]

Since the #HOLD pin on the 9900 is pulled high in 99/4A (yet another way the 99/4A was crippled), the only way to address the VDP directly would be to override the CPU's address / data bus. I don't recommend doing that. It might be possible to issue an IDLE statement though to get access to the address / data bus. However the 9900 datasheet is not clear about the state of the buses when the "external instructions" are issued, other than to say the three most significant address bits (A0, A1, A2) are set to predefined levels related to the external instruction being executed.

 

Well, I just looked at the schematics and it is all moot. The address bus is buffered before going to the side port, so you will never be able to drive the address bus. Also, the VDP's #CSR and #CSW are not available on the side port.

 

An alternative would be to have a second VDP as a peripheral, so you could have a dual-monitor 99/4A.

[speccery]

 

An alternative would be to have a second VDP as a peripheral, so you could have a dual-monitor 99/4A.

 

 

A quick question: are the fast memory accesses on the TI's 16-bit internal bus reflected on the external bus? I should know since I've done some logic analyzer captures, but I don't remember right now. I guess what I am really asking is that if you had a write-only VDP on the external bus, could it be made to mirror the picture created by the internal VDP? Not exactly sure what would be the use case there... For a dual-monitor setup it would be nice to run a debugger on the other screen, either for Basic or machine code.

[+mizapf]

No, all accesses outside of 0000-1FFF and 8000-83FF trigger the wait state circuitry.

 

[Edit: The address bus drivers at the I/O port are always on, so when you access these areas you may "see" the fast operations by their addresses outside, but probably not the data bus. Need to check.]

Edited March 14, 2017 by mizapf

[Willsy]

In addition, the data bus on the expansion port is only 8 bits wide.

[+mizapf]

Yes, but it could be that during internal accesses, one of the bytes (MSB or LSB) may become visible on the outgoing data bus. However, just had a look at the schematics, the data bus is fully controlled by the wait state logic, and when this circuitry is not triggered, there will be no signals for opening the data bus drivers. So I guess the data bus is floating during internal accesses.

[Willsy]

Yes. I don't have the schematics but I think the expansion bus is tri-stated when not in use.

[BJGuillot]

So... I finally got up courage to try to update my F18A and it seems to have failed.

 

Current rev is 1.5, trying to bump it to 1.8.

 

It seemed to start out OK, but then got stuck in the same spot for about 5 minutes (see attached picture). I pressed space bar to see what would happen and the TI reset back to the title screen.

 

An update to my saga from a few weeks back in trying to use the F18A updater with dsk files mounted into my NanoPEB...

 

After reading some of the comments about there being a special ROM available for the NanoPEB that makes it more compatible with the F18A, I reached out to the NanoPEB creator, and he sent me some few chips that updated my existing NanoPEB to the F18A-compatible version. It was just a pop-up chip out, pop new chip-in.

 

Unfortunately, the new chips in my NanoPEB didn't seem to make any difference. The F18A Updater would still fail in random places with CRC errors when reading the various portions of the update off disk. He said the update only changed the timings in the boot-up sequence, so I was skeptical if it would have made a difference in any case.

 

Fast forward to today, and I saw the new thread: http://atariage.com/forums/topic/263671-f18a-rom-based-updater/

in which Tursi released a new ROM-based F18A Updater.

 

I never programmed a ROM before--I bought all the equipment to be able to do it last year or so, but never got around to doing anything with it. Well, now I had a good reason to learn. So I flashed a chip in the UberGROM I had sitting around, and after some help from Omega, my second attempt was successful at getting the ROM-based F18A Updater to work. So happy ending: My F18A has been upgraded from the 1.5 code to 1.8.

[Omega-TI]

You were using version 1.5?

Congratulations on the completed upgrade!

[Tursi]

I was using 1.5 before I did the upgrader too

 

Glad it worked for you, BJGuillot! That does suggest a problem with your CF device. People have pretty mixed results with them, unfortunately.

[matthew180]

V1.5 was probably the largest distribution of boards, so I suspect most people will be on 1.5 if they have never updated. Thanks Tursi for making the ROM-based updater and for porting it to the CV! It it already making people's lives better. :-)

[digress]

great job providing the updater. That solves a problem I was running into with some testers that were on the older version.

 

I have a question. During a scrolling sequence in my game everything works great but every once in a while the screen goes completely black on tile layer 2 except for the top score line which is updated manually every few cycles. Now the game continues as normal and when you die the screen is reintitialized and everything is back to normal. I put in a button you can press to essetially clear your window sheild and reset the tile layer2 if it happens so you don't have to die but I need to remove the bug .

 

I'm not sure why it's happeneing yet though. it seems the colour pallette for the transparent tile has become corrupt during gameplay.

[+InsaneMultitasker]

I am trying to reset the F18A palette for T40 and T80 modes using some pre-defined 24-bit values. I do not quite understand the F18A documentation for setting the palette registers, namely:

 

1. Is each palette register represented by 4-bits per color [rrrr gggg bbbb] for a total of 12 bits per register, in all modes? The CGA and ECM1 tables show 12 and 24 bit palette register values.

 

2. If the values are indeed limited to 4 bits per color [rrrr gggg bbbb] in all modes, is it best to approximate the colors by removing the least significant nibble? i.e., would [0xBE, 0x1A, 0x24] be represented as [0x0B12] or should we round the value to the nearest 4-bit value [0x0C22]?

 

3. I followed the example in the manual to update the standard palette with some color settings of my own. I ran the program then wrote and ran a small Extended BASIC program to change the screen color from 1 to 16. I got the expected results for all but the first color. Even changing the starting palette register to 0 (in the assembly routine) didn't let me change the palette for that first color. Not sure what I am misssing.

 

Thanks

  {0x00, 0x00, 0x00},
  {0xFD, 0xFE, 0xFC},
  {0xBE, 0x1A, 0x24},
  {0x30, 0xE6, 0xC6},
  {0xB4, 0x1A, 0xE2},
  {0x1F, 0xD2, 0x1E},
  {0x21, 0x1B, 0xAE},
  {0xDF, 0xF6, 0x0A},
  {0xB8, 0x41, 0x04},
  {0x6A, 0x33, 0x04},
  {0xFE, 0x4A, 0x57},
  {0x42, 0x45, 0x40},
  {0x70, 0x74, 0x6F},
  {0x59, 0xFE, 0x59},
  {0x5F, 0x53, 0xFE},
  {0xA4, 0xA7, 0xA2}

Edited May 10, 2017 by InsaneMultitasker

[matthew180]

1. Yes, each palette is 12-bits with the format: 0000 rrrr gggg bbbb. The palette values are in effect for all modes, no matter if the F18A is locked or unlocked. You can unlock the F18A, set some new palette colors, then re-lock the F18A and the new colors will still be active. The palette only resets on a power-cycle, so changed colors will survive a warm-boot.

 

The 24-bit values in the manual are just showing the CGA colors as 24-bit color values for reference on how I reduced them to 12-bit color for the defaults in the F18A.

 

2. I suppose the best way to approximate 24-bit colors as 12-bit values really depends on what you prefer. I think the closest conversion is probably something like:

 

4-bit_red = int ( 8-bit_red / 16 )

4-bit_grn = int ( 8-bit_grn / 16 )

4-bit_blu = int ( 8-bit_blu / 16 )

 

3. Can you post the assembly code and palette data you are using? Is the F18A unlocked or locked? What mode are you using (GM1, T40, etc?) Did you enable any ECMs? There are a lot of factors that go into color selection. If you just set the palette and kept everything else standard, then I would expect color 1 to work just like any other. However, sometimes color index 0 means transparent depending on the ECM tile-attributes, or per-tile attributes for T40/T80.

[+InsaneMultitasker]

3. Can you post the assembly code and palette data you are using? Is the F18A unlocked or locked? What mode are you using (GM1, T40, etc?) Did you enable any ECMs? There are a lot of factors that go into color selection. If you just set the palette and kept everything else standard, then I would expect color 1 to work just like any other. However, sometimes color index 0 means transparent depending on the ECM tile-attributes, or per-tile attributes for T40/T80.

Hi Matthew, thank you for the clarification of #1 and the suggestion for #2, that all makes sense. I'll amend my notes accordingly.

 

WRT to #3, for now I am using the standard graphics mode that XB and EA start up with. I did not enable any ECMs and if I recall correctly, the F18A is unlocked upon completion of the palette set. I figured it would be easier to play around with the various color combinations by using CALL COLOR and CALL SCREEN within XB, though my goal is to use T40 and/or T80 with the color fore/background attribute table, just like I do with my ansi terminal emulator. I won't be able to post any code until the evening, at the earliest.

[Asmusr]

Hi Matthew, thank you for the clarification of #1 and the suggestion for #2, that all makes sense. I'll amend my notes accordingly.

 

WRT to #3, for now I am using the standard graphics mode that XB and EA start up with. I did not enable any ECMs and if I recall correctly, the F18A is unlocked upon completion of the palette set. I figured it would be easier to play around with the various color combinations by using CALL COLOR and CALL SCREEN within XB, though my goal is to use T40 and/or T80 with the color fore/background attribute table, just like I do with my ansi terminal emulator. I won't be able to post any code until the evening, at the earliest.

 

Are you testing on real iron or in JS99er.net? There could be something not accurately emulated.

 

When you convert from 4 bits to 8 bits you will want FFF (white) to become FFFFFF and not F0F0F0, which is slightly grey. So I use multiplication by 17 instead of 16 (17*15=255). But when you convert the other way you will want the range from FFFFFF to F0F0F0 to become FFF, so here you need integer division by 16 and not 17. I guess.

[+InsaneMultitasker]

 

Are you testing on real iron or in JS99er.net? There could be something not accurately emulated.

 

When you convert from 4 bits to 8 bits you will want FFF (white) to become FFFFFF and not F0F0F0, which is slightly grey. So I use multiplication by 17 instead of 16 (17*15=255). But when you convert the other way you will want the range from FFFFFF to F0F0F0 to become FFF, so here you need integer division by 16 and not 17. I guess.

I'm testing on the real iron. XB accesses the colors as 1 through 16, i.e., CALL COLOR(colorset#,foreground,background).

 

When I redefine the palette, colors 2-16 are redefined but offset by one. That is, if the palette sets color 2 as white, it is color 3 that ends up being white. Color 1 doesn't seem to change at all, even when the palette register bits are clear to represent PR#0. Maybe this is the case MAtthew was talking about regarding color index 0?

[Asmusr]

Isn't the offset due to XB colors being 1 based while the F18A is 0 based? Color 0 on the F18A is transparent in the normal mode, so you will see the backdrop color instead. If you don't want that you need to select one of the ECM modes.

[+InsaneMultitasker]

I've accounted for the offset; only 15 of the 16 colors are being redefined. I am hoping it is just an error in my code or a misunderstanding of how the palette works in the various modes.

[+InsaneMultitasker]

My program will use (is using) T80 mode with color attributes and the F18a unlocked, which I believe is a normal mode. If I can't reset color0, then it sounds like I'll need to force two colors to be the same, i.e., grey and ltgrey. I would prefer to have all 16 colors available.

 

Here is the color set (I converted these to 12-bit in my code) I am trying to use in T80 mode.

{0x00, 0x00, 0x00}, 0 Black
{0xFD, 0xFE, 0xFC}, 1 White
{0xBE, 0x1A, 0x24}, 2 Red
{0x30, 0xE6, 0xC6}, 3 Cyan

{0xB4, 0x1A, 0xE2}, 4 purple
{0x1F, 0xD2, 0x1E}, 5 green
{0x21, 0x1B, 0xAE}, 6 blue
{0xDF, 0xF6, 0x0A}, 7 yellow

{0xB8, 0x41, 0x04}, 8 orange
{0x6A, 0x33, 0x04}, 9 Brown
{0xFE, 0x4A, 0x57}, 10 LtRed
{0x42, 0x45, 0x40}, 11 DkGray

{0x70, 0x74, 0x6F}, 12 Gray
{0x59, 0xFE, 0x59}, 13 LtGreen
{0x5F, 0x53, 0xFE}, 14 LtBlue
{0xA4, 0xA7, 0xA2} 15 LtGray

[Asmusr]

If you set the tile color mode to ECM1 then each tile/pattern gets an attribute that among other things decides whether color 0 is transparent.

[Asmusr]

If you set the tile color mode to ECM1 then each tile/pattern gets an attribute that among other things decides whether color 0 is transparent.

 

But I guess you're using position based attributes instead? In this mode I don't think you can choose that color 0 shouldn't be transparent - at least that's how I have implemented it in js99er. But can't you just set the background to black?

[+InsaneMultitasker]

Yes, for each character on the screen, there is a corresponding byte that holds the character's foreground and background color. I could set the screen color and/or the character background color to black, but I still only have 15 colors to work with if we can't redefine color 0.

[Asmusr]

What's the difference between setting color 0 to opaque black, and having a black screen color that's visible through a transparent color 0 (except for the border, of course)?

[+InsaneMultitasker]

Hmmm.. I don't think there is a difference except that for the latter (black screen color visible through transparent color 0) I'm still short one color because I am now effectively using two colors to represent black. In my palette, color 0 is Black. If I move Black to color 1, then I have to bump White, and so on. Or is there a way to set the screen to black without relying upon my redefined palette? I didn't have time to post any code last night; I'll try to do so tonight.