Work on the Minimig core?

https://github.com/mist-devel/mist-board/wiki

Moderators: Mug UK, Zorro 2, Greenious, spiny, Moderator Team

apolkosnik
Atari freak
Atari freak
Posts: 70
Joined: Sat May 18, 2019 3:20 pm

Re: Work on the Minimig core?

Postby apolkosnik » Tue Nov 19, 2019 1:32 am

tobiflex wrote:I have implement my first try of the CHK2 and CMP2 Instructions here: https://github.com/TobiFlex/TG68K.C

But I need help here. Do these instructions do what they should? Who can write examples or test code?
cputester stop with false N- or V- Flag. But this is undefined behavior.


@tobiflex, you can use ccrmask as the last param to ignore the Flags.
e.g. cputest all abcd.b ccrmask or
cputest all abcd.b continue ccrmask

slingshot
Atari God
Atari God
Posts: 1351
Joined: Mon Aug 06, 2018 3:05 pm

Re: Work on the Minimig core?

Postby slingshot » Thu Nov 21, 2019 8:23 am

@tobiflex I've looked at the timing analysis of the tg68k, and there's a very long combinatorial path in the barrel shifter: the one which involves a hardware divider (inferred by the rem operator). This can fail even at 28MHz. I think it would be wise either to get rid of it somehow (if possible) or pipeline that long calculation into more cycles.

User avatar
MasterOfGizmo
Atari God
Atari God
Posts: 1311
Joined: Fri Feb 08, 2013 12:15 pm
Contact:

Re: Work on the Minimig core?

Postby MasterOfGizmo » Fri Nov 22, 2019 12:52 pm

slingshot wrote:I think it would be wise either to get rid of it somehow (if possible) or pipeline that long calculation into more cycles.


Uh ... for a second I was afraid my old barrell shifter was still lurking in Tobis code. But he has his own barrell shifter.

I think you can simply disable it by option:
https://github.com/TobiFlex/TG68K.C/blob/master/TG68KdotC_Kernel.vhd#L101

Anyway, pipelineing it basically means to return to a regular shifter. Perhaps something in-between makes sense. In the end a higher clocked core with a multi stage shifter might still shift faster than a lower clocked one with a single stage barrell shifter.
MIST board, FPGA based Atari STE and more: https://github.com/mist-devel/mist-board/wiki

slingshot
Atari God
Atari God
Posts: 1351
Joined: Mon Aug 06, 2018 3:05 pm

Re: Work on the Minimig core?

Postby slingshot » Fri Nov 22, 2019 5:36 pm

MasterOfGizmo wrote:
Anyway, pipelineing it basically means to return to a regular shifter. Perhaps something in-between makes sense. In the end a higher clocked core with a multi stage shifter might still shift faster than a lower clocked one with a single stage barrell shifter.

I just think about split to two phases - the whole calculation is ~36ns, it's more than the 28MHz system clock period!
But 1/4 of this is the inferred divider - if it can be spared, then it'll be good enough.
Or just split into two phases, that won't reduce the speed considerably, I think.

User avatar
MasterOfGizmo
Atari God
Atari God
Posts: 1311
Joined: Fri Feb 08, 2013 12:15 pm
Contact:

Re: Work on the Minimig core?

Postby MasterOfGizmo » Sat Nov 23, 2019 7:45 am

There is an inferred divider? What does the shifter need a divider for?
MIST board, FPGA based Atari STE and more: https://github.com/mist-devel/mist-board/wiki

slingshot
Atari God
Atari God
Posts: 1351
Joined: Mon Aug 06, 2018 3:05 pm

Re: Work on the Minimig core?

Postby slingshot » Sat Nov 23, 2019 9:35 am

MasterOfGizmo wrote:There is an inferred divider? What does the shifter need a divider for?

Not sure, but I think calculating the effective shift count based on the operand size and the given shift count:
https://github.com/TobiFlex/TG68K.C/blo ... U.vhd#L841

tobiflex
Atariator
Atariator
Posts: 29
Joined: Thu Oct 17, 2019 7:00 am

Re: Work on the Minimig core?

Postby tobiflex » Sat Nov 23, 2019 9:41 am

slingshot wrote:@tobiflex I've looked at the timing analysis of the tg68k, and there's a very long combinatorial path in the barrel shifter: the one which involves a hardware divider (inferred by the rem operator). This can fail even at 28MHz. I think it would be wise either to get rid of it somehow (if possible) or pipeline that long calculation into more cycles.

OK, I hope I can find a way

slingshot
Atari God
Atari God
Posts: 1351
Joined: Mon Aug 06, 2018 3:05 pm

Re: Work on the Minimig core?

Postby slingshot » Sat Nov 23, 2019 10:18 am

tobiflex wrote:OK, I hope I can find a way

Great, thank you!

fpgaarcade
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 104
Joined: Thu Sep 20, 2007 10:06 pm
Location: Sweden

Re: Work on the Minimig core?

Postby fpgaarcade » Sat Nov 23, 2019 6:25 pm

tobiflex wrote:I have implement my first try of the CHK2 and CMP2 Instructions here: https://github.com/TobiFlex/TG68K.C

But I need help here. Do these instructions do what they should? Who can write examples or test code?
cputester stop with false N- or V- Flag. But this is undefined behavior.


I haven't had time to get my tests up and running yet.
Attached is my slightly modified itest to run in the sim. It tests the additional 020 instructions.
/MikeJ
You do not have the required permissions to view the files attached to this post.

User avatar
retrofun
Atari freak
Atari freak
Posts: 52
Joined: Sat Jan 12, 2019 3:12 pm

Re: Work on the Minimig core?

Postby retrofun » Sun Nov 24, 2019 9:33 am

Fix for the ILLEGAL.B cputest:
https://github.com/TobiFlex/TG68K.C/pull/4

sonycman
Atari User
Atari User
Posts: 33
Joined: Thu Aug 29, 2019 3:33 pm
Location: Russia

Re: Work on the Minimig core?

Postby sonycman » Mon Nov 25, 2019 9:35 am

Porting minimig on Xilinx currently, and Vivado reported many errors of type: declarations not allowed in unnamed block.
Someone has declared local registers under procedural blocks without names.
So I had to give names to such a blocks or move the registers outside of them.

Is the Quartus okay with it?

What was the meaning of declaring some local variables?

slingshot
Atari God
Atari God
Posts: 1351
Joined: Mon Aug 06, 2018 3:05 pm

Re: Work on the Minimig core?

Postby slingshot » Mon Nov 25, 2019 10:01 am

sonycman wrote:Porting minimig on Xilinx currently, and Vivado reported many errors of type: declarations not allowed in unnamed block.
Someone has declared local registers under procedural blocks without names.
So I had to give names to such a blocks or move the registers outside of them.

Is the Quartus okay with it?

What was the meaning of declaring some local variables?

You can name procedural blocks in Quartus, too. The meaning? Same as in any high-level language - those registers are used only in that block.
I can understand why the tool chokes on them - if you define two registers with the same name in two unnamed blocks, then you'll get a confusion in any netlist.

tobiflex
Atariator
Atariator
Posts: 29
Joined: Thu Oct 17, 2019 7:00 am

Re: Work on the Minimig core?

Postby tobiflex » Mon Nov 25, 2019 11:19 am

fpgaarcade wrote:
tobiflex wrote:I have implement my first try of the CHK2 and CMP2 Instructions here: https://github.com/TobiFlex/TG68K.C

But I need help here. Do these instructions do what they should? Who can write examples or test code?
cputester stop with false N- or V- Flag. But this is undefined behavior.


I haven't had time to get my tests up and running yet.
Attached is my slightly modified itest to run in the sim. It tests the additional 020 instructions.
/MikeJ

Thank you Mike. Now I'll try to use it.

tobiflex
Atariator
Atariator
Posts: 29
Joined: Thu Oct 17, 2019 7:00 am

Re: Work on the Minimig core?

Postby tobiflex » Mon Nov 25, 2019 11:21 am

retrofun wrote:Fix for the ILLEGAL.B cputest:
https://github.com/TobiFlex/TG68K.C/pull/4

Thank you, I took it over.

slingshot
Atari God
Atari God
Posts: 1351
Joined: Mon Aug 06, 2018 3:05 pm

Re: Work on the Minimig core?

Postby slingshot » Wed Nov 27, 2019 9:22 am

It's known that the IDE HDD's model name/serial number/etc. are looks like byte swapped (even in the Archie core, which uses the same IDE code as Minimig). But for some reason I found this in the firmware:
https://github.com/mist-devel/mist-firm ... hdd.c#L189
Basically byte swap is commented out - //not for 68000
Why not for 68000? Anyone knows that? I don't see issues with swapping with any CPU modes.

robinsonb5
Atariator
Atariator
Posts: 17
Joined: Sat May 16, 2015 3:02 pm

Re: Work on the Minimig core?

Postby robinsonb5 » Wed Nov 27, 2019 10:17 am

slingshot wrote:It's known that the IDE HDD's model name/serial number/etc. are looks like byte swapped (even in the Archie core, which uses the same IDE code as Minimig). But for some reason I found this in the firmware:
https://github.com/mist-devel/mist-firm ... hdd.c#L189
Basically byte swap is commented out - //not for 68000
Why not for 68000? Anyone knows that? I don't see issues with swapping with any CPU modes.


Probably due to the heritage of the firmware code - which started out on little-endian ARM (for the original Minimig). I think it was Tobiflex who ported Minimig initially to a few platforms such as DE1 and Turbo Chameleon 64, which have no onboard ARM, and these have to use a second CPU within the core instead. He used a second TG68 to replace the ARM, so the firmware was now running on a big-endian CPU. (I believe Christian Vogelgsang was involved in that porting.) I made some changes to the TG68 version of the firmware which got backported to ARM, and also to OpenRisc (when Rok did some further work on the DE1 core), and I think that's the version that ultimately became the MIST firmware. The "not for 68000" comments were, I believe, from the original port from ARM to 68k.

slingshot
Atari God
Atari God
Posts: 1351
Joined: Mon Aug 06, 2018 3:05 pm

Re: Work on the Minimig core?

Postby slingshot » Wed Nov 27, 2019 10:25 am

Interesting history, the firmware run on the same CPU core as the Minimig itself?
But currently there shouldn't be an issue to do the byteswap then.

robinsonb5
Atariator
Atariator
Posts: 17
Joined: Sat May 16, 2015 3:02 pm

Re: Work on the Minimig core?

Postby robinsonb5 » Wed Nov 27, 2019 11:11 am

slingshot wrote:Interesting history, the firmware run on the same CPU core as the Minimig itself?
But currently there shouldn't be an issue to do the byteswap then.


A second instance of the same CPU, yes.
At a quick glance, I believe the Identify Device response is a 16-bit-word-oriented buffer, but which has text portions within it. Since it's sent to the FPGA low-byte followed by high-byte the behaviour for the text portions is different between big- and little-endian CPUS, so on little-endian ARM the text part of the buffer should indeed by byte-swapped before sending.

slingshot
Atari God
Atari God
Posts: 1351
Joined: Mon Aug 06, 2018 3:05 pm

Re: Work on the Minimig core?

Postby slingshot » Wed Nov 27, 2019 11:27 am

Actually it doesn't depend on the receiving CPU, but there's an oddity in the ATA spec itself:
Although most multi-byte fields in ATA are little-endian, some fields are unusual:
a) The IDENTIFY (PACKET) DEVICE data SERIALNUMBER field, MODELNUMBER field, and FIRMWAREREVISION field, and possibly the MEDIASERIALNUMBER field each contain ASCII characters representing an ASCII string. However, they do not contain the characters in normal string order (with the first character at byte 0, the second character at byte 1, etc.). For historical reasons, each pair of bytes is swapped (byte 0 with byte 1, byte 2 with byte 3, byte 4 with byte 5, etc.).

robinsonb5
Atariator
Atariator
Posts: 17
Joined: Sat May 16, 2015 3:02 pm

Re: Work on the Minimig core?

Postby robinsonb5 » Wed Nov 27, 2019 11:55 am

slingshot wrote:Actually it doesn't depend on the receiving CPU, but there's an oddity in the ATA spec itself:
Although most multi-byte fields in ATA are little-endian, some fields are unusual:
a) The IDENTIFY (PACKET) DEVICE data SERIALNUMBER field, MODELNUMBER field, and FIRMWAREREVISION field, and possibly the MEDIASERIALNUMBER field each contain ASCII characters representing an ASCII string. However, they do not contain the characters in normal string order (with the first character at byte 0, the second character at byte 1, etc.). For historical reasons, each pair of bytes is swapped (byte 0 with byte 1, byte 2 with byte 3, byte 4 with byte 5, etc.).


Yes, that's right - but we're not talking about the receiving CPU here - we're the sender!
That swapping happens automatically on a big-endian CPU (when the firmware's running on 68k) because the buffer's sent in 16-bit words, first the low byte then the high byte - so the text string "ABCD" is sent 'B', 'A', 'D', 'C'.
On a little-endian CPU (such as the MIST's onboard ARM) the same buffer is sent 'A', 'B', 'C', 'D', so needs to be byte-swapped.

slingshot
Atari God
Atari God
Posts: 1351
Joined: Mon Aug 06, 2018 3:05 pm

Re: Work on the Minimig core?

Postby slingshot » Wed Nov 27, 2019 12:54 pm

Ah, ok, agreed.
Just first I assumed the commented out byteswap function is because of the receiver 68000, not what the firmware runs on.

robinsonb5
Atariator
Atariator
Posts: 17
Joined: Sat May 16, 2015 3:02 pm

Re: Work on the Minimig core?

Postby robinsonb5 » Wed Nov 27, 2019 2:20 pm

slingshot wrote:Just first I assumed the commented out byteswap function is because of the receiver 68000, not what the firmware runs on.


Yes, indeed - I'd have assumed the same if I'd not known about the firmware previously running on 68k.

sonycman
Atari User
Atari User
Posts: 33
Joined: Thu Aug 29, 2019 3:33 pm
Location: Russia

Re: Work on the Minimig core?

Postby sonycman » Mon Dec 02, 2019 3:36 am

Hello.
I want to simulate the CPU cache, integrated in memory controller (file cpu_cache_new.v).

I far as i understand, by default it is disabled, so i need to enable it by setting right bits via cpu_cache_ctrl signal?
This signal is connected directly to CACR CPU output, so this could be done only in code running on it.

Am i right?

Could the cache be activated with 68000 cpu mode, or it must be 68020 only?

Thanks in advance!

uchristo
Retro freak
Retro freak
Posts: 14
Joined: Wed Sep 28, 2016 3:22 pm

Re: Work on the Minimig core?

Postby uchristo » Tue Dec 10, 2019 8:09 am

Is there some kind of interrim-Build available for all those who didn't set up the whole Buildsetup?

I'd like to test if the several Math-fixes will have effect on WHDLoad-Version of Rainbow Islands (crashes on MiST MiniMigAGA, works on UAE/Real Hardware)

WHDLoad Dump included
You do not have the required permissions to view the files attached to this post.

User avatar
jokker
Atari maniac
Atari maniac
Posts: 76
Joined: Mon Nov 17, 2008 7:13 am
Location: Ontario, Canada

Re: Work on the Minimig core?

Postby jokker » Thu Dec 12, 2019 8:35 pm

Here's is one I did recently that seems to work on my MIST.

I noticed that Gods worked for me in WHDLoad now when before it didn't so there has definitely been some improvements. My thanks for the hardwork by everyone.

uchristo wrote:Is there some kind of interrim-Build available for all those who didn't set up the whole Buildsetup?

I'd like to test if the several Math-fixes will have effect on WHDLoad-Version of Rainbow Islands (crashes on MiST MiniMigAGA, works on UAE/Real Hardware)

WHDLoad Dump included
You do not have the required permissions to view the files attached to this post.


Return to “MiST”

Who is online

Users browsing this forum: No registered users and 4 guests