3

I am trying to run Visicalc on the modern laptop (Lenovo Thinkpad X1 Extreme Gen.2). I created bootable flash drives with DOS 6.22 and Free DOS, booted from them and ran visicalc (vc.com file).

All rows have index 0 instead of 1,2,3... etc, and I can not enter values in the cells. On my old Asus K53E Laptop all works fine. Also all works fine in Virtual Box.

I understood that Virtual Box is one of the best solutions, but I would like to know the concrete reason why it not works correctly on real hardware and can I fix this incorrect behavior on my hardware. May be somebody observe the same issue.

Art Spasky
  • 183
  • 5
  • 2
    Systems like Virtual Box were created exactly because of this. Modern CPUs/systems are only marginally related to the CPUs/systems that software was made for. It's like bolting a 1920s Ford Model T wheel to a Tesla, jsut because both are american cars. Comments and answers to your last question should have given a hint. – Raffzahn Dec 26 '22 at 00:49
  • I know that, I would like to know what changes in modern computers lead to incompability and is any solution for this. With the wheel from Ford Model T to Tesla there is an concrete answer that explain why it will not work – Art Spasky Dec 26 '22 at 01:25
  • 2
    Well, it you really insist to stretch that, It doesn't fit. Same with your software. After all, have you checked if it's even compatible with DOS 6 or FreeDOS? Or any CPU past 286? Or on a video card like yours? Or from a device as big as that stick? It's most likely DOS1 compatible, thus using FCB access (Might be helpful if you'd at least add what version your're using) You're sitting in front of a complex device with millions of changes from 1983 in hard and software. Pick any... – Raffzahn Dec 26 '22 at 05:21
  • 1
    @Raffzahn none of the issues you specified would obviously make a program use index 0 instead of index 1. I also have a hard time seeing why an old DOS program won’t run on a newer chip, especially since it successfully runs on something much faster than a 4.77MHz 8088. – RonJohn Dec 26 '22 at 22:47
  • 1
    @RonJohn Turbo Pascal 3 provides a very old example of programs mysteriously breaking when being run on a newer machine. A calibration bit in the runtime library did a timing loop which was then divided by to get a counter value. When the machine was fast enough, the loop returned zero and the program crashed. – Thorbjørn Ravn Andersen Dec 27 '22 at 00:26
  • @RonJohn Not sure if it needs a question if it would be 'obvious', would it? But feel free to add more issues ... – Raffzahn Dec 27 '22 at 02:56
  • @ThorbjørnRavnAndersen that was exactly the kind of problem I was thinking of. The difference is that vc.com works perfectly on a 2.5GHz Core i5 CPU, which isn’t that much slower than a single core of whatever’s in a Stinkpad Extreme! Gen 2 OMG. – RonJohn Dec 27 '22 at 08:07
  • @RonJohn As Raffzahn says it can be a million things triggering this behavior. The only way to answer your question 100% correctly is to debug the code (as the source is not available). – Thorbjørn Ravn Andersen Dec 27 '22 at 10:18
  • In my opinion this is the best type of RetroComputing question. Hope you can figure it out, please let us know if you do! (In particular this is hard because, in a travesty, the source code for VisiCalc seems to have been lost to time...) – dashnick Dec 27 '22 at 17:46
  • If we are talking about VC.COM with 27520 bytes, that's obviously generated using (mostly?) auto-translation from Z80 assembly. It makes heavy use of SAHF/LAHF to emulate the 8080/Z80 instructions PUSH AF / POP AF. Especially LAHF is uncommon in typical x86 code and might work improperly. – Michael Karcher Jan 01 '23 at 10:42
  • For further reference: The Thinkpad X1 Extreme Gen. 2 was shipped with a 9th generation Intel Core processor, all models between the i5-9300H and the i7-9850H seem to be available. – Michael Karcher Jan 02 '23 at 09:56
  • 1
    Another example of programs not working as expected on newer hardware. I remember one of the Borland products complaining about not having enough memory on newer PCs. Turned out they used a signed comparison to check memory size and any machine with 512K RAM or more was therefore considered negative, hence less than the (for example) 128K needed to run the product. Or something like that. I remember debugging the code and changing the instruction to an unsigned one to get it going. – paxdiablo Feb 25 '23 at 05:09
  • are you able to compile and run https://github.com/karcherm/proof16 on the affected machine? You need VC.COM in the current working directory, and prints the video memory contents generated by the initial screen draw to the console. It should work in any 32-bit or 64-bit Intel/AMD Linux environment, even WSL2 (but not WSL1). – Michael Karcher Mar 27 '23 at 13:52

0 Answers0