mos6507's Blog

I'm impressed that you guys can keep up the efforts on this over such a long period of time.

 

I hope to own one of these some day.

Only 12 columns?

Only 12 columns?

 

Give me a kernel that will do more than 12 8x8 characters and I'll plug it in

 

Just no immediate mode patching yet.

Impressive! Is that flicker free?

Impressive! Is that flicker free?

 

It flickers like Stellar Track. I will post a video demo later today that shows the full Atari 8-bit font.

Nice to see chimera running on real hardware!

The board looks smaller than I figured

 

...

 

A very perfect port of space invaders can be done with chimera

I suspect Rally S would work well on it

The main limitation on this mode is the lack of color. It's really up to the developers to come up with kernels that provide the drawing canvas for the ARM. We're just doing this first because we need to build the menu. Once we have the menu, we'll have enough of a foundation for this to work as a multicart, and we'll have a shippable "version 1" product. The rest of the "operating system" as it were can be developed during beta and beyond.

It flickers like Stellar Track.

Where is the advantage then?

It flickers like Stellar Track.

Where is the advantage then?

 

The advantage is being able to bring up a text engine in a minimal amount of code with a full character set with lowercase and special characters. The kernel that ARM runs over is really up to the developer. The same rendering being done here is transferrable to a 48-pixel or a suicide mission or playfield bitmap. The ARM doesn't really care. If someone magically comes up with a 96 pixel bitmap display that doesn't have to flicker (I'm not holding my breath) then the ARM will be able to render to it. The graphics will only ever be as good as the kernel allows.

 

For the menu I decided that 8x8 fonts were more important than eliminating flicker. That's why we're going with this kernel. 12 characters is enough for 8+3 filenames.

Give me a kernel that will do more than 12 8x8 characters and I'll plug it in

 

The coding for something like my "What the Dickens!" kernel should be pretty straightforward. Use the Z26 log or a similar feature on Stella to find out what stores need to happen when. I think you'll probably want a somewhat different implementation from my kernel (since you'll be using queues). Actually, I don't see any reason you shouldn't be able to have per-line color without blank lines, since using queues should save up quite a few cycles. No need to use the Y register for a loop counter; just fetch the color from the queue on each line, and use a zero byte to signify the end (use a value of $01 for black).

The coding for something like my "What the Dickens!" kernel should be pretty straightforward.

 

That doesn't do 8x8 fonts. It's a 4-bit font. There is nothing prohibiting it or any other kernel being used on Chimera. Any game has to build its own kernel and sync it up with Chimera. But I have some clear aesthetic requirements for the menu.

 

I don't see any reason you shouldn't be able to have per-line color without blank lines, since using queues should save up quite a few cycles. No need to use the Y register for a loop counter; just fetch the color from the queue on each line, and use a zero byte to signify the end (use a value of $01 for black).

 

I haven't been able to find a wide enough gap in the kernel for that. The kernel has to be timing-exact because that was the only way to get the full 8-bit resolution rather than the 7-bit technique used in Stellar Track. I need 7 cycles for each color change, and two color changes if possible per scanline (for the text and background color). It's easy to do that when you throw a small gap between the rows. Bitmap-style games probably wouldn't benefit a lot from doing color changes on a scanline basis anyway.

 

13 rows per screen for the menu seems like plenty to me. The no-gap kernel is 25 rows.

That doesn't do 8x8 fonts. It's a 4-bit font. There is nothing prohibiting it or any other kernel being used on Chimera. Any game has to build its own kernel and sync it up with Chimera. But I have some clear aesthetic requirements for the menu.

 

Actually, it's an 8-wide font; I simply define characters for each character pair, since the kernel allows 250 different characters (and could be adapted to allow one character on each line to be taken from an alternate set). There are three blank lines after every seven, but if queues were used rather than (zp),y addressing, and if they could be set up in advance, the blank lines wouldn't be needed.

 

I haven't been able to find a wide enough gap in the kernel for that. The kernel has to be timing-exact because that was the only way to get the full 8-bit resolution rather than the 7-bit technique used in Stellar Track. I need 7 cycles for each color change, and two color changes if possible per scanline (for the text and background color). It's easy to do that when you throw a small gap between the rows. Bitmap-style games probably wouldn't benefit a lot from doing color changes on a scanline basis anyway.

 

The "What the Dickens!" kernel uses, for each pair of lines, thirteen load/stores for shape data, and five stores of "don't care" data (two GRPx, two HMOVE, and one RESPx). If you use queue loads that take four cycles each, that should be 52 cycles for the loads and 54 cycles for stores. So 108 cycles out of 152, leaving 44 cycles for loop overhead, color loading, and anything else you want.

 

When using (zp),y addressing, it's necessary to waste cycles storing data to a temp variable and reload it; if you're using a queue, you could avoid that overhead since you could use the Y register as a temp.

Actually, it's an 8-wide font; I simply define characters for each character pair, since the kernel allows 250 different characters (and could be adapted to allow one character on each line to be taken from an alternate set). There are three blank lines after every seven, but if queues were used rather than (zp),y addressing, and if they could be set up in advance, the blank lines wouldn't be needed.

 

If you'd like to see it work you'd need to just submit some code for me to plug in. I'm expecting a lot of cool kernels to be created for it after it's in beta. That's the whole point, to bring more developers into the project. I'm at the mercy of easily extractable drop-in kernels for these demos. Anything really tricky, I can't do the surgery.

If you'd like to see it work you'd need to just submit some code for me to plug in. I'm expecting a lot of cool kernels to be created for it after it's in beta. That's the whole point, to bring more developers into the project. I'm at the mercy of easily extractable drop-in kernels for these demos. Anything really tricky, I can't do the surgery.

 

Here's a rather hacked up version of my 13-character demo set up to use queues. Replace the references to QUEUES+0 to QUEUES+14 and INTIM with appropriate references for the appropriate queues (I used INTIM for the background color queue so I'd have something that changed on a per-line basis; QUEUES+13 and QUEUES+14 are the background colors for even and odd lines, again using separate queues so I'd have something to test per-line color changes).

 

Note that this kernel does not handle the shimmer, but that can be done either by varying which part of the code one enters (there are four entry points) or else by varying where on screen one starts and then having an appropriate offset in the queues).

 

Hmm... I can't upload the code here since it's a blog entry. Grrr... I guess I'll have to add a silly entry to my blog.

 

 

http://www.atariage.com/forums/index.php?a...;showentry=5037

The comments here are getting a little out of control so I'll redirect people to a genuine topic in the programming forum where it might get a little more notice from the coding gurus. Plus, you'll be able to post attachments there.

 

http://www.atariage.com/forums/index.php?showtopic=128139