Opus DDOS 3.00

want to contribute an update to the archive? post it here!
User avatar
Pernod
Posts: 1140
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Opus DDOS 3.00

Postby Pernod » Sat Sep 10, 2016 12:55 pm

I have received DDOS 3.00, kindly dumped by Chris Jones before he sent the machine to Cambridge.
His video of it running is at https://www.youtube.com/watch?v=09alLIz16ck.
IMG_5279.JPG

IMG_5277.JPG

It's not yet working in MAME as I'm having a little trouble determining the addressing of the 8272. Looking at the ROM it seems to be at &FE84-85 but there are also reads from &FE82-86 that I'm still investigating.
Attachments
opus-ddos300.zip
(10.38 KiB) Downloaded 23 times
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
Pernod
Posts: 1140
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: Opus DDOS 3.00

Postby Pernod » Wed Sep 21, 2016 8:01 am

Anyone fancy helping to reverse engineer this board?

What we have is the 8272 which is mapped as:
fe84 status register (read)
fe85 data register (read/write)

But this DDOS also accesses the following:
fe81 (write STA)
fe82 (read LDA)
fe86 (read LDA)

It looks like fe81 is always 0 or 1 and is 1 for drives 0,2 and 0 for drives 1,3. This is also likely used for motor control, but need confirmation.

Under emulation it always returns 'Cannot find density' so suspect it needs fe82 and fe86 to return expected values, but since the 8272 only has the two registers what can these be? I am at a loss with this so if anyone fancies documenting the earliest known version of DDOS it would be much appreciated :D
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
jgharston
Posts: 3012
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Opus DDOS 3.00

Postby jgharston » Wed Sep 21, 2016 4:16 pm

The board has two 74*161 4-bit latches so it could be latching something on the other addresses. It also has a 74*138 3-to-8 decoder and a 74*141 4-to-10 decoder (WOW R@RE!) which also suggest that other addresses are used. My hunch is that FE84/5 access the FDC and the other address access the two latches.

Do you have a hi-res picture of the underside of the board?

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
Pernod
Posts: 1140
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: Opus DDOS 3.00

Postby Pernod » Wed Sep 21, 2016 8:15 pm

Nope, no other photos. If we can't guess this out then it'll have to wait until the next Cambridge meeting where the board is currently stored. There aren't that many output lines from the 8272 and I'd expect pin 26 (MFM) to be part of the puzzle that's causing my density error.
Last edited by Pernod on Thu Sep 22, 2016 7:41 am, edited 1 time in total.
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
sydney
Posts: 2075
Joined: Wed May 18, 2005 9:09 am
Location: Newcastle upon Tyne
Contact:

Re: Opus DDOS 3.00

Postby sydney » Wed Sep 21, 2016 8:34 pm

Is this of any use? (Maybe not, but I remembered DDOS being mentioned on this site so thought it may be relevant)

regregex.bbcmicro.net wrote: EDOSPAT Version 4.90, 15 February 2014
Applies patches to an image of Opus EDOS 0.4. A versatile alternative to DDOS which is now compatible with ADE Plus, Xfer 5.3 and HADFS. There are two parts: (a) addition of OSWORD calls 7D/7E and fixes for OSGBPB and OSARGS, (b) support for seven common floppy disc controllers including those in the B+ and Master.
EDOSPAT 4.90 (130 KB, Zip archive)
Change log (14 KB, text)
EDOS notes (17 KB, text)
Images of blank formatted discs (4 KB, zipped)
Disassembly of patched EDOS Original version (378 KB, text)
Disassembly of patched EDOS by Steven Bass, with my comments (279 KB, text)
EDOSPAT Version 5.20, 15 February 2014
Quad density version for modified controllers only. Supports Opus 2791 HD and Acorn-style Ajax.
EDOSPAT 5.20 (316 KB, Zip archive)
Disassembly of patched EDOS (382 KB, text)

User avatar
Pernod
Posts: 1140
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: Opus DDOS 3.00

Postby Pernod » Wed Sep 21, 2016 8:58 pm

Thanks but no. I have EDOS, which is similar to DDOS 3.15, working with the 1791 FDC, it's a completely different implementation from the 8272 with DDOS 3.00.
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
leenew
Posts: 3552
Joined: Wed Jul 04, 2012 3:27 pm
Location: Doncaster, Yorkshire
Contact:

Re: Opus DDOS 3.00

Postby leenew » Wed Sep 21, 2016 9:19 pm

Pernod wrote:... part of the puzzle that's causing my density error.

I have those errors all the time... :wink:
Lee

cmjones01
Posts: 136
Joined: Fri Sep 06, 2013 2:12 pm
Location: Warsaw, Poland and Cambridge, UK
Contact:

Re: Opus DDOS 3.00

Postby cmjones01 » Thu Sep 22, 2016 3:14 pm

Chris here, donator of the original board...

I do have a bunch more photos of the board - I took the liberty of desoldering all the chips and taking track photographs, then putting the chips back on (and making sure it still worked) before donating it to the museum.

I've been working on tracing out the circuit diagram and I attach what I've got so far:

opus-ddos-schematic-draft-20160922.jpg


The board has a load of mod wires on it, not all of which make sense. There appears to be total nonsense going on with the HEAD LOAD signal, for example. Here's my best guess at the address map so far. I've traced all the outputs from the LS138 decoder, which takes A0 from nDACK which is really the Beeb's A2, A1 from A1 and A2 from A0 so the addresses are inside-out.

&FE80 not decoded by 138
&FE81 set HEADLOAD
&FE82 clear HEADLOAD
&FE83 not decoded by 138
&FE84 not decoded by 138
&FE85 write drive select 0/1 depending on state of D0
&FE86 strobe 8272 TC (terminal count, finishes a DMA transfer)
&FE87 not decoded by 138

The 8272 appears to be enabled by nDACK, so it should appear at &FE84-&FE87 with its two registers repeated twice.

Maybe this will help.

Chris

cmjones01
Posts: 136
Joined: Fri Sep 06, 2013 2:12 pm
Location: Warsaw, Poland and Cambridge, UK
Contact:

Re: Opus DDOS 3.00

Postby cmjones01 » Fri Sep 23, 2016 7:10 am

OK, I think I've finished tracing out the circuit now. No new innovations as regards address decoding but we can see which pins of the 8272 are connected. Some of it still doesn't make sense - what's going on with the FET and the head load signals makes no sense, and there seem to be two ways of generating RDY conflicting with each other. I can only assume that one of them has a track cut which I can't see. The circuit diagram is attached here in legible form as a PDF as well.

opus-ddos-schematic-draft-20160923.jpg


Here are the bare board photos I traced from:

ddos-board-topside.jpg

ddos-board-underside.jpg


I hope this all helps
Chris
Attachments
Opus_DDOS-20160923.pdf
(90.07 KiB) Downloaded 21 times

cmjones01
Posts: 136
Joined: Fri Sep 06, 2013 2:12 pm
Location: Warsaw, Poland and Cambridge, UK
Contact:

Re: Opus DDOS 3.00

Postby cmjones01 » Fri Sep 23, 2016 9:22 am

And still there's more! Looking more closely, it turns out that there were a few places where tracks had been cut by drilling out or partial-drilling-out of vias. Tricky to spot on a photograph. That's resolved the mysteries of HEAD LOAD and RDY: RDY is simply generated from nREADY0 and nREADY1, and IC11d is just producing the data window signal. And the HEAD LOAD business is clearly a design bodge. Originally it was generated by inverting HDL from the 8272 but for some reason that wasn't good enough, so it's now generated by the flip-flop addressed at &FE81 and &FE82, and has a scummy monostable on the output which has been constructed using a FET, a resistor and a capacitor bodged into places they weren't supposed to fit.

Latest schematic attached.

opus-ddos-schematic-draft-20160923a.jpg

Opus_DDOS-20160923a.pdf
(90.27 KiB) Downloaded 42 times


Chris

User avatar
Pernod
Posts: 1140
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: Opus DDOS 3.00

Postby Pernod » Fri Sep 23, 2016 4:47 pm

Thanks, looks great, but still confused.
&FE80 not decoded by 138
&FE81 set HEADLOAD
&FE82 clear HEADLOAD
&FE83 not decoded by 138
&FE84 not decoded by 138
&FE85 write drive select 0/1 depending on state of D0
&FE86 strobe 8272 TC (terminal count, finishes a DMA transfer)
&FE87 not decoded by 138

I'm seeing either a 0 or 1 being written to &fe81 depending on which drive is being accessed which would suggest it's not simply a flip-flop for the head-load/motor control. Also, &fe82 is never written to only read which suggests it should return the state of a line.
You also say the &fe84 is not decoded but it has to return the status register and &fe85 is the data register. Am still no clearer on what &fe86 should return, it is read frequently by the rom.
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

cmjones01
Posts: 136
Joined: Fri Sep 06, 2013 2:12 pm
Location: Warsaw, Poland and Cambridge, UK
Contact:

Re: Opus DDOS 3.00

Postby cmjones01 » Fri Sep 23, 2016 5:25 pm

That's very interesting that &fe81 gets 0 and 1 written to it, which would correspond with what I've decoded as &fe85. It may be that I've got my address decoding scrambled. Double-checking the BBC's schematic, it turns out that nDACK is actually A2 inverted, so the map looks totally the other way round! Something like this:

Code: Select all

Addr A2A1A0   A0A1nDACK
&fe80 0 0 0    001 not decoded
&fe81 0 0 1    101 drive select write
&fe82 0 1 0    011 TC strobe
&fe83 0 1 1    111 not decoded
&fe84 1 0 0    000 not decoded
&fe85 1 0 1    100 set headload
&fe86 1 1 0    010 clear headload
&fe87 1 1 1    110 not decoded


Those are just the outputs from the '138 decoder. The 8272 is selected when nDACK is low, which means A2 is high, so it'll appear at &fe84-&fe87 *in addition to* the functions listed above. It looks like the status register is best accessed at &fe84 and data at &fe87 to avoid triggering the headload flipflop.

The TC strobe, set and clear headload at &fe82, &fe85 and &fe86 are just strobes, so writing or reading them will have the same effect. No meaningful data will be returned, except that reading &fe85 and &fe86 will also read from the 8272 registers.

Chris
Last edited by cmjones01 on Fri Sep 23, 2016 11:19 pm, edited 1 time in total.

User avatar
1024MAK
Posts: 7204
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Opus DDOS 3.00

Postby 1024MAK » Fri Sep 23, 2016 5:50 pm

Chris, if you list your table within the CODE tags, the text will use fixed pitch spacing, making it easier to see the columns in your address table :wink:

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

cmjones01
Posts: 136
Joined: Fri Sep 06, 2013 2:12 pm
Location: Warsaw, Poland and Cambridge, UK
Contact:

Re: Opus DDOS 3.00

Postby cmjones01 » Fri Sep 23, 2016 11:19 pm

Good point! Thank you. I've added those tags to the table. It's still not pretty but better than it was.

Chris

User avatar
Pernod
Posts: 1140
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: Opus DDOS 3.00

Postby Pernod » Thu Jan 04, 2018 1:45 pm

Decided to revisit this and now have it working:
0026.png

Having never implemented a 8272 before I wasn't aware of the significance of the TC strobe. I added a pulse on the TC line when reading &FE62 and it sprang to life!
Needs a little cleaning up but definite progress.
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.