Jump to content

Search the Community

Showing results for tags 'ram'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Atari Systems
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Gaming General
    • Classic Gaming General
    • Classic Computing
    • Modern Gaming
    • Prototypes
    • Arcade and Pinball
    • Emulation
    • Hardware
    • Gaming Publications and Websites
    • International
  • Marketplace
  • Community
  • Game Programming
  • Site
  • Classic Gaming News
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • Atari Lynx 30th Birthday's 30th Birthday Programming Competition Games
  • 3D Printing Club's Chat
  • Drivers' Club's Members' Vehicles
  • Drivers' Club's Drives & Events
  • Drivers' Club's Wrenching
  • Drivers' Club's Found in the Wild
  • Drivers' Club's General Discussion
  • Dirtarians's General Discussion
  • Dirtarians's Members' Rigs
  • Dirtarians's Trail Runs & Reports
  • Dirtarians's Wrenching

Blogs

There are no results to display.

There are no results to display.

Calendars

  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar
  • ZeroPage Homebrew's Schedule

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website


Facebook


Twitter


Instagram


YouTube


eBay


GitHub


Custom Status


Location


Interests


Currently Playing


Playing Next

Found 12 results

  1. Hi everyone. I am hoping someone will recognize the issue I'm having with my Atari 800. I think I've narrowed it down to bad RAM, but before I spend any more money I'd like a second opinion. The machine was given to me by a friend who had had it in storage for many years. The plastic chassis was destroyed and I had to disassemble and rebuild it, but the PCBs are all intact and the machine started and was able to run BASIC and other cartridge-based software perfectly. I was also able to load a game from cassette a couple times, though the belts in the cassette decks I was sent degraded rapidly and that stopped working. I recently bought an SD2SIO, and the machine came with an Indus GT. I set to testing these this week, but I can't get anything to load. The specifics of it are peculiar, though. The SD2SIO is set up to load the menu immediately on startup. When I power on the machine, it hits the SD2SIO, spins for a moment, then loads the menu and shows the files on the card. At that point the machine freezes completely. I have tried every possible input - Ctrl+Arrows in particular - and nothing works. The System Reset button also does nothing, which leads me to suspect the CPU is completely hung. When I first tried this I chalked it up to not knowing how to use the SD2SIO and stowed it for a while. I received a cable for hooking up the Indus GT and tried it out finally. I have several disks that should be bootable - a couple boxed games, some commercial applications and some user-created disks labeled as applications. In all cases, when I start the machine the Indus sets to work reading the disk and, for several of the titles I've tried, succeeds in getting a title screen up, but then either it prints an error message or corrupt graphics, the machine hangs, or the screen becomes garbled. Obviously the disks could all be old and tired, but they appear to have been stored well in their original boxes and sleeves and my gut says it's unlikely that they're all bad. The errors are also 100% reproducible, they always fail in exactly the same way for each program. I have cleaned the heads on the Indus. My hunch is that there's some bad RAM a few kilobytes in - since everything seems to load the application data okay but then fritzes out when trying to load content, I'm guessing there's good RAM where the base program code goes but something's fried up where the bulk data tends to get loaded in. The machine has a 16K stock Atari RAM cart and a 32K third party expansion. I've tried all combinations (just the 16K, just the 32K, and swapping the two) and it just changes the way the errors look. My assumption is that the 16K RAM cart has a bad chip, that the 32K RAM cart is not wired in a way that lets it correctly replace the 16K (hence testing with that doesn't solve it), and that I just need to get a new 16K card and I should be golden. Let me know if you think I'm on the right track. Thank you! Here's some pics. Card layout SD2SIO (just hangs here) What happens when I try to load some of the disks I have What happens when I try to load a couple programs that appear to have error handling Funky RAM addon
  2. Hello everyone, I bought my Atari 400 in February 1983. I thought it had been thrown out many years ago, but I recently found it in my mother's cupboards! I tried powering it up, but it won't work. I tried a known-good 16K RAM card from my old Atari 800 and Star Raiders plays fine. I remember spending every cent on upgrading the RAM from 16K to 48K back in '83, which worked fine up until I last used it, which was probably around 1989/90. The odd thing is that the motherboard needed no mod wires to make it work. I've looked at many threads on here and on other sites and all upgrade kits seem to have needed the 4 mod wires from the RAM connector to the ROM cartridge connector. My board is a 'Mapsoft' one, so I'm wondering if anyone else has seen one, and perhaps they can advise me as to how to go about troubleshooting faults on it. I've socketed every IC, and have replaced all 74LSxxx ICs, followed by the RAM ICs themselves. I substituted the Mostek 4564-20 ones for 4164-15 chips, which I'm told will work. The originals were 200mS, but the new ones are 150mS. All chips replaced are known-good and I've tried more than one of each just in case. I even tried the 4-wire mod in case I was going mad! Any help would be greatly appreciated. I have an oscillocope and a multimeter! Many thanks, Dave.
  3. Hey guys, I am just discovering games such as Bomb Jack http://www.atarimania.com/game-atari-400-800-xl-xe-bomb-jack_20831.html Titles like this make me want to upgrade my 130XE to 320k. I want to put new games like this on an Atari Max cart and play them on my 130XE. Thinking of getting one of these awesome devices: http://atariage.com/forums/topic/232856-ram320xe576-order-thread/ So here is the question. How many games currently available use 256k or 320k of ram? Does someone have a list? I would love to make up a 256/320k game multicart. (after I figure out memory upgrade)
  4. Hello: I got inspired this weekend and implemented a helper macro library to use with CART.MAC that supports overlapping RAM segments. It's rather simple at the moment. I toyed with the idea of making it more comprehensive--allowing for extending and appending segments or multiple super-segments each containing overlapping sub-segments--but my priority right now is finishing Christmas Carol. I'll certainly expand it in the future. It will form part of the upcoming P-Machinery v2.0. Anyway, the library offers the following macros: ;; ======================================================================== ;; RAMSTART Starts RAM segment allocation. ;; RAMEND Ends RAM segment allocation. ;; RAMSEG_START Defines a new RAM segment and opens it for use. ;; RAMSEG_END Closes an open RAM segment. ;; ======================================================================== It works similar to the "ROMSEG" macro in CART.MAC: You call RAMSTART somewhere at the top of your code, to initialize RAM segmentation and mark the beginning of available RAM; and then RAMEND at the end to close any outstanding open segments. In between, you may define as many segments as you like, and each one resets the RAM allocation pointers in CART.MAC to the same base address. RAMSTART also defines a default segment called "Global" that is never overlapped. This allows you to define global variables that will be shared across all your game states, without the threat of accidental overwrite by your other segments. If you don't need this global segment, just ignore it and call RAMSEG_START() to define your own segments. Along with the "RAMSEG.MAC" library, I include a modified "STATS.MAC" library from P-Machinery v1.0 to output useful information regarding your RAM and ROM segment usage. You include this library at the very end of your code--after calling ROMEND. Below is an example usage, taken from Christmas Carol. The game is split into mutually exclusive states, and each one requiring its own set of variables. There are also variables that are shared across all states, so they are perfect candidates for the "Global" segment. Let me know if you have any questions. -dZ. ;;==========================================================================;; ;; Title: Christmas Carol vs. The Ghost Of Christmas Presents ;; ;; By: DZ-Jay ;; ;; Description: An original concept game, built on the P-MACH engine, ;; ;; originally developed to port Pac-Man to the Intellivision. ;; ;; ;; ;; Copyright 2010-2012, James Pujals (DZ-Jay), <[email protected]>. ;; ;;==========================================================================;; ;; ===================================================== ;; ROM HEADER SET-UP ;; ===================================================== INCLUDE "cart.mac" INCLUDE "macro/ramseg.mac" ROMSETUP 42K, 2012, "Christmas Carol", BOOT_UP, STACK_SIZE ; ... ; ====================================================== ; GAME WORLD STATE ; ====================================================== RAMSTART ; Start "Global" segment PLAYER_INFO STRUCT 0 @@Rank SCRATCH 1 @@ScoreRevs SCRATCH 1 @@Score SCRATCH 2 @@Lives SCRATCH 1 ENDS ; ====================================================== ; PRACTICE MODE STATE ; ====================================================== RAMSEG_START(Practice) ; Start "Practice" segment SCROLL_INFO STRUCT 0 @@Delay SCRATCH 1 @@State SCRATCH 1 @@Flags SCRATCH 1 @@Column SCRATCH 1 @@PadCol SCRATCH 1 @@RateFrac SCRATCH 1 ENDS ; ... ; ====================================================== ; LEVEL PLAY STATE ; ====================================================== RAMSEG_START(Level) ; Start "Level" segment LEVEL_INFO STRUCT 0 @@CandyCnt SCRATCH 1 @@SnoflkCnt SCRATCH 1 @@Deaths SCRATCH 1 @@Perfect SCRATCH 1 @@PresentCnt SCRATCH 1 @@PresentVec SCRATCH 1 @@BonusMult SCRATCH 1 @@PlayerHits SCRATCH 1 ENDS ; ... ;; ===================================================== ;; END OF LINE. ;; ===================================================== RAMEND ; End RAM segmentation ROMEND INCLUDE "macro/stats.mac" RAMSEG Lib.zip
  5. (Before commencing: I'm looking for open ended advice on laying out memory as a whole subject, feel free to add your own ideas, even if not addressed by my questions. Perhaps this may become a good reference article) When assembly programming, I am sat there with a pen and paper, planning out how I am going to lay out the RAM for my program and all of it's data. Occasionally I rejig it, moving blocks around. Do any of you have a best practice which you apply when deciding how to lay out RAM? My Perl based build system is pretty good at the moment and I am toying with the idea of having a parseable .csv file to decide how to lay out memory. Has anyone else done this before? People mention that they switch out the OS for extra memory. 1) How? 2) What is the knock-on effect of this, do I have to rewrite OS routines such as PMG collision detection and anything else in high RAM? Is this more trouble than it is worth? 3) Any tips in general?
  6. I didn't want to hijack the 512K cart thread, so I thought I would post this here: I actually have a cart, custom built for me by Jens-Eike (it's with him in Germany) that is a 64K bank-switched cart with 1K of ram permanently mapped in to the end of the cart ROM space (so there is 7K or ROM per bank, and the same 1K of RAM in every bank). It also has two hardware stacks on it but there's issues with the stacks - we can do a push (post increment) but pops are proving very tricky (pre-decrement) - something to do with a lack of appropriate signals in the cart port to trigger the pre-decrement, so that might not make it into the final design. We'll have to see. It's a shame because the stacks are lovely: Simply write to an address (I think it's >7FFE) and it pushes that value to the hardware stack. Do a read from the same address and it does a pop! The RAM for the stack is taken from the 1K of RAM. Of course, you don't need to use them if you don't want them, but I want them for a TF V2.x which would have a hardware stack (and thus be faster). It's currently implemented in discrete logic, but I'd be happy to hear to from anyone that is willing to tackle the problem with programmable logic. As I say, there are issues that need to be solved. I spoke with Gary Smith about it here in the UK. He has looked at the problem and agrees that it's a tricky one. He has a tentative solution using flip-flops to induce a delay (if I have understood it correctly) between detecting a read from the stack port (triggering an address decrement) and performing the read. I'd like to get the whole thing into one chip: That is: 64k ROM, 1K RAM and all logic. If anyone is interested is doing a design please let me know. Jens-Eike and Gary has expressed an interest, but it's hard to keep the momentum going - understandable enough... We all have lives outside of the TI
  7. Hello everyone, I'm relatively new to bB, but am developing a DPC+ game. Upon compiling, my free RAM is 0, and any additional work with variables is halted because of this. My code is messy, but contains a procedurally generated playfield and nine sprites. I haven't yet used all the variables a-z. (I'm up to about q right now.) Are there general practices that would help free up RAM, such as fewer variables, fewer sprites, etc.? I'm just not sure what I can free up in the standard RAM (and perhaps push into the stack?). Thanks very much for any advice!
  8. Looking for some games that don't require too much memory too run. I have a 600XL and no RAM upgrade for it yet, so just have the basic 16K. I found a version of Flappy Bird that was real good. Any ideas? Try searching basic programs in old magazines maybe? Thanks. -sirhempanite89
  9. So I was puting away my 2600 when an idea hit me, what if there was an advanced passthrough cartridge almost like the sega 32x. Here's a list of features it could include. -Built in bios -Extra 64k ram -Cartridge pull out protector (If you pull out a cartridge, it will reboot to the bois) -Sid chip (so we can finally have better music in our games) -Upgradeable -Dpc+ and Superchip compatible I would love to do this myself but I'm not very good with electronics nor do I have the budget to do it. XD
  10. This is a strange motherboard, runs for about two hours then locks up with video and audio random scrambles on the screen. When powered cycle it will run normally for another 1-2 hours. I tried swapping out the OS card, RAM, and POKEY with known working chips. The board was cleaned and so was the keyboard. Case was cleaned. A good candidate for retrobrite. It might be one electrolytic cap on the middle left of the main board that needs replacement. The keyboard port works, video port works, SIO port works, all the joystick ports work. Includes keyboard, power socket works. The electrolytc caps, and regulators on the power supply board were replaced and tested ok for voltages. Shipping from 98686 17lbs.
  11. I have a 800xl with red screen issues but i have silly question as im new to ataris. can i use the 1200xl ram in the 800 to test the ram chips?
×
×
  • Create New...