gregallenwarner

Oh, so the A instruction is using 2's complement notation? I understand now. The E/A manual doesn't say anything about it being in 2's complement. Thanks for clearing that up for me.

For guidance in this matter, I'd suggest you consider the Macintosh cloning phenomenon of days past: http://en.wikipedia.org/wiki/Macintosh_clone While even today it's still a gray area, and no one can really draw the legal boundary lines for sure, it was generally considered legal to build a hardware clone of a machine from reverse engineering the specifications. What was more clearly deliniated by the law were the ROMS. Manufacturers of Mac clones, if they wished to remain legal, had to physically pop the ROM chips out of an existing official Mac and transfer them to their clone. Simply copying the software contained in the ROM was a direct violation of copyright law. Now, it's true that today, you can download a TI-99/4a emulator that runs out of the box. I myself have downloaded it and ran it, and it ran perfectly fine right from the get-go, and I didn't even have to supply it with a ROM file. What this means is that the emulator contained its own copy of the TI ROM. Now, TI hasn't said anything to me about this, and as far as I know, the author of the emulator isn't in trouble either. Who knows? Perhaps he negotiated a licensing agreement with TI for the use of their ROM software. Or perhaps TI doens't care about such an old copyright. I don't know. The point is, it's been an ongoing legal debate since the late 80's, so you need to use your own judgement on the matter.

I'm confused a little about the meaning of the carry and overflow status bits after performing an A (add) instruction in TI-99 assembler. According to the E/A manual, "When there is a carry of bit zero, the carry status bit is set. When there is an overflow, the overflow status bit is set." Aside from the part about the carry bit being ambiguous grammar, I can't figure out under what conditions the overflow bit should be set. I tried the example given in the manual, adding >8 to >3124, and as the manual stated, I got the carry bit and the overflow bit reset. All as expected, no problems here. But then I tried to add >7777 to >7777. As far as I know, this should result in no overflow. >7777 plus >7777 equals >EEEE. No digit carries over to the next, and the addition doesn't overflow beyond the 16-bit space. However, when I add these two values, it results in the overflow bit being set. Furthermore, if I add >9999 to >7777, now, I get the carry bit set, which is as expected, yet I get the overflow bit reset. I cannot understand the logic guiding the setting/resetting of the overflow bit. Am I completely missing something here? Thanks.

I use this plastic CD box: http://www.amazon.com/Innovera-39502-Storage-Holds-Disks/dp/B001HA0KZ2/ It works a treat. Floppies fit perfectly standing up with sleeves on, no problems. Most useful purchase for my TI so far.

Amazing! Almost looks like Minecraft for the TI!

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.

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.

Does this mean that the F18A is in-system updateable? (Assuming you have some large disk system like you said.) Will this work over HDX? That's the only large storage system I have. (Although I bought my F18A's from you pretty recently, so I don't think they'll need updating at this time.) Anyway, yes, like Ksarul said, I too love my F18A's! Easy, no-hassle installation, superb video quality, and nice feature set. I'm just now getting into learning FPGA programming myself, so it's fascinating to see what a fully developed FPGA product is capable of out in the wild! It's an excellent product, Matthew!

Wow. I just had to jump in here and say, this is hands down, the best programming work I've ever seen on the TI. Excellent work guys! By the way, I'm a HUGE fan of Titanium. I play if often!

This is my first post here, but I thought I'd interject... I don't seem to have any problem switching contexts in my brain when I'm reading TI's (poorly chosen) terminology vs. when I'm working with conventional standards. For example, when I'm looking at anything TI-related and I read "A15", I automatically think, "least significant bit". And when I'm looking at anything else, when I read "A0", I automatically think "least significant bit". It's automatic--I don't have to consciously switch gears. I guess that's why it never bothered me that TI chose to be different with all their standards. But I agree, it would have behooved them to adhere to industry standards.