F18A MK2

[+OLD CS1]

My only wish for the MK2 is that I will have the time and focus to get around to utilizing it in a productive manner rather than just consumptive.

[GDMike]

BTW, what is the cooling requirement? Is it rather cool as is?

[+FarmerPotato]

10 hours ago, Asmusr said:

If you want to try what you can do with the F18A, Magellan has support for ECM2 and ECM3 colors modes for both sprites and tiles.

That's great. I used Magellan for 9d9damashi.

[JB]

8 hours ago, GDMike said:

BTW, what is the cooling requirement? Is it rather cool as is?

If I recall, the FPGA used for the F18A runs much cooler than a 9918a does, and needs no heatsink.

[+OLD CS1]

4 hours ago, JB said:

If I recall, the FPGA used for the F18A runs much cooler than a 9918a does, and needs no heatsink.

It actually absorbs heat.  Ever since installing mine, the "cup warmer" under the cartridge port runs cooler.

[JB]

2 hours ago, OLD CS1 said:

It actually absorbs heat.  Ever since installing mine, the "cup warmer" under the cartridge port runs cooler.

It breaks the cup warmer? That's a serious flaw!

 

 

[matthew180]

The F18A runs relatively cool compared to the original 9918A family.  The FPGA gets warm, but never what I would consider *hot*, and it is not necessary to have a heat sink.  I expect the MK2 to be similar, however, an FPGA's power consumption depends heavily on its circuit configuration, and since the MK2 HDL is not done, I'm not sure how demanding it will be.

 

At one point I did measure the current draw of the F18A, and it was around 130ma to 160ma IIRC.  The original VDP is rated at 200ma to 250ma (about 1W to 1.3W)

 

With the F18A, the system DRAM also becomes idle, which can account for some of the lower power requirements.  If you want to lower the power use even more, you can completely remove the DRAM chips since they are not needed with the F18A installed.  Also, the F18A does not drive the on-board video circuits, so there is a little more power savings there as well.

 

[+9640News]

So, if I can save about 0.5 watts of power/hour, with the TI-99/4A on for 2 hours a day, 7 days a week, the MK-2 unit will pay for itself in.......247 years with power at $0.20 KW.

 

 

Beery

 

[Omega-TI]

3 minutes ago, BeeryMiller said:

So, if I can save about 0.5 watts of power/hour, with the TI-99/4A on for 2 hours a day, 7 days a week, the MK-2 unit will pay for itself in.......247 years with power at $0.20 KW.

 

 

Beery

 

Without knowing the eventual price of the MK2 unit, it's actually impossible to make the calculation.

[+Lee Stewart]

31 minutes ago, BeeryMiller said:

So, if I can save about 0.5 watts of power/hour, with the TI-99/4A on for 2 hours a day, 7 days a week, the MK-2 unit will pay for itself in.......247 years with power at $0.20 KW.

 

 

Beery

 

Off by a factor of 10, I think.  That would be 2470 years!

 

...lee

[matthew180]

But the happiness it brings you is priceless. ?

[Tursi]

12 hours ago, --- Ω --- said:

Without knowing the eventual price of the MK2 unit, it's actually impossible to make the calculation.

Pays off a lot faster with California's electrical costs...

 

[wierd_w]

how feasible would a 2, 32 color palette mode be?  (Eg, 2 palettes, of 32 colors each)

 

There's a great deal of color "waste" with ECM mode 3, where you burn several colors on transparent color per palette, for instance. 

 

It is my understanding that the restriction is "Definition must fit/fill in 6 bits" right? 

 

Quote

To reference any of the 64 palette registers you need a 6-bit number (2^6 = 64) which is "000000" to "111111" or >00 to >3F hex.
Based on the ECM, a certain number of bits come from the pattern data, and the rest come from the per-tile attribute table and the
global "tile palette select" bits from VR24.

 

So, how about 5bpp color, 1bit palette select?

 

 

I can tell you, I would use the shit out of that.

 

 

[matthew180]

17 hours ago, wierd_w said:

There's a great deal of color "waste" with ECM mode 3, where you burn several colors on transparent color per palette, for instance.

In ECM3 you basically have eight groups of 8-colors.  The worst case is index 0 (zero) in all of the groups is treated as transparent, in which case you lose 8 of your 64 colors.  However, index 0 being treated as transparent is configurable on a per-tile basis, as well as the color-group (palette select) the tile belongs to, so it is totally possible that only one color is ever treated as transparent.  It is up to you to decide how you want to organize your tiles and colors.

17 hours ago, wierd_w said:

So, how about 5bpp color, 1bit palette select?

More bits per pixel means more VRAM used for pattern data.  4bpp would mean 8K of VRAM for patterns, and 5bpp would mean 10K of VRAM.  And that is just for the tiles.  If this were expanded to sprites as well, you are out of VRAM and would have to absolutely share pattern definitions between tiles and sprites.

 

The bitmap layer (BML) offers 4bpp right now in fat-pixel mode, and is very memory efficient since its x,y size is specified in pixels.

 

No matter how many colors the F18A offers, there is always talk of getting more.  5bpp, 6bpp, 8bpp, alpha channel support, etc.  At some point the capability stops aligning with the host computer system (early 80's computer) and the F18A.

 

The other problem is technical.  From a hardware perspective I can't add 5bpp and skip 4bpp, so this would be two more color *modes* (depths) to support.  I don't know if there is enough time to access the additional pattern bytes, per tile, to support more bits per pixel (scan line time *is* limited).  It also means wider multiplexers for the data and addresses to VRAM, which consumes more FPGA resources, and I'm already at 95% utilization for the original F18A's FPGA.

 

I'm also hesitant to add more features for many reasons discussed previously, ad nauseam.

[Asmusr]

On 10/3/2019 at 2:42 AM, wierd_w said:

I can tell you, I would use the shit out of that.

Maybe you would be interested in working together on a F18A MK2 game, within whatever limits it sets? There are not that many people around here with a flair for graphics, and I would rather spend my time coding.

Edited October 4, 2019 by Asmusr

[wierd_w]

5 hours ago, Asmusr said:

Maybe you would be interested in working together on a F18A MK2 game, within whatever limits it sets? There are not that many people around here with a flair for graphics, and I would rather spend my time coding.

 I would take you up on that, but I am currently already helping Farmer Potato with a Parsec derived title.  Currently drawing sprites for fancy ship movement animations. (already made him a set of 16 cardinal pointing direction sprites). After that comes asteroids, per his request.

 

(Which is why I voiced that I was chafing under the seemingly artificial restrictions of ECM3, and how it broke up the palettes. I can see the need for more than one hardware palette, just not the way ECM3 allocates it. It is very bare-bones what I can do with ECM3; It's barely enough to do simple monochrome shading with 2 accent colors left over, with the forced color zero transparency on each palette.  Sure, one could say "It's just 7 colors burned", but that is not the actual reality.  The actual reality is that 1/8 of the palette space is burned. At that low of a selection space, you have to fight for every color you get. Mathew says that this is per-tile configurable if the transparent color is forced transparent or not, but even then, I have to fight the restrictions when doing shading. I can do some sick shit with 32 colors though. That's enough for 8 colors AND their midtone shades-- EG, I can produce a workable general purpose palette out of that, and produce good results. As is, I can't do that. I am restricted to 7 colors + forced transparency, which is barely enough for 1 color and its midtones, plus 2 extra colors for accents.  I can do quite a bit with 1 specular, 1 deep shade, and 2 midtones per color, but only if the image is monochromatic. Well selected midtones can fool the eye into thinking there are more colors there than there really are. To do general purpose spriting though, rather than having to beat my head against a wall trying to juggle how to work around palette restrictions, it would make my life substantially easier to just give me fewer palettes, with more colors in them. If not 32 colors, at least give me 16 colors. That was the norm for high end color for systems of this era. I can derive a general color palette [with some less pretty results] that places the midtones between the primary colors selected, so that the same midtone colors can service two primaries, which will give me "acceptable" results. 3bpp color is barely enough to give shading with a single primary. Just not enough color space.)

 

(not without seriously over-planning the desired image, in the case of backgrounds so that each 8x8 pixel area is within the 7+1 color restriction, or without burning valuable sprites just to paint a few extra pixels a specific color, and burning a whole palette for doing just that-- anyway.) 

 

As respects "Moar colorsses precious! Moar colorsses!", if you cannot do your pixel art in 64 colors, there's a problem. As I stated, 32 colors is enough for 8 primaries AND their midtones+shades, which is a whole shaded rainbow for color. With 2 palettes, that's one that is full saturation, and one that is subdued. (For foreground and background.) I don't think I would actually really need more than that. Not for standard pixel art anyway. I might need more than that if I plan to use palette color based animations, but that's not basic package. Requests really should be Basic Package mindset.

 

Perhaps I should make some sample sprites to demonstrate how the lack of fidelity in color selection hinders rather than helps?   I get that there is a balance in getting the pixels on the screen, and gobbling up valuable vram space which could be better used for stack, but I think it would help to make a picture about what I mean?

Edited October 4, 2019 by wierd_w

[+FarmerPotato]

“Burning” another sprite overlay to get 14 colors is acceptable, for what should be the prettiest object in the game: the player ship. 

 

 

[Tursi]

at least give me 16 colors. That was the norm for high end color for systems of this era.

 

Can't agree with that. 1979 didn't have a lot of color displays, period.  C64 ('82) and NES ('85) both had 3 color sprites. 16 color hardware sprites weren't normal until the 16-bit machines started out in '87.

 

You also need to remember the F18A has already been out for years. The changes Matt is considering for the Mark2 won't automatically all work on the previous chip. Even if he takes your requests many people will probably not be able to run the software, at least for a while!

 

Just make your programmer overlay the sprites for more colors. Then you can also use multiple palettes. There's no flicker to worry about on the F18A and we have lots of sprites, so there's no real reason not to.

 

[wierd_w]

1 hour ago, Tursi said:

 

 

 

Can't agree with that. 1979 didn't have a lot of color displays, period.  C64 ('82) and NES ('85) both had 3 color sprites. 16 color hardware sprites weren't normal until the 16-bit machines started out in '87.

 

You also need to remember the F18A has already been out for years. The changes Matt is considering for the Mark2 won't automatically all work on the previous chip. Even if he takes your requests many people will probably not be able to run the software, at least for a while!

 

Just make your programmer overlay the sprites for more colors. Then you can also use multiple palettes. There's no flicker to worry about on the F18A and we have lots of sprites, so there's no real reason not to.

 

CGA debuted in 1981.

https://en.wikipedia.org/wiki/Color_Graphics_Adapter

 

Supported color depth was 16 colors. Not hardware sprites, no-- it was a bitplane based setup, but still 16 colors, and contemporary with the period.

 

I see this fancy VDP, and think more EGA though, which debuted in 1984.

https://en.wikipedia.org/wiki/Enhanced_Graphics_Adapter

 

What I requested is more in line with EGA, which would still be contemporary for the period.

[+Ksarul]

I think Tursi's original point was that from a contemporaries standpoint, the TI-99/4A has to be compared to the machines on the market when the system architecture was effectively frozen--1979. The TI had 16 colors at that time and kept that standard until production in the US and Europe stopped in 1984 (two years after that in South America). Sprites were a really special case back then. Most other available systems didn't have hardware sprites at all (the Atari 400/800 had their player missile graphics, but that was about it) until the late 1982 timeframe, four years into TI's TI-99/4 run (and a year into the /4A production), and as already noted by Tursi, they were only two to three colors.

 

The F18A is an outstanding fit for this environment and era, as it takes what was possible then and fine tunes it a bit, but it doesn't break compatibility while doing so. That was not the case with some of the Yamaha 9938/9958 enhancements that were available in the late 1980s, as they DID break older software, sometimes spectacularly.

Edited October 5, 2019 by Ksarul

[Tursi]

19 hours ago, wierd_w said:

CGA debuted in 1981.

https://en.wikipedia.org/wiki/Color_Graphics_Adapter

 

Supported color depth was 16 colors. Not hardware sprites, no-- it was a bitplane based setup, but still 16 colors, and contemporary with the period.

As Ksarul says.

 

If you want bitplane graphics, you're on the wrong machine. But the TI stock already had 15 colors (with the bitmap 8 pixel color clash), and the F18A has 64 colors in tile mode, 16 in bitmap mode (though, again, you can use the GPU to get more), and a 16 color true bitmapped overlay (with half the resolution).

 

You already have everything you're asking for. Put it to work.

 

[wierd_w]

Not exactly;

 

The stock VDP does 1bpp unless you take hard control over it with assembler. (2 color attributes, with foreground and background color, selected from 16 colors.)  CGA gives you much more, with pixel addressed painting, with the full 4 bits for color attributes, but lacks hardware sprites.

 

EGA gives a pixel addressable plane with 64 attributes, but no hardware sprites.

 

The flavors of BASIC for that class of system gave access to this with the (painfully slow) LINE command.  Theoretically, tile based graphics are more useful due to definition re-use. However, they are crippled by the limited color depth, compared to what the VDP is actually able to handle.

 

The "Already does what you want" is not correct either;  I do NOT get a unified 16 color palette, which can very much break things from a graphic arts perspective. THAT is what I am requesting-- A unified 16 color palette, not overlaid sprites, which are NOT equivalent, no matter how much you insist that they are. (The kind of argument you are making is akin to insisting that recursive addition is equivalent to multiplication, as justification for refusing to add a multiplication operator. Nevermind that when you then get to exponentiation, this becomes absurdly tedious.)

Edited October 6, 2019 by wierd_w

[+OLD CS1]

I may misunderstand, but it seems to me the F18A project is to enhance and even enrich basic 9918A VDP functionality, not replace it.  Moving away from the VDP way of doing things, like adding CGA or EGA modes, would seem to me to be very non-99/4A.

[jrhodes]

1 hour ago, OLD CS1 said:

I may misunderstand, but it seems to me the F18A project is to enhance and even enrich basic 9918A VDP functionality, not replace it.  Moving away from the VDP way of doing things, like adding CGA or EGA modes, would seem to me to be very non-99/4A.

I would be ok with CGA and EGA as long as it is user switchable somehow, not forced.

[Tursi]

19 hours ago, wierd_w said:

Not exactly;

 

The stock VDP does 1bpp unless you take hard control over it with assembler. (2 color attributes, with foreground and background color, selected from 16 colors.)  CGA gives you much more, with pixel addressed painting, with the full 4 bits for color attributes, but lacks hardware sprites.

/Sprites/ are 1bpp. But the VDP itself gives you 15 colors stock. You are comparing sprite layers to background layers. Then you start talking stock versus assembly language, and BASIC on other systems entirely. I've seen what you're producing so far - you can't do any of that without assembly anyway.

 

Anyway, what exactly is the point of this argument? To "win"? Okay. Congratulations: