Home » RBC Forums » General Discussion » Interested in a Z280 SBC (Z280 SBC retrobrew (CPU280 Revival))
() 1 Vote
|
|
|
|
Re: Interested in a Z280 SBC [message #3209 is a reply to message #3208] |
Mon, 10 July 2017 10:31 |
snhirsch_gmail.com
Messages: 63 Registered: May 2017
|
Member |
|
|
Heh, no offense taken. If I had a dime for every time I missed something that essential I'd be a wealthy man! But, in this case that does not seem to be the issue. It's probably worth my swapping the MicroSD holder out for another unit just in case the protect switch has gone flaky.
UPDATE: The good news is that I had the protect switch in the correct position. The bad news is that it had apparently failed per your comment! I subbed in another MicroSD holder and all is well. I think these things are built as cheaply as possible.
RE: IDE board. All the parts have rolled in and I'm anxiously awaiting a PCB so I can build it up.
I can borrow a Euro backplane from my YASBEC system but really should pickup another unit. Does anyone have a source / part number for a suitable backplane assembly?
[Updated on: Mon, 10 July 2017 11:02] Report message to a moderator
|
|
|
|
|
|
Re: Interested in a Z280 SBC [message #3213 is a reply to message #3160] |
Wed, 12 July 2017 20:02 |
sarah
Messages: 15 Registered: October 2015
|
Junior Member |
|
|
I'm pleased to report that my Z280 board now powers up properly and gets all the way through the RAM test!
My first attempt to find the problem was to pull all the chips, clean the board really well (to get all the "no clean flux" crud off), and inspect it very very carefully with a big magnifier. Then I used the schematic and a continuity checker to test all the connections in the DRAM circuitry. I didn't find any unexpected open circuits. Then I put the whole thing together again very, very carefully. And when I powered it up: same problem as before.
Okay, so probably not a PCB issue, probably not a solder joint problem. Maybe a bad logic chip? And... then I ran out of weekend, and started to think about what I might need for the following weekend's debugging session.
I vaguely recalled that one of the logic chips had come out of my "junk pile", but didn't remember which one it was. I decided to order a couple extra spares of each of the logic chips in the DRAM area just in case I needed to try swapping them, and because they're easier to get than the GALs or the DRAM. So I hit Digi-Key and started searching.
When I searched for the 74ACT158s... the multiplexer chips for the DRAM refresh... hmm, that's odd, they don't stock that one as DIP. I guess I must have ordered the 74AS158 instead? ...no, minimum quantity 250 for that one. That's weird. What's in my board? ... IC19 and IC20 are both... 74HCT158!?!? Hmm, maybe HCT isn't fast enough here? I checked the data sheets... yeah, that seems really plausible, the HCT part is much slower. How did the 74HCT158's end up in there??!?!
What I think happened was that the first time I was searching for the part, I couldn't find it, so I added the HCT version to my shopping cart, meaning to go back later and sort it out... and then promptly forgot about it. And then as I was putting the board together I just assumed I had already sorted all that out ahead of time, and just plugged the '158s in the right places, not checking for the appropriate logic families or considering any speed or timing issues.
Oops. It probably didn't help that I often wind up shopping for parts at 3am when I can't sleep.
This time around, I looked at the situation in a little more detail, checked the data sheets, and ordered a couple candidates that looked like plausible substitutes for the 74ACT158, one of which was the 74AS258.
The package arrived today, and this evening I pulled out the 74HCT158's and replaced them with 74AS258s... and the board came up on the first try, and passes the RAM test.
Sadly, all is not yet perfect in my Z280 world. While the serial output seems perfect, the serial input seems to be dropping 90% to 99% of the characters I type... which makes it quite challenging to get through the setup program! A quick check with a logic probe seems to suggest that the data isn't always getting from the LT1134 to the CPU; I'm not consistently seeing pulses when I type a character in the terminal program. I am seeing blinking lights on the USB to serial adapter, though, which suggests to me that the character is getting transmitted by the adapter but not being received at the CPU. I did try swapping USB to serial adapters, which didn't help. Hopefully, the serial cable I made is just a little flaky.
Once the serial port starts behaving itself, the next step will be to figure out how to wire up the floppy connector, I guess? One step at a time.
sarah wrote on Sun, 02 July 2017 21:09Hi All,
The good news: I've got my CPU280 board put together! The bad news: it needs a little debugging...
...
lowen wrote on Wed, 05 July 2017 07:316. IC19 and/or IC20. The mux is the heart of any DRAM circuit.
|
|
|
Re: Interested in a Z280 SBC [message #3215 is a reply to message #3213] |
Thu, 13 July 2017 13:42 |
snhirsch_gmail.com
Messages: 63 Registered: May 2017
|
Member |
|
|
Glad you got things going, Sarah! 74AS158s are listed as an alternative in Tillman's hardware documentation, and that's what I used in my board. Interestingly, I also had problems with the memory subsystem. In my case, moving to slower GALs (15ns - were originally 7.5) did the trick. I'm not a logic design expert, but my sense is this part of the circuit has a race condition that's triggered with certain component combinations.
Question for anyone on the forum using 7.5 ns GALs successfully: Does your board have ACT158 or AS158 parts?
[Updated on: Thu, 13 July 2017 13:44] Report message to a moderator
|
|
|
|
|
|
|
|
Re: Interested in a Z280 SBC [message #3280 is a reply to message #3229] |
Sat, 29 July 2017 08:45 |
|
lowen
Messages: 226 Registered: August 2016 Location: Western NC USA
|
Senior Member |
|
|
Update for 7/29/2017. All's quiet on the Western front.... (sorry, I couldn't resist).
I've been researching more (or maybe I should write 'moore') of the backstory on hobbyist-buildable or usable Z280 designs, and have come across a few real gems in the Google groups archives of comp.os.cpm, written by a man named Scott Moore. Scott Moore actually worked at Zilog on the Z280, and is as close to an expert on the chip that you will find. I have reached out to him to see if he's willing, after all these years, to write up some moore about the Z280 and his own experiences with the bugs of the chip. In the meantime, here are some subjects to put into your favorite comp.os.cpm archive search engine (Google groups or whatever) where Scott weighed in with very interesting information:
1.) March 7, 2001, subject line "ay REAL Altair users out there?" My favorite quote from one of Scott's posts: "You have of course asked for a story, which is a very dangerous thing to do when face to face with an old timer." Love it.
2.) November 11, 2006, subject line "Of interest: Project to put CP/M / Altair system on a single FPGA." This sounds remarkably like the socz80, but an Altair instead. Many good tidbits in that thread.
3.) December 10, 1987, subject line "CP/M Plus, Banked ZRDOS, Z280." We see a reference to Zedux, where much development on Z280 things was done by none other than Scott Moore.
If Scott replies to me and allows me to repost anything, I will do so. I want to hear (or read) what he has to say. I hope all of you reading the thread find this information useful and interesting.
--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!
[Updated on: Sat, 29 July 2017 08:47] Report message to a moderator
|
|
|
|
Re: Interested in a Z280 SBC [message #3282 is a reply to message #3281] |
Sat, 29 July 2017 11:17 |
|
lowen
Messages: 226 Registered: August 2016 Location: Western NC USA
|
Senior Member |
|
|
snhirsch_gmail.com wrote on Sat, 29 July 2017 12:47I 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.
I got a great reply, but I don't yet have permission to re-post anything. Suffice to say that the bugs in the chips along with some difficult timing issues prevented the product from seeing the light of day.
Likewise the TRX-280, I'm sure. The big bug that kept a Z280-in-an-otherwise-unmodified-Z80-system from working is what has been called the OUTJMP bug; Tim Olmstead wrote on comp.os.cpm the following:
Quote: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)
Of course, any Z80 code wouldn't be expecting this to happen, and so an OUT instruction of any kind with any branching instruction following would reliably crash the whole system. Tilmann's BIOS works around this.
--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!
|
|
|
|
|
Re: Interested in a Z280 SBC [message #3286 is a reply to message #3284] |
Mon, 31 July 2017 00:19 |
|
fritzeflink
Messages: 80 Registered: January 2017 Location: germany
|
Member |
|
|
lowen wrote on Sat, 29 July 2017 20:44Tilmann 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.
I added the OUTJMP.ZIP here
Greetings from Tilmann, I contacted him and he send me the program. He will be on holiday for some weeks.
Here I made some translation but didn't add this on oldcomputers
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.
-
Attachment: OUTJMP.zip
(Size: 9.15KB, Downloaded 287 times)
/*-----
fritz
-----*/
[Updated on: Mon, 31 July 2017 00:49] Report message to a moderator
|
|
|
|
|
Re: Interested in a Z280 SBC [message #3381 is a reply to message #1189] |
Tue, 29 August 2017 03:26 |
hperaza
Messages: 68 Registered: March 2017
|
Member |
|
|
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!
Attached a 3.5" drive with a straight-through cable (selected by DS1, thus B:), and it worked too after booting from ROM:
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.
OTOH, the image posted here seems to be corrupted, as some (most?) programs crash (e.g. SD.COM, STAT.COM). A dump of SD.COM reveals part of a text file instead of binary code. Format mismatch?
|
|
|
|
|
|
|
Re: Interested in a Z280 SBC [message #3390 is a reply to message #3389] |
Thu, 31 August 2017 07:38 |
|
fritzeflink
Messages: 80 Registered: January 2017 Location: germany
|
Member |
|
|
hperaza wrote on Thu, 31 August 2017 10:27Thanks. 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.
As I remember the system makes a read after write so it may be slower compared to other systems. As I mostly used a static ramdisk and a harddisk I can't remember slow floppyspeed compared with other systems.
/*-----
fritz
-----*/
[Updated on: Thu, 31 August 2017 07:38] Report message to a moderator
|
|
|
Re: Interested in a Z280 SBC [message #3395 is a reply to message #3389] |
Thu, 31 August 2017 11:44 |
|
Wayne W
Messages: 384 Registered: October 2015 Location: Fallbrook, California, US...
|
Senior Member |
|
|
hperaza wrote on Thu, 31 August 2017 01:27Thanks. 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.
I kind of felt the same way, so you are not alone. Fritz is probably right about the reason -- I have not personally looked at that part of the code at all and have not modified it's behavior. I would just add that Tilmann considered the preferred format to be a 1024 byte sector format. I have tried that and feel like it is much faster. Using 1024 byte sectors is problematic for making disk images on a PC, so that is why the disk images you see on GitHub are all in standard IBM 1.44MB format which is 512 byte sectors.
You could easily copy the files from the standard image to the RAM disk, then insert a new floppy disk, format at 1024 byte sectors, and copy the files back to that.
-Wayne
|
|
|
Re: Interested in a Z280 SBC [message #3396 is a reply to message #3389] |
Thu, 31 August 2017 13:41 |
|
lowen
Messages: 226 Registered: August 2016 Location: Western NC USA
|
Senior Member |
|
|
hperaza wrote on Thu, 31 August 2017 04:27Thanks. 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.
It is excellent that you have it all working. Yes, the disk I/O is a bit slow; Helmut Jungkunz wrote about it in this article on ZNode51, quote:
Quote:
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.
So, yes, the disk I/O relatively slow speed is a known thing. The hard disk interface is much faster.
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.
--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!
|
|
|
Re: Interested in a Z280 SBC [message #3398 is a reply to message #3396] |
Fri, 01 September 2017 03:05 |
hperaza
Messages: 68 Registered: March 2017
|
Member |
|
|
lowen wrote on Thu, 31 August 2017 13:41Part 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.
|
|
|
Re: Interested in a Z280 SBC [message #3399 is a reply to message #3398] |
Fri, 01 September 2017 05:33 |
|
lowen
Messages: 226 Registered: August 2016 Location: Western NC USA
|
Senior Member |
|
|
hperaza wrote on Fri, 01 September 2017 06:05
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.
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.
But I'm using an HxC emulator anyway these days.
Quote:
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.
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. Realize also that up until the Z280 was discontinued this BIOS was under development; if I were the person developing such a BIOS with a CPU that was known buggy I probably would have turned verify on by default too. 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.
Quote: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?
--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!
|
|
|
|
Re: Interested in a Z280 SBC [message #3410 is a reply to message #3399] |
Mon, 04 September 2017 00:45 |
hperaza
Messages: 68 Registered: March 2017
|
Member |
|
|
lowen wrote on Fri, 01 September 2017 05:33A 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).
Quote: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.
By looking at the code, the verify-after-write seems to be just a paranoia check for floppies. The Z280 DMA bug can be reliably detected by a status bit of the FDC controller, it affects equally reads and writes and the operation is always retried when the bug is triggered, independently of the verify-after-write setting. The hard disk (GIDE) code, for example, also uses the DMA and no verify-after-write is ever made, and not even provided for in the code as IDE transfers are not time-critical (the DMA bug is not about data corruption).
Quote: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.
|
|
|
Re: Interested in a Z280 SBC [message #3411 is a reply to message #3410] |
Mon, 04 September 2017 04:57 |
tor
Messages: 25 Registered: April 2016 Location: Norway/Japan
|
Junior Member |
|
|
hperaza wrote on Mon, 04 September 2017 09:45lowen wrote on Fri, 01 September 2017 05:33A 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).
1.44MB 3.5" floppies can't really handle their own density. I have systematically converted all my old media (CCT and various floppy types) to images, and my experience mirrors hperaza's. When focusing on 5 1/4" and HD 3.5" media, the difference is extreme - of the large numbers of old HD 5 1/4" floppies I converted I found two that didn't work at all (must have been degaussed at some point), and a small number of floppies with read errors - most could be recovered by retries, except for a couple. On the other hand, not a *single one* of the old 3.5" floppies are readable. Not one. I have lots of floppy drives, nothing can read HD 3.5" floppies from the previous century. (The exception is factory-written floppies - they're somewhat better). All my old media were stored in the same room under the same (optimal) conditions.
[Updated on: Mon, 04 September 2017 04:58] Report message to a moderator
|
|
|
|
|
|
Re: Interested in a Z280 SBC [message #3464 is a reply to message #3442] |
Sat, 16 September 2017 09:18 |
|
lowen
Messages: 226 Registered: August 2016 Location: Western NC USA
|
Senior Member |
|
|
Update for 9/16/2017.
As we approach the first anniversary of this thread, I look back over the past year with more than a little awe at what has been done. So I want to thank some folks publicly for making it possible for me to make my Z280 dreams come true, at least the hardware part of those dreams.
Number one, and top of all the lists, is Tilmann Reh. I will never forget that Tilmann designed the CPU280 and did all of the hard work. I will never forget that the reason we could have a CPU280 revival at all is due to Tilmann's extreme generosity in sharing the designs and his knowledge.
Number two is Fritz Chwolka. Fritz kept his CPU280's files, and made them publicly available, and I found them. Had I not found Fritz' archive I would have never begun the CPU280 revival.
Next in line are Helmut Jungkunz, Gaby Chaudry, ZNode51, and many who attended various ZFests.
I want to thank members of this group, especially John Coffman, Wayne Warthen, Steven Hirsch (his comp.os.cpm posts longing for a Z280 also gave me motivation!), as well as Terry Gulczynski, and all the others who have successfully built CPU280's and given feedback and encouragement. Wayne deserves extra kudos for getting a github setup and building software, as well as patching said software. Many times it is easy to overlook all who have helped in some way, and if I've not mentioned anyone who contributed please let me know so I can update this post, since I don't want to leave anyone out. Jonas, almost forgot you; your early encouragement inn this thread was exactly what I needed to keep going in a couple of instances.
And many thanks to Andrew B and Andrew Lynch, for working to get this group of people together in the first (and second) place.
Stay tuned for some feedback from Tilmann on this thread once I get it reformatted and get his OK to post.
--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!
[Updated on: Sat, 16 September 2017 10:15] Report message to a moderator
|
|
|
Current Time: Wed Apr 17 16:33:00 PDT 2024
Total time taken to generate the page: 0.01388 seconds
|