Jump to content

jum

Members
  • Posts

    173
  • Joined

  • Last visited

Posts posted by jum

  1. So I finally got around to converting my jumpong code from 5200Basic to C, and made some fixes / improvements along the way.

     

    You can get the 16k binary and the source code here:

     

    https://github.com/james7780/Jumpong-V3

     

    As usual, feedback on bugs or improvements is always welcome :)

     

     

     

    screenshot1.png

    screenshot2.png

     

    Edit: Updated 2023-12-11, now with better keypad handling, and option to play against the CPU (very simple "AI" opponent).

    • Like 4
  2. While I'm obviously happy for you Albert, I have my concerns about Atari owning the forums:

    - The "value" in the forums is community contributed, thus although you provide the platform, the content in a "socialist" way belongs to the people who contributed it. That is (was) the implied understanding. I'm pretty sure I'm not alone in thinking this. So not comfortable with any attempts to "own" the content and further, monetise it.

    - Still very wary of the "new" Atari.

     

    Then I also have the concerns about Atari censoring homebrews, rom hacks, dev documents, and any "property" they feel they own.

     

    • Like 15
    • Thanks 2
  3. I've recently been modding a "Pixels Past" 32k 5200 cartridge PCB to be able to switch between 2 16k rom images in the 32k EPROM, using an external switch.

     

    This setup assumes that the 16k rom is mapped to 0x8000 in the 5200 memory space.

     

    However I noticed that many 16k roms seem to be mapped to 0x6000, and then the last 8k of the rom is repeated at 0xA000.

     

    (I also noticed this when writing the Jum52 5200 emulator)

     

    What I'm curious about is why this was done? Was it maybe some kind of anti-piracy mechanism, to make it harder to copy the cartridge?

     

  4. On 2/20/2020 at 12:12 AM, Adam Mace said:

    Where did you pull Audio from?  I got video working fine, just looking for the best spot to tap into Audio.  The pin going into the modulator?

    See attached picture (blue wire). Looks like resistor R41 (on my 2-port 5200, I think 4-port is the same). Like the other guys say, may be a good idea to add a resistor to the audio out (although mine sounds fine and the level seems OK).

    5200 audio.jpg

  5. On 1/28/2020 at 10:23 PM, Adam Mace said:

    Do you happen to have a schematic of this circuit you've made?  I'm working on a 5200 and getting real bad RF interference.   I'd rather bypass it entirely without buying a UAV board, but my theoretical knowledge isn't that great.  

    Here's a quick hand-drawn schematic. Not 100% sure about the polarity of the 0.1uF cap, or the connections to the 2N2222 / 2N3904 transistor (you should attach the transistor as per the schematic in your post).

    You could also try the schematic in your post. Will be interesting to see which gives a better picture.

    Disclaimer: I take no responsibility for any dead 5200's resulting from the use of this mod.

     

    5200 mod curcuit.jpg

  6. 7 hours ago, DrVenkman said:

    That's a heck of a weird thing to go wrong! Glad you finally got things figured out though!

    Yeah, pretty unusual fault.

     

    Lots of pondering over schematics and datasheets, and probing with an oscilloscope, was involved...

     

    Have now discovered the GTIA may be faulty - the player to player collisions don't seem to work! (Also unusual).

     

  7. Here are the pictures, although in person the images on the screen is not so bright and the ghosting is much less noticeable.

     

    Hopefully putting the mod onto a proto board and a bit of tweaking will give a slightly better image.

     

    IMG_20200114_195830.jpg

     

    Note:

    - RF modulator removed completely

    - Resistor R33 leg (audio) lifted off the board

    - Video signal taken from left side of L12 (green clip)

    - +5V taken from top of L13 (red clip)

    - Ground taken from top side of C40

    - Transistor used in mod circuit is KSP2222N    (2N2222?)

    - Resistor used in mod circuit is 100 Ohms

     

    These are just the first points I saw on the schematics that looked like they have the right signals, possibly there are better points to take the signal off.

     

     

    IMG_20200114_200343.jpg

    IMG_20200114_200243.jpg

  8. Just removed the RF modulator from my 2-port 5200 and wired in a simple composite connection using 1 transistor (2N2222?) and one resistor between video out and ground.

     

    Also cut the one leg of the resistor (R33?) that connects the audio to the video output. Have yet to connect the audio output.

     

    Very surprised at how good it looks (way better than 2600 and 7800 composite mods I have done). Will post pictures later.

     

    Tweaked the big pot on the lower right side of the board to get the colours correct. Video output may be a bit "hot", need to check that and maybe add voltage divider to the circuit.

     

  9. On 10/19/2019 at 3:17 PM, karri said:

    Really guys....

     

    The correct way to write this code is: "memcpy"

     

    Yes, that is true for this specific example, but only because you have optimised it, not the compiler.

     

    It's not a good example, maybe a better example is something like:

     

    for (i = 0; i < 32; i++)

            {

            B[i] = A[i] * 2 + 1;         // some processing is happening, not just a memcpy

            }

     

    As said before, the point of the comparison is to see how the the 2 compilers handle the same code construct.

     

     

  10. OK here's the cc65 code and ASM output for comparison. Note I used the cc65 "-Or" optimisation flag to enable register variables:

     

    cc65 code:

     

    void main()
    {
        uchar i;
        
        asm("nop");
        i = 31;
        do {
            MIKEY.palette[i] = work_palette[i];    
            i -= 1;
        } while ( i >= 0 );
    
        asm("nop");
        for (i = 0; i < 32; i++)
            MIKEY.palette[i] = work_palette[i];    
        asm("nop");
    }


     

    Assembler output (.s file):

    ; ---------------------------------------------------------------
    ; void __near__ main (void)
    ; ---------------------------------------------------------------
    
    .segment    "CODE"
    
    .proc    _main: near
    
    .segment    "CODE"
    
        jsr     decsp1
        nop
        lda     #$1F
    L0060:    sta     (sp)
        ldx     #$FD
        lda     #$A0
        clc
        adc     (sp)
        bcc     L0044
        inx
    L0044:    jsr     pushax
        ldy     #$02
        lda     (sp),y
        tay
        lda     _work_palette,y
        ldy     #$00
        jsr     staspidx
        lda     (sp)
        sec
        sbc     #$01
        bra     L0060
    L005F:    lda     (sp)
        cmp     #$20
        bcs     L004E
        ldx     #$FD
        lda     #$A0
        clc
        adc     (sp)
        bcc     L0058
        inx
    L0058:    jsr     pushax
        ldy     #$02
        lda     (sp),y
        tay
        lda     _work_palette,y
        ldy     #$00
        jsr     staspidx
        lda     (sp)
        ina
        sta     (sp)
        bra     L005F
    L004E:    nop
        jmp     incsp1
    
    .endproc
    
     

    Way longer/slower (for this example), and very hard to follow! 

    • Thanks 2
  11. Would be nice to see a comparison with cc65 generated ASM. If I get a chance tonight I will do same code in cc65 and upload the asm generated.

     

    Also would need to expand the lynx lib/module for Millfork.

×
×
  • Create New...