Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by jum

  1. I just dislike the process of: build program, remove SD card, put in adapter, put in PC, browse to SD card folder (if OS can't remember where it was), copy file, say yes, I want to replace the darn thing!, remove SD card, remove from adapter, put in CC3 (or whatever ;) ), lather rinse repeat. ....


    I usually use an emulator for retro-dev (to avoid these issues), or am I missing something here...?


    PS: Definitely interested in getting the GroovyBee multicart (if the price is right); what's the release timeframe? Will it be open-source?

  2. Spent some hours writing a "hello world" for cc65/Atari5200, based on Dan Boris' 52hello.txt ( http://www.atarihq.com/danb/files/52hello.txt ).


    Only problems encountered:

    1. Setting the "CARTYEAR" in atari5200.cfg seemed to have no effect in the binary produced. (Always seemed to have 0x59 in the output binary).

    2. Some expressions did not work (eg: "POKE(0x1200 + i, text1 - 0x20);", which compiles but the output code does not do what you want).


    Attached is the "hello world" source code and binary.





  3. Thanks for the info Paul - very useful :)


    In my (slightly modified) Jum52 debugger, I am getting these values from the above code:

    TRIG0 returns 0 (should be 1 if no button pressed!)

    TRIG1 returns 1 (don't know why it would be different to TRIG0 if neither are pressed, must check Jum52 src code)

    CONSOL returns 0 (CONSOL is write-only in 5200, used to select which controller to read)

    SKSTAT returns 0xC (which means "neither side button of controller 1 or 2 pressed")


    You were right - if I return 0xF for CONSOL it does not crash. Previously I was just returning it's current value (ie: the value that had previously been written to it). But of course games originally written for the 5200 would not be reading CONSOL anyway.


    Jum52 uses a line-based renderer, so the image is never going to display correctly anyway.

  4. Debugging why these .bin don't work in Jum52:


    Cart start address: $94A9

    After a few steps in the debugger we get to $9492, which holds RTS instruction.

    However there is no return address on the stack (we have JMP'ed here, no JSR or PHA yet), so RTS jumps to address $0001 and the program has crashed.


    Am I missing something? Maybe some 6502 trick?


    Is it possible to get source code for one of the pics .bin so I can see what's supposed to be happening?


    (PS: If I skip the RTS in the debugger, then 1 get one or 2 frames of graphics, then the thing crashes again).




  5. My 2c worth, from what I can remember about programming my 5200 emulator:


    IIRC, the 5200 analog positions are read like the old PC joystick - the potentiometer ("pot") in the joystick affects the time it takes for a capacitor to charge or discharge. The "position" of the joystick is proportional to the charge/discharge time measured.


    This timing is all done in the POKEY.

    The programmer writes to POTGO register in POKEY, to reset all the pot counters.

    The program can then check if all counters are "finished" using the ALLPOT register.

    The pot "positions" (X and Y) are then read from the relevant POKEY registers. The software usually expects the values to be in the range 5 to 223 (roughly), with the centre position somewhere in the middle.


    Also, some games "calibrate" the joystick dynamically (probably by keeping track of the max an min positions, and then calculating the centre position as the average of those).


    Some emulators (ie: mine) cheat by making the ALLPOT register read "always finished", thus speeding up emulation a little, but negatively affecting accurate timing in the emulator.


    It's also possible that some programmers bypassed this "standard" way of reading the analog joystick, and implemented some other hack way to gain a few cycles.


    My memory is a bit fuzzy, bit there may also be a "standard" joystick read routine in the 5200 bios.

  6. Ok, now that I've had time to really put it through it's paces, a few thoughts:


    1. it's very crashy. like if you try to load a game it doesn't like, it will crash the PSP entirely.


    2. the exit feature doesn't work. It crashes the PSP (I'm on Custom Firmware 5.50 GEN-D3, by the way).


    3. lots of games that work ok on the windows version don't work here. specifically almost all of the Activision games, with the exception of H.E.R.O which plays pretty well. The ones I was bummed didn't work were Pitfall and Pitfall II. They just either give a black empty screen, or a quick flash of dark gray, and then bounces back to the menu.





    Thanks for the awesome feedback. Much appreciated. :)


    I will look into the issues you mention, and get an improved version out soonest.


    Cheers - Jum


    Audio from SDL in the other atari800 port on the PSP is pretty much crap as well.


    If you want to attach it here, I'd be more than glad to play test or scour over the source code to see if I can find some optimizations for you.


    Here is a test release of Jum52/PSP v1.0 for homebrew PSP's, for anyone who wants to playtest it and give me some feedback.


    It runs on my CFW 3.20 PSP and my CFW 5.00 PSP. H.E.R.O. runs OK, but I haven't tested Moon Patrol.


    - Jum


  8. Nicely done! Your effort is much appreciated.


    I have just tested it on Jum52 emulator (v1.0 and v1.1), seems to work OK although there is some wierdness trying to leave the title screen after picking up the gun and getting into the ship.


    - Jum


    will it have proper native 2nd fire button support, for games like H.E.R.O. and Moon Patrol?



    Yes (I will test HERO and MP to make sure. Note that HERO uses the "side trigger" (3rd fire button) to drop dynamite).


    I have basically finished the PSP port of Jum52. It now runs at full speed (I had to make some blitting optimisations and set PSP CPU speed to 333MHz), even with the "zoomed/stretched" display. Audio is pretty crap, but I'm blaming that on SDL.


    I will upload a link to the emu when the ftp to my website starts working. If you can't wait to try it out, then email me and I'll send it to you (or just attach it here).


    - Jum

  10. I'm busy porting my 5200 emulator ("Jum52") to PSP and Ubuntu.


    The Ubuntu version works fine, but there are some issues with the PSP version's speed and audio (at the moment it tops out at 50 fps, when the emulator should really run at 60fps).


    The PSP version is built in FW 1.50 mode, and runs on my CFW 5.00 PSP. Don't know if it will run on a slim.


    Nevertheless, I should be able to release a PSP version soonish.


    - jum

  11. 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

  12. 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).

  13. 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.




    - jum

  14. 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

  15. 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

  • Create New...