Jump to content


Bird's nest...

80 replies to this topic

#76 DZ-Jay OFFLINE  



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

Posted Sun Jun 24, 2018 5:34 AM

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.


Ah!  Nice. :)






  • Topic Starter
  • 505 posts

Posted Fri Oct 19, 2018 10:25 PM

Bit by bit, nearing completion. The large bottom board in the first picture is the final form of the video timing circuit It's hard to spot, but there's a DPDT switch at the top edge that selects between two and three FIFO reads per 8 horizontal pixels. This means that the available bits per 8 pixels can be either 18 or 27 bits (the FIFO is 9 bits wide). The reason for allowing selection is because a plain-vanilla 16MHz Arduino might not be able to feed three reads-worth of data that quickly, but at least the timing circuit can handle it.


The small board on top of the Inty II is obviously what goes into the cartridge port. I plan to use a very short IDC cable to connect it to everything else for two reasons: (1) to prevent mechanical stresses from adversely affecting any solder joints, and (2) to allow the mainboard to sit at a lower level as it does in the ECS (which lets me use a proper right-angle connector for the cartridge port).


The small cartridge interface board includes a circuit to generate the 4xMCLK signal that everything else needs. I squeezed it on the cart board so that space will be available elsewhere for all of the other functionality the project needs. In this prototype I socketed the chips just in case of any problems, but if all goes well what you see will be the final form of the board. The chips will have to be soldered into the board instead of socketed to fit in a cartridge shell. I commandeered pin 16 of the bus for forwarding the faster clock to the rest of the project, but it obviously won't go to the console itself or all the way through to the cartridge.


The mainboard design is 99% complete in Eagle. I'm waiting on a final power supply part that should arrive tomorrow (it's at the local USPS distribution site a couple of miles away from here). That board design is presently 6.4875" x 5.3375", but might change sightly depending on how the power-supply part works out. The basic idea is that several boards will stack directly onto the mainboard: the timing board, the RAM board (which will include interface logic to the Intellivision bus), and the microcontroller (Sparkfun RedStick in this case, since it's easy to program). The color board will then stack onto the timing board, and its outuput fill feed through the stack and back to the console.


Everything together is rather expensive, mainly due to the board costs plus the costs of the IDT chips (FIFO and RAM). That said, I'm only developing the reference design; I'd expect a real implementation to use programmable components like FPGA's or CPLD's as much as possible. Since OSH park gives me three of each board, I *might* build two additional development sets for game developers here, but no guarantees! At any rate, I'll be posting all of the designs and Arduino code so that anyone can build one. All soldering is through-hole construction, so that anyone with my minimal skill level in soldering can accomplish it :)


By the way, the free version of Eagle (version 7.7 in my case) will handle the large mainboard layout. This is because while it won't let you place components outside of a limited area, it doesn't place restrictions on plain traces, vias, lines, polygons, holes, text etc. (basically anything not a library component). It makes layout harder but not impossible.

Attached Thumbnails

  • Final_boards_1.png
  • Mainboard_proto.png

Edited by JohnPCAE, Fri Oct 19, 2018 10:41 PM.




  • Topic Starter
  • 505 posts

Posted Fri Nov 2, 2018 3:09 PM

It's starting to come together. Shown are the cart board with integrated clock multiplier, new mainboard, new timing board, and the microcontroller I plan to use (at first, at least). The top third of the mainboard will be covered by the RAM board, which I haven't yet designed, though I've laid out a design for a preliminary testing board. The timing board in the center will be covered by a third board that will manage applying color.


Next steps: update the microcontroller software for the new mainboard design, test the whole package with my minimalist color output board, then design the final color board and RAM board. Depending on what capabilities I want, I might have to go to a faster microcontroller, but the modular design should make it a simple matter of swapping one board for another.


I did get the label wrong on the new mainboard for the power controller (should be -05 instead of -03), and one of the holes for the barrel jack should have been a little wider for a better fit.

Attached Thumbnails

  • IMG_2110.png
  • IMG_2113.png

Edited by JohnPCAE, Fri Nov 2, 2018 3:15 PM.




  • Topic Starter
  • 505 posts

Posted Fri Nov 9, 2018 9:01 PM

*breathes a huge sigh of relief*


I was never 100% sure that the picture below would be possible with a plain-vanilla 16MHz Arduino. If anything, I was anticipating that it wouldn't have nearly enough horsepower for the task. What you see below incorporates two big features: programmable glyphs in external RAM and triple-pumping the output FIFO. In fact, my timing board has a DIP switch for changing between double-pumped and triple-pumped modes; that's how unsure I was whether an Arduino was fast enough to pull it off.


What does that mean? All of the character glyphs you see are being pulled from the microcontroller's flash ROM, with two exceptions (hint: look in one of the corners). The software on the microcontroller can now pull glyphs from external RAM as needed. This takes a bit longer to accomplish simply because it requires more processor instructions, and one of the stress tests that it passed was an entire screen filled with a programmable character. I was always concerned that a standard 328p coudn't do this in time before the end of the frame, but the extra overhead turned out to not be so much after all. The new mainboard has a LOT to do with this, as I expressly designed it to allow the Arduino to work most efficiently.


Triple-pumping the FIFO has to do with how much data is being written. There are 40 characters per row, with each character being 8 dots wide. So a purely black-and-white implementation like the KC means writing 40 bytes each scan line. This is writing three times as much: 8 bits for the dot patterns, and 16 more for attributes, for a total of 24 bits (actually it's writing 27 bits since the FIFO is 9 bits wide, but other limitations make using that 9th bit for each character HIGHLY impractical).


The impact? I have 16 bits of attribute data to play with for each character. That could mean 256 colors for foreground and background, or 128 + a blinking attribute + an underline attribute (think hardware cursor), or something else. 16 bits is a lot to play with.


Another possibility is to use that ninth bit as a mode bit: maybe it alters how the attribute bits are interpreted, on a whole-frame basis. For instance, maybe when that 9th bit is set, those first 8 bits of dot data are ALSO interpreted as color information: that gives 24 bits of data for every 8 dots. So there could be a pure 320x192x8 graphics mode, or if I interpret it as representing 4 "wide" dots, 160x192x16 pure graphics mode (with each color being programmable!)


There's no color in this image because my small color board for testing isn't connected. The next step is designing the real version of it.

Attached Thumbnails

  • Triple-pumped with GRAM.png

Edited by JohnPCAE, Fri Nov 9, 2018 9:02 PM.




  • Topic Starter
  • 505 posts

Posted Fri Dec 28, 2018 3:43 PM

First successful color test  :grin:


For this test, I've set the palette up with facscimiles of the Inty's 16-color palette. It's then cycling through all 16 colors for foreground and background while also cycling through the 128 characters I have in flash at the moment.


I don't think I can do anything about the checkerboarding -- that has a lot to do with how NTSC uses color subsampling as well as how well (or badly) my USB capture device can convert the composite signal.


This also isn't fully utilizing the hardware's capabilities. The text-mode daughtercard actually supports 64 colors per character (each for foreground and background), but the RAM chips I'm testing with don't have enough room to hold all that info. One thing on the list is designing a proper memory interface board instead of the nest of wires I have at present.


The text-mode card supports two text modes: one with blinking and one without. This actually requires some explanation. For every character, it accepts 8 bits of color information for the foreground color and 8 more for the background color. However, I can only store 64 colors in the palette RAM, because I need 2 bits of the 8-bit data bus to select the color timeslice -- leaving 6 bits to select the actual color. This leaves two more bits available for...something.


Mode 0 uses the two bits as "palette shift" bits. Every color that is output is internally represented by 4 timeslice values, exactly as the Inty's 8915 color chip handles it. You can use the two extra bits to select *which* timeslice is the first one. The result is that, for every color you pick, you actually have 4 available -- each one shifted in hue by 90 degrees. It's not 256 *independent* colors, but it does allow 256 simultaneous colors. The best way to describe it is you have 64 sets of four colors.


Mode 1 takes one of the palette shift bits and uses it for blinking instead. This limits the available colors to 128, where you can shift a color by 180 degrees in hue. There's a frame counter that will flip the visibility of anything set to blink every 32 frames. In this mode, the foreground and background bytes each have their own blink bit -- you can blink one or the other or both (or none).


The overall architecture supports 8 different screen modes. I have another daughtercard designed (but not built) that adds some pure-graphics modes (160x192x64 and 320x192x8, and a possible experimental third mode using 80x192 pixels)


I don't know if this setup can exactly replicate the entirety of the Inty's palette. The issue is brightness. I'm not sure if it's an internal limitation of how the Inty takes in overlay video or if I need to overdrive it with more than 5V. I'm still experimenting with finding the best way to drive the analog output. This test is using a resistor ladder the way the Inty does.

Attached Thumbnails

  • 16_col_FB.png




  • Topic Starter
  • 505 posts

Posted Sat Jan 12, 2019 6:30 PM

My RAM carrier boards came today :-D


The large chip is a 16k x 16-bit dual-port SRAM. Now my project has all the memory it needs. My pure-graphics-mode daughterboards also arrived today but I haven't assembled one yet. First, I have to deal with a bunch of noise that cropped up in the output signal. Nevertheless, the bird's nest is looking a lot less bird's-nesty now.

Attached Thumbnails

  • IMG_2128.JPG

Edited by JohnPCAE, Sat Jan 12, 2019 6:34 PM.

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users