F18A

[discomeats]

Thanks for the explanations, I'm pretty clear now on all the features you were talking about. I'll see what I can do and what makes sense. Some stuff is obviously easier than others, and a few I think are too advanced for the 99/4A.

I'm just glad it all made sense and indeed it starts taking a lot of cpu to manipulate a lot of features interactively especially when talking line by line video hardware reprogramming. Really I think most folk would be overjoyed with palettes, complete sprite freedom and scrolling, I'd certainly like dual playfields too.

 

I have definitely given that some thought too! The 99/4A hobby market is not as big as we would all like it to be, so any means to expand the potential user base makes things more feasible, and in some cases possible.

Plus extra pocketmoney too couldn't hurt

 

 

Yes, yes it is. And many people have the perception that just because their modern PC has something, or that the collective "we" have had such technology for years and years, that is should be a simple thing to add. People forget that it took years of iterative development and knowledge to create the stuff we have today, or even chips that came a few years later (like the 9938/59, 9990, etc.) However, as a hardware developer, I'm just starting out and I don't have the luxury of a team of electrical engineers and mathematicians to help work out the design, or years of making graphic hardware.

 

On the plus side, what would have taken a team of well qualified professionals in 1980 can be done by just one guy, I just wish the cost of physically realising things was lower, what starts looking like a $20 of parts project is guaranteed to end up costing a minimum of $100 for each unit.

 

It is easy to get lost in a feature list; I did when I started working out the features I originally wanted to include, and almost none of those features are in the design today.

Well, start simple, once you know that you got the basic stuff nailed down you can start adding crazy stuff for later versions.

[Willsy]

Matthew, did you ever think about doing a 9900 or 9995? I'd like something like a 9995 (which is a sanitised version of the 9900 with pipe-lining and the read before write crap removed) with some 32 bit instructions.

 

E.g MOV.L ADD.L. etc etc... 32 bit loads, shifts etc.

 

That would be nice!

[matthew180]

I was working on adding a 9900 inside the F18A as a GPU, but I have not had the time to put in to it and I don't want to hold up the F18A any longer than necessary. I think the Geneve FPGA project is doing the 9995 so I never considered it. I would probably do the 9900 first anyway, since I would need it for a 99/4A FPGA SoC. If no one has finished the 9995 by the time I get done with the 9900, I could probably look in to it. I also thought about putting a Forth CPU in the F18A. :-) I have an example written in Verilog and it would not be to hard to translate it to VHDL. Could you imagine 100MHz Forth inside the 99/4A?? I don't know Forth though...

[Willsy]

Could you imagine 100MHz Forth inside the 99/4A?? I don't know Forth though...

 

Yes. I could! <swoon>! And Forth 'assembly' (because that is what it would be) is no more difficult than any other assembly language. It's much simpler than desktop Forth systems; it's just a few instructions like DROP DUP SWAP + - etc. They don't usually have an IF ELSE THEN for example, they have a simple test and jump/don't jump, like any other processor.

 

E.g.

2 3 + (add 2 and 3 - result on the stack)

5 = ( is the value on the stack equal to 5?)

JIF xx (jump if false to label xx otherwise continue)

 

Anyway... I digress... Is there a list of the F18A features that go over and above the standard 9918 chip?

 

Mark

[matthew180]

Anyway... I digress... Is there a list of the F18A features that go over and above the standard 9918 chip?

 

I think any previous feature lists are probably out of date, so I will make a new one here. :-)

 

Currently the F18A reproduces all of the original functionality except there is no external video support, and no color composite output. These are very analogue features of the 9918A and I have no plans to add these attributes.

 

These features go above and beyond the 9918A and are already implemented:

 

* 32 sprites on a line

* 25MHz host interface, meaning the 99/4A and other systems that use the 9918A can not overrun the F18A

* 9938 compatible 80-column mode

* pin compatible drop-in replacement

 

These are the features I'm actively working on adding before releasing:

 

* Increment by 1 or 32 option for the VDP's auto-increment address

* X,Y flip for sprites and tiles

* Programmable palette

* Extra character rows (28 or 30)

* An extra mode to support horizontal and vertical scrolling, based on the NES graphic mode

 

These are features that might make it depending on how things work out *logically*:

 

* Multiple palettes

* 4-color sprites and tiles

* 32-bit random number generator (100MHz operation, 1 RNG per clock)

* Gray-scale composite output (this is in addition to the VGA output)

* Sprite linking

* Horizontal line interrupt (only 1, like the 9938)

 

These are features I would like to have, or could have, but probably won't make the release

 

* GPU based on the 9900 architecture

* In-system updates (requires the GPU)

* Built-in loadable fonts (requires the GPU)

* Graphic commands (requires the GPU)

[+Yurkie]

I really wish you would add color composite, I am confident you could sell 100+ in the CV community.

[matthew180]

The original chip already puts out color composite, so there would be no reason to use the F18A if that was the end goal.

 

FPGA's don't have analogue circuits (other than special FPGA's with very specific features), so the generation of NTSC and PAL composite requires additional external components which complicate the circuit, make the board bigger, consume more power, etc. I had it in the original design, along with a USB controller for a mouse and updates, external SRAM for more video memory, etc. Maybe in the future I will do an externally powered video system or something, but for right now I have to keep it to the basics so I can get it done and in people's hands.

 

The only reason I'm even considering gray-scale composite output is because of an article I read on generating b/w composite with two digital outputs and 3 resistors. That seemed doable, but even that simple design soon blew up in to 6 additional components (one of which is an active opamp), 4 weeks of research, testing, design, a board change, etc. and I'm still not sure if it will work very well.

[Willsy]

This sounds great! If there is room/bits spare it would be nice if it could detect coincidence between an "on" sprite pixel and an "on" tile pixel (32 column/64 column) of an on pixel in bitmap mode...?

[matthew180]

Sprite / tile collision detection? It is possible, and it is easy to talk about, but hard to be specific about. How would the collision be reported? Would it take in to consideration "1" pixels that are transparent (i.e. a sprite with a color of 0)? Would all sprites be detected, or just a few? If all sprites, where is the collision data written and when it is valid? Is there an interrupt associated with the collision? If so, when, where, how is it reported? What happens if a sprite collides with two tiles at the same time?

 

I don't mind kicking around ideas, but if something is going to be implemented it has to be fully designed. I usually look for existing features from other chips, i.e. the 9938, the NES, etc. and if the feature fits, it may be incorporated. I got the idea for the increment-by-32 from the NES, and it makes good sense when updating the VRAM for horizontal scrolling (nice feature, totally defined, easy to add.)

 

Otherwise, doing that kind of design just takes too long and is a serious pain in the ass when you have to keep everything somehow compatible with the 9918A. That's why I really don't like the 9938 very much, everything they added is just a huge kludge to add new features without blowing the 9918A compatibility. It gets messy, and there are at least 3-exceptions for every feature.

 

If anyone wants to tackle the implementation details for sprite / background collision detection, I'll definitely look at it and see if I can add it. Keep in mind that the display generation is 1 pixel at a time, and extra random memory accesses are expensive to add to the design.

 

At the time of pixel generation (when collision detection would have to happen), the design "knows":

 

* the sprite pixel (0 or 1), color code, and number (0 to 31)

* the tile pixel (0 or 1), fg and bg color for the tile, and the tile "name" (0 to 255)

 

That's it. You don't get to "loop" through a sprite's or tile's pattern data, make a bunch of random memory accesses, etc. Also keep in mind that generation is from top to bottom, left to right, and sprites are considered on the scan-line prior to where they appear (that's how the 9918A and derivatives work.)

[99'er Forever]

I just want vga output. I imagine the step to that would be similar to stepping from the RF to composite. It was like a different machine the day I found a composite cable.

[+InsaneMultitasker]

Ran across this not too long ago and thought it was interesting. If I understand correctly, they put the whole MSX2 on a chip, including the V9938.

 

http://en.wikipedia.org/wiki/1chipMSX

[sometimes99er]

Ran across this not too long ago and thought it was interesting. If I understand correctly, they put the whole MSX2 on a chip, including the V9938.

 

http://en.wikipedia.org/wiki/1chipMSX

Could it be reprogrammed to be a TI-99/4A ? I know the cartridge ports probably won't work, but then ...

[+OLD CS1]

Could it be reprogrammed to be a TI-99/4A ? I know the cartridge ports probably won't work, but then ...

 

I see a couple of card-edge connectors. I figure it should be just a matter of building a physical converter then programming the correct logic. Could I program the logic? No. But I can certainly design and build a card-edge connector adapter.

[matthew180]

Ran across this not too long ago and thought it was interesting. If I understand correctly, they put the whole MSX2 on a chip, including the V9938.

 

http://en.wikipedia.org/wiki/1chipMSX

 

Yeah, I have talked to some MSX guys about that, and about continuing the development. Seems the guy who wrote it is "gone", either he died, is terminal, or can't be gotten a hold of, and there is a lot of rumor to exactly what is up with the whole thing. Also, the company who was making the boards seems to have had problems, a lot of politics, back-stabbing, etc... Hey, this is starting to sound familiar...

 

Anyway, yes, the guts of the MSX2 were coded into a single FPGA and the circuit board broke out the standard MSX2 connectors and such. The HDL is available via download, and the design includes a 9938 core. I have looked at it briefly and most of the comments are in Japanese (or some form of an Asian dialect), and the layout is rather complicated since it is running at the original MSX2 / 9938 clock frequencies.

 

Either way, it does not really help me much since I can't put a 9938 in to a 9918A socket (for reasons mentioned before, but the primary one is the extra mode pin that the 9938 uses, which a 9918A system would not have physically wired up.) Also, I'm not really fond of the 9938, and the more I learn about it, the less I like it at all. It is a kludge, and all the new modes are bitmap, and IMO that is too much data for a system like the 99/4A to push around. Maybe I need to be "enlightened".

 

I was actually on the list to buy two of the one-chip MSX boards, but they company making the boards never did a second run. The FPGA they used was comparable to the one I'm using for the F18A. As it stands, my design is only using about 10% of the FPGA, so a complete 99/4A on a single FPGA is very possible, just like the MSX, C64, PacMan (and other) coin-op games, etc. have been done on a single FPGA.

[matthew180]

This weekend I had a chance to test the F18A in a Coleco ADAM and it worked fine. :-) I have never hand a chance to see and ADAM (other than pictures), and I didn't realize it was a ColecoVision with an add-on!! There are two boards inside, and one is a complete CV, the other is the ADAM attachment. The video generation is provided by the CV board, so, since the F18A works in the CV, it was pretty much a sure shot that it would work in the ADAM too. And yes, I forgot to take a picture! DOH! :-(

 

Also, like the CV, the ADAM's CV-board has the VDP soldered on the board, so upgrading to the F18A is going to require desoldering the original VDP and replacing it with a socket. I have found the Coleco boards to be particularly difficult to desolder and it would be easy to damage the board if you are not careful. Sadly this might be a show-stopper for some CV / ADAM owners.

 

Thus the list of tested and working systems:

 

TI-99/4A

MSX1 (Toshiba HX-10)

ColecoVision

Coleco ADAM

 

I also had a chance to test in the SpectraVideo-328 again, and sadly my latest revision still does not work in that system. It was another blow and a sad moment. I guess I still have a lot to learn about making video chips. On the plus side, the SV328 owner (Tempest) let me hold on to the system for a while to test with, and that is much appreciated!

 

It also seems that I may get a chance to test in a Tommy Tutor too! :-)

[+Ksarul]

Matthew, I have a number of Tomy Tutor machines--including a Pyuuta and a Pyuuta Jr. If you like, I can let you borrow one of the regular ones for testing.

[matthew180]

@Ksarul: Thanks for the offer, I really appreciate it! There is actually someone close by (if you consider 1.5 hours drive as "close") who is going to bring a Tommy over in a week or two, so let's save the shipping costs for now. If it does not work out for some reason, I'll definitely take you up on your offer.

 

F18A update:

I fixed the SpectraVideo-328 problem! Basically it has about a 100ms POR (power on reset) circuit, but the FPGA needs about 100ms to load its bit-stream at power on. So basically the F18A was not ready in time and the SV328 was waiting for the interrupt which was not configured. I changed the POR time from 100ms to about 400ms by adding a capacitor in parallel to the existing POR circuit's timing capacitor, and the whole system jumped to life. :-) At least the fix it very simple.

 

The power-on configuration delay is unfortunately one of the down-sides of the FPGA, and I can't really do much about it. The real 9918A is ready after a few microseconds from power on. Luckily the 99/4A has a long POR, but the CV and MSX are kind of quick and every now and then I have to power-off then back on if the F18A did not come up fast enough. I will identify these problems where I can and suggest fixes, i.e. changing the POR timing capacitor or resistor to make the POR a little longer.

[+Yurkie]

Matthew if a CV is connected to a 1080p TV does it display like a 4:3 television program, or is it a small window on the display?

[matthew180]

I have no idea, I have never connected a CV to anything but a VGA monitor via the F18A. I would assume that the native composite output from a stock CV (i.e. with the 9928) would display just like a 4:3 TV picture.

 

As for the F18A VGA output connected to a modern HDTV, I don't know that either, it totally depends on what the TV does with the signal. Also, most modern TV's probably don't have the HD15 analogue VGA input. My particular HDTV does have the VGA input, and the TV lets me select to expand the picture or have black bars on the sides.

[+Yurkie]

With RF or composite the TV automatically upscales and it is like a 4:3 tv program.

 

I am guessing the VGA will probably upscale, please post the results if you test it on your LCD TV.

 

When can I buy one of these? I want to install in a ColecoVision and show off your brilliant work over in the ColecoVision forums.

[+Yurkie]

Does this increase the video ram, scrolling and color pallete on the ColecoVision allowing for more complex homebrews?

[matthew180]

When can I buy one of these?

 

That's the six million dollar question. Believe me, I want them done ASAP, and I'm really shooting for a release this year. The board revisions should be done (hopefully no more bugs or changes will be required) so I can concentrate on finishing up the feature list. I'm still not sure of the cost, but at this point I'm pretty sure it will be under $100.

 

Does this increase the video ram, scrolling and color pallete on the ColecoVision allowing for more complex homebrews?

 

More video RAM, no. It is the same 16K. I wanted to have more, but that would have required more external parts, expense, board size, power requirements, etc. However, you can access the VRAM at full-speed, any time you want. You don't risk overrunning the F18A until you hit the 25MHz or so CPU speed.

 

I'm adding pixel accurate horizontal and vertical scrolling right now this week. I'm not sure what modes it will be available in, but definitely graphics mode 1, as well as the "enhanced" mode I'm adding.

 

I'm also adding 64 palette "registers" or Palette RAM (PRAM I'm calling it). Color in the F18A is 12-bit, i.e. 4-bits per color (red, green, blue), so each PRAM location is 12-bit. These will be fully programmable and will allow two ways to specify color:

 

1. Four palettes of four colors. This will support to original color access of the 9918A. There will be a new 2-bit Palette Select register that will allow you to select one of the four 16-color palettes to use.

 

2. Sixteen palettes of four colors. This will be used in the new color modes where sprite *AND* tiles can have four colors (2-bit addressing) from any of the sixteen palettes. *Each* tile "name" (0 to 255) will be able to use *any* of the palettes, i.e. no grouping of tiles in to sets of eight.

 

I'm also adding one new "mode" with features that may be available in some of the original four modes. The new mode is an extension of graphics mode 1, based heavily on the NES graphics, and has these specs:

 

* 32x30 tiles (8x8 pixels each)

* Four tile pages in a 2x2 configuration to help with scrolling

* Pixel level horizontal and vertical scrolling

* Four colors (2-bit) per tiles "name", i.e. each of the 256 tiles can have their own four colors from the sixteen available palettes

* Three colors per sprite (color "00" will always be transparent for sprites)

* Flip X and Y for tiles and sprites

* Tile "priority", selectable per tile name, that gives the tile priority over sprites

 

There is probably more, I just can't think of it right now. Once it is all coded I'll write up programming details and make some examples. I decided not to add any of the extra 9938 modes (other than text mode 2) because they were all pure bit-map modes and really require more than the 16K of VRAM currently available (other than the 2-bit per pixel mode, which might get added... don't know yet though.)

[+Yurkie]

Your card will completly eliminate the annoying flicker on the ColecoVision when more than 4 sprites are in a scan line correct?

[matthew180]

The VDP (which in this case is the 9918A, 9928, and 9929) has a limit of 4 sprites per line, as everyone probably knows. Any part of a sprite that is the 5th or greater on a given horizontal scan line will not be displayed.

 

The "flicker" in some games is not due to anything the VDP is doing directly. Where there are more than 4 parts of any sprite on a line, the 5th and greater sprites are simply not displayed, *at all*. The flicker happens when software tries to fix the problem by detecting when there are more than 4 sprites on a line, and rotates the sprites to allow the higher sprites to be displayed for a frame. So, the software is solving the problem by displaying the sprites every other frame or something like that, thus you get flicker.

 

So, depending on how fast the software works, and what it does, you may still experience some flicker, which again, is due to the software and not the VDP.

 

Any code that simply lets the 5th or greater sprites "disappear", those sprites will now show up. However, it was noted (previously in this thread) that sometimes this is desirable, and some programs use that limitation as part of the program. For example, the 5th sprite limitation can be used to hide sprites behind other sprites. Due to this, the F18A has a jumper, as well as a new register, to control the sprites per line features.

[+Yurkie]

Perhaps I don't understand. Are you saying that there will be no noticeable improvement with the ColecoVision, aside from the VGA output?