FDC Development - Bios Calls

Resident (44)

10-01-2022, 00:25

I have been working on disassembling and documenting a disk rom for the purpose of writing a disk driver based on the same controller. The major change is the relocation of the disk controller to the I/O space instead of the Memory Map. The purpose of this is to facilitate one of my own projects where I am creating a docking station for the Casio MX-10. But I also want to do this so others can use my work in their own projects.

The disk rom I have been dissecting is the TDC-600, as it uses the WD37C65 which is compatible with several other controllers such as the GM82C765 and FDC37C65. I have chosen these as they are more modern controllers with built in separators. During documentation of the ROM I’m seeing some calls in the disk rom to the bios that make absolutely no sense to me. Such as a call to $00DD, which is right in the middle of a paddle routine. But the call comes from what I believe is the DSKCHG (disk change) routine.

The subroutine mentioned calls to:
$0193 - Not sure where this
$00A7 - Printer Character Output
$00DD - Paddle Status

These are just some examples of some of the calls that are within the disk rom. And should not be considered to be the only calls I'm concerned with. The purpose of the post is to better understand exactly what they are calling to. Though these specific calls can be found in memory locations $7AE5-7AF9 of the TDC-600 rom.

Now, I could assume that the driver is copying a routine to ram, and then calling to these routines. However, this doesn’t appear to be the case since the floppy interface I’m using works on my MX-10 which only has RAM in Page 3 (16k). I suppose this could be a DOS 1 only routine, that gets mapped someone between $0 and $100. But that doesn't explaine the $193 memory location. And I can not seem to find any documentation on low level MSX DOS 1 calls other than to the BIOS.

Does anyone know what I’m looking at here? This doesn't appear to be a data block, as there are jumps to this subroutine from other areas in the code. And without knowing what these are calling to, I can only speculate what the code is doing.

If anyone is interested in taking a look at the work so far, it can be found here: https://github.com/jdgabbard/TDC-600-Source-Code

By st1mpy

Paladin (947)

10-01-2022, 02:43

Why not start with port based disk rom like Microsol ones?
May be This project is of interest?

By jdgabbard

Resident (44)

10-01-2022, 04:50

st1mpy wrote:

Why not start with port based disk rom like Microsol ones?
May be This project is of interest?

Primarily because the Microsol uses the WD2793, which relatively ancient compared to newer designs. Not to mention less commonly available in comparison to the 37C65. I’m not sure what the compatibilities are between them software wise. It just seems more practical to use a Rom designed for the specific IC as a basis. The largest portion of work will be removing the unneeded code. The TDC-600 does a lot of moving around and writing to different slots based on which area of memory needs to be read from / written to. Most of that can go, since the controller doesn’t have to be mapped to two different pages in the slot map.

By gdx

Enlighted (6429)

10-01-2022, 08:47

Jdgabbard wrote:

The major change is the relocation of the disk controller to the I/O space instead of the Memory Map.

I think there are already interfaces that do it to avoid I/O port conflicts.

Jdgabbard wrote:

During documentation of the ROM I’m seeing some calls in the disk rom to the bios that make absolutely no sense to me. Such as a call to $v, which is right in the middle of a paddle routine. But the call comes from what I believe is the DSKCHG (disk change) routine.

Paddle routine is at $00DE is not? Are you sure that this is called in the slot 0(-0) and not the sub-ROM or ROM mirror for example?

By jdgabbard

Resident (44)

10-01-2022, 16:30

It is calling from slot 0. One section of code makes a call to bdos FORMAT, then a call to bdos CHKNEW, sets the carry flag, and jumps to the code in question. Where it ‘JP C, $0047’, which is WRTVDP. However, if carry is not set it goes on to call $00DD after it passes a few other tests for jumps to other areas of the code. However, the tests appear to skip this code entirely. As there is a jump on NZ followed by a jump on Z right afterwards. Now I’m starting to suspect this is a data segment. But why only 3 bytes? As for the jump to $193, that one appears to be a legitimate jump. Best guess is maybe there is a routine at $193 that was more efficient to call to rather than writing a new routine…

By NYYRIKKI

Enlighted (6091)

10-01-2022, 17:01

You might want to take a look of this fine project from Arjen Zeilemaker as well:
https://sourceforge.net/projects/msxsyssrc/

... it contains sources of different disk ROM versions as well as many drivers from different manufacturer interfaces that have been used in the past... It includes also an empty driver template that can be used with the disk ROM sources.

By jdgabbard

Resident (44)

10-01-2022, 17:56

I have spoken with Arjen, and even suggested some changes to the TDC-600 driver for patching the Spanish language to English. As well as identifying some data blocks which turned out to be the media lookup table. It’s a great project, and I’ve borrowed a little from it. But his driver isn’t fully documented. Though I do generally consider my work to be a minor fork of his own.

By zeilemaker54

Champion (355)

10-01-2022, 22:12

jdgabbard wrote:

Have you already looked at the latest commit: https://sourceforge.net/p/msxsyssrc/git/ci/master/tree/diskdrvs/tdc600/driver.mac

By jdgabbard

Resident (44)

11-01-2022, 03:19

I have not until I read your comment. You've done a lot of work since we last spoke.

This particular area isn't documented ($7AE2-7AFA). However, it looks like this is the area of memory that is the routine for transferring the DSKIO routing into the buffer for execution out of memory (while writing to $4000-$7FFF I would think). Though, I am still not sure what these calls are to, unless it is just data to be copied into memory.

By zeilemaker54

Champion (355)

11-01-2022, 18:25

The area I$7A84 - CHOICE is the DSKIO routine but assembled at address 0 (.PHASE 0) and indeed used to copy in $SECBUF and executed there. This is needed to transfer to and from page 0 and 1, because normally the disk ROM is in page 1 and the FDC in page 0.
The reason why the routine is assembled at address 0 is because it is very easy to do the relocation of the addresses. The relocation table is at I$7A4E
Note also that the routine is normally is a DSKIO write routine. In case of a DSKIO read, the routine is modified by using the modify table at I$7A6A
Note further that the FDC of the TDC600 in accessible in page 0 (very untypical for a MSX FDC) and in page 2. In normal operation the page 0 addresses are being used (and that is why page 0 is switched to the same slot as page1). In case of the $SECBUF routine, the FDC addressing of page 2 is being used.

Hope this helps

By jdgabbard

Resident (44)

13-01-2022, 16:41

Arjen, that confirms what I suspected. And yes, that information is very helpful. And it is unusual in more ways than just one. I’ve noticed where the code is relocated. And I’ve also have seen where the programmer preferred to use the WRSLT call instead of relocating code to write to the FDC.