Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

Community Reputation

277 Excellent

About selgus

  • Rank
  • Birthday April 13

Profile Information

  • Gender
  • Location
    Orlando, Florida

Recent Profile Visitors

12,713 profile views
  1. I had received this book as a Christmas present but have not had time to read it yet.
  2. Back in the 90's I worked at a company called Catapult, where we built the X-BAND Modem and Network for 16-bit game consoles (I worked on the SEGA Genesis side). I modified existing SEGA game cartridges on the fly (we could sniff the address bus and re-vector specific addresses in ROM to our RAM, and execute patched code) to add network peer-to-peer game playing, for games that didn't originally support it. We had two modes to allow linking one console (or computer) to another-- one where we sync'd the vertical blanks between the two machines (basically slew the two to keep them in sync) and the other was to send packets that were lock-step and acknowledgments between the two machines. We always sent the controller data and some state information between the two machines, to validate they were in sync (32-bits of data at 60Hz). This kind of system could be done on the ATARI 8-bits too, I believe, to patch games so they could run in peer-to-peer. There were other modifications we would make the to the game execution, to make sure we had deterministic results on both machines, each vertical blank (i.e this meant patching all non-deterministic code that introduced randomness).
  3. Layout is the most fun part, especially when you are trying to make things as compact as possible while not breaking any PCB design rules. @mytek as done an amazing job designed these PCBs and making them very accessible to a spectrum of builders, not just the experts. While I do agree, when making a PCB for mass production, optimizing the BOM is one of the key elements that a developer will go through, to lower the unique part counts (even to select component values based on the overall design), but that doesn't seem to be his goal with the 1088 XEL. I know when I am designing a one-off or something I'm iterating on, I might use parts that I just happen to have on hand, or some other reason, outside of pure part optimization.
  4. +1 for getting a Hakko Desoldering Gun, if you want to reproducible successful chip removals. I've removed hundreds of chips with one of these guns, and once you get the technique down (its very simple), you should have nice results.
  5. I have removed many ICs from XEGS motherboards at this point, and I would caution removing something like the SALLY CPU chip before you know you really need to (if you don't have expert skills in desoldering and not messing up PCBs currently). I usually don't worry about lifting pads, because I am just after the chips, but especially on the XEGS', those pads lift quite easily. If you have access to an oscilloscope, then checking some signals on the CPU first, to see if you are getting valid clock signals, or even a multimeter checking VCC and some of the other pins to see if you get meaningful values (using your working ATARI also can help checking what you should expect on many of the pins). You can do this on the DRAM chips too, see if data pins have valid waveforms or you can spot something obvious before possibly risking some of those traces/pads by removing any ICs. Just some thoughts you might consider.. B
  6. I have a bunch of power switches I've pulled for multiple XEGS motherboards, and you are welcome to one of these, if you like. I am located in the USA, so would need to ship it internationally, but if you just cover the shipping, its yours. B
  7. A different implementation for PRINTing to the screen in 6502, is to not pass the address of the string data to the printing function in the index registers, but to place that data after the "jsr" call to your printing function. Then in your printing function, you can pull the return address off of the stack and use it as a pointer to the string data you wish to print. Usually you end that print data with a NULL, so you can check if you are at the end of the string yet. Lastly you can then use that pointer that is now at the end of your string, as the return address for your "rts" (by pushing it back onto the stack and doing an "rts").
  8. We were able to link two systems together directly.. this is how we developed the patches for the games. I had special XBAND cards, that we could link with a null modem cable, so we could test our code. Our servers were pretty complex too.. we had match making, news and mail systems, it was really ahead of it's time.
  9. Received my FujiNet device today, in it's nice XE-style case.. along with a cool FujiNet pin! Thanks! Now I need to find some time to play around with it, and make sure my BIOS plays nicely with the device.
  10. I worked at Catapult, building the XBAND Modem and Network, back in the mid-90's. I was one of the people that reverse engineered different cartridge games, figured out where they were reading their inputs from controllers, modified any non-deterministic patterns (i.e. random numbers couldn't actually be "random") and hooked in our synch-o-tron routines to allow two remote consoles play each other, over the CompuServe modem pool. It was really interesting back then, as we built hardware that plugged into the consoles, and you plugged your game cartridge into our hardware. From there, we had 64K of RAM, plus all the address lines flowed thru us, and as such, we had hardware that could sniff the bus looking for software modifiable addresses, have "patch" ROM cartridges to vector into our RAM to change how the games executed. We did have issues with people trying to cheat, if they were losing, pulling their modem phone connecting, etc. We had code in our OS, to try and detect this, as pulling the cord was different than noise on the line, or other kinds of error conditions.
  11. Have 12 more of these now, if anyone needs... B
  12. Received my 10 today too.. thanks and they look great!
  13. I'm not sure if this is related to your issue or not, but the XEGS OS has additional code to properly deal with the PORTB bits and the external keyboard. Here is an snip-it from my BIOS, which uses the XEGS OS as its base. I've modified it for my use case, as my keyboard is always attached. ;** PPMI - Patch for PMI ;* PPMI enables on-board game based on CONSOL and connection ;* of external keyboard. ;* ;* ENTRY JMP PPMI ;* ;* EXIT ;* Jumps to PMI3 or PMI4. ;* ;* MODS ;* Original Author Unknown 1987-05-07 PPMI = * ;entry lda CONSOL ; console switches ror a and #%00000011 ; bit 0 - SELECT, 1 - OPTION cmp #1 ; is OPTION pressed and SELECT released? beq PPMI2 ; if OPTION pressed and SELECT released ; <BSB> Modify since keyboard is already attached IF TESTKB eor TRIG2 ; bit 0 = 1 if (SELECT pressed == keyboard attached) beq PPMI1 ; if OPTION pressed and (SELECT pressed == keyboard detached) cmp #3 beq PPMI1 ; if OPTION released and (SELECT pressed == keyboard attached) ELSE ENDIF ; TESTKB jmp PMI3; enable BASIC PPMI1 lda PORTB ; port B memory control and #%10111111 ; enable game sta PORTB ; update port B memory control PPMI2 jmp PMI4 ; don't enable BASIC
  14. Received my issue in the USA today.. thanks!
  15. Yeah, I did find some PALs if I wanted to make this version work, so that wouldn't hold me back. Also using a modern SRAM chip. Haven't taken any videos of my current setup, as I am working on a patch for the video signals right now. Need to change a few parts. Meanwhile been working on the firmware.
  • Create New...