sup8pdct

That makes things hard then. If the bios is the first thing loaded, then again getting as far as the CP/m welcome message could mean that bios is built into the terminal screen? or the rom? wishfull thinking... James

I never would have thought that CP/M would have machine specific boot code in them. I am very well aware of syncromesh and have used MY indus with sparta dos X. just wondering what the super part was. I have pulled apart how the syncromesh works from the atari point of view. it is a lot like the XF551 high speed except the baud rate used for the sector data is at least twice the speed of the xf and about 1.4 times faster then the USD type. For those who don't know. the command frame for both the XF and syncromesh indus is sent at the normal speed but the command byte has it's highest bit set. The data frame is then sent/ received at the high baud rate. unlike the USD type where both the command and data are sent at high speed. Isn't CP/M written for the 8008 processor? which the Z80 is a copy of and much improved? James

Actually the later versions of MyDos allow up to 10 autorun files. The file can have any name but must have a .ARx extention with the files executed in order from .AR0 thru .AR9. Superdos has those things like that built in. any extention with RAM will be copied to ramdisk at boot up. A small file included renamed to autorun.sys will create a menu of basic games and will onlt show those with the extention of BAS. Aux.SYS has a menu loader for COM games it uses the first 3 sectors on disk and the last 3 sectors of the directory so the whole disk can be filled with games etc and be loaded at high speed USD compatiable drives and the XF551. James

Hmmmm. not so easy copied. there is a PAL chip on board. one must work out it,s functions first. James

I have been thinking and believe I have found what is wrong. A bit of background first. All atari 8 DD drives that I know of Will only send/receive 128 bytes of data for sectors 1, 2 and 3. this so the OS can read the boot strap routine stored on the drive to boot dos etc because the disk boot routine was written only with 128 byte segments in mind. Once the boot strap is loaded, it takes over and continues to load dos using 256 byte segments. The drive itself will write the 256 bytes for sectors 1 -3 with the 2nd 128 bytes padded out with what ever is in memory of the drive. I believe that CP/M disks are 256 byte right from sector 1 so 384 bytes of information is missing from the ATR files. ATR files I believe are setup in the same way with no space in the atr file what so ever for the extra data at all. What you will need to do is to get a disk from another source or an image file that can be written with a 360K mech connected to the pc. Maybe someone with an ATR8000 cpm disk could help you out. By the way, What does the Super sincromesh disk do? James

Just a question. have you tried the ramcharger util disk?? James

More things are stirring in my old memory again. There is a key combation that would make the drive read the disk to determine the density. I think the one of which you speak is the one. Also. have you tried the cp/m disks with REV B atari os (atari800)? Just a thought. James

That is correct . the self diagnosis is started by holding some buttons down while turning on the drive. i think it is 3 of them. I must find the details about the shorting plug it would help too. Not surprised the diagnosis doesn't like ape. it sends many strange commands to the indus. James

hmmmm. Things are starting to stir in my old memory. Go here http://ape.dyndns.org:8083/BRADFORD/ and download the INDUSGTD.ATR file it is the indus gt diagnostic disk. no idea if it includes ramcharger testing or not. Another thing is if a couple of buttons are pressed while turning on the drive, a self diagnostic mode is turned on. There is a short and a long version. the long version needs a special SIO shorting plug. I have here somewhere a book and schematics. Will need to dig very hard to find them tho. James

Can you please name the chips on the board? I can make out 3 ls chips and the ram chips 74LS244 74LS157 x 2 the orange one is a resistor network of some type. A schametic would be nice too james

I have one of those. I think the reason is on the 5.25 mech high density has 80 tracks, normal density has only 40 tracks. That would make the tracks on the disk narrower, the read/write head also narrower. For a 1.2m mech to read 360K disks, it would have to step twice. also more accuracy is needed to properly Aline the tracks etc so Mr Puff didn't bother with that.

I once had a lady come to me for help with her XF551 drive. She know it was the problem because a printer connected to the other side didn't work where it did when connected first. She even sent to drive to atari australia to be fixed and they said there isn't a problem with the drive. Earlier I tested the computer with my drives and proved that the computer wasn't at fault. When I got the drive, the power plug and the sio plugs had broken solder joints. the power plug was so bad that it would move around a lot and power the drive intermittently. The hole was so large on the power plug, I had to solder a flat washer over the pin to the mother board to fix it. also had to use some small screws and nuts to hold the sio connectors down. The sad part was that she was writing a book. with the drive out of action she would write out each chapter and print it. several days/weeks latter if a mistake was found, she would re write out the whole chapter again.......... James

Mine has: 72R DA 16024 213 made in taiwan sticker inside has May 23 1983 stuck on under side next to SIO port Sticker near keyboard conn DA 203 Rev A roms in 24 pin sockets etched 1083 James

Pete, what you are saying is wrong. There is NO WAY to operate a RGB monitor with the Atari 8bit hardware. It's only output is TV, Composite or S-Video. RGB is a very different approach to bring the picture on the screen. Just using a monitor which supports S-Video as well as RGB does not make my Atari produce a RGB picture. The various S-Video upgrades you are talking about only improve the existing S-Video signal. But this does not make a RGB upgrade. If you have ever seen the difference between S-Video and RGB then you would know, what I'm talking about. This also does not require new ANTIC/GTIA video modes. I only want my games, demos and applications with a clear screen as I know it the Amiga or Atari ST. With the right adapters you even could double the 15khz RGB to 30 kHz which then would allow to operate even most up-to-date TFT screens. Again, I'm not talking about converting an existing S-Video signal to RGB. The Video Board XE itself produces the RGB signals without any S-Video at all!! The result is perfect crips very sharp picture with absolutely zero artefacting! grtx, \twh::taos Hold on there. There has been an RBG output mode done for the 8 bit. it required several wires,a buffer chip and a monintor that could handle TV like scan and refresh rates. I believe bob wooly did one for his 1200XL but i could be wrong. I tried it, it wasn't the best but it did work. James

The Longbeach collection, 400/800 processor card. It has the atari 6502C version of the processor, the one atari made with an added HALT signal. Earlier versions had a 6502B that had extra chips to isolate the 6502 when ANTIC wanted the buss. On the card pictured on the right hand side is extra space for crystal and components for the PAL version. James

Yes, it would be interesting, I'll email you. And yes, following the XF551 ROM code is not easy at all. The code must be complicated for overcoming the lack of RAM. That's why I thought initially it doesn't verify the checksum. Btw, it is interesting that the CSS ROM has the same PAL issue. It means it wasn't coded from scratch, but they just modified the copyrighted Atari ROM There is a very big difference between the orignal atari rom and the CSS one. Where the atari rom has quite a bit of space, the css one has a lot less. As for the modual, Would say there is some code in it somewhere that checks to see if it is there. finding it is the hard part. James

8 bits of multiplexed (row and column) adressing gets you 64k. 9 bits gets you 256k.. 10 bits gets you 1 meg.. If ANTIC is unable to generate the required number of bits of ROW adress setups for "RAS only" refresh, then you can either: a)add your own additional binary counter circuitry to create the needed number of bits of ROW adress setups on the refresh cycle. One final question. How does the Ras refresh work? Is Ras held high or low and the 7/8/9 etc bits pulsed or what? James

.com and .xex files are the same thing? I didn't know that! Thanks For ATR files I recommend fantastic plugin for Total Commander written by Pajero! (TOTAL COMMANDER ATR PLUGIN v1.5) You Can find it -> http://madteam.atari8.info/index.php?prod=uzytki It looks nice but I cannot read polish and the 2 translators had trouble. so how does one use it? James

One I can name is the shape of the plastic surround on the cartridge port is different. where all other atari 8 bit cartridge ports have 2 raised type fingers on the front/top side where the cart pushes home, the 1200XL has a whole block between the 2 fingers. This means that some 3rd party carts won't plug in unless a section is cut away between 2 slots on the front of the cart. James

The 8bit vs 9bit refresh cycle has nothing to do with the scan rate or system clock. What it does mean is that using "RAS only REFRESH" which is one of two methods supported by most 8-bit DRAMs of the day, the 1200XL ANTIC could only refresh 64k of memory. The later ANTIC used in the 800XL, 65XE, 800XE, XEGS and 130XE machines generated refresh adress "setups" for 256k or (or 9 bits of "ROWS") on the "RAS only refresh" cycle. This is the reason that if you want to upgrade a 1200XL past 64k, you need to either 1) replace the antic with a newer (9-bit refresh) part, or 2)create your own circuit to add the extra bit of "ROW setup" on the refresh cycle. This is the reason that the RAMBO XL has jumper settings for 1200XL... Since the 400, 800 and 1200XL were never sold in Europe, it's probably a safe bet that all PAL ANTIC chips are 9-bit refresh (eg. 800XL, 130XE, etc. which were quite popular in Europe.) The older ANTIC "D" (CO12296 NTSC, CO14887 PAL) generates a 7-bit row address. The newer ANTIC "E" (CO21697 NTSC, CO21698 PAL) generates an 8-bit row address. But it's moot if you use the newer RAS-only on newer 256K/1Mbit DRAMs. I stand...... errrm..... Sit corrected:) Hmmmm. wouldn't the 1200xl have the new antic because it's 64K chips has 8 row address lines? The 400/800 use 16K chips which only have 7 address lines but then what about 265k ram upgrades for the 800 and 48K using 64K chips for the 400? James

The difference between the old antic and the new antic as far as I know is the old antic has an 8 bit refresh cycle and the new one has a 9 bit refresh cycle. What it actually means, I am not sure. maybe the new Antic interrupts the 6502 less for memory refresh compared to the old one. To convert an NTSC machine to PAL, one needs to add a second crystal with a 74LS74 chip and replace the existing one with one slightly faster? or is it slower? In the 1200XL, this will be a chore as there is no provision on the motherboard for the PAL circuitry. Also the modulator will need to be replaced. james

I have the rom files here of the CSS duel drive upgrade 1.2 and 1.3. The 1.2 is the NTSC version and the 1.3 is the one fixed up to work on PAL and should work on NTSC as well. You want to look at them? I thought I had the ver 7.0 here somewhere but will have to dig deeper. email me at [email protected] James

Just in case somebody is interested on how this is implemented: Imagine you have a similar task in a 1050. You are receving a double density sector, 256 bytes. You have no more RAM, the 1050 has just 256 bytes. All your registers are busy with some data, including the SP. All the I/O registers available are also busy. No place at all to store another byte! You hold the computed checksum in the accumulator. You are receiving serially the checksum at bit 6 of the RIOT... This is, more or less, the equivalent 650X code: Very clever. Have you seen the CSS single and duel drive upgrade? It has a completly rewritten rom and a small module with several wires. The modual on the duel drive upgrade also enables the 2nd drive. Without this modual the upgraded rom wont work. There is a hell of a lot of code to go through just to find the revelent bits of code to delete out. I had a look but not understanding the 8050 rom code very well meant i couldn't find it. James James

I can also take the uncovered modules from my 800 and replace them with the covered ones and my 800 should still work fine, I believe The ones with covers clip into plastic bits on the sides of the case. The ones without covers are held with a single plastic spacer across the top of all boards. It is best to stop all boards from moving or contact problems will arise due to movement and weird faults and hangups will happen. James

Interesting. Do you happen to still have the difference between both versions? I suspect it wasn't exactly that they didn't take the PAL timing in account, it was probably a bug. The difference between PAL and NTSC clocks is quite small, less than 1%. This is not too significant for async serial that has a much higher tolerance. Now, if my math is correct, a bug in the ROM making the "bit loop" one cycle faster would still (barely) work with NTSC computers. But it would quite off from nominal, that when you add the PAL difference it then would break. Checking the ROM does look like there is a serial routine patched. Hmm, the most "basic" MCU I ever worked with, was the 8051. But it now feels like the ultimate powerful micro in comparison with the 48 used in the XF551 Not at the moment. That is what I figured was wrong in the first place. they programmed it and made loops etc bigger till it worked Also, at what clock speed is the 8050 in the XF551 clocked at? I think it was 8Mhz. Are you at all familer with the 8040/50? it only has 256 bytes of memory and in that are some pointers are kept, so how is a full DD sector buffered? James