21 replies to this topic

[eshu]

I'll clean up the code and post it tomorrow hopefully...

This is untested on real hardware - hopefully it will work ok...

Screenshot with phospher effect enabled in stella:

Attached Files

•  slideshow.bin   29K   83 downloads

[SeaGtGruff]

eshu, on Wed May 11, 2011 8:55 PM, said:

I'll clean up the code and post it tomorrow hopefully...

This is untested on real hardware - hopefully it will work ok...

Screenshot with phospher effect enabled in stella:

slideshow.bin.png

Very cool how you use the missiles and ball to fill in the gaps!

Michael

Edited by SeaGtGruff, Wed May 11, 2011 9:17 PM.

[RevEng]

Wow - nice job, eshu!

[Zach]

Very cool. The power of DPC+ is becoming more apparent.

Unfortunately only the first image appears on my hardware. Hopefully it won't be hard to fix.

[ScumSoft]

Very nice! Hopefully you can adapt this kernal for games and slap it into batari basic

[eshu]

Thanks for the kind words everyone...

Zach, on Wed May 11, 2011 10:04 PM, said:

Unfortunately only the first image appears on my hardware. Hopefully it won't be hard to fix.

Thanks a lot for testing this - The kernel seems to be working fine which is the tricky bit, but it looks like there must be a problem with the routine copying in the new bitmap - I'm at work at the moment, but will have a look when I get home. Also spotted a bad frame in there - I think I forgot to reposition everything for the first frame....

[SpiceWare]

Impressive!

[SeaGtGruff]

One thing that confused me is that the BIN is only 29K, and I thought it was supposed to be 32K after you add the ARM code to the front of it?

Michael

[SpiceWare]

Stella treats 29K BINs as DPC+ because it doesn't actually use the 3K of code to implement it. That's left over from when we first implemented DPC+ support in Stella.

[dwane413]

After I added the DPC+.arm part to the beginning of the file, it works fine on my Harmony cart.

Great program. I hope some day instructions will be made available on how to add our on pics to this, but either way it is still very cool.

[eshu]

I found and fixed a couple of small issues, and cleaned up the source a little.

I've added DPC+.arm to the start of the file - I hope I got it right. The command line in dos, in case anyone wants it is:
copy /b "dpc+.arm"+input.bin output.bin

Zach if you could test it again I would be very grateful.

Dwane - I only really meant it as a little tech demo, I could probably make a windows based tool available quite easily if you could run that?

Attached Files

•  slideshow.zip   27.25K   49 downloads
•  slideshow32k.bin   32K   56 downloads

[dwane413]

eshu, on Thu May 12, 2011 7:28 PM, said:

Dwane - I only really meant it as a little tech demo, I could probably make a windows based tool available quite easily if you could run that?

Yes, I use Windows, but don't go to too much trouble just for me.

[SeaGtGruff]

eshu, on Thu May 12, 2011 7:28 PM, said:

I've added DPC+.arm to the start of the file - I hope I got it right. The command line in dos, in case anyone wants it is:
copy /b "dpc+.arm"+input.bin output.bin

If you're programming in assembly, you can also stick it on the front end of your program with an INCBIN statement, so that it will be automatically included when you assemble your code.

Michael

[Zach]

eshu, on Thu May 12, 2011 7:28 PM, said:

I found and fixed a couple of small issues, and cleaned up the source a little.

The flicker is a bit strong, but it works on my hardware now.

Funny that the first build worked for dwane413's Harmony but not mine. Something similar happened when I was testing 21 Blue. There may be a particular issue with my SD card or my Harmony. I'll try a different card and if that doesn't help I'll PM batari.

(Yes, I had added dpc+.arm)

Edited by Zach, Thu May 12, 2011 10:24 PM.

[dwane413]

Zach, on Thu May 12, 2011 10:23 PM, said:

Funny that the first build worked for dwane413's Harmony but not mine. Something similar happened when I was testing 21 Blue. There may be a particular issue with my SD card or my Harmony. I'll try a different card and if that doesn't help I'll PM batari.

(Yes, I had added dpc+.arm)

I just checked and the first build won't work on my Harmony either when using the dpc+.arm that is timestamped May 2nd, 2010. After the first picture fades out, the screen stays black. The dpc+.arm files with timestamps May 10, 2011 and May 11, 2011 both work.

So it was probably just that we were using different versions of dpc+.arm.

[ScumSoft]

Looking at the source just add the following at the end of the file to pad the rom out to 32K if you want:

Padding ds ($1400 -*)

I like what you've done
Use bank 6 as screen ram and set the data fetchers to access a 2760 byte ScreenBuffer from it. Then you'll have a nice(er) bitmap engine far better than what I've come up with

[edit]Almost forgot, I've compiled it here on this end with no issues and it runs on the Harmony cart just fine. Just use the latest DPC+.arm file which fixes the oddity that DataFetchers have on the real thing.

INCBIN "DPC+.arm" works just fine as well.

Edited by ScumSoft, Fri May 13, 2011 1:16 AM.

[SeaGtGruff]

ScumSoft, on Fri May 13, 2011 1:11 AM, said:

Looking at the source just add the following at the end of the file to pad the rom out to 32K if you want:

Padding ds ($1400 -*)

But would it be better to pad it at the beginning instead of at the end? (Since DPC+.arm is at the beginning of the ROM instead of at the end.)

Michael

[ScumSoft]

Considering there aren't any more ORG addresses to fill in the remaining bytes, I use it at the end to pad out the unused bytes of Bank 6 and fill in the rest of the rom. This of course isn't representing an end all solution to rom padding, but it works and you don't have to keep adjusting your sizes as you use more of bank 6.

[eshu]

I went back to the drawing board, and provided everything works on real hardware I can manage at least 136x192 if not 144x192 - will post something up soon....

[ScumSoft]

Make it so.

[SpiceWare]

SeaGtGruff, on Thu May 12, 2011 9:38 PM, said:

If you're programming in assembly, you can also stick it on the front end of your program with an INCBIN statement, so that it will be automatically included when you assemble your code.

Michael

How did I miss this before? Thanks, much nicer than the 2-step compile/merge I'd been doing.

[SeaGtGruff]

SpiceWare, on Sun May 20, 2012 1:37 PM, said:

SeaGtGruff, on Thu May 12, 2011 9:38 PM, said:

If you're programming in assembly, you can also stick it on the front end of your program with an INCBIN statement, so that it will be automatically included when you assemble your code.

Michael

How did I miss this before? Thanks, much nicer than the 2-step compile/merge I'd been doing.

DASM has a lot of useful features that I've barely learned about yet, but I did learn about INCBIN several years ago when I did my first MNetwork-bankswitched ROMs. At that time I didn't know you could use ORG and RORG to define multiple banks that occupy the same memory area, so I would code and assemble each bank as a separate ROM file, then create another file that used INCBIN to assemble all the separate banks into the final ROM. D'oh! That was before I joined AtariAge. After joining AtariAge it didn't take very long before I found out how to use RORG to do bankswitched ROMs.

But I did use INCBIN later on in the "E.T. Book Cart." I had all the text for the cartridge in separate text files, formatted for the desired characters-per-line and lines-per-screen. Then I wrote a short FreeBASIC program to take those text files (one per "chapter") and split them into two files per "page"-- one file for the even frame, and the other file for the odd frame. I also compressed the text a little bit by using some control characters (end of line, end of page, horizontal tab, and vertical tab). Then I saved all those separate text files and used INCBIN to load them at the appropriate spots in the ROM.