Jump to content
IGNORED

Text Minikernel


Karl G

Recommended Posts

Version 0.5 is up! Changes include:

 

  • Optional support for having most of the code and data reside in a different bank. This frees up space in the kernel/graphics bank, and allows for the possibility of more text data in the other bank. I believe this should allow around 240 messages to fit in a dedicated bank.
    • The minikernel code was broken-up into two files: "text12a.asm" and "text12b.asm"
    • If there is no need to put most of the code and data in a different bank, then both of these can be added to the last bank with inline statements
    • If you wish to put most of the code and data in a different bank, inline "text12a.asm" in the last bank, and inline "text12b.asm" in the desired other bank, then set a const "textbank" with a value equal to the number of the latter bank.
  • Fixed a bug with the built-in score (code alignment issue)

 

I don't have a demo ready at the moment that shows off the extended text mode or the separate bank support, so feel free to ask any questions if you want to be an early adopter and run into issues.

  • Like 4
Link to comment
Share on other sites

My next goal is to add DPC+ kernel support. There are a number of complications with this:

 

  1. The minikernel would need to be installed with a customized DPC+ kernel file due to some of the issues below. On the plus side, bB makes it easy to use custom versions of included files by putting them in the same directory as the project.
  2. Adding a minikernel of any kind using the DPC+ kernel throws off the scanline count, so the timer in the kernel will need to be adjusted, of the screen height will need to be adjusted by the same number of lines to compensate.
  3. Minikernels need to be added to bank 1, which is almost completely full, so it will need to have a stub in this bank that jumps to a bank where most of the code resides. Fortunately, I already know how to do this.
  4. The score is enhanced in the DPC+ kernel, so I will probably want to use it instead of my built-in score option.
  5. Minikernels take up scanlines that would otherwise be usable cycles in overscan, where the bB code runs, and the DPC+ kernel already has less free cycles than the standard kernel. Additionally, there's not many cycles left in vblank that can be used to compensate. For this reason, the vertical size of the screen would probably need to be shrunk by as many lines as this minikernel adds in order for it to be a usable option.
  6. There's no way to control the screen height with DPC+ via the bB code, so this needs to be done in the kernel. The kernel code has the comment "not all values will work" without saying what ones do and why, so I'm proobably going to need help determine valid values here.
  • Like 2
Link to comment
Share on other sites

Oops; unfortunately I discovered a bigger issue with DPC+ support: I am missing 6 of the 12 temp variables that I use that are available in the other kernels that are used for the score digit graphics. I'm not sure if there's a decent way around this. I'm still investigating.

 

Edit: I imitated how the Titlescreen kernel defines these variables as well as clearing them out in the same way before I exit, but this isn't working, either.

Link to comment
Share on other sites

Actually, maybe I do know what the issue could be. The minikernel and text_strings table need to go in the last bank of the project. In the case of a 64K project, this would be bank 16.

Hi Karl,

 

Thank you for this advice and sorry for my late reply.

 

Bank16 is used by Bb for my sprite data, I did not know I had access to it? I shall try and see if I can access this bank.

 

Your kernel is key to unlocking my original vision for the game, so very keen to have this working :)

 

Where are you based out of interest? UK? USA?

Link to comment
Share on other sites

Hi Karl,

 

Thank you for this advice and sorry for my late reply.

 

Bank16 is used by Bb for my sprite data, I did not know I had access to it? I shall try and see if I can access this bank.

 

Your kernel is key to unlocking my original vision for the game, so very keen to have this working :)

 

Where are you based out of interest? UK? USA?

 

You are probably thinking of the DPC+ kernel, which has a graphics bank that you cannot access directly. Also, unless you use the DPC+ kernel, you don't need the "temp1=temp1" at the beginning of each bank.

 

"text12a.asm" will need to be in bank 16, but once you confirm that it is working, you will probably want to move "text12b.asm" and the data table to a different bank to save room in your kernel/graphics bank. At the top of your project, you will want a line like this:

   const textbank=15

Then the bottom of your project would look something like this:

 

bank 15

   bank 15

   data text_strings
   __H, __E, __L, __L, __O, _cm, _sp, __W, __O, __R, __L, __D
end

   inline text12b.asm


   bank 16

   inline text12a.asm

I appreciate you being an early tester/adopter. That will help me find bugs, and figure out what needs to go into the documentation when I write it.

 

Oh, and I am from Indianapolis, Indiana, USA. :-)

Link to comment
Share on other sites

 

You are probably thinking of the DPC+ kernel, which has a graphics bank that you cannot access directly. Also, unless you use the DPC+ kernel, you don't need the "temp1=temp1" at the beginning of each bank.

 

"text12a.asm" will need to be in bank 16, but once you confirm that it is working, you will probably want to move "text12b.asm" and the data table to a different bank to save room in your kernel/graphics bank. At the top of your project, you will want a line like this:

   const textbank=15

Then the bottom of your project would look something like this:

 

bank 15

   bank 15

   data text_strings
   __H, __E, __L, __L, __O, _cm, _sp, __W, __O, __R, __L, __D
end

   inline text12b.asm


   bank 16

   inline text12a.asm

I appreciate you being an early tester/adopter. That will help me find bugs, and figure out what needs to go into the documentation when I write it.

 

Oh, and I am from Indianapolis, Indiana, USA. :-)

Ok, I'm using the standard Bb Kernel (with PF and Player Colours enabled) but bank 16 is loading up with my sprite data, I have less than 900 bytes left in it and I'll be needing all of it for the sheer size of this game world. DCP+ I am not using.

 

I have already set the bank variable I think, and it just scrambles my screen for 10 seconds before crashing out.

 

I may try a new project altogether, then introduce my various engines into the file and see at which point it crashes, but as I have 16 banks this could take some serious resource to do.

Link to comment
Share on other sites

 

You are probably thinking of the DPC+ kernel, which has a graphics bank that you cannot access directly. Also, unless you use the DPC+ kernel, you don't need the "temp1=temp1" at the beginning of each bank.

 

"text12a.asm" will need to be in bank 16, but once you confirm that it is working, you will probably want to move "text12b.asm" and the data table to a different bank to save room in your kernel/graphics bank. At the top of your project, you will want a line like this:

   const textbank=15

Then the bottom of your project would look something like this:

 

bank 15

   bank 15

   data text_strings
   __H, __E, __L, __L, __O, _cm, _sp, __W, __O, __R, __L, __D
end

   inline text12b.asm


   bank 16

   inline text12a.asm

I appreciate you being an early tester/adopter. That will help me find bugs, and figure out what needs to go into the documentation when I write it.

 

Oh, and I am from Indianapolis, Indiana, USA. :-)

 

"You do not need to specify where sprite graphics go, as they all will be automatically placed in the last bank no matter where you define them (you can just leave all of your animation frames in the same bank that contains your main loop). Also, the kernel will always be placed in the last bank. Typically, bB modules and functions will as well. You don't need to do anything differently with drawscreen, and you typically don't with built-in functions or modules either."

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#kerneloptions

 

So I am unsure that I have any scope to use my last bank at all due to the fact this game is huge and needs the whole of it for Bb stuff.

Link to comment
Share on other sites

If you use another bank as I suggested, then it should not greatly impact the amount of space in the last bank. When I tested it just now, I only had a few bytes less in this bank. I save some by turning off the kernel's implementation of the score, then I provide my own, which is mostly a wash in terms of space. Other than a replacement for the score, all the "a" part does is switch to the bank where the rest of the code and all of the data resides.

 

Anyway, if you decide you want to try to use this, I am willing to try to debug your issue if you are willing to send me your code for testing.

Link to comment
Share on other sites

With some advice from RevEng, I've been able to work around the variable issue for the DPC+ kernel. I should have a DPC+ version of this to share soon. In the meantime, here's a WIP screenshot showing this minikernel being used with RT's 13 object DPC+ demo, using the text minikernel to show the name of the selected object.

 

post-48311-0-71704500-1549912422.png

  • Like 5
Link to comment
Share on other sites

However now all my sprites are tippled up.

 

If you use another bank as I suggested, then it should not greatly impact the amount of space in the last bank. When I tested it just now, I only had a few bytes less in this bank. I save some by turning off the kernel's implementation of the score, then I provide my own, which is mostly a wash in terms of space. Other than a replacement for the score, all the "a" part does is switch to the bank where the rest of the code and all of the data resides.

 

Anyway, if you decide you want to try to use this, I am willing to try to debug your issue if you are willing to send me your code for testing.


Hi Karl, Thank you again for your help,

I have made some progress now kind of, My screen is not mangled after following your advice, and it did take 250 bytes of my sprite rom, but I may be able to find efficiencies elsewhere.

Although now all my sprites are trippled up? Like its changing my register.

Link to comment
Share on other sites

However now all my sprites are tippled up.

 

Hi Karl, Thank you again for your help,

 

I have made some progress now kind of, My screen is not mangled after following your advice, and it did take 250 bytes of my sprite rom, but I may be able to find efficiencies elsewhere.

 

Although now all my sprites are trippled up? Like its changing my register.

 

Looks like you found a bug - I should have cleared out the NUSIZx registers before exiting my minikernel. I'll include the fix in my next release, but here's the fixed copy of text12b.asm for you on the meantime.

 

text12b.asm

  • Like 1
Link to comment
Share on other sites

 

Looks like you found a bug - I should have cleared out the NUSIZx registers before exiting my minikernel. I'll include the fix in my next release, but here's the fixed copy of text12b.asm for you on the meantime.

 

attachicon.giftext12b.asm

That's sorted it nicely on the trippling up :)

 

I need to remove the score now as its pushed up.

Edited by EvoMikeUK
Link to comment
Share on other sites

Ok, I have to force the register to NUSIZ0 = $00 in the main loop to overcome that.

 

This is now putting my cycles well over and getting lots of roll, so not sure if you can make it lighter. I too will work on my code to bring my cycles down too.

 

Yeah, any minikernel will reduce the number of free cycles, and this one uses more lines than most, so it will have a greater impact. The best solution if you can accept it for your game would be to shrink the visible game area slightly with some combination of pfres and/or pfrowheight, e.g.:

   const pfrowheight=7

Using my "squished" score font as described earlier would make a small difference as well, but not as much as shrinking the screen.

  • Like 1
Link to comment
Share on other sites

 

Yeah, any minikernel will reduce the number of free cycles, and this one uses more lines than most, so it will have a greater impact. The best solution if you can accept it for your game would be to shrink the visible game area slightly with some combination of pfres and/or pfrowheight, e.g.:

   const pfrowheight=7

Using my "squished" score font as described earlier would make a small difference as well, but not as much as shrinking the screen.

 

Again, thank you. Can I disable the score altogether to get some cycles back, I don't need it at all.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

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

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...