MiST core and firmware changelog

[Newsdee]

sorry for asking, but why messing with keys and auto-fire when things like demos: nocooper 1984, atari ste 20th anniversary demo and games like turricanII dont work?
basic things like a proper fpga implementation are left behind

That's because the FPGA cores and the firmware are different projects with different contributors, and need different skills, knowledge, and motivation to work on them.

[farvardin]

sorry @jcarvalho, but you often complain about how the MiST is not correctly finished and such. It's an open source development made with the passion of some few (unpaid) developpers. We must be very grateful about what was already made. I'd be tempted to say if Turrican II is not working correctly on the Atari ST core, then use the Amiga one, I've just played it until after the 1st boss, and it was gorgeous and perfect! Yeah, on some aspects, some emulators are "better", but on other the MiST is better, that's it. You have almost real original hardware with MiST, but there is maybe 2% which is not perfect (maybe also because of undocumented features) and that prevents some demos to run.

[slingshot]

Hi!
I've sent a PR for the firmware to skip the limit on the number of max. OSD options.
https://github.com/mist-devel/mist-firmware/pull/14
Any chance for a new release with it? It would open some possibilities in some cores (e.g. in the new Amstrad core from Sorgelig). The gap between the OSD options in MiST and MiSTer could be narrowed then.

[Sorgelig]

firmware_180808
===============
- Support more than 7 OSD options (by slingshot).
- Support '?' in requested file extensions.

[RealLarry]

What a great news!
You're title is saying Fuji Shaped Bastard. That's right. You're admirable!

[Sorgelig]

firmware_180810
===============
- Support 2 mounted images at the same time.

[krupkaj]

great, thanks for a new version

[christianlucio]

Hi,
with the latest firmware I have the problem that you can not list anymore the disk content in the c64 core (load"$",8 and then "list")
Anyone can confirm that mistake ?

[NML32]

Hi,
with the latest firmware I have the problem that you can not list anymore the disk content in the c64 core (load"$",8 and then "list")
Anyone can confirm that mistake ?

I’m able to list disk contents.
Works for me I tried firmware ATH180808 & ATH180810.

[DrOG]

Disk listing works flawless with latest FW.

[christianlucio]

I now tried a newer C64 core and here everything is o.k. again !

[mrr19121970]

I now tried a newer C64 core and here everything is o.k. again !

can you provide the link ?

[christianlucio]

I now tried a newer C64 core and here everything is o.k. again !

can you provide the link ?

The one out of this subforum:
viewtopic.php?f=115&t=33985&start=25

[squid4]

Same problem here with current Mist site C64 core and firmware_180810.upg - i.e. D64 images don't load. Also noticed a few menu issues with older cores with this firmware.

Backup to firmware_170412.upg for me as it doesn't have these problems.

[slingshot]

As the source code of that C64 core version is not available, I cannot check what's the problem. The change of the UIO_[GET|SET]_SDSTAT command should not cause problems with well-written cores. ZX Spectrum still can load disks (without any change in the core), other C64 versions, too.
Also, what core has menu issue? Show me an example, and I'll fix it.

[slingshot]

---

[squid4]

The older spectrum core had messed up menus with this new firmware. I've updated it with sorg's latest version and it looks OK.

[verm71]

One little issue that I've always kept an eye on (not sure if there's a bug log anywhere) is if I swap floppies, the disk free and/or label isn't updated properly when doing a directory listing.

Say I have a nearly full disk labelled "HELLO" and a fresh disk labelled "YOYO", inserting the first D64 (labelled HELLO), load"$",8, then LIST shows the expected results. If I swap the D64 to YOYO without resetting, and then also load"$",8, then LIST, the disk shows up as label HELLO, but with YOYO content.

I think I recall this having to do with write protect sensor not triggering the disk change to the DOS.