Jump to content
IGNORED

What does this read cycle do?


ralphb

Recommended Posts

While testing a few things with the FinalGROM 99, I caught some strange-looking (to me) bus signals, which I recorded with my logic analyzer (attached to the side port, for simplicity).

 

post-35214-0-51839100-1513022877_thumb.png

 

Read cycle (A) is a read access to the FinalGROM's GPL header. You'll notice that the entire MEMEN* cycle is longer than 2 us, and that some short WE* burst precedes the actual read access (DBIN high for 2us). What the hell is that write doing there? Not every cart read access has this extra write ...

 

But these short writes do seem fairly common. In cycle (B) I caught another write followed by a read, again to the same address (only LSB A0 is shown in the graph).

 

Can someone explain to me what is happening here? I've heard of read-before-write, but not the other way around ...

 

Link to comment
Share on other sites

Yes, phi3 was my initial thought as well, but I was kind of reluctant to (somewhat painfully) rewire my test harness. But I'll try it tonight.

 

The first address read (A) is somewhere in >6000->6020 (hence the consecutive reading of two bytes). I have no idea what (B) reads (I cannot capture the entire address bus), but it looks like just one byte.

Link to comment
Share on other sites

Judging from the specification, I'd say you cannot read a single byte with the TMS9900; you should always have a two-pass access*. I already thought about some CRU activity, but it does not involve WE*.

 

The scope output is a bit strange. Ah, OK, A0 is your LSB? This was a bit confusing for me; I thought I saw an access to 8xxx or 9xxx at (A).

 

[Edit: *You can have a single pass when accessing ROM (0x0000-0x1FFF) or Scratch Pad (0x83xx). It would be helpful to see the address MSB, though.]

Edited by mizapf
Link to comment
Share on other sites

Here's the same segment with phi3 and the upper (MSB) four address lines. At least the signals seem consistent for each run.

 

post-35214-0-27964400-1513091409_thumb.png

 

Note that I'm sampling with 25 MHz, which implies that each signal transition (i.e., vertical line) could be off by 40 ns in each direction. Still, the WE* pulse is 340 ns wide and thus not a figment of the measurement. And looking at phi3, it seems that this is business as usual for the TI.

 

The address of the write seems to be >8???. Could this be the result of an access by operand *Rn+, where registers are located in scratchpad RAM >83xx? Still, it's odd that it's in the same MEMEN* cycle.

 

Link to comment
Share on other sites

MSB=1 could also mean 9xxx (for GROM), but I just noticed that A12 is also 0, so it is indeed 8xxx. If you're adventurous, you could redo it with A11-A8. Just to make sure.

 

If your workspace is 8300 and you have a *Rx+, you will have a write operation (with a single cycle, as it is scratchpad).

 

Concerning MEMEN*, maybe it returned to inactive for a short time which is not sensed by the sample rate.

Link to comment
Share on other sites

MSB=1 could also mean 9xxx (for GROM), but I just noticed that A12 is also 0, so it is indeed 8xxx. If you're adventurous, you could redo it with A11-A8. Just to make sure.

 

If your workspace is 8300 and you have a *Rx+, you will have a write operation (with a single cycle, as it is scratchpad).

 

Concerning MEMEN*, maybe it returned to inactive for a short time which is not sensed by the sample rate.

 

I haven't had a chance to look at the captures in detail, but based on mizapf's comment, Thierry Nouspikel does indeed note that there are back-to-back cycles where memen* does NOT go high. have a look at http://www.unige.ch/medecine/nouspikel/ti99/wait.htm- step 10 under the first capture mentions this.

 

Does this describe the captured condition?

  • Like 2
Link to comment
Share on other sites

Add this highly addictive stuff?

 

Ralph certainly knows them, I don't know about the others. I'm living here in Nuremberg at their natural source, where you get them from bakeries, rather than from the retail seller in cardboard with shrinkwrap. The missing part is just being eaten. :-)

 

And ... OMG ... (have to finish eating first)

 

 

post-35000-0-92237500-1513112535_thumb.jpg

  • Like 2
Link to comment
Share on other sites

Would be useful to capture IAQ as well.

 

Could it be something like:

 

-- The first write in the capture is the end of the previous instruction - ignore it.

 

-- Starting at 6us its reading an *instruction* from >6xxx, first the odd byte then at 7us the even byte.

 

-- The instruction is something like INC Rx, where the workspace pointer is set to >8xxx. At 8.5us it reads the value of Rx. (The LS address bit is high but as this is 16-bit memory that doesn't matter?) At 10us (0us) it writes the new value of Rx back.

Link to comment
Share on other sites

Back on topic, Thierry does explain that MEMEN* might not go high between parts of two different instructions. His example is

.

LOOP MOV @>2000,R0
     JMP LOOP

.

where the writing of R0 and the fetching of the JMP opcode happens in the same MEMEN* cycle. :-o

 

So it might be just as you said, Stuart. I certainly learned something today.

Link to comment
Share on other sites

MMMMMMMMMMM. . .Lebkuchen.

 

Yes ... it is often translated as "gingerbread", but I think it is not really the same. Also, these are Elisen-Lebkuchen which have highest quality (by legal regulation), and this year, on the Christkindlesmarkt, are sold for €2,20 a piece, that is US$2.58.

 

[Edit: Promised, we'll now return to the topic. ;) ]

Edited by mizapf
  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...