mini kernel question

[+grafixbmp]

Since mini kernels can be droped into the screen rendering, was wondering about a text window with about 2 or 3 rows of text and a black background. With so much extra rom space now with bankswitching, text in game at the top or bottom of the playfield, based on events which activate the text would be great especialy for RPGs.

 

Since the batari basic documentation said that a standard mini-kernel takes about 10 scnlines to complete, I figured 2 rows of this would be enough to do 2 or 3 rows of text if the characters were only 5 pixels high. I went ahead and drew up a font that has 48 characters and each would take up half of a player sprite.

 

I may try to write one some time soon if the demand it out there. My do it anyway as I will need it fo something I am trying to do.

 

 

And here is a short sentence to test what it looks like.

 

Edited January 19, 2010 by grafixbmp

[+Random Terrain]

That would be great A lot of us have been waiting for something like this.

[RevEng]

Definitely would expand the number of projects one could tackle in bB.

 

Were you thinking 24 bytes of ram for the text, or 2 with indirect addressing to rom? The latter is attractive memorywise, but the former would allow for complex score and statistic information to be displayed in games.

 

[edit - I guess 2 with indirect addressing could also point to ram too, when users want dynamic text. A wasted 2 bytes for that case, but probably worth it for the flexibility.]

Edited January 19, 2010 by RevEng

[+grafixbmp]

The batari basic guide says these would be the limitations of RAM for mini kernels. 4 bytes at aux3 to aux6, temporary storage at temp1 to temp6, and the last one I will take directly cause it is a bit more complicated "If you can ensure that the programmer won't try to call drawscreen while in a subroutine while in a bank-switched game, you might be able to use stack3 and stack4 which are normally reserved for stack space."

 

 

So this gives a total of 4 bytes dedicated plus 6 more bytes (10) with the potential of 2 more (12).

 

at 10 to 20 scanlines, this should be enough for 2 rows of text and plenty of space for overhead. And a graphics table for all characters in ROM. Would a 48 character table be enough or are there other characters that may be needed?

 

Any other thoughts?

[+Random Terrain]

at 10 to 20 scanlines, this should be enough for 2 rows of text and plenty of space for overhead. And a graphics table for all characters in ROM. Would a 48 character table be enough or are there other characters that may be needed?

It's not a big deal, but if you had the extra space, you could add 4 arrows (up, down, left, right) and maybe a heavy centered dot (bullet).

[RevEng]

An arrow or ellipses would definitely be handy for indicating dialog continues.

 

Allowing the coder to setup a variable to change the color of the text would be handy. It would allow you to have dialog between characters, each one with their own color.

 

The coder could do something like this in bB...

 dim fontcolor=z
fontcolor=$2f

 

And in the asm something like this so the color variable is optional...

ifconst fontcolor
  lda fontcolor
 else
  lda #$0f
endif
; set PM colors

[+grafixbmp]

at 10 to 20 scanlines, this should be enough for 2 rows of text and plenty of space for overhead. And a graphics table for all characters in ROM. Would a 48 character table be enough or are there other characters that may be needed?

It's not a big deal, but if you had the extra space, you could add 4 arrows (up, down, left, right) and maybe a heavy centered dot (bullet).

 

I had thought about a few ideas that could be done in game code rather than in kernel. Menu options with an icon at the far left and all text indented one space. This way you could press down during the text window and the text would scroll up by one. The bottom of the options would cause the icon to shift to the lower ine of text. Likewise when going up the icon would shift back up when the top of the list is reached. This crude menu system would allow for multiple options during turn based battles or other choices.

 

As far as continuing text lines, just having the missle at 2X for 2 scanlines in the lower right corner of the text window either flashing or with a steady 3 in a row would be enough for continuing by pressing the button. Weather there would be more text or return to gameplay it wouldn't matter. Either must be done to continue.

 

 

I also thought that if this text window were to just override the standard kernel for either the last 2 or first 2 sections of the playfield so that the normal screen would be drawn as normal with the upper or lower sections missing during this mini kernel then thoes normal bytes used for the screen displaying could be used or overridden during the text use. this would add another 8 bytes for text windows then when the text window is not needed the screen image is refreshed to reload the full playfield image.

 

The idea of 4 arrows and a center dot/bullet could be good for cardinal directions or special stick options. I figured that if the missles were used, this would give more space for text.

 

Another good reason to do 48 characters is that all the data needed for text only takes 120 bytes in ROM if the characters are doubled up. If one would want to get closer to 128 then 2 more characters could be added.

 

It might work best for speed if each lettr took all of a byte that way you would have AA BB CC etc. And just drop out the one not needed in RAM and add the one needed for each line.

 

gonna think on this for while.

Edited January 20, 2010 by grafixbmp

[Gateway]

I support this!

 

I am working on an adventure game in bB but got stuck on this very idea. I really want to have a line or 2 of text in the score area to identify the object or enemy that the player encounters on the screen as he moves to a new room, though it would be in "real time arcade" style instead of turn-based.

 

I played around with asm text generators done by Eckhard, Paul Slocum, and others from the Stella archives but have had trouble meshing it with bB's multisprite kernal (note some of the minikernals don't work the same way when moved from standard to multisprite)

 

I am most interested in making this work with the multisprite kernal, if possible.

 

I have been busy with school, etc so am distracted from programming, but would like to get back to working with bB again, and this would be a nice addition to games if it can be done in a way that doesn't eat up too much RAM, etc.

 

I will follow this thread and your progress!

 

P.S. Yes, the AA, BB, CC... technique seems to be the best route. I played around with fitting 2 - letter combos into 8 bit wide sprites. That allows in a 6- digit score table up to 12 character words..

 

Example: GOBLIN = 3 sprites:

 

GO

BL

IN

 

replace IN with ET to spell GOBLET..

 

but the number of words you can actually spell this way is very limited and uses up memory fast!

[+grafixbmp]

This is kinda a loose representation of what I was hoping for. As you can see the game area is smaller than normal just because the text windows take up 2 whole rows of PF graphics. Any thoughts? I was hoping for the ability to do it at the bottom or top. That way if the main player is at the top, the text will appear on the bottom likewise for if your player is at the bottom the text will be up top.

 

[+Random Terrain]

Sounds good. For any games I would make with it, I would probably choose a spot and stick with it. For example, if I choose to have the text at the bottom, I'll leave it there so the player always knows where to look. We could make some cool adventure games with this.

[+grafixbmp]

Sounds good. For any games I would make with it, I would probably choose a spot and stick with it. For example, if I choose to have the text at the bottom, I'll leave it there so the player always knows where to look. We could make some cool adventure games with this.

I guess if the text window overrides at the bottom only, then if the players character is near or exactly where the text window appears, you just wion't see you character or avoid having text activate when your player is over the text window area.

 

Since the text would take up space of the screen, you may not want to have it active on screen all the time. Or have the option to just have one line of text. As far as freeing up some extra RAM during the text windows render, One line for 4 bytes and 2 for 8 bytes

Edited January 22, 2010 by grafixbmp

[Gateway]

I like it so far!

 

I can see where this could be used for a game title screen, between waves, or a game over screen as well as text information being displayed during the gameplay itself.

 

I like the text on the bottom best, but if you can make it optional for top or bottom that would be even better I think ( one or the other I mean, not both on screen during gameplay, as I assume this would use to much RAM and cause display problems? )

 

For my adventure game in particular, I have a top-down view of the "dungeon" and I am using a vertical scroll ( with multisprite kernal ) so the text block would be just fine taking up the bottom next to the score. I would still be able to have my player move around because the screen would move with him..

 

The above is assuming the text mini kernal is similar to how the score mini kernal works, in that the score stays in place while the playfield can scroll independently?

 

Thanks for doing this. Please continue!

 

EDIT: Forgot to ask: What affect is this text mini kernal having on the score mini kernal? Specifically, will the text replace the lives variable or statusbar variables currently available to the score? If so, I suppose it is fair that a game designer picks one or the other..

Edited January 26, 2010 by Gateway

[+grafixbmp]

I was hoping that if the the time existed to let the text prep a portion and store part of it to some RAM then I could work part of it backwards and meet the start of text right when the first byte needed to be done for the start of the text. Or something like that.

 

So a full line of text will be stored as 12 bytes in ROM as there are 12 characters per line. Indexed by a single byte and with 2 rows on screen at once will be be just 2 bytes needed for index with.

 

Each letter uses 5 bytes for the visual font data in ROM. Each character comes doubled (AA BB CC DD etc) So I guess I could index the first and second leters and just cut and paste nybles across the whole first line of text which would take 6 bytes (three for each player). Some can be stored in RAM while some can be processed between each display of text per scanline to recycle the RAM for the rest of it. I bet 12 bytes would be a good buffer.

 

I bet it could be done with less than 16 bytes and leave plently of flexability for plenty of text. Would 256 lines be enough for most games? Each line being 12 character max long and any combination of 2 lines at a time in any color.

 

I was hoping to use 4 scanlines of prep time before the first scanline of the characters will need to be displayed. Starting X register at 5, each scanline is preped and stored, the x index can then be DEC and the procedure repeated until it reaches 0. Since text will always take the same amount of scanlines, a scanline counter may not be needed during the text window so that could be temp stored to free up most registers which will probably be neccesary anyway.

 

If I can get something consistenly workorking, can someone else conform it to work with BB?

 

I bet only 2 flags (bits) and 2 bytes would be needed to work the whole thing. First flag would display text or not. Second flag would be used if first flag were true. If the second flag is true then text at top, if false then at the bottom. The full bytes would index which text lines are displayed.

 

I hope not to interfere with the score. And I will look at the status bar kernel and see if I can keep it functional. Heck since text only appears when needed, I may just have it override it when it is used and revert back to it when the text is done.

Edited January 27, 2010 by grafixbmp

[RevEng]

Any progress? A text mini-kernel would definitely be handy.

[+grafixbmp]

In order to display a mini kernel (I would assume), I will need to know where the best place for it to fall into place so that I can start with a 0 byte already in a register to blank out the screen and then set colors from where they are preloaded in ram. I also need to know where the original kernel can/will pick up where it left off. This way, it can load fresh data back to the original display kernel. But the new text kernel needs to modify any data that keeps the original in sync where it should be.

 

The idea I was thinking of was that the text kernel would appear during any screen and would seem to just overlay the game screen either at the top or at the bottom but NOT both at the same time. I had hoped for 2 rows of text so that the kernel could just loop 2 times.

 

I say all this because I wanted to know what location in the normal kernel would this be good to fall in when needed? Can I just open the normal kernel in a text editor to look through it? Which kernel should I build this around or should I do them all? Anyway, hope you all understand what I mean.

[RevEng]

The most natural place to implement a minikernel in bB is above the score, below the main playfield area. All of the bB kernels do a "jsr minikernel" there, if "minikernel" is defined.

 

That way you just distribute a "textkernel.asm" with the minikernel label inside it, and the bBers basically include/inline it.

 

You won't know which cycle in the scanline you're on, so you'll need to do a "sta WSYNC" at some point.

 

Unless the setup is hugely expensive, its probably best to blow a few scanlines for it. Otherwise, create a "setuptext" label in your kernel and instruct the bB coder to do a "jsr setuptext" somewhere in their code. (Which executes during overscan)

 

The bB kernels use the timer for the scanline count, and the code that follows the minikernel (the score kernel) doesn't assume a whole lot about the state its in, so you don't need to fret too much about the hand-off after you rts.

[yuppicide]

With 5200Basic (for making stuff on the Atari 5200) there is a PRINT command where one could easily print text. I've been wanting something similar for bB for awhile now.. I have something I'd rather make on the 2600, but will move it to the 5200 if I feel like it. The project I'm doing is all text and no it's not a text adventure.

[+grafixbmp]

The most natural place to implement a minikernel in bB is above the score, below the main playfield area.

 

This just sounds like trying to squeeze 4 big people into a 3 person bus seat. How can there be space on screen for it if it comes after one but before the other "Somethings gotta give"

 

All of the bB kernels do a "jsr minikernel" there, if "minikernel" is defined.

 

That way you just distribute a "textkernel.asm" with the minikernel label inside it, and the bBers basically include/inline it.

 

It is possible that the PF row height could shrink which would shift the gameplay area up but could leave the score in the same. Like when a text trigger is fliped, the game screen gets effed up by squishing it up, rendering text and the score. THen when the joy button is pressed, the text kernel is removed, and everything goes back the way it was.

 

You won't know which cycle in the scanline you're on, so you'll need to do a "sta WSYNC" at some point.

 

I actualy like that. Because text can be code intensive, and doesnt need to take up much visual area, It can be easy enough to keep track of how many scanlines it will take before an rts.

 

Unless the setup is hugely expensive, its probably best to blow a few scanlines for it. Otherwise, create a "setuptext" label in your kernel and instruct the bB coder to do a "jsr setuptext" somewhere in their code. (Which executes during overscan)

 

I will take this under advisement.

 

The bB kernels use the timer for the scanline count, and the code that follows the minikernel (the score kernel) doesn't assume a whole lot about the state its in, so you don't need to fret too much about the hand-off after you rts.

This is also good to know. I guess I will start simple and see where it goes...

[RevEng]

This just sounds like trying to squeeze 4 big people into a 3 person bus seat. How can there be space on screen for it if it comes after one but before the other "Somethings gotta give"

When a minikernel isn't running bB doesn't use up 100% of the available real-estate on the screen. I just ran a quick test and hit WSYNC 16 times in a minikernel without overrunning 262 lines.

 

To use your analogy, batari reserved a couple of seats on the short bus for us minikernel coders.

Edited March 10, 2010 by RevEng

[Cliff Friedel]

This looks really cool. Would be incredibly useful to have text functionality in BB. Far better than using the playfield or sprites. Rock on!

 

Cliff

[+grafixbmp]

This just sounds like trying to squeeze 4 big people into a 3 person bus seat. How can there be space on screen for it if it comes after one but before the other "Somethings gotta give"

When a minikernel isn't running bB doesn't use up 100% of the available real-estate on the screen. I just ran a quick test and hit WSYNC 16 times in a minikernel without overrunning 262 lines.

 

To use your analogy, batari reserved a couple of seats on the short bus for us minikernel coders.

Ok. The real question is going to be, if the text line (even just one) were to fall in before the score, will this then shift the score down or can it fall under the score? And I would still like the option to display at the top.

 

But part of the whole concept I was intending, was to free up some of the RAM used for the gameplay screens only when text needs to be displayed and not have a space reserved just for text. This way, if someone wanted to set it for a maximum of lines displayed, it could even cover the whole screen in text for textaventure games or other drop-ins just by freeing up as much ram as needed from the buffer for the normal PF graphics to allow it temporary priority.

[RevEng]

It would shift the score down. Though there's no reason the text kernel couldn't keep a constant number of lines, even when it wasn't showing text.

 

If you want to position the text at the top or under the score (or if you want to replace X% of the screen) you'll need to hack a custom version of each bB kernel you want to support. For a few different reasons this might be painful. (Many different patched versions of bB out there, any new official updates would need to be patched, different kernels count the y register differently)

 

If you want to take over the playfield completely, the bB coder can call an alternate text kernel subroutine instead of doing a "drawscreen" call.

 

Right now, a minikernel text routine that "only" displayed a few lines of text and shoved the score downward would still be a major boon to the bB coders. It might be a good first target.

Edited March 11, 2010 by RevEng