Jump to content

Atari_Ace

Members
  • Content Count

    233
  • Joined

  • Last visited

Community Reputation

398 Excellent

About Atari_Ace

  • Rank
    Chopper Commander

Contact / Social Media

Profile Information

  • Custom Status
    https://ksquiggle.neocities.org/
  • Gender
    Male
  • Location
    Seattle, WA
  • Interests
    Atari 8-bit, Biking
  • Currently Playing
    Halo Collection

Recent Profile Visitors

9,885 profile views
  1. Perhaps not the dumbest, but... When the SQL Slammer virus was spreading (2003), it got into one of our labs at work and infected everything. To help decontaminate, it was useful to have an immune system physically nearby, so I took a machine from my office which I had managed to patch, and walked it up to the lab and plugged it in. I was puzzled because it didn't boot up right away... Turns out the bench I plugged it into was 220V power, and my PSU had a physical switch set to 110V. It took weeks to get a replacement PSU that fit the case (thanks, Dell), so I had to live with an open machine powered by an spare external PSU, since I really needed that machine working. Recently I was watching a PSU repair video and the presenter mentioned that modern supplies don't have the physical switch anymore, they handle both voltages fine. I could have used that innovation back then.
  2. I find such data corruption interesting: Line 4410 can be found at offset $1eea in the file, which hex dumps as follows: 1ee0 0e 40 06 00 00 00 00 15-a5 16 3a 11 5d 12 03 2b [email protected]:.]..+ 1ef0 28 8b 2c 24 0e 41 01 86-00 00 00 14 1e 2c cb 12 (.,$.A.......,.. 1f00 0e 40 23 00 00 00 00 14-2d 03 2b 28 8a 2c 24 0e [email protected]#.....-.+(.,$. 1f10 41 01 87 00 00 00 14 3f-2c 0e 40 11 00 00 00 00 A......?,[email protected] 1f20 12 0e 40 23 00 00 00 00-14 4b 03 9e 24 0e 41 01 [email protected]#.....K..$.A. 1f30 89 00 00 00 14 5d 2c 0e-40 14 00 00 00 00 12 0e .....],[email protected] 1f40 0c b5 7d 00 00 00 16 3c-11 6b 25 36 bf 2d ce 25 ..}....<.k%6.-.% Constants in Atari BASIC start with 0e, followed by a biased exponent ($40 is zero), followed by the BCD digits, so 14 = "0e 40 14 00 00 00 00". "0e 0c b5 7d 00 00 00" is the whacky number, which isn't even a valid floating point constant (you can't have hex values a-f in the BCD digits). We can change those 3 bytes to "40 23 00" to repair it. The Antic v3n4 disk is in the Atari 8bit Preservation project and that one has the same corruption. On that disk, those bytes come from the first three bytes of sector 537. It almost looks like the end of the last sector is bleeding into the beginning of that sector (well, the $7d at least). It could just be a random corruption, though. BTW, line 10 is also different from that disk and the bas file attached here. It has MO(N,5) in the DIM statement (which matches the printed listing), whereas this file has MON(P,5). Since P>N, this typo has no effect other than allocating more memory. So here's the file from the preservation disk with the patch above applied. CREEPCAV.BAS
  3. FYI, the 2nd edition was posted on bombjack about a month ago, so there's a full scan available now. DLH's Archive - Generic Books - Hardware / Programming (bombjack.org)
  4. I must have skipped over the adventures. Instead, I recall playing a fair amount of Flip It (a Reversi clone); Hopper (a Frogger clone) impressed me for a free game; Mini-Golf was fun for a diversion; and their Solitaire game cleverly used text graphics. I was most appreciative that the listings tended to be annotated and understandable. I was interested in following how these programs worked, and the SoftSide ones were easier to take apart than many others. But what I remember most now was the odd simulators. Dairy Farming, Leyte Gulf, Convoy, International Bridge Contractors... I borrowed many earlier magazines and was baffled by the odd games being published. I still typed in many of them though...
  5. Just for amusement, I converted this into a SQL database to be able to query it, e.g.: sqlite> SELECT COUNT(*) FROM missing WHERE note LIKE 'type-in%'; 114 sqlite> SELECT COUNT(DISTINCT(company)) FROM missing; 731 My conversion is certainly not perfect. I pasted the text into a file, adding line breaks between each company. I then wrote a parsing script with some simple header/footer detection (dropping the footers) and then proceeded to produce a table that was simply rows of (idx, company, title, note). I made that into a database by producing SQL commands to create the table, insert the rows, and create some indexes. It would be great to adopt some kind of text representation for this data to make it easier for people to explore the data however they want. Anyhow, I've attached my work for anyone who might want to use it. am195.zip
  6. I lived outside of Boston when SoftSide was being published and was able to buy the magazine monthly from B. Dalton (IIRC) for a couple of years (late 1982 till they ended in early 1984). I suspect because they were local (published from New Hampshire) they'd managed to get distribution into the booksellers near me. I also had a soft spot for them, and rarely missed an issue. I remember being curious why they shut down when they did. COMPUTE! at the time significantly reduced their page count (I still remember the huge December 1983 issue), but it seemed like computer magazines were doing well enough, with plenty of advertisers. Apparently that wasn't entirely true, but the ones I bought regularly (COMPUTE!, ANTIC, Analog) survived long after SoftSide disappeared though.
  7. These are the ones currently on the Internet archive. I don't know of any elsewhere on the internet. Volume 1 which has all the issues up to June 1982: https://archive.org/details/AtariComputerEnthusiastsNewslettersVolume1 Allan uploaded 12 additional issues: https://archive.org/details/AtariComputerEnthusiastsOfEugeneOreganMarch1983 https://archive.org/details/AtariComputerEnthusiastsACEEugeneORJune1985 (11 here, mostly 1985, early 1986) There's another one here: https://archive.org/details/ataricomputerenthusiastsaceeugeneorapril1986 And finally there are four issues in the SLCC 1987 newsletter collection: https://archive.org/download/AtariUserGroupsNewslettersJune-Dec1987 Some of the content was excerpted into other newsletters. The WACE newsletters from New Zealand in particular contain quite a few articles from ACE Eugene throughout its issues and is worth perusing just to see what they decided was worth reprinting: https://archive.org/details/WACENZ19840600No18 And I see a smattering of other reprints as well in other newsletters (Current Notes 1984-07, 1984-09, 1986-04, 1987-05, JACG 1982-09, TAIG 1983-04, TAIG 1985-07, Portland Atari Club 1985-09, 1985-10, ...)
  8. I wanted to comment a bit on disk 70_A, Movie Maker Files. This disk was affected by the the dreaded Happy Ultraspeed bug, causing $82 to be erroneously stamped at offset 2 on most sectors, see the comments by Nezgar and phaeron in this thread. Not only does this copy have the problem, but the PoolDisk copy is similarly corrupted (interestingly, it's contents are laid out differently and has an additional MVM file, so it's likely a later/different version of the disk). Fortunately, these files are in other archives. Bellcom disk 62 has the TREK.MVM file, and the SLCC_DOM_Vol_13_Disk_09_Side_2 Sept_1995 has the others. Using those source files I repaired the disks such that the Pooldisk version seems to function now. The other version crashes early on, most likely a problem in my restoration of the either the boot sectors or DOS.SYS. My patched copies are below. bre070a.zip
  9. Another interesting mail order house failure was Black Patch Systems, which has 1-800-ATARI-02 as their phone number. You can find ads for them in Current Notes starting in June, 1985, an interview with the owner in November, 1986 (where he claims a 300k per month run rate), and a brief mention in the June 1987 issue about their bankruptcy. Some of their ads have a small reference to "Toad Services", and I believe David Troy was an employee of Black Patch. He started Toad Computers around the time Black Patch closed (their first Current Notes ad is May 1987), and it grew into the largest Atari mail-order firm in the US.
  10. I thought that was AMAC which did that, limiting segments to 256 bytes.
  11. MACE Newletter/Journal seems complete except for volume 1 from 1981 (which I expect will be really hard to find, there's one issue on archive.org). In 1988, the group joined the Michigan Atari Magazine (which later became Atari Interface) and ceased publishing independently (except for a single issue in July 1988). I'd love to see the remaining Michigan Atari Magazine and Atari Interface's scanned, but I think it's more interesting to find and scan pre-Tramiel era newsletters such as some of these DAL-ACE newsletters, since user group newsletters from that era are scarce on the archives.
  12. The Internet Archive is a treasure for old computer enthusiasts. Archivists have been uploading old computer newsletters there for years which provide a vivid view of what it was like to be an Atari enthusiast when Atari was still a going concern. Thanks to the archive, I've been able to read such excellent old newsletters as the MACE Journal, SLCC Journal, Current Notes, and dozens of others. The archive itself though has some quirky behaviors. When you upload content, it examines it and produces derived content. In the past that included Djvu versions of the content (a feature I sorely miss), and of interest to me, OCR's of the content. In the past, the OCR's were produced using ABBY FineReader (mostly version 11). Recently the archive has switched to using Tesseract. My initial impression of Tesseract is generally favorable, but like all OCR's, it can fail in interesting ways. Take the Portland Atari Club newsletters @Allan recently added to the archive from 1984/1985. The metadata for the uploads apparently didn't specify the language, so Tesseract has some heuristic it uses to detect what language it is. For some reason, it decided that the November 1984 and January 1985 issues are in a combination of Latin and Cyrillic script, so the OCR results are much worse than the usual OCR results (which generally are not great on newsletters in general). For instance PAC (for Portland Atari Club) was often converted to three Cyrillic letters that look very similar. The reason I noticed this at all is because I have an archive of those OCR's I scan through when I want to find old reviews or Atari news. Let's say I'm curious about how Seven Cities of Gold was received when it was released. Using "grep" on the OCR's I have I find there was a review of it in Current Notes, October 1984 and the MACE Journal, March 1985. I also see there was a review in v.3 n.8 of the JACG Newsletter because it's in one of their indexes, but that issue isn't archived anywhere to my knowledge. I also spot a couple of capsule reviews (e.g. PAC Newsletter, July 1987) that I would have missed if I just kept the table of contents for all these old newsletters. So when new Atari newsletters show up, I download the OCR's and clean them up (mostly fixing errors and de-hyphenating) so that I can search them in the future. Someday I'll make these available, but I've attached the Portland Atari Club ones I recently did since the OCR's on the archive aren't very good. pac1.zip
  13. When I was looking at the disks earlier, I noted the "restored" disk (Kyan_Pascal_DOS_2.5_MD_(restored).atr) had a compiler (PC) the same size but with a different checksum than the compilers on the other disks, so I was curious what the difference might be. I finally took the time today to take a look, and discovered it's probably just bit rot. There's a single bit flip of the lowest bit of a particular byte. --- pc.txt 2021-03-13 13:35:58.129722000 -0800 +++ pc_restored.txt 2021-03-13 13:35:30.724440900 -0800 @@ -1551,3 +1551,3 @@ 60d0 65 20 31 20 73 74 61 63-6b 20 6f 76 65 72 66 6c e 1 stack overfl - 60e0 6f 77 0e 73 74 61 63 6b-20 6f 76 65 72 66 6c 6f ow.stack overflo + 60e0 6f 77 0e 73 74 61 63 6b-20 6f 76 65 72 66 6c 6e ow.stack overfln 60f0 77 0d 68 65 61 70 20 6f-76 65 72 66 6c 6f 77 21 w.heap overflow! Examining the rest of the files against the copies on other disks I found 1-bit flips in two other utilities: RM: --- rm.txt 2021-03-13 13:53:48.037502200 -0800 +++ rm_restored.txt 2021-03-13 13:53:16.211996200 -0800 @@ -59,3 +59,3 @@ 390 03 20 56 e4 30 42 a5 b4-f0 0e a5 b0 8d e0 02 a5 . V.0B.......... - 3a0 b1 8d e1 02 a9 00 85 b4-a5 b0 9d 44 03 a5 b1 9d ...........D.... + 3a0 b1 8d e1 02 a9 00 85 b4-a5 b0 9d 44 02 a5 b1 9d ...........D.... 3b0 45 03 38 a5 b2 e5 b0 9d-48 03 a5 b3 e5 b1 9d 49 E.8.....H......I PRINT: --- print.txt 2021-03-13 13:58:15.746006400 -0800 +++ print_restored.txt 2021-03-13 13:59:05.334763700 -0800 @@ -36,3 +36,3 @@ 220 20 31 8d 20 3b 8c a9 b9-a0 24 20 4c 8d a9 fb a0 1. ;....$ L.... - 230 8b 20 11 8c a1 00 95 00-a9 00 95 01 a9 59 a0 00 . ...........Y.. + 230 8b 20 11 8c a1 01 95 00-a9 00 95 01 a9 59 a0 00 . ...........Y.. 240 20 11 8c 20 6e 8c a9 fc-a0 8b 20 11 8c 20 4f 8d .. n..... .. O. All of these bit flips are on byte $41 of the relevant sectors (299, 598, 637), reinforcing the idea this is just bit rot. So I've patched the three bits back to what they "should" be: Kyan_Pascal_DOS_2.5_MD_restored1.atr There may be additional bit flips in some of the later files on the disk (largely .PAS and .O files), as I didn't find files to compare them against.
  14. archive.org has some kind of heuristic it uses to determine if the text layer in a pdf is intact and comprehensive, and if it isn't, it will reprocess the pdf file (assuming pdf is the original upload source) and generate the "with text" version. In the past it was using ABBY FineReader 11 for the reprocessing, which sometimes is able to massively shrink the input pdf, but they seem to have dropped that recently (they're using Tesseract now for OCR). I've also wondered about what that heuristic is, since it sometimes triggers on pdfs that have significant amounts of text in the file. I suspect this "with text" feature was added as a replacement for the djvu files they used to include. I miss the djvu files, as they tended to be smaller and render much faster than the pdfs, almost always at the same level of quality.
  15. Unsurprisingly, there was some skepticism about the product at the time. Here's an excerpt from the Atari Scuttlebits column by Bob Kelly (Current Notes, June 1985, page 7): 5. Matrix Software: The Infinity integrated software series has received significant attention - notably from Antic and CompuServe. Let me quote from the April issue of Antic: “The undisputable star of Atari’s new software is Infinity, a second-generation integrated program that’s more powerful than Lotus 1-2-3. Yet it will sell at only $49.95 for XEs and about $70 for the STs... Admittedly, all this is a bit hard to believe about software that can operate with as little as 64K memory. A developer of the program told Antic that Infinity was able to pack in so many advanced features by “optimizing” the assembly language compilation.” This article, as well as several others, left the impression that the software was ready to go and introduction awaited only the hardware. I decided to call Matrix Software and ask them directly about their product. I tried to find the telephone number. Ma Bell’s directory assistance informed me that there was no listing for Matrix Software in Cambridge, Mass. I was stunned (OK, maybe just surprised). I had the impression that Matrix Software was a well established outfit. Other people were contacted. Some sources stated that the Infinity Series may end up being vaporware. Others assured me that Infinity does exist but the progress reported on it’s integrated software package has been exaggerated. It is difficult to evaluate the situation given the information I have at hand. However, I can respond to Antic and its misleading report by saying, “Yes, it is hard to believe since I can’t find the place these guys optimize their infinities at”.
×
×
  • Create New...