Error in 64doc.txt at Bo's site?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Error in 64doc.txt at Bo's site?

Ruud
Hallo allemaal,

I'm building two TTL CPUs right now. For those who have no idea what I mean, have a look here: http://homebrewcpuring.org/
Please have a look at: http://www.6502.org/users/dieter/m02/m02.htm and http://www.6502.org/users/dieter/m02/system.jpg
Notice that this computer only emulates the C64 more or less.

My first TTL CPU has no Instruction Decoder which means every action that the CPU has to do has to be programmed. Advantage: you need less parts, disadvantage: you need (roughly) about ten times as much memory and it is twenty times as slow.

The second one has an Instruction decoder (ID) and should be able to emulate the 6502, although not cycle exact. The ID is made from seven FlashRAMs and needs to be filled with data of course. For this I am writing a program that analyses every step of every instruction and then sets or resets the according bits of the involved FRAM.
Now at this moment I am dealing with JSR. Next is the text for JSR from 64doc.txt found on Bo Zimmers site:

# address R/W description
--- ------- --- -------------------------------------------------
1 PC R fetch opcode, increment PC
2 PC R fetch low address byte, increment PC
3 $0100,S R internal operation (predecrement S?)
4 $0100,S W push PCH on stack, decrement S
5 $0100,S W push PCL on stack, decrement S
6 PC R copy low address byte to PCL, fetch high address
byte to PCH

What I read is: at step 1 and 2 the Program Counter is increased and thus points to the next instruction at step 4. So this is the address that is pushed to the stack at step 4 and 5.
But IMHO the PC is only incremented once before pushed to the stack. When RTS is executed, the stored address is read, written into the PC and increased according this document. Which prooves the incremental at step 2 is wrong.

Your comment, please.


--
  
Kind regards / Met vriendelijke groet, Ruud Baltissen
www.Baltissen.org





  
Reply | Threaded
Open this post in threaded view
|

Re: Error in 64doc.txt at Bo's site?

Francesco Messineo
It seems to me that if you don't increment PC at step 2, you can't
fetch the high address byte from memory at step 6. JSR is 3 bytes, so
three fetches from memory.
I could read that code wrong anyway.

On Wed, Sep 19, 2018 at 4:43 PM <[hidden email]> wrote:

>
> Hallo allemaal,
>
> I'm building two TTL CPUs right now. For those who have no idea what I mean, have a look here: http://homebrewcpuring.org/
> Please have a look at: http://www.6502.org/users/dieter/m02/m02.htm and http://www.6502.org/users/dieter/m02/system.jpg
> Notice that this computer only emulates the C64 more or less.
>
> My first TTL CPU has no Instruction Decoder which means every action that the CPU has to do has to be programmed. Advantage: you need less parts, disadvantage: you need (roughly) about ten times as much memory and it is twenty times as slow.
>
> The second one has an Instruction decoder (ID) and should be able to emulate the 6502, although not cycle exact. The ID is made from seven FlashRAMs and needs to be filled with data of course. For this I am writing a program that analyses every step of every instruction and then sets or resets the according bits of the involved FRAM.
> Now at this moment I am dealing with JSR. Next is the text for JSR from 64doc.txt found on Bo Zimmers site:
>
> # address R/W description
> --- ------- --- -------------------------------------------------
> 1 PC R fetch opcode, increment PC
> 2 PC R fetch low address byte, increment PC
> 3 $0100,S R internal operation (predecrement S?)
> 4 $0100,S W push PCH on stack, decrement S
> 5 $0100,S W push PCL on stack, decrement S
> 6 PC R copy low address byte to PCL, fetch high address
> byte to PCH
>
> What I read is: at step 1 and 2 the Program Counter is increased and thus points to the next instruction at step 4. So this is the address that is pushed to the stack at step 4 and 5.
> But IMHO the PC is only incremented once before pushed to the stack. When RTS is executed, the stored address is read, written into the PC and increased according this document. Which prooves the incremental at step 2 is wrong.
>
> Your comment, please.
>
>
> --
>
> Kind regards / Met vriendelijke groet, Ruud Baltissen
> www.Baltissen.org
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Error in 64doc.txt at Bo's site?

Segher Boessenkool
In reply to this post by Ruud
On Wed, Sep 19, 2018 at 04:26:24PM +0200, [hidden email] wrote:

[ some html email, which is hard to reply to... ]

Ah, jsr, one of the most interesting instructions :-)

The address stored is the address of the next insn minus one, i.e. the
address of the jsr plus two.

>  1 PC R fetch opcode, increment PC
>  2 PC R fetch low address byte, increment PC
>  3 $0100,S R internal operation (predecrement S?)
>  4 $0100,S W push PCH on stack, decrement S
>  5 $0100,S W push PCL on stack, decrement S
>  6 PC R copy low address byte to PCL, fetch high address
>  byte to PCH
>  What I read is: at step 1 and 2 the Program Counter is increased and thus
>  points to the next instruction at step 4. So this is the address that is
>  pushed to the stack at step 4 and 5.
>  But IMHO the PC is only incremented once before pushed to the stack. When
>  RTS is executed, the stored address is read, written into the PC and
>  increased according this document. Which prooves the incremental at step 2
>  is wrong.

That's not what the CPU really does.  It does:

00100000  jsr
2  S->ADL->ABL  1->ADH->ABH  DL->S  ADL->
3  ->ADL->ABL  PCH->DB  WR  ADL-1->
4  ->ADL->ABL  PCL->DB  WR  ADL-1->
5  fetch  ->
0  ->S, S->ADL->ABL,PCL  DL->ADH->ABH,PCH

(and at 0 and 1 there are fetches, as for everything).  Your cycles start
counting at 1.

>  1 PC R fetch opcode, increment PC
>  2 PC R fetch low address byte, increment PC

These are correct, of course.

>  3 $0100,S R internal operation (predecrement S?)

2  S->ADL->ABL  1->ADH->ABH  DL->S  ADL->

Save the low address fetched (in the previous cycle) to S; the actual
stack pointer is copied to ADL, which is also needed for actually
addressing the stack (in later cycles).  There is no "predecrement".
ADL (i.e. the stack pointer) is moved to the ALU output, the "holding
register", which is the only non-architected dataflow reg in the whole
CPU.

>  4 $0100,S W push PCH on stack, decrement S

3  ->ADL->ABL  PCH->DB  WR  ADL-1->

And here that ALU output is moved to the low address byte.  PCH is written
to that address.  ADL is decreased, that is the ALU output.

>  5 $0100,S W push PCL on stack, decrement S

4  ->ADL->ABL  PCL->DB  WR  ADL-1->

And analogous with PCL.

>  6 PC R copy low address byte to PCL, fetch high address byte to PCH

5  fetch  ->

Fetch the data byte, and retain the value in the ALU output.

0  ->S, S->ADL->ABL,PCL  DL->ADH->ABH,PCH

Every instruction ends with phases 0 and 1, which overlaps the fetches
of the next insn's first two bytes (so it does nothing on the external
buses).

Move the ALU output (from the previous cycles) to the S register (it now
has been decreased twice).  At the same time, move what was in S (which
is the low dest address fetched) to the low address bus and PCL, and
move what was fetched in the previous cycles (the high dest address) to
the high address bus and PCH.  This is the address that we fetch from
for the next insn.

Let me paste the stuff for rts too, without explanation:

01100000  rts
2  S->ADL->ABL  1->ADH->ABH  ADL+1->
3  ->ADL->ABL  ADL+1->
4  ->ADL->ABL, ->S  DL->
5  ->ADL->ABL  DL->ADH->ABH

Pretty :-)


Segher

Reply | Threaded
Open this post in threaded view
|

Re: Error in 64doc.txt at Bo's site?

John McKenna
In reply to this post by Ruud
Those internal operations were speculation.  I remember JSR being one of the more baffling instructions - Marko and I had a long discussion about it, of which I remember none of the details, except for a feeling that we hadn't ever really understood it.  Now that we have Visual6502, it should be possible to find out the truth.


From: [hidden email] <[hidden email]>
Sent: 19 September 2018 14:26
To: [hidden email]
Subject: Error in 64doc.txt at Bo's site?
 
Hallo allemaal,

I'm building two TTL CPUs right now. For those who have no idea what I mean, have a look here: http://homebrewcpuring.org/
Please have a look at: http://www.6502.org/users/dieter/m02/m02.htm and http://www.6502.org/users/dieter/m02/system.jpg
Notice that this computer only emulates the C64 more or less.

My first TTL CPU has no Instruction Decoder which means every action that the CPU has to do has to be programmed. Advantage: you need less parts, disadvantage: you need (roughly) about ten times as much memory and it is twenty times as slow.

The second one has an Instruction decoder (ID) and should be able to emulate the 6502, although not cycle exact. The ID is made from seven FlashRAMs and needs to be filled with data of course. For this I am writing a program that analyses every step of every instruction and then sets or resets the according bits of the involved FRAM.
Now at this moment I am dealing with JSR. Next is the text for JSR from 64doc.txt found on Bo Zimmers site:

# address R/W description
--- ------- --- -------------------------------------------------
1 PC R fetch opcode, increment PC
2 PC R fetch low address byte, increment PC
3 $0100,S R internal operation (predecrement S?)
4 $0100,S W push PCH on stack, decrement S
5 $0100,S W push PCL on stack, decrement S
6 PC R copy low address byte to PCL, fetch high address
byte to PCH

What I read is: at step 1 and 2 the Program Counter is increased and thus points to the next instruction at step 4. So this is the address that is pushed to the stack at step 4 and 5.
But IMHO the PC is only incremented once before pushed to the stack. When RTS is executed, the stored address is read, written into the PC and increased according this document. Which prooves the incremental at step 2 is wrong.

Your comment, please.


--
  
Kind regards / Met vriendelijke groet, Ruud Baltissen
www.Baltissen.org





  
Reply | Threaded
Open this post in threaded view
|

Re: Error in 64doc.txt at Bo's site?

Groepaz
Am Donnerstag, 20. September 2018, 09:27:59 CEST schrieb John McKenna:
> Those internal operations were speculation.  I remember JSR being one of the
> more baffling instructions - Marko and I had a long discussion about it, of
> which I remember none of the details, except for a feeling that we hadn't
> ever really understood it.  Now that we have Visual6502, it should be
> possible to find out the truth.

a lot of the C64 docs from those days should be taken with a HUGE spook of
salt. there is often a lot of guessing and half-true things - and
unfortunately not always it is pointed out as such. 64doc iirc also had a
section about illegal opcodes which is... uhm. lets say vague :=)

--

http://hitmen.eu                 http://ar.pokefinder.org
http://vice-emu.sourceforge.net  http://magicdisk.untergrund.net

An atheist doesn't have to be someone who thinks he has a proof that there
can't be a god. He only has to be someone who believes that the evidence on
the God question is at a similar level to the evidence on the werewolf
question.
<John McCarthy>





Reply | Threaded
Open this post in threaded view
|

Re: Error in 64doc.txt at Bo's site?

Marko Mäkelä
On Thu, Sep 20, 2018 at 09:14:17PM +0200, [hidden email] wrote:
>Am Donnerstag, 20. September 2018, 09:27:59 CEST schrieb John McKenna:
>>Those internal operations were speculation.  I remember JSR being one
>>of the more baffling instructions - Marko and I had a long discussion
>>about it, of which I remember none of the details, except for a
>>feeling that we hadn't ever really understood it.  Now that we have
>>Visual6502, it should be possible to find out the truth.

I remember using the CIA as a measurement tool for some instructions,
and in 1993 for measuring the conflict between the execution of a BRK
instruction and the occurrence of IRQ or NMI.

Reading from the interrupt flag register ($dcxd or $ddxd) would have a
side effect of clearing the register. One of the tricks was to write the
instruction bytes to CIA registers and then JMPing to the CIA, to let
the "instruction under test" to be fetched from there. Maybe I even let
the instruction and operands to be fetched from the timer registers, so
that based on the behaviour I would know at which cycle the read
occurred.

Later, in 1995 or 1996, I wrote two test programs that fetch instruction
data from open address space ($de00-$dfff or the most significant
nibbles of the colour RAM at $d800-$dbff). The program "dadb" would
mostly exercise the RTS instruction ($60) by filling the stack with the
byte $da, and making the RTS jump to $dadb most of the time. I cannot
remember if it exercised the JSR instruction.

Obviously I cannot remember details from 25 years ago very well. I would
however be rather certain that the read and write cycles that we
documented for the JSR instruction correspond to reality. I had no
knowledge of the internals of the 6502 back then (such as the
instruction decoding), so it was a result of experimenting and guessing
on my part.

>a lot of the C64 docs from those days should be taken with a HUGE spook
>of salt. there is often a lot of guessing and half-true things - and
>unfortunately not always it is pointed out as such. 64doc iirc also had
>a section about illegal opcodes which is... uhm. lets say vague :=)

I do not think that I contributed to the section about undocumented
opcodes. Maybe it was written by Jouko Valta, one of the original
authors of x64?

        Marko

Reply | Threaded
Open this post in threaded view
|

Re: Error in 64doc.txt at Bo's site?

Groepaz
Am Samstag, 22. September 2018, 11:24:05 CEST schrieb Marko Mäkelä:

> I do not think that I contributed to the section about undocumented
> opcodes. Maybe it was written by Jouko Valta, one of the original
> authors of x64?

that name sounds familiar :) iirc that section was a collection from various
sources that were around at that time.

PS: those test programs of yours ended up here:
https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/C64/openio/ :)

--

http://hitmen.eu                 http://ar.pokefinder.org
http://vice-emu.sourceforge.net  http://magicdisk.untergrund.net

Rock journalism is people who can't write, interviewing people who can't talk,
for the benefit of people who can't read.
<Frank Zappa>





Reply | Threaded
Open this post in threaded view
|

Re: Error in 64doc.txt at Bo's site?

John McKenna
In reply to this post by Marko Mäkelä


>[...]I would 
>however be rather certain that the read and write cycles that we
>documented for the JSR instruction correspond to reality.

The bus activity came from a logic analyser, so barring any transcription errors it should be correct.