gregallenwarner

As a Java developer by profession, this is a dream come true!

You got an option for impractical uses? I'd like to try and get mine to control stepper motors, just because I can!

Yeah, I'm using the MAX3000 line of CPLD's, and they're 5V tolerant, despite running on 3.3V. Like I mentioned earlier, 3.3V logic is supposed to be directly compatible with 5V TTL logic, but it has to be TTL, not CMOS. TTL detects a high logic level for anything above 2.5V, so 3.3V is fine, but CMOS expects something like 4V or thereabouts, in order to read as high, so 3.3V simply won't cut it. Now, I have in the past successfully driven the TI Speech Synth directly from the 3.3V outputs, but it wasn't reliable. It would work some days, and wouldn't work others. No amount of voodoo dances and incantations would resolve it, so I decided to switch the CPLD to open-collector outputs with 10K pullup resistors to 5 volts. This way, it translates the voltage levels into 5V. Takes more components, but it works reliably, and that's what's important. But sadly, it only works on this old chip, as all the new programmable logic devices aren't 5V tolerant. I don't really have the best eyesight, but the way I solder surface mount packages like this is with solder paste and a stencil, and then I lay the populated board on a hot plate that I have specifically for soldering, and I cook it on there to reflow the solder. A reflow oven would definitely be better, but I use an infrared thermometer and a stopwatch, manually adjusting the temperature knob in order to follow the proper heat curve. It works remarkably well, and I haven't had any botched PCB's yet! This method really beats using the iron!

Ok, so in order to be fully Geneve compliant, the only other thing I need to check for other than the full address bus is to ensure D0 through D2 are zero, correct? Thanks for the info. I didn't know that about external instructions. -Greg W

The purple CPLD dev board is my own creation. I hate buying dev boards, and would rather design my own, because it forces you to learn the actual implementation of the chip. When I began learning programmable logic a few years ago, I created that design, and I've been using it ever since. If one asks nicely, they might be able to get one from me! There's no USB, so you have to have your own USB Blaster to program it, but you can find cheap clones of it on eBay pretty easily. As for the male card edge connectors, I purchased them here: http://www.digikey.com/product-detail/en/EBC30MMBD/S7289-ND/1922778 and http://www.digikey.com/product-detail/en/EBC22MMBD/S7287-ND/1922776 I should mention, with those male edge connectors, while the horizontal pin pitch is 0.1 inch, the distance between the two rows of thru-hole pins is actually 0.15 inches, so it's a PAIN to use with perfboard. You have to individually bend each of the outer row of pins outward in order to space them 0.2 inches from the inner row, and even then, it's real difficult to space them so they perfectly line up with your perfboard holes, so there's usually a lot of wiggling and finagling before you finally get all the pins to go through the holes all at the same time. Took me about 10 minutes with each one.

I basically use Fred's DM2K as my operating system.

I've got a question regarding the CRU interface on the Geneve. When building cards that interface with the Geneve's main memory space, I know you've got to decode AMA through AMC, and optionally AMD and AME if you want to be fully compliant with the Geneve's memory map. However, can anyone tell me if there's a similar concern when building CRU hardware for use on the Geneve? If I'm building a device to communicate with the Geneve over the CRU interface, which address lines do I need to decode? I know for the TI-99, some cards never decode A0 through A2, as they are always assumed to be zero, since the TMS9900's CRU space never went above >1FFF. I know the TMS9995's CRU space is a lot bigger, so I should probably decode A0 through A7 for the full CRU address, right? What about AMA through AME? Or any of the other address lines? Should I be concerned with any of those? Thanks for the info. -Greg W

The one I sent to you didn't have the 74HCT245 buffer on the data lines. My (very first) prototype worked with this component omitted, but none of the first-run PCB's would. I figured it was worth the extra 50 cents to have that reliability of the buffer chip. Also, I went on ahead and reconfigured ALL of the CPLD's outputs as open-collector (with pullups to 5v) in order to translate the voltage levels from 3.3v logic that the CPLD runs on into 5v logic. Only some of the outputs on the first prototype were open-collector, and although 3.3v logic is supposed to be compatible with 5v TTL levels, I wasn't entirely convinced, since it wasn't working reliably. This is just a lot more thorough of a job, to ensure the logic levels swing all the way between 0 and 5 volts. Thanks for the positive feedback! I'll get you guys some new prototypes out in the mail soon to test for me. This also needs to be tested on a Geneve. I followed the guidelines for the Geneve's memory map, but it'll be of huge help to have it tested on a real Geneve. By the way, here's the link to the original thread, for reference: http://atariage.com/forums/topic/224521-simple-useful-project-for-your-p-box/ I should also mention that I've incorporated the Genmod decoding of AMD and AME into this design as well. There's a solder jumper in the new PCB design to enable decoding of those two additional lines. If you've done the Genmod on your Geneve, simply short this jumper with a solder blob, and it will now be compatible with the Genmod.

Soon, you will be able to relocate your speech synthesizers into your PEB's! I just wanted to start a new official thread for this project, since so many people have expressed interest so far. I can't thank you enough for your interest! It's inspired me to keep working hard on this. Had some difficulty working out some bugs in the design, but I believe I have a solid prototype now. I've got the PCB laid out for this latest design, so I'm going to be moving onto manufacturing very soon. Will keep you all updated. To see the thing in action, check out my video below: https://www.youtube.com/watch?v=9sZQHhh1AJA

If you're going to use a PLD, why not go for the equally priced, but much more capable MAX10, and program the entire system in there, CPU and all? With today's FPGA's a SoC solution is the best way to go for something like this. Plus, the new MAX10's have built-in user flash and SRAM, so the console ROM's and main memory could also be located on-chip. Fewer chips equals cost savings.

Alright, I'll just ignore GROM headers for now. I was asking because it'd be no trouble for me to emulate a GROM device with a CPLD, but if it's not even needed, I'll just stick with ROM headers. Thanks for the input. Wasn't sure what the consensus was with the v2.2 consoles, but sounds like folks will go out of their way to remove the offending ROM's from their TI's. Sounds good to me!

Where'd you buy the 99105, and where can I get one?

So, I was studying up on the TI's menu-building routine in the console ROM and noticed that the routine that builds the programs list from the >6000 cartridge ROM space isn't present in the v2.2 firmware. Thierry's site explains this as TI's attempt to lock out unauthorized vendors from manufacturing ROM-only carts, presumably so they could control the market with their proprietary GROM devices. My question is, how do you guys go about creating the header files for your cart ROM images? Do you bother with this edge-case scenario where the TI doesn't include them in the menu? What's considered best practice here? Should there be a small "bootloader" program in GROM who's only purpose is to supply the menu building routine with a program name, and then immediately jump to an assembly program in the >6000 space?

This looks good. Finally, we're getting closer to having a true, full IDE for the TI-99 platform!

I've been using one for as long as I've had my TI (that I acquired during adulthood, not the one from my childhood) with no ill effects. According to some datasheets on ribbon cables, the average signal propagation delay for IDC ribbon cable is somewhere on the order of 1.5 ns/ft, which, when you take the inverse, translates to 667 MHz. I don't think our little 3 MHz TI is going to have a problem with that. The only issue might be voltage drop due to wire resistance, which could cause unreliable detection of logic high.

Very interesting write-up on the TMS99100 series. I'd be very interested in more technical data on this series processor to see if a VHDL implementation for an FPGA would be possible, so we could experiment with this architecture.

Hope you mean me Greg and not the other Greg. If not, just ignore my ramblings. Gonna be working on the speech adapter some more tomorrow. Going to try some variations with the CPLD and the buffer chip, to see which gets best results. I'm hoping these findings won't require yet another board redesign. But if all works out, I should have the prototype completed.

I too have two half-height drives in a stock PEB with no power supply modification. My philosophy is this: Only one drive is ever active at a time. There's never a time when both drives are spinning their motors simultaneously. There is no need for the additional power capacity.

Are these commands supported by the E/A module? If so, could these potentially be used to control some hairbrained console modification ideas, or is that just asking for trouble?

Soon as I get a moment later today, I'll do the writeup on Ninerpedia for this.

Good info Fredrik. I've long scratched my head over this issue, and since given it up in favor of the F18A, and my previous post was as far as I had gotten with my debugging. Your info closes this case for me.

What I have discovered from experience is that those little cheap composite to VGA converters that PeBo mentioned: Some work and some do not. I had purchased one of those exact same converters, and it suffered from the vertical banding. Then I searched eBay for another one, and although it was an identical form factor, it apparently had different electronics inside and it worked perfectly with the TI. Unfortunately, I can't look up which one it was from eBay because it was such a long time ago, and I've since ceased using it in favor of the F18A. However, my theory is that it indeed has something to do with the "interlaced" vs "progressive" nature of the color signal. From what I can tell from my research, true NTSC color spec requires the color carrier be 180 degrees out of phase with itself on each successive scan line. (This allows for the color signal to effectively "cancel itself out" on older black-and-white TV's without color filters, a throwback to the introduction of color era.) However, based on the appearance of the image coming from the TI, it doesn't appear to be alternating the color phase every scan line. Each scan line appears to be in phase with every other scan line. There are many methods to decode NTSC color, however, one of them: the "comb filter" presents a problem here. The comb filter works by storing each scan line in a buffer, and "subtracting" the next line from it, in order to extract the color information. If the color phase doesn't switch between scan lines, the comb filter subtracts all the color information right out of the image, and the result gets interpreted as luminance (brightness) information, resulting in the vertical banding. So my recommendation is to try purchasing another composite to VGA converter, preferably of a different brand name. They're not all the same, and what you're hoping for is to get lucky with one that doesn't use a comb filter, but rather some simpler form of color decoder. Like I said, I was able to successfully locate one, and they're cheap enough to try a couple of brands. All the theory above is purely a thought-experiment of mine, based on lots and lots of reading and research. I don't own an oscilloscope to test my theories, but I believe my reasoning is logical. Hope that helps somebody out.

8 ports?!?! I imagine it probably had to have some buffer chips to avoid hitting the TTL fanout limit. Did it require an external power supply to power up all those carts? Or can the TI cart slot source that much power?

What's intriguing to me is the multi-base mod for the cart expander, the schematics for which can be found on Thierry's (newly restored) site. I'd love to build one of those someday, and perhaps build one entirely from scratch so I can have even more carts pluged in, and all accessible through the TI's menu! Has anyone built the multi-base cart expander?

Great news! Thanks for the update, mizapf!