Jump to content

jum

Members
  • Posts

    173
  • Joined

  • Last visited

Posts posted by jum

  1. The manual is not finished yet, and I definitely want some proofreading before the cart is published.

     

    I'm willing to proofread the manuals, since I do a bit of proofreading at work.

     

    - Jum

  2. The official Lynx adapter has a 9V / 500mA output, if I remember correctly.

     

    Any AC adapter that has 9V output with at least 500mA should work. 300mA might also work.

     

    You would also have to find the right power connector though (the little plug that plugs into the Lynx power socket).

  3. These are 2 cool little games - I'm impressed!

     

    They are already fun to play, so just need gfx upgraded to full screen, music, ?title screen?, ?animation?, and sound effects.

     

    If you need to, you can make the playfield taller than the Lynx screen, and then scroll up/down a bit if required.

     

    Nice.

     

    - jum

  4. He he he

     

    I'm interested to know if kenfused is modifying jumpong2.bas and recompiling it using 5200Basic, or hacking the binary?

     

    jumpong2 already has a "paddle" mode (use * and # to switch between joystick and paddle), but I never tested it on real hardware.

     

    Anyone interested can study or modify the source code (jumpong2.bas) that's inclluded with Jum52 Version 1.0

     

    - Jum

  5. Great job on the emulator!

     

    I immediately did an "acid test" and loaded up Gyruss and Mr. Do's Castle, and they both worked, which is impressive!

     

    IIIRC, Gorf needs "Pengo mode" analog control. Basically, you adjust the analog range to half or third of what is usually is (so instead of using an analog range of 21 to 222 (or whatever it is), you use a smaller range around the midpoint (eg: 71 to 192 or something similar), thus halving or thirding the sensitivity.

     

    Why these games behave differently I don't know. Perhaps it's because the joystick counters are only being reset every 2nd or third frame or something.

     

    If you need code for "Pengo mode" control or trackball control, I'll be happy to contribute.

     

    - Jum

  6. Jum, it seems that you are about to finisch Chopper X? :)

    1023155[/snapback]

     

    Yes, it has to be finished before the June deadline for the multicart.

     

    But it will be finished way before that, so I can do some fine-tuning/polishing on it to make sure it works 100% slick on a real Lynx.

  7. Progress on Chopper X:

     

    Rebased the code for compiling with "new" cc65 2.11 (big mission, also had to rewrite the audio code), replaced tgi stuff with custom functions, design of stages 2, 3, 4 almost completed.

     

    TODO: flip, pause, escape/quit, etc. Some simple tunes. Polishing and tweaking.

     

    Note: ChopperX is made to run in 64k

     

     

    - jum

  8. My Lynx I has some dead pixels, and the power jack is loose.

     

    Other than that it still works fine after 12/13 years (even after hacking the screen into a slide projector and then reassembling)...

     

    Store in a cool dry place, preferably in a box with those little silica packets.

     

    My favourite games are the simpler ones like Calfornia Games and Klax. There are more impressive games, but I think handhelds are more suited to simpler "pick-up-and-play" games.

  9. Wow, great improvements! The ship controls very nicely. The deformable landscape works really well and is a very cool effect. The anti-aliasing on the ship is a nice touch.

     

    I'm looking forward to seeing this turn into a real game. It's very interesting to be able to follow it's progress.

    977349[/snapback]

     

    Hey thanks :)

     

    Personally I think the ship is a bit "wide", and also I'm unsure about a graphical style / look to use. But I'm not going to get bogged down in graphics.

     

    What's more important is:

    1. Ideas for levels (320 x 512 pixels, made from 16x16 tiles)

    2. Ideas for "enemies" (besides ufo's and gun turrets)

     

    Any suggestions are welcome.

     

    I'll keep updating as I progress...

     

    - jum

     

    PS: yes it's possible to crash into your own particles, especially if you're moving fast and then turn quickly. It's a bug.

  10. see new version at beginning of thread.

     

    sage: I can do assembler if I have to. Please email or post your asm source for putpixel.

     

    thanks.

     

    - jum

     

    ps: I have since done the 32 sprites for the ship rotation (actually, 8 sprites that are flipped horizontally or vertically as needed (thank you Lynx designers :) ).

  11. update: I have now switched to using a 320x512 1 bitplane unpacked sprite for the background, and have made setpixel and getpixel routines that read and write to the sprite.

     

    now busy with creating 32 animation frames for the ship rotation. also need to speed up the setpixel/getpixel routines.

     

    - jum

  12. The channel select switch is for VHF channels 2 and 3 in the US. I don't recall the exact frequencies but you can probably find them in a Google search. If the switch is gone it might default to one of the channels but I'm not sure. You might try to find a switch to put in there just to verify.

     

    OK, I just a Google search myself and it looks like channel 2 is at 55.25MHz and channel 3 is at 61.25MHz. I hope that helps.

     

    Mitch

    963618[/snapback]

     

    Thanks Mitch

     

    It looks like the open switch selects one of the channels. I'll try to retune.

     

    - jum

  13. No I'm not in the good ol' US, but my small LCD TV handles NTSC/PAL/whatever.

     

    I've done a full "program scan" on my TV, and only found the 5200 "signal" at one place in the VHF and UHF bands.

     

    What does the "channel switch" on the back of the 5200 do anyway (ie: which channels/frequencies does it select)?

  14. I'm having another attempt at getting my 2-port 5200 working.

     

    Symptoms: snowy screen at power on, maybe faint vertical bars behind snow.

     

    Also the "channel switch" at the back of the 5200 is missing/removed (switch is "open").

     

    Also I'm powering it thru a 220 to 110 VAC stepdown to the 5200 power brick. My TV is auto PAL/NTSC.

     

    Also I replaced VR1 and VR2 (3905's) because they had been ripped off in transit.

     

    After taking a look at the 5200 Field Service troubleshooting chart, it seems that the problem could be a faulty RF modulator. I check GND on pin 1 and +5V on pin3 and they seem OK (0V and 4.93 V).

     

    If the problem is the RF modulator, then I'd be happy to make a composite video mod.

     

    However, before I go to that trouble, I want to make sure that the video output is the only fault in this machine.

     

    Is there an easy way to tell if there are other faults?

     

    Will tapping into the audio output help me determine if the machine is actually running a game?

     

    Any help appreciated.

     

    Thanks - jum

  15. I used the "setpixel/getpixel on unpacked sprite" in my ChopperX game, for the scrolling terrain (320x50 sprite).

     

    I was trying to avoid losing cycles to large sprites, but on the other hand a 300x300 "virtual background" would suit this game better.

     

    Do you still have the source code to your Tron game?

  16. This may help you (from my Jum52 source code):

     

    for(i = 0; i < 0x4000; i++) mapper = MAPPER_RAM; // RAM

    for(i = 0x4000; i < 0xC000; i++) mapper = MAPPER_ROM; // CART

    for(i = 0xF800; i < 0x10000; i++) mapper = MAPPER_ROM; // BIOS

    for(i = 0xC000; i < 0xC100; i++) mapper = MAPPER_GTIA; // GTIA

    for(i = 0xD400;i < 0xD500; i++) mapper = MAPPER_ANTIC; // ANTIC

    for(i = 0xE800;i < 0xE900; i++) mapper = MAPPER_POKEY; // POKEY

    for(i = 0xEB00;i < 0xEC00; i++) mapper = MAPPER_POKEY; // POKEY (mirror)

     

    - jum

  17. Very nice, keep on going, this could become a really cool game.

     

    You are using a lot of memory with the large buffer, but with this you are saving on screen redraw, which leaves you extra system power to do neat effects with.

     

    You could speed up getpixel and setpixel by using a multiplication table (y*80) instead of the <<6 and <<4 you're using now.

     

    calc_ship_verts could be sped up by not using generic sin and cos tables but premultiplying them to give the right distance from the center of the ship.

     

    I see you are already using mean(?) (point1+point2)/2 values to create extra interpolation points with little calculation cost.  You could also interpolate from the bottom two points to the center of the ship, for a nice spaceship shape.

     

    Programming the Lynx in C looks nice BTW, I've been using ASM, which is fast but cumbersome.

     

    Your game is inspiring to look at.

    960560[/snapback]

     

    Thanks for your input man.

     

    I'm not concentrating on optimising right now (rather get some good gameplay first), but if you would like to write a fast ship-drawing routine in asm, please do, and I will integrate it into the source code.

     

    I can only work out the correct "scaling" of the sin/cos tables once I've figured out whether I need to use 8:8 fixed point or 10:6 or whatever. Also I'm going to cut the sin/cos tables from 256 values to 64 values.

     

    - jum

  18. I need the 160x306 buffer because (like spout), I want to be able to blast the walls/landscape with the thrust blast.

     

    I've locked the framerate to 20fps now. It's maybe a bit sluggish, but at least it doesn't slow down and speed up all the time. I'll post a new version soon.

×
×
  • Create New...