Random F18A questions

[RXB]

I usually stay quiet in these. I'm not a mod. However, I hope I do carry some weight in this community to express myself.

 

My concern that I have is that I see people chiming in and responding with comments that have nothing to do with the matter quoted (or not quoted, in the case of some people.)

 

Matthew brings up a great example, above. I never did see him mention that the F18A had GRAM. He tried to correct Rich, and then Rich went off with another thread that had nothing to do with what Matthew was saying. I was scratching my head as well at the response. I know these terms. I know what they mean in TI context, and I know what they mean in other contexts. No biggie.

 

People sometimes do make mistakes. Some people write stuff and misquote it. Fine. Correct it, and move on. But please, for the sake of our small community, don't make this a gik'tal. We're much too small a community to be nitpicking and making enemies with each over really trivial stuff. If you have any inkling that you're going to stir something up by replying to someone who's out to start something, just take your bat'leth and go home, please. Yeah, we're adults and can shrug it off, but come on... is it really necessary?

 

I really do like and respect all of you. Tursi's excellent hardware and software knowledge, Marc's hardware (SID Blaster) and excellent games, Rich's knowledge of GPL and all the odd stuff he knows about XB and RXB. Those are just some examples. I see all kind of new stuff that just blows my mind in these forums; Titanium, the smooth scrolling (and Marble Madness examples, just recently), Mr. Chin, you name it... you all rock!

This started with the thread of someone asking about GRAM on the F18 so it was not a random rant on my part about the use of GRAM and what it means.

What did happen is my response to explain what was going on but no one seemed to go back to the original thread that started it.

 

I would not even have said anything if not for that one post that started this.

[RXB]

Sorry Matthew!

 

GPU is Graphics Programming Unit (normally used in place of VDP Chip or Video Processor or Graphics Unit) and PL is normally short for Programing Language.

Both used for many years in publications other than the TI community.

Thus GPUPL would be Graphics Programming Unit Programming Language. Your project so you pick what you want. VRAM is a very good one by the way.

 

I suppose GPUPL could have been shortened to GPUL for Graphics Programing Unit Language.

Edited November 14, 2013 by RXB

[Tursi]

Seriously, I'd like to continue to discourage updates. I know you think it's a small thing, but it's a big thing to people who actually want to support the chip. Not every chip in the wild is going to be updated, so any part that gets changed either can't be supported (like the divide function for large numbers, since it now returns two different results in a certain case), or software needs to detect what version it's working with and deal with it (or just accept that it won't work on some people's systems.) Emulators need to consider supporting /all/ the versions, including undesired operation, which gets harder and harder as the "fixed" issues get lost to time. I have personal investment on both sides of that, myself.

 

In this case, you aren't fixing any show stoppers or even serious issues. It's just "nice to haves".

 

I can't stop you, of course, but just so you've heard one vote, anyway.

[+OLD CS1]

Seriously, I'd like to continue to discourage updates. I know you think it's a small thing, but it's a big thing to people who actually want to support the chip. Not every chip in the wild is going to be updated, so any part that gets changed either can't be supported (like the divide function for large numbers, since it now returns two different results in a certain case), or software needs to detect what version it's working with and deal with it (or just accept that it won't work on some people's systems.) Emulators need to consider supporting /all/ the versions, including undesired operation, which gets harder and harder as the "fixed" issues get lost to time. I have personal investment on both sides of that, myself.

 

In this case, you aren't fixing any show stoppers or even serious issues. It's just "nice to haves".

 

I can't stop you, of course, but just so you've heard one vote, anyway.

 

I place my vote against Tursi, only because I see how well Indivision updates work for the Amiga and that I believe bugs need to be fixed. Matt offers an update service, and with the self-update he is working on, I do not see it will be too difficult to maintain parity in the field.

 

As for emulators, so long as Matt communicates openly and well with developers, I do not see difficulty in maintaining parity at that level, either. This would depend upon 1) Matt not releasing updates for little nit-picky things and only major issues and 2) the emulator developer coming to initial parity at some point. I believe he has done well with #1 and I believe Tursi and Matt, as well as others, can easily^{(see below)} work to bring emulators to an up-to-snuff starting point, provided the emulator developer wants to support the F18A. So, #1 agrees with Tursi, in part. But, to be frank, I do not see the necessity to remain backward compatible and I feel that would do more harm than good in the long run.

 

(I say easily as I am not developing any software myself, and as a consumer I am quite certain that great software comes from unicorn farts. )

[RXB]

So true for Emulators to attempt to support all devices is much more work then conceived for by the original project.

[matthew180]

@Tursi: I don't believe that emulators should support all versions of a firmware, only the latest. I have to be allowed to make mistakes since I'm just as human as anyone else. Requiring F18A owners to update their boards to get total software support does not seem too unreasonable to me. Firmware (or driver) updates to get the latest software support is typical these days, as is requiring people to update the latest version of Classic99 to get the latest bug fixes and functionality.

 

The arguments I currently have for making at least one more update are:

 

1. The 80-column update will increase compatibility with existing software, and won't break anything that has been patched so far.

 

2. The counters and RNG units have never been used, and eliminating a pair (or all) of them will make emulation easier.

 

3. The DIV instruction has also never been used, so I don't think emulating the buggy version is necessary.

 

4. It is reasonable to assume that anyone involved enough to download and use newly developed F18A software will also be involved enough to use the software updater.

 

5. So far, aside from what Rasmus has done, new software development for the F18A is nonexistent.

 

6. Until the F18A gets some heavy use, I don't know that it is bug-free, and I must be allowed to fix future bugs.

 

7. Classic99 has not yet implemented the parts I would be changing. :-)

 

None of my fixes to date would cause any F18A software to stop working, and any fixes I make in the future would have the same goal of not affecting existing F18A software (other than to correct potential bugs).

[Tursi]

@Tursi: I don't believe that emulators should support all versions of a firmware, only the latest. I have to be allowed to make mistakes since I'm just as human as anyone else. Requiring F18A owners to update their boards to get total software support does not seem too unreasonable to me. Firmware (or driver) updates to get the latest software support is typical these days, as is requiring people to update the latest version of Classic99 to get the latest bug fixes and functionality.

Unfortunately, I do. Classic99 is a development platform. If someone releases a game for the F18A, and I claim to support it, and the game works fine for the author, they need to be able to test against older versions to see whether it's that sort of a bug. In the end, people won't come to you for those questions, they will come to me. "On Classic99 it works but it doesn't work on Joe Smith's ColEvilVision. Why?" "Well, Timmy, that's because Classic99 is a TI emulator..." (okay, bad example )

 

Suffice to say that if I claim to support a device, I want to support it correctly from a developer's point of view, not a game player's point of view. That means all the warts, problems, and important revisions. I have /always/ stated that Classic99 was not created for playing games, and that other emulators are a better choice for that. This is of course, my perogative, and you are not required to support it.

 

You are allowed to make mistakes. You have fixed several important bugs, and that's great - they needed to be fixed. But I don't see anything left that /needs/ to be changed. Adding more GPU RAM won't fix anything. Masking off that register in 80 column mode might fix compatibility with one or two programs that are out in the wild and not already patched -- but patching the program is a lot easier. Systems like the ColecoVision are not systems that are typically firmware updated -- just because it's the norm "today" doesn't mean it is applicable backwards.

 

The arguments I currently have for making at least one more update are:

1. The 80-column update will increase compatibility with existing software, and won't break anything that has been patched so far.

Do you have an estimate on how many pieces of software? I bet you a Coke I could count the unpatched software that would start to work on one hand, twice.

 

2. The counters and RNG units have never been used, and eliminating a pair (or all) of them will make emulation easier.

Except for my argument above. Makes it easier for you, perhaps, but not me.

 

3. The DIV instruction has also never been used, so I don't think emulating the buggy version is necessary.

We differ in opinion on what is necessary. I don't think patching the F18A ROM for the 80 column mode is necessary. That's why we are having this discussion - we each want to do what we feel is right for our own project. For me, that means emulating the buggy version. For you, that means fixing everything you come across. We conflict here.

 

4. It is reasonable to assume that anyone involved enough to download and use newly developed F18A software will also be involved enough to use the software updater.

In particular I am thinking of the console gamers. I fully intend (and have started) my next couple of ColecoVision games to include F18A enhancements. People are not going to want to take apart their game console all the time to update the video chip. I'm certainly tired of taking mine apart.

 

5. So far, aside from what Rasmus has done, new software development for the F18A is nonexistent.

Oh yeah, I've never done anything at all. Maybe two minutes invested.

 

6. Until the F18A gets some heavy use, I don't know that it is bug-free, and I must be allowed to fix future bugs.

You are /allowed/ to do what you want. I stated my preference, and my reasons for it. Bug fixes, IMO, are a reasonable and fair consideration, but I don't see any in the current list.

 

7. Classic99 has not yet implemented the parts I would be changing. :-)

Except for the 80 column code. And the GPU memory size.

 

These things all take time to do... in fact more time than your fixing the VHDL. You're just going to add a mask to VR2. I need to add configuration, debug, and then run test programs in both modes to make sure they both operate correctly.

 

The rapid list of updates has been one of the biggest /detractions/ to wanting to add more support to Classic99, honestly. I don't want to start it if it's not stable. I am not looking for things to do - I've got too much going on as it is. It's not a conscious thing, it has just been discouraging. I thought, as of 1.5, we finally were stable and I was starting to think more seriously about it (such as the new GPU hacks and starting the rest of the opcodes).

 

None of my fixes to date would cause any F18A software to stop working, and any fixes I make in the future would have the same goal of not affecting existing F18A software (other than to correct potential bugs).

Fair statement. And yes, right now the impact /is/ minimal. I am fond of speaking up /before/ things become a problem, rather than after. I know, it's a weird attitude in today's day and age, but I have to live with it.

 

You are free to do as you like, as I said in my first post. I was just putting up my vote. I never said "DON'T DO IT YOU BASTARRRRRRRDD!!", I just said I'd prefer no. And, now you know in detail why.

[matthew180]

Do you have an estimate on how many pieces of software? I bet you a Coke I could count the unpatched software that would start to work on one hand, twice.

I assumed hundreds of programs, since the only thing the 99/4A and Geneve have that used the 9938 is 80-column programs. There must be years of 80-column development out there just waiting!

 

In particular I am thinking of the console gamers. I fully intend (and have started) my next couple of ColecoVision games to include F18A enhancements. People are not going to want to take apart their game console all the time to update the video chip. I'm certainly tired of taking mine apart.

Haha, just leave it open like I do! :-) Well, hopefully I will get around to making the software update for a few more platforms, if there is enough software for the F18A to warrant the development (i.e. me spending the time to learn to code on a few 8-bit systems).

 

Oh yeah, I've never done anything at all. Maybe two minutes invested.

Haha, yeah, I forgot. You have done some F18A coding too. :-)

 

You are /allowed/ to do what you want. I stated my preference, and my reasons for it. Bug fixes, IMO, are a reasonable and fair consideration, but I don't see any in the current list.

Maybe. The 80-column issue with VR2 could be considered a bug since it *is* a 9938 enhancement and the F18A does not conform to ignoring the two LSbits as the 9938 does. Bug?

 

Except for the 80 column code. And the GPU memory size.

Didn't Classic99 have 80-column support before the F18A?

 

The rapid list of updates has been one of the biggest /detractions/ to wanting to add more support to Classic99, honestly. I don't want to start it if it's not stable. I am not looking for things to do - I've got too much going on as it is. It's not a conscious thing, it has just been discouraging. I thought, as of 1.5, we finally were stable and I was starting to think more seriously about it (such as the new GPU hacks and starting the rest of the opcodes).

Well, the rapid list is just me thinking out loud, and not something I would typically do. I supposed I was more-so looking for public reaction like "noooo don't remove the counters!" or something like that. If you are really going to crank up Classic99 F18A support and write games that use the F18A, then I'll leave it alone.

[+OLD CS1]

I see the point about consolers wanting updates. Short of a USB-updatable patching cartridge for the ColecoVision and program for the MSX, ignoring the other 9918A-based devices, it would require a tear-down and either ship to Matt or access to a TI.

[RobertLM78]

While my technical savviness is limited, I agree with Tursi: it seems a lot easier to update a program that might have an issue rather than flashing the F18A with an update. Just my 2 cents.

[Tursi]

I assumed hundreds of programs, since the only thing the 99/4A and Geneve have that used the 9938 is 80-column programs. There must be years of 80-column development out there just waiting!

You may have underestimated how many fingers I have on a hand!!

 

Haha, just leave it open like I do! :-) Well, hopefully I will get around to making the software update for a few more platforms, if there is enough software for the F18A to warrant the development (i.e. me spending the time to learn to code on a few 8-bit systems).

Code-wise it's probably easy.. I'd even be willing to help port the code to C for the ColecoVision (in theory, then portable to other machines). The downside is the only way to /get/ software into the ColecoVision is via cartridge. (I think a megacart ROM would support the size needed, at least, if it were a one-time thing).

 

 

Haha, yeah, I forgot. You have done some F18A coding too. :-)

Besides the tests and demos, there's the emulator itself. It may not have the pretty effects, but there are a lot of hours in there.

 

Maybe. The 80-column issue with VR2 could be considered a bug since it *is* a 9938 enhancement and the F18A does not conform to ignoring the two LSbits as the 9938 does. Bug?

I got in trouble elsethread for calling the original program setting reserved bits with odd patterns a bug. So I'm not allowed to weigh in on that, apparently. Nevertheless, I always saw the F18A 80-column mode as "compatible with" the 9938 mode, not "identical to". Can't the 9938 use tables in memory above 16k? Since it wouldn't be possible to match that, I didn't see it worth considering that an F18A flaw. Just my two bits though.

 

Didn't Classic99 have 80-column support before the F18A?

Support was added when TurboForth chose to support 80 columns, which I believe was because the F18A had it. I didn't do it in support of the 9938, anyway, else I would have needed the additional memory registers.

 

Well, the rapid list is just me thinking out loud, and not something I would typically do. I supposed I was more-so looking for public reaction like "noooo don't remove the counters!" or something like that. If you are really going to crank up Classic99 F18A support and write games that use the F18A, then I'll leave it alone.

I was thinking more along the lines of the firmware updates that you have done. I agree they fixed valid bugs, but they came quickly. If you want to do one more, it's not going to kill me. But I will offer friction at each step, just to avoid surprise.

[Willsy]

I'd like to see more GPU RAM rather than counters and RNGs. I can do the counters and RNGs myself, either on the 4A side or the GPU side

 

@Tursi: As a compromise, what if you hold off implementation of full GPU support for one more round, to allow Matthew to get the next update done, and, assuming no bugs arise, Matthew agrees to a "feature freeze"? :-)

[Tursi]

I'm just providing friction. I think it's better that way than to say five releases go by, then suddenly object to the sixth, and have a big "whoa.. what? why are you suddenly objecting?" I could go on and on with all my reasons, but I don't think anyone really cares. In a nutshell, my concerns are fragmentation of the market, and effort to support all the versions in the field (even if Matthew doesn't want to).

 

Nevertheless, the additional RAM he's talking about is a change to the FPGA, if I followed right, and that's a new device. I think it should be the F19A, then I'm not obligated to support it until the F18A support is done. You can do anything you like with the F19A, I'd have a year or two to think about supporting that.

 

Anyway, it's not so much a need to compromise, if he does a 1.6 or not will not affect my free time to work on Classic99. I'll get to it when I can either way.

[+OLD CS1]

I'd like to see more GPU RAM rather than counters and RNGs. I can do the counters and RNGs myself, either on the 4A side or the GPU side

 

Sure, instead of implementing RNGs and timers, a template could be provided for doing so using the GPU with loading code from the 4A side.

[matthew180]

Code-wise it's probably easy.. I'd even be willing to help port the code to C for the ColecoVision (in theory, then portable to other machines). The downside is the only way to /get/ software into the ColecoVision is via cartridge. (I think a megacart ROM would support the size needed, at least, if it were a one-time thing).

Writing it in C would make things easier, but I don't know how practical that will be. The GPU is going to do the update part, so at least that code would be common. The host system part will be responsible for getting the data into VRAM in some predefined chunk size.

 

I think a mega-cart would make the update much easier than a disk-based solution. I almost expect consoles to be easier than computer systems.

 

Besides the tests and demos, there's the emulator itself. It may not have the pretty effects, but there are a lot of hours in there.

Absolutely, and your work, and the work of others (MLC, TF, etc.), is greatly appreciated! I apologize for implying that Rasmus is the only one doing F18A stuff, that is certainly not the case. I never intend to exclude or under value people's contributions.

 

I got in trouble elsethread for calling the original program setting reserved bits with odd patterns a bug. So I'm not allowed to weigh in on that, apparently. Nevertheless, I always saw the F18A 80-column mode as "compatible with" the 9938 mode, not "identical to". Can't the 9938 use tables in memory above 16k? Since it wouldn't be possible to match that, I didn't see it worth considering that an F18A flaw. Just my two bits though.

The F18A 80-column compatibility problem is due to 9938 programmers not following the "standards" in the 9938 datasheet, my assumption that 9938 programmers did follow the datasheet, and my failure to realize that some 9938 code might set the two LSbits of R2 to something other than "11" in 80-column mode.

 

Yes, the 9938 can place the name table in memory higher than 16K, but on the 9938 in 80-column mode the two LSBits of R2 are simply not used in the name table placement, and therefore the 80-column name table placement is limited to 4K boundaries. I didn't like that limitation for the F18A, so I trapped the "11" condition of the two LSbits and forced them to "00". For any other combination ("00", "01", "10") I used the two LSbits as-is. That was my mistake.

 

Support was added when TurboForth chose to support 80 columns, which I believe was because the F18A had it. I didn't do it in support of the 9938, anyway, else I would have needed the additional memory registers.

Ok, I didn't know that. I thought you had implemented some basic 9938 support already in Classic99.

 

In a nutshell, my concerns are fragmentation of the market, and effort to support all the versions in the field (even if Matthew doesn't want to).

Your concerns weigh heavy due to respect, they are logical, and your contributions to the community are not small.

 

Nevertheless, the additional RAM he's talking about is a change to the FPGA, if I followed right, and that's a new device. I think it should be the F19A, then I'm not obligated to support it until the F18A support is done. You can do anything you like with the F19A, I'd have a year or two to think about supporting that.

The FPGA I use for the F18A, a Xilinx Spartan 3E, comes in many sizes (number of gates) and package layouts. Four of the sizes, 50K, 100K, 250K, and 500K Xilinx offers in a VQFP-100 package with an identical pin-out. That means if you use that pin-out you can literally drop-in any of those four sizes of FPGA without any board modifications. The F18A fits in the 250K gate device (which was my target), however I could put a 500K gate FPGA on the board (albeit at double the cost for the FPGA).

 

The 500K device has more block-RAM so I could make that available. The 250K device has approx 24K total (16K VRAM, 2K GPU-RAM, 6K video line buffers), and the 500K device has approx 40K, so I could offer an additional 16K of VRAM or GPU-RAM. However, that change would certainly mess up the existing memory map, and adding it to VRAM would require changing all the table-related VDP registers, the VRAM address register, etc. like the 9938 had to do.

 

I should have considered this when I did the layout of the original F18A, but alas I did not. I'm inclined to leave it alone though. As for taking out the counters and RNGs, that does *not* free up any block-RAM. I was simply considering taking them out because there seems to be zero interest in them and it would ease the design which is currently at 99% utilization.

[gregallenwarner]

I agree with Tursi, in that if the FPGA gets swapped out for a different one, you should go with a new product identifier. (Although, I would personally put in a vote for the F38A!) I see a lot of misunderstanding going on where people mistake the F18A as a 9938 replacement, so in my mind, an updated F18A that can address more than 16k VRAM (like the 9938 can do), seems like a step toward building a 9938 replacement. Just my non-authoritative opinion, but if the objective is to make the F18A more like the 9938, then F38A might be a nice name for that. I have no idea what Matthew has in mind though for the product, and personally, I think it's great as is! I'm sure whatever decisions he makes for the future of the product, it'll still be an excellent design.

[matthew180]

The F18A is probably done. Unless I can get Tursi to agree on a small modification related to the T80 VR2 issue.

 

As for a 9938 replacement, that has been brought up before but no one begged for it. (that is a joke.) Seriously though, these are my reasons for not doing a 9938. I'm willing to change my mind, but someone is going to have to convince me...

 

* I don't have any reason, i.e. I don't have anything with a 9938 in it. Well, that is not entirely true, I did recently get an MSX2. But I USED to not have anything with a 9938 in it.

 

* The 9938 already puts out RGB, albeit at 15KHz.

 

* I don't like how the 9938 was implemented. It is an ugly hack due to needing to stay compatible with the 9918A. Kind of like the whole x86 architecture. And all the video "modes" with different resolutions, interlacing, etc. just creates a nightmare to figure out and implement.

 

* I hate dealing with PCB-pins, and the 9938 has even more than the 9918A.

 

* What community would I be supporting?

 

* What would the end goals be? The F18A was simple: pin-compatible replacement for the 9918A that generates a "VGA" signal. But I don't know what the purpose of an FPGA-9938 would be?

 

If anyone wants to take me up on these, please start a new thread specifically for that discussion.

[Omega-TI]

 

I think it's great as is! I'm sure whatever decisions he makes for the future of the product, it'll still be an excellent design.

 

I'll put my two bits (opinion), for what it's worth...

 

It's nice to have the latest and greatest device out there, especially when it's being actively supported, like the F18A is now. In my opinion the F18A has become the de-facto standard for the remaining TI users in the active community. I'm not sure I would want to screw with success. Having the latest and greatest also makes one feel part of the community, and keeps one looking forward to new goodies and gives programmers something new and exciting to play with. If a new replacement device came out, I wonder how much more stuff would ever be developed or modified for the F18A? Now that it's getting attention and new stuff is currently being written and modified for it, it's on a roll, so I'd like to see the current F18A have at least a couple of years run before dropping it is even considered. Besides, if a new device is publicly slated to come out, who would want to buy a soon to be obsolete piece of hardware? I think sales of the F18A to TI Users would drop. I know I would be irritated just having bought one piece of hardware only to find it's obsolete and may not run all the new stuff.

 

Now myself, after having nothing but problems with my Nano-PEB, and all the frustration that has come with it, I can tell you from personal experience, I'm not the least bit interested in opening up my TI to perform continual updates, nor removing the unit to send it in for an update. I've had enough headaches with the Nano-PEB. The F18A works, it was easy to install and it's trouble-free, why mess with success? The more versions in the wild, the more chances for incompatibilities with future software, thus frustrated users.

 

I agree with you Greg, the F18A is great as is! Like you, I have also have no doubt that any new device made by Matthew would be an excellent design and well constructed, but unfortunately I would not buy one, I just recently purchased an F18A and can not justify the purchase.

[matthew180]

@Kevan: No worries, I'm not going to make another 9918A replacement. The F18A does that just fine IMO. I don't have the resources (time, money, interest) to make a 9918A replacement with more VRAM or whatever. A 9938 replacement would not compete with the F18A because it would be for an entirely different end use. I'm also sick of PCB-pins and anything I do next will be externally plug-in via an existing interface. Now, that does not exclude another video board that plugs in to the side bus. Dual-head 99/4A anyone? :-) I wonder if it would be hard to patch software to use different ports when reading/writing the VDP... ?

Edited November 15, 2013 by matthew180

[TheMole]

I don't have the resources (time, money, interest) to make a 9918A replacement with more VRAM or whatever.

 

Good .

 

 

 

I wonder if it would be hard to patch software to use different ports when reading/writing the VDP... ?

 

Only slightly related, but have you ever looked at how the EVPC2 and the REPL99x work together to avoid having to solder an extra wire for VDP INT support to the PEB?

http://home.arcor.de/system-ninety-nine-user-group/evpc/index_e.htm

http://home.arcor.de/system-ninety-nine-user-group/evpc/repl99x_e.pdf

Edited November 15, 2013 by TheMole

[slinkeey]

Having the latest and greatest also makes one feel part of the community.....

 

I would like to think that most people buy something because they want it and not because they want to feel part of something like sheeple.

Edited November 15, 2013 by slinkeey

[+OLD CS1]

 

I would like to think that most people buy something because they want it and not because they want to feel part of something like sheeple.

 

But we are not discussing that majority, but rather the minority like us who do it for fun, individual discovery, and to some degree camaraderie.

[Omega-TI]

 

I would like to think that most people buy something because they want it and not because they want to feel part of something like sheeple.

 

Are you trying to bait me, or start another flame war by using the term SHEEPLE in response to one of my comments?

Of course people buy things because they want them, to suggest otherwise is insulting. You have to admit, the F18A has created a lot of INVOLVEMENT from people, from programmers, to users and has generated a lot of message traffic... bringing people into the community, and thus feeling a part of the community, well at least until they post something and get jumped.

[slinkeey]

 

But we are not discussing that majority, but rather the minority like us who do it for fun, individual discovery, and to some degree camaraderie.

 

Good point. Common interests. I was thinking monkey see monkey do.. oops I kind of forget that we are talking about a little group of people here.

Edited November 15, 2013 by slinkeey

[gregallenwarner]

Good points, Matthew, that you brought up against doing a new video chip. I can't argue there.

 

When Kevin brought up the part about the F18A being actively supported, it struck a chord with me. It's good that the F18A is becoming the de facto standard as it is, because, like it or not, the 9938 is an old chip, and you can't get new ones. Eventually, the last 9938 will fail (albeit, probably not for quite some time!) and after which, there won't be any more. An active product with continuing support is better for longevity, and thus, seems a better route to go, for some people at least. I can definitely see more people gravitating toward the feature set of the F18A, while becoming less and less reliant on the 9938-specific features of the aging chip. We're already starting to see older 80-column software slowly getting patched to be F18A compatible, and more will naturally follow suit. And as Matthew pointed out, there are fewer devices out there currently using the 9938 than there are using the 9918A.

 

I dunno. If someone disagrees with me, please, ellaborate.

Edited November 15, 2013 by gregallenwarner