Hey!

I've got a question for the Apple-heads out there . . .

I've had this Apple //c lying in the basement for some ten years or so and have yet to find a reason to keep it. So far the only reason is that I'd have to carry it up the stairs.

Is there some clear and simple way to extract useful work, e.g. monitoring and control types using bitwise I/O from it? There is a built in printer port and there's a serial port as well, but I doubt the serial port is of any use because it's so slow. Nevertheless, I'd like to see if it's useable for bitwise I/O functions.

Has anybody got data/experience/information they'd like to share?

I'd even consider building in a PIA or some such device to get the bits out, but I need more info than I've got.

Is there a clear picture of the memory map out there somewhere?

Uli

I have one of those and a pair of Apple II+'s, too...

Anyway, I think you will find the serial ports are plenty fast enough to communicate with a Basic STAMP processor, which can handle anything from 300 baud to 2400 baud. The Basic STAMP (or STAMP II, which can handle up to 38400 baud and has a lot more memory and I/O) is great for small control jobs, and the programming language is very easy to learn as it is just a stripped-down BASIC with special instructions for pin-wise I/O. Their website is www.ParallaxInc.com

If you need more "punch" from the controller, look into the BasicX chips (see the last couple issues of Circuit Cellar magazine for details). These are astoundingly fast amd powerfull single-chip microcontrollers which are programmed in a language fairly similar to Visual BASIC or QuickBASIC. I'm just starting to work with them, and I'm VERY impressed. I think the website is www.NetMedia.com.

Both chip families enjoy wide support and web-based user's groups, and allow multi-chip networking. The BasicX chips also provide for multitasking on a single processor.

When I sold my old Apple II-GS I was able to transfer all of my source files and data over to my new IBM through a standard serial cable, using the Apple serial port as a printer and running a terminal program (PROCOMM) on the IBM to capture the text to files. If you try to open an IBM's serial port in QuickBASIC you need to feed-back the IBM's DTR output to the DSR input and the RTS output to the CTS input -- some terminl programs may require this as well. I never tried running data BACK from the IBM to the Apple, but I see no reason why it would only work one way once the cabling was correct.

The biggest headache to overcome when interfacing the Apple II family to more modern equipment is that the Apple's serial I/O was usually fixed at or at least defaulted to 7 data bits and 1 parity bit ("ASCII mode"), while the standard for IBM machines which have taken over the earth is 8 data bits and no partity ("binary mode"). You can usualy change these settings when you first open the serial port. Also keep in mind that the Apple uses just a carriage-return to terminate a line, while the IBM uses carriage-return plus line-feed.

You will probably want to send at least 2 stop bits, to allow the receiving computer or microcontroller time to process the information.

As for memory map, I will try to dredge up my manuals for assembly-langugae programming of the Apple IIc, they and "The DOS Book" had a lot of detailed information. If you don't have them already, you can usually find the manuals at used computer stores (often in the back or on the dustiest shelf) and swap meets, sometimes at Goodwill or Salvation Army stores, too.

Lastly, I think the Apple IIc had an expansion interface that allowed access to the adress and data bus, but it might have required taking the case apart to get at it. Now you've done it, I have to go dig MINE up from the garage and refresh my memory!

As for bitwise I/O from the printer port, I don't think the Apple ever supported bidirectional I/O through their parallel port and in fact I think the built-in printer port on the Apple IIc might have been serial just like in the IIGS. But if it was a Centronics-type parallel port, you can write 8 bits at a time to control things and then have one of the things controlled be a data selector to feed bit-wise data back to the printer status pins where you can test them. You'll probably have to use PEEKS and POKES to avoid getting device error messages, though.

Well I hope this has been of SOME use rather than just a bunch of completely theoretical ramblings! I'll try to have a look through my IIc's manuals this weekend and see if I jostle some memories that are more direct answers to what you wanted.

-- Brian Farley

I do believe you've misinterpreted what I want. I'm looking to get some useful work out of the APPLE //c. by that I mean that I want to use the thing to do the useful work, not to tell somebody else to do it. With one bit of output, I can fire a solid state relay. With one bit of out and one bit of in, I can close the loop, testing for success or failure of whatever the output bit did. If I were interested in using a single-chipper I'd do that, though it's unlikely I'd ever use a Basic Stamp. (There's always a first time!)

I'm interested in finding out where the parallel port bits are and how many of them there are, particularly for input. It's not inconceivable that I'd use parallel port bits for the main output and perhaps use some serial port control/handshaking bits for input, just to get enough inputs. However, the goal is to do SOMETHING useful with the //c.

A fellow wrote me that there are several parallel ins and outs associated with the external floppy port. I don't know which or how many of the control port bits are available if one's not using the FDD at the time, but that might be enough. SInce I generally don't like open-loop processes, some number of inputs is essential, however.

I have Apple][+ hardware lying about too, but I haven't fire up an Apple of any sort for many years. I only bought the 7 or so Apple machines I had at one time because it was cheap and easy to use them for the one job for which I bought them. Afterward, they were given away or sold off. Unfortunately, I have two of their main-boards and one box (missing the lid) that's not assembled and probably will be a spare board if that ever becomes necessary/desirable.

I have the manuals for the ][+'s but nothing on the //c.

If nothing else works I could probably scab a CMOS PIA onto the inside of the box somewhere and bring signals out from that with a thin ribbon cable. However, I'll need the memory map in order to do that. I've got a ProDos boot diskette somewhere, methinks, so that should get me running, though I don't know whether I have a suitable assembler/editor package.

If you know of or run into a site having details about the //c hardware, memory map, etc, please share it with me.

regards,

Uli

http://rich12345.tripod.com/messin.html

At the top of the screen is a memory map. Ignore the softswitch notes, they are for accessing auxillary memory.

aiiadict@hotmail.com

Rich

It would appear that there's no indication of where I/O is mapped, though, or I don't see it. It's implicit in the location of the various soft switches that there's a dedicated region of address space at 0xC000 upward for some (?) space upward from there, but unless the list in the page to which you've referred me is complete, I may have to root around some to find a block of, say 16 consecutive locations into which to fit my I/O logic.

Thanks for the pointer!

I've determined that there's sufficient space under the keyboard to locate a buffering circuit and there's space into which a 3-1/2"-floppy-sized slot could be made in the side of the case, under the keyboard, to accomodate a bulkhead connector to which a 40-pin cable would attach nicely. I may, if I'm desperate enough, simply used the signals from the CPU, since that imposes no limitations on what/where my expansion circuit does its thing. I'd be happier if it lived in a defined location, though, and used buffered signals.

Clearly, there aren't enough signals available on the IIc to enable one to get much out of the machine by itself, and that's what I'm after.

I do have a couple of other questions.

(1) Is there a 'C' compiler that's been adapted to the IIc and that one can get from the 'net?

(2) I haven't messed with this box much , but I'd like to know whether it boots the normal Apple DOS or whether one has to use ProDos. I have both, but haven't seen either in nearly ten years. Hooking an sort of I/O circuitry to the IIc in a reasonable location would potentially make it useful.

It apparently has a BASIC ROM on board. Is this enough like Applesoft as in the ][+ that the Applesoft manual will be useful?

For simple tasks, particularly if it's only used once or twice, BASIC would be adequate for many things, paired with an adequate bit of I/O.

Thanks again!

Uli

Uli,

>> It would appear that there's no indication of where I/O is

>>mapped, though, or I don't see it.

As shown on the memory map, I/O for slots is $c100-$c7FF. The IIc has no slots though . The serialports are somehow mapped to slots 1 and 2, I think. There are two serial ports, the Disk port to interface through.

>I may have to root around some to find a block of, say 16

>consecutive locations into which to fit my I/O logic.

>Thanks for the pointer!

If this was in a IIe, I could help. The IIc I haven't worked with much. Applied Engineering made an extra RAM card for the IIc. It plugged in between the keyboard and the keyboard connector on the motherboard.

You may be able to grab some I/O locations here. $C000 and $C010 (I think) are keyboard Ascii data/strobe. I don't know if they are decoded on the keyboard or what, but it they were you could just decode some other locations for your use.

>Clearly, there aren't enough signals available on the IIc to enable

>one to get much out of the machine by itself, and that's what I'm
>after.

True, unless you use the disk I/O port or a serial port, which would need some extra circuitry to do anything useful.

>(1) Is there a 'C' compiler that's been adapted to the IIc and that
>one can get from the 'net?

I don't know, but I have a C compiler for the IIc that I am trying to sell.

>(2) I haven't messed with this box much , but I'd like to know

DOS 3.3 or Prodos will work. The latest version of Prodos will work. The main feature of Prodos is support for hard disks. There are no hard disks for the IIc.

>It apparently has a BASIC ROM on board. Is this enough like

It has AppleSoft. Most Likely "AppleSoft II". Your Applesoft manual should work great with it.

>For simple tasks, particularly if it's only used once or twice,

>BASIC would be adequate for many things, paired with an adequate bit
>of I/O.

Yep. You can read a particular memory location from BASIC with PEEK(location). You can also write to memory with POKE (location),value

aiiadict@hotmail.com

rich12345.tripod.com (check out the robot link)

Rich

Thanks for the information.

You say, there's no hard disk for the IIc ... hmmm ... I once built a hard disk adapter (before they were commercially available)for the Apple ][/][+, and, now that you suggest that the IIc may be architected more similarly to the ][/][+ than is obvious to the casual onlooker, I may have to take another run at it. It would be really simple to colocate a bridge controller together with a hard disk or two. It could even be used to drive a "standard" floppy disk drive. I'd not be anxious to get into adapting the RWTS code for the APPLE to a hard disk controller. How much is known about the code that runs the IIc?

Now, what's this about a C-compiler for the IIc? Have you got details? I've seen that there's one for one of the Atari thingies, but I don't know how widely adaptable it is. I'd be interested in one if it were easily portable and had separate but well-defined and documented libraries to support the host system.

Is there any place where schematics of the IIc are available? I've got plenty of 6502-based machines lying about doing little, and might get some amusement knowing more about this one, at least from the hardware standpoint. I really don't care much about the system, or any other Apple product, since I always objected to the way in which they (Apple) compromised system performance and reliability in order to make more money. OTOH, I do like to do in software what I'd otherwise have to wire up.

Please let me know whatever you can share about this otherwise rather uninteresting machine. With a little extra uncommitted I/O and a standard floppy, perhaps a hard disk, this one could be useful.

regards,

Uli

>I'd not be anxious to get into adapting the RWTS code for the APPLE
>to a hard disk controller. How much is known about the code that

>runs the IIc?

The Dos3.3 RWTS is easy to adapt. Prodos works with "block devices" without any drivers (block driver is built into Prodos).

Prodos uses 256 byte blocks. This is because each slot has 256 consecutive I/O locations (Cn00-CnFF) where n=slot. I don't have very much information besides this. There are also a few other bytes in the memory map that are used for slots, I'd have to look them up.

What do you mean by "how much is known about the code that runs a IIC?"? It has AppleSoft in ROM, a system monitor, possibly a Mini-assembler. The Apple II reference manual includes full schematics for the Apple II (not II+,IIe or IIc). There is a IIc reference that may have schematics. The Apple II reference manual also has source listings for the system monitor and the "autostart ROM".

The C compiler that I have for the IIc is "Aztec C". It is not ANSI C. I think that the system dependent libraries are seperate (disk access, joystick, serial, etc). I am not sure because I don't program in C. 6502 Assembly is my favorite.

With a schematic of the IIc you could probably wire directly into the System BUS and decode and use any I/O locations you'd like. If you don't use the Serial port that is mapped to "slot1" then you could use $C100-$C1FF for whatever you'd like. You might not even have to do any decoding if you can locate the DeviceSelect, I/OSelect pins for the "slot" that you end up using.

I have an extra Apple II reference manual if you are interested. The Apple II and the Apple IIc are almost %100 compatible. I think they took the II motherboard and stripped the slots, squeezed the chips in closer, and added serial/disk ports that are "mapped" to the $C100-$C7FF space.

aiiadict@hotmail.com

Rich

Hi, Rich

I've been unable, so far, to find the doc's I have for ProDos as well as the associated diskettes. I didn't get them with the IIc that, as I may have mentioned, was given to me as a token payment for a piece of PC hardware that the previous owner thought he wanted.

AFAIK, I have all the parts, i.e. the monitor, power supply brick, and the main box. The Monitor has a base into/under which the IIc seems to fit.

The notion of finding and "stealing" the slot decodes from the circuitry on the IIc board is improbable, since the decoding seems to be done in a gate array, and there's no reason to believe that Apple, in all their wisdom, would provide select signals for features not implemented in their design. I believe it would be just as easy to decode the appropriate address(es) myself with a PAL or whatever. In fact it may make sense to use a small CPLD to decode and buffer the proposed external I/O channel, since they're cheap and have sufficient drive current.

My goal, let's not forget, is to find a way to extract useful work from this otherwise not-too-useful system. I'm favoring an I/O channel port, likely containing a few addresses and a data bus, as well as rd*, wr*, irq*, wait* (the 65C02 readily supports that, unlike the NMOS part, which didn't wait on write operations) and I'm simply considering doing this as a more or less universal I/O channel in order to allow others to capitalize on the existence of the channel without limiting the purpose for which it's ultimately used. What makes this so tempting is that there's enough power on the external FDD connector to allow the device to power an external circuit, and there's enough potential, if the job's done neatly, and there is probably sufficient justification for such an effort based on the fact that there isn't an adapter for an external HDD and the like. There are undoubtedly some folks who'd use such a thing, even if they had to build it themselves.

Now, if I ultimately decide to build an extension of the CPU rather than a channel, then I'll put a 50-pin bulkhead connector through the side of the box at the right of the keyboard, near the bottom. If I build a channel adapter, it (the adapter) will probably reside inside and I'll build a bulkhead connector of either 40 or 50 pins in essentially the same place. How many pins will depend somewhat on whether I decide to include power, i.e. +12, +5, -12. Those are available on the external FD connector, though it would be more convenient to have them on the connector. We'll see ...

The idea would be to allow the device to drive a WD1002-05-series HDC. That's a bridge controller which came in several versions but which aren't made any longer. There are plenty of them around, though, and they're easy to program and handle MFM-modulated drives and, in at least one model "standard" 5-1/4" floppy drives as well. I personally like that because it has the potential of allowing one to transfer files between a PC or other machine and the IIc. It would, of course, require software.

What additonal information can you give me about that AZTEC 'C' version that you have? For what machine was it originally developed? How portable is it? Does it run, as-is on a IIc? How about a ][+? Have you any doc's for it with respect to the IIc? I have experience with Aztec's compiler, having used it under CP/M.

That, of course, gives rise to the question of what you want for the compiler you say you've been trying to sell. I routinely use 'C' compilers to lay out the logic in a task for a microcontroller, hence I use 'C' compilers for the 'HC11 and 'HC05/08 series from Motorola and for the 805x series (Intel, et. al.) It might be handy to have one for the 6502, though it would have to support both the NMOS and CMOS devices, and probably would have to support, as a minimum, the ROCKWELL CMOS devices, since I still have a number of them in stock and have MANY of them in the field, occasionally requiring support. I generally write in assembler for the 6502 as well as any other device I use, though the compiler gets me from start to a rough draft of the code I ultimately use. In some cases, where speed and resource utilization isn't critical, I just use what the compiler spits out.

Thanks for the kind offer of your extra Apple][ reference manual, but I did actually find mine, hence, don't kneed yours. I'm considering resurrecting my old ][+, not that I was ever a heavy user of the thing. I only have one drive for it, however, and I may have to snag one at the local thrift store.

It's been a long time since my last look at the Apple I/O map, but, IIRC, there was a 256-byte space mapped into each slot for device specific code (activated, methinks, by the "PR#n" command among others, and normally used to map the on-board EPROM, if there was one, into the common 1.75K-byte memory space common to all slots. Once that was done, the EPROM content could drive the board. Since I only need about 16 locations, I may just chew up a chunk of that common space, if it exists in a IIc in the same way as in the ][+, provided I can find one that was not used by any of the IIc's features. Would you have any specifics on that?

It may be a while before I'm ready to jump on this task, but I may actually get to it this year. My main interest is in making minimalist applications of various microcontrollers, though I do often use the 6502 in cases where I can buy a plurality of identical boards.

A fellow I once knew made quite a handsome lot of $$$ by using VIC-20's which once were very common in thrift stores, and applying them to control and monitoring tasks. Since they had a little memory and an on-board BASIC interpreter, he got pretty good at making them do what people had previously done with a PDP-11/03. I do the same sort of thing from time to time, though I don't run onto multiples of boards as widely available as the VIC-20 once was.

Please let me know what you can about the specific usage of the common page of I/O in the IIc, and about the compiler if you have such details available.

regards,

Uli

I would be interested in buying your Aztec C if it is for the Apple II and not just for a generic 6502.

Exegete AKA Roy Miller
Faith Orthodox Presbyterian Church
Apple ][ forever!

I know the keyboard data is kept at 49152...(sorry, I've always used BASIC, FPBASIC doesn't use hex at all) ._.,,,