810 replies to this topic

[matthew180]

The 9938 has a scan line interrupt, and having such a feature has been requested before (I think.)  However, I'm wondering what one might do with such information?  Any examples?

[Willsy]

matthew180, on Thu Sep 15, 2011 2:49 PM, said:

The 9938 has a scan line interrupt, and having such a feature has been requested before (I think.)  However, I'm wondering what one might do with such information?  Any examples?

Light pen, via the joystick port. Though you don't really need a scan line interrupt at all for a light pen, and none exist for the TI anyway.

[matthew180]

I don't think a lightpen works with an LCD, does it?  Any other reasons for a scan line interrupt?

[Tursi]

Reliable raster effects is why I wanted it (although like I noted, I don't know that I'd USE it, just something I've wanted in the past).

With a scan line interrupt, you can reliably do mid-screen effects like color swaps, screen mode changes, sprite multiplexing, and more.

For example, you could have text that is different colors on different scanlines (for rainbow effects). The same trick could give you a multicolored 40-column text mode (per line). You could do a stable split screen without eating all your CPU (for instance, bitmap on top with a 40-column text window at the bottom, like the Apple 2 has), or define more than 32 sprites by splitting the screen into zones (or even just turning off sprites after a certain scanline for vertical text windowing).

It can also be used, if returned to the CPU and the CPU can respond fast enough, for high frequency counters or sample playback. We may be a bit too crippled interrupt-wise on the TI-99/4A for this, though (otherwise the 9901 would already be enough).

None of this is too critical, really, but those were why I mentioned it in the past.

[OLD CS1]

Willsy, on Thu Sep 15, 2011 3:13 PM, said:

Light pen, via the joystick port. Though you don't really need a scan line interrupt at all for a light pen, and none exist for the TI anyway.

I thought Triton sold one way back in the day?

[Ksarul]

There was the Texas Light Shooter in the US.  There was also the Light Pen PEB card by Sven Dyroff in Germany.  I have the schematics for it.

[matthew180]

Tursi, on Thu Sep 15, 2011 4:23 PM, said:

Reliable raster effects is why I wanted it (although like I noted, I don't know that I'd USE it, just something I've wanted in the past).

Cool, thanks for the info.  Adding the raster interrupt is pretty simple and I will add it.  I was just wondering what someone might use it for so I could see if there were any features I could add that would help make such things easier.  Aside from the "special effects", it looks like timers are one reason to have it, although adding some additional programmable timers would be a simple thing.

[Tursi]

Because of the way interrupts work on the TI, we'll need a bit in the status register to differentiate vertical from scanline interrupts. Otherwise, fantastic!

[matthew180]

Any advice on exactly how the new interrupt should work?  I seem to recall from Thierry's page that the console ISR looks for the source of the interrupt in this order:

1. Cassette interface
2. VDP
3. PEB Cards (by testing CRU's or something)

I'm not sure what it does if it cannot locate the source of the interrupt, or if the user hook would be called in the case where it can't.

If the F18A generates an interrupt for the scan line and does NOT set the normal F flag, then the user hook ISR might not get called, and all that searching for the interrupt source by the ISR will add additional time, which for the scan line is critical.

If the F18A generates an interrupt for the scan line and DOES set the normal F flag, in addition to another flag to indicate the scan line was reached, then the normal ISR will be called twice as often, which would have side affects for the sound player.

The 9938 also has extra interrupts, but I have not paid attention to the details of those features yet.  I'll do that too and see what it does.  However, I'm thinking that if you are using the scan line interrupt, you will probably have to be polling the VDP with interrupts ignored via LIMI 0.  Or, if you use the ISR and user hook, you must realized that other ISR services will be affected.

Edited by matthew180, Sat Sep 17, 2011 7:43 AM.

[5-11under]

Matthew, I'm wondering if this product will be suitable for beta-testing of new ColecoVision games or not? Could there be cases where your VDP would work, where the TMS9928A would see a fault? I'm thinking more about timing issues that could crop up, rather than sprite flickering or minor colour differences.

Looking forward to seeing this available for sale!

[RXB]

Funnelweb with 80 columns was so much fun to use. YAPP (Yet Another Paint Program), X80 like a 80 column version of TML and Telco was 80 columns.

I would write a 80 column version of XB if we had that option. Just do normal XB in advanced modes.

I liked the 9958 the best as it had a built in Mouse interface but no one ever used it.

[matthew180]

5-11under, on Sat Oct 8, 2011 9:55 PM, said:

Matthew, I'm wondering if this product will be suitable for beta-testing of new ColecoVision games or not?

Beta testing *and* playing games. :-)

5-11under, on Sat Oct 8, 2011 9:55 PM, said:

Could there be cases where your VDP would work, where the TMS9928A would see a fault? I'm thinking more about timing issues that could crop up, rather than sprite flickering or minor colour differences.

The core functionality is very well tested, but like the 9938, I added features via an expanded register set, so there is always the problem of bad programming practices causing problems.  For example, the 9918A/28/29 have 8 write-only registers addressed in the low three bits of the second byte written during a "write to register" operation.  However, there is room in that second byte to address up to 64 registers by using bits in that second byte that are unused by the 9918A/28/29.  So, if some program code written for the 9928 was writing to VDP register 2 by passing any of eight values (instead of just 2), there will be problems.

What should be sent: "10 000 010" - low 3 bits select the register.  The next 3 bits are supposed to be zero on the 9918A/28/29, but the 9938/58/F18A use them to address more registers.

Sending any of these will cause problems:
"10 001 010" - R10
"10 010 010" - R18
"10 011 010" - R26
"10 100 010" - R34
"10 101 010" - R42
"10 110 010" - R50
"10 111 010" - R58

The 9918A/28/29 will ignore those middle 3 bits, the 9938/58/F18A will not.  Also, there are a few changes to a few of the originally unused bits in the existing registers to pick up extra video modes, etc.  The use of these extra bits in the F18A is the same as how the 9938/58 enhance the use of the original 8 registers.

Basically, as long as the programmers were/are setting up the VDP according to the datasheet, and setting bits to zero that were indicated as needing to be zero in the datasheet, then there should not be any problems.  Of course there is always the possibility for problems, but I'm working hard to make sure the F18A is 100% 9918A/28/29 compatible on the host-interface side.

There should not be any timing issues or anything like that.  Those problems are a bit easier since if they are wrong, the whole thing simply does not work.  The fact that the F18A runs in 5 out of 5 tested systems lets me know the timing is functioning correctly.

5-11under, on Sat Oct 8, 2011 9:55 PM, said:

Looking forward to seeing this available for sale!

Me too!  I'm putting as much time as I can spare in to it right now.  Feature creep has definitely set in, and I'm working hard to limit the list and get things implemented.

Edited by matthew180, Mon Oct 10, 2011 7:10 AM.

[matthew180]

RXB, on Sun Oct 9, 2011 12:11 AM, said:

I would write a 80 column version of XB if we had that option. Just do normal XB in advanced modes.

Willsy added "blind" (just set the mode without trying to guess the VDP type) 80-column support to TurboForth and it works GREAT on the F18A.  Why not just do the same on your version of XB?  Add an 80-column mode command, and if the user has an enhanced chip, they will get 80-columns, and if they don't, the 9918A/28/29 will ignore the attempt to set 80-column mode.

RXB, on Sun Oct 9, 2011 12:11 AM, said:

I liked the 9958 the best as it had a built in Mouse interface but no one ever used it.

The 9938 also has mouse support.  Yes, the interface was pretty much wasted.

Edited by matthew180, Mon Oct 10, 2011 7:19 AM.

[RXB]

Mathew RXB could do that with the TIM card using CALL POKER(VDP registers)
I only include registers 0 to 7 for RXB but wanted to include all the needed ones for 9958 or 9938.
But in order to get full use of a 80 column card a rewrite of XB would be required, other wise it would be just like the AMS is now.
i.e. there but seldom used.
A RXB with AMS and 80 Column support would be cool.

As for the mouse I wanted a RXB that would use a mouse all the time in 80 columns, much like a PC. The hardware did most of the work so a GPL test I did on the TIM showed this.

[Tursi]

There is a potential for timing issues, unless you changed this, Matthew? The F18A, as I understand it, runs more than fast enough to prevent CPU access from overrunning it as can happen on the TMS9918A. On the ColecoVision the CPU is more than fast enough to be able to do this (it turns out it's rather difficult on the TI-99/4A, 5-11). However, this means that there could be cases which work on the F18 which don't work on the 9918A if delays are not honored, which I think is what was asked.

Edited by Tursi, Mon Oct 10, 2011 11:48 PM.

[matthew180]

Ah yeah, that is true.  I was thinking about it the other way around, i.e. something that the 9918A would do that the F18A would not.  That is a tricky situation and falls in to the "proper programming practices" category, in my opinion.  You have to know that you can run over the original VDPs on those systems (CV, MSX, etc.)  I didn't think about it as a timing problem because, if you have the F18A and are programming a game to also run on the original chips, adding slow-down instructions like NOP or spacing your VDP access instructions to prevent overruns, won't affect the F18A in the least, i.e. it will work just fine.

I have to think this would be similar to writing a game on a system with a 9938 that you also intend to run on a 9918A.  But absolutely, if you have a system that is fast enough and can run down the original VDP, you won't have that problem with the F18A and thus you may write a program that won't run on the original.  I think that is the only host-to-VDP *interface* difference though, the rest are internal feature differences (sprites, colors, scrolling, etc.)

-- edit

I know that kind of stuff is going to come up, and the best way to make sure something is going to run on original hardware is to test on original hardware.  Also, I have to believe there will be a bug or two found in the F18A *after* release, and that sucks.  I'm doing what I can to minimize that possibility, but the deck is stacked against me.

Edited by matthew180, Tue Oct 11, 2011 6:58 AM.

[OLD CS1]

Do you have a method to update the firmware of the F18A while installed in a console?

[matthew180]

Uhm, yes and no.  The "best way" is to have an on-board USB solution, however that was not an option without almost doubling the size of the board and increasing the power requirements (I have to use equal or less power than the original VDP.)

I do have the ability to reprogram the flash chip via the FPGA, but that requires some sort of soft-core CPU, which I'm still thinking about doing.  It is dangerous though, since there is no way to "update before erasing", so if something goes wrong (power fails, or the system just glitches) during the erase or before the new bit-stream is programmed, then an external JTAG programmer is required to fix it.  The other problem is the size of the data file.  The bit-stream is between 200K and 400K, and that has to be available on the 99/4A somehow.  It would be very risky, but may be possible.

It is also possible that I may be able to find a relatively inexpensive JTAG programmer (if you consider $60 to $80 inexpensive... which it *is* as far as JTAG programmers go) that people could buy.

Hardware that relies on firmware is tricky due to the nature of possible bugs and needing to do updates.  Willsy has the same problem with the TurboForth cart, and like him, I'll probably have a few options for people to update.  One option will probably be a "send it in for an update", another might be a "put a deposit down and I'll send you a new board with the update, and you send me the old board at which point you get the deposit back", etc.

I think the best thing I can do is get a handle on the feature creep, and try to make it as stable and tested as possible.

[GroovyBee]

You don't really need to have USB on each PCB. If you have a cheap microcontroller on-board with a low speed UART that could handle flash programming then anybody that encountered a bug would need a TTL-232R-3V3 which is an FTDI USB to .1" pitch serial interface for a modern PC. If they have legacy serial ports then your PCB's "external world" RX interface can be as crude as a transistor, resistors and a diode and they make/buy an appropriate cable.

[matthew180]

Well, anyone who wants to go that route, there is a means to program the flash IC directly.  You need an SPI programmer (see dangerous prototypes) and an SOIC-8 clip.  That is actually the first way I programmed my first few boards, until I got sick of how much of a process it was and I just went with a JTAG programmer.

[GroovyBee]

It was just a thought for those people that aren't too techy.

[matthew180]

Beta Testers:

At the 2011 TI Faire I had the privilege to meet with, and get acceptance from, four people to help me with F18A beta testing.  These people are (using forum handles):

KL99
Tursi
Vorticon
Willsy

The project is to the point where I'm spending more time writing test programs than working on the device itself, so I decided it was time for beta testers.  Now that the hardware seems stable, and the v1.3 board has worked in every system I have tried it in, I'm now working on getting manufacturing quotes while I wrap up the feature set.  The F18A can not be updated in the field without a JTAG programming cable (about $50), so unlike modern games and such, I really need to work out as many bugs as possible before I start shipping the boards.

Heck, by total chance I picked up a Pole Position cartridge at the Faire and discovered a bug in the F18A!  The game plays, but there is a part before a race where a blimp is pulling a banner across the screen and it just stops and appears to hang.  A FCTN-6 lets you continue (or skip the animation all together), but the real 9918A does not hang like that.  My hunch is that it has something to do with collision detection and/or the early clock bit, which are both aspects of the 9918A that are not very well documented.

I know there are those of you who really want to get an F18A, and I assure you I'm working on it as fast as I can.  If only I didn't have a pesky day job getting in the way...

Edited by matthew180, Wed Nov 23, 2011 8:54 AM.

[Tempest]

If you need games to test, I can bring my TI-99 collection next time I'm over and we can waster some time testing some games.

[matthew180]

PRE-ORDER is open!  $98 each.  Go!

Well, the day (or night, depending) has come!  I'm finally going to get off my duff and get these out!  For the first run I need to do pre-orders to cover the parts and manufacturing costs.  The price is $98 per unit.  I was hoping for a little less, but that's what is all worked out to be.  So, let's see how bad everyone really wants this... :-) 100 is the minimum batch size.

For the impatient, head over to the CodeHackCreate Store (http://codehackcreate.com/store) and place your pre-order.  BUT, please read the whole description before placing an order!  I don't want to deter anyone, but I don't want anyone to be surprised either.  The order page contains a lot of information that I will, for the most part, repeat here.

PLEASE use the store to check out.  Yes it required PayPal, but that's really the only viable option for me right now.  If you *absolutely* have to send me a money order, then fine, PM me, but please consider the CHC store checkout first.  Thanks.


RETURNS IN CASE OF PROBLEMS

There is a $6.30 non-refundable fee in case there is a problem getting the boards made.  That cost is essentially the fees to refund the money back to you.  Obviously this is not a situation I want to get in to, but in the event things go for the worse, everyone needs to be aware that a 100% refund will not be possible.


KNOWN QUIRKS

Since the F18A uses an FPGA, it is not possible for the F18A to power-on as quickly as the original VDP.  In some instances when a system is turned on and comes out of power-on reset before the F18A is ready, the system may hang or not start correctly.  Usually a simple power-off / power-on will correct the problem, or if your system has a real reset button, that should also remedy the problem.  The F18A needs about 100 milliseconds to come ready after power is applied, compared to the original 9918A's power-on requirement of only a few microseconds.

Most systems use an resistor and capacitor as an RC-time constant to control the power-on reset time, and in systems with known fast power-on reset times, a simple modification to make the resistor or capacitor lager will extend the reset time and make a reliable power-on for the F18A enabled system.

Information will be available soon for systems where the power-on reset time might need to be extended.


DETAILS

This is a PRE-ORDER for the first run of F18A V1.3 video boards.  The cut-off date will be February 24th, or when a quantity of 100, 250, or 500 has been reached.

Turn-around time is approximately 3 weeks, but may vary.  Updates will be posted as I get more information during a run.

In the event where some number of pre-orders between those numbers listed above is obtained, I will try to fund the balance to bump to the next level.  If I cannot, the lower amount batch will be run and I will push for a second batch to fulfill the remainder.  If that does not work, refunds (see above) will be issued.


PLEASE MAKE SURE YOU KNOW WHAT YOU ARE BUYING!

The F18A is a pin-compatible replacement for the TMS9918A, 9928, and 9929 Video Data Processors used in classic home computers and game systems.  The F18A has been tested in the following systems:

TI-99/4A Home Computer

ColecoVison Game Console

ColecoVision Adam Computer

Toshiba HX-10 MSX1 Computer

SpectraVideo 328 Computer

Tommy Tutor (by Feb 24th)

The F18A is functionally compatible with the 9918A and works in both NTSC and PAL systems.  In the case of PAL, your system interrupt will function at 60Hz with the F18A installed.  50Hz operation is not an option.  The output is a standard 640x480, 60Hz, analog VGA signal.  The composite output of your system will no longer be active.

Note that certain systems require the original VDP to be desoldered and a socket put in its place.  Systems known to require the installation of a socket are the ColecoVision (and Adam) and SpectraVideo 328.  The F18A does NOT come with a socket, although kits for various systems may be available in the future.  Please make sure you have the means to replace your original VDP with a socket if necessary.

The F18A CANNOT be "piggy backed" on to the original VDP.  Do not try this, it will not work and will probably damage your system and the F18A.


UPDATES

The F18A is not currently field upgradable.  If a bug is found, an upgrade service will be available for the cost of return shipping, which is about $5 U.S., and $15 everywhere else.  There may be a European upgrade option via the Beta Testers, but that has yet to be set up.


WARRANTY

Each board will be programmed and tested in a real computer system prior to shipping.  If your board does not work, it can be returned for a replacement as long as there is no obvious physical or electrical damage due to mishandling or improper installment.

While I have done everything possible to ensure the F18A is 100% compatible with the original 9918A, I make no claims or guarantees that the F18A will work with every system or software where the original VDP works.  It is possible I got something wrong and some software may not run properly.  I will do everything I can to correct any bugs that are found after the boards are shipped.


OTHER STUFF

Yes, there are currently a few remaining bugs that I hope to have worked out by the time the boards come in.  At least now I have a fire under my ass.   There are some additional features I'd like to get in as well, so we will see what happens.  I also hope to make some install videos, as well as programming information for the enhancements.

Attached Files

•  product_01.jpg   63.07K   73 downloads
•  product_02.jpg   51.48K   79 downloads
•  product_03.jpg   48.6K   60 downloads

Edited by matthew180, Thu Feb 9, 2012 9:23 PM.

[Ksarul]

Excellent. . .on my way over there shortly.