Work on the Minimig core?

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

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

Post Reply
slingshot
Atari God
Atari God
Posts: 1830
Joined: Mon Aug 06, 2018 3:05 pm

Re: Work on the Minimig core?

Post by slingshot »

apolkosnik wrote: It was Tobiflex who fixed the addressing issue; I only ran a Toni Wilen's cputest and found some issues. :)
Of course. It's great that Tobias returned to his baby.
User avatar
DrOG
Atari Super Hero
Atari Super Hero
Posts: 732
Joined: Sun Jul 31, 2016 8:23 pm
Location: Gyula, Hungary

Re: Work on the Minimig core?

Post by DrOG »

Hi!

Alastair M. Robinson released a new minimig core for the TC64 with experimential implementation of the Akiko Chunky-to-Planar converter (which can be used by a handful of games to increase video performance), and an experimental P96 retargetable graphics driver.

More info:
http://retroramblings.net/?p=1434#more-1434

Source code:
https://github.com/robinsonb5/MinimigAGA_TC64

I don't know if it's mature enough to port or not...
robinsonb5
Atari maniac
Atari maniac
Posts: 77
Joined: Sat May 16, 2015 3:02 pm

Re: Work on the Minimig core?

Post by robinsonb5 »

DrOG wrote: Mon Jul 13, 2020 3:45 am I don't know if it's mature enough to port or not...
I tried not to break things too badly in porting the core to the TC64 - but it will need some adapting for MiST. Most notably, the video dithering and OSD overlay will have to happen on the 113MHz clock rather than the 28MHz clock, since we now have faster pixel clocks in the mix.

If you want to get an idea of what sort of performance to expect, I posted a video on Patreon a few days ago - https://www.patreon.com/posts/another-update-39071350 (not paywalled - that's not my style!)
slingshot
Atari God
Atari God
Posts: 1830
Joined: Mon Aug 06, 2018 3:05 pm

Re: Work on the Minimig core?

Post by slingshot »

Lot of things @114 MHz, lot of opportunities for timing violations :)
114 MHz pixel clock is more than 1280x720p requires. Is there any SDRAM bandwidth left for the CPU? I guess it also needs replacing the sdram controller and the cache.
robinsonb5
Atari maniac
Atari maniac
Posts: 77
Joined: Sat May 16, 2015 3:02 pm

Re: Work on the Minimig core?

Post by robinsonb5 »

slingshot wrote: Tue Jul 14, 2020 12:24 pm Lot of things @114 MHz, lot of opportunities for timing violations :)
Oh yes indeed! Luckily, the consequence of a timing violation in the video circuitry is a bit of jitter, not the whole thing coming crashing down in flames. (I also have a host CPU running on the 114MHz clock to replace the ARM, since the TC64 doesn't have that.) The project doesn't meet timing, but the RTG stuff hasn't made it any worse.
114 MHz pixel clock is more than 1280x720p requires. Is there any SDRAM bandwidth left for the CPU?
Very little when the pixel clock's maxed out - it gets very slow in 8-bit with 113.4MHz pixel clock, or 15-bit with a 56.7MHz pixel clock, but an 8-bit workbench is usable in anything under 1440x900. But if the dithering / OSD overlay's happening at 28Mhz, an 800x600 screenmode using a 30-something MHz pixel clock is going to look awful.

The biggest issue with Minimig's RAM speed is actually CPU write speed - it's not easy to make good use of bursts for that. I've rather hackily exported a "longword" signal from the TG68 so the SDRAM controller knows to gang together the two halves of a longword write - that helps a bit, but smarter write caching would be better. I don't really have the LE budget for it, though.
I guess it also needs replacing the sdram controller and the cache.
Yes, I've adapted both for 8-word bursts, so in the best case scenario it can now transfer data every cycle. The cache was surprisingly easy to adapt, and the SDRAM controller's still recognisable as the same one. The biggest change is that I now delay the CAS phase of writes by a few cycles, so the data occupies the same timeslices as read data. The new timing's documented at the end of the controller's source.
kolla
Captain Atari
Captain Atari
Posts: 309
Joined: Thu Sep 17, 2015 11:39 pm
Contact:

Re: Work on the Minimig core?

Post by kolla »

If I may toss out a random wish for the Minimig core - not caring much about RTG, but... USB host controller? :)

The MiST has 4 USB ports, and in my case, at least two of them are empty (I have a combo usb kbd+mouse, and I use old "real" joysticks), it would be really nice if two USB ports could (optionally) be directly accessible from the Minimig, for use with Poseidon (or ANAIIS), as that would open up for all kinds of USB devices supported by the stacks, among them USB ethernet, storage devices, midi etc.
-- kolla
slingshot
Atari God
Atari God
Posts: 1830
Joined: Mon Aug 06, 2018 3:05 pm

Re: Work on the Minimig core?

Post by slingshot »

robinsonb5 wrote: Tue Jul 14, 2020 6:18 pm
Yes, I've adapted both for 8-word bursts, so in the best case scenario it can now transfer data every cycle. The cache was surprisingly easy to adapt, and the SDRAM controller's still recognisable as the same one. The biggest change is that I now delay the CAS phase of writes by a few cycles, so the data occupies the same timeslices as read data. The new timing's documented at the end of the controller's source.
Just looked at the current SDRAM controller, 8-word reads and 32-bit writes looks really great improvements, would be good to have a switchable 32-bit datain/data out option in TG68K.

Or another idea to make TG68K 32-bit externally (as internally it is 32-bit already), and have different frontends with 68000 (16bit) and 68020 (32bit) interfaces.
User avatar
vebxenon
Atari God
Atari God
Posts: 1026
Joined: Fri Apr 24, 2015 12:10 pm

Re: Work on the Minimig core?

Post by vebxenon »

Do you know why some games in AGA mode have glitches? For example, SF2 on Whdload.

I'm very very happy with this core :cheers:

Regards,

Salva
Just a computer and videogame lover :)

- Atari Jr 2600 clone
- Atari 7800 Peritel
- Atari XEGS
- Atari Lynx II
- Atari Jaguar
- MiST Board
slingshot
Atari God
Atari God
Posts: 1830
Joined: Mon Aug 06, 2018 3:05 pm

Re: Work on the Minimig core?

Post by slingshot »

vebxenon wrote: Thu Jul 30, 2020 3:02 pm Do you know why some games in AGA mode have glitches? For example, SF2 on Whdload.
I don't know (and I don't know really much about Amigas). Did you read this?
viewtopic.php?p=398448#p398448
User avatar
vebxenon
Atari God
Atari God
Posts: 1026
Joined: Fri Apr 24, 2015 12:10 pm

Re: Work on the Minimig core?

Post by vebxenon »

slingshot wrote: Thu Jul 30, 2020 3:47 pm
vebxenon wrote: Thu Jul 30, 2020 3:02 pm Do you know why some games in AGA mode have glitches? For example, SF2 on Whdload.
I don't know (and I don't know really much about Amigas). Did you read this?
viewtopic.php?p=398448#p398448
Same problem. These glitches don't show if I use ECS instead of AGA. They didn't appear until some versions ago.

But well... using a former version of the WHDLoad install (1.1), from WHDownLoad, game works without glitches so... problem solved :D :wink:

Now the only game I have with problems is Rainbow Islands using WHDLoad. So one game from hundreds... it's great :cheers:
Just a computer and videogame lover :)

- Atari Jr 2600 clone
- Atari 7800 Peritel
- Atari XEGS
- Atari Lynx II
- Atari Jaguar
- MiST Board
ijor
Hardware Guru
Hardware Guru
Posts: 4012
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Work on the Minimig core?

Post by ijor »

robinsonb5 wrote: Tue Jul 14, 2020 6:18 pm Oh yes indeed! Luckily, the consequence of a timing violation in the video circuitry is a bit of jitter, not the whole thing coming crashing down in flames. (I also have a host CPU running on the 114MHz clock to replace the ARM, since the TC64 doesn't have that.) The project doesn't meet timing, but the RTG stuff hasn't made it any worse.
It is too bad that cores that don't meet timing are publicly released. I understand from what you are saying this is not your fault, and I know it is not slingshot's fault either. But I believe that is a very bad thing to do. Not only that the core, of course, might fail or misbehave. All those cores not meeting timing, IMHO, ruin the reputation of the whole FPGA non commercial community.

I agree that it might be acceptable in some exceptional cases. But should be really only exceptional, and it should be documented and the user should be warned. Btw, I hope you realize that a core not meeting timing might even damage the hardware, e.g., if it affects an external interface. Yes, the chances are quite remote, but certainly possible.

Sorry for the rant, but I had to say something.
Fx Cast: Atari St cycle accurate fpga core
slingshot
Atari God
Atari God
Posts: 1830
Joined: Mon Aug 06, 2018 3:05 pm

Re: Work on the Minimig core?

Post by slingshot »

ijor wrote: Wed Aug 05, 2020 3:36 am
It is too bad that cores that don't meet timing are publicly released. I understand from what you are saying this is not your fault, and I know it is not slingshot's fault either. But I believe that is a very bad thing to do. Not only that the core, of course, might fail or misbehave. All those cores not meeting timing, IMHO, ruin the reputation of the whole FPGA non commercial community.
I think it's not that bad, at least not on MiST, where there's no another soft-cpu. The TG68k should not really run at 112 MHz, however the multicycle paths in the sdc mostly solve it. Converting to 28 MHz is a bit challenging if one wants the same performance, since the signals between the SDRAM controller - cache (which will remain at 112) and the CPU (which will become 28) should be passed carefully (I remember the struggling with the SNES).
ijor
Hardware Guru
Hardware Guru
Posts: 4012
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Work on the Minimig core?

Post by ijor »

slingshot wrote: Wed Aug 05, 2020 7:51 am I think it's not that bad, at least not on MiST, where there's no another soft-cpu. The TG68k should not really run at 112 MHz, however the multicycle paths in the sdc mostly solve it.
I wasn't really talking specifically about this core, not even specifically about the MiST. Sadly, it became quite common practice to release cores not meeting timing.
Fx Cast: Atari St cycle accurate fpga core
slingshot
Atari God
Atari God
Posts: 1830
Joined: Mon Aug 06, 2018 3:05 pm

Re: Work on the Minimig core?

Post by slingshot »

ijor wrote: Wed Aug 05, 2020 12:11 pm I wasn't really talking specifically about this core, not even specifically about the MiST. Sadly, it became quite common practice to release cores not meeting timing.
And with loads of async logic.
robinsonb5
Atari maniac
Atari maniac
Posts: 77
Joined: Sat May 16, 2015 3:02 pm

Re: Work on the Minimig core?

Post by robinsonb5 »

ijor wrote: Wed Aug 05, 2020 3:36 am It is too bad that cores that don't meet timing are publicly released. I understand from what you are saying this is not your fault, and I know it is not slingshot's fault either. But I believe that is a very bad thing to do. Not only that the core, of course, might fail or misbehave.
I see where you're coming from, and in fact I largely agree with you. I do make an effort at least not to make things worse timing-wise!
It'd be nice to get the Minimig core completely timing-clean, but it's still quite a daunting task - and I suppose the other problem is it's not a "fun" task, when people are tinkering with this stuff for recreation. In fact I guess that's probably a big reason people don't put as much effort as perhaps they should into making cores timing-clean?
The other reason, in my case at least, was in the past I simply didn't know how to fix the timing problems! (I'm a printer/designer by trade, with no training at all in the field of FPGAs.)

(If I sound defensive, well... I don't mean to! I understand that you're not trying to attack anyone - and you make a valid point.)
All those cores not meeting timing, IMHO, ruin the reputation of the whole FPGA non commercial community.
Reputation with whom? End users?
Btw, I hope you realize that a core not meeting timing might even damage the hardware, e.g., if it affects an external interface. Yes, the chances are quite remote, but certainly possible.
Yes, I'm aware of that, and I'm very careful with the SDRAM in particular. (The modified SDRAM controller delays writes by one clock more than is theoretically necessary to make absolutely sure bus contention won't occur.)
slingshot wrote:I think it's not that bad, at least not on MiST, where there's no another soft-cpu.
Yeah, that's my other difficulty on the Chameleon, needing a second CPU. Luckily the one I'm using doesn't add much timing pressure even at 113MHz.
The TG68k should not really run at 112 MHz, however the multicycle paths in the sdc mostly solve it. Converting to 28 MHz is a bit challenging if one wants the same performance, since the signals between the SDRAM controller - cache (which will remain at 112) and the CPU (which will become 28) should be passed carefully (I remember the struggling with the SNES).
I did experiment some years ago with having a standalone TG68 SoC at 28MHz and some of the supporting logic on the negedge of the same clock, with promising results - I gave up trying to integrate it into Minimig, though.

I'm wondering whether a simpler "level 1" cache closer to the CPU might be worth exploring.
ijor
Hardware Guru
Hardware Guru
Posts: 4012
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Work on the Minimig core?

Post by ijor »

robinsonb5 wrote: Wed Aug 05, 2020 5:55 pm Reputation with whom? End users?
End users, ourselves the developers, people at the companies that produce commercial FPGA consoles .. pretty much everybody that is involved somehow.
Yes, I'm aware of that, and I'm very careful with the SDRAM in particular. (The modified SDRAM controller delays writes by one clock more than is theoretically necessary to make absolutely sure bus contention won't occur.)
That's not the main problem. The main problem is not a tiny momentarily bus contention when changing bus direction. The problem is that if you don't meet timing, your machine state might get confused and misbehave. And that means that potentially you could drive the bus when you are not supposed to. Or you could assert the peripheral OE when you shouldn't, and then you might get bus contention, or worse, for whole cycles. Again, not very likely, but one of the possible negative side effects of not meeting timing.
Fx Cast: Atari St cycle accurate fpga core
robinsonb5
Atari maniac
Atari maniac
Posts: 77
Joined: Sat May 16, 2015 3:02 pm

Re: Work on the Minimig core?

Post by robinsonb5 »

ijor wrote: Thu Aug 06, 2020 3:49 amThat's not the main problem. The main problem is not a tiny momentarily bus contention when changing bus direction.
No, I realise that - I mentioned it simply to demonstrate that, despite my somewhat flippant comment earlier about video-related circuits not meeting timing, I do actually give this stuff some careful thought.

Thanks for the input, though - you've prompted me to look again at the timing reports, and make a few changes in the CPU's supporting logic - I believe full timing closure for the Minimig core is within reach.
slingshot
Atari God
Atari God
Posts: 1830
Joined: Mon Aug 06, 2018 3:05 pm

Re: Work on the Minimig core?

Post by slingshot »

robinsonb5 wrote: Wed Aug 05, 2020 5:55 pm
The TG68k should not really run at 112 MHz, however the multicycle paths in the sdc mostly solve it. Converting to 28 MHz is a bit challenging if one wants the same performance, since the signals between the SDRAM controller - cache (which will remain at 112) and the CPU (which will become 28) should be passed carefully (I remember the struggling with the SNES).
I did experiment some years ago with having a standalone TG68 SoC at 28MHz and some of the supporting logic on the negedge of the same clock, with promising results - I gave up trying to integrate it into Minimig, though.

I'm wondering whether a simpler "level 1" cache closer to the CPU might be worth exploring.
Actually it's easy to convert to 28MHz if you don't care about the performance :) Moving the data from the long combinatorial outputs of the TG68k requires several cycles to pass to 112MHz clock domain. Registering them at the negedge of the 28MHz clock is a good idea (this is what I did in the SNES core). I'm not sure if adding another level of cache will make the timings better.
Gehstock
Captain Atari
Captain Atari
Posts: 431
Joined: Wed Dec 21, 2016 7:18 pm
Location: EastGermany

Re: Work on the Minimig core?

Post by Gehstock »

All those cores not meeting timing, IMHO, ruin the reputation of the whole FPGA non commercial community.
I think this Statement is fundamentally wrong. Without these people (and I count myself among them) there would be a lot fewer cores and a much smaller community. Most of the cores are not started by professionals but are improved by them. And I think the community knows who is a professional and who is not.
kolla
Captain Atari
Captain Atari
Posts: 309
Joined: Thu Sep 17, 2015 11:39 pm
Contact:

Re: Work on the Minimig core?

Post by kolla »

The mantra of open source - ship early and ship often. So called professional software often tend to do the opposite :)
-- kolla
ijor
Hardware Guru
Hardware Guru
Posts: 4012
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Work on the Minimig core?

Post by ijor »

Gehstock wrote: Fri Aug 07, 2020 3:02 pm
All those cores not meeting timing, IMHO, ruin the reputation of the whole FPGA non commercial community.
I think this Statement is fundamentally wrong. Without these people (and I count myself among them) there would be a lot fewer cores and a much smaller community. Most of the cores are not started by professionals but are improved by them. And I think the community knows who is a professional and who is not.
I'm not sure what you mean by "these people". Honestly, I don't know who is professional and who is not, and I don't really care neither I think it matters too much.

It is not about being professional, it is about a correct development approach. There are lots of non professional software developers releasing top notch software. There is no reason why this couldn't happen with FPGA cores. You don't need to be professional to take care about meeting timing, anybody can do that. The main problem is that many developers simply ignore the issue.
kolla wrote: Fri Aug 07, 2020 3:42 pm The mantra of open source - ship early and ship often.
I don't think it has anything to do with that. Many cores were released a few years ago and they are quite mature already. So why they still don't meet timing?

Would you release a kernel driver that exposes security holes just for the sake of shipping early? Probably not, I guess. And security usually needs to be considered since the start of the development. Meeting timing is not much different.
Fx Cast: Atari St cycle accurate fpga core
uchristo
Atari User
Atari User
Posts: 39
Joined: Wed Sep 28, 2016 3:22 pm

Re: Work on the Minimig core?

Post by uchristo »

vebxenon wrote: Fri Jul 31, 2020 4:52 am .................
Now the only game I have with problems is Rainbow Islands using WHDLoad. So one game from hundreds... it's great :cheers:
Anybody got a hint whats wrong with Rainbow Islands? I know it's only one from hundreds, but it's a very special one :wink:
kolla
Captain Atari
Captain Atari
Posts: 309
Joined: Thu Sep 17, 2015 11:39 pm
Contact:

Re: Work on the Minimig core?

Post by kolla »

ijor wrote: Mon Aug 10, 2020 1:12 am Many cores were released a few years ago and they are quite mature already. So why they still don't meet timing?
Perhaps the matter of timing is less relevant for some cores?
-- kolla
slingshot
Atari God
Atari God
Posts: 1830
Joined: Mon Aug 06, 2018 3:05 pm

Re: Work on the Minimig core?

Post by slingshot »

kolla wrote: Wed Aug 12, 2020 11:51 am
Perhaps the matter of timing is less relevant for some cores?
It's not about the precision of the "emulation", but meeting the electrical specifications, so the code will do what you expect, not random things. Maybe people who come from software background don't expect this (if the core's timings is not good, than it's like running your code on broken hardware which causes random lockups, freezes, miscalculations, etc...)

Some interesting fact about timings check (from the ZX ULA book): the engineers checked the signal propagation delays by measuring the trace lengths on the mylar film with the ULA interconnection layer.
robinsonb5
Atari maniac
Atari maniac
Posts: 77
Joined: Sat May 16, 2015 3:02 pm

Re: Work on the Minimig core?

Post by robinsonb5 »

slingshot wrote: Wed Aug 12, 2020 12:40 pm It's not about the precision of the "emulation", but meeting the electrical specifications, so the code will do what you expect, not random things. Maybe people who come from software background don't expect this (if the core's timings is not good, than it's like running your code on broken hardware which causes random lockups, freezes, miscalculations, etc...)
The best analogy I've heard so far is to think of it a bit like overclocking; the design's guaranteed to run up to a certain speed - beyond that it might work or it might not, and how far you can push it varies from chip to chip.
The most difficult part with a core like Minimig, I've found, is knowing what can be safely multicycled and what can't - there are far too many signals to handle individually, but I'm always nervous that a wildcard will include something it shouldn't.

Incidentally, I've made some changes in the TG68K wrapper in my Minimig repo, which reducing timing pressure quite a bit, by registering the autoconfig data and datatg68 signal, plus a few other tweaks. I'm getting mostly clean builds now, even with the RTG stuff included.
Post Reply

Return to “MiST”