jum
-
Posts
173 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by jum
-
-
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 210Exceptions 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 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?
-
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.
-
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.
-
-
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
-
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
-
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
-
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
-
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
-
It would be very cool to have a MOD / chiptune composing tool for the Lynx.
But it would be crucial to have some way to save your data/songs to PC. That would require a "USB-cart" or something.
-
Cool thread. I made a start on "Moon Patrol" (and some other games) for Lynx a few years back:
http://jum.pdroms.de/lynx/lynxprog.html
Unfortunately ran out of motivation or time, or the Lynx CPU was just not powerful enough to do it...
- Jum
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Requesting membership to the 7800 club...
in Atari 7800
Posted · Edited by jum
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.