Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by alex_79

  1. I had some pictures of one of my Jr board on my PC (PAL-B, board CO21503, rev. F1). I've highlighted the traces going from the luma and Sync TIA pins to the CD4050, and they match J.Sobola's schematic: board (top) bord (bottom) You might be able to fix the mod with minor modifications, by removing all the jumper plugs and soldering short pieces of wire to connect the pins as in this picture. There's still the problem that with the CD4050 removed, the gate in the CPU reset circuit (circled in blue in the schematic) is missing. Since your console is still working without it, I guess it's not strictly necessary, but if it was me I'd follow @DrVenkman suggestion and I would remove the mod board, reinstall the CD4050, and then simply connect the mod using wires to the needed signals (those pullup resistors connected to the TIA pins are perfect for this). Verify that your board matches the one shown here by checking continuity between pins marked with the same colors. If it differs trace it to find the right spots where to pick the signals. Note that I'm not familiar with the UAV board as I never installed one myself, so use these info at your own risk!
  2. Load "Air Sea Battle", press reset to start the game and flip the TV type switch to B&W. The sky will show all 8 luma values in order from black to white. If there are less than 8 shades and/or if they out of order then the luma pins are not conencted correctly. BTW, is the CD4050 still on the board, with the mod pcb mounted on top of it, or has it been removed?
  3. Work perfectly on all my PAL consoles. Thanks for sharing!
  4. Check if a new serial port is detected when you plug the usb cable (you should see a new device, e.g. /dev/ttyUSB0). Also, try running the software as root. If it works that way, it's a permission issue. You need write access to the serial port.
  5. Yes, Jerzy Sobola's schematics are not official, so you should always verify the connections on the actual board you're working on, but they're a great reference noneless. There are different revisions of the schematics, too: I think those posted above are more recent than the ones in the AtariAge site. Also note that official PAL schematics for the 6 switch console can be found in the PAL service manual. Atari_2600_PAL_Service_Manual.pdf Anyway, (many) years ago I did a s-video mod on one of my junior consoles, and later on moved that same mod into a 6-switch (link). In both cases I tapped the signals from the CD4050 and the pinout matched Jerzy Sobola's schematics. Of course it's always best to double check, as there might be different board revisions. If you compare with the youtube video above, then yes, there are hues differences, but the video shows the color of the NTSC game running on a NTSC console. The PAL game on PAL console looks like this: It seems to me that colors are correct (considering a little variance due to the color pot adjustement) and the differences are indeed due to wrong luma connections. I don't know how this specific mod works, but if the LUM and SYNC are connected to a resistor ladder like in the Atari board, then I think swapping sync with one of the luma inputs could still produce a stable picture (the resistor value would be wrong, but the resulting signal might still be within tolerances).
  6. No, that adapter just connects two ranger controllers to provide both paddles in one port (just like standard paddles). There's not electronics inside, just wires.
  7. Is there a single jumpers configuration for use with any 2600 console? No surprise that it doesn't work. I don't know about NTSC versions, but the cd4050 is surely NOT wired the same in PAL 6-switch and PAL jr consoles. The inputs for the lum and sync signals are on different pins, and the remaining 2 inputs are used for different functions: on the 6 switch they buffer the joystick fire buttos, while on the Jr (PAL-B) one is part of the cpu reset circuit, while the other one is connected to the 4.43 Mhz oscillator circuit (but the relative output is unused). There's also a PAL-I jr that uses a different board and the pinout might be different there too. 2600-2600A-2600jr_PAL.pdf I would not power on that console until after tracing the board and fixing the connections, as there's the risk of damaging the mod board and/or the console itself.
  8. James is @ZeroPage Homebrew, and the RGB mod installed on the 6-switch consoles used for playing the games during the show on Twitch seems to introduce some glitches:
  9. Just to complicate things a bit, a few years ago when testing the early bus stuffing demos, I tried swapping the TIAs between my 6-switch and vader consoles but I still got the positioning issue on the 6-switch and not on the vader. So the TIA variation is not the (only) variable. Someday I should try installing one of the later TIA from my Jr or 7800 units into an older console. I don't know if anyone tried this before, as the later models have the IC which are soldered to the board, so removing them is not as easy as with older ones.
  10. I think they're both safe with regard to the two type of race conditions discussed here.
  11. Many thanks for the explanation. Very interesting. I've just pulled from git and compiled Gopher2600 with those changes. It works great!
  12. There's a 2009 thread about a unit like these here on the forums: It would be nice to digitalize those tapes to see if the games in there differ from the known binaries.
  13. NTSC TIA CLOCK = 3579545 Hz CPU CLOCK = 1193182 Hz PAL TIA CLOCK = 3546894 Hz CPU CLOCK = 1182298 Hz SECAM TIA CLOCK = 3562500 Hz CPU CLOCK = 1187500 Hz PAL-M TIA CLOCK = 3575611 Hz CPU CLOCK = 1191870 Hz
  14. That's correct. On Odyssey2, Videopac, Videopac+ and variants, Y and N keys are electrically the same as YES and NO respectively. No software can differentiate between them.
  15. On a 6 switch, that's usually caused by the CD4050 hex buffer failing. That's a common part, so hopefully it's an easy fix. The fire buttons lines are buffered by that IC before going to the TIA. Atari_2600_PAL_Service_Manual.pdf
  16. On real hardware, is the required delay the same no matter if you're setting or clearing VBLANK bit 7? I would expect the delay to be longer when clearing the bit before you can read controller 1 and 3, compared to setting it to read controller 2 and 4, because in the first case the 68 pF paddle cap inside the console needs to charge through the pullup resistor in the Quadtari (and on 6 switch and junior models there's an additional 1k8 resitor in series inside the console itself) until it reaches a high enough voltage for a logic "1", while in the latter the transistor inside the TIA pulls down the paddle lines directly.
  17. Anyone has experience with the latest Stella on Raspberry PI? Which model will run all games at fullspeed with TV effects, scanlines and phosphor turned on at 1080p? I tried installing the latest Stella on a old hp pavillon dv4000 laptop (it took over 30 minutes to compile!) and it plays Draconian (at 1280x800) with the above settings without any slowdown, but I don't know how it compares to a Raspberry.
  18. I had a look at the source on GitLab and here is a fix that I think should work (I don't have a Pluscart, but running the modified binary in my Harmony cart fixes the glitch on my 6 switch console) The race condition in the Pluscart rom is caused by the "sta RESP0" at the end of the _KERNEL_B macro (line 335). Change it to use absolute addressing, so it ends at cycle 1, which is safe (the table in this post shows when the position counters receive clock pulses with HMOVE starting at various cycles): ; preparation for next line ldx #$00 ;2 also clear value for next kernel stx HMP1 ;3 @69 sta.w HMOVE ;4 @73 ; sta RESP0 ;3 @00 <======== RACE CONDITION !!!!!! sta.w RESP0 ;4 @01 safe! Then you just need a few adjustments to keep everything aligned: Decrease the SLEEP argument from 14 to 13 in KERNEL_A (line 298) macro to compensate for the extra cycle caused by the change above MAC KERNEL_A ; displays: 00--00--11--11--11----00--00--00--00 ; SLEEP 14 SLEEP 13 _KERNEL_A {1}, {2}, {3}, {4}, {5}, {6}, {7}, {8}, {9} ENDM Change the value stored in HMP0 from $b0 to $c0 at line 1151 (we need to increase the value because with the RESP0 at cycle 1, we are skipping the first clock pulse to the motion counter) ; lda #$b0 lda #$c0 sta HMP0 lda #$80 sta HMP1 With this change we fix the alignment of characters 0-1 and 4-5, but we offset chars 2-3 and 6-7 1 pixel to the left (because the above HMP0 value is used for both KERNEL A and B)... To fix this, we add strobes to RESP0 ending at cycle 6 in KERNEL_B_BOTH and KERNEL_B macros (from line 340), so to skip the first clock pulse here too (for the timing of the motion pulses, refer to the column for HMOVE at cycle 3 in the table linked above) MAC KERNEL_B_BOTH sta HMOVE ;3 @03 ;lda LineBackColor+{1}; #{3} ;2 ;sta COLUBK ;3 @08 ; SLEEP 7+6 sta RESP0 ;3 @06 SLEEP 10 _KERNEL_B {1}_{2}, {5}, {6}, {7}, {8}, {9}, {10}, {11}, {12} ENDM MAC KERNEL_B ; displays: --00--00--11--11--1100--00--00-- sta HMOVE ;3 @03 ; SLEEP 13 sta RESP0 ;3 @06 SLEEP 10 _KERNEL_B {1}, {2}, {3}, {4}, {5}, {6}, {7}, {8}, {9} ENDM pluscart_fix.zip
  19. I did some tests about this and I believe the issue is a RESxx at the same cycle of a motion pulse following an HMOVE. https://github.com/stella-emu/stella/issues/699 https://atariage.com/forums/topic/311795-576-and-1008-characters/?tab=comments#comment-4646705 In post #20 of the second thread, I posted 3 modified binary that avoid the race condition. 2 of them seem to work reliably on all my consoles, while the other one triggers another type of race condition that still needs to be investigated...
  20. Stella emulates the lightgun just fine using a mouse and autodetects it correctly with the above rom, so you don't have to configure it. Anyway, if using a regular mouse, you need to enable the cursor visibility in the [Mouse] tab of [Input] settings, else you won't see where you're aiming. You can keep the cursor disabled if you use e.g. a wiimote as a pointing device, so to recreate the lightgun experience more faithfully.
  21. alex_79


    It works, but the board is not visible behind the black pieces. It's the same in Stella. The arm code is faster: it takes a little less than 21 scanlines now.
  22. alex_79


    Yes, the flicker is less distracting in this version on my TV but... it's in black and white! Stella reports 273 scanlines, and my TV doesn't show color with odd number of lines.
  23. alex_79


    BTW, if you use these alternate addresses to access the timer $28c (INTIM) $29c (TIM1T) $29d (TIM8T) $29e (TIM64T) $29f (T1024T) you enable the hardware interrupt function, which will pull pin 25 of the RIOT chip low when the interrupt flag is set, so it can be detected with a logic analyzer. Enabling the interrupt has no consequences as pin 25 of the RIOT is not connected to anything on a 2600 console (and 7800 too).
  24. alex_79


    Works fine! I find the flicker a bit too much visible on bright objects. The black pieces and the board look ok, but the effect on the white pieces is a bit annoying to my eyes. It gets a bit better if I reduce the contrast and/or back away from the screen. That's because you're reading the timer value (lda INTIM at $f0ac) before testing TIMINT. Even if the timer already expired (so, interrupt flag set and timer counting at 1 cycle interval), that read access clears the flag and, as a consequence, the timer resumes counting using the last programmed interval (64 cycles in this case) from whichever value it reached at that point. The flag will be set again only the next time the timer wraps around, and since it is now counting at 64T, it can take a long time (it depends on what value it was on when the flag was cleared).
  • Create New...