What hardware is missing from the Apple II?

[cb meeks]

I just recently built a crude serial card for the Apple IIe. It uses the 65C51 and when I say crude, I mean it's just a prototype. Why build a serial card when we have the SSC? Well, I wanted to learn how to program the 65C51 directly and I had some Apple II protoboards. :-D

Also, I built a Mockingboard clone a few years ago on a breadboard.

So, I'm curious, if you could see a new piece of hardware released for the Apple II line of computers, what would it be and why?

[David Schmidt]

On 1/3/2017 3:58 PM, cb meeks wrote:
> I just recently built a crude serial card for the Apple IIe. It uses
> the 65C51 and when I say crude, I mean it's just a prototype. Why
> build a serial card when we have the SSC?

Because SSCs are either easy to find or cheap (they are typically one or
the other) but not both.

> Well, I wanted to learn
> how to program the 65C51 directly and I had some Apple II
> protoboards. :-D

Good a reason as any.

> Also, I built a Mockingboard clone a few years ago on a breadboard.
>
> So, I'm curious, if you could see a new piece of hardware released
> for the Apple II line of computers, what would it be and why?

A cheap serial board that had a female DE-9 on it so you didn't have to
have so many adapters between an Apple II and a host computer - the
USB-RS232 dongle could just plug right into the board and run a USB
cable back to the host. As long as ADTPro could detect it and the
function was close enough to SSC behaviors, it could be a drop-in
replacement.

[TheJ]

I would think that a SPI and I2C interface board could be very cool !
There are TONS of SPI and I2C devices and all it would take is an interface
card to add those to the Apple 2.


While I'm thinking of SPI... If other Apple2 add-on cards had a SPI
interface, they could all be daisy chained via the SPI bus and have a VASTLY
faster way to talk to each other rather than the IEEE-488 bus. Fast parallel
bus anyone !?! Of course that would require several boards to add SPI and
people to actually buy them.


A Math coprocessor could be quite cool!
Here's one that retails (single units) for $20.
The uM-FPU V3.1 by MicroMega Corp.
It has SPI and I2C interfaces.
If anyone actually makes a SPI/I2C interface card, please just add a socket
for this chip! Seriously. If it can fit on the same card, why not! Our 2e's
and 2gs's are typically full of cards already. The more functions per card
the better.

FPU cards for the Apple 2 are super rare (and expensive!). With this, we
could have a competent FPU on the cheap! Also, since GS/OS development is
happening, some serious acceleration/parallelization can happen there too.
This chip does 32bit Float AND 32bit Integer operations.
http://micromegacorp.com/umfpu-v3.html


My 2 cents
J

[Michael J. Mahon]

I've used a couple of FP accelerator boards in my Apple //e, and have
found them to be of marginal utility.

One required that it be able to pause the 6502/65C02 by pulling on the
RDY line until an operation was complete, which is incompatible with the
Zip Chip. Since the 8MHz Zip Chip speeds most things up by about 5x,
and the FPU only speeds up floating point (and really only trig
functions), I'd choose the Zip Chip over the FPU any day. ;-)

The other was quite fast (68000 family FP coprocessor), and could be
helpful on a IIgs, where the alternative is SANE in software. But for
an 8-bit machine, all the flogging to load operands into it and retrieve
the results makes for marginal speedup on adds and subtracts, and not
much more on multiplies and divides. (I wrote patches to Applesoft to
use the FPU instead of software FP.)

In general, the problem is that lightning fast FP computation on the
chip doesn't translate into fast FP for Applesoft, or much else, for
that matter, because all the time is spent loading and unloading the FPU
using 6502 code. The IIgs's 16-bit loads and stores help, but the
underlying problem is the same.

If 32-bit FP is what you want, great. But Applesoft is based on 32-bit
mantissas, and 40-bit FP numbers, so to be compatible, it's necessary to
use double or extended precision on the FPU, with even more data to flog.


--

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page: http://michaeljmahon.com

"The wastebasket is our most important design
tool--and it's seriously underused."

[Walter Miraglia]

There is an i2c interface using a 6522 chip for the BBC. With code:


http://stardot.org.uk/forums/viewtopic.php?f=3&t=10966

Food for thought. They also do easy to use sd card interfaces.

Cheers. Hope this is helpful.

[TheJ]

Yes, the data bus would be a big bottleneck.
Someone recently posted about a board they made using a Transputer chip. It
radically sped up mandelbrots on the 2GS but always took 60 seconds to
display b/c of the data transfer. The Transputer had it calculated much
faster.

In that case, the entire program would reside on the Transputer so the 6502
did not have to manage every aspect of the calculation.
The FPU chip would not work like the Transputer as the 6502 would have to
manage the FPU for every action.

Instead, an ARM M4 (which has an FPU) would be a better idea as it has a
32bit CPU, some memory and the FPU. It would do all the "accelerated" tasks.
It would have to have those tasks written specifically for the ARM and
residing on the ARM chip (Like an ampersand command to accelerate BASIC).
The 6502 would then "call" those tasks and supply the data. That would
reduce the data that would move across the bus. Although that would vary
greatly according to the task at hand.

The M4 would also be a lot cheaper :-)

At this point, one would have to ask themselves, "Why am I coding an ARM
instead of my Apple 2?"
"Why not just use an ARM board?"

I would think it would be for the entire ecosystem of available add-on
hardware and software including GS/OS.

It may not be super practical, but it would make the Apple2e/gs as fast as
possible!
And besides, do we really use our Apple2's out of practicality?

Yet another 2 cents
(I think I'm almost out of change ;-)
J

[cb meeks]

Those are some excellent ideas. I like the FPU idea but I admit, I'm not sure how useful it would be.

At one point I entertained the idea of creating a soft-blitter using a micro controller. Something that would jump in at the right phase of the cpu cycle, grab some RAM and do lots of stuff with it like software sprites, color shifting, etc. Then, plop the results back into RAM during the next cycle or two. Depending on how much RAM it had to pull.

I also entertained the idea of another "arcade" board that had a few things that were nice to have. Like emulated SID chip, digital joypad support (for NES controller), real-time clock, a VIA, etc. Something like a Swiss Army knife of II cards.

There are a lot of advanced cards out there that do one or two things really well like the CFFA. But they are expensive. Something like the arcade board might be nice to have.

[Steve Nickolas]

On Wed, 4 Jan 2017, cb meeks wrote:

> I also entertained the idea of another "arcade" board that had a few
> things that were nice to have. Like emulated SID chip, digital joypad
> support (for NES controller), real-time clock, a VIA, etc. Something
> like a Swiss Army knife of II cards.

inb4 a card with a VIC-II and a SID, for making C64 ports relatively
trivial. XD?

-uso.

[David Schmidt]

Well, yeah - but then you essentially _have_ a C64.

[cb meeks]

I own several C64's and A2's. I don't really have an interest in making one like the other. :-D

But, an A2 with a SID chip would be pretty cool.

My Swiss Army card for the A2 would have:

SID x 2
Real time clock
VIA
NES controller support
Random number generator

Other ideas:
SPI support
EEPROM (recording high scores, settings, etc)

[D Finnigan]

cb meeks wrote:
>
> So, I'm curious, if you could see a new piece of hardware released for the
> Apple II line of computers, what would it be and why?
>

- Wi-fi card
- 3.5" disk controller
- USB printer interface
- 16-bit upgrade for the 6502 (65802?)
- video card that allows a bigger text screen

This video card should allow more than 80x24 (like the Terminal in OS X
where you can resize the window), and should have its own scroll back
buffer. Would also be neat to see an enhanced video card for the IIgs that
allows larger screen resolutions beyond 640x200 and whatever else the IIgs
does. With the source for GS/OS available someone could update QuickDraw or
whatever else is necessary to support it.

I would also like to see a card that can act as a Format Converter. It will
accept USB flash drives and other media and can seamlessly move files in and
out of disk images, ShrinkIt archives, and other disk and file formats. The
advantage with this is that it can all be done while sitting in front of the
Apple II. Combine this with a networking card to upload/download files and
things could be really cool.

--
]DF$
The Marina IP stack for Apple II--
http://marina.a2hq.com/

[TheJ]

Maybe an ARM M4 board would be a better idea than I thought.
It should be able to do almost everything listed above. The SIDs would have
to be emulated (not sure if it could do 2 at once)

J

[John Dallman]

In article <YeydnaKeRO3lsPHF...@giganews.com>,

mjm...@aol.com (Michael J. Mahon) wrote:

> I've used a couple of FP accelerator boards in my Apple //e, and
> have found them to be of marginal utility.

> ...

> In general, the problem is that lightning fast FP computation on
> the chip doesn't translate into fast FP for Applesoft, or much
> else, for that matter, because all the time is spent loading and
> unloading the FPU using 6502 code. The IIgs's 16-bit loads and
> stores help, but the underlying problem is the same.
>
> If 32-bit FP is what you want, great. But Applesoft is based on
> 32-bit mantissas, and 40-bit FP numbers, so to be compatible, it's
> necessary to use double or extended precision on the FPU, with even
> more data to flog.

Robocom, who did the BitStik CAD system, had a prototype FPU card in 1983,
but hit the same problems. There was no commercial FPU that handled
five-byte floats, and load/store ate up all the saved time. The 3.58MHz
accelerator cards of the period, in contrast, worked excellently.

If anyone ever finds or builds an FPU chip that does Applesoft format, it
will cross over into Acorn/BBC micro fandom. The floating point format is
identical.

John

[David Schmenk]

I think new hardware should either accelerate existing applications without requiring any modifications (SD storage, CPU accelerators, etc) or add all new functionality that could be used by hacker types. With that in mind, I would like to see a card that leverages the Arduino infrastructure, including shields.

A few of us have played with interfacing Arduino's to Apple IIs, mostly through the game port or serial interfaces. Since the Atmel chips have ADCs, DACs(PWM), SPI, UART, and i2c interface already built in, its easy to leverage them. Having a high performance interface between the 6502 and Atmel CPU would be nice, i.e. a parallel interface vs a serial interface. But that chews up a lot of GPIO pins so choosing something like the ATmega 2560 with lots of GPIO to spare would be appropriate.

When interfacing to ARM chips that are designed for cell phones and such, it seems that most of the I/O is handled serially instead of in parallel. That is why I went with the UART interface for Apple2Pi. Not so good for high bandwidth I/O, but sufficient for mouse and keyboard (and a little disk I/O).

[Michael J. Mahon]

cb meeks <cbm...@gmail.com> wrote:
> I own several C64's and A2's. I don't really have an interest in making
> one like the other. :-D
>
> But, an A2 with a SID chip would be pretty cool.
>
> My Swiss Army card for the A2 would have:
>
> SID x 2
> Real time clock
> VIA
> NES controller support
> Random number generator

Unless you're into serious cryptography, excellent pseudorandom number
generators are available (in fact, I posted a very good, very fast one
awhile back). Hardware random number generators are not necessary for
much, and have their own drawbacks (unrepeatability, for example).

> Other ideas:
> SPI support
> EEPROM (recording high scores, settings, etc)

Ummm, isn't that what disk's for? ;-)

Have you noticed that the more functions you put on a card the less likely
that anyone will actually need them all?
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

[cb meeks]

>
> > Other ideas:
> > SPI support
> > EEPROM (recording high scores, settings, etc)
>
> Ummm, isn't that what disk's for? ;-)
>

Well, I was mostly just brainstorming. EEPROM could be useful for storing the card's settings and such.

> Have you noticed that the more functions you put on a card the less likely
> that anyone will actually need them all?

Oh yeah. Which is why there aren't many multi-purpose cards built like that. With that many different sorts of functions.

[STYNX]

The Transputer came in 3 "flavors":
T2xx: 16bit integer with 2k-4k on chip memory (1985)
T4xx: 32bit integer with 2k-4k on chip memory (1985)
T80x: 32bit integer and 64bit float with 4k on chip memory (1987)

All Transputer can access several megabytes of external memory (optional). The design of the Transputer was geared towards massive multiprocessing. This means a Transputer has 2-4 links on each chip to communicate with other Transputers. A typical T4xx/T80x has about 20-30 Mips and the T80x has additionally about 3-4 Mflops. you can create clusters of tens to hundreds of Transputers that scale nearly linear. The command set is very small (less than 20 instructions for a T4xx 32bit chip).
The best thing about the transputer architecture is, that its a design from the 80s. the last updates came around 1993.

Axel Muhr has implemented a simple Apple II interface: http://www.geekdot.com/t2a2-for-everyone/
It can take 2 Transputer Modules (TRAM) and off er up to 60Mips (2x 30mhz T80x/T4xx) of processing power ;-)

--------

A $10 Cortex M3 dev-board with real 5V I/O (not only tolerant) and on chip CPLD:
http://www.cypress.com/documentation/development-kitsboards/cy8ckit-059-psoc-5lp-prototyping-kit-onboard-programmer-and

The PSOC 5LP is a really nice chip that allows you to access up to 64k of on chip ram (DMA between CPLD and M3 core possible) and 256k on chip flash memory. The core frequency is 80mhz max. You can implement logic in the PSOC CPLD that is about as complex as 100-120 Xilinx macrocells of the XC9500 series.

-Jonas

[Zellyn]

On Tuesday, January 3, 2017 at 3:58:18 PM UTC-5, cb meeks wrote:
> So, I'm curious, if you could see a new piece of hardware released for the Apple II line of computers, what would it be and why?

What I'd like is a board with a Raspberry Pi 3 on for general computing, and then some kind of fast-enough-to-bitbang-the-address-and-data-buses hardware (a small fgpa with 256 or 512 bytes of buffer?). That way you could emulate anything at all. The RaspPi would give you generic computation and connectivity, and the Apple only sees cards as address and data bus input/outputs, so you could run a program that acts as a serial card, or a disk, or anything at all. It would be fun to experiment with entirely new card types just by changing software.

Zellyn

[mspa...@gemsi.com]

> - video card that allows a bigger text screen.

So an Ultraterm card with a HDMI or DVI output? That might actually be doable. A IIe version would plug into the aux slot, and could even have extra RAMWorks style memory. Would a slot 3 version work on the GS?

A wifi card could leverage the existing ethernet software.

A 3.5" disk controller would be nice as they are getting scarce, but the existing compact flash cards cover that.

The SPI or I2C card would be nice for IO work. But if you had a USB card you could power up a Labjack pretty well. The software on the Apple II end would be the harder part. Maybe reuse some code from the Applied Engineering ADC and DAC cards? I think they just read and wrote bytes C0XX space to transfer data.

Interesting thoughts.

[ultramagnus_tcv]

On 2017-01-03 21:15:03 +0000, David Schmidt said:

> A cheap serial board that had a female DE-9 on it so you didn't have to
> have so many adapters between an Apple II and a host computer - the
> USB-RS232 dongle could just plug right into the board and run a USB
> cable back to the host. As long as ADTPro could detect it and the
> function was close enough to SSC behaviors, it could be a drop-in
> replacement.

Seconded.

[ultramagnus_tcv]

It's the reverse-Mimic.

[gid...@sasktel.net]

Same thing as having a PCTransporter card - you essentially have a PC

or a CPM softcard, you essentially have a CPM computer

or a 6809 Mill card, you essentially have a Mac Plus.


That's the fun thing about an Apple II. We can emulate almost any computer through the ports with hardware.

Maybe even as much fun as using software emulators to emulate different computers, if that's possible? So much fun to be had. When will the fun ever end?

[D Finnigan]

mspangler wrote:
>> - video card that allows a bigger text screen.
>
> So an Ultraterm card with a HDMI or DVI output? That might actually be
> doable. A IIe version would plug into the aux slot, and could even have
> extra RAMWorks style memory.

Yeah, that's what I had in mind. But you could add even more features, like
simultaneous side-by-side display of pages 1 and page 2, or a screen
capture, so you could pull up a text screen for reference.

This could make developing on the Apple II more productive.

>
> A wifi card could leverage the existing ethernet software.

Yes!

>
> A 3.5" disk controller would be nice as they are getting scarce, but the
> existing compact flash cards cover that.

I mentioned that because I have a UniDisk drive and can't plug it in to
anything except for my IIgs (where it is awful). My IIc is the ROM 255 so...
:-(

[D Finnigan]

gids.rs wrote:
>
> That's the fun thing about an Apple II. We can emulate almost any
> computer
> through the ports with hardware.
>
> Maybe even as much fun as using software emulators to emulate different
> computers, if that's possible? So much fun to be had. When will the fun
> ever end?
>

The fun will end when all of our 5.25" floppy disks disintegrate, which,
according to some people, could be as soon as next year.

[Steve Nickolas]

True. Or more like a P500 - same hardware, different memory map.

-uso.

[Steve Nickolas]

That's why we've been trying to port everything over to ProDOS, which
doesn't require 5.25" floppies. xD

-uso.

[Michael J. Mahon]

Surely you're kidding.

Properly stored 5.25" diskettes will be in fine condition after all of us
are gone.

In the early days, there were a few off-brand distributors of substandard
floppies, but they were, and remain, the exception to the rule.

The big problems for floppies are storage near magnetic fields (motors,
transformers, etc.) and storage in moist (mold-inducing) conditions.

[D Finnigan]

Michael J. Mahon wrote:
> D Finnigan <dog...@macgui.com> wrote:
>> gids.rs wrote:
>>>
>>> That's the fun thing about an Apple II. We can emulate almost any
>>> computer
>>> through the ports with hardware.
>>>
>>> Maybe even as much fun as using software emulators to emulate different
>>> computers, if that's possible? So much fun to be had. When will the
>>> fun
>>> ever end?
>>>
>>
>> The fun will end when all of our 5.25" floppy disks disintegrate, which,
>> according to some people, could be as soon as next year.
>>
>>
>
> Surely you're kidding.
>
> Properly stored 5.25" diskettes will be in fine condition after all of us
> are gone.
>

Tell that to Jason Scott & Co:
http://ascii.textfiles.com/archives/3191

[Michael J. Mahon]

I certainly support Jason, and I agree that backups are good, and shared
archival backups are even better. I also agree that people need motivation
to backup their floppies.

What I have no evidence to support is that there is some impending "cliff"
over which all floppy data is about to plunge.

I have a large sample of floppies, many quite old, and I have backups for
many of them. But I have never encountered a floppy that lost its data
without being mistreated or mishandled in some way. In other words, all my
backups have proven to be insurance against mistakes, not age.

There have been cases of magnetic media failure, such as 1960s NASA tapes
whose adhesive failed, allowing the magnetic coating to flake off the tape
base. I have not seen any cases like this for 1980s floppies handled and
stored properly. Apparently adhesive failure was a solved problem by the
1980s.

Demagnetization as a result of recording densities too high for the media
coercivity is a potential problem, but Apple II 5.25" diskettes are
recorded at low density, and room temperature thermal demagnetization does
not appear to be a problem after 37 years. If it were going to be a
problem soon, the leading edge of failures would be quite significant and
easily observed.

Anecdotal evidence of data loss must be traced to its root cause, and in my
experience the causes I have seen were primarily mishandling or poor
storage. Even in many of these cases the data is recoverable through mostly
mechanical means--jacket loosening, media cleaning, etc. Creases are hard
problems, but even then, a momentary increase in pressure pad pressure (a
finger ;-) can be helpful.

So I say, be careful, back up important data, and capture images of disks,
but don't panic--there is no "cliff".

[D Finnigan]

Michael J. Mahon wrote:
>
> Anecdotal evidence of data loss must be traced to its root cause, and in
> my
> experience the causes I have seen were primarily mishandling or poor
> storage. Even in many of these cases the data is recoverable through
> mostly
> mechanical means--jacket loosening, media cleaning, etc. Creases are hard
> problems, but even then, a momentary increase in pressure pad pressure (a
> finger ;-) can be helpful.
>

I have had the same experience as you. I only started with the Apple II in
2004 so all my disks came from other people. I now have 2 groups of disks
that I keep segregated: clean disks and dirty disks. It doesn't refer to
their digital content, but rather how they were formerly stored.

The clean disks give me no problems. They're fine.

The dirty disks get "crud" on the disk drive head which leads to I/O errors
and worse -- scratching the disk surface (typically track 0) causing
permanent data loss. These dirty disks are a pain in the neck because I
constantly have to open the drive and clean the head when using them.

But I've dutifully backed them all up -- clean and dirty -- with ADTPro and
uploaded them to Mac GUI Vault... :-)

[mrbrad]

Well...I have a heavily modified Apple //e called a Dapple //e. Has the
keyboard blanked out with dials that are concentric and 3" tall. Heavily
modified eproms on the accelerator and other stuff with spagetti wire
inside with dapple stickers over eproms. Have all the manuals.

Was used to run dapple black and white imaging for Electron Microscopes.

sits there when I turn it on ..waiting for the hardware (heh) :)

Tried to get the local univ to let me hitch it up to their electron
microscope..they said NO NO NO...seemed kinda upset ..go figure....

should probably donate to the apple Museum....would be hard to tell if
this works w/o the 40x40 room with the electron microscope in it

sorry in weird mood it is like 10 below zero and was outside....effected
my mind

brad
former sysop lost gonzo bbs

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[STYNX]

On Saturday, January 7, 2017 at 1:47:25 PM UTC+1, mr. brad wrote:
> Well...I have a heavily modified Apple //e called a Dapple //e.

> ...
> Have all the manuals.

Please scan or photograph the manuals and put them online (Apple ii documentation project and/or archive.org).
It would be sad if this information gets lost as well.

-Jonas

[mrbrad]

Yeah...anyone on here in Southern Minnesota....shoot me an email.

(I need to make a frigging vintage computer club just to have the
manpower and get me motivated...yeah....I'm probably in the top
10 exotic Apple II hoard list...large wies..I say that not to brag..but
just have no time..and not a clue....too much ..way ...way too much)

I keep planning on it..but got sidetracked with this whole
BTC Mining etc etc in 2013 till still :)

Well anyone in this area you can email me. At my toss away address.
lgon...@yahoo.com.

Not like you are gonna get thru the room mate (cop) and 2 large labs and
the frigging Inet Security Cameras I have here for his stuff and his big
ass gun safe. No real danger of it getting carted off in a truck. :)

Well at least (almost all) is in Cabinets/shelves. No rot issues.

[STYNX]

On Sunday, January 8, 2017 at 11:35:28 AM UTC+1, mr. brad wrote:
> Well anyone in this area you can email me. At my toss away address.

I would like to help, but im from Germany :-/

-Jonas

[mmphosis]

a USB card

* keyboards - USB keyboard interface

The existing keyboard plugs into a 16 pin DIN on the USB card and becomes
one of the USB keyboards on the bus, the USB keyboards on the bus all work,
keys including RESET and shift are remappable via software and maybe NVRAM,
the USB card plugs into the 16 pin keyboard DIN on the motherboard. Keys,
like say shift, option and system or any other keys for that matter, can be
mapped to pushbuttons on the GAME port.

because my old keyboards are mostly / completely broken.

* mice / joysticks - USB mouse and joystick interface

The USB mice and joysticks map to the 16 pin Game IO DIN on the motherboard
/ a mouse can also map to being a MouseCard. A mouse and scroll wheel could
be mapped to 3 paddles and three buttons.

because new mice and joysticks might work better.

* storage devices - USB storage interface

The USB drives can be accessed via a ProDOS driver.

because I want to read and write folders and files, and remove and swap USB
drives.

* printer - USB printer interface

(see D Finnigan's post)

because I want to print!

[Michael J. Mahon]

The problem with just adding USB connectivity is that it doesn't get you
usable devices.

Every device you plug into a computer has to be supported by a driver, and
there are no Apple II drivers for USB-connected devices. For Windows and
MacOS, and occasionally for some flavors of Linux, but everyone else is on
their own. And these are not simple drivers--they are often megabytes of
complex code.

For instance, most USB printers are simple raster printing devices, and all
the work of rendering fonts, etc., is done by the driver, using megabytes
of code and data.

The only feasible way to usefully attach USB devices is for the card they
plug into to host the (often proprietary) driver, and then present an
interface to the device to the Apple II that can be managed with a simple
Apple II driver. Needless to say, for many devices the computer on the card
that does this "virtualization" is much more advanced in its capabilities
than the Apple II it connects to (which is ironic to purists--tail wagging
dog, etc.).

USB has become sufficiently plug-and-play that most people assume that if a
device can be plugged in, it will work. This is only true with "standard"
operating systems.

[TheJ]

USB is unfortunately super complicated.
If the goal is to be able to connect alternate keyboards then support for
PS2 keyboards would be MUCH more likely to realize.

They can still be purchased NEW on Amazon and probably many other places.

J

[D Finnigan]

[...]

>
> USB has become sufficiently plug-and-play that most people assume that if
> a
> device can be plugged in, it will work. This is only true with "standard"
> operating systems.
>

Be that as it may, we still want USB for our Apple II computers. ;-)

Could we put a basic printer driver on card firmware? Take us back to the
days of Apple Intelligent Peripheral Cards from the 70s.

[Michael J. Mahon]

I understand that you're kidding, but want to point out that Apple's I/O
innovation was putting the 6502 *code* for the device driver into an EPROM
on the card. Very few cards (and none made by Apple, IIRC) had processors.

What's needed to make any of this work is a Raspberry Pi (or comparable)
computer, running at least a semi-supported OS, to attach to the USB device
and run the driver(s), while presenting a virtual very simple device
interface to the Apple.

For example, you could present a parallel printer appearance to the Apple
while the RPi drove a modern "raster" printer. An extended ESC or ctl-G
interface could allow for font changes, etc. To be broadly usable by Apple
II apps, the extensions should emulate a commonly supported printer, like
the ImageWriter or Epson MX-80.

[mdj]

On Tuesday, 10 January 2017 10:57:39 UTC+10, Michael J. Mahon wrote:

> I understand that you're kidding, but want to point out that Apple's I/O
> innovation was putting the 6502 *code* for the device driver into an EPROM
> on the card. Very few cards (and none made by Apple, IIRC) had processors.

I don't know if there's any others, but both the Workstation card (Appletalk) and the Superdrive controller had their own 65c02 and in the case of the Workstation card, scads of firmware. It supported printing to a network Laserwriter by uploading an Imagewriter emulator written in Postscript with your print job.

Very nifty :-)

[Don Bruder]

You may or may not realize that a PS/2 keyboard effectively *IS* USB,
just without the nifty USB connector and logo. A dead-simple, completely
"dumb" adapter (it's nothing more or less than a "shape-changer" that
turns the PS/2 DIN-4 male plug into a USB "A" male plug) will connect
any PS/2 keyboard and operate flawlessly on any computer that can talk
to a USB keyboard. (ditto for PS/2 mice)

Likewise, an adapter that converts the other way (from female USB "A" to
male DIN-4) will let you plug a USB keyboard or rodent into a PS/2
system and get 100% functionality out of it.

Point being that doing a PS/2 interface for the Apple II is going to
take just as much effort as doing a full-on USB one would require.

--
Brought to you by the letter K and the number .357
Security provided by Horace S. & Dan W.

[Du Hast]

On Monday, January 9, 2017 at 5:54:12 PM UTC-5, Michael J. Mahon wrote:

> --
> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

I thought that certain things like keyboards, mice, and joysticks had a pretty standard set of drivers that allow them to work. HID interface or something....

[Michael J. Mahon]

Right--so much for my recollection. ;-)

--

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page: http://michaeljmahon.com

"The wastebasket is our most important design
tool--and it's seriously underused."

[Michael J. Mahon]

Standard for Windows and Mac, but not for Apple II's--USB protocols are
a bear!

[Charlie]

There already is an Apple II card with a USB port, the Carte Blanche II
card. I use its USB2 port (mini) to JTAG bitstreams from my PC to the
FPGA on the card. There is a driver for that. It is installed on the PC.

As Michael J. Mahon has stated, drivers are the problem. If the Apple
has to run the driver I doubt much could be done. However the Carte
Blanche II has a lot of resources that might simplify things for
something like keyboards and mice, if someone wanted to give it a try.

Charlie

[Anthony Lawther]

The protocols are significantly different in complexity. The reason these
adapters work in the first case (PS/2 devices on USB) is because the
keyboards and mice include support for both standards and can tell which
"language" to speak based on the voltages and clocks presented at power-up
of the keyboard or mouse. There are PS/2 keyboards and mice from the 1990's
that don't work with these adapters.
In the second case, the adapter is an intelligent device that includes a
small USB host (computer) that has HID drivers to support keyboards and
mice (only) and convert the USB traffic to PS/2.

PS/2 and USB have about as much in common as Ethernet and RS-232. You can
get simple connector adapters that allow RS-232 serial communication over
standard Ethernet cabling, but that doesn't make them compatible with an
Ethernet network.

It seems to me that the closest thing to a generic USB interface available
for the Apple II family is the Apple IIPi card.

Regards,
Anthony.

[Michael Black]

Yes, I have a mouse that can do both, but I can't expect to use the
"adapter" (which in this case just moves pins to the right one for the
other interface) on an older mouse or keyboard. At least some of the mice
and keyboard I've come across specify they can be used with both, I don't
know if that's consistent so I don't know if something marked "PS/2" might
be one that could do both.

The mice and keyboards use an IC to begin with, so it's not much extra
work or cost to make the IC do both, and then be smart enough to tell
which interface it's connected to, and use that.

PS/2 and ADB and USB are serial interfaces, that is common.

Michael

[mspa...@gemsi.com]

So the best way to print to modern printer would be to send the data as a serial stream (say as an Imagewriter), then have a converter box change the imagewriter code to something the USB printer could figure out. You would end up with an Raspberry Pi in a box like an old A to B serial switch.

I think I saw the plans for an PS/2 to Apple keyboard adapter somewhere. A low end PIC should handle that conversion.

The other gadget we need is not for apple //, but for those SCSI equipped Macs. A SD or Compact Flash or something that can replace the old hard drives. They would also work on an Apple of course, but we have compact flash adapters already.

[Polymorph]

The SCSI2SD has already been implemented for old Macs, and yes I saw someone has successfully tested one of these using an Apple II High Speed SCSI card:

http://www.codesrc.com/mediawiki/index.php?title=SCSI2SD

After recently trying (and failing) to get my SCSI hard drive working again, I'm thinking that one of these might be far less trouble.

Or better yet, wait for the next CFFA3000 run. :-)

Cheers,
Mike

[Michael Black]

On Tue, 10 Jan 2017, mspa...@gemsi.com wrote:

> So the best way to print to modern printer would be to send the data as
> a serial stream (say as an Imagewriter), then have a converter box
> change the imagewriter code to something the USB printer could figure
> out. You would end up with an Raspberry Pi in a box like an old A to B
> serial switch.
>

Like that whatever it was called that did the conversion from Imagewriter
code to "normal" and did the conversion to serial? It wsa famous and nice
and small, a tiny external box.

That was the problem with the Mac, it outputted only Imagewriter codes,
which weren't recognized by the average printer. When I had a Mac Plus,
starting in 1993, I soon found an early edition of MS Word, which happened
to have a "TTY driver" so I could use any simple printer. I ended up
using my Radio Shack Model 100 laptop as a serial to parallel converter;
it had a parallel printer port, and there wsa a button to press which
would have it echo to the printer anything that came into the serial port,
so I had the serial to parallel converter. That worked fine, except I
could only print via MS Word.

How many programs actually output imagewriter code? I thought for the
Apple II, the usual output wsa more like the average printer would
accept. Unless the II put out imagewriter control code a lot, better to
start with somethng cleaner.

> I think I saw the plans for an PS/2 to Apple keyboard adapter somewhere.
> A low end PIC should handle that conversion.
>
> The other gadget we need is not for apple //, but for those SCSI
> equipped Macs. A SD or Compact Flash or something that can replace the
> old hard drives. They would also work on an Apple of course, but we have
> compact flash adapters already.
>
>

Of course, SCSI is an interface, you either had an SCSI drive that
included a disk controller, or a bit earlier (or maybe in the SASI age),
an SCSI controller card and an average drive.

So there you'd need a microprocessor of some kind to interface the SD card
with the SCSI bus.

Michael

[Steve Nickolas]

On Tue, 10 Jan 2017, Michael Black wrote:

> How many programs actually output imagewriter code? I thought for the Apple
> II, the usual output wsa more like the average printer would accept. Unless
> the II put out imagewriter control code a lot, better to start with somethng
> cleaner.

The Imagewriter was the usual printer on Apple ][s, from my experience.
Sometimes you'd see an Epson MX-80 or RX-80, or some other sort of
Epson-compatible. I guess either of those would be the ideal to emulate.

The first printer I owned, btw, was an IBM Graphics Printer - basically a
rebadged Epson MX-80 with Codepage 437 support - and I had it hooked up to
my first IBM 5160.

-uso.

[Michael Black]

On Wed, 11 Jan 2017, Steve Nickolas wrote:

> On Tue, 10 Jan 2017, Michael Black wrote:
>
>> How many programs actually output imagewriter code? I thought for the
>> Apple II, the usual output wsa more like the average printer would accept.
>> Unless the II put out imagewriter control code a lot, better to start with
>> somethng cleaner.
>
> The Imagewriter was the usual printer on Apple ][s, from my experience.
> Sometimes you'd see an Epson MX-80 or RX-80, or some other sort of
> Epson-compatible. I guess either of those would be the ideal to emulate.
>

I suppose it depends on when.

The imagewriter arrived with the Macintosh, didn't it? So that's 1984,
there were about seven years before that for people to get used to using
other printers.

Michael

[TheJ]

cb meeks wrote:
> I just recently built a crude serial card for the Apple IIe. It uses the
> 65C51 and when I say crude, I mean it's just a prototype. Why build a
> serial card when we have the SSC? Well, I wanted to learn how to program
> the 65C51 directly and I had some Apple II protoboards. :-D
>
> Also, I built a Mockingboard clone a few years ago on a breadboard.
>
> So, I'm curious, if you could see a new piece of hardware released for the
> Apple II line of computers, what would it be and why?
>


Here's a board that should be made for the Apple 2!

There is a design on the Internet that was made in the 80's (actually
works!) that adds a number of features directly to the 65C02.

Features
-Linear 16MB Address space (no MMU required)
-6 new registers (2 are 16 bit)
-2 are for accelerating the Forth language
-44 new op-codes (all run inline and at CPU speed)
-the design is not limited to these features


This design is possible because on the 6502, "machine" cycles are synonymous
with Bus cycles. Utilizing the SYNC signal on pin 7, the "co-processor" will
always know when cycles are fetching op-codes.


This design was actually built and used by the designer so it is verified to
work.
It's called the "KimKlone" and you can check it out here:
http://laughtonelectronics.com/Arcana/KimKlone/Kimklone_intro.html

J

[Steven Hirsch]

On 01/12/2017 12:32 PM, TheJ wrote:

> Here's a board that should be made for the Apple 2!
>
> There is a design on the Internet that was made in the 80's (actually
> works!) that adds a number of features directly to the 65C02.
>
> Features
> -Linear 16MB Address space (no MMU required)
> -6 new registers (2 are 16 bit)
> -2 are for accelerating the Forth language
> -44 new op-codes (all run inline and at CPU speed)
> -the design is not limited to these features
>
>
> This design is possible because on the 6502, "machine" cycles are synonymous
> with Bus cycles. Utilizing the SYNC signal on pin 7, the "co-processor" will
> always know when cycles are fetching op-codes.
>
>
> This design was actually built and used by the designer so it is verified to
> work.
> It's called the "KimKlone" and you can check it out here:
> http://laughtonelectronics.com/Arcana/KimKlone/Kimklone_intro.html

The status of this device is unclear.

[mspa...@gemsi.com]

https://knzl.de/ps2-keyboard-for-apple-ii/

There is the PS2 to apple keyboard converter. It uses a PIC microcontroller for the translation.

[Nootrac90]

On Tuesday, January 3, 2017 at 3:58:18 PM UTC-5, cb meeks wrote:
> I just recently built a crude serial card for the Apple IIe. It uses the 65C51 and when I say crude, I mean it's just a prototype. Why build a serial card when we have the SSC? Well, I wanted to learn how to program the 65C51 directly and I had some Apple II protoboards. :-D
>
> Also, I built a Mockingboard clone a few years ago on a breadboard.
>
> So, I'm curious, if you could see a new piece of hardware released for the Apple II line of computers, what would it be and why?

Maybe, a clone of the Cricket by Street Electronics. It was a real time clock, sound card and speech synthesizer that plugged into the serial port on the //c.

[Charles Mangin]

I've got a board in the works that addresses a couple of modern protocols via the game port. I talked about the software side of things, and had beta boards, at last year's KansasFest. You can read about the current state of things here:

https://github.com/option8/gp2io

The idea is to create a common "bit banging" protocol that the Apple talks via the game port, and a simple microcontroller then interprets the bytes and communicates to other peripherals via I2C, SPI, UART serial, etc.

I'll have updates to the software coming soon, as well as production hardware ready to purchase for experimenters.

[mspa...@gemsi.com]

"The idea is to create a common "bit banging" protocol that the Apple talks via the game port, and a simple microcontroller then interprets the bytes and communicates to other peripherals via I2C, SPI, UART serial, etc. "

That jogged my memory. I looked it up and they still make the chip, or something similar.

http://www.rmv.com/itc232-a_mi.htm


Digital IO, SPI interface, and PWM output. And stepper motor control. RS 232 communications.

[leelan...@gmail.com]

On Tuesday, January 3, 2017 at 4:21:10 PM UTC-6, TheJ wrote:
...
> I would think that a SPI and I2C interface board could be very cool !
> There are TONS of SPI and I2C devices and all it would take is an interface
> card to add those to the Apple 2.

I am going to try building an i2C card for the Apple II using the NXP PCF8584N chip. It looks like it should be easy to set up on a proto board.

SPI is a bit more work as I have not been able to find any neat single chip solutions like the PCF8584 looks to be for i2C. I think it can be done using 74HC165 and 74HC595 8 bit shift registers and some glue. Worst case I might have to use a 6522 or something to drive them.

FWIW I already have a simple WiFi card for the Apple II designed, I'm just waiting for some parts orders to come in from China to put it together. It is based on the ESP-01 WiFi chip and I cribbed a lot of the design from David Schmenk's Apple 2 Pi card. The hard part on that is going to be the software. I have been looking at the available TCPIP stacks for the Apple II (Marinetti, IP65, Contiki, Marina, etc), and I will probably go with whichever one looks like it is the easiest to hack together a driver for my card with.

Another thing I have planned is to build an Apple II card that has an Arduino as a co-processor. That basically completely opens things up to all the parts that are available for the Arduino world, and a lot of the hard work can be off-loaded to the Arduino letting the Apple just send it simple commands to access what is needed. The most simple way to do this would be using a 6551 or similar UART but an i2C or SPI bus would be a lot faster.

I need to order a couple more proto boards I think...

[Antoine Vignau]

A wifi card! very nice! I hope you will find the right software solution.

Antoine

[Mark D. Overholser]

On 06-Mar-17 12:02, leelan...@gmail.com wrote:
> On Tuesday, January 3, 2017 at 4:21:10 PM UTC-6, TheJ wrote: ....

>> I would think that a SPI and I2C interface board could be very cool
>> ! There are TONS of SPI and I2C devices and all it would take is an
>> interface card to add those to the Apple 2.
>
> I am going to try building an i2C card for the Apple II using the NXP
> PCF8584N chip. It looks like it should be easy to set up on a proto
> board.
>
> SPI is a bit more work as I have not been able to find any neat
> single chip solutions like the PCF8584 looks to be for i2C. I think
> it can be done using 74HC165 and 74HC595 8 bit shift registers and
> some glue. Worst case I might have to use a 6522 or something to
> drive them.
>

I have worked with the MicroChip PIC 18F2550 in the past and it supports
I2C and SPI in Hardware.. It or its Bigger Sibling, the 18F4550 could
be used to get more diverse I/O into the old Apple ][..


<http://www.microchip.com/wwwproducts/en/PIC18F2550>
<http://www.microchip.com/wwwproducts/en/PIC18F4550>

> FWIW I already have a simple WiFi card for the Apple II designed, I'm
> just waiting for some parts orders to come in from China to put it
> together. It is based on the ESP-01 WiFi chip and I cribbed a lot of
> the design from David Schmenk's Apple 2 Pi card. The hard part on
> that is going to be the software. I have been looking at the
> available TCPIP stacks for the Apple II (Marinetti, IP65, Contiki,
> Marina, etc), and I will probably go with whichever one looks like it
> is the easiest to hack together a driver for my card with.
>

Luckily the ESP8266 ESP-01 has an on board TCP/IP Stack, so something
like the Uthernet II Drivers might be a good starting point...

> Another thing I have planned is to build an Apple II card that has an
> Arduino as a co-processor. That basically completely opens things up
> to all the parts that are available for the Arduino world, and a lot
> of the hard work can be off-loaded to the Arduino letting the Apple
> just send it simple commands to access what is needed. The most
> simple way to do this would be using a 6551 or similar UART but an
> i2C or SPI bus would be a lot faster.
>

An Apple ][ Bus to SPI/I2C would be a good start to connecting to all
kinds of modern Microcontrollers...

> I need to order a couple more proto boards I think...
>

You can Never have too many of those.... ;)


MarkO

[leelan...@gmail.com]

On Monday, March 6, 2017 at 2:47:39 PM UTC-6, Mark D. Overholser wrote:
...

> I have worked with the MicroChip PIC 18F2550 in the past and it supports
> I2C and SPI in Hardware.. It or its Bigger Sibling, the 18F4550 could
> be used to get more diverse I/O into the old Apple ][..

...
> MarkO

That chip is not really exactly what I'm looking for. It has i2C and SPI, but no way to directly interface with the Apple II bus directly. It is really more like one of the Atmel chips like the ATmega328p. If you look at the PCF8584 for i2C you'll see what I mean, it directly hooks to the D0-D8 (well, may need a buffer in there) and A* lines. I haven't been able to find any single chip that is designed to interface directly to a microcomputer bus that does SPI yet. Right now I am leaning towards using a 6522 with one of the parallel channels hooked to a 74HC165 and the other a 74HC595 to do the 8 bit in and out shifting. It may be unnecessarily complex but I think it should be able to provide a reliable SPI interface.

[mspa...@gemsi.com]

" I haven't been able to find any single chip that is designed to interface directly to a microcomputer bus that does SPI yet."

Could you use something like a Teensy 3.2 and use 8 digital data pins to talk to the Apple // bus? And you would have to use a few more to deal with R/W and Device Select.

I've bit-banged an SPI using pushbutton inputs and annunciators long ago. It was slow, but it worked. Using a 6821 should be more flexible.

[leelan...@gmail.com]

Using an Arduino would work, but it is still kinda kludgy. I know I could do bit banging with the game port but the whole point of this exercise is to do it the "right way". And at this point that looks like a 6522 and 74HC165 and 74HC595 (plus a 74HC245 and 74HC74 as glue). Maybe need another part or two but I think that's getting close.

[Anthony Lawther]

A Parallax Propeller with a fairly small amount of code could be used to
produce what you are looking to do. It could be coded to support both SPI
and I2C in the one slot.

Regards,
Anthony

[RayGee]

On 7/03/2017 1:27 PM, mspa...@gemsi.com wrote:
> " I haven't been able to find any single chip that is designed to interface directly to a microcomputer bus that does SPI yet."
>

Hi,
There was a project by Daryl Rictor allowing a 6502 to interface to a
set of SPI peripherals. It could be an ideal basis for creating an
efficient SPI Master for the Apple 2 if still available:
http://sbc.rictor.org/65spi.html

It is a single chip in a square 44 pin package.

Raymond.

[leelan...@gmail.com]

On Tuesday, March 7, 2017 at 12:23:23 AM UTC-6, Anthony Lawther wrote:
...

> A Parallax Propeller with a fairly small amount of code could be used to
> produce what you are looking to do. It could be coded to support both SPI
> and I2C in the one slot.
>
> Regards,
> Anthony

Basically the same solution as the PIC or Atmel (Arduino) chips. It could be made to work, but you're still looking at something ugly like serial to talk to the Propeller.

[leelan...@gmail.com]

Yeah, I've seen Xilinx (FPGA) based solutions for SPI. They are usually prohibitively expensive (like > $40 by the time you get one and the socket) and still require programming the chip before they do anything. And the software and programming hardware is out of reach for me price wise.

[Michael J. Mahon]

Have you considered using software and the annunciators and pushbuttons?
Unless bandwidth in excess of 10kbytes/sec is needed, it's a much simpler
solution--and free. ;-)

[leelan...@gmail.com]

On Tuesday, March 7, 2017 at 11:38:04 AM UTC-6, Michael J. Mahon wrote:
> Have you considered using software and the annunciators and pushbuttons?
> Unless bandwidth in excess of 10kbytes/sec is needed, it's a much simpler
> solution--and free. ;-)
>
> --
> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

That solution was rejected several messages ago, but thanks. It is just plain ugly and it interferes with having a joystick attached.

The whole point of the exercise is building a card to do it "right". Which means a card for an Apple II slot and hardware that doesn't require bit banging. I'm getting pretty close to working up a design using a 74HC245, 6522, 74HC74, 74HC165, 74HC595 & maybe a couple other parts. It is still not terribly expensive (the proto board will be by far the bulk of the cost) and it should not require too huge of a load on the Apple II to process since the 6522 and shift registers offload a lot of the hard work.

Don't get me wrong, the game port hack is great for some things, but for others like interfacing to storage or networking devices where speed and overhead are significant it isn't appropriate. And that's a large share of the SPI peripherals. Newer devices that don't require high speed are more often i2C or one-wire interfaces.

[Anthony Lawther]

One cog of the Propeller could be devoted to communicating on the Apple II
bus (8 data, 4 address, 4 control) while one or more cogs can run precanned
SPI or I2C interfaces over the remaining pins. The most significant
limitation I can see is the internal RAM.

But given that your definition of doing it "right" precludes bit-banging
then this isn't the right solution for you.

Good luck in your endeavours.

Regards,
Anthony

[Michael J. Mahon]

The 6522 also provides shift register and interrupt capability.

[Michael J. Mahon]

I understand, but many potential "attachments" would not require sustained
data transfers, and "no hardware required" removes a lot of obstacles to
proliferation!

And, as I'm sure you appreciate, "right" is in the mind of the beholder.
Some of the code I'm proudest of can be classed as bit-banging. In fact,
there's a lot of bit-banging spirit in the Disk ][ (though I suppose
that's "byte-banging" ;-).

[leelan...@gmail.com]

Argh!!! "No hardware required" is exactly the antithesis of this whole thread!!!

It is "what hardware is MISSING".

Bit banger SPI from the game port already exists. David Schmenk showed how it could be done to hook up an Arduino SD card reader shield. I have no interest in re-inventing his solution. There isn't much fun in that.

There is not a good real hardware implementation of SPI on the Apple II. For the applications where the bit banging approach falls short there currently is no good solution. That is an interesting problem. I don't understand why people keep trying to get me to take the easy way out.

Of course the Disk II controller and analog board is cool... Aren't you glad that Woz didn't say "hey, I could just hook that all up by the game port" and build some kind of bastard contraption like the Commodore 154x where they cheaped out and bit banged it off the 652x instead of putting in real GPIB like the PET had. I'm no Woz. I am sure he could build an SPI card for the Apple II with 1/2 the chips it will take me. I'm an old geezer but I've been more of a software guy over the years so there is a lot about hardware I'm still learning. That's a whole lot of why I want to try this -- to learn something.

Also as I said before, I might not want to have to pop the cover and unplug my joystick every time I wanted to do something like read an SD card. There is only one game port, but there are several slots.

[Michael J. Mahon]

I hear you.

Since you are precisely looking for interesting Apple-related projects, I
understand your desire to stay in the hardware domain.

I'm probably not the best judge, since I'm more interested in old hardware
for the hobby and new hardware for the convenience. ;-)

I suggested the "easy" or "prototype" approach because I don't know the
requirements you want.

It would be cool to hear more about what the SPI world has to offer the
Apple II user.

It sounds like you're in this for the fun, so more power to you!

> There is not a good real hardware implementation of SPI on the Apple II.
> For the applications where the bit banging approach falls short there
> currently is no good solution. That is an interesting problem. I don't
> understand why people keep trying to get me to take the easy way out.

No problem--what data rates are you planning? Is DMA useful? Most
software-data-transfer routines will require about 13 cycles per byte, plus
whatever handshaking is required--that's about 125kBytes max. I'm guessing
that some on-board buffering may also help data rates. Pretty soon it
starts to look like a microcontroller would be a good way to
go...hmmm--another software solution. ;-)

> Of course the Disk II controller and analog board is cool... Aren't you
> glad that Woz didn't say "hey, I could just hook that all up by the game
> port" and build some kind of bastard contraption like the Commodore 154x
> where they cheaped out and bit banged it off the 652x instead of putting
> in real GPIB like the PET had. I'm no Woz. I am sure he could build an
> SPI card for the Apple II with 1/2 the chips it will take me. I'm an old
> geezer but I've been more of a software guy over the years so there is a
> lot about hardware I'm still learning. That's a whole lot of why I want
> to try this -- to learn something.

I get it. That's terrific!

FWIW, I think Woz was always get the most he could from as little as
possible. I've always found the Disk ][ Controller to be an elegant
example of that: faster, denser, and cheaper than the industry standard--by
quite a lot.

> Also as I said before, I might not want to have to pop the cover and
> unplug my joystick every time I wanted to do something like read an SD
> card. There is only one game port, but there are several slots.

Indeed. But you can "stack" things on the 16-pin game port (the only one
with outputs) by using a machined-pin socket for the connector. That only
leaves the question of interference between uses. Not knowing the intended
applications, I can't be sure, but for many the SPI adapter might not be in
use when the game port is otherwise in use.

I usually run with NadaNet and a game-port-connected clock/calendar, and
even they both use some signals, they never interfere with each other. (Of
course, if I hit Open-Apple or a game controller pushbutton, NadaNet
requests time out after several seconds, but that's a handy way for me to
test. ;-)

I encourage you to continue your hardware efforts. I think it will be fun,
enlightening, frustrating, enlightening, fun, etc.! I especially applaud
your cross-discipline approach. Designs would be better if hardware
engineers learned software engineering, and vice versa.

[leelan...@gmail.com]

On Wednesday, March 8, 2017 at 2:36:29 PM UTC-6, Michael J. Mahon wrote:
> I hear you.
>
> Since you are precisely looking for interesting Apple-related projects, I
> understand your desire to stay in the hardware domain.

Yeah, and I do software all day so the hardware is a nice change of direction. I could just stay with more modern stuff like the Arduinos and Raspberry Pis, but the nostalgia aspect of the Apple II is pretty cool since for me that was the machine that ignited my whole interest in computers to begin with.

> I'm probably not the best judge, since I'm more interested in old hardware
> for the hobby and new hardware for the convenience. ;-)

For this kind of thing for me it is about the making it. It being a challenge is part of the thrill of it all.

> I suggested the "easy" or "prototype" approach because I don't know the
> requirements you want.
>
> It would be cool to hear more about what the SPI world has to offer the
> Apple II user.

Go to some of the places that sell parts for Arduinos and Raspberry Pis and you'll see the vast array of peripheral devices that are out there. It is a pretty incredible ecosystem. For hardware and software hobbyists right now is in my opinion the most exciting time since the heyday of the 8-bit micro.

In addition to the things I've mentioned there are LCD displays and all kinds of sensors and input/output devices that use either the SPI or i2C interfaces. Oh and things like SATA interfaces (2 TB drive on your Apple II ?), BlueTooth, etc. A driver for wireless mice and keyboards on an Apple II could be cool.

> It sounds like you're in this for the fun, so more power to you!

Thanks. I think I'm kinda going through a mid-life crisis lately and this whole thing has been a way for me to re-connect with my childhood. That and last year I traded my big full sized luxury car for a Corvette...

> > There is not a good real hardware implementation of SPI on the Apple II.
> > For the applications where the bit banging approach falls short there
> > currently is no good solution. That is an interesting problem. I don't
> > understand why people keep trying to get me to take the easy way out.
>
> No problem--what data rates are you planning? Is DMA useful? Most
> software-data-transfer routines will require about 13 cycles per byte, plus
> whatever handshaking is required--that's about 125kBytes max. I'm guessing
> that some on-board buffering may also help data rates. Pretty soon it
> starts to look like a microcontroller would be a good way to
> go...hmmm--another software solution. ;-)

DMA would be great, but probably not going to be reasonable to implement with the solution I am working on. Data rates for many of the peripherals will be as fast as possible. It is more trying to see what is possible than having a target in mind up front. I am thinking that whatever cycles a bit banging approach takes a hardware based approach ought to be at least 4-8x as fast because of whole bytes being sent and received at a time instead of having to manually shift out or shift in bits and write them one at a time.

Actually one potential use for a high speed SPI interface on an Apple II might be connecting to something like an Arduino or maybe a full fledged NodeMCU version of the ESP8266 and using it to offload tasks that the Apple II may struggle to do on its own. David Schmenk already has a game port SPI based solution for attaching an Arduino to an Apple II, but a hardware one would offer considerably higher throughput. Another idea... the Raspberry Pi has both i2C and SPI interfaces... David's Apple 2 Pi card uses serial with a 6551... but i2C or SPI should be way faster.

> > Of course the Disk II controller and analog board is cool... Aren't you
> > glad that Woz didn't say "hey, I could just hook that all up by the game
> > port" and build some kind of bastard contraption like the Commodore 154x
> > where they cheaped out and bit banged it off the 652x instead of putting
> > in real GPIB like the PET had. I'm no Woz. I am sure he could build an
> > SPI card for the Apple II with 1/2 the chips it will take me. I'm an old
> > geezer but I've been more of a software guy over the years so there is a
> > lot about hardware I'm still learning. That's a whole lot of why I want
> > to try this -- to learn something.
>
> I get it. That's terrific!
>
> FWIW, I think Woz was always get the most he could from as little as
> possible. I've always found the Disk ][ Controller to be an elegant
> example of that: faster, denser, and cheaper than the industry standard--by
> quite a lot.

I agree... however it is also a different world today than it was back then and hardware that was unobtanium back then is cheap today. I imagine he is a super busy guy but it would be interesting if Woz were to re-discover his Apple II heritage and start designing hardware and/or software for it again.

> > Also as I said before, I might not want to have to pop the cover and
> > unplug my joystick every time I wanted to do something like read an SD
> > card. There is only one game port, but there are several slots.
>
> Indeed. But you can "stack" things on the 16-pin game port (the only one
> with outputs) by using a machined-pin socket for the connector. That only
> leaves the question of interference between uses. Not knowing the intended
> applications, I can't be sure, but for many the SPI adapter might not be in
> use when the game port is otherwise in use.

That does go both ways though... there may be just as many applications where someone might want to use both at once.

> I usually run with NadaNet and a game-port-connected clock/calendar, and
> even they both use some signals, they never interfere with each other. (Of
> course, if I hit Open-Apple or a game controller pushbutton, NadaNet
> requests time out after several seconds, but that's a handy way for me to
> test. ;-)

There are SPI and i2C devices for most of those kind of peripherals... clock
calendars, Ethernet, storage devices, radio transmitters, cell/gsm modems, etc.
I'd be worried about things like the Apple keys interfering with a lot of those devices.

> I encourage you to continue your hardware efforts. I think it will be fun,
> enlightening, frustrating, enlightening, fun, etc.! I especially applaud
> your cross-discipline approach. Designs would be better if hardware
> engineers learned software engineering, and vice versa.

I agree. At one time I wasn't sure what direction I wanted to go and ended up going the software route. I was glad I did that because after the 8 bit micro days faded out the clock speeds and complexity got to be too much for hobbyist experimenters. A couple years ago I got aquainted with first the Raspberry Pi and then the Arduino type boards. That has sort of brought me full circle to the old days.

[mdj]

On Wednesday, 8 March 2017 05:01:35 UTC+10, leelan...@gmail.com wrote:

> The whole point of the exercise is building a card to do it "right". Which means a card for an Apple II slot and hardware that doesn't require bit banging. I'm getting pretty close to working up a design using a 74HC245, 6522, 74HC74, 74HC165, 74HC595 & maybe a couple other parts. It is still not terribly expensive (the proto board will be by far the bulk of the cost) and it should not require too huge of a load on the Apple II to process since the 6522 and shift registers offload a lot of the hard work.

That's more or less what I would do if I wanted to do this for 'fun'. One piece of advice though - if you intend your card to work across the entire range of slotted Apple IIs, be very mindful when interfacing 74HC family parts directly to Apple II bus signals.

Why is this so ? In the original II and IIe, the bus signals are (with some exceptions) TTL, and TTL inputs register a logic '1' when the input is >= 2.4v. 74HC OTOH, are CMOS parts, and their inputs will be logic '1' when the input voltage is above 0.7 of Vdd. Assuming you're supplying your HC logic with a good strong 5v, this is 3.5v. Assuming a nominal 4.5v supply it's still 3.15v.

This is especially problematic since "most of the time" a TTL output will be at least this high and it will "just work". Worse, if your development rig is an Apple IIgs, it will always work because the bus signals are 5v CMOS already. Figuring out why it then doesn't work in a IIe is an excellent learning exercise in circuit debugging, but one that can be avoided ;-)

For this reason, the 74HCT family exists (with a nominal logic '1' input of 2.0v) and if you must cross between TTL and CMOS domains you should design with those parts instead where the signalling interfaces directly to the Apple II. In the case of a SPI adapter, this is obviously what you need to do since all SPI parts are CMOS.

> Don't get me wrong, the game port hack is great for some things, but for others like interfacing to storage or networking devices where speed and overhead are significant it isn't appropriate. And that's a large share of the SPI peripherals. Newer devices that don't require high speed are more often i2C or one-wire interfaces.

It's often a good first place to start, but as you've no doubt concluded, 3 74xx parts will get you 8 annunciators, 4 pushbuttons and 3 spare strobes. It's also a great deal of fun :-)

[6502en...@gmail.com]

What really would be great would be a

durable USB Connection to the PC, IPhone etc. that just prints the monitor of the Apple II to a Software on these devices, f.e. Word.

So you would be able to copy and paste all text or sheets work on these devices. Would open another way for modern use of the Apple II.

[Oliver Schmidt]

Hi,

>FWIW I already have a simple WiFi card for the Apple II designed [...] It is based on the ESP-01 WiFi chip [...] I have been looking at the available TCPIP stacks for the Apple II (Marinetti, IP65, Contiki, Marina, etc), and I will probably go with which ever one looks like it is the easiest to hack together a driver for my card with.

The ESP-01 obligates you to use it's built-in TCP/IP stack. The
existing TCP/IP stacks for the Apple II more or less insist in using
them. That doesn't fit.

Regards,
Oliver

[Oliver Schmidt]

Hi,

>Luckily the ESP8266 ESP-01 has an on board TCP/IP Stack, so something
>like the Uthernet II Drivers might be a good starting point...

The Uthernet II drivers used for ADTPro, IP65, Marinetti and Contiki
all ignore the TCP/IP stack of the W5100 chip on the Uthernet II.
Execatly this "bypassing the TCP/IP stack" is not possible with the
Espressif products.

Regards,
Oliver

[leelan...@gmail.com]

I think it can be done by writing a wedge between one of the existing Apple II APIs and the ESP-01. Worst case I can write code that runs on the ESP-01 to replace the AT command processor so it doesn't take up a lot of space on the Apple II. I could also add additional Apple II code on an EPROM if necessary.

I'll take a look at the Uthernet II drivers, but if they aren't a good starting point I will take a different approach. Where there's a will, there's a way.