ZX Next port

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

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

Chris23235
Captain Atari
Captain Atari
Posts: 268
Joined: Thu Aug 07, 2014 6:52 pm

Re: ZX Next port

Post by Chris23235 »

MasterOfGizmo wrote: Mon Sep 13, 2021 6:20 pm
There are similar issues on software side. The entire menu system is still the one from the minimig. It has grown into an inconsistant mess on the MIST (and also a bloated and ugly source code) and I have only recently used a MISTer for the first time and was surprised that the same interface is still there but is an even bigger mess. A nice and simple graphical interface (perhaps even using a mouse if present) is imho needed. Something more user friendly. The SRAM could e.g. provide the framebuffer for that.
From the perspective of a MiST user, I would love to see the menu system stay as it is. It is easy to use, flexible enough and not bloated. I don't see how a Mouse driven menu would improve things. In my opinion there is no need to change the menu system.
User avatar
MasterOfGizmo
Atari God
Atari God
Posts: 1356
Joined: Fri Feb 08, 2013 12:15 pm
Contact:

Re: ZX Next port

Post by MasterOfGizmo »

Chris23235 wrote: Tue Sep 14, 2021 8:41 am From the perspective of a MiST user, I would love to see the menu system stay as it is.
I understand. My main reason for this is the software side which is a total mess. I once tried to rewrite that part (and leaving the user interface itself mostly intact). But I never finished that.

Anyway, the current system also has its drawbacks as you sometimes navigate hierarchically bei selecting entries and return from them using return/esc keys and sometimes you navigate "horizontally" between pages using cursor left and right (mainly in the amiga and atari st config). Sometimes menus allow you to scroll for more entries sometimes they use the aforementioned left/right approach with multiple pages. I think this might be simplified and unified somewhat to give the menu a clear hierarchy. When I played with the MISTer menu I simply got lost and confused pretty soon. Sure, some fiddling around brings the expected results after a few seconds but to me it simply wasn't obvious where in the menu tree I was and how to e.g. get back to the core selection part.

No fundamental changes on user side. Just simplifications. But the software side needs a major update. That part is a total mess.

The mouse idea was just an "add on" as we can already use a keyboard or gamepad to navigate the menu. But indeed no system comes to mind that has a mouse but neither keyboard nor joystick attached.
MIST board, FPGA based Atari STE and more: https://github.com/mist-devel/mist-board/wiki
slingshot
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2306
Joined: Mon Aug 06, 2018 3:05 pm

Re: ZX Next port

Post by slingshot »

MasterOfGizmo wrote: Tue Sep 14, 2021 9:27 am
I understand. My main reason for this is the software side which is a total mess. I once tried to rewrite that part (and leaving the user interface itself mostly intact). But I never finished that.
My opinion is it would be good to add more generalized possibilities, then all the custom menu code for Archie/Minimig/ST could be thrown away, using only generated menu items. That would greatly reduce that spaghetti code (and flash space occupied). And move setting to ini files in all cases (should be no problem, Minimig already converted to .ini).
robinsonb5
Captain Atari
Captain Atari
Posts: 243
Joined: Sat May 16, 2015 3:02 pm

Re: ZX Next port

Post by robinsonb5 »

slingshot wrote: Tue Sep 14, 2021 10:02 am My opinion is it would be good to add more generalized possibilities, then all the custom menu code for Archie/Minimig/ST could be thrown away, using only generated menu items.
This, 100%. I have to admit I was initially skeptical about the config string system - I thought it'd be painful to deal with. I was wrong!

In DeMiSTify it takes me around 200 lines of code to parse a config string, figure out which options are currently selected from the status word, and build a menu view. I don't store anything other than the displayed text and a tiny bit of metadata for each row of the OSD - it's fast enough that I can simply re-parse the entire config string any time the menu needs updating.
With the TC64 port of the MiSTery core I handled the menus by creating a virtual config string, which is accessed from the ROM instead of over SPI.
User avatar
MasterOfGizmo
Atari God
Atari God
Posts: 1356
Joined: Fri Feb 08, 2013 12:15 pm
Contact:

Re: ZX Next port

Post by MasterOfGizmo »

robinsonb5 wrote: Tue Sep 14, 2021 12:17 pm I have to admit I was initially skeptical about the config string system
It may need some updates to become a little more flexible and perhaps using something like JSON would make parsing and handling a little simpler and easier to understand.

Anyway, before thinking about these things I'd like to verify that there's indeed something like a hardware roadmap ahead ...
MIST board, FPGA based Atari STE and more: https://github.com/mist-devel/mist-board/wiki
slingshot
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2306
Joined: Mon Aug 06, 2018 3:05 pm

Re: ZX Next port

Post by slingshot »

--
ManuFerHi
Atari maniac
Atari maniac
Posts: 97
Joined: Fri Dec 23, 2016 1:20 am

Re: ZX Next port

Post by ManuFerHi »

MasterOfGizmo wrote: Mon Sep 13, 2021 6:20 pm
ManuFerHi wrote: Fri Apr 02, 2021 5:26 pm Maybe I could make a version of SiDi64 with this processor to be able to do tests
What happened to this?

Here are my 2ct regarding this. Main point is that a "real" update to the MIST like this would really be great. MISTer is pretty much a dead end since there's no path for improvement and they day the DE10 Nano is not being sold anymore will simply bring the whole project to a stop.

I fully agree with most points you all mentioned. To summarize:
  • More RAM with more bandwidth (preferably by more and independent RAM channels)
  • Faster link between MCU and FPGA
  • Better video (real analog DAC and HDMI)
  • Faster and bigger FPGA
Regarding the RAM it may be useful to go from SDRAM to some more modern variant and add a fast SRAM (4MBIT 10ns seems to be resonably priced). Having e.g. 256k 16 bit words at 10ns random access would imho solve many problems.

When designing the MIST I was aware that the MAX USB would be an expensive and slow solution. But I wanted to keep the SAM MCU from the Minimig to have one unknown variable less. The same goes for HDMI which would have been another big question mark. And finally the SDRAM which should have been at least DDR2. I did all that to lower the risk of failure. So addressing all of these now sure makes sense for a better MIST.

There are similar issues on software side. The entire menu system is still the one from the minimig. It has grown into an inconsistant mess on the MIST (and also a bloated and ugly source code) and I have only recently used a MISTer for the first time and was surprised that the same interface is still there but is an even bigger mess. A nice and simple graphical interface (perhaps even using a mouse if present) is imho needed. Something more user friendly. The SRAM could e.g. provide the framebuffer for that.

But my biggest question is: What FPGA do you have in mind? It should IMHO be a significant update from the MIST.

But the main goal should imho be to stay in the price range of the MIST or at most slightly above. On MCU/USB side some savings are sure possible as you already pointed out. But adding a second RAM, more color channels and HDMI will already significantly increase the FPGA footprint and increase the cost.

Whatever ... it's been a long time since I started the MIST and cooperating on a successor will sure be fun. So what's the state?
We are working on it, next week I get the second prototypes, we have had to make important changes.
We are doing the prototypes on the EP4CE22 FPGA just because it is cheaper, but the final board will have Cyclone 10GX 10CX085 and HDMI. SRAM I do not see it necessary since this FPGA has enough BRAM to make a framebuffer.
I also think that the supply of semiconductors, MCUs and FPGAs is going to be a problem, it is difficult to achieve at the moment, we hope that next year the supply problem will be solved.
clebin
Atariator
Atariator
Posts: 18
Joined: Mon Jul 28, 2014 8:14 pm

Re: ZX Next port

Post by clebin »

My main wish for the hardware besides the improvements mentioned - keep the DB9 ports. They're so important to the function and identity of the MiST. They're like the MiST's opposable thumbs - they separate it from emulation and FPGA dev boards. :)

My main wish for the software would be an easier way to set the priority order of joysticks through the menus. Clear up the 'swap joysticks' and multiple slightly confusing ini settings. It would be great to have a simple way to see what you have plugged in and change the priority order on the fly.

As someone who's never been won over by the Mister, I'm very excited to see these discussions happening.
User avatar
MasterOfGizmo
Atari God
Atari God
Posts: 1356
Joined: Fri Feb 08, 2013 12:15 pm
Contact:

Re: ZX Next port

Post by MasterOfGizmo »

ManuFerHi wrote: Wed Sep 15, 2021 9:37 am not see it necessary since this FPGA has enough BRAM to make a framebuffer.
Basically all the "next" cores need additional memory interfaces as the original machines also had multiple memories and one single sdram simply doesn't give sufficient bandwidth. Even Amiga and Atari ST cores run into these limits when increasing video quality. Things like Neogeo etc will definitely need additional RAM. How much is "enough" BRAM?

I also heard that you are returning to the MAX USB bridge. I stronly suggest not to do that. It's already very limited in the current version and it's awfully slow and using ethernet adapters or memory sticks is basically impossible due to that. I was struggling with that chip back then and the original MIST should already have used some MCU with integrated USB host. And it's very expensive ...

Everything else sounds reasonable :-)
MIST board, FPGA based Atari STE and more: https://github.com/mist-devel/mist-board/wiki
User avatar
MasterOfGizmo
Atari God
Atari God
Posts: 1356
Joined: Fri Feb 08, 2013 12:15 pm
Contact:

Re: ZX Next port

Post by MasterOfGizmo »

ManuFerHi wrote: Fri Apr 02, 2021 6:07 pm The problem with Chinese FPGA dev boards is that they don't have the MSEL pins available, they all come with flash memory and you can't change the mode to passive serial for programming.
I still remember that I used a cheap chinese FPGA board for the first tests and that I lifted the MSEL pins up the board. That of course only works if there are pins and no solder balls ...
MIST board, FPGA based Atari STE and more: https://github.com/mist-devel/mist-board/wiki
slingshot
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2306
Joined: Mon Aug 06, 2018 3:05 pm

Re: ZX Next port

Post by slingshot »

MasterOfGizmo wrote: Thu Sep 16, 2021 12:46 pm
ManuFerHi wrote: Fri Apr 02, 2021 6:07 pm The problem with Chinese FPGA dev boards is that they don't have the MSEL pins available, they all come with flash memory and you can't change the mode to passive serial for programming.
I still remember that I used a cheap chinese FPGA board for the first tests and that I lifted the MSEL pins up the board. That of course only works if there are pins and no solder balls ...
Good trick.
I've experimented a bit with the 10GX in Quartus. The generated RBFs are quite big (5 MB compressed), I wonder how fast it'll be uploaded via the bit-banged passive serial interface. (And luckily the 10GX support seems really free.)
User avatar
MasterOfGizmo
Atari God
Atari God
Posts: 1356
Joined: Fri Feb 08, 2013 12:15 pm
Contact:

Re: ZX Next port

Post by MasterOfGizmo »

slingshot wrote: Thu Sep 16, 2021 1:16 pm I've experimented a bit with the 10GX in Quartus. The generated RBFs are quite big (5 MB compressed), I wonder how fast it'll be uploaded via the bit-banged passive serial interface. (And luckily the 10GX support seems really free.)
Per datasheet passive serial as the MIST uses is limited to 100Mbps so in theory this should allow to download 5Mb in half a second. But it's likely to be much slower.

But the GX also supports a "Fast passive parallel" mode (FPP) which is 32 times faster than PS and should allow for reasonable download speed. The overall timing of that looks very similar to PS but it just uses 8, 16 or even 32 data lines instead of one.

Another thing with the GX is that it runs its IOs at 3.0 volt max. So the MCU would also have to run at most at 3.0 volt if level shifters shouldn't be needed.
MIST board, FPGA based Atari STE and more: https://github.com/mist-devel/mist-board/wiki
Post Reply

Return to “MiST”