Jump to content

Photo

Bird's nest...


78 replies to this topic

#51 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 475 posts

Posted Sat Mar 10, 2018 4:37 AM

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.

Attached Thumbnails

  • Video_overlay_4_from_board.png
  • Video_overlay_5_from_board.png

Edited by JohnPCAE, Sat Mar 10, 2018 4:39 AM.


#52 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 475 posts

Posted Sat Mar 10, 2018 4:50 AM

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.

Attached Thumbnails

  • Video_overlay_6_from_board.png

Edited by JohnPCAE, Sat Mar 10, 2018 4:58 AM.


#53 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 475 posts

Posted Sun May 20, 2018 1:05 AM

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.

Attached Thumbnails

  • IMG_2098.JPG

Edited by JohnPCAE, Sun May 20, 2018 1:16 AM.


#54 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 475 posts

Posted Sun May 20, 2018 6:59 PM

Mmm.... dual-port RAM 8)

Attached Thumbnails

  • IMG_2099.JPG


#55 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,491 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Mon May 21, 2018 3:18 AM

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



#56 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 475 posts

Posted Mon May 21, 2018 7:04 AM

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



#57 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,491 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Tue May 22, 2018 3:20 AM

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

Ah! :cool:

 

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. :thumbsup:

 

    -dZ.



#58 mr_me OFFLINE  

mr_me

    River Patroller

  • 3,525 posts
  • Location:Ontario

Posted Tue May 22, 2018 4:52 AM

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.

#59 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,491 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Tue May 22, 2018 4:55 AM

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 by DZ-Jay, Tue May 22, 2018 5:05 AM.


#60 mr_me OFFLINE  

mr_me

    River Patroller

  • 3,525 posts
  • Location:Ontario

Posted Tue May 22, 2018 5:04 AM

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 by mr_me, Tue May 22, 2018 5:10 AM.


#61 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,491 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Tue May 22, 2018 5:12 AM

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 by DZ-Jay, Tue May 22, 2018 5:13 AM.


#62 carlsson OFFLINE  

carlsson

    Metagalactic Mule

  • 7,860 posts
  • Location:Västerås, Sweden

Posted Tue May 22, 2018 6:12 AM

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/...-module/page-14



#63 nanochess ONLINE  

nanochess

    Processorus Polyglotus

  • 5,632 posts
  • Coding something good
  • Location:Mexico City

Posted Tue May 22, 2018 10:29 AM

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

Keep up the good work :)

#64 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 475 posts

Posted Tue May 22, 2018 7:19 PM

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 by JohnPCAE, Tue May 22, 2018 7:26 PM.


#65 fdr4prez OFFLINE  

fdr4prez

    Stargunner

  • 1,779 posts

Posted Tue May 22, 2018 11:28 PM

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


IntelliZork!!!



#66 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,491 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Wed May 23, 2018 3:12 AM

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.



#67 Lathe26 OFFLINE  

Lathe26

    River Patroller

  • 3,705 posts

Posted Wed May 23, 2018 11:50 AM

IntelliTaxes 1982 (got to keep it retro)

#68 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 475 posts

Posted Wed May 23, 2018 10:01 PM

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 by JohnPCAE, Wed May 23, 2018 10:02 PM.


#69 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 475 posts

Posted Sat May 26, 2018 8:03 AM

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.earlytele...cifications.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.



#70 grips03 OFFLINE  

grips03

    River Patroller

  • 3,697 posts
  • Location:New England

Posted Sat May 26, 2018 9:36 AM

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.



#71 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 475 posts

Posted Sat May 26, 2018 4:04 PM

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...



#72 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,491 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Mon May 28, 2018 5:04 AM

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.



#73 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 475 posts

Posted Fri Jun 22, 2018 5:15 PM

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 by JohnPCAE, Fri Jun 22, 2018 5:16 PM.


#74 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,491 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Sat Jun 23, 2018 4:12 AM

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?



#75 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 475 posts

Posted Sat Jun 23, 2018 1:43 PM

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.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users