Try an Apple IIe. Its simple enough you can look at the motherboard and see each major part, how its connected, etc. Get a decent intro assembly language on the Apple II book, and start having fun.

On Wed, Jul 11, 2001 at 10:11:25PM -0400, Eric Chomko wrote: You have a ROM monitor and (either on original ][s or the enhanced //e and newer) a small assembler. There are more sophisticated assemblers too. and machine language work together pretty nicely. -- Derek

On Thu, 12 Jul 2001, Richard Erlacher wrote: Here we go again. At the risk of offending Dick with historical fact, the Apple ][ was NOT "designed from the ground up as a video game". Certainly it implemented graphics and sound features, but these were just clever hacks by Woz that added these powerful features without significant additional circuitry. I don't know why I even welcome the eventual flood of nonsense from our friend Dick by even bothering to respond to his message, but nonsense coming from anyone should not go unanswered. BZZZT. Wrong again, the original Apple ][, as I just previously mentioned, had an assembler built into the ROM. Thanks for playing. Your consolation prize is a vat of molten iron. Just to keep things in perspective, when Woz designed the Apple-1, and subsequently, by way of evolving the design, the Apple ][, he very much had in mind the design elements and structure of mini-computers of the day. Woz told me personally that he was very inspired by the design of the Data General Nova (mostly because of the simplicity of it's circuitry). The big difference was that the Apple was designed around a cheap microprocessor, rather than implementing his own processor, which I think even you will agree makes more sense, considering the time (1975-76). The monitor feature was there from the start, and was the main interface by which the user interacted with or programmed the computer. Creating a BASIC interpreter was obviously an attempt to make the computer more immediately useful to the average computer geek of the time. More nonsense. The Apple ][ is a very good introduction to modern day PCs. It's cheap, abundant, and easy to use and program. What better way to learn about video than to HAVE to confront the video system limitations head on and basically write code to emulate what would amount to video hardware in other machines? Anyway, I'm putting my armor back on in anticipation of the impending battle. Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org

On Thu, 12 Jul 2001, Hans H?bner wrote: Uh, Dick, sorry. This was not meant to go public and provoke another post of you. Take it easy, will you? -Hans -- finger hans(a)huebner.org for details

On Thu, 12 Jul 2001, Richard Erlacher wrote: Haha. This is like the asshole asking who farted. Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org

At the risk of opening old wounds, I'd point out that there's a significant difference between microprocessors and microcomputing. While the one requires the other, and while the Apple][ is an adequate platform for microcomputING, it doesn't offer much support for learning much about microPROCESSORS, since they're a hardware device, and the Apple][ environment limits the user's access to such hardware features considerably. Microprocessors were developed, in large part, out of a need to reduce the amount of hardware that implementing various functions required. A good example would be a video terminal. The benefit that a microprocessor provides is that it allows the same logic, i.e. that in the CPU to be used for several purposes, while most functions in a comparable device fabricated using MSI/SSI logic functions, as was the custom prior to the availability of microprocessors, required that each function be discretely provided with dedicated logic. The business of learning about microPROCESSORs involves lots of things other than BASIC programming, assembler, or the availability of monitor ROMs, most of which are, in fact, hardware-related, rather than software-related. These are all very important with respect to microCOMPUTING, but, after all, the differences between microCOMPUTING and computing in general, are simply a matter of the choice of platform. The business of learning about microPROCESSORs involves issues such as system timing (not an easy thing to change in a video-dedicated environment), effective decoding techniques, (not an option in a fixed environment, particularly one requiring limitations on hardware/software interactions as the Apple][ imposes, doesn't lend itself to learning about the microPROCESSOR and its use. MicroCOMPUTING can be investigated on nearly any platform, but learning about microPROCESSORs is more a hardware process, certainly one requiring understanding of hardware/firmware interaction, but nevertheless one which is based in the way the microPROCESSOR works and not so much dependent on whether one is using a resident monitor or a cross-development software suite on a mainframe to generate the code under study. Apple][ is a fine place to do your software/firmware development, if you have the tools to support your effort. It won't allow you to do much of the stuff that microprocessors were used for back when the '70's and '80's, however. Microprocessors were, after all, not develped for the benefit of computer hobbyists. MicroCOMPUTING was not widely accepted as a form of COMPUTING until the PC was legitimized by the placement of the IBM logo on a microCOMPUTER. MicroPROCESSORS, however, were in wide use in appliances, switching systems, communication devices, etc. by then. The Apple was a nice video-based and clearly graphics-targeted system. At the time it was developed, there were few applications for the graphics, aside from games, and that's what Apple promoted early on. One important thing made it different from many other systems was that its designer(s) were clever enough to see that it could be applied in a much more general way than many of their predecessors had done, or even than their successors would do. They wisely cooked up a memory map that left fairly large contiguous regions of memory available for use by user programs, albeit interrupted by segments of graphics memory. Although the Apple was a decent platform for microCOMPUTING, the very features that made it desirable for the home user were likely to interfere with the process of learning about the details of microPROCESSORs and their application. Development of computing platforms, after all, was then, a really small part of the microprocessor market. No system as complex as the Apple could provide a particularly good environment for learning about the generalities of microPROCESSORs, if for no other reason than the number of compromises that are made in getting a system to completion. Microprocessors were devised in order to minimize the extent of the hardware required to implement a given function. Making a circuit general enough to provide a computing platform was probably not an initial goal. The fact that it was so easy to get there from the basic concept is, of course, one of the great things about this technology. As in that infamous previous thread, it seems some people have chosen to read what they wanted to read rather than was was written. That's not my fault, though. Dick ----- Original Message ----- From: "Eric Chomko" <chomko(a)greenbelt.com> To: <classiccmp(a)classiccmp.org> Sent: Friday, July 13, 2001 9:35 PM Subject: Re: Apple II for into to microprocessors as a on-topic Festival http://www.vintage.org

Since you apparently believe you've found some self-contradictions, perhaps you'd like to point them out. I'll be happy to explain my meaning, since I certainly haven't changed my thinking on this matter. The fact remains that while the Apple along with nearly any other platform is quite capable of helping one learn about computing, it's pretty limited where learning about microPROCESSORs and their application is concerned. Dogging the Apple, which, admittedly, I never learned to like, won't shed light on what will really be helpful as far as teaching folks about the application of microPROCESSORs, and dogging the Apple isn't what I set out to do. I simply wanted to point out that, while the Apple does support plug-in cards, it has a number of limitations resulting from the compromises involved in integrating the processor with the video timing and I/O scheme that was selected. A device that would probably be more educational is the Motorola MC6801L1, which is a 6801 with the Lilbug monitor in ROM, or a Motorola MC68701-1 programmed with the LILBUG monitor (available for free on their MCU web site). This device has a number of configurable "modes" in which it can be used, ranging from "single-chip" mode to a full-blown microprocessor mode, and several in-between modes. With the 6801L1 you have the Lilbug debug monitor which has a mini-assembler built into it. There's very little external hardware needed to make this thing work, and anyone interested in microprocessors as anything other than a personal computer/video toy, would have little difficulty hooking up the necessary oscillator, switches, and serial port buffers to make it into a simple development/evaluation tool. Since it's capable of producing a set of parallel ports, or of producing a full 16-bit address bus and 8-bit data bus with the aid of an external address latch, it offers the user an opportunity to fiddle with the timing, decoding logic, etc, as he sees fit. Use of the monitor, however, requires that one choose one of three baud rates, provided by the firmware. The device, however, is capable of a wide range of baud rates, etc. It is really a very impressive device, contemporary with the 68000 and 6809, but targeted at a different market. There's also a ROMless version, the 6803, which is often found on old ST-412-style hard disk drives. Miniscribe, CMI, and others used the 6803, and RMS and others used the 68701, which is the EPROM version. Hitachi made a compatible set of devices, though their EPROM parts used a piggy-back EPROM. The 805x family is another set of processors that offer some interesting possibilities, including a built-in serial port, and the 803x types are the ROMless versions of them. These are still widely available today, most notably in EEPROM/FLASH versions from ATMEL and others. There are a lots of free development tools, e.g. assemblers and a few compilers, for the 805x family and a few resident debug monitors. Dallas Semiconductor makes a RAM-based version of the chip that allows it to be used as an in-circuit development tool, among other things, and Intel, among MANY others made an 875x series, which used EPROM. These things have been around for nearly 20 years and their popularity hasn't seemed to wane much. They are, like the 6801 series, capable of functioning either as a single-chip device or as an expanded microprocessor with a 16-bit address bus and an 8-bit data bus. These were also used on a wide range of HDD's likely to be lying in the back of the closet. I'd say either of those devices, available during the Apple era, would give more support to one wishing to experiment and learn about the use of microPROCESSORs than does the Apple, or any other desktop platform. The reality simply is that involvement of the processor in a platform like the Apple, with its video and I/O features, is necessarily limiting, hence interferes with learning about the features which are most critical to microPROCESSOR application, e.g. timing, decoding, and other low-level features of that ilk. Dick ----- Original Message ----- From: "Sellam Ismail" <foo(a)siconic.com> To: <classiccmp(a)classiccmp.org> Sent: Saturday, July 14, 2001 9:25 AM Subject: Re: Apple II for intro to microprocessors

see inline comments below, plz. Dick ----- Original Message ----- From: "Mike Ford" <mikeford(a)socal.rr.comTo: <classiccmp(a)classiccmp.orgSent: Sunday, July 15, 2001 11:46 PM Subject: Re: Apple II for intro to microprocessors requires While there are a lot of processor-application-related things you are prevented from, or at least, restricted in, accomplishing because of the restrictions placed on the hardware by the design of the platform, there certainly isn't anything you can't do from a computing standpoint. However, that was my point. The things that define a microprocessor-based system are fixed in the Apple, mostly by its video timing restrictions, but also by its memory map and the way in which I/O is managed. If you want to focus on the computING, it doesn't matter what platform you use, since the platform will always impose restrictions that prohibit you from applying the microprocessor fully so long as you're bound to that platform. That's why, no matter how well-designed a "development system" was, it was still difficult to manage the precise target timing. Consequently, many microprocessor-based devices were badly designed and implemented, since their timing was based on the development/in-circuit-emulator system rather than the precise system requirements of their target. The devices I recommended allow their synchronization with any task, yet still allow all the computing capabilities of the device to be exploited. That's where the meat and potatoes of the application of microprocessors, at least when you separate the computing tasks from the hardware operational requirements. That was, after all, the point I was trying to make. For example, right on the floor at my feet are three microprocessor-based hard disk drives. These are perfect examples of what I was driving at, namely, that there are several processors on each drive, and each processor has a specific task, for which it has a carefully selected operating frequency and a processor that accomplishes that task efficiently because it was chosen for an instruction set that provides features desirable for its tasks. This drive in my lap has a Motorola processor handling the host interface, a TI DSP to handle servo and read/write channel issues, and an Intel '188 to manage data transfers and bufering between the two. Another drive, from the same mfg has an Intel processor to manage the host interface, a different MOT processor, and a couple of Fujitsu DSP's. Each one is essentially a separate subsystem with its own memory and I/O. Each one operates with a crystal selected for its particular role in this system. If you look in your supply of old hard disks, you'll undoubtably see much the same thing. It's impossible to guess how much SSI/MSI hardware these replace, but it's for sure that they replace a lot of it, and, because they're computers rather than fixed logic, they can be mdified with much less hassle than the SSI/MSI hardware could have. If one had tried to work out the timing and the various decoding and other I/O related tricks used to do these jobs on an Apple, or any other platform dedicated to its video or other subsystems, it would have been MUCH more difficult than it had to be. It's true, through computing, it's possible to calculate how long a given loop takes, and, with considerable effort, to calculate how that might interact with a process occurring in another subsystem operating at a different rate. Most in-circuit-emulators didn't even support speed-switching or different target and host execution rates. You either operated at the host rate, or the system didn't work properly. There's no question that one had to read quite a bit. However, most of the materials written about microprocessors were really dedicated to microcomputing rather than the application of microprocessors. Device manufacturers weren't of much help either because they wanted you to buy their particular development systems, with their limitations, and those didn't often help very much. In the late '80's, third-party develpment support systems ultimately provided support for those applications, of which the HDD's I mentioned were a typical example. The advantage was that the platform didn't restrict the operating rate of the emulators, since each one was slaved to target system timing, and the host system used resources independent of the MPU support hardware. None of this says that a given thing CAN'T be done, but it's certainly not as convenient to work out a firmware set for a microprocessor that will be processing data at a rate derived from the 1.544 MHz T1 rate on a system that's firmly bound to the timing of a 3.579 MHz color burst crystal. Even if they're running at the same nominal rate, the variation between their respective timing references cause problems. Moreover, when you're devising a subsystem that will be using its own private memory and I/O resources, having a fixed platorm's memory decoding scheme imposing its restrictions on what you do won't make your work easier. That's why I recommended the devices I mentioned in my previous post as a more convenient alternative to the Apple or any other fixed platform. They make it much easier to isolate the processING from the processOR. After all, the firmware/software can be develped on any platform. The hardware is the reason that microprocessors became so important, not to suggest that they could function without the firmware/software, but you get the picture.

There's no doubt about it, Mike, the Apple was quite useful for a lot of things. I simply pointed out that with a different device, costing about $90 rather than the considerably more that an Apple][ cost back in '79, you could do much of the same stuff, unfettered by the restrictions that the Apple hardware put on you. Now, I don't remember what an Apple proto card cost back then (I still have one of those I bought back in '80) but those were bought to build a HDC for the Apple. I find the 6801L1 quite a bit better for dealing with the basics of handling microprocessor related issues, since they don't have the video timing logic defining the clock rate. That's not because the Apple is bad, but because it's easier to deal with the naked processor than the entire system. Having the ability to define a clock rate based on your application needs rather than those of the video timing makes it possible to save on costs and effort. Many applications, particularly those of low volume, make it cheaper, overall, simply to build an Apple, or, nowadays, a PC into the solution. Dick ----- Original Message ----- From: "Mike Ford" <mikeford(a)socal.rr.com> To: <classiccmp(a)classiccmp.org> Sent: Monday, July 16, 2001 2:09 PM Subject: Re: Apple II for intro to microprocessors

I was one of those who went for the AIM-65 when it came out, but found it too limiting because of its "features" and facilities. It seems that the more facilities a system provides, the less flexibility one has in its use. I stand by my previous comment, namely, that the single-chippers with a built-in or programmed-in monitor offered a better solution to the problem of LEARNING/EXPERIMENTING with microprocessors than did either the Apple or the AIM-65 or other devices of that sort. Hindsight's always 20/20, as they say, and I base that comment on the fact I've been able to figure out more things with a single-chip device that could be adapted to a task without hindering its I/O capabilities, yet didn't have to be slaved to the I/O either. Your comment about the FDD's is right on target, Mike. That's why so many people used the Apple][ for development. Writing an OS for the AIM or something of that ilk, or, for that matter, for a single-chipper, would have been a serious pain, and, for most of us, unlikely to happen. However, with a ROM-resident debugger and line-by-line assembler, it was possible to get quite a bit done. The LILBUG monitor, which is what was built into the ROM on a 6801L1, as an example, had a reader and punch function, which could be used to dump to an audio tape interface, though I personally never used it in that way. It could also be used to dump to a serial port, and, with a host system that used its console as a terminal to the single-chipper, you had lots of options where lodaing and saving code were concerned. The Lilbug monitor has the option of allowing its console function to be routed through an external serial port at a user-defined location, and to use an external counter/timer chip as well, though I'm not sure why except perhaps to free the internal faciliites for development use. Routing the console to an external ACIA (MC6850) is helpful when one is developing an application that requires the presence of the internal serial port and counters. It does, of course, place restrictions on what one can do, but I find that a small price for the added funcitonality in cases where it's needed. It's the same way with the Apple hardware environment. If you want the functions, you have to put up with the associated restrictions. It certainly wasn't difficult to use a CP/M box to send a block of code to the resident monitor on the single-chipper. Back then I used cross-assemblers under CP/M (this was before the rise of the PC) to support those efforts. Using a monitor that had the capability merely to dump a block of binary code translated to ASCII-HEX to the console was enough to enable the file to be saved on a host system. That rendered the use of a dedicated develpment system with in-circuit emulator unnecessary, though not totally without potential merit. Dick ----- Original Message ----- From: "Mike Ford" <mikeford(a)socal.rr.com> To: <classiccmp(a)classiccmp.org> Sent: Monday, July 16, 2001 10:01 PM Subject: Re: Apple II for intro to microprocessors you.

Quoting Mike Ford <mikeford(a)socal.rr.com>om>: I once contemplated building an eprom emulator from one of Ciarcias columns (198x Byte, when they still had articles). The reason for this OT message is that I almost ruined my keyboard with coke when I read the product name. Romu means junk in Finnish, Romulator -> Junkulator -> Junk-U-Later. I'm such a bore. -- jht

Hopefully I haven't screwed the attribution here... If it was a genuine "Romulator", it may have been made here in Columbus by a friend of mine - Grammar Engine produced the Romulator about 15 years ago and later produced the PROMice. I have one of each. They are awesome. I had to code the ROMs for our VAXBI product and using ROM emulation gave me about 50 edit-compile-download-test cycles per day instead of 5-10. The big benefit was that I didn't have to power down the 8300 to change out the ROMs. Arvind gave me the source for the download program and I got it working under VMS so I could compile the 68000 target code (on our homegrown assembler) and shoot it into the COMBOARD, all from the same makefile! I can recommend highly anyone doing firmware development to have one of these. -ethan ===== Visit "The Seventh Continent" http://penguincentral.com/penguincentral.html __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

--- Mike Ford <mikeford(a)socal.rr.com> wrote: Yep. Confirmed. That's them. I hadn't heard of the RomRocket, but I am familiar with the older stuff. Got one here that's rigged for 16-bit operation. Great for 68K work. I was assembling on a VAX 8200 and squrting the binary out to the PROMice over one of the internal console ports - not high speed output. 9600 bps, but I'm pretty sure that described the bit time, not the bandwidth. We dropped $13K on the CPU, RAM and disk controller. We did had them pull the Ethernet and any other I/O to get the price _down_ to that! (later we got another CPU card and I managed to fiddle around with console media enough to get the CPU revs to match and, voila, an 8300. The last thing I got to work in it was a couple of 4Mb VAXBI memory cards I got from a scrapper for $10 each (he was going to strip the DRAM off of them) I have a DEBNT but don't know how to install the cab kit). Grammar Engine has been in the ROM emulation market since about 1988, give or take a bit. I may be biased, but I can at least recommend their older products. -ethan ===== Visit "The Seventh Continent" http://penguincentral.com/penguincentral.html __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

On Wed, 18 Jul 2001, Richard Erlacher wrote: I have always reassured my programming students that nothing that they accidentally enter through the keyboard of their computers would actually DAMAGE the computer. One wiseguy said, "I entered a Pepsi." After Three Mile Island, Saturday Night Live postulated that it was caused by "The Pepsi Syndrome", the result of spilling a Pepsi into a computer keyboard. Shortly after that, the U.S.A. and USSR (CCCP) normalized diplomatic relations enough to import vodka and export Pepsi to Russia. That was followed almost immediately by Chernobyl. Surely that could not be coincidence! Until their recent bailout, Apple computers ride into failure was with a former Pepsi exedcutive at the helm. Coincidence?

A non-text attachment was scrubbed... Name: not available Type: text Size: 489 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20010718/8ec0c72b/at…

I had one of those, albeit for the S-100 bus, and found it functional but not as useful as I'd originally hoped. It did save a little time, but all it really saved was the time used to transfer a binary file into the target system's memory. The things the more generously appointed systems like the AIM or the Apple don't allow you to do is (1) use address lines as device selects, (2) use ambiguous decoding, (3) adapt the processor speed to the code being executed, (4) anything else that involves changing system memory mapping or system timing to the target application. That's what I mean by "their features get in your way." They can compute anything you like, but the rate is dependent on their internals rather than your target. It happens I have the AIM schematic right here and what it indicates is that you might have a little trouble finding a block of space for your target application hardware in the memory map. The notes on my schematic indicate that I had to use a modificaiton to open a block of space for an external application hardware addition. The Apple memory map available for expansion hardware is a mite trickier, i.e each slot hin the backplane has different addresses available, yet each shares a chunk of space intended for a ROM. It's not terrimbly difficult to work around, but it means, at the outset, that you have to learn about the Apple rather than the target. Dick ----- Original Message ----- From: "Mike Ford" <mikeford(a)socal.rr.com> To: <classiccmp(a)classiccmp.org> Sent: Wednesday, July 18, 2001 1:39 AM Subject: Re: Apple II for intro to microprocessors

see inline comments, plz. Dick ----- Original Message ----- From: "Mike Ford" <mikeford(a)socal.rr.com> To: <classiccmp(a)classiccmp.org> Sent: Wednesday, July 18, 2001 11:03 AM Subject: Re: Apple II for intro to microprocessors Yes, but, since the original question was regarding learning about microprocessors, which are hardware components, and not system/software-products, that requires lots of effort dedicated to learning tools that don't really need to be learned in context. Number (3) is very GOOD form, since microprocessors are HARDWARE and hardware should be optimized for each task it performs. Microprocessors are just substitutes for dedicated hardware, and, in the examples I mentioned before, they'd fall apart if they had to operate at rates a few percent off the rates at which they function. If you limit a processor to one oscillator frequency, where you started out with a virtually unlimited capability, you end up with a VERY limited system. Making the thing faster won't always make it better, where making it operate at the correct speed, where a loop can be precisely synchronized with a process operating at an independent rate, will make things work. This wouldn't be an issue, of course if the processor and memory in an Apple or AIM were infinitely fast, but they're not. If you fiddle with the AIM's oscillator, it might work, but until you study out the precise effects on timing, say, of the print resistors in the printer, you may find that you damage things, or, if you speed it up, the motor in the printer may not work. It's true, you could rewrite the code ... but I dont' want to do that. Rather than a $300-400 AIM, I'd rather buy a $90 (prices are based on 1979, when the AIM was new, as was the 6801L1) component, and build the target hardware so it runs at a rate that suits the application. It's HARDWARE, after all, and it should suit the applicaton, not the development system. Those techniques are fine, but they don't relate to the task of learning about micorprocessors. They may be involved in a given implementation, but they don't address the needs of a student learning how to build microprocessor-based hardware. Elegant hardware is the simplest, least complicated, least costly, that does the job while meeting all the spec's, including reliability. In some applications, 99% was good enough. Computers, including microprocessor-based hardware, that don't achieve a part in 10^9 reliability need thorough study, however. The problem is that if you write code that relies on a 0.768 MHz Phase-0 clock, it's awfully difficult to test in an Apple. The hardware/firmware boundary is probaly the most critical issue in microprocessor system design. That's what makes the Apple as good as it is at what it does, but it's also what makes it as poor a solution as it is for what it doesn't do well. It has absolutely no flexibility in its execution rate because it's tightly coupled with the video circuitry. There's even a "skip-a-beat" cycle in which it keeps in sync with the color burst. That's one that someone pointed out to me back in the late '70's when the Apple was new, and, while it's a clever way to do what they needed to do in order to make the Apple what it is, it's just exactly the thing I'm saying makes the Apple a poor environment for learning about using microprocessors, which are, after all, a hardware element. What platform you use to develop software is completely arbitrary, since anything at all will work, whether it's a 1 Hz 4004, or a 1.5 GHz Pentium. The timing may vary, though. It takes a while to learn the stuff that it's necessary to know in order to use the Apple. It takes a while to learn nearly any environment. However, learning about the way in which software is implemented when your job is to produce hardware, is something that CAN get you fired, and always WILL make the schedule slip.

Say ... Which Apple OS is the ][e supposed to run? I have checked out that IIe and it appears to work OK, but I've not yet found a bootable diskette. Does it run the same DOS as the ][+? If this stuff all works OK it won't be such a bad deal, now, will it? Apparently the ][e uses a serial printer. Perhaps I should have looked around for that. It uses a wierd PS/2-like connector to communicate with the thing. Dick

I can recommend you consider that the difference between the fastest speed and the optimal speed comes down to a number of things. Consider one case, wherein we speeded the operation of a multi-computer security system by reducing the baud rate of the monitor terminals from 9600 to 1200. That reduced the amount of idle (ENQ/ACK) traffic by 90%. Moreover, lots of I/O tasks require too much speed if you have to test a flag before fetching each byte. However, if your processor is running at a rate synchronized with the transfer, you only have to check the flag once, then use a loop tuned for the exact length of the transfer cycle. As Tony points out, it's based on the externally imposed rate, and if your oscillator doesn't synchronize with that, you have problems. Dick ----- Original Message ----- From: "Mike Ford" <mikeford(a)socal.rr.com> To: <classiccmp(a)classiccmp.org> Sent: Thursday, July 19, 2001 12:16 AM Subject: Re: Apple II for intro to microprocessors

As you get close to the limits, there are plenty of wrong ones as well. Dick ----- Original Message ----- From: "Mike Ford" <mikeford(a)socal.rr.com> To: <classiccmp(a)classiccmp.org> Sent: Friday, July 20, 2001 3:46 AM Subject: Re: Apple II for intro to microprocessors and amount

On Wed, 11 Jul 2001, Eric Chomko wrote: CALL -151 ...will get you into the machine language monitor. Enjoy. Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org

Its been a few years, but call -151 drops you into the monitor, with a miniassembler and various other simple tools. BTW I bought a cheapo book at MicroCenter that included a software emulation/display CD of some processor, I can't remember whether it was powerPC or AMD, I am thinking its the K6. I'll have to look around for it.

A non-text attachment was scrubbed... Name: not available Type: text Size: 554 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20010712/79ee246a/at…

I'm pretty sure it's there in the same file as intbasic Eric

I recall that now. I believe that by looking at the ROM listing in one of the older Apple ][ reference books I was able to get the step and trace commands back (and save a copy). Eric

On Mon, 16 Jul 2001, Tony Duell wrote: I've got the manual for it that I recently put away in a box. The next time I get out to my warehouse I'll pull it and then scan it for you. I never used it myself (I started with a second-hand ][+ and everything that came before that was unknown to me until I started collecting :) but apparently it contained subroutines that were useful to the machine language programmer; common routines that you didn't have to spend time writing yourself. Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org

A non-text attachment was scrubbed... Name: not available Type: text Size: 1024 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20010712/e77ce80e/at…

A non-text attachment was scrubbed... Name: not available Type: text Size: 1322 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20010713/a5d3fe3c/at…

A non-text attachment was scrubbed... Name: not available Type: text Size: 447 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20010714/5a020c75/at…

the early macs at least also have a built in ROM-Monitor :) probably the later ones too, although I think that they stopped including in the powermac series. At 04:05 AM 7/14/01 +0100, you wrote:

My B/W G3 still has the programmer's switch on the front panel and I believe that the G4's we have at work still do as well. I don't recall if the iMac's do or not. When pressed, it still drops you to the '>' prompt but none of the manuals that ship with the machines tell you anything about it. I've never been able to exit back out of it without rebooting, nor have I actually gotten it to show any of the info one generally does from a monitor program. Jeff -- Collector of Classic Microcomputers and Video Game Systems: Home of the TRS-80 Model 2000 FAQ File http://www.geocities.com/siliconvalley/lakes/6757

Given the talent on this list maybe we should come up with a little tutorial on using a vintage system like an Apple IIe etc. as a microprocessor learning station?

Tony Duell wrote: I lucked out at a flea market about 10 years ago and found one for $15 or so. It had a US style plug, so I figured it would work fine "over here". It did, with a few caveats: 1. Unlike US micros, which had a TV output on Channels 3 or 4, the BBC output RF on UHF (Channel 37 or something like that). Of course, the channel numbers and frequencies used in the US are different than those in the UK. 2. It still outputs a 625-line screen, which my 525-line US TV can only display a part of (some lines off the top and bottom are missing) 3. It outputs PAL color, so a NTSC TV will get a monochrome picture (It also supports direct RGB output, so, theoretically, I could wire a cable that would connect it to a monitor, fixing all of those problems) 4. Support can be hard to find in the US. I remember having to dig through several different (public) libraries, looking for books about the machine. I even wrote to a BBC users group in New Zealand, and got one of their newsletters, but at that time (late 1991), they seemed to be more focused on the Archimedes (just as most US-based Apple user groups turned their attention to the Macintosh). I haven't run this machine in about 10 years, so who knows what will happen if I try to turn it on...

A non-text attachment was scrubbed... Name: not available Type: text Size: 2521 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20010715/894701fe/at…

A non-text attachment was scrubbed... Name: not available Type: text Size: 2420 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20010716/2600b426/at…

Hi gang, This looks to me like a truly classiccmp.subject, except its not exactly UNIX/VAX stuff: even if I run Linux on it. How do I make the Toshiba pa2701u docking station capable of running with a cdrom (instead of the floppy)? There are two ISA slots in it. Use an ISA generic drivercard and then? disable the floppy addresses and the serial and the IDE1 so as to have no conflict with the laptop addresses? Anybody know how to get into that durned box without a key? With a drill? Cavemen! Any info on this would be appreciated. Fred

Agreed. But I'm compelled to clean the unit as much as possible of dust and debris. prior to powering it on. Not sure if it is necessary, but a spray of canned air or power to a unit that has been sitting for years. Eric Sellam Ismail wrote:

On Thu, 12 Jul 2001, Mike Ford wrote: Apple ][+'s do still turn up from time to time. But yes, not nearly as often as they used to. Apple ]['s are pretty rare these days. Apple //e's are almost as common as Commodore 64s. Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org