Jump to content

drac030

Members
  • Content Count

    2,598
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by drac030

  1. Yes, that's very interesting indeed. What is the type of that "slow" IDE drive?
  2. Well. It is slow, then. Hardly faster than a good serial disk drive.
  3. No, this is the side effect of the 256-byte sector emulation. IDE drives have sector size fixed at 512 bytes. The firmware stores two 256-byte sectors inside one physical sector, and so while writing 256 bytes to the media it has to do a 1024-byte I/O (read 512 - replace half - write 512). Of course, the emulation mode can be switched off. This speeds I/O up a lot. However, there is no DOS that can work with such a sector size. Yes, there is a guy who occasionally sells them on eBay or Allegro. Hmm, this is hardly believable. If the speed is measured correctly, the program must run for about 46 seconds (it first writes a 64k data file in four portions 16 each, and then reads it back). Maybe there's a bug in the program, but at the other hand all other figures look reasonably. From the bad photo I had previously, I estimated the size as 25x15x2 cm, and later from your photos I corrected this estimation to 25x15x3 cm. The real dimensions you gave are 24.13x15.875x3.302 cm. So, not bad Thank you again.
  4. Yes. If you are interested, here are the numbers for an IDE disk attached to the KMK/JŻ IDE: DOS writing: 8713.666 B/sek. DOS reading: 36714.887 B/sek. DOS average: 22714.276 B/sek. Could you please yet tell me, what are the dimensions of the Multi I/O?
  5. No, these pics are just great. Thank you. As about "anything else", can you please, if possible, tell me how does this device perform as a harddisk interface? I mainly mean the I/O speed. Specifically, if you could run this program: http://drac030.krap.pl/rwtest.arc and tell me, what did it report, it would be great. Also, I'd like to hear more about that video port.
  6. Could you please make a few good photos of that device and send to me? I need them to a web-based article about Multi I/O, and it seems that the board is so rare, that even photos are almost nowhere to be found - and a photo I found has very low quality. Until I found that one I even had no idea how does the MIO look like.
  7. Does anyone here have the ICD Multi I/O board for Atari XL/XE, and/or have some nice high-resolution and good quality photos of this?
  8. For that matter, every XL/XE computer works without the keyboard plugged in
  9. There are more differences. Early XEs (both 130XE and 65XE models) had the "on-springs" type of keyboards, with green membrane and a spring under each key. While typing, tt feels much like 1040ST keyboard. The keys on such a keyboard often get yellow after some 10 years. It seems that all late XE computers (which probably includes all 800XEs ever produced) have some other, crap type of keyboard (called "gum" keyboard). The look is alike, but there are no springs and the membrane has no colour (it is transparent), and they also have "MADE IN CHINA" written on them. Typing on this is much less convenient, than on the other type. The keys don't get yellow, at least I never saw such a phenomenon on such a keyboard. Also, in the first type, and also some keyboards of the second type, the keys are made from two kinds of plastic: the key itself is white, and the character is made from plastic of a darker colour and grouted into the key. On chinese keyboards the characters are simply printed on the white plastic, so that after some time they tend to disappear on more often used keys (like Control or Return). My 65XE has the first type of the keyboard (springs, green membrane, grouted characters). My 800XE has the second type (no springs, transparent membrane, printed characters). My 130XE has the same as the 800XE, the only difference is that the characters are grouted.
  10. Yes, "sent" is to be understood litterally, as "transmitted out completely over the line to the other side". Some guy here says he tried; he says it didn't work. But he might have overlooked something. CLOCK OUT is said to be active. From what I was told, it is used by some third party disk drives to detect the US Doubler protocol. I can't verify it myself, I don't construct disk drives, I don't have an oscilloscope etc.
  11. Sure, you have to wait. Your device is supposed to change the speed not sooner than after it sent the first ack replying to a command where the command byte has bit 7 set. Edit: unless you can somehow externally convince the computer's Pokey to change the speed. You could then change the transfer speed almost at any time you could want. Pokey has a CLOCK INPUT line, but honestly I don't know if it could be of any use.
  12. First, you must decide which high speed protocol you want to use. SpartaDOS X supports three of them, US Doubler, XF-551 and Indus. The easiest to implement is the US Doubler protocol, but Indus is faster (this does 68,2 kbps, while for the US Doubler the SpartaDOS X routines use fixed baud rate of 52 kbps). Once you decide on the protocol, you simply implement it, and that's all. I admit, that you rather need a detailed description, and won't do much with trial and error. If you understand C, perhaps this will help you: http://drac030.krap.pl/sio2bsd.tar.gz
  13. There's currently no English version of that article. There are no reliable translating programs / engines available either (AFAIK). You can of course always ask a human to convert that into English.
  14. $D3, as you already figured out, is the STATUS code for XF-551. The rest you listed is loading Synchromesh routines into LDW 2000 Super (or Indus GT). You can safely ignore this, unless you are going to emulate these drives.
  15. It doesn't do it the way you apparently think of. To repeat the answer to your initial question, the Atari 1450XL OS ROM rev. BB 02.03 dated 21.06.1984 - does not contain references to any extra hardware. It uses the normal (in XL series) parallel bus device interface to invoke extra ROM handlers.
  16. I'd say that it is the other way around: * European (PAL) computers are 1,773 MHz * US (NTSC) computers are 1,789 MHz
  17. It did not. I suppose that the custom hardware was designed as "external" (to the OS) PBI devices - the OS ROM itself does not contain any references to any other hardware than in 800XL.
  18. I don't think that this is necessary. At last, Atari development didn't require a PC in eighties, so it doesn't now either. MAC/65 4.20 is still an excellent assembler. Also MAE is good (it has a bit worse compiler, but at the other hand features a very convenient editor, a full screen debugger and - last but not least - it knows about 65c816 if that matters). For learning machine code: simply get a book about 6502. You can also consider browsing the Western Design Center site - I saw there a programmer's manual for 65c816 (in PDF format), maybe they also have something about mere 65c02. Also, you can consider getting a disk drive for your 65XE - and maybe a hard drive too.
  19. What does that mean in practice? I never used DOS 3, I'm going by this quote from Antic, July 1985: "The DOS 3.0 file management is a more serious flaw. It stores files in "blocks" of 1024 bytes as opposed to the DOS 2 (and compatibles') 128 byte "sectors." This can be wastefully inefficient. If you save a file of 1025 bytes (one block plus one byte), DOS 3 will save it as 2 blocks, wasting 1023 bytes of disk space!" Well, the text you quote is correct: "it CAN BE wastefully inefficient". Probably, for short files it just is wastefully inefficient, however, I guess that DOS 3.0, at the other hand, allows you to use the 16 data sectors which are not accessible under DOS 2.5 The rest depends on the actual filesystem used. I don't know anything about the DOS 3.0, but the DOS 2.0 FS can be wastefully inefficient (space-wise) too. On a diskette you get 1040 sectors, 128 bytes each, however, about 3k of this capacity is taken by sector links, 2k you loose because the FS is only capable to map 1024 sectors, yet 1 k is taken by fixed-size directory, not to mention the VTOC and boot sectors. The diskette's capacity is 130k, but you can store only 123k of your data on it; ideally, that is, or in one file. Under DOS 3.0 you could probably save a file few kB longer, to the same diskette. The DOS 2.0 FS may perform well with short files, but comparing with SpartaDOS FS it is probably more wasteful for long files. On DOS 2.5 this is not a problem, because it is by design limited to small media. However, MyDOS continues the same filesystem concept, with 3-byte sector link. Despite the fact, that this linkage goes only one direction (from the begin of the file to the end, but there's no way back), it takes more place than on SpartaDOS filesystem, where the sector link is 2-byte long (and it goes both directions). So imagine a file that is 8 MB long (perfectly possible on a 16 MB disk, both MyDOS and SpartaDOS can do this). 8 MB is 8388608 bytes. On SpartaDOS FS it will take 32768 data sectors. Apart of this, the file map will take additional 66580 bytes, i.e. 261 sectors. The total of allocated space is 33029 sectors, i.e. 8257,25 kilobytes. Out of that, 8192 kilobytes, i.e. 99,21 %, is the actual data. On MyDOS the file will be mapped to 33157 sectors, i.e. 8289,25 kilobytes; out of that 98,82% is the actual data. This is exactly 32 kB, i.e. 128 sectors, more than on SpartaDOS. Not to mention such a detail, that under MyDOS such a big file is a nonsense, because you do not have any possibility to randomly access it; to read the last byte, you have simply to read the entire file, 8 MB of data. With fastest hard drive known to me you can attach to the Atari, you could do such a "seek" in about 3 min. (yes, three minutes). At the other hand, SpartaDOS can seek from the begin of the file to the end and back (i.e. 16 MB seek), in 3-4 seconds. At the other hand, 1-byte file saved by MyDOS takes 1 sector, and 2 sectors on SpartaDOS (I have no idea, how much sectors allocates MyDOS for a zero-length file, Sparta allocates two IIRC). 254-byte file on SpartaDOS still takes 2 sectors, and so does on MyDOS. 257-byte file still takes 2 sectors on MyDOS, but three on Sparta. And so on - until around 21k (21759 bytes, if I calculate correctly), at what file size the SpartaDOS filesystem starts to be less wasteful than MyDOS.
  20. Yes. 8 sectors, 128 bytes each, per one block; more like a cluster actually. This finally allowed to use all the 1040 sectors on 1050 dual density disks. However, I have no detailed description of DOS 3 filesystem, and I don't have any information on DOS 4 filesystem - does anyone know an URL?
  21. SpartaDOS X 4.2x. Advanced memory management, low memory requirements, native relocatable file formats, powerful filesystem, great I/O library, path searching, up to 1423 (one thousand four hundred twenty three) files per subdirectory, convenient and configurable UI, tons of utility programs. The SpartaDOS is perhaps the only DOS on Ataris that provides real seek(), thus allowing trurly free access to any file location at any time. The next one is MyDOS - eventhough it doesn't have even a fraction of the power that SpartaDOS X offers - it is very close to SpartaDOS 2.x/3.x, moreover, it is superior than SpartaDOS 3.x in such a detail that you can run Turbo BASIC XL with it. However, MyDOS has two big disadvantages: it is menu driven, which allows to load programs, but does not allow to pass command line arguments to them. The other disavantage is worse: MyDOS continues the old, primitive and wasteful filesystem invented by Atari for DOS 2.0 - thus: please get a longer file,open it, and read last 10 bytes twice; this is possible on every decent filesystem - including SpartaDOS filesystem - just not on DOS 2.0 FS. The rest is the silence.
  22. SpartaDOS X uses extra RAM to keep DOS code and data buffers (this is why the MEMLO is so low under this DOS). MAE assembler uses extra RAM to store source and symbol tables: you get 64k of free memory for source code/symbol table. It can optionally store the screen memory in extra RAM too - 8k bitmap for 64-column display.
×
×
  • Create New...