Jump to content

RevEng

Members
  • Content Count

    6,771
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by RevEng

  1. Here's my 2 cents... lilmissit.bas lilmissit.bas.bin ...better make that my 2 k's. It took a *lot* of rework to collapse this puppy into 2k. There's nothing terribly inefficient about the original source, but the bB multisprite kernel has a lot of functionality packed into it to use it in a 2k game. A multisprite bin with nothing more than a looping drawscreen takes up ~1160 bytes! I avoided any changes to the bB kernel, as I felt that would have cheated the spirit of the thing. I was sorely tempted to try to rework the playfield drawing routines to try and squeeze the storage used for that... so many precious bytes to draw a box!!! But in the end I was able to make it work without cheating. Techniques used: I simplified the direction/bounce code by using directional xy vectors for each object, instead of the existing single vector. This traded-off ram for code. For similar objects, I looped through arrays and called common functions. I grouped together variable assignments of the same value and put them on single line with the : operator. This removes redundant register=constant assignments in the assembly code. I used shared sprite data. The last thing I did was to play with the positioning of routines around the shared sprite data, to minimize the wasted padding due to the sprite data's location requirements. If anybody wants to add something, you have at least 54 bytes of rom free. If anybody spots any bugs, fix 'em yourself... after all this code bumming I'm sick of looking at it.
  2. RevEng

    Tetris

    I believe he means what happens in "official" 2-player tetris, not his program. But AFAIK there is no official 2 player tetris. Some clones have the game end when one of the players lose, other have you play it out. One feature some have, which you may choose to copy, is if you get a tetris it causes your opponent to have his stack move up and random blocks inserted on the bottom rows.
  3. For sure. I'm just looking to achieve the same functionality. I don't care if it looks different.
  4. Keep holding up or keep holding down. It cycles through the numbers. Admittedly the UI could be improved - I was just going for a quick proof of concept. It will likely be more friendly if you shorten the jdelay=60 assignments to 20 or 30, and also add in a line that sets jdelay=0 if there's no joystick input.
  5. It's no more complicated for 4k bB binaries than it is for other 4k binaries. For a proof-of-concept, here is the beginnings of a simple bank-switching menu program written in bB. I decided to jump to the reset vector rather than jump to $1000 as I mentioned earlier - in case the two differed in bB and it had some special reset-cleanup. Not sure if this is the best approach or not, but it works. If you want to use this with other non-bB bins, then you might care to change the last $FC and $FF bytes to $00 and $10. binary... gameselect.bas.bin source files... gameselect.bas score_graphics.asm.txt To build your own menu, compile gameselect.bas, then concatenate 3 files onto gameselect.bas.bin. In linux/cygwin/MacOS/*BSD use "cat file1.bin file2.bin file3.bin >> gameselect.bas.bin". In DOS/Windows-CMD I believe something like the following should work "copy /b gameselect.bas.bin+file1.bin+file2.bin+file3.bin full_gameselect.bas.bin" It would be fairly simple to embellish this program to include unique player/playfield graphics for each game selected. I leave this as an exercise to the reader. Feel free to take this program and use it as your own.
  6. BTW, there's no need for the games to share pfres or even a common kernel. Just compile the menu and each game as a 4k bin. Then just stick them all together. Your menu program will setup a ram-based bank-switch and jump to $1000. Each game is then it's own entity, and you can dim/pfres/kernel-hack each one individually.
  7. Actually, I think it would look pretty cool if you could figure out a way to do the whole thing and re-decal it. If you take a second whack at it, I'd suggest you use "vinyl dye". It's used frequently by the case-modding community for this kind of project, hardly adds any thickness (can be used for mated parts), and actually bonds with the plastic. You can pick it up at any auto store.
  8. RevEng

    Playaround Demo

    A checksum routine is pretty easy to defang. I've done it myself, and I'm no great shakes at assembly. So I thought there might be an alternate reason. This checksum causes a blank screen and bad rolling if it fails. I just thought it might be a way to flag a partial bad burn that might otherwise have subtle effects, saving the programmer from tearing his hair out over a bug that isn't there. ...But if it's known for sure that the purpose of the checksum is anti-tamper, then nevermind.
  9. RevEng

    Playaround Demo

    Maybe they had a cheap eprom programmer that didn't verify the eproms.
  10. Unfortunately this isn't the case. Looking at the generated assembly, it does a bankswitch to the first bank even in the first bank. My original "benchmark" timing of 160 cycles was with the addition happening in the first bank, and it drops to 106 cycles if I change to a 4k bin. (this is all running on stella, BTW. Not sure if a bankswitch to an existing bank would be any faster on real hardware) The other odd thing, is 8.8=4.4+8.8 doesn't call the library routines, and 8.8=8.8+4.4 does, which is odd because it's just an operator switch. It seems in the former case bB treats the 4.4 as a regular byte instead of a 4.4... .L09; dim a_fp44 = a.a .L010; dim b_fp44 = b.b .L011; dim c_fp44 = c.c . .L012; dim a_fp88 = a.d .L013; dim b_fp88 = b.e .L014; dim c_fp88 = c.f .L015; a_fp88 = 123.123 LDX #31 STX d LDA #123 STA a_fp88 .L016; b_fp88 = 123.123 LDX #31 STX e LDA #123 STA b_fp88 .L017; c_fp88 = 123.123 LDX #31 STX f LDA #123 STA c_fp88 .main ; main .L018; c_fp88 = b_fp44 + a_fp88 LDA b_fp44 CLC ADC a_fp88 STA c_fp88 .L019; c_fp88 = a_fp88 + b_fp44 LDY b_fp44 LDX d LDA a_fp88 sta temp7 lda #>(ret_point1-1) pha lda #<(ret_point1-1) pha lda #>(Add44to88-1) pha lda #<(Add44to88-1) ; ...etc
  11. Ok, I tried 8.8=8.8+4.4 in a 4k bin, and it takes 106.6 cycles (+-4.2 cycles). Unless I'm doing something horribly wrong, I think I'll keep my FPs in 8.8 to avoid it entirely.
  12. Thanks for the clarification! I didn't realize some of that behind-the-scenes bankswitching was going on. As you surmised, I did do this in a bankswitched bin. I think that was serendipitous, as I haven't seen some of these penalties hightlighted before. (though likely it's somewhere buried deep in this forum's archives!) Unfortunately, I'm not able to fit my current project into 4k, and it's fairly fixed-point heavy. I just tried a test program that stuck some fixed-point math in the last bank, and it seems to hit the same penalty. Is bB doing the bankswitch even when the fixed-point-using-code is in the last bank?
  13. You're welcome. Glad it was useful!
  14. I was curious to see how many cycles certain operations took in bB, so I ran a bunch of loop for each operation and subtracted from the cyclecount. (also subtracting the loop overhead) The result was fairly educational. I anticipated many of the results, but perhaps not to the magnitude I discovered. It's certainly helped me in my game tuning, so hopefully someone else finds use for it. No doubt some assembly coders are going to suggest that I could have just added up cycles in the assembly. That get's pretty hairy when you're going though long branching code, and this method IMO was good enough to get a good idea of what the piggie operations are. The results... a=b+c : 11.5 cycles (+-1.3 cycles) a=b/3 : 460.8 cycles (+-12.8 cycles) a=b/2 : 7.68 cycles (+-1.3 cycles) * a.a=b.b+c.c : 11.52 cycles (+-1.3 cycles) a.d=b.b+c.c : 11.52 cycles (+-1.3 cycles) a.d=b.b+c.f : 11.52 cycles (+-1.3 cycles) a.d=b.e+c.c : 160.0 cycles (+-6.4 cycles) ** a.d=b.e+c.f : 20.48 cycles (+-1.3 cycles) gosub+return : 25.6 cycles (+-1.3 cycles) gosub_with_bankswitch+return : 123.73 cycles (+-4.2 cycles) goto: 2.56 cycles (+-1.28) *** goto_with_bankswitch : 49.06 cycles (+-4.2) -------------------------------------------------- * = x/2 is a lot less than x/3 because bB uses a rotate-rights for divisions by powers of 2. ** = this one is weird. If you add an 8.8 type and a 4.4 type, it's *way* slow if the 8.8 is first. *** = bB implements this with a jmp, which is 3 cycles. This one was a check of my methods. Note 1: a,b,c=byte a.a,b.b,c.c=bB 4.4 fp type a.d,b.e,c.f=bB 8.8 fp type Note 2: an empty-loop in the bB standard kernel has about ~2432 spare cycles. (~3432 if you count vblank area) an empty-loop in the bB multi-sprite kernel has about ~2176 spare cycles. (not much more in the vblank)
  15. For sure! I realize the components in a heavy are better quality, and usually the video as a result. I'm hoping to snag a Longhorn AV mod to improve the video. (not a lot of luck getting a hold of him) Despite the title of this topic, I don't have illusions that whatever I do will *really* turn a heavy into a light. I'd just like to do what I can to make this light the best it can be. I do think you're right about going heavier. I recall switching carts one-handed was a bit of an art back in the day.
  16. Sweet! Thanks for the info! Amazing how much diffence that extra 1.1 pound makes! Washers is a good idea, and any break-free events are likely to be noticed before they become damaging... Time for a trip to the hardware store.
  17. Bahahahahahahahahahahahahaha! [wipes tear]
  18. I'd be adding enough weight to make it the same as a heavy-six... I only recall mine from youth, so I'm not sure about the exact weight. If I buy a heavy-sixer, it will be an Atari one. I know the Sears is the *exact* same thing, but I want the console of my childhood, irrational though it may seem.
  19. Heh, life is full of co-incidences! I was talking to Atari, and it thinks your brother is lame! Seriously, from his comments it sounds like your brother is the kind of guy who would turn his nose up at D&D, Sudoku, strategic board games, and various other alternative gaming experiences, in favour of the latest generic-but-pretty first person shooter. Don't get frustrated or angry with people that shut themselves off from life's experiences through elitism; the attitude is its own punishment. Learn from his mistakes, and be sure to never turn your nose up at someone else's hobby.
  20. BigO: Where's the sport in that? Buying a heavy-sixer is probably in my future, but at heart I'm a tinkerer and I'll enjoy the light->heavy project. tremoloman2006: A most excellent suggestion! I think I'll do just that. Now to find some bar steel...
  21. RevEng

    Tetris

    If you're looking for some cycles, either tune the worst offending routines or throw them in the vblank. (Provided they're less than 1000 cycles) The latter is the easiest, the former takes some art. In a worst case scenario in which you could do neither, you could probably make a 2 player version by doing the work for player1 during odd frames and handle player2 during even ones.
  22. So you're saying batari shouldn't have broached the subject of pre-orders, since it wasn't in the original topic? I think it was a natural evolution, given that lots of people have asked about it. Normally I'd be firmly in your camp and very cautious with my money. However, batari has given a lot to this community without asking for anything, which has given him a lot of credibility and trustworthiness in my eyes. I'd be willing to put some cash to the cause if and when he feels confident enough to take preorders. I'd be glad to feel I was helping out in the development in some small way. I also trust that he'd return any money he collected if he couldn't follow-through for some reason. I'm also comfortable of my pre-order going toward something with ballpark pricing. It's not something new - gamestop takes pre-orders all the time without guaranteeing a final priceing.
  23. I'm totally looking forward to the day when I can own a Harmony, but your pre-order plan sounds a bit counter-intuitive - People willing to plunk down their cash early have to wait longer to get one? Am I not understanding correctly? or maybe you have some reason for doing this that escapes me? I'd be totally willing to pay a pre-order for the higher priced unit. IMO that would be a win-win, allowing me to secure a high position in the queue. I'm sure I'm not alone in this either. ...just my 2 cents, in advance of a pre-order.
×
×
  • Create New...