Search the Community
Showing results for tags 'Kernel'.
Found 3 results
So as some may know I'm working on a coprocessor cart for the 2600 which will essentially reduce the system's job to generating graphics and sound. As such I'm now trying to decide if it would be possible to build a frame buffer using the majority of the 4KB the system can address as it might be difficult to always know which part of the screen the 2600 is drawing. Essentially, the idea is that the coprocessor will write an atari rom to a ram chip which the 2600 will read. The chip will contain a bare minimum kernel, the sound the system should currently be playing, and the line buffer which gets drawn with the TIA. The issue is that I'm not sure I can get the two chips in sync enough to know which line the system is drawing at any one time. Therefor I want to know if it would be possible to write at least a partial frame buffer so that the ram could hold several line buffers at once and the 2600 could just request the one it needs. For example, the code contains a variable F which is equal to the current line being drawn, 1-10 (holding a 1/16 of the frame in a buffer), and depending on that it could draw one of the line buffers in the 'ROM'. I'm assuming for the moment that since the 2600 can only draw four colors per line that each of the 160 pixels is represented by a 2bit number, 0-3, plus the four color pallet meaning that the frame buffer would be 44bytes (which sounds low). Of course I could be completely wrong. I'm kind of a newbie on the 2600 so some input from the experts out there would her really appreciated. Thanks in advance!
After having done some successful Trak-Ball hacks lately, I wondered if adding paddle support might be possible too. Both have (do they?) to be polled during the kernel, but I found that the Trak-Ball polling is surprisingly tolerant to irregular timing. E.g. if you poll every 8th scanline, no one will notice, if you skip some of those polls. And it doesn't matter where you skip them. So you can poll in 8,16,32,40 and then in 8,24,32,40. The intervals do not even have to be identical. A poll e.g. in 5, 14, 31 and 39 would work too. And since my hacks only poll during the main kernel, skipping a big number of scanlines is still not noticeable. I haven't tested this, but probably polling outside the kernel a number of times with not too large gaps between the polls would somehow work too. You do not have that flexibility for paddle polling. There the timing has to be very strict. And the kernel is the only part of the code, where you have such a timing over a longer period. I think most of the Trak-Ball flexibility results from relative positioning based on the previous position, where in case of a paddle, we start from scratch with each frame. So as of now, it seems that adding paddle support to an exiting game is much more complicated than adding Trak-Ball support. But maybe some of us can come up with some new ideas? E.g. can we do relative positioning with a paddle? Awaiting your input...
Hello folks, After the positive response from the Homebrew group on Facebook, I decided to start creating a tool for drawing out kernel code. This would ease out development of correctly timed drawing code, using a simple drag-and-drop tool. Here attached is a HTML demo of what I've made last 2 days. It is still very preliminary, but it is just to give the feeling. kernelpaint.html see also on Github: https://github.com/Yvar-deGoffau/Kernel-Paint Please send in any feedback, and I hope to find more free time in my week. Of course, all contribution is more than welcome!