zx spectrum: new slot devices, floating bus restore, big mface tidy-up

[TwistedTom]

2 new slot devices: spec-mate, micro-pokeer[sic]

reinstate floating bus, slot device friendly this time
(let devices have a callback, if by the last-in-chain slot device, iorq_r hasn't returned anything, return floating bus value instead of just returning 0xff)
add floating bus to applicable 128k machines (not +2A,+3 they don't have it)

split up multiface devices into hardware revisions (some bios roms weren't working because h/w is different)
added correct partial decoding of ports
fix issues with mface128, mface3 (missing logic)
add mprint missing stuff, parallel port
add mface3 pal
change default key for "magic button" (backspace is mapped for 128K machines and in natural keyboard mode)
don't clash with disk devices as it's possible to have 2 "magic button" devices chained eg. mface + beta, so use something else (numpad-) for disk devices
all models now work correctly with working disk interfaces: beta, opus, disciple/+d -> OK, kempston disk, +3 disk -> no write support

fix bug in specpls3 preventing paging lock being fully applied
move HC91+ clone into spectrum.cpp (it's a clone of 48k, not 128k)
add dual-bios cp/m roms (not working) and inf1 roms

sort out +2A,+3 bios roms:
redump english v4.0, v4.1 (the real chips are 2x 32KB not 4x 16KB)
add bios options to +2A
correct spanish v4.0 (is v4.1)
add spanish v4.0
make spanish dumps 2x 32KB not 4x 16KB to match real h/w

[TwistedTom]

btw, has anyone got a schematic for Kempston disk interface? I had it once upon a time but can't find it now, would be nice to get that fully working...

[p1pkin]

btw, has anyone got a schematic for Kempston disk interface? I had it once upon a time but can't find it now, would be nice to get that fully working...

what you mean "get that fully working" ? Kempston Disc v3 was fully working at the point it was implemented.

Kempston Disc v2 AKA "Watford SP-DOS" in theory fine too, but at practice is useless / non working without missing system disc.

[TwistedTom]

what you mean "get that fully working" ?

Seems there's no write support, at least creating a new .mfi image and attempting format fails. What little software is available is .dsk format which is read-only in Mame.
Was writing ever working? perhaps a regression... wd1770 is fairly popular and everything else seems to be working so I assumed its an issue with the device rather than the fdc.

[rb6502]

There was a major bug in the low-level floppy handling (common to all controller chips) that was fixed at the last minute for 0.230. Have you tested formatting on 0.230?

[TwistedTom]

Have you tested formatting on 0.230?

Yes, I checked with official 0.230 binary release, not working.

[galibert]

How do you do the formatting with a spectrum? Tell me as if I never used a spectrum, because I never used a spectrum :-) OG.

…

On Mon, Apr 5, 2021 at 1:54 PM Tom ***@***.***> wrote: Have you tested formatting on 0.230? Yes, I checked with official 0.230 binary release, not working. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7913 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGSF4IQ2JCFS3QXCR6TTJ3THGQHDANCNFSM42FWKZ5Q> .

[TwistedTom]

How do you do the formatting with a spectrum? Tell me as if I never used a spectrum, because I never used a spectrum :-)

Well you're in for a treat as the Kempston disc interface is a very odd syntax even by Spectrum standards ;-)

PRINT #4: FORMAT "disc_name": PRINT 1,80,2,1

last part is drive #1, 80 tracks, 2 sides, 1=6ms step rate
PRINT and FORMAT are tokenized not typed, so you want P for PRINT, extended-mode+0 for FORMAT, (extended-mode is caps-shift+symbol-shift, then hold symbol-shift+key)

[galibert]

How should I start mame to have the correct interfaces? OG.

…

On Mon, Apr 5, 2021 at 8:19 PM Tom ***@***.***> wrote: How do you do the formatting with a spectrum? Tell me as if I never used a spectrum, because I never used a spectrum :-) Well you're in for a treat as the Kempston disc interface is a very odd syntax even by Spectrum standards ;-) PRINT #4: FORMAT "disc_name": PRINT 1,80,2,1 last part is drive #1 <#1>, 80 tracks, 2 sides, 1=6ms step rate PRINT and FORMAT are tokenized not typed, so you want P for PRINT, extended-mode+0 for FORMAT, (extended-mode is caps-shift+symbol-shift, then hold symbol-shift+key) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7913 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGSF4LKXW5M6RBWAHC3T4TTHH5L5ANCNFSM42FWKZ5Q> .

[TwistedTom]

How should I start mame to have the correct interfaces? OG.

You just want kempdisc, it's not dependant on anything else being present or not, so:

mame spectrum -exp kempdisc

Also, I can rule out regression, I just tried the first official release which had kempdisc (0.223) and it's the same.

[Tafoid]

Is there any reason this is still sitting not applied?

[p1pkin]

in general it is OK, but I noticed one thing
@TwistedTom can you please recheck changes like "data &= something" replaced with "data = something" ? it was like that for a reason, and &= modified only specific bits just like real expansion devices, while other bits may retain original (bus) value. i.e. (some of) that devices was written with future full per-bit floating bus simulation in the mind.

[TwistedTom]

@p1pkin yes it's intentional, the &= bit mask only worked when "data" was initialized with 0xff. If we're using floating bus value, then the mask no longer works as it can return any value.
eg. floating bus returns 0xfe, device sets bit 0, 0xfe & 0x01 = 0x00 -> fail, bit 0 is lost

Now we could introduce better masking obviously but i'm not sure it's necessary. It seems devices do return the whole byte (no un-used/hi-z bits). Take for example Kempston joystick, even though it only uses 5 bits, the un-used 3 are explicitly set low rather than left floating and some games even break if this is not the case. Multiple chained devices should never be using the same port anyway so in theory un-used bits shouldn't actually matter all that much (I don't think there's any scenario where software will read a certain port and expect certain bits from exp dev A and certain other bits from exp dev B simultaneously).
That said, it's of course possible there's cases where certain devices only use/return certain bits and leave others un-used/hi-z, so for full accuracy we would need to check every device h/w or schematic to confirm which bits.
In reality the games that use floating bus use certain ports which the devs chose not to conflict with known exp devices that existed at the time. It's possible devices that came later could use the same ports and conflict but I'm not aware of any such cases. The floating bus "trick" was discovered quite late in the Spectrums life so most well known exp devices did exist when the games were written.

[rb6502]

@TwistedTom Could you update this so it doesn't conflict and I'll apply it?

[TwistedTom]

Had forgotten all about this!
Fixed the conflicts, have a feeling clang build will probably fail, gcc/windows is ok, don't have a local clang setup, better wait for autobuilds to complete...

[holub]

Write function as well

[TwistedTom]

It's just rename, no change to functions. The proper decoding is any even port (a0=0) accesses ula, not specifically port 0xfe, so rename makes more sense.

[holub]

Right. But there is FUNC(tsconf_state::tsconf_port_fe_w)) in same line. Is it compilable without renaming this as well?

[TwistedTom]

That's your function in tsconf class, so up to you if you want to rename them or not. It's just the functions back in base class (spectrum.cpp) that you're inheriting from that are renamed.