Larry

I *think* that the overclock and High Density data rate would not enter into it, because there is no actual disk reading/writing involved. I do wonder about the "native" emulated format of 160 tracks X 9 sectors per track X 512 bytes/sector (instead of 256)? So I wonder also if some of these are adjustable in the format to accomodate 256 bytes/sector. Shades of the MIO years ago!

And I'm not referring to an S-Drive or SIO2SD. This would be a hybrid drive -- electronics from the XF and the replacement mechanism from the emulator. Seems as if it could be used as a replacement mechanism for the 720K drives in an XF551 (with XFfirmware upgraded to 720K)? Has anyone ever done any research on this or perhaps has one in use? As I understand how it works, it seems feasible. The USB stick or SD card would be formatted as 100 or so 720K floppies. Then the regular Atari firmware would be used to treat it as a FDD for R/W and Atari format. Of course, not as handy as a S-Drive or such, but as a replacement for a dead 720K drive in an XF551, might be useful. And of course, just because we can -- maybe. Any thoughts? -Larry Edit: What-if: since this would seem to solve some of the issues of using a 1.44 high density drive in the XF551, it seems like possibly the XF551 rom could be altered so that the XF could recognize the total capacity of the 1.44. (?)

Thanks. Please let us know how this experiment goes. Are the plastics used for parts production pretty sturdy? My only experience with 3D pieces is my UNO Cart with a 3D shell. Seems sturdy, but then it is a very simple shape and pretty thick. -Larry

The guy is selling a file for a 3D printable version of the SIO plug? Or?

Maybe a dumb question, but did anyone ever build a hardwired version of this to an Android phone? Would use an SIO2PC-usb with a mini connector? Could use handshake and eliminate all the dropouts? -Larry

I thought I might give this another whirl since I've got a spare Android phone now. My initial tests did not go particularly well, but that was a couple of years ago, I believe, so they may have been some progress. I'll be using Mr-Atari's MyBios as the OS. I have to buy a new module, having lost my original, and they seem to range from a little over $1 to about $15 or so. Is there any difference -- do any modules work better than others? I know that with regular BT audio, there can be a big difference in latency, so if you are watching TV, the sound is not in sync with the picture. Anything like that that might affect use with the Atari? I'd be happy to pay more if it will work better. Anyway, if anyone has a suggestion of one that works really well, I'd live to hear about it. Edit: I see that some of these are listed as HC05 and some as HC06. Does this make any difference for our use? Thanks, Larry

Are you "direct connected" with the SIO2PC? A problem with the 2nd SIO port on the 1050 (rare) would cause the SIO2PC to fail. Also I ask because with a regular 1489 setup, I could not daisy chain. 1489C or Max232 chained fine. Got that tip from Steve many years ago when I first started with APE. Did you try APE? As best I can see in your answers, you never replied to that. Did you try AspeQt? Do you have an old laptop or another desktop (with a serial port) that has XP? XP is pretty much bullet-proof with APE in my experience. It would be nice to rule in or out hardware or cables. If I were to bet, I'd bet on Win10 being the issue. -Larry

Nice, useful update. Good photos -- may have to add one to mine! -Larry

Didn't you file a PayPal complaint?

I've been working with both AspeQt and RespeQt on this drag and drop issue. I'm puzzled by lack of responses that either it works or doesn't work for others here (save rdea6). And when I say works, I'd mean "bullet-proof" -- 10 times out of 10. Sometimes I must drag the same image multiple times before it will "stick." Mostly instead of the "+" symbol that means it will be added, I get the circle with the line through it, meaning it won't. I've seen this same issue on both Win7 and XP. AspeQt works more often than RespeQt, but even it is not really reliable. Maybe I'm the only one that sees this? Maybe there are very few AspeQt/RespeQt users? -Larry

I have not found information on how to "unlock" this IDC header, and I'm very reluctant to try to desolder the pins on it with the very fine traces on the IDE+2. (If anyone ever buys this header, it would be great if they could post a picture of how the pieces lock together.) But I came up with a solution. Since the cable supplied is fairly long, and it takes "abuse" at the computer end (attaching and detaching), I reasoned that the damage must be at that end. So I cut several inches off the cable and attached a new piece with conventional IDC's. I don't like the idea of the additional connectors on the cable, but it passes successive runs of RWCRC (from drac030) with zero errors. As a bonus, since the new piece will now take the stresses of un/plugging at the PBI, it will be very easy to replace if the issue crops up again in the similar location. And fortunately, this fix did cure my problem! -Larry

Hi- How would you do a low-level format on an SD or CF card to 256 bytes/sector? Not saying it couldn't be done, but I'm not familiar with a tool to do it. You're right about the MIO, but it does perform quite a bit better with the new rom. I don't think you could run one of these devices with the old rom, anyway, but I admit I never tried. -Larry

I've seen this device before, but I don't have one. However it looks very similar to the "Aztec Monster" and (now very pricey) Acard 77xx series of SCSI emulators. I'm pretty sure that I used the Aztec Monster with an SD card via adapter, but not positive. I've run both the above with my Black Box systems for years. It is a bit tricky to set up, but those devices both work fine, so I would think that yours would also. You should not need to do a low-level format (I never did -- since the BB will accept 512-byte sectors and then create 2-256 byte sectors from them.) Hopefully the files in this zip will help with your setup, even though a different device: How to Set Up the Acard with BB (or MIO).zip You probably have the regular BB docs, but available at http://www.nleaudio.com/css/ And there is some additional info at http://www.mathyvannisselroy.nl/blackbox.htm -Larry

Well, there must be something else involved or amiss. Sometimes that procedure works and sometimes it does not. If I am successful in DD one image to the UI, then 100% of the time I will be unable to DD a second image. So far, it looks like the most successful approach is to DD one image, then exit the app, and then re-open it and DD another image. That seems to work most of the time (but not always). BTW, I'm using XP SP3. Didn't AspeQt have one release which was installed? I was thinking that there was no issue with DD on that one, but it's been awhile, so might be a "false memory." -Larry Edit: I dug out my older version of AspeQt which is installed and it has no issues with drag and drop. I think this issue is RespeQt only. Clarification: Aspeqt Preview 7 runs from a folder on the C; drive, but is not installed via the registry.

Hi Roy- Thanks! Yes, If I place the source folder on top of the UI (in the drives section), the images drag and drop fine. But if the source folder is off of the UI, the images can't be dragged/dropped. That seems odd. Can you (or anyone else) explain why it works that way? I can only relate to APE (which I use most often), and I can drag/drop from most anywhere to the APE UI. Maybe because APE is installed and RespeQt is not? -Larry

Recently, I've been using RespeQt 4.x some, and it works fine for me -- even seems a bit faster than AspeQt. (?) But in mounting images, it does not appear possible to "drag and drop" images to the selected drive? I've tried several ways, but it does not seem to work. -Larry

Scanning to PDF works really well -- much better than doing a PITA OCR. If your scanner doesn't have Scan to PDF, then there are plenty of apps for Windows to do it. I like PDF Converter Pro 7 and 8. I have 7 on an XP computer and 8 on Win 7. I use a Brother all-in-one, and they work together seamlessly. Once you have the PDF, many of the apps will do a very good job of converting the PDF to a Word file. BTW, a plug for Brother -- this device is way better than any of the HP devices I have had. And the ink is amazingly cheaper! The document feeder works flawlessly for me. -Larry

Hello Simius- My 50-pin cable has apparently failed, so now I need to replace it. Can you provide a link where I can get some more information about this 50-pin miniature IDC. I don't see this connector anywhere (usual sources). I've opened many of the regular IDC connectors, but I cannot see how this one opens, and I don't want to break it and end up having to desolder the connector. It looks really fragile. Or perhaps you can make a sketch as to how it opens? I can see the joints, but cannot determine how it "locks" together (or how to unlock it). Thanks, Larry

I've recycled all my old dot matrix printers. In fact, I was thrilled to get my first HP inkjet (with Epson emulation) many years ago. But APE changed the game completely several years ago when Atarimax added printer emulation. It uses a Winprinter to print through the Windows Printer Driver or Epson emulation or an Atari 1020 plotter (but I've never used that). But you must use APE, and I think that some or all of the printer features are not available in the free version. I know that the features work with the APE USB adapter and also a (genuine) FTDI USB adapter, although the FTDI on APE can only do 3X disk transfers. I've not tested a real RS232 setup. I also believe that AspeQt/RespeQt also have some print-thru capabilities, but last I checked, it was not nearly as complete as APE. Here is a setup shot of APE's printer configuration that shows some of its features. (If you click on it, it will open up larger for easier viewing) -Larry

Please let us know how you come out with this. -Larry

That's great, Steve. Presume you can copy, read, and write to those disks ok? Those cables can bite! -Larry

Hi Steve- Here is a doc on the ATR8000 with HD 5.25 that may be helpful. I didn't find a file for 1.44, but yes, I'm quite sure the data rate is reduced for DD. Edit: Data rates at the disk -- 500 KBS for high density; 250 for DD. Since the ATR8000 can write DD, it should have no trouble writing to a std. double density 3-1/2" diskette, assuming you can get the floppy configured correctly. I no longer have any ATR8000's, but when I did, I used 3-1/2" drives, but in a Percom housing/controller. Do let us know if you get this sorted out -- the ATR8000 is still a very interesting peripheral! -Larry High Density 525 Drive for ATR8000.doc

@santosp/foft Any particular plans for a keyboard, or just a stock PC keyboard (there are bunches to choose from)? A plug-in adapter for a regular Atari keyboard would be really cool. Really like this design since so things are built-in and need not be added at extra cost. Have you finalized a size & layout for the pcb at this time? -Larry

@dmsc- Yes, I need to try your very nice Fast Basic. I thought I might have some conversion issues, so I put it off until another day. But I'm sure that once I get used to any differences, I'll like it very much. @luckybuck- You're right, but I wanted something that I knew should agree with the embedded stock OS checksum, and TBXL/compiler and Basic XE replace the math pack, right? That's why I chose BXL, and also since ABC has it own internal integer-only routines, that seemed like a reasonable comparison. But today I checked TBXL and it gave a highly respectable value of 67 sec. (with a bad checksum message). And I also tried the compiler, but it gives compiler errors, so it is omitted. The only issue that I had with ABC was that I knew that I could not use a constant of 65536 or larger. But the fix is very simple -- change the constant to a variable, SUM=32768 + 32768. Then it compiled on the first attempt. -Larry

Work-arounds? I tried to think of some work-arounds for the 16-bit limitation of Integer Basic, but so far nothing has worked. I was interested in using IB on one of the Basic programs that calculates checksums for the OS roms. Here are some benchmarks of different Basics and Compilers calculating the checksum for the XLOS: Atari Basic © 213 seconds Basic XL 127 seconds ABC compiler 27 seconds (!) Since ABC has work-arounds for floating point using 3-byte integer internal representation, it is quite easy to get around the 65535 limit. (See the ABC manual pages 8-12 if interested.) Because these checksum programs basically just add integers, ABC can really shine -- nearly 8 times faster than Atari Basic Basic XL is equally fast with or without the FAST command. That is quite interesting to me since BXL usually is very similar to Atari Basic in benchmarks except when using FAST on programs that benefit from that. Anyone had any thoughts on work-arounds for the Integer Basic limitation? -Larry