ClausB

Here's a truth table for the luma multiplexer output. As I said, we divide the Phi2 cycle into 8 70 ns states to drive the mux and select data bits as luma outputs: Mode 0: black (all outputs 0), LEM disabled Mode 1: all 16 gray levels, 160 pixels State 0 1 2 3 4 5 6 7 Lum3 D7 D7 D7 D7 D3 D3 D3 D3 Lum2 D6 D6 D6 D6 D2 D2 D2 D2 Lum1 D5 D5 D5 D5 D1 D1 D1 D1 Lum0 D4 D4 D4 D4 D0 D0 D0 D0 Mode 2: 4 levels (0, 5, A, F), 320 pixels State 0 1 2 3 4 5 6 7 Lum3 D7 D7 D5 D5 D3 D3 D1 D1 Lum2 D6 D6 D4 D4 D2 D2 D0 D0 Lum1 D7 D7 D5 D5 D3 D3 D1 D1 Lum0 D6 D6 D4 D4 D2 D2 D0 D0 Mode 3: 2 levels (0, F), 640 pixels State 0 1 2 3 4 5 6 7 Lum3 D7 D6 D5 D4 D3 D2 D1 D0 Lum2 D7 D6 D5 D4 D3 D2 D1 D0 Lum1 D7 D6 D5 D4 D3 D2 D1 D0 Lum0 D7 D6 D5 D4 D3 D2 D1 D0

Right. I was thinking we should read the luma from the second register right away for one cycle and then, on the next (non-DMA) cycle, transfer the first register to the second and then read it out. That way we're only multiplexing 8 bits every cycle instead of 16 bits every two cycles. Also, by reading out the second register first, we eliminate ~0.5 color-clock delay between luma and GTIA which I measured on the prototype (see old thread). I was thinking yesterday that we could also eliminate the full 8 color-clock (4 cycle) delay by chaining 4 more 8-bit registers and clocking the luma data through them every cycle. That would make the luma output line up with the GTIA output so the programmer would not have to offset the luma plotting. Also the character modes (above) would work better. It takes 32 more flip-flops, but you said you had some 64 FF CPLDs, right?

Wait, you said before it works with just the 256K DRAMs, so why would the PIA, ANTIC, or RAM be bad? I'm not sure exactly how ICD modified my 800XL upgrade for the 1200XL. Can you photograph both sides of the RAMBO PCB and post them here? Or better yet, does anyone have a schematic of the RAMBO PCB?

Wait a minute! Why shouldn't single-line character modes work? As long as the character set data are stored in the SRAM and the character codes are stored elsewhere, it should work. You would still get 40 or 20 characters across the screen but each character would be 16 bits wide and have the same hi-res luma options as the graphics modes. One complication however is the 8 color-clock delay between luma video and GTIA video. In graphics modes that is easily corrected by offsetting the plotting locations, but in character modes it gets more restrictive.

Very interesting idea! A few details in your example need correcting: Page $BE is outside the range we've selected, but $9E would work. ANTIC mode 2 would not be useful. The design only works with single-line modes which use DMA on every line. But the clever idea of using ANTIC to enable and disable the luma is worth considering.

It's been bouncing around in my head for a year, so it's pretty clear to me: As far as the SRAM goes, the sequence is laid out in the timing diagrams I posted at the top of this thread. At the rising edge of Phi2, 8 bits of SRAM data get clocked into the first data register. 140 ns later, 8 bits from another bank go into the second register. (That's one reason why a 140 ns delay line on Phi2 would be ideal.) As for the luma output, we must divide each 560 ns bus cycle into 8, 4, or 2 equal parts and select 1, 2, or 4 bits at a time per pixel using a variable width, variable period multiplexer. (A 70 ns delay helps generate the counter to address the mux).

Here are my original instructions for the 800XL: http://www.atariage.com/forums/topic/122470-ram-upgrade-applications/page__view__findpost__p__1481893 Here's a RAMBO manual: http://www.atariage.com/forums/topic/103323-rambo-xl-install-instructions/page__view__findpost__p__1252838

Not sure what you mean. How will you sync it to Phi2?

If you want to troubleshoot a bit, you can undo the mod but leave the 256K DRAM chips in place. If it works as a 64K machine then the RAMs are good and you can suspect the PCB or the installation.

You might be right. I'm old-school so I'm trying to design hardware, not software-on-a-chip. That's fine for large, complex designs like VBXE, but I don't think LEM needs it. I'll try to keep an open mind, though. "I can change, if I have to." - Red Green

I doubt there are enough spare gates in our CPLD to chain up to 140 ns and 70 ns delays. Maybe we should use the larger chip you recommended and devote 90% of it to the clock and 10% to the LEM.

Does that assume there is some high frequency clock in the FPGA to count out 70 ns? Nothing like that here. We have 1.8 MHz available and we're trying to make 7.2 MHz synchronized.

Certainly the XORs will be in the CPLD. What about the delays? I researched a bit on the Web and saw some things about the Xilinx Digital Clock Manager core and about Digital Locked Loops, but I could not find enough details to see if such a thing would fit into our smallish CPLD. Do you have details to share?

This is the email quote I got yesterday: MOQ is 10 pieces 3D7323Z-70 $8.68 each 1 week to ship MDU3C-70 $11.55 each 4-6 weeks This is the part: http://www.datadelay.com/datasheets/3d7323.pdf The delay tolerance is 2%. The ideal delays are 69.8 ns for NTSC and 70.5 ns for PAL. They differ by less than the tolerance.

Is it really fried? What are the symptoms? Some RAM test programs out there do not work correctly with the RAMBO/Buchholz upgrades.

A very simple clock doubler is merely a delay line and an XOR gate. You delay the input clock by 1/4 cycle and XOR both signals to get twice the frequency and 50% duty. Put two of those in series and you also get the 4x clock we need. So the first doubler needs 140 ns delay and the second needs 70 ns. I have found a triple 70 ns delay line for $9 from DDD. A bit pricey but we likely won't be mass producing!

It occurred to me that we don't need an 8x clock, just 4x. Here's why: Our highest resolution mode sends out 8 pixels per Phi2 cycle. Instead of clocking them out of a shift register 8 times per cycle, we can multiplex them out with 8 states per cycle. We can get 8 states by decoding 3 bits - the 1x, 2x, and 4x clocks. So we just need two clock doublers. This is exactly how GTIA does its hi-res mode (ANTIC mode F). Those pixels come out at 7.2 MHz but GTIA only has a 3.6 MHz clock. It uses half a cycle to display one pixel and the other half to display the next pixel.

FRENCH GUARD: Well, I'll ask him, but I don't think he'll be very keen. Uh, he's already got one, you see? ARTHUR: What? GALAHAD: He says they've already got one! ARTHUR: Are you sure he's got one? FRENCH GUARD: Oh, yes, it's very nice-a. (I told him we already got one.) GET ON WITH IT! Oh, sorry, yes, I've already got one. Its contacts are plated with, well, copper oxide.

Interesting idea. So the enhanced luma values would be a signed 4-bit number. If you want 16 gray levels you would set the Atari lumas to 8 and the enhanced lumas to -8 through +7. One problem I see is that the 16-color GTIA mode lets you set the lumas for the 15 hues but not the gray - you always get black. Crossing that mode with signed enhanced lumas gets you 248 colors, not 256. White and lighter grays would be missing. The D/A I had in mind is a simple resistor ladder like the one in the Atari.

What is the frequency of the cart connector's Phi2 signal on PAL machines? If we use a PLL or some other clock multiplier circuit to multiply Phi2's frequency by 8, then we'll have a good luma clock. We don't care about the color subcarrier frequency since this is a luma-only circuit, right? According to the 800XL schematic, the PAL system clock crystal is 3.547 MHz (3.580 on NTSC). So the frequency of the cart connector's Phi2 signal is 1.77 MHz (1.79 on NTSC). If we use a PLL or some other clock multiplier circuit to multiply Phi2's frequency by 8, then we'll have a good luma clock of 14.19 MHz (14.32 on NTSC).

What is the frequency of the cart connector's Phi2 signal on PAL machines? If we use a PLL or some other clock multiplier circuit to multiply Phi2's frequency by 8, then we'll have a good luma clock. We don't care about the color subcarrier frequency since this is a luma-only circuit, right?

IMO the clock multiplier is the biggest challenge here. Maybe we should look for a dedicated PLL chip instead of trying to do it in the CPLD. Once we have solid 14.3 MHz (synced to the cart's 1.8 MHz) we can divide it down in the CPLD to get states for reading the SRAM and clocking out the luma.

I don't follow. Do you mean with active analog circuits like op-amps?

I think we discussed that in the old thread. IIRC the XL MMU does not assert the cart select lines during refresh. It might be an issue on the 400/800, though. I'll look at it. Yes, the cart connector has two separate 8K select lines, -S4 and -S5. If you ignore -S5 and respond to -S4, you get $8000-$9FFF.

Perfect! Less crowded. I agree with you both. SRAM timing is not very critical but video clocking is. And the same clock will be used for both.