On 4 Feb 2007 at 0:56, Tony Duell wrote: Thank you for absolving me of being the first to use the term "gutless wonder". :) In a way, I suppose the disk controller was a clever design. But it locked the CPU into 2MHz operation. The use of a simple arithmetic checksum for each sector was not perhaps the most reliable solution either. But the biggest problem is that disk reading and writing required 100% attention from the CPU. On most other computers that used dedicated LSI controllers, the possibility existed for overlapped computation/disk access. Cheers, Chuck

On Feb 3, 2007, at 10:12 PM, woodelf wrote: The Apple IIfx comes to mind.. -Dave -- Dave McGuire Port Charlotte, FL

What was it, the 8237, actually came on the ram board? I probably knew this at one time. I have about three of these things in the shed, I'll need to check them out to see if any has it. Yes true. Depends on how you want to interpret "IBM compatible". To some, pc and compatible are the same thing. In reality, an Apple II or a Commodore 64 is a pc. So...using the previous definition, a Sanyo MBC-5xx isn't really a "pc", nor a compatible. Not a very good one anyhoo... I used to call things like that semi-compatible, but the term is misleading. Now I just say pseudo- compatible. Some are slightly compatible, and many can use "well behaved" IBM peecee software - only accesses the hardware through DOS or BIOS calls, but to refer to a Tandy 2000 as a semi-compatible is just too darn crazy. ____________________________________________________________________________________ Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/

I thought every PC (maaning IBM compatible) did that. The floppy system in the PC. XT and ZT has a DMA channel associated with it. You ask it to read some secotyors from the current track, it does so and transfers the data into memory, then gives you an iterrupt when it's done. I know for a fact that other tasks carry on running on this (slow) linux machine when it's doing floppy drive operations. -tony

It might be stretching the term "compatible", but IIRC, the Peanut didn't use DMA for disk access. On a side somewhat related topic, how many disk controllers had their own track buffer (like hard disk controllers)? The Microsolutions Backpack is the only one that I can think of for the PC. The C64/128 drives probably had them, also. Cheers, Chuck

Chuck Guzis wrote: The northstar disk controller and many similar ones required the processor to suck in each byte anyway, so there was no chance there of the CPU doing something productive. Now look at the chip count of the nortstar controller board: http://www.sol20.org/manuals/nstar_MDS-A-D.pdf vs. the apple II disk controller (scroll down a bit): http://www.8bit-museum.de/docs/apple3b.htm# By comparison, the apple II controller is brilliant. Yes, there existed disk controllers with DMA, but those were more complex and cost a whole lot more in 1977. Besides, the Apple II had a great expansion bus, and some enterprising company could have plopped a 177x disk controller in machine at the point it made sense, but apparently it never did as its market was happy with what apple offered. The disk controller didn't lock the CPU into 2 MHz operation -- the CPU was 1 MHz. :-) Besides, the apple disk controller was a point solution for a point in time. Later Apples had higher speed clocks and could read/write the old disks. Obviously this inexpensive solution didn't preclude decoupling the CPU speed later once VLSI made it practical to do so. As for the apple II minimalism -- saving a chip here and there -- indeed, it is a toy compared to, say, the the way HP would do it. But then the HP would have cost 10x as much. Let's look at contemporaries (1977 micros). The Sol-20 had 64x16 text, and unless you polled the hblank signal and limited yourself to poking one character per 50 uS, you'd get snow on the screen. There were others that had the snow problem as well (eg, exidy sorcerer). The TRS-80 didn't have the snow problem, but it too had a 64x16 text display. The PET (which I never used) also had character graphics of the most pathetic sort. Now look at the apple. Yeah, crappy 40x24 text mode, but they were in color and, for the time, unheard of bitmapped graphics modes in a microcomputer. By running the DRAM at 2x the CPU cycle time and locking it to the video rate, all graphics could be written real-time with no snow and no wait-states. Other than DRAM and the CPU, all cheapo TTL. Tony said: Yes and no. They spent some chips to give the machine great expandability and color, bitmapped graphics. On the other hand, wherever Woz could save a chip (or ten), even if it meant an oddball mapping of memory to screen, was done to save cost and keep the board size down. It is fantasy to think that cost wasn't one of the most important factors in a successful home computer. I admire the design greatly for what it was and for the time it was done. The fact the machine came standard with full schematics and a commented disassembly of the ROM should not go unappreciated with this group. The machine has character, the good kind, in spades.

On 2/3/07, Jim Battle <frustum at pacbell.net> wrote: I would hardly call the PET character graphics "pathetic". It's true that dozens of pre-defined 8x8 pixel character blocks can't compare in rendering quality to a similar-sized mono bitmapped display, but back in the day, folks were quite creative with their use of the available characters. Sticking to shuffling bytes around rather than calculating pixel positions allows one to get some fast graphics on a 1MHz 6502, but it's true that true bitmapped graphics are much flashier than any character graphics. When I was using a PET at the library and sneaking time on the TRS-80 Model I at the local Radio Shack, one thing I never did on the TRS-80 was graphics. With the 6-blocks-per-character-position lo-res graphics, the TRS-80 could manage 128x48 individually addressable "pixels". By comparison, the PET character set had a pre-defined set of images that also allowed one to subdivide one character position into, in this case, four low-res "pixels". Since the early PETs had a 40x25 screen, that translated into 80x50 low-res pixels - obviously not as wide as the TRS-80, but taller, and with *square pixels*. The *excellent* machine-language Space Invaders game from those days used these chunky graphics to great effect to slide the Invaders from side to side and top to bottom. Another handy little feature of the PET character set was the ability to draw horizontal or vertical bargraphs with a much finer resolution. The characters were already there to draw a single "pixel" tall by 8 pixel wide line, two pixels tall, three, etc., up to 8, and the same for left-right. Coupled with curved and square box corners, one could put together a rather nicely formatted textual UI for virtual gauges, etc. All true there, but having programmed the Apple II for a living for a couple of years, I can say that the hardware shorcuts Woz took made the graphics a bit strange to deal with. Among other oddments, only 7 bits per byte in graphics RAM could turn into a pixel, converting a 40x24 screen to 280x192 mono pixels, or 140x192 colored pixels (color was really strange on an Apple II since it depended on phase shifting pixels that were too small for an NTSC monitor to resolve individually, resulting in a) color fringing, and b) *6* colors due to there being two flavors of white and black pixels (that's where the 8th bit went - to add or remove an additional 1/4 phase shift to that byte - leading to strange boundary effects). Because of the "only 4 colors per 7-pixel-wide-region" restriction, it was common to stick to only the black/white/green/purple or black/white/red/blue palettes to minimize the strange fringing one got trying to pass shapes with one palette over shapes from the other palette. So, yes... the Apple II had color, and it had bitmapped graphics, which were unique in the micro world in 1977, but due to how they were implemented, one could *not* turn on arbitrary color pixels without first considering where they were on the screen and what else was going on around them (one _could_ turn on each and every mono pixel of the 280x192, but applications writers tended to focus heavily on color graphics, not mono graphics - "Bolo", an overhead-view tank/maze game being one counter-example that I can dredge up right now). I don't know which home computer was *the* first to be able to set any pixel on the screen to any desired color, but I'd have to think that few famous ones did it before the Atari 400/800, a few years after the Apple/TRS-80/PET days. All that having been said, though, the Apple II was an amazing design, it was quite popular, and, through the Apple IIe and Apple IIgs, stuck around, warts and all, for a long, long time. Longer than the TRS-80, and longer than the PET, its true contemporaries. Even though the remembered "my computer is better than yours " battles might have been between the Atari 800, the Apple II, and the C-64, only one of those machines was around in 1977. The others had faded away. -ethan

On 2/4/07, Fred Cisin <cisin at xenosoft.com> wrote: I did not mean some other year - what I meant was that in the louder battles of the 1980s, between the Atari 800, the Apple II, and the C-64, only the Apple II was around in 1977. The other computers were 1980s technology, not late 1970s technology. Right. Sort of my point, except I was trying to point out that Apple's offering survived more than one round of "my X is better than your X". -ethan

On 3 Feb 2007 at 22:56, Jim Battle wrote: The DIsk II didn't come out until 78. The 1977 Apple had only a casette interface. Remember that OSI (from around the same time) used a 6850 UART for the same purpose, yet OSI didn't get any acclaim for the "genius" of the controller. Instead, it got slammed for the incompatibility of the floppies. A major part of Apple lore, it seems to me, is the mystique. Cheers, Chuck

Wouldn't the difference be that the more complex cassette interfaces are less prone to error? The MITS documentation says that the 680-KCACR accepts a -20 to +20 % speed variance. I have played basic into my Altair with two recordings. One of them is 10 minutes long and the other is 13 minutes. Neither recording is demodulated at 300bps. Both of them load with no checksum errors, the recordings are speeds. I would be interested to find out if the Apple II was as good. Does the Apple II use the same or a similar circuit as the Apple 1? Woz has a schematic for it in the Wonderbook or whatever that big PDF is called. Pretty much a comparator or opamp connected to a data line for demodulation. Grant

[Apple ][] In once sense it was, it was a very minimal-component-count design. But I do wish it had had a track 0 sensor (which wouldn't have added much to the design and would have kept the drives in alignment a little longer...). The downside was that it was incompatible with everythign else. You couldnt send disks to owneres of other machines. That to me is a major minus-point. Apple seem to have an aversion to interrupts (This carried on into the early Macs too it appears). -tony

On 2/4/07, Pete Turnbull <pete at dunnington.plus.com> wrote: That was a problem I also saw with the drives. Several of my friends had Apple IIs (I had a 32K PET 2001-N), and ISTR more than one person did that. Not cheap. My memory is that at the time, the bare drives were $600 new, so even if one just replaces boards, it's not inexpensive in that environment. The 6520 == 6821 FWIW. I don't recall how much those were, but new 6522 VIAs were $8 quantity 1 in the early 1980s, so I think Woz may have just shied away from them on the basis of cost alone. I did enjoy learning how to twiddle the PET user port on a 4K PET. More complicated than the Apple scheme (data direction registers, interrupts, etc.), but vastly more powerful. -ethan

"Ethan Dicks" <ethan.dicks at gmail.com> wrote: I recall that the "off by one" cable mistake required replacement of a socketed chip, a ULN2003-type driver? A less than one dollar part. I know we like to argue about component level debugging, but there's only a small number of chips on the boards involved, all socketed. Heck, except for the PROM you could replace every single chip for circa $12.00. Tim.

--- Tony Duell <ard at p850ug1.demon.co.uk> wrote: I guess this could be said about a lot of units, but a coco in particular seems to be a pretty good way of studying computer hardware initially. The 6800 was fairly commonly used in sbc's back in those days, and the 6809 is just a step up from that. I can't say anything particularly bad about it's makeup, and I'd bet it was way more reliable then a Commie 64. I can't speak much of the other TRS-80s (except the model 2000, which few people realize WAS a TRS-80) never played with any of them, and in reality a Z80 based micro is probably an even better platform to learn on. ____________________________________________________________________________________ Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/