This patch add Multiface1 emulation to fuse... Just for
fun :-)
I add the Multiface 1 red button menu entry to Machines
menu branch, it may not so good but i have no idea of
the perfect place.
The multiface 1 stealth option represents the J2 jumper
state - disable Multiface, if checked, J2 open. The
joystick port always disabled (J1 always "open").
The multiface not work in 128k+ machines (I need some
info may the proper ports an port masks... or
schemantic of mf128 and mf+3 )
Wiki: Fuse 1.2 Release Plan
Wiki: Fuse 1.2.2 Release Plan
Wiki: Fuse 1.3.0 Release Plan
Wiki: Fuse 1.3.1 Release Plan
Wiki: Fuse 1.3.2 Release Plan
Wiki: Fuse 1.3.3 Plan
Wiki: Fuse 1.3.4 Release Plan
Wiki: Fuse 1.3.5 Release Plan
Wiki: Fuse 1.3.6 Release Plan
Wiki: Fuse 1.3.7 Release Plan
multiface 1 emulation
multiface1,128,(+3) emulation
Logged In: YES
user_id=57243
Here is an updated patch, some thing is better (the RED
button "handling"), and a multiface128 and (that time broken
:-( ) mf+3 emulation...
Logged In: YES
user_id=57243
Originator: YES
Here is an updated patch to the current SVN
File Added: fuse.multiface_06.diff
updated to the current svn
Logged In: YES
user_id=57243
Originator: YES
Now, (with this patch) the multiface 1 and multiface 128 working with interface 1..
so it is possible to save screen or program to microdrive cartridge.
The problem was the ROMCS handling of fuse... :-(
File Added: fuse.multiface_07.diff
mf1/128 work with if1
Logged In: YES
user_id=57243
Originator: YES
Now multiface working with 16K, 48K, TC2048, 128K, +2, +2a, +3, and +3e models.
File Added: fuse.multiface_08.diff
working mf one/128/3
Logged In: YES
user_id=57243
Originator: YES
Now, MF128 and MF3 stealth at power on.
File Added: fuse.multiface_09.diff
Here is an updated patch.
File Added: fuse.multiface_10.diff
Here is an updated patch for Multiface One/128/+3
Thanks, Gergely! Could you give us an idea of the current level of support for each interface, and what else there is left to do? It'd be great to get this committed soon.
Attachet two patch, one with MF changes, and an another with menu "split up".
I've committed the splitting of Select ROMs into Machine ROMs and Peripheral ROMs. I made a small change and used the plural form, because many of the machines have more than one ROM image and it seemed to make more sense this way.
The patch needs to be refreshed after recent changes.
Please be careful to make sure you don't accidentally lose your changes to add the "Multiface" option to Select ROMs -> Peripheral ROMs menu.
machines_periph.c should be tidied up so that the Multiface is only available on 48K, 128K and +3 families.
PERIPH_TYPE_MULTIFACE and #include "peripherals/multiface.h" should be placed in alphabetical order. Listing of multiface.c and multiface.h should be in alphabetical order within Makefile.am.
mf_ and MF_ should be multiface_ and MULTIFACE_, including changing UI_MENU_ITEM_MACHINE_MF to UI_MENU_ITEM_MACHINE_MULTIFACE.
There's a funny / MF1 / comment in multiface.h which looks like it needs to be removed.
I'm not sure if it is better to model MF1, MF128 and MF+3 as one single peripheral or not. To be honest, I feel it best not to, although I can see the motivations for going for a common peripheral. I would say it encumbers the code too much to be beneficial, though.
On a hard reset, the Multiface's RAM should be wiped. You should probably memset() to 0 for a hard reset. You should remove the GCC_UNUSED marked against hard_reset when you do this, assuming you do not clear the RAM for a soft reset.
Where possible, we should use static const char * const [] arrays of string literals, such as name[] in mf_get_type().
A unittest would not go amiss.
Otherwise the functionality looks great given a cursor glance!
Sorry, "cursory glance", i.e. a quick look.
I attach an updated patch:
i try to do my best... only unittest missing at now.
And of course emulation does not deal with Multiface1 kempston joystick interface..
I updated the patch:
- unittest
- man
- more consistent menu strings
Again, I've committed a change to the ROMs handling in the man page. Whilst I don't mind updating this patch to correct for that, I think this patch might need another respin anyway, so it'd be helpful to account for this.
The code seems a lot tidier. I still feel we should try to split out the different Multiface types, though. We would keep a single multiface.c file and share most of the code between the interfaces, as I can accept that they have a good amount in common. PERIPH_TYPE_MULTIFACE would be split up into separate values. multiface_reset() would test for all of these values. We then use the ordinary machines_periph code for determining compatibility of interfaces with different models of Spectrum, and multiface_get_type() would either be removed or simplified.
Part of my thinking is that we should have three separate peripheral port tables, to avoid the switch() within multiface_port_in(). We can and should do this irrespective of how the peripherals are modelled in the UI.
Another part of my thinking is that peripheral selection is likely to get reworked at some point and it would be helpful if the Multiface emulation followed the same pattern as is used for other interfaces.
The grammar needs tidying up slightly in man/fuse.1. I'm afraid as I've learnt English by ear rather than formally it's hard for me to properly explain why, but "Emulate a Romantic Robot's Multiface" is the issue. I think "Emulate a Romantic Robot Multiface" would be fine.
(Our manual is not perfect: "Emulate a Opus Discovery" should be "Emulate an Opus Discovery" but I will make that change separately.)
"Multiface emulation avaliable for 16K, 48K +Timex TC2048, 128K, +2, +2A, +3, +3E and SE machines". Wait, is it enabled for Timex? We also need a comma after 48K.
The "dumb" double quotes used in '"invisible" or "stealth"' should be avoided unless we are referring to straight quote marks used on the Spectrum (such as in LOAD ""). We do use smart double quotes somewhere in the manual but we should try to maintain a consistent style throughout, and single quotes seem to be the usual style in man pages. We should probably go through and replace some of the smart double quotes but that is a change for another day.
Of course, my changes mean that ROM numbering now starts from 1 for peripherals, so that part of the patch needs redoing. Sorry about that: there's an element of "the sooner the better" but it does disrupt any patches currently in progress. However, it should make it a little less disruptive to add machines in future, so hopefully the good outweighs the bad.
Peripheral ROMs should be listed in almost-alphabetical order. The Multiface ROMs should appear between "DISCiPLE" and "Opus Discovery", starting at menu action 5, ROM group number 4 and ROM image number 4. The three different Multiface ROMs should only be grouped together if we can display meaningful titles for each ROM (i.e. not just "ROM 0", "ROM 1" and "ROM 2"). Relying on the preset filenames is not sufficient in my view. I don't really see the advantage in grouping these together besides cutting down on menu items. For that reason, I feel they should be split into separate "Multiface One", "Multiface 128" and "Multiface +3" options. Note: the ordering of "One", "128" and "+3" is preferable over whatever may be considered "alphabetical".
On consideration, my sorting of "uSource" is probably wrong. I'm not sure if we should treat the "u" as a mu ("µ"), sorting it separately from letters in the Latin script, or treat it as a different letter case as "m", or treat it as the Latin letters "mu", or treat it as "micro", or what. Treating it as "u" is probably bad. I don't know if this applies to #includes. This should be fixed separately and I have no idea how.
We should not be using "backtick" a closing quotation mark, ever. It should use it as an opening quote in places where we already do this. Ideally, we will use UTF-8 translations that will convert to smart quotes in the future, as the untranslated "C" locale must use (British) English with ASCII only.
Schematics for MF3
Just a few more changes I'm wondering about:
We can deal with compatibility with Beta, +D, DISCiPLE and Opus later, but we do need the other changes I have described.