6 Aug
2000
6 Aug
'00
11:51 p.m.
There's a question - since I can't get to the FAQs ATM can anyone tell me
which Mac monitor I can use with the ][GS? And the ][c+ for that
matter......
-----Original Message-----
From: Paul R. Santa-Maria [mailto:paulrsm@ameritech.net]
Sent: 06 August 2000 18:28
To: classiccmp(a)classiccmp.org
Subject: Re: Apple IIc+ boot disk for DOS3.3
sound chip,
> There are, of course, many other features in
the ROM; it's just a
matter of
> digging up the programming info. And (since
you have such a late
member of
> the ][ series) there are also features in
the hardware,
such as double-
> resolution text, low-res, and high-res
modes, that the
ROM was never
updated
to
handle.
How do you get at these modes? Are they in the IIgs, also?
Speaking of which, can you drive the IIgs graphics chip and whatever they're called, from Applesoft?
The double-resolution text mode is 80-column mode, and can be
turned on
with PR#3. This mode is supported by the ROM.
The double low-res (twice as wide, not half as wide!) and
double hi-res
modes are not supported by the ROM. You can write BASIC
routines to use
them, but it is much faster to use assembly language routines
called by
BASIC. These modes are also in the Apple IIe and IIc.
The IIgs has super-res modes with hardware color fill
available. I am not
a IIgs programmer (I use mine as a IIe) but there may be ROM
routines in
the toolbox to support those modes. The same may be true for the IIgs
sound chip. I have seen a BASIC program that used the sound
chip, but all
it did was POKE the data into memory.
No Apple II has real support for even the built-in speaker in the ROM,
except for the Programmer's Aid #1 option for Integer BASIC
which had tone
routines.
Paul R. Santa-Maria
Ann Arbor, Michigan USA
paulrsm(a)ameritech.net
7 Aug
7 Aug
1:13 a.m.
There's a question - since I can't get to the
FAQs ATM can anyone tell me
which Mac monitor I can use with the ][GS? And the ][c+ for that
Thats an easy one, none of the mac monitors work on the II series. A TV
monitor can be used, or a regular TV if you have a modulator. There was
also a Apple Color RGB monitor that worked specifically with the Apple IIgs
and I think the IIc/c+.
4:45 a.m.
There's a
question - since I can't get to the FAQs ATM can anyone tell me
which Mac monitor I can use with the ][GS? And the ][c+ for that
Thats an easy one, none of the mac monitors work on the II series. A TV
monitor can be used, or a regular TV if you have a modulator. There was
also a Apple Color RGB monitor that worked specifically with the Apple IIgs
and I think the IIc/c+. 
6:58 a.m.
New subject: Commodore 1084 (was: Re: Apple IIc+ boot disk for DOS3.3
On Mon, 7 Aug 2000, Cameron Kaiser wrote:
Naturally, I use a Commodore monitor with mine if an
Apple one isn't
available. The Commodore 1702 is the world's hardiest monitor, and the
1084 the most versatile.
I have a 1084 that I switch between an Amiga 1000 and either an Apple IIe
or a TI 99/4A, using the digital/composite switch...
8:04 a.m.
New subject: Computer collecting/preservation article in today's LA Times
9:02 a.m.
New subject: Apple IIc (not IIC+) details
While there seems to be a fair amount of information about the older apples,
i.e. ][, ][+, and the IIc+, I've been unable to find any menaingful
information on the web about the plain-old IIc. It has an external
connector to a floppy disk drive, but I've found no information about the
drive itself. The IIc+ has an external "intelligent" drive, and I'd like
to
know what that means, in this case, not to mention that I'd like to know
about the "intelligent" hard disk that attaches to the IIc+ via that same
connector, though perhaps not using the same protocol.
There's also little definitive information about the memory usage for I/O
and how (and how closely) they emulated the ][+ slot usage. They've
apparently memory mapped the keyboard, so I would also like to know where in
the memory map the keyboard lives.
I'm considering cutting a hole in the side of the box to accomodate some
sort of I/O channel. I understand that there was an expander available from
a third party, but have little information about that. The slot I'd make in
the box would accomodate a 40-pin, or perhaps 50-pin inline cable connector.
Since I'd prefer to make an internally buffered I/O channel as opposed,
simply, to bringing out the CPU's signals, it would be useful to have some
information.
Any suggestions?
Dick
----- Original Message -----
From: Charles P. Hobbs (SoCalTip) <transit(a)lerctr.org>
To: <classiccmp(a)classiccmp.org>
Sent: Monday, August 07, 2000 11:04 AM
Subject: Computer collecting/preservation article in today's LA Times
10:35 a.m.
New subject: Apple IIc (not IIC+) details
While there seems to be a fair amount of information
about the older apples,
i.e. ][, ][+, and the IIc+, I've been unable to find any menaingful
information on the web about the plain-old IIc. It has an external
connector to a floppy disk drive, but I've found no information about the
drive itself. The IIc+ has an external "intelligent" drive, and I'd like
to
know what that means, in this case, not to mention that I'd like to know
about the "intelligent" hard disk that attaches to the IIc+ via that same
connector, though perhaps not using the same protocol.
AFAIK, the IIc+ has the internal equivalent of a UniDisk 3.5, which was a
"normal" Apple 800K mechanism with a microprocessor-based daughterboard
added. It communicates with the IIc through a packet protocol, which is
called SmartPort. However, the actual disk controller hardware of the IIc+
is just the IWM chip, which is a slightly fancier single-chip version of
Woz's original disk controller.
The only "intelligent hard drive" that Apple made for hooking up to floppy
disk ports on their computers was the HD20. (Not the HD20-SC, which is SCSI.)
The HD20 is only supported on Macintoshes, and it's protocol is NOT the
same as SmartPort. I don't know any technical reason why it wouldn't be
possible to write a driver to use the HD20 on the IIc+, but I haven't heard
of anyone doing it.
There's also little definitive information about
the memory usage for I/O
and how (and how closely) they emulated the ][+ slot usage. They've
apparently memory mapped the keyboard, so I would also like to know where in
the memory map the keyboard lives.
AFAIK, the keyboard is encoded at $C000 and $C010, just like any other
Apple II. The shift and option keys might be wired to the extra button
inputs, just like the old "shift key mod" people did on earlier Apples.
I'm considering cutting a hole in the side of the
box to accomodate some
sort of I/O channel. I understand that there was an expander available from
a third party, but have little information about that. The slot I'd make in
the box would accomodate a 40-pin, or perhaps 50-pin inline cable connector.
Since I'd prefer to make an internally buffered I/O channel as opposed,
simply, to bringing out the CPU's signals, it would be useful to have some
information.
Any suggestions?
Well, my main suggestion would be that if you're trying to accomplish
something *practical*, you should just use a late-model laptop computer.
But if you're just doing this for fun, more power to you!
12:58 p.m.
New subject: Apple IIc (not IIC+) details
Please see embedded remarks below.
Dick
----- Original Message -----
From: Eric Smith <eric(a)brouhaha.com
To: <classiccmp(a)classiccmp.org
Sent: Monday, August 07, 2000 1:35 PM
Subject: Re: Apple IIc (not IIC+) details
IIc+
...
My question would be whether the IIc (not the
IIc+) can talk to an external
device by way of the channel used to talk to its external drive(s) in the
same way a IIc+ does it. This would presuppose that the data is not
manipulated in to its encoded format until it's at the peripheral, since
there are plural peripheral devices, not all the same. I've seen
discussions asserting that's the case, and others asserting not, so I'm no
better informed than previously.
One question, then, begging definitive answer is, "What protocol does the
IIc use when communicating via its external drive connector?" Judging from
what I got from the U of IOWA site, it has several supplies, four stepper
driver phases, probably controlled by software, and a couple of control
signals that are probably also controlled by software. If there were a
reasonable way to seize control of the individual bits that control these
babies, this thing becomes a potential powerhouse. That's particularly true
if there's some protocol in place that sends unmodulated data to the outside
world, say, in some external-intelligence-dependent format that could be
deciphered without having to unmodulate the Apple-style GCR code normally
found on their controllers. It seems as though there are enough signals to
do the job if one could just get control of them. That requires information
not commonly published on the web. If there's an easy way to get that info,
I'd like to do that.
> > There's also little definitive
information about the memory usage for
I/O
> AFAIK, the keyboard is encoded at $C000 and
$C010, just like any other
> Apple II. The shift and option keys might be wired to the extra button
> inputs, just like the old "shift key mod" people did on earlier Apples.
> > I'm considering cutting a hole in
the side of the box to accomodate some
> > sort of I/O channel. I understand that there was an expander available
from
> > Any suggestions?
> Well, my main suggestion would be that if
you're trying to accomplish
> something *practical*, you should just use a late-model laptop computer.
> But if you're just doing this for fun, more power to you!
Well, the fact is that "late-model"
laptops don't have much power available,
while the IIc, with it's "brick" connecting to the mains, does have that
potential. That way you don't have to have yet another power supply to
accomplish the "useful work" that's being so evasive here.
Yes, I've used the EPP built into most notebooks to generate control
signals, but there's no power tap on the typical notebook. What's more,
this one (the one I'm using now) only runs for about 40 minutes on batteries
if the NIC and modem are plugged in. (the PC-cards are power-hungry!) That
in itself rules out trying to extract work by means of the PC-card slots,
though I've considered it.
As I often do, I've allowed my alligator mouth to overload my hummingbird
other end so I can't easily produce what I said I would. Now, given that
there's power on the floppy port, I'd only need one bit of control, but I'd
rather have the whole thing at my disposal, given it's not being used for
anything helpful.
Is the necessary information around somewhere that you know of? Is is
sufficiently complete and detailed that I can rely on it to drive those
stepper phases and unscramble the data that may have to be led to believe
it's on its way to a drive? Is there an alternate path to the data lines
to/from the external drive so it can be induced to contain unencoded data?
If the info is available, it's not inconceivable that one could packetize
communication with the outside world via an encoded disk interface. It's
just a lot of work and if it leads nowhere, it's not worth the effort. If
the data's all there, however, it would make a highly interesting project.
> While there seems to be a fair amount of
information about the older
apples,
<snip connector,
though perhaps not using the same protocol.
AFAIK, the IIc+ has the internal equivalent of a UniDisk 3.5, which was a
"normal" Apple 800K mechanism with a microprocessor-based daughterboard
added. It communicates with the IIc through a packet protocol, which is
called SmartPort. However, the actual disk controller hardware of the is just the IWM chip, which is a slightly fancier
single-chip version of
Woz's original disk controller.
This is exactly what I meant in my original remark. There's information
everywhere about what the IIc doesn't have. This reference to the external
FDC connector is essentially the same as what's on the Iowa U. site, in that
it refers to the IIc+, and the IIe, but says little about the IIc. I'm not
interested in the IIc+ (note the PLUS), but rather in what's in the normal
IIc (no PLUS!). The IIc+ is apparently an entirely different machine,
having twice the processor speed, twice the memory, additional features,
etc.
I have a IIc which was given to me as a token payment for something
potentially useful (which the IIc apparently wasn't) and recently took on a
challenge to get useful work out of a post ][+ Apple product. This arose
out of my argument that one can get useful work out of the $5 computers
available at the thrift stores, etc.
Now, I've little cause to believe that useful work from an apple product is
achievable, since useful work is limited for purposes of this challenge to
things that happen as a direct result of the actions inside and propagating
thence outward from the Apple box not to be accomplished by some other
device. If it will turn on/turn off a relay, that's potentially useful, so
it qualifies. It has to do this under program control, however, so knowing
it's possible to do that isn't enough.
The only "intelligent hard drive" that Apple made for hooking up to floppy
...
<snip of anyone doing it.
Yes, I've got one of the HD20's lying about somewhere, though I've
taken the
drive out of the box, since the box is useful for packaging. The drive may
be of some use in a CP/M context some day.
> and how (and how closely) they emulated the ][+
slot usage. They've
> apparently memory mapped the keyboard, so I would also like to know
where in
> > the memory map the keyboard lives.
> a third party, but have little information about
that. The slot I'd
make in
> the box would accomodate a 40-pin, or perhaps
50-pin inline cable
connector.
> Since I'd prefer to make an internally
buffered I/O channel as opposed,
> simply, to bringing out the CPU's signals, it would be useful to have
some
> > information.
>
2:28 p.m.
New subject: Apple IIc (not IIC+) details
My question would be whether the IIc (not the IIc+)
can talk to an external
device by way of the channel used to talk to its external drive(s) in the
same way a IIc+ does it.
[...]
One question, then, begging definitive answer is,
"What protocol does the
IIc use when communicating via its external drive connector?" Judging from
what I got from the U of IOWA site, it has several supplies, four stepper
driver phases, probably controlled by software, and a couple of control
signals that are probably also controlled by software. If there were a
reasonable way to seize control of the individual bits that control these
babies, this thing becomes a potential powerhouse.
The //c disk controller is for all reasonable intents and purposes the same
as the Disk ][ controller used in the Apple ][ and ][+, simply with a
different connector pinout (D-subminature 19 pin instead of a 2x10 header).
It's reduced from seven chips to one, but functions the same.
If you can build some external device that you can control with an Apple ][+
and the Disk ][ controller, you'll be able to use it with the //c.
The Disk ][ controller schematics are in the DOS 3.2 and DOS 3.3 manuals.
That's particularly true
if there's some protocol in place that sends unmodulated data to the outside
world, say, in some external-intelligence-dependent format that could be
deciphered without having to unmodulate the Apple-style GCR code normally
found on their controllers. It seems as though there are enough signals to
do the job if one could just get control of them. That requires information
not commonly published on the web. If there's an easy way to get that info,
I'd like to do that.
If you want to use the actual read data and write data signals, the data
*must* be in GCR (or FM) form. That's all the disk controller is capable
of dealing with. Your external device may decode the GCR on a write and
convert it to something else; that's what the UniDisk 3.5 and the HD20
do. (Note that the UniDisk ends up re-encoding data in GCR, but at a
higher bit rate.)
If you can talk to your device using only the signals other than the
actual read and write data (e.g., the stepper phase signals and the
write protect input), you don't need to mess with GCR.
6:48 p.m.
New subject: Apple IIc (not IIC+) details
Please see embedded comments below.
Dick
----- Original Message -----
From: Eric Smith <eric(a)brouhaha.com
To: <classiccmp(a)classiccmp.org
Sent: Monday, August 07, 2000 5:28 PM
Subject: Re: Apple IIc (not IIC+) details
the
<snip the same
What? How does it generate FM? Is there a straightforward way to create FM
with the standard controller? FM is VERY easy to deal with, while GCR
requires one switch data rates, etc, all of which can be done, but it's an
unnecessary pain. How does it generate FM? is that a function it does
automatically or does it bit-bang it into a buffer and then ship it out ...
or what??? I was NOT aware the Apple-][ controller could put out FM. That
would have made it able to read/write TRS-80 diskettes, wouldn't it? Well .
. . maybe . . .
> My question would be whether the IIc (not the
IIc+) can talk to an
external
> device by way of the channel used to talk to its
external drive(s) in
the
same way a
IIc+ does it.
[...]
> One question, then, begging definitive answer is, "What protocol does
babies, this
thing becomes a potential powerhouse.
The file://c disk controller is for all reasonable intents and purposes as the Disk ][ controller used in the Apple ][ and
][+, simply with a
different connector pinout (D-subminature 19 pin instead of a 2x10
header).
It's reduced from seven chips to one, but
functions the same.
If you can build some external device that you can control with an
Apple ][+
and the Disk ][ controller, you'll be able to use
it with the file://c.
The Disk ][ controller schematics are in the DOS 3.2 and DOS 3.3 manuals.
> That's particularly true
> if there's some protocol in place that sends unmodulated data to the
outside
> world, say, in some
external-intelligence-dependent format that could be
> deciphered without having to unmodulate the Apple-style GCR code
normally
> found on their controllers. It seems as though
there are enough signals
to
> do the job if one could just get control of them.
That requires
information
> not commonly published on the web. If
there's an easy way to get that
info,
I'd like
to do that.
If you want to use the actual read data and write data signals, the data
*must* be in GCR (or FM) form.
That's all the
disk
controller is capable
of dealing with. Your external device may decode the
GCR on a write and
convert it to something else; that's what the UniDisk 3.5 and the HD20
do. (Note that the UniDisk ends up re-encoding data in GCR, but at a
higher bit rate.)
If you can talk to your device using only the signals other than the
actual read and write data (e.g., the stepper phase signals and the
write protect input), you don't need to mess with GCR.
I was afraid of that . . . it means I can't get away with anything simple .
. . of course I'm grateful you've cleared that up. It seems as though every
mention of the IIc in this context talked around this question rather than
dealing with it head-on as you 've done. Thanks.
The stepper phase signals are of interest because they can sink some
current, and particularly because the floppy port has the supplies on it as
well. Naturally the drive select (out) and write protect (in) signals ( I
haven't looked at this stuff in over a week, so I may have the signal count
wrong, but I think there were two out and two in, aside from data) and you
say this works precisely the same way the ][+ controller works? Since they
can run the same software the locations and bit definitions must be the
same. I'll have to contemplate that for a while. I seriously doubt the
current venture will require I use the data stream, but it would be
interesting to know how to use it.
Now, is the rest of the memory map pretty much the same as on the ][+, that
is, can one rely on finding the small 256-byte blocks associated with each
"slot"? That's way more than I'd need for a channel.
8 Aug
8 Aug
10:38 a.m.
New subject: Apple IIc (not IIC+) details
"Richard Erlacher" <richard(a)idcomm.com> wrote:
What? How does it generate FM? Is there a
straightforward way to create FM
with the standard controller? FM is VERY easy to deal with, while GCR
requires one switch data rates, etc, all of which can be done, but it's an
unnecessary pain. How does it generate FM? is that a function it does
automatically or does it bit-bang it into a buffer and then ship it out ...
or what??? I was NOT aware the Apple-][ controller could put out FM. That
would have made it able to read/write TRS-80 diskettes, wouldn't it? Well .
. . maybe . . .
It can do FM, but not IBM 3740 and equivalent formats. Woz's patent on
the controller in fact *only* describes FM; apparently he switched to
GCR later. In fact, the address fields on the disk are FM-encoded even
though the data sectors are GCR.
In the following discussion, not the careful distinction between channel
bits (the actual bits on the diskette), and user bits. FM and GCR are
channel codes, which specify the transformation from user bits to
channel bits during write operations, and back to user bits during read
operations. In the Apple disk controller, these transformations are
performed by software (typically the RWTS routines). However, the
hardware still imposes restrictions on what channel codes may be used.
In Apple terminology, eight channel bits are called a nibble, but since
that term is more commonly used to refer to four data bits (half a
byte), I'll instead use the term "octet". Note that while an octet is
eight channel bits, it does not inherently correspond to any specific
number of user data bits. Some octets on the disk do not correspond to
user data at all, but instead are used for address fields, data marks,
checksums, etc.
The basic idea of read channel of the Apple disk controller is that the
PROM state machine does clock recovery by acting as a digital PLL. The
original (13-sector) PROM could not reliably count more than one missing
pulse (i.e., a zero channel bit). The 16-sector PROM can reliably count
two missing pulses.
The only way the processor can tell that an octet has been read into the
shift register is that the MSB of the shift register is set. This means
that there are only 128 usable octet values. However, when combined
with the additional restriction of no more than one or two consecutive
zero channel bits (for 13 and 16 sector PROMs, respectively), this
leaves only 34 or 81 usable octet values.
For FM, then, you simply use data patterns for which the odd-numbered
bits of the octet (considering bit 0 to be the LSB) are all set. These
are effectively clock bits. The even numbered channel bits are used for
user data bits. This encoding takes advantage of only 16 of the usable
channel code octets, so it clearly is nowhere near optimal coding
efficiency. It results in an expansion of each user data byte into two
octets. This format is used for the address fields on the disk, but if
it were to be used for the data fields as well, it would only be
possible to fit ten 256-byte sectors per track.
Apple's 13 and 16 sector formats take advantage of the larger range of
possible channel code octets. 13-sector format uses 32 octet values for
representing 5 bits of user data, and the remaining 2 octets values for
address and data marks. 16-sector format uses 64 octet values for data,
2 for address and data marks, and leaves 15 unused.
The disk write process requires the software to gather groups of five or
six user data bits from a data buffer, look up the corresponding octet
in a table, and write that to the shift register. The read process
involves getting an octet from the shift register, looking up the
equivalent user data bits in a second table, and packing them into the
data buffer. The processes of converting user data bits to and from the
corresponding octet values are commonly referred to as "nibblizing" and
"denibblizing".
In the traditional RWTS routines, the nibblizing and denibblizing were
done as separate steps before and after the actual writing and reading.
This is one reason why a minimum of 2:1 sector interleave is required.
Starting with the Apple III, more clever code was developed that could
handle nibblizing and denibblizing for 16-sector format on-the-fly.
There is one other important part of how the Apple disk controller
works, which is the "self-sync" pattern written as a preamble before
sectors. The self-sync consists of sets of nine (13-sector format) or
ten (16-sector format) channel bits, of which the first eight bits are
ones, and the remaining bit(s) are zero. The self-sync pattern is
necessary because if the controller attempted to start a read at an
arbitrary point on the track, it wouldn't be able to determine where an
octet starts. However, when starting in a preamble, it is guaranteed
that no matter where reading starts, after five complete self-sync
patterns (16-bit format) the reading will be properly synchronized.
Of course, there's no way to guarantee that the read process starts in
a preamble. However, if it starts somewhere else, it will not find a
valid address mark until after a preamble, so synchronization will be
achieved.
The self-sync marks are generated by writing an all-ones (0xff) octet
to the shift register every 36 or 40 microseconds, rather than the normal
32 microseconds.
In terms of what you can do to "abuse" the floppy controller into talking
to devices other than floppy drives, you still have the limitation of
no more than 81 usable octet values. If you use a microcontroller and
shift register as your interface, you can easily support the Apple GCR
formats. But if you prefer, there's no reason why you can't simply stick
to FM. That will get you an effective user data transfer rate of
125 Kbits/second.
The stepper phase signals are of interest because they
can sink some
current,
No, they can't. They're TTL signals. The drive has ULN2803A drivers.
Now, is the rest of the memory map pretty much the
same as on the ][+, that
is, can one rely on finding the small 256-byte blocks associated with each
"slot"? That's way more than I'd need for a channel.
No, the "slot" memory is taken up by the IIc ROM.
11:31 a.m.
New subject: Apple IIc (not IIC+) details
It'll take a while for me to digest what you've said here. I looked at
the ][+ manual long enough to note that none of the bits used in the
interface go "straight through" which would have made life simple.
Consequently I'll probably build an I/O channel with power on the connector
and run it to something capable of latching/buffering bits in and out. That
will make the IIc capable of controller/monitoring nearly anything
electromechanical. Isn't there an 8-or-16-byte block anywhere in the IIc's
memory map that's not already used? This is what I've been trying to find,
among other things.
BTW, I caught the fact that the stepper phase signals are driven by a 9334,
which is a ttl addressable latch. I'm not even certain how it uses that
particular device, since it has several useful modes. The 16mA sink of the
9334 is quite significant as compared with most HCT-TTL workalikes will give
you, but it's not a relay driver. I was misled by the fact that someone
told me the ULN2803's were used to drive the stepper. I naturally assumed
that meant they were on the controller, since that's an 8-bit device and
there are only 4 phase drive signals to each drive. There's probably good
reason for that, however.
Dick
----- Original Message -----
From: Eric Smith <eric(a)brouhaha.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, August 08, 2000 1:38 PM
Subject: Re: Apple IIc (not IIC+) details
<snip lots of detailed info>
The 16 mA output from standard TTL is quite a bit as compared with the 6 ma
one gets from today's HCMOS, don't forget.
"Richard Erlacher"
<richard(a)idcomm.com> wrote:
> What? How does it generate FM? Is there a straightforward way to
create FM
> with the standard controller? FM is VERY easy to
deal with, while GCR
> requires one switch data rates, etc, all of which can be done, but it's
an
> unnecessary pain. How does it generate FM? is
that a function it does
> automatically or does it bit-bang it into a buffer and then ship it out
...
> or what??? I was NOT aware the Apple-][
controller could put out FM.
That
> would have made it able to read/write TRS-80
diskettes, wouldn't it?
Well .
. . maybe . .
.
It can do FM, but not IBM 3740 and equivalent formats. Woz's patent on
the controller in fact *only* describes FM; apparently he switched to
GCR later. In fact, the address fields on the disk are FM-encoded even
though the data sectors are GCR.
In the following discussion, not the careful distinction between channel The stepper
phase signals are of interest because they can sink some
current,
No, they can't. They're TTL signals. The drive has ULN2803A drivers.
> Now, is the rest of the memory map pretty much the same as on the ][+,
that
> is, can one rely on finding the small 256-byte
blocks associated with
each
"slot"? That's way more than I'd need for a channel.
No, the "slot" memory is taken up by the IIc ROM.
5:34 a.m.
New subject: Apple IIc I/O map
Hi, Eric!
I've gotten snippets of information regarding the IIc's I/O allocation
scheme. Does it support the constructs associated with the slots of
the ][+? I got out the ][+ doc's per your recommendation and looked at the
I/O allocation scheme, finding that each card was allocated 16 bytes of
memory map for local I/O. It also was allocated a page of memory for
device-unique code, ostensibly to initialize the device and condition the
system prior to enabling its on-board ROM if there was one. Is this same
memory allocated likewise in the IIc?
Which FDC bits would you recommend one use for parallel output? Having
looked at the ][+ FDC schematic, I find there are no directly controllable
output bits available, nor, in fact are there any directly accessible input
bits. Every otherwise conceivably available turns out to be attached to
something having other side-effects. This convinces me it would be simpler
to build an externally accessible channel, perhaps including power on its
own connector, or perhaps using the power available on the external FD
connector.
This has me leaning once again toward simply building in a channel similar
to what's used with the WD series bridge controllers. That's not because I
want to attach one of them, but rather because it's an easy interface
channel to use. It maps eight bytes under a single select and does so quite
simply. If one were to decode a card select, (12 bits of address, assuming
nothing about available decode signals for I/O and such, it would be easy
enough to time the write and read signals and buffer the 4 addresses that
remain. That would allow external decodeing of two 8-byte blocks,
sufficient for a PIA or some other general-purpose device, not to mention
discrete MSI components.
It's pretty simple to build a channel, since it doesn't require much logic,
and it's pretty simple to use it. What do you think? Since power is
available, there's no real reason to worry those same issues that make the
notebook less likely to provide a practical solution. I'd say the IIc and a
notebook provide pretty equivalent hardware solutions. Both require a
"brick" to operate for a longer period, though the notebook's is smaller,
(actually my Toshiba notebook didn't require one, but I gave that to my
elder son when he went away to college. The one I use now is a Winbook.)
and the size isn't an issue.
What do you think?
Dick
7 Aug
7 Aug
6:57 p.m.
New subject: Commodore 1084 (was: Re: Apple IIc+ boot disk for DOS3.3
On Mon, Aug 07, 2000 at 10:58:19AM -0500, Charles P. Hobbs (SoCalTip) wrote:
On Mon, 7 Aug 2000, Cameron Kaiser wrote:
My favorite use for a 1084:
http://www.decvax.org/myvax/cabletv.jpg
Makes a *GREAT* television when hooked to the composite-outs of a
Scientific Atlanta "Explorer 2000" digital cable box.
Bill
--
+-------------------\ /-----------------+
| Bill Bradford | www.sunhelp.org |
| mrbill(a)mrbill.net | www.decvax.org |
| Austin, Texas USA | www.pdp11.org |
+-------------------/ \-----------------+
Naturally, I use a Commodore monitor with mine if
an Apple one isn't
available. The Commodore 1702 is the world's hardiest monitor, and the
1084 the most versatile.
I have a 1084 that I switch between an Amiga 1000 and
either an Apple IIe
or a TI 99/4A, using the digital/composite switch... 
8 Aug
8 Aug
5:03 a.m.
New subject: Commodore 1084 (was: Re: Apple IIc+ boot disk for DOS3.3
At 10:57 PM 8/7/00 -0500, Bill Bradford wrote:
My favorite use for a 1084:
http://www.decvax.org/myvax/cabletv.jpg
Makes a *GREAT* television when hooked to the composite-outs of a
Scientific Atlanta "Explorer 2000" digital cable box.
I think I've exhausted my supply of 1084 for this reason.
Eventually, they've zapped in one way or another and I haven't
the skill to fix them. I'm still using a Sony KV-1311CR
for a television, though, which was also a somewhat popular
Amiga analog RGB monitor in its time. I drive it with a
Roctec P-i-P tuner, which can select between TV and three
inputs. I also have a Zenith analog monitor that serves
as a composite display, although I don't know which computer
it came from.
- John
7 Aug
7 Aug
8:33 a.m.
Thats an easy
one, none of the mac monitors work on the II series. A
TV monitor can be used, or a regular TV if you have a modulator.
There was also a Apple Color RGB monitor that worked specifically
with the Apple IIgs and I think the IIc/c+.
Naturally, I use a Commodore monitor with mine if an Apple one isn't
available. The Commodore 1702 is the world's hardiest monitor, and the
1084 the most versatile.
9:23 a.m.
New subject: Commodore monitors (was: Re: Apple IIc+ boot disk for DOS3.3
On Mon, 7 Aug 2000, Lawrence Walker wrote:
Why do you consider the 1084 the most versatile ? I
had
thought they could only be used on an Amiga.
No, they have composite input and can accept PC graphics
(the one that uses 9-pins...CGA definitely, EGA as well???)
Definitely not VGA, though, that used 15 pins and a different
sync rate that the 1084 cannot handle.
1:24 p.m.
New subject: Commodore monitors (was: Re: Apple IIc+ boot disk for DOS3.3
On Mon, 7 Aug 2000 13:23:17 -0500 (CDT), Charles P. Hobbs
(SoCalTip) wrote:
On Mon, 7 Aug 2000, Lawrence Walker wrote:
CGA definitely, which is digital RGB. They are also great
monitors for the Color Computer 3, which uses analog RGB.
This is also used on the Apple IIGS. They are also popular
with video gamers. They always bring a good price on eBay.
Louis
Why do you consider the 1084 the most versatile
? I had
thought they could only be used on an Amiga.
No, they have composite input and can accept PC graphics
(the one that uses 9-pins...CGA definitely, EGA as well???)
Definitely not VGA, though, that used 15 pins and a different
sync rate that the 1084 cannot handle.
9:48 a.m.
New subject: Commodore monitors (was Apple IIc+ boot disk for DOS3.3)
You gotta love those Commodore monitors. I have 2
1702s , 2
different model 1802s and a 2002. Unfortunately no 1084 or more
desireably a 1084S. I use mine for most of my different home
system needs and with a VCR they make a nice TV.
That's exactly what my buddy used his spare 1702 for; when it wasn't
connected to his SX-64, he watched TV on it. :-)
My spare 1702 is usually connected to the Tomy Tutor. I have another 1702
plugged into a 64, a 1902 plugged into two 128s (one into the RGB input
and one into the composite), and a 1084S.
Why do you consider the 1084 the most versatile ? I
had
thought they could only be used on an Amiga.
No, they take composite as well and a crapload of video modes. My only
complaint with the 1084 is that the controls are very inconveniently placed;
if you switch video modes a lot like I do with my 1902 and the two 128s,
the front control panel of the 1902 is much nicer rather then screwing
around with the settings in the back.
My 2002 has the Video-Chroma-Audio RCA jacks and
9pin RGB inputs. It also has a digital Pos-Neg and analogue
switch. What was the dig.-neg. position used on ?
Dunno -- the 1902s have that also.
The only Commodore monitor I dislike is the 1802. It came two flavours: the
black variety decked out in 264/Plus/4 style (a.k.a. the CM-141 or the 1703)
and the white variety that also does monochrome RGBI (simply by hooking up
the RGBI luminance pin into the composite luma). I had the CM-141 and it
failed within a few months; I've heard similar complaints about it when
Commodore rebadged it as the 1802, and then when they introduced the white
model. You must be lucky to have yours still working. :-P
Just to be complete, there's a 1402 green-screen which was intended for the
Commodore PC clones, I believe, and the 1701, which resembles a 1702 and is
also a straightforward composite monitor. I've also heard of a 1202, and of
course, there's the famous 1080 and 1941 monitors as well.
--
----------------------------- personal page: http://www.armory.com/~spectre/ --
Cameron Kaiser, Point Loma Nazarene University * ckaiser(a)stockholm.ptloma.edu
-- Since we're all here, we must not be all there. -- Bob "Mountain" Beck
-----
7:03 p.m.
New subject: Commodore monitors, was Re: Apple IIc+ boot disk for DOS3.3
Hello Lawrence
On 07-Aug-00, you wrote:
You gotta love those Commodore monitors. I have 2 1702s , 2
different model 1802s and a 2002. Unfortunately no 1084 or more
desireably a 1084S. I use mine for most of my different home
system needs and with a VCR they make a nice TV.
Why do you consider the 1084 the most versatile ? I had
thought they could only be used on an Amiga.
My 2002 has the Video-Chroma-Audio RCA jacks and
9pin RGB inputs. It also has a digital Pos-Neg and analogue
switch. What was the dig.-neg. position used on ?
IBM CGA cards liked to use positive going sync rather than negative.
Also fyi, the Commodore 1702 monitor was built by JVC as an HR12U. The 1084
was built by several contractors, including Toshiba, and Phillips/Magnavox.
The analog/digital RGB inputs were nice, but since the scan rate is limited
to 15 kHz, I see little value in them except for Amigas, or as a straight
composite video monitor.
Best thing to find would be a nultisync monitor that went from a5 kHz on up
to 35 or 40 kHz, RGB analog.
Regards
--
Gary Hildebrand
Box 6184
St. Joseph, MO 64506-0184
816-662-2612
or
ghldbrd(a)ccp.com
Thats an
easy one, none of the mac monitors work on the II series. A
TV monitor can be used, or a regular TV if you have a modulator.
There was also a Apple Color RGB monitor that worked specifically
with the Apple IIgs and I think the IIc/c+.
Naturally, I use a Commodore monitor with mine if an Apple one isn't
available. The Commodore 1702 is the world's hardiest monitor, and the
1084 the most versatile.
8723
days inactive
8724
days old
19 comments
11 participants
participants (11)
-
agraham＠ccat.co.uk -
eric＠brouhaha.com -
ghldbrd＠ccp.com -
jfoust＠threedee.com -
lgwalker＠look.ca -
louiss＠gate.net -
mikeford＠socal.rr.com -
mrbill＠mrbill.net -
richard＠idcomm.com -
spectre＠stockholm.ptloma.edu -
transit＠lerctr.org