+SpiceWare Posted September 28, 2011 Author Share Posted September 28, 2011 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 Quote Link to comment Share on other sites More sharing options...
disjaukifa Posted September 28, 2011 Share Posted September 28, 2011 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted September 28, 2011 Author Share Posted September 28, 2011 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. Quote Link to comment Share on other sites More sharing options...
disjaukifa Posted September 28, 2011 Share Posted September 28, 2011 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 . . . . Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted September 28, 2011 Share Posted September 28, 2011 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. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted September 28, 2011 Author Share Posted September 28, 2011 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. Quote Link to comment Share on other sites More sharing options...
disjaukifa Posted September 28, 2011 Share Posted September 28, 2011 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 . . . Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted September 28, 2011 Author Share Posted September 28, 2011 (edited) 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 Quote Link to comment Share on other sites More sharing options...
raindog Posted September 28, 2011 Share Posted September 28, 2011 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. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted September 28, 2011 Share Posted September 28, 2011 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. Quote Link to comment Share on other sites More sharing options...
disjaukifa Posted September 28, 2011 Share Posted September 28, 2011 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 ) Quote Link to comment Share on other sites More sharing options...
Cebus Capucinis Posted September 28, 2011 Share Posted September 28, 2011 Ma'am bug? NO MAAM! Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted September 29, 2011 Author Share Posted September 29, 2011 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. Quote Link to comment Share on other sites More sharing options...
disjaukifa Posted September 29, 2011 Share Posted September 29, 2011 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. Quote Link to comment Share on other sites More sharing options...
Mr SQL Posted September 29, 2011 Share Posted September 29, 2011 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?? Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted September 29, 2011 Share Posted September 29, 2011 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. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted September 29, 2011 Author Share Posted September 29, 2011 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 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted September 29, 2011 Author Share Posted September 29, 2011 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; } Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted September 29, 2011 Share Posted September 29, 2011 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. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted September 29, 2011 Author Share Posted September 29, 2011 (edited) Probably, but we might have to wait a while - he still hasn't replied to a DPC+DA1 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. 1 the variation of DPC+ that supports digital audio. Edited September 29, 2011 by SpiceWare Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted September 29, 2011 Share Posted September 29, 2011 Ah! OK. Let me know the LPC chip number in the Harmony and I'll take a look later. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted September 29, 2011 Author Share Posted September 29, 2011 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. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted September 29, 2011 Share Posted September 29, 2011 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. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted September 29, 2011 Share Posted September 29, 2011 Try this :- Define the following :- #define MAMCR *(volatile unsigned char*)0xE01FC000 To enable MAM1 :- MAMCR=1; to enable MAM2 again :- MAMCR=2; Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted September 29, 2011 Author Share Posted September 29, 2011 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.