262 replies to this topic

[batari]

I've decided to post the latest build of bB. It's (very) beta at this stage, but basic elements of a new kernel are in place. This new kernel takes advantage of the advanced hardware available with Harmony/Melody.

http://www.atariage....ith-dpc-kernel/

[Philsan]

10 multicolor sprites+missiles+ball?
Multicolored any resolution asymmetric playfields?
That's not fair!
Every bB game now needs to be enhanced!

If I am not wrong this kernel works with melody boards sold by AtariAge, isn't it?

[abaudrand]

AAARRRRRRGGGHHHH NEED TO REPROGRAM ALL MY GAME !!!! :_D

[Random Terrain]

batari, on Mon Jan 31, 2011 3:39 AM, said:

• Six sprites (one exclusive, five multiplexed, will be increased to 10)
  
• All sprites have twice the vertical resolution as other bB kernels
  
• All sprites can be multicolored
  
• Asymmetric playfield, any resolution
  
• Multicolored playfield
  
• Playfield allows independent resolution control for each 8-pixel column
  
• Both missiles and ball available and may be any height
  
• Each sprite allows its REFPx and NUSIZx set independently
  
• Automatic flickering

Thanks. Now we won't have to move on to other programs like Multimedia Fusion 2 for PC and online games if we want to have more multicolored sprites and a higher resolution playfield. After we get those 10 multicolored sprites, the adventure game I've been wanting to make should look a heck of a lot better than it would have. And it looks like I'll finally be able to make a pinball game.

I was wondering if some people wouldn't accept these games because they might think it's 'cheating' or unnatural, but people have been playing Atari 2600 games with more memory in them for more than 25 years. There should be no problem.

I wonder if any bB users will ever go back to the old ways once they get addicted to this new stuff?

[diogoandrei]

Oh my, this is something! Multisprite, all colored, missiles, ball, independent REFPx and NUSIZx... sweet!

Random Terrain, on Mon Jan 31, 2011 7:51 AM, said:

I was wondering if some people wouldn't accept these games because they might think it's 'cheating' or unnatural, but people have been playing Atari 2600 games with more memory in them for more than 25 years. There should be no problem.

I wonder if any bB users will ever go back to the old ways once they get addicted to this new stuff?

If some may think this is or isn't cheating... well, maybe some do, who knows. I am pretty sure, though, that this will be a ball for those who already love bB!

[RevEng]

Wow!

This is a game changer... literally and figuratively!

[jrok]

Wow, this is very cool! Thank you Fred!

Is there a separate beta thread you want us to post bug reports to, or should we just use the regular pinned thread?

[theloon]

Multi-colored playfield but still one color per row?

Wasn't vertical resolution already big but horizontal width was only 8 pixels wide?

The example doesn't use bank switching.. is that possible with this beta? We should get six 4K banks right?

Are we stuck with a-z for variables with this beta or does superchip still work?

What is this "dim rand1=$DA"? Is it a special DPC+ memory address for a random number generator?

Edited by theloon, Mon Jan 31, 2011 2:01 PM.

[abaudrand]

Beg your pardon, but is 32Ko still the maximum size available for making a game? I didn't install the beta version as I m afraid it will ruin my previous install of Bb.

[batari]

Philsan, on Mon Jan 31, 2011 6:46 AM, said:

If I am not wrong this kernel works with melody boards sold by AtariAge, isn't it?

Yes, it works with Melody boards.

jrok, on Mon Jan 31, 2011 9:42 AM, said:

Wow, this is very cool! Thank you Fred!

Is there a separate beta thread you want us to post bug reports to, or should we just use the regular pinned thread?

Let's not clog up the bug report thread, so post here.

theloon, on Mon Jan 31, 2011 12:52 PM, said:

Multi-colored playfield but still one color per row?

Wasn't vertical resolution already big but horizontal width was only 8 pixels wide?

The example doesn't use bank switching.. is that possible with this beta? We should get six 4K banks right?

Are we stuck with a-z for variables with this beta or does superchip still work?

What is this "dim rand1=$DA"? Is it a special DPC+ memory address for a random number generator?

DPC+ has a 32-bit random number generator by default and doesn't need the "dim rand1" anywhere. If that dim rand1 is still in there, it's because I forgot to take it out.

For now, a-z. Later you will get access to more RAM, indirectly.

abaudrand, on Mon Jan 31, 2011 3:15 PM, said:

Beg your pardon, but is 32Ko still the maximum size available for making a game? I didn't install the beta version as I m afraid it will ruin my previous install of Bb.

Yeah, don't install over your existing bB yet. For now, you have about 26k of space. Later that limit will be removed when I add support for the onboard EEPROM chip in Harmony or one that can be added to Melody (which will add up to 256k.) Note, however, that this extra 256k can only be used for data.

[abaudrand]

Thanks for the quick reply, it will avoid me a blank night. I will slow down my programming to see if I can gradually go on this new promising version.
Regards and great job (once again).

[RevEng]

I took the sample and started working it into a game. It's amazing being able to use single-height players.

I ran into a few issues, which I expect you're already aware of batari...

• It looks like player0colors has some glitching on some lines. I checked it on real hardware as well, with the same results. Its pretty obvious in the attached binary.
  
• The scanline counts are off.

...I'm very excited to see the DPC kernel in development!

 ghosttown.bas.bin   32K   109 downloads

[batari]

The scanline problem will go away as the kernel setup gets translated into ARM code. As for the player 0 color, you had me nervous there, but it looks like it's simple. In DPCplus_kernel.asm:

  lda #<DF0DATA ;73
  STX COLUP0 ; 0

The STX should be STA.

Edited by batari, Mon Jan 31, 2011 9:21 PM.

[RevEng]

Excellent - it's perfectly clean now!

[yuppicide]

Am I allowed to curse here? OH MY FUCKIN GOD!

I wonder how cycles and stuff works in this one? Maybe I can finally get my "Blocked In" game to not have scanline problem.

Edited by yuppicide, Mon Jan 31, 2011 9:52 PM.

[Random Terrain]

yuppicide, on Mon Jan 31, 2011 9:51 PM, said:

Am I allowed to curse here? OH MY FUCKIN GOD!

Nope, that's not allowed, but you can expose yourself.

[SeaGtGruff]

I installed 1.1 beta in a new directory to keep things clean, and ran into "sed not found" when I compiled. I copied sed.exe to the new directory from the previous version, but you might want to include sed.exe in the 1.1 zip.

I'm looking forward to playing with this. Thank you!

Michael

[Byte Knight]

Wow, the mere thought of this is giving me a chubby!

I haven't tried it out yet, so I have a couple of questions:

Does it still have the horizontal scan lines on the playfield?

Can we use the full horizontal resolution of the playfield or is it still limited?

Thanks!

[yuppicide]

I predict RT has a bunch of work ahead.

[RevEng]

Byte Knight, on Mon Jan 31, 2011 10:18 PM, said:

Does it still have the horizontal scan lines on the playfield?

Nope.

Byte Knight, on Mon Jan 31, 2011 10:18 PM, said:

Can we use the full horizontal resolution of the playfield or is it still limited?

Presently its the usual 32 across. batari might surprise me here, but I'm expecting that's the way it will remain. There's just a heck of a lot going on here for a single line kernel.

[Philsan]

I haven't undertood immediately than now players can have single line resolution.
Not only games must be reprogrammed but also graphics must be redesigned.
PAC-MAN-RED!

[batari]

RevEng, on Mon Jan 31, 2011 11:07 PM, said:

Byte Knight, on Mon Jan 31, 2011 10:18 PM, said:

Does it still have the horizontal scan lines on the playfield?

Nope.

Byte Knight, on Mon Jan 31, 2011 10:18 PM, said:

Can we use the full horizontal resolution of the playfield or is it still limited?

Presently its the usual 32 across. batari might surprise me here, but I'm expecting that's the way it will remain. There's just a heck of a lot going on here for a single line kernel.

The first kernel I wrote was full width, but sprite repositioning was too simple and would require around 13 lines between sprites or they would flicker. This kernel only needs around 4 lines but there wasn't enough time for the full playfield. I figured you all would have more use for flicker-free sprites than a 40-wide playfield.

I don't know if this kernel will have "kernel options" as mostly it doesn't need them, but if it ever does, the 40-wide playfield could be added as an option but you'd have to sacrifice the missiles.

[Random Terrain]

After everything gets figured out and the dust settles, will the info about it go in its own section on the bB page or will it need a separate page?

[RevEng]

Minor bug uncovered... the positioning routine seems to be off in 2 places near the right hand side of the screen.

I've attached a modified version of the sample program where its easy to see this... the sample program increments each object's x position, and zeros it when x>152.

 sample.bas.bin   32K   94 downloads
 sample.bas   3.35K   80 downloads

[SeaGtGruff]

Random Terrain, on Tue Feb 1, 2011 9:05 AM, said:

After everything gets figured out and the dust settles, will the info about it go in its own section on the bB page or will it need a separate page?

I would vote for updating the appropriate sections of the current page, rather than creating a separate page-- although you might want to keep a copy of the original current page for people who are still stubbornly using version 1.0! I work in the software industry, and believe me, trying to support multiple versions is a real hassle. You almost *have* to keep supporting the most recent previous version, at least during the period of time when some users are still on the older version. But at some point you have to bite the bullet and drop support of the previous version(s), otherwise you go insane. (I know-- I'm already there! Whee!) For example, no reasonable person should expect you to create separate versions of your bB reference page that are specific to versions 0.1, 0.2, 0.3, 0.35, or 0.99, because (presumably) no one is still using them. On the other hand, it would be cool to have installation files and documentation for all those previous versions, strictly from an archaeological viewpoint.

Michael