Larry

Probably a printer port, BUT a friend of mine had an 800 with a DB-25 connector on the left side that connected an external keyboard that was sold in the early 80's. Since the 400 had one of the "10-worst keyboards" maybe this could be a keyboard connector? (Presume the joystick ports could be used to pick up the key presses?) -Larry

I am having a new printing issue since I installed the 3.0.4 upgrades. This is very much like the printing issue that APE initially had with Win XP. As then, the disk transfers are error-free. But I keep getting error messages 138 (timeout) and 140 (Framing) errors. When I use the APE Print Monitor, I only see partial lines printed. Sometimes the MX-80 virtual printer will print properly, but mostly it terminates early with the errors 138/140. I have uninstalled 3.0.4 and reinstalled 3.0.2, but the errors remain. I have an Intel dual core processor with an AS Rock MB, using an on-board serial port at $3F8. Has anyone else using a dual core processor had printing issues? Anyone who has done the 3.0.4 upgrade having printing issues? Thanks, Larry

Final Benchmarks and a small bump in the road... I finished my benchmarks this AM, but immediately ran into a small issue -- the my Atari would not boot this AM at a divisor of 01 or 02. It was again completely stable at 03. I can't explain that since the test conditions were the same. Perhaps 01 or 02 is just a little "iffy" on my equipment. So I went back and ran the SD benchmark again; this time it came in at 37 seconds. That's 4 seconds or about 10% faster than the serial. The double density image copy test came in at 63 seconds, 10 seconds faster than the original USB test, and 9 seconds faster than the serial or about 13% faster. Finally, I backed up my HD using a sector copier. This was 20,000 DD sectors. Serial: 19:19 USB: 18:11 That's about 6% faster, and a more "real world" comparison in my Atari use. So there it is. Steve has made some significant improvements in the USB adapter performance. Would the speed alone be worth purchasing a new adapter? The "wow-factor?" I guess everyone has an opportunity to vote on that with their money. -Larry

Wow! I'm impressed! I installed the new (registered) updates and it really improves the USB interface's performance. I can now get all the way down to a Pokey divisor of "01" using the Black Box high speed driver -- that's 111860 BPS. The updates improved the single density sector copy time from 43 seconds to 34, a full 7 seconds faster than the serial interface (~17% faster). This is really quite an improvement! Nice going, Steve! More times tomorrow. -Larry

Using certain programs (MyCopier for one) the USB version can be double the speed of the serial SIO2PC. At the moment, not even Steve's Warp OS support all the PoKey divisors (meaning only regular speed and 3X are supported). But, as long as the programs supports all divisors, the USB device absolutely screams along. Stephen Anderson Some Benchmarks would probably be useful... Test #1: Sector Copy 720 sectors S/D using Copy 2000 2.41D APE image to APE image; Black Box high-speed driver: Serial "3X" 41 sec. USB "08" 55 sec. USB "03" 43 sec. Test #2: Sector Copy 720 sectors D/D using Copy 2000 2.41D APE image to APE image; Black Box high-speed driver: Serial "3X" 72 sec. USB "08" 96 sec. USB "03" 73 sec. Test #3: Copy Ape image to APE image using Win XP and mouse: Instantaneous... Notes: I also used MyDos to do the sector copy but got the same numbers as the Copy 2000 (+/- 1 second). I can't get the Pokey divisor any lower than 03. Maybe the "Black Rabbit" from Analog which blanked the screen entirely? Yes, the USB sounds like it is screaming at "03" but the numbers say that the throughput is essentially the same as "3X." Originally, using a USB hub slowed things down a bit as opposed to plugging the interface directly into a computer USB port. Dunno about now -- my current MB has 6 USB ports, so I don't use a hub. Doesn't mean the USB interface is not neat or useful (especially if you have no serial port). All times with second hand on watch. Will post the HD backup times tomorrow or Sunday -- need to back it up, anyway... -Larry

Check out this similar thread: http://www.atariage.com/forums/index.php?showtopic=116288 Looks like SpartaDos X is the lowest of any "regular" Dos (by a bunch). Not sure about the new "Real Dos." -Larry

It depends on what you are doing and software you are using. The USB can be a little faster for some single density sector copiers. but this amounts to little actual time difference. If you are using Dos, and especially in double density, the serial version is 10-15% faster on my equipment. I ran apples-to-apples tests backing up my hard drive, and the serial version was clearly faster. Both are very nice, but if I already had a serial interface would I buy a USB? No. Would I instead spend the money and get the registered version of the software? Yes! -Larry

If your disks are copy-protected (originals), it would be very difficult to do without tracing the loads. That would require a Happy or a Super Archiver (or APE/Atari810 with a PC). If you were able to trace the loads, then you might be able to custom-format specific tracks, based on the copy-protection (or lack thereof). It's a PITA, but can be done. For your menu disks, presumably with binary load files, yes, you should be able to do that. You would need to make a new disk with Ultra-Skew format, then copy the old disk contents to the new disk. Be sure to check each disk after copying before "burning any bridges" i.e. erasing your old disks. Of course, you'll need a high-speed driver so that SIO can operate at high speed. That could be a potential issue for your project unless your driver is in ROM. Guitarman's advice about the Happy drive is dead-on. If this is a casual thing, not worth it, but if you decide you are into this for the long haul, get a Happy 1050 board/workalike. These are quite inexpensive these days. See: .... http://www.atarimax.com/myide/documentation/ (scroll down toward the bottom). If you could have only one drive, then there is nothing so useful as a Happy or workalike. Good luck. -Larry

Thanks guys, for the links. Of course the world doesn't necessarily work this way, but 70(%)/66(MHz) as 100(%)/ "x"(MHz) X=94 MHz. That's well within the range of the acceleration. 1.4 times (Fast) is 92 MHz; 1.8 times (Ultra) is 116 MHz. Certainly looks feasible at a glance. Doesn't look too nice to install, but I've never seen the insides of a DS (other than those pics). For grins, I need to see what my 266 MHz Pentium I Libretto will do with Atari800Win Plus. Definitely apples to oranges, but the Libretto has a real keyboard and mouse. -Larry Finally got around to trying A8CW+ on my old Libretto -- 270% with small screen and refresh=10; 200% with large screen. Those old Pentiums had a little "oomph!"

A brief follow-up... I now have a nice, bright emulator (text) screen. When I first ran the checksum program on my real hardware, I was getting "BAD" checksums. That's odd! At first, I suspected my Black Box of somehow corrupting the results, but then reasoned that it was more likely Basic XE, since it replaces part of the OS with its math pack. Ditto Turbo Basic, which corrupts both tested segments. Probably some others, too, such as SDX (?), depending on how it is configured. I did thoroughly read that section of appendix twelve in Mapping the Atari -- there is so much good info in that book. This thread produced some really good info for me thanks to Urchlay -- thanks again! -Larry

It has -12V on it? That seems very unusual. -Larry

This info was posted on Compuserve for several years as PAR1050. However IIRC, the project archive was missing a file. I think it was the custom format program written in Atari BASIC. This program used the custom format facilities of the US Doubler (see Sparta Dos Construction Set, p.150) to allow formatting the disk with high-speed skew. I believe that this program (or one very similar) re-appeared in Bob's mod of the XF-551 - called XFMT.BAS. I never built this - it wasn't too long after this that hard drives started appearing, and I decided buying a HD would be a much more useful. I looked for this file, but so far have failed to find it in my stuff. Perhaps Bob might re-post the archive at a later date? Of course, having the completed, original hardware would be quite neat, but if you are willing to do some work and/or don't win the auction, then you can likely have one also. -Larry

Hi Urchlay- Thanks, that is superb, and *greatly* appreciated. The BASIC code is great - yep, I'm pretty much stuck in BASIC; dabble in ACTION! when forced by speed; and only capable of very small ML routines. BASIC is so user-friendly! Thanks again, Larry

That is a great suggestion, but it brings up two other questions: Do you also know the ROM location code of the default background (color2) for Gr. 0 for both the XL and the 800? (I'd love to also change the very-dark Omnimon colors.) And do you know how the XL OS Rom checksum is calculated? It would be nice-to-have to also "fix" the checksum. -Larry

Photoshop stores more than 8 bits per color, but most (all?) PC video cards only actually display 8 bits per color (RGB, 24-bit, or 32-bit with an alpha channel). The extra precision in Photoshop is used to avoid roundoff errors, and possibly for very expensive printers that can do more than 8 bits per color (assuming they exist, I don't know). Making an emulator use more than 8 bits per color wouldn't help because unlike Photoshop, the emulator isn't doing math on the colors, it's just displaying them. The thing about emulator palettes is that there are so many other factors that can affect the perceived colors: - Monitor make/model and type (CRT vs LCD, analog vs digital video) - Monitor brightness/contrast/gamma/color-temperature settings - For some video cards, color calibration and gamma settings in the driver - Even the cabling might make a difference, for analog SVGA Also, when you're comparing the emulator's video to the Atari's, you're seeing the Atari displayed on some sort of monitor/TV, which also has its own set of color/brightness/tint/etc controls... not to mention, the different A8 models have wildly different video output (800, 1200XL, early/late model 800XL, XE all have different displays, compare them & see). Then there's RF vs composite vs s-video... and the fact that the Atari has a color adjustment that can get out of whack... even the Atari power supply voltage can affect the colors. What looks like a "real Atari" depends on what you're used to. I guess what I'm saying is that you'll never design the One True Palette that will make everyone's emulator look like the real thing. The best you can do is build a palette that makes your emulator (running on your PC setup) look like your Atari... but give that palette to someone else, and it will look wrong to him unless he's got exactly the same Atari and PC hardware, with all the settings set the same way. It doesn't mean you should stop trying, it just means your solution will probably only work for you (which is why the emulators support user-defined color palettes in the first place). Forgive me if I'm telling you what you already know... I spent much time beating this particular horse before I found out it was dead Hi Urchlay- Thanks for your input, and yes, I agree with all of the factors that you mention. Certainly "color" as well as "beauty" lies in the eye... (for many reasons). My main issue is the brightness of the higher luminance values, and in particular the luminance of Graphics 0 text. Since I rarely play games and only work with text-based programs in the emulator, the text color (luminance) is important to me. Since you have already flogged this horse, you may be able to help me. Here is my line of thinking: The shadow registers for Gr. 0 are 710 (background) and 709 (foreground/text) The default Gr. 0 colors are 710 = 148 (Blue-green; luminance of 4) and 709=202 (green; luminance value of 10) (I also have no clue why Atari chose 202, since it is the luminance value of 10 for color 12 (Green), but any color value should produce the same results so long as it has a luminance value of 10.) Now, when running the emulator, I can POKE 709 with 12 and things look a quite a bit better. POKE it with 14, and it is quite pleasing to my eye. How then can I change an external palette to accommodate my sense of "color correctness?" The way I approached this is that since the default luminance value is 202, then this would be taken from the 202nd position in the palette. The palette is 768 bytes long, 256 * 3, so I think that I would need to modify values palette values 606, 607, and 608 to "brighter" values, e.g. closer to 255. So since this represents a default luminance of 10, I actually took the higher values in the same group (of 0-15) and moved them *down* to positions 606, 607, and 608 in a Hex editor and saved the changes. But somehow this must be wrong, since I could not get anything like the brightness that I see by simply POK(E)ing higher luminance values into location 709. Does this approach/line of thinking seem correct? Thanks, Larry

Hi Bryan- Thanks, that's a good suggestion, and I'll do it. My vague recollection is that the RGB values shown in PC graphics programs go much larger than 0-255 (two-byte values). If so, that would explain why A8W+ is "dark." I have Adobe Photoshop Elements, so I'll re-install that and give it a try. -Larry

Some progress and a question: First, I found several external palettes in the Atari800Win "Palette" folder. Of these, the Xformer.act palette looks closest to what I think the colors should look like, but still not quite right. By bumping up the white level in the palette controls, I can brighten the foreground and background a bit, making it closer to "correct." But I still cannot come close to the text brightness on the real Atari -- the emulator is always much darker. I'd still like to still bump up the luminance, especially in the default BASIC/DOS Gr. 0 colors. So I think that means that I would need to increase the (0-255) values of RGB in the palette file. The default background color held in location 710 is 148. That is color 9 (blue-green) + a luminance value of 4 (9*16+4=148). The luminance value for GR. 0 foreground is held in (shadow) location 709. The default value is 202 on my NTSC system. So in order to bump up the text luminance in the Atari800Win+ palette, I *think* that I need to increase the RGB values in location 202*3=606, 607, and 608 in the palette file. I did that and as best I can determine, nothing much happens to the luminance. (Maybe a little bit brighter.) It almost looks like the 0-255 scale for RGB is not correct. i.e. in order to achieve significant levels of brightness, something is missing. Perhaps someone can comment on what I'm seeing. -Larry

Larry, What are the differences between the orange and black OSS carts?? I have sets of both. Hi Guitarman- The early (first generation) carts were orange. They use two 2764-type roms/eproms. (The Writer's Tool only used one 8 KB eprom.) The black carts use a single 27128-type rom/eprom (2764 for the Writer's Tool). These were presumably cost-reduced, and used a different, less complicated banking scheme. Basic XE only came as a black cart; all others were orange and then black. Some evidently had exactly the same software version released as orange and black carts. For several years, a non-OSS orange cart "work-alike" was sold, but I have never seen a black (external) cart "work-alike." Like you, I have both orange and black carts. I have never had an orange cart fail for any reason, but have had two black carts fail. -Larry

Yes, this is the correct order. Thanks. This is on this week's "to-do" list. -Larry

Another Basic XE cart -- can't have too many (black) OSS carts! -Larry

Christmas 1982: A Happy 810 Enhancement! That was a very merry Christmas... -Larry

Very Clever and very nice! Thanks, Larry

I will guess that it is some type of a "genlock" device to overlay the scrolling text on the normal broadcast picture. Congrats on finding a nice 130XE. -Larry

Thanks for the info and link! On my NTSC system, the PAL palette is somewhat dark and shifted toward green. However, I have started experimenting with it using a HEX editor. I think it is possible to write a Q&D BASIC program to automate making changes to the palette, after I get some sense of what changes work properly. We'll see. Since you have already worked with the palette, can you confirm that the file is arranged as (Start of file) Color 0; Lum 0 (RGB) Color 0; Lum 1 (RGB) ... ... Color 15; Lum 15 (RGB) (EOF) Thanks, Larry

After reading about the file characteristics of the .ACT (palette) file, yes, a custom palette should work. I'll try editing yours and see where that leads. If I'm successful, I'll post the results. Thanks, Larry