Hacker News new | past | comments | ask | show | jobs | submit login

So the cartridge is the computer and basically treats the console as a dumb display? That's not as exciting as I was hoping.



The 2600 is streaming the data from the cartridge, including the program that is run on the 2600. We should remember that there's no frame buffer in the 2600, so there's considerable work done by the 2600 every frame - just as there is when its working with any other cartridge.

The 2600 kernel that runs on the 2600 is excellent but the encoding method is what makes a real difference here. Lodefmode did a great job with this. The use of playfield/background and player colour is exceedingly clever.


No frame buffer. The target CRT display scanned an electron beam from left to right in about 63 microseconds, snapped it back in just a couple more microseconds, working gradually downward to produce about 200 such lines before taking a couple milliseconds to return to the top. The 6507 had to literally write the pixels into that raster in real time, and was just skin of the teeth able to do that, hence the phrase 'racing the beam', leaving just the retrace times for any other program code to run. To get video from a cart, all that still has to happen. Pretty cool.


It reminds me of the gameboy player for the SNES, where the entire gb console ran inside the cartridge and used the snes for inputs and display. In this case a PIC controller is the cpu in the cartridge doing the heavy lifting.


Ever hear the term "racing the beam"? That came out of game programming for the 2600. There is a book named after the technique that is pretty great and well worth a read.

https://en.wikipedia.org/wiki/Racing_the_Beam




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: