Jump to content

Recommended Posts

5 hours ago, --- Ω --- said:

will the new unit support a WIDE SCREEN resolution?

I don't know what you are asking.  Are you talking about some resolutions other than 256x192 (256x240 with row30 enabled) or T80 480x192?  Retro computers lived in a 4:3 aspect world, so coming up with a modern resolution, especially a wide-screen version, does not really fit with the era or systems.  There is no precedence to follow from the era for anything like that.

 

Also, I'm very hesitant to put a lot of effort into non-legacy features since it has been proven over the last 7 years (the F18A has been available since 2012) that people are very reluctant (and even unwilling) to write software that *requires* the F18A's enhanced features.  Anything that can't be written with a way to fall-back to the original VDP probably won't get written, and that excludes a lot of the F18A's exiting best features, let alone new ones.  I'm always hoping this will change, but so far it has not happened.

 

I know the F18A has been in short supply the last year or so, but I'm working on fixing that.  But the primary goals of the MK2 are a digital output, a 600-mil DIP footprint, and cost / part availability (the older FPGA used on the F18A is now more expensive than the better FPGA used on the MK2).

  • Like 2

Share this post


Link to post
Share on other sites
22 minutes ago, matthew180 said:

I don't know what you are asking.  Are you talking about some resolutions other than 256x192 (256x240 with row30 enabled) or T80 480x192?  Retro computers lived in a 4:3 aspect world, so coming up with a modern resolution, especially a wide-screen version, does not really fit with the era or systems.  There is no precedence to follow from the era for anything like that.

 

Also, I'm very hesitant to put a lot of effort into non-legacy features since it has been proven over the last 7 years (the F18A has been available since 2012) that people are very reluctant (and even unwilling) to write software that *requires* the F18A's enhanced features.  Anything that can't be written with a way to fall-back to the original VDP probably won't get written, and that excludes a lot of the F18A's exiting best features, let alone new ones.  I'm always hoping this will change, but so far it has not happened.

 

I know the F18A has been in short supply the last year or so, but I'm working on fixing that.  But the primary goals of the MK2 are a digital output, a 600-mil DIP footprint, and cost / part availability (the older FPGA used on the F18A is now more expensive than the better FPGA used on the MK2).

Well I for one would hope that we get to see a 80 columns 60 rows mode.

I'm preparing TiVi for supporting a variable amount of rows.  I'm now running at 80x30 and i feel that already helps.  ;-)

 

EDIT: Almost forgot to mention that I'm really thrilled by the F18A MK2 development. Really looking forward to that. Keep up the good work! 

 

Edited by retroclouds
  • Like 2

Share this post


Link to post
Share on other sites

I'm wishing for a 256x192 mode with a 256 color palette. Like good old VGA but at a slightly lower resolution. Preferably with double-buffering support. 

Share this post


Link to post
Share on other sites
1 hour ago, Asmusr said:

I'm wishing for a 256x192 mode with a 256 color palette. Like good old VGA but at a slightly lower resolution. Preferably with double-buffering support. 

I know Matt commented long ago that 9938 compatibility was not on his roadmap. But I would be excited to see 9938:

G6 512x256 16 color mode.

G7 256x192 8-bit color mode. 

 

I admit that I've not written any F18A specific code. 

Share this post


Link to post
Share on other sites

Some quick questions about the MK2:

 

Does it still output video on the original pins?  Can I get analog RGB from it?  I would like to put one in my Baby Pac-Man as the vidiot board in it does a terrible job with converting to RGB (Via a chroma decoder) I would like to get something that will look better on the original arcade monitor.  I would be sweet to also have a TV connected as a spectator monitor.

 

I still want one for my Colecovision, so the digital output for that will be awesome. 

 

 

Share this post


Link to post
Share on other sites
12 hours ago, matthew180 said:

Are you talking about some resolutions other than 256x192 (256x240 with row30 enabled) or T80 480x192?  Retro computers lived in a 4:3 aspect world, so coming up with a modern resolution, especially a wide-screen version, does not really fit with the era or systems.  There is no precedence to follow from the era for anything like that.

 

Also, I'm very hesitant to put a lot of effort into non-legacy features since it has been proven over the last 7 years (the F18A has been available since 2012) that people are very reluctant (and even unwilling) to write software that *requires* the F18A's enhanced features.  Anything that can't be written with a way to fall-back to the original VDP probably won't get written, and that excludes a lot of the F18A's exiting best features, let alone new ones.  I'm always hoping this will change, but so far it has not happened.

Yes, I was kind of hoping for at least 480 X 270 in graphics mode with it driving the monitor at X 2 or X 4 for compatibility.  Yes, I know 4:3 is the norm, but I kinda figured WHY does it have to be?  "If you build it, the will come."  😉

 

I can understand and appreciate your hesitance to invest so much time and effort into features that might get little use, but then again it could make our little platform unique in the retro community giving it the capability of porting over a whole new selection of games.  When it comes to added features, I'm of the camp that say's, "If you don't want them, don't use them."  Just like with your previous F18A model, it was billed as a 9918A replacement, but those added features made it AWESOME in my mind,  80 column ANSI graphics for the BBS being just one that comes to mind. 

 

From a marketing aspect, I see this as adding potential life to the devices sales lifetime and to the TI platform itself.  But you know me, I always want more! 

 

 

 

 

Share this post


Link to post
Share on other sites
6 hours ago, Tighe said:

Does it still output video on the original pins?  Can I get analog RGB from it?

 

The F18A never put out the original video signal, either composite or component, that would defeat the primary goal of the board.  The F18A does output Analog RGB at 31KHz, a.k.a. "VGA", but not the 15KHz needed to sync an arcade monitor.  It would be possible with the F18A and some customized HDL, but the MK2 will only output digital TMDS video.

 

I'm sorry, but there is no current F18A / MK2 solution to directly drive an arcade monitor.  If you put the F18A or MK2 into your Baby PacMan, you will have to use a different monitor.

 

There might be some options in the future, but I don't know and have not had time to think about it.

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, --- Ω --- said:

I was kind of hoping for at least 480 X 270 in graphics mode

270?  By "graphics mode", are you talking about a pixel-addressable layout?  270 is not divisible by 8 and would not work very well for a tile-based display, i.e. like all the modes on the 9918A.

 

5 hours ago, --- Ω --- said:

"If you build it, the will come."  😉

Proven to *not* be the case, thus far.

 

6 hours ago, --- Ω --- said:

then again it could make our little platform unique in the retro community giving it the capability of porting over a whole new selection of games.

The 99/4A already has the same graphics capabilities as the ColecoVision and MSX1, and the F18A gives NES and better capability, yet you do not seen people clamoring to port games from those platforms.  Giving the MK2 additional graphics capabilities won't make existing software run any better, and won't entice existing or new people to make new software for the 99/4A.

 

Every new features adds more complexity, a chance to break something that is currently working, create an unexpected incompatibility, and increases the amount of documentation I should write.

 

Maybe I'm too negative these days, and I get frustrated a lot.  It is also always better to under promise and over deliver.

 

  • Like 5

Share this post


Link to post
Share on other sites
12 hours ago, Asmusr said:

I'm wishing for a 256x192 mode with a 256 color palette. Like good old VGA but at a slightly lower resolution. Preferably with double-buffering support. 

Pixel-addressable?  That is a 50K buffer.  That is a lot of data to push from the host computer.

  • Like 1

Share this post


Link to post
Share on other sites

Yeah, and it is one of the few systems that I am unaware of anyone using the F18A in.  It would be nice to get a positive confirmation that it works as expected.  I almost got to try it out at the MGC in 2013, but I could never sync up with the owner of the cabinet.

Share this post


Link to post
Share on other sites
Yeah, and it is one of the few systems that I am unaware of anyone using the F18A in.  It would be nice to get a positive confirmation that it works as expected.  I almost got to try it out at the MGC in 2013, but I could never sync up with the owner of the cabinet.
I own one :) just got it last month. A survivor but works

Sent from my LM-G820 using Tapatalk

  • Like 2

Share this post


Link to post
Share on other sites
11 hours ago, matthew180 said:

Pixel-addressable?  That is a 50K buffer.  That is a lot of data to push from the host computer.

I would not be pushing 50K every frame, I would upload all the graphics to the F18A once and let the GPU take over from there. Even though there are more KB, having one byte per pixels can make it a lot faster to work with. And having 256 pixels per line makes address calculations as simple as possible (MSB is y, LSB is x).

 

  • Like 1

Share this post


Link to post
Share on other sites
On 9/8/2019 at 12:14 AM, matthew180 said:

I don't know what you are asking.  Are you talking about some resolutions other than 256x192 (256x240 with row30 enabled) or T80 480x192?  Retro computers lived in a 4:3 aspect world, so coming up with a modern resolution, especially a wide-screen version, does not really fit with the era or systems.  There is no precedence to follow from the era for anything like that.

 

Also, I'm very hesitant to put a lot of effort into non-legacy features since it has been proven over the last 7 years (the F18A has been available since 2012) that people are very reluctant (and even unwilling) to write software that *requires* the F18A's enhanced features.  Anything that can't be written with a way to fall-back to the original VDP probably won't get written, and that excludes a lot of the F18A's exiting best features, let alone new ones.  I'm always hoping this will change, but so far it has not happened.

 

I know the F18A has been in short supply the last year or so, but I'm working on fixing that.  But the primary goals of the MK2 are a digital output, a 600-mil DIP footprint, and cost / part availability (the older FPGA used on the F18A is now more expensive than the better FPGA used on the MK2).

I'm definitely counting on an 80 column text mode for s/w I used to run on my OPA 9958 upgrade (Funnelweb version of TI Writer, etc). The HDMI output option is super valuable to me also, though in scanning the thread it looks like that has switched to DVI? As far as graphics modes for games, etc, the F18A (original) opened up great doors, hence things like Super Mario port. I assume this new board would open those doors also.

Edited by patrickmcmichael

Share this post


Link to post
Share on other sites

The 80 column mode is in there now and works, but this doesn't mean that 9958 software automatically works. If it put the display buffer in the first 16k of VRAM, then the software would probably work. If it took advantage of the expanded memory, then porting work is required. We did patch a few pieces of software over the years, but Funnelweb's editor does more than just display 80 columns, it also uses the expanded memory for a larger buffer. The source is out there but I was never able to make sense of the build process. 😕

  

  • Thanks 1

Share this post


Link to post
Share on other sites

I agree that adding new modes is less important than adding access to the new RAM. I have given up several ideas for F18A games over the years because of the RAM limitation (my ray caster demo is one example). Access to the new RAM alone would open up a lot of possibilities. However, 256 colors would be really cool. I imagine I would develop a sprite library drawn by the F18AII GPU, and make games with scaled sprites like Outrun. I would also like to look into 3D with texture mapping etc. That is impossible with 16K RAM and 4 colors.

Edited by Asmusr
  • Like 4

Share this post


Link to post
Share on other sites

I'd like to see at least one really cool Kick-A__ game that shows the full potential of the MK2 when it's released.  Something that when you see or play it say, "Damn, that's unbelievable!"

Share this post


Link to post
Share on other sites

On the F18A, are the I/O ports limited to the bus speed of the 4A? Or is it possible to read/write at a faster speed if the host system can?

 

For example, if the host system were capable of doing a memory cycle every 333 ns (or faster?).

 

 

 

Share this post


Link to post
Share on other sites

Hmm.. I am a reasonably talented pixel artist (but a rather crappy programmer, sadly)-- Being able to have hardware manipulated 256 color sprites would be fan-****ing-tastic.  Telling the GPU to move sprites around, or to composite sprites/chars, would be a reasonable tradeoff for a quality indexed color mode. One of the things that always put me off qbasic programming was the lack of quality sprite routines. (NO. PSET is NOT good! There is no reliable way to move the sprite while easily retaining the background untouched without resorting to endless cycles of peeks and pokes! that defeats the purpose of using basic!)

 

I have a game concept in mind that I would like to flesh out.  I would love to do it on this TI I picked up. I could do quite a lot with composited characters, if that was an option. Sadly, it currently is not, and the stock graphics chip has... some nasty limits.

 

I really should set my avatar to one of my pixel art doodles.  I think I will do that now actually.

 

Edit: DONE 

That is 16 colors. The default ones MSPAINT offers. I could probably write a routine that could generate that image using layered characters, if the VPU supported doing that. (EG, write a char with a single BPP and two defined colors, one being transparent, with the option to composite rather than obliterate the prior char.)

 

Edit again:

I should probably explain what I mean better.

 

Suppose I wanted a 320x240 mode at 256 colors. This would require an addressable bitplane that is ~77kb! This is outside the realm of reality on the TI.  Or-- IS IT?

 

Suppose instead that I requested a 40 col X 30 row text mode, but with some flags I could tell the GPU, with the GPU holding the bitplane.  Specifically, I would ask for these flags:

1) Do not overwrite transparent color

2) DO overwrite transparent/background color

3) Hmirror char on placement

4) Vmirror char on placement

 

I could draw the same images as a fully addressable 320x240 bit plane, but do so with a FRACTION of the system ram, just iteratively.  I could define useful pixel patterns as chars, then put them down in a specific sequence, and be able to produce any arbitrary arrangement of pixels on the screen.  For static backgrounds, this would be a nice compromise. I could do a lot with that.

 

Specifically, I could abuse the empty space character after doing draws, to redefine characters on the fly without distorting the image. (From the TI's perspective, all that is written there is a blank space! We set the "Do not overwrite transparent color" bit, so the GPU keeps the data as composited in its internal bitplane while we redefine some more chars to do any specific operation!) I could theoretically draw *ANY* 256 color image with 2 characters, and enough time. (Write the transparent char over that position, but hold "do not overwrite" high, then redefine the brush char for the next composite step.)

 

 

 

Edited by wierd_w

Share this post


Link to post
Share on other sites
5 hours ago, FarmerPotato said:

On the F18A, are the I/O ports limited to the bus speed of the 4A? Or is it possible to read/write at a faster speed if the host system can?

For example, if the host system were capable of doing a memory cycle every 333 ns (or faster?).

Faster is certainly possible, it works at full speed with the Z80 in the ColecoVision. But I don't know what the numbers are. :)

 

  • Like 1

Share this post


Link to post
Share on other sites
23 hours ago, Asmusr said:

Access to the new RAM alone would open up a lot of possibilities.

I'm hoping to have that in the initial release, but if not, it will certainly come in a firmware update.  I'm trying to weigh initial features with getting the MK2 out.  The hardware will be ready before the HDL to support all the features I want to implement will be done.

 

23 hours ago, Asmusr said:

However, 256 colors would be really cool.

I'm trying to think if this would need to stay compatible with the 12-bit palette for any reason (i.e. with the original F18A).  Since the MK2 has a digital output at 8bpp, even the 12bpp palette has to be scaled.  So, 8bpp as the typical RRRGGGBB, and scale each color component to an 8-bit red, green, and blue value, respectively?

8bpp.thumb.png.d0f6d28289027cc92f461e98bbe5aea5.png

  • Like 1

Share this post


Link to post
Share on other sites
13 minutes ago, Tursi said:

Faster is certainly possible, it works at full speed with the Z80 in the ColecoVision. But I don't know what the numbers are. :)

 

The F18A's host interface should be good up to about 20MHz, or 50ns #CSR / #CSW cycle.  70ns (14MHz) for safety I suppose.  I'm hoping to get this a little faster in the MK2.  The way the GPU was integrated was not exactly ideal and could impact the host access time, and I intend to fix that.

  • Like 1

Share this post


Link to post
Share on other sites
4 hours ago, wierd_w said:

Suppose instead that I requested a 40 col X 30 row text mode

The text modes limit the tiles to 6x8, so you won't get get 320, you end up with the same 240 horizontal pixels in T40 mode, and 480 horizontal in T80.  However, you don't have the same tile color capabilities in the text modes as in the graphics modes.

 

4 hours ago, wierd_w said:

, but with some flags I could tell the GPU, with the GPU holding the bitplane.

The 9918A, and thus the F18A, do not work that way.  There is no "bitplane" being held in memory anywhere that can be used to modify existing pixels during subsequent frames.  The 9918A family is a table-based VDP that builds the image on the fly.

 

4 hours ago, wierd_w said:

I could draw the same images as a fully addressable 320x240 bit plane, but do so with a FRACTION of the system ram, just iteratively.

Where is this iterative image held between operations?

 

4 hours ago, wierd_w said:

so the GPU keeps the data as composited in its internal bitplane while we redefine some more chars to do any specific operation!

This requires more RAM than the 9918A or F18A has.  The MK2 will have the RAM, and in that case the host system would just have direct access to any such memory, it would not be exclusive to the GPU.  The GPU would certainly have access to this RAM too, and could be used to do any sort of pixel operations on the screen.

  • Like 1

Share this post


Link to post
Share on other sites
14 hours ago, matthew180 said:

The F18A's host interface should be good up to about 20MHz, or 50ns #CSR / #CSW cycle.  70ns (14MHz) for safety I suppose.  I'm hoping to get this a little faster in the MK2.  The way the GPU was integrated was not exactly ideal and could impact the host access time, and I intend to fix that.

Excellent. I'm thinking about a DMA mode in Geneve2020 between DRAM and VDP. Also, a pipe to VDP for interleaving mouse sprite updates without disturbing other VDP read/write (buffer VDPWA, change VDPWA, update sprite, re-insert VDPWA, all in a pipe). It helps if the pipe can run at higher speed than the user program can write bytes.

 

Share this post


Link to post
Share on other sites
8 hours ago, matthew180 said:

The text modes limit the tiles to 6x8, so you won't get get 320, you end up with the same 240 horizontal pixels in T40 mode, and 480 horizontal in T80.  However, you don't have the same tile color capabilities in the text modes as in the graphics modes.

 

The 9918A, and thus the F18A, do not work that way.  There is no "bitplane" being held in memory anywhere that can be used to modify existing pixels during subsequent frames.  The 9918A family is a table-based VDP that builds the image on the fly.

 

Where is this iterative image held between operations?

 

This requires more RAM than the 9918A or F18A has.  The MK2 will have the RAM, and in that case the host system would just have direct access to any such memory, it would not be exclusive to the GPU.  The GPU would certainly have access to this RAM too, and could be used to do any sort of pixel operations on the screen.

 

This was a request a feature (for the MK2), no?  I am well aware that the TI's hardware (and the current F18A) does not have such features.  And, again, I would only need 2 bit color for the char being passed-- The transparent color, and the active color for the brush. 

 

The idea was to get around having to map such a large section of the GPU's innards into the TI's video memory area.

 

Share this post


Link to post
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.

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