MrMartian

I for one, would love to have them. I'm always playing around with the firmwares in my drives trying to tweak them and add little features.. Having more to look through would be great!

Turns out that there just isn't enough pins on this chip to get the job done. I can do non-Antic switching just fine, but I won't be able to add in the Antic part unless I use a larger chip, which basically necessitates me going to a small circuit board.. I'll look into what the cost would be to have this, and see what kind of interest there would be.

Hello all, I'm developing a memory upgrade for the XL and XEGS, adding 1M of extended memory that is CPU/Antic banking compatible.. What I need is, a demo or game that quickly shows if the separate Antic access is working! I know I could code something up to check it, but if there is a readily available program that proves it out for me, it'd be easier.. (And I can spend more time on hardware!) Thanks!

I know there is a Atari genius here in the Netherlands, called Mathy van Nisselroy. He designed a 1MB upgrade for XEGS. The last news I heard about it was in 2002... and that was that it was 99% ok, but not 100% compatible or something like it. Perhaps it is 100% now? Ah here is the link: http://www.mathyvannisselroy.nl/ I'm not sure if it is on his site... but I think it is. Have fun! Marius I'm 90% done designing a 1M upgrade based off this design and Bob Wooley's , that will work in an XL, XE, or XEGS, based on a single GAL22V10. One chip, one simm, and you're done! I hope to release this by the weekend. I have it working in my 1200XL (the extra ram works, I'm trying to make it Antic compatible at the moment). There will likely be two different versions of the chip, depending on whether or not you have a FREDDIE chip...

Sorry, no. Only what I've figured out myself.

I built my own SIO2SD interface, and I notice that sometimes (seems to be after I'm in the config menu) the device won't boot up properly. As in, I'll turn my Atari on, and I get no display on the LCD, except backlight and a slight greying on the first line.. (Typical response from an initialized LCD). Often the light for the SD card access will be on (and stay on, no flickering)... It won't come back to life for me until I erase and reprogram the ATMEGA.. Possibly there is something being saved into the EEPROM incorrectly, causing the device to not boot properly? It'd be nice to be able to see the source code for the SIO2SD!

Actually, this reminds me that the Ultraspeed+ OS has some kind of disk menu installer in it too. I've never seen it, so I guess I'll throw it back into a system and check it out. I'll let you know what it works like.. (Unless somebody else beats me to it!)

That's kinda sucky. I guess at the time, that was the only thing, but... ICD put the option there for it to be used!

I've basically re-written a whole new firmware for the drive. So, it isn't so much of a patch for ultraspeed, but I put that feature in what I made. But, since I could never seem to get it work, I figured I didn't understand exactly what was going on, and gave up.. Now that I actually have it working, I'm back to working on the features I had originally planned. I didn't bother with the printer support in it, since I wanted to use the ram as a track buffer. It will work in single, enhanced, and double.

Well, one problem I found with my CSS OS+, is the ultraspeed routines seem to ignore the actual speed byte returned by the drive. As long as it ACKs the command, it assumes $0A. Could never figure out why the replacement rom I made up for my Trak to add ultraspeed, never seemed to work, until I found out (from [email protected]) that this bug existed! Note, this also keeps APE from functioning at ultraspeed. Does anyone have a dump of the OS itself, so that it can be patched? I miss a lot of the functionality of this OS, but with that bug, it's really unusable..

I had been wondering about this same question! I've just gotten back into my Ataris after years away, and I'm happy to find this forum! I had read in another post (but can't find it with the search) about someone changing out the the 7805's in the power supply with little switchers. I've used these power supply chips myself, and would like to do this mod, but one question.. Is there a reason to keep the two supplies separate, or was it just done to split the current, and I should be fine just bridging them?

There are many ways to determine the "bitness" of a processor, and it can often be different than that of the system. The best way is to look at the register model of a processor itself. In this way, the 68000 (in fact, all the 680x0 family) is 32-bit. All the data and address registers are 32-bit, and all programming is done to a 32-bit model. The fact that the 68000 only brings out a 16-bit data bus, and 24-bit address bus, is only a price consideration, especially for the era it came out in. There was even a 68008, which had an 8-bit data bus, for even lower cost systems. Because the programming model was always 32-bit from the start, programs didn't need to be re-written to take advantage of more addressing space, etc, when newer processors came out. (Except for the people who used the upper 8 bits of an address register to hold extra information, which was just a dumb idea from the start) So, the ST designation came from it being a 16-bit system (due to the external bus of the 68000) with a 32-bit processor. The TT is truly a 32-bit system with a 32-bit processor.

Yes, with RAM there are many issues that can occur with regards to speed. Since RAS and CAS are used as strobes to latch in memory addresses, as well as selecting refresh on some chips, holding one of them on for a very long time (at least to what the chip is designed for.. ) can result in some other function being selected other than just plain reading an address.

As far as EPROMs go, there would never be a problem going with a faster one. The speed of an EPROM is the maximum amount of time after you ask for a certain address, until the data the valid. It doesn't matter how long after that you actually read the data.