MS-DOS 6.22

Je kan eens proberen of je met je diskettes DOS kan installeren op een virtual machine in Windows. Daarna kan je de benodigde bestanden uit de viruele harddisk kopieren.

Op 31 januari 2020 13:22:06 schreef gj71:

Mijn vraag; Weet iemand war ik de losse files kan vinden? (de diskettes heb ik maar die moeten geïnstalleerd worden). Of heeft iemand toevallig nog een draaiende DOS 6.22 en kan mij mode.exe mailen?

MSDOS 6.22 is te downloaden zowel de Engelse als Nederlandse versie https://winworldpc.com/product/ms-dos/622 dan is de file vanaf die computer te kopiëren. Uit de oude tijd kan ik me herinneren dat io.sys en msdos.sys en command.com nodig was om een PC op te starten en externe commando's zoals mode te kunnen gebruiken.

Mode was nog een .com file...

Mode.zip

1000x dank ARCO! mode.com was het ja

Super. Kijken of ik de boel nu aan de praat krijg...

Als je een moderne pc gebruikt met usb naar com converter dan kun je handshake in 95% van de gevallen vergeten je zult echt een dedicated com-poort moeten hebben on-board of op een PCI kaart.

Beste is om de oude panels te bewaren en daar eventueel iemand naar te laten kijken.

heb een moderne pc maar met een echte com poort on board. (Volgens de specificatie)
dus op papier zou het moeten werken. Ik probeer nog te achterhalen welke chip er gebruikt wordt. Ik herinner me nog iets van goedkope varianten en wat duurdere.. Wel leuk om weer met dos bezig te zijn. het komt allemaal weer terug.

industrieele panel pc ..

Is het wel RS232? Niet 485?

Houd er ook rekening mee dat veel oude DOS programma's direct naar com/lpt poort schreven; dat vindt Windows niet goed...

Een nieuwe pc met DOS werkt ook niet altijd goed. Als het een grafisch programma is, werkt dat meestal niet, omdat de Vesa bios routines er niet meer zijn.
(sinds een jaar of 10 zijn die eruit gesloopt...)

Een WIN95, WIN98 of WIN ME willen ook nog wel eens de oplossing zijn. Je kan deze starten in DOS-mode.

Als orgineel plain MS dos draaide, dan ga je onder elk OS na win 98 een timings probleem krijgen. Je hebt geen direckte toegang tot de serieele poort meer, genoeg elende mee gehad/gezien.

Draait er nu enkel DOS op dit scherm, of in een "container" /VMware?

Waarom geen nieuwe software (W10) om de PLC aan te sturen?

En zorg voor een onboard RS232 verbinding, iets met USB--> RS232 is ook een drama, met een FTDI maak je kans (maar zeker geen garantie!), Prolific besteed ik geen tijd meer aan die gaan linearecta naar het ronde archief

[edit/] Settings: 19200, n, 8, 1, p ? gezien het tijdsbesef van de machines zou ik eerder 9600 eerder verwachten. Maar dat zou je simpel uit een werkende machine kunnen uitlezen, die settings moet je eerst zeker van zijn. zelfs 4800 is een optie, maar nogmaals simpel uit te lezen op en werkende machine, anders even een terminal programmatje mee laten draaien.

MR-direct (DOS programma dat seriële poort bitbangt om een digitale modelspoor centrale te emuleren) draait hier probleemloos op een PC met WIN ME er op. Uiteraard zit er in deze stokoude PC nog een echte 16550 uart.

Wat een boel reactie nog. Dos leeft nog blijkbaar

Het is echt een rs232. Dat verbaasde mij ook. Ging uit van een rs485 maar bleek toch rs232 te zijn. Andere systemen draaiden volgens de bios op 19k2. Kan het altijd nog lager proberen natuurlijk. Maar de bios terug zetten was niet de oplossing.
Heb nu een Vortex x86 panel PC. Daar draait nog dos op. Dos 6.22 gaat probleemloos.
De software is in Pascal geschreven maar de broncode is niet beschikbaar. Dus nieuwe software schrijven wordt erg duur. Als ik de boel aan de praat krijg met mijn nieuwe schermpje, dan is de klant gelukkig.

Scherm dat ik nu gebruik: PDX3-090T-5A. Besteld in Duitsland. Op papier voldoet het aan de specificaties.
Als ik het probleem met de poort heb opgelost moet ik nog iets met de touch driver oplossen. Er zit nu een demo bij die alleen de coordinaten van het scherm terug geeft. Een echte dos driver voor het touch panel moet ik zelf nog schrijven.

Al die DOS en bios settings... vergeet het. In die tijd deed niks wat met drivers. Je software kletste direct tegen de hardware. Kwam geen BIOS of OS aan te pas. En ja, er waren wat BIOS routines. Maar die deden alleen wat met polling. Zodra het interrupt based werd (en dat werd het eigenlijk altijd wel...) mocht je het zelf schrijven. Inclusief de initialisatie (bitrate, frame length etc.).
Het enige waar de BIOS voor gebruikt werd, was uitvlooien op welke hardware adressen de daadwerkelijke hardware zat - dat lag niet 100% vast. Als ik het me goed herinner had je ergens een table waarin BIOS veel van dat soort dingen uit haalde. Daar scoorde je het 'base address' en vanaf daar mocht je zelf verder.

Als je zelf nog een DOS bak hebt, zou je ff kunnen kijken of je nog ergens een DOS debugger kunt scoren en ff kijken of je de initialisatie kunt vinden. Die code is meestal vrij plat en dus ook in assembly goed te volgen. Datasheet van een 8250 ernaast, dan moet dat te volgen zijn.

Je schrijft dat het spul in Pascal geschreven is. Is dat toevallig Turbo Pascal (of later: Borland Pascal)? Begin 90-er jaren heb ik heel veel met Turbo Pascal gedaan - Borland Pascal was al wat meer OO, dat was de hype op dat moment.
Een issue waar ik me rot naar gezocht heb, is dat op de development 386 de boel prima draaide, maar op de productie 486 gewoon niet. Het uiteindelijke probleem bleek te zitten in een library. Die maakte gebruik van 'delay'. En dat hadden ze niet moeten doen.
In de runtime lib van Turbo Pascal werd 'delay' in de init gecalibreerd. Er werd een interrupt geset die op de BIOS timer (ik meen 18.2Hz) een schop kreeg. In de handler werd wat met flags gedaan. Op de eerste call werd een loopje gestart wat niks anders deed dan 'variable +1'. Op de 2de call werd gekeken hoe ver men gekomen was. En dat was een maat voor de snelheid van de betreffende PC. Men wist tot waar men moest tellen voor 1mS delay. Helaas, men had er een 16-bit variabele voor genomen. Op een 486 had die last van overflow - de machine telde te snel tussen 2 interrupts. Het gevolg was dat alle delays heel veel te kort duurden - en dus alle timing in die betreffende lib de mist in ging.

Ik weet niet waar het oorspronkelijk op draaide, maar zou dat bij jou een issue kunnen zijn? Communicatie blijft voor heel veel programmeurs toch iets erg moeilijks, er is (en wordt...) heel wat afgekl**t. Ik kan me er best wat bij voorstellen dat een prutselaar (combinatie van prutser en knutselaar) ergens de boel niet aan de praat kreeg en vond dat het te snel ging, en dat vervolgens met een handje delays heeft 'opgelost' (ofwel: het symptoom onderdrukt heeft).

De kort-door-de-bocht oplossing was 'slowpc' aan het werk zetten. Dat was een tool die botweg clock cycles stond weg te stoken om de PC trager te maken. Met name voor spelletjes - die ook wel eens last hadden van dergelijke problemen. Een korte search leverde dit op. Wellicht kun je er wat mee.

Helaas (voor jou) zijn alle floppies met Pascal en DOS tools (incl. DOS 6.22) een half jaar geleden 'opgeruimd' - stonden inmiddels 5+ jaar zonder gebruik, geen van mijn klanten heeft nog wat met DOS draaien. Dus 'mijn' tools kan ik je niet meer aan helpen.

Ik heb ook heel veel lol gehad van zoiets in die tijd. Je kunt zien wat er gebeurt.

Daarnaast is 'handshaking' (flow control) met een 'nullmodemkabel' ook vaak wel een soort van avontuur. Daar de complete aansturing 'custom' was en er niet echt een duidelijke 'afspraak' was over hoe het moest werken, ging dat dus vaak mis. In basis kon het in software (start en stop tokens terug sturen, deden printers wel. Doorgaans een soort van simplex communicatie) of in hardware. In hardware kon het RTS/CTS of DTR/DSR zijn. En een hele enkele creatieve geest keek ook nog naar CD.
Als de ene kant DTR/DSR wilde en de andere kant RTS/CTS, dan was niet zelden de oplossing om de boel in de kabel gewoon zo aan elkaar te knopen. Per saldo werd dat ook een 'null modem kabel' genoemd. Daarmee is de 'definitie' van 'null modem kabel' erg ambigu.
Als het met exact diezelfde kabel op een andere PC wel gewerkt heeft, dan zal daar het probleem waarschijnlijk niet zitten.

Dank voor je uitgebreide reactie EricP.

De laatste versie van de software komt uit 1998. De eerste versies zijn vanaf 1994. Ik weet het niet zeker maar denk dat het turbo Pascal is.
In de bios kan ik de snelheid van de com poort aanpassen. maar dat lijkt niets te veranderen. Vandaar dat ik opzoek was naar mode.com.
De kabel die ik gebruik werkt goed met een bestaand systeem op de testopstelling. Dus de null modem kabel lijkt in orde.
In de config files van de executable kan ik iets met de snelheid van de PC regelen. Dis staat nu op 'FAST'. Een van de 'ouders' systemen draait op dezelfde CPU als mijn huidige bordje. Dus dat lijkt ook ok.
Maar ik ga wel iets proberen met slowpc. eens kijken wat dat doen. Misschien toch iets met timings die niet goed gaan.

In de bios kan ik de snelheid van de com poort aanpassen. maar dat lijkt niets te veranderen. Vandaar dat ik opzoek was naar mode.com.

De bitrate op een 8250 setten is niks anders dan een divisor instellen. In hardware is loopt er een klok, de waarde die jij instelt wordt in een counter gefrot en als je bij 0 bent wordt de volgende clock aan de daadwerkelijke shiftregisters gegeven.
Dat is het simpele stuk. De BIOS zal daar wel wat in kunnen setten. mode zal dat ook wel kunnen. En de gemiddelde prutselaar kreeg dat ook nog wel voor elkaar.

In de config files van de executable kan ik iets met de snelheid van de PC regelen. Dis staat nu op 'FAST'. Een van de 'ouders' systemen draait op dezelfde CPU als mijn huidige bordje. Dus dat lijkt ook ok.

Dezelfde CPU... maar clocked die ook even snel? Lomp gezegd: wat gebeurt er als je de disk uit die machine in die van jou frot? Loopt het dan nog steeds? (zo ja: je hebt een config issue, zo nee: er is een verschil in hardware / BIOS settings).

Je zegt dat je wel een verbinding kunt opzetten, maar dat die 'stuk' gaat. Derhalve moet de bitrate goed zijn - anders kun je helemaal niks.

Daarbij denk ik dan nog ff hoe ik zelf destijds met mijn interrupt routines heb zitten stoeien. Het spelletje werkt als volgt: als de UART een character naar binnen heeft geschoven, werd dat naar een 'reading' register gecopieerd (zo is het shift register klaar voor de volgende) en er werd een interrupt gegenereerd (hardware buffering deden we in die tijd nog nauwelijks). De ISR moest dan dat character uitlezen, ergens in een buffer frutten, wat dingetjes resetten (zodat de volgende interrupt kon komen) en iets met IRET doen[edit]Nee, dat was de lompe manier. De nette manier was een jump naar de handler die er voordat je jouw eigen handler sette stond[/edit]. Daar zit iets 'naars' in en wel dat je een deadlock kunt fabrieken. De 'reset' van de UART was de READ van het holding register. De 'reset' van de interrupt controller moest je zelf doen. Dat is niet atomair - het is mogelijk dat de UART het volgende character klaar heeft, een interrupt genereert waarop jij de interrupt controller reset en er vervolgens niks meer gebeurt (immers... de interrupt controller weet niet dat er nog meer is, die is net gereset, de UART staat braaf te wachten tot er wat uitgelezen wordt). Ook daar was in software wel omheen te werken, maar ja, prutselaars. In de praktijk liep het eigenlijk wel los. Ook op 115k2 - er draaide immers geen OS wat vanalles qua timing verziekte.
In die context is 'sneller' altijd 'beter', dus zo op het oog zou een snellere machine geen probleem mogen zijn.

Dan nog ff over die interrupts... De oorspronkelijke PC had er 8. Toen de AT kwam werden dat er 15. De truc was dat een 2de interrupt controller werd geïntroduceerd en die hing als slave aan de eerste (vandaar dat het er 15 werden en geen 16). Voor de UARTS maakte dat niet zo heel veel uit, die hingen min of meer 'fixed' aan de eerste. Later (toen het meer de kan van PCI enzo uit ging) werden 'shared interrupts' gebruikelijker. Heel veel software kan daar niet mee overweg. Ook werd de gebruikte interrupt variabel. Oudere software kent dat vaak niet. Als je het al in kan stellen, dan is het vaak beperkt tot de 1e controller, omdat ze (in de context van 'serieel') het verhaal '2de controller' gewoon niet kennen.
Shared interrupts werden ook vaak 'naar' als je meer dan 2 poorten had. De hardware kon het zondermeer. Maar veel software snapte het niet.
Kijk nog ff of je in de BIOS wat kunt instellen. COM1 'hoort' op IRQ4 (als ik het me goed herinner). COM2 op IRQ3. Dan was er nog een halve standaard dat COM3 ook op IRQ4 zat en COM4 op IRQ3, maar heel veel 'drivers' snapten dat niet (konden niet met 'shared' overweg) waardoor men die vaak op 2, 5 of 7 zette. So far, so good. Echter... IRQ2 op een PC gedraagt zich anders dan IRQ2 op een AT. Dat heeft met die 2de interrupt controller te maken - die gebruikte IRQ2.
Als de software (driver) het verschil tussen PC en AT niet kent, dan gaat een UART op IRQ2 niet werken - de interrupt controller(s) moeten anders aangestuurd worden.

En eh... het klinkt als iets met 'productie'. Maar ik neem aan dat je zelf wel snapt dat je met dingen van andere machines gebruiken even goed moet nadenken over wat je doet en dat er wel een weg terug moet zijn.

Sorry als het verhaal zo hier en daar wat warrig is. Het is een 25-30 jaar terug dat ik hier actief in was en het is geen parate kennis meer...

Ik denk dat je je beter af kunt gaan vragen of je dit zo nog in stand wilt houden.spul is al jaren obsolete en naar de toekomst toe moet je toch iets.

Mijn idee is eerder om of een dedicated terminal te maken op een linux omgeving. Bijv met een raspberry

Of weer anders: met een microcontroller en een hmi werken

Of nog anders en echt industrieel. Plc met rs232 en hmi.

Alles in verschillende gradaties van kosten.

Nadeel is dat je eerst de huidige communicatie moet reverse engineeren...

Dank voor de reacties weer.
Voor mij is het ook steeds even graven in oude kennis. Maar wel leuk om het weer te doen.

De linux/ raspberry oplossing is overwogen. Maar het aantal machines dat jaarlijks vervanging van de Panel PC nodig heeft is beperkt. het idee is dat er nog max 10 jaar onderhoud gegeven wordt, en dat moet zo goedkoop mogelijk. Als dit gaat werken, dan liggen er 10 op voorraad voor de komende jaren.

voor de toekomst is er een geheel nieuwe machine gebouwd met nieuwe software. Nieuwe klanten kunnen alleen daarvoor kiezen. Die is sinds een jaar of 2 in productie.

Ik las 'twisted pair' en dacht direct aan RS485 (of CANbus, ModBus etc.)

Hoeveel draden zitten er nu aan die 'COM' poort?

Bij twee moet het wel een differential iets zijn wanneer daar data over heen en weer gaat. Bij drie zou het nulmodem RS232 kunnen zijn.

EricP heeft inderdaad gelijk. BIOS settings doen helemaal niets.

Oude DOS software schrijft direct naar de UART registers zonder tussenkomst van iets. Vrijwel altijd hardcoded INT nummers 4 en 3 voor COM1/COM2.

Vergeet heel dat "mode com blabla" verhaal want daar heb je niks aan. In mijn hele carriere heb ik daar nog nooit iets van zien werken.

Interrupt sharing werkt helemaal niet met COM1/3 (of 2/4) want de lijnen zijn totempole typen en high active. Heeft niks met software te maken die het niet zou begrijpen, kan niet werken omdat de hardware dat niet ondersteund.

Maar je zegt zelf in je openingspost:

De panel PC maakt verbinding via een rs232 nul modem verbinding (twisted pair) en gebruikt een hardware handshake. Tot zover krijg ik alles aan de praat. Maar als de verbinding is opgezet, dan verlies ik connectie en probeert de software opnieuw verbinding te maken.

Dat is tegenstrijdig: Eeen null-modem kabel is intern doorverbonden en gebruikt dus geen handshaking.

Misschien zit er helemaal geen handshaking in en werkt het door toeval op de oude configuratie en met een nieuwe panel-PC veel te snel (Zie EricP zijn verhaal).

Dus ik zou eens checken hoe die kabel precies aangesloten is.
Anders post de exacte verbindingen eens hier op het forum?

Wat ook kan is dat je nieuwe panel PC het niet zo nauw neemt met de officiele RS232 levels en dat ze domweg 0-5V uitsturen. Dan zit er wel een echte com poort in maar is het nog "brak".

P.S.: Ik heb ook ergens nog 3 (floppy) images rondzwerven van MSDOS 6.22 een aantal jaren geleden gebruikt om een zaagmachine met soortgelijk probleem op te lappen.

[offtopic]

Interrupt sharing werkt helemaal niet met COM1/3 (of 2/4) want de lijnen zijn totempole typen en high active. Heeft niks met software te maken die het niet zou begrijpen, kan niet werken omdat de hardware dat niet ondersteund.

Dat is BS. Uitgaande van een ISA bus (daar praten we tenslotte over in deze tijd...) is het volledig afhankelijk van het insteekkaartje (!) wat je gebruikte. De kaartjes die het netjes deden, konden het prima, zo leert (of eigenlijk: leerde) de ervaring.

Het grote probleem was altijd dat veel software het niet snapte. De 'nette' ISR deed iets van 'ff kijken of deze voor mij is, zo ja: handel af. Jump naar de routine die voor mij geregistreerd was'. Zo kon je een chain van handlers bouwen. De praktijk was vaak 'handel af. IRET'. En daarmee kon alleen de laatste die zich in de 'chain' gefrut had wat. Zoals gezegd: veel programmeurs snappen hardware niet.

Dat is tegenstrijdig: Eeen null-modem kabel is intern doorverbonden en gebruikt dus geen handshaking.

Dat is dus precies wat ik beschreef: er is geen harde definitie van een 'null modem kabel'. Daarmee is het begrip ambigu. In mijn beleving is de praktijk doorgaans RTS/CTS en DSR/DTR netjes van de ene naar de andere kant de meest 'universele' variant.

RS232 op een PC was bedoeld voor (half duplex!) modem aansturing. En de enige handshaking die daar plaats vond was tussen modem en PC. Als je dat volledig zou willen implementeren, dan zou je dus een RTS moeten setten, wachten op CTS en dan eens gaan praten met de buitenwereld. Dat doet dus geen hond, want half-duplex modems hebben (in combinatie met een PC) maar heeeeel even 'bestaan'. Ik ken nog wel de 300bps zonder autodail: zelf het nummer bellen en zodra je een carrier kreeg een knopje op het modem omzetten. Magisch dat je dan wat van een computer 100km verderop zag! Maar ook dat modem was al full-duplex.[/offtopic]
Gelukkig is de kabel 'known good' voor deze software als ik TS goed begreep - het heeft ermee gewerkt.

Wat ook kan is dat je nieuwe panel PC het niet zo nauw neemt met de officiele RS232 levels en dat ze domweg 0-5V uitsturen.

In die context zou het 'probleem' ook nog een MAX232 ofzo kunnen zijn. Oorspronkelijk werden RS232 signalen door een 1488 (en een 1489) geinterfaced naar TTL. Die werd met + en - 12V gevoed en stuurde veel 'harder' dan een MAX232 met z'n charge pump (feitelijk was het voor zover ik weet gewoon een totem pole tussen + en - 12V. Over 'flanken op lange kabels' deed men toen nog niet zo moeilijk .
Beiden voldoen waarschijnlijk wel aan de spec. Maar ik kan me zo voorstellen als het met kabels 'op het randje' zit, moderner spul het net niet redt.

Woensdag ben ik weer bij de klant en kan ik weer wat dingen proberen.
Mijn grootste zorg nu is dat de rs232 geen echte rs232 is maar intern gewoon een USB is. Geen idee hoe ik daar achter kan komen. Ik probeer nog ergens iets vandaan te halen waarmee ik de data kan uitlezen die over de kabel gaat.

Ik ga nog naar de kabels in de testopstelling kijken. Of het niet stiekem toch een rs485 is.
Ik kan wat dingen proberen met mode. (al heb ik daar weinig vertrouwen in)
En ik kan misschien wat filmpjes en foto's maken om te delen.

Hang er eens een scoop aan. Bekijk de signaalniveaus. Veel kans dat het 'RS232' is met TTL signaal niveau's.

Op een bepaald ogenblik moet je als bedrijf ook durven zeggen dat de ondersteuningstermijn overschreden wordt. MS-DOS 6.22, dan spreken we tenslotte over 1994. Of 26 jaar geleden. In de beginperiode van de RS232 muis was het bij momenten al een uitdaging om deze werkende te krijgen. Zeker als je 4 com poorten gebruikte en 2 printerpoorten. Een goede insteekkaart kon je de IRQ nog instellen.

Systemen met Hercules, CGA en EGA kan je ook niet meer overeind houden.

Nieuwe PLC lijkt mij de meest adequate oplossing op langere termijn.

Bij ons zijn de SCADA pc's ook eindelijk vervangen nadat er VM-ware nodig was om de oude XP software nog te draaien. XP-drivers waren er dan weer niet meer voor de moderne PCs.

Scada, daar loopt de zooi aan boord (zie koffiecorner) nog op.
15 Jaar oud..

gj71,

ik heb in het verleden stapels software in Pascal gemaakt. Van TurboPascal 3.0, tot Delphi, Embarcadero etc. Als je mij eens wat stuurt kan ik wel even kijken wat het is. Als je wil teken ik wel een NDA of zo.

Ik heb pas geleden ook nog een oude MSDOS-gebaseerde machine weer werkend gekregen. Ik doe dat soort dingen wel vaker.

Over R232: tegenwoordig worden termen foutief gebruikt. Met RS232 bedoelen ze niet meer de hardware layer uit het OSI model (wie kent dat nog). Maar ze bedoelen het protocol. Dat protocol wordt bij een USB poort met 0V (0) en 5V (1) uitgevoerd, op sommige plaatsen op de PCB met 3V3. Waar RS232/V.24 meestal -12V en +12V is. Er worden vanuit onkunde wel vaker termen foutief gebruik, dat kan je best wel op het verkeerde been zetten.

5V-TTL signaalniveaus naar de normale 12V RS232 omzetten is niet moeilijk met een MAX232. Bij lange verbindingen is het best wel verstandig met current loop de zaak galvanisch te scheiden.

Als je de sources in Pascal hebt kan ik wel even kijken of ook de andere signalen van de RS232 poort gebruikt worden. DTR, RTS, CTS etc. Het kan ook zijn dat een XON/XOFF protocol gebruikt is.

Zonder sources van PC en PLC wordt het moeilijk.