intvnut

BTW, where it looks like Richard went astray is here: It turns out, the units ARE unambiguous, and the signs aren't missing. What he missed was that the B-Y and R-Y signals are positive-swing only, and so have a DC bias applied. This is why black, gray and white all have chroma outputs of 0.47. If you subtract 0.47 from the B-Y and R-Y signals, you get the actual signed B-Y and R-Y values. The Y', B-Y and R-Y values are all normalized, so that a white signal corresponds to 1.0 and a black signal corresponds to 0.0. All other magnitudes are scaled appropriately. That is, there is one scale factor applied to all the voltages. I think he misread this as "percent of the luma swing for this color." That's not it at all. What it means is white is "1.0 by definition", black is "0.0 by definition" and all other values are scaled to match this. (Kinda like how water boils at 100°C and freezes at 0°C by definition.) Since all of the transforms are defined on unit-scale signals, this is precisely what you need to be able to covert unit-scale Y'IQ to unit-scale RGB. Once you have unit-scale RGB, you can then multiply by 255 to get 8-bit RGB triples. That's what my spreadsheet did further up. Richard and I actually worked from the same source material. The VDP guide he mentioned is the exact same one that I worked from. He just missed that one insight that would have saved himself a lot of time.

I'm posting this here rather than keeping this in a private message because I'm not necessarily the expert in NTSC to RGB conversion. :-) I'm sure there are other experts that could chime in with their 2¢. To recap, you mentioned he did the following: That sounds like a somewhat reasonable starting point if nothing else. You could apply the same approach with the actual A', phase angle and luma values from the table I gave above to get Y'IQ values to convert. For the the 28/29, I think starting from the actual B-Y and R-Y values is a better idea than trying to compute them from the composite signal. One of the issues with the TMS9918A and decoding its color output is its extreme rainbow artifacting. This is due to the fact it doesn't alternate the colorburst phase from field to field, and so the pixel edges in the luma domain alias into the chroma band. Also, the composite signal specification itself (amplitude/phase) is just an approximation anyway. I suspect the actual composite encoder is outputting samples at a sample rate of 3x colorburst that approximate the luma and chroma spec shown. You can see something similar in the spec sheet for GI's "color processor": AY-3-8915. Note that that's an unrelated part. I'm just mentioning it because it illustrates the principle of operation I'm trying to describe. (As for why the 9918A has such bad rainbow artifacts: In proper NTSC, the colorburst phase flips 180° field-to-field, and I believe frame-to-frame. The luma components stay in-phase with each other and the chroma components flip sign. This makes it easier to separate the chroma from the luma more fully. That's where different chroma decoders bring you different chroma artifacts, such as vertical edge dot-crawl, horizontal edge dot-crawl and so on, when they take short cuts. The best decoders, such as "three-axis" decoders, correlate across fields and frames. But I digress.) If you're just trying to get the TMS9918A's nominal colors (ie. the color you'd see if you filled a large solid area with that color), I think you can do something similar to what Richard did: Project the vector described by A' and the phase angle from the table I posted above onto I/Q, and plug Y'IQ into a Y'IQ to RGB decoder matrix. Charle's Poynton's Color FAQ covers how to convert Y'PBPR into Y'UV and then Y'IQ. You should be able to invert the steps (by inverting the matrices) to work your way back to a Y'IQ to RGB matrix. Alternately, you could project onto U/V and skip a step.

Ben, You had also asked separately for my table for the TMS9118. I believe it should match what the TMS9918 does, but I don't have a TMS9918 sheet handy to compare. Here's a scan of my tables for the TMS9118/28/29:

Ben, The B-Y and R-Y are positive-going signals during active display, which is why there are no signs. You need to subtract 0.47 to get signals centered around 0. I whipped up a spreadsheet that actually seems to give pretty good results. It uses the YPbPr matrix from Charles Poynton's Color FAQ, and then adds a term for scaling the color saturation. It seems to do pretty much the right thing. The following image stripe shows the color set the spreadsheet generated. EDIT: I should add, the numbers are unitless because they are in terms of "full black-to-white swing." That is, they've all been normalized from 0 - 1 based on the full swing of the Y channel. (So if R-Y went above the Y channel, you'd see a number bigger than 1 there.)

I have enough parts boards here to pull cart slots from. Give me a shout and we can work something out. RJ They're just standard 64-pin, 0.1" card edge connectors right? I found some new ones at Digikey for a little over $6. I'm sure if you check around, you might be able to find them cheaper. At least in my case, I'm not sufficiently handy at desoldering for it be cost or time effective to desolder a 64-pin connector like that.

I wonder what it means for display artifacts. TMS9918As have horrible rainbow artifacts, which I suspect is why the Coleco uses the TMS9928A. I wonder if the TMS9118 eliminates those artifacts with its native composite out? To give you an idea, here's a screen shot of Parsec from the TI-99/4A with a TMS9918A: Here's the image the TMS9918A was programmed to display. Notice the vertical yellow lines in the image below come up in "rainbow colors" in the screen cap above, as well as color fringes on other vertical lines, such as in the score. (Note: Images stolen shamelessly from here, which seems to be a nifty page in its own right.) Do you notice any additional "rainbow" effects like these with the TMS9118 compared to a traditional Coleco?

Looks like the Atari pots are 1MΩ if that page is to be believed. To make them work on the Xbox360, you'd need to do more work than just "hook it up." Do you know how the Xbox360 controller senses the potentiometer? If it's looking for a voltage range with a linear transfer characteristic on a high-impedance D/A input, then it shouldn't be too hard to arrange for that. If it's doing something like the capacitive-discharge method common w/ old 8-bitters, then it's maybe a bit more complicated.

I honestly don't know. As you know, the system has a funky power supply setup with that darn momentary-contact switch. The diagnostic flow chart at pages 14/15 of that PDF look useful. It'll tell you if it's the supply board or something else pretty quickly, since the first steps are all voltage checks.

Very possibly. C64 and Inty pinouts are incompatible in such a way that putting a C64 cart into an Inty ought to short +5 and GND, frying the power supply. If you want to try to fix it, this might be handy.

Very possibly. C64 and Inty pinouts are incompatible in such a way that putting a C64 cart into an Inty ought to short +5 and GND, frying the power supply.

Why would you go to all that trouble? You could write a high-fidelity emulator that runs on one or more $5 80MIPS microcontrollers. A silicon reimplementation is just an emulator written in VHDL or Verilog as opposed to C or assembly.

Is it a 9918 or 9118? (Notice the different number of 1s and 9s. TMS9918 doesn't have bitmap mode, but TMS9118 does, just like a TMS9918A. I don't think they could have made it more confusing, do you?)

Is that a TMS9918A, or a TMS9118? I thought you needed to use a TMS9118 to get down to two VRAM chips.

Several people (including me) of MSX communities are interested in this too. Since it's newer than the available TMS9918 datasheet, it's very likely to contain additional and more accurate information, including details about the TMS9118. Belated thanks for scanning that programmer's guide btw. *doh* I never did get around to scanning this. Since I have this next week off from work, I'll try to get this done and out of the way. The databook is specific to the TMS9118/19/29, and so doesn't really contain much information for the TMS99x8 variants. I'm sure any register programming quirks that are documented in this book apply to both the TMS9918 and TMS9118 equally though.

The RISC vs. CISC distinction largely centers around the question of whether to have instructions of a fixed length that is somewhat longer than optimal, in the interest of facilitating pipelining, or whether to have variable-length instructions for purposes of reducing code size (and in some cases memory bandwidth). The 6502's fairly simple state machine does avoid the idle bus cycles that are common on many CISC architectures, but the fact that very few instructions are one machine word long precludes its being called a RISC. The Advanced RISC Machines' (aka. ARM) Thumb mode raises an eyebrow at you. :-) While fixed-length, highly regular encoded opcodes are a hallmark of many RISC machines, that doesn't preclude compression in the context of a RISC machine, if decompression can be pipelined efficiently. The architectural aspects that most often get cited as "RISC-like" in my experience are: Operations other than "move" are register to register. Registers are strongly distinct from memory, due to relative latency of access. That is, registers are cheap and "in the CPU." Memory is more expensive. (Combine this with the first bullet, and you arrive at the term "load/store architecture" for RISC, as distinguished from a "memory/register architecture" (808x), or a "memory/memory architecture.") Operations are kept simple, with a focus on pipelining. If you can't do something with single-cycle throughput, break it up into multiple instructions. Single-cycle throughput is different than single-cycle latency. Latency is ok--you can mange it with interlocks or exposed delay slots. Instruction decoding is also kept simple, to enable pipelining. Simple does not mean there can be no compression, or that all opcodes are the same width/format. It just means that the process is high throughput and easily pipelined. The focus on operations that could be pipelined limits the complexity of the instructions one could consider. For example, you can't pipeline "string compare," (e.g. 8086's REP CMPSB) because you don't know string lengths a priori. You can pipeline multiply, though, because its latency is bounded by the argument size, despite being complex. Also, disassociating memory reads and writes from computation instructions limits the "addressing" modes associated with computation to a couple modes: "register to register," and occasionally "immediate constant to register." All of your memory addressing modes are associated with your load and store instructions. Your computation instructions just focus on reading/writing registers and the occasional immediate constant. So, my main beef with 8051 and 6502 as "RISC" CPUs is that they don't embody "load/store" architecture, and they don't pipeline a darn thing. They're thoroughly memory-to-register machines. (And in the case of the 8051, rather often memory-to-memory. The 6502-with-T-bit crosses into the memory-to-memory territory also.) If the 6502 were to integrate its zero-page on-chip as a register file, you start to get close to what RISC was about, but it's still rather iffy. The indexed-indirect addressing mode--(zero-page, X)--is the real killer there. :-) (And I apologize. I called that mode (ZP, Y) when it's (ZP, X). Oops. It's been a few years since I've written 6502 code regularly. Where the ",X" and ",Y" go sometimes get flipped in my mental stack.) If you were to integrate the zero-page on chip, eliminate the ability to address it in memory through normal reads and writes, eliminate the indexed-indirect addressing mode, then I can start to feel the RISC vibe. Pipeline the machine, and then I think you'd capture what Hennessy and Patterson were going for when they built MIPS and SPARC. But, go in the direction malducci described with the 'T' bit and indirecting through 'X', and I think you end up in quirky microcontroller territory, not RISC machine territory.

The 8051's internal RAM is on a separate bus from the code store, so there is no speed penalty for instructions that use it. On the 6502, LDA zp is faster than LDA abs, but it's still slower than LDA #imm. By contrast, on the 8051, MOV A,direct is the same speed as MOV A,#imm. I was just referring to the style of programming, where you have 128 or 256 bytes of RAM that you can access directly, indirectly, or as registers, and you have lots of memory-to-memory operations on that space. The notion of "register" in that environment is really just opcode compression. Combine that with the bit test/set operations, and the parallels are striking. Make a version of this "6502 w/ T bit" with the zero page on the die and a dedicated bus, eliminating the penalty you highlight, and you're a stone's throw from 8051. I don't think anyone would accuse 8051 of embodying RISC principles. :-)

I started with the C version first (Rockwell variant with even more instructions than the standard C model), then later on worked with the original 02 version (NES coding). I'm not sure if that might have effected how I looked at the processor in comparison. The official dev/assembler reserved a some ZP registers(maybe 16) with Register names. Latter dev units reserved even more ZP slots with register names. They even called the registers with x86 names: AX,BX,CX,DX,SI,AL,AH, etc and then some with Rx names. I always wondered what if the assembler syntax was different. Instead of LDA <$00, you had MOV A,R0 or MOV A,[R1:XI] or MOV A,[R16]:YI, etc. If ZP registers would have still been treated like fastmode ram. Later 6502's had more ZP register interfacing opcodes - like the BBRx/BBSx bit test and branch on condition. Not really related but it's funny to note that NEC's later RISC v8xx line had a 'zero' register like the C02's (STZ <operand>) - though they labeled it R0. Anyway, about the T flag. When the T flag was set (SET), the A register is ignored/untouched and all arithmetic was done register to register - ZP registers to be exact. The value in the X register is the second operand (destination) of the two ZP registers. I would like to think that if the 65x had more evolving stages like the x86, we would have seen more implementation of ZP registers as processor registers in functionality. I have a real hard time calling those "6502." :-) That's more like 8051!

I don't see any relevance in that. It's a 'fast interrupt' system (if I may borrow the term from the 6809) - you push what you want for your routine. I could just image the overhead if all the regs were pushed on the stack (if it was large enough) like the 68k - lol. You know, iirc, there is a variant of the 65x with a 16bit stack (not the 65816). Hell - there are a lot a variants of that chip Fair enough. My point is that they aren't really managed like register resources in most machines. Could you imagine dedicating a handful of registers in any other CPU to a BASIC interpreter, even if it wasn't running all the time? Dedicating 4 CPU registers to the current text window boundaries? (That's what Apple ][ does!) The fact that the ZP was large and in RAM allowed it to be simultaneously more flexible than traditional registers by being used in completely different ways, and yet still have most of the advantages associated with proper registers. It was managed (or squandered, IMHO) more like RAM than a register file. The ZP is part vector table, part OS configuration, part scratch pad. Well - nobody pushed X or Y directly on the stack until the CMOS version came along. Yeah ok, that was rather lame It's not the same thing. Anyway, such a large set of registers, there's no need to push them onto the stack. If they were located on the die, I still wouldn't push them onto the stack. I'm thinking in terms of context switching, like in a multitasking operating system. If you want to swap between two tasks, you generally have to save off the context of one task and load the context of another. The zero page is part of that context, and so presumably if you're treating it like a register resource, you'd have to swap part of that along with it. One of the CPUs I work with nowadays (the TMS320C64x family) has 64 32-bit registers. That's the size of the entire 6502 zero page. And yes, we swap them all on a context switch. I do get your point about fast interrupts only saving what they need to. We do that too on the C64x devices. I should have been more specific. I haven't programmed the 6502 seriously since 1991, and I never really got into anything beyond the original 6502. I peeked at the 65816, but since I only had access to one Apple IIgs, I didn't bother learning something I couldn't make use of. So, while I know about some of the enhancements on the 65C02, I never even got accustomed to using those, even. I imagine someone must've made a variant that put the ZP on-die, and/or allowed you to change its base address. At one time, I was designing a 6502-based computer that would have done that in external hardware, remapping $0080 - $00FF to any 128-byte page in the system, just to get around the context-switch overhead associated with switching out a large portion of the ZP. Thus, you'd have the stable half of the ZP from $00 - $7F, and the switchable half from $80 - $FF. I was also going to relocate the stack, too. I guess what you're saying is that later 6502 variants did something like this for you.

If you want to see a CPU with a really weird setup, look at the RCA 1802 (RCA Studio II, Voyager space probes). I also find Harvard Architecture hard to mentally visualize. Harvard Architecture isn't all that complex. It just means that you have separate program and data buses. If you look inside any reasonably modern CPU, they have a Harvard architecture at least as far as their L1 caches go. The level 1 program and level 1 data caches are separate, with the program fetch pipeline separate from the data access pipeline. Now, once you get beyond the level 1 controllers, things typically unify onto a shared bus. This is the so-called Modified Harvard Architecture. The RCA 1802 is definitely a weird beast. I have a coworker that programmed them once upon a time. He mentioned building up call/return on top of the "any register could be the program counter" methodology. IIRC, it went something like this: Use one register as your "primary PC", and then two others point to your "call" and "return" subroutines. To make a call, you'd switch your PC register to the "call" function. That function would read the address to jump to and save off the primary PC register on a stack. It'd then set the primary PC register to point to the called function. And then the tricky bit: The call function would branch to one instruction ahead of its entry point that switches the PC register back to the primary PC. The result is that the "call PC" register is left pointing at the entry point, and execution resumes at the called function. The return path worked similarly, except it popped the new PC from the stack. Pretty clever if you ask me, although I'd rather just have normal call/return instructions.

It seems a bit weird to have more registers than you can fit on the stack. (Zero Page, A, X, Y, P and PC take up 262 bytes, but the stack is only 256 bytes large...) While small pools of zero page locations make up for the lack of a large internal register file, and the 6502's addressing modes use the ZP much like other processors use registers (the (ZP, Y) mode notwithstanding), the fact of the matter is that the zero page as a whole didn't get used exactly like a register file. Nobody pushes the zero page on the stack in response to an interrupt, for instance. I do agree that the faster cycle time of zero page addressing gives it some "register-like" qualities, but don't confuse it with CPUs like the TMS9900 family, where R0 - R15 were in RAM, but they really were treated much more like registers than the 6502's zero page, including how calling conventions treat them and so on.

Actually, all of zero page are technically 6502 registers. They were not on chip because it was cheaper to use external RAM. Hmmm.... I'm not sure I buy that. Most CPUs don't have the equivalent of "($xx, Y)" addressing mode, where you select which CPU register to indirect through based on the value of another register. Especially not RISC CPUs. ARM certainly doesn't seem to have that mode.

Adding a reset button is so easy, though, if you have a soldering iron. I believe enough contact is exposed that you could even manage to add one without removing the shielding. All in all, it's a simple thing. Why chuck otherwise good systems when they are a fundamentally limited resource?

I don't know if you missed it, but his console is missing its reset button and doesn't self-reset reliably.

The AY-3-8915 Color Processor doesn't run very fast--NTSC colorburst * 2 as I recall. You might even be able to do this with something as simple as an EPROM feeding a resistor ladder. The biggest complication is figuring out what values to put on the chroma and luma channels.

Why do you need to switch all the pins? It seems like just masking the chip selects should be enough for most purposes (C_OE, C_CS) as long as the carts are just plain carts, and not something fancy like a 32X. (I'm not sure if you'd need to do more than just C_OE and C_CS. I'm not really familiar with the Genesis' specific bus.) Then all you need to do is wire everything up as a bus, with just those lines going through some additional logic. e.g. a handful of 74LS32s and a 74LS138 to provide the "selected cartridge" signal that you OR with. (The reason you'd use OR is that the select lines are active-low.) Or, you could put it all on a single CPLD, even. Then you just need some logic to provide the 3 bit code that says which cart was selected. Alternately, use a PIC to provide handle the input and provide the select lines going out, and use 74LS32s to do the actual masking.