Search the Community
Showing results for tags 'kernel'.
Found 10 results
-
Hi all! For the past week, I've been teaching myself batari Basic while creating my first game as a programmer. The online documentation has been absolutely invaluable. (Thanks @Random Terrain!) After making a playable game, I thought I'd spend some time adding a bit of polish. I added sounds and a game over screen, but what it needs is a killer title screen! Searching the AA forums, I discovered the bB Title Screen Kernel. EXACTLY WHAT I WAS LOOKING FOR! (Thanks @RevEng!) I downloaded it and consumed the accompanying PDF documentation and examples. Then I followed the examples to generate my future killer title screen. I created the image assets, turned them into data using the recommended Image to Code utility, copied and edited the required files, and added the code to my game. Compile -> Launch LOOK! A title screen. But not a killer title screen. My animation isn't working. Where's the bouncing spider? I made the image source file per the instructions. I even made this snazzy animated GIF for reference. I'm currently trying to track down the issue. I created a test .bas that strips out every non-essential to eliminate any possible conflict, and it still doesn't animate. So I'm gonna post the working files here, in hopes that someone can explain what I've done wrong. TSK-anim-test.zip
-
I'm trying to make a sample game with 3 or 4 sprites. The problem is the character collision with floor is not very precise when it comes to gravity (pfread function). I have seen in similar threads that you have to divide by a specific number depending on width and height, but i can't get it correctly. I use multisprite kernel with pfread. Here's what i got so far: Sample.bas Sample.bas.bin Any suggestions? Thank you.
-
Hello everyone, I'm working on a project and I have a few questions: First, take a look into this code: As you can see, I'm loading X with #48, because the shape & color tables have 48 values each, this is the result: Now to the questions: 1. If I use #96 instead of #48, how do I update the Playfield only every 2 values? (What I'm trying to ask here is how do I modify the #48 and use #96 but still get the same results? So I can draw sprites using the #96 loop). 2. Is it still possible to draw sprites (Player/Ball) using that amount of resources in the Kernel? (Updating the PF & BK like in the code above). Thank you.
-
Is there a good summary of the various bAtari kernels and their strengths and weaknesses somewhere? I have to believe there is... but my search is coming up empty. Thanks so much.
-
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!
- 7 replies
-
- 4
-
-
- Development
- Kernel
- (and 2 more)
-
I'm sure this has been asked a dozen times before, but I tried searching the forums to no avail. If you want to create a 96-pixel display (perhaps for a 12x 8-pixel-wide character display), you might set NUSIZ to 3-copies-medium for something like this: P0 - P1 - P0 - P1 - P0 - P1 - (the dashes represent 8-pixel-wide spaces) Then, on the next scanline, you would shift P0 and P1 eight pixels to the right: - P0 - P1 - P0 - P1 - P0 - P1 Then you would shift back to the left for the next scanline. Classic venetian blinds effect. So my question is this. How do you deal with the problem of only being able to HMOVE 7 pixels to the left per scanline when you need 8 pixels? Do you need to perform a shift on the graphics to fake it? (...if you have enough cycles, otherwise you would need a second graphics table that is already shifted). That could work for a character display because there are spaces between letters. But is there a better way to do this, especially if you need to use all 96 pixels without any blank spaces? Do you need to strobe the RESPx registers in order to do this? That's the only other way I can think of that might work, but I'm not sure, I haven't done any of that yet. I don't have any example code yet. I simply set up the players and NUSIZ, but that's it, no graphics or HMOVE's yet. I'm just trying to figure out the best way to do it now rather than going down a few dead ends.- 2 replies
-
- 1
-
-
- venetian
- venetian blinds
- (and 3 more)
-
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...
-
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!
- 40 replies
-
- 1
-
-
- line buffer
- Kernel
- (and 1 more)
-
Hello there, I'm new here and new to Atari dev, but not new to 6502 assembly. That being the case, I am focusing a lot on the architecture of the TIA and the complexities of writing a decent kernel. After reviewing this site's 2600 101 tutorial, I am a bit confused on the "dos and dont's" of when exactly to perform certain functions. The examples given define what the TIA is doing, but I am hoping for a more comprehensive workflow so that I can visualize when it is best to perform game logic. In the NES world, you are a bit more shileded from TV protocol. For instance, when the TV hits VBLANK, you automatically go into an NMI. I use this time to handle all of my drawing and the main game loop for my logic. I'm happy to not use interrupts for a change, but I don't fully grasp WSYNC or HBLANK and what have you. I guess what I'm asking for is a better kernel example with documentation that provides best practices. Later down the line, I will develop my own tricks, but I would rather not reinvent the 30 year old wheel
-
I made a silly no-goal game for my son to play. It stars him as a little astronaut collecting moonrocks. I'd like some music in it someday, which I'm working on, but I really need help with the titlescreen kernel. My other silly no-purpose game featured a standard kernel playfield-based title screen, but after looking into the titlescreen kernel, i'd really like to incorporate it into this game. if anyone wants to help me build it onto this code, i'd be totally stoked. attached is the game .bas, and 3 image files I'd like on the title screen. i've dedicated the last day of vbB use trying to figure out this thing, but it just isn't compiling, no matter which build i use or which version of the kernel i use. the wizard produces code, but won't compile. bah! alternately if anyone can give me a .zip of an install directory package that has a working titlescreen wizard and working sound/music generator that runs under x64 windows, i'd be able to work on this myself i think. Moon.bas logo.bmp copyright text.bmp
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord