StickJock

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?

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.

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?

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".

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.

Which 8-bit? Do I need to include BASIC as one of my programs?

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.

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!

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!

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.

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.

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.

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.

You may want to also employ some method of making sure that the data finished writing properly (i.e., the power didn't go out during the write). There are many ways to do this, but a couple of simple ideas would be to have a checksum or CRC that gets written at the same time, or a faster way would be to do a two-step write where you first write the data, and then write a byte saying that the full data write completed. For example, you might write the entire block where the first byte is $FE. Then, when the write has been verified, go back and write the first byte to $FC. Then, you can read the first byte to see if the block is empty ($FF), block is known good ($FC), or block may be incomplete or corrupted ($FE). You could continue to use bit pairs in the byte like this to indicate four separate blocks as being used & good. Note: You may want to check the flash specs on how many times you can write to the same byte before erasing it. In a past life, I worked with a flash that specified that you could only write to a 32-bit word up to four times before doing an erase.

If the race condition hits in line 800, you will have artificially low values by either $010000 or $000100 jiffies. Averaging this into 10 will still give you a pretty big error (6553.6 or 25.6 offset). Maybe discard any result that is more than 250 less than other passes? You can minimize (but not eliminate) the window by shortening the timer read code by doing something like T1=PEEK(18):T2=PEEK(19):T3=PEEK(20) and then processing the data. Also, if you do it this way, you can see if you *might* have hit the window by seeing if T3 is 0. How about this idea: 99 STARTTIME=0 100 POKE 20,STARTTIME:POKE 19,0:POKE 18,0 800 T3=PEEK(20):T2=PEEK(19):T1=PEEK(18):T31=PEEK(20):IF T3<>T31 AND T31=0 THEN STARTTIME=128:GOTO 100 801 TIME=(T1*65536)+(T2*256)+T3-STARTTIME In line 800, if T3 and T31 are not the same, then the VBI hit during the reads. However, if it is just incrementing from, say 5 to 6, then it is no big deal as there is no carry involved. If it is wrapping from 255 to 0, that is when we start getting big errors, so we will only trap that case. To make sure that the next pass doesn't end up in the same place, we offset the starting timer value. Of coarse, it is still a good idea to average several runs.

Beware of the race conditions in the above code. In line 10, where you are clearing the timer, you could potentially have a VBI occur in the middle of the line, resulting in the second or third timer byte incrementing to 1 right after you clear it, but before you clear the next lower byte. It is probably better to clear them in the other order, low to high (weird that in this one case they decided to go big endian). Likewise, in your reading of the values, you could end up missing a 'carry' where you read the higher byte and then the lower byte wraps back to 0 before you read it. Maybe inhibit VBIs while reading these?

Since the order you do the memory modification doesn't matter, you can also use the classic optimization of making it a down counting loop and get rid of the cpy at the end of the loop. This will save 2 bytes & 2 cycles from the loop. Load Y with #(8*2)-1, and change the INYs to DEYs (moving the last one to the end of the loop, changing the "bne loop" to "bpl loop"). Change the adc/inc to sbc/dec, along with changing the initial value of destination to point to the last byte - ((8*2)-1) instead of the first byte.

Maybe find a friend with an APO address?

I just noticed in your pic that you used your Atari to generate your lucky number! How fitting is that? +1 coolness factor!

Looks like skr wins it. Target number was 43465, so only off by 2219 out of 1M. .2219% off, not bad. Pretty cool that the first guy to enter wins it!

182820

Mr. Robot, Did you get around to testing your V6 boards yet? I only see the gerbers for V4 on your website. Could you post the schematic for V6 for those of us adventurous enough to build it up on a protoboard? Thanks, - Stickjock

Here is mine, bought new in 1983. I remember getting a good deal. I think it had a $100 rebate or something. I also got a 1050 floppy drive with it. 411647 153 I noticed that my serial number is ~47,000 lower than the above example, but my date code is 16 weeks later than the above example (512 --> 153). Weird, huh?