Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

377 Excellent

About Atari_Ace

  • Rank
    Chopper Commander

Contact / Social Media

Profile Information

  • Custom Status
  • Gender
  • Location
    Seattle, WA
  • Interests
    Atari 8-bit, Biking
  • Currently Playing
    Halo Collection

Recent Profile Visitors

9,614 profile views
  1. 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.
  2. 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”.
  3. Here's the text extracted for easier reading: SILICA ~ THE SHOP OF PLENTY The Silica Shop is the Mecca for South London electronic gamers — it is also one of the best known and respected mail order houses in the country. The shop nestles surprisingly in an old mews just a short missile blast away from Sidcup High Street. Stepping inside the overall effect is like entering a 21st century version of Aladdin’s cave: the walls are lined with glittering game displays of every type and they resound with the familiar crashes of invaders biting the dust and that immortally demented Atari music. Those insistent bleeping tones are the sweet song of success for Tony Deane and Mike West the directors of this fast-growing and highly successful business. Tony explained how they got started. “Right from the beginning we had the intention of specialising in leisure electronics. We began by selling cheap semi-programmables for £30 to £40. We found plenty of buyers for them, around Christmas 1978 and then we expanded into selling the fully-programmable types, starting off with Atari. “Atari is the most popular TV game on the market at the moment — it outsells everything else by about ten-to-one and we are becoming known throughout the London area as THE Atari specialist. There’s nothing that fits the Atari that we don’t have in stock. It’s part of our philosophy. We figure if you’re going to do something, then do it well and thoroughly and, well, if you buy a Ford car then you expect the same place to be able to sell you spares for the thing. That’s how Atari should be sold. “The problem with buying a machine through a big store is that most of them are interested in selling you one for around £99 and making a quick killing. They couldn’t care less about supporting the thing. We CAN care and that’s how we make our money. “We try to provide a service. For example, by the end of this year there will be around forty chess computers in the market and we’ll stock every one of them. Poor old Joe Public doesn’t stand a chance — he can only look at that range and think ‘Which one...?’ He can’t go to the manufacturers in the States: the importers are very cagey about giving out information, so he comes to us. What we do is reprint reviews from magazines, copies of instructions booklets, anything that’ll give him the information he wants and send it out. It costs us an enormous amount in postage and printing but we hope that if Joe buys, then he’ll do it from us.” From what we saw in the shop, on an ordinary weekday morning, Joe Public is certainly visiting Silica Shop in pretty large numbers — it would probably be difficult to get in the doors on a weekend! And it’s not just Atari that he’s coming to buy and see — Tony and his colleagues have widened their range enormously, now you can get virtually any TV game in the shop, plus all the cartridges and other extras. Now that chess computers are becoming more popular you can see the whole range of those as well. But perhaps the most important newcomer, at least from Tony’s point of view is the personal computer. When we interviewed him, the shop had just had its first delivery of the Atari 4/800 sets. Tony was very pleased with the reception they’d received AND the way Atari had handled the whole thing. “Now that Atari have come on to the market, home computers are the fastest mover we’ve got. The way they approached it was to say, ‘We’ve got a good name, and a good image. Everyone knows the TV game, so let’s build on that image and bring out a home computer’. The biggest problem with all the home computers so far was that the manufacturers rushed on to the market and the problem for the buyer has been that the basic machine has been available, but the software and other hardware has NOT. “Now Atari took a much more cautious approach and decided not to launch until absolutely everything was ready. We received our first delivery of the computers only two weeks ago and we got everything — main units, programmes, disc drives, back-up spares, manuals — everything is there.” And now that Tony does have everything in stock, you can be sure that he’ll be doing everything possible to shift it out to you — Joe Public — along with the standard TV games, hand helds, chess computers and 1001 other products that he keeps in his Aladdin’s cave. As we said earlier Tony was suitably pleased with the efficient way Atari have handled the computer’s launch — it has been efficient and if something is to make money then, in Tony’s book, efficiency is indispensable. The Silica Shop runs with stunning efficiency and we’d bet that it makes a stunning amount of money — but the thing to remember about the whole organisation, whether it be the shop or the mail order side, is that it makes that money by giving a fair and honest service to you — Joe Public. If you are in the area and want to sample the latest on the electronic game market, stick your head round the door, you are welcome to try anything they have in stock. If you’re too far away to get there, drop them a line for their selection of literature. The address is: Silica Shop 1-4 The Mews Hatherley Road Sidcup, Kent DA14 4DX. --- Shop manageress Mary Nelson displays a Chess game outside the shop. A great Saturday morning haven for the youngsters. Another staffer (there are around 20 in all), Bob Katz this time, introduces our compiler to the delights of the Atari computer system — and the Star Raiders game in particular!
  4. CAPS LOCK is enabled initially on an Atari, so toggle it off before doing the Paste and it'll work as you want. That said, it is odd that the CAPS LOCK state is obeyed when pasting in content at all.
  5. I see the file and you're correct, it's definitely not a valid file by itself. There's no damage to the file metadata though (the file links are all intact and the sector count in the directory matches), so I suspect this is intentional. Sectors 450-486 are the start of the MOUNTAIN program, which then abruptly stops. Then sectors 487-701 is data from a completely different source, which after a little investigation I matched to the 2.02 pascal compiler binary (name PC, 26949 bytes, CRC32: a9dd6bca), minus the first sector. So somehow we've got part of a Pascal program and most of the compiler linked together. It almost looks like someone noticed this extra data on the disk and just added a directory entry and stitched the data together so they could look at it.
  6. My Forth is pretty rusty, but I think you want to do something like: : DSPEC " N:TCP://foo.com:6502" ; : SETDSPEC DSPEC 776 ! 772 ! ; Here DSPEC will return the length/address of the string and SETDSPEC will set DBYTLO/HI and DBUFLO/HI.
  7. I looked briefly at the disk images for file/disk integrity. There are three (identical) utility disks and all are missing sector 451, which in each case is in file REPEAT.I. This can be repaired, as there is a good copy in Kyan_Pascal_System_Utilities_V1.00_Side1.atr. The fixed image is attached. Kyan_Pascal_DOS_2.5_MD_(restored).atr also looks troublesome, as file A2.OUT has a link issue. I haven't looked into that further. Kyan_Pascal_1.1_A.atr (and an identical copy) is an SD size disk, but sector 360 declares it has 1010 sectors (i.e. an ED disk). This is a common error I see a lot and doesn't interfere with reading the disks. KYANUTILS1.ATR
  8. I think there's currently 39 AIM's on archive.org (only a handful are missing), but there are also 16 of the predecessor magazines, Michigan Atari Magazine and Mid-Michigan Atari Magazine from 1986 and 1987. There are also a number of ENERGY newsletters, which is where the CHAOS club published their articles prior to launching the the Atari-dedicated magazines.
  9. Done for Ultima II. My brother and I played Ultima II/III/IV obsessively back when they were relatively new, and I've always been fond of them.
  10. BTW, the patterns to search for in the WoW cartridge are: [CE6806:EAEAEA] [CE6706:EAEAEA]
  11. It looks like to make that list a game has to have at least 21 votes, so even some well-known games aren't going to make the cut. Looking over the games I had archived on my own disks in the 80's (which I ruthlessly culled), I find that most are on that list by I did spot a few that didn't make it. Cohen's Towers (Datamost): Nice platformer by Frank Cohen. Can't go wrong with pretty much anything by Frank Cohen. Lawkeeper (by Broderbund): Apparently not well loved, but I must have seen something in it BITD. Lost Tomb (Datasoft) Chop Suey (English Software) Krazy Copter (English Software) Starion (Romox) Also all of the early ANALOG ML games: Planetary Defense especially was a favorite. Livewire! seems to have made the list, though it's nice to see some of those games getting attention.
  12. The Gorf cartridge uses a PMBASE of 0, so page 3 gets cleared and the cart pull logic triggers. In principle I can find all those accesses and update them to another PMBASE. The problem is there's no room on the cart left to place that patch, so I will have to reverse engineer the compression algorithm and restream the image onto the cart with the updates applied. I could make a 16K cart version though without changing the decompression code, maybe I'll start with that.
  13. Gorf is a ~12k image compressed into an 8k cart which decompresses and runs from RAM, so any small patch to the code is likely to change most of the ROM data, so I stopped there. It's possible a small patch could be developed, but more likely the patch will look like a completely different ROM. I couldn't quite work out what was wrong with Seafox, it seems to play fine in Altirra. I saw some comments not being able to fire horizontally but I didn't have that problem. I did an initial disassembly but didn't notice any obvious OS-B only code. I'm willing to look further if someone can clue me in to the problems and how to reproduce them.
  14. In past blog entries I went through the steps developing an 8-bit ATR disk parser so that we could examine and repair damaged disks. Today, I will walk through the creation of a new disk parser, this time for Atari ST disks. The motivation in this case requires some explanation: My first computer was an Atari 800, and when I went to university I brought an Atari 130XE and Indus GT drive with me. The school had more sophisticated machines (PC's, Macs, various Unix workstations), so before long the Atari was largely relegated to entertainment. When I graduated in 1990, my parents offered to buy me a new computer as a gift. I chose an Apple Mac SE/30. I don't think I even considered an Atari ST for even a moment; the Mac was a reasonably priced 32-bit computer (for a student, yay Apple educational discounts), and was clearly better supported than the Atari. For the next eight years or so that Mac SE/30 and later a PowerMac 6100/60 were my main home computers. I used the Macs largely for word processing and games, and recall fondly the amazing sound generation capabilities provided through MOD files and other downloadable sound formats. But curiously, in my archives of files from that period, I didn't find any MOD files at all. Disk storage was expensive in the early 1990s, and I was a poor graduate student, so discarding files was common. Still, I usually kept a few examples, but for MOD files, I couldn't find anything. Searching around the web today you can find MOD file archives, but I really wanted to track down files clearly from that late-80s/early-90s period. That's when it occurred to me that I had a great source in the public domain Atari ST disks. The page6.org site has an extensive collection of Atari ST disks (more than a thousand), and a few of them appear to be MOD file collections. OK, enough backstory. We have some old disk images and we want to get the files off them. I'm sure there are tools already written for this purpose, but I like to develop my own tools when possible. As is my preference, I'm going to do it in perl, since it is well suited to working with binary files. ST disks are essentially the same as a PC-DOS formatted disks. A disk starts out with a reserved section (to contain the disk metadata), and is followed by one or more FATs (for File Allocation Table). After the FATs is the root directory, followed by the actual data on the disk. So we need some code to locate all of these sections. I'll start by borrowing the code from past blog posts to read the file into a buffer, and pull values from the first sector that describe the disk. my $rbuff = read_file($file) or return; my ($bra, $oem0, $oem1, $oem2, $ser0, $ser1, $bps, $spc, $ressec) = unpack "vvvvvCvCv", substr($$rbuff, 0x00, 0x10); my ($nfats, $ndirs, $nsects, $media, $spf) = unpack "CvvCv", substr($$rbuff, 0x10, 0x08); Although I've named all the values in the first 0x18 bytes, the ones we need to parse the disk are just $bps (bytes per sector), $spc (sectors per cluster), $ressec (reserved sectors), $nfats (number of FATs), $ndirs (number of directories), and $spf (sectors per FAT). Using these we can compute the location of the FATs ($fatOffset), the location of the root directory ($rootOffset) and the location of the disk data ($clusterOffset). my $fatSize = $spf * $bps; my $fatOffset = $ressec * $bps; my $rootOffset = $fatOffset + ($nfats * $fatSize); my $clusterOffset = $rootOffset + $ndirs * 0x20; my $clusterSize = $spc * $bps; All data on FAT disks are organized in clusters, which are sequential runs of sectors. Sector sizes were generally fixed at 512 bytes, so by varying the number of sectors per cluster you could support larger disks while keeping the cluster numbers small. Disks used 12-bits for cluster numbers (so 0 - 4095), so with a cluster size of one sector you could support up to about 2MB (some of the high cluster numbers had special meanings, so not every number is valid). Nevertheless, most disks I've examined use a cluster size of two sectors for some reason. Let's now unpack the FAT. The FAT contains a map that tells you what cluster follows a given cluster, data that on Atari DOS2 disk would be in the last bytes of the sector itself. Since typically files are contiguous runs of clusters, that information is usually in just one or two sectors of the disk, so finding the location of a particular byte in a file doesn't require loading all the preceding sectors, just one or two sectors of the FAT. This design is much more sensible than what is done in Atari DOS. Anyhow, the only complication for FAT is that the numbers are 12 bits, so every three bytes contain two entries, so the code requires a little bit shifting. FAT uses little endian ordering for data, thus the first byte contains the lower bits of the first entry and the last byte contains the upper bits of the second entry. sub unpack_fat12 { my ($fat) = @_; my $map = []; for (my $i = 0; $i + 2 < length($fat); $i += 3) { my ($a, $b, $c) = unpack "CCC", substr($fat, $i, 3); my $val0 = $a | (($b & 0x0f) << 8); my $val1 = (($b >> 4) & 0x0f) | ($c << 4); push @$map, $val0, $val1; } $map; } my $fat; for (my $i = 0; $i < $nfats; $i++) { my $fatBuff = substr($$rbuff, $fatOffset + $i * $fatSize, $fatSize); $fat = unpack_fat12($fatBuff); } There are potentially multiple FATs, which all should be duplicates of each other. The code I've written unpacks all of them but simply uses the last one. Now that we have the FAT map, we create a $disk object now to hold it and the other parameters of the disk (clusterSize, clusterOffset, rbuff) and we pass that around. We will soon need a utility to get a file or sub-directory from the disk, so let's write that. Like in Atari DOS, directory entries are going to include only the starting cluster, so we need code to get all the clusters. We simply chain from one cluster to the next until we reach an end of cluster marker (a very large cluster offset). sub get_clusters { my ($disk, $scluster) = @_; return '' if $scluster == 0; my $data = ''; my $rbuff = $disk->{rbuff}; my $clusterSize = $disk->{clusterSize}; while ($scluster < 0xff0) { my $offset = $disk->{clusterOffset} + ($scluster - 2) * $clusterSize; $data .= substr($$rbuff, $offset, $clusterSize); $scluster = $disk->{fat}->[$scluster]; } $data; } OK, the home stretch now. We need code to handle directories and files. A directory is just a contiguous sequence of entries, each of which is 0x20 bytes in size. Those entries are generally either files or sub-directories. Whether it's a file or a directory, it contains the starting cluster of the data, so we can use get_clusters to get the data. So we end up with the following code for reading directories and entries. sub read_entry { my ($disk, $entry, $path) = @_; my $first = unpack "C", substr($entry, 0, 1); return if $first == 0; return 1 if $first == 0xe5; # deleted my $name = get_name($entry, 0); my ($attrib) = unpack "C", substr($entry, 0x0b, 1); my ($dostime, $scluster, $fsize) = unpack "VvV", substr($entry, 0x16, 10); my $root = get_clusters($disk, $scluster); if ($fsize > 0) { my $new = substr($root, 0, $fsize); write_file($name, \$new); } my $fullName = $path eq '' ? $name : "$path\\$name"; my $directory = $attrib & 0x10; print "$fullName:$attrib:$scluster:$fsize\n" if !$directory; if ($directory && $name ne '.' && $name ne '..') { read_directory($disk, $root, $fullName); } return 1; } sub read_directory { my ($disk, $root, $path) = @_; my $offset = 0; while (1) { my $entry = substr($root, $offset, 0x20); last if !read_entry($disk, $entry, $path); $offset += 0x20; } } get_name is a routine to get the file name from the 11 bytes padded with spaces, and write_file writes a data file. Our main routine needs to invoke read_directory on the root directory now to extract all the files. Notice that when read_entry finds a sub-directory, it calls read_directory, recursively traversing the directory hierarchy. So that's it, a ~150 line utility to extract the contents of an ST disk. Let's apply it now. At http://www.page6.org/st_lib/standard/st0627.php is the "The Module Collection 1", which contains a number of MOD files. Running the tool will extract them, and the contents of the READ_ME.PDQ file is good, so I'm sure the tool is working successfully. That said, xmplay (which should support old MOD files) won't play the files so I have more research ahead of me to figure out how these files differ from other MOD files. Although I moved away from the Atari and onto Apple computers back then, I have since developed an interest in the Atari ST (largely from reading old user group newsletters) and hope that this tool will help me extract old text files, images and sound files to get a taste of the Atari ST scene of the time. Even if I don't do much more with ST images, it was fun writing this little tool. stdisk1.zip
  15. UXB, from Compute! 30 (November 1982) looks related. The SCAT group disks on the pooldisk call it TIMEBOMB on their disk 3 (attached), and the magazine text refers to "time bombs" in the game. 003.atr
  • Create New...