#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...

[Stuart Brady]

I'd like to apply diff.libspectrum_d40_01.patch but shouldn't we refer to "Didaktik 80" as the more capable of the two interfaces?

Surely a Didaktik 40 disk is still a valid Didaktik 80 disk, but a Didaktik 80 disk is not necessarily readable in a Didaktik 40. Would it therefore be okay to name these LIBSPECTRUM_ID_DISK_D80 and LIBSPECTRUM_CLASS_DISK_DIDAKTIK80?

[Gergely Szasz]

Uhum... i quite hesitated: what is the 'perfect' name?
Only just DIDAKTIK? or DIDAKTIK 40? or DIDAKTIK 80?

The spectrum clone's name was "Didaktik Gamma" and later build "Didaktik M" and "Didaktik Kompakt" with builtin Didaktik 80, so we may say Didaktik Disk Interface (because 40 and 80 just the attached disk drive).. hmm?

[Gergely Szasz]

Hmm.. after read the sector appeared in "shadow" RAM from 512...

[Gergely Szasz]

Hmm.. ;) no problem, with WD2797 (instead of WD1770) works well.. ;-)

[Stuart Brady]

Maybe we can call it the "Didaktik interface" if the context is clear, then? So, LIBSPECTRUM_ID_DISK_DIDAKTIK and LIBSPECTRUM_CLASS_DISK_DIDAKTIK?

I'm not sure if separate D40 and D80 disk IDs would be going over the top. There are different file extensions and in principle, we could do smarter things with the IDs, i.e. warn about creating 40-track ".d80" files and warn about creating 80-track ".d40" files. We might also want to have filters on file types within file open/save dialog boxes, and I'm not sure how this would relate to the disk IDs.

[Stuart Brady]

didaktik40_fdc = wd_fdc_alloc_fdc( WD1770, 0, WD_FLAG_DTRQ );

Yes, that might do it. :-D

[Gergely Szasz]

Here is a new patch, still with the "old" names.

BTW: do we need to emulate the i8255 PIO? (IMHO not...)

When I test with this disk, in the "main" program say "C Nonsense in BASIC 60:1". BTW: the programs can loaded one by one... in the image file i see ZSDOS (somewhere in the first sector), but in Omikron's test disk ISDOS..??? Maybe for MDOS 2.0?..

BTW: Omikron's test disk works well of course.

[Stuart Brady]

I don't understand why it isn't essential. What does the D80 use the i8255 for if it isn't vital to disk access? Do I assume this is yet another option for feeding data to the device besides DMA and direct access to the WD2797's data register?

It's difficult to say without real hardware to test against. X128 (for DOS) and RealSpectrum emulate the D80 so you could perhaps compare with that. XZX-Pro also emulates it but has a TODO entry "Emulate i8255 parallel interface chip" marked as "nice to have" rather than "should" or "must".

If you're reasonably confident any failures are expected (due to using the old MDOS with WD2797 instead of the 765 FDC) then I think we can commit this.

[Gergely Szasz]

Here is patch with SNAPSHOT button emulation.

The i8255 PPI (sorry Intel use PPI instead of PIO) just for joystick, printer, gadgets... So, there is no any connection between i8255 and WD2797.
BTW: what we can do with the output, or the input of the chip, just save a file???

Omikron said:

The system works without it too and it doesn't need to be emulated.
It is possible to mask its chipselect by some OUTs, see the schematics.

....

If you're reasonably confident any failures are expected (due to using the old MDOS with WD2797 instead of the 765 FDC) then I think we can commit this.

I would be pleased if Omikron has a look at it...

Questions:

• Snapshot: SNAPSHOT button create a "SNAPSHOT00" file on the disk, but when I load it, just some garbage and reset
• 128K compatibility:

  Yes, original D40 has the collisions with 128K ports. There was the
  modification, that adds the highest 2 address bits to the main address
  decoder. Then it works with 128K too.

hmm. I check with 8bit "highest" and 16 "highest" but simple did not work.

• and of course the question about "C Nonsense in BASIC 60:1"

[Stuart Brady]

I've committed the libspectrum part in [r5235], with some changes to naming and numbering.

I'd like to change the paging so that we map the full 16K ROM in first and immediately overwrite it with the 2K RAM. This might seem odd, but:

• It would better reflect the code for other peripherals.
• It should play better (faster) with any future subpage infrastructure.
• It will avoid the open-coding, so is more readable.

I expect the overhead of 2 KB of unusable space at the end of the ROM image, both on disk and in memory is not much of a problem.

[Stuart Brady]

The joystick, we should get working. The printer, would do the same as our other peripherals, i.e. write to a file. We should look at improving our printer emulation but not as part of this patch, of course. The gadgets, I have no idea about, as I do not know what they are.

If we don't emulate the devices, we should still at correctly emulate the behaviour you would see with them disconnected, i.e. emulate the i8255 with no joystick and no printer attached. If it's easy to emulate an unused i8255 but hard to emulate the connection to the joystick and printer, then we could leave that for another patch, but I would prefer if we did it now.

Yes, we should get Omikron to look at this, although he might prefer if we fully emulate it rather than us asking in stages, rather than having us asking him to do regression testing. I should commit the side comparison change, first.

We do need to find out about the snapshot button. Even if the snapshot feature itself is not of great importance, this suggests wider problems may be lurking.

Maybe the 128K compatibility mod only works for the version that has MDOS 2 and the µPD765 clone?

The "C Nonsense in BASIC 60:1" thing is worrying. Perhaps it's just the disk and it happens with real hardware. It would be worth checking.

[Gergely Szasz]

If we don't emulate the devices, we should still at correctly emulate the behaviour you would see with them disconnected, i.e. emulate the i8255 with no joystick and no printer attached.

As i think there is no joy or printer connector on the D40/80 only just an edge connetor with all (or almost all) I/O pin of i8255 see KON2 on schematic

So, users have to build their own cabling, and (as i think) only special programs can use the i8255 as a joystick or printer port, because the i8255 programming and special I/O ports. (hmm... Omikron?)

If it's easy to emulate an unused i8255 but hard to emulate the connection to the joystick and printer, then we could leave that for another patch, but I would prefer if we did it now.

Ok, no problem, i think, i can manage it quite easily...

[Arki55]

About that 128K compatibility: I debugged that. It was ot only about making the ports not colliding. There is also some not properly explained port write back for 128 page flipping, which is hardcoded to the worst port mask for all 128K versions and that needed a modification as well. I will post the fix soon. Maybe some switch in options.. Making the write back more universal is a bit harder to do as it is in a function that does not have all port info available.

[Stuart Brady]

As a side note, we should reverse engineer the snapshot format and produce a patch for libspectrum for reading it, if possible.

We should also try to add write support for all of the formats that are currently read-only, but we really need a better way of handling the information loss warnings before we do that.

We could also do with a better ability to manipulate, convert, extract, etc. disk/tape images of all of the different Spectrum-related filesystems, and also a of fuse (Filesystem in USErspace) filesystems. These would be side-projects of Fuse, and some of them could be a part of fuse-utils.

I already made a start on the G+DOS filesystem. We should do the same for Opus, TR-DOS, Didaktik, Microdrive. Of course, this is a long project... so hopefully there is some way to load a non-corrupt SNAPSHOT00 into Spectrum RAM and save it straight out to a tape image, if we cannot extract from Didaktik disks just yet.

[Arki55]

Loading and saving of .S files outside of .d40 disk image has been implemented by me
https://sourceforge.net/p/fuse-emulator/feature-requests/146/

I also agree that the disclaimer about missing data is not correctly done. There should be a central registrations of peripherals, then when saving data by some snapshot format, it should explicitly state what data was saved, and then outside of the specific file format it should check what HW was not used and echo the warning.

[Gergely Szasz]

Here is a patch for the current libspectrum and fuse SVN.

I try to rename every "pulblic" thing to DIDAKTIK80, except 'UI_MENU_ITEM_MEDIA_DISK_DIDAKTIK...' enums.

[Stuart Brady]

Thanks, Gergely. Seems good so far.

If users have to build their own cabling, then don't worry about getting joystick or printer emulation working. We just need to emulate the i8255 well enough to keep software happy. If MDOS doesn't even use the i8255, so there's no danger of software locking up / crashing if we don't emulate it, then IMO it would be okay not to implement it for now, especially as this does not seem to have been a problem for XZX-Pro.

The commented out //#include "peripherals/ide/didaktik.h" in utils.c is mysterious to me. Surely we need to include "peripherals/disk/didaktik.h"?

The Didaktik ROM settings should go between +D and DISCiPLE. I chose to ignore "+" when we sort lists including "+D", so "+D" goes between "Beta 128" and "Didaktik", and then "DISCiPLE" goes next. We should adjust the ROM group numbering so that it is sequential, within menu_data.dat, which means we must update menu.c accordingly. Numbering should also be sequential for individual ROMs, so we would need to update settings.pl accordingly.

Regarding end_opcode and end_snap, would you mind reworking this slightly? I feel it would be better to increment PC (and R) after overriding the opcode, so that you can test the address that will actually be overwritten (0x0066) rather than the address afterwards. You then won't need the extra label "end_snap" label (and I feel we would otherwise need a more descriptive name for this, anyway).

BTW, I think the names "run_opcode" and "end_opcode" were not great to start with. We should name labels for what comes after them, not what has preceded, and I don't know whether that was the intent or not. "fetch_opcode" would be a better name than "run_opcode", and "exec_opcode" better than "end_opcode". I will deal with this separately, though.

[Gergely Szasz]

Here is:

• read i8255 ports return 0xff
• //#include "peripherals/ide/didaktik.h" -> removed
• Didaktik menus went between +D and DISCiPLE
• SNAP in z80_ops: fixed
• hotkeys more consistent now
• open_didaktik80() in disk.c renamed to open_d40_d80()
• add write_d40_d80() in disk.c

• head compare done by 0 == 0; 1 == !0

• open_d40_d80() not tweaked for "side 3" now

p.s. SNAPshot is working... just we need a disk with sufficient space to save the snapshot ;-).

[Gergely Szasz]

Just adjust the i8255 ports' bitmask according to http://cs.wikipedia.org/wiki/Didaktik_40

[Stuart Brady]

Okay, committed in [r5248]. I made it 48K only. I also removed the fallback to a 14K ROM image, as we would map 16K out of 14K (!) temporarily, and we would still display an error message from the first failure.

Leaving this open as I'm expecting there will be further changes here, but this seems to be a great start.

[Gergely Szasz]

This patch fix the i8255 port mask/value.

The returned 0xff from i8255 not changed, because the "Nonsense in BASIC" is a bug of the program, not the emulation. If joy fire pressed when cursor on a "bad" area (between program titles), then program abort with the message before.

[ub880d]

Hi,

just for more completeness, I analyzed this "issue" more as I thought it is a bug in the "run" program. But it isn't so.

The only problem in "run" is that it reads kempston port and use the value without any check, so when there is no kempston joy interface attached the value read from port is "random" with the high probability the 'fire' bit set to 1. This means that as soon as program runs, it realize fire is pressed so it will execute program on which is arrow cursor initialy, which is the first program in the list (128f).

This "run" loads program by filling a$ basic variable (it is filled in assembly code) with the name of program to execute, then it sets system variable for next line to 60 and next command number to 1 and then jumps to zx rom to continue in execution of basic program. And there is line "60 LOAD *a$".

The problem why 'Nonsence in basic' is raised is, that first program (128f.p) doesn't have autorun line set, so basic is maybe confused by "bad content in memory" when it tries to continue in execution after program is loaded.

This issue can be repeated also without d40/80 attached on the plain zx with tape (tested in emulator). Here are steps:

1) make program:
10 PRINT "abraka dabra"

2) save this program without autostart:
SAVE "test"

3) wipe program and type new one:
NEW
10 LOAD ""

4) rewind tape to previously saved program and type:
RUN

After program is loaded 'C Nonsence in BASIC' error is printed.

To fix this issue on that diskette you can overwrite 128f by one with autostart:
LOAD "128f"
SAVE "128f" LINE 10

then it will be loaded and executed properly, without 'Nonsence in BASIC' error.

[Stuart Brady]

Thanks. Committed in [r5261].

UB880D, do you know what IN from port 31 (0x1f) returns on real hardware when no Kempston joystick (or adaptor if one is needed) is attached to the D80?

Maybe "Nonsense in BASIC" does not occur on real hardware because 0xff would not be returned?

[ub880d]

I don't have D40/80, but I have interface with 8255 on the same ports (schematic is here: http://cygnus.speccy.cz/obrazky/mhb8255/schema-ur4.png ). difference is, that in d40/80 there are no pulldowns on port 31. I got nearly every second read value 0, nearly every other read it was 255 and sometimes different value to 0/255 (I tested it in basic, on port 63 which is not pulldowned in UR4).. so i think you cannot guarantie some fixed value on the port 31 when there is no joystick connected. didaktik skalica (company which constructed d40/80) made also joystick adapters for d40/80 which had pulldowns included.

to 8255 in d40/d80.. there are also ports to disable/enable 8255 in d40. i think 8255 in d40/80 is disabled on poweron and it is enabled by d40 rom and later it can be enabled or disabled by user. you can look to the schematic http://zxm.speccy.cz/dok/sch/d40schm.png . here is also commented disassembly of d40 rom: http://zxm.speccy.cz/dok/lit/Komentovany_vypis_ROM_D40-Kvaksoft.pdf (unfortunately, it is in czech only), there is routine at 0x227A which initialy setups 8255, but this routine is missing in some version of mdos (in that commented disassembly, there are those two different situations with and also without routine to setup 8255).

[Stuart Brady]

Thanks! I suppose there's no clear winner between 0 and 255, although it would be nice to have results from an actual D80, if you think it could make a difference. I don't want to choose a value just to make one particular BASIC program happy, though, if it means our emulation is less accurate.

Looking at the datasheet for the i8255, the “8255A BASIC OPERATION” table on page two lists a read from the control port as an “Illegal Condition”. As Gergely might say, does this mean Intel are sending us to jail? I am wondering if it is best to return 0 or 255 here. Perhaps if we changed this, the “Nonsense in BASIC” message would go away? Or perhaps not?

We can easily emulate the i8255 being disconnected on power up. I assume this applies to all four I/O ports (A, B, C and control)? If so, I can do this if nobody beats me to it.