Bertus
-
Aantal items
138 -
Registratiedatum
-
Laatst bezocht
Inhoudstype
Profielen
Forums
Galerij
Kalender
Alles dat geplaatst werd door Bertus
-
Hahaha. Ik heb hier erg van genoten. 🤣 Je hebt natuurlijk een punt hier. Het probleem aan mijn kant is eigenlijk niet zozeer het wachten maar meer het sneuvelen van componenten met bewegende onderdelen. De wetten van de entropie zijn onverbiddelijk...
-
Inmiddels goed bekeken en het ziet er allemaal heel stabiel uit. Ik heb nu een versie 2 van het bordje dat draait rondom een ATF1502 CPLD en een 128 KiB RAM chip. Het kale printplaatje ziet er als volgt uit: Het bordje rust op een bracket om ervoor te zorgen dat de pinnen aan de onderkant geen contact maken met het CPU bord. De 40-pins connector van het CPU bord komt door de uitsparing en wordt met een hele korte 40-lijns bandkabel bevestigd aan de CPU-bord ingang van het CP/M coboard. Aan de zijkant loopt er een tweede 16-lijns bandkabel naar het CPU bord waarop de CP/M bord de 82S123 chip vervangt (de adresdecoder PROM). De bandkabel van het VIDEO bord wordt op de expansiepoort aangesloten. Ik had overigens ook een variant gemaakt met een vrouwelijke header aan de onderkant, maar dan zit het bord net te hoog om comfortabel tussen het CPU bord en het VIDEO bord in te zitten. Vanuit de zijkant ziet het er zo uit:
-
BIS is een stand-alone programma met een eigen set aan systeemtracks en een aparte SLOT1 cartridge. Het draait dus niet op het JWS-systeem, het gebruikt enkel dezelfde hardware (infrastructuur) als JWS. De routines zijn ook wezenlijk verschillend; BIS roept niet een #SAVE of #LOAD aan van JWS, maar heeft daarvoor zelf routines geimplementeerd die verschillen van JWS. In principe kun je een BIS of een JWS bestand op een floppy plaatsen die geformatteerd is met de andere, maar het kan leiden tot corruptie van de schijf dan, want ze gebruiken onder de motorkap andere bestandsindelingen. Nu is BIS netjes geprogrammeerd en alle "DOS" routines zitten op de systeemtracks welke aangeroepen worden via een elegante systeem waarin je in register C een waarde inlaadt en dan een call maakt naar $0005. Die gaat vervolgens naar RAM bank 1 en als je daar dus SD-kaart routines plaatst, dan werkt BIS met de SD-kaart. Dus met een wijziging van die systeemtracks, eigenlijk heel vergelijkbaar hoe SDDOS ook zijn eigen systeemtracks heeft, kun je BIS ook laten draaien met een SD-kaartje. Werkt goed! 🙂
-
Nee dat gaat niet. Het is of JWS-DOS of SD-DOS. Niet allebei tegelijkertijd.
-
Ik ben voor deze lijst heengelopen. De meeste software zijn bestandssysteem routines. Die worden in principe niet meer ondersteund omdat via de SD kaart omdat een andere bestandsindeling wordt gebruikt. Dat zal ik afvangen met een andere tool. AUTORUN bestanden en AUTORUN.CAS, waarvan de laatste bijv. een menuutje heeft, kan makkelijk toegevoegd worden. $AUTOSTART ben ik nergens tegengekomen. Is dat hetzelfde dan?
-
Ik heb een variant gemaakt op JWS DOS, genaamd SDDOS, welke vergelijkbaar werkt zoals JWS maar dan met een SD kaartje in de SD cartridge in plaats van een floppy in een floppydrive. Hieronder een screenshot van een prototype. Het staat allemaal nog een beetje in de steigers, maar het laat al de functionaliteit zoals ik voor ogen heb zien. Je kunt BASIC programmaatjes inladen en opslaan op een SD kaartje. Nu zit ik te stoeien met wat de eindgebruiker nu handig zou vinden. Een SD-kaartje heeft makkelijk 32 GiB capaciteit. JWS liet altijd de capaciteit zien van de floppy, maar bij een SD kaartje duurt dat gruwelijk lang om uit te rekenen op een P2000T (minuten...), maar het is eigenlijk ook een zinloos vraagstuk met zo'n capaciteit. Welnu, als je "INHOUD" draait, dan krijg je een lijst met bestanden te zien. Nu kan die lijst heel lang worden. Op een floppy zou dat beperkt zijn. Om dat te tackelen gebruik ik nu het SYS commando (gebruik onder JWS om van floppystation te wisselen) waarmee je van folder kunt wisselen. Je hebt als het ware 256 virtuele floppies op die SD kaart. (dat zijn gewoon simpele folders onder FAT32) Door middel van die virtuele floppies zou het allemaal behapbaar moeten blijven qua bestandsbeheer. Een andere optie is dat ik in SDDOS ga proberen om echte folderstructuren aan te brengen. Dus meer letterlijk zoals ze op die FAT32 partitie staan. Dan zou ik foldernavigatie moeten gaan inbrengen zoals je vroeger onder MSDOS deed met "CD" en dergelijk. Op logische wijze zou dan ook "MKDIR", "RMDIR" enzovoorts toegevoegd moeten worden. In principe kan dit allemaal (ik gebruik slechts 5 KiB van de 8 KiB in upper RAM voor deze implementatie), maar het doet ergens ook wel weer afbreuk aan het nostalgische karakter, zover die afbreuk al niet gedaan is door de SD kaart natuurlijk... Kortom: ik ben eigenlijk heel erg benieuwd wat jullie ervan vinden en wat jullie zouden aanraden in dit geval.
-
Hier heb ik zeker wat aan! Dank! 🙂
-
Ik heb een oscilloscoop en die ga ik er inderdaad maar eens aanhangen. Heeft wel maar 4 lijnen, maar met wat wisselwerk moet dat goedkomen. Goede tip. Ik had de ATF1502 gekozen omdat deze "op papier" een propagatietijd van 7.5-10ns heeft, maar goed, dat blijft een papieren werkelijkheid. Meten = weten. 🙂
-
Systeemdisk is inderdaad het verkeerde woord. Het zijn gewoon een setje routines die vanaf de floppy in het RAM geheugen geladen worden. Bij CP/M is dit overigens ook zo. Wat zou een goede naam zijn? Op het archief worden het "systeemtracks" genoemd.
-
Ik heb uiteindelijk een ontwerp gemaakt met maar 2 chips: een ATF1502 (CPLD) en een 128 KiB ram chipje. In die CPLD weet ik alle logica af te vangen (niet alleen van de 82S123, maar ook van de andere chips). De broncode voor de CPLD staat hier: https://github.com/ifilot/p2000m-cpm-coboard/blob/master/cupl/p2000m-cpm-coboard.pld Tot nu toe werkt alles stabiel, maar dit is iets wat ik goed moet stresstesten.
-
Ik heb me even moeten verdiepen hoe JWS precies werkt, maar ik denk dat dat wel moet kunnen. De JWS-ROM verschilt maar op 133 bytes van de gewone BASIC-ROM. Het eigenlijke DOS staat op de systeemdisk; de ROM-aanpassing zorgt vooral ervoor dat deze routines worden uitgevoerd. Bij het normale opstarten leest de monitor-ROM 8 KiB van vaste sectoren op de floppy naar RAM op &HE000–&HFFFF. Die 8 KiB bevat aanvankelijk: 4 KiB DOS: de schijfcommando’s, het bestandssysteem en de aansturing van de floppycontroller. 2 KiB initialisatie: code die JWS aan BASIC koppelt en het benodigde geheugen reserveert. 2 KiB directorygegevens: de inhoudsopgave van één kant van de floppy. Na de initialisatie wordt die tijdelijke opstartcode overschreven door directorygegevens. Uiteindelijk gebruikt JWS dus 4 KiB voor DOS en 4 KiB voor twee directorybuffers. Daarom neemt het vrije BASIC-geheugen in JWS ook met +/- 8 KiB af t.o.v. de gewone BASIC. Diezelfde systeemcode kunnen we ook uit de SD-cartridge laden. De bestaande cartridge gebruikt eenzelfde routine al om zijn launcher naar RAM te kopiëren en er is voldoende ruimte op de ROM beschikbaar. Voor dat kopiëren is de SD-kaart zelf niet nodig. In het verlengde hiervan zou het ook mogelijk moeten zijn om in plaats van de floppy drive of het casettedeck de SD kaart te gebruiken om bestanden op te slaan. @Patrick1977 Maar ik vroeg me af: als je een werkende floppy drive hebt en je start JWS op via de SD-cartridge i.p.v. via de systeemfloppy; wat "win" je dan? Uiteindelijk ga je toch die floppy-interface gebruiken?
-
Zonder een boot floppy bedoel je dan?
-
Voor wie er mee wilt spelen: ik heb nu ook een emulator voor de P2000M gebouwd. Naast de CP/M variant van Philips voor de P2000M kun je ook de variant die ik ontwikkeld heb voor de SD-cartridge ermee uitproberen.
-
Het is niet zozeer dat je het attribuutgeheugen nodig hebt, maar meer dat CP/M (en vooral de software geschreven voor CP/M) aanneemt dat je 80-koloms video hebt. Dus als je een 80-koloms uitbreiding op je T hebt, dan zou het ook (met een zeer kleine aanpassing) moeten werken.
-
Het heeft me even gekost, maar met de coboard draait CP/M nu op mijn P2000M. Grote dank nogmaals aan @cancom voor het verschaffen van de schema's en debug hulp! Omdat ik al eerder een SD-cartridge had gemaakt voor de P2000T vroeg ik me af of je CP/M ook via de SD-cartridge kunt draaien in plaats van via de floppy drive. In CP/M kun je immers de BDOS routines aanpassen. Met een SD-kaart heb je een stuk meer opslagcapaciteit (feitelijk voor die tijd gewoon harde schijven...), meerdere drives, en sneller inladen van de programma's. Ik heb daarom op basis van de CP/M v2.2 broncode een variant geschreven die werkt op de P2000M. Hij heeft nu 11 drives + 1 RAM drive (via de 128 KiB geheugenchip in de SD-kaart cartridge) en een TPA van 48.75 KiB. Aan dat laatste ben ik nog aan het sleutelen want het liefste probeer ik tegen de 54 KiB aan te komen die de Philips varianten van CP/M bieden. Ik ben ook nog aan het uitpuzzelen welke programma's lekker draaien op de P2000M. Sowieso alle CP/M programma's die enkel gebruik maken van de BDOS routines, maar wellicht dat het breder is dan dat. Met CP/M heb je naast software ook een hele horde aan leuke adventure spellen. Ik denk dat de bekendste Zork is. Hieronder een screenshot met de bekende opening van Zork.
-
Heb je daar een handleiding ofzo voor want ik blijf normaal gesproken van dat soort "hoogspanning" af.
-
Aangezien deze verkeerd stond op het PPP, kun je ook eens kijken naar de `MCPM.bin` en de `MCPM-system.bin`? Die zijn beiden 8 KiB wat me erg weinig lijkt voor een cartridge en CP/m disk. Idem voor `Seeters.bin` (`CPM Nater.bin` is 8 16 KiB, dus lijkt erop dat die wel klopt).
-
Ik heb hem opgepoetst en kom dan op 4.82V. (gemeten bij koude start) Heb er ook een nieuwe (moderne) op aangesloten en dan krijg ik 5.01V. Ga er dan vanuit dat het niet aan interne weerstanden lag. Vervangen dan maar? Er zat trouwens nergens thermal compound op. Puur metaal op metaal contact.
-
Hele andere vraag: ik heb de 5V lijn eens gemeten op mijn P2000M (hij doet het nog goed, maar was benieuwd) en die zit rond 4.75V. Is dat normaal of is dat een teken aan de wand dat ik de regulators moet gaan vervangen? Iemand ervaring hiermee?
-
Dank voor het puzzelwerk! Ik had bij deze twee rijen `79` en `5C` i.p.v. respectievelijk `F9` en `DC`. Dat is dus inderdaad de foute RAMS2 op de Sanecal PROM. Inmiddels heb ik een printje besteld waarmee ik kan gaan testen.
-
Yes, deze doet het! 🙂 Grote dank wederom! Nog een andere vraag; in de handleiding van het SANECAL CP/M bord wordt de volgende PROM encodering gegeven: 00: 7E 7E 7E 7E FE FE FE FE 7D 7D 7D 7D 7D 7D 7D 7D 10: FD FD FD FD F9 F9 F9 F9 F9 F9 F9 F9 DC DC FD FD Als ik alle signalen naloop dan kan dit gewoon niet werken. Om maar een voorbeeld te geven, in sommige gevallen wordt zowel RAMS1 als RAMS2 signalen geactiveerd. Ik zou verwachten dat deze mutueel exclusief zijn. Als ik alles goed heb doorgelezen, dan zou de mapping eigenlijk als volgt moeten zijn: Dat komt dan overeen met deze encodering: 00: 7E 7E 7E 7E 7E 7E 7E 7E FD FD FD FD FD FD FD FD 10: FD FD FD FD 79 79 79 79 79 79 79 79 5C 5C FD FD Dit is ook hetgeen wat in het tekstbestandje staat dat je me stuurde wat volgens mij jouw persoonlijke notities bevatte. De vraag is simpel: heb je zelf zo'n CP/M bordje gehad en heb je toen de PROM uitgelezen en bleek hetgeen in de handleiding staat gewoonweg niet te kloppen of zijn jouw notities ergens anders op gebaseerd?
-
Grote dank! Ik heb hem "omgeschreven" naar een moderne SRAM geheugenchip; dat maakt alles een stuk dunbevolkter. Ik zag dat in de originele handleiding dat D0 wordt gebruikt voor de flip-flop voor de remapping, maar in jouw notities staat D7. Ik heb de assembly van CP/M nagelopen en het lijkt er op dat het inderdaad D7 moet zijn. Ik ga sowieso nog een keertje alle sporen nalopen. p2000m-cpm-coboard.pdf
-
Ik dacht dat deze voor een T met flop was. Dit is toch een teletekst-editor? Grote dank! Ik ga puzzelen. 🙂
-
Ik heb recent mijn P2000M weer eens uit de berging gehaald. Ik heb alleen de machine, niet de monitor / floppy combinatie die erbij hoort. Buiten de originele monitor die bij de P2000M hoort, heb ik nooit een andere monitor weten te vinden die ik erop aan kan sluiten. Om toch beeld te krijgen heb ik het videosignaal bekeken met mijn oscilloscoop en op basis van het signaal heb ik een adapter gemaakt welke het videosignaal van M omzet naar standaard 640x480@60Hz VGA. Daarmee kan ik de M aansluiten op een moderne(re) monitor. De volgende stap was om de floppy controller aan de gang te krijgen. Ik heb meerdere oude 5.25" floppy drives, maar wou proberen of een floppy drive emulator ook werkt. Ik heb een GoTeK gebruikt en deze werkt na wat aanpassingen als een zonnetje. Met de VGA adapter en de GoTeK heb ik nu een werkend (zij het geemuleerd) systeem. In het PPP heb ik een viertal cartridge + disk combinaties aangetroffen. Disk BASIC Philips P2000M CP/M Nater / Seeters CP/M UCSD Pascal Op dit moment draait alleen Disk BASIC. Ik begrijp dat voor CP/M een speciale print nodig is, welke ik niet heb, waardoor CP/M niet kan draaien. De UCSD loopt vast tijdens het opstarten; ik heb het idee dat de dump van de systeemdisk niet goed is, omdat ik wel de metadata zie van de bestanden maar niet de daadwerkelijke bestanden om te starten. Kan iemand mij verder helpen? Hoe zit dat CP/M bordje in elkaar? Uit de archieven maak ik op dat er 4 verschillende varianten bestaan en dat het een relatief lichte ingreep is. Feitelijk moet de geheugenmap van de M gewijzigd worden, immers, CP/M wil continu geheugen. De monitor en cartridge moeten dus vervangen worden voor RAM en ik neem aan dat het videogeheugen ook anders geaddresseerd moet worden. Heeft iemand (mijn hoop is @cancom) wellicht een schema? Heeft iemand ergens nog de UCSD floppies liggen en kan daar een dump van gemaakt worden?
-
Dank beiden!! De monitorroutines zijn dus voor T en M hetzelfde en op basis van de adresdecoder worden de signalen op de juiste manier naar de componenten gebracht waarbij het enige verschil in die decoder dus feitelijk het videogeheugen is. Verklaart ook meteen waarom de P2000T basic draait op de M. Maar zou andersom dan ook niet moeten draaien? Hoe het videogeheugen in elkaar steekt geeft dan enkel wat visuele artefacten maar buiten dat zou het dan toch moeten draaien met een FDC bord in de T?
