Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by alex_79

  1. You did in every single post of this thread. You distort or just plain invent what other said, and then use that to support your thesis. And it takes efforts to selectively quote small portion of a phrase (just a few words more and it would be clear what the original poster meant) and presenting it out of context so to completely misrepresent other people's view. That's clearly deliberate. And shows a complete lack of respect towards the people here who invested time to have a reasoned discussion with you. You're insulting them. The end result is that the other interlocutors soon realize how worthless is to continue this single-way "discussion" and give up. I guess in your mind your think that you "won" by resignation of the opponent. I hope you're proud of it. For example, there was absolutely no warning that has been escalated to error. No one ever said that. And a previous version of dasm has been posted in this very same thread, so you could have tried to compile the source and verify your facts without much effort. You evidently felt it was better to spend your time enriching your "discussion" with random images and youtube videos. I guess you consider supporting your point with facts an "academic exercise", and you made pretty clear how much a negative connotation that has in your mind. I think the dasm mantainers gave very reasonable motivations for the addition of this error check, and explained why it was worth sacrificing a bit of backward compatibility with that fix. I don't have anything to add and only posted because I was yet again pissed off by you trying to make a fool of people investing time discussing with you. I have not desire to talk about any subject with you either. I did it once and that was enough. The problem is that your comments are visible when someone quote them even if you're on my ignore list (the only and one, in more than 20 years of me participating in forums on internet!), and unfortunately you seem to always show up in threads I'm more interested in. As a result I more and more abstain from commenting in those threads and I lost quite a bit of interest in visiting the forums. What you do is not discussing, as from the beginning you have absolutely no intention to listen to what other people have to say nor to change your position if evidence proves you wrong. That's a sermon rather than a discussion. And I'm not interested in that. I apologize to everyone else for going off-topic and I won't derail the thread any further.
  2. I agree. Even with the standard pot, games only use a small portion of the full 270 degree rotation because else it would take multiple frames to read the full range. A 360 degree pot wouldn't have any purpose in this application.
  3. @Nathan Strum showed a technique to fix this issue in a recent blog post:
  4. Twisting other people's words, not providing evidence, moving to another argument when shown to be wrong, are some of the reasons he's been put in the ignore list by most of those who had the misfortune to embark in a discussion with him. For unknown reasons, if someone finds a bug in his code, he consider that as an insult and a personal attack, so that might explain his aversion to this bug fix in dasm. In the past, some changes in Stella behavior revealed missing initialization in some of his games, and as a result he totally freaked out, spamming threads by affirming that the emulator was buggy and, when proved wrong, coming out with the absurd explanation, that in fact he programmed the games that way on purpose, to support a toy console running a lousy emulator...
  5. The games that supported the kid's controller are listed on this page. The controller is electrically the same as the Video Touch Pad and the Keyboard Controller, so it works with games made for those too, although the overlays won't fit.
  6. I don't know for sure. Since I used the cd4050 that was already installed on the board (this is only possible on 6 switch and junior models), I removed a few components to isolate the chip from the rest of the circuit on the Atari board. But if you're building the full mod with an external cd4050 like shown in the FAQ, maybe the existing circuit won't interfere and you don't need to isolate it. Sorry for the late reply, I didn't log in the forums in the past few days.
  7. A guy told me that applying some holy water with a soft brush to the crt surface will help the magnet doing its stuff. This apparently is due to the phosphor coating transubstantiating into a magnetic powder so it can be moved into the burned areas. Of course you won't find this mentioned in scientific literature as those academics and their students are too closed-minded.😜
  8. I too prefer to make my mods reversible and avoid drilling the case. When I modded an heavy sixer for s-video, I used a female in-line SCART socket.
  9. Yes, you can use standard foil tape. The point is to provide a path to ground to discharge static. Check with a multimeter that you have some continuity between the switches and the rf shield. With the tape I'm using, the glue act as an insulator and prevents electrical contact between the tape and the surface it is stuck to (in the picture, the needle on the multimeter in the background is all the way to the left, that is infinite resistance). The solution is to make a few cutouts so you can fold a little area of the tape on the back to ensure contact with the switches and the rf shield. If you plan to open the console often, it's probably best to just solder a small piece of wire from the metal case of each switch to a ground point on the PCB, so you don't need to reapply the tape every time.
  10. Another method is to turn off only "Correct aspect ratio" in the "Display" tab, and then select "Create pixel-exact image..." in Options>Snapshots. No need to individually disable the effects and change the zoom in this case, and should work correctly also in fullscreen mode. The resulting snapshots will be at 1x size, that is 320 pixels wide.
  11. I can get pixel perfect screenshots without changing the renderer: In the "Display" tab, turn off "Interpolation" and "Correct aspect ratio", and set the zoom to an integer value (i.e. a multiple of 100) In the "TV Effects" tab, set "TV mode" to "disabled", turn off "Phosphor for all ROMs" and set Scanline Intensity to "off" Restart Stella You should now get this:
  12. Tested the new rom with the L6 and the glitch is gone.
  13. There should only be two possible results: 1 - the extra clock at cycle 0 happens slightly before the reset of the position counter -> the player is moved left one pixel, then it's repositioned (at pixel 3, as we are in HBLANK), then moved left one pixel for each of the remaining clock pulses. For a HMP0 value of $40 (12 pulses), it will then move left 11 pixels from position 3, ending at 152. 2 - the extra clock at cycle 0 happens slightly after the reset of the position counter -> the player is positioned at pixel 3 and then moved left one pixel for the current and following clock pulses (so 12 in total), ending at position 151. I did some tests with my consoles. Here are the results when running the roms posted in this thread: 1008 Char and 576 Char: The first 2 chars are garbled on the Light 6er on every other row. Works fine on all other consoles 576 Char multicolor: slight issue on the very first pixel row for the L6. Fine on the other consoles. I also tried the 36 char demo posted here, which doesn't display correctly on my L6. By looking at the included source, there is room to move the RESP0 strobe from the critical cycle 0 without affecting the timing of the rest of the kernel. So I compiled a few modified versions with that RESP0 happening at cycle 1,2 or 3 (and changing the HMP0 values accordingly, to keep the alignment). I would have expected all three versions to work reliably on all consoles, and while this is true for the "cycle 1" and "cycle 2" ones, the "cycle 3" shows another positioning issue on three of my consoles!! This seems to be a different kind of race condition, as there aren't HMOVE clock pulses at cycle 3, and the difference in positioning is 3 pixels, not just 1. Here the results with an altered rom that helps showing the positioning of the players: 36_Char_Interlaced_mod.zip
  14. I remember watching this show as a little kid! The title was "Superauto Mach 5" here. It was about 35 years ago, and I only have vague memories about the story, but I distinctly remember the italian theme song 😀 https://www.youtube.com/watch?v=JazRMFYLWIk
  15. Cool! I tested on the Jr console I have hooked up to my CRT. I agree with @SpiceWare that the 576 chars one looks best. The 1008 one flickers too much for my taste. I recently tested various consoles by resetting an object position while an HMOVE is still performing its operations, and my conclusion is that the offset between different consoles is the result of a race condition. If the strobe to RESxx coincides with one of the extra CLK pulses that the position counter receives during an HMOVE, the resulting position depends on which of the two events happens first. Here is a table with the (hopefully correct) timing of the extra CLK pulses for HMOVE cycles form 73 to 3. HMOVE extra CLK pulses | HMOVE cycle HCOUNT CPU | 73 74 75 0 1 2 3 ---------------------------------------------------------------------- 0 0 | 1* 1 1 1.33 | 2 2 1 2 2.67 | 3 3 2 1 3 4 | 4* 4* 3* 2* 1* 1 4 5.33 | 5 5 4 3 2 2 1 5 6.67 | 6 6 5 4 3 3 2 6 8 | 7* 7* 6* 5* 4* 4* 3* 7 9.33 | 8 8 7 6 5 5 4 8 10.67 | 9 9 8 7 6 6 5 9 12 | 10* 10* 9* 8* 7* 7* 6* 10 13.33 | 11 11 10 9 8 8 7 11 14.67 | 12 12 11 10 9 9 8 12 16 | 13* 13* 12* 11* 10* 10* 9* 13 17.33 | 14 14 13 12 11 11 10 14 18.67 | 15 15 14 13 12 12 11 15 20 | 15* 14* 13* 13* 12* 16 21.33 | 15 14 14 13 17 22.67 | 15 15 14 -------NORMAL HBLANK END----- 18 24 | | 15* 19 25.33 | | --EXTENDED HBLANK END (hmove bar) --------- * = a RESXX on this cycle causes race condition with the extra CLK pulse.
  16. Chapter 2 of the Magicard manual explains how to safely handle the bare board, which orientation is the correct one, and how to open the cart port dust cover using a fiberglass tool included in the package: You can find scans of the manual here on AA: https://www.atariage.com/manual_page.php?SystemID=2600&ItemTypeID=&SoftwareLabelID=281&currentPage=15&maxPages=138&currentPage=0 I made a PDF version of the manual a few years ago, that you can find in this thread: https://atariage.com/forums/topic/233941-magicard-pal-conversion-enhanced-version/
  17. It seems that the TV is on the wrong channel. Are you sure that you tuned it correctly?
  18. You're right. Here's an excerpt from the "Berenstain Bears" game manual mentioning this "feature":
  19. Weird. In the Tapper rom that seems to work fine on this board, the next instruction is at $fff9, so both A6 and A5 are HIGH. I didn't include it in the schematic (as my goal was just to determine the truth table), but in the pics there's a small ceramic capacitor (unknown value) between pins 10-11 of the 74LS00 and GND. Could a cap placed there help filtering out transient variation of the /R and /S inputs due to A5 and A6? And, if so, could it be that it works when A12 pulses LOW, but it's not enough when A12 is steady LOW because the effect of the other signals (A9,A10,A7) are delayed by the extra gate (of the 74LS10) they go through compared to A12? Sorry for the likely dumb questions. As I've said I only have very basic knowledge about this stuff, but I find it very interesting nonetheless.
  20. It doesn't change the truth table: in both cases (pin 4 floating or connected to pin 5) the gate acts as an inverter for the signal on pin 5. Whether it affects the timing during the transient, I have no idea.
  21. I guess it's a timing issue: the address lines don't switch state all at the same time, and the logic gates themselves add delay to some of the signals too. When accessing the hotspot from RAM, A12 stays unset, and maybe during the transition of the remainig bits between the valid hotspot address and the valid next instruction one, a pattern corresponding to the other hotspot (or the "illegal" state of the latch) briefly appears on the bus, messing the bankswitch. This is just my naive theory, so don't take my word on it! I'm able to trace the circuit and reconstruct the truth table based on how the logic gates are wired, but understanding what happens during the transients is well beyond my skills.
  22. The highest address pin (A14 - pin 27) is tied to +5V, so the Atari only "sees" the second half of the eprom. What's in the first half doesn't matter. Yes, you can put a 27128 in there without modification. I don't know what's the purpose of those resistors.
  23. Yes, each eprom contains half of the rom. As for replacing it with another game, it's no different than for the other boards: you can as long as the game uses the same bankswitching as the old one. If not, it has to be hacked first. Popeye cannot be converted to work on any of these boards. The bankswitching it uses is very different and more complex than the one used by Atari. (instead of 2 4k banks, there are 8 1k ones that can be mapped in any order in the Atari 4k address space).
  24. Regarding for the "Kangaroo" board, the rom is split into two 4k eproms. The bankswitching logic switches the "chip enable" pins of the 2 eproms so that only the one containing the current bank is enabled. Some commercial Atari 7800 and atari 5200 games have the rom on separate chips. And the typical board used for 2600 8k prototypes has two 4k eproms too (here an example).
  25. I'm glad it finally worked! So it seems that the bankswitch on this board doesn't work reliably if the code that accesses the hotspot is being run from RAM. In the last version of "Tapper" it has been changed to run from ROM.
  • Create New...