WD1772 vs DP8473V

Nagging hardware related question? Post here!
Post Reply
User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

WD1772 vs DP8473V

Post by Dave »

Hi folks!

A while ago I had the misfortune to blow up my SQBv3. It isn't very feasible to repair it, and I think there are some elements of it that can be improved in a new design.

I have large stocks of WD1772 and VL1772, but I also have very large stocks of DP8473V.

I'm making this for myself, but I'm hardly going to order just one PCB.

So... Should I use the WD1772 and the ROM I already have and am ok to use, or should I try to extract the driver for the DP8473V that exists in the SGC ROM? If so, do you think it would be at all easy to make it ROMable? If I can extract a working ROM image I'd rather go with the DP8473V, on Nasta's advice. Otherwise, I'll have to stick with the 1772. I'm aware there's a driver for the DP8473V in SMSQ/E too, but again, unsure of its status outside of SMSQ/E, its ability to operate with other QL OS, and the ability to make it ROMable.

Is there any principle objection to mapping the floppy IO to the internal IO somewhere non-conflicted between $18000 and $1BFFF?

If I do stick with the 1772, I will go from my existing plans, incorporate Marcel's DD/SD mod, try to reduce component count with an additional GAL, and completely modernise the power regulation. If I go with the DP8473V, I'll retain the other features of the SQB where possible.

Any pointers appreciated.

Thank you.


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: WD1772 vs DP8473V

Post by tofro »

Dave,

I don't see a lot of disadvantages going with the 1772 - You probably won't use HD (nor ED, for that matter) drives (they've never really been used to exchange data between people) and you got working software for the Qboard anyhow. Extracting a driver from the GC/SGC ROM and re-using it for different hardware could be a bit of a challenge, I suppose.

With regards to I/O addresses, I would refrain from using the area reserved for internal I/O for expansion boards. Do what everybody except Miracle did (Trump Card, GC and SGC filled the possible address space of the QL anyhow, so there were no conflicts to be expected) and put the I/O addresses to the end of the board's ROM area, so you are avoiding any possible conflicts - This means the addresses will wander, but that should already be covered by the existing driver, I think.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
stephen_usher
Gold Card
Posts: 429
Joined: Tue Mar 11, 2014 8:00 pm
Location: Oxford, UK.
Contact:

Re: WD1772 vs DP8473V

Post by stephen_usher »

If you want HD then the 1772 can be overclocked to 16MHz to do this, as used in the Atari TT030.


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: WD1772 vs DP8473V

Post by Dave »

Tobias:

In that 32K block, only 9 bytes seem to be actually used by memory mapped IO. A couple of mouse systems use three or four bytes near the top of that 32K. Part of the problem is that the area is only partially decoded so it contains aliases of those IO registers with the frequency dependent on whether it's an Issue 5, or Issue 6/7 board.

My intent is to place the interface ROM and IO in the regular place on machines shipped to the general public, with the address decoded by a GAL. However, I'd like to map just the IO into the Internal IO area on *my* machine for testing a particular address decoding arrangement.

There are some advantages to putting the IO address in that IO window: no need to have a see-through port in your ROM image for IO to operate through - even if it's just a few bytes, much simpler and more consistent address decoding if you know where the IO is going to happen, regardless of the location of the card in memory. It seems there would be advantages to having that portal in the bottom 256K of the address map. A stepping through the IO area would be added into the address from A14-17, so cards would not conflict with each other. This would later allow the expansion cards themselves to be remapped anywhere in the memory map.

I have ED drives, and ind the higher 500 kbps and 1mbps transfer rates with ED drives provide a very useful increase in transfer rate. Those drives are also much easier to get, being 5-10 years newer than our old Citizen and Sony mechanisms.

So the question is more general than specifically floppies, and is trying to find out if anyone knows of any logical or practical reason why the IO of certain predictable devices like floppy, IDE, QL-SD, might not be placed at, say, $18100-181FF, $18200-182FF etc. assuming the area were fully decoded.

Would it break anything?

Stephen:

Yep, that was the first mod I made.


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: WD1772 vs DP8473V

Post by martyn_hill »

Hi Dave

Like you describe, I've always found that 32kB block of Int QL I/O very tempting to re-use 'for my own purposes.'

Only the bottom 64 bytes (aligned to a bit-boundary) are needed for valid QL internal I/O, plus we hear that QIMI uses the top 256bytes (or less.)

I was researching recently any other reported uses of this area and didn't find anything documented and was gong to devise some additional decoding there in the hope to move QL-SD I/O out of the Ext ROM area on one of my setups (with a revised driver.) I never bothered in the end, once I saw how many inputs I'd need to consume on the GAL just to decode the holes in that block.

Still, a worthy exercise, to my mind.


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: WD1772 vs DP8473V

Post by Dave »

DISCLAIMER FOR THE EXPERT: I'm writing this post to expand generally on information for the average user. If you're more knowledgeable and disagree with anything I said, or would like to add nuance, please do so in a positive and constructive manner. There's a few remappings of the QL memory map already and I do not wish to add yet another. I would just like to put the IO window for some common, included devices that are... "fixed" to the memory map in a more flexible way that allows the driver image to be remapped anywhere without moving the IO.


EVERYONE ELSE:

Indeed. It's 32K that is not part of the RAM or ROM memory map.

I'm going to provide some background for the "average user."

There's a number of 16K allocations in the memory map for expansions. So, an expansion gets plugged in and it has, nominally, a 16K address space. The card has an address decoder that detects when the address on the address bus is within the expansion's address space and when it is it knows it is being referenced as either a read (W/R is high) or a write (W/R is low).

Generally speaking, the expansion is an IO device that contains a ROM which on boot is linked into and expands the OS resources and usually the BASIC keywords list. So you have a 16K memory slot with a 16K ROM holding the driver that will be linked in. This ROM is going to need a carefully managed hole in the ROM image at some specific addresses, so the IO can be read and written through the ROM image. Imagine you have a 16384 length EPROM and a 15520 driver. That leaves 864 bytes free at the top. To simplify the driver, you'll align the IO area to 512 bytes from the top, and create a "window" through the ROM image to see the IO for input and output.

There is an alternative, which is to further decode the address space to identify the explicit IO addresses and de-assert the output enable of the ROM for those addresses. You don't need a window in the image - the ROM isn't even selected. This is "clean" in that it is self-contained, but in every other way it is dirty.

This is further complicated by the ambiguity that some expansions always occupy a fixed position in the address space, but others follow the SP0..3 system.

The SP0..3 system are four pins on the expansion connector. In systems before the QL, the idea was that each card would plug into the previous card using a through connector, and each card would increment SP0..3 by 1. So card 1 would be SP=0000, card 2 would be SP=0001, card 5 would be SP=0101, etc. Each card could them simply compare A14..17 with SP0..3 while A18..19=0 to known they where being addressed. All code would be relocatable.

Only problem is not a SINGLE backplane implemented this. Even my MiniPlane didn't, because I wanted to be consistent. Every slot starts at SP=0000. Every card has to avoid conflict by itself.

So, here we are, 35 years later. The Q68 doesn't really have expansion in that no hardware has been released for it, and nobody's making new hardware that challenges or hits the problems caused by the status quo. I've talked a fancy game over the last five years but released nothing, so, yeah, I get it.

Well, the Issue 8 is a real thing and is really happening. I'm not asking you to believe me. Just ask the people around me. I'm being very targeted and focused. Nasta is working on the logic and HEAVILY steering me. Marcel Kilgus has been offering cautionary notes that are keeping me on track. I have this period of a few months where I am focusing on this and not being distracted by the daily grind of work. If anything is going to happen, now is it. All of these questions have a very definite focus. They do inform the decisions Nasta and Marcel and me make about Issue 8, but they also impact everything that follows.

So, yeah, I'm making myself a floppy interface based on one I did some work on in 1985. And I'm going to make extras. And they'll be plugged into Issue 5s and 6s and 7s. And 8s. And mainboards that follow that which nobody in 1984 could have even envisioned. I mean, who in 1984 knew the Q68 or Q60 would happen?

So this stuff matters and you need to chime in and inform me of the demand and the requirements.


I want to move the IO area into the internal IO because the floppy interface won't move, the IDE won't move, the QL-SD won't move. QL-SD is particularly problematic because it's designed to be used in a read only area - the expansion ROM slot. It would be MUCH faster if its IO were in a writeable location. Even more so with hardware parallel to serial support. It's already very fast, but the desire to have it scale with the speed and capability of the system is only natural.

So...

There are reasons for and against moving fixed IO into the internal IO window between $18000 and $1FFFF. Let's discuss the implications so we understand the positive and negative implications of making this change,

It came down to an informal co-operation between vendors to map expansions into non-conflicted expansion slots, since they were all the "same" as far as SP0..3 were concerned. This is why QubIDE has a jumper block, so you can assign the QubIDe to a non-conflicted block where another expansion already resides. This was in a way abused explicitly by the Trump Card, for example, which would work out the positions of expansion cards and map RAM into unused slots in a way that maximized unused continuous RAM.

This leaves me as a hardware designer to work out either a method to fit into the existing system, or to devise a new compatible one that doesn't break anything.


Nasta
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: WD1772 vs DP8473V

Post by Nasta »

Dave wrote: In that 32K block, only 9 bytes seem to be actually used by memory mapped IO. A couple of mouse systems use three or four bytes near the top of that 32K. Part of the problem is that the area is only partially decoded so it contains aliases of those IO registers with the frequency dependent on whether it's an Issue 5, or Issue 6/7 board.
Correction - it's a 16k area between $18000 and $1BFFF. Depending what manual is consulted, in some of them it's a 32k block extending to $1FFFF, however, the actual mapping has been established by precedent - when a common denominator is taken from all motherboard and 8301 ULA versions, you end up with the already mentioned 16k.

In any case, it is explicitly stated in the Technical manual (that does have some holes in the descriptions...) that if things alias to multiple addresses, software should ALWAYS use the LOWEST address ONLY, for future compatibility. This of course does not include hardware that needs to use aliases for it's own purposes but then it has to cater for this with appropriate drivers and documentation.

Regarding the mothrboard IO, it is decoded within the 16k area mentioned above, using only 4 address lines, of which A6 is the highest. This means there are 128 aliases of that 128 byte area within the 16k and indeed, extra aliases of addresses withing the 128 bytes. However, using the 'lowest alias' rule, everything on the motherboard is addressed in the lowest 128 bytes, so that's $18000..$1807F.

ASIDE: It is quite possible that there have been errors made in the 8301 ULA and initial board routing because it seems the original intention (and I have already contended both ULAs have started life as a single design) was to have all the IO in the first 8 bytes. The way the actual registers are decoded strongly suggest this.

The one seminal piece of hardware that first used this area for it's own purposes, and with a good deal of conceptual backing, since it was in fact expanding the capability of the motherboard itself, was QIMI. It actually reduces the on-board IO to only those aliases that have A10=0. When A10=1, it maps in it's own circuits. However, it also breaks the 'lowest address rule' by using the highest alias, which I suppose was used because Qjump did not want to bother with badly behaved software so they chose the least likely alais to cause trouble. QIMI is mapped into the top 256 bytes of the on-board IO area.

As far as I know (and indirectly everyone that ever used an Aurora), the part between the lowest and highest 256 bytes was never used by anything - or it would not have worked on Aurora. It actually decodes the addresses in this area and presents a chip select pin on the extended ROM slot that is active for any address between $18100 and $1BEFF. The extended ROM slot also has a R/W pin and a /RESET pin, and an /EXTINT pin. You know, stuff that should have been there from the beginning :P do some clever simple peripherals could be made to work in the ROM slot.

My intent is to place the interface ROM and IO in the regular place on machines shipped to the general public, with the address decoded by a GAL. However, I'd like to map just the IO into the Internal IO area on *my* machine for testing a particular address decoding arrangement.
There are some advantages to putting the IO address in that IO window: no need to have a see-through port in your ROM image for IO to operate through - even if it's just a few bytes, much simpler and more consistent address decoding if you know where the IO is going to happen, regardless of the location of the card in memory. It seems there would be advantages to having that portal in the bottom 256K of the address map. A stepping through the IO area would be added into the address from A14-17, so cards would not conflict with each other. This would later allow the expansion cards themselves to be remapped anywhere in the memory map.
That was my initial idea - but QIMI breaks this. Unfortunately it's of no consequence as automatic addressing was broken long ago, more on that later.
The idea was to provide 16x 512 bytes (=4k) of IO space from $19000..$19FFF that would track the 16k block selected by the required setting of A19..A16 that maps the expansion card into the expansion IO area at $C0000.
There are problems with this:
There are several cards that required two or in fact ALL of the expansion IO area for their own use. The best known are the SuperQboard and Trump Card (Not THAT Trump!). Once they were introduced, the use of the SP lines to select a peripheral was completely deprecated, and to a large extent so was the use of the expansion IO area - with a TC that became RAM (and it was very welcome, given how many were sold).
It should be noted that the SP0..3 system was not intended for backplanes unless the card address was set by switches or spread out to the number of backplane slots available. It's intention was for through-ported cards. Each would add one to the SP state to move the next card's address one 16k slot up. THe odd thing is, why it dod not start at the top slot and move down, that would have been more logical because RAM was permitted to grow upwards into the expansion IO area from the very beginning - this is how the OS works (and there are other tricks it does but that's another story). Cards that were intended to use up the whole space, like TC, GC and SGC actually used the fact the SP lines were tied to ground on the motherboard, to establish a better ground connection.
The TC also pioneered the use of $10000..$17FFF for ROM.
When Qubide came along, it simply had to have a jumper selectable address or it would not fit a lot of systems which would indeed be the best candidates for having a Qubide in the first place.
And once you had a Qubide in there, thre was literally no-where to go. Minerva did try to make things somewhat better but alas missed one thing, and that is using the addresses just above the 16k IO block, at $1C000..$1FFFF as a candidate for a ROM or expansion card - it did, however, add $10000 and $14000 as possible candidates. If that were added, Qubide would have worked in there (and it IS actually possible to map it there, and patch the LRESPR version of the driver to use it).
After that (S)GC came and we were back to the ROM slot as far as expansions go.

As Dave pointed out, 'real' expansions intended to work together with other ones, had to put their private IO stuff somewhere.
It should be known that 'expansion IO' actually means 'extension ROM'. Since there was no specification as to where various IO addresses should go for add-on stuff, the idea was for the ROM that drives the said IO to contain code that knows where to look for it's relevant hardware, and the typical way of doing that (in order to not have to figure out any possible conflicts) was to reserve a bit of space, usually 2^N bytes, N being a small number, subject to required IO space and decoding resources, at the very end of the 16k space allocated to the ROM. Of course, that also 'shortened' the available space for code in the ROM by that 2^N amount. 256 was the most common - and to give you an idea how few bytes are typically needed to map an IO device, Qubide uses 256 bytes at the end and maps no less than 16 IDE channels in there, given external decode. And, not only that, it maps the single data port into 8 consecutive bytes so that successive data accesses can capitalize on the 68008 being able to do 4 or more byte accesses back to back by accessing the data as long words.

It is now a moot point if decoding IO inside the on-board Io area or inside the 16k space for the ROM on an expansion card needs more or less hardware, the point is, some expansions have become ubiquitous and almost a standard, so they could well be mapped to fixed addresses.

So far we can assume the old ULAs at $18000..$180FF and Qimi (original, not the one on the SQB) at $1BF00..$1BFFF. The rest is more or less up for grabs.
One entry which I would add to this, is the entire first 4k of that area. There is a hidden agenda behind that one :P


User avatar
Pr0f
QL Wafer Drive
Posts: 1298
Joined: Thu Oct 12, 2017 9:54 am

Re: WD1772 vs DP8473V

Post by Pr0f »

Nasta wrote: So far we can assume the old ULAs at $18000..$180FF and Qimi (original, not the one on the SQB) at $1BF00..$1BFFF. The rest is more or less up for grabs.
One entry which I would add to this, is the entire first 4k of that area. There is a hidden agenda behind that one :P
Curiosity raised :-)


In my trawls through various lots of documentation about the memory map, that I/O area of 32K is sometimes described as a singular I/O area, and sometimes as 16K internal - from $18000-$1BFFF, and external I/O - from $1C000-$1FFFF. Certainly in the latter case, that seems to be the approach Miracle systems took with the Trump Card, and to a lesser extent the Gold and Super Gold cards, where ROM is also found lurking there...

If you are trying to maintain compatibility for the Miracle products, then that area seems to get left alone (SMSQ/E avoid gold for instance), but if the device you are providing is a processor add on card, then surely that area is available again? Just thinking out loud.


Also - just for giggles - there is a 37C78 disk controller on the market that appears to offer the same capability as the DP8473V, but without the need to have the external passives, saving board space and making routing slightly easier...

http://ww1.microchip.com/downloads/en/D ... /37c78.pdf


Nasta
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: WD1772 vs DP8473V

Post by Nasta »

Pr0f wrote:
Nasta wrote: So far we can assume the old ULAs at $18000..$180FF and Qimi (original, not the one on the SQB) at $1BF00..$1BFFF. The rest is more or less up for grabs.
One entry which I would add to this, is the entire first 4k of that area. There is a hidden agenda behind that one :P
Curiosity raised :-)
Something to do with dual port RAM :P
In my trawls through various lots of documentation about the memory map, that I/O area of 32K is sometimes described as a singular I/O area, and sometimes as 16K internal - from $18000-$1BFFF, and external I/O - from $1C000-$1FFFF. Certainly in the latter case, that seems to be the approach Miracle systems took with the Trump Card, and to a lesser extent the Gold and Super Gold cards, where ROM is also found lurking there...
If you are trying to maintain compatibility for the Miracle products, then that area seems to get left alone (SMSQ/E avoid gold for instance), but if the device you are providing is a processor add on card, then surely that area is available again? Just thinking out loud.
The expansion system is configured so that any part of the motherboard address map can be disabled and used for something else, and that's on a address by address and cycle by cycle basis. That being said, the (S)GC does things a bit differently and replaces some areas of the _BUS_ address map with it's internal address map so from the standpoint of the CPU things like a RAM copy of the OS and (S)GC ROM appear at addresses that are never generated on the external bus, so whatever is mapped there based on the bus address, will never be selected, and is thus disabled.
A good example is the motherboard RAM - only the screen RAM addresses ever appear on the bus, and only for writing. The card keeps a copy of the data written in it's own RAM that maps to the same address (as viewed from the CPU) and only ever reads it from there as that's several times faster. Since most screen data manipulation is done by reading data, then modifying it inside the CPU and writing it back, this shadowing scheme can result in significant speed gains.

In any case, all known add-on cards leave the $18000..$1BFFF for 'on board IO', except QIMI. But as I said, only a tiny amount is used so there is no reason why an expansion card could not use a part of that as long as there are no conflicts with other expansions or actual motherboard hardware.
Also - just for giggles - there is a 37C78 disk controller on the market that appears to offer the same capability as the DP8473V, but without the need to have the external passives, saving board space and making routing slightly easier...
http://ww1.microchip.com/downloads/en/D ... /37c78.pdf
Also there is an equivalent DP8477.
Along with no external components, they also feature a data in/out FIFO of 16 bytes, to reduce the interrupt frequency and interrupt latency requirements.
The problem with that whole family of FDCs (and this includes many integrated on multi and super-IO chips) is that they are completely different than the WD chips, and are based on a NEC uPD765 controller.
The only available code base for them is in SMSQ/E, apart from disassembling the (S)GC ROM. Another possibility would be the Q40/60 version of Minerva, as that was (as far as I remember) using a PC multi-IO card, which also used floppy controllers compatible with the uPD765.


Post Reply