Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

  • Days Won


Lathe26 last won the day on October 29 2016

Lathe26 had the most liked content!

Community Reputation

2,854 Excellent

About Lathe26

  • Rank
    River Patroller

Profile Information

  • Gender

Recent Profile Visitors

10,885 profile views
  1. I have a suggestion in regards to the two board approach, use the same cable connector for connecting the new boards to the Intellivision board. I'm already doing something similar to make it easy to swap between the various existing composite mods. By having a common cable connector for both boards, it's easy for someone who buys the 1st board to later upgrade to the 2nd one. I don't recall if all Intellivisions put the AY-3-8915 in a socket or if some boards solder the chip straight in. If the former is the case, then a DIP-18 ribbon cable adapter or something similar would do the job nicely. If the latter is the case, then installing the 1st board would require solder work. Of course, simply getting the big metal shield off is a pain. Since only some folks can solder and other can't, there are folk in the community that offer video upgrading as a small service (at least from time to time). Once there is a modest number of folks with the 1st board installed (including users with no solder skills), it would be easier for them to upgrade to the 2nd board later. Anyways, this is just a suggestion.
  2. Someone got a good deal on an old catalog. I was going to bid but forgot after sleeping in this morning. https://www.ebay.it/itm/333601160090
  3. Sounds smart to have a 2 phase approach to reduce risk. Regarding the Broadcom ARM chip for the later option, which one are you looking at? I'm assuming the chip has a hardware RGB input mechanism (unless you are planning to skip using a preemptive OS and write bare metal assembly). It's understandable if the later option a back-burner design and details are still in flux.
  4. Yes, the AFT1502 is programmable. I own several. The point is that it isn't programmable by end-users to change the color table. This would avoid customer complaints that "the colors are wrong", even if you've worked hard to pick the best colors. In regards to the feature where users are able to change the color table: A SPLD or CPLD is the simplest but the table is fixed. Maybe a few spare pins could be used for jumpers to let users pick from a handful predetermined color tables. However, the average end-user can't create their own custom color tables. A fast EPROM is has incrementally more flexibility. Probably could use the unused address lines for the jumpers, similar to above. A handful of people can create their own custom color tables with EPROMs, but they can be counted on your fingers in the Intellivision community. Maybe one of them would offer custom EPROM color tables as a service, though I'm not certain if there is a practical mechanism for an end-user to be able to effectively communicate the shades they want on their own TV to someone else who writes the values to the EPROM. A microcontroller with SRAM is the most advanced option for color table configurability. End-users can change the colors at will. Either the menu program would be in the microcontroller (i.e. a text menu via a terminal program) or a GUI executes on the host system (Windows, Mac, Linux?). The downside is that this solution is also the most complex by far. It might fit in the $20-$30 budget but that isn't certain. Of course, there is a big question to ask in all of this: what is the right amount of configurability of the color table to offer the end-user? Too little and you have to deal with complaints (but design and user setup is easier). Too much and it might just be "rope to hang themselves" in that some end-users might just mess up the colors or find changing the colors too hard (may need a "restore defaults" menu option for the users to recover).
  5. Yes, GAL or ATF1502 are very simple. That is their advantage but also their flaw. Once such a simple device is shipped to end-users, the colors are not customizable by the end-user; the colors are instead locked in. If the user doesn't like the colors, the end-user doesn't have any options. A fast EPROM is better in that a handful of folks can reprogram them to differ color shades, but only a handful of people can do that. Going to an SRAM with a microcontroller gives maximum color flexibility, though likely at higher cost due to the complexity
  6. I don't know if the EPROM idea will work since some are too slow for video signal speeds. A slightly more advanced (uhhm, complicated) design would be to use a 16-bit SRAM that stores the active color table. Have a microcontroller that loads the SRAM at boot. Additionally, the microcontroller could have a serial port that lets users change the colors table. Since many microcontrollers include on-board EEPROM, any user configured colors could be stored there when power is off.
  7. Personally, it would be better to skip the OSSC and either go straight to component or get an HDMI chip to have an all-in-one upgrade board.
  8. Regarding Magic Carousel, will it be the same or similar ROM previously sold? Understandably, might have some title screen change but will there be any other changes to the code? Just curious.
  9. Whether you use RF or Composite (ex: the above RF Tuner), the TV will need to be able to accept NTSC signals.
  10. What hurt the Kin badly was the internal politics and delays inside of Microsoft. The Kin came from the acquisition of the Danger Hiptop / T-Mobile Sidekick, which was a successful product line before the Microsoft acquisition. After the acquisition, from Wikipedia: According to Engadget, there was jealousy and rivalry in Microsoft's executive ranks, and Windows Phone Senior Vice President Andy Lees managed to wrest control of the Kin project away from Allard, and move it under his Windows Phone division. Danger's Sidekick, the predecessor to Kin, was based on the Java programming language, but Engadget says that Andy Lees wanted Kin to run an in-house Microsoft operating system. Microsoft planned to base Kin on Windows Phone. Due to delays with Windows Phone, however, the software instead had to be based directly upon Windows CE. Engadget claims that Andy Lees lacked enthusiasm for the Kin project. Nonetheless, Microsoft spent a further two years developing the Kin until its release in 2010. I can confirm that the internal Microsoft water-cooler talk (by employees not connected to the Kin) aligns with the above. The talk was that 1) the Kin continued being developed for ~1 year with its original OS then 2) was forced to switch to WinCE which threw out the previous year's work and 3) most of the original Kin employees quit. Again, this was the rumor mill inside Microsoft, but it crudely aligns with what Wikipedia / Engadget say. By the time the Kin came out, the original fans of the Hiptop / Sidekick had moved on and the market had shifted. The Kin's failure rests on Andy Lees, not Allard.
  11. Even better, intvnut and decle did a extensive work on reverse engineering it! The PDF here includes photos Further, here it is in action
  12. Adding to the ultra rare list of items, there are a couple items used internally by Mattel when the KC was converted to be part of the "Black Whale" development system. One is the ROM cartridge that repurposed the BASIC cartridge. 2 are known to exist (one is mine). The other item is the serial board. 1 is known to exist.
  13. I can digitize the tapes with a 4-track Tascam recorder. If anyone has tapes they want digitized, contact me.
  • Create New...