Frantic (2600)

[disjaukifa]

I'll test it tonight when I get home Spiceware and let you know what I see. Hopefully this will relieve your frustrations with this game development.

[+SpiceWare]

played a bit during lunch and had a crash on the 2600

[GroovyBee]

Just looking at your sample_expand routine in main.c you could nearly quadruple the throughput if you used 32 bit words and not bytes. The caveats being that both source and destination buffers must be aligned on a 4 byte boundary. It would then become something like (not tested) :-

 

void sample_expand(unsigned char* destination, unsigned char* source, int count)
{
unsigned long int *pDest=(unsigned long int*)destination;
unsigned long int *pSrc=(unsigned long int*)source;
int i=count>>2 ; // +1 (to round up if required).

for ( ;i--; )
  	 {
	const unsigned long int data=*pSrc++;
	*pDest++=data>>4;
	*pDest++=data;		// Could bitwise and with 0x0F0F0F0F if really needed.
	}
}

 

Obviously you'd need to pack the samples differently in your WAV to TIA converter.

[GroovyBee]

played a bit during lunch and had a crash on the 2600

 

Is your ARM code now taking too long at the reduced speed (due to MAM1 enabled)? If you don't get back in time to take the NOP off the data bus and do a jmp XXXX (if that's how it works) the 6507 will wrap around and start pulling instructions from the read registers of TIA.

[+SpiceWare]

Yep, that's how it works, I have the 6507 towards the beginning of the 4K cartridge space when it makes the ARM calls. That might be the issue as I was testing the Frenzy variation with more robots on screen.

[+SpiceWare]

played a bit during lunch and had a crash on the 2600

Looks like it was this bug - but for the Frenzy variation. Frenzy's right wall is 1 PF to the right from the Berzerk layout, so the shots can travel 4 pixels farther. Testing and will upload a new ROM in a bit if it pans out.

[+SpiceWare]

Quite a few changes for this build.

• fixed the shoot-off-screen bug for Frenzy variation
  
• digitized sound disabled. I tried to make it work, but had garbled screens and other odd results. I suspect the IRQ routine to update the audio when the ARM code was running didn't like being in MAM1 mode.
  
• I removed the 6 scan lines of padding between the bottom of the room and the score-lives/bonus display. This time was given to Over Scan to help compensate for the slower CPU (setting MAM to 1 disables part of the cache which makes the CPU run faster).
  

frantic_harmony_20110929_MAM1_b.bin

 

If crashes have cleared up then the following's going to happen:

• digitized audio will be removed (an AtariVox will be required to hear speech).
  
• the space used by the playback buffer will be used to convert a bunch of variables from 1 byte to 4 bytes(8 to 32 bit). As I understand it, the ARM runs much better with 32 bit values, so by changing variables that are used a lot (spriteX, spriteY, etc) to 32 bit I might be able to offset the performance hit from using MAM1 mode.
  
• I'll update the sound routines to use both channels so we can have 2 concurrent sound effects instead of 1 (the other channel was tied up with the digitized audio).
  
• I'll have space for new animation sequences from espire8
  

 

 

Note: you will most likely encounter screen jitter with this build. That's a non-issue, so no need to report it.

Edited September 30, 2011 by SpiceWare

[disjaukifa]

Hey Spiceware

 

Just tested that build, I have NO screen jitter, and I was able to navigate multiple rooms without any issues. I think toggling the MAM was the answer, I'm fine with needing an AtariVox to hear the sounds, that doesn't bother me at all. Just want to let you know I was successful with both of my machines that this usually crashes on which I think you will be happy to hear

 

Also looking forward to seeing the animation included in the builds as well

 

-Disjaukifa

Edited September 30, 2011 by disjaukifa

[GroovyBee]

digitized sound disabled. I tried to make it work, but had garbled screens and other odd results. I suspect the IRQ routine to update the audio when the ARM code was running didn't like being in MAM1 mode.

 

Did you try the quad byte audio processing code above?

 

the space used by the playback buffer will be used to convert a bunch of variables from 1 byte to 4 bytes(8 to 32 bit). As I understand it, the ARM runs much better with 32 bit values, so by changing variables that are used a lot (spriteX, spriteY, etc) to 32 bit I might be able to offset the performance hit from using MAM1 mode.

 

ARM7 (v4 architecture) is equally at home loading/storing 8, 16 and 32 byte values. Its the integer promotion rules in C/C++ that add extra left and right shifts by 24. If you moved over to ARM/THUMB assembly language you'd probably save quite a bit of space.

[+SpiceWare]

you've not gone far enough if you're not seeing any jitter. Set CONTINUE and LIVES = 5. If you die, then exit thru the "newly opened" door to advance to the next level, and use continue at the end of each game. By the time you get to room 10 (really 16) the screen will be jittering a lot.

 

Did not try the quad byte routine, changing to that would not help with the garbled screens, just with jitter.

 

I suppose that would be an option, just didn't start this as a project to learn ARM assembly.

[+Nathan Strum]

• I'll have space for new animation sequences from espire8
  

Nice. That front-facing run cycle is especially sweet. Very clever use of pixels, and a really good-looking end result.

[KevinMos3]

I just played the frantic_harmony_20110927.bin and the frantic_harmony_20110929_MAM1_b.bin on my Jr. Both of them played fine with no crashes as of yet. I played up to about room 1A. I haven't played either of them on my heavy sixer or 7800 yet. The enemies look fantastic and the Frenzy enemies look better than either the arcade or coleco. I can't think of any other game where the 2600 version looks better than the arcade. o.O

 

Sorry to hear that you may have to remove the digitized voice, since we've been waiting for so long for more AtariVoxes and may never see more, (here's to hoping). Although, those animations you posted do look darn good.

 

BTW, I finally played the arcade version of Frenzy the other night. Personally, I like the coleco version way better than the arcade simply because of the tunes. If anyone hasn't played the coleco Frenzy, they really owe it to themselves to check it out. Although, I don't suppose you'd have room for both the new animations AND tunes.

 

I hope you do what you need to do to complete the game... I'd hate to see you get frustrated and leave it unfinished. o.O

[GroovyBee]

Did not try the quad byte routine, changing to that would not help with the garbled screens, just with jitter.

 

Are garbled screens the result of MAM1 changes or something else? If its MAM1 is the "init_room" function taking too long?

 

I suppose that would be an option, just didn't start this as a project to learn ARM assembly.

 

Projects evolve However, its fully understandable if you don't want to touch ARM assembler.

[ComputerSpaceFan]

Chun-Li crashed on the 7800

 

..... I wish Chun-li would crash onto me

[+SpiceWare]

There'd probably be room for tunes, but if I'm dropping the samples I'd prefer 2 concurrent sound effects over background music.

 

I'd prefer to leave this project in C and 6507 assembly to make it more accessible to others who might be interested in a Harmony project. I can foresee learning ARM assembly for my next project as it does look intriguing.

[+SpiceWare]

New builds in the blog. Next build posted here will be after I get the performance hit of MAM Mode 1 addressed.

[disjaukifa]

So far so good Spiceware, I haven't seen any crashes yet! I'm really . . . really glad you are not canceling this project!

[SmileyDude]

I suppose that would be an option, just didn't start this as a project to learn ARM assembly.

 

 

As someone who has done both 6502 and ARM assembly, if you can write code for the 2600, you can definitely understand the ARM. It's a very orthogonal instruction set and very easy to get into, very much like the 6502. That shouldn't be too surprising since the ARM's origins are from the old Acorn days where they wanted a RISC CPU to replace the 6502 that they were using at the time.

 

My own recommendations to get around your problems would be as follows. Make sure you are using THUMB code if space is a concern, run out of RAM as much as possible, and try to use 32-bit load/stores if you are writing C code. For assembly, you can use the 8-bit and 16-bit load/stores directly. Theoretically gcc should be able to use the correct versions, but I found that gcc doesn't generate the best ARM code.

 

If you want to stick with C, you might want to try another ARM compiler -- since you are on a Mac, you might have luck with Clang. Apple has spent a lot of time getting Clang to generate optimal ARM code, so it could be worth a look. Once I get a Harmony cart, I'll probably take a look at going down that route myself.

[keilbaca]

Is there a trick to get this to run on the Harmony cart? Because every time I load any build on it, my screen goes blank and nothing shows up.

 

Also, I seem to be having issues with Moonsweeper on the Harmony cart as well....

[+SpiceWare]

Does your Harmony have the Version 1.05 BIOS? That's when support for custom bank switching was added.

[+LS650]

I haven't been able to run previous releases of Frantic, and then saw that I had an old 1.04 BIOS. I've updated my Harmony cart's BIOS to 1.05 and now I can run the frantic_harmony_20110929_MAM1_b build no problem.

 

Wow - very impressive! The graphics are amazingly good. The only suggestion I would make is that the 'death' animation could be a bit more outstanding, perhaps like the flickering man in Berzerk.

[+SpiceWare]

It's interesting that you think I'd ever entertain your input.

[Underball]

It's interesting that you think I'd ever entertain your input.

That's kinda harsh.

[+SpiceWare]

That's funny. PM sent.

[espire8]

I thought the death looked too static at one point, but I also like the way it's set up now too. Makes the death look unique every time, which works well for me. It does use no extra space at all where the images are concerned.

Edited October 15, 2011 by espire8