jum

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

If I see another I will notify you

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. PS: I paid about $65 for it. Good condition, everything working.

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.

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)

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.

OK so I was missing something. True, emulators are not perfect for final dev. @groovybee: By open source I mean the ability to build a multicart (in the same way that Arduino is open source). Not a deal-breaker, just a bonus.

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?

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

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.

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

Thanks Chris - looks interesting. I used cc65 for some Lynx homebrew projects, will give you some feedback if I get a chance to mess with a 5200 project (maybe make a simple 5200 lib?)

Very original and fun game, can't believe I never played it before! (Tested in Jum52 emulator). Great work dudes!

Wow! Great gfx, musics and playability Had to tear myself away and save state on level 3. Came across it while trying to get another homebrew ("100 pictures") to run in Jum52. Glad that Thetris runs fine in Jum52.

http://kidsquid.99k.org/compilers/5200bas/5200bas.html

Maybe someone could port 5200basic to work with Lynx. I think 5200basic uses DASM assembler which could probably be configured for Lynx. 5200basic is pretty low-level though, but is pretty fast.

I used 5200Basic to write JUMPONG, a simple PONG clone for 5200 that comes with Jum52 Atari 200 emulator. The source code "JUMPONG.BAS" is included in the emulator zip file, which you can download here: http://jum.pdroms.de/emulators/emu5200.html - jum

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.

I have released Jum52 Atari 5200 emulator v1.1 for PSP, Win32 and Ubuntu. You can get it at http://jum.pdroms.de (5200 section). It runs at full speed (thanks to frameskip). - jum

Seems the non-working Activision games mentioned in post above were due to "bad" roms. Here's a small update to the download above (fixes bug with 2nd fire button). Beta release to follow (soonish). - jum jum52_PSP_update.zip

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

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