A way to choose core upon power up.

[sorgelig]

I've just pushed the commit. IO Firmware will display OSD with list of cores if core MENU is loaded. I think, some users (including me) would like to have OSD displayed at startup with core choice. Here is dummy core which should be placed into SD card as a core.rbf.

There is one bug in OSD menu i've discovered: if i press Cursor Down key, the cursor will jump 2 or 3 times at once. It happens only with first key press. Does anyone know how to fix it?

This is a concept. The core can be modified and some background picture with MIST logo can be added. Currently 2bpp video used, but can be easily changed to any color format. May be this way of launching would be good for those who have difficulty to access F12 key, since OSD menu displayed at startup. I think, FW need a little tuning to remove item "core" from list for MENU core.

Can press ESC key to access FW upgrade, btw.

If it's completely unwanted feature then feel free to revert the commit.

[harbaum]

Sounds like a good idea. I'll have a look at this. And yes, some special handling by the firmware when it detects the menu core is definitely possible.

[sorgelig]

Actually i've pushed this special handling in FW. Just need to tune it to work more smooth. I don't know why cursor down key jumps 2 times on first press. Since you know FW better, may be you can provide a better handling.

[sorgelig]

Skipping core.rbf in list can be achieved by setting hidden attribute. So, this tweak is not required. Just need cursor jump fix. Till, do you have a picture for background with MIST logo?

[renaudhelias]

You could detect "core.rbf" and then... boot it if exist or else display a choice menu if somes or else display "no core found"

[fordp2002]

I would suggest making the modifications to the firmware small as the firmware space is precious while the space on the SDCARD is plenty.

[harbaum]

Without core the firmware cannot display anything as it's the fpga that drives the vga output.

But I could hide core.rbf from the list. But you might actually want to select core.rbf to return to the menu from another core.

I don't have a title screen to use. Perhaps there's some nice hdl graphics demo we could use. Something like the first lessons in my tutorial but a much cooler.

[harbaum]

And I'll look at the double key issue once I finish my current ethernet tutorial in two or three days.

[sorgelig]

As i've wrote above, core.rbf can be easily made hidden by setting hidden file attribute on any PC. So, no modification in firmware required. And user can choose hide or show by himself.

For me, standard OSD menu is sufficient. Doing some fancy menu is redundant and will occupy space in firmware. But background full screen picture can be easily added because it will be in FPGA core.

[harbaum]

I fixed the firmware issues.

[sorgelig]

Thanks! Now it's usable :) I will make some better backrgound. May be grey color with CRT lines should be good looking.

[sorgelig]

I've released Menu core https://github.com/sorgelig/Menu_MIST/tree/master/release Added old non-tuned TV effect as a background. Any opinion?

[harbaum]

The new way of reloading cores via JTAG doesn't work with the Minimig or the MIST core. I'll have to fine tune this a little more.

Would it hurt to keep the old method of suppressing the core loading with DIP-1 intact? Most people could then choose to use your new method. But the DIP-1 would still work as before.

[sorgelig]

Hm, i didn't understand what you've wrote. I don't use DIP switches, so i don't care their ON states. But i would like to be able to load cores from JTAG with full reinitialization with DIP1=OFF. If you mean, you want to tweak the flags in reserved memory, then no problem.

[sorgelig]

Hello, Till.

I'm looking around time after time for FPGA boards. Basically i'm still trying to find VGA-In + HDM-out FPGA board. So far, no suitable boards found, but i've found something more interesting!

There is Xilinx Zynq-7000 hybrid chip. It has ARM CPU + FPGA. It looks like ultimate solution for the next MIST. And ARM CPU is very powerful and thus we can shift more tasks to ARM. Also can make hybrid emulators where some parts will be emulated on ARM side and other on FPGA. I'm not sure how tight FPGA and ARM integrated and how fast communications are between them, but at least it should cover current Altera + ARM tasks. This board looks like MIST in Raspberry Pi size: http://shop.trenz-electronic.de/en/TE0726-01-ZynqBerry-Zynq-7010-in-Raspberry-Pi-form-factor FPGA part of Zync7010 is a little more powerful than FPGA in MIST, right? What do you think?

best regards, Sorgelig

[fordp2002]

This is way off topic but the Zynq-7010 is too small for most things, the Zynq-7020 would be better ;) Say this: http://www.myirtech.com/list.asp?id=502

[Newsdee]

I'm sure we can squeeze more out of the current hardware :) maybe make a mini VGA->HDMI dongle to avoid having to revise the board? On Jan 19, 2016 11:10 PM, "Simon Ellwood" notifications@github.com wrote:

This is way off topic but the Zynq-7010 is too small for most things, the Zynq-7020 would be better ;) Say this: http://www.myirtech.com/list.asp?id=502

— Reply to this email directly or view it on GitHub https://github.com/mist-devel/mist-firmware/issues/2#issuecomment-172882116 .

[sorgelig]

Oops.. I wrongly send message to this topic while it meant to be send to Till e-mail. Ok. Anyway.

[rkrajnc]

While I think the current MiST board is quite OK for what it is, in the future, there doesn't seem to be much room for 'home-made' FPGA boards, especially as any bigger FPGA comes only in BGA packages, which means very expensive PCBs.

Luckily, there are a bunch of very cheap FPGA boards out there already, which could be used for a sort of MiST2, especially the SoC ones (ARM + FPGA). All you really need is some fast memory (DDR3), an HDMI output, USB, and some easily interface-able GPIO pins for old joysticks, maybe dedicated SD card, etc. One of the big advantages is that you can run linux on such a board, plus emulate a CPU on the ARM.

But let's wait and see what time will bring, besides, there's lots to do with the MiST we have today.

[sorgelig]

With big choice of USB gamepads and joysticks, i don't understand why need to use old hard-to-find joysticks. For me, ultimate joystick solution is wireless PS3 gamepad. But, i doubt it's possible to add support for this gamepad in current MIST board due to lack of space in IO controller.

[harbaum]

Regarding the PS3 controller: The MIST uses a heavily modified version of the Arduino USBHostShield driver. And that has gotten bluetooth support and even PS3 controller support. So i am pretty sure it is possible and that it fits into the IO controllers flash space. But it will be significant work.

Regarding an updated MIST: Yes, there are many nice options etc. But don't underestimate the amount of work required to bring all the current functionality onto a new board. There's definitely so much possible with the current board that i don't see the big advantage of a new board. We e.g. simply have no use for a bigger FPGA. No core so far is using more than 70% of the current one. Only the Amiga makes use of the full 32MB RAM but i don't think many users ever had a real use for that. The ARMs flash still has 50kb space and there's also some RAM left. Starting a new board would bring development for the current one to a full stop and it'd take some months before we'd have the current state stable on a new board. I prefer to see what the current board can still do.

Did i e.g. mention that i'd like to see a SNES core? Or a PS1 core? How about a hi rez color graphics card for the ST? Support for bluetooth input devices? And also all existing cores really have room for improvement.

[sorgelig]

Current IO firmware doesn't have Bluetooth stack, and PS3 controller requires special pairing procedure. Will it fit into 50kb? Well.. If Arduino has it all already, then shouldn't be big problem to add it. I will observe arduino code. Regarding SNES, PS1 and other non-existent (i mean open source) cores: it's completely different level of development. It involves a lot unexplored and sometimes unknown information. It requires people who is very familiar with these platform. Even you have many docs, but you never touch a real hardware of these consoles, then chances to make it near the zero. So, it's matter of chance. Chance to get some people who is not only familiar with FPGA but also in simulated hardware and who would like to make it open source. MIST have many cores ported already, but they weren't developed from ground for MIST. But there is no SNES or PS1 cores exist. If someone will start to do this, then it will take years. 4-5 years according to histories of different existing cores.

About new board: It's not only about usage of LUTs. I found, that having SRAM could help in many cores. Most retro consoles could fit in 256kb of RAM with simplier structure than using SDRAM. So, either bigger FPGA or external RAM would help a lot. Don't forget about HDMI. It becomes more and more annoying to deal with VGA signals. Most converters expect either only TV or only DMT VGA. And i didn't find any converters supporting wide range of video sync. At the same time HDMI has CIA mode which covers both old TV modes and modern progressive modes natively by most TV and even by cheap HDMI converters (in case if need to convert frame rate). So, we are stuck with retro-VGA connector requiring very special monitors supporting all possible modes. And even then, what if i don't want to use the monitor? Then i have NO choice.

As for higher resolutions: I would love to see Amiga Workbench on progressive VGA mode. @rkrajnc, is it hard to add progressive modes into Amiga AGA? It could be good boost in usability.

[harbaum]

That all sounds reasonable. Whoever wants to build a new board can do so. It's all open source ...

And it took me two weeks to write a Gameboy core that runs many games. Amiga AGA was first public on MIST. The Sinclair QL was also written from scratch for the MIST as well as the Atari ST or the Acorn Archimedes. All of these took a few months at most. So a very basic SNES can be done in some weeks as well i am sure. Not everything has been ported.

[sorgelig]

Hmm.. It seams the BT porting to MIST won't be easy. Arduino's USB stack written in C++, while MIST's IO in C.

[sorgelig]

It's not fair to compare Gameboy/QL simple architectures with SNES. As far as i know there is no 65c816 core avaialble, nor very complex SNES PPU. Amiga AGA wasn't developed from ground, but on modifications of mature ECS implementation according to @rkrajnc story. And he is very professional in FPGA to be able to do this upgrade.

I also have experience to make core from so-called "scratch". It's BK0011M. So-called, is because the main component CPU (DEC PDP-11) was recently made available be some professional de-caper. It took couple weeks to make a fully working retro computer. But it also has simple architecture where the only one complex model - CPU. Everything else is just discrete logic. (I didn't release it yet, because i want to polish the code). Even with simple architecture it takes long time to understand how it was working more than 20 years ago because i don't have access to real hardware now.

For SNES we have NOTHING for FPGA. No any skeleton to port or improve. And architecture is quite complex. More complex than NES. I know, you are very professional developer, but frankly speaking i wouldn't bet for its readiness in a few weeks even if you will dedicate full working days for it.

More believable is to convince that Japanese developer to port at least closed source version for MIST ;) May be he can do this for free MIST board?

[rkrajnc]

sorgelig: As for higher resolutions: I would love to see Amiga Workbench on progressive VGA mode. @rkrajnc, is it hard to add progressive modes into Amiga AGA? It could be good boost in usability.

Amiga core already outputs progressive PAL modes. Do you mean flicker-fixing the interlaced modes? That is probably not going to happen, as it would require more memory bandwidth than is available (need to save whole frame to SDRAM and read it back). There is still an option to support other display modes, like Productivity, Super72, Euro36 and Euro72, but I will have to write support for programmable display modes. Lots of reading & testing to do ... ;)

[harbaum]

The SNES PPU is available in vhdl and the T65 has partial support for the 65816. And emulator source code is the ultimate documentation. But please lets stop arguing. I may do it one day but ATM I am busy with the existing cores. So you are right: Its too much work for me at the moment.

[sorgelig]

Do you mean flicker-fixing the interlaced modes?

Nope, i didn't mean de-interlacing. I mean extra resolutions. When I've used real Amiga 1200 i had extra modes to choose and they weren't laced. Yes it was called Productivity, but i don't remember the exact names. May be no need to support all of them if it's too complex, but couple hires modes should be fine. Like 640x480p or 1280x720p.