For anybody who ever wondered what exactly the 8088 was doing
while it was wast^H^H^H^Husing four cycles per memory access,
here's an interesting article:

http://www.righto.com/2024/04/intel-8088-bus-state-machine.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thomas Koenig wrote:

For anybody who ever wondered what exactly the 8088 was doing
while it was wast^H^H^H^Husing four cycles per memory access,
here's an interesting article:

http://www.righto.com/2024/04/intel-8088-bus-state-machine.html

That was fun, thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thomas Koenig wrote:

For anybody who ever wondered what exactly the 8088 was doing
while it was wast^H^H^H^Husing four cycles per memory access,
here's an interesting article:

http://www.righto.com/2024/04/intel-8088-bus-state-machine.html

I always thought the 4 cycles was inherited from the 8080/Z80 cpus and
their support chips which the PC was going to use.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

BGB wrote:

Seems like probably in a similar area as QSPI RAM.

Quick skim, looks like QSPI RAM access looks something like:
Pull CS low;
Send command byte;
Send address bytes (4);
Send/receive data bytes;
CS goes high when transfer is done;
CS going high apparently puts the chip back in its idle state.

If you do a 16-byte burst, this would be ~ 1.4 cycles (DDR) per data
byte, or 2.8 cycles if driving it from a faster SDR clock. A datasheet
for a random QSPI RAM chip I found suggests it has a maximum operating frequency of around 54 MHz (so, a little lower than the DDR chips), and
a lot are apparently "pseudo static" (they are DRAM internally, but also perform their own RAM refresh, appearing as SRAM from the POV of the
external bus interface).

You are forgetting that DRAM RAS occurs after the first 2 address bytes
are latched, and that CAS occurs after the second 2 address bits are
latched {and that you are in a deRAS deCAS state already.}

QSPI at 54 Mhz is just under 20ns per DRAM address/command event not that
much different than current DDRs

But what current DDRs can do is to partially overlap address/command with
data transfer--I would suspect QSPI could do this too.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 15 May 2024 21:41:32 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:

BGB wrote:

Seems like probably in a similar area as QSPI RAM.

Quick skim, looks like QSPI RAM access looks something like:
Pull CS low;
Send command byte;
Send address bytes (4);
Send/receive data bytes;
CS goes high when transfer is done;
CS going high apparently puts the chip back in its idle state.

If you do a 16-byte burst, this would be ~ 1.4 cycles (DDR) per
data byte, or 2.8 cycles if driving it from a faster SDR clock. A
datasheet for a random QSPI RAM chip I found suggests it has a
maximum operating frequency of around 54 MHz (so, a little lower
than the DDR chips), and a lot are apparently "pseudo static" (they
are DRAM internally, but also perform their own RAM refresh,
appearing as SRAM from the POV of the external bus interface).

You are forgetting that DRAM RAS occurs after the first 2 address
bytes are latched, and that CAS occurs after the second 2 address
bits are latched {and that you are in a deRAS deCAS state already.}

We are talking about 1978 here. Back then, it was 7-bit raw addres
and 7-bit column addresss. I don't know how they applied address bits
above A13. Later on there were chip select and/or output enable signals,
but circa-1978 16-bit DRAM had neither of those. So, it seems, if one
wanted to put more than 16 KB on 8-bit bus, one had to generated
multiple sets of RAS# and CAS# signals.

Since then # of rows, first per DRAM chip and later per bank, grew tremendously, but number of columns only grew by factor of 8 and
remains the same for more than 20 years.

QSPI at 54 Mhz is just under 20ns per DRAM address/command event not
that much different than current DDRs

But what current DDRs can do is to partially overlap address/command
with data transfer--I would suspect QSPI could do this too.

Partially?
With typical CL=14==28T, and with burst that just recently was
increased to 16T and before that stayed at 8T for more than decade, I'd
say that it's full overlap ++.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/15/24 3:30 PM, BGB wrote:

In my case, I hadn't found much information about accessing SDcards in anything other than SPI mode, but I guess if it turns out it is
basically just QSPI and the same byte-oriented protocol as before, that
would be useful to know.

The SD card specification covers both in detail.

But the 4 bit wide SD access will depend a lot on what hardware support
you have. I used an ARM (in a Teensy 3.2) to do the job. Mostly quite
similar to SPI access.


--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/15/24 6:48 PM, BGB wrote:

When looking around before, I generally only found people talking about
the SPI interfaces. Granted, I didn't have the official specifications
(which seemed to be paywalled and not generally available otherwise). I mostly implemented stuff based on information I found on various websites.

Parts of it are/were paywalled but the interesting bit hasn't been. At
least as far back as SD 1.0.

https://www.sdcard.org/downloads/pls/

I am not sure which one of those is the one to look at. Probably the one
with the 9.1 revision level.

--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S wrote:

We are talking about 1978 here. Back then, it was 7-bit raw addres
and 7-bit column addresss. I don't know how they applied address bits
above A13. Later on there were chip select and/or output enable signals,
but circa-1978 16-bit DRAM had neither of those. So, it seems, if one
wanted to put more than 16 KB on 8-bit bus, one had to generated
multiple sets of RAS# and CAS# signals.

Yes. I'm looking at a 1979 Motorola Memory book and both the
16k*1 MCM4116A and 64k*1 MCM6664 were 16 pin packages without
chip select. You controlled them by gating the RAS and CAS.
At access time after CAS the output switches from high-z to valid data,
so at least you can just wire the outputs together.

The 4116A's were a pain because they required power of +12V, +5V, -5V, GND
(but so did the 8080) but the power supplies often only produce +5V
so you had to use voltage pumps for +12V and -5V, and those pumps were
really inefficient and got really hot, so now you needed a fan too.

The 6664's only required 5V and GND.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/16/24 4:21 PM, BGB-Alt wrote:

Seems I was wrong about something before:
The combination of CMD0+CS is what selects SPI mode (for normal SD mode,
the CS signal would not be asserted).
I was mistaken in thinking that it was the stream of FF bytes and then asserting CS near the end (say, the init procedure for the SDcard
involving sending a large number of FF bytes at a fairly low speed, then sending some other commands and boosting the speed to the intended
operating speed).

The low speed was a holdover from its previous life as the MMC card
standard. (I still have a 64MB MMC card.) Which were intended to be a multi-drop solution. As such some of the signal lines were
open-drain/collector so the speed was limited by the pullup resistor and parasitic capacitance.


--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)