Does anyone have a theory for why my CPU280 believes disk volumes on an HxC diskette emulator are read-only? This seems to have come out of nowhere. I have CP/M A: and C: mapped to the A & B drives on the emulator and CP/M B: mapped to a physical 3.5" HD floppy. I can write to the floppy without problems but not to either of the HxC volumes. Definitely was working a few weeks ago.

Will just released a nice 3 slot ecb backplane a couple of months ago. It's listed on the wiki.

If you're looking for a full up backplane in a card cage, then I can't help you. Those always seemed way more expensive than they should be. Or I really should say: way more expensive than I wanted to pay!

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

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

Nice to know that 258's can be subbed-in. I need to investigate that a bit better.

Question for anyone on the forum using 7.5 ns GALs successfully: Does your board have ACT158 or AS158 parts?

snhirsch_gmail.com wrote on Thu, 13 July 2017 13:42

Question for anyone on the forum using 7.5 ns GALs successfully: Does your board have ACT158 or AS158 parts?

I am using 7.5ns GALs (Atmel) along with 74AS158's very successfully.

Thanks for the data point, Wayne. While I'm happy that my board is functional I hate a mystery. Would be great to understand why the fast GALs proved so problematic in my case.

I always wondered what happened to Zedux. IIRC, they put out advertising referring to a family of OS components and development tools targeted at Z280, but disappeared off the face of the earth without shipping anything. If Mr. Moore has any of this stuff still in his collection it would be great to have.

After an I/O instruction, if there was a branch instruction within three
instrucrtions (the time it took to flush the pipeline) then the addess
that made it to the package pins would actualy be the I/O address, not
the instructin address. Naturaly that lead to a very dramatic crash.
They never diod fix that one, but it was pretty easy to avoid if you
watched that. (From the March 2001 comp.os.cpm thread referenced above)

Tilmann references an 'OUTJMP' program in his software manual..... but I have not located this program. It's certainly not in any of the files I received from Tilmann, nor do I find it on Fritz' oldcomputers.dyndns.org archive. Sounds like an opportunity.

program Out_Jump_Check;

(* 300391 Tilmann Reh *)

const signon = ^m^j'OUT/JMP-Tester V1.0  TR 300391'^m^j;

(* Dieses Programm sucht in CP/M-Programmen (.COM) nach Befehlssequenzen
aus einem Output-Befehl und einem 'Program Flow Change' Befehl (zB CALL/JMP).

Laut Errata Sheet zum Z280 koennen Fehler auftreten, wenn nach einem
'external write with wait states' ein Befehl ausgefuehrt wird, der die
Pipeline des Prozessors loescht. Bei der CPU280 ist Erstgenanntes nur bei
I/O-Write (d.h. OUT) moeglich. Ausser bei CALL und JMP wird die Pipeline
auch bei PCACHE und LDCTL geloescht, wobei LDCTL privilegiert ist und
daher hier nicht ueberprueft werden muss (kommt nur im BIOS vor). RETurn-
Befehle sind bei externem Stack (also bei der CPU280 generell) unkritisch.

Das Programm OUTJMP untersucht Dateien auf das Auftreten solcher 'verbotenen'
Sequenzen und zeigt diese sowie deren Adresslage an. Zu untersuchen sind
nur Programme mit direkter I/O-Ansteuerung, also i.A. Programmiersoftware
fuer EPROMs/PALs und dergleichen sowie Kommunikationsprogramme. Nicht alle
angezeigten Sequenzen muessen tatsaechlich die entsprechenden Befehle
darstellen (es koennen z.B. Datenfelder fehlinterpretiert worden sein).

Werden Sequenzen gefunden, so ist zunaechst zu pruefen, ob sie richtig
interpretiert wurden. Ist dies der Fall, sollte das Programm derart
gepatcht werden, dass zwischen den beiden Befehlen mindestens ein
'normaler' Befehl, am besten ein IN-Befehl, ausgefuehrt wird. In den
meisten Faellen wird dies nur durch Auslagern der Sequenz in ein Mini-
Unterprogramm moeglich sein. 

Translated by google and fritz (maybe not always correct).

This program looks for command sequences in CP/M programs (.COM)
From an output command and a 'Program Flow Change' command (eg CALL / JMP).

According to Errata Sheet to the Z280 errors can occur if after a
'External write with waitstates', a command executing the command is executed
Pipeline of the processor. In the case of the CPU280 the former is only at
I/O-Write (i.e., OUT). Except for CALL and JMP is the pipeline
also deleted with PCACHE and LDCTL, whereby LDCTL is privileged and
so it does not have to be checked here (comes only in BIOS). Return-
Commands are not critical in the case of an external stack (ie, CPU280 in general).

The OUTJMP program scans files for the occurrence of such 'forbidden'
Sequences and displays these as well as their address. To be investigated
only programs with direct I / O control, ie i.A. programming software
for EPROMs / PALs and the like as well as communication programs. Not all
Displayed, the corresponding commands must actually be
(For example, data fields may have been misinterpreted).

If sequences are found, first check whether they are correct
Were interpreted. If this is the case, the program should be so
Be patched between the two commands
'Normal' command, preferably an IN command. In most cases this is only done 
by outsourcing the sequence into a mini-Subroutine.
*)

(* Tabellen aller denkbaren OUT-Befehle (ausser D3xx) *)
(* Table of all possible OUT-Commands (without D3xx) *)

type  bs       = set of byte;
const out_ed   : bs = [$41,$49,$51,$59,$61,$69,$79,$83,
                       $8B,$93,$9B,$A3,$AB,$B3,$BB,$BF];
      out_dd   : bs = [$49,$51,$59,$61,$69];
      out_dd_n : bs = [$41,$79];
      out_fd   : bs = [$61,$69];
      out_fd_n : bs = [$41,$49,$51,$59];

(* Tabellen aller denkbaren CALL/JUMP-Befehle (ausser E9) *)
(* Table of all possible CALL/JUMP-commands (without E9) *)

      calljump : bs = [$CD,$C4,$CC,$D4,$DC,$E4,$EC,$F4,$FC,
                       $C3,$C2,$CA,$D2,$DA,$E2,$EA,$F2,$FA];
      cj_dd    : bs = [$CD,$C4,$CC,$D4,$DC,$E4,$EC,$F4,$FC,
                       $C2,$CA,$D2,$DA,$E2,$EA,$F2,$FA];
      jumprel  : bs = [$10,$18,$20,$28,$30,$38];
      jafjar   : bs = [$20,$28];

(* vorbelegte Variablen *)
(* defined variables *)


      start    : integer = $100;  (* Startadresse *)
      ende     : integer = 1023;  (* letzes zu untersuchendes Byte *)

(* Variablen des Programms *)
(* program variables *)

var filnam     : string[20];
    f          : file;
    buf        : array[0..1151] of byte;  (* 9 records *)
    i,j,secs   : integer;

(* Ausgabe von Bytes und Worten hexadezimal *)
(* output of Bytes and words in hex *)

procedure hex_byte(b:byte);
const nyb : array[0..15] of char = '0123456789ABCDEF';
begin
  write(nyb[b shr 4],nyb[b and 15]);
  end;

procedure hex_word(w:integer);
begin hex_byte(hi(w)); hex_byte(lo(w)); end;

(* ALARM: Ausgabe von Adresse und Objektcode der gefundenen Sequenz *)
(* ALARM: Output from address and object code found sequence *)


procedure alarm(laenge:integer);
var x : integer;
begin
  if eof(f) and (pred(j+laenge)>ende) then
    if j<=ende then write('begonnene ') else exit;
  write('Sequenz bei '); hex_word(i+start);
  write(' :');
  for x:=i to pred(j) do begin write(' '); hex_byte(buf[x]); end;
  write(' -');
  for x:=j to pred(j+laenge) do begin write(' '); hex_byte(buf[x]); end;
  writeln;
  end;

(*--------- MAIN ----------*)

begin
  writeln(signon);
  if paramcount=0 then begin
    writeln('Aufruf: OUTJMP filename (Default Extension .COM)');
    halt; end;
  filnam:=paramstr(1);
  i:=pos('.',filnam); if i=0 then filnam:=filnam+'.COM';
  assign(f,filnam);
  {$I-} reset(f); {$I+}
  if ioresult<>0 then begin
    writeln('Datei ',filnam,' kann nicht ge|ffnet werden!');
    halt; end;

  blockread(f,buf,9,secs);
  if secs<8 then ende:=pred(secs shl 7);
  repeat
    for i:=0 to ende do begin
      j:=-1;
      if buf[i]=$D3 then j:=i+2 else
      if (buf[i]=$ED) and (buf[succ(i)] in out_ed) then j:=i+2 else
      if (buf[i]=$DD) and (buf[succ(i)]=$ED) then begin
        if (buf[i+2] in out_dd) then j:=i+3 else
        if (buf[i+2] in out_dd_n) then j:=i+5 end else
      if (buf[i]=$FD) and (buf[succ(i)]=$ED) then begin
        if (buf[i+2] in out_fd) then j:=i+3 else
        if (buf[i+2] in out_fd_n) then j:=i+5 end;
      if j>=0 then begin
        if buf[j] in calljump then alarm(3) else
        if buf[j] in jumprel then alarm(2) else
        if buf[j]=$E9 then alarm(1) else
        if (buf[j] and $DF=$DD) and (buf[succ(j)]=$E9) then alarm(2) else
        if (buf[j]=$FD) and (buf[succ(j)] in calljump) then alarm(4) else
        if (buf[j]=$DD) then begin
          if buf[succ(j)] in cj_dd then alarm(2) else
          if buf[succ(j)] in jafjar then alarm(3) end else
        if (buf[j]=$ED) and (buf[succ(j)]=$65) then alarm(2);
        end;
      end;
    move(buf[1024],buf[0],128);
    blockread(f,buf[128],8,secs);
    if secs<7 then ende:=127+(secs shl 7) else ende:=1023;
    start:=start+1024;
  until ende<128;
  end.

I used the CPU280_144.img posted here some time ago and works fine, although is missing most of CP/M 3 utilities like STAT and SHOW.

Just finished my board last weekend (well, almost: still is missing the 9.6MHz xtal which should arrive mid-September). Since the crystal is not needed except apparently for some 5.25" drives, I decided to do a quick test and powered up the board. It worked immediately, no RAM or communication issues!...

Thanks. Downloaded the disk images, tried the CPM3 one and is working OK, only the FDC access seems very slow. Anybody else got the same feeling? Even my old P112 when clocked a half speed (8 MHz) copies files faster. Disks are formatted with 2:1 interleave, formatting the floppy with the P112 makes no difference.

Thanks. Downloaded the disk images, tried the CPM3 one and is working OK, only the FDC access seems very slow. Anybody else got the same feeling? Even my old P112 when clocked a half speed (8 MHz) copies files faster. Disks are formatted with 2:1 interleave, formatting the floppy with the P112 makes no difference.

Thanks. Downloaded the disk images, tried the CPM3 one and is working OK, only the FDC access seems very slow. Anybody else got the same feeling? Even my old P112 when clocked a half speed (8 MHz) copies files faster. Disks are formatted with 2:1 interleave, formatting the floppy with the P112 makes no difference.

At first, I was a
bit disappointed about the relatively slow disk performance,
there are faster BIOSes, yes, but then I agreed to Tilmann's
arguments of absolute data integrity, which resulted in a double
verify. After switching off the copy verifies in ZFILER and
other copy programs, I found the speed to be equivalent to disk
I/O on my 386SX.

Part of the issue with writes being slow is a Z280 bug that causes weird hangs on DMA output; while there is a workaround implemented in the BIOS code, a read-after-write is still done. This is definitely more efficient at 1K sector sizes, but, as Wayne mentions, that makes it more difficult for a PC to read and write the disks.

Just looked at the code, and indeed there is a 'VerTry' equate in diskio.280 that controls the number of verify-after-write operations, and which is set by default to 1. That probably made more sense back in time when floppies were not known for being reliable; they got much better after the introduction of the 3.5" disks with their hard shell and sliding door mechanism that protected the magnetic surface against bend damage, fingerprints and dust.

Note that the verify-after-read has nothing to do with the Z280 DMA bug, as there is a separate check for that. And, if I understand well the code, once the bug happens then the workaround is always applied; the 'cure' consisting of writing 4 null words to the non-existing I/O address FFxxE8. With such a short code, I wonder if further write operations will be slowed down at all.

I will change my copy of the BIOS and test again the performance. Perhaps it will make sense to release the standard distribution with verify-after-read disabled? After all, PIP has already a switch to force verify-on-copy.

I'll have to think about whether I want to distribute EPROMs with verify turned off. I for one am more concerned about data integrity than performance, but I respect the fact that others may have different priorities. You are of course free to rebuild with any options you want. Wayne is of course free to distribute the code from github with the options enabled that he wants, too.

How does the rest of the group who are running CPU280's feel about this?

A good analysis overall, but I will mildly disagree with the assertion that 3.5 HD media is more reliable than older media; I typically have more trouble reading old 3.5 HD disks than I do reading some really old 5.25 DD disks, and 8-inch disks have the best reliability record of all.

Perhaps I was mistaken as to the cause of the need to verify after write. It seemed reasonable to me that if the DMA error interfered more with HD writes than with other things that such an error could be cause to verify those writes.

It would be nice if some of these options could be rolled into a configuration setting or could be jumper-selectable; just some code for someone to write.

lowen wrote on Fri, 01 September 2017 05:33

A good analysis overall, but I will mildly disagree with the assertion that 3.5 HD media is more reliable than older media; I typically have more trouble reading old 3.5 HD disks than I do reading some really old 5.25 DD disks, and 8-inch disks have the best reliability record of all.

Interesting... Not a single of my 5.25" disks survived to this day, and the 360K SD were the ones to go bad first. Of the 3.5" disks, about 80% survive and are still readable. I suspect in my case environmental conditions played a role (I used to live next to the sea where moisture/corrosion was an issue for both disk and drives).

lowen wrote on Fri, 01 September 2017 05:33

It would be nice if some of these options could be rolled into a configuration setting or could be jumper-selectable; just some code for someone to write.

That would be nice indeed, and not that difficult to implement (at least via jumper). That would be a relief for those users who do not have an UV eraser and/or an EPROM programmer.