Bitmap kernel

[SeaGtGruff]

Two can play this "mystery guy" game. Hint: If you do *not* know who this is, you are hereby banished from these forums!

 

Michael

mystery_guy_2.bin

[Wickeycolumbus]

Nolan Bushnell!

[+Random Terrain]

Nolan Bushnell!

That's not Nolan Bushnell. That's Chuck E. Cheese.

[+batari]

Any chance it can display RAM?

Absolutely! However, a 96x192 image takes 2304 bytes, or 2.25K. I think the only existing bankswitching method that could handle it is 4A50. But the Harmony/Melody cart might be able to handle it, too, although it might require a new bankswitching scheme (unless it can emulate a stripped-down version of 4A50 bankswitching).

 

If you change the bitmap to 96x96 (2 lines per pixel), you'd need only 1152 bytes, or 1.125K, which might be doable with E7 bankswitching, although the kernel would need to be revised a bit.

 

Or you could keep the pixels at 1 line per pixel, and change the width and/or height of the bitmap.

 

1024 bytes (1K) is exactly enough for a 64x128 image-- 8 player columns across, or a little bit wider than a standard 6-digit score display, and 2/3 the height of the screen.

 

1024 bytes is also enough for an 80x102 image-- 10 player columns across.

 

Michael

Traditional bankswitching can't directly address 2.25k, but Supercharger can handle this easily.

 

The 4A50 just allows reading and writing to the same logical address in fewer cycles using a method called "magic writes."

 

Harmony/Melody lacks the bus hold circuitry to do magic writes but it may be able to do something close if one wishes to write with the 6507. If you want to write (which could involve a host of graphics functions) using the microcontroler, the Melody/Harmony could outperform 4A50 for this functionality.

Edited August 19, 2009 by batari

[SeaGtGruff]

That's Chuck E. Cheese.

Well, he's certainly hairy enough to be Chuck E. Cheese!

 

Michael

[+thegoldenband]

I'm trying to compile the .bas files in this thread, but every one I've tried has thrown a "Fatal assembly error: Check command line format" when it reaches DASM. Since my own, preexisting bB files are still compiling fine, and no one else in the thread has raised a red flag, I'm wondering if I'm out of date. Have there been any recent changes to bB, or to DASM, that are required by this kernel? I haven't updated my copy of either one in (ahem) close to two years.

[jwierer]

In case anybody else wants to join in the fun, here is a copy of the utility RT has been testing for me. I am going to integrate this into visual bB, but if anybody wants to test it by itself you can give it a try.

 

ImgToCode.zip

 

It's written to the .NET Framework 2.0 so if you're not running XP, Vista, or Win7 you *might* need to install it from here. If you're already using Hack-o-matic 3 or Visual bB then you already have this installed and working.

 

-Jeff

[MausGames]

Thanks jwierer. Is there any way to set your imgtocode program to not automatically analyze a loaded image, or a way to stop the process?

[katchow]

wowee wow! I know what'll I'll be playing w/ when I get home.

[Dan Iacovelli]

the second mystery guy is Nolan "Pong" Bushnell

former head of atari, and in weird Al worlds " the reason Atari Age was invented "

[Dan Iacovelli]

exactly what does the size have to be for images.

I tried to get to get to work and the images in the bin file crashes.(I convert to Bbasic,)

maybe when Iget more time I'll work with other pics.

[+Random Terrain]

exactly what does the size have to be for images.

I tried to get to get to work and the images in the bin file crashes.(I convert to Bbasic,)

maybe when Iget more time I'll work with other pics.

For the Bitmap kernel, it needs to be 96 x 192, but the for the .bas code, it needs to be 32 x 32 since that's a totally different thing.

[jwierer]

Thanks jwierer. Is there any way to set your imgtocode program to not automatically analyze a loaded image, or a way to stop the process?

Yes that is an easy change for me to make. You want to be in control of when code is actually generated correct?

[jwierer]

<!--quoteo(post=1819634:date=Wed Aug 19, 2009 2:40 PM:name=Dan Iacovelli)--><div class='quotetop'>QUOTE (Dan Iacovelli @ Wed Aug 19, 2009 2:40 PM) <a href="index.php?act=findpost&pid=1819634"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->exactly what does the size have to be for images.

I tried to get to get to work and the images in the bin file crashes.(I convert to Bbasic,)

maybe when Iget more time I'll work with other pics.<!--QuoteEnd--></div><!--QuoteEEnd-->

For the Bitmap kernel, it needs to be 96 x 192, but the for the .bas code, it needs to be 32 x 32 since that's a totally different thing.

The other thing to consider is number of frames. The code it outputs won't move around banks so you could produce more data than can fit in a bank.

 

-Jeff

[jwierer]

Thanks jwierer. Is there any way to set your imgtocode program to not automatically analyze a loaded image, or a way to stop the process?

Here's an update. In general this should decode animated gifs faster, especially on modern computers with multiple cores.

ImgtoCode.zip

-Jeff

[MausGames]

Here's an update. In general this should decode animated gifs faster, especially on modern computers with multiple cores.

-Jeff

 

This version closes when I click from playfield to sprite.

 

Here is a 3d fuji i made with it:

fuji3d.bin

Edited August 24, 2009 by MausGames

[jwierer]

Here's an update. In general this should decode animated gifs faster, especially on modern computers with multiple cores.

-Jeff

 

This version closes when I click from playfield to sprite.

 

Here is a 3d fuji i made with it:

fuji3d.bin

Closes? I would say crashes horribly! Sorry about that. This one should work and should be faster for black and white rendered images.

ImgtoCode.zip

-Jeff

Edited August 24, 2009 by jwierer

[jwierer]

This one fixes a few other bugs I found. I also tried to speed it up a bit more. Animated GIFs that are sized to be 32x32 should be pretty quick to render now.

ImgtoCode.zip

-Jeff

[+Random Terrain]

This one fixes a few other bugs I found. I also tried to speed it up a bit more. Animated GIFs that are sized to be 32x32 should be pretty quick to render now.

Thanks.

[+thegoldenband]

I'm still not able to get any of the examples posted in this thread to compile. Any suggestions?

[jwierer]

I'm still not able to get any of the examples posted in this thread to compile. Any suggestions?

It's possible you need one of the various updates that have come out over time. I think there is a roll up of different updates here.

 

-Jeff

[rpgfaker]

Wow oh wow! Wow Micheal this is truely amazing thanks for sharing this! It's just like the GameBoy Camera! I was playing Asteroids Arcade(2600) last night and then fiddled with this..so here's Asteroids titlescreen.

Asteroids title.bas

Asteroids title.bas.bin

[+thegoldenband]

It's possible you need one of the various updates that have come out over time. I think there is a roll up of different updates here.

Thanks so much, that's exactly what I was looking for. I'll give it a whirl.

[+thegoldenband]

It turned out that the problem was something else, namely that the .bas files I was trying to compile weren't in the same directory as bB. In fact, I can't even have them in a subfolder inside the bB folder -- for reasons I don't understand, they absolutely have to be on the top level, or else compilation fails. At least I got it to work!

 

I'd like to add music to my bitmap display:

 

bennu01.bas.bin

 

But it seems as if any additional code would need to be in a separate bank. SeaGtGruff warned that bankswitching wasn't working yet, and indeed, the 8K ROM option messes up the display. I tried forcing all the existing code into one bank or the other, but it didn't seem to work, since the compiler forces the graphics into the last bank. Is there a way to override that?

 

I'm also not 100% sure how I should return to the display code. Should I wrap the whole thing in a routine name, or is there already one that I'm overlooking?

 

EDIT: Also, how many variables are available with this code? I don't really understand what I'm seeing, but it looks like all but one of them are tied up...?

Edited August 31, 2009 by thegoldenband

[jwierer]

It turned out that the problem was something else, namely that the .bas files I was trying to compile weren't in the same directory as bB. In fact, I can't even have them in a subfolder inside the bB folder -- for reasons I don't understand, they absolutely have to be on the top level, or else compilation fails. At least I got it to work!

Not to get off-topic, but it sounds like your environment variables are not setup. The bB readme covers how to set these and if you're using VisualbB there is an option to handle this for you. Also directory names with spaces are problematic. I would recommend keeping bB in root directory with no spaces to rule out those issues.

 

-Jeff

Edited August 31, 2009 by jwierer