Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store

Shannon

Members
 View Profile  See their activity

  • Posts

    8,384

  • Joined

  • Last visited

  • Days Won

    1

 Content Type 

Blog Entries posted by Shannon

  1. Shannon
    Well although I managed to sneak in a few rounds off klax and warlords on my awecades unit despite my lego star wars kick. Seems a new beast is about to garner my attention.
     
    Guitar Hero 2!!
     
    Last time I got hooked on GH I actually got blisters on my fingers.
     
    I figured I'd dust off this old Blog and post it. I originally posted it back in Nov of last year.
     
    My plans at the time were to start working in February on replacing the default Awecades drive with mine own containing mamewah and a ton of emulators. I've managed to do that, but not much more. Except add some mame gameplay videos to be played after 5 seconds of inactivity. It seemed to work pretty well. Obviously February is pretty far off. I think I started fooling around with getting mamewah going around June but issues at work really got in the way.
     
    It's amazing how much time can be wasted trying to build up custom play lists. I'm trying to limit it to stuff I play the most but am always afraid I'll overlook a gem somewhere. Anyways the motherboard that came with my Awecades unit seemed to have trouble with the current versions of MAME and scrolling, as well as running some of the older early 80 games full speed. I did manage to update the screen drivers to get them finally at full speed. Not sure what I did though cause according to windows my screen driver update failed. Plus I had to bump the clock speed on the MB up.
     
    So now I just have to decide whether to replace the motherboard, or just add some type of graphics card in this thing. I'm just thinking of doing the motherboard because I also suspect that the built in sound card is slowing things down as well.
     
    Unfortunately recent unemployment interfered with my plans.
  2. Shannon
    Quick little update.
     
    I got around to compiling the code changes I mentioned earlier (dec 23) and got em working except for the up/down configuration which I'll look at later.
     
    Seems the capslock key is not mapped properly. Not sure how to fix this.
     
    After a bit of tracking I was able to get the capslock situation fixed. Now we can enter lowercase letters! This one took a while cause after spending all my time in the core code trying to get it to work. I eventually discovered the culprit creating problems was in the x-port interface. Typical square hole, round peg situation.
     
    Got the upload/download configuration stuff working. Just waiting for x-port to set up the permissions correctly at the usual place. I'm thinking eventually maybe it would be better to host elsewhere. Got some other stuff in the works but I really dont wanna say anything in case it backfires.
     
    Silly me.. Accidently deleted some of those cheat/rumbles I created earlier in the year. Note to self, must not clear saved data..
     
    Noticed something interesting today. Thanks to a little fluke on my part the old pokey emulation was playing too high. Turns out I didn't have the old STEREO var defined. So basically what was happening was the same thing the new pokey was doing before I fixed it. The old pokey was defaulting to MONO sound, hence the problem. Apparently when the sound is set to MONO how the data is sampled is affected.
  3. Shannon

    Internal overhauls

    By Shannon,

    Never even realized I would be spending so much time with this thing!! What started out as a desire to make a few minor fixes is snowballing into one Giant todo list!
     
    Regardless, it is still fun. Even if I don't half know what I'm doing. It's amazing though all the little quirks and bugs one notices when one has access to the source code. I go to test one thing and notice a small thing here, a small thing there. The record/playback function is one example. First issue is the one I mentioned in the previous log, playbacks would not work cause the random generator was a little too "random".
     
    The record/playback is pretty basic. Doesn't do a whole lot but stuff emulator events in array. Thing is it ignores things not related to stick functions so stuff like keyboard presses are not recording. Not really a problem unless your running 5200 mode which relies on keyboard presses to initiate games, etc. Also no analog movement is recorded either. So my little project started off as an attempt to record the 5200 analog motions.
     
    The code uses DWORDS to store the digital values of all four controllers (no analog). Why Dwords? Well because the system relies on masks to quickly store/read all the controller buttons (see below) Each analog direction takes up a word (-32767 to 32767) so you can fit two directions in each Dword. That would be 6 Dwords for each controller (two analog sticks x/y, and l/r triggers), totalling 24 Dwords. Your basically storing eight times as much data as the normal record mode.
     
    The code currently allocates enough space for 10 minutes of recording so adding just the analog stuff alone would kill it. Not good. Well being the Xbox doesn't have a whole lot of RAM and I have a couple other future things in mind that may be memory consuming I decided to come up with something else. At first I came up with this elaborate scheme for squeezing the analog data within the currently saved Dwords. Turns out after 3 hrs of coding I just didn't have space for the l/r triggers. At this point they are not used but I wanted to have room for them if I use this code in the 2600 emulator. So time for plan B! One thing that came to mind is the Atari really only stores paddle and 5200 stick values in a byte so I figured maybe storing that data would be more efficient. Although such code may not work to well on other x-port emulators if they use more than one byte.
     
    So I ran with that. At 1 byte per value I could store two 5200 analog stick values (x/y) in one Dword. The code scans all 4 ports, so two Dwords for all 4 ports aint bad. That leaves two unused Dwords assuming I'm stealing four at a time. Leaving room for any other junk I decide to store. This time I just hacked the code into the 5200 analog read routines and "stole" Dwords from the normal record/playback code. I also threw the same code in the paddle read section for normal computer paddle reads, although that is a little problematic at the time. Once I got the code working, it worked like a charm! So record time is now only cut in half! I went ahead and doubled the mem used for recording to bump it back up to 10. Which means up to 20 minutes if in 8-bit mode and not using paddles. Gotta be able to create those youtube videos!!
     
    This code will come in handy for other emu's that rely on things like mouse (read analog) movement so when I'm done here I can move it over! Only problem left now is capturing those keypresses! This one was a bit of an issue because the record function did not really store them (even if a controller button was assigned to them). It only stores controller "events" and it creates a conflict when you try to store keypresses in there. It gets keycodes confused with controller events. Funny thing is how it is coded makes sense at first but then not so much sense later.
     
    All of this stuff is controlled by masks. So for example stick events would be mapped to 0x01, 0x02, 0x04, 0x08. The front end is set up so keycodes are prefixed with 0x80000000. So for example 0x80000073 would represent the A5200 start button (which is later translated to 0x29, don't even get me going on that). This would confuse the emulator cause any given keyboard code can be confused with a controller code (AND the keycode with x10 and it thinks the fire button was pressed.)
     
    I got to thinking ascii/atascii values are store in a byte. So why not bump up the controller masks so they start a bit higher (say 0x100, 0x200, 0x400, 0x800). That way you can store their values without the emulator getting confused. Anyways I'm pretty sure it will work and it will also allow multiple controller to be bunched up with at least a single keypress. Had it almost working today but I didn't have time to find the joystick code so I could shift the data back 8 bits and call it a day.
     
    Once I get this done I should be set and the emulator should be able to record analog and keypresses as well. Now if I could only get that paddle playback code working.
  4. Shannon
    Well most of the atarixlbox stuff lately I've been posting over in my testing thread. But this one was worthy of a log.
     
    I'm quite pleased with myself today. A couple of days ago I realized the record/playback function did not work and was a bit baffled as to why. After digging around in the emulator code I managed to fix it! A change I could actually submit to the A800 team, although I doubt they'd really care.
     
    I tell ya. It sure caused some weird behavior when using the rewind function! Certain events that occured alot of times would not happen again, etc. It was one of those things that I noticed, but didn't notice. Things are usually moving so fast it isn't always obvious. I might leave that in the rewind function because I found it easier to recover from ugly situations as a result of this little "quirk".
     
    So I can add that to my list of changes.
     
    Record and Playback now work correctly.
    Added in a "do not allow activating attract mode". Really only useful in demo's.
    Autoselect media defaults to yes if no configuration file exists, so if you go to the "configure computer options" menu it will execute.
     
    I know it isn't really much. But it does mark the first "core" related change I made that could probably be submitted to sourceforge.
  5. Shannon
    After farting around with x-ports "upload game configuration" code I got to thinking it'd be kinda sweet if the user could download controller configs and cheat settings as well. His code doesn't really save the config info which can be pretty useful when you have a bunch of keys mapped to the controller.
     
    Then I got to thinking further. What if I CRC'ed the file and included the CRC as part of the filename and then included a bunch of those files with Atarixlbox in directories (configs, presets, cheats). Then if the program finds a match it can ask the user if he wants to use them. Well assuming I can get the CRC calculation code working.
     
    I would also add and leave in this ability for the upload section. I'm also thinking of moving the up/down configuration into the options menu since it seems to make more sense to have it there.
     
    As for the menu changes I was thinking about.... I'm gonna go ahead and do them since I'm getting no feedback.
  6. Shannon
    Kinda gotten away from updating the blog since I scrapped together a thread for testing atarixlbox. Here are some of the things I was thinking of changing. But really at this point I just wanna try to focus on playing with the emu and not "tweaking" it. Plus I've been fending off a cold recently. Not sure who is going to win, probably the cold but ah well.
     
    I'm thinking of splitting off the "Computer Specific Options" in a seperate menu. See a few posts above where I list the configuration options. One new option not on that list will be to disable the Analog mapping for those few games it aint so great for (mostly a personal preference thing). And I'll probably do the "Disable Attract Mode" feature as well.
     
    Plus, although I'm not a big fan of "autochangin" fields. I was thinking of maybe, for example, if you change the computer to 5200 that it automatically sets the media type to Cartridge, video mode to NTSC. Setting up the autodetect so it does not ask yes/no. Removing the Enable 0xC0000 RAM and Rtime option (Time seems to return the correct date-time even with it off).
     
    Just trying to think of a way to reduce clutter and simplify things a little.
     
    While messing with the up/down configuration I was considering the possibility of having an up/down cheats and up/down controller configuration (for those more complicated games that could use custom mapping). Not sure if x-port would be too thrilled about the extra info on his server though.
  7. Shannon

    feeling lonely

    By Shannon,

    ok well after listening to the numen demo just for kicks I quickly compiled a version of atarixlbox with the new_pokey code from foft, the creator of the GP2x port. It sounded pretty ok so I'm thinking of going with that, thus reducing the number of sound options to pick from. It even manages to make it through Ghostbusters without crashing.
     
    Slapped the player/missile/playfield collision cheats in tonight, hopefully it will compile later without any big isssues. If it works well enough then I will use that as a release candidate for testing. I wanna test one last thing related to the rewind function as well.
  8. Shannon

    go, go go!, no, no, no!

    By Shannon,

    I'm trying to round up some people for testing of this baby, just running into a few snags. But if anyone is interested in kicking some tires just PM me. The big issue is going to be figuring out how to distribute this thing considering it's origins.
     
    In the meantime things will be delayed just a tad. I discovered that the pokey sound code I'm using will lock up rather quickly when music is playing. So I wanna sort that out, at least. Also stubborn 'ol me is kinda hung up on trying to get some decent volume only sound. I have a few potential ideas but I'm not sure which way I wanna go. But I promise I wont delay too long (hopefully just a day or two). I don't wanna get too dragged down in this though cause it is the type of thing that could take a while.
     
    So if a couple quicky things don't work I'll just revert back to a more stable sound core for testing. After that I was just gonna add one feature real quick and it should be good to go for testing!
  9. Shannon

    more!, more!, more!

    By Shannon,

    Well I've pretty much completed upgrading the core to 2.03 with the exception of the sound core (see pokey.c comment below).
     
    Had to back out of the pokey.c update until I can figure out why Beef Drop does not want to work..
     
    I was fooling around and put some quick and dirty code in to support the 5200 analog stick. This does create some other issues (like where to map the numpad keys). The analog stick is only read when in 5200 mode. Centipede plays pretty ok, missile command is near impossible to control (I'm wondering if I can hack in some type of sensitivity setting). The only flaw is that I believe the Xbox analog stick has a dead zone that may interfere just a little.
     
    Put in an option/code to allow swapping of the joystick in port 1 and 2.
     
    Been messing around with the H: driver. Not even sure why I am. Anyways everything seems functional under Dos 2.5 except for the delete file option. All other DOS's seem dysfunctional, but then they do the same thing on the windows/dos release of 2.03.
     
    Pokey_old and Pokey_new code. Currently I'm using the ones that came with A800winplus. I have like three different sound core setups so it's a matter of deciding which one I want. Not sure what to do about the sound cores. I can effectively cut out at least one of the core's. But I'm not sure if there are any differences between any of them with the modifications. Supposedly new_pokey is better (at least at lower frequency rates), but on the xbox we don't really care. 44100 all the way baby!!
     
    Update. Hmmm seems the A800winplus sound cores I put in cause the emulation to lock up after a period of sound playing. I'll probably just back out of that and switch to one of the others. It's possible I foobared something while hacking away at the endless (#ifdef/#endif) combo's though. But I have an idea I wanna try.
     
    Since the black button is not used on the virtual keyboard I went ahead and mapped it to the capslock key.
     
    Changed the palette code again, now using some routines created by Kr0tki.
     
    Reactivated the rewind code. I temporarily disable it while I upgraded the core so I would not have to worry about dealing with it. Rewind is a big memory eater so depending on what skin you are using you might see parts of the interface graphics dissapear. In my case the opening animation I created is a bit of a memory hog, I might have to reduce the number of animation frames on it. The menu graphics come back after exiting a game.
  10. Shannon
    [Colorblind]
     
    I was tinkering around with some code that was posted up on the A800 sourceforge cvs that now provides seperate NTSC and PAL palette support. When I implemented the code (assuming I didn't foobar something) I noticed that the PAL palette's black level seemed kinda off. See below pictures.
     
    Now this guy took pictures. See links below. Now the guy said this..
    But the thing is he said that the picture was taken from an S-video modded Atari. 
    His pictures look closer to NTSC than the ones produced by the new NTSC palette.
     
    Another odd thing is if I apply the default saturation of 100 and color shift of 30 that earlier versions of colours.c would apply to the PAL palette it almost appears to be exactly the same as the NTSC palette.
     
    So I made a post over in the atari 8-bit forum for some input.
     
     
    new NTSC new PAL Svideo PAL
     
    I actually dragged out my 5200 and took a look at a few games and for the most part the new NTSC palette seems ok but unfortunately who knows how bad the tint is off on the tv I was hooked up to. So I'll have to try it on a couple other TV's.
     
    [3 steps forward, 1 step back]
    While working on my little "project" it's amazing how much progress can be made but then some little "quirk" pops up. Well seems the 5200 version of Beef Drop doesn't respond to the Start, *, and # keys anymore although other 5200 titles seem unaffected.
     
    It's pretty funny digging thru code trying to figure something out only to find out it was right in front of you. For some reason I could not figure out how X-port's code was producing sound. He pretty much cleaned out the sound.c code. Well seems he moved it somewhere else. Doh!
     
    I was able to port the sound code from the gp2x version. He had taken the mzpokeysnd code and converted it to int based. Plus modified it so it used the VOL_ONLY sound from pokeysnd. This speeded up it's performance and allowed it to at least get some digital sound (berzerk sounds ok, ghostbuster a little scratchy). I had to modify some code to account for differences in Visual Studio and C++ and it's possible I foobared something without realizing it (hey but it works!). If anything this would allow me to remove the old pokey from use.
     
    I got some other sound related stuff going on so I'll have to see what kind of results I get from that. Probably nothing since my experience in this area is like NULL. But hey it's worth a shot.
     
    Just realized that the code changes I made to SIO.c to only do four drives can probably be switched back to 8 since the code automagically ignores "empty" drives anyways. Same thing with the disk rotate option.
     
    Apparently the front end does not "unload" a cartridge when switching games thus creating weird behavior. (like atari basic being unusable). Fixed that.
     
    X-port set up an A800 directory for configuration uploads so I'll start upping stuff there once I know the conguration file is stable.
     
    I noticed while perusing thru the aplus directory that they added cheats in with the ability to disable player/missile/playfield collision detection. So I may consider slipping that into Atari800xl.
  11. Shannon

    Morph mania

    By Shannon,

    Well I've been wanting to change the default menu graphics for atarixlbox for ages. Although I do not exactly have the graphic skills. I was actually hoping to find someone with graphic talent to do the work for me. So I dug in and messed around a little.
     
    This is an idea of what I was envisioning for the opening graphic displayed, as well as the sound that would be played. Hmm seems that startup sounds is NOT a feature of x-port emu's. Maybe later I will change that, but for now I'll have to dump the startup sound idea for now.
     
    Note I did not edit the sound file so there is a delay, and a little bit of sound at the end.
    Animation was created with WinMorph.
     
    The other thing I would like to do is have some type of music file that plays various tunes from different atari games, modernized, and in a tracker style format (musically).
     
    Click on the picture to see the animation.
  12. Shannon
    Figured out why the fast forward stopped working. Also found what I think to be a bug in the 2.03 code. Seems they moved alot of loop code that was in main.c over into atari.c. Problem is the loop that worked by default in main.c don't work so well in a called function. So I modified it and finally got it working.
  13. Shannon

    atarixlbox core update

    By Shannon,

    Well seems like an all-in-one core update is a little bit beyond me. Although I was able to resolve all errors the emu would just lock up on load of a game. It's no fun flying blind. I did learn alot though.
     
    So I decided to go with baby steps until I have a better understanding. It's a little more work in the long run but they've moved so much stuff around since 103 that its harder to catch things. So far I have found several items that would not have caught my attention in the first attempt. At one point the emu was running twice as slow (double sync commands) and echoing sound. So if things go well I should be able to get it all updated fairly quickly.
     
    Oh and fast forward seems to be not working at the moment.
     
    I just love talking to myself. I figure I'm ok as long as I don't talk back.
  14. Shannon

    Christmas mayhem

    By Shannon,

    Well I had some major plans for the atarixlbox code Christmas week but as usual succumbed to the Christmas madness. So maybe once I recover from it I'll be able to do what I originally planned. Have not had much time to play with anything I got. Spent most of my time unpacking all the junk I lugged up north for the visit to the family. Although I did get to see a little of the Zack and Wicki game as my son was playing it today.
  15. Shannon

    atarixlbox

    By Shannon,

    I've been kinda pre-occupied with Christmas and things like Rock Band. So work has been kinda slow.
     
    I'm being kinda lazy with the updates lately but here is what I've done. Have not tested any of these yet, just edited the code. I decided I just wanted to enjoy the changes I've made so far without getting caught up with compiling, tweaking, compiling, editing, test, tweak some more.
     
    Fixed up the controller save code in the "game options" screen. Oopsy.
    Fixed up the code that copies the preset controller .ini files from the emulator directory to the save code. Oopsy.
    Put in some code that I think will fix up the change directory problem I was having.
    Display disks in drives shows drives 1-4 and I added a rotate disks options. I had to modify sio.c to deal with this. But because the way they have the emu coded, changing MAX_DRIVES does not do the trick.
     
    Added in some of the extra functionality in winuaex to the virtual keyboard. Can't seem to dig up the doc on these but essentially you get the following functionality. White button toggles shift key. Y button toggles ctrl key. Start presses enter and back backspaces. Cursor can be moved with the analog stick.
     
    I'm gonna add in the ability to up/down configuration files. For some reason I thought I already did, but apparently not.
     
    I wanna beef up the load state functionality (in order to get around the samba/relax issue). This would include the need to add in return code for the unzip procedure, plus have loadsavestate try alternatives if the unzip fails and display a dialog with the error or an option to select the correct disk. May be a while though, feeling lazy.
  16. Shannon
    Created some cheat codes and rumble settings for a few atari games in Atarixlbox.
     
    Gyruss - Unlimited live for both players. Double shots for both players.
    Donkey Kong - Unlimited live for both players. Controller rumbles when kong stomps on the ground.
    Pacman - Unlimited lives for both players. Controller rumbles when pac dies or eats a ghost.
     
    Ms. Pacman - Unlimited lives for both players. Ms Pac seems to have a couple "quirks". One it only seems to use one byte to store lives. It assumes that both players have the same number of lives. Hence if player one gets an extra player, two gets one as well. Odd. Plus the byte used to store the level does not correspond with the fruit value. So when the game hits the baby pack levels the fruit value never increasess. In fact the fruit is not random like in the arcade.
     
    Wasted several hours farting around with the sound core from different versions of Atari800 and even Aplus but the same sound quirks seem to be there. Not really sure why. So I may have to re-enable the option to pick old pokey when playing games like Berzerk for the speech.
     
    Still not quite sure if those NTSC colors are right. Guess I'll have to drag out my 130xe sometime.
     
    Things I wanna do.. Enable configuration uploads. I want to add support for up to four drives, should be easy. Rotate disks option. I cannot seem to find the keyboard transparency option anywhere. Did I forget where it is, or is it disabled?
     
    Rewind is temporarily disabled. I'll have to try it in the release version to see if it even worked.
     
    Oh and seems my understanding of how some of the 5200 controller buttons are mapped was incorrect. It's only noticeable with Parker Brothers Games. "F" acts as START, not "4" and the right arrow key acts as "*". I guess I better double check the other keys like "#" etc. I'm thinking of mapping "Warm Reboot" to one of controller buttons.
  17. Shannon

    Atarixlbox Changes

    By Shannon,

    It's funny how minor little typo's can affect how code runs. Especially something like a semicolon which was totally messing up my loadstate code.
     
    Herein lies a list of the changes I made (that I remember). I reversed the order so the sequence they were completed is bottom up.
     
    Informational:
    Current code base is 1.3.2 with a few things upped to 1.3.5. Don't expect any miracle updates anytime soon.
     
    Todo:
     
    Fix cartridge select code so it is more flexible for future cartridge type additions.
    Set it up so if you load a game from the "favorites" menu that the "change a disk" option takes you to same directory that game is located in. (Temporarily put on hold due to some issues it causes).
     
    Changelog:
     
    Load save state now works like it is supposed to, even when restoring from a zipped file. The only exception is Samba/Relax drives. X-port's code copies them to the x: drive and in some cases renames them. Savestates only store the destination filename thus making it difficult to guess the original filename. I'll have to think about this one for a while. Look at it this way. The savestates for multi-disk games never worked right to begin with.
     
    Plugged in code to "autodetect" the media type. Stole it from the Atari800 2.0.0. code. It works great!!
     
    I added an option to the "Game Options" menu to display what files are "loaded" in the disk drives so I have a better idea of what is going on.
     
    Copied over the Preset controller stuff into the "Game Options" menu. Tested and working. The cartridge select code now filters out or in 5200 carts depending on machine type. Took a while to figure that one out. It's amazing how much trouble one little line can cause.
     
    Still working on getting proper disk to load when a savestate is loaded, almost there. But this one has me baffled as to why it is not working. Unfortunately a few "assumptions" have to be made. Like all mounted disks if they were unzipped came from originating game zip and not elsewhere. Seems another issue is relax and samba files are renamed and copied to the X: drive hence making the information saved by the savestate useless.
     
    Temporarily commented out some savestate code I thought that was not being used, only to find out it is part of the "rewind" function. I'll look at it more closely later.
     
    Fixed up the problem created from using multiple files in a .zip. This error also occured when "changing disks". Removed all the configure game code that does not need to execute when changing disks and changed it so the emulator keeps all of the save/config/key stuff underneath the originating (read boot) disks name. Keep in mind that if you play any game that "saves" to a floppy, that disk has to be a seperate UNZIPPED file.
     
    Well I modified the savestate so it saves the SIO and Cartridge state. Although I'm not really sure what advantage this provides. Other then possibly rescuing me from the multi-files in a .zip problem the code seems to have. Yup. Apparently selecting a disk from a multi-file zip creates all kinds of havok with the game in question being played (Imagine removing the floppy disk while playing a game). As well as dumping a bunch of files in the "E:\\saves\atarixlbox\ directory. I'm currently working around this "issue" but it also seems to affect the C64 emulator (ViceX) as well.
     
    Apparently the front end did not "unload" a disc from the drive when switching games thus creating weird behavior. Fixed that.
     
    Hacked in the ability to pick a file from within a zip file when selecting a game. That way multi-disk games can be zipped now. I stole the code from the ViceX emulator whom's code seemed the same (unlike Winuaex which seems like a beast in of itself). Need to add this feature to WinstonX sometime in the future.
     
    In the user preset controls I currently only save Emulator Definitions and Joypad Mappings. Autofire Config, Combo Config, and Rumble Config seem to be the type of things that would be game specific so I don't save those. Not sure what to do about analog stick and analog button sensitivity (anyone use these?)
     
    Added in three user definable preset controls. They are Atari Joystick (stick based games, space, enter, and esc mapped), Atari Keyboard (assigns the d-pad to the arrow keys), and Atari 5200 stick (for 5200 specific set-up). This is in the "Game Configuration" screen and will be eventually added to the "Game Options" menu. Filenames are "Atari 5200 Stick.ini", "Atari Joystick.ini", and "Atari Keyboard.ini" and are stored in the default saves diretory.
     
    Changed the "Game Configuration" menu so that when computer 5200 type is picked the menu options pertaining to "other" modes are not listed. This includes the Video Type "NTSC/PAL" option since there is no such thing as a PAL 5200.
     
    Modified the button definitions to include "5200 specific" options, as well as removing unneeded stuff like "F1-F10". Tried to keep them lined up as to be least likely to create "issues" with older ".key" saves. Things less likely to be used (like mouse buttons) I pushed towards the end.
     
    Added a pregenerated pallette for NTSC that is supposedly more accurate. (genpal -colshift 30 -colors 80) See this msg topic. Not sure how accurate this is, I really need to dig out my 130xe. Here is an image.

     
    Fixed the option for setting artifacting mode. Turned out to be a typo.
     
    Fixed the screen shot save function. Turned out to be a typo. Here is a before and an after.
    .
     
    Removed the option to use old pokey since new pokey is so much better. Old config files will still load and the pokey automatically defaults to NEW.
     
    Fixed the sound. Oddly enough the fix was changing the number of simulated pokeys to 2. Don't have a clue as to why this fixed the issue. Only that it does nothing on the DOS version which does have messed up sound that was not fixed until 1.3.5. Must be an xbox thing. Weird.
  18. Shannon

    Atari 8-bit emulation

    By Shannon,

    Well seems I somehow got myself involved with modifying the recently released x-port source code for the Atari800 emulator. This runs on the xbox for those who are not in the know. Being that the Atari 8-bit computers were like my first love (PC wise). I've always had a fondness for the machine and emulation thereof. My first computer was an Atari 400 with 8k. I remember one of my first programming endeavors was to get a 16k Basic game to run in 8k and alter it for 2 players (the game was Goldrush).
     
    Anyways, long story short. I managed to fix three things that really bothered me about the emu. 1. The sound was off. 2. The colors in save screenshot were way off. 3. Artifact select mode was acting funky. There were other things that I did that I may post in here. Now before anyone begins even thinking it. I have absolutely no C++ skills so I'm kinda learning this stuff as I go. I can make basic fundamental changes, and probably upgrade the core versions, but that's about it. The above changes luckily happened to be just a weird fluke and two typo's in the source code.
     
    So why am I posting this? Well because I'm not really getting any feedback over at xbox-scene and I figured if I'm not getting any responses I might as well stick my blatherings in my blog where they wont get buried underneath ten million other unread forum msgs.
     
    Meanwhile my poor Awecades machine goes neglected. I really need to either replace the MB or add RAM and maybe a new graphics card.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...