I finally figured out how to convert a CPU280 diskette IMG file to HFE (for HxC diskette emulator) with a sector interleave of 2. Use the 'Load Raw Image' option in the GUI tool and set things thusly:

FYI: It does appear that fast GAL parts can be problematic. I originally used Lattice 16V8 7ns parts in all four locations and found that the board was unable to count the full memory complement until it had been on for about 10 minutes or was run at reduced voltage. Suspecting a race condition, I replaced the CAS GAL with a National 16V8 15ns part. The problem is gone. It now counts all 2048k from a cold start at full voltage. It's possible my unit is an outlier, but it might be worth advising future builders to stick with 15 ns devices. Digikey and Mouser don't appear to stock the slower devices, but they are available from Unicorn Electronics. I've found Unicorn to be a great source for ICs. They stock all but one of the parts on the CPU280 BOM (I had to pickup the 74AS158s from DigiKey).

snhirsch_gmail.com wrote on Sat, 27 May 2017 20:23

I finally figured out how to convert a CPU280 diskette IMG file to HFE (for HxC diskette emulator) with a sector interleave of 2. Use the 'Load Raw Image' option in the GUI tool and set things thusly:

Great work. So you can define your own format I believe.

I, in my case, did mostly the easier way reading a floppy disk with IMD or Teledisk as the HxC tool can work with those images.
As I use the HxC seldom I must read the documentation again.

snhirsch_gmail.com wrote on Sat, 27 May 2017 06:55

FYI: It does appear that fast GAL parts can be problematic. I originally used Lattice 16V8 7ns parts in all four locations and found that the board was unable to count the full memory complement until it had been on for about 10 minutes or was run at reduced voltage. Suspecting a race condition, I replaced the CAS GAL with a National 16V8 15ns part. The problem is gone. It now counts all 2048k from a cold start at full voltage. It's possible my unit is an outlier, but it might be worth advising future builders to stick with 15 ns devices. Digikey and Mouser don't appear to stock the slower devices, but they are available from Unicorn Electronics. I've found Unicorn to be a great source for ICs. They stock all but one of the parts on the CPU280 BOM (I had to pickup the 74AS158s from DigiKey).

Different PLD speeds could certainly make a difference, but note that I have been using 7.5ns Atmel devices from the start and my system has always been rock solid. No doubt a combination of tolerances, but I would not conclude that 15ns PLDs are the answer as a general rule.

-Wayne

As I said, I'm not an electrical engineer nor a computer designer. All I know is that my symptoms were characteristic of a timing violation and the slower parts solved it. Just out of curiosity, what brand and speed of memory are you using on your board?

snhirsch_gmail.com wrote on Sun, 28 May 2017 08:13

As I said, I'm not an electrical engineer nor a computer designer. All I know is that my symptoms were characteristic of a timing violation and the slower parts solved it. Just out of curiosity, what brand and speed of memory are you using on your board?

Toshiba, 60ns

Wayne W wrote on Sun, 28 May 2017 09:07

snhirsch_gmail.com wrote on Sun, 28 May 2017 08:13

As I said, I'm not an electrical engineer nor a computer designer. All I know is that my symptoms were characteristic of a timing violation and the slower parts solved it. Just out of curiosity, what brand and speed of memory are you using on your board?

Toshiba, 60ns

Ah, that may be why your board works with 7 ns. parts! My original memory was 80 ns, resulting in a machine that barely would boot after considerable warmup. Lamar sent me 70 ns. memory, which worked quite a bit better although still required warmup to recognize all the memory. Moving to the slower GAL brought the 70 ns parts to full life. If I had 60 ns it might have been fine with the 7 ns GALs.

• Do not use disk capacitors for power supply bypass. They create clearance issues in several locations due to their height. Even if they don't directly interfere, they make it next to impossible to work a screwdriver under the adjacent chip for extraction.
• The BOM (spreadsheet) called for SIL six pin resistor networks at RN2 and RN6 with a note to "Cut off extra pin / resistor". Cutting the resistor off fractures the ceramic package and cutting the pin leaves enough length to create significant clearance issues. If a five pin package is not available I suggest fabricating the networks from individual parts. Ditto for RN5.
• Jury is still out on the wisdom of using machined pin IC sockets. Their footprint is just enough larger to create clearance issues for bypass caps between sockets. I had to stack a second socket under both EPROMs and the Dallas DS1287 to lift them over the bypass caps and/or adjacent chips.
• A 34-pin header should be used for the floppy connection. I didn't think this through and mounted a 50-pin header on mine.
• A detail drawing is needed to explain polarity for both the tantalum caps and the LEDs. The screened symbols were hard to read and are not familiar (perhaps DIN standard).
• Must use 15 ns GALs (discussed in a recent thread of notes)_.
• Suggest socketing the ZIP DRAM packages.

Hopefully I'm one of the five, but if not please write me in for an IDE board. Also very interested in a VGA solution.

Is anyone using the Briel Pocketerm with their CPU280? For some reason, it is not sending a proper DEL character and I cannot access the 280 setup menu as a result. I've encountered this before with certain terminal emulation settings on ProComm. A solution or workaround would be great, since the Pocketerm is otherwise very convenient.

Thanks, Fritz. I was able to to hack the Propellor code to emit a 7FH and get into the setup screen successfully.

Unfortunately, I seem to have shot myself through the foot after that. I setup the CPU280 for hardware handshaking and reset it. And... It's dead. I see no memory test anymore and the third status LED stays lit. Something appears to have gone very wrong with the NVRAM setup in the Dallas clock chip. I tried installing jumper J10 (with power off), but that does not seem to work. Tillman's documentation does imply that only the 'A' version of the 1287 has that feature and I'm using an original 1287.

Does anyone know how I can recover from this?

Hi, Fritz.

How will a null-modem help towards clearing/resetting NVRAM? The CPU280 will not come up at all (third LED stuck on). Unless there's something I'm missing, the original DS1287 cannot be cleared easily. It's possible my current problems are unrelated to the CMOS setting (maybe the board just decided to drop dead on its own), but looks like I'll have to order a 12887A and give that a try.

Hi, Fritz.

UPDATE: Found a stash of DS12xxxx chips that I'd totally forgotten about! After a slight diversion with a DS12287 that caused the '280 to use some bizarre baud rate, I located another working DS1287 and am back in action. Very strange and more than a bit scary. I ordered a new DS12887A+ from Digikey so I'll have a means for recovery using the jumper if this happens again.

You are lucky again...

will you please disconnect your terminal cord and tell me what the CPU280 leds do after reboot?

Problems with your DALLAS - use your universal memory programmer

In the past I got some DS12887A+ without the pins for reset and just looked onto my memprog programmer.
The memprog is a small programmer but he can be used to programm the DALLAS too.

So if you have a programmer and some unusable DALLAS give them a try.

Hi All,

The good news: I've got my CPU280 board put together! The bad news: it needs a little debugging... :)
...

With all that sorted out, the board powers up, and outputs:

CPU280 Boot Loader V1.2 RBC 8-Mar-2017
http://www.retrobrewcomputers.org
based on Cold Loader Program V1.13 TR 950314
Press DEL to run SETUP.

Fatal Error: not enough RAM

:(

Additional Information

The board is drawing about 380mA.

The third LED stays lit, I assume because the RAM test doesn't pass.

I'm not 100% sure what kind of EPROMs lowen sent me,...

I've attached a picture of the mostly-completed board, but that image was taken before first powerup, so the jumpers might not be what I've described above.

I also tried to measure the /CAS pulse as the documentation suggested, using my analog scope; a picture of that is attached too. Sorry for the quality; wrong time of day and not enough hands. It looks like about 20ns, though, doesn't it? Is it clean enough? Square enough? There's also a /RAS pulse that's a bit wider than the /CAS pulse; I didn't get a picture of that one.

So... any thoughts on where I should start trying to debug this? I've poked around the DRAM refresh circuitry with both the scope and a logic probe, but I don't really know what I'm looking for. There's definitely a lot of "stuff" happening; most of the pins are changing state.

Suggestions welcome!

Hi, Fritz.

How will a null-modem help towards clearing/resetting NVRAM?

Sorry for the delay in replying; I had a wisdom tooth extracted Friday, so I took it easy over the long weekend.....

Thanks for the good writeup on your experiences with the serial ports; no, they aren't 9-pin AT standard (they are actually designed to line up with a 25-pin connector's first 10 pins according to the docs).

snhirsch_gmail.com wrote on Tue, 04 July 2017 11:40

Hi, Fritz.

How will a null-modem help towards clearing/resetting NVRAM?

With hardware handshaking, the code will block all output, including the banner that is printed prior to the memory test. The third LED won't get cleared until the memory test is complete, but it won't even start while the UART is stalled. The CPU280 code implements straight RTS/CTS handshaking; a true null modem will cross RTS/CTS as well as RXD/TXD and DTR/DSR/DCD (DTR on each end to both DSR and DCD on the other end). Without RTS/CTS crossed, you get a stalled UART. Simply connecting RTS to CTS on the CPU280 end should unstall the UART and let output proceed, which should let you rescue your DS1287 (this is what Fritz was correctly suggesting you do with a null modem).

There really needs to be a "failsafe" jumper to force the firmware back to defaults and allow graceful recovery from such mistakes. Fritz mentioned something about "User jumper", but I am not sure what that refers to. I tried shorting the first jumper at the bottom edge of the board but that didn't accomplish anything.

	
; Pruefen, ob waehrend RAM-Test eine Taste betaetigt wurde.    ## Test if during RAM-Check a key is pressed
; Bei DEL (oder geaenderter Checksum): Setup-Menu aufrufen.    ## if DEL or changed checksum call setup-menue

iopage	boardp
	in	a,(gpi)		; User-Jumper lesen  # read user jumper
	bit	b$uj1,a
	#################
        jp	z,boots1	; UJ1 gesteckt: ins Setup gehen (Defaults!)  ## if user jumper 1 is set goto setup
        ################
	ld	hl,(ChkSum)
	in	a,(CheckLo)
	cp	l		; Low-Bytes vergleichen  #compare low-bytes
	jp	nz,BootS	; verschieden: Setup!    #different -> setup
	in	a,(CheckHi)
	cp	h		; High-Bytes vergleichen #compare high-bytes
	jp	nz,BootS	; verschieden: Setup!    #different -> setup
	inchar			; inzwischen Taste betaetigt?   # was a normal key pressed ?
	jr	c,Boot		; nein: normal booten           # no: normal boot
	cp	DEL
	jr	nz,Boot		; nur bei DEL : Setup-Menu (sonst normal)  # only if DEL is pressed -> setup menue

snhirsch_gmail.com wrote on Tue, 04 July 2017

There really needs to be a "failsafe" jumper to force the firmware back to defaults...

What I have writen : Otherwise in loader.280 there is the check if user jumper UJ1 is set or if the checksum changed and then -> call setup...

Sorry for the delay in replying; I had a wisdom tooth extracted Friday, so I took it easy over the long weekend.....

First, great that it is together and a portion of the board is working fine (otherwise you wouldn't get any text at all). Thanks for the good writeup on your experiences with the serial ports; no, they aren't 9-pin AT standard (they are actually designed to line up with a 25-pin connector's first 10 pins according to the docs). I need to write that up better and put it on the wiki, along with a wiring diagram.....

Current draw is good, and yes the third LED doesn't go out because the RAM test didn't pass.

The good news is that the Z280's bus is good, the system and I/O address decode is good, the lower 16 bits of the address is properly latched, the EPROMs are good, the DS12887A is good, the clocking is good, and you have good UART and LT1134 RS-232-TTL shifters.

Now, the areas that could be bad:

1.) The RAM itself. I'll be glad to swap you four more chips. This is the easiest thing to troubleshoot and is the most likely culprit.

2.) IC21 (GAL16V8-RAM). I tested this chip prior to shipping, but it's always possible that it could have lost some of its programming.

3.) IC22 (GAL16V8-CAS4). I tested this chip prior to shipping as well. IC21 and IC22 together produce the majority of the DRAM control.

4.) IC30 and IC4. Together these chips provide the synchronous timing chain that drives the critical DRAM timing, with the base CAS pulse width being determined by R8 and C6.

5.) R8 and C6. Your scope's trace at 50ns/div makes the CAS pulse look a tad long, but it also looks pretty smeared; what bandwidth scope is that? CAS is supposed to be about 20ns.

6.) IC19 and/or IC20. The mux is the heart of any DRAM circuit.

The first step would be to swap RAM, and I'll be glad to send you four from my working CPU280 in exchange for those four.