Jump to content
IGNORED

F18A programming, info, and resources


matthew180

Recommended Posts

Both Tursi and Rasmus reported having to try the update a few times when using the Nanopeb. All I can say is to make sure it is plugged in securely and that it is supported in some way. The program will simply not run if the self-test checksum fails, and it will not update the firmware if there are any CRC errors. I'm glad to hear your second unit worked out. Thanks for the feedback!

  • Like 1
Link to comment
Share on other sites

Both Tursi and Rasmus reported having to try the update a few times when using the Nanopeb. All I can say is to make sure it is plugged in securely and that it is supported in some way. The program will simply not run if the self-test checksum fails, and it will not update the firmware if there are any CRC errors. I'm glad to hear your second unit worked out. Thanks for the feedback!

 

Yep.. I bet it's a build issue with the newest peb.. Lots of complaints from people about it. I'll dig into it and figure out the issue and let the manufacturer know about it..

 

Very glad you did the CRC stuff BEFORE erasing anything :):)

 

Greg

  • Like 1
Link to comment
Share on other sites

There might be differences between cf7+/nanopeb/nanopebVersion2, and even within the same system there might be different firmwares floating around.

Maybe we can summarize positive/negative reports on users that tried to update with infos about which "compact flash" device was used, size/manufactor of cf card.

I will try it out asap with both of my compact flash devices, although I am already on f18a_v1.5.

Link to comment
Share on other sites

Both Tursi and Rasmus reported having to try the update a few times when using the Nanopeb. All I can say is to make sure it is plugged in securely and that it is supported in some way. The program will simply not run if the self-test checksum fails, and it will not update the firmware if there are any CRC errors. I'm glad to hear your second unit worked out. Thanks for the feedback!

I only have a CF7+, and I want to clarify, the /update/ worked perfectly every time I tried it (6 times in total!).

 

Moving my CF7 to a new physical TI console usually takes a few tries to get the CF7 to boot again, and this is what I mentioned in my email. Nothing to do with the update, it's just got a crap edge card connector on it.

Link to comment
Share on other sites

Hi Matthew,

 

In a vertical scrolling setup on the F18A, is there 1K or 2K between the two name table pages? This post http://atariage.com/forums/topic/168968-f18a/page-27?do=findComment&comment=2573661 states that there is 1K between them, but this post http://atariage.com/forums/topic/207586-f18a-programming-info-and-resources/page-5?do=findComment&comment=2848296 says "that the VSP will select between 0 (0K) or 2048 (2K) offset".

 

In case of the latter, is it possible to use the VSP in a horizontal setup to choose between displaying/scrolling pages 1/2 vs. pages 3/4?

 

The reason for these questions is that I'm thinking of the best way to implement smooth scrolling on the F18A that will fall back nicely to character (8 pixels) scrolling on the 9918A. For that I think you need some kind of double buffering scheme. So after scrolling 8 pixels on the F18A using the scroll registers you switch to another name table that is offset by one character, reset the scroll register, and repeat. The idea is that the 9918A will ignore the scroll registers but will respond to the name table switching, so it will scroll in character offsets using the same code that on the F18A produces smooth scrolling. Does that make sense?

 

 

Link to comment
Share on other sites

Rasmus, thanks for pointing out the error. I have corrected the first post you linked. The vertical scroll pages (0 and 2) are always 2K apart because of the way the name table address is built-up when scrolling is enabled (as described in the second link you cited). Also note that I have been inconsistent with the naming of the pages and sometimes 1-offset them (1,2,3,4), and other times I 0-offset (0,1,2,3) them. Sorry.

 

In case of the latter, is it possible to use the VSP in a horizontal setup to choose between displaying/scrolling pages 1/2 vs. pages 3/4?

No it is not. Sorry again.

 

The reason for these questions is that I'm thinking of the best way to implement smooth scrolling on the F18A that will fall back nicely to character (8 pixels) scrolling on the 9918A.

I'll have to think about it, but off the top of my head I'm not coming up with anything that would work for both VDPs unless you use a 1-tile border on the left and right and keep the scrolling as a single page. Otherwise I would probably have two different version of the game, or possibly two different sets of routines that get called based on if the F18A was detected or not.

Link to comment
Share on other sites

What happens if you try to do it anyway? Is VSP just ignored when VSIZE is zero?

You can try, it won't hurt anything. :-) In short, yes, the vertical page size is set to the name table VR2(6) bit when the vertical size is 0 (zero).

 

For each scan line the VDP needs the pixels to display, and it does that by looking at the name table for a tile "name", and using that to look up the pattern. The current tile name on the 32x24 grid to look up is based on the current raster location. The vertical raster is controlled by the y-counter, and the horizontal pixel is controlled by an x-counter.

 

To get the value of the current tile name at the current raster location, a 14-bit VRAM address needs to be generated based on the name table base address and the x and y counters. In the F18A the x and y counters are affected by the scroll registers, vertical/horizontal page size, and vertical/horizontal page start.

 

VDP Registers are 8-bits, using TI bit numbering:

MSB         LSB
0 1 2 3 4 5 6 7


ntba(0..3) = VR2(4..7) (4 bits)
x-counter(0.. (9 bits, 0=MSB, 8=LSB)
y-counter(0.. (9 bits, 0=MSB, 8=LSB)

h_page_start = VR29(6) // also affected by hto calculation and h_page_size
h_page_size = VR30(1)

v_page_start = VR29(7) // also affected by vto calculation and v_page_size
v_page_size = VR30(2)

hto = (x-counter + VR27)(1..5)  // basically ((x-count + hscroll) / 
vto = (y-counter + VR28)(1..5)  // basically ((y-count + vscroll) / 

hpg_sel = ntba(3) when h_page_size == 0 else h_page_start
vpg_sel = ntba(2) when v_page_size == 0 else v_page_start


14-bit Address:

 MSB                                                                   LSB
|  0     1   |    2    |    3    |  4   5   6   7   8  | 9  10  11  12  13|
|8192  4096  |  2048   |  1024   | 512 256 128  64  32 | 16  8   3   2   1|
+------------+---------+---------+---------------------+------------------+
|ntba(0 to 1)| vpg_sel | hpg_sel |         vto         |        hto       |


VRAM tile address = ntba(0 to 1) & vpg_sel & hpg_sel & vto & hto
.

I'm not sure if that helps, but you can see that the vertical page size and current vertical page selection are wired in at the 2K bit in the VRAM address. That is why the vertical pages are always 2K apart in VRAM. For each scan line the vpg_sel will be initialized based on the current vertical page size from VR30 as well as the vertical page start from VR29. Also note that when the vertical scroll offset wraps, it will toggle the vertical page start bit if the vertical page size is 1. That is what causes the VRAM address to use name table 0 or 2 depending on the vertical page size. This works the same for the horizontal page select bit, but it is always at the 1K address bit.

 

There are other factors that affect the vto and hto like the border registers, banner size, and "fixed table" bits, but I'm leaving those out for the sake of simplicity.

 

Now that I think about it a little more, for horizontal scrolling you could set up four name tables at memory 0K, 1K (first two), and 4K, 5K (second two that skip 2K and 3K). Then you could change the name table base from "00" to "01", i.e. 0K and 4K. That would cause the F18A to use horizontal name tables 0K/1K and 4K/5K and the 9918A to use name tables 0K and 4K.

 

Clear as mud?

 

Another question: is Graphics Mode 1 (with or without ECM) the only mode where scrolling works? How about half bitmap mode?

When I implemented the scrolling I was only thinking about the 32x24/30 tiles and 8x8 pixels. Only after I got things working did I remember T40 and MCM "modes", but by then it was too late to rework everything. So in short, scrolling works no matter the "mode", but I don't know what exactly will happen. ;-) For GM2 it should be fine since it works with 8x8 tiles, but I don't recall testing GM2 with scrolling. Also T40/T80 should work up to 6 pixels, after that I don't know what will happen.

Edited by matthew180
Link to comment
Share on other sites

I'm bumping this idea - I'd love to see F18A emulation in MESS - something 80-column capable, nevermind the great games that have been made to use it now :).

 

Mess already has 80 column capability and much more, thanks to EVPC emulation with full 192k vram memory.

Why not use what's already there instead of shortchanging yourself?

 

Gazoo

  • Like 1
Link to comment
Share on other sites

@RobertLM78, OX.: Please do not underestimate the challenge of emulating this rather new device, in particular with the MAME/MESS emulation architecture in mind. This is not a task of one or two weekends, but rather something in terms of months ... if possible at all.

 

The primary benefit of the F18A, allowing the TI to do its video output on a modern monitor, is something given by default on an emulator. The second aspect, executing code inside that device with 25 times the speed of the TMS9900 in the TI console, may bring many host PCs to their limits. We can certainly go for some shorter ways inside the chip, compared to the real TMS9900, but we must also be ready to adapt it when there are new versions or changes.

 

I see it as a future goal, beyond mid-term. This is just my estimation, I'd be happy for any concept showing it's feasible.

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

The attached disk contains a program (E/A#3:PAL) that modifies the standard TI-99/4A palette to one with more pure colors. For fun, try running the file and then run some of your favorite games. The palette change survives a cartridge change, so in order to get back to normal colors you need to turn the power off and on.

 

09-Apr-2015: Fixed to lock F18A again.

F18ACOLORS.dsk

  • Like 5
Link to comment
Share on other sites

The attached disk contains a program (E/A#3:PAL) that modifies the standard TI-99/4A palette to one with more pure colors. For fun, try running the file and then run some of your favorite games. The palette change survives a cartridge change, so in order to get back to normal colors you need to turn the power off and on.

 

Rasmus,

Dude, that is so fricken AWESOME! :-o I just wish there was a way to AUTOLOAD it!

I'm tellin ya people, once you use Rasmus' new program, you'll never want to run your F18A equipped TI without it ever again.

Link to comment
Share on other sites

@RobertLM78, OX.: Please do not underestimate the challenge of emulating this rather new device, in particular with the MAME/MESS emulation architecture in mind. This is not a task of one or two weekends, but rather something in terms of months ... if possible at all.

 

The primary benefit of the F18A, allowing the TI to do its video output on a modern monitor, is something given by default on an emulator. The second aspect, executing code inside that device with 25 times the speed of the TMS9900 in the TI console, may bring many host PCs to their limits. We can certainly go for some shorter ways inside the chip, compared to the real TMS9900, but we must also be ready to adapt it when there are new versions or changes.

 

I see it as a future goal, beyond mid-term. This is just my estimation, I'd be happy for any concept showing it's feasible.

Well for RGB we have:

 

https://www.google.com/search?q=RGB+output+to+VGA+or+HDMI&oq=RGB+output+to+VGA+or+HDMI&aqs=chrome..69i57.12044j0j8&sourceid=chrome&espv=210&es_sm=93&ie=UTF-8#q=RGB+to+VGA+or+HDMI

 

 

And why buy the hardware when we have Classic99? It is much cheaper to just run a emulator on the current monitor we use.

 

Personally I am retired and can not afford the hardware or each hardware upgrade. On the other hand I can afford Emulatiors as they are free.

Link to comment
Share on other sites

 

And why buy the hardware when we have Classic99? It is much cheaper to just run a emulator on the current monitor we use.

 

Personally I am retired and can not afford the hardware or each hardware upgrade. On the other hand I can afford Emulatiors as they are free.

 

why? because i like the real thing. duh!

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...
  • 2 weeks later...
  • 4 weeks later...

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...