F18A programming, info, and resources

[Asmusr]

18 hours ago, matthew180 said:

 

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

Thanks, your pseudo-code will be very useful for making the emulation in js99er more accurate.

[Asmusr]

11 hours ago, matthew180 said:

I'm not sure how it will map out now.

Perhaps a flag to choose between f18A and V9938 compatibility? But that would be quite messy. The question is if any existing V9938 application for the TI-99/4A is setting these registers? I know they are used by my Super Mario demo, which some people have purchased on cartridge. VR14 (high bits of address counter) is fortunately not used by the F18A, which is probably the most important register for supporting existing applications.

[matthew180]

I think the majority of the 99/4A (geneve?) software that would use the 9938 is mostly looking for the extra VRAM and ability to relocate tables.  I might have interfered in making this seamless when I put TL2's registers in the VR range 8..14.  The 9938 has a lot of bits for using things like interlace and the color bus, which the F18A-compatible MK2 will never support, so I'm not worried about those registers.  I have not looked at the addressing in enough detail to come to any conclusions yet; I have to get the video section rewritten first to support the DVI output (and free up 4K to 6K of Block RAM for the original F18A).

 

What VRs in the 8..14 range does Super Mario use?

[matthew180]

41 minutes ago, Asmusr said:

Thanks, your pseudo-code will be very useful for making the emulation in js99er more accurate.

When I was writing the pseudo-code, I realized it is easier to do this in hardware than software.  If you can read VHDL I'm happy to provide you the F18A tile and sprite source if that would help with the emulator.  I really should write an F18A reference in C as well, so other emulators can incorporate the features...  yeah, just what I need, yet another project I don't have time for...  However, I do plan to open-source the F18A HDL at some point in the near future.

[Asmusr]

2 hours ago, matthew180 said:

What VRs in the 8..14 range does Super Mario use?

It uses VR10 and VR11 to set up TL2.

[matthew180]

Ah, sure, so those won't be changing at this point.  I messed that up when I chose to use those VRs, so I'll have to deal with it now.  I'm not going to break existing F18A software.

[+FarmerPotato]

4 hours ago, matthew180 said:

When I was writing the pseudo-code, I realized it is easier to do this in hardware than software.  If you can read VHDL I'm happy to provide you the F18A tile and sprite source if that would help with the emulator. 

Hey, you said in your EETimes interview that you switched to Verilog after trying VHDL!  I went with Verilog after reading that.

 

 

I've got through multi-color sprites (EC3), tested on both emulators and hardware, and next moving on to the TL1 TL2 scrolling code. 

 

One pitfall I fell into was which bits of the sprite attribute select the palette. In EC3 it's the MSbits.. so palette 3 is 6.  That took a while to debug until I found the answer in one your detailed posts here.

 

[matthew180]

32 minutes ago, FarmerPotato said:

Hey, you said in your EETimes interview that you switched to Verilog after trying VHDL!  I went with Verilog after reading that.

I did?  Oh no!  I secretly hate Verilog.  Do you have a link?  Verilog looks too much like a familiar programming language to most people (like C or C++), and tends to mislead people and promote hard to read HDL.  Just my opinion though.  It is very popular with the new kids trying out FPGAs.

 

37 minutes ago, FarmerPotato said:

One pitfall I fell into was which bits of the sprite attribute select the palette. In EC3 it's the MSbits.. so palette 3 is 6.

Hmm.  Yeah, where you have overlap between the pattern bits and the palette select bits, the MSbits remain:

 

5 4 3 2 1 0  palette index
-----------
3 2 1 0      palette select bits
      2 1 0  ECM3 pattern bits
-----------
3 2 1 2 1 0  combined bits

Where the two overlap, the LSbits of the palette select are replaced by the pattern bits.  In thinking about it now, it seems I might have chosen poorly.  Dropping palette select MSbits would probably have been a better choice.  Sorry.  This is what happens when you use hardware without context of the best way it might be used.  It was this kind of failure that resulted in the big V1.6 release that blew away a lot of original useless design and introduced things like TL2 and other features (after a lot of feedback mostly from Rasmus as he tried to use the enhanced features).

[+FarmerPotato]

22 minutes ago, matthew180 said:

I did?  Oh no!  I secretly hate Verilog.  Do you have a link?  Verilog looks too much like a familiar programming language to most people (like C or C++), and tends to mislead people and promote hard to read HDL.  Just my opinion though.  It is very popular with the new kids trying out FPGAs.

 

I'm mistaken.  https://www.eetimes.com/document.asp?doc_id=1278573#

Someone else must have made that remark.

 

I have found that when I stick to Dr. Pong's  format and style for state machines, my Verilog code works. I have thrown away my spaghetti code and written test benches for everything in Verilator.

 

[GDMike]

I love this part of the article, 

"It played tones from 100Hz to 1000Hz! That means the BASIC interpreter was successfully storing my program in VRAM and then executing my code from VRAM. Mega-cool!!" It's alive!!

and I'm thrilled to read this btw as I've never seen it till today, thx for sharing this.

 

[+FarmerPotato]

Questions:

I just noticed there are 2 bits of HPSIZE and VPSIZE.. so TL1 can be 2x1 while TL2 is 2x2? This is for parallax scrolling. TL1 is off in the distance and will scroll at half the speed of foreground TL2.

Is there a bit that enables TL2 to display? I can't find it in the spreadsheet.

Plan:

Use the free 1K for the BML: make a big sprite 4x32 (1bpp?) to mask off 4 rows. 

Use these 4 covered up rows as a "off-screen" buffer in the HPSIZE=2 VPSIZE=1 TL1 parallax scrolling image. Since it wraps in the V direction, the scroll offset moves continuously, with new content placed into "off screen" rows as needed. For H direction, when the on-screen part (32 out of 64 columns) approaches the edge, the name table can be rewritten to recenter the visible portion.

Still! Using this scheme, I might as well reduce TL2 to 2x1 pages as well, since it will have 4 rows masked off.  That saves 2K of memory.

BML at 1bpp would mean 256*32/8 = 1K. Am I mistaken about how much memory BML needs?  Can BG be solid color? not transparent? The BML will have game status graphics and text. Maybe with a few other sprites on top for little animated gizmos.

 

How big of a BML can I make with 3K of memory free? (must be 256 pixels wide)
 

[Asmusr]

10 minutes ago, FarmerPotato said:

I just noticed there are 2 bits of HPSIZE and VPSIZE.. so TL1 can be 2x1 while TL2 is 2x2? This is for parallax scrolling. TL1 is off in the distance and will scroll at half the speed of foreground TL2.

Is there a bit that enables TL2 to display? I can't find it in the spreadsheet.



Yes.

TILE2_EN is in VR49.

[Asmusr]

14 minutes ago, FarmerPotato said:

How big of a BML can I make with 3K of memory free? (must be 256 pixels wide)

256x48 in 4 colors. Or 128x48 fat pixels (2x1) in 16 colors.

[Asmusr]

Will you be scrolling diagonally in one direction only?

[+FarmerPotato]

14 minutes ago, Asmusr said:

256x48 in 4 colors. Or 128x48 fat pixels (2x1) in 16 colors.

Thanks! I look forward to getting BML up and running. With 4 colors I can do text and some blinky lights and dials.

 

8 minutes ago, Asmusr said:

Will you be scrolling diagonally in one direction only?

Any direction? This is an unbounded map. The ship has an X and Y velocity, so it could be scrolling to keep up with diagonal moves. I'll buffer 2 rows above and below the visible area so you can flip Y direction  without immediately causing a buffer load.

 

[Asmusr]

9 minutes ago, FarmerPotato said:

Any direction? This is an unbounded map. The ship has an X and Y velocity, so it could be scrolling to keep up with diagonal moves. I'll buffer 2 rows above and below the visible area so you can flip Y direction  without immediately causing a buffer load.

Don't you need to mask both top and bottom then?

43 minutes ago, FarmerPotato said:

Can BG be solid color? not transparent?

Yes, by setting BML_TRANS=0.

[+FarmerPotato]

46 minutes ago, Asmusr said:

Don't you need to mask both top and bottom then?

Yes, by setting BML_TRANS=0.

Well, there are 4 rows masked at the bottom. It will wrap in V.  I can use 2 of those rows for bottom tiles, 2 rows for top. 

 

 

[Asmusr]

On 10/1/2019 at 12:24 AM, matthew180 said:

I'll try to pseudo-code the sequence.

 

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

With this code TL2 will not be displayed if TL1 has a pixel, but isn't it the other way around? And there are also the TL1_OFF and TILE2_PRI bits to consider.

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

I think sprite color 0 is always transparent?

[matthew180]

5 hours ago, FarmerPotato said:

I just noticed there are 2 bits of HPSIZE and VPSIZE.. so TL1 can be 2x1 while TL2 is 2x2?

I just checked the HDL and, yes, apparently TL2 has its own page size bits...  Sad I can't remember everything I implemented.  I really need to write some documentation!

 

1 hour ago, Asmusr said:

With this code TL2 will not be displayed if TL1 has a pixel, but isn't it the other way around?

Yeah, the pseudo-code does not look right.  The "if have_pixel == false then" block should just be deleted.

 

2 hours ago, Asmusr said:

And there are also the TL1_OFF and TILE2_PRI bits to consider.

Yes, there are those flags too... which I forgot about.  The TL1_OFF is pretty easy, it does exactly what it says.  When it is off you should end up with just the background as the base color behind TL2, the BML, and any sprites.

 

The TL2 Priority I had to look up.  I don't remember why I implemented this, but I have to assume it was a request from you (Rasmus).  It is a *global flag* that affects TL2's priority:

Mode     TL2 Priority
         Select/Enable
--------------------------
Original    0      TL2 covers sprites
            1      sprites cover TL2
ECM1..3     0      TL2 covers sprites
            1      Tile's attribute bit >80 selects tile's priority over sprites

So depending on the mode, the TL2 Priority controls if all of TL2 is above or below sprites, otherwise it is an enable as to whether or not the tile's attribute sprite priority bit is considered.  This could be work into the pseudo-code by replacing:

tile_priroity = priority-over-sprite

With a check that considers the TL2 Priority flag and mode.

  get TL1 pixel
  if TL1_OFF == 1 or (pixel == 0-value and pixel-transparent == 1) then
    pixel_color = background-index
  else
    have_pixel = true
    tile_priority = priority-over-sprite
    pixel_color = pixel-index
  end if

  if TL2 enabled
    get TL2 pixel
    if mode == original then
      pri_over_sprite = not TL2_PRI
    else
      pri_over_sprite = attr_pri_bit or (not TL2_PRI)
    end if

    if pixel != 0-value or pixel-transparent == 0 then
      have_pixel = true
      tile_priority = pri_over_sprite
      pixel_color = pixel-index
    end if
  end if

[matthew180]

2 hours ago, Asmusr said:

I think sprite color 0 is always transparent?

True.  I'm not sure why I wrote that as an option for sprites.  Must have been thinking too hard about the tile layers.

[Asmusr]

5 hours ago, matthew180 said:

I don't remember why I implemented this, but I have to assume it was a request from you (Rasmus).  It is a *global flag* that affects TL2's priority

That was a bad suggestion from me, based on my lack of understanding. I would be happy for this to be removed in the MK2.

[Asmusr]

I have fixed the layering in https://js99er.net according to Matthew's pseudo-code, so it should now be possible to have BML on top of TL1 and TL2. I haven't got any code to test this specific condition, but maybe FarmerPotato will have something soon?  

[Asmusr]

@matthew180, I noticed in my code that I'm supporting ECM1-3 in TEXT and TEXT80 modes. Is that correct or do these modes only support the original color mode (monochrome). 

 

[+FarmerPotato]

4 hours ago, Asmusr said:

I have fixed the layering in https://js99er.net according to Matthew's pseudo-code, so it should now be possible to have BML on top of TL1 and TL2. I haven't got any code to test this specific condition, but maybe FarmerPotato will have something soon?  

It's putting BML over TL1 and TL2.

Sending you my test file.

I was not able to test on real iron today. my serial cable is acting up.

[+FarmerPotato]

On 9/29/2019 at 9:52 PM, 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

 

I think I've got this now. The BML is like a big sprite with #33, so other sprites take priority over it. However ordinary sprites can be masked out of their layer by TL1 or TL2 tile attribute priority bits. (this is cool, having some tiles to be more "foreground" than others.) BML's priority bit lets it jump to the top, except for surviving sprites.

 

So in my scrolling map, I can use the BML with priority=1 to mask out tile rows, but sprites will still float over that region.

 

So, to keep sprites from floating over the BML, I must zero out their pattern bytes. This is do-able.

 

(With BML priority=1 and TL2 or TL1 priority=1, it's kinda like rock-scissors-paper. BML beats tile, tile beats sprite, sprite beats BML unless already beaten.)