Jump to content

alex_79

Members
  • Content Count

    1,613
  • Joined

  • Last visited

Everything posted by alex_79

  1. 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
  2. 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...
  3. 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.
  4. 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.
  5. 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.
  6. 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).
  7. 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).
  8. 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.
  9. 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
  10. 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.
  11. 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)
  12. 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.
  13. 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...
  14. This article from may 1978 "Personal Computing" presents the Signetics chip set 2650/2636/2622 (NTSC).
  15. 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.
  16. The bytes read from the hotspots (and cartridge ram, altought in this case there's none) might differ depending on the specific dumper used, so I guess the rom doesn't match the one in the internal database, and Stella reverts to default settings. Unfortunately, in that case Stella autodetects the game as using a genesis pad in left port, while it actually uses an (optional) booster grip, and because of the inverted logic between the two controllers, the game "seees" the booster grip button for thrust as always pressed.
  17. It's here. That's the one I'm using.
  18. Tried again flashing the eeloader and a few roms with different bankswithing. Worked first try each time with both carts. No errors, no crashes. I will try to test further in the next days and will report back.
  19. I compiled the latest beta from git on my linux PC and tested a little bit today with the two standard (not encore) harmony carts that I have (version 1.0 and 1.9b respectively, as per the output of "lsusb"). I tried dowloading the eeprom loader image to both carts using the UI and failed, despite trying several times: With the new cart, on first try I got "error on writing data (1)" on the console. On every subsequent one I got "free(): invalid next size (fast)" AND the app crashed. I tried changing the number of retries to 20 and also setting the "add delay after writes..." option, but I got the same results. With the old cart I got "free(): invalid pointer" on the first try, and "free(): invalid next size (fast)" on subsequent ones, and the app always crashed after that. I also tried different cables, with no change in the results. I then tried flashing a few roms (from command line, this time). new cart: 4k game: ok f8 game: ok f6 game: "error on writing data (1)". tried 3 times with same result. f4sc game: same error - tried 2 times old cart: 4k game: ok f8 game: ok f6 game: download finished (game works), but software crashes with error "free():invalid pointer" f4sc game: same as with f6 The older software v1.3 seems to work fine (I used it from time to time in the last years and never had issues with it). Only sometimes fails on first attempt, but always works on second one in that case. The app doesn't crashes. ------------------------------------------------------- Note on the firmware: I noticed there's a PAL version 1.06 on the first post of this thread and tried it. The result is a b&w image on my CRT, so I guess it's outputting an odd number of scanlines. I currently use an unofficial NTSC firmware that TJ posted a few years ago. Looking forward for an updated official one.
  20. It doesn't depend on bBasic, that's how the TIA works. In score mode (CTRLPF bit 1 set), the left half of the PF takes color and priority of P0/M0, while the right half takes color and priority of P1/M1. The ball keeps normal priority (behind both players/missiles) Also note that if the playfield priority bit is set (CTRLPF bit 2), the score mode bit is ignored.
  21. Yes, in the 650x processor, all the internal registers and flags are in an unknown state at power on, and must be initialized. That's stated in the official technical docs. The same is true for TIA registers, the RIOT timer and RAM, and typically the extra RAM eventually installed on cartridge. The RIOT I/O pins are always set to input and do not need initialization if that's the desired behavior. There shouldn't be any difference in behavior in this area between the various Stella ports, if you didn't change the default settings and you're using the same release version. Different versions might have different default values and they're all configurable by the user anyway (configuration is usually retained after upgrading Stella to a newer version), so that might explain it. Also note that loading the game from a flashcart (Harmony, Unocart, etc) will usually hide initialization bugs (like a missing CLD), because the menu code initializes the registers before the game is run. Those bugs will show up in a standalone cart, though, causing the game to glitch if at power on the uninitialized registers do not have the desired values. Power cycling the console a few times typically allows the game to start correctly, so it might seem like a case of bad electrical contacts in the cart port or power switch. Stella default values are more forgiving, and hide some of these missing initialization. For this reason, it's a good idea to enable all the randomization in the "developer settings" to catch bugs early in development, rather than after the game has been put on cart.
  22. You're right, I didn't notice as I only checked the first one. Anyway, I managed to recover the corrupted archive (hopefully, there isn't any missing page). henry_will_notebook2_repaired.zip
  23. The Wayback Machine has the linked page archived and the downloads seem to work: https://web.archive.org/web/20161208144456/http://www.2600connection.com:80/library/tech_docs/tech_docs.html
×
×
  • Create New...