Jump to content

alex_79

Members
  • Content Count

    1,596
  • Joined

  • Last visited

Everything posted by alex_79

  1. I think they're both safe with regard to the two type of race conditions discussed here.
  2. Many thanks for the explanation. Very interesting. I've just pulled from git and compiled Gopher2600 with those changes. It works great!
  3. 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.
  4. 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
  5. 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.
  6. 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
  7. 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.
  8. 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.
  9. 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
  10. 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...
  11. 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.
  12. alex_79

    Chess

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

    Chess

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

    Chess

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

    Chess

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

    Chess

    I tried increasing the value stored in the timer from $2f to $31, which gives 278 scanlines in Stella, and the resulting rom works fine on my TV (I confirmed with the logic analyzer that the frame is 278 lines with the hacked rom) So, the arm code is taking is taking too long and the timer expires before the 6507 code starts checking it.
  17. alex_79

    Chess

    It rolls faster than the previous one on my PAL CRT TV. By looking at the signals: 592 scanlines per frame (38ms) ARM code running from scanline 5 to 33 Chess board from scanline 361 to 562
  18. alex_79

    Chess

    Tested version in post #1198: it still rolls. I connected my cheap logic analyzer to the console: The frames are 375 scanlines (24ms) long The board is displayed between scanline 144 and 345 as there's activity on LUM0-3 pins of the TIA in this range. The arm appears to idle the 6507 between scanline 5 and 33 as in this range A12 is high (cart space) and D4 is constantly low (which is compatible with the arm putting $EA, that is "nop", on the bus). I only have 8 inputs available, so I can't monitor the entire bus.
  19. If you have one, you can pair a wiimote to the PC and use that as a lightgun substitute. (you'll need a sensor bar, too)
  20. I use this vintage eprom programmer that includes an eprom emulator function. Connection is over rs232 (and works perfectly with an usb to serial adapter too), and doesn't need any proprietary software, so it works with modern devices with no problem. The default file format is "intel hex" and I use the program "srec_cat" on linux which is part of the "Srecord" package to convert to/from binary files. (the program can use the serial port device directly as input or output without creating intermediate files). I've set up two simple bash scripts to upload or download data to the programmer with a single command. I use an harmony cart to test binaries on the 2600, but the eprom emulator comes in handy with other consoles for which I don't have flashcarts.
  21. Yes, the Elektor "TV games computer" uses the same hardware as the Interton/1292 APVS consoles. The expansion board for the computer published In one of the later articles included, among the other improvements, two cartridge ports to use the commercial games for the Interton and Radofin consoles. The Elektor articles also mention that a few readers actually modified their consoles instead of building the computer from scratch. The Hobby module for the Radofin console (and the similar units for the Voltmace, Rowtron and Occitane) basically turn the console into the Elektor computer in its basic version. Apparently the tape format is also compatible, so you can load the software published by the Elektor magazine into an Hobby module. The two monitor software look almost identical to each other, and all the commands and the layout of the keys are the same. I tried both (with an home built eprom cartridge) on my Interton VC4000 console. elektor TVGC: Hobby Module: I'd like to build the cassette interface some day...
  22. This article from may 1978 "Personal Computing" presents the Signetics chip set 2650/2636/2622 (NTSC).
  23. This happens when you write the timer exactly at the "wrap around" cycle, that is when the timer value is decremented from $00 to $ff. In that case the interrupt flag isn't cleared and the timer counts at "1T" interval. In fact, when the interrupt flag (TIMINT bit 7) is set, the timer always counts at 1T, while when it's clear, it counts at the programmed interval (1T,8T,64T,1024T). The flag is set whenever the timer wraps around, while it's cleared on every read (INTIM) or write (TIM1T,TIM64T,etc.) access, except when the read/write happens at the wraparound cycle. Stella has two pseudoregisters to easily debug these occurrences: _timwrapread: true if you read the timer at wraparound cycle _timwrapwrite: true if you write the timer at wraparound cycle So you can set a conditional break in the debugger prompt breakif _timwrapwrite to detect such cases. If you can't ensure to avoid that condition, a solution is to just write to the timer twice: sta TIM64T sta TIM64T The second write will always be ok, unless you're storing a value of "3". In that case, either use any other value for the first write, or delay the second write by executing other instructions in between.
×
×
  • Create New...