#333 Didaktrik 80 emulation V2 (MDOS20, 82C765B)

[Gergely Szasz]

Here is a "WIP" patch to emulate Didaktik 40/80 with 82C765B FDC (and MDOS20).

• We could enable the "old" emulation with a command line switch: --didaktik80-v1
• The ROM image for V1 is didaktik80-1.rom
• CAT, FORMAT, "LOAD *" works well
• "LIST *" says: "Sector not found (Retry = R)
• in uPD765 emulation: quite heavy changes around paralell seek/recalibrate for the more realistic operation (even imho nobody uses this "really must have" feature, wich comlicates things totally... ;-)
• emulation of G82C765B (which core is a uPD765A ;) and its OPER register...
• ... So, the +3 disk layer still works like as before (at least i hope it;)

[Gergely Szasz]

Updated for current HEAD.

[Gergely Szasz]

After a long period of time...
Here is a new update: now LIST * works...

So... after a lot of experimetations ...
The main problem was that: the GM82C765B single chip floppy controllers has no (disk) READY (input) signal (... by the way, this is a very clever decision ;). So, FDC cannot know anything about a disk loaded or not. FDC assumes: disk always READY (loaded and spinning). READ ID or READ DATA commands try to read an ID or try seek to the given ID within two disk revolution (two index pulse detected). The problems with this:

1. there is no any information about how FDC "detects" index pulses:
   a., just read the /IDX input and if it is 0 -> IDX pulse
   b., or wait a 1->0 transition (or 0->1)
2. we don't know, how FDC react if not get IDX pulse for a long time...

So, we are not sure the emulation of this situation.

We assume G82C765B detect IDX at the edge of the IDX pulse and there is no any timeout, so if disk not loaded, it waits forever...
It seems that Didaktik80's MDOS2.0 uses some timeout to detect empty disk drives.
After 2 seconds it makes a soft reset and think the drive is empty...

The patch:

• peripherals/disk/upd_fdc.h:
  • adds G82C765B FDC type
  • rearranges FDC command enums to better handle of parallel seeks
  • adds code for "Operations Register" emulation
• peripherals/disk/upd_fdc.c:
  • adds code to emulate G82C765B (status registers NOT-REAY, WRITE-PROTECT bits...)
  • adds/changes code to emulate uPD765 family "parallel seek" behaviour
  • adds code to emulate "Operations Register" and PC-AT mode drive select, motoron features
• peripherals/disk/fdd.[hc]:
  • adds code to emulate PCAT floppy drives (hasn't got READY signal...)
  • adds code to handle disks different WP "strategy" (floppies (8") and hard cased micro floppies (3" and 3.5") use "open WP hole" for WP but 5.25" minifloppies use "sticked WP notch" for WP the disk)...
  • reset disk->bpt and "bit index" when a disk unloaded, because FDC code relay on it...
• peripherals/disk/didaktik.c:
  • modifies code to handle V1 (MDOS1.0 with WD... FDC) and V2 (MDOS2.0 with GM82... FDC) floppy systems

[tomascz]

Thanks that you didn't give up - excellent work! :-)

[Sergio Baldoví]

Good work. I've tested the snapshot button. I works quite well but sometimes I get an Out of Memory error when loading a snapshot with a game. That seems to happen after reseting the machine. The snapshot loads properly after a cold start. Maybe it is a limitation of the interface. See video:

https://www.dropbox.com/s/b46cfzi7i7ci767/didaktik-snapshot.ogv?dl=1

Note that disk drive icon remains ON after an Out of Memory error. Is that the expected behavior?

I have also given a closer look to the snapshot format. The routine that saves the snapshot is SNAPR, as stated by Rutiny ROM D40 [1], page 30. The snapshot have 128 bytes from the RAM of Didaktik (16256-16383) and 48K with the RAM of spectrum, 16512 bytes in total.

The steps for testing were:

1. Pause machine
2. Save szx snapshot
3. Fire didaktik snap
4. Unpause machine
5. Save disk image in d80 fomat
6. Run MD3 Tool [2], import .d80 image and export the snapshot file as a binary

The 128 bytes header looks like:

$ hexdump -C -n 128 -v SNAPSHOT00
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 44 02 89 24 02 00  |..........D..$..|
00000030  3e 27 05 00 44 02 89 24  02 01 3e 27 05 01 9c 23  |>'..D..$..>'...#|
00000040  02 03 00 02 00 0a 00 ff  3b 27 05 01 91 23 06 03  |........;'...#..|
00000050  00 61 80 3f 7d 01 b9 22  80 3f 00 61 91 00 05 01  |.a.?}..".?.a....|
00000060  b2 20 80 0e 3a 1a 47 03  28 3f 3a 5c d4 03 38 00  |. ..:.G.(?:\..8.|
00000070  b8 00 20 17 44 00 a8 10  b9 5c 21 17 5c 00 44 ff  |.. .D....\!.\.D.|

and as far as I can see:

0x69 I
0x6A IY
0x6C IX
0x6E HL'
0x70 DE'
0x72 BC'
0x74 AF'
0x76 HL
0x78 DE
0x7A BC
0x7C AF
0x7E SP - 2 (PC is stored in stack)

[1] http://ci5.speccy.cz/files/rutiny%20D40%20by%20George%20K.pdf
[2] http://velesoft.speccy.cz/zx/divide/systems/mdos3/soft/mdos3tool_0.6beta.zip

[Gergely Szasz]

Note that disk drive icon remains ON after an Out of Memory error. Is that the expected behavior?

Yes.. Didaktik does not turn off FDD's motor after (this) Out of Memory error.

That seems to happen after reseting the machine. The snapshot loads properly after a cold start. Maybe it is a limitation of the interface.

This is very strange... Hard reset should be the same as a cold start..(?) ...hmm?

[Sergio Baldoví]

This is very strange... Hard reset should be the same as a cold start..(?) ...hmm?

The manual states that a hard reset is equivalent to turning the Spectrum's power off, and then turning it back on. I think that you are considering a floppy disk drive with an independent power source and remains unaltered to a hard reset.

As there is no option to power off a floppy disk drive, I like the idea of resetting on hard reset. That would not imply a disk ejection as it is a mechanical action.
But that's not a strong opinion.

Anyway, I think a power off would mask the real problem here. I've found another test case, if you format a disk without a floppy in the drive, Didaktik prompts:

Drive is not ready (Retry = R)

If you insert a disk and press R, the process resumes but near track 08 the traces show a MissingAM flag. After a long (long) wait, the process ends with a Sector not found message.

I suspect the interface is failing to recognise the disk structure in both cases.

[Gergely Szasz]

I suspect the interface is failing to recognise the disk structure in both cases.

Note: Than may related to [bugs:#325]

[Gergely Szasz]

I made some test...
When "Drive is not ready (Retry = R)" message is arrives: Didaktik switch off the FDD motor. After we insert a new disk and press "R", Didaktik start up FDD motor and immediately(?) start the formatting.
So after ~6-7 track, the FDD is get ready, and "real" formatting is just begin...
- maybe this is a bug in Didaktik ROM(?)
- the formatting "code" is too unreal (there is no any timing - too fast), so maybe this is causing the trouble

[Gergely Szasz]

Thomas , could you check this situation on real hardware?

[tomascz]

Hi, I'd be glad to help. Btw, I will forward your discussion to more acquainted people here in the Czech Rep., and eventually mediate what they say on it. Yet as for the testing I have a Didaktik with MDOS1 (the rarer one) - I will ask a collector fellow if he can repeat the tests with MDOS2 hardware. We will do the following tests:
(1) attempt to run SNAPSHOT00 on a real hardware after it's been hard/soft reset
(2) create our own snapshot, hard/soft reset the machine and attempt to run it
(3) command the hardware to format a disk without a disk being inserted, then insert it and command Retry.
Hope this helps somehow :-)
PS: I just experimented with the MDOS tool you work with. I've also created one, that seems to be more straightforward, but lacks at the moment the hexa editor for sectors (only the boot sector features one). Maybe you may want to give it a try?

[tomascz]

Hi Gergely,
so here I've taken a video of me conducting the tests on a real hardware with MDOS1 - my colleague will provide results of his tests during the weekend. Yet a note on your configuration - I don't think if it may have some influention but you probably use a standard 48k Spectrum ROM in conjuction with D80 ROM. To be more sure during testing, I'd suggest that you use the 48k Didaktik ROM at place of the Spectrum one.
Will get in touch once the other results are ready.
Best regards,
Tomas

[Gergely Szasz]

Hi,
Nice video, i loved it really...
In the meantime I realized that: this test is not so trivial task. Because we need an unformatted, totally blank disk. With formatted or new preformatted disk, this promlem does not occur, or exactly not the same way.
If we use a "used" floppy,
- the format is finished without error.
- LIST * show the new disk label
- but, CAT may show previouse calaogue and some garbage
because the first couple tracks does not formatted.

(attached a screenshot - testing with games.d40 http://hracka.org/~mike/d40/games.zip)

Whith MDOS1 (WD2797) there is no problem with formatting.

BTW: We have an another format bug [bugs/#171].. maybe it is a upd765 emulation problem...

[tomascz]

Hi,
thank you for the comment on the video :-)
The tool, that I've posted link to, actually should be able to "unformat" the disk. If you select New -> Image, then choose "MDOS" in conjuction with "Physical floppy drive A:", and set the Format Cylinders dialogue this way (that is, there is only one long sector on each track that overwrites itself), you should receive a disk that is essentially blank, aka "unformatted" (a recommendation by Simon Owen, the author of fdrawcmd, with whom I discussed this possibility some time ago). EDIT: I haven't tested this actually - maybe the app will crash once not having found the expected boot sector, but the tracks will be unformatted anyway.
Well, the behaviour of MDOS2 formatting as you described it, is strange at best. If the tracks are not formatted and only the disk label is changed (shown using LIST * ), then I'd expect that also FAT entries are all set to "empty", making each of the stored program unreachable (nothing is loaded in). Btw, can it matter that you format a 40x10 image (40 cylinders, 10 sectors per each track) to 40x9 capacity? That could explain the "garbage" in the listing - the competitive Real Spectrum emulator gets confused a very similar way.
Hope this helps somehow. Will say my colleague to "unformat" a disk prior to conducting the tests.
Best regards,
Tomas
PS: Found in the tool a bug - if an MDOS file is deleted, the dir sector is not marked as "dirty". Have fixed it already but will be releasing a new version no earlier than the next weekend. Let me know if you needed to delete files from a floppy disk earlier and I will build you a "debug special" version.

[Gergely Szasz]

Hi,
I made a quick test: force "filler byte" of formatting to 0xe1 to see what really written after formatting by Didaktik (low level format).
1. h0t0s1 (first sector) overwritten with some information and label, and filled with 0x00 from 0x00d0
2. h0t0s2 first 21 byte overwriten by 0xdd, all other filled with 0x00 except at 0x00c3 to 0x00c6: 0xff 0xdd 0xff
3. h0t0s3 filled with 0x00
4. h0t0s4 filled with 0x00 until 0x0038, and the rest filled with 0xdd
5. h0t0s5 filled with 0xdd
6. h0t0s6 filled with 0xdd
No any other data overwritten. So, because the first 7 track not formatted: h0t0s7 and h0t0s9 looks like remains of previouse catalogue...

[tomascz]

Hi,
well I don't understand much your numbering (h0t0s1, h0t0s2...) and how it makes up 7 tracks. But anyway, if only the label and FAT are modified (and the rest remains the same even if you modified it manually before), then the tracks are really not formatted and only overwritten with information that "this is a completely blank disk" as long as FAT is concerned (40x9 geometry with two bad sectors). If you tried to load a picture from such disk, your attempt would either fail or you'd load some nonsense.
What puzzles me is why the emulation manages to address correct tracks when setting their contens (boot, fat) but fails to find them during formatting. I don't think the creators of MDOS2 would leave such mistake in the driver... Hope you find the bug soon :-) Btw, a great piece of work so far already! :-)
Kind regards,
Tomas

[Gergely Szasz]

h0t0s1 - head 0 (side 1/side A); track 0; sector 1 -- the very first sector of the disk (the "IBM format" sector numbering starting with 1 not 0)
The formatting process may has two main part:
1. low level format - Didaktik instructs upd765 to format all tracks (and all sectors) one by one (from 0 to 39 or to 79) in both side - this create all the sectors filled by the given byte (now Didaktik use 0xe5 as i see)
2. Didaktik write some sector (6 sector from 1 to 6) to create the initial file system - all the sector laid on side 1 (or side A, head 0), in track 0.

So our problems that:
When we (hmm Didaktik :) start the formatting process, there is no disk in drive.
Didaktik notices this and stops the disk (motor off) and informs user: "Drive is not ready (Retry=R)".
When we insert a totally blank disk (there is no any track or sector on it!), and press "r": Didaktik start up the drive (motor on) and immediately begin the formatting.
Because the used FDC (GM82C765B) always think "drive is ready" - at the beginning of the process maybe some data cannot written properly to disk, (the disk not spinning at the desired speed -- 300rpm).
The emulation not too fathfully for the format process (we format "very high speed"), so I cannot know, how it is works with the real hardware. How many track not formatted in this way? one?, two? seven? Or even Didaktik waiting for enough time to disk spinning on?
So, in the emulation Didaktik miss the first 7 track (exactly 6 and most of the 7th), and the "real" write process start after this.
If we have formatted tracks before ("preformatted" or "used" disk) the current formatting, then the not formatted tracks (1-7) does not lose their data (in the emulation), and after the "faulty" formatting process, Didaktik can read it.
Maybe on the real hardware the disk drive overwrites these tracks with garbage... (I do not know), or maybe does as we do in the emulation (does not enable erase/write current until disk spinning at the desired speed)...

BTW the documentations of this chips are not so precise, couple of things not specified exactly, so maybe the emulated GM82C765B behaves differently in reality...

IMHO the best if we could test it with real hardware.
And many thanks for your (and others) help.

[Fredrick Meunier]

Hi all,
I'm confused by the state of the various Didaktik emulation patches - could someone please summarise the current state of the art and what patches are needed to get there? :)

Let's at least get them committed to a feature branch so they are easier to understand/test as a whole and prepare to merge to trunk.

Fred