Bird's nest...

[JohnPCAE]

Apologies for the blurry focus. It's really hard to get a sharp picture just holding my camera. This should, however, show my progress. I can produce color text now, though there are still some noise issues to iron out. I'm using a new timing board design that's a lot simpler and I haven't yet looked at eliminating noise from it. I only just got it working.

 

The long-thin board that's closer to the camera is the timing stage that produces black-and-white output. The smaller board behind it is the color stage. Both of these boards are only testbed designs that allow me to fine-tune things, experiment with noise reduction, palettes, etc. A "production" version would also require a proper frame buffer, character ROM and RAM, and an input stage that interfaced with the Inty's bus. One step at a time, though.

 

The color stage incorporates a small 2k RAM chip that I use for storing the color palette. On startup, the Arduino programs it with the four timeslice values that need to be output for a given color, similar to how the inty's color chip works. With this new timing board, the palette isn't matching the Inty palette so another bit of experimenting will have to involve messing around with timeslice values. I might save that for a different color stage, though: I'm working on a design for the color stage that supports 8 bits of resolution for timeslice values instead of only 4.

 

As in earlier pics, the left half of the text looks noisy on my Dell monitor. That's because it doesn't like the noninterlaced format that the Inty outputs, and so it's getting confused. The right half is what it would normally look like on a TV.

Edited March 10, 2018 by JohnPCAE

[JohnPCAE]

Here is a better pic of the boards. The color stage is at the top and the timing and B/W stage is at the bottom. The Arduino programs the palette into the color stage once, sets the color to use (for the entire screen with this testbed setup), then ouptuts pixel data to the B/W stage. Every 2 seconds it changes the chosen color, eventually cycling through all 16 colors in the palette. This lets me evaluate not just how closely I can get to the Inty color palette but also lets me see how noise affects the output of different colors.

 

I had actually made some mistakes with this new B/W board such that it took me hours to get it working. I'd forgotten a couple of very short traces (between adjacent pins on 2 chips) which I jumpered. I also mislabeled the last 4 pins on the right edge (which is why PIX OUT is just visible in the corner -- it's really the 3rd from the bottom). The board supports various isolating capacitors sprinkled around it, so the next task will be to see what reduces noise and interference the best. And, I neglected to include a clock output from it that I could feed to the color stage. That is because I'd been thinking of the new color stage I'm working on, which doesn't need a clock input. It instead needs a pair of inputs, C0 and C1, which this board does output.

Edited March 10, 2018 by JohnPCAE

[JohnPCAE]

Going counterclockwise:

 

1. A/V tap in the Inty cartridge port. This gives me access to a handful of signals that I need to synchronize timing and pipe overlay video to it.

 

2. B/W pixel stage. This handles primary frame synchronization and contains the pixel FIFO.

 

3. Color output stage. This takes the pixel data and applies color to it. This is an early one that is only useful for applying a color to all text on the screen.

 

4. Memory manager/bus. This is where the Arduino connects. It contains three 16-bit memory buses (separate from the Inty bus). The Arduino uses it to program the palette SRAM, read external RAM (for the frame buffer and GRAM), write to frame buffer/GRAM (which you normally won't need but I need it for testing purposes), and write to the FIFO in the B/W stage. It's also special in that it allows the Arduino to either latch the starting address for its internal address-increment counter (actually it provides a latched address to an adder), or to let the Arduino specify an absolute read/write address. Thus, it allows support for scrolling and GRAM.

 

5. The white breadboard contains only a 2k SRAM chip. This is single-ported RAM that is only for testing. It will eventually be replaced with dual-port RAM.

 

 

Next steps (in no particular order)

 

1. Swap out the single-port RAM for dual-port RAM. I already have a chip for testing and made a carrier board.

 

2. Finish assembling my second-generation color stage. It supports 64 colors with 6-bit resolution for the four timeslice values (up from 4). It also allows the currently displayed color to be selected on the fly.

 

3. Slightly hack the existing B/W stage to allow for a second FIFO that will store color information. That will let me test per-character color with the new color stage.

 

4. Design a new B/W stage that also includes some color management. The simplest (and most expensive) way is to use two FIFO's, but I have a lot of potential ideas I first want to test (double-pumped single 8-bit FIFO, double-pumped pair of 8-bit FIFO's, quad-pumped FIFO(s), octal-pumped FIFO's, etc.). Basically, the more bits I can extract per 8 pixels, the more that is potentially possible. Cost, complexity, and what I can fit on a 100mm x 80mm board (roughly 4" x 3", the maximum that I can make with the free version of Eagle) will be the limiting factors, though.

 

5. I'm anticipating that a plain-vanilla Arduino Uno won't be fast enough to handle the load of all that I want to do. At some point I'll have to start testing with something faster. I picked up an Adafruit M0 feather that has a 48MHz ARM. It's a 3.3V device, so I also picked up some level shifter breakout boards. As it turns out, IDT is phasing out their 5V chips for 3.3V devices, so a migration to 3.3V is pretty much inevitable.

Edited May 20, 2018 by JohnPCAE

[JohnPCAE]

Mmm.... dual-port RAM

[+DZ-Jay]

I lost track... what are you trying to accomplish with these tests? Are you attempting to reproduce the Intellivision "on-a-chip"?

[JohnPCAE]

I'm trying to design an add-on that would let the Inty supply high-resolution text through its video overlay pin.

[+DZ-Jay]

I'm trying to design an add-on that would let the Inty supply high-resolution text through its video overlay pin.

Ah!

 

Are there any specific applications you already have in mind? Off the top of my head, I'm thinking a good BASIC package for the ECS with more than 20x12 characters.

 

-dZ.

[mr_me]

Plenty of game applications for a text overlay layer. That includes multidirectional scrolling with text information on the screen. What I wonder is if this has to be a hardware add-on peripheral or can it be inexpensive/small enough to include in cartridges. A Keyboard Component clone is another application.

[+DZ-Jay]

Plenty of game applications for a text overlay layer. That includes multidirectional scrolling with text information on the screen. What I wonder is if this has to be a hardware add-on peripheral or can it be inexpensive/small enough to include in cartridges. A Keyboard Component clone is another application.

 

I'll be honest, I wouldn't pay an extra surcharge just to see text overlaid on a scrolling screen. That's a nice-to-have, but barely the hook to purchase an add-on.

 

A Keyboard Component clone sounds more interesting as a game development environment (think ECS BASIC done right), at least to me. I don't think the practical applications are as obvious as you make it sound without a specific hook to drive the initial purchase. Especially when you consider that any new hardware will require programmers to dedicate their effort and time into adopting it.

 

Unless you're thinking that people will just buy it because it's there -- in which case, it'll mostly remain on a box on a shelf.

 

That's why I asked if he had any specific applications in mind or just playing with cool tech. I'm not knocking it, I think it's a great idea. I'm just curious to know the direction in which it is going. It's perfectly fine if the direction is just "cool tech to play with"; God knows we need more of that in this community.

 

-dZ.

Edited May 22, 2018 by DZ-Jay

[mr_me]

Yes, add-ons don't sell. This was a hard lesson learned by the pioneer of add-ons, Mattel Electronics in the early 1980s.

 

As with most inventions, practical applications often comes from others.

Edited May 22, 2018 by mr_me

[+DZ-Jay]

Yes, add-ons don't sell. This was a hard lesson learned by the pioneer of add-ons, Mattel Electronics in the early 1980s.

 

Putting aside that the Intellivoice didn't really sell all that well, it's "hook" was actually that the voice was integral to game-play. That sort of thing is harder to do than it seems.

 

In any case, I didn't mean to hijack this thread. I'm excited over this project and want to see where it goes.

 

I've considered making an actual usable version of BASIC on cartridge for the ECS with a good, modern development framework on ROM to drive sprites, graphics, and sound. As I dream of the possibilities, it dawns on me that we have a 20x12 character display area, hardly any space for real code to display -- especially for a verbose language like BASIC. JohnPCAE's add-on would serve to lift most of that limitation.

 

-dZ.

Edited May 22, 2018 by DZ-Jay

[carlsson]

The question is how this type of text overlay would be relate to Opcode's intelliXpander module, if it becomes a reality. I understand that the two are not doing the same thing, though both are video extensions that require some form of external hardware.

 

http://atariage.com/forums/topic/266909-intellixpander-module/page-14

[+nanochess]

Maybe it will not become commercial but I love what JohnPCAE is doing.

 

Keep up the good work

[JohnPCAE]

I have lots of ideas in my head, but I don't know how much I can implement within the restrictions I have. I've toyed with a few ideas:

- foreground-only color text mode (background is transparent)

- independent foreground/background color selection per character

- separate cursor support (this I think is a must)

- text blinking attribute (with programmable rate for the entire screen)

- colored-squares mode

- reprogramming a timeslice value(s) on-the-fly in lieu of displaying a character (using GRAM as the source for the timeslice values)

- four-color character mode

- pure graphics mode

- page flipping (should be easy)

- selectable row/column blanking (this should be easy)

 

It mostly depends on what I can do with respect to the FIFOs: for instance, how many times can I pull bits from the FIFO (which is 9 bits wide) for every 8 pixels? Each extra read requires latching the value so that they all become active simultaneously. I'd prefer to use just one FIFO instead of 2 due to their cost. The ones I'm experimenting with are the IDT 7205 and 7208, though a production version would likely have to use their 3.3v counterparts as the 5v ones are being phased out.

 

I have no intention of manufacturing anything: my intent is to create the reference design. A big reason why I'm sticking with through-hole construction as much as possible is so that anyone can build the components.

Edited May 23, 2018 by JohnPCAE

[+fdr4prez]

I'm trying to design an add-on that would let the Inty supply high-resolution text through its video overlay pin.

IntelliZork!!!

[+DZ-Jay]

I have lots of ideas in my head, but I don't know how much I can implement within the restrictions I have. I've toyed with a few ideas:

- foreground-only color text mode (background is transparent)

- independent foreground/background color selection per character

- separate cursor support (this I think is a must)

- text blinking attribute (with programmable rate for the entire screen)

- colored-squares mode

- reprogramming a timeslice value(s) on-the-fly in lieu of displaying a character (using GRAM as the source for the timeslice values)

- four-color character mode

- pure graphics mode

- page flipping (should be easy)

- selectable row/column blanking (this should be easy)

 

It mostly depends on what I can do with respect to the FIFOs: for instance, how many times can I pull bits from the FIFO (which is 9 bits wide) for every 8 pixels? Each extra read requires latching the value so that they all become active simultaneously. I'd prefer to use just one FIFO instead of 2 due to their cost. The ones I'm experimenting with are the IDT 7205 and 7208, though a production version would likely have to use their 3.3v counterparts as the 5v ones are being phased out.

 

I have no intention of manufacturing anything: my intent is to create the reference design. A big reason why I'm sticking with through-hole construction as much as possible is so that anyone can build the components.

 

Wow! Any of those would be a treat!

 

-dZ.

[+Lathe26]

IntelliTaxes 1982 (got to keep it retro)

[JohnPCAE]

Well, I just had a breakthrough. I've never been satisfied with the hue stability (rather, instability) in the output. It stems from not having a precise enough clock; I need the clock to be 4x MCLK and as close to exactly in phase as possible. I had hoped that restarting a crystal in sync with SR1 would do the trick, but the oscilloscope showed that it wasn't having the effect I wanted. So, I decided to take another look at synthesizing it directly from MCLK with a PLL. After several hours of fighting with it I finally got something that is stable. The result is that the hues I'm producing are now very stable. This has been a nagging issue from the start, but it's finally solved.

Edited May 24, 2018 by JohnPCAE

[JohnPCAE]

Okay, now my brain hurts.

 

One issue that has been nagging me has been the fact that I have to calculate phase-shifted timeslice values to get correct hues. By experimentation I found it to be somewhere in the range of a 210-215 degree shift. This value made no sense to me, so I decided to look at the NTSC standard. The Wikipedia page was no help, but after an hour of searching I ran across the actual standard (http://www.earlytelevision.org/pdf/ntsc_signal_specifications.pdf). It specifies that the color signal has to be 180 degrees out of phase from the burst signal, and then shifted by an additional 33 degrees -- for a total of 213 degrees.

 

Well, well.

 

However, the color chip in the Inty doesn't output phase-shifted values. So how was the phase shift getting in there? I looked at the Inty I and II schematics and the only thing that made sense was the 18k resistor and 200pF capacitor. I know that RC networks can cause a phase shift. Various "RC calculator" pages were of no help, so I fired up LTSpice and drew a simple simulator circuit.

 

Well, guess what? The waveform response shows a shift of 175-194 degrees. It varies depending on the color being output: a timeslice value of 1 gives a shift of 175 degrees, while a timeslice value of 15 gives a shift of 194 degrees. A simple solution could be to just add the RC network to my output stage and see what happens.

 

As an aside, this revelation makes creating accurate RGB representations of the colors a lot more complicated.

[+grips03]

Issue most of us have with the current RGB mod is that sync works on some devices XRGB2, Sony PVM, but OSSC can sync to it. So its hit more miss.

[JohnPCAE]

I put the RC network on my output pin and the hues are now dead-on. I still had to apply a straight 180 degree phase shift (which merely shifts all the timeslices by 2 entries). I'll have to think about why this is so, but at any rate now I have good hue values. All this experimenting has introduced lots of noise and resulted in a dimming of the output, so there is more experimentation in my near future...

[+DZ-Jay]

I put the RC network on my output pin and the hues are now dead-on. I still had to apply a straight 180 degree phase shift (which merely shifts all the timeslices by 2 entries). I'll have to think about why this is so, but at any rate now I have good hue values. All this experimenting has introduced lots of noise and resulted in a dimming of the output, so there is more experimentation in my near future...

 

Just out of curiosity (and having absolutely no knowledge on this topic), could that have anything at all to do with the issues encountered by Joe Z. in getting the proper palette of colours from the Master Component, as discussed in this thread?

 

-dZ.

[JohnPCAE]

Very likely. The extra R-C filter has a nonlinear response, which will complicate calculating correct RGB values. At some point I'll have to augment my Excel spreadsheet to try to take it into account.

 

In other news, some key chips arrived this week, and tomorrow I'll take a stab at double-pumping the FIFO in the display board. I've already updated the Arduino code to write 16 bits of data for every 8 dots, which allows for 8-bits of color information. A plain-vanilla Arduino appears to be able to keep up just fine, in fact there should still be a very healthy margin. Now I need to get a design working on the other end to perform two reads per 8 pixels instead of just one.

 

The initial design is built and mostly working, though I had to add a little hack with a flip-flop until the new chips arrived (the problem was using an asynchronous counter vs. a synchronous one). Neither Mouser nor Digi-Key carried them, so I had to order them directly from the TI store. So now I have to migrate to the new counter chips and then fix the timing for where it begins and ends scan lines Right now, it's cutting some columns off.

 

Another thought I'd like to plant in the backs of people's minds: what to do about RGB modded Intys. As they stand today, they won't ever see the overlay video since they intercept color information between the STIC and the color chip. I don't know if using spare pins on the cartridge port is viable or if some other measure is necessary. One additional wrinkle is that my output mirrors the output of the color chip: it's timeslice values, not RGB values. I'm sure a solution exists, but it will require a lot of thought not just from me but from the community.

 

Once I get this working, then I need to implement a GRAM scheme. I have the chips and my backplane board can support it; the real question is can a 16MHz Arduino keep up, or do I need to switch to ARM.

Edited June 22, 2018 by JohnPCAE

[+DZ-Jay]

Once I get this working, then I need to implement a GRAM scheme. I have the chips and my backplane board can support it; the real question is can a 16MHz Arduino keep up, or do I need to switch to ARM.

 

What do you mean "a GRAM scheme"? What would that be for?

[JohnPCAE]

Right now, it's pulling the dot patterns from the Arduino's flash memory -- they aren't writable on the fly. I mean using external RAM also as a place from which it can fetch dot patterns, that they Inty can also write to.