sup8pdct

Hmmm. it is actually the early version I am chasing. I already have version 7.7 It wasn't really a bug but failure to take into account that Pal pokey clocked is slightly slower hence the serial rate would be slightly slower as well. I believe that the programmer kept trying with larger loops till it worked. the programmer is in the usa so........ James

does anyone have the NTSC version of the XF551 rom? I have the Pal version but no longer have the NTSC one. Thanks in advance. James

He has committed to finish the project even with the unforeseen problems he has encounted. I believe he is studying or working so this project is an after hours job so it could take a while. I take my hat off to him for this huge undertaking. I personally found it hard enough to upgrade a 256K MIO to a 1 Meg. Many holes to clear of solder, many chips to fit then finally getting the thing to run stable. James

It appears to me that 3 ports are used. follow the traces to pins 1-4 of each joyport Purple, blue, green and yellow appears to go to joyport 3 orange red, brown, black to port 2 yellow grey brown, blue to port 1. Is how I read it. James

I personally know of at least 2 types. type 1 is a circuit board type, the keys soldered to it and the cable is mini single strand wires if memory is correct. type 2 is a steel backed mylar type with a clear flexable cable with silver tracks. Most likely there will be several variations of each type. James

It could be a parallel printer port but it could also be a port for an eprom burner. Here is Australia, an electronics mag did one that had the data lines interfaced directly to what ever held the data and the address and programming pulse were done on the burner it self. all that was required was a single pulse from the controller. In fact, one Aussie made monitor for the 800 had the software built in to use this burner. it was called the john Nichols monitor. James

I was thinking along the lines of Sparta dos 2.3, but Sparta dosX would be very low as well At least SpartadosX will work on an 800, even better if the 800 has an axlon compatiable ramdisk James

I'm not saying it won't work but still, it's not the same as this adapter. d9240-01 is actually a HEADER - the pins on both sides are not of the same shape and length. I would have thought that the larger end was soldered to the board and the smaller end would be inserted in to a chip socket. so that part would fit what he is chasing. Would certainty fit what upgrades i used to do. only problem i ever had was that the pins would break rather easily if bent a little to far. James

Check out harwin.com d9240-01 James

The nearest I have found so far is this: http://www.rsaustralia.com/cgi-bin/bv/rsww...e&Nr=avl:au catalog number 227-2639 but is a 32 pin Sil also known as a component header by this mob. Mouser dot com has it 554-ca-s32mp, but once again, is a 32 pin sil. I used to set them up in a 40 pin socket and solder them on. www.Harwin dot com part no D9240-01 is 40 pin dil version. James

In a couple of upgrades I used to do, if I wanted small one like that, I used to cut them to suit my needs. However, I don't know where they came from orignally. may be quicker in the long run to get the small one and cut it down the center and use that. James

The 1200XL is the only one that had a slightly different cart port. Look at the Magic dump cart. The 2 small cutouts match what is in all cart ports except the 1200XL. If the bit of plastic between those cutouts is to long, the cart won't fit properly. The sawen off ones i assume the ones you can see connector stickimg out of the bottom of the plastic case has been designed that way. no idea why. James

No - The nearest to that is Assembler editor. The list is in alphabetical order so it's easy to scan for a cart. - PJ I will have to see if I can find it. Thought I had some instructions for it as well. May take me a while to dig it up. James

with the chips shown, the max ram this upgrade has is 256 bytes total, unless the right hand chip has another one under it or the rom has ram under it. SA has 2k ram but it also has only a 6507 processor. James

did it have more ram then what is shown? James

I haven't looked right through the whole list, but is edit 6502 in the list? no idea who made this cart. It also has a disassembler disk file as well. I used to have it long time ago. James

not very interesting at all. the switch switches between the floppys and also switches the drive os over as well. a far better upgrade for the xf551 is the duel drive upgrade from CSS. James

Not all 400/800 have a std 6502. I have 2 800 and 1 400 that use the 6502C , the one with the added Halt pin. All of them are PAL too. Early 400/800 did use the std 6502 with extra buffer chips to isolate the processor when antic wanted the buss. I bought and recieved a NTSC version of the processor board thinking I would get a std 6502. I got one with a 6502C instead James

There were several upgrades for the 800 that went into the 3rd memory slot. one was an 80 coloum card from Bit3 I think there was some sort of storage card as well. saw an add in an early mag but not much else about it. With one memory slot taken, one of the other 2 had to have 32K. the Middle ram slot was capable of handling 32k with a 16K board in the first slot. also, the atari 400 could also take the 32K card with no mods. The 800 by design can only have 48K of ram normally but there are mods to get around this limit. James I'm looking at the packaging/docs from one of these right now... In addition to James' excellent answer, early 800's were sold with only 16K, and I've heard that early, early models came with 8K. So you could upgrade as ram became cheaper by adding 2, 16K boards or 1, 32K board. 32K boards in general were cheaper than 2, 16K boards, had less RFI, and supposedly ran cooler. (?) For sure, heat was an issue if you had 3 ram boards + the OS board in the RFI shields/covers. The premier memory upgrade was of course the Axlon Ramdisk 128K board. Probably second was the Mosaic 64K board. There were a bunch of 32K boards from 3rd party suppliers. -Larry Just on the heat issue, I directive came from atari about the 800 and the covers on the ram boards. If any computer came in, remove the covers to stop possible problems with heat build up. Later atari 800's had fully populated ram. all covers were absent, the boards were held in place by a single plastic spacer that went across the top of the boards. also the black clips along the sides of the case that held the plastic covers is also missing. The top cover was held by 2 screws, not those little plastic locking clips. James

Almost but not quite right. True the DCB is used for Highspeed SIO but each high speed dos has it's own highspeed SIO routine. Basicly, it doesn't use the IRQ vector unlike the OS SIO routine but instead monintors it in a tight loop. It is this high speed routine that trips up most atari emulators by the way. James

There were several upgrades for the 800 that went into the 3rd memory slot. one was an 80 coloum card from Bit3 I think there was some sort of storage card as well. saw an add in an early mag but not much else about it. With one memory slot taken, one of the other 2 had to have 32K. the Middle ram slot was capable of handling 32k with a 16K board in the first slot. also, the atari 400 could also take the 32K card with no mods. The 800 by design can only have 48K of ram normally but there are mods to get around this limit. James

So far, the newest version anyone has seems to be this 1.2, so I'm going to re-do my routines based on this firmware. I can tell it supports ED properly, and if haven't seen any issues with your display, I'm going to expect this version doesn't have a bug there either! I'm not sure how they expected Syncromesh to ever work.. 52Kbps is not too hard to get out of the Z80, and I could possibly get a little higher, but I can't see 78K!! If you read through the forums, you will find that the syncromesh code is actually uploaded to the drive. any SDX user will be able to get the indus.com file from the cart and send it to ya. A version of dosXL? also has the code tho it may or maynot be the same as the one in SDX. The code works very well too as I have tried it many times. James

After a lot of digging, I have finally found the changes for the pal/ntsc xf551 roms. At least I hope these are the differences. Could someone please let me know if they are part of the xf sio routine. $9af was $99 change to $24 $9b0 $ef -$e0 $9e0 Was $ff -$09 9e1 ff-53 9e2 ff 08 9e3 ff c6 9e4 ff f0 9e5 ff 9a 9e6 ff cf 9e7 ff 8a 9e8 ff 10 9e9 ff 99 9ea ff e7 9eb ff 24 9ec ff b1 9f0 ff 8a 9f1 ff 30 9f2 ff 89 9f3 ff 08 9f4 ff 99 9f5 ff ef 9f6 ff 24 9f7 ff b1 Hope this is very informative. James

Nothing is inverted in this drive. AFAIK, the only drive I've seen with the inverted FDC was the 810.. Sure, I'd like a copy of your USD disassembly. I've done it a bit myself, but if someone else has already cleaned it all up and commented it, that saves me some time I can put towards other projects. after looking on other disks, I found another usd source file that I worked on that is better then the first one i posted. James usd.txt

Okay, after disassembling the various versions, I've come to a bit of a conclusion.. The file that is labelled 1.2, seems to be 1.2. The file labelled 1.4 is 1.1, and the one labelled unk (unknown?) also claims 1.2, but is different than the other 1.2.. The two that call themselves 1.2 handle enhanced density properly, so please ignore the first firmware I posted! I will try and determine the difference between the two 1.2s that I have. Also, if someone has ANY other dumps of an Indus GT rom, I'd love to see them! The version number seems to be the two bytes, four from the end of the file. The last two bytes are the checksum of the ROM. The investigation continues! It could be that I am wrong. I thought I had the latest version, but I have 1.2. maybe the rom versions were 1, 1.1 and 1.2 someone with a field service manual will be able to tell. I have one but cannot find it at all at the moment. I do know the early one did have trouble with enhanced density and a latter one had a mapping problem with the numbers/letters sent to the led display, the rom tables were adjusted to fix this problem. also a go was had at fixing the syncromesh but it didn't work. here is my 1.2 version James indus.bin