Jump to content
IGNORED

F18A


matthew180

Recommended Posts

Great to see you announce this!!

Yeah, I could not stand it any more. I still don't have the sprites done, but I hope to get some time to work on it again soon.

 

If I had a choice, I'd like to see the 4-sprite on a line limit active by default if it's there at all, but I only have one project that used it deliberately (to mask out sprites on certain lines), Classic99 survived for a very long time not supporting the limit without any real issues, too. I think that only software which expects the limit will be written for it, so a switch to enable it probably is not very useful.

I still don't know why you added the technically correct 4 sprite limit... It is going to take some serious convincing to get me to see why I would want to have the limit set by default. I like my idea of a register that you can set a limit if you want it.

 

That said, enhancing existing titles that flicker when you don't want them to is nice, too. Perhaps we could release a hacked GROM that lets you select certain VDP modes from the master title page? :)

Not sure what you mean by "tiles that flicker when you don't want the to"?

 

As for new GROM's, I'm all for it! You have a GROM board coming out soon, right? And the GROM's in the 99/4A are all in sockets already. :-)

 

Matthew

Link to comment
Share on other sites

I suspect that legacy games that used flicker or didn't allow more than 4 sprites per line will still operate the same as they always did with the new video chip. Some might crash or behave unexpectedly too.

Sprites being displayed do not affect the computer or an application in any way. The SAT (Sprite Attribute Table) is just bytes in the VRAM and the host computer interacts with sprites by reading and writing the SAT. The host computer has no idea whether or not the VDP reads the SAT and actually displays the pixels on the screen. As it is right now, I can run any game that has sprites and they work just fine, I simply can't see them (which makes playing MunchMan really hard. ;-) )

 

I'm not familiar with XB but does it have a POKE command? If so, you could still activate the enhanced mode using that (I'm assuming POKE has free reign over the memory map). Failing that a small assembly language routine could be called.

XB has a VPOKE, but you cannot use it to set the VDP's registers.

 

Matthew

Edited by matthew180
Link to comment
Share on other sites

If I had a choice, I'd like to see the 4-sprite on a line limit active by default if it's there at all, but I only have one project that used it deliberately (to mask out sprites on certain lines), Classic99 survived for a very long time not supporting the limit without any real issues, too. I think that only software which expects the limit will be written for it, so a switch to enable it probably is not very useful.

I still don't know why you added the technically correct 4 sprite limit... It is going to take some serious convincing to get me to see why I would want to have the limit set by default. I like my idea of a register that you can set a limit if you want it.

 

Because, I have one program that relied on it for correct graphics, and it bugged me. Also because someone was being twitty about it in the mailing list. ;)

 

My point is, either have it set on by default (with a register to DISABLE the flicker, rather than enable it), or don't include it at all. Having an option to turn it on doesn't help because I can't see anyone writing software for a chip without sprite limits but wanting to turn them on -- said software won't work with the real 9918. Software on the real 9918 that DOES expect the limit won't work correctly on yours, because it doesn't know to set the new register you are proposing. There's so little that relies on it my personal thinking is that either of these options are equal in desire. But saying you need to set a register to ENABLE 4-sprite-on-a-line -- I can't think of a case that would be used.

 

That said, enhancing existing titles that flicker when you don't want them to is nice, too. Perhaps we could release a hacked GROM that lets you select certain VDP modes from the master title page? :)

Not sure what you mean by "tiles that flicker when you don't want the to"?

 

Because I wrote "titles", not "tiles". ;) ie: games like the one you often quote, Munchman. :)

 

As for new GROM's, I'm all for it! You have a GROM board coming out soon, right? And the GROM's in the 99/4A are all in sockets already. :-)

 

No boards. I have a working single-chip emulation of GROMs that runs on AVRs are full speed. AVRs are not pin-compatible with GROMs, unfortunately (at least none I've found are), but you could wire them into the console. In fact one Mega168 can replace two GROMs. I haven't released it yet because I need to code up the write mode, and for larger AVRs, multiple GROM bases. Soon, I hope.. my last day at work is Friday, then I'm out of the country for a couple of weeks, then I need to knuckle down. ;)

Link to comment
Share on other sites

Just to mention, that MSX has another old VDP project too..

 

http://www.msx.org/VSU-news.newspost4862.html

 

Probably there is newer information somewhere too.

 

 

And two (though quite different ones) which are NOT projects anymore. ;) ( unless you call it a project if a latter one doesn´t have it´s box ready yet... ;) )

 

 

Franky

 

http://supersoniqs.com/2009/06/29/hello-world/

 

 

and Playsoniq

 

http://supersoniqs.com/2010/06/20/supersoniqs-announces-playsoniq/

 

 

Greetings,

MäSäXi, the soon-to-be-happy-playsoniq-owner ;)

Link to comment
Share on other sites

I still don't know why you added the technically correct 4 sprite limit... It is going to take some serious convincing to get me to see why I would want to have the limit set by default. I like my idea of a register that you can set a limit if you want it.

 

 

 

I think Mike's point is that your new processor would be best served being 100 percent backwards compatible at boot up and then software configurable. Since existing games won't know about unlimited sprites per line (and some do take advantage of masking) they May not behave correctly video wise. The VGA output and 80 column mode would definitely goad me into purchasing one or two but non realistic behavior at boot up would make me think twice. Or.....Perhaps you could implement a hardware jumper so a user could select which way it boots. Then you could satisfy everybody (or at least die trying) ;-)

 

I do have a question about your 80 column mode. Is it compatible with the 9938 or 58's 80 column mode. I would love to use the FW editor on a TI in 80 column mode on a VGA screen. Might even name my next child after you if you can pull all this off and I can get a 13 year old vasectomy reversed. ;-)

 

My poor little rat bike of a computer barely resembles a TI now. Hope to have something else to cram under the hood soon.

 

Marcus

Link to comment
Share on other sites

Perhaps you could implement a hardware jumper so a user could select which way it boots.

Eh, I really hate jumpers and switches sticking out of the console. I'll come up with something, maybe an LCD control panel or something. That would only, oh, double the prince I think. ;-)

 

Then you could satisfy everybody (or at least die trying) ;-)

:rolling: You will always die trying to please everyone.

 

I do have a question about your 80 column mode. Is it compatible with the 9938 or 58's 80 column mode. I would love to use the FW editor on a TI in 80 column mode on a VGA screen.

Don't know, I have not implemented it yet. Should I do one over the other? I have not spent a great deal of time in the 9938/58 datasheets yet (just enough time to know they suck ass and are confusing.)

 

Might even name my next child after you if you can pull all this off and I can get a 13 year old vasectomy reversed. ;-)

:rolling: Damn, two for two, you killing me today. Well, get ready to have another "Matthew" in your life. :-)

 

My poor little rat bike of a computer barely resembles a TI now. Hope to have something else to cram under the hood soon.

 

Marcus

 

:lol: You are in your element today. Thanks for the post, I needed a boost.

 

Matthew

Link to comment
Share on other sites

My point is, either have it set on by default (with a register to DISABLE the flicker, rather than enable it), or don't include it at all. Having an option to turn it on doesn't help because I can't see anyone writing software for a chip without sprite limits but wanting to turn them on -- said software won't work with the real 9918.

 

Well, part of my "global domination" life goal is to replace every 9918A in every computer with the F18A. That should take care of any incompatibility issues. ;-)

 

Because I wrote "titles", not "tiles". ;) ie: games like the one you often quote, Munchman. :)

 

Well I'll be, look at that, you did write "titles" and not "tiles". Well what did you expect, I'm clearly thinking about sprites and tiles, not titles?!?! :-)

 

Yeah, I use MunchMan because I can count my 99/4A games on one hand...

 

No boards. I have a working single-chip emulation of GROMs that runs on AVRs are full speed. AVRs are not pin-compatible with GROMs, unfortunately (at least none I've found are), but you could wire them into the console. In fact one Mega168 can replace two GROMs. I haven't released it yet because I need to code up the write mode, and for larger AVRs, multiple GROM bases. Soon, I hope.. my last day at work is Friday, then I'm out of the country for a couple of weeks, then I need to knuckle down. ;)

 

You know, one CPLD or small FPGA could replace a GROM or three real easy too. One board that spans all 3 sockets might be the way to go. Just some food for thought. I'm really having fun with the FPGA's and GAL's lately, so I'm biased towards those kinds of solutions now.

 

Matthew

Edited by matthew180
Link to comment
Share on other sites

Just to mention, that MSX has another old VDP project too..

 

Thanks for the links, I'll check them out. However, I have yet to find any 9918A project that actually got to the production phase and become available to purchase. The hardest part of any project is always on the details of getting is made, assembled, marketed, packaged, shipped, etc. I'm really planning to go all the way with the F18A.

 

Matthew

Link to comment
Share on other sites

However, I have yet to find any 9918A project that actually got to the production phase and become available ...

http://fpgaarcade.com/cv.htm

 

Been reading this VHDL code, and it ain't that bad.

 

Oh yeah, I've spent a *lot* of time on FPGA Arcade and reading Mike's code. That site is one of the main reasons I bought the devboard I did (it is the same one he was prototyping with.) The first thing I did was download the PACMAN code, compile and load it. It is pretty awesome to run the *real* game on *real* hardware.

 

However, all the stuff on that site is source code only, which is good, but it is not an end user product such that I'm planning for the F18A. Also, Mike seems to not really update the site much other than the news, and he's pretty focused on some new uber hardware MAME kind of thing. It would be awesome to talk to him about FPGA development and such, but the few times I've emailed he has never replied.

 

As for the 9918A implementation used in that ColecoVision project, I have that code and initially based some of my design around it. However, there are a few problems with the 9918A they designed and used:

 

1. It was very much designed to be use in a SoC (system on a chip) kind of environment. Getting it to actually plug into the socket in a real computer would take some modifications. That was my initial plan, get that 9918A code running, the hack it to add the features I wanted. There were problems.

 

2. It was designed to run at the original 10MHz, and thus has the same limits as the real 9918A. While that is fine and all, I wanted to add enhancements, and at 10MHz you just really can't do much more than the original.

 

When you jump up to higher frequencies, like the 100MHz I'm running at, things change. Stuff they are getting away with in that 9918A design simply won't synthesize at 100MHz, too much propagation delay in what they are doing. At 10MHz they have time, but not at 50MHz or 100MHz. So, I wound up not being able to use anything except some ideas about how to cut up the parts of the system and such, and even then my design was so different that it does not always work out. You learn a lot from reading other people's code though, so don't get me wrong, I'm grateful to have their VHDL to see how they did certain things.

 

You also get a really good idea about what designers of ICs go through. I'm earning my education for sure at 100MHz, but I can't even imagine trying to get something to run at 1GHz or more like modern CPUs. That stuff is insane. I have found that some of the best information has been from computer architecture and design books from the mid 70's. The information still applies and has helped me design and write better VHDL, plus understanding what I have to do to keep things running at 100MHz.

 

Of course you've already heard of this one

 

http://www.ti99ug.co.uk/g2.htm

 

:)

 

I did not know about that project, and I have never seen that website! Thanks for the link. I do have something to complain about though. The specs on that new system don't match the 99/4A. Gigabit Ethernet... 64MB of RAM... 18-bit color... Those are all way overboard for the 99/4A, IMO. Tursi and I have had this conversation numerous times, about what we *can* do vs. what we *should* do to stay true to the original machine. If you change too much, or add things that go way overboard, then the computer ceases to be a 99/4A and no one has any interest.

 

The common factor here is the fact that we all had a 99/4A at some point in our past and we each have an attachment to it. There currently is exotic hardware (AMS cards, Geneve stuff, etc.), but it draws a very small subset of the userbase because so few people have the stuff, and it is no longer generally available for purchase.

 

In designing the F18A one of my primary goals was to provide features that match the system (i.e. 512 colors max, etc.), yet provide enhancements that don't make new or existing software unique to the new hardware. I'll probably never have more "specs" than the 9958 provided, since those existed in the MSX2 systems which were 3.5MHz Z80 based, so that seems applicable to the 99/4A as well.

 

As for the sprite issue, I figured displaying all 32, no matter what row they were on, would not affect existing software or add anything that the original 9918A could not do, except fix the flickering when 5 or more sprites are on a line. Based on the feedback so far I now know I need to consider a 4-sprite limit as the original 9918A had.

 

Matthew

Edited by matthew180
Link to comment
Share on other sites

It is hard to say what the cost will be since I don't have all the details worked out yet. The FPGA itself costs about $30 USD and I'm currently working on my FPGA devboard, so I don't have to worry about the USB connectivity (needed to program the device) or the programmable ROM device to hold the FPGA's bitstream. Then there is the cost of having the boards made, plus overhead of assembly, etc. I have a rough number in my head though, $80 seems to keep floating around, but I just can't say. I will definitely try to make it as inexpensive as possible without compromising quality or features, and I'm pretty sure it will not go over $100 USD.

 

The current plan for the physical device is a 40-pin DIP package that will directly replace the 9918A in its original socket (in the 99/4A anyway.) There will be a connector (USB probably) for programming/updating the FPGA, and a header for connecting a sub-d 15-pin VGA connector via a pig-tail. This was the only way I have come up with so far to get the VGA connector out of the 99/4A, and would require cutting a hole in the back of the console. While not exactly ideal (cutting the hole is a pain in the ass), at least no one will have to do any soldering; the device itself would still be plug-n-play. This is one part I have not even looked at yet in detail, so any suggestions are welcome.

 

Matthew

Link to comment
Share on other sites

This morning, before I got to work I was thinking about the F18A and possible features.

 

Here's a crazy idea that is most likely impossible to do, but I guess it depends on the FPGA speed

and a lot of stuff I don't know a thing about.

 

Would it be possible to have multiple "virtual" F18A or 9918's and overlay them ?

 

You'd send a short special byte sequence to select the 1st or 2nd virtual F18A/9918.

 

The bottleneck is probably the amount of data you can dump from the TI-99/4A,

but if the VDP memory read/write window is open all the time, it could be sufficient for two F18A's or 9918's ?

 

Dunno if this would be useful, but if I recall correctly the MSX VSU project had such a feature.

Possible use: parallax scrolling, multicolored sprites, ...

Edited by retroclouds
Link to comment
Share on other sites

Sure, that is very possible. The cool thing about FPGA's is that they do actually work in parallel, as does all hardware. Once the design is finished I can duplicate it as many times as I want until I run out of gates in the FPGA. The biggest problem would be memory, since I'm planning on having an external SRAM, all memory access would have to be multiplexed, or there would have to be multiple physical SRAMs for each VDP in the FPGA.

 

It would be easier to just expand the capabilities of the VDP. I'm planning 8 or 16 colors per sprite in the future, along with other features. I was also kicking around the idea of a collision matrix of some sort that gives details about what sprites are overlapping with other screen pixels, or something like that. Hardware collision detection seems like it would be a good thing to have.

 

Something else I was thinking about was adding another VDP in the >8800 address range, just beyond the current VDP ports, but that would require console modification and such a thing is probably best left to doing in a complete SoC.

 

Matthew

Link to comment
Share on other sites

  • 2 weeks later...

Matthew:

 

I think you have a lot going for you in the implementation of the VDP in a gate array. Its a lot like Thierry's IDE card and USB card projects. As an old 99'er from way back, I think your premise of staying as close to what's under the hood of a regular black and silver console makes sense. There aren't that many 99'ers who have a PEB or the means to get one and your project makes it not only affordable (at the proposed $80 US price point), but desirable. I further agree with you in being able to pop a cartridge in the console and run "barefooted" is a great way to test compatibility. I eagerly await the results here in the great NorthWet.

 

Rick

Link to comment
Share on other sites

Hey Rick, thanks for the reply. Wow, post #1 for you! I feel privileged that it was in my project thread. :-) Keeping the 99/4A intact is very important when making these enhancements. If we make hardware that is no longer compatible with the original, then we no longer have a 99/4A, nor any attachment to our creation.

 

Matthew

Link to comment
Share on other sites

  • 4 weeks later...

Quick update, I actually got some form of a sprite working today. I took quite a long break from actually writing VHDL (several months at least) to read and do more learning, since my first 3 attempts at sprites failed miserably. I guess my brain just needed some time to soak it all in, mull things over, and understand what is going on with these kinds of chips and circuits. I started writing the sprite code last night and got a static, fixed pattern sprite on the screen. Today I added the VHDL to read the sprite's location, so I can now see a MunchMan sprite running around the screen (I do some testing with MM), and I can see and move sprite #1 from XB.

 

Right now I'm adding the VHDL to read the pattern information and handle the 8x8 and 16x16 sizes. Since it is working out very nicely, I just may have all 32 sprites up and running before the Faire, which I really did not expect to have done.

 

Anyway, more to come later, and I will have a full journal entry on the CHC site soon too.

 

Matthew

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