-
Content Count
935 -
Joined
-
Last visited
Content Type
Profiles
Member Map
Forums
Blogs
Gallery
Calendar
Store
Everything posted by sup8pdct
-
If you went off the indus 1.1 rom, it did have a problem with enhanced density. Not sure about 1.2 tho it may or may not have a problem with enhanced density. one or both versions had a problem with the mapping of the letters or numbers sent to the led display. 1.4 had all problems fixed. James
-
Well done a true hacker My hat off to you sir. I would like both when you have done the schematics . 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. It isn't commented very well at all. only what I could figure out. It assembles with no errors and have done a brief check to make sure it assembles correctly. I had it once till a problem occurred and lost half of it. lucky i still had the original dissembly output and have redone it. James usd_source.txt
-
Is it true that the indus inverts the data from the atari on the sio buss? I am not 100% on this. also is the FDC used in the indus the inverting data type? well done. I have the USD rom disassembled here. want a copy of it? James.
-
New web site - SIO2PC Hardware and more
sup8pdct replied to atari8warez's topic in Atari 8-Bit Computers
That's of course a choice you can make. I simply wouldn't tie the worthiness of whatever they are doing simply on their choice of browser support, but that's me anyway. Just an interesting note. On tomshardware, a survey was taken on which browser people use. Firefox come out just ahead by .1% or some small figure like that. James -
software for cartridge dumping with The Pill!
sup8pdct replied to JamesTheOrangeCat's topic in Atari 8-Bit Computers
As far as I know, Zybex uses ram under the OS rom so the only use of the $D1xx area is to turn off the os rom. The cart line is the $D5xx area. I comes directly from a 74LS138 chip that selects all the hardware chips except Antic. The Pill sounds a lot like what we have here in Australia called the cramp board. It is a very simple bit of hardware that has a latch and some gate chip. Any writes to the cart area , the Cramp board deselects the ram in the cart area only. any reads, the ram is selected. A read or write to the $D5xx area turns on the cramp board. There is a utility that loaded the game from disk, moves it to the location in ram that the original code came from, writes to $D500 and does a warm boot. James -
Sure, but anything you put on it has to be coded for OSS's proprietary bank-switching scheme. So it wouldnt be real useful for developing stuff for "normal" atari carts (if there is such a thing.) It doesnt match the normal atari 8k/16k cart standard, nor does it match teh XEGS supercart standard. Whatever you developed for it would also have to be used on an OSS bank-switched cart. Also, as soon as you turn the power off, or un-plug the cart, it's gone.. Heres what you could do with it.. get ROM images of all the OSS cart ROMs.. and save them to your atari's hardisk. Then write a simpleprogram that switches the banks of the cart, one at a time, and writes the ROM image of whichever .ROM file you specify into the cart, in the appropriate way.. Then you could use that OSS language.. And when you want to switch, just "write" the next language into it teh same way.. You can take a normal OSS cart and stick a 27512 EPROM in it, with 2 switches, and have all 4 langauges in ROM on a single cart, hard-switchable, which makes alot mre sense and is easy to do.. This is what I have done with my OSS super cart. It has basic XL, basic XE, action and Mac65 all in one. There are 2 versions of the oss supercart. one which is very similar to the one pictured with 2 eproms and another with a single eprom. The code from each type is not interchangeable between the 2 versions, how ever, I have managed to do it with a bit of editing of the rom code. One bit has been changed in the bank switching logic so it wasn't too hard to do. Also tho I am not 100% sure on this. the 2 eprom version, the lower 4K bank could be switched off and the ram under it could be accessed. the single rom version couldn't do this. James
-
Sounds like a Stand alone test cart. There is also A Salt cart used with a external plugin board that has 4 joystick ports, a SIO port and 2 power connectors. Use short leads to connect the ports together and plug power into the external board. I have one here but have never used it. James
-
Hmm, I have the Chicago/LA/Seattle/New Yourk scenery disk with the charts. Is this thing any fun? It seems pretty slow and fugly to me. Sounds like the scenery disk that comes with FS II. There are 6 extra scenery disks, I am sure one is Japan and maybe one or 2 in Europe. James
-
What scenery disks do you have? and do they come with the charts? I have disk 3 here but need to find the charts. James
-
Yes how can we implement this mod with just a 27C32 ROM? (I assume a 27C256 can be used if you just double the image until it fills up the chip) I would like to give this a try sometime! I can't be just the ROM, as the additional ram is needed as well. The 1050 originally had only 256 bytes (128 in the RIOT, 128 in a 6810). The SA adds 2K of ram to this. It needs both. I have a small stack of 6116-like RAM, so it wasn't a problem for be to build the stack like that, but perhaps a little board could be made up to use modern available components.. The SA firmware was a tricky beast to extract for me about 15 years ago. I discovered that 1/2 the rom was copied to ram. Why? The super archiver program sends commands to the drive to modify the code that is in the 2k ram so the drive can do it's stuff. not all the ram is used. at least 256 bytes is for the sector buffer. I also discovered a command/data frame combo when send to the drive, the processor runs the small bit of code in the data frame. James
-
hmmm. maybe my 1090XL? no use for it tho what about about 1000 blank floppy's? The John Nickles Monitor for the 800. The Cramp Board. The Super E Burner. James
-
Are you asking to have physical disks mailed to you? I'd be happy to do that, but postage might not be cheap to Australia. I'm not sure if they would be of much value to you if you don't have an ATR8000. There are images available that you could use to make your own copies. The only problem is they would not be bootable on an ATR8000. All of the files on the copy would be readable, but the boot tracks probably would not. They did something really weird with their disk format on the boot tracks and I've never been able to copy that part of the disk, only write new tracks usnig the ATR8000 CP/M itself. I'm not sure if it was intended to be a form of copy protection, but it certainly works that way. It's some kind of weird combination of single density and double density tracks that is almost impossible to read or write even with very old Single Density capable Floppy controller cards in a PC. I suppose a catweasel could do it, and I've always meant to see if the Happy Discovery Cart could handle it, but I don't have an ST 5.25 drive. Anyway, if you would like me to mail the floppies to you and don't mind paying the postage, I'll do that, or I can send you the images and you can see what you can get from those first if you like. I thought electronic images of the single density disk would be sufficient. I assume the atr8000 cp/m disks are single density? James After a lot of mucking around with old stuff, I finally got teledisk and a 360K drive to work. Bad part is, the CP/M boot files don't want to write properly. the modem source disk appeared to do so. I do have an ATR8000 as well as a floppy board for the BB and several 360K and one 1.2M 5.1/4 mechs. The ATR i don't have instructions for. A quick look on the net should turn up some. re reading the failed to write disks, teledisk says the first track is 128 byte sectors and the reast are 1024 byte sectors. Very unusual to do things this way, unless teledisk didn't get it right in the first place? James
-
Are you asking to have physical disks mailed to you? I'd be happy to do that, but postage might not be cheap to Australia. I'm not sure if they would be of much value to you if you don't have an ATR8000. There are images available that you could use to make your own copies. The only problem is they would not be bootable on an ATR8000. All of the files on the copy would be readable, but the boot tracks probably would not. They did something really weird with their disk format on the boot tracks and I've never been able to copy that part of the disk, only write new tracks usnig the ATR8000 CP/M itself. I'm not sure if it was intended to be a form of copy protection, but it certainly works that way. It's some kind of weird combination of single density and double density tracks that is almost impossible to read or write even with very old Single Density capable Floppy controller cards in a PC. I suppose a catweasel could do it, and I've always meant to see if the Happy Discovery Cart could handle it, but I don't have an ST 5.25 drive. Anyway, if you would like me to mail the floppies to you and don't mind paying the postage, I'll do that, or I can send you the images and you can see what you can get from those first if you like. I thought electronic images of the single density disk would be sufficient. I assume the atr8000 cp/m disks are single density? James
-
Yes, I'd like to see that, do you have it in an electronic format? yes they are. Page 1 http://www.eftel.net.au/~sup8pdct/indus1.gif Page2 http://www.eftel.net.au/~sup8pdct/indus2.gif Page3 http://www.eftel.net.au/~sup8pdct/indus3.gif they were originally on paper size somewhere close to A3 James
-
I haven't played much at all with syncromesh with dosXL, only with spartaDosX. I have found that Syncromesh is close if not that same as the USD format disk skews and speeds. As many people know, if a high speed format disk is read at normal sio speeds, loading is much slower till the highspeed routines cut in. As for getting the Indus to format the highspeed sector layout, I think one needs to set the high bit on the command byte for the indus to format that way, after telling the drive via the percom drive control block what density to format in. Bit of a PITA i know but I haven't played with it for 15 years so memory is a bit scratchy. Bye the way, I just found my scanned schametics for the indus. any one want a copy? is 3 pages. James
-
There's no love for SuperDos, but it does need some updates for XF551 running Hyper-XF SO SuperDos only see the XF551 as 1050 just with US doubler. Hard Drive support would be nice and support for XF551 with 5.25/3.5 drives upgrades. Superdos was originally written to be a dos 2 replacement and as such has a very close memory footprint to dos2 while keeping some hidden dos 2 vectors. While the writers where at it, they added Highspeed routines to support the local 1050 upgrade plus added extra stuff in the DUP.sys menu, thus 4.3 was born. when the XF551 came out, the writers added support for it and for USD drives as well. thus 5.1 while keeping it fully compatible with dos2.0. Adding support for Hdd will require moving away from the dos 2 spec with regards to the sector link structure (AKA mydos) SuperDos was written at a time before Hdd were available for the 8-bit (if any were, they were very costly to get to australia at the time) Superdos uses it's own SIO routine for all speeds ie doesn't enable pokey interrupts but monitors them closely.so if an emulator doesn't do a proper job, the dos won't work. Every High speed dos uses a very similar type of high speed routine so it is nothing new. best way around the high speed part is to find the sio routine which is near the start of dos and put a jump to the os sio instead. james
-
could you please send me a copy of the NTSC rom? I either don't have it or all my xf551 rom images are pal. I at one time had both but finding it now....... James
-
If i Recall correctly, 1 or 2 of the early rom versions had trouble with enhanced density. Any one with a field service manual will be able to tell ya. I have one but I cannot recall where it is James
-
yes thanks/ the numbers are blurry. Interesting thing about the SA. only 2k of rom is visible at any time. First thing done is to copy the hidden half to the ram chip. Both the rom and ram are configured so that the top half of the rom then the ram chip appear in the top 4K of address space for the 6507. Very tricky. James
-
Is the MegaCD files stored in Audio format not in digital or file format??? is my understanding of the interface. But what a way to select each file, scroll through the track numbers till you get the one you want....... James
-
You are right. I have compared the Retrobit ATR file with other CP/M 2.2 editions and it seems that sectors 2 and 3, which contain a part of CP/M command processor are corrupted (128 of 256 bytes of each sector are lost). It seems that one can fix this by getting the missing pieces from a CP/M disk for a different platform (many of them are available on the Net), because the command processor is platform-independent (64kb CP/M 2.2 version is appropriate). However, writting the full 256b of sectors 1-3 to a disk can be a question here. For example, this version seems to be compatible (file diska.img is the CP/M image) I also found source code for 2.2. the very first bit looks like CP/m itself and not the bios which appears to be last. been thinking about the 256 byte write sector problem for sectors 1 -3. Maybe, just maybe some modifyed 1050's will accept 256 byte data frames for sectors 1-3 and write them out. only way is to try it and see. you will need to put values in to $300-$30B and jump to $e459. Maybe the Indus can do that as well? if not, then putting an XF551 mech into a pc and using an editor is the only way to go to fix up the disk. james
-
Yes. that is very true the reason is the longer VBI time that PAL atari's have. Funny thing is, the line drawing time For PAL Just may be a little shorter or very close to the same time compared to NTSC. due to more lines drawn for each field. Antic pads extra at the end compared to NTSC so antic register VCOUNT goes to a higher number with PAL. James
-
They do but most games and most music goes off the VBI cycle which is slower. 60 v 50 hz so game play could be slower and the music played a bit slower. Also the music pitch will be a little different. James
-
could you possiably copy the atr8000 disks with the pc and send them to me? I have compared cp/m version 2.2 from the indus atr file and some other computer and it appears that they are very much the same except for the missing data. Comparing the atr full with the indus part just may reval what is missing. Rebuilding it would be a problem....... James
