Re: 68008 co-processor board complete working design available ...

[Jim Gilbert <brokerjim@gmail.com>]

On Dec 3, 8:37 pm, Jim Gilbert <broker...@gmail.com> wrote:
> On Nov 25, 2:47 pm, Patrick Schaefer <pa.schae...@web.de> wrote:
>
> > Am 24.11.2010 21:53 schrieb Jim Gilbert:
>
> > > Newly posted information:
>
> > > (...)
>
> > Thank you very much! It would be great if you could provide binary
> > versions of the sotware as well. I.e. a hex or bin file for the EPROM,
> > and a dsk or shk with the Prodos part.
>
> > Best regards
> > Patrick
>
> I am working on this...
>
> The binary is on Apple ][ 5.25" floppies. I no longer have an Apple ]
> [. I do not have hardcopy source for the print spooler but I swear I
> wrote one.
>
> I can recreate the softcopy of the Applesoft monitor and the DOS3.3
> ram disk and the EPROM Monitor by OCRing the listings I have, I think.
>
> Cheers.
> Jim Gilbert

After some extensive review of the design I have concluded that this
could easily be upgraded to 512K of memory (ironically going from
matching the original Mac to the "Fat Mac" in RAM).  There is room for
the 1-pin longer sockets on the layout if the decoupling capacitors
for the 4 memory chips are relocated to beside the chips instead of
inline with them.  And you CAN still buy 256x8 FPM 5V DRAMs.

The EPROM could be fairly easily upgraded to EEPROM.

And an LED or two for RESET and HALT would be nice.

I have seriously considered putting together a little breadboard
driven by a spare ATX supply that would connect to power, a power
button, the 50-pin backplane connector and a PC parallel port. Careful
review of the 68008 board and a whole lot of parallel port
documentation reveals that given power, the 68008 board would run with
a PC parallel port interfacing to the backplane connector.  A QBASIC,
or C, program driving the parallel port would replace the Applesoft
DBG68 debugger.
In a moment of weakness I ordered a cable with the 50-pin card edge
connector.  The next step would be getting a little breadboard and
some jumpers.  I can hear
the cry "She lives!" from that old Peter Sellers movie already...

So I may bring the board back to live without an Apple ][ just for
fun.
Of course I could buy another Apple ][.

The easiest way to rescue the softcopy of the programs on the Apple ]
[ floppies I have would be to mail them off to a trusty volunteer with
a real Apple ][ and working 5.25" drive. They could be liberated from
the medium and turned into disk images that are easier to save and
toss around the Internet that way.

Or more intriguingly, since I am out of space on the 68008 board I
could use an Arduino, Beagleboard, Netburner, or PIC-breadboard for
the host interface. This would allow me to easily add IDE/CF disk,
Ethernet, Wifi or USB access to the 68008 via the host interface.  I
might end up programming the host interface more than the 68008.

And, other than the thrill of retro-hacking, what would you have?   An
8-bit 68008 with 512K RAM, a bi-directional 512x8 path to the host,
and a serial port.
Too small for uclinux. OK for SK*DOS, the USCD P-system*, or someone's
real time system. OK for Contiki. No display capability except via the
serial port to a terminal emulator.

Of course a host interface with an ARM, x86 or Coldfire processor
would already have Linux available on it.

Intel, AMD, Microsoft, and all the Linux guys have buried us under GB
of RAM, GHz of processor, and awesome high-res color displays.

If I want to enjoy 68000 assembly language programming then the
smartest thing to do is to do it on my Windows box via an emulator.
This would be rather sterile.

If I were to do the board again today I would use the free Coldfire V1
FPGA core, do the bulk of the logic in the FPGA or CPLD, do it in
3.3v, use modern RAM, and allow for standalone or Apple ][ versions.

Retro-ramblings, eh?

Jim Gilbert

*Regarding the UCSD P-system I once ported the II.0 P-system entirely
to 8086 running on my Cromemco System III using a Seattle Computer
Products S-100 8086 board, SCP-DOS 0.9 (the great-grandfather of all
MS-DOS's, and Tim Patterson's monitor). I compared the performance of
the UCSD system compiling the compiler using Z80 at 4 MHz, 8086 at
8MHz with 8 bit memory, 8086 at 8MHz with 16 bit memory, etc.  I had
lots of experience with the P-System compiler because I had ported,
extended, and maintained it for the Basic Four "Newport" 32-bit stack
machines. I gave away, threw away all my P-system stuff when I moved
from California to the East Coast in 1989.