Fixed BwG Contoller in MESS

[+mizapf]

Just to inform you if you are using some recent MESS release: I fixed an issue with the BwG controller which corrupted double density images on write. This fix will be available with the next release (0.152).

And, by the way, we may have the first complete 99/8 emulation with that release. As it seems I have a complete, consistent ROM set by now.

[ti99iuc]

Ooooohhhhh yeahhhhhh ... thank you for your work Michael.

[Willsy]

Wow! That's seriously cool. I would love to play with the 99/8!

[+mizapf]

One problem remains for the BwG, which is there for a longer time, obviously: When reading single density, the BwG sometimes fails to read the file on the first attempt. The problem is that the BwG always tries double density first (also after a "floppy restore" command) and when it fails, tries to read it as single density. However, the images in MESS deliver data even when accessed in the wrong mode (because the sector dumps do not contain information about density), so the controller falsely assumes that double density (with 18 sectors/track) is OK and fails to find the next sector if it is beyond sector 8 in track 0.

 

---

 

The double density problem was pretty difficult to find out. The controller was unable to write any sector; reading was OK. I found out the solution in many small steps by log analysis:

 

- We want to save a file

- The controller reads the sectors 0, 1, and 2, which works flawlessly.

- The controller tries to write sector 1

- After writing it tries to verify the sector data

- Verify fails. The controller retries several times, then gives up and switches to single density.

- The image is still formatted for 18 sectors/track, but now the controller assumes 9 sectors/track.

- The controller creates a file information block in sector 3. It says the contents are at sector >22

- Now the controller divides the sector number by 9, thus calculates a wrong track, and writes the contents to the wrong location.

- As a result, the file shows up in the directory, but the contents are gone.

 

Why did this happen?

 

- After saving the DSR tries to read the sector again

- The read sector operation is triggered on the WD1773 controller

- The sector is found, the first byte is being assembled. This takes 8*4 microseconds.

- Meanwhile a SBO 2 is executed. This connects the DRQ line with the READY line, and accordingly, the CPU goes into wait state.

- When the byte is complete, the DRQ goes to 1, and the CPU continues.

- The program now heads for the compare loop while the next byte is already being assembled

- Unfortunately, the CPU needs about 40 microseconds to reach the compare loop after the SBO 2.

- This means the first byte is overwritten by the next byte, and verify fails.

 

I had some discussions with Harald Glaab who wrote the DSR. As a matter of fact, there are way too many commands between the SBO 2 and the CB @>5FF6,*R2. Using the cycle table you can calculate that you need more than 118 cycles to reach it, and 32 microseconds are just 96 cycles.

 

I had a closer look at the schematics of the BwG. There I discovered that the address bus lines A13-A15 are combined with the DRQ, which delivered the answer:

 

The wait states are created as soon as the address 5FF7 is read. Why 5FF7? Because the TI-99/4A always reads two bytes, the second byte first. Accordingly, the program proceeds until the CB line is reached, and then the wait states are created, so it need not hurry to reach the compare loop in time, in particular because the first byte takes longer to be read (have to find the sector first etc.).

 

The implementation in MESS did not contain any check for the address bus, but since the emulation was not cycle-precise at that time, the controller worked as expected. Now, after I rewrote the core to operate on cycle precision, the controller indeed failed.

 

This had another consequence: I had to remove the BwG from the Geneve emulation because the BwG should not be able to work with the Geneve. Remember it waits for address 5FF7 to be read - but the Geneve only reads single bytes, not words, so it will never trigger the wait state creation and will receive lots of wrong values from the WD1773 because of premature access.

[+Ksarul]

Actually, I use a BwG controller with my Geneve--it works fine using the standard Geneve DSR. . .

[+mizapf]

Well, then we're back at the question which a former collegue of me laughed about when I was asking "why does it work"? Other people seem to be satisfied with the fact, not me.

 

I think I remember some of those discussions (it should not be wrong to say some of the SNUG people are not really friends of Myarc) that there were issues with the Geneve and the BwG. Either this was solved in a later hardware layout, or with some minor mod. One way would be not to check for access to 5FF7 but 5FF6 (cut the A15 line); this should be sufficient for both TI and Geneve.

 

I'm currently fixing the ti_fdc (standard TI controller) which has multiple problems. One interesting thing that I found is that the TI controller has bad problems reading a file information block with a file status flag 90 (meaning DIS/VAR, modified). It only accepts 80 (DIS/VAR, unmodified). This modified flag was added later, and it seems to bother the old controller.