Anyone think Ballblazer is possible on the 2600?

[GroovyBee]

Or bite the bullet and make it a Melody only title and move over to the dark side of ARM .

[Keatah]

From what the last few binaries showed, I thought mega-progress has been made. So much has already been done!

[roland p]

Or bite the bullet and make it a Melody only title and move over to the dark side of ARM .

Maybe the easiest option at this moment... Feels like cheating though. No one will blame me probably. Does Stella emulate the ARM?

[GroovyBee]

Maybe the easiest option at this moment... Feels like cheating though. No one will blame me probably. Does Stella emulate the ARM?

 

It does but it isn't current cycle accurate. Have a look at SpiceWare's Space Rocks for the most recent example of it being used.

 

I know it seems like cheating to use CPU assist but it depends how much you want closure on the project. If you are quite happy to "try, get close, rewrite, get closer" for an infinite number of iterations the project can become a magnum opus affair. For some hobby programmers the fact that a project is taking too long can make it little to no fun to work on. With such a high standard set by the game on the A8s and 7800 its a difficult choice between "I know the VCS can do it so I'll keep on going" and "I have a life and I want to work on something else eventually" .

[KevinMos3]

Maybe the easiest option at this moment... Feels like cheating though. No one will blame me probably.

 

As a game player, I certainly wouldn't blame you. You could have a nuclear powered sub in there, and as long as it plays when I plug it into my 2600, I'm happy.

 

Some ppl might say, "but it wouldn't have been possible back in 1980," but I say why not? If they'd been more on the ball, they would have used time machines! They were just lazy. I mean, really... I can think back to 1980, but supposedly they couldn't think forward to 2013??? Orrrr... does it not work that way?

[Thomas Jentzsch]

Having worked on both types of projects now (with and without ARM support), I can say that the experience for me is pretty different. When you switch to ARM, almost everything besides the display kernel can be easier and faster done using ARM code. After you created your (much simpler) kernel(s) almost all other code is done in C. Effectively this means that coding for ARM has very little resemblance to coding for a stock Atari 2600.

 

If the result still feels like a true 2600 game is solely up to.

Edited January 6, 2013 by Thomas Jentzsch

[Joe Musashi]

Or bite the bullet and make it a Melody only title and move over to the dark side of ARM .

 

Yes, a programmers's strength flows from the Melody. But beware of the dark side. ARM, DPC+, more memory; the dark side of the Melody are they. Easily they flow, quick to join you in a project. If once you start down the dark path, forever will it dominate your destiny, consume you it will, as it did Batari's apprentices.

[djmips]

Maybe the easiest option at this moment... Feels like cheating though. No one will blame me probably. Does Stella emulate the ARM?

 

it is cheating. don't give in to the dark side!

Edited January 6, 2013 by djmips

[+stephena]

It does but it isn't current cycle accurate. Have a look at SpiceWare's Space Rocks for the most recent example of it being used.

 

This will be added to Stella eventually. I hope to get a preliminary implementation done sometime in the next 3 months. I've already been talking with the original author of the ARM emulation code, but the problem isn't as easy to solve as it first appears. Even with the current ARM deficiencies in Stella, though, it's still a pretty good development platform, as long as it's accompanied by testing on a Harmony cart. Of course, that's a good idea anyway, even if you're not developing a DPC+ game.

[raindog]

I'd like to see the best possible version that can be done on a ~1MHz 6507 before you resort to using a 70MHz 32-bit chip to match a ~2MHz 6502.

 

But you need to do what makes this fun for you, or you'll burn out.

[roland p]

Having worked on both types of projects now (with and without ARM support), I can say that the experience for me is pretty different. When you switch to ARM, almost everything besides the display kernel can be easier and faster done using ARM code. After you created your (much simpler) kernel(s) almost all other code is done in C.

Do you have some hello-world code?

I now use 32Kb bankswitching + SARA RAM. Could ARM code be easily added to this?

[Thomas Jentzsch]

Do you have some hello-world code?

No, but Darrell Spice (Spiceware) should be able to help you.

 

I now use 32Kb bankswitching + SARA RAM. Could ARM code be easily added to this?

If your own code is well organized it shouldn't be too complicated. But if you want to get the most out of the ARM, you will probably have to rewrite a lot of code and you may have to reorganize your data too.

[roland p]

I'd like to see the best possible version that can be done on a ~1MHz 6507 before you resort to using a 70MHz 32-bit chip to match a ~2MHz 6502.

 

For 'the best possible version' you can check the last binary

The last improvements are the hardest because the codebase gets more complex every time. It sometimes feels like moving an elephant through a small house.

At least the kernel (the part that draws the checkerboard) is more or less set in stone.

 

The ARM code will only be twice as fast as 6502 code?

[Thomas Jentzsch]

The ARM code will only be twice as fast as 6502 code?

Since you can only use the ARM maybe 20% of a frame and the instructions take longer than on the 650x, the overall factor is probably around 5-10.

[roland p]

Since you can only use the ARM maybe 20% of a frame and the instructions take longer than on the 650x, the overall factor is probably around 5-10.

That's probably fast enough. I guess multiplications are a magnitude faster than my square table based approach.

 

I'm just investigating all pro's and cons.

[Thomas Jentzsch]

That's probably fast enough. I guess multiplications are a magnitude faster than my square table based approach.

Depends on the precision you need and how good your code already is.

 

I needed a lot of multiplications for my Elite demo. And there I used some really fast multiplications. So maybe there is some room for optimizations left.

[djmips]

Depends on the precision you need and how good your code already is.

 

I needed a lot of multiplications for my Elite demo. And there I used some really fast multiplications. So maybe there is some room for optimizations left.

 

Thomas, where would be ready to release the Elite demo source code?

[raindog]

For 'the best possible version' you can check the last binary

The last improvements are the hardest because the codebase gets more complex every time. It sometimes feels like moving an elephant through a small house.

At least the kernel (the part that draws the checkerboard) is more or less set in stone.

 

The ARM code will only be twice as fast as 6502 code?

 

No, as Thomas said, it's higher than that. But Ballblazer was on the Atari 400/800/5200, which had a 1.79MHz 6502.

[tschak909]

No, as Thomas said, it's higher than that. But Ballblazer was on the Atari 400/800/5200, which had a 1.79MHz 6502.

 

Yeah, but the 2600 is 1.19mhz, and almost half of the CPU time is spent bit banging the display kernel.

 

-Thom

[+SpiceWare]

Yeah, but the 2600 is 1.19mhz, and almost half of the CPU time is spent bit banging the display kernel.

 

-Thom

 

More than half - most games display about 192 scanlines out of the 262 per frame . That's about 73% spent on the kernel. Medieval Mayhem displays 200 scanlines, which bumps that up to 76%.

[+SpiceWare]

Do you have some hello-world code?

I now use 32Kb bankswitching + SARA RAM. Could ARM code be easily added to this?

 

You get less if you're using DPC+ as there's some overhead for the DPC+ driver. The 32K ROM is broken up like this:

3K - DPC+ driver

24K - 6507 accessible (6 banks)

4K - Display Data (data storage for graphics/etc, contents of which are only accessible to the 6507 via DPC+ data fetchers).

1K - Frequency Data. (can be used to store other ARM accessible data as well)

 

The 8K of RAM is broken up like this:

3K - DPC+ driver (copied over from ROM during boot, run from RAM for speed).

4K - Display Data (copied over from ROM during boot, contents can be changed at run time)

1K - Frequency Data - when using ARM code this changes to just 512 bytes, the later 512 bytes are used for C runtime variables.

 

 

No, but Darrell Spice (Spiceware) should be able to help you.

 

If your own code is well organized it shouldn't be too complicated. But if you want to get the most out of the ARM, you will probably have to rewrite a lot of code and you may have to reorganize your data too.

 

My time's a little constrained, but if roland p's serious about this I'll see what I can do to come up with a "Hello World" this week. One thing that'll most likely change is your sprite data will be flipped, it's stored right-side-up when using DPC+ data fetchers.

Edited January 7, 2013 by SpiceWare

[Thomas Jentzsch]

Thomas, where would be ready to release the Elite demo source code?

Sure, but it is quite a mess sometimes.

Elite_051.zip

[enthusi]

Not that my opinion matters much but once it runs on ARM its not 2600 game/project IMHO.

I cringe whan I read about SRAM and 32 KB ROMS already. The only excuse I accept is BoulderDash

[GroovyBee]

The only excuse I accept is BoulderDash

 

That runs on ARM . The ARM processor feeds the 2600 instructions and handles the bank switching and RAM access. The ARM doesn't assist in any other way so its not like a coprocessor.

[Thomas Jentzsch]

That runs on ARM . The ARM processor feeds the 2600 instructions and handles the bank switching and RAM access. The ARM doesn't assist in any other way so its not like a coprocessor.

No it only handles the bankswitching. It does not feed any instructions or whatsoever.