From: "Peter "Firefly" Lund" on
On Fri, 5 Jan 2007, drhowarddrfine wrote:

> I never carried it through. I was putting together a bit-slice system using
> ttl and, later, 2901s.

But what was your planned VAX microarchitecture going to look like?

My intention is to prove that the VAX could be pipelined and could be made
fast -- and maybe try out a few microarchitectural tricks along the way.

My thesis is that the VAX could have been made fast relatively easily and
that the Alpha, however much we loved it, was a mistake.

A secondary point is that the VAX family could have been more
"self-compatible", i.e. that it wasn't necessary to remove instructions to
the degree it was done. I am not so sure about this point, though.

-Peter
From: Eric P. on
"Eric P." wrote:
>
> Ok I see what they are griping about. It has to do with
> non-existent devices and the signal sense.
>
> If the addressed device/ram is missing, a protocol that requires
> an ack to proceed (DTACK) will hang the bus whereas a protocol that
> requires an ack to hold (NOT_READY) will not hang.
> The former case _must_ be dealt with in every design,
> the later case you read junk data but the cpu doesn't hang.
>
> Eric

Hmmm... I looked at some of the above page again, and after a bit
more thought this this looks like just a marketing burb to sell
their brand of 68000 board and a red herring issue.

My statement about which case must be dealt with was in error.
In both cases you must ensure the signal is proper in a proper
state when a non-existent device is addressed and not allowed to
float tri-state to arbitrary logic levels. IIRC the solution was
to tie the line to either +5 (DTACK) or ground (NOT_READY)
through a 100K resistor. No timers were required to prevent cpu
hanging, only if you wanted a trap generated for bad addresses.

Eric

From: drhowarddrfine on
Peter "Firefly" Lund wrote:
> On Fri, 5 Jan 2007, drhowarddrfine wrote:
>
>> I never carried it through. I was putting together a bit-slice system
>> using ttl and, later, 2901s.
>
> But what was your planned VAX microarchitecture going to look like?
>
> My intention is to prove that the VAX could be pipelined and could be
> made fast -- and maybe try out a few microarchitectural tricks along the
> way.
>
> My thesis is that the VAX could have been made fast relatively easily
> and that the Alpha, however much we loved it, was a mistake.
>
> A secondary point is that the VAX family could have been more
> "self-compatible", i.e. that it wasn't necessary to remove instructions
> to the degree it was done. I am not so sure about this point, though.
>
> -Peter
I'm sorry I confused you. I did not try and recreate the VAX but was
doing an architecture of my own specific to an application.
From: drhowarddrfine on
Eric P. wrote:
> "Eric P." wrote:
>> Ok I see what they are griping about. It has to do with
>> non-existent devices and the signal sense.
>>
>> If the addressed device/ram is missing, a protocol that requires
>> an ack to proceed (DTACK) will hang the bus whereas a protocol that
>> requires an ack to hold (NOT_READY) will not hang.
>> The former case _must_ be dealt with in every design,
>> the later case you read junk data but the cpu doesn't hang.
>>
>> Eric
>
> Hmmm... I looked at some of the above page again, and after a bit
> more thought this this looks like just a marketing burb to sell
> their brand of 68000 board and a red herring issue.
>
> My statement about which case must be dealt with was in error.
> In both cases you must ensure the signal is proper in a proper
> state when a non-existent device is addressed and not allowed to
> float tri-state to arbitrary logic levels. IIRC the solution was
> to tie the line to either +5 (DTACK) or ground (NOT_READY)
> through a 100K resistor. No timers were required to prevent cpu
> hanging, only if you wanted a trap generated for bad addresses.
>
> Eric
>

Yes, that is correct. We would have pullups/downs because tri-state was
not allowed. The value depended on the length of the bus and impedance.
I want to say the value was more like 1Meg but 100K sounds right, too.
I just don't remember.

iirc, I had to incorporate an outboard timer to timeout invalid accesses.
From: ChrisQuayle on
Peter "Firefly" Lund wrote:

>
> Sure. First of all, they weren't /really/ in same time frame.
> The 8086/8088 got there years before the 68K.
>
> That tends to matter.

I wasn't quite sure about some of the dates, so google for a timeline gets:

8080 and 6800 : 1974
6502: 1975

8086: 1978
68k: 1979

So not much time slip between them.

>
> Secondly, the 8088 could easily use existing peripheral chips designed
> for the 8080/8085/Z80.

So could the 68k, having 3 pins, enable, vma and vpa pin dedicated to
legacy 6800 series peripheral control.

> As far as I can tell, the 8086/8088 was also easier to interface with
> than the 68000/68008. I'm referring both to how you hook up memory and
> I/O devices, how interrupts are handled, and how the initial bootup is
> handled.
>
> That also tends to matter ;) -- but since I'm not nearly as sure about
> this point I won't belabor it. I might be wrong here.

I guess it depends on how much work you have done with a given cpu, as
there is always a learning curve. My x86 hw design is limited, but
around '83 I designed memory cards using the then new 64k x 1 bit
devices. A 128k card for the 6502 Apple II and a 384k card for the 8086
Sirius (II ?). Still have the Intel iAPX86 users manual somewhere, but
remember it being hard work to build any simple mental model for what
was required for the design. There were pages that seemed to contradict
themselves in terms of timing or other info and if not impenetrable, was
quite dense. Bought a 68k eval board later and it seemed like orders of
magnitude improvement over anything seen previously. Generous register
set and addressing modes, 24 bit flat address space, asynchronous bus to
allow a mixture of memory and peripheral access times, multimode, fully
vectored interrupts, the list goes on and on. At the time, the
architecture was like a wish list in silicon and if not perfect, quite
revolutionary. I think what i'm trying to say is that the 68k was one of
the first micros to break the old mold mini model of accumulator + index
register architecture that was so pervasive in early micro designs.

>
> As for the programming model, I much prefer the 68000 over the
> 8086/8088, if we ignore compatibility issues (which tend to matter).
> Even if the 68000 had those annoying alignment issues (which tend to
> matter).
>
> Notice I wrote "68000" and "8086/8088".
>

Agreed, a delight to program at assembler level.

> Some of the 68K models used different exception stack frame formats than
> others, without having a compatibility flag.

But that doesn't matter, as 68k exceptions are fully vectored, so you
always know what generated the interrupt and shouldn't need to poll
registers or poke around in the entrails. Or am I missing something ?.
Ok, perhaps for debugging.

Last time I looked, even the arm cores, current darlings of the embedded
telephony and handheld device market, only had a basic 2 level interrupt
structure. Should imagine quite helpfull for real time multi
interrupting device work ^)...

Chris


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Prev: Software vs Hardware
Next: Searching for the PDP-3