Jump to content
IGNORED

Bird's nest...


Recommended Posts

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

 

-dZ.

Link to comment
Share on other sites

  • 3 months later...

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.

post-7945-0-61738100-1540009188_thumb.png

post-7945-0-32337100-1540009230_thumb.png

Edited by JohnPCAE
  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

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.

post-7945-0-12476000-1541192878_thumb.png

post-7945-0-76898400-1541192890_thumb.png

Edited by JohnPCAE
  • Like 4
Link to comment
Share on other sites

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

post-7945-0-77435500-1541818886_thumb.png

Edited by JohnPCAE
  • Like 6
Link to comment
Share on other sites

  • 1 month later...

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.

post-7945-0-40208700-1546033192_thumb.png

  • Like 3
Link to comment
Share on other sites

  • 3 weeks later...

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.

post-7945-0-50641700-1547339440_thumb.jpg

Edited by JohnPCAE
  • Like 6
Link to comment
Share on other sites

  • 5 months later...

It took a lot of changes to power and ground distribution, but I finally have stable color output! The previous screenshot was a very rare stable frame. Most of the time it was all over the place.

 

The next step is brightness. I need to make the output much brighter. After that it's on to the graphics-mode daughtercard, memory interface to the Master Component, and finalizing capabilities.

 

Birds_nest_stable_output.thumb.png.4ceb3dfd09f1a98ebecc3134cf4ac83b.png

Edited by JohnPCAE
  • Like 2
Link to comment
Share on other sites

  • 1 month later...

These are the results of tweaking DAC output values:

 

Intellivision I:

Birds_nest_stable_output_7.thumb.png.05835a109c69c0760f6966a198e11b6e.png

Intellivision II:

Birds_nest_stable_output_8_inty_2.thumb.png.39e2351f88f984bd7aea2200323aab58.png

The major reason why I can't achieve really bright colors like yellow on an Inty I is because of the 3k R24 resistor on the Inty motherboard, and why the Inty II is so much brighter. It means that games will have to let users set which palette they want based on which console they have. An Inty II can achieve the dimmer look of the Inty 1 in software but not vice versa. The circuit I'm using tries to maximize the brightness on an Inty I, which results in blown-out colors on an Inty II with the same palette settings. However, I'm providing eight bits of granularity for each color timeslice as opposed to just 4 from the 8915 chip, so there is a lot of flexibility for dimming colors.

 

I don't have an Inty I with the System Changer mod, but from what I see of the schematic after the change it should look identical to the output from an Inty II.

Edited by JohnPCAE
Link to comment
Share on other sites

  • 5 weeks later...

No breadboards!

 

This includes text and graphics mode support. The small cart board needed a little bit of rework to stabilize my PLL clock generator, which I'll put in its next rev. The only hardware piece left is to design the real RAM interface board that lets the Inty control it. It would replace the narrow board in the foreground that has the 7026J RAM chip on it. That will make the hardware feature-complete and then it's on to finalizing the microcontroller code.

 

The FINAL final step (and I'm not sure I want to do this or leave it to someone else) is to put all this into an FPGA to bring the cost down. By my calculations a total of 31 5V I/O pins would be required, with 8 output, 7 input, and 16 bidirectional. The internals would run at exactly MCLKx4, synchronized with MCLK via PLL.

Birds_Nest_With_Graphics_Card.png

  • Like 2
Link to comment
Share on other sites

Here are a couple of thoughts I have, but I think I need some feedback on them. I'm looking at enabling the device by writing a magic value to Inty address $007F (assuming that address doesn't conflict with anything else). It would be divided up like this:

 

fbs3   fbs2   fbs1   fbs0   bs1   bs0   magic

 

The magic field is 10 bits wide. Writing a specific value to it would enable access to the frame buffer, which would always be at $D000. The frame buffer is 16k words in size, and up to 8k of it would be visible at a time. Fields bs0 and bs1 would determine how much of the buffer is visible: 1k, 2k, 4k, or 8k. Fields fbs0-fbs3 would determine the starting origin in the frame buffer in 1k chunks (so from 0k to 15k, wrapping around at 16k).

 

Certain magic areas in the frame buffer would configure the display: screen mode, column/row blanking, column/row offset, glyph offset, and whatever else I can think of. I'm guessing that 16 locations should be enough.

 

Reading a zero/nonzero value from $007F would tell you if the device was active. I'm not sure which should indicate which is which: I need to know what an Inty would normally read from that location first before I can design it in.

 

I'm also considering adding address $007E as a sort of general-purpose read/write user port, which would go to a 16-bit expansion bus at the back. The idea is then you could easily add, for instance PS/2 keyboard or mouse connectivity, or whatever else strikes your fancy. This is just tentative though.

 

At some point I'm going to need some sort of Inty program that lets me peek and poke to memory so I can test it. I don't know if something like that exists.

Edited by JohnPCAE
Link to comment
Share on other sites

  • 2 months later...

The final boards are built. So far I'm getting good video, but the whole stack needs to be fully tested (changing the video contents from the Inty). Then I have to update the microcontroller code to support all five screen modes. Already I think I see one problem with the enable pin (video should be disabled by default), but that's a simple thing to fix in a later revision.

 

IMG_2139.thumb.JPG.20357b4f2a862840018aa2d8d7158a7d.JPG

Edited by JohnPCAE
  • Like 1
Link to comment
Share on other sites

  • 2 months later...

The hardware part of this project is very nearly finished. I need one more board revision (due to having the enable pin logic reversed), but everything else works. At this point, I think I need advice from the community. As it stands, anyone with basic soldering skills can build this as it uses only through-hole construction, but between the board and chip costs it's pretty pricey. An FPGA solution would be much better, and probably wouldn't need an external power supply like this does (the switching power supply component alone costs about $40).

 

Turning this into an FPGA isn't in my skill set, though, and I'm not sure it makes sense to spend the next couple of years trying to climb that learning curve. So I'm wondering if anyone here has any ideas.

 

As for the software side (yes, there is one), the microcontroller code needs an update, but it's not particularly hard. At present it only supports text mode and I'd have to slightly expand it to support the three graphic modes. It's a pretty trivial change. I also want to add support for things like scrolling and column blanking, which is also a pretty easy change. The microcontroller (which isn't visible in the above picture) is a Sparkfun RedStick. I chose it because it's basically an Arduino Uno in a tiny form factor and doesn't require a cable to program as you just stick it in your USB port. That's actually one of the cheaper components in the setup: the IDT FIFO and dual-port RAM chips are the expensive parts.

 

One thing about the software is that you can't use the Arduino IDE to create it. The problem is that the machine code it produces is just far too inefficient. I'm using Atmel Studio 7 and everything is written in assembly. That's the only way this can work.

Edited by JohnPCAE
Link to comment
Share on other sites

As an alternative to an FPGA, have you looked in CPLDs?  They are simpler than an FPGA.  For example, the Microchip ATF15xx family of chips is good and you use WinCUPL to program them.  As a cheaper and simpler option, you can also use WinCUPL for SPLD chips such as 22V10 PAL chips.  You may need get a new programmer/chip-burner, at least for the CPLD chips.  Both CPLD and SPLD chips are available in 5V.

Link to comment
Share on other sites

22 minutes ago, JohnPCAE said:

 That sounds like the same sort of learning curve, though.

It depends on the individual.  For me, WinCUPL has been easier to learn than Verilog or VHDL.  That said, there remains a learning curve that takes time.  As you suggested earlier, sometimes it is better to farm the work out to someone else so you can focus your time on other parts of the design.  

Link to comment
Share on other sites

  • 1 year later...

I've started working on a redesign of this project. While the exitsing one works, IMHO it would be prohibitively expensive for someone to build and the stack of half a dozen boards leads to unreliability. Luckily, something has appeared on the market that has the potential to drastically simplify the project while also making it more capable.

 

The Raspberry Pi Pico features a dual-core ARM Cortex M0+ processor running at 133MHz, 264kb SRAM, and 2Mb of flash. With these features, I'm working on a design for the project that works very differently. Instead of using multiple output boards that convert dot and color information to composite video, one core of the Pico handles all of that and sends digital composite information to a single output board. The other core of the Pico listens to the Intellivision bus, and they share the screen buffer, color palette, and font information between them. To marry the Pico, which is a 3.3V device, with the Intellivision I'm using four TXB0108 level-shifters from Adafruit.

 

I've already breadboarded the output board design and have it working, and I've written some code for the Pico that handles the output core. A breadboard produces signals that are too noisy for decent color, so I've designed a complete project board and I'm waiting for it to arrive. Then I can work on color conversion, more output modes, and implement the code for the other microcontroller core that will listen to the Intellivision bus. The project promises to be vastly simpler and cheaper to make, and will likely be more capable.

 

One thing I learned is that there is a huge difference between board prices. OSH Park wanted over $200 for three boards, but the price from Jlc Pcb was $15 for five boards. I have no idea if there will be a huge difference in quality, but I've ordered from them before and the boards were fine. The only way to know is to wait until they arrive.

Edited by JohnPCAE
  • Like 2
Link to comment
Share on other sites

The Raspberry Pi Pico has a feature that I would highly recommend you investigate for the this project: PIO.  These are dedicated bits of high-speed programmable hardware that run in parallel to the dual ARM cores.

 

https://www.digikey.com/en/maker/projects/raspberry-pi-pico-and-rp2040-cc-part-3-how-to-use-pio/123ff7700bc547c79a504858c1bd8110

Link to comment
Share on other sites

  • 2 months later...

I have my 2nd generation of the project fully working now, and I'm in the process of adding software features to the firmware. I have a question, though: of all the components that it uses, the hardest one for me to source is the right-angle card edge connector that the cart plugs into. Does anyone have any insight on which ones are best? It seems that the ones in the Inty are somewhat special in that the actual connector protrudes a bit to allow the cartridge shell to slip over them.

Link to comment
Share on other sites

I guess no one knows? When this is fully released we'll have to come up with an answer. The hardware design is complete and only requires some more testing before I can fully sign off on it. Note that this is NTSC-only as I don't have any PAL equipment.

 

As far as features, programming it will look a little familiar to anyone who has done bare-metal VGA programming. It exposes two registers at 0x007E and 0x007F, where 0x007E is the register index and 0x007F is the register value. Both are read/write. So far I have the following programmable features implemented for text mode:

 

- signature register (read-only) that allows a cart to detect the expansion module

- programmable buffer start position (allows scrolling and page-flipping)

- programmable buffer pitch (default is 40 since the screen displays 40 characters but it can be set wider or narrower -- useful mainly for scrolling)

- programmable scanlines per character (as of now it allows values from 6-16, default of 8, yet to be tested)

- display of top row, bottom row, left column, or right column can be disabled, or any combination thereof (useful mainly for scrolling)

- pixel-level vertical scrolling

- 2048 built-in character dot patterns (not writable)

- ram character dot pattern address offset (i.e. user-programmable dot patterns)

- 256-color palette (programmed as 4 timeslices, similarly to how the 8915 color chip works: conversion from RGB is way too expensive in terms of CPU time, but I'll supply an Excel spreadsheet that can do the conversion)

- display enable/disable (allows registers to be programmed and video buffer to be set up before the screen is shown)

 

Planned features (not exhaustive: I add features as I think of them):

- cursor support (character position, start scan line, end scan line, blink enable)

- four-color character support

- bitmap graphics mode

- blinking text

 

The screen buffer itself is at 0xD000, and is disabled whenever an MSYNC pulse is detected. One of the programmable registers makes the screen buffer visible to the bus. On MSYNC, many registers are set to defaults, but the screen buffer is not reinitialized as that would take too long. Hence why a "display enable" bit is essential)

 

The hardware also has a bidirectional 8-bit user port, which I also have to test.

Edited by JohnPCAE
Link to comment
Share on other sites

On 9/26/2021 at 1:36 AM, Lathe26 said:

The Raspberry Pi Pico has a feature that I would highly recommend you investigate for the this project: PIO.  These are dedicated bits of high-speed programmable hardware that run in parallel to the dual ARM cores.

 

https://www.digikey.com/en/maker/projects/raspberry-pi-pico-and-rp2040-cc-part-3-how-to-use-pio/123ff7700bc547c79a504858c1bd8110

I did some investigating into PIO and tested it, but I got faster performance without it for some reason. No worries though, I have the bus timing nailed down in my software now and I'm working on implementing features.

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

I can't believe this is actually legible even with a composite mod. Oh well, it will be an available screen mode. 80-column text mode is more minimal than the 40-column text modes because the Pi Pico simply can't do any more and get the scanline data out in time. So while it supports a cursor, blinking text, and 256 available colors for foreground and background, it doesn't support four colors per cell or row/column blanking. The code timing is just too tight. In 40-column text mode, however, you can mix several types of characters on the screen:

- Standard two-color characters

- Blinking two-color characters

- Four-color characters with fat pixels (4 pixels across per cell)

- Four-color characters with normal pixels (8 pixels across per cell)

 

The last character type uses two bytes per row in the font, of course, so that necessarily requires using RAM for font glyphs. ROM and RAM glyphs can be mixed at will.

 

Now that the text modes are fully implemented, time to implement the bitmap graphics modes.

 

80cols.thumb.png.3d82f42cbf10997d555e75991e15ea0e.png

Edited by JohnPCAE
Link to comment
Share on other sites

1 hour ago, Lathe26 said:

Interesting character sets in that image.  I think there is the old DOS, Intellivision, and Keyboard Component character sets.

Correct, plus there are several Commodore 64 fonts in there as well as a common arcade font. Also, since it supports variable character height up to 16 scan lines, you can use RAM to implement EGA or VGA text fonts. I'm not including the longer glyphs in the ROM because of the space they would take up.

Edited by JohnPCAE
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...