ijor

Hi Jurgen, I know it's a very old thread ... Are you sure all versions of FREDDIE are CMOS? There are at least two versions and the older one was released in 1983 for the 1400XL. And BTW, I'm pretty sure MMU and EMMU are CMOS gate arrays.

The XE was released in 85, but again, FREDDIE was released in 83 for the 1400XL. And some 130XE computers, including mine, use exactly the same FREDDIE chip that used the 1400XL. I'll ask Jurgen in the thread you linked. He might have some info. But again, there are at least two different versions of FREDDIE, so it is very possible that the newer version (and only the newer version) is CMOS. I'm sure he could repair my computer. Unfortunately I'm not located in Europe. Thanks again.

Thanks again for all the info.

Thanks for the advice. Interesting. I'm not so sure, where you read that? If you look at the values at the preliminary engineering datasheet, it seems to be an NMOS device. And 1983 was probably too early for a fast CMOS LSI anyway. Of course, the final product might be different and by 1985 CMOS fab was much more advanced. But FREDDIE was already produced for the 1400XL which was released earlier, and seems the 130XE used, at least initially, exactly the same NCR part. There is a later FREDDIE version with a different part number, conceivable could be a CMOS redesign. The chips that I'm pretty sure are CMOS gate arrays are MMU and EMMU. May be this caused some confusion? FREDDIE engineering datasheet is here: https://web.archive.org/web/20060214093449/http://www.atarimuseum.com/ahs_archives/archives/pdf/computers/8bits/freddie-mcu.pdf

Ah, you mean to update the FPGA core (firmware). Yeah, not being able to update the core without an Usb Blaster can be a problem when the product is not mature enough. In theory it should be possible, the FPGA used in the Ultimate Cart does have a method to update its own firmware. It requires a little bit more resources, but not too much. So it should be possible unless it is currently almost full (if the core is already close to 100% utilization).

I wouldn't recommend an USB Blaster clone like that one. They are all known to be problematic. Terasic official USB Blaster is available at Amazon at a reasonable price. The newer and faster Usb Blaster II is quite expensive, but there is, AFAIK, no Usb Blaster II clone. Even those that claim to be Usb Blaster II, they are actually a Usb Blaster I clone.

Sorry to ask, but I don't understand. What you mean by refresh from a file?

I stand corrected, I wasn't aware. Indeed, my PSU is precisely that mentioned in the post you linked. And yes, it is quite heavy. Surely it's filled with epoxy. But not all epoxy filled PSUs are that bad, are they? However doesn't look that my PSU suffered yet the dangerous death as mentioned in other INGOT threads. At least it seems to output a, more or less, reasonable voltage. And at least the first time, it didn't fry my computer because only one RAM chip was damaged. Of course, I didn't test yet for spikes, so the PSU might still be the culprit. And now with FREDDIE gone, I don't really know if the other chips are working or not. Difficult to test when FREDDIE doesn't produce the main system clock. Is the Ingot PSU know to produce spikes as well? Or, as reported in other threads, it's ok until something breaks inside and start outputting a crazy voltage level? Just asking to have a reasonable idea about what produced the damage in my case.

Btw, this is a 220V PSU. So no Ingot model, that I just read they are dangerous

Good tip. I measure 5.20-5.23V without load, and 5.17-5.20V with load. Detecting spikes is a little more complicated for me. Will try to hook a reasonable instrument later. More or less, but according to the calendar! But I barely use this computer. So if you ask how much time it was actually turned on between both events, I'd say just minutes, may be half an hour. Sounds too bad? Thanks again

I was performing some tests on my 130XE and suddenly it stopped working. After some diagnosis seems to be that FREDDIE is dead. At least there is a good 14.3 MHz input signal, but no 3.57 MHz output to GTIA. As a matter of fact FREDDIE pin 37 (OSC output) doesn't seem to be fully stable (guess it is floating). PSU seems to be fine. It works on a different computer. And trying a different PSU on this 130XE still gives the same, FREDDIE dead, behavior. A couple of weeks ago on of the DRAM chips died. But being an "MT" chip, known to be problematic, I didn't pay too much attention. But now I'm a little bit suspicious to get two chip deaths one after the other. Might still be the PSU, even when it seems to be working fine on another computer? Or may be it was just a coincidence and bad luck? Or this behavior is not so uncommon? Thanks

Fair enough. But in this particular case, AVG would actually be a solution to my problem. The reason I might not end buying one is because it is not open source. I don't always avoid closed source projects, but in this particular case it is important to me. As a matter of fact, being open source, I might end implementing pass through support for the Ultimate Cart myself.

Thanks. Not confusing anymore! Yeah, I watched the video embedded and then I missed the description (my fault). Not very important, but while we are here ... I don't see the SDX CAR image there? It was on another directory, or it is integrated in the hardware?

You are correct, of course, but I don't see how this is related to pass through cart support. Well, except that you obviously can't fully emulate stacking an R-Time-8 cartridge, if that's what you mean.

Very nice @tmp . Good job, seems very powerful. I wasn't aware about AVG CART. But I understand AVG CART is not open source like Ultimate Cart, is it? Also, if you don't mind, I find the video a little bit confusing regarding the operation of this feature. Do you select a secondary (connected to SDX pass through) cartridge from the AVG CART menu? What I find it confusing is the presence of the [email protected] file in the D1: directory. I would expect the cartridge image not to be visible to SDX at all. Or that file image was there just by chance without a direct relation to loading Action?

Thanks @flashjazzcat . But I understand this is only a firmware (and software) limitation, right? Seems the hardware should be capable to support SDX (virtual) pass through.

Does it support SpartaDos X pass through logic? So that you could mount another image (virtually) "on top" of the SDX image, and fall back to, say, Basic XE as you would do in real hardware with real BXE and SDX carts.

Thanks. No problem if the images are full as long as I can remove files that I don't need. Appreciate all the other ideas, but I'm not sure they fit my current goal. I need to put everything in a single normal CAR image.

Is there any tool, or just any way, to easily modify the content of the CAR: device in a SpartaDOS X image? Say, I want to put a couple of my own executables Thanks

Each type of drive has its own pros and cons... Some damaged disks can sometimes be read successfully on 96tpi drives only, and sometimes the other way around. Most, but not all, 48tpi drives can access the flippy side without index hole, while almost none 96tpi ones can. 48tpi drives are better for writing back; 96tpi drives require bulk erased disks. 96tpi drives are usually faster (360 vs 300 RPM). Oldest drives require higher current drivers. They might not work, i.e., with the simple unbuffered Greaseweazle. It could be an issue even with buffered devices if you connect multiple drives at the same time. But I guess most people just use what they have

Yes, plenty, including just plain DOS. Any disk that was originally mastered on an 810 or 1050 and didn't have its track alignment adjusted will have sectors spanning the index. Phaeron is of course, right. Furthermore. Most Atari 8-bit original disks are NOT aligned to the index hole. Even those duplicated and mastered by professional duplicators. Of course, some do are aligned. This depend mostly on the specific publisher, and also on the period. But on the earlier classic period, very few publishers duplicated disks aligned to the index hole. Notably EA disks do are aligned since day one. Synapse disks, except the latest titles are NOT aligned to the index hole. Even most Synapse titles that are among the ones with the most advanced copy protection, they still are not aligned. And that includes a couple of Synapse titles with a skew align protection!

Ok, thanks everybody for making this clear. Btw, just for my info, what about those sockets that have legs more similar to a chip. Such as this: https://www.newark.com/amp-te-connectivity/516-ag10d/dip-socket-16-position-through/dp/14F2702 Are they any better than "regular" sockets or are for special purposes? They seem to be more expensive.

That's what I thought. Many thanks. Good recommendation. Thanks.

One of the RAM chips on my 130XE stopped working correctly. Soldering is not one of my few talents, so I asked a friend to replace the chip. I thought it would be better to solder a socket instead of soldering the new RAM chip directly. He is not very familiar with old through hole systems, but said it will be ok. While desoldering the old chip he noted that it was soldered on both sides of the board. He said he won't be able to do that with the socket, and it might be then better to solder the new chip directly instead of installing a socket. Does this make any sense? Is is really important to solder the socket on the top side of the board as well? I searched and I found some special sockets that have pins like a chip, and I guess those sockets could be soldered on both sides of the board. But is this really needed, or important at all? Thanks

There is still no support for the FDC read track command and data outside the sectors. Note that as I commented already, this is not strictly required for running DiskMaster 1050. It doesn't use it as a copy protection but only for hiding part of the protection when using the program to analyze its own disk. Adding support for gap data at ATX images is not very difficult. But there are significant complications for emulating the read track command accurately, especially at MFM. The extra size required to store all the track data shouldn't be a big problem. Not only that this would be, of course, optional, but also it is possible to store full track data on specific tracks only. It's not top priority for me anyway. There are a few other issues that IMHO, are more important. E.g., we need to add support for weak bits at the header (a weak sector header). This is required for running SuperArchiver.