Jump to content

tf_hh

+AtariAge Subscriber
  • Content Count

    847
  • Joined

  • Last visited

Community Reputation

1,128 Excellent

1 Follower

About tf_hh

  • Rank
    Dragonstomper
  • Birthday 10/11/1970

Profile Information

  • Gender
    Male
  • Location
    Germany
  • Interests
    Microelectronics, Atari 8-Bit Hardware, Atari 16-Bit Hardware, ATMEL Microprocessors

Recent Profile Visitors

13,813 profile views
  1. The video circuitry is exactly the same. My focus was on the general very good signal quality of the 600XL machines. A S-Video mod is also very easy made. The missing monitor jack at NTSC systems is another story. But, to make it neat, you´ve to install the monitor jack in any case, not dependent if you´re using UAV or mod the existing video to S-Video. In both cases you get a very good picture, better than any other XL or XE machine. That´s what I said.
  2. Hi Larry, I´ve updated two times a 600XL with UAV. Installation is easy like in any 800XL, but... IMHO it´s not so mandatory like with the other systems. The 600XL has the best video circuit of all Atari XL/XE systems. The whole video involved parts are away from other buss activity traces. I never saw a 600XL with vertical banding or other disturbations (as long a good power source is used). The one and only bad thing is the capacitor C109, which causes a very unsharp picture. Just remove it and you´re done. With a slightly S-Video mod the picture quality of the 600XL is nearly perfect as with UAV. Ok, I have only experience with PAL systems here, maybe it´s a difference with NTSC. This picture shows a solder joint where to grab the COLOR signal.
  3. Maybe B&C has some, also, but it´s a special part. Some years ago I found a schematic from an unknown author with a discrete reproduction of the Delay Line: I don´t know if anybody has built and successfully use such a substitute. But, it´s not really needed. If no Delay Line is availible, just replace all 74s parts incl. delay line around the DRAM control circuit, use one SRAM and you´re fine. Same way like I did in my 600XL expansion, Mytek did it in the 1088XEL/XLD or Lotharek with his SRAM module and Freddie replacement.
  4. One of these typically homemade installations of the 90s... 😲 Are there ROMs/EPROMs installed? The RAM PCB covers the lower sockets. I suggest there was a TOS 2.06 adapter PCB with CPU sitting in the CPU´s socket. So if no ROM/EPROMs inserted, you need such a TOS-card or re-install standard ROMs for TOS 1.0x. The upper CPU socket is heavily oxydized, remove and exchange it complete. The little PCB between is the blitter correction part, it must be present. The GLUE and MMU are made by IMP... these ones are best known as trouble maker. The chances are high that you never get a real stable system with these. if there´s no ROMs and no TOS-card, check for more modifications. Maybe somebody has removed expansions like OverScan ST, which require cutting of traces.
  5. Sorry, I´m late to this party 😃 Did you exchange the Delay Line IC (CO60472)? I´ve had similiar problems with the Sophia RGB and VBXE, too. Stock video works fine, even with UAV or any other mod, but FPGA based video emulators makes woes. After hours of investigation with a logic analyzer and scope I found out, that the Delay Line has wrong delay times at two outputs. This causes the CAS and RAS timing slightly different than standard, we´re talking only about 30-40 nanoseconds. For me the conclusion was, that the slow old chips aren´t affected by this, but the very fast sampling FPGA read wrong infos, because the RAMs switched already to another output state. The system I have had for repair makes more trouble, not only PMG, but mostly. A new Delay Line cures all. It´s worth a try I would say... alternative is to try a VBXE in this system.
  6. Ok, but this isn´t resonable, because all parts are SMD parts. You must include two shottky diodes (one for the battery, the other for the default +5 volt supply) and a little mosfet to enable/disable chip-signal support with "high" during battery mode. Withou these parts the SRAM won´t switch to deep energy safe mode and consumes much more power - battery is exhausted also faster than usual. An real expert can add these parts with SMD parts, but not the most common users, so I didn´t offer a solution - this will end up in much support I can´t give.
  7. Hmm, I didn´t see (surely language issue) the difference between this and what I wrote above? Nevermind, for those who want this feature without modding their SysCheck, I create a slightly updated version "SysCheck Deluxe" with battery back up and write enable/disable switch (for the extended memory in memory expansion mode) - availible at the end of October 2019.
  8. Hmm, when the board is running and soft-power on/off works also fine, I would say, that these both LEDs are simply soldered in the wrong way. Desolder the yellow LED first, turn it about 180 degrees and try it again... if it lit up, do the same for the green one.
  9. The jumper settings in the linked post are explained for the Rev.C of UAV. I´m pretty sure you got a Rev.D these days. Here´s one example for Rev.D:
  10. The pictures looks like not all four LUM signals reached the UAV module OR the jumper settings at the UAV module are wrong. Check jumper settings first, then the connecitivity from GTIA to the 74HCT08 and from this chip to UAV:
  11. Just for the records... Connecting any I/O to ground of the Xilinx XC95...XL series is harmless. Connecting an I/O directly to +5 volts without current-limiting resistor will kill the XL series (3.3 volts models with 5 volt tolerance) immediately.
  12. I would say it´s a MC1488 - the MC1489 counterpart is found at the most left place.
  13. Can only guess... it look likes that only the parallel port parts are installed. The PIA on the card will be mirrored (it´s register) to the I/O area (maybe $D7xx or so), the 74LS245 is used for latching the 8 databits.. Curt´s pictures shows the MC1489 voltage converter for serial communications. The 24 pin chip is a MC6850 UART (for serial). Some more logic ships for address multiplexing. The only strange thing is the crystal. By default, twisted frequencies like 1.8432 MHz are used to get "clean" baudrates like 19200, 9600 bps... on the card is a 4 MHz crystall installed, with clock dividers (74LS74). More Re-Engineering needed 🙂
  14. There´s another possible way for future revisions: Generating one´s own PHI2 signal 😀 Mostly all modern, external (cartridges, PBI devices etc.) solutions use the monovibrator-circuit with the 74HCT123/74LS123 to get a shortened PHI2 high phase. This is needed when modern, fast switching chips like FPGA, CPLD and even the old GALs are used together with "modern", much faster SRAMs, EEPROMs or Flash-Chips. Together with the shortened PHI2 phase all write accesses to external chips etc. are made more safe when the devices sampling the state of the databuss at the falling edge of PHI2. Also mostly all these solutions (incl. myself) didn´t use the second monovibrator provided with these 74s TTL logic IC. So I suggest to use it for all upcoming cartridge solutions and let generate two "new" PHI2 signals: 1. The shortened one as usual (approx 170nS "high" phase) 2. A standard one with approx. 220-230ns. The "new standard" PHI2 is used for all logic on the cartridge instead of the PHI2 (or RAS) coming from the mainboard. This should cure all these problems and also the cartridge should be work in ALL computers without modding or cutting any traces. I will do some experiments, but I´m sure 220nS should be enough for all read operations. When upcoming cartridges uses something like that, then it doesn´t care if the real PHI2 or RAS is present at the cartridge port. The rising edge of PHI2 and RAS are nearly equal with a slightly difference of max. 10nS - that´s fine.
  15. Sorry for late response. I wasn´t sure, so I check out a real, unmodified Atari 400: This is what you get on pin "S" of the 400´s cartridge port - clearly a RAS signal. Personally I never said something about the 400, because at the time I wrote the thread "how to patch the Atari 800 to make myIDE2 run" the The!Cart (version 1) won´t fit in the 400. After all, the schematics in the "Atari 400 and 800 field service manual" (see Atarimania etc.) also states, that "RASTIME" is connected to pin "S" instead of PHI2 (O2). So IMHO you need to patch the 400 the same way to make The!Cart V2 and others work, independent from the question of size.
×
×
  • Create New...