Project Logs

Collapse

• Cabling

  Keith • 11/23/2025 at 03:11 • 0 comments

  The original designers made a mistake. IDC header cables carry pin 1 to pin 1 for stack of boards with the connector on the same edge, but not for two boards facing each other. That is fine when using vertical headers, but right-angle headers bend to the right, by convention and to avoid having to make two variant headers of each right-angled headers.

  This would be fine if the designer had designed the Speculator and Silicon Disk to be "upside down" in their box, but they are not. Therefore pin 1 of the Einstein goes to pin of of the cable, but the Speculator pin 1 goes to pin 60 of its connector.

  The original system seems to get round this by cutting off the polarity bump on the IDC socket, which then allows the IDC socket to fit either way. 

  We now have to make suitable cables for new kits.

  Lee shopped around and found that it was cheaper to by ready-made cables then their components.

  https://uk.farnell.com/w/c/cable-wire-cable-assemblies/cable-assemblies/ribbon-flat-cable-assemblies?st=2.54+60+ribbon+cable&range=inc-in-stock

  The header-to-header cables have the headers in the same orientation. Fine if you accept cutting off the polarising lug at the Speculator end. There is also no way to add a 3rd IDC socket for a Silicon Disk.

  The original system had the cable about 100 mm, or 4 inches. This is very short, to reduce signal ringing.

  https://uk.farnell.com/multicomp-pro/mp012858/cable-assy-60p-idc-rcpt-rcpt-100mm/dp/4243759 (£3.32) is 100mm header to header.

  https://uk.farnell.com/multicomp-pro/mp012774/cbl-assy-60p-idc-rcpt-free-end/dp/4243666  (£2.95  is 100mm to free end, which would allow tw IDC sockets to be slid on, in inverted fashion (pin 1 to pin 60).
  

  https://uk.farnell.com/multicomp-pro/mp012775/cbl-assy-60p-idc-rcpt-free-end/dp/4243667 (£2.47) is 150 mm to open end but even cheaper.

  https://uk.farnell.com/multicomp-pro/mc-254-60-00-00-idc/connector-rcpt-60pos-2row-2-54mm/dp/2843507 (76p) is a 60 way IDC socket. It makes sense to have two at the Speculator end, to allow for a Silicon disk in the same case.

  So the cost of a cable would be about 247+76+76 = 399p.

• Comparing the PAL and GAL chips

  Keith • 11/14/2025 at 01:34 • 0 comments

  Next step is to check they work exactly as the originals.

  I wired my device programmer to a plugblock, to rearrange the signals as a 16 kbyte EPROM (27C128). 

  The single-core wires are a bit stiff, the trick is to put them into the ZIF socket first then get the socket to grab them. Then you can bend them into the plug-board holes. A bit Tricky swapping chips under the wires though. I'll have to make something more robust.

  I then read the original and recreated logic outputs. Alas, they did not match! Not a disaster, just need to figure it out.

  2025-11-02

  I put the fuse maps into a spreadsheet for comparison. I was pleased to see the main logic fuses match, so there is no error in the equations. The GAL chip has extra fuses for configuration, and the PAL does not, so they have nothing to compare with. 

  The configuration bits seemed plausible. So I made a better test adaptor using a USB-to-I2C device and a I2C-to-digital-IO chip. It looks like this:

  Top right, a USB-to-I2C module. Top centre, in I2C to 16-bit I/O module. Top left, an LED bar for monitoring the logic chip outputs. Bottom, an ATF16V8 being read to confirm that its outputs match the PAL14L4 which was read earlier. Sorry about the camera trying to focus more on the ribbon cable than the active components.

  2025-11-13

  I read the outputs of the PAL and the GAL chips. I found that for both type of chips, pins 16 and 17 behaved identically. Pins 14 and 15 of the GAL chips were low all the time, exactly as expected from the JEDEC files read from the PAL chips.
  

  However, pins 14 and 15 of the PAL chips were not low all the time! It is rather suspicious that the same two pis on two different chips just happen to be unused. I suspect my device programmer is not reading out the fuses for the PAL14L4. Damn! I hope this is just a bug in the software and not hardware fault in my programmer.

  On the plus side, I have now read out the actual behaviour of the PAL pins and therefore I should be able to reverse-engineer the logic equations from that. This will take time, but the Memotech version might provide a few hints.

  2025-11-15

  After a lot of manual work, I now have the GAL chips behaving exactly like the PAL chips. Success!

• Creating the 16V8 chips

  Keith • 10/31/2025 at 01:56 • 0 comments

  2025-10-30

  The chips programmed successfully but failed verification.

  I loaded the buffer with the created JEDEC files, then saved the buffer to files.

  I read the programmed chips into the buffer, then saved the buffer to files.

  I then ran diff to compare them. This is what I got:

  1c1
  <  Generated by Dataman-48 on Fri Oct 31 00:24:45 2025
  ---
  >  Generated by Dataman-48 on Fri Oct 31 00:16:13 2025
  68,74c68,74
  < L002048 11000010*
  < L002056 0000000000000000000000000000000000000000000000000000000000000000*
  < L002120 11000010*
  < L002128 0000000000000000110000001000000010000000100000000000000000000000*
  < L002192 10*
  < C1259*
  < 2dea
  \ No newline at end of file
  ---
  > L002048 11111111*
  > L002056 1111111111111111111111111111111111111111111111111111111111111111*
  > L002120 11111111*
  > L002128 1111111111111111111111111111111111111111111111111111111111111111*
  > L002192 11*
  > C23bd*
  > 2ec6
  \ No newline at end of file

  and 

  1c1
  <  Generated by Dataman-48 on Fri Oct 31 00:25:04 2025
  ---
  >  Generated by Dataman-48 on Fri Oct 31 00:17:03 2025
  68,74c68,74
  < L002048 00000000*
  < L002056 0000000000000000000000000000000000000000000000000000000000000000*
  < L002120 00000011*
  < L002128 0000000000000000110000001111000010000000100000000000000000000000*
  < L002192 10*
  < C1ed7*
  < 2e93
  \ No newline at end of file
  ---
  > L002048 11111111*
  > L002056 1111111111111111111111111111111111111111111111111111111111111111*
  > L002120 11111111*
  > L002128 1111111111111111111111111111111111111111111111111111111111111111*
  > L002192 11*
  > C2ff3*
  > 2f1a
  \ No newline at end of file

  I haven't found a fuse map for the GAL16V8CZ yet.

  I retried programming with the Dataman set to device ATF16V8C, and the devices programmed and verified without problem.

  The Z suffix relates to "zero power" mode parts. Perhaps Dataman did not get round to implementing those fuse bits?

• Casing

  Keith • 10/04/2025 at 14:42 • 0 comments

  The PCB itself is 4 x 4 inches, and fitted in a custom Bend-And-Fold box (aka BAFbox). 

  This is slightly larger than will fit in the off-the-shelf extruded cases for 100 mm Eurocards.

  I suggest that the new board be resized to 100mm square, to allow the use of such cases. And also that the audio connectors are moved to so they stick through the endplate, instead of the side which is harder to drill through.

  See https://www.farnell.com/datasheets/1933057.pdf

  Not cheap at £30 each but cheaper than the time spent trying to find or make alternatives. If you fit a silicon disk in the same box, 

  IDC sockets are £5.80 each from Farnell. Two needed per kit, or 3 if you allowed for Silicon disk on same cable.

  60-way boxed headers are £2.67 from Farnell.

  A right-angle header with ejector lugs is £1.33 from Farnell.

• Component placement

  Keith • 09/26/2025 at 18:06 • 0 comments

  The part numbering corresponds to the Memotech circuit, the extra parts are numbered by me.

  Diagrams by Lee Bendall.

  Major components:

  Minor components:

  In another board photo, there is another resistor, between IC2 and IC9. I presume it was found redundant, and removed.
  

• Discrete logic analysis

  Keith • 09/25/2025 at 23:17 • 0 comments

  To do this methodically, I made a spreadsheet listing every pin of every logic chip that was not in the I/O mapped RAM and PAL chip circuit. The traced them with a multimeter. 

  Some chips have obvious functions. The 74LS175 is a 4-bit output port and the 74LS125 is a 4-bit input port.  Both are wired to D0-3. There will be bits for tape output and buzzer, and tape input. What the other bits do I don't know, or care much.

  There's some logic made of discrete gates (LS32, LS74, HC14), and even a 4-input OR gate made of four diodes. 

  Tape output seems to be just a 1% resistor divider, so 2.8 volt TTL out becomes 28 mV audio.

  Tape input seems to be just an RC filter into a CMOS Schmitt trigger. You'll have to turn the volume up to TTL levels, because there is no amplifier circuit. Not even a single transistor. But that is consistent with Sinclair cheapness.

  The RC delay on the /WR signal suggests a nasty hack to give noisy input signals more time to settle down before writing data to the RAM. 2k2 * 68p is ~ 150 ns time constant.

  The interrupt pulse signal lengths are 560p x 47k = 26 microseconds time constant. This is ten times the Memotech time, if its 56p capacitors are to be believed.

  Some of the logic seems odd, or redundant. This might just be defensive design, in case things have to be thrown out of the PAL chips. Again, I don't care much so so long as it works. There might be a market for maybe 15 units, and that would be 3/8ths of the Einstein Facebook group!

• Kitting list

  Keith • 09/24/2025 at 13:07 • 0 comments

  Lee Bendall wishes to make 15 kits, so he has ordered 15 buzzers and 30 ATF16V8 chips from China. The latter are coming to me for programming. These were chosen because they are reprogrammable, so if the kits don't sell then they can re-used for something else.

  Everything else is common TTL, passives, and connectors. I think I have many spare 74LS74 chips etc. in my junk box.

  2025-10-07

  RAM chips, buzzers and GAL16V8 chips arrived. The latter in a non-ESD-safe plastic bag surrounded by bubble wrap. The eBay vendors in China are not engineers, that's for sure! I hope there are not many bent pins in there.

  I have ordered some conductive foam for storing chips safely.

• Copying the PAL14L4 chips

  Keith • 09/12/2025 at 12:59 • 0 comments

  The first way to do this is for me to read their fuse maps directly using my old Dataman device programmer. 

  The PAL14L4 has no security fuse, so this would be straightforward.

  However, most people are very reluctant to post essential and irreplaceable components to strangers on the web.

  A way round this is to wire the 14L4 chips to an EPROM socket like so:

  The 10L8 appears as a 1k x 8 bit ROM.
  The 12L6 appears as a 4k x 6 bit ROM.
  The 14L4 appears as a 16k x 4 bit ROM.
  The 16L2 appears as a 64k x 2 bit ROM.
  The 16L8 is trickier, because 6 pins can be either input or output. But that's a problem for another project.
  

  Reading the device like a ROM, the addresses will go through every possible combination of inputs, and the outputs read. 

  From this information, one can deduce the logic.

  2025-09-17 15:30

  The physical Speculator arrived in the post!

  I made a spreadsheet of the connections of the PALs, RAM and host connector.

  With this information, I read the PAL chip fuse maps, which I then converted to equations, and then edited the equations to have their proper pin names.

  It looks like the RAM is permanently enabled, which I would expect to clash with other I/O devices.

  Also, RA1 and RA0 seems to be fixed, and RA2 priority-encodes only 4 out of 8 possible keyboard columns.
  That is all it can do, because it can only encode four OR-terms.
  

  However, so long as the board actually works, I shan't bother working out why.

  The GAL16V8 can have up to eight OR terms per pin, in non-tristate mode, so a full 8-bit priority encoder can be implemented.

  There are six TTL chips, where the Memotech version only had two.

  2025-12-02

  Creating the GAL chips and comparing their behaviour with the PAL chips showed that my device reader had not read the fuses for pins 14 and 15 (see other log). Today I tested five known-blank PAL16L4CN chips, and they all read bank as non-blank. Again, the fuses for pins 14 and 15 were read as blown. So I have to conclude there is a fault with my reader, not the chips.

View all 8 project logs