YACHT, MULU # and an extra program fetch

All 680x0 related coding posts in this section please.

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

TomH
Atarian
Atarian
Posts: 7
Joined: Fri Mar 08, 2019 3:47 pm

YACHT, MULU # and an extra program fetch

Postby TomH » Wed Apr 17, 2019 10:33 pm

Continuing to trawl through yacht.txt, I spotted the following as the bus pattern for MULU and MULS #,Dn:

Code: Select all

    #<data>    | 38+2m(1/0)  8(2/0) |   np np       |               np       n*


... which confuses me because MULU # is a two-word instruction, allowing only a 16-bit argument, and none of the other addressing modes seem to generate a bonus program fetch. So what's the purpose of the third program fetch, and where is it from?

ijor
Hardware Guru
Hardware Guru
Posts: 3783
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: YACHT, MULU # and an extra program fetch

Postby ijor » Thu Apr 18, 2019 2:28 am

Yacht is wrong. There is no third prefetch cycle.
Fx Cast: Atari St cycle accurate fpga core

TomH
Atarian
Atarian
Posts: 7
Joined: Fri Mar 08, 2019 3:47 pm

Re: YACHT, MULU # and an extra program fetch

Postby TomH » Thu Apr 18, 2019 3:15 am

Thanks for clearing that up; I've noticed that the document is self-contradictory about TRAP also, so am now doubly disabused of any belief in its perfection. Luckily the proper execution of TRAPs has already been covered here.

wietze
Captain Atari
Captain Atari
Posts: 239
Joined: Fri Mar 01, 2013 10:52 pm

Re: YACHT, MULU # and an extra program fetch

Postby wietze » Thu Apr 18, 2019 8:47 am

ijor wrote:Yacht is wrong. There is no third prefetch cycle.


Is there an errata on Yacht?

ijor
Hardware Guru
Hardware Guru
Posts: 3783
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: YACHT, MULU # and an extra program fetch

Postby ijor » Thu Apr 18, 2019 12:24 pm

TomH wrote:Thanks for clearing that up; I've noticed that the document is self-contradictory about TRAP also, so am now doubly disabused of any belief in its perfection. Luckily the proper execution of TRAPs has already been covered here.


MULU mistake is probably just a typo. I didn't check Yacht 's TRAP section, but I wouldn't be surprised if it is wrong. Yacht is mostly based on the famous Motorola patent that discloses the 68K microcode. But the patent description of the exception microcode is not accurate.

wietze wrote:Is there an errata on Yacht?


Don't know. I never checked Yacht document in details; so I can't say if there are further mistakes or not. To be honest, I wasn't even aware about Yacht until somebody mentioned it here a couple of years ago.
Fx Cast: Atari St cycle accurate fpga core

TomH
Atarian
Atarian
Posts: 7
Joined: Fri Mar 08, 2019 3:47 pm

Re: YACHT, MULU # and an extra program fetch

Postby TomH » Thu Apr 18, 2019 4:06 pm

It's a bit of a weird document all around to be honest; it is primarily about what you'd observe on a bus, but slightly overlapping into what's going on inside the 68000. If you're interested in 68000 internals then there's quite a lot of deduction involved. Though I think it gets you 80% of the way there — if you're mainly interested in writing code and can therefore decide not to trigger any exceptions then it's more like 95%.

That aside, for completeness on TRAP:

Its documentation as an instruction gives a data bus usage pattern of nn ns nS ns np np np np. Which means [no bus usage] [stack push of a low word] [stack push of a high word] [stack push of a low word] [four program fetches].

But down in the separate exception processing execution times section it instead offers nn ns ns nS nV nv np np. The nvs rather than nps mean "vector fetch", so probably just a terminology switch, but the order of stack operations has mysteriously changed. And now contradicts the text immediately below: "First are pushed on the stack the program counter high and low words then the status register." (taking 'first' to mean chronologically, anyway).

Based on this comment to a previous thread here I've assumed that 'ns ns nS' is correct and write order is PC.l to (sp - 2), then SR to (sp - 6), then PC.l to (sp - 4).

mlynn1974
Captain Atari
Captain Atari
Posts: 264
Joined: Mon Mar 03, 2008 10:33 pm
Contact:

Re: YACHT, MULU # and an extra program fetch

Postby mlynn1974 » Thu Apr 18, 2019 8:59 pm

There is also a clock cycle reference sheet in this book:
MC68000 Assembly Language Programming by Bramen and Bramen
https://www.amazon.co.uk/MC68000-Assemb ... rogramming

I'm not sure how accurate it is. Instead of using these crazy text files wouldn't it be great to have a program that you just type in the line of code and it'll tell you how many clock cycles it will take? Doesn't STEEM boiler room give an estimate?
Still got, still working: Atari 4Mb STe, 520STFM, 2.5Mb STF.
Hardware: Cumana CSA 354, Ultimate Ripper, Blitz Turbo, Synchro Express II (US and UK Versions).

ijor
Hardware Guru
Hardware Guru
Posts: 3783
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: YACHT, MULU # and an extra program fetch

Postby ijor » Fri Apr 19, 2019 1:10 am

TomH wrote:It's a bit of a weird document all around to be honest; it is primarily about what you'd observe on a bus, but slightly overlapping into what's going on inside the 68000. If you're interested in 68000 internals then there's quite a lot of deduction involved.


Bus timing and order is important for several reasons. In most cases when accessing memory it doesn't matter. But when hardware is accessed, the order and the timing might be relevant. Even when accessing RAM, if i.e., the access triggers a bus error, the order is important. The exact timing of the bus cycles might be important as well. In the ST, a RAM access might produce pairing or not depending on the exact cycle that the bus access is performed (search the forum for pairing if you are not familiar with the concept).

If you are really interested in the 68000 internals, especially if you want to understand the "why" and not just the "how" and the "when", then studying the microcode is essential.

If you want to check a specific instruction sequence, then may I modestly suggest to perform a simulation with my FPGA core (FX68K). You don't need any FPGA hardware. You simulate on a standard PC. You don't even need to know anything about FPGAs. My core is based on the real microcode, not on the one described on the patent. It should be cycle exact. See below for what you can easily do ...

That aside, for completeness on TRAP:
...
Based on this comment to a previous thread here I've assumed that 'ns ns nS' is correct and write order is PC.l to (sp - 2), then SR to (sp - 6), then PC.l to (sp - 4).


This is exactly what happens when executing a TRAP instruction:

FX-Trap-SimulWaveform.jpg


The TRAP instruction executes between both yellow vertical guides, from cycle 42 to 76. Bus cycles 8 to 14 inclusive. The TRAP instruction is located at address $FC0022, and the stack pointer was initialized to $40002. TRAP vector is $fa8050

During the first 3 bus cycle of the instruction the CPU pushes the exception frame, then it reads the exception vector, and finally performs the prefetch of two words.

Edit: Fixed SP initialization typo.
You do not have the required permissions to view the files attached to this post.
Fx Cast: Atari St cycle accurate fpga core

TomH
Atarian
Atarian
Posts: 7
Joined: Fri Mar 08, 2019 3:47 pm

Re: YACHT, MULU # and an extra program fetch

Postby TomH » Fri Apr 19, 2019 1:27 am

ijor wrote:
TomH wrote:It's a bit of a weird document all around to be honest; it is primarily about what you'd observe on a bus, but slightly overlapping into what's going on inside the 68000. If you're interested in 68000 internals then there's quite a lot of deduction involved.


Bus timing and order is important for several reasons. In most cases when accessing memory it doesn't matter. But when hardware is accessed, the order and the timing might be relevant. Even when accessing RAM, if i.e., the access triggers a bus error, the order is important. The exact timing of the bus cycles might be important as well. In the ST, a RAM access might produce pairing or not depending on the exact cycle that the bus access is performed (search the forum for pairing if you are not familiar with the concept).


Agreed entirely, and to answer the other poster: this is why I keep referring yacht.txt as part of my 68000 education. The bus activity matters; that it usually gives you enough information to make reasonable deductions about the internals is useful but it leaves the odd dangling issue such as the one that kicked off this thread.

My comments re: yacht.txt are merely that perhaps the text might be have benefitted if the author had decided either that he just wanted to provide a guide to bus activity, in which case noting which writes are high words and which are low is unnecessary, or alternatively that he wanted to provide information about the internals, such as what is written when, in which case there are many dangling ambiguities.

There are plenty of occasions on which the 68000 fetches when it doesn't logically need to — e.g. during any CLR, as noted on p4-74 in the Programmers' Reference Manual — so no reason to discount an apparently-unnecessary fetch.

I'm grateful for the highly-knowledgeable feedback and will definitely look into FPGA emulation to discover whether I can figure that stuff out.

EDIT: regarding the provided trace, presumably $402 is a typo for $40002? No need to reply if so, it seems clear from context and I've worn out my welcome. Thanks again for the help!

danorf
Atari maniac
Atari maniac
Posts: 81
Joined: Tue Feb 12, 2013 1:18 pm
Location: Behind a computer

Re: YACHT, MULU # and an extra program fetch

Postby danorf » Mon May 06, 2019 4:32 pm

Hello,

First thank you for your interest in these little piece of doc Yacht was (and still is ?).

I confirm the typo for the MULU #<data> line.
I made a wrong copy/paste for the <ea> exec time (got the line from the .L section and not from the .W section).
The line should read :
#<data> | 38+2m(1/0) 4(1/0) | np | np n*

As I initially stated in the topic where I originally posted this file (http://www.atari-forum.com/viewtopic.php?f=68&t=24710#p227267), I'm sure it's far from perfect. Primary because this table was a re-work of many documents (some in propriary format, some still partially handwritten) and was only re-read by its writer (me) and secondly because English is not my first language and the texts I wrote could be unclear.

The primary goal of these documents was to provide to a 68000 programmer a practical view of the timing of instructions, to explain a further more the numbers you could find in the 68000UM, by tracing when and in which order data are read or write (LSB/LSW first or MSB/MSW first) and when prefetches occure. The order of read and write was important when programming a 68000 to work with co-processors. The occurrence of prefetch was important when using some self modfying code (and other nasty tricks of these days of paleo-computering).

On the original documents, there was also a section on /DTACK (grounded or not) that never maked its way to the yacht doc.

At the time the original documents were written, we had a very few tools to understand how this processor worked and, yes, the patent and the official manuals were our primary source of knowledge. As far as I can say, more of the guess we have done from these documents were tested on real hardware (except from the exceptions, I think).

As for the exception (and as I stated in the original post), they always kept a smell of magic to the team that wrote the original documents.
As you stated, the document is self-contradictory about some exceptions between instruction section and exception section. It's probably all my fault misreading source documentation, but our work was, by far, more imprecise on this part than on the "standard instructions".

Nowaday with the excellent work of ijor on his FPGA core, i don't know if this yacht file is still of any interest, but if it is, as I stated in the initial post feel free to correct it and improve it. For me It's more than past history, now.

Enough of good old days for this time. Cheers ! :cheers:

ijor
Hardware Guru
Hardware Guru
Posts: 3783
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: YACHT, MULU # and an extra program fetch

Postby ijor » Wed May 08, 2019 1:20 am

danorf wrote:First thank you for your interest in these little piece of doc Yacht was (and still is ?).


Hi danorf, good do see you here, it is always nice to get answers from the source :)

As I said, I wasn't aware about Yatch until rather recently, long after I studied the patent. It would have saved me some time I knew it then. But I do know it was a very valuable documentation to many programmers.

As for the exception (and as I stated in the original post), they always kept a smell of magic to the team that wrote the original documents.


The exception microcode at the patent is not accurate. I think this confused many people, including myself when I studied the patent. I intend to write some article about this, but unfortunately I haven't find the time so far. However, if you are curious, you can see one interesting detail in the simulation waveform I posted. There is an idle microcycle just before the last prefetch, at clock cycles 70 to 72. This microcycle is missing at the patent.

Cheers
Fx Cast: Atari St cycle accurate fpga core


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 2 guests