#331 Didaktik 40/80 emulation

[Gergely Szasz]

Here is a "preliminary" patch for Didaktik 40/80 emulation (if somebody want to play with it)

Enabled for 16k/48k machines
ROM: didaktik.rom 16k (!!not 14k)
Emulated only the disk interface and the ROM/RAM paging logic. PIO and SNAPSHOT are not emulated.
Machine boot up and MDOS works normally, only all disk command end with "Drive is not ready (Retry = R)"
POKE #xx,yy say OK (but i do not know, how to read back the value)

CAT and LIST * read h:0 t:0 s:1 (the first) sector, but after that say: "Drive is not ready (Retry = R)"
All data from WD2797 arrives ok...

[Gergely Szasz]

Here is a patch to implement i8255 PPI.

• Makefile.am: I have to change the order of libperipherals.a and libdisk.a because now libdisk.a depend on libperipherals.a
• peripherals/Makefile.am: add i8255.[ch]
• peripherals/i8255.[ch]: the code itself ;)
• peripherals/disk/didaktik.c: allocate, reset and use a i8255 PPI...

[ub880d]

why is there "if( settings_current.joy_kempston )" in case of reading from port C (in didaktik_8255_read)? kempston joy can be read on port 31 which stands for port A on 8255 in D40/80

[Gergely Szasz]

Hmm.. because this is the cleanest way to implement overlapped kempston joy emulation.

The kempston joystick implemented in joystick.c with bind to joystick settings, joystick and keyboard joystick routines, etc. so this way we can avoid to rempliement it.

If kempston joystick enabled, it works as is. (The same as works if plugged to didaktik edge connector.)

o.k. we cannot check the state of port A (in, out, mode 1/2)...

[Stuart Brady]

I think UB880D's real question was "why port C and not port A?" Surely the joystick would connect to port A, not port C?

It might be cleaner if we were to disable the "real" Kempston port when emulating a D80. The Kempston enabled setting would then simply determine whether there was a joystick attached to the i8255 port, but if a program were to set port A as output, we could presumably have reads from port 0x1f fail as expected. The scheme in this patch means that i8255 setup does not affect the Kempston port.

[Gergely Szasz]

Uhum.. There are two ways:

1. as you said: we disable the "original" Kempston port, and somehow read the static kempston_value (eg with a new public function in joystick.c), and of course check port A mode, etc.
2. only just add port A mode check, etc.

[Gergely Szasz]

Here are the patches:
01c -> 1.
01b -> 2.

[ub880d]

just a cosmetic change to diff.i8255_01c.patch.

i'd change

ret = joystick_kempston_read( 0x3f, &tmpattached );

to

ret = joystick_kempston_read( 0x1f, &tmpattached );

it has no impact on result as parameter port is not used in joystick_kempston_read(), but i see it less confusing at first sight

[Stuart Brady]

The i8255 should really make use of a callback function passed in from didaktik.c. That callback function should then check whether the Kempston interface is enabled. There should be no Kempston-specific code in i8255.c and no handling of i8255 internals in didaktik.c.

We have another device that needs i8255 emulation, the ZXATASP. It might be good for us to get zxatasp.c converted to use i8255 before we add this to the Didaktik 80.

I've just committed a change that handles port attachment using a bitmask instead of as a single boolean value. It would be cleaner for joystick.c to add a new function that returns kempston_value without taking an "attached" parameter, so we don't have to supply a fake port number at all. Do we know how floating inputs to the i8255 would be seen by the Z80 when reading from the i8255? Are outputs of the i8255 itself allowed to float? My view here is we should handle floating inputs to the i8255 from the joystick exclusively within didaktik.c, but there should be no sophistication in didaktik.c regarding reads of the i8255 itself.

[Gergely Szasz]

Are outputs of the i8255 itself allowed to float?

Yes and no ;)

If an i8255 port (A/B/C) programmed as output, than all pins belong this port, are logic 0 or 1 (0V or 5V ). So pins cannot "floating".

If a port programmed as input, then all pin of that port are in 3rd state, (not logic 0 nor logic 1, it has a very high impedance /e.g. >100kOhm/). This way the (i8255 port) output is detached from the "DATA bus" (this is not the Z80 data bus!), so "other" circuitry can set the logical values of the pins, and i8255 can "listen" to it...

If we do not connect anything to force this pins to logic 0 or 1, than (because the high impedance) any electrical interference or noise can cause randomly logical 0 or 1 level on these pins. So if we read port again and again, we see it is "floating". (On high speed systems this can be more complex of course)

We could avoid float, to lower the input inpedance of this pins to a "proper" value. e.g. connect these pins to GND (logical 0) or +5V (logical 1) with resistors (not be confused with OC pull up resistors). Let's see a kempston interface schematics ;-). All pins (D0-D7) connected to GND (logical 0) with ~20k resistors.

But attention: this "floating" is totally different from ZX Spectrum floating bus effect. This is really "random" thing and not related to Speccy's system bus (D0-D7) and 470Ohm resistors...

So, back to the original question: all (logical) IC with high inpedance inputs can show "floating" data effect if there is some not properly pulled up or pulled down input pins. So i8255A can too...

Precisely not the outputs of i8255 float, but CPU read the values of the floating inputs ;)

Of course if we disable i8255 (or exactly not enable when CPU read from it) than we get the "floating bus" effect of unattached ports...

[Gergely Szasz]

Here is a patch (version d :)

Now, didaktik registers a callback to get informaion about kempston_value.
Other little changes:

• i8255_reset(): not reset the "input" state of pins when reset
• write to CTRL reset the output "latch" of i8255 cleared according to datasheet

[Fredrick Meunier]

Thanks Gergely.

Should i8255_state be an attribute of struct i8255_t as it seems to be part of the state of the 8255?

[Gergely Szasz]

Hi Fred!

Here is a modified patch to implement /CS and RESET handling in i8255 emulation itself.

...

after i wrote it, i became unsure...

Should i8255_state be an attribute of struct i8255_t as it...

Hmm... this state really represent 2 flip-flop on D40 board (IC8: 74LS74), so even we implement CS and RESET handling in i8255 emulation, we need some similar "state" (ic8_74ls74 in this patch) to "track" the state of these two flip-flops.

IMHO: there is no so mutch sense to emulate the CS state separately. (in this patch I do shortcut for read and write when CS is inactive, to avoid "empty" call of i8255_read and i8255_write, because we know exactly what happen if we try to read or write when CS is inactive... ??)

The RESET state is questionable too (at now), because we (at least I) don't know, what exactly happend when we set RESET pin permanently high...? And we cannot test, because we haven't got any software which read or write from/to i8255 during RESET is high...

... ???

[Fredrick Meunier]

OK, I've created a 2016-04-25-didaktik branch to work on didaktik emulation and would like to get any completed parts of this code into the release if possible. It looks you have addressed Stuart's feedback about the kempston callback already so I think there is nothing else to do there.

For the parts where you are guessing behaviour as we don't have a real example, I suggest just adding comments to make that clear.

Is the shortcut you mean the early return statement in i8255_read() in the I8255_PORT_B case or is that a mistake?

Also, it looks like intrq in typedef struct i8255_t should be a i8255intrq rather than a i8255port?

[tomascz]

Hi there,
there's been quite a deep discussion on Didaktik drives on the Czech forum OldComp, so I'm getting in touch to mediate it - hopefully you'll find it helpful :-)
First, some terminology (I noticed some confussion). The Didaktik drives were manufactured either as 5.25" units (aka, Didaktik 40 or commonly also abbreviated as D40) or 3.5" units (aka, Didaktik 80 or D80). The older drives (until 1993) were equipped with Western Digital chip WD2797, the newer ones (after 1993) then with Intel chip i8255. The executive code was supplied in a "system", or in nowadays terms rather a "driver", called MDOS (standing for "M Disk Operating System" where the lonely "M" probably refers to the computer model introduced a year before the first Didaktik drive was manufactured - but that's not important). There are two major versions of the system: MDOS 1.0 and MDOS 2.0. The first of them was designed to cooperate with WD2797, the latter one then with i8255. Here I'm coming to the first question you've been sorting out in your discussion - D80 is NOT "more capable" than D40 - the logic in either of them is equivalent - either WD2797/MDOS1 or i8255/MDOS2 combination (in other words, the numbers in D40 and D80 refer to the standard number of tracks, not to a version of the unit). As I take it, you already managed to make the WD2797/MDOS1 combination work. (Can it be downloaded from somewhere? :-) )
Now to the less pleasant part: MDOS1 is buggy! I'll constrain only to the relevant two bugs which are: (1) wrong numbering of disk sides (instead of 0 and 1, MDOS1 numbers them as 1 and 2), and (2) a smaller than correct gap before the first sector on each track (which causes MDOS1-formatted floppies to be unreadable in sector-wise manner in PC, e.g. due to preservation reasons). Programmers at Didaktik didn't discover these bugs because WD2797 is, for some reason, comfortable with the values. The situation became different when the company migrated to i8255 in 1993. The Intel chip didn't swallow the out-of-norm values, and that's how they tracked down most of the bugs when releasing MDOS2 (already sector-wise readable in PC drives). Unluckily for the programmers, they had to make MDOS2 backwards-compatible with the norm non-compliant MDOS1. It's must have been a bit of challenge but they had to "hack" it on the hardware-level (maybe the clue you've been missing when making the i8255/MDOS2 combination work?). The exact way they did it is currently still the open subject in the referred forum, so I'll pass it over here when it's been "revealed" there.

Few more notes:
- There have been some non-functional copies of MDOS ROMs distributed on the Internet (which then eventually caused further problems). I've extracted MDOS1 ROMs content from a real hardware so that their functionality is guaranteed, and zipped them up here (the MDOS2 ROM is currently still not guaranteed [aka, taken over from the available sources on the Internet); but luckily enough, this can change in just a few days - a collector on the forum has just purchased a 1993 Didaktik computer). As you correctly write in your discussion, the MDOS ROMs are just 14k long with the upper 2k mapped to a drive RAM (or DRAM) that served as (1) a sector read/write buffer, and (2) drive current state descriptor (initialized during the red screen).
- MDOS detects its floppies by checking the presence of the string "SDOS" at the address 0xCC in the boot sector. Preceeding this text are two random numbers (that serve as the "statistically unique" identifier of the disk). Coincidentally, the characters can sometimes optically melt down to produce strings like "ZSDOS" or "ISDOS" you've been discussing - but the essential part remains just the "SDOS" part (modify it and MDOS will complain with "Bad device type").
- As for the collision of drive with printer you've been discussing, I'm quite sure I had both of these devices connected to my Didaktik computer back in the the 1990's and they found a way how to live together. Truth is, each printed had to be connected via an additional interface (either "Interface M/P" or "UR4"). Maybe this interface was preventing the devices from being in collision? I don't know.
- I'm still a proud owner of a Didaktik computer with both D80 and D40 drives :-) So if you wanted me to test something on the real hardware, just drop me an email. The bad news is that I'm not so often in my hometown where I have these things, so it may take some while from my side.

Best regards,
Tomas (Czech Rep.)

[Gergely Szasz]

Hi!

have been a bit of challenge but they had to "hack" it on the hardware-level (maybe the clue you've been missing when making the i8255/MDOS2 combination work?).

Hmm.. not likely... CAT, FORMAT, LOAD * works well (see.:[#333]). The hardware "hack" only shorten the index pulse (as i see), so if FORMAT not fail, than it does not seem a problem.

My problem with LIST* is that, i cannot see any further problem with GM82C765B emulation, (standing on the datasheet and the schematics). But, LIST * always say: "Sector not found (Retry = R)", even if drive is empty. MDOS20 waiting for what, to realize: drive is empty?...

As for the collision of drive with printer you've been discussing, I'm quite sure I had both of these devices...

Not the drive collision with the printer. As I see the joystick and the printer use the same i8255 port. (Joystick in Mode 0, printer in Mode 1)

[tomascz]

Hi,

Hmm.. not likely... CAT, FORMAT, LOAD * works well (see.:[#333]). The hardware "hack" only shorten the index pulse (as i see), so if FORMAT not fail, than it does not seem a problem.

Yes, there's no other purpose but to shorten the index pulse. I've forwarded the information, just in case it would matter after all.

But, LIST * always say: "Sector not found (Retry = R)", even if drive is empty. MDOS20 waiting for what, to realize: drive is empty?...

Well, this is definitely a wrong behaviour. Given that a floppy image is, in essence, nothing more than a sequence of sectors, you should virtually never see a sector access-related error like this. Anyway, like I already said, there are known to be some wrong ROMs out there on the Internet, so may I suggest that you first try to sort this out using a guaranteed MDOS2 ROM that I hopefully will be mediating shortly? (The OldComp member has already been contacted and provided with a method on how to obtain it.)

Tomas

[tomascz]

Hi there,

the discussion at OldComp has brought in some new information, so I'm about to share it here. But before that, an apologize for misleading information - as I've been kindly noticed by an OldComp member, the 1993 correct combination is i8272/MDOS2 not i8255/MDOS2 (although i8255 PIO is used there too) - my apologizes for that.
The hardware modification that had to be incorporated in order to make MDOS2 backwards compatible with MDOS1 is as follows: The index signal isn't fed from the drive right into the chip (as would be the usual) but instead is shortened using a single-step circuit 74123 to the width of 1.5 ms (2x 68nF and 39kOhm). (Translated from Slovakian "Signal index z mechaniky nejde priamo do radica (ako obvykle) ale je skrateny monostabilom 74123 na sirku cca 1.5 ms (2x 68nF a 39kOhm)."). The corresponding member has also attached an image showing this modification - see here (let me know should you not manage to display the image).
Wish you good luck in the struggle with MDOS2, hopefully you will beat it soon :-)

Kind regards
Tomas

[tomascz]

Hi,

sorry that it took that long for me to respond but my request for the "guaranteed" ROMs extracted directly from the computer succeeded no earlier than couple of days ago with the third Didaktik user I spoke to. So I've uploaded them here. In this respect, and lucky enough, my request resulted in me managing to collect ROMs of virtually all devices manufactured by Didaktik - but for your purposes, only the 1993 versions are relevant (in folders "DIDAKTIK_KOMPAKT_1993" and "MDOS2_1993"). So when bringing the Llist* command to life under MDOS2, please use these ROMs obtained directly from the machine.
Yet have a question - do I take it correctly that you already managed to fully implement the MDOS1 support? If that's the case, may I please ask if you could include it in the upcoming 1.2 release? It would be definitely very welcome by the Czech-o-Slovakian community, currently reliant only on the obsolete and user-unfriendly (plus here and there also buggy) Real Spectrum emulator. Thanks for a response! :-)

Best regards,
Tomas

[Gergely Szasz]

After a long time period...
I just post a new patch [#333] with working LIST * ...
(Not the ROM caused the problem... ;-)

[Arki55]

I suppose this patch is obsolete, right ? Didaktik 40/80 FDD is already in Fuse. So this should be just closed.

[Gergely Szasz]

Hi,

Yes, looks like obsolate.

[Sergio Baldoví]

Closing as obsolete. Further development on [patches:#347] and [patches:#333].