A retrocomputing project, details of the journey

[slburris]

I found one of my EPROM erasers, a Heathkit 4803 from
the 1980's.  I fired it up and the lamp lit, so I think I'm
good to go.  Good thing too, where in the world would
I find a replacement UV lamp for this nowdays?

Pics taken with an original iPhone camera instead of my
real camera, so the quality isn't too good.

Scott

[JohnS_AZ]

I don't know, I'll have to look it up. It -HAS- been a long time. :-)
There's no way I'll find the Radio Shack alophone speech chips I used.
Did you find the right eproms you were looking for?

[slburris]

For you nostalgia fans, I found my copy of the CP/M documentation.
Good thing too, because I don't remember the details of how
you build the interface to the serial console and the disk controller
anymore.

Scott

[DJPhil]

Good thing too, where in the world would I find a replacement UV lamp for this nowdays?

It might use a fairly standard 15-20W fluorescent bulb, and those are still available in most hardware stores. Thanks to modern air freshening technology (and a little bit of hypochondria) there's a good selection of germicidal UV bulbs out there that might work too.

[slburris]

I've spent the last couple days reviewing CP/M documentation, refreshing my memory of
the BDOS, BIOS, TPA, DPHs, DPBs (all acronyms that should be familiar to
the CP/M fan).  I'm struggling with ideas about how to use the flash storage.

If I've done my calculations correctly, CP/M supports disks up to 32MB in size, so
I can create drive letters A: through P: each with a 32MB chunk.

It would be most convenient to have the CP/M disks actually be files on a
FAT16 formatted flash card.  Then I could easily build images using
the simh simulator.

The question is, do I have enough space in the BIOS area to read/write a
FAT formatted filesystem under the covers, yet present it as a "disk" with
128 byte sectors to CP/M?  I'm kinda doubting it.

Well then, I could drop in a PIC or Atmel chip to handle the FAT stuff, and
have it be an intelligent peripheral of the Z80.  So the Z80 BIOS would just ask for
a particular cylinder/head/sector and the controller would go off and do the right thing.

Somehow it seems wrong to drop a modern processor into a retrocomputer
design though.  I'm already going to use a buck regulator chip and probably
an FTDI USB chip for serial interfacing and those are already anachronistic
in this design.

Hmm, I could drop in a second Z80 system with code to manage the storage in
EPROM, and have the second Z80 be a peripheral of the first Z80.  Of course
then I'm starting to have an unreasonable number of chips just to get anything done!

Or I could chuck the whole using files on a FAT filesystem idea, partition the flash
card into 32MB chunks, and then have the BIOS use that.  That makes writing out
the disk images from a PC much less convenient though, and I really have to do
that to get stuff like Wordstar and Pascal/MT+ running.

Decisions, decisions...

And of course the choice made here directly affects the schematic/PCB design and if I
made the wrong one, I'll be on my way to making my first set of green coasters 

Scott

[baljemmett]

The question is, do I have enough space in the BIOS area to read/write a
FAT formatted filesystem under the covers, yet present it as a "disk" with
128 byte sectors to CP/M?  I'm kinda doubting it.

Well then, I could drop in a PIC or Atmel chip to handle the FAT stuff, and
have it be an intelligent peripheral of the Z80.  So the Z80 BIOS would just ask for
a particular cylinder/head/sector and the controller would go off and do the right thing.

You could take a halfway-house approach, perhaps, and create a number of contiguous 32MB files in a FAT partition in convenient locations (starting on cylinder boundaries, etc.); that way you can write into them fine from a PC, and the CP/M BIOS code can also know where they are simply by adding a cylinder offset.

Could even perhaps have enough smarts in the BIOS to find a small file describing where they are (kinda like a partition table - just keep it in one cluster so it's just a scan through the root directory with no need to understand FAT properly), and would probably be wise to have a small program on the PC to check that they're still where you expect, etc.

[slburris]

"How are you going to program those newfangled EPROM chips?"

Glad you asked.  Digging through dusty old boxes, I found a
Modular Circuit Technology Enhanced PLD Programmer model
MOD-LPP.

What's that?  I *think* MCT is a private branding that Jameco Electronics
uses (www.jameco.com).  Doing a little digging, I found this is just a
rebranding of the ChipMax by EETools.  Checking out their website
(www.eetools.com), I found that although the hardware is no longer
supported, they are still releasing programming software which
supports this unit!  Yea EETools!

Being so old, the interface to this is a parallel port.  Well, my two
Windows boxes are both running Windows 7 64-bit.  No parallel port
access for the EEtools software :-(

However, I found that I could run Windows 2000 under VMware and
give that virtual machine access to the parallel port.  Tada!  It works.

Scott

[slburris]

This isn't done yet, but here is a copy of the in-progress schematic for
classic system.  It's already getting very busy, so I'll probably break it
up into several schematic sheets before I'm done.

This is just to give you an idea of where I'm going with this.

Scott

[Zad]

Talking of retro computing, how about this! http://www.visual6502.org/

They have taken a 6502, photographed it at high resolution, worked out the metallisation and diffusion layers to see exactly how it works (nothing unusual there really) but then gone on to graphically simulate the physical chip, showing which conductors have a charge. That must have taken a huge amount of work!

[slburris]

Talking of retro computing, how about this! http://www.visual6502.org/

They have taken a 6502, photographed it at high resolution, worked out the metallisation and diffusion layers to see exactly how it works (nothing unusual there really) but then gone on to graphically simulate the physical chip, showing which conductors have a charge. That must have taken a huge amount of work!

Wow, these guys are quite mad! 

Scott

[slburris]

I've been working on the I/O decoding and memory decoding, and the design
was starting to take up quite a few jelly bean logic chips.

So to symplify things yet stay with technology of the era, I've decided to
sweep the glue logic into a GAL chip.  Yes, I should probably use a PAL,
but I don't have any, and I don't fancy programming one-time programmable
chips anyway, since I invariably get things wrong!

In my junk box, I have a bunch of ATF22V10, which is Atmel's GAL22V10 chip.

I haven't touched anything like this in years.  These days I program FPGAs
and CPLDs in VHDL.  But GALs?

Time to wrap my head around WinCUPL and try to remember how you program
in this language.  It sure seems much clumsier to me than VHDL....

Anyone, here's my first shot at the CUPL description for the GAL:


Name     z80 ;
PartNo   00 ;
Date     9/24/2010 ;
Revision 01 ;
Designer Engineer ;
Company  - ;
Assembly None ;
Location  ;
Device   g22v10 ;

/* input pins */
pin  1 = !reset;
pin  2 = !mreq;
pin  3 = !iorq;
pin  4 = !rd;
pin  5 = !wr;
pin  6 = !m1;
pin  [7..9] = [a5..a7];
pin 10 = a15;

/* output pins */
pin 14 = !siosel;
pin 15 = !ctcsel;
pin 16 = !piosel;
pin 17 = !cfsel;
pin 18 = !memlow;
pin 19 = !memhigh;

pin 22 = !promena;

field ioaddr = [a5..7];
field iosel = [siosel,ctcsel,piosel,cfsel];
field iodecode = [sio,ctc,pio,cf,mem];

table ioaddr => iodecode {
   [00..1f] => 'b'10000;
   [20..3f] => 'b'01000;
   [40..5f] => 'b'00100;
   [60..7f] => 'b'00010;
   [80..9f] => 'b'00001;
}

siosel = !m1 & iorq & sio;
ctcsel = !m1 & iorq & ctc;
piosel = !m1 & iorq & pio;
cfsel = !m1 & iorq & cf;
memena = !m1 & iorq & mem;

promena.ar = memena;
promena.sp = 'b'1;

memlow = mreq & !a15 & (!rd # !promena);
memhigh = mreq & a15 & (!rd # !promena);

[slburris]

Lets try posting again, first time didn't work....

Time for an update.

I've completed 90% of the schematic work and attached the three schematic
sheets to this posting.

I've done a layout of the PCB and did a preliminary routing test.

Next up, I need to finished the schematic and PCB, print out the PCB at
actual size, get all the components together, and do a fit test on paper.
Once that all looks good, then it will be time to order PCBs and build
a prototype.

Scott

[Zad]

Maybe it is because I am a hardware person rather than a software one, but give me logic gate diagrams any day, so much easier to understand what is going on!

 

[slburris]

Test to see if posting to this topic still works.

[slburris]

Going to continue in "Retrocomputing, part 2"