11/03/2023 at 03:49 •
I've looked at this board and there are eight PAL chips, one of which is registered, which I feel is too much effort to reverse engineer for 4 MByte of DRAM and a SCSI interface. It could be largely replaced by eight 512K byte SRAM chips.
It uses 256k x 4-bit DRAM, which you can add four at a time. The kind of applications that require a lot of RAM are better served by a modern PC with at least a thousand times more RAM (over 4 GB) and faster with it.
I read that the SCSI interface is faster to use directly than asking an 8 MHz Z80 slave to do the work. But then it is probably simpler, cheaper and faster to bit-bang an SD card interface. The main reason for a SCSI interface is to extract data from SCSI drives, which are rare and expensive these days.
10/23/2023 at 23:43 •
U8 ("ZPAL") - the glue logic for the onboard Z80 microcomputer
The Z80’s memory map is as follows
0000H-5FFF H:ROM 6000H-7FFF Common RAM bank H: 8000H-FFFF Switching RAM bank H:
So that the Z80 may access all of the possible 64 kbytes of RAM whilst still reading from the ROM, the RAM is split into two 32k halves.
Only one of these halves may appear in the top 32k of address space at a time. When the ‘BANK’ signal is low the data in RAM0 (IC1) is accessible in this address range; when ‘BANK’ is high the data in RAM1 (IC2) is accessible.
If 8 kbyte RAM chips are loaded in the board then only the first 8 kbytes of this 32k address space are useful. The first 8 kbytes of RAM is always accessible in the common bank. The ‘MAP’ signal is not used at present.
The Z80’s I/O port address map is as follows:
Address Name Function 00H PORT Read only input port. 08H LATCH Read/write disk select latch 10H ZINTS Write: interrupt the 1616. 10H ZCLRINT Read: clear pending Z80 interrupt. 18H SDATA Read/write 1616 communications port. 20H SCSIBASE SCSI controller base address 40H FDCBASE Floppy disk controller base address. 60H SCCBASE Serial communications controller base address.
The input port enables a Z80 program to determine the level of the following signals:
Bit 0: The ‘SCOMMAND’ signal is set when the byte from the 1616 which is currently held in the receive latch is a command, meaning that the MC68000 put the data there by writing to its ‘SCOMMAND’ output port.
Bit 1: The ‘ZRXRDY’ signal is high if there is a data or command byte from the MC68000 within the receive register.
Bit 2: The ‘ZTXRDY’ signal is high if the 1616 has read the previous byte out of the transmit register.
Bit 3: This signal determines whether the Z80 is to enter its normal operating mode or to execute its diagnostic test mode.
Again, does not look difficult.
10/23/2023 at 23:42 •
U24 ("SPAL") - the expansion bus interface logic
Pins 1 and 2 go low at the I/O space (A23 to A8 are high). A7-A1, R/W, and /LDS are basic 68000 signals.
The manual states that the memory map looks like this:
$FFFFFC1 R/W ZDATA Read: Data from Z80. Write: Data to Z80. $FFFFC3 Read SCLRINT Clear 1616 interrupt. $FFFFC3 Write SINTZ Interrupt Z80. $FFFFC9 Read SRXRDY Bit 7 set if receive latch full. $FFFFCB Read STXRDY Bit 7 set if transmit latch empty. $FFFFCD Read ZCOMMAND Bit 7 set if contents of the receive latch is a command. $FFFFD1 Write SCOMMAND Write data to the data latch, set SCOMMAND bit.
The PAL multiplexes SRXRDY and STXRDY onto SD7.
Basically the two processors communicate through two 8-bit latches.
This all looks pretty simple to implement.
The binary behaviour data seems wrong, because pin 18 is listed as an input when it should be an output.
So I just had a quick go at deducing the logic by reading the manual and the circuit.
10/23/2023 at 23:23 •
IC5, VPAL, Video
VIDEO_CLK is simply half the 15 MHz clock frequency. The PAL can work in two modes.
In 640-pixel wide mode, two bits from the shift registers (VD1, VD0) are fed to T0-1 to drive a 2-bit-address 4-bit-data look-up table, acting as a colour palette.
In 320-pixel-wide mode, VD1, VD0 are shifted into RED, GREEN, BLUE and INTENSITY.
BC0-3 is the Background Colour.
An LS157 multiplexer (IC3) selects either the RGBI bits from the PAL (IC5) or the palette (IC4). ENPAL selects which.
I don't think this would be very hard to reverse engineer. The worst case is that wrong colours appear on the screen, which won't harm the 1616 hardware and would usefully indicate what is going wrong.
10/23/2023 at 23:20 •
IC15, TPAL, Timing PAL
We can see that pins 19,18,17 are a simple clocked counter. Other signals control DRAM, and other designs might provide a starting model. The RAM is interleaved VDU/CPU access, so the DRAM signals may only begin just after the VDU phase has finished.
I suspect that this forms a state machine with 8 states per memory cycle, and generates a fixed sequence of DRAM access signals from those states. Which makes sense, because the 6845 does not do that. I also suspect it generates the same sequence for CPU access, but simply making the CPU wait until it is complete.
Scoping the signals would give a good idea of the DRAM signals to be created.
Alternatively, you might be able to tell the PAL it is doing video cycles, and then record the state of the output pins as it is clocked. Pins 17, 18 and 19 are going to cycle through states 0 to 7, and the DRAM control signals should change at the same states throughout an 8-state memory cycle.
It is worth noting that the microprocessors of the 1980s all ran at pretty much the same memory cycle rate. A 1 MHz 6502 had 1 clock per memory cycle, a 4 MHz Z80 had 3 or 4 clocks per memory cycle, and an 8 MHz 68000 had 8 clocks per memory cycle. All of these would have around the same 1 MHz memory cycle rate.
If you get the DRAM signals wrong, the computer will crash straight away, so I doubt it would have time to do any damage to the 1616. You could make a small gadget that turns off the 1616 if does not run some code that disables the gadget in time. This would prevent the 1616 running for any significant length of time with a non-valid DRAM interface.
The 68000 memory read cycle
... looks like this:
So I would expect a /RAS signal to be similar to /AS, with /CASU and /CASL to resemble /UDS and /LDS respectively.
The DRAM control signals will be a function of the signals on pins 17 to 19.
To find the timing, one would have to tell the PAL it is in video cycles (using DISPEN?) and then toggle the clock (pin1) and record the state of the outputs as they cycle through eight states.
This can be done at human speed, just by applying a debounced pulse on pin 1.
Until that gets done, I will look for existing 68000 DRAM interfaces. This is hard to find, as it is not the sort of thing people tackled unless they were a big company. However, I did find a book that covered the subject in great detail:
68000 hardware, software, and interfacing by Allan Clements.
After much text about DRAM in general, it presents a 68000 to DRAM timing diagram on page 390:
This provides a good starting point where there is only one DRAM access per CPU cycle. /AS is effectively /RAS and /DS is effectively /CAS.
For interleaved video/CPU access, the CPU DRAM access must be crammed into the second half (S4-7) and the video access crammed into the first half (S0-3).
Example timings are hard to find. This sort of thing goes on in the 1616, the Apple Mac, the Atari ST, the Commodore Amiga, The Sinclair QL.... but manufacturers were not keen on disclosing such details.
I eventually found some timings from some files salvaged from Atari after they went bust. Here is the timing of one of their chips:
For the 1616, the signals "MHZ16" and "MHZ8" would be the 15 and 7.5 MHz clocks respectively.
The MHZ8 signal has the numbers 0 to 7, representing the 68000 CPU states S0 to S7.
The Atari ASIC derives timings by shifting a 2 MHz square wave through an 8-bit shift register at 32 MHz. This makes it easy to decode timings with very little logic. For instance:
/SLOAD = TIME2 * /TIME6 ; /* a NAND and NOT gate for single pulse */ LATCH = /TIME2 * TIME6 ; /RAS = TIME0 * /TIME5 + /TIME0 * TIME5 ; /* a XOR gate for double pulses */ COL = TIME1 * /TIME5 + /TIME1 * TIME5 ; /CAS = TIME2 * /TIME7 + /TIME2 * TIME7 ; CLK4 = /TIME3 * /TIME7 + TIME3 * TIME7 ;
The 1616 TPAL derives timings by using its 30 and 15 MHz inputs and a 3-bit synchronous counter. That gives 5-bit resolution, same as the Atari. Other logic generates the ROW/COL signal (just delayed /RAS ?).
So it is looking very possible to generate Atari timings in a 1616 GAL chip. This can then run in parallel with an original 1616 chip and the signals compared. The logic can then be tweaked until they are identical.
I have made a spreadsheet to confirm the logic above.
The actual circuit and timings are shown here: Atari_timing_from_ASIC_ST4081S_page_7,8,48,49.pdf
The shift register is simple and economical of silicon chip area, but the 1616 timing PAL16R8 has to use three pins for a 3-bit counter in order to have five pins left for control outputs. If it is a simple binary counter, multiple bits may change on the clock edge. So any logic derived fed by them must be clocked to avoid glitches, but the 16R8 can provide that.
The PAL does not have to generate the row/column select signal, as this is simply /RAS delayed by one clock cycle in U50b.
I've just found a timing diagram for the Apple Lisa:
The RAS and CAS signals have very similar timings. High for 3 dot clocks and low for 5. The CAS signal is RAS delayed by 2 dot clocks.
Looking at the Texas 4164 datasheet page 9, and the 200ns access time device, the minimum times for RAS high and low are 120 and 200 ns respectively, which is in the ratio of 3 to 5. That device has a read cycle time of 330 ns, which is fast enough for 500ns of a 2 MHz cycle rate (twice the 1 MHz cycle rate of a 68000 clocked at 8 MHz).
For a 16 MHz 68000, the cycle times are halved to 250ns. The 150ns 4164 has a cycle time of 260 ns which is 10ns longer but in practice devices are rated conservatively. They are not rated at their extreme limits. For the 150 and 120 ns devices, the RAS high:low times are 100:150 and 80:120 respectively, both having a ratio of 2:3.
Dividing 8 dot clocks in the ratio 2:3 give 3.2 to 4.8. So 3:5 is still the nearest integer ratio. For a 16 MHz CPU clock, and 250 ns memory cycle, RAS high:low would be 93.75 : 156.25 ns, which a 150 ns part might manage and a 120ns part would be within spec.
I conclude that the RAS and CAS timing for the Atari and Apple Mac should suit the Applix 1616.
10/22/2023 at 18:06 •
The 1617 is a SCSI and Floppy drive controller board.
Fortunately the PAL chips are purely combinatorial PAL16L8.
Their output patterns have been read.
10/22/2023 at 00:17 •
These devices are the only things standing in the way of the 1616 being a fully open source design.
Alas they had their security bits programmed, and the designers have lost the original source files.
From the circuit diagram, we can read the functions and the signal directions.
ChipTester V2 Pro says it analyses registered PAL chips. Yes it does, but only in the same way as it analyses combinatorial chips. Cefiar's binary files have 256 identical bytes, which suggests it did not do any clocking at all. The results are effectively useless.
What is needed
... is a gadget to apply clocked test sequences and examine the results. If one knows nothing about a PAL, one has to apply very many test sequences and a great deal of analysis. I think I recall someone trying to do this with a fairly powerful microcontroller, and eventually concluding it would need something based on an FPGA to do it fast enough.
If one knows something about the PAL, such as the input and output pin functions, one can make intelligent guesses and cut down the work greatly.
One way to test if two chips work the same (without damaging the host board) is to run them in parallel with the same input signals, and then compare their output signals. This requires building a PCB that holds both chips and plugs into the original socket. Comparison can be done visually by comparing scope traces, or XOR gates. The latter will have many fine glitches but at least show how much outputs differ.
This will be a slow process if PALs are shipped from the UK to Australia.
An alternative is to ship a GAL programmer and email test patterns for the recipient to program and test.
10/21/2023 at 15:06 •
Stuart is restoring a 1616 machine and documenting his progress at:
He has read the PAL chips using a ChipTester V2 Pro from BackBit.io and I eagerly await looking at them. I don't know whether the security bits were blown or not. If they were, one can only make a best guess by examining the behaviour.
There is a project that tries to dump PAL contents. Easily done for combinatorial chips, less so for registered chips.
I don't know how clever it is, or how reliable the output.
Worst case, I could make a best guess replacement and ask Cefiar to try them out.
His system has:
- 1616 processor motherboard
- SCSI and Memory Expansion board
- Two intelligent Z80-based Floppy Disc Controller boards
Both SCSI and floppy discs are obsolete, and I am not very motivated to reverse engineer the PALs although they should be fairly simple to do.
The motherboard PALs are registered and harder to reverse engineer. I can't scope his system (and nor can he) but I think I could make a good guess at the 68000 DRAM interface by scoping my Atari ST here.
10/02/2023 at 01:11 •