Subject: PC99 format

From: "Michael Zapf" <[email-masked]>
Date: Tue, 01 Dec 2009 15:42:31 -0000

Paolo B., are you here?

I was lucky to find the format specification of PC99 disks on WHTech just before my head got covered with scratches. I tried to understand the WD17xx operation, especially with the read/write track functions, and I thought all the time that PC99 format disks are track dumps.

Well, almost, as it seems. There are some points that are significantly different. I'd now be interested in a *real* track dump, fresh from the source.

Does anybody have a tool to dump a track from a real disk on the TI? This should not be too complicated, but it depends on the controller, of course.

Michael
(rumors that MESS may be supporting PC99 format in some near future are pre-mature, but I currently feel unable to deny that)

---

From: fdos <[email-masked]>
Date: Tue, 01 Dec 2009 09:45:17 -0700

Michael,

Once upon a time when Raphael Nabet first released MESS TI and Geneve 
emulation both V9T9 and PC99 disk image formats were supported.  At some 
point he decided to just support the V9T9 disk image formats and the 
MESS hard disk image format .HD that later changed to CHDMAN .CHD image 
formats.

Is it your intention to support both disk image formats even though the 
PC99 format only goes up to DSDD 40 track (1440 sectors)?  Me, myself 
and I (hoping other MESS users would add their voices, one way or the 
other) would much rather see a DSDD 40 track V9T9 image of 1600 sectors 
supported, so I could mount V9T9 disk images from my CF7A+ Sidecar 
system in the TI or Geneve MESS emulators.  Thus allowing me to copy 
files from hard disk images to CF7A+ disk images and vise versa, and to 
do all application development in the MESS TI emulator specific to the 
CF7A+ system.

I make this request even though I will be putting PC99 back on my 
TI/Geneve Win98SE peripheral in the near future.  If there was a way for 
me to change the CF7A+ system to 1440 sectors I would do that instead as 
all my installed HRD systems are partitioned into disk volumes of 1440 
sectors even though disk volumes of 1600 sectors are supported.  The 
reason I did this was to allow volatile ramdisk volumes to be backed up 
to 360K (DSDD 40 track) floppy diskettes instead of having to use 720K 
(DSDD 80 track) diskettes for this purpose.

Bill S

Michael Zapf wrote:
>  
> 
> Paolo B., are you here?
> 
> I was lucky to find the format specification of PC99 disks on WHTech 
> just before my head got covered with scratches. I tried to understand 
> the WD17xx operation, especially with the read/write track functions, 
> and I thought all the time that PC99 format disks are track dumps.
> 
> Well, almost, as it seems. There are some points that are significantly 
> different. I'd now be interested in a *real* track dump, fresh from the 
> source.
> 
> Does anybody have a tool to dump a track from a real disk on the TI? 
> This should not be too complicated, but it depends on the controller, of 
> course.
> 
> Michael
> (rumors that MESS may be supporting PC99 format in some near future are 
> pre-mature, but I currently feel unable to deny that)
> 
>

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Tue, 1 Dec 2009 19:14:29 +0100

A real dump of a TI disk can be obtained with Advanced Diagnostics (Miller 
Graphics). I'm afraid that since I don't have a working TI system, I can't 
perform one for you.

AFAIK, PC99 format is exactly equal to a real WD17xx track dump (Type III 
command, >E0), except for the following:
- CRC before Data - 2 bytes (
- CRC after  Data - 2 bytes

In PC99 these two fields have always the same value (>F7F7), whereas in a 
real floppy disk the value would vary, reflecting the real CRC value 
calculated on the data field (256 bytes of data).

Please also note that while formatting a real TI disk with a WD17xx you 
have to write just one byte (>F7) to trigger the WD17xx CRC internal 
calculation and you get two bytes of CRC written to disk.

Also, the WD177X-00 Floppy Disk Formatter/Controller doc (24 pages) has a 
typo at page 18, when it describes the 256 bytes/sector layout.
Reported: ....
          256 DATA
          1   F7 (Data Addressm Mark)

Should be:....
          256 DATA
          1   F7 (2 CRC's written)

I still have the source code of my JumpBoot disk creator. From there I can 
extract all what's needed to format at a very low level a TI disk with a 
Myarc Floppy Disk Controller. My software uses the Myarc FDC hardware to 
format the disk in a special way.

Michael, I could write for hours about this topic. It has always 
fascinated me a great deal. Just ask me what you need. Maybe I know the 
answer :-)

Paolo

P.S.
The PC99 disk format is reported below. It's an excerpt from TI99-PC 
Manual.

*****************************
##-40.02.02
 ****           SINGLE DENSITY PC99 DISK FORMAT         ****
                =========================================
  9  sectors per track (0-8)
 40  tracks (0-39)
  2  sides (0-1)
720  total sectors
180  KBytes

Format disk layout
PC 99 Double Side/Single Density format layout is very similar to
the standard pattern you would find on a normal diskette, formatted
with a WD 1770-1772 chip in FM mode (Single Density). There are
only minor differences, namely:

1) Start of track gap is shorter than normal: 16 bytes instead of
  the normal 40 bytes of 00.

2) CRC is always F7,F7. On a normal diskette you would write just 1
   F7 byte and that would create 2 CRC bytes. The value of these
   CRC bytes would depend on what you had written previously. Not
   so on a PC99 disk! You have to write 2 F7 bytes and, of course,
   then you will find your 2 F7 bytes.'

3) The After Data Gap is longer than normal: 45 FF bytes instead of
   10.'

4) End of track gap is shorter than normal, 231 FF bytes instead of
   369.'

'Start of track                    =  16  00    post index gap
+-------------------------------------------------------------
'             |  Pre_ID gap        =   6  00
'             |  ID                =   1  FE    ID Address Mark
'   Each      |  Track #           =   1  ..    Track #  (00-39)
'   sector    |  Side #            =   1  ..    Side #   (00 or 01)
'   (repeat   |  Sector #          =   1  ..    Sector # (0-8)
'   for 9     |  Sector length     =   1  01    256 bytes/sector
'   times)    |  CRC before Data   =   2  F7    always F7
'             |  Gap 1 before Data =  11  FF
'             |  Gap 2 before Data =   6  00
'             |  Data Address Mark =   1  FB    Data Address Mark
'             |  Data field        = 256  ..    your real data, or
'             |                                 E5 if a blank disk!
'             |  CRC after Data    =    2 F7    always F7
'             |  After Data Gap    =   45 FF
'             +-----------------------------------------------------
'
'End of track                      = 231    FF
'
Used space
==========
        Sector length   = 334 bytes
        334 x 9 sectors = 3006 bytes + 16 (start of track) + 231
                          (end of track) = 3253 bytes
        3253 x 40 tracks x 2 sides = 260,240 bytes/disk.

As a matter of fact, a PC99 DS/DD disk image is 260,240 bytes.
____________________________________________________________________
Note: (Not relevant for formatting, but important for copying
       purposes).

Following the TI-99/4A convention, the logical sectors will first
have to completely fill the lower Side (Side 0). Further logical
sectors have to go first to the last track (the inner track) of
Side 1 (the upper side).
The next sectors will go on the tracks in backward order, from the
inner tracks to the outer tracks of side 1. The highest sectors
will go to track zero of Side 1

The interleave is 4:1 (advance 4 sectors ahead on the track to find
the next sector) on both disk sides, while you are on the same
track. At track shift, the starting sector is different and it
depends on the side. On side 0, at track shift, the starting sector
number is 4 higher than the sector number of the last sector on the
previous track, while on side 1 is only 1 higher. This makes sense
when you realize that the head is stepping backward on side 1 for a
real disk.

This data has been discovered by close examination of the PC99 disk
image files DSK1, DSK2, DSK3, and WNY23B. See the table below.

 Side 0

     track     sector number order

       0 =     0 7 5 3 1 8 6 4 2
       1 =     6 4 2 0 7 5 3 1 8
       2 =     3 1 8 6 4 2 0 7 5
       3 =     0 7 5 3 1 8 6 4 2
       4 =     6 4 2 0 7 5 3 1 8
               . . . . . . . . . . . .
      38 =     3 1 8 6 4 2 0 7 5
      39 =     0 7 5 3 1 8 6 4 2

        ________________________

Side 1

     track     sector number order

       0 =     0 7 5 3 1 8 6 4 2
       1 =     3 1 8 6 4 2 0 7 5
       2 =     6 4 2 0 7 5 3 1 8
       3 =     0 7 5 3 1 8 6 4 2
       4 =     3 1 8 6 4 2 0 7 5
       5 =     6 4 2 0 7 5 3 1 8
               . . . . . . . . . . . .
      37 =     3 1 8 6 4 2 0 7 5
      38 =     6 4 2 0 7 5 3 1 8
      39 =     0 7 5 3 1 8 6 4 2

The interleave (or the gap length) must be important on a PC99
diskette.  One of the two have to be the method by which PC99 finds
its sectors.  On a real diskette, the start of a new sector is
detected by the missing clock signal in the FE and FB bytes on the
disk (the ID Address Mark and Data Address Mark). The missing clock
is a very special signal to the disk controller. It means
"something important is coming up. Watch out".

On a PC99 disk image file that method can't work. For instance, all
the FB values are identical. They don't have a Missing Clock. How
can PC99 understand that a particular FB byte is not part of the
normal data in the data field of a sector? It simply can't.

In order not to make mistakes, it must rely on the length of the
gaps. For the above reasons, the format pattern shown above must
used as it is, with no variation at all. (Editor's note: There
might be a better, more compatible way to find the sector data
fields. The first FB byte must be a data address mark. The next
256 bytes would be normal data. Then the next FB byte should be
another data address mark. A PC99 disk image made from an original
TI disk might have a different sector order and gap size than
these files have. You would need to examine the ID fields to
determine the sector order.)

##-40.02.03
****            DOUBLE DENSITY PC99 DISK FORMAT                 ****
                ============================================

  18  sectors per track (0-17)
  40  tracks (0-39)
   2  sides (0-1)
1440  total sectors
 360  KBytes

Format disk layout
PC 99 Double Side/Double Density format layout is very similar to
the standard pattern you would find on a normal diskette, formatted
with a WD 1770-1772 chip in MFM mode (Double Density). There are
only minor differences, namely:

1) Start of track gap (filled with 4E) is shorter than normal:
   40 bytes instead of the normal 60.

2) CRC is always F7,F7. On a normal diskette you would write just
   1 F7 byte and that would create 2 CRC bytes. The value of these
   CRC bytes would depend on what you had written previously. Not
   so on a PC99 disk! You have to write 2 F7 bytes and, of course,
   then you will find your 2 F7 bytes.

3) End of track gap is longer than normal, 712 4E bytes instead of
   668.

                              number of bytes  byte value

'Start of track                    =  40  4E
'           +-------------------------------------------------------
'           |  Pre_ID gap          =  10  00
'           |  First 3 A1          =   3  A1
'  Each     |  ID                  =   1  FE     ID Address Mark
'  sector   |  Track #             =   1  ..     Track #  (00-39)
'  (repeat  |  Side #              =   1  ..     Side #   (00 or 01)
'  for 18   |  Sector #            =   1  ..     Sector # (0-8)
'  times)   |  Sector length       =   1  01     256 bytes/sector
'           |  CRC before Data     =   2  F7     always F7
'           |  Gap 1 before Data   =  22  4E
'           |  Gap 2 before Data   =  12  00
'           |  Second 3 A1         =   3  A1
'           |  Data Address Mark   =   1  FB     Data Address Mark
'           |  Data                = 256  ..     your real data,
'           |                                 or E5 if a blank disk!
'           |  CRC after data      =   2  F7     always F7
'           |  After Data Gap      =  24  4E
'           +-------------------------------------------------------
'
'End of track                      = 712  4E
'___________________________________________________________________

Used space
==========
        Sector length    = 334 bytes
        334 x 9 sectors = 3006 bytes + 16 (start of track) + 231
                          (end of track) = 3523 bytes
        3523 x 40 tracks x 2 sides = 260,240 bytes/disk.

As a matter of fact, a PC99 DS/DD disk image file is 260,240 bytes.
____________________________________________________________________
Note: (Not relevant for formatting, but important for copying
       purposes).

Following the TI-99/4A convention, the logical sectors will first
have to completely fill the lower Side (Side 0). Further logical
sectors have to go first to the last track (the inner track) of
Side 1 (the upper side). The next sectors will go on the tracks in
backward order, from the inner tracks to the outer tracks of side 1.
The highest sectors will go to track zero of Side 1

The interleave is 4:1 (advance 4 sectors ahead on the track to find
the next sector) on both disk sides, while you are on the same
track. At track shift, the starting sector is different and it
depends on the side. On side 0, at track shift, the starting sector
number is 4 higher than the sector number of the last sector on the
previous track, while on side 1 is only 1 higher. This makes sense
when you realize that the head is stepping backward on side 1 for a
real disk.

This data has been discovered by close examination of the PC99 disk
image files DSK1, DSK2, DSK3, and WNY23B. See the table below.

Side 0

     track     sector number order

       0 =     0 7 5 3 1 8 6 4 2
       1 =     6 4 2 0 7 5 3 1 8
       2 =     3 1 8 6 4 2 0 7 5
       3 =     0 7 5 3 1 8 6 4 2
       4 =     6 4 2 0 7 5 3 1 8
         . . . . . . . . . . . .
      38 =     3 1 8 6 4 2 0 7 5
      39 =     0 7 5 3 1 8 6 4 2

                ________________________

Side 1

     track     sector number order

       0 =     0 7 5 3 1 8 6 4 2
       1 =     3 1 8 6 4 2 0 7 5
       2 =     6 4 2 0 7 5 3 1 8
       3 =     0 7 5 3 1 8 6 4 2
       4 =     3 1 8 6 4 2 0 7 5
       5 =     6 4 2 0 7 5 3 1 8
         . . . . . . . . . . . .
      37 =     3 1 8 6 4 2 0 7 5
      38 =     6 4 2 0 7 5 3 1 8
      39 =     0 7 5 3 1 8 6 4 2

The interleave (or the gap length) must be important on a PC99
diskette. One of the two have to be the method by which PC99 finds
its sectors.

On a real diskette, the start of a new sector is detected by the
missing clock signal in the FE and FB bytes on the disk (the ID
Address Mark and Data Address Mark). The missing clock is a very
special signal to the disk controller. It means "something
important is coming up. Watch out".

On a PC99 disk image file that method can't work. For instance, all
the FB values are identical. They don't have a Missing Clock. How
can PC99 understand that a particular FB byte is not part of the
normal data in the data field of a sector? It simply can't. In
order not to make mistakes, it must rely on the length of the gaps.

For the above reasons, the format pattern shown above must used as
it is, with no variation at all. (Editor's note: There might be a
better, more compatible way to find the sector data fields. The
first FB byte must be a data address mark. The next 256 bytes would
be normal data. Then the next FB byte should be another data
address mark. A PC99 disk image made from an original TI disk might
have a different sector order and gap size than these files have.
You would need to examine the ID fields to determine the sector
order.)

---

From: "Michael Zapf" <[email-masked]>
Date: Tue, 01 Dec 2009 20:10:05 -0000

Hello Bill,

> MESS hard disk image format .HD that later changed to CHDMAN .CHD image 

Well, yes, in the way "he decided" must be understood as used within the herd of MESS developers. Or let's say, they decided to unify disk access to sector level. I'm not sure Raphael was too happy about that. Indeed, the HFDC implementation is incomplete in the track access, and Raphael noted somewhere that it has been decided support sector dumps only; he never finished it (thus, you should never try to format a disk with HFDC).

The situation is now somehow better, mainly because the architecture evolved a bit and now there is a clean interface between the image format and the controller code. So in principle you can hook any format to the controller, and it is the duty of the format to decide where to put the recently written byte. 

I had a closer look at the implementation, and I found that 41 computer systems in MESS make use of the WD17xx controller! So it is quite understandable that one should be very cautious with changes. 

> would much rather see a DSDD 40 track V9T9 image of 1600 sectors 

These are two different topics. We have quite a lot of PC99 dumps which I want to be able to work with in MESS. As for 1600 sectors, this is a matter of creating an emulation for the CF7A+ Sidecar, not of extending the floppy formats. I'll put that on the todo list.

Michael

---

From: fdos <[email-masked]>
Date: Tue, 01 Dec 2009 13:28:40 -0700

Hi Michael,

True.  I learned early on not to format diskette images with the HFDC 
and any disk manager software.  On the other hand we have to use MDM5 to 
format the HFDC hard disk images (.HD/.CHD) that are created with MESS 
CHDMAN.

Everything else clearly understood and accepted.

Bill S

Michael Zapf wrote:
> Well, yes, in the way "he decided" must be understood as used within the 
> herd of MESS developers. Or let's say, they decided to unify disk access 
> to sector level. I'm not sure Raphael was too happy about that. Indeed, 
> the HFDC implementation is incomplete in the track access, and Raphael 
> noted somewhere that it has been decided support sector dumps only; he 
> never finished it (thus, you should never try to format a disk with HFDC).
> 
> The situation is now somehow better, mainly because the architecture 
> evolved a bit and now there is a clean interface between the image 
> format and the controller code. So in principle you can hook any format 
> to the controller, and it is the duty of the format to decide where to 
> put the recently written byte.
> 
> I had a closer look at the implementation, and I found that 41 computer 
> systems in MESS make use of the WD17xx controller! So it is quite 
> understandable that one should be very cautious with changes.
> 
> These are two different topics. We have quite a lot of PC99 dumps which 
> I want to be able to work with in MESS. As for 1600 sectors, this is a 
> matter of creating an emulation for the CF7A+ Sidecar, not of extending 
> the floppy formats. I'll put that on the todo list.
> 
> Michael
> 
>

---

From: "Michael Zapf" <[email-masked]>
Date: Tue, 01 Dec 2009 20:31:42 -0000

Hello Paolo,

good to see you. I hope I can close the rest of my knowledge gaps here.

I have learned quite a lot about disks in the last 3 days. 

- You can read raw tracks. 
- You cannot write them, though. Because there are special control bytes (like f7) which are not written to the disk but which control the built-in CRC generator. If a sector content of the track contained such a f7 (of fb, fe, whatever), it may cause problems.
- I believed to remember track copier programs. This could only work if you read the track, write the track without sector content (type-3), and then write the sectors with type-2 commands.
- PC99 is not a clean track dump. I failed to map the gap specifications on the gaps in a sample PC99 file. And there are always those f7f7 - where's the CRC? I already suspected that this has to do with the PC99 format.
- Today I thought I should have a look at some possibly available PC99 format documentation. And found your text.

I originally planned to implement the PC99 format in the TI MESS emulation as a 1:1 track/image transfer, but now this means PC99 is just another format which needs translation.

One motivation for me to go to track level was to support non-standard formating (useful for disk protection, has there ever been an example like different sector ordering?) or support other interleaving. But reading your text I'm getting doubts. Do you think PC99 may cope with other track structures like a different interleave (3:1 or other)? I mean, does it make sense at all to go for such deep track handling when in the end, PC99 is not so flexible at all? 

Or should we consider to extend the format? 

Michael

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Wed, 2 Dec 2009 00:10:19 +0100

Michael,

> - You can read raw tracks.

A:
True, but your results will vary, depending on the hardware and the FDC 
chip you use.
In almost all cases, the gap length between sectors won't be the same, 
which is very different from what happens in PC99 format, where the fixed 
length of each field makes it easy to find sectors in a track.
That's why, in my opinion, PC99 format is artificial and unnecessarily 
complicated. It gives you an almost extact track format that, if you are 
to format a real TI disk, does not serve the purpose. You will just have 
to extract all the sectors anyway.

> - You cannot write them, though. Because there are special control bytes 
> (like f7) which are not written to the disk but which control the 
> built-in CRC generator. If a sector content of the track contained such 
> a f7 (of fb, fe, whatever), it may cause problems.

A:
I'm sure you mean you cannot write them with all the sectors already 
written with real data. This is true.
When you format a track, what you really do is to actually write a track.
With WD1770 you lay down an entire track in VDP, leaving all the sector 
data fields filled with any byte that is below F5, write just 1 byte (F7) 
for any CRC you need and that will generate 2 CRC bytes once the VDP 
content is trasferred to the Data Register.

> - I believed to remember track copier programs. This could only work if 
> you read the track, write the track without sector content (type-3), and 
> then write the sectors with type-2 commands.

A:
True. The strength of a track copier lies in its ability to mimick all the 
protections implanted by the first creator.

I mistakenly thought that a NEC 765 was what was needed to track-copy a TI 
disk. Once I managed how to work with the NEC 765 I realized that the 
WD17xx is much more flexible and suitable for that particular task. Just 
because the WD17xx does so little for you and expects you to feed it 
anything that has to go to the disk, well, for that very reason it is more 
apt to do any strange thing you want it to do (wrong track and sector 
numbers, false sectors, different sector lenghts inside the same track, 
and so on...). NEC 765 leaves you so little to do: you either use the few 
built-in functions or you're stuck.

> - PC99 is not a clean track dump. I failed to map the gap specifications 
> on the gaps in a sample PC99 file. And there are always those f7f7 - 
> where's the CRC? I already suspected that this has to do with the PC99 
> format.

A:
True. See above. As said, PC was a noble and brave effort to give the user 
the "real thing", a format good for any season, so to speak. Too bad it 
was also a lot of unneeded data that complicated life for some of us. Mind 
though, aside from the PC99 format, I really admire Mike Wright for his 
superb work with PC99!

> - Today I thought I should have a look at some possibly available PC99 
> format documentation. And found your text.

A:
:-)

> I originally planned to implement the PC99 format in the TI MESS 
> emulation as a 1:1 track/image transfer, but now this means PC99 is just 
> another format which needs translation.
> One motivation for me to go to track level was to support non-standard 
> formating (useful for disk protection, has there ever been an example 
> like different sector ordering?) or support other interleaving.

A:
I don't think PC99 has ever tried to support/defeat disk protection on a 
TI disk. Others may know more than me on this matter. For what I know, 
PC99 is just a collection of sectors, like VT99, surrounded with extra 
data that are never really used by the program.
Mike Wright stated that he had contacted an external firm to add real TI 
disk support (read/write/format) for his PC99. The firm asked a very high 
price for it, and that did not include a guarantee the software would work 
in any circumstance (I might add the firm was right in that [Single 
Density depends on the PC hardware]).
That obvioulsy discouraged Mike and the project was abandoned.
Maybe, and I am just guessing now, the PC99 format was a naive effort on 
Mike's side to make things easier for a possible "TI formatter on a PC" 
from an external firm.

> But reading your text I'm getting doubts. Do you think PC99 may cope 
> with other track structures like a different interleave (3:1 or other)?

A:
Nope, I don't think so. But I never really tried that, man. You'd better 
try it out, if you wanna know for sure.

> I mean, does it make sense at all to go for such deep track handling 
> when in the end, PC99 is not so flexible at all?

A:
I, for one, wouldn't go to that extent, but I'm not you :-)
At any rate, my approach to the PC99 supports in TI99-PC works like this. 
You will see the QBasic code posted at the bottom of this message actually 
supports different interleaves:

GetVirtualZero
==============
1) See if the disk is V9T9 or PC99 by analizing sector zero 
(presence/absence of 'DSK' at byte 13.
2) If PC99, see if it is Single or Double Density (presence of 3 >A1 bytes 
at the sector start)
3) Establish what type of disk we have, to be used at later calls.

GetVirtualSect
==============
4) When accessing a PC99 disk, don't assume the track has the standard 
interleave. Rather, search the sector by reading all the sector numbers in 
the ID Field in an orderly manner, until you find the one that matches the 
sector you are looking for. Do assume that all the gaps have a fixed 
length. Hence, track length is fixed too.

Paolo

====================================================================
My QBasic code support for V9T9 and PC99. The caller does not need to know 
what type of disk he's working with. As usual, code is not optimized!!!
Could be better, but it works. Please report only cases of real flaw.
====================================================================
' ESTABLISH MEDIA OF A PC99 OR V9T9 DISK AND GET SECTOR ZERO
' Ex. Call GetVirtualZero (1, d$)
'       .... will return
'FType$ = "VS" if V9T9 disk
'FType$ = "PS" if PC99 Single density disk
'FType$ = "PD" if PC99 Double density disk
'FType$ is a Global Static Variable

SUB GetVirtualZero (FileNum%, d$)
  ByteOff& = 1
  DIM DAT(1) AS STRING * 256

  GET #FileNum%, ByteOff&, DAT(1)
  IF MID$(DAT(1),14,3)<>"DSK" THEN GOTO PC99Detect
  FType$ = "VS"          ' V-9T9 S-ingle density
  d$=MID$(DAT(1),1,256)
  GOTO V9T9Found

PC99Detect:      P = INSTR(DAT(1), CHR$(&HFE)): IF P = 0 THEN GOTO 
EstMedAbort
  A$ = MID$(DAT(1), P + 4, 1)
  IF A$ <> CHR$(&H1) THEN GOTO EstMedAbort
  A$ = MID$(DAT(1), P - 3, 3)
  IF A$ = CHR$(&HA1) + CHR$(&HA1) + CHR$(&HA1) THEN GOTO DDens
  IF A$ <> CHR$(0) + CHR$(0) + CHR$(0) THEN GOTO EstMedAbort
'*** SINGLE DENSITY DISK ***
SDens:
  A$ = MID$(DAT(1), P + 4, 1)
  IF A$ <> CHR$(1) THEN GOTO EstMedAbort
  IF P <> 23 THEN GOTO EstMedAbort
  Gap1% = 16             ' Start of track Gap
  PreIDGap% = 7          '
  PreDatGap% = 31
  SLength% = 334
  SekTrack% = 9

  CONST TrkLenS% = 3253
  TrkLen# = TrkLenS%
  'REDIM TrackSing(1) AS STRING * TrkLenS
  GET #FileNum%, 1, TrackSing(1)
  d$ = TrackSing(1)
  FType$ = "PS"          ' P-C99 S-ingle density
  GOTO GetSZero1

'*** DOUBLE DENSITY DISK ***
DDens:
  IF P <> 54 THEN GOTO EstMedAbort
  Gap1% = 40             ' Start of track Gap
  PreIDGap% = 14
  PreDatGap% = 58
  SLength% = 340
  SekTrack% = 18
  ERASE TrackSing
  CONST TrkLenD% = 6872
  TrkLen# = 6872
  'REDIM TrackDoub(1) AS STRING * TrkLenD
  GET #FileNum%, 1, TrackDoub(1)
  d$ = TrackDoub(1)
  FType$ = "PD"          ' P-C99 D-ouble density
  GOTO GetSZero2
GetSZero1:       ERASE TrackDoub
GetSZero2:
  OldTrack# = 0
  OldDskSide# = 0
  SideLen# = TrkLen#
  SideLen# = SideLen# * 40
  FOR T = 1 TO SekTrack%
  P = 1 + Gap1% + PreIDGap% + (SLength% * (T - 1))
  A$ = MID$(d$, P, 4)

  IF A$ = CHR$(0) + CHR$(0) + CHR$(0) + CHR$(1) THEN GOTO SZeroFnd
  NEXT T
  GOTO EstMedAbort
SZeroFnd:        P = 1 + Gap1% + PreDatGap% + (SLength% * (T - 1))
  d$ = MID$(d$, P, 256)
  'A$=MID$(DAT,14,3)
  'IF A$<>"DSK" THEN GOTO EstMedAbort
  GOTO EstMedExit

V9T9Found:       ERASE TrackSing
  ERASE TrackDoub
  GOTO EstMedExit
EstMedAbort:    FType$ = ""  : d$ = ""
EstMedExit:     ERASE DAT
END SUB

' READ A SECTOR FROM PC99 DISK
SUB GetVirtualSect (FileNum%, Sektor%, d$)
  Sekr% = Sektor% - 1

  IF FType$ <> "VS" THEN GOTO PC99disk            ' V-9T9 S-ingle density
  ByteOff&=Sekr%
  ByteOff&=ByteOff&*256
  GET #FileNum%, ByteOff& + 1, V9T9Sekt(1)
  d$= V9T9Sekt(1)
  GOTO GetSectExit

PC99disk:       Trk# = INT(Sekr% / SekTrack%)
  DskSide# = 0
  IF Trk# > 39 THEN Trk# = 79 - Trk#: DskSide# = 1
  Skt% = Sekr% MOD SekTrack%

  IF FType$ = "PD" THEN GOTO GetSectD
  IF FType$ = "PS" THEN GOTO GetSectS

'*** SINGLE DENSITY DISK ***
GetSectS:       IF Trk# = OldTrack# AND DskSide# = OldDskSide# THEN GOTO 
GetSectS03
  ByteOff& = SideLen# * DskSide# + Trk# * TrkLen#
  GET #FileNum%, ByteOff& + 1, TrackSing(1)
  OldTrack# = Trk#: OldDskSide# = DskSide#

GetSectS03:     FOR WHT% = 1 TO SekTrack%
  P = 1 + Gap1% + PreIDGap% + (SLength% * (WHT% - 1))
  A$ = MID$(TrackSing(1), P, 4)

  IF A$ <> CHR$(Trk#) + CHR$(DskSide#) + CHR$(Skt%) + CHR$(1) THEN GOTO 
GetSectS05
  d$ = MID$(TrackSing(1), 1 + Gap1% + PreDatGap% + (SLength% * (WHT% - 
1)), 256)
  GOTO GetSectExit

GetSectS05:     NEXT WHT%

  GOTO GetSectBad:

'*** DOUBLE DENSITY DISK ***
GetSectD:       IF Trk# = OldTrack# AND DskSide# = OldDskSide# THEN GOTO 
GetSectD03
  ByteOff& = SideLen# * DskSide# + Trk# * TrkLen#
  GET #FileNum%, ByteOff& + 1, TrackDoub(1)
  OldTrack# = Trk#: OldDskSide# = DskSide#

GetSectD03:     FOR WHT% = 1 TO SekTrack%
  P = 1 + Gap1% + PreIDGap% + (SLength% * (WHT% - 1))
  A$ = MID$(TrackDoub(1), P, 4)

  IF A$ <> CHR$(Trk#) + CHR$(DskSide#) + CHR$(Skt%) + CHR$(1) THEN GOTO 
GetSectD05
  d$ = MID$(TrackDoub(1), 1 + Gap1% + PreDatGap% + (SLength% * (WHT% - 
1)), 256)
  GOTO GetSectExit

GetSectD05:     NEXT WHT%

GetSectBad:     d$ = ""

GetSectExit:
END SUB

---

From: "Michael Zapf" <[email-masked]>
Date: Wed, 02 Dec 2009 00:12:05 -0000

Hello Paolo,

many thanks for the answer. In the meantime I was also active. I sometimes forget about the power of an emulator (especially one of which you have the source code :-) ), but I remembered just now that I can witness the process of formatting quite easily: I just put some printf lines in the wd17xx.c of MESS. The DSR in the disk controller "believes" to have a real system here, so let's just listen to it.

You can find the result on ninerpedia: http://www.ninerpedia.org/index.php/SSSD_Format_Log .

What I wonder about is the lead-in of the track: 7f 3f ... This is what I could not find in the specs and also not in the PC99 format. These are 8 bytes supplied to the data register after the WRITE TRACK command but before the 16 zeros. You have a theory about that?

As for PC99 I think I will step back to just supporting the format as a somewhat bloated sector format and keep the track structure. It does not make sense to make it more flexible and then create incompatible file formats. In that way it is basically as easy to support as the sector dump (aka "v9t9").

Michael

---

From: Insane Multitasker <[email-masked]>
Date: Tue, 1 Dec 2009 19:19:38 -0600

Paulo,  this thread has been most interesting.

I am curious about one thing:  why is "DSK" used to determine if the disk is V9T9 or PC99?  Assuming both formats capture the sector as is presented on disk, would this not be ambiguous?  Or did I just miss something else important?  :)  Tim

GetVirtualZero
==============

> To: [email-masked]
> From: [email-masked]
> Date: Wed, 2 Dec 2009 00:10:19 +0100
> Subject: Re: [TI994A] Re: PC99 format
> 
> Michael,
>  		 	   		  
_________________________________________________________________
Windows Live Hotmail is faster and more secure than ever.
http://www.microsoft.com/windows/windowslive/hotmail_bl1/hotmail_bl1.aspx?ocid=PID23879::T:WLMTAGL:ON:WL:en-ww:WM_IMHM_1:092009

---

From: "Jacques Groslouis" <[email-masked]>
Date: Tue, 1 Dec 2009 21:52:50 -0400

I may be wandering beyond my depth in asking this question. Is this "DSK" 
the same as the '.dsk' extension on most PC99 or v9t9 files? If so, I know 
that a PC99 file without such an extension works perfectly OK with the PC99 
emulator. I do not know if this is the same with v9t9.

Jacques

----- Original Message ----- 
From: "Insane Multitasker" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, December 01, 2009 9:19 PM
Subject: RE: [TI994A] Re: PC99 format

I am curious about one thing:  why is "DSK" used to determine if the disk is 
V9T9 or PC99?  Assuming both formats capture the sector as is presented on 
disk, would this not be ambiguous?  Or did I just miss something else 
important?  :)  Tim

GetVirtualZero
==============

---

From: mark wills <[email-masked]>
Date: Tue, 1 Dec 2009 22:42:48 -0800 (PST)

I read a Micropendium article the other day, in which Mike Wright wrote an article on defeating the copy protection on the SPAD XIII disk.

To cut a long (and interesting) story short, the disk had multiple levels of protection, including fake sectors that PC99 could not handle.

The soloution in the end was to hack the assembly language loader (which checked for the existance of this 'fake' track 3 (IIRC)) so that it *thinks* the fake track is there.

The disk image was then modified to be compatible with PC99. So the disk 'image' for SPAD on a PC99 disk, and a real TI disk, are different.

I therefore conclude that PC99 disk format is not as flexible as the real thing.

Not sure if this answers any questions, but it might give some insight.

Regards

Mark

>
>From: Paolo Bagnaresi <[email-masked]>
>Sent: Wed, 2 December, 2009 0:10:19
>>disk support (read/write/ format) for his PC99. The firm asked a very high 
>>============ ==
>>============ ==
>>============ ========= ========= ========= ========= ========= ========= ==
>>============ ========= ========= ========= ========= ========= ========= ==
>>  IF MID$(DAT(1), 14,3)<>"DSK" THEN GOTO PC99Detect
>>  d$=MID$(DAT( 1),1,256)
>>PC99Detect:      P = INSTR(DAT(1) , CHR$(&HFE)): IF P = 0 THEN GOTO 
>>EstMedAbort
>>  'A$=MID$(DAT, 14,3)
>>  ByteOff&=ByteOff& *256
>>  A$ = MID$(TrackSing( 1), P, 4)
>
>>IF A$ <> CHR$(Trk#) + CHR$(DskSide# ) + CHR$(Skt%) + CHR$(1) THEN GOTO 
>>GetSectS05
>>  d$ = MID$(TrackSing( 1), 1 + Gap1% + PreDatGap% + (SLength% * (WHT% - 
>>1)), 256)
>>  GOTO GetSectExit
>
>>GetSectS05:     NEXT WHT%
>
>>GOTO GetSectBad:
>
>>  A$ = MID$(TrackDoub( 1), P, 4)
>
>>IF A$ <> CHR$(Trk#) + CHR$(DskSide# ) + CHR$(Skt%) + CHR$(1) THEN GOTO 
>>GetSectD05
>>  d$ = MID$(TrackDoub( 1), 1 + Gap1% + PreDatGap% + (SLength% * (WHT% - 
>>1)), 256)
>>  GOTO GetSectExit
>
>>GetSectD05:     NEXT WHT%
>
>>GetSectBad:     d$ = ""
>
>>GetSectExit:
>>END SUB
>
>
>

---

From: "Michael Zapf" <[email-masked]>
Date: Wed, 02 Dec 2009 10:31:15 -0000

> I am curious about one thing:  why is "DSK" used to determine if the disk is V9T9 or PC99?  Assuming both formats capture the sector as is presented on disk, would this not be ambiguous?  Or did I…

In PC99, since there is track data (to some extend, as we just found out in this thread), the sector 0 has an offset to the beginning of the file, coming after track lead-in and its sector lead-in. The track data will never show "DSK" at the locations where you expect them in a VIB if the VIB is stored right at the beginning like in sector dumps (aka "v9t9").

I'm also thinking about an auto-detection within MESS (we won't agree on changing suffixes, I'm sure :-) ). Checking for "DSK" sounds good, but I would rather check for the medium length. If you check for content, unformatted disks and those with no or a broken VIB will not be recognized. Apart from that, since a sector may contain any data, including parts of the image of a track, the length should be the only safe way of telling them apart. There are only a few numbers to check for SSSD up to DSHD which are all different to numbers appearing for PC99.

Michael

---

From: "Michael Zapf" <[email-masked]>
Date: Wed, 02 Dec 2009 11:15:07 -0000

> emulator. I do not know if this is the same with v9t9.

No, it's the DSK character sequence in the Volume Information Block (sector 0). See http://www.ninerpedia.org/index.php/Formats#Volume_Information_Block .

Michael

---

From: ti99_forever <[email-masked]>
Date: Wed, 2 Dec 2009 03:31:40 -0800 (PST)

Yeah, I wasn't sure from reading the code whether it was the offset from the beginning of sector 0, or the offset from the beginning of the file...

I see you think the latter, which is what I wound up assuming...

--- On Wed, 12/2/09, Michael Zapf <[email-masked]> wrote:

> From: Michael Zapf <[email-masked]>
> Subject: [TI994A] Re: PC99 format
> Date: Wednesday, December 2, 2009, 5:31 AM
> 
> 
> 
> 
> 
> > I am curious about one thing:  why is "DSK" used
> to determine if the disk is V9T9 or PC99?  Assuming
> both formats capture the sector as is presented on disk,
> would this not be ambiguous?  Or did I just miss
> something else important?  :)  Tim
> 
> In PC99, since there is track data (to some extend, as we
> just found out in this thread), the sector 0 has an offset
> to the beginning of the file, coming after track lead-in and
> its sector lead-in. The track data will never show "DSK" at
> the locations where you expect them in a VIB if the VIB is
> stored right at the beginning like in sector dumps (aka
> "v9t9").
> 
> I'm also thinking about an auto-detection within MESS (we
> won't agree on changing suffixes, I'm sure :-) ). Checking
> for "DSK" sounds good, but I would rather check for the
> medium length. If you check for content, unformatted disks
> and those with no or a broken VIB will not be recognized.
> Apart from that, since a sector may contain any data,
> including parts of the image of a track, the length should
> be the only safe way of telling them apart. There are only a
> few numbers to check for SSSD up to DSHD which are all
> different to numbers appearing for PC99.
> 
> Michael
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
>     [email-masked]
> 
> 
>

---

From: Insane Multitasker <[email-masked]>
Date: Wed, 2 Dec 2009 13:44:00 -0600

Agreed, Michael, medium/media byte size seems like a reasonable method.  In fact, this may be one "reason" not to change the extension, leaving Ernie less work to do with WHT's files.  ;)

My concern with "DSK" detection was partially rooted in that some disks do not contain this identifier, which then makes them terribly difficult to mount in MESS and could create difficulties with Paulo's program.  
 
> From: [email-masked]
> Date: Wed, 2 Dec 2009 10:31:15 +0000
 		 	   		  
_________________________________________________________________
Get gifts for them and cashback for you. Try Bing now.
http://www.bing.com/shopping/search?q=xbox+games&scope=cashback&form=MSHYCB&publ=WLHMTAG&crea=TEXT_MSHYCB_Shopping_Giftsforthem_cashback_1x1

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Wed, 2 Dec 2009 23:14:11 +0100

Mmmh,

7f 3f 00 cf e0 7f 3f 01 01
00*16
00 00 00 00 00 00
fe
00 00 00
01
f7
ff*11

the first 9 bytes surely don't belong to any standard format performed by 
FDC chip I know: WD177x, TMS279X, NEC 765.

If I were to say what would happen if you really started formatting a 
track on a real floppy with those values, I'd say: nothing.

The first bytes in a track are there just to give time to the head to sync 
with the bit patterns. The first important byte is the >FE byte. It comes 
after 6 bytes of >00, again there just to make recognizing the >FE byte 
easier (pattern change). >FE byte presets CRC and does something with the 
CLK (missing bits again??).

So, whatever comes before
00 00 00 00 00 00
fe
I think that is bound to be ignored. As a matter of fact, on a fast system 
you can considerably shorten the first bytes of a track. The sector will 
be read anyhow.

So, since those 9 bytes are not strictly needed, at least on a real 
system, what are they there for?
- A way for MESS to identify the controller FDC is trying to emulate?
- A date, an hour stamp?
- Just a programmer's mark, like "Kilroy was here" in WWII?

Please check if the 9 byte string remains the same when you change 
Density, Date, MESS version, and so on.

More important. Since you have the MESS source code, why don't you give a 
look at the MESS code that actually *reads* that track?

At any rate, if you find that all the tracks in different disk images 
alway start with those 9 bytes, then I wouldn't bother. Maybe it is just 
something inherited from the past, an unimportant leftover that nobody 
knows why is there anymore.

> As for PC99 I think I will step back to just supporting the format as a
> somewhat bloated sector format and keep the track structure.
> It does not make sense to make it more flexible and then create 
> incompatible file formats.
> In that way it is basically as easy to support as the sector dump (aka 
> "v9t9").

Yep, I'd do the same :-)

Paolo

----- Original Message ----- 
From: "Michael Zapf" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 02, 2009 1:12 AM
Subject: [TI994A] Re: PC99 format

> Hello Paolo,
>
> many thanks for the answer. In the meantime I was also active.
> I sometimes forget about the power of an emulator (especially one of 
> which you have
> the source code :-) ), but I remembered just now that I can witness the 
> process
> of formatting quite easily: I just put some printf lines in the wd17xx.c 
> of MESS.
> The DSR in the disk controller "believes" to have a real system here,
> so let's just listen to it.
>
> You can find the result on ninerpedia: 
> http://www.ninerpedia.org/index.php/SSSD_Format_Log .
>
> What I wonder about is the lead-in of the track: 7f 3f ... This is what 
> I could not
> find in the specs and also not in the PC99 format.
> These are 8 bytes supplied to the data register after the WRITE TRACK 
> command
> but before the 16 zeros. You have a theory about that?
>
> As for PC99 I think I will step back to just supporting the format as a
> somewhat bloated sector format and keep the track structure.
> It does not make sense to make it more flexible and then create 
> incompatible file formats.
> In that way it is basically as easy to support as the sector dump (aka 
> "v9t9").
>
> Michael
>

---

From: "Tony Knerr" <[email-masked]>
Date: Wed, 02 Dec 2009 22:25:15 -0000

Call me nutty, but it looks like a listing of VDP registers got mixed  into that first part of the code. (you won't be the first to call me nutty). :)

Tony

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Thu, 3 Dec 2009 00:06:41 +0100

VDP Regs???
Gee, Tony, that would be really *hilarious*!!!
:-D

Paolo

----- Original Message ----- 
From: "Tony Knerr" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 02, 2009 11:25 PM
Subject: [TI994A] Re: PC99 format

Call me nutty, but it looks like a listing of VDP registers got mixed 
into that first part of the code. (you won't be the first to call me 
nutty). :)

Tony

--- In [email-masked], "Paolo Bagnaresi" <paul.bagnaresi@...>

---

From: Insane Multitasker <[email-masked]>
Date: Wed, 2 Dec 2009 21:24:47 -0600

hi Michael,

A few items I noticed while reading the latest version of the 'format' section:

1. Density values: Ultra (4): 1MBit/s MFM 

I don't know of any practical or DSR-invoked application of density value (4).  I believe the highest physical disk density value is three, utilized by the HFDC for High Density 1.44MB disks. 

2. Disks with a capacity of at most 400 KiB have an AU size of 1 sector (all SSSD, SSDD, DSSD, DSDD, with 40 tracks, at most 1440 sectors). Disks with at most 800 KiB space have 2 sectors per AU (720 KiB, 2880 sectors), with 1.4 MiB we have 4 sectors per AU, and the disks with ultra capacity (2.8 MiB) have 8 sectors per AU. 

The Geneve operating system may be the only system to use 8 sectors/AU.  It is limited to RAMdisks and EMULATE files on the HFDC.  However, IIRC, a density value of 2 or 3 is used.  I do not have access to my system at the moment to confirm.

3. Hard drive FDIRs

The directory parent/child pointers operate different under the TI and Geneve.  I have it on my list to find the actual difference; I believe the Geneve DSR uses the standard whereas the HFDC DSR does not.  Using MDM5 for directory operations is therefore performed at one's own peril ;)

4. MESS hard drive images require some tweaking as you know.  (I believe I still owe you a reply about that)

5. I think Fred's site contains additional information about the IDE hard disk partition format. 

Nice job on that Wiki.  Tim

---

From: "Michael Zapf" <[email-masked]>
Date: Thu, 03 Dec 2009 10:01:51 -0000

Hello Paolo,

>...

can't have to do with MESS, I'm pretty sure. The nice thing about such an emulator is that if done correctly, the software running on it "believes" to run on a real machine. Keep in mind we are using the original TI DSR here.

I was just listening to write operations to the data register in the wd17xx implementation. That is, those bytes are definitely produced by the DSR in the TI FDC. There is no other way they could have been produced, as MESS does not "call itself". I could try to find out whether this can be found in the ROM somewhere.

> look at the MESS code that actually *reads* that track?

Quite simple: Because the code is broken in MESS. As I said, they attempted to map track reading/writing to sector operations. Read track is rarely used, and I would not bet anything on its proper operation. And write track was formerly just extracting the sectors from the track image and then using type-II operations for each one. Currently, write track has evolved to a dummy operation, silently returning: If you format a disk in Disk manager 2 in MESS, it seems as if the track is formatted, but in effect nothing is done. The sectors are not cleared, just the VIB and FDIR is written (so it's been turned to a "quick format"). This only works with the wd17xx, but the smc92x4 is buggy at that point, thus we get a crash as soon as someone tries to format a disk with the HFDC. 

(What I did was to eavesdrop before MESS delegates the operations to the empty functions.)

So I'm not just doing research for research's sake here :-) ... I'm trying to learn how low-level floppy access is working, so that I can fix that. And on that occasion, allowing for pc99 format processing.

I thought these obscure bytes could be some meaningful bit pattern at the beginning of the track: 7f 3f 00 cf e0 7f 3f 01 01 =

01111111001111110000000011001111111001111111001111110000000100000001 

As I said, I'll try to find the location in the TI FDC ROM where this is produced (again a matter of suitably positioned printf). If I can locate that I can ask developers for other system what this could mean.

Michael

---

From: "Michael Zapf" <[email-masked]>
Date: Thu, 03 Dec 2009 10:13:47 -0000

Hello Tim, 

> [...]  

I can add that. But if you are sure about that, don't hesitare, just go ahead and add that to the Wiki. 

> 4. MESS hard drive images require some tweaking as you know.  (I believe I still owe you a reply about that)

But only w.r.t. the VIB and MaxAU, right? In fact, I successfully used my conversion tool to convert the SCSI image to HFDC, modified that in MESS's Geneve emulation, reconverted to SCSI, wrote to the real hardware, hooked that to the Geneve, read it, added a file there, reconnected the SCSI drive to the PC, read the image, turned it to HFDC, read the file in MESS's Geneve emulation.

Michael

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Thu, 3 Dec 2009 20:03:33 +0100

Hi Michael,

> > 7f 3f 00 cf e0 7f 3f 01 01

Definitely that's not the usual way you would start formatting a track 
with. I don't have the TI FDC disassemble listing at hand (it's stored in 
the basement of my summer house, 380 km away), so I cannot give you proofs 
for that. But I do remember that a track formatting begins with a 
repetition of the same byte, for several times (and not with different 
bytes, apparently taken randomly).

So, MESS is doing soemthing strange there.

I do have at hand the way the source code of Jump Boot Generator, a Geneve 
formatter that would allow fast booting from floppy at Geneve bootstrap. 
My friend Massimo Cariboni and I wrote that program. The formatting code 
was .. ahem... cough.. cough... let's say 'inspired' by the Geneve code. 
If you have the MDOS source code (MDOS650source.zip, 1,130 KB), go to
 File L8.ARK, extracting file: 'FORMAT-P.3'. Check lines 47 - 68. That 
code is reported at the very bottom of this message.

Michael, all the docs we have about the WD177X point out that the first 
bytes can either be >00 or >FF. Why would TI deviate from that standard?

I would supsect corruption of the TI FDC DSR PROM.

Maybe Tony Knerr is right after all, ... aha, that seemed way too funny at 
the beginning!
:-)

Paolo

===================================================

* 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* This routine only provides initialization. No check of valid sectors is
* performed by the routine. Before checking, you have to write on sector 
zero
* all the usual infos (total sectors, side #, density #, sector/track,
* track/side). Due to the particular features of Myarc Disk Controller, 
failure
* to comply with this requirement will make it impossible to access any 
sector
* above 1440
*
********************************************************************************
*   San Donato Milanese,  6,10/26/86,21:04:15
*
*   Paolo Bagnaresi
*   Via J.F. Kennedy 17
*   20097 San Donato Milanese, Italy
*   Phone 514.202 (Milan area code : 2. Calling from U.S. dial
*                        011-39-2 first).
********************************************************************************
*
* Disclaimer: the informations given in this program are not warranted to
* free from errors. Users will assume full responsibility if they ever try 
to
* put into practice whatever is suggested in this program. This implies 
that
* any damage that may arise from the use of this program, including drive 
or
* disk controller damage, is not to be ascribed the author.
* However, you can bet your last penny the program will work!
********************************************************************************
       LI   R1,DH        -> Load Double Density Table Address
       CB   @>8350,@DI   -> >02 ? That is: Double Density ?
       JEQ  DJ           -> Yes, jump
       LI   R1,DK        -> Load Single Density Table Address

* PREPARE VDP LAYOUT TO FORMAT

DJ     MOV  *R1+,R4      -> Get Sector/Track
DO     MOVB *R1+,R0
       CB   R0,@DL       -> >01, Token for START OF SECTORS?
       JEQ  DM           -> Yes, jump
       CB   R0,@DI       -> >02, Token for END OF SECTORS?
       JEQ  DN           -> Yes, jump
       MOVB *R1+,R7      -> Get byte count
       SRL  R7,8
       BL   @CW          -> Send bytes to VDP
       JMP  DO

* VDP VALUES FOR SECTOR START

DM     MOVB @DP,@>8C00   -> Send IDENTIFIER ADDRESS MARK (>FE)
       MOVB R6,@>8C00    -> Send Track #
       MOVB R5,@>8C00    -> Send Side # (>00 or >01)
       MOVB @>5011,@>8C00   -> Send Sector # (>5011 is R8 LSByte)
       MOVB @DL,@>8C00   -> Send sector length (>01, that is 256 bytes)
       MOVB @DQ,@>8C00   -> Send >F7: triggers CRC
       JMP  DO

* VDP VALUES FOR SECTOR END

DN     ABS  @EXTRA       -> Special Track Fromatting?
       JEQ  DN1          -> No, jump
       INCT R1           -> Pointer to last sector fill gap byte
       MOV  *R1+,R0      -> Get last sector fill gap byte
       MOV  *R1,R1       -> Get restart Density Table address
       MOV  @CSECT,R7    -> Pointer to Sector Progrssion Table for Current 
Track
       INC  @CSECT       -> Pointer to Next Sector Progrssion Table for 
Current
       MOVB *R7,R8       -> Get Next sector #
       SRL  R8,8         ->
       CI   R8,>FF       -> End of sector?
       JNE  DO           -> No, do next sector: jump back
       JMP  TRKEND

DN1    A    *R1+,R8      -> Add Interlace factor to sector #
       CLR  R7
       DIV  R4,R7        -> Divide it by sector/track #

       MOV  *R1+,R0      -> Get last sector fill gap byte
       MOV  *R1,R1       -> Get restart Density Table address
       MOV  R8,R8        -> End of track?
       JNE  DO           -> No, do next sector: jump back

* TRACK END

TRKEND LI   R7,>02BC     -> TRACK END is here: >2BC bytes to send
       BL   @CW          -> Send them to VDP

       ......   Note 12.3.2009 - Track formatting is finished here

* FORMATTING VALUE TABLE
*
* Double density DATA

DH     DATA >0012  -> Number of Sectors in each Track
       BYTE >4E    -> Value to fill First Gap
       BYTE >20    -> First Gap byte count (send >20 bytes)

BC     BYTE >00    -> Value to fill Second gap
       BYTE >0C    -> Second Gap byte count

       BYTE >F5    -> Third Gap fill byte
       BYTE >03    -> Third byte count

       BYTE >01    -> Software TOKEN : send ID Address Mark, Track number,
*                     Side number, Sector number, sector length, CRC 
preset
       BYTE >4E    -> Value to fill Third Gap
       BYTE >16    -> Third Gap byte count

       BYTE >00    -> Forth Gap fill byte
       BYTE >0C    -> Fourth Gap byte count

       BYTE >F5    -> Fifth Gap fill byte
       BYTE >03    -> Fifth Gap byte count

       BYTE >FB    -> DATA ADDRESS MARK
       BYTE >01    -> Byte Count

       BYTE >E5    -> Fill sector value
       BYTE >80    -> Byte count for first half sector
       BYTE >E5    -> Fill sector value
       BYTE >80    -> Byte count for second half sector

       BYTE >F7    -> CRC (Cyclic Redundancy check)
       BYTE >01    -> Byte count

       BYTE >4E    -> After sector Gap
       BYTE >0A    -> After sector gap byte count: Shortened from >14 to 
 >0A
*                     to allow smooth SYSTEM/SYS loading. We must give 
more
*                     time to the head when it gets to the end of track.
*                     Today is April 2, 1988
DI     BYTE >02    -> Software TOKEN : Update Sector Number

       DATA >000B  -> Interlace factor
       DATA >4E4E  -> Used only when last Sector in Track
       DATA BC     -> Loop back once more

* Single Density DATA

DK     DATA >0009  -> Number of Sectors in each Track
       BYTE >FF    -> Value to fill First Gap
       BYTE >0C    -> First Gap byte count (Send >0C bytes)

DKU    BYTE >00    -> Value to fill Second Gap
       BYTE >06    -> Gap byte count
       BYTE >01    -> Software TOKEN : send ID Address Mark, Track number,
*                     Side number, Sector number, sector length, CRC
       BYTE >FF    -> Value to fill Third Gap
       BYTE >0B    -> Third Gap byte count

       BYTE >00    -> Value to fill Fourth Gap
       BYTE >06    -> Fourth Gap byte count

       BYTE >FB    -> DATA ADDRESS MARK
       BYTE >01    -> Byte Count

       BYTE >E5    -> Fill sector value
       BYTE >80    -> Byte count

       BYTE >E5    -> Fill sector value
       BYTE >80    -> Byte count

       BYTE >F7    -> CRC (Cyclic Redundancy check)
       BYTE >01    -> Byte count

       BYTE >FF    -> After sector Gap
       BYTE >24    -> After sector byte count

       BYTE >02    -> Software TOKEN : Update Sector Number

       DATA >0007  -> Interlace factor
       DATA >FFFF  -> Used only when last Sector in Track
       DATA DKU    -> Loop back once more

* VDP WRITE: same byte, count in R7

CW     MOVB R0,@>8C00
       DEC  R7
       JNE  CW
CO     B    *R11

===========================================
* The below table is an excerpt from the MDOS650source.zip, 1,130 KB,
* File L8.ARK, File FORMAT-P.3, lines 47 - 68. If you pay attention,
* it's basically the same * FORMATTING VALUE TABLE used above, the only
* difference being the value used for the sector filler byte in Double
* Density (>D7 instead of >E5).

* TRACK HEADER FOR DOUBLE DENSITY
*
DDHED  DATA 18           18 SECTORS / TRACK
       BYTE >4E,32
*
* SECTOR LAYOUT FOR DOUBLE DENSITY
*
D12    EQU  $
DDTBL  BYTE 0,12,>F5,3,01,>4E,22,0,12,>F5,3,>FB,1
       BYTE >D7,128,>D7,128,>F7,1,>4E,20
RESCM2
H02    BYTE >02
       DATA 11,>4E4E,DDTBL
*
* TRACK HEADER FOR SINGLE DENSITY
*
SDHED  DATA 9            9  SECTORS / TRACK
       BYTE >FF,40
*
* SECTOR LAYOUT FOR SINGLE DENSITY
*
SDTBL  BYTE 0,6,01,>FF,11,0,6,>FB,1
       BYTE >E5,128,>E5,128,>F7,1,>FF,36
       BYTE 2
       DATA 7,>FFFF,SDTBL
*
JUNK2  BYTE DPAG4,0
*

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Thu, 3 Dec 2009 21:40:30 +0100

Hi Michael,

I found the layout for Single Density used by TI FDC. Guess where is it? 
At our Thierry Nouspikel site, where else? That man is just incredible!

http://nouspikel.group.shef.ac.uk//ti99/disks.htm#write%20track

You can see that the first bytes are the same used by Myarc in their FDC 
and in Geneve code, from MDOS 0.97 up to MDOS 6.5.

In all cases, no > 7f 3f 00 cf e0 7f 3f 01 01

Paolo

---

From: "Tursi" <[email-masked]>
Date: Thu, 3 Dec 2009 15:51:32 -0500

> the basement of my summer house, 380 km away), so I cannot give you proofs

Thierry has the disassembly commented on his website 
(http://nouspikel.group.shef.ac.uk//ti99/download.htm#disass) - that may 
help.

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Thu, 3 Dec 2009 22:23:52 +0100

Thanks Tursi!

http://nouspikel.group.shef.ac.uk//ti99/download.htm#disass

Filename: dc2.txt, lines 293 and following. See below

It's quite clear, no strange stuff to start formatting a track:
"LI   6,>0016           write 24 sync bytes >00".

Paolo

==================================================================

A43AA  MOV  11,8              format a track
       MOV  @>004E(9),2       --------------
       BL   @A4614            set VDP to write to data buffer
       LI   6,>0016           write 24 sync bytes >00
       CLR  2                 sector counter
       JMP  A43C0
A43BC  LI   6,>0006           write 6 sync bytes >00
A43C0  MOVB @A4630,@>FFFE(15)
       DEC  6
       JNE  A43C0
       MOVB @A4639,@>FFFE(15) write >FE (will be ID mark)
       NOP
       MOVB 3,@>FFFE(15)      write track #
       NOP
       MOVB 7,@>FFFE(15)      write side #
       MOVB 3,0               track number

---

From: "Michael Zapf" <[email-masked]>
Date: Fri, 04 Dec 2009 00:32:38 -0000

Hello Paolo,

I should have looked earlier here, since I already started to disassemble the code. Manually. 

So, it's getting even more mysterious: Remember, the bytes that I got from the eavesdropping are

00*16

00 00 00 00 00 00
fe
00 00 00
01
f7
ff*11
00 00 00 00 00 00
fb
e5*256
f7
ff*45
...

and at the track end

ff*223 

But here's another deviation: The code says 0xe7 bytes, that is, 231. Where are the missing 8 bytes? 

I begin to understand ... the whole buffer is shifted. That is, the reading from VDP begins too early, and stops too early (after the number of bytes were written). I cannot see the bytes 7f...01 either, but they are there, that's doubtless. They may have been written there some time before.

As I said, it actually cannot be an artifact of MESS since MESS has simply no idea what's happening within the emulation. What I can clearly see is that the values 7f ... 01 are retrieved from VDP RAM by the execution of MOVB @>FBFE(15),0 within the loop near address 4440. So they were not written by the DSR, but who wrote them? When?

Interestingly, to me this all seems as if the VDP address is not set correctly before starting to read the track template from VDP RAM. Could that be a bug in MESS? Judging from the lots of VDP accesses which are working correctly, that's less than likely. 

Turn it around: Who can *prove* that this shift does not happen with the real disk? This can only be verified when we do a read_track command on the real TI disk controller (other controllers do not count, of course, since they may differ in their DSRs). And I can imagine that even when there was a bug in the TI FDC controller, no one will notice due to the technique of locating sector content on the disk. The controller tries to find the gap and will skip those bytes simply.

There are actually some peculiarities in the code of the FDC (note Thierry's comment "why on earth is it done like that???"). Well, that's a real mystery for the week-end.

Michael

---

From: "Michael Zapf" <[email-masked]>
Date: Fri, 04 Dec 2009 12:05:23 -0000

Hmmm ... by the way, WHAT IS THAT?

(-> look at Thierry's disassembly, dc2.txt)

43AA... MOV  11,8              format a track
....... MOV  @>004E(9),2       --------------
....... BL   @>4614            set VDP to write to data buffer
....... LI   6,>0016           write 24 sync bytes >00

(R9 is >8300)

Later, when writing the buffer from VDP to disk:

442C... MOVB @>004E(9),2       top of data buffer
....... BL   @>461E            set VDP to read from it

WTF? Why MOVB?? And it's NOT a typo from Thierry. Here is the ROM dump of the TI controller:

0004420: 16cd 06a0 4474 00e7 0204 0003 d0a9 004e  ....Dt.........N
0004430: 06a0 461e 06a0 45ca 0b00 0206 0ca3 1d02  ..F...E.........

I'll check that more closely later today.

I think I'll vote for Bug in TI DSR.

Michael

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Fri, 4 Dec 2009 14:28:06 +0100

Very nice, Michael!
I think you got it.

R2 is zero when the MOVB @>004E(9),2 (instead of a MOV @>004E(9),2) takes 
place, because the BL @A4474 (above) doesn't use R2 and R2 is already zero 
there (JNE A43BC).

If >834E in your code (VDP Buffer Start) contains xx09, then this would 
perfectly explain the extra 9 bytes at the start of the track. The VDP 
buffer start gets wrongly moved 9 bytes backwards.

Please check that and we will be through with this baby.

Paolo

---

From: tursi <[email-masked]>
Date: Fri, 4 Dec 2009 05:31:16 -0800 (PST)

Nice work, Michael! I love seeing this sorta thing.

There's something awesome about pinning down bugs nearly 30 years after 
they were written! :)

---

From: mark wills <[email-masked]>
Date: Fri, 4 Dec 2009 05:47:41 -0800 (PST)

Yeah that's some pretty awesome work Michael!

Mark

>
>From: tursi <[email-masked]>
>Sent: Fri, 4 December, 2009 14:31:16
>>> From: "Michael Zapf" <newsmail09@mizapf. de>
>>>> 0004420: 16cd 06a0 4474 00e7 0204 0003 d0a9 004e  ....Dt...... ...N
>>>> 0004430: 06a0 461e 06a0 45ca 0b00 0206 0ca3 1d02  ..F...E..... ....

---

From: fdos <[email-masked]>
Date: Fri, 04 Dec 2009 09:39:36 -0700

I love a mystery, and this has certainly proved to be one for the 
decades.  Awesome detective work Michael.

Bill S

tursi wrote:
>  > From: "Michael Zapf" <[email-masked] 
> <mailto:newsmail09%40mizapf.de>>

---

From: "computerclassics2000" <[email-masked]>
Date: Fri, 04 Dec 2009 19:22:23 -0000

How very cool it is that we still have the talent in the community 30 years later that can 'see and understand' that sort of thing. Thanks, Michael!!!

--- In [email-masked], mark wills <markrobertwills@...> wrote:
> >From: tursi <yahoogroup@...>

---

From: "Michael Zapf" <[email-masked]>
Date: Fri, 04 Dec 2009 20:39:16 -0000

> How very cool it is that we still have the talent in the community 30 years later that can 'see and understand' that sort of thing. Thanks, Michael!!!

Thanks, no need to get enthusiastic. :-)

Indeed, I always enjoyed that kind of "code adventure". By the way, it's almost as far in the past where I started with those things. 

I wrote my first real assembler program, a prime number finder, back in 1984 ... when I was 14 years old. I never felt this as extraordinary in any way. My frieds also had computers, some of them also tried programming, but it seemed to be me who was most active. 

When I look at youngsters today - especially my nephews - I tend to believe that we (my generation, today of age around 40) were really lucky in those times. Really. We encountered this exciting technology in its first steps into the private houses, still with fields of programming wide open, just at an age where you could easily afford to invest some time in it. And it was top technology. No mobile phones around with "apps" on them. No CDs or even DVDs. No TV program in the afternoon :-). The next complicated thing at home was a video tape recorder.

So you could even be proud of writing a simple but basically useless tool like a prime number finder. I remember I also wrote small training programs in Basic for my Latin courses in school.

Today ... how discouraging is it to get games and other applications for less than $10 which had a big staff of programmers behind, developing on this for months? Can you still find motivation to start programming? I don't know whether I would have found such an easy entry into computing today as in those times in the eighties.

But one should not take that too seriously. The past was always better, and will always be. That's the way our mind is working.

Michael

---

From: "Michael Zapf" <[email-masked]>
Date: Fri, 04 Dec 2009 20:45:47 -0000

Like to see a proof now? :-)

I used a hex editor and changed the opcode from D0A9 to C0A9 in disk.bin and created a new ti99_4ae.zip.

Here is the MESS output now (arranged):

c=f4
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 fe 00 00 00 01 f7 ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 00 00 fb e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 f7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
...
end of track:

00 00 00 00 00 00 fe 02 00 05 01 f7 ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 00 00 fb e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 f7 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff

ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff

Michael

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Fri, 4 Dec 2009 22:43:39 +0100

Yep, that's it.
Kudos to you, Michael!!!

Ok, from now on all the programs that format a TI disk *should* set the 
Least Significat Byte of the VDP buffer address at >00, lest the user has 
a TI FDC.
Example: >1100, or >1300, and so on.

In this way the disk will be perfect, even with our buggy TI FDC.

The worst case scenario is when the VDP buffer is set to 1 below a *round* 
address, i.e. >10FF. In this case the sector starts 255 bytes after what 
it should. The disk will probably still function, but if you're really 
unlucky it won't.

I had fun, thank you all.

Paolo

----- Original Message ----- 
From: "Michael Zapf"
To: <[email-masked]>
Sent: Friday, December 04, 2009 9:45 PM
Subject: [TI994A] Re: PC99 format

> 00 00 00 00 00 00 fe 00 00 00 01 f7 ff ff ff ff ff ff ff ff ff ff ff 00 
> 00 00 00 00 00 fb e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 f7 ff 
> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ...
> end of track:
>
> 00 00 00 00 00 00 fe 02 00 05 01 f7 ff ff ff ff ff ff ff ff ff ff ff 00 
> 00 00 00 00 00 fb e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 
> e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 f7

---

From: "Michael Zapf" <[email-masked]>
Date: Fri, 04 Dec 2009 23:42:36 -0000

Hello Paolo,

> it should. The disk will probably still function, but if you're really 

the interesting question for me is now: If I still plan to implement a track handling in MESS, I must be prepared for the TI FDC to produce non-standard formats.

If we assumed that FM formats *must* start with 00*24, we would simply fail with the TI FDC. For one part, *real* track dumps (created by a read_track) would show these false headers. OK, we could fix them by a converter. Or I could create a format in MESS that fixes these deviations on-the-fly. 

But this does not help in the case that we format a new disk. It would be ugly to try to fix this byte stream within the format implementation.

Another way would be to fix the controller (as I did) and to circulate the new version. That's not good either, since it will take years until all MESS users would finally get the fixed ROM. And, strictly speaking, it would not emulate the *real* machine anymore.

So why did we not notice this bug? Because the sector retrieval routine does not care about those bytes at the track start. It just tries to find the address marks, and when found, delivers the sector content. That's also the proper way to emulate it. 

But as I said, at first I'll get the PC99 format going again. BTW, after all this stories, the PC99 format does not deserve the naming "track dump" anymore, as I once suggested - as it is not a proper track dump. As it seems, "PC99 format" is OK after all, as it shows peculiarities inherited from the PC99 emulator.

Another lesson from this episode: Emulation is not just fun, it is a valuable tool - particularly for development.

Michael

---

From: Insane Multitasker <[email-masked]>
Date: Sat, 5 Dec 2009 23:39:20 -0600

Hi Michael, I'll give that a shot.   A thought occurred to me -- have you considered giving MESS the ability to mount physical media?  For example, could MESS mount a EZ135 platter natively or through Omniflop code, access a diskette directly?  
 
> Date: Thu, 3 Dec 2009 10:13:47 +0000
> Subject: [TI994A] Re: Disk Formats - ninerpedia
> 
> 
> 
> Hello Tim, 
> 
> 
 		 	   		  
_________________________________________________________________
Windows Live Hotmail gives you a free,exclusive  gift.
http://www.microsoft.com/windows/windowslive/hotmail_bl1/hotmail_bl1.aspx?ocid=PID23879::T:WLMTAGL:ON:WL:en-ww:WM_IMHM_7:092009

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Sun, 6 Dec 2009 14:01:46 +0100

Hi Michael,

> If we assumed that FM formats *must* start with 00*24, we would simply 
> fail with the TI FDC.
> For one part, *real* track dumps (created by a read_track) would show 
> these false headers.
> OK, we could fix them by a converter. Or I could create a format in MESS 
> that fixes these deviations on-the-fly.

There is an inherent problem with emulating a floppy track read. While the 
emulator will always give you the same image, which is quite obvious, a 
real operation (track read) on a real floppy won't. I have already 
experienced that. Depending on the hardware and maybe on the floppy 
itself, you will get different results while repeating the same read track 
operation on the same disk.  I don't know why this happens, but it does. 
Especially the leading bits of the track may change. In my opinion, 
reading a track is not a trustworthy operation.

As a side note, this is why I've always found it strange that people 
recommend track copy just to overcome a possible disk protection. It's not 
that simple.

Back to the point. So, while reading sectors is dependable, reading tracks 
is not and, more important, the results will vary. Now, how do you choose 
a fixed format for something that does intrinsically vary?

The only possible approach to this riddle is to have an 'open' format, 
i.e. a format that sets only some parts as fixed (and needed), while 
leaving the rest of the format open and free.  More precisely, a format 
that doesn't care what or how many bytes there are at the beginning of the 
track, but starts counting and checking only when a special byte arrives: 
for instance, the >FE byte, that is the 'ID Address Mark'. At this point 
the emulator switches to an 'acquiring data mode', where all the bytes 
from the emulated disk are taken as good and reliable.  After the data 
sector is finished, the emulator should switch to 'waiting mode', just 
waiting for the next sector (i.e. the next >FE byte) to come up, at which 
point it should switch to 'acquiring data mode' again, getting the next 
sector. Although slow, this method would quite effectively emulate what 
happens on a real disk.

There is a problem, though. What if among the unwanted leading bytes there 
is an unexpected >FE byte? On a real floppy, and while reading sectors 
(Type II Command) that does not pose a problem, because the >FE that 
markes the 'ID Address Mark' has a modified clock pattern (CLK = C7), so 
the FDC would simply ignore any >FE byte that has a normal clock. On a 
Type III Command, Read Track, the clock patterns with missing bits are 
ignored, and all the track will be read no matter what.

But that leaves you a problem. How can you understand if an >FE byte from 
the read track is a true 'ID Address Mark', or just a meaningles byte that 
just happens to be >FE, but does not serve as a marking byte? How do you 
go about building a track image file for this kind of track?

Obviously, you have to find a way of getting rid your track image file of 
all these fake marking bytes. Ok, but how? A method could be by deeply 
analizing the track. For instance, by seeing if there is an >FB byte 
('Data Address Mark') 24 bytes after the first >FE byte: this would kind 
of reassure us that the first >FE byte was a real 'ID Address Mark'.

Will all that be enough to avoid false identifications? I don't really 
know, but it is unfortunate that  you'll have to resort to these awkward, 
and sometimes unreliable, sort of things. Surely a pesky problem. But you 
have to solve this problem if you are to implement an effective track 
reading on MESS.

Besides, there isn't any TI software around that already creates a TI 
track image file, (except for TI Advanced Diagnostics, which does not work 
with all the FDCs around, though). So, you will have to write yourself a 
software for that.

As for the PC platform, my old TI99_PC.com could be modified to do track 
reading. Yes, I think it could be done. But not by me. Maybe I will have 
to release the MASM 6.11 source code for that, because I am a too rusty 
programmer with MASM environment to do anything valuable myself right now.

OmniFlop does not do any 'track reading' and, quite honestly, I don't know 
whether that could be done with the limited access to the hardware that 
Windows XP/Vista/7 suffers of. Jason Watton might be able to do it, but 
he's not likely to jump at the idea. He's already written that what you 
can do with OmniDisk (the OmniFlop version for DOS/Windows 95/98/Me) 
cannot be done with OmniFlop. This means to me that convincing Windows 
XP/Vista/7 to do what you want is not an easy task, even when you're 
writing a device driver yourself.

All the above is why I think that supporting a "true" TI track image file 
on an emulator is going to be a challenging task, to say the least.

Good luck.

Paolo

---

From: "Michael Zapf" <[email-masked]>
Date: Sun, 06 Dec 2009 16:39:07 -0000

Hello Paolo,

that's one of the most interesting contributions here ... thanks a lot! I guess we have to preserve almost all of this in ninerpedia in a suitable format.

So this clears up the final part, I suppose. What I could not make sense of from the WD17xx manual was the CLK values. A quick look at Wikipedia in FM and MFM articles gives interesting information. I was also wondering about how the address marks will be found once they are written, but I thought of some heuristic at first. I believed this "CLK=C7" could mean some timing but postponed the research on that. 

Actually, this is relevant for FM encoding. There is a clock pulse on the signal, like 00 11 00 11 00 11 ... and the payload data are put on it, with 0 showing no change, 1 showing a transition 1-0 or 0-1. That is, if you encode 010010 (payload) you get 00 10 00 11 01 11. And now this makes sense: The IDAM (ID Address Mark) is FE with a clock pattern of C7, while a data item FE has a clock pattern of FF (this again modulated with the 010101... base signal).

And so this "Address Mark Detector" also makes sense in the schematic - I always asked myself what could be special about "detecting" an FE, FC, or FB...

OK, now that means the following: While reading from a track, we get the raw bytes, but we lose the clock signal. Therefore, the byte sequence does *not* precisely map the physical contents of the disk track. The details of FM/MFM are not visible to the systems using the WD17xx which means that some essential details will always be lost.

Two solutions to this: 

1. Every track needs an additional array of flags for each byte in the track, defining the underlying clock signal pattern per byte. That would require us to reconstruct the clock signal. This would be more close to the real situation, but ... marginally helpful. Is it really interesting to emulate flux transitions on a magnetic medium? Not really.

or

2. We emulate tracks on a slightly abstract level, just like PC99 does. This is a kind of "standardized" track image.

One could say, certainly, why care about that anyway and not just stay with sector dumps? Well, one advantage of this is that we have some influence on the track layout. And we can read the PC99 dumps. And that should be enough.

Michael

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Mon, 7 Dec 2009 21:43:07 +0100

Hi Michael,

> OK, now that means the following: While reading from a track, we get the 
> raw bytes,
> but we lose the clock signal. Therefore, the byte sequence does *not* 
> precisely
> map the physical contents of the disk track. The details of FM/MFM are 
> not visible
> to the systems using the WD17xx which means that some essential details 
> will always
> be lost.

Yes, the WD17xx gets the full info (Data + Clock). We (the system) get/s 
only the data. The clock is lost.

> 1. Every track needs an additional array of flags for each byte in the 
> track,
> defining the underlying clock signal pattern per byte. That would 
> require us
> to reconstruct the clock signal. This would be more close to the real 
> situation,
> but ... marginally helpful. Is it really interesting to emulate flux 
> transitions
> on a magnetic medium? Not really.

Agreed. We would have no useful purpose for that.

> 2. We emulate tracks on a slightly abstract level, just like PC99 does. 
> This is a
> kind of "standardized" track image.

I concur. PC99 support is definitely needed in any TI emulator. On the 
other hand, I surely prefer V9T9 over PC99 format. I still don't 
understand what we gain by adding all that inter- sector information that 
PC99 disk format has. There is no active CRC in PC99, we only have 
additional info about sector length, side, track and sector #. Anadisk has 
a nice disk sector dump: there is a header for each sector that tells you 
exactly what you need, and nothing more: sector length, side, track and 
sector #. That's it. I like that format a lot, although I could never 
really use it, because I needed compatibility with existing formats.

While I see the use of having a PC99 compatibility, I would by far have 
V9T9 as a default format.

How are you going to support the PC99 interleave? Would you assume is a 
fixed one (so you would have no need to scan every track to get the right 
sector), or would you follow my approach, scanning each sector in a track 
until you get to the one that matches the sector you want?

I had to resort to the second method lest PC99 changed interleave. 
However, this method slows down things, and that's why I never liked PC99 
format.

As a final note, my '*.img' format of TI99-PC is not a fixed one. It can 
have two possible lengths. The real one, i.e. the same as V9T9, or the 
real one plus >300 bytes. It all depends on if there are bad sectors or 
not. It works in the following way: if the disk image obtained by reading 
a real floppy has no read sector error, then the image is exactly the same 
as a V9T9 disk image file. Otherwise, an error table of >300 bytes will be 
added to the end of the file, containing a bit map of all the bad sectors. 
There is a small header at the beginning of the error table, reporting in 
plain ASCII the bad sector count. The error table, is AU=1, i.e. each bit 
in the bitmap represents just one bad sector, no matter how big the disk 
is (and this is why the table is longer than >100 bytes).

Paolo

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Tue, 8 Dec 2009 14:35:43 +0100

Hi Michael,

There is still something I would like to clarify.

In a previous message, you wrote:

> There are actually some peculiarities in the code of the FDC (note 
> Thierry's comment
> "why on earth is it done like that???"). Well, that's a real mystery for 
> the week-end.

The following is the portion of the TI FDC DSR you were referring to, as 
from Thierry's site (file: dc2.txt):

A4440  MOVB @>FBFE(15),0      read one byte from buffer
       INV  0                 FDC has an inverted data bus
       MOVB 0,@>5FFE          send it to data register
       MOVB @>FBFE(15),0      why on earth is it done like that???
       INV  0
       MOVB 0,@>5FFE          send next byte
       DECT 6
       JGT  A4440             next pair of bytes

I think Thierry was simply commenting out the two consecutive VDP access 
(MOVB @>FBFE(15),0). The code might have been:

A4440  MOVB @>FBFE(15),0      read one byte from buffer
       INV  0                 FDC has an inverted data bus
       MOVB 0,@>5FFE          send it to data register
       DEC 6
       JGT  A4440             next byte

just a DEC instead of a DECT ad one VDP access instead of two. However, 
the second coding takes more time to be executed. I suppose the original 
TI code simply reflects the WD17xx timing needs. At this moment there is a 
disk spinning, the drive head is writing formatting data to the magnetic 
medium and there is nothing that tells the code when to wait (no TB, Test 
Bit) or, more important, when to speed up.

In fact, VDP access is slow, as we all know. Still, the code has to be 
synchronized, to avoid a buffer underrun or overrun on the magnetic 
medium. In the WD1770 pdf, page 15, in the flow chart: HAS DR BEEN LOADED? 
NO -> WRITE BYTE OF ZEROES - SET DATA LOST. Here DR is the WD 1770 Data 
Register, which in our TI FDC is placed at >5FFE. Data Lost is flagged out 
as "S2 LOST DATA/BYTE", by the WD1770 Status Register, placed at >5FF0 in 
the TI FDC (ibid., page 18). Probably, the TI coder saw that the best 
results were obtained with a double VDP access before the DECT R6.

I am just guessing here, Urbite (of Parsec fame, greatest TI game 
ever!!!), who is simply amazing at syncing TI code, could explain much 
better than me why the code was written this way by TI.

A second topic.

Michael, what formatter were you using when you found out the 9 extra 
bytes at the beginning of a track formatted with the TI FDC?

Maybe I am not the only one who wants to know. If we know, we can steer 
clear of that software.

Thanks,

Paolo

---

From: "morpheusinindy" <[email-masked]>
Date: Tue, 08 Dec 2009 13:48:12 -0000

Hi, 

   A couple of interjections in to this highly technical conversation, from which I am learning a lot...
   As a user of MESS (not a MESS programmer) – my concern is, what level of emulation will be provided by the various designs. Will Copy-C work? Will TrackHack? What about the Myarc disk Manager that lets you select the number of tracks and interlace? What about RapidCopy that does a lot of direct hardware access bypassing the DSR?

    Obviously, you can't have everything in life, but it is comforting to know what should work by design and what doesn't.

   Michael, kudos to you for all the work you have put in to MESS. I have wondered for a long time, why MESS and other emulators hadn't went to a sqllite format for distributing cartridges? All in one place, built in data integrity with plenty of crc/hash checks. One time additions or deletions. I think all of us can think of many occurrences where a program did or didn't run – a md5sum would be created of both dumps – and found that it didn't work because it was corrupt, or it did work, because a couple of bytes had been tweaked to make it work with a Geneve or a 9938 or 58 device. This type of engineering or vetting would only need to be done once. 

Thanks for the hard work that you have put in to MESS, the bug you discovered in the TI DSR ROM and the eduction of reading your emails.

Dan

---

From: "Michael Zapf" <[email-masked]>
Date: Wed, 09 Dec 2009 00:35:09 -0000

Hello Paolo,

> I think Thierry was simply commenting out the two consecutive VDP access 

yep, I know. I also wondered about this code here. And, by the way, it has the supposedly unwanted effect that it always writes an even number of bytes, although the track image length is an odd number. This added another >FF (or >00) at the end.

> Probably, the TI coder saw that the best 

(Paul Urbanus, I suppose. Urbites were the ones to fire at.)

Could be. That's some kind of programming that I hope to avoid as far as possible. Timing by instructions ... yuck.

BTW, the MESS emulation also cares for the timing delays by using timers with callbacks. Took me some hours to get through it (virtually undocumented stuff). This is currently only done correctly for the TI FDC, not for the HFDC; thus, disks load as quickly as harddrives with the HFDC. I'm going to fix that to get to realistic times. And finally I'd love to hear the head stepping, as can be heard in the UAE (Amiga emulator).

> Maybe I am not the only one who wants to know. If we know, we can steer 

That was Disk Manager 2, but the bug is in the DSR of the Disk controller. So either you can avoid the original TI FDC, or you must use a formatter with an own format procedure. I guess the original TI FDC is only rarely used today, with its lack of DD support.

Anyway, this bug is obviously not critical (otherwise it may have been found early); it has no practical effect, I'm sure. These bytes at the beginning will certainly be skipped while the controller waits for the data address marks of the sectors. 

As I said ... it could be interesting for future hardware projects to be tested on the emulation at first, provided that someone creates an emulation for the hardware. That's not too difficult, as soon as one has understood the architecture of MESS. The problem is that the whole project is in dire need of a documentation update. 

Michael

---

From: Insane Multitasker <[email-masked]>
Date: Tue, 8 Dec 2009 18:55:36 -0600

Michael, 

If you change the HFDC code to support realistic times, could you please make it optional?  I rely upon the speed boost, as I suspect many others might, to make the emulation more enjoyable and usable.  In fact, I would hope you do not slow down the hard disk access at the same time.   Simulating disk speeds would be a step back for little gain, IMHO.  

Tim

>This is currently only done correctly for the TI FDC, not for the HFDC; thus, disks load as >quickly as harddrives with the HFDC. I'm going to fix that to get to realistic times. And >finally I'd love to hear the head stepping, as can be heard in the UAE (Amiga emulator).

---

From: Tony Knerr <[email-masked]>
Date: Tue, 08 Dec 2009 20:00:00 -0500

The motion is seconded.

Tony

Insane Multitasker wrote:
>  
>
> Michael,
>  
> If you change the HFDC code to support realistic times, could you 
> please make it optional?  I rely upon the speed boost, as I suspect 
> many others might, to make the emulation more enjoyable and usable.  
> In fact, I would hope you do not slow down the hard disk access at the 
> same time.   Simulating disk speeds would be a step back for little 
> gain, IMHO.  
>  
> Tim
>
> >This is currently only done correctly for the TI FDC, not for the 
> HFDC; thus, disks load as >quickly as harddrives with the HFDC. I'm 
> going to fix that to get to realistic times. And >finally I'd love to 
> hear the head stepping, as can be heard in the UAE (Amiga emulator).
>  
>

---

From: ti99_forever <[email-masked]>
Date: Tue, 8 Dec 2009 17:35:39 -0800 (PST)

On that topic, why can't I find a way to speed Win994A up? It *always* runs at realistic speeds...

--- On Tue, 12/8/09, Tony Knerr <[email-masked]> wrote:

From: Tony Knerr <[email-masked]>
Subject: Re: [TI994A] Re: TI FDC DSR bug (was PC99 format)
To: [email-masked]
Date: Tuesday, December 8, 2009, 8:00 PM

  

The motion is seconded.

Tony

  
  Michael, 

If you change the HFDC code to support realistic times, could you
please make it optional?  I rely upon the speed boost, as I suspect
many others might, to make the emulation more enjoyable and usable.  In
fact, I would hope you do not slow down the hard disk access at the
same time.   Simulating disk speeds would be a step back for little
gain, IMHO.  

Tim

HFDC; thus, disks load as >quickly as harddrives with the HFDC. I'm
going to fix that to get to realistic times. And >finally I'd love
to hear the head stepping, as can be heard in the UAE (Amiga emulator).

---

From: fdos <[email-masked]>
Date: Tue, 08 Dec 2009 19:00:47 -0700

Tim, Tony & Me too.  I mainly use MESS as a development environment, so 
I need compile and assembly times to be as fast as possible.  Real 
hardware is real hardware, emulators are not.  No amount of realism or 
my imagination will make me believe otherwise.

Bill S

---

From: mark wills <[email-masked]>
Date: Tue, 8 Dec 2009 19:57:01 -0800 (PST)

Well, Win994A is described as a simulator, so it is designed to run at realistic speeds.

However, Cory broke that rule when he added the extra instructions to the 9900 virtual processor to support stacks and other stuff. He added some really lovely instructions, which are only supported in WinASM994A

I'd like to see 80 column (or rather 9938/58) support in our emulators. The only one that does it at the moment (AFAIK) is TI994W.

Mark

>
>From: ti99_forever <[email-masked]>
>Sent: Wed, 9 December, 2009 2:35:39
>--- On Tue, 12/8/09, Tony Knerr <tonyknerr@comcast. net> wrote:
>
>
>>From: Tony Knerr <tonyknerr@comcast. net>
>>To: TI994A@yahoogroups. com

---

From: "Tursi" <[email-masked]>
Date: Tue, 8 Dec 2009 23:20:59 -0500

> I'd like to see 80 column (or rather 9938/58) support in our emulators. 
> The only one that does it at the moment (AFAIK) is TI994W.
>

I did find the 9938 core that was in Classic99 ten years ago.. it's on my 
list to reimplement it. :)

---

From: "Michael Zapf" <[email-masked]>
Date: Wed, 09 Dec 2009 12:01:33 -0000

Hello Tim (and others),

> If you change the HFDC code to support realistic times, could you please make it optional?  I rely upon the speed boost, as I suspect many others might, to make the emulation more enjoyable and usa…

The way the HFDC is currently emulated is simply not correct, as the real operation is in some part event-driven, raising signal lines when data is present and so on. It may well be that stability is sacrificed when neglecting real processing times. There are some systems (outside the TI family) which simply did not work with the wd17xx emulation due to missing delays.

It is interesting to see in what ways emulations are perceived and used, and I know that there are different feelings about that. My understanding of emulation (which is in line with the MESS project policy) is that the emulation should strive for a maximum of realism compared to the real hardware. An emulation is not intended to make the original better. Thus, *any* bit of added realism is a gain, even if that means a decrease in comfort. I'm sorry if that sounds disappointing to some of you, I can't do more than trying to make clear the rationale of MESS and of emulations in general.

As the smc92x4 is only used in the TI/Geneve computer emulation we may have some chances to build in some options like "realistic timing" vs. "fast", but I would not be surprised if I get into some arguments with the other maintainers. For the wd17xx (original TI controller) this is out of my reach; it would at first require a common agreement in the MESS developer community to introduce tunable delays. I know that other emulators offer such a feature, like the UAE.

I suggest that we just wait and see how this will affect the usability. Comparing current boot times with the Geneve emulation I would not expect that the floppy will slow down too strongly. Anyway, now with the easy conversion of SCSI drives to HFDC and back, I'd prefer to work with the hard drive instead of with the floppy anyway.

Michael

---

From: fdos <[email-masked]>
Date: Wed, 09 Dec 2009 08:21:49 -0700

Mark,

MESS absolutely supports V9938 emulation, so 80 columns, as that is what 
I use in both the TI and Geneve MESS emulators along with Myarc HFDC 
hard drive images up to 248MB x 3 and 4 floppy drives.  All the drive 
images (V9T9 floppy disk and CHD/HD hard drive) are shared (except 
1.44MB floppy images are Geneve only).

Bill S

mark wills wrote:
> However, Cory broke that rule when he added the extra instructions to 
> the 9900 virtual processor to support stacks and other stuff. He added 
> some really lovely instructions, which are only supported in WinASM994A
> 
>     *From:* ti99_forever <[email-masked]>
>     *To:* [email-masked]
>     *Sent:* Wed, 9 December, 2009 2:35:39
>     *Subject:* Re: [TI994A] Re: TI FDC DSR bug (was PC99 format)
> 
>      
> 
>     --- On *Tue, 12/8/09, Tony Knerr /<tonyknerr@comcast. net>/* wrote:
> 
> 
>>         If you change the HFDC code to support realistic times, could
>>         you please make it optional?  I rely upon the speed boost, as
>>         I suspect many others might, to make the emulation more
>>         enjoyable and usable.  In fact, I would hope you do not slow
>>         down the hard disk access at the same time.   Simulating disk
>>         speeds would be a step back for little gain, IMHO.  
>>          
>>         Tim
>>
>>         >This is currently only done correctly for the TI FDC, not for
>>         the HFDC; thus, disks load as >quickly as harddrives with the
>>         HFDC. I'm going to fix that to get to realistic times. And
>>         >finally I'd love to hear the head stepping, as can be heard
>>         in the UAE (Amiga emulator).
>>          
>>
> 
> 
> 
> 
>

---

From: Insane Multitasker <[email-masked]>
Date: Wed, 9 Dec 2009 18:51:19 -0600

Hi Michael, you raise some good points. Please allow me to respond in kind.

Concerning stability, I often run the emulator at max speed during compilation times, which provides a 9-10x speed increase over the real hardware.  I have not noticed any issues doing so, either from a corruption or timing perspective.  This does not mean there is not already, or never will be, a stability issue, thus I can appreciate the desire to dig further. 

Concerning maximum realism, I suppose this comes down to interpretation.  There are critical components which must be recreated to ensure realism, such as video, keyboard, memory timings, etc.  Why after all this time must the disk subsystem be changed?  To me disk load variations are not critical nor do they detract from realism.   To whom would slowing the disk system be a gain, those writing the MESS vision statement?  

Now, before you think I have been outside in the sub-zero weather too long, I do not begrudge the pursuit of realism. Yet I would be remiss if I did not argue for the side benefits emulation offers. Over the years I do not recall hearing anyone complaining that MESS did a poor job of realistically emulating the Geneve. Quite the contrary!

The "unrealism" which you propose to fix is part of a great development environment.  For those of us with real hardware, MESS becomes another tool; for those without, the emulation is as viable as the real hardware. 

So I will "wait and see" as you suggest. I simply wanted to raise awareness as your comments were unsettling. To me this is less a comfort issue than a very real potential use impact to Geneve emulation and its users.  And if it turns out to be a non-issue, you can say "I told you so".  :)

I look forward to your continued support and effort.

Tim

PS - Concerning hard disks versus floppy disks, I prefer to use floppy emulation for most development work.  I do so for three reasons:  (1) portability to the real hardware, (2) separation of files, (3) ability to quickly back up my work in disk-size increments. 
 
> Date: Wed, 9 Dec 2009 12:01:33 +0000
> Subject: [TI994A] Re: TI FDC DSR bug (was PC99 format)
> 
> Hello Tim (and others),
>

---

From: ti99_forever <[email-masked]>
Date: Wed, 9 Dec 2009 16:57:16 -0800 (PST)

You forgot #4. Floppies are more reliable than hard drives, emulation or otherwise. Being small, separate containers, when you wipe the directory structure of one, you only affect the files on that particular container, and not potentially everything you've got in one big screw-up...

--- On Wed, 12/9/09, Insane Multitasker <[email-masked]> wrote:

---

From: "jhwhite_delphi" <[email-masked]>
Date: Thu, 10 Dec 2009 01:50:46 -0000

Just a few things the MESS developers should consider for added realism of the 99/4A and Geneve emulations:

(1) Failure of the 9901.
(2) RF Modulator emulation with the common failure modes and crappy video (missing characters at the edges). 
(3) Failure of the flyback transformer of the monitor.
(4) Loss of colorburst, random failures of RAM chips, over-run of VDP.
(5) Disk head crashes (floppy and hard disks) unrecoverable.
(6) Cold-solder joints.
(7) Dried-out or leaking capacitors.
(8) Dirty cartridge port.
(9) Loss of buffering chips on the peripheral cards.
(10) Upgrading the video output by changing the RC circuit.
(11) Sticking of the keys, wearing of the joystick, ALPHA lock issues and fix.
(12) Electrocuting the user or burning the house down if the transformer is defective/does not have the pigtail fix. 
etc.

These are just a few of the things that would make the emulations more realistic.

Jeff White
[email-masked]

---

From: "Michael Zapf" <[email-masked]>
Date: Thu, 10 Dec 2009 09:23:31 -0000

...
> These are just a few of the things that would make the emulations more realistic.

You are thinking too negative, did you already know? :-)

But I can answer to that ... if those issues were part of a specification, yes, then we should implement them. But I just cannot remember reading that a capacitor is designed to fail.

I said *not better* that the original. I did not say *worse*. 

Michael

---

From: "Michael Zapf" <[email-masked]>
Date: Thu, 10 Dec 2009 09:28:52 -0000

> You forgot #4. Floppies are more reliable than hard drives, emulation or otherwise. Being small, separate containers, when you wipe the directory structure of one, you only affect the files on that…

I think you never had such an easy way of doing backups than now with an emulator. Besides, I've been working with hard drives on the Geneve for many years and never had any kind of major file system damage, but I just may have been lucky.

Michael

---

From: "Michael Zapf" <[email-masked]>
Date: Thu, 10 Dec 2009 10:47:41 -0000

Hello Tim,
 
> Concerning maximum realism, I suppose this comes down to interpretation.  There are critical components which must be recreated to ensure realism, such as video, keyboard, memory timings, etc.  Why…

First to say, I think it could make sense indeed to include a parameter in the mess.ini about delays, and I think I can convince the others, because this may also allow to find-tune some sensitive systems.

The MESS emulator system is actually an emulation of single chips, tied together to form a system. This is what makes the difference between simulations and emulations. There is a collection of microprocessors, of controller chips, of sound chips, video chips, and more. Someone wrote an emulation of the VDP, another one created the speech synthesis. I don't know much about the internals, but they are working according to their specs. One of the dreams of MESS developers is to describe a system on a pure textual, descriptive base (e.g. describing the PCB layout), and then letting the emulation evaluate this system. We're not as far, not even close, and I don't know whether we'll ever reach that, since on a PCB, many things are happening at the same time, and you just cannot well emulate that in a computer system.

So back to the current discussion. You noticed that I always have to struggle to keep the emulation going. From time to time, people change implementations, and suddenly things stop working. Just recently there was a version in SVN which broke our floppy access again, since the developer could not make sense of our "special TI handling". (It was not a big issue, and it was corrected in the next SVN release. But it probably would have stayed there, until someone of you would have noticed.)

I agree with the other developers that according to the nature of this emulator, we should keep the machine-specific things as small as possible. Ideally, there should not be *any* kind of machine-specific implementation in the emulation of the chips. Currently, we have quite some parts in there like "these lines are required for system xy" or "workaround for ab". As soon as people start changing some code at a distant location, these workarounds may stop working since they relied on some undocumented and out-of-spec behaviour.

My primary concern is that the TI/Geneve emulation must remain stable even when there are changes in the chip implementations. It is not acceptable that every some releases, the emulation becomes severely broken, only because someone decided to change memory access implementation, introduced RAM delays or whatever. Therefore, staying exactly with the specification is a guarantee for stability in future, as I hope.

Have a look at the wd17xx, the controller within the TI FDC. I remember it once was much faster, but at some later point it slowed down to the speed which I well remember from the real machine. I found that the developers had completely rewritten the controller, now exactly following the specification which also defines delay time, head load time, even index pulse! They are even emulating the turning disk with 300 index pulses per second.

This was obviously important for some other computer systems which had a kind of instruction timing (remember our recent discussion on the code in the FDC) and using interrupt-driven access. By the overly high data rate from the floppy, some other system parts failed.

As I said, with the HFDC we are in the comfortable position that this one is not used outside the TI/Geneve family, so we can include many tricks in there. Until, well, someone does find another system which makes use of this chip as well. And then the trouble comes back.

I know that one could say, let's just keep this version, it's running smoothly. Well, for one part, that's not quite true, we have quite a lot of issues still, but the worst ones are cured, OK. Second, the user interface could be improved. And third, the underlying concept of MESS is really fascinating, beyond the mere emulation of the TI system. As I said, if done correctly, we can precisely simulate system reactions for hardware that has not even been created yet. 

It is perfectly OK that you and the others are arguing from the user's point-of-view, and as those users you have good arguments about how the system should feel like to support you in the productive work. On the other side, I hope I can make it clear from the system architect viewpoint what our plans are. Be assured that my intention is not to make things less comfortable just because I can do it.

Michael

---

From: "jhwhite_delphi" <[email-masked]>
Date: Thu, 10 Dec 2009 14:21:09 -0000

--- In [email-masked], "Michael Zapf" <newsmail09@...> wrote:
<snip>
> I said *not better* that the original. I did not say *worse*. 

I could argue that failure is implicit in any design specification.  The true 99/4A experience is fraught with "dangers" not present in the emulated world.

The 9995 preliminary data manual details a bug in the actual implementation that is an unintended part of the specification.  The 9995 in the 99/8 does not meet the published specification.  These are minor issues.

The SMC UDC9234 controller chip of the HFDC is buggy.  Implementing the UDC9234 to the specification may in fact break the emulation because the DSR's would no longer work reliably.  There are artifacts in the design of the HFDC that especially make it troublesome for handling floppy disks written by Western Digital 17xx- or 279x-based designs.

I am fine with the efforts of the MESS developers, and by no means do I want to suggest that hardware failures be added as features.

You do know that if the specification requires no more than 3 defective parts per 100, then that is what we will attempt to achieve.  It is the American Way.

Jeff White
[email-masked]

---

From: fdos <[email-masked]>
Date: Thu, 10 Dec 2009 09:28:13 -0700

Michael,

You were, indeed, lucky.  In my very early days with the Myarc WDS-100 
system I had two Tulin 30MB hard drives (both are still out in my 
garage) limited to 15MB each by the Myarc disk management software, but 
once I went to the new HFDC the Tulin drives wouldn't format, so I 
replaced them with two ST-251 40MB drives.  Some of these that were 
assembled in Singapore were notorious for too much grease which would 
collect on the heads, and after cool down would be stuck (liked glued) 
to the platters.  On the next power up they would not spin up until the 
drives and grease got warm enough to release.  Fortunately, in my case, 
the drives were in a PC tower case with my Geneve system which we all 
know is a good heater, but eventually this no longer worked, but having 
heard of the problem I used a hair dryer to effectively get a few more 
months of use out of them.

Once again I was fortunate, as I learned that the Seagate regional hard 
drive repair center was just 6 blocks from where I lived at the time in 
Delray Beach, FL thus allowing me to hand carry my drives to that center 
(had to be boxed up and labeled for return shipment authorization). 
Along the way I lost a few ST-251 & ST-225 drives for other reasons, and 
a NEC 40MB drive that crashed with lots of noise and rattling, but I was 
able to identify bad Seagate drives with the grease problem at computer 
shops around town, and because they didn't want to bother with any of 
the bad drives as they sent them all out for salvage, so I was able to 
talk them out of the Seagate drives that didn't rattle when shook.  I 
tested them at home with the hair dryer, and those that worked I took to 
the Seagate Center for repair.  Did I mention that they repaired the 
grease problem at no charge even if out of warranty?

In Texas I had a computer shop just 3 blocks from where I lived, and 
they had these 3.5" half height 45MB Rodime MFM hard drives for $20.00. 
I tried one and it was so much faster and quieter than the Seagate 
drives that I went and bought 3 more.  These are the MFM drives I still 
use today with my two HFDC cards.

Some day, time allowing and God willing, I will reassemble the WDS-100 
system as I still have all the parts (nostalgia:-).

Bill S

Michael Zapf wrote:
>  
> 
> 
> 
> --- In [email-masked] <mailto:TI994A%40yahoogroups.com>, 
> ti99_forever <ti99_forever@...> wrote:
>  >
>  > You forgot #4. Floppies are more reliable than hard drives, emulation 
> or otherwise. Being small, separate containers, when you wipe the 
> directory structure of one, you only affect the files on that particular 
> container, and not potentially everything you've got in one big screw-up...
> 
> I think you never had such an easy way of doing backups than now with an 
> emulator. Besides, I've been working with hard drives on the Geneve for 
> many years and never had any kind of major file system damage, but I 
> just may have been lucky.
> 
> Michael
> 
>

---

From: Gregory McGill <[email-masked]>
Date: Thu, 10 Dec 2009 09:36:35 -0800

I still have my WDS-100 with the Rodime 15meg mfm drive I installed in
it when i got it. (late 80's)
It has a break sticking problem now and then but a few power ups
usually resolves it.  I cringe every time I power it up thinking this
will be the day i have to find another mfm drive. But it keeps
working.  Wish there was a better way to back it up than the wds-100
backup tool..

Greg

On Thu, Dec 10, 2009 at 8:28 AM, fdos <[email-masked]> wrote:
>>  >
>>  > You forgot #4. Floppies are more reliable than hard drives, emulation

---

From: TIMOTHY KIRSCH <[email-masked]>
Date: Thu, 10 Dec 2009 14:39:38 -0600

Got p card roms for pc99 but still need ones for mess. Tim
 		 	   		  
_________________________________________________________________
Windows 7: Unclutter your desktop. Learn more.
http://www.microsoft.com/windows/windows-7/videos-tours.aspx?h=7sec&slideid=1&media=aero-shake-7second&listid=1&stop=1&ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_7secdemo:122009

---

From: fdos <[email-masked]>
Date: Fri, 11 Dec 2009 10:50:58 -0700

Yes, backups and restores were nightmares to accomplish because the 
software was so slow.  I still have a bunch of WDS-100 backup diskettes 
to restore from, and this is probably why I've never put the system back 
together--I dread the restore process.

Bill S

Gregory McGill wrote:
> On Thu, Dec 10, 2009 at 8:28 AM, fdos <[email-masked] 
> <mailto:fdosbrs%40frontiernet.net>> wrote:
>  > Michael,
>  >
>  >> --- In [email-masked] <mailto:TI994A%40yahoogroups.com> 
> <mailto:TI994A%40yahoogroups.com>,

---

From: Gregory McGill <[email-masked]>
Date: Fri, 11 Dec 2009 10:06:06 -0800

I have this delusion that someday someone may make a dm2k interface dm
for that card..  Dm2k can read the root dir, but that's it..

Greg

On Fri, Dec 11, 2009 at 9:50 AM, fdos <[email-masked]> wrote:
>>  > Michael,
>>  > You were, indeed, lucky.  In my very early days with the Myarc WDS-100
>>  > system I had two Tulin 30MB hard drives (both are still out in my
>>  > garage) limited to 15MB each by the Myarc disk management software, but
>>  > once I went to the new HFDC the Tulin drives wouldn't format, so I
>>  > replaced them with two ST-251 40MB drives.  Some of these that were
>>  > assembled in Singapore were notorious for too much grease which would
>>  > collect on the heads, and after cool down would be stuck (liked glued)
>>  > to the platters.  On the next power up they would not spin up until the
>>  > drives and grease got warm enough to release.  Fortunately, in my case,
>>  > the drives were in a PC tower case with my Geneve system which we all
>>  > know is a good heater, but eventually this no longer worked, but having
>>  > heard of the problem I used a hair dryer to effectively get a few more
>>  > months of use out of them.
>>  >
>>  > Once again I was fortunate, as I learned that the Seagate regional hard
>>  > drive repair center was just 6 blocks from where I lived at the time in
>>  > Delray Beach, FL thus allowing me to hand carry my drives to that center
>>  > (had to be boxed up and labeled for return shipment authorization).
>>  > Along the way I lost a few ST-251 & ST-225 drives for other reasons, and
>>  > a NEC 40MB drive that crashed with lots of noise and rattling, but I was
>>  > able to identify bad Seagate drives with the grease problem at computer
>>  > shops around town, and because they didn't want to bother with any of
>>  > the bad drives as they sent them all out for salvage, so I was able to
>>  > talk them out of the Seagate drives that didn't rattle when shook.  I
>>  > tested them at home with the hair dryer, and those that worked I took to
>>  > the Seagate Center for repair.  Did I mention that they repaired the
>>  > grease problem at no charge even if out of warranty?
>>  >
>>  > In Texas I had a computer shop just 3 blocks from where I lived, and
>>  > they had these 3.5" half height 45MB Rodime MFM hard drives for $20.00.
>>  > I tried one and it was so much faster and quieter than the Seagate
>>  > drives that I went and bought 3 more.  These are the MFM drives I still
>>  > use today with my two HFDC cards.
>>  >
>>  > Some day, time allowing and God willing, I will reassemble the WDS-100
>>  > system as I still have all the parts (nostalgia:-).
>>  >
>>  > Bill S
>>  >
>>  > Michael Zapf wrote:
>>  >>
>>  >>
>>  >>
>>  >>
>>  >> --- In [email-masked] <mailto:TI994A%40yahoogroups.com>
>>  >> ti99_forever <ti99_forever@...> wrote:
>>  >>  >
>>  >>  > You forgot #4. Floppies are more reliable than hard drives, emulation
>>  >> or otherwise. Being small, separate containers, when you wipe the
>>  >> directory structure of one, you only affect the files on that particular
>>  >> container, and not potentially everything you've got in one big
>> screw-up...
>>  >>
>>  >> I think you never had such an easy way of doing backups than now with an
>>  >> emulator. Besides, I've been working with hard drives on the Geneve for
>>  >> many years and never had any kind of major file system damage, but I
>>  >> just may have been lucky.
>>  >>
>>  >> Michael
>>  >>
>>  >>
>>  >
>>  >
>>  > ------------------------------------
>>  >
>>  > Yahoo! Groups Links
>>  >
>>  >
>>  >
>>  >
>>
>>
>
>

---

From: "Michael Zapf" <[email-masked]>
Date: Mon, 14 Dec 2009 14:11:30 -0000

One question that I hit while I was writing the disk format support this weekend:

PC99 used F7F7 als CRC value. Would it tolerate other values, i.e. does it check whether the format has these F7F7 values? What would happen if we had the actual CRC values there? Anybody knows more about the internals of PC99 image handling?

Michael

---

From: "hexbus" <[email-masked]>
Date: Mon, 14 Dec 2009 14:46:45 -0000

Just throwing something out there - has anyone attempted to talk with Mike Wright to see if we could get his source code from RSECTOR and WSECTOR?  

Jon

---

From: "epergrem" <[email-masked]>
Date: Mon, 14 Dec 2009 15:45:08 -0000

Hi Jon, 
I don't think there is much to the source.  It's just a straight sector copy.  Copy 256 bytes.. Write 256 byes, rinse, repeat.

The only difference is that RSECTOR/WSECTOR uses RS232 rather than DSK1, etc.

Ernie

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Mon, 14 Dec 2009 22:08:51 +0100

Ernie,

there should be something more than that. The whole point here is on how 
RSECTOR/WSECTOR detects a sector in the PC99 .dsk file. Does 
RSECTOR/WSECTOR just start from a fixed offset from the start of the file, 
and calculate the offset to any next sector, ignoring anything that there 
is in between?

Or, does it also check for markers and special values along the file (i.e. 
sector, side, length) , making sure the .dsk is a true and valid .dsk 
file, and not a corrupt one? By this  second approach, the presence of the 
F7F7 word (CRC) could be tested, and other special values could be tested 
too.

If we can look at the portion of the RSECTOR/WSECTOR source code that 
reads a .dsk file, we could easily understand what is really needed in the 
.dsk structure and what is not. I'm positively sure that there are bytes 
in the .dsk structure that are not checked and others that are. Bytes that 
are not checked could be considered as "fillers". Thanks for your support.

Paolo

----- Original Message ----- 
From: "epergrem"
Sent: Monday, December 14, 2009 4:45 PM
Subject: [TI994A] Re: PC99 format

Hi Jon,
I don't think there is much to the source.  It's just a straight sector 
copy.  Copy 256 bytes.. Write 256 byes, rinse, repeat.

The only difference is that RSECTOR/WSECTOR uses RS232 rather than DSK1, 
etc.

Ernie

--- In [email-masked], "hexbus" <jon@...> wrote:
>
> Just throwing something out there - has anyone attempted to talk with 
> Mike Wright to see if we could get his source code from RSECTOR and 
> WSECTOR?
>
> Jon

---

From: "hexbus" <[email-masked]>
Date: Mon, 14 Dec 2009 21:27:55 -0000

Does anyone have a good relationship with Mike?  His number is on the CaDD homepage here:

http://home.netcom.com/~mjmw/

I'd volunteer to call him asking if he would mind giving a few people access to the source code, but I really don't know him that well...

Jon

--- In [email-masked], "Paolo Bagnaresi" <paul.bagnaresi@...> wrote:
> --- In [email-masked], "hexbus" <jon@> wrote:
> >

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Mon, 14 Dec 2009 23:42:12 +0100

This is a strange situation.

I have the source code used by Mike Wright to build a PC99 .dsk file in my 
hands. I got that directly from Mike through a personal mail on the year 
2000. Since the email was personal, I cannot release the content, unless 
Mike himself authorizes that. And this is why I, too, am asking for a 
public release of the source code.

At any rate, I can tell you right away that the code in my possess does 
not explain how the sector will be read by PC99. It just tells you how the 
sector will be built, and this is not the same thing. By just seeing how 
the sector is built you can't understand what portion of the format is 
mandatory and what is not.

Mike also explains how the sector is read, but that was through words, and 
not through code. As such, the explanation is kind of vague. And, again, 
unless Mike gives permission, I can't say anything more about it.

But Mike could step in this discussion, if he reads us, and hopefully shed 
some light on this matter.

Paolo Bagnaresi

----- Original Message ----- 
From: "hexbus"
Sent: Monday, December 14, 2009 10:27 PM
Subject: [TI994A] Re: PC99 format
> I'd volunteer to call him asking if he would mind giving a few people 
> access to the source code, but I really don't know him that well...
>
> Jon

---

From: "epergrem" <[email-masked]>
Date: Tue, 15 Dec 2009 00:52:44 -0000

Paolo,

That's the genius of PC99.  It's an emulator, not a simulator. 

You're reading a formatted disk using the DSR in the TI FDC and writing to a formatted disk using the DSR in PC99.  Since PC99 uses a ROM dump, it's the same DSR as you would use with a 'real' TI.

So the question becomes not how PC99 does it, but how does the TI or Myarc DSR code do it.

Ernie

---

From: tursi <[email-masked]>
Date: Mon, 14 Dec 2009 17:25:31 -0800 (PST)

> So the question becomes not how PC99 does it, but how does the TI or 

Unfortunately, there's not enough information there for what Paolo is 
trying to understand. The track dump doesn't exactly match the layout of 
the physical disk (it's clearly inspired by, but it's not correct). 
Besides, the TI and Myarc DSR read the disk by sectors, they don't do 
track access except during format. This is why V9T9, MESS, Win994A, and 
other emulators can run the TI DSR and not need the extra track 
information in the disk image.

The terms "emulator" and "simulator" are tossed around now and then, but 
in truth all of the current offerings are a combination. A full emulator 
would run everything as a reproduction of the circuitry, and all software 
would run through that circuitry. In truth, at least parts of all existing 
emulators use simulation (for instance, none of them today scan the video 
display line by line, they're all frame based - this is a simulation of 
the video chip).

Likewise, the existing "simulators" (Win994A, I thought there was a 
second) do a great deal of emulation, running original ROM code on an 
emulated CPU, a true simulator would reproduce this entirely by other 
means. For instance, Virtual Merlin 
(http://www.monroeworld.com/vmerlin/wip.htm) is a simulation of the old 
Merlin game by Parker Brothers, in that it reproduces none of the original 
hardware and does not run the original software.

I used to call Classic99 a simulator, and in truth it did simulate a lot - 
the console interrupt routine was simulated, as was keyboard and video, 
but the CPU was emulated, and over time more and more emulation has crept 
in. Looking at it, and other offerings, combined with the more than a 
decade of experience earned, I think the terms might as well be 
interchangable in the TI world, since there is not and is not likely to be 
a full simulator (a full emulator is possible, but we aren't there yet).

---

From: ti99_forever <[email-masked]>
Date: Mon, 14 Dec 2009 21:36:18 -0800 (PST)

RSECTOR/WSECTOR is simply a program that does sector I/O on the disk and calls the DSR in the RS232 for save/load.

This program actually runs in PC99, it is not external to it, and the other end, a real TI, runs another copy.

So, you'd have to look at PC99 internals, not RSECTOR/WSECTOR code.

--- On Mon, 12/14/09, Paolo Bagnaresi <[email-masked]> wrote:

> Date: Monday, December 14, 2009, 4:08 PM
> Ernie,
> 
> in the .dsk structure that are not checked and others that
> are.. Bytes that

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Tue, 15 Dec 2009 10:18:23 +0100

To Ernie and Ben:
Thanks for your explanations. It seems to me that only Mike Wright can 
clear up things on this matter.

To Michael (Zapf):
Apparently, obtaining the source code is not going to be an easy task. 
Maybe, if Mike is willing, he can cut out for us and post here just the 
portion of code that handles the sector input from a PC99 .dsk file, down 
to the DSR level.

Michael, can you tell us why you want to change the two F7 bytes (CRC) in 
the PC99 .dsk file, and what you are planning to replace them with? Maybe 
with a real CRC value, calculated on the bytes that there are before the 
CRC, as it should have been in the first place?

In that case, I can tell you right away that my code in TI99-PC just 
ignores the presence of CRC. So, if the above is your purpose, that would 
surely be ok with TI99-PC.

Please, let us know anyway, thanks.

Paolo

---

From: "epergrem" <[email-masked]>
Date: Tue, 15 Dec 2009 12:49:09 -0000

Michael (Zapf),
If you have any questions regarding whether a specific byte sequence will run in PC99 then feel free to email me the disk in PC99 format and I'll try it in PC99.

Not sure that will be of much help, but the offer is out there.

Ernie

---

From: "Michael Zapf" <[email-masked]>
Date: Tue, 15 Dec 2009 22:41:10 -0000

Hello Paolo,

> surely be ok with TI99-PC.

I'm currently writing the PC99 support for MESS; this is a good opportunity for cleaning up the WD17xx implementation which has some quirks in it. Especially the track handling is left in some unsatisfying state. I guess they once tried, found that it did not work for different machines, gave up, worked around, then no one cared as long as they stayed with sector dumps.

One point is the handling of 0xf5 - 0xff bytes for write_track. What should the controller do when it gets an 0xf7? Should it write one f7 to the image? Two f7? The real CRC?

Following the modular architecture of MESS, formats and controllers are clearly separated. That is, I cannot put anything specific to PC99 into the WD17xx implementation.

Assuming that other systems could be interested in the CRCs I should make the controller calculate CRCs and write them to the disk (or image). Now, if we want to have ther PC99 format, and if that format required the pseudo CRC (f7f7), I would have to parse the output from the controller to find out where these CRC bytes are - in order to replace them by the f7f7. 

It's not impossible to replace them, since the format is structured quite regularly. But I'd like to avoid that.

I think I'll go for writing real CRC values, and then we will see.

Michael

---

From: "Michael Zapf" <[email-masked]>
Date: Tue, 15 Dec 2009 23:00:57 -0000

Hello Tim,

> Hi Michael, I'll give that a shot.   A thought occurred to me -- have you considered giving MESS the ability to mount physical media?  For example, could MESS mount a EZ135 platter natively or thro…

Sorry, I did not notice this posting ... as for physical devices, no, at least not me. And there are some points that you cannot easily handle: For instance, the floppy controller of the PC usually does *not* support full track reading/writing. The problem would be how to create an interface between the TI DSR and the PC hardware. MESS runs the original TI/Myarc/whatever ROMs, and it will be a challenge to "convince" the ROM that the PC hardware reacts the way it expects from the TI hardware. But what I would really love to see is a live connect to the serial interface. This is the only hardware that is still more or less unchanged, and which had only few variations.

Michael

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Wed, 16 Dec 2009 01:56:29 +0100

Hi Michael,

> One point is the handling of 0xf5 - 0xff bytes for write_track. What 
> should the controller
> do when it gets an 0xf7? Should it write one f7 to the image? Two f7? 
> The real CRC?

You write just one >F7 byte to the WD177xx Data Register (at >5FFE in a TI 
FDC and at >5F07 in a Myarc FDC) and, as if by magic, 2 (two) CRC bytes 
will pop up on the floppy disk. The 2 CRC bytes will contain the 
calculated CRC for all the bytes that have been written to the Data 
Register, as from the following table.

Single Density or Double Density (makes no difference)
==============
For each sector
...
>FE - ID Address Mark - Presets CRC
>xx - Track Number
>xx - Side Number
>xx - Sector Number
>xx - Sector Length (always >01 for TI Disks)
>F7 - Will write 2 CRC bytes to floppy, calculated from Track Number 
>through Sector Length,
...

>FB - Data Address Mark - Presets CRC
256 bytes of Data (that's for TI disks)
>F7 - Will write 2 CRC bytes to floppy, calculated only on the 256 bytes 
>of data

=================================================================================
From the above and for each sector.
You first write one >F7 byte for the Track/Side/Sector/Length values, and 
2 CRC bytes (a word)will be written to disk.
Next, on the same sector, you write another >F7 byte, this time for the 
actual data that you have just written to the disk (a bunch of >E5s, or 
whatever filler byte you have chosen to mark an unused sector) and 2 CRC 
bytes, a word, will be written on disk.

The WD177xx does the actual computation of the CRC. At formatting time, 
the computed CRC for Track/Side/Sector/Length will alway vary. On the 
other hand, the computed CRC for the Data Sector will always be the same 
at formatting time, because the filler byte (usually >E5) is always the 
same for all the sectors.

When you write a sector to a disk, only the second CRC (the Data CRC) will 
be computed again, reflecting the checksum, so to speak, of the data you 
have just written to disk.

For a SSSD disk (360 sectors) you supply 360*2 = 720 >F7 bytes and the 
disk will become longer by 720 bytes (since each >F7 generates two bytes 
worth of CRC).

For a DSDD disk (1440 sectors) you supply 1440*2 = 2880 >F7 bytes and the 
disk will become longer by 2880 bytes.

> Assuming that other systems could be interested in the CRCs I should 
> make the controller
> calculate CRCs and write them to the disk (or image). Now, if we want to 
> have ther PC99
> format, and if that format required the pseudo CRC (f7f7), I would have 
> to parse the output
> from the controller to find out where these CRC bytes are - in order to 
> replace them by the
> f7f7.

I don't know. I am still confused about PC99. I always thought PC99 would 
create a new .dsk disk image file out of thin air, i.e. not passing 
through an emulated FDC, but rather by just adding byte after byte to an 
opened file, according to the format layout. By the way, this is the 
approach I chose for TI99-PC. It's fast, clean and you make no easy 
mistakes. However, Ernie (Pergrem) says that PC99 does not work that way.

Ok, so be it, then. Parsing the .dsk disk generated by MESS seems the 
easiest viable solution. Since the format is fixed (and it'd better be 
so!) it will take you almost no time.

Dan Eicher and Jeff White have worked with Mike Wright to create the PC99 
format. They are better qualified than I am to give advice on PC99 format. 
I hope they will step in and give us a hand here :-)

Paolo

P.S.
Michael, I have a nice table that explains quite clearly how the Myarc FDC 
hardware works from a programmer's standpoint: where the hardware gates to 
the WD177xx are in the FDC and so on. If you are interested, I will gladly 
post it here.

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Wed, 16 Dec 2009 03:04:49 +0100

CRC 16 - For what is worth. I found this on www.99er.net.
I don't know if it works for data disk too. 

* http://www.99er.net/files/docs/RS232_Detailed_Specs.pdf
* 
* TI-99/4 EIA RS232C STANDARD I/O COMMAND HANDLING
* The Format of a data block will be 256 data bytes followed
* by a two byte cyclic redundancy check code for the data bytes.
* The two byte CRC check code is generated by the following
* TMS 9900 Assembly Language code:

*
* INPUTS:  R6 - MSbyte = character to add to CRC
*          R9 - Current CRC check code value
* OUTPUTS: R9 - Updated CRC check code value
* The CRC        16  12  5
* polynomial is X + X + X + 1
*

CRCALC MOV R6,R1       Copy new data to work reg
       ANDI R1,>FF00   Clear LSbyte
       XOR R1,R9       XOR new data with old CRC
       MOV R9,R1       Move to scratch register
       SRL R1,4        Shift right logical 4
       XOR R9,R1       XOR CRC with scratch
       ANDI R1,>FF00   Clear LSbgte
       SRL R1,4        Shift right logical 4
       XOR R1,R9       XOR scratch with CRC
       SRC R1,7        Shift right circular 7
       XOR R1,R9       XOR scratch with CRC
       SWPB R9         Reverse bytes of CRC
       RT              Return

Paolo

---

From: "Michael Zapf" <[email-masked]>
Date: Wed, 16 Dec 2009 09:29:31 -0000

Hello Paolo,

> Register, as from the following table.

:-) sorry, the question from me was meant rhetorically - I know that f7 writes the CRC, I was just asking how I should eventually decide. Nevertheless, thanks for your comments. 

There is also a ccitt_crc16 function in utils.c in MESS. What the specification of WD17xx fails to mention is the start CRC value (the preset). I saw that many implementations assume 0xFFFF as the start value, but I also saw other values there.

The CRC is indeed not very important for disk handling for most systems. The controller chip already checks the CRC and raises an interrupt with status bits set accordingly if there is a CRC mismatch. When reading sectors you never get to see the CRC. However, with read_track, the CRC values become visible. So there might be a chance that some program has a look at them. The TI FDC for sure does not.

BTW, as I found out, the SMC92x4 (HFDC) has a totally different way of writing a track: You have to set registers which define the sizes of the gaps and the filler byte for the sectors, and then you initiate the write_track command. No streaming of bytes to the medium.

Michael

---

From: "epergrem" <[email-masked]>
Date: Wed, 16 Dec 2009 11:04:00 -0000

Hi Paolo,
I'm not quite sure what you mean by the following, but when using RSECTOR/WSECTOR, PC99 has to start with a formatted disk.  

This is accomplished in PC99 by using the template disks FMT21.DSK (720 sectors) or FMT22.DSK (1440 sectors).  So, if I am copying a series of 360 sector disks from the TI to PC99, I would do a >COPY FMT21.DSK DSK1, >COPY FMT21.DSK DSK2, etc.  This sets up four new formatted disks for PC99 to write to.

It has  been recommended by Mike in the past to 'not' create the newly formatted disks within in PC99 using DSKU, DM-1000, etc, because this sometimes causes problems.  I can't site any instances where it has because it's quicker to do the four COPYs in a batch file than run DSKU four times (sorry, hope that's not confusing).

Ernie

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Wed, 16 Dec 2009 13:47:49 +0100

Hi Michael,

----- Original Message ----- 
From: "Michael Zapf"
Sent: Wednesday, December 16, 2009 10:29 AM
Subject: [TI994A] Re: PC99 format

> :-) sorry, the question from me was meant rhetorically - I know that f7 
> writes the CRC, I
> was just asking how I should eventually decide. Nevertheless, thanks for 
> your comments.
Dumb me :-)

> There is also a ccitt_crc16 function in utils.c in MESS. What the 
> specification of WD17xx
> fails to mention is the start CRC value (the preset). I saw that many 
> implementations assume
> 0xFFFF as the start value, but I also saw other values there.

From page 18 of "Diagnostic Software from TI manual.pdf" (Miller 
Graphics).
ftp://ftp.whtech.com/datasheets%20and%20manuals/Software%20manuals%20-%20Third%20Party/Millers%20Graphics/Diagnostic%20Software%20from%20TI%20manual.pdf

The following are the values found with a Read Track on Track zero:
Side   0
Track  0
Sector 0
Length 1

found:

FF FF FF FF FF FF FF FF FF FF FE 00 00 00
01 F1 D3 ...

So, from >FE (ID Address Mark, CRC Preset) up to the calculated CRC (>F1 
D3) there are the following 4 bytes:
00 00 00 01
Assuming the above example is valid (and Miller Graphics did not fake it), 
you just calculate a CRC on those bytes, and vary the CRC starting value 
(CRC preset) until you find the one that gives you as a result >F1 D3.

At any rate, the CRC we find on a TI floppy is compatible across many 
platforms and controllers (PC, Linux,...). So the starting value must 
pretty well be a standard one.

> BTW, as I found out, the SMC92x4 (HFDC) has a totally different way of 
> writing a track: You
> have to set registers which define the sizes of the gaps and the filler 
> byte for the
> sectors, and then you initiate the write_track command. No streaming of 
> bytes to the medium.

It works like a NEC 765, same approach.

Have fun,

Paolo

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Wed, 16 Dec 2009 14:08:07 +0100

Hi Ernie.

> This is accomplished in PC99 by using the template disks FMT21.DSK (720 
> sectors) or
> FMT22.DSK (1440 sectors).  So, if I am copying a series of 360 sector 
> disks from the TI to
> PC99, I would do a >COPY FMT21.DSK DSK1, >COPY FMT21.DSK DSK2, etc. 
> This sets up four new
> formatted disks for PC99 to write to.

Then it's like I thought. You don't use a FDC to format a PC99 .dsk image 
file. Thank you.

> It has  been recommended by Mike in the past to 'not' create the newly 
> formatted disks
> within in PC99 using DSKU, DM-1000, etc, because this sometimes causes 
> problems.

Indeed, and now we understand there is a very good reason for that too. 
You don't want to pass through the TI FDC by using DSKU, DM-1000, etc, 
because of the bug Micahel just found on the TI FDC. Depending on the 
position of the VDP buffer while formatting a track, a shift in all the 
data forming a track will ensue, spoiling the chance of easily detecting 
where a sector starts in a track.

If the VDP buffer starts at a multiple of 256, the resulting track will be 
a perfect track.
Otherwise, a shift will occur, some unwanted bytes will pop up at at the 
beginning of the track and any software that relies on offsets to detect 
where the sector starts will fail miserably. Well, Mike realized there was 
a problem, but he could never imagine what was the real reason from that. 
Quite amusing... :-)

Finally, by changing the FDC make, you might get different results anyway. 
That is why it is always better to stick to a unique format, the one you 
have just created on purpose.

Thank you Ernie for clearing up things.

Paolo

---

From: "jhwhite_delphi" <[email-masked]>
Date: Sun, 20 Dec 2009 04:25:05 -0000

Xmodem-CRC and Floppy Disk Controller CRC polynomials are the same, and are "properly" called CRC-CCITT (not CRC-16).  Xmodem-CRC initializes to >0000, while FDC CRC initializes to >FFFF.

The algorithm in the code below is for CRC-CCITT.

Jeff White
[email-masked]

---

From: "jhwhite_delphi" <[email-masked]>
Date: Sun, 20 Dec 2009 04:30:52 -0000

<snip>

Presetting to 0xFFFF is correct for the WD17xx and any other controller that is designed to support the original IBM 8-inch floppy disk formats.  It is also correct for the Winchester Disk System and other MFM hard disk formats.

Jeff White
[email-masked]

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Sun, 20 Dec 2009 10:00:10 +0100

Thanks Jeff, it's crystal clear now!
I knew you were the guru on this matter :-)

So, will the below code be ok?

PRESET SETO R9         Presets the CRC. Call this
*                      for first byte only. Call
*                      CRCALC for all remaining bytes.
CRCALC MOV R6,R1       Copy new data to work reg
       ANDI R1,>FF00   Clear LSbyte
       XOR R1,R9       XOR new data with old CRC
       MOV R9,R1       Move to scratch register
       SRL R1,4        Shift right logical 4
       XOR R9,R1       XOR CRC with scratch
       ANDI R1,>FF00   Clear LSbgte
       SRL R1,4        Shift right logical 4
       XOR R1,R9       XOR scratch with CRC
       SRC R1,7        Shift right circular 7
       XOR R1,R9       XOR scratch with CRC
       SWPB R9         Reverse bytes of CRC
       RT              Return

Paolo Bagnaresi

----- Original Message ----- 
From: "jhwhite_delphi" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, December 20, 2009 5:25 AM
Subject: [TI994A] Re: PC99 format

Xmodem-CRC and Floppy Disk Controller CRC polynomials are the same, and 
are "properly" called CRC-CCITT (not CRC-16).  Xmodem-CRC initializes to 
 >0000, while FDC CRC initializes to >FFFF.

Jeff White
[email-masked]

---

From: "Michael Zapf" <[email-masked]>
Date: Mon, 21 Dec 2009 14:53:35 -0000

Hi Jeff,

> Presetting to 0xFFFF is correct for the WD17xx and any other controller that is designed to support the original IBM 8-inch floppy disk formats.  It is also correct for the Winchester Disk System a…

OK, thanks for the information. I think I will find some time in the next days to complete the PC99 emulation.

Michael

---

From: "jhwhite_delphi" <[email-masked]>
Date: Wed, 23 Dec 2009 01:07:33 -0000

Paolo,

Not sure I am the guru on this matter, but I have done quite a bit of reading on floppy disk controllers and have several pages of documents on the Western Digital series, the SMC UDC9234 of the HFDC, and the NEC 765 (and equivalents).

The code below should be okay, but I have not verified the algorithm to be sure it was transcribed correctly.  It could be verified by looking at the source to FastTerm or other terminal emulator or BBS software for the 99/4A and Geneve that supports Xmodem-CRC.  FastTerm source is available.

Tim Tesch could also verify with the S&T BBS source code.

Jeff White
[email-masked]

<snip>

---

From: Insane Multitasker <[email-masked]>
Date: Tue, 29 Dec 2009 00:32:20 -0600

Jeff and Paolo,

The routine looks correct.  Though it may be apparent, the CRC calculations are computed using the 8 most significant bits of the incoming word, in this case R6.  Therefore, to generate a CRC for a 256 byte sector, the below routine would be called once to initialize and 256 times to calculate the final CRC.

A few months ago I queried the SWPB group regarding table-driven CRC code - some of that conversation may be applicable to your efforts.

Tim

> From: [email-masked]
> Date: Wed, 23 Dec 2009 01:07:33 +0000
 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141664/direct/01/

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Tue, 29 Dec 2009 20:58:27 +0100

It was Michael Zapf that first started this thread, but then I got in and 
I have to admit I got carried away a bit.

Well, maybe it's best to call it once so as to process the first byte 
(PRESET label), and then 255 times to process the other 255 bytes. But I'm 
sure in real life you don't want to call a BL for 256 times, and the code 
can surely be arranged in a more suitable way.

Thanks a lot for your support, Tim.

Paolo

----- Original Message ----- 
From: "Insane Multitasker"
To: <[email-masked]>
Sent: Tuesday, December 29, 2009 7:32 AM
Subject: RE: [TI994A] Re: PC99 format

>Jeff and Paolo,
>
> The routine looks correct.  Though it may be apparent, the CRC 
> calculations are computed
> using the 8 most significant bits of the incoming word, in this case R6. 
> Therefore, to
> generate a CRC for a 256 byte sector, the below routine would be called 
> once to initialize
> and 256 times to calculate the final CRC.
>
> A few months ago I queried the SWPB group regarding table-driven CRC 
> code - some of that
> conversation may be applicable to your efforts.
>
> Tim
>
>> Not sure I am the guru on this matter, but I have done quite a bit of 
>> reading on floppy disk controllers and have several pages of documents 
>> on the Western Digital series, the SMC UDC9234 of the HFDC, and the NEC 
>> 765 (and equivalents).
>>
>> The code below should be okay, but I have not verified the algorithm to 
>> be sure it was transcribed correctly. It could be verified by looking 
>> at the source to FastTerm or other terminal emulator or BBS software 
>> for the 99/4A and Geneve that supports Xmodem-CRC. FastTerm source is 
>> available.
>>