Victor 9000 / Sirius 1 Hard Disk Emulation

[djg]

s the loud buzz coming from reading faults on the floppy disk?

If your referring to the noise of the head stepping the drive may seek back to track 0 and back to the track when retrying a read error.

Controller: NOK - Error- Address mark not found, poss. failures are: Radial cable, Drive, Controller

For the address mark not found can you tell where it was trying to read?

Can you try f4 sequential test to do a read test of the image? Is new media referring to a new floppy or something?

f4 Sequential Test The entire drive media surface is read looking
for defective media not currently logged in the drive header label.
If new media is discovered, it is logged and displayable upon
breaking the scan process with a SPACE or by utilizing option f7.
Only a single pass of the drive surface is made.

Controller: NOK - Error- Address mark not found, poss. failures are: Radial cable, Drive, Controller

If you use mfm_util to decode the emulator file does it report any errors?

I would use factoryf to reformat and follow pdevine procedure. I would also switch to the non debug version since we know it worked. We could still be dealing with incompatibility between the machines that makes his image not work on yours. If that doesn't work we will need to try debug again and see if we can find a sector

 

[1302L]

Hi,
I switched back to the normal Version 4.14.
The cleaning floppy disk arrived as well, cleaned the heads of my drive, runs smoother now, I hope, it did the trick.
- Started @pdevine 's new emu file (Which I formatted last time)
- Loaded an MS-DOS Floppy version
- Ran FACTORYF
=> Success, drive was formatted correctly

To get further I have to create some fresh floppy disks with the HD Field Programs, but running out of time for today... :-(

More to come.
Best,
Martin.

 

[1302L]

Tonight I had a little bit more time and was successful obeying @pdevine ’s instructions.
After the drive was formatted correctly with FACTORYF, by using the F5 parameters, I used HDSETUP to create one partition of 10MB.
Having had success with that I ran AUTOSET successful as well and switched to DOS 3.1.
The outcome was useable HDD emulation.
As I am having still trouble with my floppy drive, I wasn’t able to execute ‘SYS B: A:’ - is there another way to copy the hidden system files from floppy to HDD? Without this I cannot figure out if the re-fomatted HDD image is bootable for my machine or not. Now I am getting X99 (No operating system on HDD) instead of X98 as an error code on powering up the Victor.
But I was able to copy single files to the emulated HDD and was able to execute them there as well.
Seek times on the Putty log are always between 3 and 6ms.
I will try to copy KERMIT to the HDD emulation tomorrow to have another way to bring files to it.
Many thanks again and best regards,

Martin.

 

[Gary C]

SYS B: A: ? That should work but could you not from B: just type SYS A: ?

 

[1302L]

Hi Gary,
thanks, I will try this tonight.
Created new disks early this morning and was able to copy KERMIT to the HDD.
My Floppy drive is giving me a hard time as it is not in good shape, the further the head moves outward, the louder it gets and more read errors are occurring.
But I managed to copy a few files on the emulated HDD.
Trying to execute i.e. KERMIT from the HDD brings the error message: 'Program too big to fit in memory' - 'Memory allocation error' - 'Cannot load COMMAND, system halted' - Same with other executables, please see screenshots attached.
I will produce a putty logfile of the emulation tonight.
Will send an update until tonight.
Best,
Martin.

 

[Gary C]

Good luck

It shouldn't make any difference but you never know

I am very interested in this project and once you are in a good place, could you let me know what I need to replicate it ? I

 

[1302L]

Good luck

It shouldn't make any difference but you never know

I am very interested in this project and once you are in a good place, could you let me know what I need to replicate it ? I

Hi Gary,
will gladly do so, I think it's time to do a write-up. There has been a lot going on.
But @djg and @pauldevine had been right, my HDD controller seems to work properly.
I modified my last post a little bit, maybe also of interest for you.
Just visited the website of the Northwest Computer Museum, this is very impressive and the best intro I have ever seen!
Best,
Martin.

 

[Gary C]

If you type in the Konami code, you can play asteroids with the screen artefacts.

It does need update though. Its 'flashy' but quickly gets annoying and the website doesn't have any real detail. The facebook page (and something called tick... something) has more but I keep on at the boss to improve the website content.

As the drives stick so much onto a 5.25 floppy, they seem more prone to errors so its important I think to have an alternative, long term bootable device for these machines.

 

[djg]

Trying to execute i.e. KERMIT from the HDD brings the error message: 'Program too big to fit in memory' - 'Memory allocation error' - 'Cannot load COMMAND, system halted' - Same with other executables, please see screenshots attached.

My guess would be kermit transfer issue. Is the file the same size after the transfer? Are you using binary mode? Can't read the kermit.exe size to compare to this earlier directory.

https://forum.vcfed.org/index.php?attachments/img_3516-jpg.1272002

 

[1302L]

Hi all,
I finally succeeded to copy the system files to the hdd emulation, after many attempts it worked.
The Victor now boots from the HDD emulation!
Tried a different version of Kermit (2.29) this worked as well.
What I did before this attempt was removing the RAM extension card. Each time I started the machine I had another RAM status displayed and lot of system halts, now, back to 256kB things are working better. (Is there a way to check the card?)
I will play around a little bit and try to get some more software on the image.
- Is there any DOS 3.1 available with German Keyboard Layout?
Very glad it worked finally! THANKS!
Best,
Martin.

 

[djg]

I finally succeeded to copy the system files to the hdd emulation, after many attempts it worked.

What I did before this attempt was removing the RAM extension card.

Good to hear. I finally got the small seek time issue to reproduce. May be a couple days before I have time to fix. Would be interesting to try the st412_a.zip previously in the thread to see if that now works. Could have been bad RAM for some of the previous problems.

If only your new image works or otherwise you get an image useful to add to my status page let me know.

 

[1302L]

Hi djg,
Thanks!

Would be interesting to try the st412_a.zip

The base of my emulation was this file. I will try to load another image and do a safety copy of mine.
Interesting would be also, if the bigger images (from your website) can be modified as well by the procedure @pdevine described or if the Limit is 10MB. We'll see.

If only your new image works or otherwise you get an image useful to add to my status page let me know.

I will send you my image.

Another question:
As I now have managed to get KERMIT on the HDD.
@pdevine 's software archive is containing the files stored on the particular floppy disk, is it possible to copy these files from a recent PC on the HDD using KERMIT running on both machines?

 

[djg]

The base of my emulation was this file.

I think you ran FACTORYF on it so all its original contents were erased. I'm curious if st412_a.zip will now boot as is.

is it possible to copy these files from a recent PC on the HDD using KERMIT running on both machines?

It should be though you will need to set the right options to make sure its transferred in binary mode so no bytes are changed. Newer KERMIT on PC may also use options that the 9000 KERMIT may not know about so you may need to turn them off. Been too long since last using it to be able to say what the options are.

If you set up autostart of the emulator the latest code has a fix so systemctl stop properly stops the emulator for changing/copying emulator file.

 

[1302L]

I think you ran FACTORYF on it so all its original contents were erased. I'm curious if st412_a.zip will now boot as is.

Yes, I did. I tried it with the original st412_a.zip file. Did not work. It seems that my machine wants to put their own 'signature' on the emu file first before it works. I will download my file from the emu board and will provide it for trials on other V9K machines. Curious if this works vice versa.
Also, just being curious: Had the real MFM hard disks have been interchangeable between different V9K's? If this is not the case, it could be an explanation why the existing emu files did not work.

It should be though you will need to set the right options to make sure its transferred in binary mode so no bytes are changed

I will try and report here. On the other side I am using a Toshiba Libretto 110ct with a selfmade (from a Kodak photo storage medium) solid state HDD, it has the advantage of a real RS232 9-Pin Port as I made negative experiences with the USB converters. On this I run Kermit95, I will look for the options you described.

If you set up autostart of the emulator the latest code has a fix so systemctl stop properly stops the emulator for changing/copying emulator file.

Thanks for the advice!

 

[davidrg]

On this I run Kermit95, I will look for the options you described.

I think what you want for forcing transfers in binary mode will be something like:

set transfer-mode manual
set file type binary

Also, if you're still running Kermit 95 it might be worth having a look at its open-source successor - for working with serial ports it should be much like the final version of Kermit 95, just with a few less bugs.

 

[pdevine]

@1302L I'm glad you made so much progress. All the disks in the archive also have a .zip file that's readable on a modern PC. You should be able to transfer any of the files via kermit. I concur with @davidrg that you'll need to be careful about binary vs text mode. There is a RAM test on one of the diagnostic disks. It should be able to tell you if you have any bad RAM on the expansion card. I have a German MS-DOS 2.1. I think I can make a German DOS 3.1, but I'll have to play around to see if I can. In the meantime you should be able to save a keyboard configuration from the German disk and use modcon to load it onto the MS-DOS 3.1 so at least your keyboard matches what's on the labels.

 

[1302L]

Thanks @djg , @davidrg and @pdevine !

I will try to transfer files in binary mode and report how this went. Next slot for this should be on Sunday.

@pdevine, yes, I am very glad that the emulation worked finally (impressive, how fast and easy @djg 's board boots the Victor) , many thanks for your help once again! Yesterday evening I figured out that it's quite simple to have a German Keyboard Layout by executing i.e. modcon GERM01, I sourced the files from the KEYGEN image of your Archive. Now I have to get used to handle the keyboard as it is designated!


BTW: Will this work also with DOS 3.1?

Tasks for the weekend are amongst others enabling the automatic start of the emulation and providing my emu file to you.

Currently one question left:

Also, just being curious: Had the real MFM hard disks have been interchangeable between different V9K's? If this is not the case, it could be an explanation why the existing emu files did not work.

- Any thoughts on this?

Cheers,

Martin.

 

[1302L]

Hi,

a little bit earlier:

please find attached my emu file, I did not rename it.

I was checking the RAM via RAMTEST V4:: With the extension card (384kB), the test failed and program was frozen after the screen attached was displayed, please see screenshot attached. Without the extension (256kB) the test was OK and ended automatically.

Automatic emu startup is working fine

Best,

Martin.

 

[pdevine]

Hi @1302L, Sorry for the slow response. I was traveling for work and then visiting family and haven't had much time lately.

BTW: Will this work also with DOS 3.1?

I had never seen that procedure you found to update the keyboards in MS-DOS 2.1. I'm sure the general principle would work with 3.1, but the offset addresses they have are certainly specific to 2.1. By that I mean where it says "load the keyboard table at offset F000" that F000 number would be different in 3.1 than it was in 2.1. You'd have to find the keyboard locations in the MSDOS.sys file. When I mentioned I thought I could create a german MS-DOS 3.1, there's a process with syselect where you can define your own keyboards and localize the language for the operating system. The tool use is described at the end of this document http://www.bitsavers.org/pdf/victor/victor9000/Victor_9000_Programmers_Toolkit_Volume_II.pdf. That would be much easier to use than the method you're suggesting above.

On your question:

Also, just being curious: Had the real MFM hard disks have been interchangeable between different V9K's? If this is not the case, it could be an explanation why the existing emu files did not work.

I have successfully swapped MFM disks between two different Victor 9K's. I'm guessing the problem were running into is you and I having different versions of the boot ROM in our machines. I'm not entirely sure what's going on, TBH. I'm just glad you were able to get to a working system.

I haven't played at all with the RAM diagnostic test. I knew that it existed but I've never run it. I'm assuming that the program hangs with the RAM card in it that there is bad RAM on the card. The address being printed probably points to which chip is bad on the board. I'm not sure how to translate between the address and board contents.

Where you able to get kermit to run for you?

Best,
Paul

 

[1302L]

Hi Paul,

load the keyboard table at offset F000" that F000 number would be different in 3.1 than it was in 2.1

Thanks for your explanation, this might be far beyond my capabilities.
I think, you’re right SYSELECT ist the right tool for this job, I was just afraid of doing any damage to my fragile success at this time, but now, as I have made safety copies of my emu file it might be worth a try.

The upper section of this issue of ‘Victor Talk’ is interesting as well, as it makes the hidden DOS system files visible, is there any other possibility, I saw that there is an early version of Norton Utilities in your archive, may this does the job?

I'm guessing the problem were running into is you and I having different versions of the boot ROM in our machines

Thanks, this might be the cause, nevertheless I am very happy to have a running HDD emulation now.
Sometimes the boot process is getting stuck (cannot load COMMAND:COM) but this a minor flaw, as rebooting is fixing this at once. Also the programmes I tried to execute are stuck sometimes, (System memory allocation error, System is halted) Reboot fixes this as well.

Kermit works the most time and I was able transfer files back and forth, but I have to update to C-Kermit, as you had been correct, without being able to use binary mode the files transferred to the Victor are not useable, trying to execute them lats the machine freeze immediately.

I will experiment around a few days and post my findings here.

Regarding the RAM, I will see if I can change the RAM units on the card, as there is only one capacitor on the whole card, this might be a feasible job as well, but in the meantime I am happy with 256kB.

- Maybe you’ll find some time to try my emu file, I would be interested if it works with your machines.

Have a great Sunday!

Martin.