Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

15 Good

About StickJock

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Both of the drives are Tandons. The longer post is farther back, so it pushes on the aluminum casting (or, least misses the taller part of the drive). The shorter post pushes on the sheet metal. Obviously, it did close as both drives were sealed up with the 4 corner screws & 2 bezel screws. My wife said that she got them from her sister, whose husband probably bastardized it back in the 80s. He probably put the wrong top & faceplate on it, maybe while upgrading several to USD? I still need to clean the mechanisms & power them up to see if they still work. Oddly, one was set as D4.
  2. Neither PCB was screwed down, and I'm pretty sure that they are both Tandon drives, but who knows what happened to these drives in the past 35 years. Well, nothing in the past 25 since they were in a box in a closet, but prior to that...? I did think that it was odd that the drive from the case with the longer, rearward post had discoloration on it from where the shorter, forward post would press. It seems that at some point in it's life, the case was swapped on this. It is also missing the four lower bumpers on the drive alignment pins, and has what appears to be a homemade US Doubler installed (stacked RAM with the wires across the top & eprom instead of masked ROM, and case label has "USD" written in sharpie). The other drive has an actual ICD US Doubler in it. These drives, along with an 800, were in a box (no cables or power supplies) in the back of a closet for 25 years. They belonged to my wife BitD. I didn't even know about them until Saturday when I was pulling out the rest of my old 8-bit stuff from the closet. Since I retired last year, I figured that I would get back into them. All of my old stuff was stored in their original boxes (2 1050s (one with USD), 800, 130XE (with 320K), 850, trackball, 1020 plotter, Anchor 2400 baud modem - still haven't come across the Epson RX80 F/T+ yet). Yeah, I'm a packrat. 😀
  3. Not sure how helpful this is, but here is an 800 that I just found. I didn't see the stamped/melted numbers on the case. Where should I look for them?
  4. There was a recent thread that mentioned that there were two different top shells for the 1050 floppy drive. As it happens, I just came across a box with an 800 & two 1050s. They were pretty dirty, so I disassembled everything to clean them. The two 1050s had different top cases, so I thought that I would take some pics of the differences and post them here. Here you can see that the front edge has different interlocks that go to the front frame. You can also see that the hold-down post (center left) that presses on the drive mechanism is in a different location and is a different height. The one on the left presses on the aluminum drive casting, and the shorter one on the right presses on the shaped sheet metal closer to the front. The rubber bumpers are different between them as well. The ones on the right seem to be just rubber "bump-on feet". This shows a closeup of the left top shell and the front bezel. You can see that the interlocks are like loops, with simple projections on the top shell. Here is the closeup of the right shell. You can see that the bezel has groups of three "finger hooks" to hook onto beefier projections on the top shell. Some of the top shell has been cut back where a (probably write protect) switch was added. There was also a small plastic hook on the bottom right (top left in pic) of the bezel, which broke off. I'll probably CA it back on. The other bezel doesn't have this hook, and both bottom shells have the tab for the hook (bottom shells are same part #). This one also has plastic ridges on either side of the drive opening that the one above doesn't have.
  5. OK, so you have blank disks. What about a DOS? How are you going to load & save your BASIC & MAC/65 files? Is DOS also a freebie? If so, which DOS? Although, I suppose that you could start without a DOS, and write enough code in BASIC with USR() calls to get basic disk access and go from their to develop your own DOS. I mean, you've got plenty of time, right?
  6. On the pic above, the Pengo entry, shows "Pengo (1983)(At...(Atari)(US)[!].car". I am wondering, is the "(At" just before the ellipses the same as the "(At" just after the ellipses? That is, are you repeating these three characters on both sides due to the total filename being shorter than most? If so, it isn't obvious, and thus can be confusing. Perhaps filenames that fit should be displayed normally? This also would help if you had a 32 character filename that is just missing the three characters that are replaced by the ellipses. The name fits but you are obscuring the middle three characters. So, I guess what I am suggesting is that for filenames of 32 characters (if my count is correct) or less, just display the filename. I would probably keep the .ext right aligned, though, so you would end up with "Pengo (1983)(Atari)(US)[!] .car".
  7. I have a lot of disks with the Battillac loader. It was written by a friend of mine back in high school in the early 80s. I don't remember exactly how many sectors it takes, but it is pretty compact. It also has the ability to write itself to a new disk. I don't recall if it had the option to format the disk at the same time. I *think* that it moves its file loader routine into stack memory to avoid conflict with file load addresses, so it can load most binary files.
  8. Which 8-bit? Do I need to include BASIC as one of my programs?
  9. Make sure that any indirect JMPs (opcode $6C) don't end up with the low byte of the address as $FF (JMP $xxFF). This will trigger a known 6502 bug. If you find that the relocated code does this, maybe increment your starting address (wasting a byte) and run your relocator again? Repeat until you get a good conversion.
  10. Yeah, I got my US version ZX81 in the kit form for $99.95. The assembled one was $149.95. Man, I would stay up so late every night programming on that thing! My neighbor across the street had one also. He shaved the "ZX81" off of the case to flatten it and placed a large aluminum block on the case to act as an auxiliary heat sink. Good times!
  11. Yeah, I had a ZX81 as well. It was actually the first computer that I owned. I eventually got the 16K RAM pack for it, but that really slowed things down since, as I understood it, the RAM refresh was done by software by reading the RAM in the OS. That meant that the more RAM you had, the slower the computer ran! The Wang was the first computer that I ever used, learning BASIC on it in 1978, IIRC. My older brother worked in the computer lab at the high school, so he brought me in and taught me how to use them. By the time I got to high school, the 2200T systems were outdated so hardly anyone used the three of them that they had left, so they were pretty much always available, unlike the newer machines that had a signup sheet. Three 2200T computers, all sharing a 2 slot 8" floppy drive. The first one of the three was also connected to a 132 column daisy wheel printer. The "new" computers were a Wang 2200VS system, with about a dozen terminals and a very loud band printer. The terminals were connected to a chest freezer sized CPU and a similar sized hard drive with removable disk packs. The CPU & drive were located in a small, windowed room with two window air conditioners to keep the room cold. Fun fact: The Wang 2200T computer did not have a microprocessor. It had boards full of discrete components, and booted to BASIC in ROM. Programming these old systems, where every byte mattered, prepared me for my career as a firmware engineer, where every bit and every cycle mattered!
  12. I think a lot of us have there. I've lost code from time to time (like accidentally kicking the power switch on the outlet strip), but I think the most discouraging was back in high school in the early 80s. I had written a bunch of games for the Wang 2200T computer, including Space Invaders, Robotron, Tron, Moon Patrol, Breakout & more. The computer ran a version of Basic, and did not have a lot of memory (maybe 8K?). I used lots of tricks to save RAM, like no space between the line number & the commands, and all variables names were single characters. The keyboard had a toggle switch to change between lowercase/uppercase and uppercase/keyword. If you typed "PRINT" then it took 5 bytes, but if you used the PRINT keyword on the keyboard, it only took 1 byte. Cramming as many commands on one line as possible since the ":" tool less RAM than a new line number. It was like a 10-liner contest before there was such a thing! My version of Robotron, for example, used a loader program, the main game program, data files for the rooms, a separate high score program (you could pass variables between programs), and a high score data file. Since there was no POS command, I used string commands to locate X&Y on the screen, where the Y string had a "screen home" character, followed by line feed characters, and the X string had "move cursor one space to the right" characters. The screens were green phosphorous 64 x 16, btw, with tall character cells with underlines & lowercase decenders, too. Anyway, I figured out lots of tricks to get the most out of these old machines. I had just finished my "masterpiece". A two-player tank game that used two separate computers. The two computers would pass their moves to each other by writing to the shared 8" floppy drive (trivia: the 8" floppies had a write protect notch instead of a write enable notch. To double-side the disks, we had to punch the index hole openings in the disk envelope, which required carefully spreading the disk envelope open at the center hole and punch both sides of the envelope, but not the disk material itself). Each system showed two screens, which were windows into a large scrolling map. One window was centered on your tank, and the other on your base. You would move around the world, which was using characters as graphics, and could shoot your cannon and lay mines. You could see your mines on the map, but not your opponent's mines. You could not cross rivers, and you could not see through mountains on the map. You returned to your base to repair damage to your tank and to reload on ammo & mines, and won by destroying your opponent's tank. Anyway, it was a pretty cool game. It was the early 80s so we pretty much thought that all computer games were cool. Anyway, the point of this story is that all of my stuff was on an 8" floppy disk, which was kept in my Trapper Keeper 3-ring binder with all of my school notes. One day, I misplaced it at school. I found it a couple of days later, and someone had intentionally damaged the floppy. It looked like they had spit on the oval disk opening and scratched it with something. I think I may have had a backup 8" floppy, but I had not backed stuff up for weeks, so I lost a significant amount of my work, including my just finished tank game. The next semester, the school got Atari 800s, and I never looked back! BTW: I rewrote the tank game for the Atari in the late 80s, but never finished it. It was meant to be played over a modem, but I never got a chance to test it out since by that time most of my 8-bit friends had moved on to the ST. Man, I haven't thought about that for years. Thanks? for the memories.
  13. I don't remember off the top of my head, but it would be one of the end ones. They are in order 0..7. OK, checking a schematic, it looks like D0 is on U9 and U26. U9 is on the R110 bank and U26 is on the R111 bank.
  14. It looks like you have a bad bit 0. DUP.SYS changed to DTP.SXR, with some spaces changed to ! as well. All of these changes (U->T, Y->X, S->R, space->!) are the result of bit 0 changing from a 1 to a 0. If your 130 has the two banks of 8 ram chips, then your bit 0 chip is bad. I had a similar issue BITD, when I was using Paperclip to write a report and I saw a typo. I went back and fixed it and then after a bit the typo reappeared. It wasn't a typo after all, the letter would just change on its own. I used the bit position of the letter difference to figure out which chip went bad. In your case, it looks like bit 0 of your ramdisk bank is the issue.
  15. Flash is typically written in chunks, a 'flash line" at a time. The size of the flash line can vary by device, but 32 bytes is the size of the last one I worked with. So you write out 32 bytes to the device and then it programs them. The details of how it does this are device dependent. But you can imagine that not all bytes or bits are zapped to 0 at exactly the same time. So in this case, maybe you are writing a $00 to the last byte when power gets yanked. Perhaps you end up with a $05 in that byte? Perhaps you get some weak bits, so that the value read back is not consistent? If power is cut prior to the write completing, the values of those bytes can not be guaranteed.
  • Create New...