Ksarul

There is a mostly complete design for a 68881 coprocessor board for the PEB in existence. I happen to have the rights for that one, although I haven't done much with it yet. . .

Success! I now have another cartridge on the way for the Tiger Stripe CC-40.

You might also want to check here for the MM58274. One vendor on the list says they have nine of them and the other says they have one. Only the one with one lists a price ($26). Both are reliable vendors. Of course, this one says they have 26,000 of them, but they are a Chinese source that sometimes plays a bit fast with their products. When they're good, they're really good, but when they're bad, the product is abysmal. I've bought a few things from them in the past and the results were mixed, so I've tended to avoid them unless they were one of the primary remaining sources for the item.

Look in the documentation thread for the documents we're scanning from the CB Wilson collection. One of the recent posts includes all of the data needed to roll your own cables for the Sony and Panasonic VCRs and also for the Pioneer Laser Disk. The connectors are pretty standard. . .and as long as you follow their instructions for the wiring, you should be good. Original cables are seriously hard to find (I think I have a set of the Panasonic cables somewhere, but that's it).

I'm definitely a fan of the segmented arthropods. . .it is one of a small number of games that I always come back to.

Note, you may still need access to 32K for the program to run. Not all programs run directly from the FinalGROM. Some are lobbed into the 32K memory space and executed from there.

Look carefully and you will see a pattern in the pin differences: in the first two, it looks like the printer is reversing even and odd pins everywhere except at the beginning and at the end. If you look at Enri's list, it looks like he is using standard pin descriptions for teh bits, instead of the inverted nomenclature TI uses. Those changes to the first and third chart eliminate a lot of the differences. . .

There are just a few of the Tiger Stripe CC-40s out there, although cartridges for them are a bit more common. They don't have as much memory as a regular CC-40 either (2K), so the programming ability is more limited. I actually have one of the Tiger Stripe CC-40s (courtesy of @curtis a few years ago). They are interesting CC-40 variants.

One other general note: you can't use the SAMS cards in a Geneve, so there are no byte reversal issues--you only have to make sure it works in a 99/4A. On SAMS memory, my original post covers how it works--no matter how big (or small) the SAMS card is. The key to wrapping your mind around memory use is all in the bytes. The first byte written is IGNORED by SAMS cards up to 1M in size, as they don't use the four high-order bits being written to. Even though they are ignored, SOMETHING has to be written there, as it is used to populate the top four bits of the bank registers. The 74LS612 then takes the second byte and uses it to set up the 8 low-order register bits. Some of these bits may also be ignored by the SAMS card, specifically when the card is smaller than 1M. A 256K SAMS card ignores the two highest-order bits in the second byte, a 128K AEMS card ignores the three highest-order bits in the second byte, and the earliest, 64K AEMS boards (these do exist, as I have actually seen/held one BITD) would ignore the four highest-order bits of the second byte. This behavior changes a bit with 4M and larger SAMS cards, as that first, high-order byte now has meaning to the entire card (and not just the 74LS612). The last two bits of the first btye select between four different 1M zones (with further subdivision within each 1M zone being controlled by the 8 bits of the low-order byte) on a 4M card. On a 16M card, all four of the high-order bits of relevance to the 74LS612 are used to select between 16 different 1M zones, again, with the low-order byte controlling paging within the currently visible 1M zone. The bits in the high-order byte set the 1M zone, and the bits in the low-order byte select the pages within that zone. If you have been following that convention, I don't think you'll need to do a rewrite, Rich.

I believe @OLD CS1 has a project-in-process in this particular direction (Arkanoid) for the TI. . .we just have to prod him a bit to keep him working on it.

I really have to make that upgade on one of mine. . .I'm still running 2.50 on both of them.

Rich, this has nothing to do with a stupidly thought out design. It is a physical limitation of the bank switching chip. The original AMS and SAMS cards only used one byte of the 12-bit address space, making the four high-order bits invisible to programs and the users. In order to get the results they needed, they had to write the address byte twice to ensure that the address they wanted was populating the registers. The first write was shifted to the high-order register when the low order byte was written in--but it had no function as there were no outputs tied to the four high-order bits. This is a requirement of the 74LS612, as it MUST have both bytes written to it for it to work. The original design reflected this limitation of the hardware--it is definitely NOT a bug, it is a feature that programmers have to wrap their minds around to get the card to respond properly. Expansion to 4M uses two of those high-order bits, and expansion to 16M would use all four, so that high-order byte now actually DOES something when it is shifted into the registers. Tursi's variant actually uses one additional high-order bit that isn't available on the 74LS612 to expand the space to 32M. Rich, I have a thought: when writing to set the registers on a 1M SAMS, if you write zeroes in the first byte sent (the high-order byte), it should not try to switch you to bizarro pages that don't exist, as now there won't be spurious ones in the high-order byte. Same goes for the high-order byte in largr cards, always make sure unused bits are set to zero in the first byte sent to set the registers. Following this convention at all times should allow just a single SAMS management routine (set up a variable that identifies card size and mask all necessary initial bits to zero, which will also eliminate potential issues with cards smaller than 1M too). I am really glad you are working to integrate large SAMS support into RXB, as it opens a lot of possibilities for the user community. Thank you!

Sidecars are good if you want to somewhat limit your expansion possibilities. For long term flexibility, a Peripheral Expansion Box (PEB) is definitely the way to go. SAMS exists in both flavors (I make the PEB cards), as does TIPI.

SAMS doesn't clear memory on boot (I don't think any TI memory card does, for that matter). The cards hold memory as long as they have power--and no, there is usually no battery, although if using Zeropower RAMS in a 4M board, they just might have a good battery and hold data even when the power is off. As the 2M Zeropower chips are generally used, the batteries are usually dead, but there will always be random exceptions out there.

I sent a message about this to Kyle tonight, as he and I go way back (over 25 years now). I'll soon see how he responds. . .

That said on the parts availability, Kyle Crichton of Competition Computers is still active on eBay (mostly with Vectrex stuff). Contacting him may have results.

In answer to your question, the +5V available at the side port is insufficient to power anything that draws much more power than the speech synthesizer (IIRC, about 50mA). The Nano draws quite a bit more than that. The TI power supply is also broken into two parts--an external AC power supply that lowers the line voltage to 18VAC and the internal DC power supply that converts the 18V to the +5V, -5V, and +12V required by the console. There is very little wiggle room there--and the only way to get more power would be to use a beefier DC power supply--but note: you really need all three voltages. Meanwell makes one that can be adapted to the TI as an external supply, but it does require a bit of connector surgery to bring all of the DC inputs out to the back of the machine.

He's @Swim here on the forum.

I think Michael may have also sent a bunch of the daughter boards to the US to allow upgrades of existing cards. I think they may have gone to Richard Bell, as he's the US SNUG liaison, but they could also have gone to Don.

That's the only one I've ever seen that wasn't from TI (their 9900 System Design Handbook).

There are five custom chips on the board that are not commercially available. That said, the complete internal logic for four of those chips (POLLO, OSO, MOFETTA, and VAQUERO) exists in the form of detailed gate schematics. The fifth one (AMIGO) is a bit trickier. We have the equations for the portions of it that do combinatorial logic, we have the complete functional pinout, and we have the detailed description of the portion that manages the overall system memory. That data should allow a replacement to be coded, but it hasn't been attempted by anyone yet. @jens-eike also hit upon another potential issue--the somewhat mutant TMS9995 used by the 99/8. The rest of the board is either standard, commercially-available chips or TI GROMs (which can probably be emulated using ATMEGA1284s programmed as UberGROMs).

C'est magnifique! Merci beaucoup, Fabrice!

The Mechatronic Hexbus drive is a 2.8 Inch Quick Disk. They are harder to find than the original hexbus drives are (I have two of the Hexbus drives and a Quick Disk). There is also a recent effort to make an SD Hexbus drive that is nearly feature complete. I also have a lot of the TI Hexbus chips which would make it possible to make new drives (Fabrice Montupet recently did this). What other things do you have for the 99/8? I also have two of them, a 128K RAM card, an Armadillo Interface (round cable), a 512K RAM card, and an RS-232 card with a 99/8 DSR. I also have to finish scanning the TI design spec for the 3.5 Inch TI Hexbus drive.

. . .only sometimes? Looking at those bodge wires is enough to trigger permanent nightmares. It looks like it is trying to expand and eat the house. . .

Nice! Another excellent add to the Tutor library. . .