Jump to content

jum

Members
  • Content Count

    152
  • Joined

  • Last visited

Posts posted by jum


  1. I came across the MCC-216 FPGA-based classic system emulator on the weekend:

     

    http://mcc-home.com/2.html

     

    At $150 it's cheaper than MIST, and supports Amiga, C64, Atari 800 plus one or two others.

     

    Not sure how much effort would be involved in getting the 5200 to run on this (not to mention joystick interfaces etc).

     

    PS: I'm very impressed with the progress you guys have made with the MIST-based 5200 :)


  2. Yesterday I found an Atari 7800 locally, which is very rare in these parts (last and only time I saw a 7800 was in 1993).

     

    It's a PAL version with joypads and a built-in game "Asteroids", which is lucky since there were no 7800 carts included.

     

    post-4417-0-00121000-1414425870_thumb.jpg

     

    post-4417-0-95714000-1414425896_thumb.jpg

     

    PS: I paid about $65 for it. Good condition, everything working.

    • Like 2

  3. I wired up my 5200 controller over the weekend to the de1. Keypad, joystick and buttons are working well.

     

    Now doing some adjustments to the menu to load 16k 1/2 chip and 32k rom images. Then I'll be ready to release de1 version. For other cartridge types I'm hoping we can use/modify the support that Hias is building for the Atari xl core.

     

    It's also running on the mist. On that there will be the option of analog stick+ keyboard or a USB 5200 controller adaptor probably.

     

    Curious... With a real 5200 on Pete's test what are the min/max values for horiz/vert? I'm using 5v for pot common and 66uF capacitance right now - a bit off to the left on the box test. Oh and 1.7k ohm for when/if the stick potentiometer has 0 resistance.

     

    Main reason I ask. I tried missile command - crazy fast movements! Is this playable on a real 5200?

     

    One other question: Most cartridge images are in .bin format, not .car format. Is there a list of which are 1 chip/2 chip etc?

     

    Cartridge images should all be "raw" .bin (or .a52) 8K, 16K or 32K (except Bounty Bob). 8K and 16K carts are mirrored in the 5200 "rom space" (ie: loading a 16K cart will mirror it at 0x4000 and 0x8000). There may be a few exceptions.

     

    From the game code's perspective (value read from POKEY register), it usually expects joystick X/Y values to be in the following range:

    // Note: VSS uses 15/120/220 for LEFT/CENTRE/RIGHT
    #define POT_CENTRE 115
    #define POT_LEFT 15
    #define POT_RIGHT 210
    Exceptions are Missile Command and Pengo. I was not aware of the CONSOL bit 2 setting for Missile Command.
    Pengo seems to need POKEY joystick values in the range 70 to 170.

  4. Mr. Do's Castle doesn't work on Jum52.

    Depending on which version of the ROM you have, you may get as far as seeing the "castle" playfield.

    Maybe if I get some time I will take another look at what the problem is.

    PS: The Atari and Activision games seem to work best on Jum52

    PPS: Make sure you have the latest version of the emulator (from jum.pdroms.de)


  5. I think software emulation of the older systems (8/16 bit) has kind of plateaued. Pretty much all the older 8 and 16 bit game consoles and "personal computers" now have pretty good software emulators.

     

    However it's still "early days" for FPGA emulation of these systems. It's only in the last few years that we've seen FPGA emulators like MiniMig, MIST, FPGA-Arcade and Papilio Arcade appearing (due to the appearance of low-cost FPGA dev boards).

     

    From what I see the FPGA emulation is better than software in some ways because the FPGA recreates the actual circuitry and logic in the emulated system. Also you can "build your own" real (physical) Amiga / C64 / A8 etc.

     

    Right now only the hard-core retro computer / game console / arcade enthusiasts are prepared to pay $200 to $300 for an FPGA emulator, and there are only a few retro systems implemented in FPGA. But in the next few years more retro systems will be implemented, and the price of FPGA hardware should drop (while also getting more capable), so I'm hoping it becomes more mainstream in the next few years.


  6. 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?


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

     

     

     

    hello.zip


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


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

     

     

     


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


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

     

    etc...

     

     

    Thanks for the awesome feedback. Much appreciated. :)

     

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

     

    Cheers - Jum


  12.  

    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

    Jum32_v10_PSP.zip


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

×
×
  • Create New...