Jump to content
Sign in to follow this  
BeeryMiller

Myarc HFDC Bug?

Recommended Posts

I don't have CFORM; could you post a copy please? I assume this is a formatter. I'd like to try it in MAME.

 

Thinking about that, I never formatted a hard disk in MAME within the Geneve emulation but only in the TI emulation with MDM150.

 

I recently ran into weird issues with my (real) hard disk; reported it to Tim already: After years of flawless operation, my hard disk started to raise errors like being unable to open a file or corrupting files while writing. More precisely, when I run TASM, it sometimes stops working, telling that it could not open the source file that it has opened successfully on the first pass. GenASM, in contrast, does not issue that message but creates an object file with an invalid first record, so that loading the object file stops with "Illegal tag".

 

I suspected a problem with my SCSI2SD or the SD memory card, if not ... MAME reacted identically! The point is that I had formatted a 240 MiB drive (maximum capacity) in MAME and had copied that image on the SD card, which I've been using in the real machine. What I found out is that the recently created directory where the source files is located uses a surprisingly high AU number.

 

At some point of experiencing recurring errors, I decided to create another HD image with AU size 8, half of the capacity, and this works perfectly again (on MAME and on the real machine).

 

When there is enough free time, I will have a closer look. Debugging is not trivial because the errors seems to be on level 3, and this is hard to track in MAME where your view is limited to level 1.

Share this post


Link to post
Share on other sites

I'm at work right now.  If you want, download the MAME archive setup to run for the Geneve at:

 

http://www.uswingnuts.com/Files/MAME.zip

 

The image Bootdisk1.hd has a directory called CFORM.  In it, there is a the CFORM program, however, before running it, run the WIN-DRIVE program first.  That is a Windows driver that CFORM requires to get proper menu displays and windows, etc.  Things run from the MDOS mode.

 

CFORM is much slower than MDM5 on the formatting. An 8 head, 2048 cylinder image will take at least 3 hours just to format, then it goes through a verification process that adds more time.

 

Mike Maksimik wrote the program in C, and to my knowledge, the source code I do not think exists anymore.

 

There is a settings option in one of the menus requiring one to specify a few options.

 

Beery

Share this post


Link to post
Share on other sites

Unfortunately, I'm not getting far with CF; after a keypress there is a window with three lines, the last one being "Function complete", but that was it. The log file says that CF (like WINDOWS which I also tested) crashes with a MID. WIN-DRIVE works, though. I guess I don't need more than the files #QHLP1/2, %QDEF, CF/G/H, KAL, WIN-DRIVE/F, and WINDOWS/T/U in a directory. Maybe there is a bug in the emulation. Luckily they are pretty rare, but they show up from time to time.

 

A MID means that there is something different at the executed address than expected. Could be an issue with the mapper.

Share this post


Link to post
Share on other sites

The ugly thing is, as far as I found out already, that it is a BL *R1 that sends the system into the woods, because R1 was set to 0 in the line before (a MOV command), which worked 3 times correctly before. So the original issue is somewhere else.

 

It seems as if CFORM makes use of windows, so hopefully I can write a simple program that triggers the problem, or it will become a really hard challenge.

Share this post


Link to post
Share on other sites

Interestingly, CFORM does not crash when I don't run WIN-DRIVE before. But the menu and the screen display seems to be broken (no pull-down menus, menu items seem to appear left in the menu bar, I cannot really operate the menus, no mouse visible).

0029.png

Share this post


Link to post
Share on other sites

Yeah, it won't crash, but you need the WIN-DRIVE to run.


What version of MDOS are you using?  I know with 6.50, it had no issues.

 

I just tested CFORM with the Win-DRIVe which should be the same file on the BOOTDISK1.HD file part of the complete zip I had.  No problems here.

 

Mouse is not required.  Hitting <ENTER> on a  menu navigating with the arrow keys is what I am doing.  The mouse used a mouse driver that would be required if you wanted to use it.  There were at least two versions of the mouse driver.  One for the Geneve Bus mouse, and another driver written if you plugged a serial based mouse into the RS232 port.  Obviously, with MAME, the serial interface would be more complicated.  I'm pretty sure on my BBS, as well as on Whtech, there should be the Mouse Development Kit.  Source may even be on the HD image for both bus and serial mice.  It should be under HELLSTROM directory if I recall correctly.  He also wrote BHDMV.  BHDMV was key for me back in the day to understanding how the operating system was working so I could intercept and put other programs to sleep, etc. with the Windows program.  It was an accomplishment back then, but as I look back on it, practical use was very limited.

 

Beery

 

Share this post


Link to post
Share on other sites

I found that although the GUI showed up, there were still lots of MID events, which means that the application still jumped to some undefined location but recovered from that issue.

 

I suspect an exotic bug in the Geneve emulation in MAME. Obviously it is reproducible by running WINDOWS; maybe if I find it there, it will solve all other issues.

 

Are there source codes for WINDOWS? Preferably with some build procedure so that I can apply changes for debugging?

Share this post


Link to post
Share on other sites

If you have my BOOTDISK1.hd file, look at directory BMILLER.

 

That whole image has everything you need to run.  It uses GenASM and GenLINK.

 

The file "ASS" starts the assembly/linkage process.  The assembly process as is produces the Windows program.  You will need the MOUSE driver in that file to use the Windows program.  If that generates the MID events by itself, then you have the code.

 

The file "BEGIN9" contains the code for the full "multi window" capability of Windows, or if you want to recreate the driver, the beginning of that file had the notes for single task usage that should give you the WIN-DRIVE program.  There is a second source file "DRIVER1" that installs the "BEGIN9" code.  You will need to modify the LINK1 file that is used by the linker to use the appropriate object files for assembly.

 

You should be able to run the Windows program, and quit.  Then, go and run CFORM.  The Windows XOP stays installed which is the "full" version of the Windows driver code, instead of code for a single task program like CFORM.

 

Hope that makes sense.

 

If I had it to do all over again, I would have done things with that program much differently so please do no judge the quality of the programming effort <grin>.

 

Beery

 

 

Share this post


Link to post
Share on other sites

There seem to be some things to be done before assembling the BEGIN9 file; (un)commented lines ... I guess I should configure it for building Windows 9640.

Share this post


Link to post
Share on other sites

At what point are you seeing a crash, or is it just a MAME warning?  I know just loading CFORM with the library, I have not seen anything.  Not sure about executing the format command where Mike's CFORM code starts doing all of its thing. 

 

The source file in question which I think you have figured out that has the code is BEGIN9 for the XOP.  

 

Inside the Winlib XOP, that XOP does call the Video XOP.  The XOP's allow you to go two levels deep from what Paul told me back in the 90's.  The DSR XOP's go two levels deep as well as they also call internally the memory management XOP.

 

On real hardware, the issue was never seen.  I would think you could use the Debugger and single step the code to identify where the MID event occurs.  I know back in 2003/2004, GenASM would not work and it took quite a bit of effort to trace down an instruction that was trying to execute on an odd byte boundary instead of even byte boundary.  At the time, I just knew the code ran amuck and figured out the issue when the program counter went odd instead of staying even.  That more than likely created the MID event, but that was something I had never read up on back in the day.  I think there were two instruction codes that had to be fixed in the emulation.  That was back in the day with MESS.

 

If I had my guess, I would suggest watching the Program Counter register and single step starting prior to doing something that picks up the MID event.  I would almost be willing to bet something is going to an odd byte instead of advancing to the next even byte.

 

Beery

 

 

Share this post


Link to post
Share on other sites

The warnings that I see in MAME are MID events. It will suffice for me to locate the point in the code where this happens; the problem, as I described above is, however, that there is an invalid address in R1 when the command BL *R1 is reached. Also, R1 gets the value from elsewhere, so the problem is actually there etc.

 

With the real iron, you don't see MID events, since they are not handled (just a RTWP), unless you install my "Guru mediation", which only works in GPL mode.

Share this post


Link to post
Share on other sites
On 6/18/2019 at 7:25 PM, BeeryMiller said:

Are yo able to load the Format routine on your end?  The program does not recognize the format module.

 

Beery

Did you or anyone try DU2K?  As I recall I used it to format MFM hard drives to 248MB, and in the case of IDE up to 4 partitions of 248MB each, using 1GB IDE drives.  Supposedly, CF cards could be used with Jon's adapter to do this also.  I know I wanted to try it with SCSI and the CF adapter, but never got around to it.

 

Bill

Share this post


Link to post
Share on other sites
25 minutes ago, FDOS said:

Did you or anyone try DU2K?  As I recall I used it to format MFM hard drives to 248MB, and in the case of IDE up to 4 partitions of 248MB each, using 1GB IDE drives.  Supposedly, CF cards could be used with Jon's adapter to do this also.  I know I wanted to try it with SCSI and the CF adapter, but never got around to it.

 

Bill

Never tried, nor was I aware, DU2K could format MFM drives.  I will try and check it out this evening.


Beery

Share this post


Link to post
Share on other sites

Beery,

 

I tried WINDOWS, WIN-DRIVE, and CF on my real Geneve. Good news or bad news (depending on the point of view): My real Geneve reacts 100% identically to the MAME emulation! I did not try to install a MID handler, though, so I guess that MIDs are happening and causing the lockup.

 

As a proof, have a look at these video clips: https://www.mizapf.de/en/ti99/tivideos

Share this post


Link to post
Share on other sites

Well, I guess I need to ask what you are doing then as I ran the program just this past week and have had no issues with it?  

 

Beery

Share this post


Link to post
Share on other sites

I used the built version from the Bootdisk1.hd, and I also tried building from the sources in BMILLER. The only changes I applied are as mentioned above, changing the comments to include DEF lines and remove the early SLAST. No other lines were touched.

 

I am using GeneveOS Version 6.50 Redistributable. Are you using the same? If there are differences this would explain why it is working for you but MAME and my real Geneve are both crashing in the same way.

Share this post


Link to post
Share on other sites

I've got the program loaded without any errors, etc.  What are you doing after that, or is that where you are getting the errors?  I'm wondering if the cfg file could be the issue?  Maybe delete it????

 

Beery

 

Share this post


Link to post
Share on other sites

What other differences exist --  TIMODE on/off?  WINDRIVE load order?  Memory expansions?   32k installed in the hfdc?  phase of the moon during testing?  ;)

 

I don't remember CFORM taking three hours to format.  Is there an option to skip sector verification?  I do know that it will periodically stall while formatting cylinder 0.  When this happens MDM5 is _required_ to successfully format the drive.

 

One advantage to CFORM is formatting to 34 sectors/track but through limited experience I am not convinced this is stable over the long haul.  MDM5 has always been reliable and works on both TI/Geneve systems, so I've just continued to use it for my purposes.

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...