Jump to content

The Southsider

  • entries
  • comments
  • views

Batari Kernel

Sign in to follow this  


Now that the Juno First release candidate is out, I have a bit more time to look at other 2600 programming. I have been interested in batari basic for a while as I have several game ideas that could be done with a custom kernel strapped on. However, until recently I hadn't really looked at batari basic properly.


One thing that has been bothering me is that batari basic doesn't have a way to load playfield data directly from ROM. There are several games (e.g. Cave In) that have a high resolution playfield, but this requires extra superchip RAM. To cut a long story short, I have now written a prototype batari kernel that can load playfield data directly from ROM, without the need for the superchip. This should make several new kinds of games possible, and allow some existing superchip games to be released on regular carts.


The new kernel works by copying a single line of the playfield into RAM at a time. When a new playfield line is required, the kernel performs a bankswitch and copies the next line into RAM. The key to the technique is the following code which is placed in each bank. To make this code work, X is set to the bank containing the PF data, pfptr points to the start of the data, and pfoffset holds the current playfield offset from the start:


; Switch To Playfield Bank & Copy Data
 lda bankswitch_hotspot-1,x; [9] + 4
 ldy pfoffset; [13] + 3
 lda (pfptr),y; [16] + 5
 sta aux1; [21] + 3
 iny	; [24] + 2
 lda (pfptr),y; [26] + 5
 sta aux2; [31] + 3
 iny	; [34] + 2
 lda (pfptr),y; [36] + 5
 sta aux3; [41] + 3
 iny	; [44] + 2
 lda (pfptr),y; [46] + 5
 sta aux4; [51] + 3
 iny	; [54] + 2
 sty pfoffset; [56] + 3
 ifconst bankswitch
if bankswitch == 8
  lda $FFF9; [59] + 4
if bankswitch == 16
  lda $FFF9; [59] + 4
if bankswitch == 32
  lda $FFFB; [59] + 4
 jmp EndLoad; [63] + 3


This code requires 57 cycles, so an extra blank line is required between PF rows. However, I think it still looks good (compare the attached Cave In screenshots below to see the difference). Let me know if you can see any improvements to this technique? Obviously it could be improved if the playfield data was always in the same bank as the kernel, but this isn't practical for many games.





Because the PF data is loaded from ROM, it could technically support more than the 31 PF rows of the superchip kernel, though I haven't tried this yet. The kernel is still at a prototype stage and I could use a bit of help to improve it and integrate it properly into batari basic. The files that I have changed from the standard 1.0 release of batari basic are attached (in batarifiles.zip).


The main issues are:

  1. There isn't enough RAM left to support various kernel options, e.g. pfscore, pfheighttable, pfcolortable, lives, etc. This can probably be fixed by reorganising things a bit.
  2. The colour data for the player 1 sprite is off by one line (not sure why).
  3. It should probably be integrated as a new kernel, rather than a hack of the standard kernel.
  4. It is relatively tolerant of page boundary crossings in the playfield data, but this could be improved.
  5. There are some weird issues display missile and ball sprites (occasionally it craps out completely).

I have been using the Cave In source code as a testbed for this kernel. However, I don't want to post the code here as I haven't heard from Atarius Maximus yet. I can only compile pre-RC1 versions as the new kernel requires a bit of extra space in each bank and this is pushing things over the limit. Hopefully this issue can be fixed in later versions.


Anyway, let me know what you think? I'm not sure of the status of the superchip boards, so this kernel might not be necessary, but I still think it would be nice to avoid using the superchip if it is not strictly required.



Sign in to follow this  


Recommended Comments

Oh well, this didn't generate much interest from the BBers! I guess it doesn't do anything that can't be done already with the Superchip. It might be useful when memory is really tight, but I'm leaving it for now.



Share this comment

Link to comment

Adding an extra blank line is an approach that never occurred to me. It looks like with a little tweaking, this could work. It would provide a way to release Cave In if the development of ARM boards gets delayed much more.

Share this comment

Link to comment
Add a comment...

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

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Create New...