gregallenwarner

Looks good! Unfortunately, I don't have any of those handy prototyping boards, so all of my prototypes are hanging out of my PEB with crazy wires everywhere. It's really a mess.

Already beat you to it! :-) I just added 3 mounting holes. Kind of a tight squeeze on one of the corners, so I couldn't fit a hole there. I'll play around with the layout some more and see if there's a better way to arrange things so I can fit another mounting hole on there.

Very good so far. Rescanning the thread, I've now got this list of interested parties. Let me know if the number by your name is incorrect. And of course, if anyone else hasn't voiced their interest yet, and are wanting one, please let me know. I'll leave it open for a couple more days before I place the order. And by all means, if there's continuing interest after this run, I'll do some more, so don't worry if you miss it. Gary from OPA 1 --- Ω --- 1 OLD CS1 2 Iwantgames:) 2 Ksarul 2 coolio 1 RasmusM 1 Astharot 1 Fritz442 2 ti99userclub 3 Thanks for the interest! I'm glad something I made is of use to somebody!

Will do. That's usually the last step I take before sending it off to the board house. Thanks. There's something to be said for going newer and smaller, but I still love my big ol' PEB. You are correct. The Flex Cable Interface doesn't pass through the SBE (Speech Block Enable) line, and so you must replicate the selection circuitry that exists in the console to generate that line. I've done it in a CPLD, but the resources at the very beginning of this thread show how it's done with discrete logic.

I've always used R13 as the stack pointer, since I never use BLWP for my own routines, that means R13-R15 are freed up for other uses. Saves R10 for another general purpose register.

Since you guys are so interested in this adapter, I figured I'd post an updated screenshot of the board. I've been tweaking it, fixing errors and optimizing the trace layout. I managed to get better thermal management for the voltage regulators by increasing their thermal planes, reduce unnecessary vias, shorten power traces, and generally make everything more tidy. I also noticed a crucial error in the 44-pin edge connector. When I flipped the component around to position it on the top, I guess I inadvertently mirrored it as well, so the pads were on the opposite side of the board from where they should be. (1 and 2 were flipped, 3 & 4, etc.) So I corrected that. I've attached new renderings of the top and bottom sides separately, in case you're interested in seeing the progress. I can easily spend days just optimizing traces. I never feel they're quite right until I've tweaked them into beautiful, optimal paths. If I'm not careful, I might continue optimizing indefinitely! :-) (Don't worry, I think I may be close to perfection for this one!)

I'd recommend a complete board instead of a kit, unless you're set up to do reflow soldering. Once you've got the setup, surface mount soldering is much faster and easier than doing things by hand. I'm actually using the hot plate reflow method, rather than an oven. I spend a great deal of time researching it before I went ahead with this method, but basically, I have a hot plate that I dedicate solely to soldering (no cooking on this plate! Or else, Mmmmm, lead poisoning!) I use an IR thermometer aimed at the board for constant temperature monitoring. Right now, I use a stopwatch and manually turn the hot plate on and off (Manual PWM!) to manually follow the appropriate heat curve, but eventually I want to automate this with a microcontroller. But aside from that, the method works surprisingly well. Couldn't be easier. (Well, admitedly, an automated oven WOULD be easier! But it's easy enough. I would say, anyone could do it.)

If you can cover the cost of shipping, I'll ship to Denmark. Though I wouldn't be able to tell you off hand what the cost would be exactly, as I've never calculated it before. I've never actually sold a project of mine yet. Everything I've designed, I've only kept to myself for my own uses. So I don't know what's a reasonable markup for something like this. That's why I just wanted to be as transparent as possible with my BOM so you know exactly what the cost is to me. What is the recommended profit margin that you guys normally charge for your boards? Assembly wouldn't take too long, since it's all surface mount, so I can just reflow it in one step. Also, I feel like my best strategy moving forward would be to start with 3 prototypes using OSHPark. I'd keep one for myself, and send out the other 2 to a couple of people here for testing. Once those two people report back their results, and pending any further tweaks that need to be made to the board, then I can go ahead with a larger production run, perhaps using a more economical board house for cheaper PCB's. Does that sound acceptable to everybody? EDIT: About the kits, if you guys are serious about wanting to do the assembly yourself, I'd be happy to kit one out for you, but be aware, I do most of my designs using surface mount components, and this board, in efforts to make it as small as possible, has a pretty dense component population, so it would be next to impossible to assemble by hand with an iron. I'm set up to do reflow soldering, so I'm happy to assemble these for you, as it only takes about 15 to 20 minutes to do a full board, once I get going. I've been tweaking the design a little, nudging components around, to make things fit a little nicer on there.

Ok, I've calculated my BOM for the speech synth adapter card: MAX3000A CPLD x1 @ $2.93 $2.93 Diodes x6 @ $0.093 $0.558 Resistors x9 @ $0.016 $0.114 Ceramic Caps x7 @ $0.018 $0.126 Tantalum Caps x6 @ $0.30 $1.80 LM317 x2 @ $0.639 $1.278 LM337 x1 @ $1.36 $1.36 PCB (OSHPark) x1 @ $9.63 $9.63 --------------------------------------- Total (before shipping) $17.826 So call it $17.83. There will probably be a small amount I'll have to add to cover the cost of shipping of the components once I place the order, but, depending on how many people commit to one, that shouldn't add more than a dollar to the final cost. Then just tack on the cost of shipping the assembled board to you using your shipping method of choice. Those are the numbers we're looking at. So far, we've got Ω with 1, OLD CS1 with 2, and Iwantgames:) with 1. If anyone else is interested, say the word. I'll wait for a little while to let people respond before I begin this build.

Unfortunately, I can't make the card the correct length, as I'm working in Eagle and thus am under a maximum size restriction of about 3 inches by 4 inches. Also, trimming the board size down makes it cheaper. You could probably add some material to it or add a backing of some sort that would reach the slots for stability. I'll think of some ideas. Edit: About the price, the board itself is gonna be $9.63 each to get 3 from OSHPark. I'll have to add up a BOM on Mouser later tonight to figure out how much components will add to that. I will update later.

Well, after some grueling trace routing, I've completed the PCB layout for the speech-synth-to-PEB-bus adapter card. Overall dimensions: 3.3 inches by 1.75 inches. Eagle CAD render attached. Also, AMA, AMB, and AMC are routed, but I will need to know what the expected values of these lines will be before I can reprogram the chip. As a quick head count, how many people do you reckon will want one?

Ha ha! Thanks! I don't know about clean. I abhor wires all over the place, but, they're unavoidable. The piece of stripboard sticking out of the speech synth will be my prototype card, just as soon as I migrate the breakout PCB over to it.

Ok, I'll give Sitopway a look. I just got home and took a few photos of my setup. Here's the speech synth hooked up to a little breakout PCB that I designed for breadboarding. Let me emphasize: this thing is TINY! That one chip alone does the entire speech synth interfacing logic. There's actually quite a lot of room left in that chip; it's hardly used at all. Most of the silicon is sitting there being wasted. Tremendous amount of logic capable there, in a little $3 chip. It's mind blowing. Tested under XB (CALL SAY) and Parsec.

I wasn't planning on releasing mine, but considering there's some interest and the only thing lacking is whipping up a quick PCB layout, I'll go ahead and complete it and release it. Keep in mind, it is only a speech synth adapter. No other components. So it's not a viable replacement for a CorComp Triple Tech, or anything else. That being said, if there's still an interest out there for people to move their speech synths into the PEB, I'll go ahead and manufacture a few. I've got no idea where the best place would be to mass produce the boards. All I've ever done is have a few prototypes made with OSHPark. So if I go ahead with production, I'll likely only be able to offer 2 prototypes to the first bidders. I'm just not sure there are enough people out there wanting a synth adapter to warrant a huge run.

I don't wanna encroach on anyone's territory here. If anyone's got an active project going on for a speech synth adapter, I don't wanna steal your thunder. I just mentioned mine since I have a working prototype, and all that's lacking is the PCB layout. I'll post some photos tonight and see if there's any interest.

Sure! I'll post photos tonight. It does not currently, but there's no reason I couldn't add those in. Let me know what those signals are supposed to be decoded as, and which pins are they on the PEB bus? I need my memory refreshed.

Jumping in late here, but I have a one-chip implementation of the Speech to PEB Bus adapter that I made for my own use. Uses a single 44-pin TQFP, (aside from the requisite voltage regulators), so it could be made pretty small. Haven't designed a PCB for it yet, though. I'd be willing to finish this real quick if there's interest in it.

I've heard of the RAG Linker/Assembler, but I've never used them. I'll take a look. Thanks.

The problem I see with porting the entire libc over to the TI is the limited space. Eventually, you're going to have to start using SAMS bank switching for program code, and as it's already been stated earlier, that's trickier, as you need a sort of trampoline routine just to get in and out of routines that lie in an unmapped bank. So far, my efforts have been limited to implementing only a few certain functions from the libc code in TMS9900 Assembly, as the need arose. It wasn't intended to provide a libc implementation to a C compiler, though, that would be a nice thing to have. As mizapf already stated, the 64K address space is the real killjoy here. Still, at least for my immediate purposes, I think I've learned enough about the SAMS to make limited use of it in my own Assembly programs. It's certainly far from ideal, but I guess if I were trying to do ideal programming, I wouldn't be doing it on a 30+ year old architecture!

I already have a calling convention/call stack of sorts written for my own personal uses, though I'm not sure how compatible it is with the current C compiler for the TMS9900. I haven't even attempted to use a C compiler with the TI yet, so I'm not sure what the binaries it generates even look like, or how to ensure my assembly routines would be compatible with it. If C programming on the TI is a common enough thing, please let me know, so I can investigate it now, rather than try and shoe-horn in that compatibility later! Also, I happen to know that there exists at least two different C compilers for the TI--C99 and a TMS9900 extension for GNU GCC. Correct me if I'm wrong about those two. In any case, what are people currently using the most? Do either of those compilers already have SAMS support built in? I'd be very interested in writing new assembly routines to expand the standard libraries for either of those compilers, if the demand were great enough.

This is getting way deeper than I ever imagined from the beginning! So let me see what we've got so far. Are we still saying that XOP is slower than BLWP? If that's the case, I'd rather go with BLWP, since passing arguments to a BLWP routine isn't inherently more difficult than passing arguments to an XOP routine. Different, but not harder. Speed is a big concern of mine. Basically, here's what I'm attempting to do: I want to implement a Heap memory structure. I've read the C stdlib source code and found out how malloc() and free() work, when in the context of a single contiguous block of memory. Of course, malloc() and free() are also running in a virtual memory space which is provided to it by the operating system, which we don't have on the TI. But working with hard coded addresses, I believe I could implement a Heap structure in the TI using standard memory. Now I want to consider using the SAMS as well. malloc() returns an address pointing to the beginning of the allocated chunk of memory, immediately following the length prefix, so in the SAMS case, I believe I can replace this return value with an address/bank pair. I will need to write a fetch routine to operate on this address/bank pair, so that the application software can be agnostic about where in memory its data lies. The memory management routine will take care of the mapping/banking for it. Of course, what this means is, I'll have a maximum allocation size of 4K when requesting a block from malloc(), since the application software won't be able to tell when it's reached the end of a page, if the memory management function is doing all the management for it. I'll have to think on this some more. I'm sort of a computer science geek, so I like data structures and structured programming and things like this, so I like the notion of having a managed Heap of memory that I can allocate and deallocate at will, avoiding memory leaks that way. Just in case you guys wanted to know what I'm learning all this for!

This makes perfect sense to me! I have been bemoaning the TI's lack of a privileged mode and system calls, but now that I understand how XOP works, it looks like it could serve my purposes perfectly! I think I'm going to put the code that handles bank switching in an XOP routine, so effectively the XOP instruction will serve as an "extended fetch", reaching into the SAMS to fetch the desired data. Banking will be handled automatically by the XOP implementation routine. Thanks again, everybody. I'm learning quite a lot.

Looks vaguely like the Japanese game Go. The objective of that game is to enclose territory with your color stones. So you could count up the number of white squares that are completely boxed in by a closed circuit of a solid color, and award that color those points. You'd have to define a set halting point though, to decide when further attacks are no longer permitted. In Go, the game ends when both players pass in succession, however, it's kind of a human-intuition thing to judge when further plays are no longer advantageous for you. The trick is modelling that scenario such that it can be evaluated algorithmically.

Hmm, looks like I need to learn about this XOP thing. That could simplify program writing. How common is it really to find a console that doesn't support XOP 1?

Thanks for the routines, Willsy! I'm definitely learning a lot from this. Namely, to decide on one 4k page to be designated the sole bank switcher. I was trying to wrap my mind around writing a memory manager that would keep track of many banking pages all over the TI's memory space. Unfortunately, I don't have RXB, and I don't have a GRAM device either, so I'd have to build a GROM emulator if I were to try and download RXB and give it a try. However, I'm very comfortable in ASM, so as long as I'm following the proper techniques, I feel I shouldn't have any trouble. RasmusM, I have a few games ideas, but this isn't directly related to them. I probably won't attempt writing any games for quite some time. Thanks again to everyone who's posted some suggestions. They're all starting to paint a better picture in my head of how things should be done in the TI.