Jump to content
IGNORED

F18A programming, info, and resources


matthew180

Recommended Posts

I too just updated my F18A ColecoVision with the v1.9 firmware. Flawless update using Tursi's excellent updater via my AtariMax Ultimate SD cart. Huge thanks to Tursi for making this such a painless process.

 

Even more thanks to Matthew for this awesome update. One of my issues was that the VGA output from my F18A would not display on my relatively old (2006) Sharp LCD TV. I would get just a blank screen. The v1.9 firmware has fixed this problem and for the first time ever I can now play my F18A enabled CV on this TV instead of my other displays. Thanks Matthew :thumbsup: :thumbsup: :thumbsup: :thumbsup:

Edited by Ikrananka
  • Like 4
Link to comment
Share on other sites

Hi Matthew,

 

do you have a (direct?) link to the v1.9-update ? I cannot find it.

(I used the link from post #1 and some more).

I only see this:

 

thx

There is a zip file in the first post of this thread. It appears to be what you are looking for.

 

Did you find it? Chue's comment was spot-on, you are looking for the F18A_V19.zip file at the bottom of the first post. Here is a direct link (I think):

 

http://atariage.com/forums/index.php?app=core&module=attach&section=attach&attach_id=612778

 

I have not updated my website yet, it ends up being lower on the priority list.

  • Like 2
Link to comment
Share on other sites

The update gave me a good 'excuse' to set up my F18A / CF7+ system today. It took me a while to figure out that my ubergrom UART/serial connection was plugged into a cable that went... nowhere. Ugh. Anyway, once I get the files transferred and update my F18A, I'll upload a TI archive to Heatwave, as a few people nabbed earlier updates that way in the past.

 

Edit: updated to v1.9 successfully and uploaded the files in the disk image.

Edited by InsaneMultitasker
  • Like 1
Link to comment
Share on other sites

I just reprogrammed my F18a with the v1.9 firmware. It was a flawless update using Tursis excellent updater on my Super ColecoVision.

I can't take full credit, all I did was wrap Matt and Rasumus' original excellent updater with some more GPU code so it could be easily ported. ;)

Link to comment
Share on other sites

The updater is pretty paranoid, and every block is checked before the F18A is modified. Don't be too worried about the initial checksum displayed on the screen - that is the program checksum and has /also/ been verified by the program to be correct. It's displayed only to make it easier for people who are BUILDING the tool to get the correct checksum to put in the code.

  • Like 4
Link to comment
Share on other sites

  • 2 weeks later...

The update gave me a good 'excuse' to set up my F18A / CF7+ system today. It took me a while to figure out that my ubergrom UART/serial connection was plugged into a cable that went... nowhere. Ugh. Anyway, once I get the files transferred and update my F18A, I'll upload a TI archive to Heatwave, as a few people nabbed earlier updates that way in the past.

 

Edit: updated to v1.9 successfully and uploaded the files in the disk image.

 

Thanks for continuing the real TI file ARC tradition on Heat Wave. I mirror it on the Hidden Reef.

Link to comment
Share on other sites

Just an FYI here that the F18A 1.9 update package works as expected when the F18A is installed in a console with the 32k on the 16 bit buss running a 3.58MHz clock crystal. However, if you have just completed updating some F18A equipped consoles running at stock 32k and 3.0MHz clock speed and then move to update a 32k on the 16 bit buss console running a 3.58MHz clock crystal your heart may wind up in your throat and you may look for something to hold on to as the binary code rolls by almost faster than you can read it and you finish in almost half the time it takes to update a stock console. The F18A is a fantastic piece of hardware and the F18A firmware update software is a fantastic software package.

 

That is all. :)

  • Like 8
Link to comment
Share on other sites

  • 8 months later...


With the F18A, what's an effective setup to do pixel-scroll in all directions, on an unbounded map?

 

With 2x2 name table, there is a 48x64 area to draw in, so tiles scroll smoothly on and off all sides of the screen. But there is no wrapping, so when the visible area approaches the edge, you must relocate chunks of the name tables and recenter. Perhaps GPU can help there.

 

With 1x1 name table and scroll registers, it wraps in both directions. But there's no buffer zone to park new columns off-screen, so you need a blank column, and both sides can't have smooth entry and exit. Row-wise, does the 30 row mode get you some extra off-screen rows?

 

An optimization I see to 2x2 is to keep the written area of the name tables to 24+1 rows, so as not to chew up too much memory. Update it every row move. I end up keeping 64x48 of map chunks in RAM. (I think chunks will be 16x16.)

 

Another idea is to hide some rows with the BML. Since the "non scrolled" feature went away, the BML could provide a non-scrolling status panel.

 

With 1x2, there is a horizontal 64 columns, which would be useful if the row buffering problem were solved.

 

Finally, I want to do parallax scrolling, so I need TL2 and TL1. 

 

 

I planned the memory map like so, but this ain't gonna work out:

; VDP Memory Map
; 0000 | TL2 | TL2 | TL2 | TAT |
; 0400 | TL2 | TL2 | TL2 | SAT |
; 0800 | TL2 | TL2 | TL2 | ___ |
; 0C00 | TL2 | TL2 | TL2 | ___ |
;
; uhoh TL1 and TL2 have to be the same size?
;
; 1000 | TL1 | TL1 | TL1 | ___ |
; 1400 | TL1 | TL1 | TL1 | ___ |
; 1800 | PAT     ECM3          |
; 1C00 | PAT                   |
; 
; 2000 | PAT                   |
; 2400 | PAT                   |
; 2800 | PAT                   |
; 2C00 | PAT                   |
; 
; 3000 | SPT      ECM3         |
; 3400 | SPT                   |
; 3800 | SPT                   |
; 3C00 | free                  |
; 
; 4K TL2
; 6K PAT
; 3K SPT     VR29 bits set the size of SPT or PAT to 1K or 32*4*8
; 2K TL1
; 

 

Link to comment
Share on other sites

Yeah, scrolling always presents the problem of "where does the new data come from?"  I thought about this a lot when doing the scrolling in the F18A, and ultimately it is left as an exercise for the programmer. ;-)

 

The ROW30 options does not give you extra non-visible rows, it give you 32x30 tiles, all visible.

 

There are a few options, the easiest is probable to use TL2 to mask a row and or column.  But if you need both tile layers to scroll, then you will need to set up the 1x2, 2x1, or 2x2 page sizes.  However, keep in mind that just because you specify a 2x1 page, for example, you do not have to use the entire second page.  After scrolling 7-pixels, you can reset the scroll register and tile-shift the display left or right.  This way you only need two extras rows or columns from the neighboring name tables, and the reset of the VRAM can be used however you like.

 

It gets harder to be efficient with the 2x2 page size though.  Also, the color/tile-attribute table has the most flexible options for locating in VRAM, and I like to tuck it in unused name table VRAM.  The GPU can also be used to do the name-table adjustments very fast, i.e. when you have scrolled 7-pixels and need to do a tile-sized scroll and reset the pixel-scroll.

 

There are also options to restrict the number of tiles you use, which means you can trade unique tiles for pattern VRAM.

  • Thanks 1
Link to comment
Share on other sites

With the 2x2 layout you need to update the column and row just outside the visible screen in the direction of scrolling. I did that in a demo, but only for one layer.

 

If you have two layers you won't have enough RAM for full ECM3 tables for both sprites and tiles. You can overlap the tables, reduce the number of patterns, or use ECM2 instead.

 

Using the BML as a mask doesn't seem to be an option since a full BML takes 12K. And I don't think you can place it on top of TL2? (I always get confused about how the priorities of layers work.)

 

It would be great if the MK2 would allow you to specify a RAM page for each table.

 

  • Thanks 1
Link to comment
Share on other sites

I have never been able to come up with a diagram that explains the pixel color stack-up, most due to the complexity of all the possibilities.

 

The BML can be above or below the Tile Layers depending on VR31 bit >40 (which is incorrectly indicated as "sprite priority" in the register use spreadsheet, which will be corrected in the next release).  Also, VR31 bit >20 specifies if a BML pixel value of "00" (two zero bits) is transparent or if the zero-index palette color is used.

 

BG

BML if priority = 0

Sprite if TL1 tile-priority = 1

TL1

Sprite if TL1 tile-priority = 0

Sprite if TL2 tile-priority = 1

TL2

BML priority = 1

Sprite if TL2 tile-priority = 0

 

Transparency for the tiles depends on the transparent setting (tile attribute byte bit >10) for each tile (in ECM1..3).  Like the BML transparent setting, this bit determines if a zero-value pixel is the zero-index palette color, or treated as transparent.  The interaction between the BML and the Tile Layers also depends on the transparency of each pixel at each layer.

 

19 hours ago, Asmusr said:

It would be great if the MK2 would allow you to specify a RAM page for each table.

Can you clarify?  The MK2 will expand the addressing of the tables with more address bits, as close to the 9938 as possible.  Is this what you mean?

 

  • Like 1
Link to comment
Share on other sites

11 hours ago, matthew180 said:

Can you clarify?  The MK2 will expand the addressing of the tables with more address bits, as close to the 9938 as possible.  Is this what you mean?

I hadn't thought about the details, but yes, that's what I mean.

The F18A is already using R10 and R11, is that what you mean by "as close as possible"?

Will the BML also have a register for the high bits?

Are you planning to allow access to more than 128K RAM? 

 

Link to comment
Share on other sites

17 hours ago, matthew180 said:

BG

BML if priority = 0

Sprite if TL1 tile-priority = 1

TL1

Sprite if TL1 tile-priority = 0

Sprite if TL2 tile-priority = 1

TL2

BML priority = 1

Sprite if TL2 tile-priority = 0

Thanks for the info. It's still difficult to understand, but I think I'm missing a clause in JS99er that allows BML to be displayed on top of TL2.

 

I'm drawing the layers in the order BG, TL1, BML, Sprite, TL2, and before I draw each pixel in each layer I'm checking if a pixel with higher priority has already been drawn. Is that also how the F18A works?

Link to comment
Share on other sites

I'll try to pseudo-code the sequence.

 

First, any bits in the VRs or attribute-bytes that specify "transparent", that determines how the zero-value pixels will be considered.  A zero-bit ("0") means not-transparent, a one-bit ("1") means transparent:

Mode     Bits per pixel  Attribute   Result color
         from pattern    trans bit
----------------------------------------------------
Original     "0"            NA       Backgroud color from color byte
             "1"            NA       Foregroud color from color byte

ECM1         "0"            "0"      Use color from palette
             "0"            "1"      Pixel is transparent
             "1"            NA       Use color from palette

ECM2         "00"           "0"      Use color from palette
             "00"           "1"      Pixel is transparent
             "1x"           NA       Use color from palette
             "x1"           NA       Use color from palette

ECM3         "000"          "0"      Use color from palette
             "000"          "1"      Pixel is transparent
             "1xx"          NA       Use color from palette
             "x1x"          NA       Use color from palette
             "xx1"          NA       Use color from palette

There is also a priority bit in the tile attribute byte, which gives the tile's pixels priority over sprites.  The BML has its own transparent bit, and priority over tiles bit.  The BML transparency works the same as the tiles, a zero-value pixel is either transparent or the palette color based on the transparent-bit in VR31.

 

With that out of the way, a pixel's color is determined like this:

for every screen x,y location
  have_pixel = false
  tile_priroity = false

  get TL1 pixel
  if pixel == 0-value and pixel-transparent == 1 then
    pixel_color = backgroud-index
  else
    have_pixel = true
    tile_priroity = priority-over-sprite
    pixel_color = pixel-index
  end if

  if TL2 enabled
    get TL2 pixel
    if have_pixel == false then
      if pixel != 0-value or pixel-transparent == 0 then
        have_pixel = true
        tile_priroity = priority-over-sprite
        pixel_color = pixel-index
      end if
    end if
  end if

  if BML enabled
    get BML pixel
    if pixel != 0-value or BML-transparent == 0 then
      // if BML on top of tile-layers, or previous tile pixels were transparent.
      if BML-priority == 1 or (BML-priority == 0 and have_pixel == false) then
        // DO NOT SET *have_pixel* to true. The BML is always under sprites.
        pixel_color = pixel-index
      end if
    end if
  end if

  for each active sprite at this x,y location
    get sprite pixel
    // if there is a non-transparent sprite pixel, and the tile pixel is transparent
    // or the tile does not have priority over sprites, display the sprite pixel.
    if (pixel != 0-value or sprite-transparent == 0) and (tile_priority == false or have_pixel == false) then
      pixel_color = pixel-index
    end if
  next sprite

  lookup pixel_color in palette
  show pixel color

next x,y screen position

I think that is right, I'll have to look at it again later to see if I missed something.  Basically for every pixel you want to display, in the order of TL1, TL2, BML, Sprites, you have to see if the pixel is zero-value, see if a zero-value is considered transparent, and when it comes to the BML and Sprites see if the tiles have priority or not.

 

For TL1, check for non-transparent pixels vs background, and replace BG if there is a pixel.

For TL2, check for non-transparent pixels vs TL1, and replace TL1 if there is a pixel.

For BML, check for non-transparent pixels vs tile-layers, and priority over the tile-layers, replace if priority over tile-layers or both tile-layers are transparent.

For Sprites, check for non-transparent pixels vs tile-layers, and priority over tile-layers, replace if priority over tile-layers or both tile-layers are transparent.

 

Priority of tiles vs sprites is considered only when ECM1..3 is true.  Original mode does not.  Same with the TL2 and BML, the F18A must be unlocked and those features enabled.

  • Like 2
Link to comment
Share on other sites

14 hours ago, Asmusr said:

The F18A is already using R10 and R11, is that what you mean by "as close as possible"?

Yes, I tried to stay out of VR8..14 in case I tried to be more 9938 compatible in the future.  I kind of blew that when I added TL2.  I'm not sure how it will map out now.

 

14 hours ago, Asmusr said:

Will the BML also have a register for the high bits?

Yes.  Probably in VR37.  If I had given more thought to expansion I would have set up the new registers a little better.  That was my first pass at making a chip...

 

14 hours ago, Asmusr said:

Are you planning to allow access to more than 128K RAM?

I sure hope so.  If I can get my way about things, I'm planning to have access to all 512K on the MK2, otherwise an rather expensive SRAM chip will go under utilized.  A lot of the table registers have room for the needed address bits (5 more bits are needed for the full 512K).  Even if I can't get table access to the full 512K, the VRAM should still be fully addressable by the host interface and GPU.

 

Also, I'm having to do a lot of rework for the DVI video output, and I should be able to free up at least 4K of VRAM for the original F18A.  I could also make the 2K of GPU RAM part of the overall VRAM, which would give the original F18A 22K of VRAM total.

  • Like 4
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...