Jump to content

selgus

+AtariAge Subscriber
  • Content Count

    414
  • Joined

  • Last visited

Posts posted by selgus


  1. When I was in high school, we had time-sharing systems with a DECSYSTEMS PDP-2020 and teletype terminals. I learned MACRO-10 assembly language on that mini-computer and wrote many programs to do inter-communications between schools. We also had a CompuColor II 8080-based computer, where I wrote my first pac-man and defender clone games, in intel 8080 assembly. I think we also had a Commodore PET somewhere in a lab.

    • Like 1

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

    • Like 2

  3. 1 hour ago, mytek said:

    Just what @Levas was looking for. Well at least the schematics in Eagle. He'll still have to do his own layout from scratch.

     

    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.

    • Thanks 1

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

    • Like 2

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


  6. On 7/26/2020 at 2:01 AM, Video said:

    Always wondered if you could cut the middleman and use xband to link two systems directly today. How much was handled by servers? Granted, what's the interest, since, as far as I'm aware, all its games are still available today in better formats.

    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.


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

    • Like 3

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

     


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

    • Like 1

  10. While I've been writing code and waiting on some parts, I wanted to see how hard it would be to add 512K SRAM support to my portable. I had to re-layout portions of the board and move some of the logic and the crystal around, but I was able to cleanly route everything. I also swapped out the 7-pin DIN connector on the upper-left with a standard DB-9 joystick port, for joystick-1.

     

    I've never programmed a PAL before, but I've been looking over Matthias' SRAM 1.3 code, and I'm using the same GAL, so I think understand this logic. I also included DIP switches for the different RAMDISK options.

     

    Not sure if I will build up this version, but nice to know I could, if wanted..

     

     

    atari67xePortable-cpu-512K.png

    • Like 6

  11. 12 minutes ago, ivop said:

    Wondering, why do you print with nylon filament? I have compared several (affordable) filaments, like PLA, ABS, PETG and Nylon, and I'm very satisfied with PETG, at the moment. Slightly higher temp than PLA, but way better strength and layer bonding. Nylon is said to have better layer bonding, less wear during use, but also slightly more flexible. But it is toxic! The gasses produced during printing are carcinogenic. But perhaps you have a very good ventilated setup with filters and all? When I "warned" you about the illegal OS entry points, you had that covered already, too :)

    Oh I don't have a 3D printer, I use a service that has very high-end machines.. and that was one of the materials they offered. I wanted to get a nice sampling of different materials and do some test painting/clear coating, and see what gives me the best results.

    • Thanks 1

  12. You could open the cartridge and use a multimeter to beep-out all the traces from the cartridge connector, to the ROM chips.. if you think you have a broken trace. If you do find a break, you could use a bodge wire and solder in the fix.

     

    Here is a schematic of a 5200 cartridge which you could use to know where each trace goes..

     

     

    5200cart.gif

    • Thanks 1

  13. 49 minutes ago, mozzwald said:

    Backlit keys would be awesome for using it in the dark

    Not currently in my plans, but the keyboard was designed to be a totally separate board, with header connections to the CPU board.. so multiple keyboard designs are possible..

    • Like 2

  14. For that timeframe, I would prefer the architecture they used for DOS (i.e. some sort of ROM-based boot loader, and the bulk being loaded from updatable media). How many versions of DOS did ATARI themselves release? How many other versions have been around for the 8-bit series? If it was embedded in ROM, also taking up space in the memory map, it was have been much more difficult to update.

     

    The AMIGA had the Kickstart boot, that loaded what would become ROM, from floppy, back when the 1000 was released. IMHO, it was the correct choice for the product, at the time.

     

    Today, we'd use things like flash-ROM, but that wasn't the state of the technology back in the 80's. The ATARI OS was actually well thought out for adding functionality to the system, over time.

    • Like 1
×
×
  • Create New...