Frantic (2600)

[+SpiceWare]

• Frenzy variation playable
  
• Hitting GAME SELECT will bypass the end-of-game score screen
  
• door routines revamped, if you die the room's entry door will reopen
  
• for testing purposes, the room number shows during the room-shift sequence
  

 

 

ROM (Stella instructions in 1st post)

frantic_harmony_20110927.bin

[disjaukifa]

Trying it now!

 

WOW!!!! Frenzy is . . . WOW simply insane. Ok now for my scientific observations without emotional comments:

 

1st - I think the addition of the room you just cleared is cleaver and useful.

2nd - I'm able to go to multiple rooms without any issues

3rd - You should congratulate yourself on the technical achievement for the number of enemy sprites you are rendering on the screen at once in Frenzy, how you are keeping it at 262 scan lines is remarkable.

4th - The idea of the door re-opening is a neat feature that many including myself would have never thought of.

 

Honestly, I'm stunned Spiceware, I don't know what else I can say. I would actually like it if the room number stayed, it would be a neat way to keep track of the number of rooms you have cleared in the game, unless that is not how the numbering worked, I need to look at it more in depth to be certain.

 

I'll continue playing with this build and let you know what I find. I hate to admit this but this game is making Berzerk boring and my own homebrew seem . . . well unworthy.

 

I still can not get over the number of enemy sprites you are generating on the screen . . . thats just astonishing.

 

Actually I one minor suggestion. When the enemy robots shot their lasers up or down, the beam moves at half speed compared to the horizontal, shouldn't the diagonal laser beam be the same way, you get to a point were the diagonal just murders you in Frenzy.

Edited September 28, 2011 by disjaukifa

[+SpiceWare]

1 - don't know if I'll leave it. It's a quick and dirty hack, which is why it's displayed in hexadecimal.

2 - cool, though I did have a couple crashes later last night Spending a few hours at a time rearranging code in hopes the crashing stops has become very aggravating - enough so that Frantic and Chun-Li are now in jeopardy of being cancelled.

3 - higher levels with lots of moving robots cause screen jitter/roll. That's why I added the room number, so I could narrow down when it happens and see if my revisions to speed up the code help.

4 - arcade versions do this. However, they also reposition you to the left side of the screen which I'm not doing.

 

The shots should be the same speed - they might appear different due to the aspect ratio of the pixels, but that impacts the movement speed of the humanoid and robot as well.

[disjaukifa]

1 - don't know if I'll leave it. It's a quick and dirty hack, which is why it's displayed in hexadecimal.

2 - cool, though I did have a couple crashes later last night Spending a few hours at a time rearranging code in hopes the crashing stops has become very aggravating - enough so that Frantic and Chun-Li are now in jeopardy of being cancelled.

3 - higher levels with lots of moving robots cause screen jitter/roll. That's why I added the room number, so I could narrow down when it happens and see if my revisions to speed up the code help.

4 - arcade versions do this. However, they also reposition you to the left side of the screen which I'm not doing.

 

The shots should be the same speed - they might appear different due to the aspect ratio of the pixels, but that impacts the movement speed of the humanoid and robot as well.

 

!!! Can you expand on that statement. Hoping I'm not understanding you correctly here . . . .

[GroovyBee]

2 - cool, though I did have a couple crashes later last night Spending a few hours at a time rearranging code in hopes the crashing stops has become very aggravating - enough so that Frantic and Chun-Li are now in jeopardy of being cancelled.

 

How about automating the process? If you mark the start and end of each function with a known sequence you could write a PERL script (or C/C++/Python/whatever) that parses your main.c file and finds the start and end line of each function. It could then copy the main.c file verbatim to maintest.c (for example) until it finds the first marker. Then it would randomly select function blocks and append them to maintest.c until the list has been exhausted. You could then build that file and try it out on the hardware.

 

3 - higher levels with lots of moving robots cause screen jitter/roll. That's why I added the room number, so I could narrow down when it happens and see if my revisions to speed up the code help.

 

I can see quite a few places where you could optimise the code to be more GCC/ARM7 friendly. However, this is best done towards the end of the project.

[+SpiceWare]

The testing on the consoles is what takes the longest amount of time, not rearranging the order of the functions. And even then, after getting a version that works on all of my consoles it often crashes for disjaukifa and KevinMos3.

 

The problem's caused by a bug in the ARM chip, I covered it before.

[disjaukifa]

Just FYI, I have no problem doing acceptance testing, I'm an automated tester by profession, so I'm use to testing and trying to find bugs . . . just usually not for games, but I think I'm getting better.

 

That is annoying that they don't have a more detailed explanation of what is causing this issue . . .

[+SpiceWare]

The problem is it seems like I'm spending as much time rearranging code to avoid the ARM bug as I do working on the game. And even after spending hours to get something to run on my 3 systems, it appears to be a coin-toss as to whether or not it'll work for you or KM3.

 

It's an exercise in frustration - I do these games for fun and if I'm not having fun, well...

Edited September 28, 2011 by SpiceWare

[raindog]

This strikes me as pretty much a fatal bug as far as any kind of non-trivial Harmony-based games go, yeah. You've been putting more effort into working around it than I think most hobbyist coders would.

 

Incredible work, whether or not you end up considering it complete.

[GroovyBee]

The testing on the consoles is what takes the longest amount of time, not rearranging the order of the functions. And even then, after getting a version that works on all of my consoles it often crashes for disjaukifa and KevinMos3.

 

The problem's caused by a bug in the ARM chip, I covered it before.

 

Its been a while since I used the LPCs and I never had a problem with MAM. However, it seems that the MAM bug is affected by temperature and clock speed from the research I've done. If you can't change MAM mode, clock speed or execute from RAM you'll need to ensure 100% ARM/THUMB code coverage in your testing (not easily achievable ). Maybe if you give your Harmony a blast with a hair drier while playing it might throw up more problems with your set up.

[disjaukifa]

The problem is it seems like I'm spending as much time rearranging code to avoid the ARM bug as I do working on the game. And even after spending hours to get something to run on my 3 systems, it appears to be a coin-toss as to whether or not it'll work for you or KM3.

 

It's an exercise in frustration - I do these games for fun and if I'm not having fun, well...

 

How much is left before you consider this game done? I know its be tedious and not fun which really sucks, but this game is awesome! I mean it awesome, as in probably going to be the best game ever release for the 2600 awesome (well at least in my humble opinion )

[Cebus Capucinis]

Ma'am bug? NO MAAM!

[+SpiceWare]

However, it seems that the MAM bug is affected by temperature and clock speed from the research I've done.

I've experienced this - have had instances where code worked fine in the evening on a "warm" Harmony, but not the next day when it was "cold".

 

If you can't change MAM mode, clock speed or execute from RAM you'll need to ensure 100% ARM/THUMB code coverage in your testing (not easily achievable ).

I'm not familiar with using the ARM - can MAM mode be toggled on the fly? Maybe I could turn it to 1 at the start of my custom code, and turn it back to 2 when it's done so the DPC+ stuff runs correctly. If toggling it is possible, I suspect the digitized samples would have to go (removing the IRQ overhead for the digitized samples might also offset the performance hit for using MAM 1 mode). While the samples are neat, I'm willing to drop them if needed (and voice would still be available via the AtariVox).

 

If it can't be toggled on the fly, perhaps batari could revise the DPC+ driver to work with MAM1. He created a test version a while back, but it didn't work correctly on my 7800. He might be able to work around that, I don't know.

 

How much is left before you consider this game done?

Probably 2-3 months, and I'm not going to be aggravated that long.

[disjaukifa]

However, it seems that the MAM bug is affected by temperature and clock speed from the research I've done.

I've experienced this - have had instances where code worked fine in the evening on a "warm" Harmony, but not the next day when it was "cold".

 

If you can't change MAM mode, clock speed or execute from RAM you'll need to ensure 100% ARM/THUMB code coverage in your testing (not easily achievable ).

I'm not familiar with using the ARM - can MAM mode be toggled on the fly? Maybe I could turn it to 1 at the start of my custom code, and turn it back to 2 when it's done so the DPC+ stuff runs correctly. If toggling it is possible, I suspect the digitized samples would have to go (removing the IRQ overhead for the digitized samples might also offset the performance hit for using MAM 1 mode). While the samples are neat, I'm willing to drop them if needed (and voice would still be available via the AtariVox).

 

If it can't be toggled on the fly, perhaps batari could revise the DPC+ driver to work with MAM1. He created a test version a while back, but it didn't work correctly on my 7800. He might be able to work around that, I don't know.

 

How much is left before you consider this game done?

Probably 2-3 months, and I'm not going to be aggravated that long.

 

Hey Spiceware, I was doing some googling and it looks like you can toggle MAM on the fly, I'd be fine with getting rid of the digitized samples if it meant simpler programming on your part and just using an Atari Vox.

 

Like you said, this is suppose to be fun and currently it sounds like a royal pain which is unfortunate. I'll see what else I can find out about MAM and Arm.

[Mr SQL]

Fantastic game SpiceWare! It feels like Bezerk for the Intellivision. How did you get a stock 2600 to output digitized sound? Is the Harmony carts chip emulating a voice expansion module/DA converter??

[GroovyBee]

I'm not familiar with using the ARM - can MAM mode be toggled on the fly?

 

Yep! You can change MAM mode on the fly. However, you might also need to drop the core CPU frequency at the same time.

[+SpiceWare]

Fantastic game SpiceWare! It feels like Bezerk for the Intellivision.

Thanks.

 

How did you get a stock 2600 to output digitized sound? Is the Harmony carts chip emulating a voice expansion module/DA converter??

It's done by changing the volume on just about every scan line. The Harmony makes it easier to do, but it's not necessary - digitized sound was done on the Atari on 2 games back in 83:

 

Quadrun

http://www.youtube.com/watch?v=5Mbrolb4fpg

 

Open Sesame (seconds 2-4, it's a bit hard to understand)

http://www.youtube.com/watch?v=UEAE4s2NH-E

[+SpiceWare]

I'm not familiar with using the ARM - can MAM mode be toggled on the fly?

 

Yep! You can change MAM mode on the fly. However, you might also need to drop the core CPU frequency at the same time.

Any idea how to do this? I assume it'd take some ARM assembly that I'd drop into the C code like this:

 

unsigned int BitReversal(unsigned int value)
{
// original C method
// value = ((0xaa & value) >> 1) | ((0x55 & value) << 1);
// value = ((0xcc & value) >> 2) | ((0x33 & value) << 2);
// value = ((0xf0 & value) >> 4) | ((0x0f & value) << 4);
// return value;

// alternate C method, uses same amount of ROM as original
// return (((value * 0x0802LU & 0x22110LU) | (value * 0x8020LU & 0x88440LU)) * 0x10101LU << 8 ) >> 24;

// inline assembly method, takes 16 bytes less ROM space
  asm volatile(
"lsr %0,%0,#1\n\t"
"adc r0,r0,r0\n\t"
"lsr %0,%0,#1\n\t"
"adc r0,r0,r0\n\t"
"lsr %0,%0,#1\n\t"
"adc r0,r0,r0\n\t"
"lsr %0,%0,#1\n\t"
"adc r0,r0,r0\n\t"
"lsr %0,%0,#1\n\t"
"adc r0,r0,r0\n\t"
"lsr %0,%0,#1\n\t"
"adc r0,r0,r0\n\t"
"lsr %0,%0,#1\n\t"
"adc r0,r0,r0\n\t"
"lsl r0,r0,#25\n\t"
"lsr r0,r0,#24\n\t"
"orr %0,%0,r0\n\t"
: "=r" (value) : "0" (value)
: "r0", "cc"
);
  return value;
}  

[GroovyBee]

Any idea how to do this? I assume it'd take some ARM assembly that I'd drop into the C code like this:

 

Its probably something that batari should do in the DPC+ ARM "driver" before your code is called.

[+SpiceWare]

Probably, but we might have to wait a while - he still hasn't replied to a DPC+DA¹ request from August 19th that I need so I can submit the patches for Stella to support it. The current build has the wrong "id strings" in it. I also seem to recall there isn't much space left in the 3K DPC+ code, so he might not even have space to change the MAM setting.

 

¹ the variation of DPC+ that supports digital audio.

Edited September 29, 2011 by SpiceWare

[GroovyBee]

Ah! OK. Let me know the LPC chip number in the Harmony and I'll take a look later.

[+SpiceWare]

I believe it's the LPC2103. Looks like there's 2 variations(different packaging) I don't know which one is used in the Harmony.

[GroovyBee]

I believe it's the LPC2103. Looks like there's 2 variations(different packaging) I don't know which one is used in the Harmony.

 

Doesn't matter about the physical package because all I need is the datasheet for the LPC family.

[GroovyBee]

Try this :-

 

Define the following :-

 

#define MAMCR *(volatile unsigned char*)0xE01FC000

 

To enable MAM1 :-

 

MAMCR=1;

 

to enable MAM2 again :-

 

MAMCR=2;

[+SpiceWare]

Thanks - Dropped it in and Frantic now jitters during the speech due to timing, so it appears to be working as things should take longer to run and the ARM speech routine is triggered during VBwait when INTIM = 7 (5-6 scan lines before it starts to draw the game display). Of course we'll need some good testing to make sure it works as the crashes seem to be hit-or-miss.

 

frantic_harmony_20110929_MAM1.bin

 

Chun-Li crashed on the 7800, though we did have issues with MAM1 on the 7800 before. If that can't be resolved then the games might have to be 2600 only.

 

If testing of the above ROM pans out, I'll start removing the speech support and shift some routines from Overscan to Vertical Blank. That'll buy back a lot of space which would be handy for things like espire8's up/down humanoid animation sequence. I'll also be able to set up for 2 concurrent sound effects instead of just 1.

Edited September 29, 2011 by SpiceWare