![[Valid RSS]](images/valid-rss-rogers.png "Valid RSS")
This is a valid RSS feed.
This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.
line 86, column 3: (818 occurrences) [help]
]]></content:encoded>
^
<p><video width="100%" autoplay loop muted><source src="docs/silo_38911/silo ...
line 153, column 0: (5 occurrences) [help]
<p><iframe width="560" height="315" src="https://www.youtube-nocookie.com/em ...
line 329, column 0: (10 occurrences) [help]
<div style="display: flex; flex-flow: row wrap;">
line 7152, column 0: (2 occurrences) [help]
<h2 id="functionality->-4-kb”>Functionality > 4 KB</h2>
<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" > <channel> <title>pagetable.com</title> <atom:link href="https://www.pagetable.com/?feed=rss2" rel="self" type="application/rss+xml" /> <link>https://www.pagetable.com</link> <description>Some Assembly Required</description> <lastBuildDate>Sun, 21 Apr 2024 12:50:49 +0000</lastBuildDate> <language>en-US</language> <sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>1</sy:updateFrequency> <generator>https://wordpress.org/?v=4.9.25</generator> <item> <title>64’er Magazin 5/84</title> <link>https://www.pagetable.com/?p=1768</link> <comments>https://www.pagetable.com/?p=1768#respond</comments> <pubDate>Sun, 21 Apr 2024 12:50:49 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Literature]]></category> <category><![CDATA[VIC-20]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1768</guid> <description><![CDATA[Die Ausgabe 5/84 ist nun auf www.64er-magazin.de verfügbar. Vielen Dank an goloMAK, Endurion und Drachen für das Abtippen der Listings! Neu ist auf der Website zudem: Während über das Inhaltsverzeichnis jetzt schon alle Artikel verfügbar sind, werden auf der Startseite die Artikel nach und nach gepostet, genauso wie im RSS. Alle Fehler in Artikeln, die ... <a title="64’er Magazin 5/84" class="read-more" href="https://www.pagetable.com/?p=1768">Read more<span class="screen-reader-text">64’er Magazin 5/84</span></a>]]></description> <content:encoded><![CDATA[<p>Die Ausgabe 5/84 ist nun auf <a href="https://www.64er-magazin.de/">www.64er-magazin.de</a> verfügbar. Vielen Dank an <a href="https://www.forum64.de/wcf/index.php?user/28439-golomak/">goloMAK</a>, <a href="https://www.forum64.de/wcf/index.php?user/1964-endurion/">Endurion</a> und <a href="https://www.forum64.de/wcf/index.php?user/9125-drachen/">Drachen</a> für das Abtippen der Listings!</p><p>Neu ist auf der Website zudem:</p><ul><li>Während über das Inhaltsverzeichnis jetzt schon alle Artikel verfügbar sind, werden auf der Startseite die Artikel nach und nach gepostet, genauso wie im RSS.</li><li>Alle Fehler in Artikeln, die in einem “Fehlerteufelchen” Abschnitt korrigiert werden, sind durch eine rote Unterstreichung markiert, und über einen Klick gelangt man zur Korrektur. (Fehler in Listings sind weiterhin direkt korrigiert.)</li></ul><p>Zur nächsten Ausgabe sind folgende Features der Website geplant:</p><ul><li>Bessere Darstellung auf mobilen Endgeräten</li><li>Artikel werden auf Mastodon gepostet</li></ul>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1768</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>64’er Magazin – mit 40 Jahren Verzögerung jetzt monatlich im Web</title> <link>https://www.pagetable.com/?p=1764</link> <comments>https://www.pagetable.com/?p=1764#comments</comments> <pubDate>Wed, 20 Mar 2024 08:15:35 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[C128]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[GitHub]]></category> <category><![CDATA[Literature]]></category> <category><![CDATA[VIC-20]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1764</guid> <description><![CDATA[Zum 40jährigen Jubiläum des 64’er Magazins präsentieren wir das Kunstprojekt www.64er-magazin.de: eine Website, die so tut, als wäre 1984. Exakt 40 Jahre nach der ursprünglichen Veröffentlichung erscheint hier jeden Monat eine neue Ausgabe: 4/84: 20. März 2024 (Erstausgabe) 5/84: 19. April 2024 6/84: 18. Mai 2024 usw. Auf der modernen Homepage gibt es durchsuchbare PDF-Dateien ... <a title="64’er Magazin – mit 40 Jahren Verzögerung jetzt monatlich im Web" class="read-more" href="https://www.pagetable.com/?p=1764">Read more<span class="screen-reader-text">64’er Magazin – mit 40 Jahren Verzögerung jetzt monatlich im Web</span></a>]]></description> <content:encoded><![CDATA[<p>Zum 40jährigen Jubiläum des <em>64’er Magazins</em> präsentieren wir das Kunstprojekt <a href="https://www.64er-magazin.de">www.64er-magazin.de</a>: eine Website, die so tut, als wäre 1984. Exakt 40 Jahre nach der ursprünglichen Veröffentlichung erscheint hier jeden Monat eine neue Ausgabe:</p><ul><li>4/84: 20. März 2024 (Erstausgabe)</li><li>5/84: 19. April 2024</li><li>6/84: 18. Mai 2024</li><li>usw.</li></ul><p>Auf der modernen Homepage gibt es</p><ul><li>durchsuchbare PDF-Dateien der einzelnen Ausgaben</li><li>alle Artikel im Web-Format mit Kommentar-Funktion</li><li>alle Listings zum Download statt zum Abtippen</li><li>Übersichtsseiten für alle Tests, alle Listings etc. über alle Ausgaben hinweg</li><li>eine Suche über den Text aller Artikel</li><li>einen RSS-Feed, der ab Veröffentlichung jeden Tag zwei Artikel liefert</li><li>die Funktion, einen Artikel auf Mastodon zu teilen</li></ul><p>Alle Artikel sind mit dem Text im gedruckten Magazin identisch, Schreibfehler und sachliche Fehler sind also unverändert. Errata aus späteren Ausgaben (“Fehlerteufelchen”) werden den Artikeln allerdings angehängt, und später dokumentierte Fehler in Software sind in den Downloads bereits behoben.</p><p>Verbleibende Unterschiede im Text sowie Verbesserungen der Website sind auf <a href="https://github.com/mist64/64er-magazin.de">GitHub</a> willkommen.</p><p><img src="docs/64er-magazin/64er-magazin1.png" alt="" /></p><p><img src="docs/64er-magazin/64er-magazin2.png" alt="" /></p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1764</wfw:commentRss> <slash:comments>10</slash:comments> </item> <item> <title>Silo S01E06: 38911 BYTES FREE</title> <link>https://www.pagetable.com/?p=1760</link> <comments>https://www.pagetable.com/?p=1760#respond</comments> <pubDate>Fri, 21 Jul 2023 20:53:22 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[BASIC]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Trivia]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1760</guid> <description><![CDATA[]]></description> <content:encoded><![CDATA[<p><img src="docs/silo_38911/silo_38911.png" width="500" height="300"></p><p><video width="100%" autoplay loop muted><source src="docs/silo_38911/silo_38911.mp4" type="video/mp4"></video></p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1760</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>[Ankündigung] Vortrag “Apollo Guidance Computer” an der Embedded Computing Conference in Winterthur</title> <link>https://www.pagetable.com/?p=1753</link> <comments>https://www.pagetable.com/?p=1753#comments</comments> <pubDate>Tue, 16 May 2023 12:44:05 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Archeology]]></category> <category><![CDATA[Presentation]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1753</guid> <description><![CDATA[This post is about an upcoming talk in German. Am Dienstag, den 06. Juni 2023 um 9:00 gibt es auf der Embedded Computing Conference in Winterthur (bei Zürich) meinen Vortrag zum Thema “Apollo Guidance Computer im Kontext von modernen Embedded Systems und Echtzeit-Betriebssystemen”. Beim Vortrag handelt es sich um eine abgewandelte und erweiterte Version des ... <a title="[Ankündigung] Vortrag “Apollo Guidance Computer” an der Embedded Computing Conference in Winterthur" class="read-more" href="https://www.pagetable.com/?p=1753">Read more<span class="screen-reader-text">[Ankündigung] Vortrag “Apollo Guidance Computer” an der Embedded Computing Conference in Winterthur</span></a>]]></description> <content:encoded><![CDATA[<p><em>This post is about an upcoming talk in German.</em></p><p>Am Dienstag, den 06. Juni 2023 um 9:00 gibt es auf der <a href="https://www.swisst.net/swisstevents/eventdetails/?eventid=1&scrollsingleexecution=62#!/?eventid=1&scrollsingleexecution=62">Embedded Computing Conference</a> in Winterthur (bei Zürich) meinen Vortrag zum Thema “<em>Apollo Guidance Computer im Kontext von modernen Embedded Systems und Echtzeit-Betriebssystemen</em>”.</p><p><img src="docs/agc_ecc/agc_ecc.jpg" height="400" width="710" alt="" /></p><p>Beim Vortrag handelt es sich um eine abgewandelte und erweiterte Version des <a href="https://www.pagetable.com/?p=922">Ultimate Apollo Guidance Computer Talk</a> von Christian Hessmann und mir. Diese Version vertieft sich in die Software-Architektur und betrachtet den AGC aus dem Blickwinkel von <em>modernen</em> Echtzeitsystemen – schließlich handelt es sich um eine Konferenz über Embedded Systems!</p><p>Die eintägige Konferenz besteht aus 30 weiteren Vorträgen auf 3 bis 4 Tracks. Der Eintritt ist <strong><a href="https://www.swisst.net/swisstevents/eventdetails/?eventid=1&scrollsingleexecution=62#!/?eventid=1&scrollsingleexecution=62">nach vorheriger Anmeldung</a></strong> kostenlos.</p><p><a href="https://www.swisst.net/swisstevents/eventdetails/?eventid=1&scrollsingleexecution=62#!/?eventid=1&scrollsingleexecution=62"><img src="docs/agc_ecc/ecc2023.png" height="335" width="659" alt="" /></a></p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1753</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item> <title>The Easter Egg in the “Schrott-Tornado” at the Deutsches Museum</title> <link>https://www.pagetable.com/?p=1750</link> <comments>https://www.pagetable.com/?p=1750#comments</comments> <pubDate>Mon, 26 Dec 2022 19:21:05 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Archeology]]></category> <category><![CDATA[Hardware]]></category> <category><![CDATA[Puzzle]]></category> <category><![CDATA[Teardown]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1750</guid> <description><![CDATA[The Deutsches Museum in Munich (Germany) has a new art installation as part of the reopened Electronics exhibition: The “Schrott-Tornado”, a tornado-shaped sculpture made from scrap electronics. There is (at least) one item in it that is most definitely not trash. Here is a picture of the full sculpture: Let’s zoom into the interesting part: ... <a title="The Easter Egg in the “Schrott-Tornado” at the Deutsches Museum" class="read-more" href="https://www.pagetable.com/?p=1750">Read more<span class="screen-reader-text">The Easter Egg in the “Schrott-Tornado” at the Deutsches Museum</span></a>]]></description> <content:encoded><![CDATA[<p>The Deutsches Museum in Munich (Germany) has a new art installation as part of the reopened Electronics exhibition: The “Schrott-Tornado”, a tornado-shaped sculpture made from scrap electronics. There is (at least) one item in it that is most definitely not trash.</p><p>Here is a picture of the full sculpture:</p><p><img src="docs/schrott_tornado/schrott_tornado.jpg" alt="" /></p><p>Let’s zoom into the interesting part:</p><p><video width="100%" autoplay loop><source src="docs/schrott_tornado/schrott_tornado_zoom.mp4" type="video/mp4"></video></p><p>And this is a high-res photo of the detail. You might recognize it.</p><p><img src="docs/schrott_tornado/schrott_tornado_detail.jpg" alt="" /></p><p>And now look closely at what’s written on the cartridge port shield.</p><p>Related: Here’s the Schrott-Tornado Making-Of video:</p><p><iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/CaCB8QQ8zjY" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe></p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1750</wfw:commentRss> <slash:comments>4</slash:comments> </item> <item> <title>darmok.com: Memes in the Tamarian Language</title> <link>https://www.pagetable.com/?p=1747</link> <comments>https://www.pagetable.com/?p=1747#comments</comments> <pubDate>Sun, 25 Dec 2022 13:30:43 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1747</guid> <description><![CDATA[I have created darmok.com, a website that lets you share common memes in the Tamarian language. Try it out, and fork at github.com/mist64/darmok!]]></description> <content:encoded><![CDATA[<p>I have created <a href="http://darmok.com">darmok.com</a>, a website that lets you share common memes in the Tamarian language.</p><p>Try it out, and fork at <a href="https://github.com/mist64/darmok">github.com/mist64/darmok</a>!</p><p><a href="http://darmok.com"><img src="docs/darmok/darmok_meta.jpg" alt="" /></a></p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1747</wfw:commentRss> <slash:comments>4</slash:comments> </item> <item> <title>PostScript Cartridge for HP LaserJet</title> <link>https://www.pagetable.com/?p=1721</link> <comments>https://www.pagetable.com/?p=1721#respond</comments> <pubDate>Sat, 24 Dec 2022 20:00:31 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Archeology]]></category> <category><![CDATA[PostScript]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1721</guid> <description><![CDATA[We have recently dissected and dumped the Level 2 “Plus” version of HP’s PostScript cartridge series. This time, we will look at the earlier Level 1 “PostScript Cartridge”. Article Series There are two cartridges for the HP LaserJet series that add Adobe PostScript support. They differ in the PostScript Level: Year Name Description 1991 HP ... <a title="PostScript Cartridge for HP LaserJet" class="read-more" href="https://www.pagetable.com/?p=1721">Read more<span class="screen-reader-text">PostScript Cartridge for HP LaserJet</span></a>]]></description> <content:encoded><![CDATA[<p>We have recently dissected and dumped the <a href="https://www.pagetable.com/?p=1673">Level 2 “Plus” version</a> of HP’s PostScript cartridge series. This time, we will look at the earlier Level 1 “PostScript Cartridge”.</p><p><a href="docs/postscript_cartridge/postscript_cartridge_case.jpg"><img src="docs/postscript_cartridge/postscript_cartridge_case.jpg" height="276" width="302" alt="" /></a></p><h2 id="article-series">Article Series</h2><p>There are two cartridges for the HP LaserJet series that add Adobe PostScript support. They differ in the PostScript <a href="https://en.wikipedia.org/wiki/PostScript#History">Level</a>:</p><table><thead><tr><th> Year </th><th> Name </th><th> Description </th></tr></thead><tbody><tr><td> 1991 </td><td> <a href="https://www.pagetable.com/?p=1721">HP LaserJet PostScript Cartridge</a> </td><td> PostScript Level 1 </td></tr><tr><td> 1991 </td><td> <a href="https://www.pagetable.com/?p=1673">HP LaserJet III PostScript Cartridge Plus</a> </td><td> PostScript Level 2 </td></tr></tbody></table><p>Note that the article on the Level 2 “Plus” cartridge is the main one. This article only describes the differences of the Level 1 cartridge to the Level 2 cartridge.</p><h2 id="cartridge">Cartridge</h2><p>The cartridge is about 9×14 cm in size.</p><p><a href="docs/postscript_cartridge/postscript_cartridge_case_front.jpg"><img src="docs/postscript_cartridge/postscript_cartridge_case_front.jpg" height="380" width="269" alt="" /></a><a href="docs/postscript_cartridge/postscript_cartridge_case_back.jpg"><img src="docs/postscript_cartridge/postscript_cartridge_case_back.jpg" height="391" width="270" alt="" /></a></p><p>The front says</p><blockquote><p>HEWLETT PACKARD</p><p>PostScript* Cartridge</p><p>ITC Avant Garde Gothic<em><br />ITC Bookman</em><br />Courier<br />Helvetica<em><br />Helvetica-Narrow<br />New Century Schoolbook<br />Palatino</em><br />Times<em><br />ITC Zapf Chancery</em><br />TIC Zapf Dingbats*<br />Symbol<br />33439Q ©Hewlett-Packard 1989, 1990, 1991</p><p>HP<br />LASERJET<br />POSTSCRIPT®</p></blockquote><p>The back says</p><blockquote><p>Adobe and PostScript are registered trademark of Adobe Systems<br />Incorporated in the U.S, and other countries. Helvetica, Palatino and<br />Times Roman are registered trademarks of Linotype AG and/<br />or its subsidiaries in the U.S. and other countries. IT Avant Garde<br />Gothic, ITC Bookman, ITC Zapf Chancery and ITC Zapf Dingbats are<br />registered trademarks of International Typeface Corporation in the<br />U.S. and other countries.</p></blockquote><h2 id="board">Board</h2><p>This is the very same board as used by the later <a href="https://www.pagetable.com/?p=1673">“Plus” cartridge</a>, except that it is fitted with only three instead of four ROM chips:</p><p><a href="docs/postscript_cartridge/postscript_cartridge_board_front.jpg"><img src="docs/postscript_cartridge/postscript_cartridge_board_front.jpg" height="254" width="388" alt="" /></a></p><p>The ROM chips are:</p><ul><li>two 512 KB Toshiba TC534200P mask ROM chips</li><li>one 512 KB Toshiba TC574200D-150 EPROM</li></ul><p>Both types conform to the 27C400 pinout. The mask ROMs are marked with</p><blockquote><p>© 1989-90 HP BOISE<br />© 1984-90 ADOBE<br />© 1981 LINOTYPE</p></blockquote><p>and the EPROM is marked with</p><blockquote><p>© 1986-91 HP BOISE<br />© 1984-91 Adobe<br />© 1981 Linotype AG</p></blockquote><h2 id="rom">ROM</h2><p>These are the verbatim dumps (adjacent bytes are swapped):</p><ul><li><a href="docs/postscript_cartridge/1818-4788.bin">1818-4788</a>, MD5 e2d740f3b15bfdf837b9385490e8dafd</li><li><a href="docs/postscript_cartridge/1818-4789.bin">1818-4789</a>, MD5 1fe13fabb47f0719b9a840df8e5844e6</li><li><a href="docs/postscript_cartridge/33439-60115.bin">33439-60115</a>, MD5 520d4f2e0ccf7f143fcdbe62f31792a2</li></ul><p>This is the combined (<a href="docs/postscript_cartridge_plus/byteswap.py">byte-swapped</a>) 1.5 MB ROM image:</p><p><a href="docs/postscript_cartridge/33439q.bin">HP PostScript Cartridge 33439Q ROM</a>, MD5 929ba4050a8a48c3ed4761c3f9267837</p><p>The ROM image starts with a signature of “SYST” and the following messages at 0x30:</p><blockquote><p>C V6.20 PSCRIPT<br />06.20<br />Copyright © Hewlett-Packard Company, 1991. All rights reserved.</p></blockquote><p>(This part comes from the EEPROM.)</p><p>Just like the “Plus” cartridge, the ROM contains Adobe’s PostScript rasterizer (level 1 in this case) compiled for the 68000 CPU, the PostScript base fonts as well as some LaserJet-specific software (messages, errors and settings texts for the 15 char display in several languages).</p><h2 id="postscript-files">PostScript Files</h2><p>Like in the “Plus” cartridge, there is some PostScript source code in the ROMs:</p><ul><li><a href="docs/postscript_cartridge_plus/ps/fontpage.ps">fontpage.ps</a></li><li><a href="docs/postscript_cartridge/ps/test_page.ps">test_page.ps</a></li><li><a href="docs/postscript_cartridge/ps/startup_page.ps">startup_page.ps</a></li></ul><p>(The missing <code>%!</code> file header has been added to the downloads.)</p><h3 id="fontpage">FONTPAGE</h3><p>“FONTPAGE” is identical to the file in the “Plus” cartridge, see <a href="https://www.pagetable.com/?p=1673">there</a>.</p><h3 id="test-page">TEST PAGE</h3><p>“TEST PAGE” prints various internal printer settings which are unsupported by computer-based PostScript rasterizers, so the file has been patched to work with the the macOS 12.6 PSNormalizer.framework rasterizer (based on Adobe Acrobat Distiller 5.0):</p><ul><li><a href="docs/postscript_cartridge/ps/test_page_apple.ps">test_page_apple.ps</a></li><li><a href="docs/postscript_cartridge/ps/test_page_apple.pdf">test_page_apple.pdf</a></li></ul><p><img border="1" src="docs/postscript_cartridge/ps/test_page_apple.png" width="319" height="413"/></p><h3 id="startup-page">STARTUP PAGE</h3><ul><li><a href="docs/postscript_cartridge/ps/startup_page.ps">startup_page.ps</a></li><li><a href="docs/postscript_cartridge/ps/startup_page.pdf">startup_page.pdf</a></li></ul><p><img border="1" src="docs/postscript_cartridge/ps/startup_page.png" width="319" height="413"/></p><h2 id="manuals-and-extras">Manuals and Extras</h2><p><kbd><a href="docs/postscript_cartridge/postscript_cartridge_users_guide.pdf"><img src="docs/postscript_cartridge/postscript_cartridge_users_guide.jpg" height="316" width="208" alt="" /></a></kbd> <kbd><a href="docs/postscript_cartridge/postscript_cartridge_application_notes.pdf"><img src="docs/postscript_cartridge/postscript_cartridge_application_notes.png" height="314" width="208" alt="" /></a></kbd> <kbd><a href="docs/postscript_cartridge/postscript_cartridge_license.pdf"><img src="docs/postscript_cartridge/postscript_cartridge_license.jpg" height="314" width="202" alt="" /></a></kbd> <kbd><a href="docs/postscript_cartridge/postscript_cartridge_smart_choice.pdf"><img src="docs/postscript_cartridge/postscript_cartridge_smart_choice.jpg" height="258" width="185" alt="" /></a></kbd> <kbd><a href="docs/postscript_cartridge/postscript_cartridge_stickers.jpg"><img src="docs/postscript_cartridge/postscript_cartridge_stickers.jpg" height="126" width="100" alt="" /></a></kbd></p><h2 id="future-work">Future Work</h2><p>Are there versions of this cartridge with different EPROM contents?</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1721</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>Scanntronik Manuals</title> <link>https://www.pagetable.com/?p=1730</link> <comments>https://www.pagetable.com/?p=1730#comments</comments> <pubDate>Fri, 23 Dec 2022 18:00:18 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Literature]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1730</guid> <description><![CDATA[The German company “Scanntronik” offered a lot of high-quality hardware and software for the Commodore 64 series computers, most in the space of graphics and desktop publishing. They are well-known for their Pagefox and Printfox software as well as their Handyscanner 64 hardware. This page offers most of the German-language manuals from across their product ... <a title="Scanntronik Manuals" class="read-more" href="https://www.pagetable.com/?p=1730">Read more<span class="screen-reader-text">Scanntronik Manuals</span></a>]]></description> <content:encoded><![CDATA[<p>The German company “Scanntronik” offered a lot of high-quality hardware and software for the Commodore 64 series computers, most in the space of graphics and desktop publishing. They are well-known for their Pagefox and Printfox software as well as their Handyscanner 64 hardware. This page offers most of the German-language manuals from across their product range as searchable PDFs.</p><p><img src="docs/scanntronik_manuals/montage.png" height="271" width="302" alt="" /></p><p>If you have any additional manuals, or manuals in different languages, please reach out to me and we can get them added.</p><h2 id="pagefox">Pagefox</h2><div style="display: flex; flex-flow: row wrap;"><div style="display: inline-block; margin: 4px; width: 210px;"><a href="docs/scanntronik_manuals/pagefox.pdf"><img src="docs/scanntronik_manuals/pagefox.png" width="210" height="296" style="border:1px solid gray;"></a><center>PAGEFOX</center></div><div style="display: inline-block; margin: 4px; width: 213px;"><a href="docs/scanntronik_manuals/tipsundtricks_pagefox.pdf"><img src="docs/scanntronik_manuals/tipsundtricks_pagefox.png" width="213" height="295" style="border:1px solid gray;"></a><center>Tips & Tricks für den PAGEFOX</center></div></div><h2 id="printfox">Printfox</h2><div style="display: flex; flex-flow: row wrap;"><div style="display: inline-block; margin: 4px; width: 211px;"><a href="docs/scanntronik_manuals/printfox.pdf"><img src="docs/scanntronik_manuals/printfox.png" width="211" height="296" style="border:1px solid gray;"></a><center>Printfox</center></div><div style="display: inline-block; margin: 4px; margin: 4px;width: 221px;"><a href="docs/scanntronik_manuals/printfox__errata.pdf"><img src="docs/scanntronik_manuals/printfox__errata.png" width="221" height="129" style="border:1px solid gray;"></a><center>Printfox Errata</center></div><div style="display: inline-block; margin: 4px; margin: 4px;width: 211px;"><a href="docs/scanntronik_manuals/character_fox.pdf"><img src="docs/scanntronik_manuals/character_fox.png" width="211" height="296" style="border:1px solid gray;"></a><center>Character Fox; Erweiterungsdisk 1 zum Printfox</center></div><div style="display: inline-block; margin: 4px; margin: 4px;width: 212px;"><a href="docs/scanntronik_manuals/fox_bibel.pdf"><img src="docs/scanntronik_manuals/fox_bibel.png" width="212" height="296" style="border:1px solid gray;"></a><center>Die Fox-Bibel zum Printfox-Basar</center></div></div><h2 id="videofox">Videofox</h2><div style="display: flex; flex-flow: row wrap;"><div style="display: inline-block; margin: 4px; width: 208px;"><a href="docs/scanntronik_manuals/videofox.pdf"><img src="docs/scanntronik_manuals/videofox.png" width="208" height="296" style="border:1px solid gray;"></a><center>VIDEOFOX</center></div><div style="display: inline-block; margin: 4px; width: 208px;"><a href="docs/scanntronik_manuals/videofox2.pdf"><img src="docs/scanntronik_manuals/videofox2.png" width="208" height="295" style="border:1px solid gray;"></a><center>VIDEOFOX II</center></div><div style="display: inline-block; margin: 4px; width: 209px;"><a href="docs/scanntronik_manuals/movies_videofox.pdf"><img src="docs/scanntronik_manuals/movies_videofox.png" width="209" height="297" style="border:1px solid gray;"></a><center>MOVIES FÜR DEN VIDEOFOX</center></div><div style="display: inline-block; margin: 4px; width: 211px;"><a href="docs/scanntronik_manuals/colour_movies.pdf"><img src="docs/scanntronik_manuals/colour_movies.png" width="211" height="297" style="border:1px solid gray;"></a><center>COLOUR MOVIES; Eine Kollektion von Farbbildern und Vorspännen für den Videofox II</center></div></div><h2 id="eddison-&-eddifox">Eddison & Eddifox</h2><div style="display: flex; flex-flow: row wrap;"><div style="display: inline-block; margin: 4px; width: 213px;"><a href="docs/scanntronik_manuals/eddison.pdf"><img src="docs/scanntronik_manuals/eddison.png" width="213" height="297" style="border:1px solid gray;"></a><center>EDDISON</center></div><div style="display: inline-block; margin: 4px; width: 209px;"><a href="docs/scanntronik_manuals/eddifox.pdf"><img src="docs/scanntronik_manuals/eddifox.png" width="209" height="295" style="border:1px solid gray;"></a><center>EDDIFOX</center></div></div><h2 id="cheese">Cheese</h2><div style="display: flex; flex-flow: row wrap;"><div style="display: inline-block; margin: 4px; width: 195px;"><a href="docs/scanntronik_manuals/cheese.pdf"><img src="docs/scanntronik_manuals/cheese.png" width="195" height="251" style="border:1px solid gray;"></a><center>Bedienungsanleidung Malprogramm Cheese</center></div><div style="display: inline-block; margin: 4px; width: 208px;"><a href="docs/scanntronik_manuals/cheese_addon.pdf"><img src="docs/scanntronik_manuals/cheese_addon.png" width="208" height="294" style="border:1px solid gray;"></a><center>Cheese Add-on</center></div></div><h2 id="colourprinter">Colourprinter</h2><div style="display: flex; flex-flow: row wrap;"><div style="display: inline-block; margin: 4px; width: 210px;"><a href="docs/scanntronik_manuals/colourprinter.pdf"><img src="docs/scanntronik_manuals/colourprinter.png" width="210" height="295" style="border:1px solid gray;"></a><center>Colourprinter</center></div></div><h2 id="handyscanner-64">Handyscanner 64</h2><div style="display: flex; flex-flow: row wrap;"><div style="display: inline-block; margin: 4px; width: 209px;"><a href="docs/scanntronik_manuals/handyscanner64.pdf"><img src="docs/scanntronik_manuals/handyscanner64.png" width="209" height="292" style="border:1px solid gray;"></a><center>Handyscanner 64</center></div></div><h2 id="catalogs"><em>Catalogs</em></h2><div style="display: flex; flex-flow: row wrap;"><div style="display: inline-block; margin: 4px; width: 210px;"><a href="docs/scanntronik_manuals/katalog_1990-12.pdf"><img src="docs/scanntronik_manuals/katalog_1990-12.png" width="210" height="296" style="border:1px solid gray;"></a><center>Scanntronik-Katalog 12/90</center></div><div style="display: inline-block; margin: 4px; width: 142px;"><a href="docs/scanntronik_manuals/katalog.pdf"><img src="docs/scanntronik_manuals/katalog.png" width="142" height="297" style="border:1px solid gray;"></a><center>Scanntronik Katalog [ca. 1993+]</center></div><div style="display: inline-block; margin: 4px; width: 296px;"><a href="docs/scanntronik_manuals/katalog_beilage.pdf"><img src="docs/scanntronik_manuals/katalog_beilage.png" width="296" height="133" style="border:1px solid gray;"></a><center>Katalog-Beilage [ca. 1993+]</center></div><div style="display: inline-block; margin: 4px; width: 218px;"><a href="docs/scanntronik_manuals/katalog_1992_12.pdf"><img src="docs/scanntronik_manuals/katalog_1992_12.png" width="218" height="307" style="border:1px solid gray;"></a><center>Scanntronik-Katalog 12/92</center></div><div style="display: inline-block; margin: 4px; width: 208px;"><a href="docs/scanntronik_manuals/bestellung.pdf"><img src="docs/scanntronik_manuals/bestellung.png" width="208" height="148" style="border:1px solid gray;"></a><center>Scanntronik Bestell-Postkarte</center></div></div>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1730</wfw:commentRss> <slash:comments>3</slash:comments> </item> <item> <title>The Commodore AUTOMODEM (Model 1650)</title> <link>https://www.pagetable.com/?p=1716</link> <comments>https://www.pagetable.com/?p=1716#comments</comments> <pubDate>Thu, 22 Dec 2022 17:06:57 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Archeology]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Literature]]></category> <category><![CDATA[Modem]]></category> <category><![CDATA[VIC-20]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1716</guid> <description><![CDATA[The Commodore 1650, also known as the “AUTOMODEM”, is Commodore’s first full modem directly connected to the phone line. It supports pulse dialing in software and 300 baud duplex connections. Historical Context Year Name Model Description 1982 VICMODEM 1600 connected to phone’s handset connector; manual dialing through phone; Motorola MC14412 1982 AUTOMODEM 1650 connected to ... <a title="The Commodore AUTOMODEM (Model 1650)" class="read-more" href="https://www.pagetable.com/?p=1716">Read more<span class="screen-reader-text">The Commodore AUTOMODEM (Model 1650)</span></a>]]></description> <content:encoded><![CDATA[<p>The Commodore 1650, also known as the “AUTOMODEM”, is Commodore’s first full modem directly connected to the phone line. It supports pulse dialing in software and 300 baud duplex connections.</p><h2 id="historical-context">Historical Context</h2><table><thead><tr><th> Year </th><th> Name </th><th> Model </th><th> Description </th></tr></thead><tbody><tr><td> 1982 </td><td> <a href="https://www.pagetable.com/?p=1679">VICMODEM</a> </td><td> 1600 </td><td> connected to phone’s handset connector; manual dialing through phone; Motorola MC14412 </td></tr><tr><td> 1982 </td><td> <a href="https://www.pagetable.com/?p=1716">AUTOMODEM</a> </td><td> 1650 </td><td> connected to phone line, pulse dialing in software; Motorola MC14412 </td></tr><tr><td> 1985 </td><td> <a href="https://www.pagetable.com/?p=1644">MODEM/300</a> </td><td> 1660 </td><td>added tone dialing support by feeding SID output into modem; Texas Instruments TMS99532A </td></tr><tr><td> 1987 </td><td> <a href="https://www.pagetable.com/?p=1647">MODEM/1200</a> </td><td> 1670 </td><td> Hayes command set; pulse and tone dialing in hardware; 300/1200 baud support; U.S. Robotics chipset </td></tr></tbody></table><h2 id="photos">Photos</h2><p><a href="docs/cbm1650modem/cbm1650.jpg"><img src="docs/cbm1650modem/cbm1650.jpg" height="398" width="506" alt="" /></a></p><p>On the front, there is the VIC-20/C64 user port connector and an activity LED.</p><p>On the left, there is<br />* the “LINE” jack that is supposed to be connected to the telephone network<br />* the “PHONE” jack for connecting an existing telephone<br />* a D/T switch. In D mode, the modem takes over the phone line, in T mode, “LINE” gets passed through to the telephone.<br />* an A/O switch. When making a modem call, it is to be put into the “O” (originate) position, and when answering a call, it is to be put into the “A” (answer) position.</p><p>On the right, there is an H/F switch to select Half Duplex (“H“) or Full Duplex (“F“).</p><p><a href="docs/cbm1650modem/front.jpg"><img src="docs/cbm1650modem/front.jpg" height="277" width="348" alt="" /></a><a href="docs/cbm1650modem/back.jpg"><img src="docs/cbm1650modem/back.jpg" height="284" width="356" alt="" /></a></p><p>The label on the bottom says:</p><blockquote><p>FCC ID: B4V8N2AUTOVIC<br />Commodore Business Machines, Inc<br />Made in USA</p><p>Certified to comply with the limits for a Class B<br />computing device pursuant to Subpart J of<br />Part 15 of FCC Rules. See instructions if<br />interference to radio reception is suspected.</p><p>Complies with Part 68, FCC Rules; FCC<br />Registration Number B4V8N2-70317-<br />DM-R; Ringer Equivalence 0.1B; Jack<br />(USOC) RJ11</p><p>Model 1650<br />Serial Number: 018208</p></blockquote><p><a href="docs/cbm1650modem/board1.jpg"><img src="docs/cbm1650modem/board1.jpg" height="283" width="375" alt="" /></a><a href="docs/cbm1650modem/board2.jpg"><img src="docs/cbm1650modem/board2.jpg" height="281" width="359" alt="" /></a></p><p>The only text on the board is “00312A” on the back. The core component is the Motorola <a href="docs/cbm1600modem/MC14412.pdf">MC14412</a> modem chip at the bottom center.</p><p>The design of the AUTOMODEM is basically the same as its <a href="TODO">predecessor’s</a>, with the extra circuitry added to allow it work with the phone line directly instead of acting as the handset of an existing telephone.</p><h2 id="box">Box</h2><p><a href="docs/cbm1650modem/box_front.jpg"><img src="docs/cbm1650modem/box_front.jpg" height="357" width="257" alt="" /></a><a href="docs/cbm1650modem/box_side.jpg"><img src="docs/cbm1650modem/box_side.jpg" height="357" width="59" alt="" /></a><a href="docs/cbm1650modem/box_back.jpg"><img src="docs/cbm1650modem/box_back.jpg" height="357" width="257" alt="" /></a></p><h2 id="manual">Manual</h2><p><a href="docs/cbm1650modem/cbm1650modem_manual.pdf"><img src="docs/cbm1650modem/cbm1650modem_manual.jpg" height="261" width="189" alt="" /></a></p><h2 id="more-box-contents-&-tape">More Box Contents & Tape</h2><p>I don’t have any of the extras that came with the box. If you have them, please contact me.</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1716</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item> <title>A 1960s Children’s Book about Computers</title> <link>https://www.pagetable.com/?p=1709</link> <comments>https://www.pagetable.com/?p=1709#comments</comments> <pubDate>Wed, 21 Dec 2022 21:43:22 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Archeology]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1709</guid> <description><![CDATA[The 1963 book “Robots and Electronic Brains” (by Robert Scharff) from the “How and Why Wonder Books” series is an early children’s book about computers. Let’s look at some of the interesting contents – and how the German translation “Was ist was: Roboter und Elektronengehirne” from 1967 changed some details. Historical Context of the Books ... <a title="A 1960s Children’s Book about Computers" class="read-more" href="https://www.pagetable.com/?p=1709">Read more<span class="screen-reader-text">A 1960s Children’s Book about Computers</span></a>]]></description> <content:encoded><![CDATA[<p>The 1963 book <a href="https://www.worldcat.org/title/how-and-why-wonder-book-of-robots-and-electronic-brains/oclc/7839429?referer=br&ht=edition">“Robots and Electronic Brains”</a> (by Robert Scharff) from the <a href="https://en.wikipedia.org/wiki/How_and_Why_Wonder_Books">“How and Why Wonder Books”</a> series is an early children’s book about computers. Let’s look at some of the interesting contents – and how the German translation “Was ist was: Roboter und Elektronengehirne” from 1967 changed some details.</p><p><img src="docs/robots_and_electronic_brains/titles.jpg" width="670" height="450"></p><h2>Historical Context of the Books</h2><p>Published in 1963, this might very well be one of the first children’s books on computers ever. To put this into context, this was:</p><ul><li>less than 20 years after the first workable computers</li><li>four years after the introduction of the IBM 1401, one of the first commercial computers based on transistors (as opposed to tubes), weighing five tons and with programs on punch cards</li><li>six years before the <a href="https://www.pagetable.com/?p=922">moon landings</a></li></ul><p>With this context, the somewhat weird title “Robots and Electronic Brains” might be more understandable:</p><ul><li>Computers are called “electronic brains”, since “computers” might not have been a common enough term (especially for children!) at the time.</li><li>Even though the book is mostly about computers, “robots” are mentioned first in the title, because they are a familiar concept. Robots like “Robby” (“Forbidden Planet”, 1956) were part of the pop culture.</li></ul><p>While the original German version went with a literal translation, later editions updated the title to “Computer und Roboter” – computers and robots. They kept updating it until <a href="https://www.amazon.de/Was-ist-was-Band-037/dp/3788602775">1999</a>, but it’s now out of print.</p><h2>Differences in the German Version</h2><p>The German translation was done by Käte und Heinrich Hart. While the book retains the same chapters and the identical layout, the text was slightly adapted. Here are some examples:</p><h3>Who invented computers?</h3><p>This question has no easy answer, as both versions correctly state. Yet the original version claims it’s an <i>American</i> invention – this part has been removed from the German version.</p><table border="1"><tr><th width="33%">English</th><th width="33%">German (<a href="https://www.DeepL.com/Translator">translated back</a>)</th><th width="33%">German</th></tr><tr><td style="vertical-align: top;"><p>The electronic computer, among the foremost <b>American</b> inventions of this century, was not an overnight discovery. It is the fruit of the practical science of mathematics and has its roots far in the past.</p></td><td style="vertical-align: top;"><p>Electronic computing systems, one of the most significant technical achievements of this century, were not accidental inventions. They are the result of developed modern technology and applied mathematical science. The origin of mathematics lies far in the past.</p></td><td style="vertical-align: top;"><p>Die elektronischen Rechenanlagen, eine der bedeutendsten technischen Leistungen dieses Jahrhunderts, waren keine Zufallserfindungen. Sie sind das Ergebnis der entwickelten modernen Technik und der angewandten mathematischen Wissenschaft. Der Ursprung der Mathematik liegt weit in der Vergangenheit.</p></td></tr></table><p>The translation also adds an explicit credit to the German Leibniz for his <a href="https://en.wikipedia.org/wiki/Stepped_reckoner">calculator</a>:</p><table border="1"><tr><th width="33%">English</th><th width="33%">German (<a href="https://www.DeepL.com/Translator">translated back</a>)</th><th width="33%">German</th></tr><tr><td style="vertical-align: top;"><p>The first adding machine, invented in 1642, was followed by a four-operation arithmetic machine composed of a difference engine that performed calculations, a mechanical tabulator, a punch-paper control system, and a differential analyzer. Although these inventions increased computation speeds, they failed to fulfill the needs of our complex world.</p></td><td style="vertical-align: top;"><p>The first simple adding machine was invented in 1642, the first calculating machine for all four basic arithmetic operations around 1672 <b>by the German philosopher and mathematician Leibniz.</b></p></td><td style="vertical-align: top;"><p>Die erste einfache Addiermaschine wurde im Jahre 1642 erfunden, die erste Rechenmaschine für alle vier Grundrechnungsarten um 1672 <b>von dem deutschen Philosophen und Mathematiker Leibniz.</b></p></td></tr></table><p>The two versions of the book heavily diverge on the topic of the first “workable” computer:</p><table border="1"><tr><th width="33%">English</th><th width="33%">German (<a href="https://www.DeepL.com/Translator">translated back</a>)</th><th width="33%">German</th></tr><tr><td style="vertical-align: top;"><p>In <b>1936</b>, a young <b>Harvard</b> physicist, Professor <b>Howard Aiken</b>, happened upon some of the writings of Dr. Babbage. Like Babbage, Dr. Aiken saw the possibility of a robot that could do the thinking of hundreds of men in a fraction of the time it took any one of them to work out routine mathematical problems. Aiken teamed up with other researchers and, by 1944, they built the first workable computer.</p></td><td style="vertical-align: top;"><p>An electromechanical calculator was first built in <b>Germany</b> in <b>1941</b> by <b>K. Zuse</b>. <b>At the same time, similar types were being worked on in North America.</b></p></td><td style="vertical-align: top;"><p>Eine elektromechanische Rechenmaschine wurde zuerst im Jahre <b>1941</b> in <b>Deutschland</b> von <b>K. Zuse</b> gebaut. <b>Zur gleichen Zeit wurde in Nordamerika an ähnlichen Typen gearbeitet.</a></p></td></tr></table><p>Some historical context from today’s perspective: There were actually several electronic or electromechanical and <a href="https://en.wikipedia.org/wiki/History_of_computing_hardware#Early_digital_computer_characteristics">more or less general-purpose computers in the 1940s</a>. The original version of the book picked the <a href="https://en.wikipedia.org/wiki/Harvard_Mark_I">Harvard Mark I</a> by the team around Howard Aiken as the first “workable” computer. The German adaptation replaced this with the <a href="https://en.wikipedia.org/wiki/Z3_(computer)">Z3</a> of the German Konrad Zuse, which pre-dated the Mark I as the first programmable computer by 3 years.</p><p>To be fair to the original book, Zuse’s work had been largely unknown outside of German-speaking countries until at least the late 1970s. The talk <a href="https://www.youtube.com/watch?v=MWaCpSu9eks">“The Early Development of Digital Computing In Central Europe”</a> given by <a href="https://en.wikipedia.org/wiki/Friedrich_L._Bauer">Friedrich L. Bauer</a> at the 1976 <a href="https://computerhistory.org/playlists/international-research-conference-on-the-history-of-computing/">First International Research Conference on the History of Computing</a> in Los Alamos, NM presented Zuse’s work to an international audience. Zuse himself also had a <a href="https://www.youtube.com/watch?v=UHOU_FlLsHc">talk</a> at the conference.</p><p>In fact, even the <a href="https://en.wikipedia.org/wiki/Colossus_computer">Colossus Mark 1</a> at Bletchley Park predated the Harvard Mark I (by 3 months), but the UK’s codebreakers efforts were still secret at the time the books were written – in fact, they were <a href="https://www.youtube.com/watch?v=WCeLTWPCEFI">revealed</a> at the very same conference in 1976.</a></p><p>Here is what the two versions say about ENIAC:</p><table border="1"><tr><th width="33%">English</th><th width="33%">German (<a href="https://www.DeepL.com/Translator">translated back</a>)</th><th width="33%">German</th></tr><tr><td style="vertical-align: top;"><p>Two years later, the <b>first general-purpose</b>, all-electronic computer, called the ENIAC computer (from Electric Numerical Integrator and Calculator), was built. ENIAC was the grandfather of today’s electronic brains, room-size robots who answer to the unlikely names as UNIVAC, STRETCH, MANIAC, UNICALL, MINIVAC, SEAC, and BIZMAC.</p></td><td style="vertical-align: top;"><p>In 1946, there was <b>also</b> the first real electron computer <b>in the USA</b>, named ENIAC (Electronic Numerical Integrator And Computer). ENIAC was, so to speak, the ancestor of today’s electron brains, the room-sized robots. Some <b>American</b> manufacturers give them names like UNIVAC, MANIAC, UNICALL, MINIVAC and BIZMAC; <b>others, including the German manufacturers, refer to their various computer types only by numbers.</b></p></td><td style="vertical-align: top;"><p>1946 gab es <b>auch in den USA</b> den ersten wirklichen Elektronenrechner, ENIAC genannt (Electronic Numerical Integrator And Computer). ENIAC war sozusagen der Ahnherr der heutigen Elektronengehirne, der zimmergroßen Roboter. Einige <b>amerikanische</b> Hersteller geben ihnen Namen wie UNIVAC, MANIAC, UNICALL, MINIVAC und BIZMAC; <b>andere, auch die deutschen Hersteller, bezeichnen ihre verschiedenen Computertypen nur mit Nummern.</b></p></td></tr></table><p>The German version downgrades <a href="https://en.wikipedia.org/wiki/ENIAC">ENIAC</a> into an “also-ran”. In all fairness, ENIAC should be credited as the first working computer designed to be Turing-complete.</p><p>Finally, the German text clarifies that the UNIVAC-style naming scheme does not apply to all computers, especially non-US ones.</p><h3>Does an electronic brain ever fail?</h3><p>Thankfully (and surprisingly), the German version removes the sexism from the garbage-in/garbage-out chapter:</p><table border="1"><tr><th width="33%">English</th><th width="33%">German (<a href="https://www.DeepL.com/Translator">translated back</a>)</th><th width="33%">German</th></tr><tr><td style="vertical-align: top;">A computer, of course, gives wrong answers if given wrong information. One experiment with the decision-making ability of computers was a failure. A television quiz program used a computer to select the ideal wife for a contestant. To accomplish this, the programmer fed into the machine all facts known for a perfect marriage – likes and dislikes, interests in various hobbies, movies, music, food, etc. When the computer compared the qualifications of many women with those of the male contestant, it recommended one as ideal. But, when the two got to know each other, they decided they were mismatched and should not marry each other. Whose fault was this? The machine programmer’s? <b>Perhaps it only proves that even a computer cannot understand a woman’s mind.</b></td><td style="vertical-align: top;">Of course, if a computer is fed the wrong information, it will give a wrong answer, but other attempts to use a computer’s capability can also lead to failure. Example: In a television program, a computer was used to find out the ideal wife for a certain man. The programmer gave the electronic computer all the characteristics desired for an ideal marriage – likes and dislikes, interests in various hobbies, in cultural values, and so on. After the computer compared the characteristics of many women with those of the man in question or according to his wishes, it declared a particular woman to be the ideal partner. But when the two got to know each other, it turned out that they did not like each other. Whose fault was that? The programmer’s? <b>Perhaps the experiment only proves that the human heart and its inclinations are not calculable.</b></td><td style="vertical-align: top;">Natürlich gibt ein Computer, wenn er mit falschen Angaben gefüttert wurde, eine falsche Antwort. Aber auch andere Versuche, die Fähigkeit eines Computers zu nutzen, können zum Mißerfolg führen. Ein Beispiel: In einem Fernsehprogramm wurde ein Computer dazu benutzt, jeweils für einen bestimmten Mann die ideale Ehefrau herauszufinden. Der Programmierer gab dem Elektronenrechner alle für eine ideale Ehe gewünschten Eigenschaften auf – Neigungen und Abneigungen, Interessen an verschiedenen Hobbies, an kulturellen Werten usw. Nachdem der Computer die Eigenschaften vieler Frauen mit denen des betreffenden Mannes oder gemäß dessen Wünschen verglichen hatte, erklärte er eine bestimmte Frau zur idealen Partnerin. Aber als die beiden dann einander kennenlernten, stellte sich heraus, daß sie sich nicht sympathisch waren. Wessen Fehler war das? Des Programmierers? <b>Vielleicht beweist der Versuch nur, daß das menschliche Herz und seine Neigung nicht berechenbar ist.</b></td></tr></table><h2>Complete Comparison</h2><p>Here are both books side by side. If you find any more interesting details (or differences), please add them in the comments of this article!</p><p><img src="docs/robots_and_electronic_brains/haw-000.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-000.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-001.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-002.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-001.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-002.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-003.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-004.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-003.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-004.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-005.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-006.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-005.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-006.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-007.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-008.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-007.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-008.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-009.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-010.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-009.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-010.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-011.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-012.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-011.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-012.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-013.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-014.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-013.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-014.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-015.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-016.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-015.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-016.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-017.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-018.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-017.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-018.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-019.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-020.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-019.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-020.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-021.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-022.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-021.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-022.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-023.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-024.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-023.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-024.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-025.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-026.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-025.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-026.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-027.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-028.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-027.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-028.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-029.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-030.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-029.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-030.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-031.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-032.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-031.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-032.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-033.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-034.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-033.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-034.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-035.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-036.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-035.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-036.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-037.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-038.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-037.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-038.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-039.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-040.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-039.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-040.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-041.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-042.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-041.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-042.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-043.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-044.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-043.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-044.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-045.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/haw-046.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/wiw-045.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-046.webp" width="335" height="450"><br /><img src="docs/robots_and_electronic_brains/haw-047.webp" width="335" height="450"><img src="docs/robots_and_electronic_brains/wiw-047.webp" width="335" height="450"></p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1709</wfw:commentRss> <slash:comments>6</slash:comments> </item> <item> <title>Digitizing Analog Video through a Digital Camcorder</title> <link>https://www.pagetable.com/?p=1697</link> <comments>https://www.pagetable.com/?p=1697#comments</comments> <pubDate>Sat, 19 Nov 2022 22:06:04 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Archeology]]></category> <category><![CDATA[Digital Video]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1697</guid> <description><![CDATA[This article explains a setup and workflow for digitizing analog video (e.g. VHS, Beta, Video 2000, LaserDisc, …) using a Mac and digital camcorder – in high quality and with interlacing intact; optimized for archival. We will use a old-school digital camcorder (they are cheap!) to convert the analog signal to a high-quality digital “DV” ... <a title="Digitizing Analog Video through a Digital Camcorder" class="read-more" href="https://www.pagetable.com/?p=1697">Read more<span class="screen-reader-text">Digitizing Analog Video through a Digital Camcorder</span></a>]]></description> <content:encoded><![CDATA[<p>This article explains a setup and workflow for digitizing analog video (e.g. VHS, Beta, Video 2000, LaserDisc, …) using a Mac and digital camcorder – in high quality and with interlacing intact; optimized for archival. We will use a old-school digital camcorder (they are cheap!) to convert the analog signal to a high-quality digital “DV” stream and then record the DV stream on a Mac using a FireWire connection.</p><p><img src="docs/digitizing_vhs/digitizing_vhs.png" height="238" width="800" alt="" /></p><h2 id="the-problem-with-interlaced-video">The Problem with Interlaced Video</h2><p>Standard definition analog video is either</p><ul><li>576i50 (PAL/SECAM): 25 full frames per second of 720×576 pixels, interlaced</li><li>480i60 (NTSC): 30 full frames per second of 720×480 pixels, interlaced</li></ul><p>Interlaced means that every full frame is split into two “fields”, one with the picture’s 288 (PAL; NTSC: 240) odd lines, and one with the 288 (240) even lines. These two fields can represent one moment in time: When combining them, they will give 25 (30) full 720×576 (720×480) frames. Or they can be recorded 1/50 (1/60) second apart, giving motion at a resolution of 50 (60) Hz, but at half the vertical resolution, and with the set of lines alternating every time.</p><p>Interlaced video was natural for old CRT displays, but in order to show interlaced video on modern displays or encode them into modern video compression formats, they need to be converted into progressive format, i.e. deinterlaced.</p><p>The two fields are always transmitted one after the other, and it is unclear whether every two fields should be combined (“comb filter”) for a 25 (30) Hz video or whether the 50 (60) fields should be vertically upscaled for a 50 (60) Hz video. Using the wrong method means either <a href="https://www.google.com/search?q=interlaced+combing+artifact">combing artifacts</a> or flickering.</p><p>The worst part is when the pairing of fields is inconsistent, like <a href="https://www.pagetable.com/?p=484">in this example of Futurama</a> or whenever two scenes are composited in the original SD version of Star Trek TNG.</p><p>So deinterlacing is hard, especially if you want to do it well. When digitizing analog video, it is best to keep the interlacing intact. When playing the file, VLC for instance will already do pretty good deinterlacing by default – and tomorrow’s VLC will certainly do a better job. And if you come back to the footage years later to share it or reuse parts in an HD video, you can use the best deinterlacer available then!</p><p>So all in all, if you want to <em>archive</em> analog video, you should keep it interlaced. Many simple solutions won’t do this, but this solution does.</p><h2 id="digital-video-and-dv">Digital Video and DV</h2><p>A full, uncompressed digital representation of a PAL signal is 50 times a second a 720×576 image at 24 bits per pixel, which is 25x720x576x24: almost 240 Mbits/sec.</p><p>This implies “4:4:4”, meaning every 2×2 pixels have four brightness values (Y’) and four values each for the two color components (Cb and Cr). Most digital formats use <a href="https://en.wikipedia.org/wiki/Chroma_subsampling">chroma subsampling</a>, meaning that a 2×2 pixel grid has fewer chroma values. Since the human visual system is less sensitive to color than it is to brightness, 4:2:2 (half horizontal chroma resolution) is practically indistinguishable from 4:4:4.</p><p>The 1986 <a href="https://en.wikipedia.org/wiki/D-1_(Sony)">D-1 format</a> uses 4:2:2 chroma subsampling and thus reduces the data rate by a factor of 1.5 to about 160 MBits/sec. Sony’s 1993 <a href="https://en.wikipedia.org/wiki/Digital_Betacam">Digital Betacam</a> additionally uses lossy compression to reduce the data rate by a factor of 2.34:1 down to about 70 MBits/sec. Both formats were meant for professional use.</p><p>The consumer format for digital SD camcorders is the 1994 <a href="https://en.wikipedia.org/wiki/DV">DV</a> (“Digital Video”). It uses 4:2:0 chroma subsampling (one color value per 2×2) for PAL and 4:1:1 (one color value per 4×1) for NTSC, which reduces 4:4:4 data by a factor of 2. The resulting data is lossily <a href="https://en.wikipedia.org/wiki/Discrete_cosine_transform">DCT</a>-compressed by a factor of 5, leading to a data rate of 25 MBit/sec.</p><p>DV embeds an uncompressed 48 kHz 16 bit stereo PCM audio stream, which adds 1.5 MBit/sec (or alternatively, two 32 kHz 12 bit stereo streams with the same total bitrate).</p><p>Unlike today’s common compression methods (e.g. MPEG-2, H.264, H.265), DV compresses images individually, so in the stream, there are no dependencies between images. You can imagine DV as a stream of 64 KB JPEG images. This allows frame-exact editing and allows for simpler encoder and decoder hardware, but means that a higher data rate is required for the same quality. A 25 MBit/sec DV stream is roughly equivalent to a 10 MBit/sec MPEG-2 stream and a 3 MBit/sec H.264 stream.</p><p>DV is an excellent match as an intermediate digital representation or even as an archival format for pretty much</a> all analog media, it even surpasses LaserDisc and matches DVD in <a href="https://en.wikipedia.org/wiki/Betamax#Comparison_with_other_video_formats">luma and chroma resolution</a> (PAL values; NTSC are similar):</p><table><thead><tr><th> Format </th><th> Luma </th><th> Chroma </th></tr></thead><tbody><tr><td> VHS </td><td> 320×576 </td><td> 40×288 </td></tr><tr><td> Betamax </td><td> 333×576 </td><td> 40×288 </td></tr><tr><td> S-VHS </td><td> 560×576 </td><td> 40×288 </td></tr><tr><td> Broadcast </td><td> 440×576 </td><td> 120×288 </td></tr><tr><td> LaserDisc </td><td> 560×576 </td><td> 120×288 </td></tr><tr><td> DVD </td><td> 720×576 </td><td> 360×288 </td></tr><tr><td> <strong>DV</strong> </td><td> <strong>720×576</strong> </td><td> <strong>360×288</strong><sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup> </td></tr></tbody></table><p>DV’s DCT-based compression is lossy but quite gentle, and given the increased resolution of DV compared to all analog media, it will capture virtually all data from the analog media.</p><h2 id="digital-sd-camcorders">Digital SD Camcorders</h2><p>There are two types of digital standard definition camcorders:</p><ul><li>MiniDV (1995) was the industry standard. It uses a proprietary cassette format.</li><li>Digital8 (1999) by Sony re-uses the same tapes as the analog Hi8 format.</li></ul><p>Both Digital8 and MiniDV camcorders store a DV stream on tape and all devices come with a 4-pin FireWire/IEEE-1394/i.LINK connector that allows losslessly copying the DV stream from the camcorder to a second device or to a computer, or copying a DV stream <em>to</em> the device.</p><p>In addition to an analog video output (for connecting it to a TV), many camcorders also have an analog composite or even S-Video input. Unless the firmware has this feature disabled to avoid the European tax on video recorders (check the manual!), these camcorders can record analog video from an external input, or output a live digitized DV stream over FireWire (“DAC”).</p><p>This is what we will be using, so the tape format of the camcorder does not matter, since we won’t be using tape.</p><h2 id="setup">Setup</h2><p>You need</p><ul><li>a high quality player for your VHS, Beta, Video 2000, LaserDisc etc. media</li><li>a composite or S-Video cable plus audio to connect the player to the camcorder<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup></li><li>a Digital8 or miniDV camcorder that supports digitizing external sources (“DAC” functionality).</li><li>an Apple Mac with a FireWire or Thunderbolt port, so:<ul><li>any iMac, Mac mini, Mac Studio, Mac Pro or MacBook Pro</li><li>MacBook Air since Mid 2011</li><li>MacBook up to (!) Mid 2009, except Aluminum 2008</li></ul></li></ul><p>Depending on what kind of Port your Mac has, you need the following cables and adapters:</p><table><thead><tr><th> Port on Mac </th><th> Cables </th><th> Images </th></tr></thead><tbody><tr><td> FireWire 400<br />(1999-) </td><td> 4-pin (DV) to 6-pin (FW 400) </td><td> <img src="docs/digitizing_vhs/4-6.jpg" height="75" width="150" alt="" /> </td></tr><tr><td> FireWire 800<br />(2009-) </td><td> 4-pin (DV) to 9-pin (FW 800) </td><td> <img src="docs/digitizing_vhs/4-9.jpg" height="75" width="150" alt="" /> </td></tr><tr><td> Thunderbolt 1/2<br />(2011-) </td><td> 4-pin (DV) to 9-pin (FW 800)<br /><a href="https://www.apple.com/shop/product/MD464LL/A/apple-thunderbolt-to-firewire-adapter">Thunderbolt to FireWire adapter</a> </td><td> <img src="docs/digitizing_vhs/4-9.jpg" height="75" width="150" alt="" /><br /><img src="docs/digitizing_vhs/fw_tb.jpg" height="52" width="256" alt="" /></td></tr><tr><td> Thunderbolt 3/4<br />(2016-) </td><td> 4-pin (DV) to 9-pin (FW 800)<br /><a href="https://www.apple.com/shop/product/MD464LL/A/apple-thunderbolt-to-firewire-adapter">Thunderbolt to FireWire adapter</a><br /><a href="https://www.apple.com/shop/product/MMEL2AM/A/thunderbolt-3-usb-c-to-thunderbolt-2-adapter">Thunderbolt 3 (USB-C) to Thunderbolt 2 Adapter</a> </td><td> <img src="docs/digitizing_vhs/4-9.jpg" height="75" width="150" alt="" /><br /><img src="docs/digitizing_vhs/fw_tb.jpg" height="52" width="256" alt="" /><br /><img src="docs/digitizing_vhs/tb_tb.jpg" height="52" width="256" alt="" /> </td></tr></tbody></table><p>The older the Mac, the fewer adapters you will need, but the more hassle it will be installing the necessary software. The sweet spot seem to be late FireWire 800 Macs (model years 2011-2012) or Macs with Thunderbolt 1/2 (model years 2011-2015).</p><h2 id="installing-tools">Installing Tools</h2><p>macOS supports DV video over FireWire natively, so you can open QuickTime Player, and select “File -> New Movie Recording…” to preview what is being transmitted by the camcorder. While QuickTime Player can record, the resulting video will already be deinterlaced using the low-quality “blend” method.</p><p>Apple’s iMovie has a dedicated DV/FireWire import function that will save MOV-encapsulated DV video, but has the habit of silently stopping recording when there is an empty area of the source tape.</p><p>The open source <code>ffmpeg</code> tool not only allows grabbing the original DV bits from FireWire, it can also convert video in all kinds of formats.</p><p>If you are running macOS 11 (Big Sur) or later, install <a href="https://brew.sh">Homebrew</a>, and then install <code>ffmpeg</code> with this Terminal command:</p><pre><code>brew install ffmpeg</code></pre><p>Homebrew should also work but is <a href="https://docs.brew.sh/Installation#2">unsupported</a> on 10.11 (El Capitan) through 10.15 (Catalina). If Homebrew does not work on your version of macOS, you may want to find an <a href="https://duckduckgo.com/?q=static+ffmpeg+mac">ffmpeg binary through other means</a> or consider upgrading to a later version of macOS – maybe even through <a href="https://dortania.github.io/OpenCore-Legacy-Patcher/">OpenCore Legacy Patcher</a>.</p><h2 id="digitizing">Digitizing</h2><p>Make sure the camcorder’s audio is configured to 48 KHz 16 bit mode (as opposed to 32 KHz 12 bit). Connect the camera to the Mac and switch it into “PLAY” or “DAC” mode. Then run the following Terminal command to list the available capture devices:</p><pre><code>ffmpeg -f avfoundation -list_devices true -i ""</code></pre><p>On my MacBook Pro, this prints:</p><pre><code>AVFoundation video devices: [0] DCR-TRV520E [1] FaceTime HD Camera [2] Capture screen 0 AVFoundation audio devices: [0] Speaker Audio Recorder [1] MacBook Pro Microphone</code></pre><p>It detected the Sony DCR-TRV520E. We will have to pass this device name whenever we want to read DV data with ffmpeg.</p><p>To capture the video tape into a DV stream, enter the following command (replacing the device name) and press PLAY on the VCR immediately after.</p><pre><code>ffmpeg -f avfoundation -capture_raw_data true -i "DCR-TRV520E" -c copy -map 0 -f rawvideo video.dv</code></pre><p>Once the tape is finished, press Ctrl+C to stop recording. If you want to automatically stop the recording after a certain time, you can add something like <code>-t 4:10:00</code> (4h 10m) to the command line.</p><p>You can monitor the progress by looking at the camcorder’s viewfinder or LCD, or by using this command in a different Terminal window:</p><pre><code>tail -f video.dv | ffplay -i -</code></pre><h2 id="compressing">Compressing</h2><p>While DV is an excellent archival format, it’s also big: about 11 GB per hour. MPEG-2 can slash this by a factor of three (4.5 GB per hour). The following line recompresses the DV into DVD-quality MPEG-2, leaving the interlacing intact.</p><pre><code>ffmpeg -i video.dv -b:v 10M -flags +ildct+ilme video.vob</code></pre><p>Here is the corresponding line to encode the video in H.264 at 3 MBit/sec, which is about the same quality, and also with interlacing intact. This will be a little more than 1 GB per hour – 10 times smaller than DV.</p><pre><code>ffmpeg -i video.dv -b:v 3M -flags +ildct+ilme video.mp4</code></pre><p>While H.265 has some basic support for interlaced video, neither ffmpeg nor VLC support it without tricks, and AV1 does not support interlaced video at all. Consequently, H.264 is effectively the latest compression format that you should use to store interlaced video.</p><h2 id="on-the-fly-compression">On-the-fly Compression</h2><p>Any Intel or Apple Silicon Mac can also encode MPEG-2 in real-time. The following line skips the intermediate DV file:</p><pre><code>ffmpeg -f avfoundation -capture_raw_data true -i "DCR-TRV520E" -c copy -map 0 -f rawvideo pipe:1 | ffmpeg -i - -b:v 10M -flags +ildct+ilme video.vob</code></pre><p>And this is the line to encode straight into H.264. You will need a 2015 or newer Mac for this, otherwise it won’t be able to keep up with the incoming data.</p><pre><code>ffmpeg -f avfoundation -capture_raw_data true -i "DCR-TRV520E" -c copy -map 0 -f rawvideo pipe:1 | ffmpeg -i - -b:v 3M -flags +ildct+ilme video.mp4</code></pre><h2 id="deinterlacing">Deinterlacing</h2><p>If you need the video in progressive format, you can use the following commands to deinterlace the video. You should try the 50/60 Hz command first, which will retain motion smoothness. If the resulting video contains every frame twice (verify by single stepping with the arrow keys in QuickTime), the original material was 25/30 Hz, so you can to re-do the deinterlacing with a frame rate of 25/30.</p><p>MPEG-2, 10 MBit, 50/60 frames per second:</p><pre><code>ffmpeg -i video.dv -vf yadif=1:-1:0 -b:v 10M video.vob</code></pre><p>MPEG-2, 10 MBit, 25/30 frames per second:</p><pre><code>ffmpeg -i video.dv -vf yadif=0:-1:0 -b:v 10M video.vob</code></pre><p>H.264, 3 MBit, 50/60 frames per second:</p><pre><code>ffmpeg -i video.dv -vf yadif=1:-1:0 -b:v 3M video.mp4</code></pre><p>H.264, 3 MBit, 25/30 frames per second:</p><pre><code>ffmpeg -i video.dv -vf yadif=0:-1:0 -b:v 3M video.mp4</code></pre><p>H.265, 1.5 MBit, 50/60 frames per second:</p><pre><code>ffmpeg -i video.dv -vf yadif=1:-1:0 -c:v libx265 -b:v 1.5M -tag:v hvc1 video.mp4</code></pre><p>H.265, 1.5 MBit, 25/30 frames per second:</p><pre><code>ffmpeg -i video.dv -vf yadif=0:-1:0 -c:v libx265 -b:v 1.5M -tag:v hvc1 video.mp4</code></pre><p>While the YADIF filter in ffmpeg does a pretty good job, there are now also machine-learning based tool like <a href="https://www.topazlabs.com/topaz-video-ai">Topaz Video AI</a> for deinterlacing.</p><p>Remember though that you should archive the original interlaced data, since deinterlacing is lossy.</p><h2 id="limitations">Limitations</h2><p>This method only captures the 720×576 (720×480) video signal and one stereo audio track of your media. Depending on the media, there may be information that is not captured:</p><ul><li>PAL broadcast recordings usually contain <a href="https://en.wikipedia.org/wiki/Teletext">teletext</a>, albeit with lots of errors, because of the insufficient bandwidth of tape.</li><li>NTSC broadcast recordings and pre-recorded media usually contain <a href="https://en.wikipedia.org/wiki/Closed_captioning">closed captioning</a>.</li><li>VHS contains a mono track and an optional HiFi stereo track. VHS players pick the HiFi stereo track if it exists, so this solution will not capture the mono track which, in theory, could contain entirely different audio.</li><li>LaserDisc can contain digital audio (PCM, Dolby Digital or DTS). If you want to capture the audio losslessly, you need to record it in parallel using an S/PDIF connection.</li></ul><p>In general, the recording will only be as good as the player can decode the media. If you don’t have access to a good player or if the media has defects, you may want to talk to a company that specializes in digitization services.</p><h2 id="simpler-solutions">Simpler Solutions</h2><p>If the solution described in this setup seems overkill, there are simpler solutions as well:</p><ul><li><p>A DVD recorder (or a VHS/DVD combo device like the Panasonic DMR-EX98V and DMR-EX99V) can convert analog sources (or VHS directly) into high-quality interlaced MPEG-2 files written to a recordable DVD. The downside is that these devices are usually limited to two (DVD-5), maybe four (DVD-9, i.e. dual-layer) hours of recording at 10 MBit/sec because of the limitied capacity of a DVD.</p></li><li><p>There are devices that connect to the analog signal on one side and to a computer’s USB port on one side. The PC/Mac software will usually create a deinterlaced MP4 file.</p></li><li><p><a href="https://www.youtube.com/watch?v=ZC5Zr3NC2PY">Technology Connections</a> describes a solution where you connect the video player to an analog-to-HDMI box, and its output in turn to a device that records HDMI onto an SD card. This will also deinterlace the video.</p></li></ul><h2 id="links">Links</h2><ul><li><a href="https://forums.macrumors.com/threads/updated-old-video-tapes-conversion-via-thunderbolt-firewire-for-camcorders-video-decks-and-players-that-supported-ieee-1394-firewire-ilink.2321691/">Old Video Tapes Conversion via Thunderbolt / Firewire </a></li><li><a href="https://leolabs.org/blog/capture-minidv-on-macos">Capturing and Archiving MiniDV Tapes on macOS</a></li><li><a href="https://mipops.github.io/dvrescue/index.html">DVRescue</a></li><li><a href="https://www.researchgate.net/publication/224078937_HDTV_subjective_quality_of_H264_vs_MPEG-2_with_and_without_packet_loss">HDTV subjective quality of H.264 vs. MPEG-2, with and without packet loss</a></li></ul><hr /><div class="footnotes"><hr/><ol><li id="fn:1"><p>NTSC DV uses 4:1:1 chroma subsampling instead of PAL’s 4:2:2, so it has a Chroma resolution of 130×480. This still surpasses all consumer formats – except DVD.<a href="#fnref:1" rev="footnote">↩</a></p></li><li id="fn:1"><p>Always use an S-Video connection if the player supports it! If the connector exists, it means the media supports a higher-than-composite color bandwidth, which is only available through S-Video.<a href="#fnref:1" rev="footnote">↩</a></p></li></ol></div>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1697</wfw:commentRss> <slash:comments>8</slash:comments> </item> <item> <title>Dissecting a Dummy Promo MiniDisc</title> <link>https://www.pagetable.com/?p=1693</link> <comments>https://www.pagetable.com/?p=1693#comments</comments> <pubDate>Thu, 17 Nov 2022 23:08:35 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Archeology]]></category> <category><![CDATA[Teardown]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1693</guid> <description><![CDATA[Many pre-recorded MiniDiscs are rare and expensive. An extra rare special case is the dummy promo copy of Michael Jackson’s “Dangerous”, which we will dissect in this article. Just looking at the case, the dummy promo copy looks like the regular retail MiniDisc: Instead of the inner pages with the song lyrics, the booklet only ... <a title="Dissecting a Dummy Promo MiniDisc" class="read-more" href="https://www.pagetable.com/?p=1693">Read more<span class="screen-reader-text">Dissecting a Dummy Promo MiniDisc</span></a>]]></description> <content:encoded><![CDATA[<p>Many pre-recorded MiniDiscs are rare and expensive. An extra rare special case is the <em>dummy</em> promo copy of Michael Jackson’s “Dangerous”, which we will dissect in this article.</p><p><img src="docs/promo_md/dummy.webp" height="379" width="292" alt="" /></p><p>Just looking at the case, the dummy promo copy looks like the regular retail MiniDisc:</p><p><img src="docs/promo_md/case_front.webp" height="410" width="284" alt="" /><img src="docs/promo_md/case_back.webp" height="410" width="427" alt="" /></p><p>Instead of the inner pages with the song lyrics, the booklet only contains a sheet with the MiniDisc logo:</p><p><img src="docs/promo_md/booklet_inner.webp" height="410" width="545" alt="" /></p><p>The front of the MiniDisc looks inconspicuous:</p><p><img src="docs/promo_md/md_front.webp" height="340" width="360" alt="" /></p><p>But instead of the track listing, the back only contains a sticker saying “NOT PLAYABLE”:</p><p><img src="docs/promo_md/md_back.webp" height="345" width="360" alt="" /></p><p>If you look closely, you can see that the actual disc behind the shutter has “DUMMY” etched into it. The full text is “DUMMY-CDF01-1/100”.</p><p>When trying to play the MiniDisc, any player will complain that it cannot read the TOC (table of contents). But a closer look reveals that the data area is not in fact empty:</p><p><img src="docs/promo_md/surface_dummy.webp" height="363" width="315" alt="" /></p><p>Like audio CDs, MiniDiscs are played from the inside to the outside. The innermost area (outside of the readable text) looks uniform, which usually indicates an empty area. Then, there are three areas of what looks like random data, with smaller regular stripes in between – this reminds of tracks on a vinyl record. For comparison, here is a proper pre-recorded MiniDisc:</p><p><img src="docs/promo_md/surface_regular.webp" height="363" width="377" alt="" /></p><p>The empty area is at the end of the MiniDisc, that is, on the outside. The data is in one large area – individual tracks are in fact not visible.</p><p>The random areas do look like they contain some data, so we have to try to read it! But how do you play a MiniDisc without a valid TOC? By hot-swapping a good MiniDisc with this one! I used a toothpick on the door detection switch of a SHARP MD-MT15 so I could open the door without the player noticing, as described <a href="https://www.pagetable.com/?p=1384">in my article about dumping MiniDiscs</a>:</p><p><img src="docs/dumping_md/recover1.jpg" height="330" width="440" alt="" /><img src="docs/dumping_md/recover2.jpg" height="330" width="440" alt="" /></p><p>No matter which of the 11 tracks (i.e. offsets) of the good MiniDisc I picked, the player always shows a READ ERROR after a few seconds. It seems the “data” area does not in fact contain any correctly formatted data sectors.</p><p><img src="docs/promo_md/read_error.webp" height="350" width="446" alt="" /></p><p>Yes, it’s disappointing, but I chose to publish this anyway to counter <a href="https://en.wikipedia.org/wiki/Publication_bias">publication bias</a>, and to maybe motivate someone else to come up with a different method to analyze what’s on these dummy MiniDiscs!</p><p>Here’s a question though: What was the point of these dummy promo MiniDiscs? What were they used for?</p><h2 id="references">References</h2><ul><li><a href="https://www.laserdiscplaza.fr/forumld/viewtopic.php?t=6415">Toutes les versions de “Dangerous” en MD</a> by macaddict77, 2020-08-12</li><li><a href="https://www.discogs.com/release/15823037-Michael-Jackson-Dangerous">Discogs: Dangerous (Promo, Not Playable – Mock-Up)</a></li><li><a href="https://www.discogs.com/release/12752332-Michael-Jackson-Dangerous">Discogs: Dangerous (Promo)</a></li></ul>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1693</wfw:commentRss> <slash:comments>8</slash:comments> </item> <item> <title>The Commodore VICMODEM (Model 1600)</title> <link>https://www.pagetable.com/?p=1679</link> <comments>https://www.pagetable.com/?p=1679#comments</comments> <pubDate>Mon, 27 Jun 2022 15:25:28 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Archeology]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Literature]]></category> <category><![CDATA[Modem]]></category> <category><![CDATA[VIC-20]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1679</guid> <description><![CDATA[The Commodore 1600, also known as the “VICMODEM”, is Commodore’s very first modem (1982): It supports 300 baud duplex connections, and is connected to an existing telephone’s handset connector instead of the phone line. This kept the price down, but required the user to dial manually through the phone. Historical Context Year Name Model Description ... <a title="The Commodore VICMODEM (Model 1600)" class="read-more" href="https://www.pagetable.com/?p=1679">Read more<span class="screen-reader-text">The Commodore VICMODEM (Model 1600)</span></a>]]></description> <content:encoded><![CDATA[<p>The Commodore 1600, also known as the “VICMODEM”, is Commodore’s very first modem (1982): It supports 300 baud duplex connections, and is connected to an existing telephone’s handset connector instead of the phone line. This kept the price down, but required the user to dial manually through the phone.</p><h2 id="historical-context">Historical Context</h2><table><thead><tr><th> Year </th><th> Name </th><th> Model </th><th> Description </th></tr></thead><tbody><tr><td> 1982 </td><td> <a href="https://www.pagetable.com/?p=1679">VICMODEM</a> </td><td> 1600 </td><td> connected to phone’s handset connector; manual dialing through phone; Motorola MC14412 </td></tr><tr><td> 1982 </td><td> <a href="https://www.pagetable.com/?p=1716">AUTOMODEM</a> </td><td> 1650 </td><td> connected to phone line, pulse dialing in software; Motorola MC14412 </td></tr><tr><td> 1985 </td><td> <a href="https://www.pagetable.com/?p=1644">MODEM/300</a> </td><td> 1660 </td><td>added tone dialing support by feeding SID output into modem; Texas Instruments TMS99532A </td></tr><tr><td> 1987 </td><td> <a href="https://www.pagetable.com/?p=1647">MODEM/1200</a> </td><td> 1670 </td><td> Hayes command set; pulse and tone dialing in hardware; 300/1200 baud support; U.S. Robotics chipset </td></tr></tbody></table><h2 id="photos">Photos</h2><p><a href="docs/cbm1600modem/cbm1600_1.jpg"><img src="docs/cbm1600modem/cbm1600_1.jpg" height="383" width="459" alt="" /></a></p><p>On the back, there is the RJ11C handset connector. On the side, there is an LED indicating that indicates when the phone is transmitting or receiving, and a switch that can be put into the “A” (answer) or “O” (originate) position, depending whether a phone call is supposed to be made or accepted.</p><p><a href="docs/cbm1600modem/cbm1600_2.jpg"><img src="docs/cbm1600modem/cbm1600_2.jpg" height="345" width="459" alt="" /></a></p><p>On the front, there is the VIC-20/C64 user port connector.</p><p><a href="docs/cbm1600modem/front.jpg"><img src="docs/cbm1600modem/front.jpg" height="480" width="270" alt="" /></a><a href="docs/cbm1600modem/back.jpg"><img src="docs/cbm1600modem/back.jpg" height="468" width="250" alt="" /></a></p><p>The label on the bottom says:</p><blockquote><p>FCC ID: B4V8N2VIC 20<br />Commodore Business Machines, Inc.<br />Made in USA</p><p>Certified to comply with the limits for a Class B<br />computing device pursuant to Subpart J of<br />Part 15 of FCC Rules. See instructions if<br />interference to radio reception is suspected.</p><p>COMPLIES WITH PART 68, FCC RULES FCC<br />REGISTRATION NUMBER B4V8N2-68331-<br />KX-N RINGER EQUIVALENCE O.0B JACK<br />(USOC) N.A. (KX)</p><p>Model 1600<br />Serial Number: 093333</p></blockquote><p><a href="docs/cbm1600modem/board1.jpg"><img src="docs/cbm1600modem/board1.jpg" height="472" width="263" alt="" /></a><a href="docs/cbm1600modem/board2.jpg"><img src="docs/cbm1600modem/board2.jpg" height="465" width="262" alt="" /></a></p><p>The only text on the board is “PWB 00201 B” on the back. The core component is the Motorola <a href="docs/cbm1600modem/MC14412.pdf">MC14412</a> modem chip (bottom, second from the left).</p><p>The RJ11 connector on the back must be connected to an existing phone, instead of its handset, like this:</p><p><img src="docs/cbm1600modem/connection1.png" height="179" width="474" alt="" /></p><p>The VICMODEM does not talk on the phone line level, but on the handset level, this reusing the hardware in the existing phone. This allowed the modem to be produced for under $33, so it could be the first modem to be sold for under $100<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup>.</p><p>The flip side of this design was that the modem could not dial or answer by itself. To dial a number, it had to be keyed into the telephone with the handset connected, and once one would hear that the remote side picked up, switch the cable to the modem. To wait for a call and answer it, the modem has to be connected and the (unconnected) handset has to be in the cradle. Once it rings, the handset has to be picked up and set aside.</p><p><img src="docs/cbm1600modem/connection2.png" height="243" width="389" alt="" /></p><p>This is exactly how one would operate an acoustic coupler. After all, this modem is more of an acoustic coupler with a direct audio connection than a full modem.</p><h2 id="box">Box</h2><p><a href="docs/cbm1600modem/box_top.jpg"><img src="docs/cbm1600modem/box_top.jpg" height="57" width="257" alt="" /></a><br /><a href="docs/cbm1600modem/box_front.jpg"><img src="docs/cbm1600modem/box_front.jpg" height="357" width="257" alt="" /></a><a href="docs/cbm1600modem/box_back.jpg"><img src="docs/cbm1600modem/box_back.jpg" height="357" width="257" alt="" /></a> <a href="docs/cbm1600modem/box_side.jpg"><img src="docs/cbm1600modem/box_side.jpg" height="357" width="59" alt="" /></a></p><p>In late 1983, the modem was already sold for under $70.</p><h2 id="manual">Manual</h2><p><a href="docs/cbm1600modem/cbm1600modem_manual.pdf"><img src="docs/cbm1600modem/cbm1600modem_manual.jpg" height="261" width="189" alt="" /></a></p><h2 id="more-box-contents">More Box Contents</h2><p><a href="docs/cbm1600modem/warranty_card.pdf"><img src="docs/cbm1600modem/warranty_card.png" height="262" width="131" alt="" /></a> <a href="docs/cbm1600modem/services.pdf"><img src="docs/cbm1600modem/services.png" height="260" width="172" alt="" /></a><br /><a href="docs/cbm1600modem/dowjones1.pdf"><img src="docs/cbm1600modem/dowjones1.jpg" height="176" width="77" alt="" /></a> <a href="docs/cbm1600modem/dowjones2.pdf"><img src="docs/cbm1600modem/dowjones2.jpg" height="208" width="159" alt="" /></a> <a href="docs/cbm1600modem/dowjones_envelope.pdf"><img src="docs/cbm1600modem/dowjones_envelope.png" height="95" width="217" alt="" /></a><br /><a href="docs/cbm1600modem/compuserve1.pdf"><img src="docs/cbm1600modem/compuserve1.png" height="187" width="144" alt="" /></a> <a href="docs/cbm1600modem/compuserve2.pdf"><img src="docs/cbm1600modem/compuserve2.png" height="187" width="144" alt="" /></a> <a href="docs/cbm1600modem/compuserve3.pdf"><img src="docs/cbm1600modem/compuserve3.png" height="97" width="147" alt="" /></a></p><p>The CompuServe signup form came with the user name and the password pre-filled. We would have been user 75155,731 with a password of <code>FRILL:DOUBLET</code>.</p><h2 id="tape">Tape</h2><p><a href="docs/cbm1600modem/tape1.jpg"><img src="docs/cbm1600modem/tape1.jpg" height="122" width="190" alt="" /></a> <a href="docs/cbm1600modem/tape2.jpg"><img src="docs/cbm1600modem/tape2.jpg" height="122" width="190" alt="" /></a></p><p><a href="docs/cbm1600modem/64%20term.prg">64 TERM.PRG</a> (2577 bytes)</p><hr /><div class="footnotes"><hr/><ol><li id="fn:1"><p><a href="https://talesfromthecollection.com/2021/10/19/michael-tomczyk-commodore/">Michael Tomczyk: Commodore VIC-20 Developer, Computer Pioneer</a><a href="#fnref:1" rev="footnote">↩</a></p></li></ol></div>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1679</wfw:commentRss> <slash:comments>5</slash:comments> </item> <item> <title>PostScript Cartridge Plus for HP LaserJet III</title> <link>https://www.pagetable.com/?p=1673</link> <comments>https://www.pagetable.com/?p=1673#comments</comments> <pubDate>Tue, 21 Jun 2022 06:31:49 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Archeology]]></category> <category><![CDATA[PostScript]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1673</guid> <description><![CDATA[The HP LaserJet III laser printer from 1990 used the “Printer Command Language” PCL 5 by default, but could be upgraded with the “HP PostScript Cartridge Plus” cartridge, which contained 2 MB of ROM with Adobe’s PostScript Level 2 rasterizer. Let’s look at the ROM contents and some of its hidden gems. Cartridge The cartridge ... <a title="PostScript Cartridge Plus for HP LaserJet III" class="read-more" href="https://www.pagetable.com/?p=1673">Read more<span class="screen-reader-text">PostScript Cartridge Plus for HP LaserJet III</span></a>]]></description> <content:encoded><![CDATA[<p>The HP LaserJet III laser printer from 1990 used the “Printer Command Language” PCL 5 by default, but could be upgraded with the “HP PostScript Cartridge Plus” cartridge, which contained 2 MB of ROM with Adobe’s PostScript Level 2 rasterizer. Let’s look at the ROM contents and some of its hidden gems.</p><p><a href="docs/postscript_cartridge_plus/postscript_cartridge_plus_case.jpg"><img src="docs/postscript_cartridge_plus/postscript_cartridge_plus_case.jpg" height="303" width="403" alt="" /></a></p><h2 id="cartridge">Cartridge</h2><p>The cartridge is about 9×14 cm in size.</p><p><a href="docs/postscript_cartridge_plus/postscript_cartridge_plus_case_front.jpg"><img src="docs/postscript_cartridge_plus/postscript_cartridge_plus_case_front.jpg" height="380" width="269" alt="" /></a><a href="docs/postscript_cartridge_plus/postscript_cartridge_plus_case_back.jpg"><img src="docs/postscript_cartridge_plus/postscript_cartridge_plus_case_back.jpg" height="391" width="270" alt="" /></a></p><p><a href="docs/postscript_cartridge_plus/postscript_cartridge_plus_case_side.jpg"><img src="docs/postscript_cartridge_plus/postscript_cartridge_plus_case_side.jpg" height="52" width="270" alt="" /></a></p><p>The front says</p><blockquote><p>HEWLETT PACKARD</p><p>PostScript Cartridge Plus</p><p>ITC Avant Garde Gothic®<br />ITC Bookman®<br />Courier<br />Helvetica®<br />Helvetica-Narrow<br />New Century Schoolbook<br />Palatino®<br />Times®<br />ITC Zapf Chancery®<br />TIC Zapf Dingbats®<br />Symbol<br />C2089A ©Hewlett-Packard 1989, 1990, 1991</p><p>HP<br />LASERJET III<br />POSTSCRIPT®</p></blockquote><p>The back says</p><blockquote><p>Adobe and PostScript are registered trademark of Adobe Systems<br />Incorporated in the U.S, and other countries. Helvetica, Palatino and<br />Times Roman are registered trademarks of Linotype AG and/<br />or its subsidiaries in the U.S. and other countries. IT Avant Garde<br />Gothic, ITC Bookman, ITC Zapf Chancery and ITC Zapf Dingbats are<br />registered trademarks of International Typeface Corporation in the<br />U.S, and other countries.</p></blockquote><h2 id="board">Board</h2><p><a href="docs/postscript_cartridge_plus/postscript_cartridge_plus_board_front.jpg"><img src="docs/postscript_cartridge_plus/postscript_cartridge_plus_board_front.jpg" height="247" width="377" alt="" /></a><br /><a href="docs/postscript_cartridge_plus/postscript_cartridge_plus_board_back.jpg"><img src="docs/postscript_cartridge_plus/postscript_cartridge_plus_board_back.jpg" height="257" width="381" alt="" /></a></p><p>Here is the front without the components:<br /><a href="docs/postscript_cartridge_plus/postscript_cartridge_plus_board_front_empty.jpg"><img src="docs/postscript_cartridge_plus/postscript_cartridge_plus_board_front_empty.jpg" height="247" width="377" alt="" /></a></p><p>The board contains 6 74-series logic chips:</p><ul><li>1x SN74ALS139N: Dual 2-to-4 Decoder/Demultiplexer</li><li>4x SN74ALS244BN: Octal Buffer and Line Driver with 3-State Output</li><li>1x SN74LS32N: Quadruple 2-Input Positive-Or Gates [marked as HP part number 1820-1208]</li></ul><p>and four 512 KB mask ROM chips of the type Fujitsu MB834200B-15 (27C400 pinout). They are all marked with</p><blockquote><p>© 1991 HP-BOISE<br />© 1984-90 ADOBE<br />© 1981 LINOTYPE AG<br />© 1991 FUJITSU</p></blockquote><h2 id="rom">ROM</h2><p>These are the verbatim dumps (adjacent bytes are swapped):</p><ul><li><a href="docs/postscript_cartridge_plus/1818-5336_16a.bin">1818-5336 / 16A AA</a>, MD5 258464faa19a1ff78bbb57270eec8835</li><li><a href="docs/postscript_cartridge_plus/1818-5318_03a.bin">1818-5318 / 03A AA</a>, MD5 da113b6c6c53e21858b30a71c7be017c</li><li><a href="docs/postscript_cartridge_plus/1818-5319_04a.bin">1818-5319 / 04A AA</a>, MD5 f6e368806aa8caf22b4c28d235a2df1d</li><li><a href="docs/postscript_cartridge_plus/1818-5320_05a.bin">1818-5320 / 05A AA</a>, MD5 ed1700895daeac733f80ce20278c4a64</li></ul><p>This is the combined (<a href="docs/postscript_cartridge_plus/byteswap.py">byte-swapped</a>) 2 MB ROM image:</p><p><a href="docs/postscript_cartridge_plus/c2089a.bin">HP PostScript Cartridge Plus C2089A ROM</a>, MD5 8a5d1f66ab1624e7188fc07154f4224d</p><p>The ROM image starts with a signature of “SYST” and the following messages at 0x30:</p><blockquote><p>V9H-18f PSCRIPT<br />09.H<br />Copyright © Hewlett-Packard Company, 1991. All rights reserved.</p></blockquote><p>The ROM contains Adobe’s PostScript Level 2 rasterizer compiled for the 68000 CPU, the PostScript base fonts as well as some LaserJet-specific software (messages, errors and settings texts for the 15 char display in several languages).</p><h2 id="postscript-files">PostScript Files</h2><p>There is also some PostScript source code in the ROMs!</p><ul><li><a href="docs/postscript_cartridge_plus/ps/fontpage.ps">fontpage.ps</a></li><li><a href="docs/postscript_cartridge_plus/ps/test_page.ps">test_page.ps</a></li><li><a href="docs/postscript_cartridge_plus/ps/startup_page.ps">startup_page.ps</a></li></ul><p>(The missing <code>%!</code> file header has been added to the downloads.)</p><p>Since this is printer-specific PostScript code, it may not work with computer-based rasterizers, so let’s go over them one by one.</p><h3 id="fontpage">FONTPAGE</h3><p>This is “FONTPAGE” converted to PDF using GPL GhostScript:</p><p><a href="docs/postscript_cartridge_plus/ps/fontpage.pdf">fontpage.pdf</a></p><p><img border="1" src="docs/postscript_cartridge_plus/ps/fontpage.png" width="319" height="413"/></p><p>The PostScript code contains the <code>product</code> operator, which returns the name of the printer, so the second line – “GPL Ghostscript printer” – would read “HP LaserJet III printer” on an actual LaserJet.</p><h3 id="test-page">TEST PAGE</h3><p>“TEST PAGE” prints various internal printer settings which are unsupported by computer-based PostScript rasterizers, so some lines had to be removed for the file to work. These are the files hacked for different rasterizers:</p><table><tr><td>Adobe Acrobat Distiller 5.0 (2001) </p><li><a href="docs/postscript_cartridge_plus/ps/test_page_acrobat.ps">test_page_acrobat.ps</a></li><li><a href="docs/postscript_cartridge_plus/ps/test_page_acrobat.pdf">test_page_acrobat.pdf</a></li><p><img border="1" src="docs/postscript_cartridge_plus/ps/test_page_acrobat.png" width="319" height="413"/></td><td>macOS 12.4 PSNormalizer.framework </p><li><a href="docs/postscript_cartridge_plus/ps/test_page_apple.ps">test_page_apple.ps</a></li><li><a href="docs/postscript_cartridge_plus/ps/test_page_apple.pdf">test_page_apple.pdf</a></li><p><img border="1" src="docs/postscript_cartridge_plus/ps/test_page_apple.png" width="319" height="413"/></td></tr><tr><td>GhostScript 9.56.1 </p><li><a href="docs/postscript_cartridge_plus/ps/test_page_gs.ps">test_page_gs.ps</a></li><li><a href="docs/postscript_cartridge_plus/ps/test_page_gs.pdf">test_page_gs.pdf</a></li><p><img border="1" src="docs/postscript_cartridge_plus/ps/test_page_gs.png" width="319" height="413"/></td></tr></table><p>(The almost identical contents of Acrobat Distiller 5.0 and Apple’s PS to PDF converter built into macOS (down to the internal version number!) is no coincidence: Apple’s converter is in fact a licensed “Adobe Normalizer 5.0”<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup>, the same engine powering Distiller 5.0.)</p><p>There is a second page which only prints if the <code>product</code> is “HP LaserJet IIP” or “HP LaserJet IIIP”:</p><ul><li><a href="docs/postscript_cartridge_plus/ps/test_cleaning.ps">test_cleaning.ps</a></li><li><a href="docs/postscript_cartridge_plus/ps/test_cleaning.pdf">test_cleaning.pdf</a></li></ul><p><img border="1" src="docs/postscript_cartridge_plus/ps/test_cleaning.png" width="319" height="413"/></p><h3 id="startup-page">STARTUP PAGE</h3><ul><li><a href="docs/postscript_cartridge_plus/ps/startup_page.ps">startup_page.ps</a></li><li><a href="docs/postscript_cartridge_plus/ps/startup_page.pdf">startup_page.pdf</a></li></ul><p><img border="1" src="docs/postscript_cartridge_plus/ps/startup_page.png" width="319" height="413"/></p><p>There is no such device as a “LaserJet IIx” – this is what the PostScript code falls back to if the <code>product</code> is none of these:</p><ul><li>“HP LaserJet IID”</li><li>“HP LaserJet IIP”</li><li>“HP LaserJet III”</li><li>“HP LaserJet IIID”</li><li>“HP LaserJet IIIP”</li></ul><p>Tests for these can be found across all PostScript code in the ROM. The IIID (“duplex”) and IIIP (“personal”) and variants of the LaserJet III. HP never offered PostScript for the LaserJet II series, so it is unknown why these product names show up in the ROM.</p><h2 id="future-work">Future Work</h2><p>There are several open questions that might be interesting:</p><ul><li>What’s up with PostScript for the LaserJet II?</li><li>Did the cartridge extend the printer’s internal ROM or replace it?</li><li>What other PostScript features are supported that are not official API?</li><li>What is the computer inside the LaserJet III like? Can we emulate it and run this rasterizer on a computer?</li><li>What is the pinout of the cartridge connector?</li></ul><div class="footnotes"><hr/><ol><li id="fn:1"><p><code>strings /System/Library/PrivateFrameworks/PSNormalizer.framework/Versions/A/Resources/PS.VM | grep -i Adobe</code><a href="#fnref:1" rev="footnote">↩</a></p></li></ol></div>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1673</wfw:commentRss> <slash:comments>6</slash:comments> </item> <item> <title>CCGMS Future 0.2</title> <link>https://www.pagetable.com/?p=1665</link> <comments>https://www.pagetable.com/?p=1665#comments</comments> <pubDate>Sun, 20 Mar 2022 17:56:09 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[GitHub]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1665</guid> <description><![CDATA[CCGMS Future 0.2 was just released. It adds 80 columns support, a true ASCII charset (in 80c mode), and bug fixes. Release on CSDb Release on GitHub]]></description> <content:encoded><![CDATA[<p>CCGMS Future 0.2 was just released. It adds 80 columns support, a true ASCII charset (in 80c mode), and bug fixes.</p><p><img src="docs/ccgms_80.png"/></p><ul><li><a href="https://csdb.dk/release/?id=215589">Release on CSDb</a></li><li><a href="https://github.com/mist64/ccgmsterm/releases/tag/v0.2">Release on GitHub</a></li></ul>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1665</wfw:commentRss> <slash:comments>2</slash:comments> </item> <item> <title>The Punter C1 Protocol</title> <link>https://www.pagetable.com/?p=1663</link> <comments>https://www.pagetable.com/?p=1663#comments</comments> <pubDate>Tue, 15 Mar 2022 01:17:43 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Archeology]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1663</guid> <description><![CDATA[The Punter file transfer protocol (“New Punter”/“Punter C1”) is an alternative to the XMODEM family of protocols, which was and still is very popular on BBSes for Commodore computers. It is notorious for being badly documented. Let’s fix that. I quickly developed quite a distaste for the badly designed punter protocol. Especially with the awful ... <a title="The Punter C1 Protocol" class="read-more" href="https://www.pagetable.com/?p=1663">Read more<span class="screen-reader-text">The Punter C1 Protocol</span></a>]]></description> <content:encoded><![CDATA[<p>The Punter file transfer protocol (“New Punter”/“Punter C1”) is an alternative to the XMODEM family of protocols, which was and still is very popular on BBSes for Commodore computers. It is notorious for being badly documented. Let’s fix that.</p><blockquote><p>I quickly developed quite a distaste for the badly designed punter protocol. Especially with the awful and rather smug “documentation”.</p><div style="float: right;">— MagerValp</div></blockquote><h2 id="the-protocol">The Protocol</h2><p>The protocol allows the transmission of one file from the “sender” to the “receiver”. No file name, but a 1-byte file type is transmitted (0=<code>PRG</code>, 1=<code>SEQ</code>).</p><p>For handshaking, the three-byte ASCII strings <code>GOO</code>, <code>BAD</code>, <code>ACK</code>, <code>S/B</code>, <code>SYN</code> are used.</p><p>The transmission of a file consists of two almost identical phases:</p><ul><li>Phase A transmits the file type, and consists of a lot of handshaking and overhead to transmit a single block with a single payload byte (the file type).</li><li>Phase B transmits the file data in one or more blocks. “B2” is repeated for each block.</li></ul><table><tr><td><h3 id="a-file-type">A File Type</h3></td><td><h3 id="b-file-contents">B File Contents</h3></td></tr><td><h4 id="a1-start">A1 Start</h4><table><thead><tr><th></th><th>Sender</th><th>Receiver</th></tr></thead><tbody><tr><td>1</td><td><code>GOO</code></td><td></td></tr><tr><td>2</td><td></td><td><code>GOO</code></td></tr></tbody></table></td><td><h4 id="b1-start">B1 Start</h4><table><thead><tr><th></th><th>Sender</th><th>Receiver</th></tr></thead><tbody><tr><td>17</td><td></td><td><code>GOO</code></td></tr></tbody></table></td></tr><td><h4 id="a2-block">A2 Block</h4><table><thead><tr><th></th><th>Sender</th><th>Receiver</th></tr></thead><tbody><tr><td>3</td><td><code>ACK</code></td><td></td></tr><tr><td>4</td><td></td><td><code>S/B</code></td></tr><tr><td>5</td><td>block data</td><td></td></tr><tr><td>6</td><td></td><td><code>GOO</code>*</td></tr></tbody></table></td><td><h4 id="b2-blocks-(repeated)">B2 Blocks<em>(repeated)</em></h4><table><thead><tr><th></th><th>Sender</th><th>Receiver</th></tr></thead><tbody><tr><td>18</td><td><code>ACK</code></td><td></td></tr><tr><td>19</td><td></td><td><code>S/B</code></td></tr><tr><td>20</td><td>block data</td><td></td></tr><tr><td>21</td><td></td><td><code>GOO</code>*</td></tr></tbody></table></td></tr><td><h4 id="a3-end-off">A3 End-Off</h4><table><thead><tr><th></th><th>Sender</th><th>Receiver</th></tr></thead><tbody><tr><td>7</td><td><code>ACK</code></td><td></td></tr><tr><td>8</td><td></td><td><code>S/B</code></td></tr><tr><td>9</td><td><code>SYN</code></td><td></td></tr><tr><td>10</td><td></td><td><code>SYN</code></td></tr><tr><td>11</td><td><code>S/B</code></td><td></td></tr><tr><td>12</td><td><em>(wait 1s)</em></td><td><em>(ignored)</em></td></tr><tr><td>13</td><td><code>S/B</code></td><td></td></tr><tr><td>14</td><td><em>(wait 1s)</em></td><td><em>(ignored)</em></td></tr><tr><td>15</td><td><code>S/B</code></td><td></td></tr><tr><td>16</td><td><em>(wait 1s)</em></td><td><em>(ignored)</em></td></tr></tbody></table></td><td><h4 id="b3-end-off">B3 End-Off</h4><table><thead><tr><th></th><th>Sender</th><th>Receiver</th></tr></thead><tbody><tr><td>22</td><td><code>ACK</code></td><td></td></tr><tr><td>23</td><td></td><td><code>S/B</code></td></tr><tr><td>24</td><td><code>SYN</code></td><td></td></tr><tr><td>25</td><td></td><td><code>SYN</code></td></tr><tr><td>26</td><td><code>S/B</code></td><td></td></tr><tr><td>27</td><td><em>(wait 1s)</em></td><td><em>(ignored)</em></td></tr><tr><td>28</td><td><code>S/B</code></td><td></td></tr><tr><td>29</td><td><em>(wait 1s)</em></td><td><em>(ignored)</em></td></tr><tr><td>30</td><td><code>S/B</code></td><td></td></tr><tr><td>31</td><td><em>(wait 1s)</em></td><td><em>(ignored)</em></td></tr></tbody></table></td></tr></table><p>*Step 6/21: After receiving the block data, if the checksum is incorrect, the receiver sends <code>BAD</code>, moving the protocol to step 3/18 with the same block.</p><h3 id="blocks">Blocks</h3><p>Every block has a 7 byte header:</p><table><thead><tr><th> offset </th><th> size </th><th> description </th></tr></thead><tbody><tr><td> 0 </td><td> 2 </td><td> “additive” checksum </td></tr><tr><td> 2 </td><td> 2 </td><td> “cyclic” checksum </td></tr><tr><td> 4 </td><td> 1 </td><td> size of <em>next</em> block </td></tr><tr><td> 5 </td><td> 2 </td><td> block index </td></tr></tbody></table><p>The two checksums are calculated over all bytes of the block, starting with index 4.</p><ul><li>The “additive” checksum is calculated by adding all bytes.</li><li>The “cyclic” checksum is calculated by XORing all bytes, rotating the 16 bit result left after each byte.</li></ul><p>Block sizes can be freely chosen and can vary from block to block. The maximum size is 255. This includes the 7 header bytes, so the payload is up to 248 bytes. Every block contains the size of the following block. The size of the first block is fixed (per phase). (For the last block in a sequence, this field is unused.)</p><p>The block index starts with 0. The last block (or only block) in a sequence has index -1 ($FFFF), though it is enough to only check the hi byte. This allows file sizes of almost 16 MB.</p><h3 id="file-type-transmission">File Type Transmission</h3><p>File type transmission only consists of a single 8 byte block. Its index is -1, since it is the last block. The single payload byte is the file type.</p><h3 id="file-data-transmission">File Data Transmission</h3><p>File data transmission starts with a 7 byte header block that contains no payload. Its purpose is to communicate the size of the first block that actually contains file data.</p><h2 id="bugs">Bugs</h2><h3 id="checksum">Checksum</h3><p>The two checksums are 32 bits total, yet CRC16 would probably provide better integrity guarantees.</p><h3 id="end-off-sequence">End-Off Sequence</h3><p>Steps 11-16 and 26-31 in the “End-Off” sequence in both phases are buggy. In the original implementation</p><ul><li>The sender repeats the following three times: transmit <code>S/B</code>, then keep reading a byte from the modem about 5000 times, discarding the data. This takes about one second on a C64.</li><li>The receiver expects just one <code>S/B</code>, then proceeds to the next step. The <code>GOO</code> sent in step 17 will be ignored by the sender.</li></ul><p>Because of the resends in the original implementation, the protocol can recover from this.</p><p>(Lines 5070-5120 in the <a href="https://groups.google.com/g/net.micro.cbm/c/NWEcf_15nkk/m/MKtq7fyetMYJ">original source</a> are responsible for this. The call to <code>accept</code> with an argument of 0 will continue reading bytes from the modem until it times out, because it can’t match any of the codes. Maybe this was meant to match one or any specific code at some point.)</p><p>New implementations should expect three <code>S/B</code> and then wait for two seconds before continuing.</p><h2 id="multi-punter">Multi-Punter</h2><p>Multi-Punter is a very simple extension to the protocol that can transmit several files at a time and includes the file names and types. It has no error detection or re-send capability on a file level whatsoever.</p><p>Every file is transmitted like this:</p><ul><li>16× code 0x09 (TAB)</li><li><code>FILENAME,P</code> (<code>PRG</code>) or <code>FILENAME,S</code> (<code>SEQ</code>)</li><li>code 0x0D (CR)</li></ul><p>…followed by the transfer using the Punter protocol.</p><p>After the last file, the following is sent:</p><ul><li>16× code 0x09 (TAB)</li><li>16× code 0x04 (EOT)</li><li>code 0x0D (CR)</li></ul><h2 id="documentation">Documentation</h2><ul><li><a href="http://www.bbsdocumentary.com/software/COMMODORE/PET/PUNTERNET/punter_c1.txt">punter_c1.txt</a>: The original documentation by Steve Punter with additional comments by Geoffrey Welsh and Matthew Desmond</li><li><a href="https://csdb.dk/forums/?roomid=11&topicid=109007&showallposts=1">Thread on CSDb</a>, mostly by Oliver VieBrooks (Six), about reverse engineering the protocol</li></ul><h2 id="implementations">Implementations</h2><ul><li>The <a href="https://groups.google.com/g/net.micro.cbm/c/NWEcf_15nkk/m/MKtq7fyetMYJ">original 6502 source</a> by Steve Punter was posted to net.micro.cbm in 1985. Almost all software supporting the Punter protocol was based on this implementation.<ul><li>The binary and a BASIC program to control it are #1797 and #1798 in the <a href="https://cbmfiles.com/genie/C64TelecomListing.php">GEnie Commodore File Library</a></li></ul></li><li><a href="https://github.com/mist64/ccgmsterm/blob/main/src/punter.s">CCGMS Future</a> contains a cleaned-up and heavily commented version of the original code.</li><li><a href="https://csdb.dk/release/?id=45545">C*Base</a> contains an independent 6502 implementation. (Source is available in the downloads.)</li><li>There is a C implementation as part of <a href="https://github.com/MagerValp/CGTerm/blob/master/punter.c">CGTerm</a> by Per Olofsson (MagerValp). It only supports downloading and interoperates with the C*Base implementation, but not the original implementation. There is a <a href="https://github.com/mist64/ccgmsterm/blob/main/test/punter.c">hacked version</a> in the CCGMS Future repo that works with the original code (and CCGMS).</li><li><a href="https://github.com/sixofdloc/CBMTerm3/blob/master/FileTransferProtocols/Protocols/Punter.cs">CBMTerm</a> by Oliver VieBrooks (Six) contains a C# implementation, including Multi-Punter.</li><li>There is also a Rust implementation called <a href="https://github.com/srwalter/punter-server">punter-server</a> by Steven Walter.</li></ul>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1663</wfw:commentRss> <slash:comments>2</slash:comments> </item> <item> <title>UP9600: How to Bit-Bang 9600 Baud RS-232 on the C64</title> <link>https://www.pagetable.com/?p=1656</link> <comments>https://www.pagetable.com/?p=1656#comments</comments> <pubDate>Mon, 07 Mar 2022 18:11:14 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Hacks]]></category> <category><![CDATA[Hardware]]></category> <category><![CDATA[Tricks]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1656</guid> <description><![CDATA[The user port of the Commodore 64 exposes a TTL-level RS-232 serial port that supports up to 1200 baud1. In 1997, Daniel Dallmann came up with a very sophisticated trick that allowed sending and receiving at 9600 baud2, using slightly different wiring and a dedicated driver. This “UP9600” wiring has become the de-facto standard for ... <a title="UP9600: How to Bit-Bang 9600 Baud RS-232 on the C64" class="read-more" href="https://www.pagetable.com/?p=1656">Read more<span class="screen-reader-text">UP9600: How to Bit-Bang 9600 Baud RS-232 on the C64</span></a>]]></description> <content:encoded><![CDATA[<p>The user port of the Commodore 64 exposes a TTL-level RS-232 serial port that supports up to 1200 baud<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup>. In 1997, Daniel Dallmann came up with a very sophisticated trick that allowed sending and receiving at 9600 baud<sup id="fnref:2"><a href="#fn:2" rel="footnote">2</a></sup>, using slightly different wiring and a dedicated driver. This “UP9600” wiring has become the de-facto standard for all modern accessories, like C64 WiFi modems. Let’s see how UP9600 works.</p><h2 id="history">History</h2><p>Before diving into the details of RS-232 and the UP9600 solution, let’s look at some historical context.</p><h3 id="mos-6551-acia">MOS 6551 ACIA</h3><p>MOS made an RS-232 chip for the 6502: the 6551 ACIA (“Asynchronous Communications Interface Adapter”), which, per specification, can support up to 19200 baud. Commodore used it in the SuperPET (1981), the CBM-II series (1982) as well as the business-oriented Plus/4 (1984). It is exposed through a KERNAL driver as device #2.</p><h3 id="6551-emulator">6551 Emulator</h3><p>For cost saving reasons, the VIC-20 and its successors, the C64 and C128<sup id="fnref:3"><a href="#fn:3" rel="footnote">3</a></sup>, did not contain a 6551 chip. Instead, Commodore included a bit-banging driver in the KERNAL that emulated the 6551 and exposed it as device #2. This emulator supports up to 2400 baud, but due to DMA from the VIC-II video chip (“badlines”), only speeds up to 1200 are stable on the C64 (and the C128 in 40 columns mode).</p><h3 id="software-2400-baud">Software 2400 baud</h3><p>In the article “Toward 2400” in <a href="https://archive.org/details/transactor-magazines-v9-i03">Transactor volume 9, issue 3 (Feburary 1989)</a>, George Hug presented software to achieve 2400 baud reliably on the C64 without any hardware modifications<sup id="fnref:4"><a href="#fn:4" rel="footnote">4</a></sup>.</p><h3 id="swiftlink-232">SwiftLink-232</h3><p>The primary use for RS-232 on the C64 was for modems, and as modems faster than 2400 baud became available, Dr. Evil Laboratories released the $30 <a href="https://www.commodoreserver.com/BlogEntryView.asp?EID=FA5AE758474345A9A0A7208C7F408538">SwiftLink-232 cartridge</a> for the C64 expansion port in 1990. It contained a 6551 chip that could even reach 38400 baud, thanks to doubling the rate of the external oscillator.</p><h3 id="up9600">UP9600</h3><p>In 1997, Daniel Dallmann created UP9600, a solution that allowed 9600 baud on the user port. The idea is to use the hardware shift registers of the two CIA 6526 I/O controllers to do the timing-critical part of the transfer.</p><h2 id="rs-232-pins-on-the-user-port">RS-232 Pins on the User Port</h2><p>Every Commodore 8 bit computer except for the C16/C116 has a user port, and all user ports except for the original PET support TTL-level RS-232 through eight dedicated pins.</p><p><img src="docs/up9600/userport.png" height="143" width="451" alt="" /></p><p>The following table describes the C64 user port. The RS-232 pins are marked in red:</p><table><thead><tr><th> Pin </th><th> Description </th><th> Pin </th><th> Description </th></tr></thead><tbody><tr><td> 1 </td><td> GND </td><td> A </td><td> GND </td></tr><tr><td> 2 </td><td> +5V </td><td> B </td><td> /FLAG2 </td></tr><tr><td> 3 </td><td> /RESET </td><td> C </td><td> PB0: <font color="red">RS-232 RXD</font> <img src="https://s.w.org/images/core/emoji/11/72x72/2b05.png" alt="⬅" class="wp-smiley" style="height: 1em; max-height: 1em;" /> </td></tr><tr><td> 4 </td><td> CNT1 </td><td> D </td><td> PB1: <font color="red">RS-232 RTS</font> </td></tr><tr><td> 5 </td><td> SP1 </td><td> E </td><td> PB2: <font color="red">RS-232 DTR</font> </td></tr><tr><td> 6 </td><td> CNT2 </td><td> F </td><td> PB3: <font color="red">RS-232 RI</font></td></tr><tr><td> 7 </td><td> SP2 </td><td> H </td><td> PB4: <font color="red">RS-232 DCD</font> </td></tr><tr><td> 8 </td><td> /PC2 </td><td> J </td><td> PB5 </td></tr><tr><td> 9 </td><td> SER ATN IN </td><td> K </td><td> PB6: <font color="red">RS-232 CTS</font> </td></tr><tr><td> 10 </td><td> 9 VAC </td><td> L </td><td> PB7: <font color="red">RS-232 DSR</font> </td></tr><tr><td> 11 </td><td> 9 VAC </td><td> M </td><td> PA2: <font color="red">RS-232 TXD</font> <img src="https://s.w.org/images/core/emoji/11/72x72/2b05.png" alt="⬅" class="wp-smiley" style="height: 1em; max-height: 1em;" /> </td></tr><tr><td> 12 </td><td> GND </td><td> N </td><td> GND </td></tr></tbody></table><p>RXD is the receive line, and TXD is the transmit line. The remaining lines deal with flow control, among other things, and are optional.</p><h2 id="rs-232">RS-232</h2><p>Before we can talk about UP9600, we first need some understanding of the RS-232 serial protocol.</p><p>To send serial data from one sender to one receiver, only a single data wire is needed. Beforehand, the two devices need to agree on the baudrate (e.g. 1200 bits/sec) and the format of each unit of data: how many data bits, whether there is an added parity bit, and how many stop bits. The most common parameter setting (and in fact the only one supported by the original UP9600 driver) is 8-N-1, meaning 8 data bits, no parity, and a single stop bit.</p><p>The transmission of one byte in 8-N-1 mode will look like this on the wire:</p><p><img src="docs/up9600/rs232-1.png" height="84" width="483" alt="" /></p><ul><li>“1” on the wire signals an idle line: the sender has no new data to send.</li><li>The transmission of a byte is indicated by sending a “0” for the duration of one bit.</li><li>The 8 data bits are transmitted afterwards, LSB first.</li><li>After that, a “1” is sent for at least the duration of one bit.</li><li>If there is no additional data, the line stays at “1”.</li></ul><p>Data can be sent back to back if there are multiple bytes available for sending:</p><p><img src="docs/up9600/rs232-2.png" height="57" width="226" alt="" /></p><p>As usual, the 8 data bits are followed by a stop bit (“1”), then immediately by a start bit (“0”) and then the next 8 data bits.</p><p>The point in time when the sender sets the wire from “1” to “0” for the start bit is the synchronization point for the transmission of the following byte. The receiver will have to sample the line at the right intervals counting from the sync point for the following 8 data bits and the stop bit. The next start bit will re-sync sender and receiver again, so the clocks of sender and receiver only have to be matching well enough for the duration of the transmission of a single byte.</p><p>After the line has been idle, a start bit can be sent at any time, it does not have to fall into the time raster of the bit rate. As just described, time starts anew with each start bit for both sender and receiver.</p><p>If the receiver starts listening while the sender is already in the middle of a transmission, incorrect data will be received. The first “0” bit it encounters will be understood as the start bit, and the next 8 bits will be the data byte. If the following bit is not a “1”, the receiver will discard the byte, and wait for the next “0” bit, which hopefully is the correct start bit this time. In the worst case, it will detect a few garbled bytes, but statistically, the receiver will sync itself over time.</p><h2 id="the-cia-6526-shift-register">The CIA 6526 Shift Register</h2><p>The core idea of UP9600 is to use the two otherwise unused hardware shift registers in the C64, which can automatically send or receive a byte bit-by-bit over a single wire, faster than the CPU would be able to do it.</p><p>The C64 has two CIA 6526 I/O controllers, each of which contains a serial shift register that can transfer bytes using a clock and a data line to a peer that speaks the same protocol, e.g. the CIA in another computer<sup id="fnref:5"><a href="#fn:5" rel="footnote">5</a></sup>. They are unused by a stock C64, but exposed on the user port. Here is the table again, this time with the shift register wires marked in red:</p><table><thead><tr><th> Pin </th><th> Description </th><th> Pin </th><th> Description </th></tr></thead><tbody><tr><td> 1 </td><td> GND </td><td> A </td><td> GND </td></tr><tr><td> 2 </td><td> +5V </td><td> B </td><td> /FLAG2 </td></tr><tr><td> 3 </td><td> /RESET </td><td> C </td><td> PB0 </td></tr><tr><td> 4 </td><td> <font color="red">CNT1</font></td><td> D </td><td> PB1 </td></tr><tr><td> 5 </td><td> <font color="red">SP1</font> </td><td> E </td><td> PB2 </td></tr><tr><td> 6 </td><td> <font color="red">CNT2</font></td><td> F </td><td> PB3 </td></tr><tr><td> 7 </td><td> <font color="red">SP2</font> </td><td> H </td><td> PB4 </td></tr><tr><td> 8 </td><td> /PC2 </td><td> J </td><td> PB5 </td></tr><tr><td> 9 </td><td> SER ATN IN </td><td> K </td><td> PB6 </td></tr><tr><td> 10 </td><td> 9 VAC </td><td> L </td><td> PB7 </td></tr><tr><td> 11 </td><td> 9 VAC </td><td> M </td><td> PA2 </td></tr><tr><td> 12 </td><td> GND </td><td> N </td><td> GND </td></tr></tbody></table><p>CNT1 and SP1 are the clock and data lines of CIA#1, and CNT2 and SP2 are the clock and data lines of CIA#2.</p><p>In order to send a byte, we need to set timer A so it fires at the correct interval between bits<sup id="fnref:6"><a href="#fn:6" rel="footnote">6</a></sup></p><pre><code> timer = (system_freq) / (2 * bit_output_freq) - 1</code></pre><p>and set it to continuous mode, set the serial port to output, and then write the byte to the serial data register. On every timer underflow, the CNT line will be toggled, and on every falling edge, the next bit is put on the SP line – this is why the timer has to fire twice per bit, explaining the extra factor of 2 in the divisor of the formula.</p><p>Once all 8 bits are shifted out, a bit in the interrupt control register is sent, which can optionally trigger an interrupt. The SP line will retain the value of the last bit.</p><p>To send a continuous stream of bytes, you have to write the first two bytes to the serial data register immediately after one another – the CIA will start sending out the first byte and cache the second one – and after each interrupt, a new byte can be written to the shift register, while the previous one is still being shifted out.</p><p>To receive a byte through the shift register, you have to set it to input mode, and it will sample a bit on every rising edge of CNT. Again, after 8 bits, it will set a bit in the interrupt control register and optionally trigger an interrupt. Now, the 8 bits can be read from the serial data register.</p><h2 id="cia#1-and-cia#2">CIA#1 and CIA#2</h2><p>The two 6526 CIA chips in the C64 are identical, but connected differently.</p><ul><li>Most pins of the user port, and all RS-232 pins go to CIA#2.</li><li>The serial ports of both CIAs are exposed on the user port.</li><li>The interrupt output of CIA#1 is connected to the CPU’s IRQ line, while the interrupt output of CIA#2 is connected to the CPU’s NMI line.</li></ul><p>Receiving data is more timing-critical than sending, so we will use CIA#2 for receiving, since NMIs are useful for tighter timing requirements.</p><h2 id="sending-rs-232-data">Sending RS-232 Data</h2><p>Now how do we use the shift register to send data in the RS-232 transmission format? After all, it was not exactly designed with RS-232 in mind:</p><ol><li>The user port wiring of the serial port is different than what the KERNAL driver uses.</li><li>The order of the bits in a byte is reversed in the CIA compared to RS-232.</li><li>The shift register works on 8 bits at a time, while RS-232 deals with groups of 10 bits.</li></ol><h3 id="txd-wiring">TXD Wiring</h3><p>The data output of the CIA#1 shift register is wired to SP1 (pin 5) on the user port, but the old RS-232 KERNAL driver outputs data on PA2 (pin M). This means that existing user port RS-232 hardware (which uses pin M) wouldn’t be compatible. But new hardware that is aware of UP9600 can just bridge pin M to pin 5, and it will be compatible both with the original pinout and with UP9600.</p><p>The additional clock output of the CIA is not a problem: It will appear at pin 4 (CNT1) on the user port, and existing user port RS-232 hardware wouldn’t have it connected, and there is no reason to connect it on new hardware.</p><h3 id="bit-order">Bit Order</h3><p>The shift register sends data with the most significant bit first, while RS-232 sends the least significant bit first. The 8 data bits will have to be reversed in order before sending them. The fastest solution is a 256 byte lookup table. The UP9600 code actually uses a 128 byte lookup table and patches the remaining bit into the resulting byte, trading some execution speed for memory.</p><h3 id="sending-10-bits">Sending 10 Bits</h3><p>The trickiest problem in sending is that the shift register works on 8 bits at a time, while for RS-232, each data byte results in a total of 10 bits: one start bit, 8 data bits and one stop bit. If all the data to be sent were known beforehand, one could shift the data bytes into a set of bytes that corresponds to the RS-232 bit stream and continuously write them to the shift register:</p><p><img src="docs/up9600/shift_register_stream.png" height="109" width="458" alt="" /></p><p>Unfortunately, software that wishes to send data often doesn’t have all the data available, or data arrives from software in bursts with pauses in between. In a terminal program, text typed by the user arrives one byte at a time, with significant pauses. During file transmission (e.g. XMODEM), a number of bytes will be sent together, but without additional communication, the RS-232 driver wouldn’t know at what point it needs to flush the accumulated data. It’s possible to do it this way, but it is quite complicated.</p><p>Instead, the UP9600 software sends every data byte as 16 bits, the 10 RS-232 bits (one stop bit, 8 data bits, one stop bit), and 6 filler bits with a value of “1” – you can see them either as additional stop bits or as a signal that the line is idle.</p><p><img src="docs/up9600/shift_register_2bytes.png" height="100" width="194" alt="" /></p><p>While this only achieves 62.5% of the peak data rate – 600 bytes/sec instead of 960 bytes/sec, assuming 9600 baud – this is completely legal and will be understood by any receiver. It does not look any different than a sender that had to add a little extra pause between bytes.</p><p>So in practice, the UP9600 code always sends one data byte at a time, like this (using CIA#1):</p><ul><li>Set the serial port to output.</li><li>Enable serial port interrupts.</li><li>Set timer A to 1022727 / (2 * 9600) – 1 = 52 (NTSC) or 985249 / (2 * 9600) – 1 = 50 (PAL)<sup id="fnref:7"><a href="#fn:7" rel="footnote">7</a></sup>.</li><li>Set the timer to continuous and start it.</li><li>Write a “0” (start bit) and bits 0 through 6 to the serial data register – note the reversed bit order!</li><li>Write the remaining bit and seven “1” bits (stop bits) to the serial data register. Again, note the bit order.</li></ul><p>The next byte can be written once two interrupts have been triggered by the CIA.</p><p>(There is a little added complication: Serial timing has to come from the timer A, but the C64 KERNAL has timer A of CIA#1 set up as the 60 Hz interrupt source that deals with updating the TI$ clock, scanning the keyboard and blinking the cursor. We have to migrate the 60 Hz interrupt to timer B if we want to continue using these KERNAL services.)</p><p>Let’s look at the timing of this code: We have to make sure that the second byte is written before the first byte is fully transmitted. Otherwise, the last bit of the first byte (i.e. second-to-last data bit) would stay on the line too long, leading to incorrect data transmission. With 9600 baud, we have a window of about 100 clock cycles.</p><ul><li>Every 8 raster lines, the VIC-II takes control from the CPU for 40 cycles (“badlines”).</li><li>We could be interrupted by an NMI caused by the receiving part of the UP9600 software – see below.</li></ul><p>As long as the receiver NMI code takes less than 60 cycles, we’re good at 9600 baud, even when a badline and an NMI occur at the same time. In fact, even higher speeds could be possible by avoiding VIC-II badlines – after all, we control when to start the transmission of a byte. But since the baud rate is the same for sending and receiving, it’ll be the receiving part that will limit the maximum bit rate.</p><h2 id="receiving-rs-232-data">Receiving RS-232 Data</h2><p>Receiving is also tricky because:</p><ol><li>Again, the user port wiring of the serial port is different than what the KERNAL driver uses.</li><li>A start bit and thus the transmission of a data byte can happen at any time, and at 9600 baud, the window for a single bit is just 100 cycles.</li><li>The shift register has no way to shift in a bit every <em>n</em> cycles.</li></ol><h3 id="rxd-wiring">RXD Wiring</h3><p>The data input of the CIA#2 shift register is wired to SP2 (pin 7) on the user port, but the old RS-232 KERNAL driver receives data on PB0 (pin C). As with the output wire, new hardware that is aware of UP9600 can just bridge pin C to pin 7 and be compatible with both drivers.</p><h3 id="detecting-the-start-bit">Detecting the Start Bit</h3><p>To detect a start bit, we have the following options:</p><ul><li>Busy waiting. This way, there will be no way to do anything else on the system.</li><li>A timer interrupt that fires every 100 cycles, so we can check the line. This would be a lot of interrupts, slowing down the system significantly.</li><li>Finding a way to have the stop bit cause an interrupt.</li></ul><p>In fact, it is possible to have an external pin on the user port generate an interrupt – a falling edge on FLAG2 (pin B) will make CIA#2 trigger an NMI. So UP9600-aware hardware needs to bridge PB0 (pin C), which normally carries RDX (receive line) to FLAG2 (pin B).</p><p>The UP9600 software thus enables the FLAG interrupt on CIA#2 and hooks the NMI vector. Once the NMI fires, it sets up the CIA#2 to read the next 8 bits into the shift register.</p><h3 id="using-a-cia-timer-for-the-clock">Using a CIA Timer for the Clock</h3><p>The trickiest problem in receiving is the fact that for data input, the shift register has to be clocked from the CNT line, and we don’t have such a signal! There is no way to tell the shift register to just sample the data wire every <em>n</em> clock cycles.</p><p>The trick is to have the CIA generate a matching clock signal, output it on the user port, and use a bridge on the UP9600-aware device to feed this signal back into the CIA through the CNT2 pin.</p><p>The CIA has a way to send a pulse every <em>n</em> cycles on pins PB6 and PB7. When enabled, an underflow of timer A will pulse PB6, and an underflow of timer B will pulse PB7. And both these CIA outputs are available on the user port! UP9600 uses timer B for this, so we need a bridge from PB7 (pin L) to CNT2 (pin 6).</p><p>So inside the NMI handler for the start bit, we have to</p><ul><li>Disable FLAG interrupts – we are not listening for a start bit any more.</li><li>Set the serial port to input</li><li>Enable serial port interrupts.</li><li>Set timer B to 1022727 / (9600) – 1 = 106 (NTSC) or 985249 / (9600) – 1 = 102 (PAL).</li><li>Set the timer to continuous, set it to pulse on PB7 and start it.</li><li>Change the NMI vector to the second NMI handler.</li></ul><p>The second NMI handler will then</p><ul><li>Read the data byte from the serial data register and reverse the bit order.</li><li>Disable timer B.</li><li>Enable FLAG interrupts for the next start bit.</li><li>Change the NMI vector to the first NMI handler.</li></ul><p>Note that we never read the stop bit. This means that the UP9600 does not plausibility check of the data. If the receiver starts listening while the sender is already in the middle of a transmission, the UP9600 driver will pass several garbled bytes to the receiving software and take longer than necessary to eventually sync itself to the signal.</p><h2 id="up9600-wiring">UP9600 Wiring</h2><p>So for a C64 user port RS-232 device to be UP9600-aware, all it needs to do is bridge the following pins:</p><table><thead><tr><th> Pin 1 </th><th> Pin 2 </th><th> Description </th></tr></thead><tbody><tr><td> M (PA2) </td><td> 5 (SP1) </td><td> RS-232 output to CIA#1 Serial Port </td></tr><tr><td> C (PB0) </td><td> 7 (SP2) </td><td> RS-232 input to CIA#2 Serial Port </td></tr><tr><td> C (PB0) </td><td> B (/FLAG2) </td><td> RS-232 input to CIA#2 FLAG, for NMI on start bit </td></tr><tr><td> L (PB7) </td><td> 6 (CNT2) </td><td> CIA#2 timer B pulse to CIA#2 Serial Port clock </td></tr></tbody></table><p>UP9600 does not work on a C128 in 128 mode, since it uses the CIA#1 shift register for communication with Fast Serial disk drives (1571, 1581, …). It will even hang on boot if a Fast Serial device is attached. To work around the latter, a jumper can be installed to disconnect M from 5.</p><h2 id="why-is-9600-the-maximum-baudrate?">Why is 9600 the Maximum Baudrate?</h2><p>The highest baudrate that is possible on a C64 with the described algorithm is 9600 baud.</p><p>At this speed, a bit arrives roughly every 100 cycles. It takes about 30 cycles from the moment of the start bit NMI to disable the FLAG NMI, enable the timer and hook the serial port NMI. 50 cycles after the start bit NMI would be the center of the start bit and the optimal time to sample every 100 cycles, so starting the timer 30 cycles into the start bit is fine.</p><p>The interesting part on the C64 are VIC-II badlines, which can stall the CPU for 40 cycles at practically any time. If a badline happens just as the NMI is taken, setting up the CIA to read the 8 data bits will be finished 40 cycles later, i.e. at 70 cycles after the moment of the start bit NMI. This is still fine, because in either case, we will fall into the window where the start bit is valid.</p><p><img src="docs/up9600/sampling_9600.gif" height="256" width="420" alt="" /><br /><img src="docs/up9600/sampling_9600.png" height="256" width="420" alt="" /></p><p>The next highest standard baudrate would be 19200, with a bit every 50 cycles. With the same algorithm, the following will happen: If there is no badline, we will set up the CIA at 30 cycles again, and it will sample every 50 cycles, so pretty much in the center of each bit. Great. But if there is a badline, we’re already at 70 cycles, which is in the middle of the first data bit. The first bit would have to be read by the serial port immediately, 50 cycles later would be too late.</p><p><img src="docs/up9600/sampling_19200.gif" height="256" width="420" alt="" /></p><p>We can’t detect whether a badline just happened, but since the window to read a bit is 50 cycles and the fuzz introduced by badlines is just 40 cycles, we have a chance to time it just right to read the bit within the window.</p><p><img src="docs/up9600/sampling_19200.png" height="256" width="420" alt="" /></p><p>Depending on whether there is a badline, the latency from the moment of the start bit NMI to the point where we can access the CIA is 30 to 70 cycles. The process would be to:</p><ul><li>Wait 25 cycles, so we fall into the 55 to 95 cycle range, in the center of the window of bit #0. These cycles can be used to set up the shift register and disable the FLAG NMI.</li><li>Output a manual pulse on PB7 to sample the first bit into the shift register immediately.</li><li>Set up the timer to pulse PB7 every 50 cycles and start it.</li></ul><p><img src="docs/up9600/sampling_19200-2.png" height="256" width="420" alt="" /></p><p>The implementation of UP19200 is left as an exercise to the reader.</p><h2 id="source-code">Source Code</h2><ul><li>The <a href="docs/up9600/up9600.txt">original UP9600 source code</a> is available as part of an email from Daniel Dallmann to the developer of Novaterm, dated 30 Nov 1997. It is designed as a library that can be used from BASIC or assembly.</li><li>Bo Zimmerman maintains <a href="https://github.com/bozimmerman/Zimodem/blob/master/cbm8bit/src/up9600.asm">a version of UP9600</a> as part of the ZiModem repository that hooks itself into the KERNAL vectors for the Channel I/O calls, so UP9600 can be used from BASIC or assembly using the existing KERNAL interface.</li><li>The <a href="https://github.com/mist64/ccgmsterm">CCGMS</a> terminal program contains a version adapted by <a href="https://1200baud.wordpress.com/">alwyz</a>. It is the only version to also support, in addition to 9600, baudrates of 300, 1200, 2400 and 4800. The current version in the repository contains fixes, cleanpus and comments by myself.</li></ul><h2 id="related">Related</h2><ul><li><a href="http://kahlin.net/daniel/over5/">over5</a> by Daniel Kahlin can do 38400/8N2 with the screen off.</li><li><a href="http://www.pastbytes.com/retroterm/">Retroterm</a> (<a href="https://csdb.dk/release/?id=206995">CSDb</a>) by Jorge Castillo can do 57600/8N1 with the screen off, and – using RTS/CTS flow control – an effective throughput of 1500 (PAL) or 1800 (NTSC) baud equivalent by only receiving in the border area.</li></ul><div class="footnotes"><hr/><ol><li id="fn:1"><p>It is supposed to support 2400 baud as well, but this speed does not work reliably in practice. <a href="#fnref:1" rev="footnote">↩</a></p></li><li id="fn:2"><p>Sending won’t achieve the full data rate though; we’ll cover this in the article. <a href="#fnref:2" rev="footnote">↩</a></p></li><li id="fn:3"><p>Development machines of the C128 did contain a 6551. <a href="#fnref:3" rev="footnote">↩</a></p></li><li id="fn:4"><p>A modern version of this software exists in the form of a <a href="https://github.com/nanoflite/c64-up2400-cc65">cc65 driver</a>. <a href="#fnref:4" rev="footnote">↩</a></p></li><li id="fn:5"><p>This is the same shift register that was supported, but broken in the MOS 6522 VIA chip, which is why the <a href="https://www.pagetable.com/?p=1595">1541 disk drive was so slow</a>. <a href="#fnref:5" rev="footnote">↩</a></p></li><li id="fn:6"><p>The timer value has to be one less than the quotient, because in continuous mode, automatic reloading of the timer takes one extra cycle. <a href="#fnref:6" rev="footnote">↩</a></p></li><li id="fn:7"><p>1022727 and 985249 are approximations of the respective system clock rates in Hz. The exact numbers are 4/14 * <strong>315/88</strong> for PAL and 4/18 * <strong>4433618.75</strong> for NTSC. The two constants are the respective <a href="https://en.wikipedia.org/wiki/Colorburst">colorbust frequencies</a>.<a href="#fnref:7" rev="footnote">↩</a></p></li></ol></div>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1656</wfw:commentRss> <slash:comments>8</slash:comments> </item> <item> <title>The Commodore Modem/1200 (Model 1670)</title> <link>https://www.pagetable.com/?p=1647</link> <comments>https://www.pagetable.com/?p=1647#comments</comments> <pubDate>Sat, 05 Mar 2022 19:23:11 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Archeology]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Literature]]></category> <category><![CDATA[Modem]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1647</guid> <description><![CDATA[The Commodore 1670, also known as the “Modem/1200”, is Commodore’s first Hayes-compatible modem: It connects directly to the phone line and supports pulse and tone dialing for 1200 and 300 baud duplex connections. There were two revisions, the original 1670 and the “new” 1670, a.k.a. CR-1670. (The unit in this article is the later revision.) ... <a title="The Commodore Modem/1200 (Model 1670)" class="read-more" href="https://www.pagetable.com/?p=1647">Read more<span class="screen-reader-text">The Commodore Modem/1200 (Model 1670)</span></a>]]></description> <content:encoded><![CDATA[<p>The Commodore 1670, also known as the “Modem/1200”, is Commodore’s first Hayes-compatible modem: It connects directly to the phone line and supports pulse and tone dialing for 1200 and 300 baud duplex connections. There were two revisions, the original 1670 and the “new” 1670, a.k.a. CR-1670. (The unit in this article is the later revision.)</p><h2 id="historical-context">Historical Context</h2><table><thead><tr><th> Year </th><th> Name </th><th> Model </th><th> Description </th></tr></thead><tbody><tr><td> 1982 </td><td> <a href="https://www.pagetable.com/?p=1679">VICMODEM</a> </td><td> 1600 </td><td> connected to phone’s handset connector; manual dialing through phone; Motorola MC14412 </td></tr><tr><td> 1982 </td><td> <a href="https://www.pagetable.com/?p=1716">AUTOMODEM</a> </td><td> 1650 </td><td> connected to phone line, pulse dialing in software; Motorola MC14412 </td></tr><tr><td> 1985 </td><td> <a href="https://www.pagetable.com/?p=1644">MODEM/300</a> </td><td> 1660 </td><td>added tone dialing support by feeding SID output into modem; Texas Instruments TMS99532A </td></tr><tr><td> 1987 </td><td> <a href="https://www.pagetable.com/?p=1647">MODEM/1200</a> </td><td> 1670 </td><td> Hayes command set; pulse and tone dialing in hardware; 300/1200 baud support; U.S. Robotics chipset </td></tr></tbody></table><h2 id="photos">Photos</h2><p><a href="docs/cbm1670modem/cbm1670_1.jpg"><img src="docs/cbm1670modem/cbm1670_1.jpg" height="403" width="476" alt="" /></a></p><p>On the front, there is the user port connector.</p><p><a href="docs/cbm1670modem/cbm1670_2.jpg"><img src="docs/cbm1670modem/cbm1670_2.jpg" height="363" width="452" alt="" /></a></p><p>On the back, there are</p><ul><li>two phone line connectors. “LINE” is connected to the telephone network, and an existing telephone can be connected to the “PHONE” line.</li><li>four DIP switches (default to down):</li></ul><table><thead><tr><th> DIP </th><th> Description </th><th> </th></tr></thead><tbody><tr><td> 1 </td><td> Auto Answer Enable </td><td> down: auto-answer on second ring disabled </td></tr><tr><td> 2 </td><td> Carrier Detect Enable </td><td> down: carrier detect on pin H-K of edge connector (needed for Plus/4) </td></tr><tr><td> 3 </td><td> Speed Indicate Enable </td><td> down: speed indicate on pin J of edge connector </td></tr><tr><td> 4 </td><td> Data Terminal Ready </td><td> down: DTR always on (instead of computer controlled) </td></tr></tbody></table><p><a href="docs/cbm1670modem/back.jpg"><img src="docs/cbm1670modem/back.jpg" height="463" width="259" alt="" /></a></p><p>The label on the bottom says:</p><table><tr><td align="center">C= COMMODORE</td><tr><tr><td>MODEL NO. 1670</td><tr><tr><td>SERIAL NO. CA1111714</td><tr><tr><td>COMPLIES WITH PART 68, FCC RULES; FC<br /> <br />REGISTRATION NUMBER BR98YV-19442-MDE<br /> <br />RINGER EQUIVALENT 0.4A 0.6B; JACK (USOC) RJ11<br /> </td><tr><tr><td>CERTIFIED TO COMPLY WITH CLASS B LIMITS,<br /> <br />PART 15, SUBPART J OF FCC RULES. SEE<br /> <br />INSTRUCTIONS IF INTERFERENCE TO RADIO<br /> <br />RECEPTION IS SUSPECTED.</td><tr><tr><td>FCC ID BR98YV1670<br /> <br />MADE IN USA <span style="float:right">310476-03</span></td><tr></table><p><a href="docs/cbm1670modem/board1.jpg"><img src="docs/cbm1670modem/board1.jpg" height="242" width="480" alt="" /></a><a href="docs/cbm1670modem/board2.jpg"><img src="docs/cbm1670modem/board2.jpg" height="257" width="480" alt="" /></a></p><p>The board is marked “COMMODORE CR-1670 MODEM” and “A/W 311956 REV 4”.</p><p>The 1670 is based on a U.S. Robotics (“USR”) chipset:</p><ul><li>U2: <code>© USR'85 U2J2 / OKI C49-387 / JAPAN 7X2033</code>: This is an OKI MSM80C49-387RS, a <a href="docs/cbm1670modem/M80C49_OKIelectronic.pdf">80C49 microcontroller</a> with 2KB of mask ROM and 128 bytes of RAM. “387” indicates which ROM image it contains.</li><li>U3: <code>© USR'85 U3J2 / OKI C49-388 / JAPAN 7Y2013</code>: This is an OKI MSM80C49-388RS, another 80C49 microcontroller, with a different ROM image (“388”).</li><li>U4: <code>© USR86 / USR101 16-249 / S8749 / 35561</code>: This socketed IC is probably the ROM that holds the bulk of the modem’s firmware.</li></ul><p><a href="docs/cbm1670modem/speaker.jpg"><img src="docs/cbm1670modem/speaker.jpg" height="252" width="336" alt="" /></a></p><p>There is a speaker glued to the top shell that allows monitoring the audio data on the line.</p><p><a href="docs/cbm1670modem/phone_cable.jpg"><img src="docs/cbm1670modem/phone_cable.jpg" height="218" width="296" alt="" /></a></p><p>The modem comes with a phone cable.</p><h2 id="box">Box</h2><p><a href="docs/cbm1670modem/box_front.jpg"><img src="docs/cbm1670modem/box_front.jpg" height="460" width="292" alt="" /></a><a href="docs/cbm1670modem/box_back.jpg"><img src="docs/cbm1670modem/box_back.jpg" height="460" width="295" alt="" /></a><br /><a href="docs/cbm1670modem/box_side.jpg"><img src="docs/cbm1670modem/box_side.jpg" height="87" width="447" alt="" /></a></p><h2 id="manual">Manual</h2><p><a href="docs/cbm1670modem/cbm1670modem_manual.pdf"><img src="docs/cbm1670modem/cbm1670modem_manual.jpg" height="412" width="284" alt="" /></a></p><h2 id="quantumlink-material">QuantumLink Material</h2><p><a href="docs/cbm1670modem/QuantumLink%20Envelope.pdf"><img src="docs/cbm1670modem/QuantumLink%20Envelope.jpg" height="176" width="216" alt="" /></a><a href="docs/cbm1670modem/QuantumLink%20Letter.pdf"><img src="docs/cbm1670modem/QuantumLink%20Letter.jpg" height="314" width="199" alt="" /></a><a href="docs/cbm1670modem/QuantumLink_Registration_Certificate.pdf"><img src="docs/cbm1670modem/QuantumLink_Registration_Certificate.png" height="142" width="203" alt="" /></a><a href="docs/cbm1670modem/QuantumLink%20Quick%20Connect%20Guide.pdf"><img src="docs/cbm1670modem/QuantumLink%20Quick%20Connect%20Guide.jpg" height="406" width="265" alt="" /></a><a href="docs/cbm1670modem/QuantumLink%20Members%20Guide.pdf"><img src="docs/cbm1670modem/QuantumLink%20Members%20Guide.jpg" height="406" width="265" alt="" /></a><a href="docs/cbm1670modem/QuantumLink%20Local%20Access%20Directory.pdf"><img src="docs/cbm1670modem/QuantumLink%20Local%20Access%20Directory.jpg" height="395" width="266" alt="" /></a></p><h2 id="more-box-contents">More Box Contents</h2><p><a href="docs/cbm1670modem/Warranty%20Card.pdf"><img src="docs/cbm1670modem/Warranty%20Card.png" height="423" width="255" alt="" /></a><a href="docs/cbm1670modem/Sixth%20Sense.pdf"><img src="docs/cbm1670modem/Sixth%20Sense.png" height="358" width="277" alt="" /></a><a href="docs/cbm1670modem/Damaged%20Disk.pdf"><img src="docs/cbm1670modem/Damaged%20Disk.png" height="224" width="180" alt="" /></a></p><h2 id="disk">Disk</h2><p><img src="docs/cbm1670modem/disk_label_a.png" height="124" width="384" alt="" /> <a href="docs/cbm1670modem/cbm1670modem_a.d64"><img src="docs/d64.png" alt="" /></a><br /><img src="docs/cbm1670modem/disk_label_b.png" height="124" width="384" alt="" /> <a href="docs/cbm1670modem/cbm1670modem_b.d64"><img src="docs/d64.png" alt="" /></a></p><h2 id="the-hayes/at-interface">The Hayes/AT Interface</h2><ul><li><p>ATI/ATI0 (product code) prints</p><pre><code> 121 OK</code></pre></li><li><p>ATI1 (ROM checksum) prints</p><pre><code> 1003 OK</code></pre></li><li><p>The manual defines registers (<code>ATSn=a</code>, <code>ATSn?</code>) 0-8, 10-12 and 16. Except for 16 (self test), they are identical to other U.S. Robotics modems – as late as the 1997 <a href="https://support.usr.com/support/1663/1663-files/1663-unkg-Manual.pdf">Sportster Flash x2</a>!</p></li><li><p>Register 9 is undocumented. Later U.S. Robotics manuals document it as: </p><blockquote><p>Sets the required duration, in tenths of a second, of the remote modem’s carrier signal before recognition by your modem. (default: 6)</p></blockquote><p> On the 1670, register 9 reads back as 6, so it may as well be the same feature.</p></li><li><p>The registers just seem to map to the 128 bytes of RAM of one of the 80C49 microcontrollers, they wrap around at 128, e.g. 130 is the same as 2. Here is a complete dump after power-on; much of the data may be random, but note the current <code>AT</code> command (<code>S19?</code>) starting at register 0x11 (17):</p><pre><code> 00000000 00 00 2b 0d 0a 08 02 1e |..+.....| 00000008 02 06 07 46 32 00 02 00 |...F2...| 00000010 00 53 31 39 3f ff ff 00 |.S19?...| 00000018 12 01 00 00 00 00 02 04 |........| 00000020 20 00 00 04 00 00 20 a4 | ..... .| 00000028 00 80 00 00 00 00 50 01 |......P.| 00000030 00 00 00 00 00 00 04 00 |........| 00000038 20 80 00 00 02 00 00 00 | .......| 00000040 98 02 00 00 00 40 02 80 |.....@..| 00000048 05 00 10 00 00 7f 47 81 |......G.| 00000050 00 00 0a 00 86 10 02 63 |.......c| 00000058 d4 23 30 24 bd 63 6e 63 |.#0$.cnc| 00000060 00 08 00 00 00 00 04 00 |........| 00000068 6b 00 00 00 e5 66 00 08 |k....f..| 00000070 80 60 00 65 01 3b 00 07 |.`.e.;..| 00000078 01 80 65 00 00 0a 01 00 |..e.....|</code></pre></li><li><p>Like all Bell 212A-compatible modems, when on a 1200 baud call, the data rate between the modem and the C64 is actually 1219 bits/sec. The manual states that it is necessary to specify this manual bitrate when using the KERNAL’s software RS232 implementation: </p><pre>OPEN2,2,2,CHR$(0)+CHR$(0)+CHR$(61)+CHR$(1)</pre><p><a href="https://github.com/mist64/ccgmsterm">Modern versions of CCGMS</a> won’t work with the 1670 for this reason.</p></li></ul><h2 id="open-questions">Open Questions</h2><ul><li>How to dump the ROM chip? I had no success reading it as a 2764..27512.</li><li>How to dump the ROM of the 80C49 microcontrollers?</li></ul>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1647</wfw:commentRss> <slash:comments>2</slash:comments> </item> <item> <title>The Commodore Modem/300 (Model 1660)</title> <link>https://www.pagetable.com/?p=1644</link> <comments>https://www.pagetable.com/?p=1644#comments</comments> <pubDate>Wed, 02 Mar 2022 00:55:00 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Archeology]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Literature]]></category> <category><![CDATA[Modem]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1644</guid> <description><![CDATA[The Commodore 1660, also known as the “Modem/300”, is Commodore’s first full-featured modem: It connects directly to the phone line and supports pulse and tone dialing for 300 baud duplex connections. Historical Context Year Name Model Description 1982 VICMODEM 1600 connected to phone’s handset connector; manual dialing through phone; Motorola MC14412 1982 AUTOMODEM 1650 connected ... <a title="The Commodore Modem/300 (Model 1660)" class="read-more" href="https://www.pagetable.com/?p=1644">Read more<span class="screen-reader-text">The Commodore Modem/300 (Model 1660)</span></a>]]></description> <content:encoded><![CDATA[<p>The Commodore 1660, also known as the “Modem/300”, is Commodore’s first full-featured modem: It connects directly to the phone line and supports pulse and tone dialing for 300 baud duplex connections.</p><h2 id="historical-context">Historical Context</h2><table><thead><tr><th> Year </th><th> Name </th><th> Model </th><th> Description </th></tr></thead><tbody><tr><td> 1982 </td><td> <a href="https://www.pagetable.com/?p=1679">VICMODEM</a> </td><td> 1600 </td><td> connected to phone’s handset connector; manual dialing through phone; Motorola MC14412 </td></tr><tr><td> 1982 </td><td> <a href="https://www.pagetable.com/?p=1716">AUTOMODEM</a> </td><td> 1650 </td><td> connected to phone line, pulse dialing in software; Motorola MC14412 </td></tr><tr><td> 1985 </td><td> <a href="https://www.pagetable.com/?p=1644">MODEM/300</a> </td><td> 1660 </td><td>added tone dialing support by feeding SID output into modem; Texas Instruments TMS99532A </td></tr><tr><td> 1987 </td><td> <a href="https://www.pagetable.com/?p=1647">MODEM/1200</a> </td><td> 1670 </td><td> Hayes command set; pulse and tone dialing in hardware; 300/1200 baud support; U.S. Robotics chipset </td></tr></tbody></table><h2 id="photos">Photos</h2><p><a href="docs/cbm1660modem/cbm1660_1.jpg"><img src="docs/cbm1660modem/cbm1660_1.jpg" height="325" width="459" alt="" /></a></p><p>On the front, there is the user port connector. On the left, there is a switch that can be put into the “A” (answer) or “O” (originate) position, depending whether a phone call is supposed to be made or accepted.</p><p><a href="docs/cbm1660modem/cbm1660_2.jpg"><img src="docs/cbm1660modem/cbm1660_2.jpg" height="287" width="457" alt="" /></a></p><p>On the back, there are</p><ul><li>two phone line connectors. “LINE” is connected to the telephone network, and an existing telephone can be connected to the “PHONE” line.</li><li>an RCA audio connector. The circuitry in the modem only does the 300 baud data transmission part once the telephone connection is established – tone dialing is done by using software to generate the audio using the C64’s sound chip, which is looped into this connector! (Pulse dialing is also done in software, by timing on-hook and off-hook events.)</li></ul><p><a href="docs/cbm1660modem/back.jpg"><img src="docs/cbm1660modem/back.jpg" height="454" width="259" alt="" /></a></p><p>The label on the bottom says:</p><table><tr><td align="center">C= commodore</td><tr><tr><td>MODEL NO. 1660</td><tr><tr><td>SERIAL NO. 158297</td><tr><tr><td>COMPLIES WITH PART 68, FCC RULES; FC<br /> <br />REGISTRATION NUMBER BR 9608-15671-DM-E<br /> <br />RINGER EQUIVALENT 0.4A 0.6B; JACK (USOC) RJ11<br /> </td><tr><tr><td align="center">CERTIFIED TO COMPLY WITH CLASS B LIMITS,<br /> <br />PART 15, SUBPART J OF FCC RULES. SEE<br /> <br />INSTRUCTIONS IF INTERFERENCE TO RADIO<br /> <br />RECEPTION IS SUSPECTED.</td><tr><tr><td>FCC ID BR 9608-1660<br /> <br />MADE IN: HONG KONG <span style="float:right">310476-01</span></td><tr></table><p><a href="docs/cbm1660modem/board1.jpg"><img src="docs/cbm1660modem/board1.jpg" height="472" width="257" alt="" /></a><a href="docs/cbm1660modem/board2.jpg"><img src="docs/cbm1660modem/board2.jpg" height="454" width="244" alt="" /></a></p><p>The board is marked “MAGIC MODEM TI-1660” and “ARTWORK NO. 310484 REV 4”. The “TI” might stand for “Texas Instruments”, the manufacturer of the <a href="docs/cbm1660modem/TMS99532A.pdf">TMS99532A</a> modem chip on the top left of the board, which is the central component of the device.</p><p><a href="docs/cbm1660modem/speaker.jpg"><img src="docs/cbm1660modem/speaker.jpg" height="378" width="504" alt="" /></a></p><p>There is a speaker glued to the top shell that allows monitoring the audio data on the line.</p><p><a href="docs/cbm1660modem/phonecable.jpg"><img src="docs/cbm1660modem/phonecable.jpg" height="148" width="452" alt="" /></a></p><p>The modem comes with one phone cable.</p><p><a href="docs/cbm1660modem/dincable.jpg"><img src="docs/cbm1660modem/dincable.jpg" height="123" width="456" alt="" /></a><br /><a href="docs/cbm1660modem/ycable.jpg"><img src="docs/cbm1660modem/ycable.jpg" height="150" width="488" alt="" /></a></p><p>And there are two cables that connect the C64’s audio output to the modem:</p><ul><li>The DIN to RCA cable takes the audio signal from the C64/C128 AV connector. It is used if the C64 is connected to a TV through the RF connector, so the AV connector is available.</li><li>The RCA Y-cable takes the audio signal from the monitor cable. This is used if the C64 is connected to a monitor using the AV connector.</li></ul><p>Page 8 in the manual visualizes this:</p><p><img src="docs/cbm1660modem/connection1.png" height="204" width="300" alt="" /><img src="docs/cbm1660modem/connection2.png" height="204" width="300" alt="" /></p><h2 id="box">Box</h2><p><a href="docs/cbm1660modem/box_front.jpg"><img src="docs/cbm1660modem/box_front.jpg" height="453" width="293" alt="" /></a><a href="docs/cbm1660modem/box_back.jpg"><img src="docs/cbm1660modem/box_back.jpg" height="460" width="297" alt="" /></a><br /><a href="docs/cbm1660modem/box_side.jpg"><img src="docs/cbm1660modem/box_side.jpg" height="93" width="453" alt="" /></a></p><h2 id="manuals">Manuals</h2><p><a href="docs/cbm1660modem/cbm1660modem_manual.pdf"><img src="docs/cbm1660modem/cbm1660modem_manual.jpg" height="326" width="215" alt="" /></a> <a href="docs/cbm1660modem/quantumlink_manual.pdf"><img src="docs/cbm1660modem/quantumlink_manual.jpg" height="306" width="212" alt="" /></a></p><h2 id="more-box-contents">More Box Contents</h2><p><a href="docs/cbm1660modem/QuantumLink%20Letter.pdf"><img src="docs/cbm1660modem/QuantumLink%20Letter.jpg" height="395" width="303" alt="" /></a> <a href="docs/cbm1660modem/QuantumLink%20Card.pdf"><img src="docs/cbm1660modem/QuantumLink%20Card.jpg" height="254" width="165" alt="" /></a> <a href="docs/cbm1660modem/QuantumLink%20Code.pdf"><img src="docs/cbm1660modem/QuantumLink%20Code.jpg" height="191" width="148" alt="" /></a></p><p><a href="docs/cbm1660modem/Important.pdf"><img src="docs/cbm1660modem/Important.jpg" height="305" width="198" alt="" /></a> <a href="docs/cbm1660modem/Damaged%20Disk.pdf"><img src="docs/cbm1660modem/Damaged%20Disk.jpg" height="222" width="176" alt="" /></a> <a href="docs/cbm1660modem/Warranty%20Card.pdf"><img src="docs/cbm1660modem/Warranty%20Card.png" height="427" width="215" alt="" /></a> <a href="docs/cbm1660modem/Magazine%20Ad.pdf"><img src="docs/cbm1660modem/Magazine%20Ad.jpg" height="307" width="197" alt="" /></a></p><p><a href="docs/cbm1660modem/Keyboard%20Overlay.pdf"><img src="docs/cbm1660modem/Keyboard%20Overlay.png" height="157" width="145" alt="" /></a></p><h2 id="disk">Disk</h2><p><img src="docs/cbm1660modem/disk_label_a.png" height="127" width="393" alt="" /> <a href="docs/cbm1660modem/cbm1660modem_a.d64"><img src="docs/d64.png" alt="" /></a></p><p><img src="docs/cbm1660modem/disk_label_b.png" height="126" width="389" alt="" /> <a href="docs/cbm1660modem/cbm1660modem_b.d64"><img src="docs/d64.png" alt="" /></a></p><h2 id="further-reading">Further Reading</h2><p><a href="https://archive.org/details/byte-magazine-1983-03-rescan/page/n27/mode/2up">Build the ECM-103, an Originate/Answer Modem</a>, Byte Magazine Volume 08 Number 03</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1644</wfw:commentRss> <slash:comments>3</slash:comments> </item> <item> <title>Announcing CCGMS Future 0.1</title> <link>https://www.pagetable.com/?p=1641</link> <comments>https://www.pagetable.com/?p=1641#comments</comments> <pubDate>Fri, 25 Feb 2022 15:32:06 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[GitHub]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1641</guid> <description><![CDATA[The CCGMS Terminal Program for the Commodore 64 is maintained again, and there is a new version: CCGMS Future 0.1, with bug fixes and new features. History CCGMS has a rich history: It was originally written in 1985-1988 by Craig Smith, then binary patched by many people over the years, and finally maintained again by ... <a title="Announcing CCGMS Future 0.1" class="read-more" href="https://www.pagetable.com/?p=1641">Read more<span class="screen-reader-text">Announcing CCGMS Future 0.1</span></a>]]></description> <content:encoded><![CDATA[<p>The CCGMS Terminal Program for the Commodore 64 is maintained again, and there is a new version: CCGMS Future 0.1, with bug fixes and new features.</p><p><img src="docs/ccgms/ccgms.png" height="272" width="384" alt="" /></p><h2 id="history">History</h2><p>CCGMS has a rich history: It was originally written in 1985-1988 by <a href="https://github.com/spathiwa/ccgmsterm">Craig Smith</a>, then <a href="https://commodore.software/downloads/category/59-ccgms">binary patched</a> by many people over the years, and finally maintained again by <a href="https://1200baud.wordpress.com">alwyz</a> from 2016 to 2020, based on the rediscovered source code.</p><h2 id="cleanup">Cleanup</h2><p>As a first step, I cleaned up the source of the last version (v2021), splitting it into multiple files, renaming symbols and adding comments. The resulting source uses cc65/ca65 to build and will generate a byte-for-byte identical v2021 PRG file – you can find this version in a <a href="https://github.com/mist64/ccgmsterm/tree/ccgmsterm2021">branch</a>.</p><h2 id="fixes">Fixes</h2><p>Then I started implementing fixes. In v2021, the standard user port driver was broken for PAL systems because of a bug in the lookup of the timings. Similarly, the UP9600 driver had a timing issue on PAL, but it was minor; but the fix may improve data transfer stability.</p><h2 id="features">Features</h2><p>Finally, I added features to the XMODEM transfer protocol:</p><ul><li>The <strong>XMODEM-1K</strong> protocol has been added. This increases the block size to 1 KB (instead of 128 bytes) and will significantly increase throughput. Both regular checksum and CRC are supported with XMODEM-1K, and since the protocol specifies that the sender decides on the block size, CCGMS will accept 128 bytes and 1 KB blocks on receive, no matter the setting.</li><li>The XMODEM protocol specifies that the receiver decides whether a simple checksum or CRC16 should be used. The original code would only accept its own settings on uploads. For example, if CCGMS was set to regular “XMODEM” (i.e. no CRC16) and the sender used the XMODEM-CRC protocol, the transfer would fail. This has been changed to always accept the sender’s choice.</li></ul><p><img src="docs/ccgms/protocols.gif" height="272" width="384" alt="" /></p><p>Because of the added flexibility, the upload and download prompts are now a little clearer about the current settings:</p><ul><li><strong>XMODEM/XMODEM-CRC Upload</strong>: forces 128 B blocks, will accept checksum or CRC (more compatible)</li><li><strong>XMODEM-1K Upload</strong>: forces 1 KB blocks, will accept checksum or CRC (faster)</li><li><strong>XMODEM Download</strong>: forces checksum, will accept 128 B or 1 KB blocks (more compatible)</li><li><strong>XMODEM-CRC/XMODEM-1K Download</strong>: forces CRC16, will accept 128 B or 1 KB blocks (more reliable)</li></ul><p><img src="docs/ccgms/xmodem_up.gif" height="272" width="384" alt="" /><img src="docs/ccgms/xmodem_down.gif" height="272" width="384" alt="" /></p><h2 id="download">Download</h2><p>The .PRG files for this release are available on <a href="https://github.com/mist64/ccgmsterm/releases/tag/v0.1">GitHub</a>.</p><h2 id="future">Future</h2><p>I set up a <a href="https://github.com/mist64/ccgmsterm">GitHub repository</a> for the project, which is licensed under the terms of the 3-clause BSD license.</p><p>While I am working on further features, I am also more than happy to accept pull requests for features, bug fixes as well as clean up work!</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1641</wfw:commentRss> <slash:comments>2</slash:comments> </item> <item> <title>Free Joystick Extension Cable to Build Your DB9 Competition Pro</title> <link>https://www.pagetable.com/?p=1636</link> <comments>https://www.pagetable.com/?p=1636#respond</comments> <pubDate>Wed, 02 Feb 2022 15:07:32 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Commodore]]></category> <category><![CDATA[Hardware]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1636</guid> <description><![CDATA[This article explains how to convert a “Competition Pro Extra USB” (which you can still buy new) to work with a C64, Amiga or Atari. For the conversion, you need a joystick extension cable like this: I have a huge amount of them, with the wire colors described in the article, and I am happy ... <a title="Free Joystick Extension Cable to Build Your DB9 Competition Pro" class="read-more" href="https://www.pagetable.com/?p=1636">Read more<span class="screen-reader-text">Free Joystick Extension Cable to Build Your DB9 Competition Pro</span></a>]]></description> <content:encoded><![CDATA[<p><a href="https://www.pagetable.com/?p=1097">This article</a> explains how to convert a “Competition Pro Extra USB” (which you can still buy new) to work with a C64, Amiga or Atari. For the conversion, you need a joystick extension cable like this:</p><p><img src="docs/competition_pro/joyext.jpg" height="312" width="600" alt="" /></p><p>I have a huge amount of them, with the wire colors described in the article, and I am happy to mail one (or more) to you for free within Europe. Reach out to <a href="mailto:mist64@mac.com">mist64@mac.com</a>/<a href="https://twitter.com/pagetable">@pagetable</a>.</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1636</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>[UPDATE] Converting the “Competition Pro Extra USB” to C64/Amiga/Atari DB9</title> <link>https://www.pagetable.com/?p=1612</link> <comments>https://www.pagetable.com/?p=1612#respond</comments> <pubDate>Thu, 06 Jan 2022 08:53:47 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Commodore]]></category> <category><![CDATA[Hardware]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1612</guid> <description><![CDATA[I updated the instructions to a USB Competition Pro to DB9, so you can use it with a C64, Amiga etc. They now include the new “V3” and “V04T” pinouts and were updated with the use of a joystick extension cable.]]></description> <content:encoded><![CDATA[<p>I updated the <a href="https://www.pagetable.com/?p=1097">instructions to a USB Competition Pro to DB9</a>, so you can use it with a C64, Amiga etc. They now include the new “V3” and “V04T” pinouts and were updated with the use of a joystick extension cable.</p><p><img src="/docs/competition_pro/competition_pro.jpg" width="600"></p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1612</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>The Ultimate Commodore 1541 Disk Drive Talk [video]</title> <link>https://www.pagetable.com/?p=1595</link> <comments>https://www.pagetable.com/?p=1595#comments</comments> <pubDate>Thu, 16 Sep 2021 05:57:10 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Archeology]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Floppy Disks]]></category> <category><![CDATA[Presentation]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1595</guid> <description><![CDATA[This is the video recording of “The Ultimate Commodore 1541 Disk Drive Talk” at VCF West 2021. As always, if you think it’s too fast, try watching it at 0.75x speed! I will post the slides in Apple Keynote format later. If you enjoyed this, you might also like my talks “Ultimate Apollo Guidance Computer ... <a title="The Ultimate Commodore 1541 Disk Drive Talk [video]" class="read-more" href="https://www.pagetable.com/?p=1595">Read more<span class="screen-reader-text">The Ultimate Commodore 1541 Disk Drive Talk [video]</span></a>]]></description> <content:encoded><![CDATA[<p>This is the video recording of “The Ultimate Commodore 1541 Disk Drive Talk” at VCF West 2021. As always, if you think it’s too fast, try watching it at 0.75x speed!</p><p><iframe width="640" height="360" src="https://www.youtube.com/embed/_1jXExwse08?feature=oembed" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe></p><p>I will post the slides in Apple Keynote format later.</p><p>If you enjoyed this, you might also like my talks</p><ul><li><a href="https://www.pagetable.com/?p=922">“Ultimate Apollo Guidance Computer Talk”</a></li><li><a href="http://www.pagetable.com/?p=877">“Ultimate Game Boy Talk”</a></li><li><a href="http://www.pagetable.com/?p=54">“Ultimate Commodore 64 Talk”</a></li><li><a href="http://www.pagetable.com/?p=517">“Reverse Engineering the MOS 6502 CPU”</a></li></ul>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1595</wfw:commentRss> <slash:comments>12</slash:comments> </item> <item> <title>[Announcement] The Ultimate Commodore 1541 Disk Drive Talk @ VCFW 2021</title> <link>https://www.pagetable.com/?p=1590</link> <comments>https://www.pagetable.com/?p=1590#comments</comments> <pubDate>Fri, 06 Aug 2021 16:25:38 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Floppy Disks]]></category> <category><![CDATA[Presentation]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1590</guid> <description><![CDATA[After The Ultimate Commodore 64 Talk (2008) The Ultimate Game Boy Talk (2016) The Ultimate Apollo Guidance Computer Talk (2017) my fourth talk from the “Ultimate” series will take place at the Vintage Computer Festival West 2021 in Mountain View on 2021-08-08 at 12:00. This talk discusses floppy disk drives, with the 5,25” Commodore 1541 ... <a title="[Announcement] The Ultimate Commodore 1541 Disk Drive Talk @ VCFW 2021" class="read-more" href="https://www.pagetable.com/?p=1590">Read more<span class="screen-reader-text">[Announcement] The Ultimate Commodore 1541 Disk Drive Talk @ VCFW 2021</span></a>]]></description> <content:encoded><![CDATA[<p>After</p><ul><li>The Ultimate Commodore 64 Talk (2008)</li><li>The Ultimate Game Boy Talk (2016)</li><li>The Ultimate Apollo Guidance Computer Talk (2017)</li></ul><p>my fourth talk from the “Ultimate” series will take place at the <a href="https://vcfed.org/wp/vcf-west-event-schedule/">Vintage Computer Festival West 2021 in Mountain View on 2021-08-08 at 12:00</a>.</p><p>This talk discusses floppy disk drives, with the 5,25” Commodore 1541 as a case study. We discuss the history of magnetic recording formats, how data is represented on a disk and how it gets from the drive to the computer. We also talk about fast loaders, alternate recording formats, copy protection schemes, and how to preserve disks using modern tools.</p><p><img src="docs/vcfw-1541.png"/></p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1590</wfw:commentRss> <slash:comments>10</slash:comments> </item> <item> <title>Commodore’s Assemblers: Part 5: 6502ASM</title> <link>https://www.pagetable.com/?p=1542</link> <comments>https://www.pagetable.com/?p=1542#respond</comments> <pubDate>Sun, 13 Jun 2021 18:32:44 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Commodore]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1542</guid> <description><![CDATA[In the series about the assemblers Commodore used for developing the ROMs of their 8-bit computers, this article covers the 1989 “Commodore 6502 Assembler” (6502ASM), a cross-assembler written in C that ran on VAX and PC. Series Overview Part 0: Overview Part 1: MOS Cross-Assembler Part 2: MOS Resident Assembler Part 3: BSO CY6502 Part 4: HCD65 Part 5: 6502ASM ← ... <a title="Commodore’s Assemblers: Part 5: 6502ASM" class="read-more" href="https://www.pagetable.com/?p=1542">Read more<span class="screen-reader-text">Commodore’s Assemblers: Part 5: 6502ASM</span></a>]]></description> <content:encoded><![CDATA[<p>In the series about the assemblers Commodore used for developing the ROMs of their 8-bit computers, this article covers the 1989 “Commodore 6502 Assembler” (6502ASM), a cross-assembler written in C that ran on VAX and PC.</p><p><img src="docs/cbmasm/6502asm.png" alt="" /></p><h2 id="series-overview">Series Overview</h2><ul><li><a href="https://www.pagetable.com/?p=1518">Part 0: Overview</a></li><li><a href="https://www.pagetable.com/?p=1520">Part 1: MOS Cross-Assembler</a></li><li><a href="https://www.pagetable.com/?p=1522">Part 2: MOS Resident Assembler</a></li><li><a href="https://www.pagetable.com/?p=1538">Part 3: BSO CY6502</a></li><li><a href="https://www.pagetable.com/?p=1540">Part 4: HCD65</a></li><li>Part 5: <strong>6502ASM</strong> ← this article</li></ul><p><img src="docs/cbmasm/cbmasm_history.png" alt="" /></p><h2 id="history">History</h2><p>To build the ROMs for their 8-bit computers, Commodore originally used an assembler that ran on their own 6502-based machines (<a href="https://www.pagetable.com/?p=1522">part 2</a> of the series). From 1984 on, they used the “Boston Systems Office” (BSO) cross-assembler running on VAX/VMS (<a href="https://www.pagetable.com/?p=1538">part 3</a>).</p><p>In 1989, Commodore started working on the C65 project, a much enhanced successor to the C64. The C65 had a 4510 CPU, which supported the extended 65CE02 instruction set.</p><p>In order to be able to use the new 65CE02 instructions, they had several options:</p><ul><li>Write a set of macros that wrapped the new instructions: This worked well for some instructions, but required non-standard syntax for other cases. Dennis Jarvis, who developed the C65 DOS, started out with this approach while developing using the Merlin 128 assembler. Here is an example for the <a href="https://www.pagetable.com/c64ref/6502/?cpu=65ce02&tab=2#INW"><code>INW</code></a> instruction:</li></ul><pre> INW MAC DFB $E3 ;INW BP DFB ]1 <<< </pre><ul><li><p>Add 65CE02 support to an existing assembler: Three years earlier, Commodore had written the HCD65 assembler for C128 (<a href="https://www.pagetable.com/?p=1540">part 4</a>), and they did in fact add 65CE02 support to it. Unfortunately, developing with HCD65 was slow and cumbersome.</p></li><li><p>Write a new assembler from scratch: Using modern tools on a modern platform, writing a new assembler would not be too much work.</p></li></ul><p>The “Commodore 6502 Assembler” (6502ASM") is a 6502/65CE02 cross-assembler written in C, <a href="https://www.amazon.com/Commodore-Final-Years-Brian-Bagnall/dp/0994031033">written by Bob Norby</a> of Commodore Semiconductor Group (CSG, formerly MOS). It aimed at full compatibility with the “BSO” cross-assembler on VAX (<a href="https://www.pagetable.com/?p=1538">part 3</a>), which Commodore had been using for all their projects before. It was developed on VAX (using VAX C V2.4-026) to allow for easy comparisons of its outputs with BSO’s.</p><p>In June 1989, Fred Bowen ported the source to MS-DOS. An Amiga version was mentioned in the 1991 C65 specification, but it is unclear whether the source was ever actually ported to an Amiga C compiler.</p><h2 id="usage">Usage</h2><p>The 6502ASM was closely modeled after the BSO assembler, so it used the same command line interface. The user could pass the arguments either as command line options, or type it into a prompt, if no command line arguments were specified:</p><pre><code>C65>PROG.OBJ,PROG.LST=PROG.SRC</code></pre><p><code>C65></code> is the prompt printed by the assembler. It matches the prompt of the BSO assembler, and symbolizes “<strong>C</strong>ross assembler for <strong>65</strong>02” – it has nothing to do with the Commodore C65 project.</p><p>This is the help text that is printed if <code>/H</code> is passed:</p><pre><code>the assembler command line consists of the file names and switches C65> [object],[listing]=source[,source]...[,source][/switch]...[/switch] Items enclosed in brackets [...] are optional. The default file extentions are .obj , .lst and .src Switches (either upper or lower case) /A absolute assembly (default) /Cn cpu instruction set /C0 for NMOS 6502 /C1 for CMOS 6502 /C2 for CMOS 6502 w/bit instructions /C3 for Commodore 4502 (default) /Dpath specify path for intermediate file ( usually RAM disk on PCs). /H help - prints this message /L assume long branches on pass1. (default= assume short branches) /Mnnn maximum macro nesting depth (default=50, limits=2-999). /Pnn maximum number of passes to try (default=15, limits=2-99). /N don't print errors to console during assembly /R relocatable assembly - illegal since this is an absolute assembler only /S narrow list format /T don't print symbol table /V don't print cross reference /X print cross reference (default)</code></pre><p>Details on the usage as well as the supported syntax are described in the <a href="https://github.com/mist64/cbm6502asm/blob/main/README.md">unofficial manual</a>.</p><h2 id="differences">Differences</h2><p>6502ASM is very similar to the BSO assembler. It supports the same directives, and uses the same syntax for local symbols, conditional assembly and macros.</p><p>The only real difference seems to be the lack of the <code>.IF</code> directive, just like with HCD65. <code>.IF</code> seems to have been undocumented on the BSO assembler, which would explain its omission from both HCD65 and 6502ASM. That BSO supported it and treated it as a synonym for <code>.IFN</code> can be seen from its use in the <a href="https://github.com/mist64/cbmsrc/blob/master/KERNAL_TED_04/vectors.src#L9">TED KERNAL source</a>.</p><h2 id="versions">Versions</h2><h3 id="6502asm-b0.0-(1989)">6502ASM B0.0 (1989)</h3><p>This is the MS-DOS binary of version B0.0, built with Microsoft C 5.00 for MS-DOS (<a href="https://sites.google.com/site/pcdosretro/mschist">1987</a>):</p><ul><li><a href="docs/cbmasm/6502asm_msdos.zip">6502ASM B0.0</a> (1989-06-14, 67233 bytes, from <a href="http://6502.org/users/sjgray/dj/">DJ</a> 4502-asm-for-pc-7-89.img)</li></ul><p>This version has a few bugs:</p><ul><li>A <code>;</code> character in a string terminates it.</li><li><p>If an operand is 8 bits wide and the instruction does not support the zero-page addressing mode (i.e. <a href="https://www.pagetable.com/c64ref/6502/?cpu=65ce02&tab=2#LDZ"><code>LDZ</code></a> on the 65CE02), the assembler does not support falling back to absolute addressing. The following code would fail:</p><p> <tt>ldz $80</tt></p><p> This issue prevents some C65 source code from building.</p></li><li><p>If a macro is used within an <code>.INCLUDE</code>d file, assembly is stopped after the current file. <a href="http://www.zimmers.net/anonftp/pub/cbm/src/drives/serlib.zip">serlib.zip</a> on zimmers.net contains an LST file generated by 6502ASM B0.0 from the original 1581 source that shows this problem. The LST file is incomplete; it ends after the included file “mrout”, and the remaining LST therefore shows 150 undefined symbols.</p></li><li>Projects like <a href="https://github.com/mist64/cbmsrc/tree/master/RAMDOS">RAMDOS</a> (a solution for exposing a RAM Expansion Units (REU) as a disk), the <a href="https://github.com/mist64/cbmsrc/tree/master/HCD65_3.5">HCD65 assembler</a> and its editor (<a href="https://github.com/mist64/cbmsrc/tree/master/EDT_C128">EDT_C128</a>) as well as <a href="https://github.com/mist64/cbmsrc/tree/master/DOS_SHELL">DOS_SHELL</a> use BSO assembler features extensively. 6502ASM fails to build it for various reasons.</li></ul><p>The source code of 6502ASM B0.0 has been preserved through <a href="http://6502.org/users/sjgray/dj/">DJ</a> 4502-asm-for-pc.img.</p><h3 id="6502asm-v1.0-(1990)">6502ASM V1.0 (1990)</h3><p>Version V1.0 fixes a few bugs, including the <code>;</code> and <code>LDZ</code> problems.</p><p>LST files of the source are included in <a href="http://www.zimmers.net/anonftp/pub/cbm/src/c65/c65_src.tar.gz">c65_src.tar.gz</a>. The reconstructed source is available as part of the <a href="https://github.com/mist64/cbmsrc">cbmsrc repository</a>.</p><h3 id="current-version-(2021)">Current Version (2021)</h3><p>I adapted version V1.0 to current compilers so that it builds and runs on modern Unix systems. It is available on GitHub:</p><p><a href="https://github.com/mist64/cbm6502asm">https://github.com/mist64/cbm6502asm</a></p><p><code>.IF</code> has been added and the bug with macros within <code>.INCLUDE</code>s has been fixed. It can currently compile all known Commodore BSO source code, with the exceptions mentioned above. Contributions are welcome!</p><h2 id="use-at-commodore">Use at Commodore</h2><p>At the beginning of the C65 project, three different assemblers had been in use at Commodore:</p><ul><li>Dennis Jarvis (DOS) originally had used Merlin 128, with added 65CE02 macros.</li><li>Fred Bowen (KERNAL, BASIC) had originally used the BSO assembler, possibly also with added 65CE02 macros.</li><li>The external contractor Walrus Software Inc. (graphics extensions for BASIC) had used HCD65.</li></ul><p>All development was switched to 6502ASM in mid-1990.</p><p>The A2232 7-port serial card for the Amiga also contained a 65CE02 CPU. The project started in 1988, using the BSO assembler. The final version was built with 6502ASM on VAX<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup>.</p><hr /><p>This marks the end of the 5-part series on the assemblers used by Commodore.</p><div class="footnotes"><hr/><ol><li id="fn:1"><p>The Amiga makefile in the driver source does not build the 65CE02 source, but only links an already built .OBJ file, which is a strong indication that 6502ASM did not in fact exist on the Amiga, and the source was built on VAX and transferred to the Amiga instead.<a href="#fnref:1" rev="footnote">↩</a></p></li></ol></div>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1542</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>Commodore’s Assemblers: Part 4: HCD65</title> <link>https://www.pagetable.com/?p=1540</link> <comments>https://www.pagetable.com/?p=1540#comments</comments> <pubDate>Sun, 06 Jun 2021 04:31:41 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Commodore]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1540</guid> <description><![CDATA[In the series about the assemblers Commodore used for developing the ROMs of their 8-bit computers, this article covers the 1987 “HCD65” assembler that ran on the C128. Series Overview Part 0: Overview Part 1: MOS Cross-Assembler Part 2: MOS Resident Assembler Part 3: BSO CY6502 Part 4: HCD65 ← this article Part 5: 6502ASM History To build the ROMs for ... <a title="Commodore’s Assemblers: Part 4: HCD65" class="read-more" href="https://www.pagetable.com/?p=1540">Read more<span class="screen-reader-text">Commodore’s Assemblers: Part 4: HCD65</span></a>]]></description> <content:encoded><![CDATA[<p>In the series about the assemblers Commodore used for developing the ROMs of their 8-bit computers, this article covers the 1987 “HCD65” assembler that ran on the C128.</p><p><img src="docs/cbmasm/hcd65.png" alt="" /></p><h2 id="series-overview">Series Overview</h2><ul><li><a href="https://www.pagetable.com/?p=1518">Part 0: Overview</a></li><li><a href="https://www.pagetable.com/?p=1520">Part 1: MOS Cross-Assembler</a></li><li><a href="https://www.pagetable.com/?p=1522">Part 2: MOS Resident Assembler</a></li><li><a href="https://www.pagetable.com/?p=1538">Part 3: BSO CY6502</a></li><li><strong>Part 4: HCD65</strong> ← this article</li><li><a href="https://www.pagetable.com/?p=1542">Part 5: 6502ASM</a></li></ul><p><img src="docs/cbmasm/cbmasm_history.png" alt="" /></p><h2 id="history">History</h2><p>To build the ROMs for their 8-bit computers, Commodore originally used an assembler that ran on their own PET machines (<a href="https://www.pagetable.com/?p=1522">part 2</a> of the series). From 1984 on, they used the “Boston Systems Office” (BSO) cross-assembler running on VAX/VMS (<a href="https://www.pagetable.com/?p=1538">part 3</a>).</p><p>In 1986, Commodore started working on a clone of the BSO cross-assembler that was supposed to run on the C128. An internal document (<code>c65.doc</code>) in the <a href="http://www.zimmers.net/anonftp/pub/cbm/src/c128/c128_dev_pack.tar.gz">original C128 source archive</a> states:</p><blockquote><p>HCD65XX is a powerful macro assembler syntactically identical to the assembler used to orginally develop the C128 source code running on a VAX-8600 under VMS. This tool is capable of assembling the same source files on a C128.</p></blockquote><p>They announced the project in a <a href="https://archive.org/download/usenet-net">usenet post to net.micro.cbm</a> from April 1986:</p><blockquote><p>There is a package developed in house that includes a macro assembler and a program editor that both take advantage of the C128 hardware. […] the object was to make it do everything that the VAX based cross assemblers can do, and to allow truely large assemblies. The editor is similar to the DEC EDT keypad editing mode.</p><p>It is too soon to know when or if this package will be available, but I am sure that it will be publicized on the various networks…</p></blockquote><p>It was mentioned again in a post from October 1986:</p><blockquote><p>We have a developers package containing a new macro assembler and editor that we hope to have available by year end. The assembler is compatible with the BSO 6502 Assembler that has been used by Commodore for software development of late.</p></blockquote><p>The new assembler, called “HCD65” (in the manual) or “HCD65XX” (in the software), named after its developer Hedley Davis, was released in 1987 as part of the <a href="https://commodore.software/downloads/download/121-general-programming-tools/11956-commodore-128-developer-s-package">Commodore 128 Developer’s Package</a> (<a href="ftp://www.zimmers.net/pub/cbm/schematics/computers/c128/servicemanuals/C128_Developers_Package_for_Commodore_6502_Development_%281987_Oct%29.pdf">manual</a>, <a href="docs/cbmasm/hcd65.txt">internal</a>, <a href="docs/cbmasm/asm65ce02.txt">internal (65CE02 version)</a>).</p><h2 id="usage">Usage</h2><p>The assembler consists of two components: A BASIC program to query the arguments from the user, and the non-interactive assembler binary. The BASIC frontend presents the following menu:</p><pre><code>(C)1986 COMMODORE ELECTRONICS, LTD. ALL RIGHTS RESERVED V3.5 ENTER FILE NAME FOR SOURCE = KERNAL.SRC PICK A CONFIGURATION 0) NO LISTING : SOURCE,OBJ ON 8 1) LISTING TO SCREEN : SOURCE,OBJ ON 8 2) LISTING TO UNIT 4 : SOURCE,OBJ ON 8 3) ERRORS ONLY : SOURCE ON 8 4) LIST/XREF TO UNIT 4: SOURCE,OBJ ON 8 5) NO LISTING : SOURCE,OBJ ON 9 6) LISTING TO SCREEN : SOURCE,OBJ ON 9 7) PRINT LISTING ON 4 : SOURCE,OBJ ON 9 8) ERRORS ONLY : SOURCE ON 9 9) LIST/XREF TO UNIT 4: SOURCE,OBJ ON 9</code></pre><p>It allows entering a filename (the extension <code>.SRC</code> is added automatically) and configuration options that control whether to hide/show/print the LST, whether to generate a cross-reference and what drive to read the sources from. Pressing RETURN in the menu will allow the user to configure all options manually.</p><p>It then asks for the date string, since the C128 does not have a real-time clock, and asks the user to verify the settings:</p><pre><code>(C)1986 COMMODORE ELECTRONICS, LTD. ALL RIGHTS RESERVED V3.5 ASSEMBLY OF KERNAL.SRC SOURCE FILES ON UNIT 9 LISTING OUTPUT = PRINTER NO CROSS REFERENCE DATE STRING ="2021-05-08" ERROR OUTPUT = SCREEN OBJECT OUTPUT = KERNAL.OBJ ON UNIT 9 PRINTER DEVICE NUMBER = 4 LIST AND ERROR FILE WIDTH = 80 COLUMNS RUN THIS CONFIGURATION ? (Y/N)</code></pre><p>Pressing <code>Y</code> will start the assembly.</p><h2 id="differences">Differences</h2><p>HCD65 was designed to be as similar to BSO as possible, but there are a few differences:</p><ul><li>HCD65 accepts both ASCII and PETSCII source files. When using existing BSO source files, it is important that the source files use CR line breaks and that the filenames referenced by <code>.INCLUDE</code> have the right case.</li><li>HCD65 is missing the <code>.IF</code> directive that BSO understands as a synonym to <code>.IFN</code>.</li></ul><h2 id="versions">Versions</h2><p>There are four known versions of the HCD65 assembler:</p><h3 id="hcd65xx-v3.1">HCD65XX V3.1</h3><p>Little is known about this version. The LST files that shipped with the C128 Devpack were built with this version.</p><h3 id="hcd65xx-v3.5">HCD65XX V3.5</h3><p>This is the version that shipped as part of the C128 Devpack.</p><ul><li><a href="docs/cbmasm/hcd65_v3.5.zip">HCD65XX V3.5</a> (BAS: 6613 bytes, BIN: 10498 bytes, from <a href="http://6502.org/users/sjgray/dj/">DJ</a> devpack1of4.d64)</li></ul><h3 id="hcd65xx-65ce02-v0.1">HCD65XX 65CE02 V0.1</h3><p>In 1989, Commodore started writing the ROM for the upcoming C64DX/C65. The CPU of the machine was a 4510, which implemented the extended 65CE02 instruction set, so in order to use the additional CPU features, they needed an assembler that supported them.</p><p>The BSO/VAX cross-assembler that they had been using for all development at the time was written by a third party and Commodore did not have its source, so Fred Bowen added support to the C128 HCD65.</p><ul><li><a href="docs/cbmasm/hcd65_65ce02_v0.1.bin">HCD65XX 65CE02 V0.1</a> (BIN: 11166 bytes, built from the source using HCD65XX V3.5)</li></ul><h3 id="hcd65xx-65ce02-v0.2">HCD65XX 65CE02 V0.2</h3><p>Version 0.2 is changes the AUG/MAP opcode from 65CE02 to the 4510 semantics, and adds an alternative syntax to the BBR/BBS mnemos.</p><ul><li><a href="docs/cbmasm/hcd65_65ce02_v0.2.zip">HCD65XX 65CE02 V0.2</a> (BAS: 6769 bytes, BIN: 11156 bytes, from <a href="http://6502.org/users/sjgray/dj/">DJ</a> asm45.d81)</li></ul><h2 id="source">Source</h2><p>The sources of the V3.5 and 65CE02 0.1 and 0.2 versions are available as part of the Commodore Source collection:</p><p><a href="https://github.com/mist64/cbmsrc">https://github.com/mist64/cbmsrc</a></p><ul><li>HCD65_3.5</li><li>HCD65_65CE02_0.1</li><li>HCD65_65CE02_0.2</li></ul><h2 id="use-at-commodore">Use at Commodore</h2><p>It is unclear why Commodore developed HCD65 in the first place.</p><p>It is unlikely that they developed HCD65 mainly for a commercial release. There were plenty of assemblers on the market, and BSO compatibility is not something users were looking for.</p><p>Another hypothesis would be that they wanted to replace the BSO cross-assembler for in-house use.</p><p>In 1986, they were using BSO on a 12.5 MHz VAX-8600. The original PDP-10 version of BSO’s tools were implemented in hand-written machine code, but the later PDP-11/VAX/ULTRIX versions were probably written in a high-level language. There might have been a chance that a new assembler written in well-optimized machine code for the 2 MHz C128 could have matched the speed of the BSO assembler, but the C128’s I/O system (even using the new Fast Serial bus) would have certainly ruined that.</p><p>So they wouldn’t have replaced BSO for a speed benefit or added convenience. Original LST files that have been preserved show that Commodore used BSO, not HCD65, for all 6502-based projects until 1990 (C64GS).</p><p>One realistic reason for developing HCD65 would be as an insurance policy: to have an in-house alternative to BSO, so they would not be dependent on a third party. The in-house solution could also be altered and extended, especially in the context of the upcoming 4510/65CE02 CPU. The 65CE02 project, an effort to re-design the 6502 in CMOS, <a href="https://www.amazon.com/Commodore-Final-Years-Brian-Bagnall/dp/0994031033">started in late 1985</a>. And in fact, 4510/65CE02 support was added to HCD65 in 1989.</p><p>The graphics extensions to BASIC 10 by the external contractor Walrus Software Inc. were developed using HCD65 65CE02, and so was the C65 DOS ROM for a while, before all development switched to the “Commodore 6502ASM” cross-assembler in 1990.</p><p>The next article will discuss this new cross-assembler that Commodore developed in 1989.</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1540</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item> <title>Commodore’s Assemblers: Part 3: BSO CY6502</title> <link>https://www.pagetable.com/?p=1538</link> <comments>https://www.pagetable.com/?p=1538#comments</comments> <pubDate>Sat, 29 May 2021 17:37:59 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Commodore]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1538</guid> <description><![CDATA[In the series about the assemblers Commodore used for developing the ROMs of their 8-bit computers, this article covers the 1984 “Boston Systems Office” (BSO) cross-assembler running on VAX/VMS. 6502 relocating cross assembler version 20.53.12 Copyright, The Boston Systems Office, Inc. 1978 (617) 894-7800 TWX: 710-324-0760 Type /H for help Series Overview Part 0: Overview Part ... <a title="Commodore’s Assemblers: Part 3: BSO CY6502" class="read-more" href="https://www.pagetable.com/?p=1538">Read more<span class="screen-reader-text">Commodore’s Assemblers: Part 3: BSO CY6502</span></a>]]></description> <content:encoded><![CDATA[<p>In the series about the assemblers Commodore used for developing the ROMs of their 8-bit computers, this article covers the 1984 “Boston Systems Office” (BSO) cross-assembler running on VAX/VMS.</p><pre><code>6502 relocating cross assembler version 20.53.12 Copyright, The Boston Systems Office, Inc. 1978 (617) 894-7800 TWX: 710-324-0760 Type /H for help</code></pre><h2 id="series-overview">Series Overview</h2><ul><li><a href="https://www.pagetable.com/?p=1518">Part 0: Overview</a></li><li><a href="https://www.pagetable.com/?p=1520">Part 1: MOS Cross-Assembler</a></li><li><a href="https://www.pagetable.com/?p=1522">Part 2: MOS Resident Assembler</a></li><li><strong>Part 3: BSO CY6502</strong> ← this article</li><li><a href="https://www.pagetable.com/?p=1540">Part 4: HCD65</a></li><li><a href="https://www.pagetable.com/?p=1542">Part 5: 6502ASM</a></li></ul><p><img src="docs/cbmasm/cbmasm_history.png" alt="" /></p><h2 id="history">History</h2><p>Commodore bought the chip-maker MOS in 1976 and with it its development tools: They used the so-called MOS “Resident Assembler” (<a href="https://www.pagetable.com/?p=1522">part 2</a> of the series) – first on the MDT650 and later on the PET – to develop for machines like the VIC-20 and the C64, and for disk drives like the 8250 and the 1541.</p><p>In 1984, they switched to a cross-assembler by the company “Boston Systems Office” (BSO).</p><h2 id="boston-systems-office">Boston Systems Office</h2><p>Boston Systems Office had been specializing on cross-development tools since 1975, offering dozens of cross-assemblers for <a href="https://ia803207.us.archive.org/20/items/bitsavers_tymsharetygramIndexRev11May77_1215271/Tymcom-X_User_Program_Index_Rev11_May77_text.pdf">Tymshare</a> systems that were hand-written in PDP-10 assembly for maximum speed, and that aimed at full compatibility with the CPU-makers’ own tools.</p><p>Since 1976, they had been offering a 6502 assembler. The 1979 version of the BSO 6502 cross-assembler, called “CA6500” (<a href="https://github.com/TYMCOM-X/169273.tape/blob/abc68e373db6be0104efe986d23624462ef691b9/*6news/ca6502.doc">documentation</a>, <a href="https://github.com/TYMCOM-X/169273.tape/blob/abc68e373db6be0104efe986d23624462ef691b9/sys/ca6502.sav">PDP-10 binary</a>) was highly compatible with the original MOS assemblers, and had added a few features.</p><p>According to <a href="https://archive.org/details/AtariOperatingSystemUsersManualAugust1980">internal documentation</a>, Atari had used CA6500 on a PDP-11 for their in-house 6502 development as early as mid-1980.</p><p>In early 1984, BSO <a href="https://archive.org/details/computerworld1816unse/page/46/mode/2up?q=cy65xx">released</a> a version for PDP-11 and VAX/VMS named CY65XX<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup>, which was then licensed by Commodore. This version had many additional features added.</p><p>No binary of the assembler seems to be archived anywhere, but we do have the manual of the last version Commodore used:</p><ul><li><a href="docs/cbmasm/cy6502.txt">CY6502 Version 20.53.12 Manual</a> (1985)</li></ul><h2 id="usage">Usage</h2><p>When run, the BSO assembler shows the following prompt:</p><pre><code>6502 relocating cross assembler version 20.53.12 Copyright, The Boston Systems Office, Inc. 1978 (617) 894-7800 TWX: 710-324-0760 Type /H for help C65></code></pre><p>The output file (ABS) file, the LST file and the SRC file would be specified like this:</p><pre><code>C65>PROG.ABS,PROG.LST=PROG.SRC</code></pre><p>The file name extensions are optional. If they are omitted, the defaults are used.</p><p>The output file is in BSOs’ own “ABS” format, and needs another conversion step using the tool OBJCNV:</p><pre><code>Object file converter Version 3.25 Copyright, The Boston Systems Office, Inc. 1978 TEL: (617) 894-7800 TWX: 710-324-0760 Type /H for help ></code></pre><p>To convert the resulting ABS file into the MOS “OBJ” format, you would type this at the prompt:</p><pre><code>>PROG.OBJ/F:MTK=PROG.ABS/F:BSO</code></pre><p><code>MTK</code> stands for MOSTEK, a chipmaker unrelated to MOS Technology, Inc. BSO seems to have had confused the two companies: ABS files also contain the string <code>6502,MOSTEK</code>.</p><p>In practice, one would use a DCL script to invoke both tools with the right arguments.</p><h2 id="differences-to-original-mos-spec">Differences to Original MOS Spec</h2><p>The BSO assembler diverged in two aspects from the original MOS syntax:</p><ul><li>Labels have to start at column 1, so lines with labels cannot have any leading whitespace. But it is still legal for statements to also start on column 1: The assembler can tell them apart, since all mnemos are reserved keywords, which can’t be used as labels.</li><li>The <code>.OPT</code> directive is not supported. Several of the options are supported through dedicated directives though. See below.</li></ul><h2 id="differences-to-updated-resident-assembler">Differences to Updated Resident Assembler</h2><p>The syntax of both the Resident Assembler and the BSO cross-assembler are based on the original MOS syntax, but some features that are supported by later versions of both have diverged.</p><h3 id="include-syntax">Include Syntax</h3><p>The Resident Assembler uses the <code>.LIB</code> directive to include source files. The BSO assembler uses the <code>.INCLUDE</code> directive:</p><pre><code>.include disclaimer</code></pre><h3 id="macro-syntax">Macro Syntax</h3><p>Macros for the BSO assembler look like this:</p><pre><code>dpinc .macro arg ;double precision increment inc arg bne 1$ inc arg+1 1$ .endm</code></pre><p>The name of the macro is defined as a label. Arguments can be any string of characters after the <code>.MACRO</code> directive, and are blindly searched and replaced in the macro’s body. <code>.ENDM</code> marks the end of the body.</p><h3 id="conditional-assembly-syntax">Conditional Assembly Syntax</h3><p>Conditional assembly on the BSO assembler uses an <code>.IF</code>/<code>.ELSE</code>/<code>.ENDIF</code> construct, like this:</p><pre><code>.ifn gdebug jsr grbpri ;garbage debug .endif</code></pre><h2 id="new-features">New Features</h2><p>There are a number of additional features supported by the BSO assembler compared to the original MOS assemblers.</p><h3 id="text-format">Text Format</h3><p>Source files can now use the complete ASCII character set, as opposed to just uppercase. This means that comments can use mixed case and that TABs can be used for indenting.</p><p>In addition, labels, statements and operands are now case insensitive. In practice, all Commodore BSO source code uses lower case for those.</p><h3 id="local-labels">Local Labels</h3><p>Local labels are in the form of a number from 1 to 255 followed by a <code>$</code> sign, e.g.:</p><pre><code>100$ ; this is legal 001$ ; this is the same as the next 1$ ; this is the same as the previous 999$ ; this is illegal (1-255).</code></pre><p>The range of local labels is delimited by global labels as well as the <code>.LOCAL</code> directive.</p><h3 id="additional-directives">Additional Directives</h3><p>The BSO assembler supports a number of additional directives:</p><ul><li><code>.NAME</code>/<code>.TITLE</code>: set name of project</li><li><code>.SUBTTL</code>: set name of section (like <code>.PAGE</code> on MOS)</li><li><code>.SKIP</code>/<code>.SPACE</code>: skip lines in LST</li><li><code>.FORMLN</code>: set number of lines per page</li><li><code>.LIST</code>/<code>.NLIST</code>: enable/disable LST (like <code>.OPT LIST</code>)</li><li><code>.CLIST</code>/<code>.NCLIST</code>: show/hide disabled conditional assembly in LST</li><li><code>.MLIST</code>/<code>.NMLIST</code>/<code>.BLIST</code>: control macro expansions in LST</li><li><code>.GEN</code>/<code>.NOGEN</code>: enable/disable extra lines in LST (like <code>.OPT GENERATE</code>)</li><li><code>.INCLUDE</code>: include file</li><li><code>.MACRO</code>/<code>.ENDM</code>: macro definition (existed on MOS, but different syntax)</li><li><code>.REPT</code>/<code>.ENDR</code>: repeat</li><li><code>.IRP</code>/<code>.IRPC</code>: extended repeat</li><li><code>.IFE</code> conditional assembly if == 0 (existed on MOS, but different syntax)</li><li><code>.IFN</code>/<code>.IF</code> conditional assembly if != 0 (existed on MOS, but different syntax)</li><li><code>.IFGE</code> conditional assembly if is >= 0</li><li><code>.IFGT</code> conditional assembly if is > 0</li><li><code>.IFLT</code> conditional assembly if is < 0</li><li><code>.IFLE</code> conditional assembly if is =< 0</li><li><code>.IFB</code>/<code>.IFNB</code> conditional assembly if (not) blank</li><li><code>.IFIDN</code>/<code>.IFNIDN</code> conditional assembly if strings are (not) identical</li><li><code>.IFDEF</code>/<code>.IFNDEF</code> conditional assembly if symbol is (not) defined</li><li><code>.LOCAL</code>: delimit the range of local labels</li><li><code>.MESSG</code>: print message during pass 2</li><li><code>.RMB</code>: reserve memory byte</li><li><code>.RADIX</code>: change default radix for literals without a prefix</li></ul><p>All these features are also <a href="ftp://www.zimmers.net/pub/cbm/schematics/computers/c128/servicemanuals/C128_Developers_Package_for_Commodore_6502_Development_%281987_Oct%29.pdf">documented</a> in the “Commodore 128 Developer’s Package”, which cloned the BSO assembler for the C128. (More details in part 4 of the series.)</p><h3 id="relocating">Relocating</h3><p>It was possible to create relocatable object files with the BSO assembler. Commodore never made use of this feature. The following directives control this:</p><ul><li><code>.AORG</code>/<code>.RORG</code>/<code>.ZORG</code></li><li><code>.SECT</code>/<code>.ASECT</code>/<code>.RSECT</code>/<code>.ZSECT</code></li><li><code>.EXTERN</code>/<code>.INTERN</code></li><li><code>.LINK</code></li></ul><h3 id="lst-files">LST Files</h3><p>Listing files had an updated format. Here is an example:</p><pre><code>1581 DOS v10 318045-01 (c)1987 CBM CR6502/11 version 20.53.12 19-Mar-87 20:17:11 Page 26 "copy" COPY.SRC Error Addr Code Seq Source statement 1755 ; copy file(s) to one file 1756 87A2 20 82B9 1757 copy jsr lookup ; look ip all files 87A5 AD 022F 1758 lda f2cnt </code></pre><p>The header distinguishes between the project name (<code>.NAME</code>, first field of first line), the section name (<code>.SUBTTL</code>, first field of second line) and the filename (second field of second line), and contains the assembler’s name and the current date.</p><p>The body lines have a new first column that can contain one or more characters that indicate errors in the line, e.g. <code>U</code> for undefined symbol. This is instead of added lines with error messages.</p><h2 id="use-at-commodore">Use at Commodore</h2><p>From the headers of the Commodore LST that have been preserved, we can see that Commodore was using at least the following versions:</p><ul><li>version 10.36.6 since at least July 1984 (TED KERNAL and Char ROM)</li><li>version 20.51.10 since at least August 1984 (TED BASIC, 1570, original C128 ROM)</li><li>version 20.53.12 since at least December 1985 until July 1990 (later C128 ROM, 1551, later 1541/1541C/1541-II, 1571, 1571CR, 1581, C64GS)</li></ul><p>CY6502 was available for VAX/VMS and PDP-11 systems. Everything points towards Commodore using VAX hardware. The <a href="http://www.zimmers.net/anonftp/pub/cbm/src/c128/c128_dev_pack.tar.gz">original C128 source archive</a> contains a VAX reference dated October 1984 (file <code>monitor.sum</code>). A different file (<code>c65.doc</code>) in the C128 source archive mentions that the C128 ROM was developed on a VAX-8600 (12.5 MHz, 4+ MB RAM; released in October 1984).</p><p>According to a <a href="https://archive.org/download/usenet-net">usenet post to net.micro.cbm</a> from December 1985, Commodore had multiple VAX systems at least as early as December 1985:</p><blockquote><p>[…] which consists of the cbmvax 11/750 and a host of VMS Vaxen, Sun’s and developmental systems at both Commodore and Commodore [Amiga].</p></blockquote><p>(<code>cbmvax</code> was the UUCP-connected machine at Commodore. Usenet identifiers and (later) email addresses of Commodore employees contained this machine name.)</p><p>Another document (<code>howto.doc</code>) in the source archive describes how the result was transferred from the VAX to the Commodore computer: VAX computers were multi-user, and each developer had their own VT100-like terminal connected through RS-232. Each terminal had a second AUX/printer RS-232 connection that was connected to the Commodore computer (at 9600 baud if it had an ACIA chip). The tool “DOWNLOAD” on the VAX then sent the contents of the OBJ file through the terminal to the Commodore computer, which used a tool named “RSX” to receive the data.</p><p>The <a href="https://www.pagetable.com/?p=1540">next article</a> will discuss the HDC65 assembler on C128 that Commodore built in 1986 as a clone of the BSO assembler.</p><p><!-- --></p><div class="footnotes"><hr/><ol><li id="fn:1"><p>The BSO 6502 cross-assembler seems to have many names. The 1976 documentation called it CA6500: Back then, the 6502 was part of the 6500-series that consisted of the 6501 and the 6502. The version Commodore used 8 years later was called CY6502 in the documentation, but in LST files, it called itself CR6502/11: The “11” must have stood for either PDP-11 or VAX-11, or both. The “R” could stand for “relocatable”, which seemed to have been a recent feature.<a href="#fnref:1" rev="footnote">↩</a></p></li></ol></div>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1538</wfw:commentRss> <slash:comments>2</slash:comments> </item> <item> <title>Commodore’s Assemblers: Part 2: MOS Resident Assembler</title> <link>https://www.pagetable.com/?p=1522</link> <comments>https://www.pagetable.com/?p=1522#comments</comments> <pubDate>Sat, 22 May 2021 06:19:07 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Commodore]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1522</guid> <description><![CDATA[In the series about the assemblers Commodore used for developing the ROMs of their 8-bit computers, this article covers the 1976 “MOS Resident Assembler” that ran on a variety of 6502-based computers. Series Overview Part 0: Overview Part 1: MOS Cross-Assembler Part 2: MOS Resident Assembler ← this article Part 3: BSO CY6502 Part 4: HCD65 Part 5: 6502ASM History MOS ... <a title="Commodore’s Assemblers: Part 2: MOS Resident Assembler" class="read-more" href="https://www.pagetable.com/?p=1522">Read more<span class="screen-reader-text">Commodore’s Assemblers: Part 2: MOS Resident Assembler</span></a>]]></description> <content:encoded><![CDATA[<p>In the series about the assemblers Commodore used for developing the ROMs of their 8-bit computers, this article covers the 1976 “MOS Resident Assembler” that ran on a variety of 6502-based computers.</p><p><img src="docs/cbmasm/resident_assembler.png" alt="" /></p><h2 id="series-overview">Series Overview</h2><ul><li><a href="https://www.pagetable.com/?p=1518">Part 0: Overview</a></li><li><a href="https://www.pagetable.com/?p=1520">Part 1: MOS Cross-Assembler</a></li><li><strong>Part 2: MOS Resident Assembler</strong> ← this article</li><li><a href="https://www.pagetable.com/?p=1538">Part 3: BSO CY6502</a></li><li><a href="https://www.pagetable.com/?p=1540">Part 4: HCD65</a></li><li><a href="https://www.pagetable.com/?p=1542">Part 5: 6502ASM</a></li></ul><p><img src="docs/cbmasm/cbmasm_history.png" alt="" /></p><h2 id="history">History</h2><p>MOS Technology, Inc. released two assemblers for the newly introduced 6502 architecture: the “<strong>Cross-Assembler</strong>” (1975), available for various mainframes and minicomputers, and the “<strong>Resident Assembler</strong>” (1976), running natively on 6502 systems.</p><p>The Resident Assembler was <a href="https://www.facebook.com/groups/commodoreinternationalhistoricalsociety/permalink/2304551053122944/?comment_id=2304702559774460&__tn__=R">written</a> by Michael Corder (of MOS contractor COMPAS Microsystems) by hand-assembling the Cross-Assembler FORTRAN code to native 6502 assembly.</p><p>Consequently, both assemblers were compatible in that they understood the same source format, with the same math features<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup> and the same directives and options. That way, they defined the basic format supported by all future Commodore assemblers.</p><p>This means that the Resident Assembler took uppercase ASCII source files and created ASCII-encoded OBJ output files. It could even create the same LST output, but it was sent to the screen or the printer instead of a file.</p><h2 id="versions-and-platforms">Versions and Platforms</h2><p>The Resident Assembler ran on almost all 8-bit computer systems by MOS and Commodore.</p><h3 id="mdt650">MDT650</h3><p>MOS built two computers for demonstration of and development for their new 6502 CPU: the MDT650 and the KIM-1.</p><p>The very first version of the Resident Assembler targeted the MDT650 (“Microcomputer Development Terminal”; 1976), a development computer by MOS that contained two 6502 CPUs: One to develop software, and one to test it on. Its ROM came with an editor, the Resident Assembler and a disassembler. Source was saved on tape, and later on 8″ disks.</p><p>According to the <a href="docs/cbmasm/MOS%20MDT.pdf">manual</a>, the feature list of this version of the Resident Assembler was the same as that of the Cross-Assembler, except:</p><ul><li>no multiplication or division</li><li>no error files</li><li>no cross references</li><li>no symbol table sorting</li><li>no error messages; but errors numbers instead (1-23)</li></ul><p>No ROM dumps are known.</p><h3 id="kim-1">KIM-1</h3><p>The KIM-1 (1976) was a single-board computer originally intended as a demonstration board for the 6502, but with additional hardware, it could also be used as a full computer. For this, MOS released <a href="http://retro.hansotten.nl/6502-sbc/kim-1-manuals-and-software/kim-1-manuals-and-software/">hardware</a> like the KIM-2/KIM-3 RAM extension and the KIM-4 motherboard.</p><p>In 1977, Commodore <a href="https://archive.org/details/kilobaudmagazine-1977-07">announced</a> the Resident Assembler for the KIM-1, which was supposed to ship in the form of the KIM-5 ROM board with three 6540 ROM chips (6 KB total) containing the assembler and a simple editor. The same year, they announced that the project was being <a href="http://archive.6502.org/publications/6502notes/6502_user_notes_5.pdf">postponed indefinitely</a>, but it did appear in a <a href="https://worldradiohistory.com/UK/Practical-Computing/70s/Practical-Computing-1979-03-S-OCR.pdf">price list in 1979</a>.</p><p><a href="https://www.facebook.com/groups/commodoreinternationalhistoricalsociety/permalink/2304551053122944/"><img src="docs/cbmasm/KIM-5.png" alt="" /></a></p><p>There is a <a href="docs/cbmasm/MOS_KIM_Assembler_Manual_Preliminary.pdf">1977 manual</a>, which does not mention the <code>.DBYTE</code>, <code>.PAGE</code> and <code>.SKIP</code> directives. These were probably just undocumented, since the smaller AIM-65 version (see below) does support them.</p><p>The assembler could read source from cassette tape or paper tape, but it could not write OBJ files; instead, it would write the binary to RAM.</p><p>No ROM dumps are known.</p><p>(A company named “ARESCO” offered a 6 KB RAM-based assembler for the KIM-1 that may have been based on the MOS Resident Assembler. According to the <a href="https://www.apple.asimov.net/documentation/programming/6502assembly/Rainbow%20Assembler%20Editor%20manual%20Apple%20II.pdf">documentation of the Apple II version</a>, the supported directives and error codes matched the MOS Resident Assembler, and some sources call it the “MOS/ARESCO” assembler. Unfortunately, no dumps are known.)</p><h3 id="aim-65">AIM-65</h3><p>The AIM-65 (“Advanced Interactive Microcomputer”, 1978) was a single-board computer similar to the KIM-1, sold by the 6502 second source Rockwell. A very stripped down and optimized 4 KB version of the MDT650 version of the Resident Assembler was available for this platform.</p><p>The AIM-65 is not a MOS/Commodore device, and it was not used internally at Commodore, but its version of the Resident Assembler is presumably based on the (lost) KIM-1 version.</p><p>Chapter 5 of the <a href="docs/cbmasm/AIM-65_Users_Guide.pdf">AIM-65 User’s Guide</a> covers the assembler.</p><ul><li><a href="docs/cbmasm/resident_assembler_r3224_aim65.bin">AIM-65 Resident Assembler R3224</a> (1978)</li></ul><h3 id="pet">PET</h3><p>After the release of the CBM 2040 disk drive for the PET in 1978, John Feagans (of KERNAL fame) ported the MDT650 version of the Resident Assembler to the new platform.</p><p>The oldest known version is undated:</p><ul><li><a href="docs/cbmasm/resident_assembler_Vxxxxxx_pet.prg">PET Resident Assembler</a> (undated, 6696 bytes, from <a href="http://6502.org/users/sjgray/dj/">DJ</a> old-dos-sources.d81); for BASIC 2</li></ul><p>The next known versions are the only ones publicly released:</p><ul><li><a href="docs/cbmasm/resident_assembler_V112779_pet.prg">PET Resident Assembler V112779</a> (1979-11-27, 7426 bytes); for BASIC 2</li><li><a href="docs/cbmasm/resident_assembler_V121579_BASIC4_pet.prg">PET Resident Assembler V121579 BASIC4</a> (1979-12-15, 7546 bytes); for BASIC 4</li></ul><p>These two binaries were published as part of the <a href="http://www.zimmers.net/anonftp/pub/cbm/pet/programming/c=development.d64.gz">Commodore PET Assembler Development System</a> in 1980.</p><p>They add multiplication and division support, as well as textual error messages. So except for the missing cross-reference support, this version basically has feature parity with the MOS Cross-Assembler. The <a href="https://archive.org/details/manualzilla-id-5917290">manual</a> is based on the KIM-1 Assembler Manual, and adds descriptions of the OBJ format as well as the added features. Conditional compilation (<code>.IFN</code>/<code>.IFE</code>) is undocumented, but supported by the BASIC 4 version of the assembler.</p><p>There are more versions, all of which have only been used only internally:</p><ul><li><a href="docs/cbmasm/resident_assembler_V121579_BASIC2_pet.prg">PET Resident Assembler V121579 BASIC2</a> (1979-12-15, 7546 bytes, from <a href="docs/RB_Images.zip">RB</a> 6502ASM/MASTER.D80, UTIL001.D80, UTIL003.D80, UTIL004.D80, UTIL008.D80, UTIL009.D80); for BASIC 2: only direct calls into the PET ROM differ</li><li><a href="docs/cbmasm/resident_assembler_V090580_a_pet.prg">PET Resident Assembler V090580 A</a> (1980-09-05, 7858 bytes, from <a href="http://www.cbmhardware.de/show.php?r=14&id=66/Software">cbmhardware.de</a>); <strong>adds cross-reference support</strong></li><li><a href="docs/cbmasm/resident_assembler_V090580_b1_pet.prg">PET Resident Assembler V090580 B1</a> (1980-09-05, 7938 bytes, from <a href="http://6502.org/users/sjgray/dj/">DJ</a> b128-editor-1of1.d64); later (!) version with optimizations</li><li><a href="docs/cbmasm/resident_assembler_V090580_b2_pet.prg">PET Resident Assembler V090580 B2</a> (1980-09-05, 7822 bytes, from <a href="docs/RB_Images.zip">RB</a> UNKN003.D80, UTIL008.D80, UTIL009.D80); identical to B1, but for 72 lines per page instead of 66</li><li><a href="docs/cbmasm/resident_assembler_V102780_pet.prg">PET Resident Assembler V102780</a> (1980-10-27, 8049 bytes, from <a href="http://6502.org/users/sjgray/dj/">DJ</a> c64kernal.d64); detects BASIC 2/4 at runtime</li></ul><p>These two versions are non-mainline:</p><ul><li><a href="docs/cbmasm/resident_assembler_V050482_pet.prg">PET Resident Assembler V050482</a> (1982-05-04, 7624 bytes, from <a href="docs/RB_Images.zip">RB</a> UTIL008.D80); binary-patched version of V121579 BASIC4, asks “PAPER LENGTH (CR/66 OR 72)?”</li><li><a href="docs/cbmasm/resident_assembler_V26MAR82RR_pet.prg">CBM 6502 Copyright Assembler V26MAR82RR</a> (1982-03-26, 7982 bytes, from <a href="http://6502.org/users/sjgray/dj/">DJ</a> b128-kernal-2of2.d64); based on V090580 B, calls itself “CBM 6502 COPYRIGHT ASSEMBLER”; changes to LST format</li></ul><h3 id="c64">C64</h3><p>There is one known version of the Resident Assembler for the C64:</p><ul><li><a href="docs/cbmasm/resident_assembler_V080282_c64.prg">CBM Resident Assembler V080282 (C64)</a> (1982-08-02, 9714 bytes)</li></ul><p>It was released on disk as part of the <a href="http://www.zimmers.net/anonftp/pub/cbm/c64/programming/cbm-assembler.d64.gz">Commodore 64 Macro Assembler Development System</a>. The <a href="https://archive.org/details/C64MacroAssemblerDevelopmentSystemManualC64101">manual</a> is based on the PET version, and adds documentation of the macro (see below) and cross-reference features, but does not document conditional compilation. An earlier version of the manual, which is part of the <a href="https://archive.org/details/commodore64softwaredevelopmentkit">Commodore 64 Development Kit</a> internal document, does document conditional compilation, but not macros.</p><h3 id="ted-series-(c16,-c116,-plus/4)">TED Series (C16, C116, Plus/4)</h3><p>Commodore also ported the assembler to the TED series, but never released it publicly:</p><ul><li><a href="docs/cbmasm/resident_assembler_V112384_ted.prg">Commodore Assembler V2.0 (TED)</a> (1984-11-23, 10550 bytes, from <a href="http://6502.org/users/sjgray/dj/">DJ</a> cbm-assembler.d64)</li></ul><p>This binary was built from the <a href="https://github.com/mist64/cbmsrc/tree/master/ASSEMBLER_TED">original source code</a>. Unlike all earlier and later versions, this one does not interactively ask for its arguments, but relies on a BASIC program to place the arguments in memory before calling the machine code.</p><h3 id="c128">C128</h3><p>And finally, there is a C128 version:</p><ul><li><a href="docs/cbmasm/resident_assembler_V022086_c128.prg">C/128 6502 ASSEMBLER V022086</a> (1986-02-20, 10498 bytes, from <a href="http://6502.org/users/sjgray/dj/">DJ</a> testing-c65-dos.d81)</li></ul><p>It was based on the TED version, but went back to being standalone and asking for the arguments itself.</p><p>This version, too, was not released publicly.</p><h2 id="new-features">New Features</h2><p>While the MDT650 version of the Resident Assembler had no additional features compared to the Cross-Assembler, new features were added to later versions.</p><h3 id="kim-1/aim-65">KIM-1/AIM-65</h3><p>The AIM-65 version (and presumably the KIM-1 version) of the Resident Assembler added one new directive:</p><ul><li><code>.FILE</code>: switch to different source file, do not return</li></ul><p>The size of the source of a more complex program could easily exceed the amount of RAM installed in a KIM-1/AIM-65. For instance, the 4 KB version of the Resident Assembler itself was, without comments, 24 KB in size, much larger than the typical amount of RAM in a KIM-1 or AIM-65.</p><p>While the powerful computers that the <em>Cross-Assembler</em> ran on had text editors that could handle files larger than the available RAM, the KIM-1/AIM-65 editors could not do this.</p><p>Therefore, the assembler allowed splitting the source into multiple files, which were then concatenated during the build.</p><h3 id="pet-v112779-(1979-11-27)">PET V112779 (1979-11-27)</h3><p>Version V112779 of the PET Resident Assembler had the following additional features:</p><ul><li><code>.LIB</code>: switch to a different source file (and unlike <code>.FILE</code>, return to the original source file after the end of the included file)</li><li><code>.OPT</code> <code>SYMBOL</code> – <code>NOSYMBOL</code>: add symbol table to the end of the LST</li></ul><h3 id="pet-v121579-(1979-12-15)">PET V121579 (1979-12-15)</h3><p>Version V121579 added conditional assembly:</p><ul><li><code>.IFE</code>: conditionally assemble if expression == 0</li><li><code>.IFN</code>: conditionally assemble if expression != 0</li></ul><p>The code guarded by the condition has to be between <code><</code> and <code>></code>:</p><pre><code>.IFN GDEBUG < JSR GRBPRI ;GARBAGE DEBUG ></code></pre><h3 id="c64-v080282-(1982-08-02)">C64 V080282 (1982-08-02)</h3><p>The C64 version adds support for macros. The manual contains the following example:</p><pre><code> .MAC DPINC ;DOUBLE PRECISION INCREMENT INC ?1 BNE ?2 INC ?1+1 ?2 .MND</code></pre><p>The argument of <code>.MAC</code> is the name of the macro. The macro contents are defined between <code>.MAC</code> and <code>.MND</code>. Arguments are named <code>?1</code> etc., and local variables can be declared from the same namespace.</p><p>No known Commodore source code used this feature.</p><h3 id="ted-(1984-11-23)">TED (1984-11-23)</h3><p>The TED version adds the following <code>.OPT</code> arguments:</p><ul><li><code>LONG</code>/<code>NLONG</code>: allow long labels</li><li><code>MLI</code>/<code>NMLI</code>: enable expanding macros in LST</li></ul><p>Also, expressions can contain <code>&</code> (bitwise and), <code>.</code> (bitwise or) and <code>!</code> (bitwise exclusive or).</p><h3 id="c128-v022086-(1986-02-20)">C128 V022086 (1986-02-20)</h3><p>The C128 version removes support for mnemo statistics (<code>.OPT COUNT</code>/<code>CNT</code>/<code>NOCOUNT</code>).</p><h2 id="source-code">Source Code</h2><p>The source code of the TED and C128 versions was preserved as part of the <a href="http://www.zimmers.net/anonftp/pub/cbm/src/plus4/index.html">TED</a> and <a href="http://www.zimmers.net/anonftp/pub/cbm/src/c128/c128_dev_pack.tar.gz">C128 Source archives</a>. it was added to the Commodore Source collection:</p><p><a href="https://github.com/mist64/cbmsrc">https://github.com/mist64/cbmsrc</a></p><p>The sources of the AIM-65 version, all PET versions as well as the C64 version have been reconstructed from the TED source and are also available in this repository:</p><ul><li>ASSEMBLER_AIM65_REC</li><li>ASSEMBLER_PET_REC</li><li>ASSEMBLER_PET_V112779_REC</li><li>ASSEMBLER_PET_V121579_REC</li><li>ASSEMBLER_PET_V090580_A_REC</li><li>ASSEMBLER_PET_V090580_B_REC</li><li>ASSEMBLER_PET_V102780_REC</li><li>ASSEMBLER_PET_V26MAR82RR_REC</li><li>ASSEMBLER_C64_REC</li><li>ASSEMBLER_TED</li><li>ASSEMBLER_C128</li></ul><h2 id="bugs-and-quirks">Bugs and Quirks</h2><p>The C64 version has at least two known bugs:</p><ul><li><a href="https://archive.org/details/Commodore_Disk_User_Volume_03_Number_10_1990-08_Argus_Specialist_Publications_GB">Commodore Disk User 1990-08</a> contains an article that fixes some problems with macros.</li><li>A <a href="https://comp.sys.cbm.narkive.com/mgfpE1pf/c64-cbm-asm-bug">thread in comp.sys.cbm</a> discusses and fixes a problem with multiplication.</li></ul><p>It remains to be researched whether the TED source and the C128 binary contain these bugs.</p><p>Also, there is a confusing error message:</p><pre><code>**RAN OFF END OF CARD</code></pre><p>This means that the assembler was expecting more input, but encountered the end of the line. Back in the mainframe days, lines were also called “cards”, since one punch card stored a single input line.</p><p>The Cross-Assembler used to call lines “cards”, as can be seen in the LST headings:</p><pre><code> CARD # LOC CODE CARD 10 0009 B1 0E NEXT LDA (SAVIL)Y</code></pre><p>The Resident Assembler had dropped the “card” nomenclature on the PET though:</p><pre><code>LINE# LOC CODE LINE 10 0009 B1 0E NEXT LDA (SAVIL)Y</code></pre><p>…except for the single remaining case of the error message.</p><h2 id="use-at-commodore">Use at Commodore</h2><p>Commodore used the Resident Assembler on the MDT650 (with an 8″ disk drive) to develop the ROM of the original PET and the CBM 2040 (dual 5.25″) disk drive. At the time, the two MDT650 systems at Commodore were a <a href="https://www.facebook.com/groups/commodoreinternationalhistoricalsociety/permalink/2624023531175693/?comment_id=2624122201165826&__cft__[0]=AZWHV99O07jwUFqpjjSsN9hVaNNizvF4K5GhXzvU_WJJ9bxIyDRnZxmdrVduK35nuorC5tFw-kEpLhOroSx60QvS8hJrXSAEazqROkfRUuC37MhW-MqxHqB9joVP3coemgwJE6bgtiRwQ7wHwfjBOjQx&__tn__=R]-R">scarce resource</a>, so as soon as the CBM 2040 drive was available, the Resident Assembler was ported to the PET, and thus 6502 software development was switched to PETs.</p><p>The software Commodore built on the PET was:</p><ul><li>KERNAL/EDITOR and BASIC of later PETs, the CBM2, VIC-20 and C64</li><li>the DOS ROMs of the 4040, 8061/8062, D9060/D9090, 8050/8250/1001, 2031, 1540 and the original 1541</li><li>the ROMs of the 6502-based printers</li><li>Commodore-developed applications and games, like Gorf and Omega Race</li></ul><p>A large amount of <a href="https://github.com/mist64/cbmsrc">Commodore source</a> since 1980 (VIC-20, 1540, CBM 4040, …) has been preserved, and all source until 1984 (just before the TED series) is in a format that can be built with the Resident Assembler (V121579 or above).</p><p>The <a href="https://www.pagetable.com/?p=1538">next article</a> will discuss the BSO cross-assembler on VAX that Commodore switched to in 1984.</p><p><!-- TODO: * some other stuff during PET times, e.g. Transactor * https://ksquiggle.neocities.org/ff6502.htm was built with this * http://archive.6502.org/publications/icpug/icpug_v04_i06_nov_1982.pdf * inexplicably still uses OBJ * use outside of CBM? Rockwell? --></p><div class="footnotes"><hr/><ol><li id="fn:1"><p>Multiplication and division were missing from the original version.<a href="#fnref:1" rev="footnote">↩</a></p></li></ol></div>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1522</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item> <title>Commodore’s Assemblers: Part 1: MOS Cross-Assembler</title> <link>https://www.pagetable.com/?p=1520</link> <comments>https://www.pagetable.com/?p=1520#comments</comments> <pubDate>Sat, 15 May 2021 05:30:19 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Commodore]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1520</guid> <description><![CDATA[In the series about the assemblers Commodore used for developing the ROMs of their 8-bit computers, this article covers the 1975 “MOS Cross-Assembler”, which was available for various mainfraimes of the era. Series Overview Part 0: Overview Part 1: MOS Cross-Assembler ← this article Part 2: MOS Resident Assembler Part 3: BSO CY6502 Part 4: HCD65 Part 5: 6502ASM History MOS ... <a title="Commodore’s Assemblers: Part 1: MOS Cross-Assembler" class="read-more" href="https://www.pagetable.com/?p=1520">Read more<span class="screen-reader-text">Commodore’s Assemblers: Part 1: MOS Cross-Assembler</span></a>]]></description> <content:encoded><![CDATA[<p>In the series about the assemblers Commodore used for developing the ROMs of their 8-bit computers, this article covers the 1975 “MOS Cross-Assembler”, which was available for various mainfraimes of the era.</p><p><a href="https://archive.org/details/mos-6500-software-support"><img src="docs/cbmasm/cross-assembler.png" alt="" /></a></p><h2 id="series-overview">Series Overview</h2><ul><li><a href="https://www.pagetable.com/?p=1518">Part 0: Overview</a></li><li><strong>Part 1: MOS Cross-Assembler</strong> ← this article</li><li><a href="https://www.pagetable.com/?p=1522">Part 2: MOS Resident Assembler</a></li><li><a href="https://www.pagetable.com/?p=1538">Part 3: BSO CY6502</a></li><li><a href="https://www.pagetable.com/?p=1540">Part 4: HCD65</a></li><li><a href="https://www.pagetable.com/?p=1542">Part 5: 6502ASM</a></li></ul><p><img src="docs/cbmasm/cbmasm_history.png" alt="" /></p><h2 id="history">History</h2><p>MOS Technology, Inc. released two assemblers for the newly introduced 6502 architecture: the “<strong>Cross-Assembler</strong>”, available for various mainframes and minicomputers, and the “<strong>Resident Assembler</strong>”, running on natively on 6502 systems.</p><p><a href="https://www.pagetable.com/?p=1520#comment-694762">According to Norm Farrington</a>, MOS contracted with the company COMPAS to write the Cross-Assembler. COMPAS specialized in 6502-related software and hardware and developed some of the official MOS peripherals for the KIM-1.</p><p>The Cross-Assembler was <a href="https://archive.org/details/crossassemblersi886blan">written in FORTRAN</a><sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup> and used a 6-bit (i.e. all uppercase) character encoding. On a CDC Cyber 175 system, it required 120K (!) 60-bit words of memory to run and had “generally acceptable” response times.</p><p>The Resident Assembler (<a href="https://www.pagetable.com/?p=1522">part 2</a> of the series) was then developed (also by COMPAS) using the Cross-Assembler, and designed to be compatible in that it understood the same source format, with the same math features and the same directives and options. This way, MOS defined the basic format supported by all future Commodore assemblers.</p><h2 id="platforms">Platforms</h2><p>Today, you would expect a cross-assembler to run on Linux, Windows or Mac. But these were different times: When the 6502 was released, <em>micro</em>computers were just appearing – and the 6502 was a part of this shift – and even the first fridge-sized <em>mini</em>computers like the PDP series had only been introduced 10 years earlier. Most companies that used computers at the time used terminals that dialed into mainframes hosted in computing centers. And the market was very fragmented.</p><p>The 6502 <a href="http://archive.6502.org/books/mcs6500_family_programming_manual.pdf">Programming Manual (6500-50A)</a> states:</p><blockquote><p>The Cross Assembler is available on various time share systems or for batch use on the user’s system.</p></blockquote><p>According to the 6502 <a href="docs/cbmasm/MCS6500%20Microcomputer%20Family%20Cross%20Assembler%20Manual.pdf">Cross Assembler Manual (6500-60P)</a>, the supported platforms as of August 1975 were:</p><ul><li><a href="https://en.wikipedia.org/wiki/General_Electric">GE</a> Timesharing, running on GE/Honeywell mainframes</li><li><a href="https://en.wikipedia.org/wiki/National_CSS">National CSS</a> time-sharing, running VP/CSS on IBM System/360 and System/370 mainframes</li></ul><p>And the 1975 <a href="https://www.team6502.org/uploads/1/0/6/0/106091831/mos_brochure.pdf">MOS Technology marketing brochure</a>:</p><blockquote><p>Current plans involve having the software available on several of the more popular Time Sharing services.</p><p>In addition, it will be available for deck sales. Batch decks for the CDC, IBM, and PDP-11 class machines are available and we will support several other popular mini and major computer systems in the near future.</p></blockquote><p>Furthermore:</p><ul><li>The 1975 <a href="https://archive.org/details/mos-6500-software-support">MCS6500 Microprocessor Software Support brochure</a> shows the Cross-Assembler running on the United Computing Systems (UCS) time-sharing service.</li><li>A 1976 <a href="https://lib.dr.iastate.edu/cgi/viewcontent.cgi?article=6700&context=rtd">dissertation</a> shows that the Iowa State University ran the Cross-Assembler locally on an IBM 360/370.</li><li>A 1977 <a href="https://archive.org/details/bitsavers_ElectronicignV25N2119771011_176731913">magazine article</a> mentions support for PDP-8, PDP-10 and PDP-11.</li></ul><p><!-- NASA was using Cross-Assembler 5.1: https://ia601203.us.archive.org/23/items/NASA_NTRS_Archive_19800013494/NASA_NTRS_Archive_19800013494.pdf – Not sure what hardware it was on, though... --></p><h2 id="basic-syntax">Basic Syntax</h2><p>Back then, not all computer systems used the ASCII encoding, and some computers didn’t even support lower case. The encoding of source files is therefore specific to the platform the Cross-Assembler runs on, and only uppercase characters were allowed.</p><p>Here is an example from the manual:</p><pre><code>; ; 650X CROSS ASSEMBLER SAMPLE PROGRAM. ; *=$C000 DEFINE ORIGIN. LDX #$FF SET UP STACK. TXS LOAD STACK POINTER. LDA #$F0 LOAD A WITH HEX F0. STA ASAVE SAVE A IN ASAVE. ;; ALLOCATE SAVE AREA. ; *=$0000 ASAVE *=* .END</code></pre><ul><li>Lines starting with <code>;</code> are comments and will be ignored.</li><li>Labels start at the first column, everything else is indented.</li><li>Comments may follow the operand or the operand-less mnemonic. No <code>;</code> is necessary.</li><li>The Cross-Assembler uses the <code>*=</code> syntax to define the current assembly address.</li></ul><p>The rule about the start columns of labels and assembly statements is actually more relaxed, as this very compressed example from the C64 KERNAL shows:</p><pre><code>;COMMAND SERIAL BUS DEVICE TO LISTEN ;LISTN ORA #$20 ;MAKE A LISTEN ADR JSR RSP232 ;PROTECT SELF FROM RS232 NMI'S LIST1 PHA</code></pre><p>Since all mnemos and register names are reserved keywords and cannot be used for labels, the assembler does not enforce indenting for assembly statement. The <code>JSR RSP232</code> starting at the first column is legal. In fact, even labels may be indented. This example prepends comments after statements with <code>;</code>, which is legal because the assembler ignores everything after the statement anyway.</p><p>If you want to go for maximum readability (and don’t care about the size of the source), you could also indent the above example like this:</p><pre><code>; COMMAND SERIAL BUS DEVICE TO LISTEN ;LISTN ORA #$20 ; MAKE A LISTEN ADR JSR RSP232 ; PROTECT SELF FROM RS232 NMI'S LIST1 PHA</code></pre><p>Labels can be up to 6 characters in length, so one could use 7 character indents for statements so that they always line up. That’s also how the LST output is formatted, which will be described later.</p><h2 id="assembly-statements">Assembly Statements</h2><p>The accepted syntax of assembly statements matches the one in the <a href="http://archive.6502.org/books/mcs6500_family_programming_manual.pdf">6502 Programming Manual</a>. This includes the syntax for statements that take the accumulator as the argument:</p><pre><code>ASL A LSR A ROL A ROR A</code></pre><p>Modern assemblers usually allow omitting the <code>A</code>; the Cross-Assembler does not.</p><p>One additional feature is an alternative syntax to the indirect, y-indexed addressing mode. In addition to</p><pre><code>LDA (PNT),Y</code></pre><p>the following syntax is accepted:</p><pre><code>LDA (PNT)Y</code></pre><h2 id="expressions">Expressions</h2><p>Operands of assembly statements can use hexadecimal (<code>$</code>), octal (<code>@</code>), binary (<code>%</code>) and decimal (no prefix) constants. Mathematical expressions using <code>+</code>, <code>-</code>, <code>*</code> and <code>/</code> are possible, but they are always evaluated left-to-right with no operator precedence and no parenthetical grouping. Character/string literals are prefixed with <code>'</code>.</p><h2 id="directives">Directives</h2><p>The Cross-Assembler understands the following directives:</p><ul><li><code>.BYTE</code>: store one or more bytes</li><li><code>.WORD</code>: store one or more words (little endian)</li><li><code>.DBYTE</code>: store one or more words (big endian)</li><li><code>.PAGE</code>: optionally set a section title, and cause an LST page break</li><li><code>.SKIP</code>: insert a number of blank lines into the LST</li><li><code>.END</code>: stop assembly; not required but suggested at end of file</li><li><code>.OPT</code>: set or clear a list of options<ul><li><code>XREF</code> – <code>NOXREF</code>: add a cross-reference to the end of the LST</li><li><code>ERRORS</code> – <code>NOERRORS</code>: write errors into separate file</li><li><code>COUNT</code>/<code>CNT</code> – <code>NOCOUNT</code>: add mnemo statistics to the end of the LST</li><li><code>LIST</code> – <code>NOLIST</code>: enable LST output</li><li><code>MEMORY</code> – <code>NOMEMORY</code>: enable writing object file</li><li><code>GENERATE</code> – <code>NOGENERATE</code>: verbose printing of character strings in the LST</li></ul></li></ul><p>Only the first three characters after the period are actually checked.</p><h2 id="lst-file">LST File</h2><p>Like most development tools from the 1970s, the assembler can create a so-called listing file (suggested file extension <code>.LST</code>) during assembly that shows the source and the generated bytes side-by-side and is meant to be printed on paper. Here is a example from the manual:</p><pre><code> CARD # LOC CODE CARD 1 CR=15 2 LF=12 3 ; LOW CORE DATA AREAS 4 0000 E7 06 TEMTBL .WORD G3TEM, G1TEM 5 0002 E7 05 6 GROUP=B10 7 0004 00 THI .BYTE 0 8 0005 00 TLO .BYTE 0 9 0006 00 00 00 3PER .WORD 0 ***** ERROR ** LABEL DOESN'T BEGIN WITH ALPHABETIC CHARACTER - NEAR COLUMN 1 10 0009 B1 0E NEXT LDA (SAVIL)Y [...] 269 07C9 C9 3B CMP #'; 270 07CB 00 00 BEQ DONE ***** ERROR ** UNDEFINED SYMBOL - NEAR COLUMN 18 280 .END END OF MOS/TECHNOLOGY 650X ASSEMBLY VERSION 4 NUMBER OF ERRORS = 2, NUMBER OF WARNINGS = 0</code></pre><p>The first column (<code>CARD #</code>) is the line number in the source. The <code>LOC</code> field is the memory address, which is followed by the output bytes (<code>CODE</code>) and the source line (<code>CARD</code>), which the assembler re-indented for readability.</p><p>The <code>CARD</code> nomenclature stems from 1960s mainframes, where each line of text was represented by one punch card.</p><p>Error messages are shown as extra lines after the line that caused the error. Note that the assembler will keep working through the file no matter what, and will output placeholder bytes for lines with errors.</p><p>The <a href="http://retro.hansotten.nl/uploads/files/KIM%20ROM%20listings%20user%20manual.pdf">original LST printout of the KIM-1 ROM</a>, which was part of the <a href="http://retro.hansotten.nl/uploads/6502docs/usrman.htm">user manual</a>, is a real-world example of a 1200-line LST file, with the symbol table and the mnemo statistics (<code>.OPT COUNT</code>) at the end.</p><h2 id="obj-file">OBJ File</h2><p>The main output of the assembler is the binary program, which is in the form of a so-called “interface file” with a suggested file extension of <code>.OBJ</code>.</p><p>The diverse set of platforms that the Cross-Assembler ran on all had different word sizes, and many of them measured memory only in words and did not even have a concept of (8-bit) “bytes”. Therefore, the assembler could not output a binary file, but instead wrote a portable, hex-encoded text file, like this:</p><pre><code>;18E500A200A0DC60A228A01960B00786D684D3206CE5A6D6A4D3600D8C ;18E51820A0E5A9008D910285CFA9488D8F02A9EB8D9002A90A8D890C62 [...] ;06FFFA43FEE2FC48FF0665 ;0001200021</code></pre><p>Every line consists of the following characters:</p><ul><li><code>;</code>: first character of each record</li><li>2 chars: number of data bytes to follow</li><li>4 chars: load address of first byte of line</li><li>2 chars (repeated): data byte</li><li>4 chars: checksum</li></ul><p>The last line is<br />* <code>;00</code>: identifier for last line<br />* 4 chars: number of preceding lines<br />* 4 chars: checksum</p><p>The checksum is calculated by adding <em>all</em> preceding bytes of the line together.</p><p>This text-only file is platform-independent and can easily be transferred between different computer systems, and e.g. downloaded from a time-sharing system in order to write it to an EPROM.</p><h2 id="use-at-commodore">Use at Commodore</h2><p>The Cross-Assembler was used at MOS to create the very first 6502 code, like the KIM-1 ROM (shown above), or the <a href="http://archive.6502.org/books/mos_tim_terminal_interface_monitor_manual_mar_1976.pdf">TIM</a> ROM (MCS6530-004).</p><p>A large amount of the <a href="https://github.com/mist64/cbmsrc">original Commodore source code</a> has been preserved, and all code before 1984 is in a format very similar to the original MOS definition supported by both the Cross-Assembler and the Resident Assembler. So at first sight, it is not so clear which assembler Commodore used for developing ROMs of the PET, VIC-20 etc. and the disk drives.</p><p>The <a href="https://www.pagetable.com/?p=1522">next article</a> in the series will discuss this topic further.</p><div class="footnotes"><hr/><ol><li id="fn:1"><p>An earlier version of the article stated that the original MOS Cross-Assembler had been implemented by a grad student at the University of Illinois at Urbana-Champaign. In fact, the linked paper is only <em>about</em> the COMPAS/MOS Cross-Assembler as it was used on the university’s CDC computer.<a href="#fnref:1" rev="footnote">↩</a></p></li></ol></div>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1520</wfw:commentRss> <slash:comments>8</slash:comments> </item> <item> <title>Commodore’s Assemblers: Overview</title> <link>https://www.pagetable.com/?p=1518</link> <comments>https://www.pagetable.com/?p=1518#respond</comments> <pubDate>Sun, 09 May 2021 11:06:01 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Commodore]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1518</guid> <description><![CDATA[Commodore used 5 different assemblers, most of them in-house tools, to build the ROMs for their Computers like the PET, the C64 and the C128. Nevertheless, all Commodore source files, from 1975 to 1990, share a common format and use the same assembly directives. This series of articles describes each of these assemblers. Year Company ... <a title="Commodore’s Assemblers: Overview" class="read-more" href="https://www.pagetable.com/?p=1518">Read more<span class="screen-reader-text">Commodore’s Assemblers: Overview</span></a>]]></description> <content:encoded><![CDATA[<p>Commodore used 5 different assemblers, most of them in-house tools, to build the ROMs for their Computers like the PET, the C64 and the C128. Nevertheless, <a href="https://github.com/mist64/cbmsrc">all Commodore source files</a>, from 1975 to 1990, share a common format and use the same assembly directives. This series of articles describes each of these assemblers.</p><table><thead><tr><th> Year </th><th> Company </th><th> Assembler </th><th> Platform </th><th> Encoding </th></tr></thead><tbody><tr><td> 1975 </td><td> MOS </td><td> 6502 Cross-Assembler </td><td> GE, NCSS time-sharing, … </td><td> various (upper case) </td></tr><tr><td> 1976 </td><td> MOS </td><td> Resident Assembler </td><td> MDT650, KIM-1, PET, C64, CBM2, TED, C128 </td><td> ASCII (upper case, CR) </td></tr><tr><td> 1984 </td><td> BSO </td><td> CY6502 </td><td> VAX </td><td> ASCII (mixed case, CRLF) </td></tr><tr><td> 1986 </td><td> Commodore </td><td> HCD65 </td><td> C128 </td><td> PETSCII (mixed case, CR) </td></tr><tr><td> 1989 </td><td> Commodore </td><td> 6502ASM </td><td> VAX, Amiga, PC </td><td> ASCII (mixed case, LF/CRLF) </td></tr></tbody></table><h2 id="series-overview">Series Overview</h2><ul><li><strong>Part 0: Overview</strong> ← this article</li><li><a href="https://www.pagetable.com/?p=1520">Part 1: MOS Cross-Assembler</a></li><li><a href="https://www.pagetable.com/?p=1522">Part 2: MOS Resident Assembler</a></li><li><a href="https://www.pagetable.com/?p=1538">Part 3: BSO CY6502</a></li><li><a href="https://www.pagetable.com/?p=1540">Part 4: HCD65</a></li><li><a href="https://www.pagetable.com/?p=1542">Part 5: 6502ASM</a></li></ul><p><img src="docs/cbmasm/cbmasm_history.png" alt="" /></p><h2 id="cross-assembler-and-resident-assembler">Cross-Assembler and Resident Assembler</h2><p>In late 1975, MOS Technology, Inc. introduced the 6502 CPU and in 1976, they released the KIM-1, a demonstration/development platform for the 6502. Commodore bought MOS in November 1976, and the 6502 and the KIM-1 became Commodore products.</p><p>MOS also developed two assemblers for the 6502:</p><ul><li>The “Cross-Assembler” (1975), available for various mainframes and minicomputers.</li><li>The “Resident Assembler” (1976), running on 6502 systems. It was ported to all Commodore 8-bit computers. The C64 version was sold as the “C64 Macro Assembler” in 1982.</li></ul><p>Both assemblers were compatible in that they understood the same source format, with the same math features and the same directives and options.</p><p><strong>Read more: <a href="https://www.pagetable.com/?p=1520">Commodore’s Assemblers: Part 1: MOS Cross-Assembler</a></strong><br /><strong>Read more: <a href="https://www.pagetable.com/?p=1522">Commodore’s Assemblers: Part 2: MOS Resident Assembler</a></strong></p><h2 id="bso-cy6502-(vax)">BSO CY6502 (VAX)</h2><p>In mid-1984, Commodore switched to “CY6502” by the company Boston Systems Office (BSO), a cross-assembler running on VAX/VMS systems that was highly compatible to the MOS assemblers, but more advanced.</p><p><strong>Read more: <a href="https://www.pagetable.com/?p=1538">Commodore’s Assemblers: Part 3: BSO</a></strong></p><h2 id="hcd65-(c128)">HCD65 (C128)</h2><p>In 1986, Commodore wrote a new assembler named “HCD65” for the C128 that aimed at full compatibility with the BSO assembler. They sold it as part of the Commodore 128 Developer’s Package in 1987. In 1989, as Commodore worked on the ill-fated C65, they added support for the extended 65CE02/4510 instruction set.</p><p><strong>Read more: <a href="https://www.pagetable.com/?p=1540">Commodore’s Assemblers: Part 4: HCD65</a></strong></p><h2 id="6502asm-(vax,-amiga,-pc)">6502ASM (VAX, Amiga, PC)</h2><p>Also in 1989, and also for the C65 project, they wrote a new cross-platform assembler from scratch to replace the BSO one on VAX/VMS. It was supposed to be fully backwards-compatible and support the 65CE02/4510 instruction set from the start.</p><p><strong>Read more: <a href="https://www.pagetable.com/?p=1542">Commodore’s Assemblers: Part 5: 6502ASM</a></strong></p><h2 id="others">Others</h2><p>There are two more assemblers that were used to develop the ROMs of Commodore computers that don’t really count as in-house tools:</p><h3 id="macro-10-(pdp-10)">MACRO-10 (PDP-10)</h3><p>All Commodore 8-bit computers shipped with a version of Microsoft BASIC. Microsoft had used a PDP-10 mainframe for cross-developing the BASIC interpreter. Instead of writing a cross-assembler from scratch, they reused the MACRO-10 assembler that came with the PDP-10 and defined a set of macros that emitted 6502 opcodes. The article <a href="https://www.pagetable.com/?p=774">Microsoft BASIC for 6502 Original Source Code [1978]</a> has more information.</p><p>For the first two versions of the PET ROM, Microsoft delivered the BASIC binary together with the source to Commodore. After BASIC V2, Commodore adapted it to their own assemblers and built it themselves – so Microsoft’s development tools were never used by Commodore.</p><h3 id="merlin-128-(c128)">Merlin 128 (C128)</h3><p>The Merlin 128 Macro Assembler by Glen Bredon was a commercial assembler for the C128. It was used by <a href="http://6502.org/users/sjgray/dj/">Dennis Jarvis</a> while he worked on the DOS of the Commodore 65. Jarvis had used Merlin for his personal projects before, and it had become the tool of his choice.</p><p>He started out with the source of the CBM 8250 disk drive ROM, converted it from Commodore’s format to Merlin (PETSCII) format, and developed on top of it. The 65CE02/4510 extensions were used through a set of macros.</p><p>Towards the end of the project, the C65 DOS code was ported from Merlin to the cross-platform Commodore 6502ASM.</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1518</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>Reverse-Engineered geoWrite 2.1 for C64 Source Code</title> <link>https://www.pagetable.com/?p=1512</link> <comments>https://www.pagetable.com/?p=1512#comments</comments> <pubDate>Mon, 23 Nov 2020 14:26:48 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Archeology]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[GEOS]]></category> <category><![CDATA[Operating Systems]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1512</guid> <description><![CDATA[geoWrite is a WYSIWYG rich text editor for the Commodore 64 GEOS operating system. I created a reverse-engineered source version of the geoWrite 2.1 for the C64 (English and German) for the cc65 compiler suite: https://github.com/mist64/geowrite The source compiles into the exact same binaries as the English and German versions of geoWrite 2.1 included with ... <a title="Reverse-Engineered geoWrite 2.1 for C64 Source Code" class="read-more" href="https://www.pagetable.com/?p=1512">Read more<span class="screen-reader-text">Reverse-Engineered geoWrite 2.1 for C64 Source Code</span></a>]]></description> <content:encoded><![CDATA[<p>geoWrite is a WYSIWYG rich text editor for the Commodore 64 GEOS operating system. I created a reverse-engineered source version of the geoWrite 2.1 for the C64 (English and German) for the cc65 compiler suite:</p><p><a href="https://github.com/mist64/geowrite">https://github.com/mist64/geowrite</a></p><p>The source compiles into the exact same binaries as the English and German versions of geoWrite 2.1 included with GEOS 2.0.</p><p>Not all code has been commented yet, contributions are welcome.</p><p>The pagetable.com article series on geoWrite internals is based on the results of this reverse-engineering effort. Here is the list of articles in the series again:</p><ol><li><a href="https://www.pagetable.com/?p=1425">The Overlay System</a></li><li><a href="https://www.pagetable.com/?p=1428">Screen Recovery</a></li><li><a href="https://www.pagetable.com/?p=1436">Font Management</a></li><li><a href="https://www.pagetable.com/?p=1442">Zero Page</a></li><li><a href="https://www.pagetable.com/?p=1449">Copy Protection</a></li><li><a href="https://www.pagetable.com/?p=1460">Localization</a></li><li><a href="https://www.pagetable.com/?p=1471">File Format and Pagination</a></li><li><a href="https://www.pagetable.com/?p=1481">Copy & Paste</a></li><li><a href="https://www.pagetable.com/?p=1490">Keyboard Handling</a></li></ol>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1512</wfw:commentRss> <slash:comments>3</slash:comments> </item> <item> <title>Diskettenlaufwerke am Beispiel der Commodore 1541 [video]</title> <link>https://www.pagetable.com/?p=1505</link> <comments>https://www.pagetable.com/?p=1505#comments</comments> <pubDate>Tue, 20 Oct 2020 16:30:15 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Floppy Disks]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1505</guid> <description><![CDATA[Dieser Vortrag wurde am 11. Oktober 2020 auf dem (virtuellen) Vintage Computing Festival Berlin gehalten. Diskettenlaufwerke am Beispiel der Commodore 1541 Aus der Homecomputer- und frühen Personal-Computer-Zeit sind Disketten nicht wegzudenken. Dieser Vortrag beschäftigt sich mit Diskettentechnologie am Beispiel des 5,25-Zoll-Laufwerks “Commodore 1541”, bekannt als das Laufwerk zum Commodore C64. Nach einer historischen Einordnung (Bänder, ... <a title="Diskettenlaufwerke am Beispiel der Commodore 1541 [video]" class="read-more" href="https://www.pagetable.com/?p=1505">Read more<span class="screen-reader-text">Diskettenlaufwerke am Beispiel der Commodore 1541 [video]</span></a>]]></description> <content:encoded><![CDATA[<p><iframe width="1024" height="576" src="https://media.ccc.de/v/vcfb20_-_149_-_de_-_202010111700_-_diskettenlaufwerke_am_beispiel_der_commodore_1541_-_michael_steil/oembed" frameborder="0" allowfullscreen></iframe></p><p>Dieser Vortrag wurde am 11. Oktober 2020 auf dem (virtuellen) <a href="http://vcfb.de/">Vintage Computing Festival Berlin</a> gehalten.</p><p><b>Diskettenlaufwerke am Beispiel der Commodore 1541</b></p><p>Aus der Homecomputer- und frühen Personal-Computer-Zeit sind Disketten nicht wegzudenken. Dieser Vortrag beschäftigt sich mit Diskettentechnologie am Beispiel des 5,25-Zoll-Laufwerks “Commodore 1541”, bekannt als das Laufwerk zum Commodore C64. Nach einer historischen Einordnung (Bänder, Platten, 8-Zoll-Disketten) besprechen wir den Aufbau von Laufwerken und Disketten, sowie das Low-Level-Aufzeichnungsformat (Spuren, Sektoren, SYNC-Marker, GCR-Codierung) und dessen Implementierung in der Laufwerks-Firmware. Danach behandeln wir das Dateisystem-Format und die Datenübertragung zwischen dem Laufwerk und dem C64. Wir thematisieren außerdem Schnelllader, welche die Laufwerks-Firmware durch optimierteren Code zum Lesen und zur Datenübertragung ersetzen, sowie Kopierschutz-Systeme, die Nonstandard-Formate mit verschleierten Leseroutinen verbinden. Schließlich sprechen wir noch über Lösungen zum fehlerfreien Auslesen von antiken Disketten mit moderner Hardware.</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1505</wfw:commentRss> <slash:comments>7</slash:comments> </item> <item> <title>Ankündigung: Vortrag “Diskettenlaufwerke am Beispiel der Commodore 1541” am VCFB 2020</title> <link>https://www.pagetable.com/?p=1502</link> <comments>https://www.pagetable.com/?p=1502#respond</comments> <pubDate>Sat, 10 Oct 2020 09:49:27 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Floppy Disks]]></category> <category><![CDATA[Presentation]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1502</guid> <description><![CDATA[This post is about an upcoming talk in German. Update: Mitschnitt verfügbar! Am Sonntag, den 11. Oktober 2020 um 17:00 gibt es auf dem (virtuellen) Vintage Computing Festival Berlin meinen Vortrag Diskettenlaufwerke am Beispiel der Commodore 1541. Der Vortrag wird live gestreamt; ein Mitschnitt wird danach verfügbar sein. Diskettenlaufwerke am Beispiel der Commodore 1541 Aus ... <a title="Ankündigung: Vortrag “Diskettenlaufwerke am Beispiel der Commodore 1541” am VCFB 2020" class="read-more" href="https://www.pagetable.com/?p=1502">Read more<span class="screen-reader-text">Ankündigung: Vortrag “Diskettenlaufwerke am Beispiel der Commodore 1541” am VCFB 2020</span></a>]]></description> <content:encoded><![CDATA[<p><i>This post is about an upcoming talk in German.</i></p><p><b>Update: <a href="https://www.pagetable.com/?p=1505">Mitschnitt</a> verfügbar!</b></p><p>Am Sonntag, den 11. Oktober 2020 um 17:00 gibt es auf dem (virtuellen) <a href="http://vcfb.de/">Vintage Computing Festival Berlin</a> meinen Vortrag <a href="https://wiki.vcfb.de/2020/vortraege_workshops#diskettenlaufwerke_am_beispiel_der_commodore_1541">Diskettenlaufwerke am Beispiel der Commodore 1541</a>.</p><p>Der Vortrag wird <a href="https://wiki.vcfb.de/2020/stream">live gestreamt</a>; ein Mitschnitt wird danach verfügbar sein.</p><p><img src="docs/vcfb-1541.png" width="800" height="586"></p><p><b>Diskettenlaufwerke am Beispiel der Commodore 1541</b></p><p>Aus der Homecomputer- und frühen Personal-Computer-Zeit sind Disketten nicht wegzudenken. Dieser Vortrag beschäftigt sich mit Diskettentechnologie am Beispiel des 5,25-Zoll-Laufwerks “Commodore 1541”, bekannt als das Laufwerk zum Commodore C64. Nach einer historischen Einordnung (Bänder, Platten, 8-Zoll-Disketten) besprechen wir den Aufbau von Laufwerken und Disketten, sowie das Low-Level-Aufzeichnungsformat (Spuren, Sektoren, SYNC-Marker, GCR-Codierung) und dessen Implementierung in der Laufwerks-Firmware. Danach behandeln wir das Dateisystem-Format und die Datenübertragung zwischen dem Laufwerk und dem C64. Wir thematisieren außerdem Schnelllader, welche die Laufwerks-Firmware durch optimierteren Code zum Lesen und zur Datenübertragung ersetzen, sowie Kopierschutz-Systeme, die Nonstandard-Formate mit verschleierten Leseroutinen verbinden. Schließlich sprechen wir noch über Lösungen zum fehlerfreien Auslesen von antiken Disketten mit moderner Hardware.</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1502</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>Inside geoWrite – 9: Keyboard Handling</title> <link>https://www.pagetable.com/?p=1490</link> <comments>https://www.pagetable.com/?p=1490#comments</comments> <pubDate>Thu, 24 Sep 2020 14:19:10 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Archeology]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[GEOS]]></category> <category><![CDATA[Operating Systems]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1490</guid> <description><![CDATA[In the series about the internals of the geoWrite WYSIWYG text editor for the C64, this article discusses how the app consolidates keyboard input to keep up with fast typists. Article Series The Overlay System Screen Recovery Font Management Zero Page Copy Protection Localization File Format and Pagination Copy & Paste Keyboard Handling ← this ... <a title="Inside geoWrite – 9: Keyboard Handling" class="read-more" href="https://www.pagetable.com/?p=1490">Read more<span class="screen-reader-text">Inside geoWrite – 9: Keyboard Handling</span></a>]]></description> <content:encoded><![CDATA[<p>In the series about the internals of the geoWrite WYSIWYG text editor for the C64, this article discusses how the app consolidates keyboard input to keep up with fast typists.</p><p><img src="docs/geowrite/geowrite_9_keyboard.gif" height="400" width="640" alt="" /></p><h2 id="article-series">Article Series</h2><ol><li><a href="https://www.pagetable.com/?p=1425">The Overlay System</a></li><li><a href="https://www.pagetable.com/?p=1428">Screen Recovery</a></li><li><a href="https://www.pagetable.com/?p=1436">Font Management</a></li><li><a href="https://www.pagetable.com/?p=1442">Zero Page</a></li><li><a href="https://www.pagetable.com/?p=1449">Copy Protection</a></li><li><a href="https://www.pagetable.com/?p=1460">Localization</a></li><li><a href="https://www.pagetable.com/?p=1471">File Format and Pagination</a></li><li><a href="https://www.pagetable.com/?p=1481">Copy & Paste</a></li><li><strong>Keyboard Handling</strong> ← this article</li></ol><h2 id="geos-keyboard-basics">GEOS Keyboard Basics</h2><p>GEOS does not use the keyboard driver in the C64’s ROM, but has its own implementation that uses ASCII-based 8 bit key codes: Codes $20 through $7F are the regular ASCII printable characters. All control keys (e.g. cursor keys) as well as non-ASCII keys (like “£”) are mapped into the control code space $00 through $1F:</p><table><thead><tr><th> Code </th><th> Key </th><th> Comment </th></tr></thead><tbody><tr><td> $00 </td><td> </td><td> no key </td></tr><tr><td> $01 </td><td> F1 </td><td> </td></tr><tr><td> $02 </td><td> F2 </td><td> </td></tr><tr><td> $03 </td><td> F3 </td><td> </td></tr><tr><td> $04 </td><td> F4 </td><td> </td></tr><tr><td> $05 </td><td> F5 </td><td> </td></tr><tr><td> $06 </td><td> F6 </td><td> </td></tr><tr><td> $07 </td><td> NO SCROLL </td><td> C128 only </td></tr><tr><td> $08 </td><td> CRSR← </td><td> C64: SHIFT+CRSR→ </td></tr><tr><td> $09 </td><td> TAB </td><td> C64: Ctrl+I </td></tr><tr><td> $0A </td><td> LF </td><td> C128 only </td></tr><tr><td> $0B </td><td> ENTER </td><td> C128 only </td></tr><tr><td> $0C </td><td> </td><td> unused </td></tr><tr><td> $0D </td><td> </td><td> unused </td></tr><tr><td> $0E </td><td> F7 </td><td> </td></tr><tr><td> $0F </td><td> F8 </td><td> </td></tr><tr><td> $10 </td><td> CRSR↑ </td><td> C64: SHIFT+CRSR↓ </td></tr><tr><td> $11 </td><td> CRSR↓ </td><td> </td></tr><tr><td> $12 </td><td> HOME </td><td> </td></tr><tr><td> $13 </td><td> SHIFT+HOME </td><td> “CLR” </td></tr><tr><td> $14 </td><td> ← </td><td> </td></tr><tr><td> $15 </td><td> UPARROW </td><td> </td></tr><tr><td> $16 </td><td> STOP </td><td> </td></tr><tr><td> $17 </td><td> SHIFT+STOP </td><td> “RUN” </td></tr><tr><td> $18 </td><td> £ </td><td> </td></tr><tr><td> $19 </td><td> HELP </td><td> C128 only </td></tr><tr><td> $1A </td><td> ALT </td><td> C128 only </td></tr><tr><td> $1B </td><td> ESC </td><td> C128 only </td></tr><tr><td> $1C </td><td> SHIFT+DEL </td><td> “INST” </td></tr><tr><td> $1D </td><td> DEL </td><td> </td></tr><tr><td> $1E </td><td> CRSR→ </td><td> </td></tr><tr><td> $1F </td><td> </td><td> used internally </td></tr></tbody></table><p>All this defines the codes $00-$7F, which accounts for seven bits. The uppermost bit (value of $80) indicates whether the “Commodore” modifier key has been pressed with the key. The Commodore key is used in GEOS for keyboard shortcuts, much like the Command key on the Macintosh.</p><h3 id="keyboard-buffer">Keyboard Buffer</h3><p>The keyboard driver runs in the interrupt context, which is triggered 60 times per second by a timer. It scans the keyboard and puts new key codes at the end of a 16 byte queue: This way, no keys will be lost if the application can’t get to handling incoming keys immediately – as long as it’s not more than 16 keys behind.</p><p>The application can get the next key from the queue by calling <code>GetNextChar</code>. If there is a key in the queue, it will be removed from the queue and returned. Otherwise, a value of 0 will be returned.</p><p>All this is pretty much what’s going on in any operating system – including the C64’s original ROM in BASIC mode.</p><h3 id="callback">Callback</h3><p>GEOS is an event-driven environment: The system’s “main loop” controls all execution and calls back the app based on events, like mouse clicks, key presses and timers.</p><p>The idiomatic way to handle the keyboard on GEOS is therefore to register for keyboard callbacks. On every main loop iteration, the system will check whether there is at least one key in the queue. If this is the case, it will dequeue the oldest key, store it in the system variable <code>keyData</code> and call the function pointer <code>keyVector</code>, which the app can set. If the vector is 0 (the default), no callback will happen and the key code will be discarded.</p><p>The app can then read the key code from <code>keyData</code>, handle it and return. If there are more keys in the queue, the main loop will call the vector again, with the next key code, in the next iteration.</p><p>Alternatively, the callback function can read more keys from the queue by repeatedly calling <code>GetNextChar</code>.</p><h2 id="geowrite">geoWrite</h2><p>The core function of geoWrite is text input, so it needs to make sure it is responsive, and no key presses get lost.</p><p>And that’s tricky: On a 1 MHz CPU, redrawing several lines of proportional fonts can take seconds, so it is quite common that the app falls behind the user’s typing. So if the user types a character that leads to a few lines being redrawn, and the user types three characters in the meantime, these three characters may cause three redraws, in which time the user can type another nine characters. The app would fall more and more behind, and eventually drop characters.</p><p>To avoid this, the app has to catch up to the user’s typing. The good news is that once the app is behind on keys, it has several key codes to work with, so there are some optimizations that can be applied:</p><h3 id="consolidating-character-inserts">Consolidating Character Inserts</h3><p>When inserting a single character, the text data after the cursor is moved up by one byte and the new character is added. Then, the screen is updated: The part of the current line to the right of the cursor is redrawn, and if the last word of the line overflows to the next line, that one has to be redrawn as well and so on.</p><p>The following animation shows this in action:</p><p><img src="docs/geowrite/geowrite_9_keyboard.gif" height="400" width="640" alt="" /></p><p>Instead of doing this work for every character in the keyboard buffer separately, a lot of work can be saved by doing it for all characters in one go:</p><ul><li>Only move the buffer up once, by the number of characters in the buffer.</li><li>Copy the characters into the buffer.</li><li>Redraw only once.</li></ul><p>This is basically the same as what happens when <a href="https://www.pagetable.com/?p=1481">pasting text from a text scrap</a>.</p><p>You can see the effect of this strategy on the animation above. The “a” key was held down on the keyboard, generating a fast stream of “a” key codes.</p><ul><li>The first character is inserted, which triggers a redraw of just the line.</li><li>In the meantime, two more characters came in, which are added in one go. This triggers the redraw of the whole paragraph, in this case, since the word “Commodore” had to be moved to the next line.</li><li>This redraw was so expensive that seven more characters came in in the meantime. The line gets redrawn, and it does not overflow this time.</li><li>Because this redraw was cheap, only two more characters came in. Again, it causes a redraw of only the current line.</li></ul><p>We see in practice that whenever more text needs to be redrawn, more keypresses are buffered, but the system catches up quickly.</p><p>All printable characters as well as line break and TAB characters can be combined into a single string to be inserted. All other keys have to be special cased.</p><h3 id="del-characters">DEL Characters</h3><p>If the user types a character, and then hits the DEL key, the document will effectively be unchanged, but the text in memory was first moved up by one byte, then moved down by one byte again, and the screen was updated twice.</p><p>So if the keyboard buffer contains a DEL char, geoWrites removes the preceding character from the buffer. The two characters cancel each other out and no more work has to be done.</p><p>If a DEL is encountered while the buffer is empty, no character can be removed, but it’s not a character that can be inserted either. geoWrite then increments the count of DEL keys it has seen in the keyboard buffer that remained. There are some examples after the next paragraph.</p><h3 id="control-keys-and-keyboard-shortcuts">Control Keys and Keyboard Shortcuts</h3><p>Non-printable key codes like cursor keys and keyboard shortcuts are also special. If the queue contains “abc”, followed by C=T (Commodore Key + T; paste text) and “def”, geoWrite has to insert “abc”, paste the text in the text scrap, and then insert “def”. It can not combine the two text strings.</p><p>This is why whenever a control key or shortcut is encountered, geoWrite stops processing the queue. The DEL characters, the string so far and the control key will be evaluated, and the remainder of the keyboard queue will be handled once the <code>keyVector</code> is called the next time.</p><h3 id="examples">Examples</h3><p>Here are some examples of contents of the keyboard queue, the number of DEL characters at the beginning, the string to be inserted, the control key that was detected, and the contents of the keyboard queue after this processing:</p><table><thead><tr><th> Kbd Queue Before </th><th> # DEL </th><th> Insert String </th><th> Control Key </th><th> Kbd Queue After </th></tr></thead><tbody><tr><td> <code>abc</code> </td><td> 0 </td><td> <code>abc</code> </td><td> </td><td> </td></tr><tr><td> <code>abc<DEL></code> </td><td> 0 </td><td> <code>ab</code> </td><td> </td><td> </td></tr><tr><td> <code>abc<DEL>d</code> </td><td> 0 </td><td> <code>abd</code> </td><td> </td><td> </td></tr><tr><td> <code>abc<DEL><DEL>DEL></code> </td><td> 0 </td><td> </td><td> </td><td> </td></tr><tr><td> <code>abc<DEL><DEL>DEL><DEL></code> </td><td> 1 </td><td> </td><td> </td><td> </td></tr><tr><td> <code><DEL>abc</code> </td><td> 1 </td><td> <code>abc</code> </td><td> </td><td> </td></tr><tr><td> <code><DEL><DEL>abc</code> </td><td> 2 </td><td> <code>abc</code> </td><td> </td><td> </td></tr><tr><td> <code>a<DEL><DEL>bc</code> </td><td> 1 </td><td> <code>bc</code> </td><td> </td><td> </td></tr><tr><td> <code>a<C=T>bc</code> </td><td> 0 </td><td> <code>a</code> </td><td> <code>C=T</code> </td><td> <code>bc</code> </td></tr><tr><td> <code>a<DEL><DEL>bc<C=T><DEL>de</code> </td><td> 1 </td><td> <code>bc</code> </td><td> <code>C=T</code> </td><td> <code><DEL>de</code> </td></tr></tbody></table><p>The examples show that DEL keys that follow a character will effectively remove that key, but if the number of DEL key codes exceeds the number of characters before it, the extra DEL keys will be counted. And if there is a control key or keyboard shortcut, processing of the keyboard queue stops at this point.</p><h3 id="code">Code</h3><p>This is the code that processes the keyboard queue and returns the number of characters to delete, the string to insert, and the detected control key:</p><pre><code>processKbdQueue: lda #0 sta delCount ; no excess DEL keys so far sta kbdStringCnt ; kbd string empty sta curControlKey ; no control key lda keyData ; first character, as passed into keyVector @again: bmi @ctrl ; "C=" shortcut, so stop processing cmp #KEY_DELETE ; DEL key? beq @del ; yes cmp #KEY_INSERT ; SHIFT+DEL? beq @del ; yes (same as DEL in GEOS) cmp #CR ; return key? beq @nctrl ; yes, does not count as a control key cmp #TAB ; TAB key? beq @nctrl ; yes, does not count as a control key cmp #$20 ; below $20, i.e. non-printable bcc @ctrl ; yes, it's a control key, stop processing @nctrl: ldx kbdStringCnt sta kbdString,x ; add to kbd string inc kbdStringCnt @next: jsr GetNextChar ; are there more characters in the kbd queue? tax beq @rts ; no, return bne @again ; yes, repeat @del: ldx kbdStringCnt ; are there characters in the kbd string? beq @excss ; no, no characters to delete dec kbdStringCnt ; remove previous character bra @next ; and continue @excss: inc delCount ; count excess delete characters bne @next ; and continue @ctrl: sta curControlKey ; save control key @rts: rts</code></pre><p>geoWrite’s <code>keyVector</code> handler calls this, and then applies the three outputs (DELs, string, control key) to the document:</p><ol><li>First, if there are excess DELs, it deletes characters at the current cursor position according to the number of DELs. It just moves the remainder of the buffer down by the number of DELs.</li><li>Then, if there is a string, it inserts it in one go by moving the buffer up by the length of the string, and copying the string into the text.</li><li>If there were DELs or a string, the screen is updated.</li><li>If there is a control key, it gets evaluated.</li></ol><p>There are two special cases: If there are more DELs than characters on the current page, the extra DELs have to be handled differently. And if there are DELs <strong>and</strong> a string, there is an optimization performed in the first two steps: There is no need to move the buffer twice. For example</p><ul><li>if there is one DEL and two characters in the string, the buffer has to be moved up by one byte, and the insertion position is one byte before the cursor.</li><li>if there are two DELs and one character in the string, the buffer has to be moved down by one byte, and the insertion position is two bytes before the cursor.</li><li>if there are two DELs and two characters in the string, the buffer does not have to be moved at all, and the insertion position is two bytes before the cursor.</li></ul><h2 id="conclusion">Conclusion</h2><p>When designing software, a slow CPU can be made up for if there is a lot of memory, e.g. by caching data to avoid calculating it. And too little memory can be made up for by a fast CPU. GEOS and geoWrite had neither. They were written for an 8-bit CPU with 64 KB of RAM.</p><p>This scenario makes all design decisions interdependent:</p><ul><li>The memory constraint requires all code to be optimized for size, which makes it slower, and requires geoWrite to be <a href="https://www.pagetable.com/?p=1425">split into 9 parts</a> that are loaded from the slow disk drive.</li><li>The font renderer could have been much faster, had it had the space for fastpath code and caches.</li><li>Slow font rendering requires geoWrite to include lots of extra logic to be able to keep up with fast typists.</li><li>The extra code increases the memory pressure, requiring other code to be written more densely or pushed into different records.</li></ul><p>The GEOS engineers seem to have found a reasonable tradeoff. Yes, geoWrite is slow on an unexpanded C64, but it is a useful and very powerful tool for a 64 KB computer.</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1490</wfw:commentRss> <slash:comments>5</slash:comments> </item> <item> <title>Inside geoWrite – 8: Copy & Paste</title> <link>https://www.pagetable.com/?p=1481</link> <comments>https://www.pagetable.com/?p=1481#comments</comments> <pubDate>Tue, 22 Sep 2020 15:18:45 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Archeology]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[GEOS]]></category> <category><![CDATA[Operating Systems]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1481</guid> <description><![CDATA[In the series about the internals of the geoWrite WYSIWYG text editor for the C64, this article discusses its efficient cross-application cut/copy/paste implementation. Article Series The Overlay System Screen Recovery Font Management Zero Page Copy Protection Localization File Format and Pagination Copy & Paste ← this article Keyboard Handling GEOS Scrap Architecture Just like modern ... <a title="Inside geoWrite – 8: Copy & Paste" class="read-more" href="https://www.pagetable.com/?p=1481">Read more<span class="screen-reader-text">Inside geoWrite – 8: Copy & Paste</span></a>]]></description> <content:encoded><![CDATA[<p>In the series about the internals of the geoWrite WYSIWYG text editor for the C64, this article discusses its efficient cross-application cut/copy/paste implementation.</p><p><img src="docs/geowrite/geowrite_8_textscrap.png" height="400" width="640" alt="" /></p><h2 id="article-series">Article Series</h2><ol><li><a href="https://www.pagetable.com/?p=1425">The Overlay System</a></li><li><a href="https://www.pagetable.com/?p=1428">Screen Recovery</a></li><li><a href="https://www.pagetable.com/?p=1436">Font Management</a></li><li><a href="https://www.pagetable.com/?p=1442">Zero Page</a></li><li><a href="https://www.pagetable.com/?p=1449">Copy Protection</a></li><li><a href="https://www.pagetable.com/?p=1460">Localization</a></li><li><a href="https://www.pagetable.com/?p=1471">File Format and Pagination</a></li><li><strong>Copy & Paste</strong> ← this article</li><li><a href="https://www.pagetable.com/?p=1490">Keyboard Handling</a></li></ol><h2 id="geos-scrap-architecture">GEOS Scrap Architecture</h2><p>Just like modern operating systems, GEOS supports cut, copy and paste, within one app as well as between multiple apps. But this is about where the similarities end.</p><p>First of all, there is no single clipboard/pasteboard: There is one for every type of data, and they are called “scraps”. There can be a “text scrap” and a “photo scrap” (image data) at the same time, for example. When the user selects “paste” in the “edit” menu, geoWrite asks what type should be pasted:</p><p><img src="docs/geowrite/geowrite_8_paste.png" height="400" width="640" alt="" /></p><p>The GEOS KERNAL has no concept of scraps – they are purely a convention between apps. Text and photo scraps are specified by the <a href="https://archive.org/details/The_Official_GEOS_Programmers_Reference_Guide">GEOS reference manual</a> and apps like geoWrite, geoPaint and geoPublish implement this specification.</p><p>Since scraps can be rather large, they are stored as files on disk. Copying text between two apps basically means that one app writes a file with a defined file name in a standardized format, and the other app reads it. As a side effect, scraps are persistent even across reboots of the operating system. Here is a text scrap on disk:</p><p><img src="docs/geowrite/geowrite_8_textscrap.png" height="400" width="640" alt="" /></p><p>Text and photo scraps are the two types specified by GEOS, but since there is nothing special about scrap files, any application can use its own scrap format: geoCalc uses calc scraps, for example, which allows spreadsheet cells to be copied between documents.</p><p>By convention, scraps are sequential (non-VLIR) files with a name of “<code>* Scrap</code>” and a type of “<code>* Scrap Vn.n</code>”. “<code>*</code>” represents the type of scrap, space-padded to 5 characters:</p><table><thead><tr><th> App </th><th> Filename </th><th> Type String </th></tr></thead><tbody><tr><td> geoWrite 2.1 </td><td> <tt>Text Scrap</tt> </td><td> <tt>Text Scrap V2.0</tt> </td></tr><tr><td> geoPaint 2.0 </td><td> <tt>Photo Scrap</tt> </td><td> <tt>Photo Scrap V1.1</tt> </td></tr><tr><td> geoCalc 1.0 </td><td> <tt>Calc Scrap</tt> </td><td> <tt>Calc Scrap V1.1</tt> </td></tr></tbody></table><p>As you can see from the type string, scraps are versioned, just like apps and documents. Apps should contain conversion code to accept older versions, and refuse to load versions that are newer than supported.</p><p>GEOS comes with the Text Manager and Photo Manager desk accessories, which are simple databases (called “albums”) for text and photo scraps, respectively. The following screenshot is Text Manager showing a plain-text preview of one text scrap in its album:</p><p><img src="docs/geowrite/geowrite_8_textmanager.png" height="400" width="640" alt="" /></p><h2 id="text-scraps">Text Scraps</h2><h3 id="format">Format</h3><p>A text scrap is a sequential file on disk with a name of “<tt>Text Scrap</tt>” and a type of “<tt>Text Scrap V2.0</tt>”. It supports all geoWrite features (fonts, styles, rulers) except embedded images.</p><p>The first two bytes of the file are the size of the data that follows, so the data can be up to 65535 bytes. geoWrite can paste any size, but cannot create scraps larger than a page.</p><p>The remainder is regular geoWrite page data. It must start with a NewCardSet escape sequence to define the font and style of the text that follows. Here is an example:</p><pre><code>00000000 10 00 17 8c 00 40 48 65 6c 6c 6f 20 57 6f 72 6c |.....@Hello Worl| 00000010 64 21 |d!|</code></pre><ul><li><code>10 00</code> ($0010) is the scrap’s length, 16 bytes.</li><li><code>17</code> is the <code>ESC_NEWCARDSET</code> escape code.</li><li><code>8c 00</code> ($008C) specifies the California font at 12 pt.</li><li><code>40</code> is the style byte, and means bold face.</li><li>The remainder is the ASCII text “Hello World!”</li></ul><p>The text can contain the following control codes:</p><table><thead><tr><th> Code </th><th> Description </th></tr></thead><tbody><tr><td> $09 </td><td> Tab </td></tr><tr><td> $0C </td><td> Page Break </td></tr><tr><td> $0D </td><td> Line Break </td></tr><tr><td> $11 </td><td> Ruler Escape </td></tr><tr><td> $17 </td><td> NewCardSet Escape </td></tr></tbody></table><p>See <a href="https://www.pagetable.com/?p=1471">part 7</a> for more information on the geoWrite escape sequences. For the following sections, the background discussed in that article may be generally useful.</p><h3 id="geowrite-implementation">geoWrite Implementation</h3><p>By convention, the text scrap needs to be a file on disk. But disk is slow, so geoWrite uses a 300 byte cache in memory. When copying and pasting within the app, and if the text is small enough to fit in the cache, the scrap is not written to disk until necessary.</p><h4 id="copy">Copy</h4><p>If the user selects some text and then clicks on “copy” in the “edit” menu, the current selection gets copied into a text scrap.</p><p>First, geoWrite looks through the selected range of geoWrite data to see whether it contains an embedded image (<code>ESC_GRAPHICS</code>). If this is the case, it shows an error, since text scraps cannot contain images.</p><p><img src="docs/geowrite/geowrite_8_cantcopyimage.png" height="400" width="640" alt="" /></p><p>Then it trims the selection so that it doesn’t contain unnecessary data: If the very end of the selection is a ruler data structure, it gets removed, since all its properties (margins, tab stops, alignment and spacing) only apply to the paragraph following it, which is not part of the selection.</p><p>The same would be true for a NewCardSet (font and style) structure at the end of the selection, but the text selection logic has already stripped it from the end.</p><p>All text scraps have to start with the NewCardSet structure to set font and style. geoWrite does not have the space to work on a copy of the selected text and needs to create the scrap in-place: Therefore it saves the four bytes preceding the text range and overwrites them with the NewCardSet structure. It will restore these bytes after saving the text scrap.</p><p>If the resulting scrap data is small enough, it will be copied into the buffer in memory. Otherwise, it will be saved to disk. If there is already a text scrap on disk, it will be overwritten.</p><h4 id="paste">Paste</h4><p>The “paste/text” function in the “edit” menu inserts the text scrap at the cursor position. If there is currently text selected, it gets deleted before inserting the scrap, effectively replacing the selection with the scrap.</p><p>To insert text into a page, the text between the cursor position and the end of the buffer is moved up in memory to make space for the data to be inserted. If there is a text scrap in the memory buffer, geoWrite just copies the scrap data verbatim into the page.</p><h5 id="disk">Disk</h5><p>If the text scrap is on disk, it is more complicated. geoWrite cannot just make space in the buffer and read the scrap into it: It might not fit. The app’s <a href="https://www.pagetable.com/?p=1471">memory manager</a> generally keeps about one page in the buffer, and pages data from and to disk to work with bigger amounts of data.</p><p>geoWrite therefore reads and inserts the text scrap block by block, every time moving the page data up by a block. If this would overflow the buffer, the memory manager will do a repagination run to move some data to disk and therefore reduce the size of the data in the buffer.</p><p>But there is now another problem: Inserting the text scrap is no longer an atomic operation. geoWrite must be able to abort the insertion process after any block and still have a consistent document at the end. There are several reasons the insertion might be aborted:</p><ul><li>There is an I/O error when reading the scrap.</li><li>The document exceeds 61 pages.</li><li>The disk is too low on space to continue.</li></ul><p>Ruler (27 bytes) and NewCardSet (4 bytes) escape sequences may cross a block boundary, so if insertion is aborted, it could happen that an incomplete sequence is added to the document, which would leave the document in an illegal state.</p><p>Therefore, geoWrite interprets the scrap data and stops before escape sequences that span two blocks. It then only inserts the data before this incomplete escape sequence. Then, when the next block is loaded, it inserts the whole escape sequence in one go.</p><p>With this strategy, if an insertion has to be aborted, the text up to the error will be cleanly added to the document.</p><h5 id="style">Style</h5><p>All text scraps define the font and style at the beginning, and they can contain a ruler definition. By just concatenating the scrap with the document’s existing text after the insertion point, these font/style/ruler changes would continue to apply to existing text after the inserted scrap. Therefore, geoWrites inserts after the scrap a copy of the ruler or cardset that was active before the insertion point, in order to keep the style of the original text the same.</p><p>There is no need for this though:</p><ul><li>if there is already a ruler/NewCardSet escape at this position.</li><li>if the paste happens at the end of the document.</li><li>if the paste happens at the end of a page. The next page always starts with explicit paragraph and font/style escapes.</li></ul><h4 id="lazy-logic">Lazy Logic</h4><p>Copying and pasting text that is less than 300 bytes within geoWrite happens without disk access, but for interoperability with other apps, the buffer in memory will have to be written to disk in two cases:</p><ul><li>If geoWrite runs a desk accessory. Desk accessories are like apps, but they are smaller, launched from a regular app and they return to the app when they quit. Examples would be the calculator, note pad and the text and photo managers. These desk accessories may want to access the text scrap.</li><li>It geoWrite quits. If geoWrite is launched again, or any other app is run, this app may want to read the text scrap.</li></ul><h2 id="photo-scraps">Photo Scraps</h2><h3 id="format">Format</h3><p>A photo scrap is a sequential file on disk with a name of “<tt>Photo Scrap</tt>” and a type of “<tt>Photo Scrap V1.1</tt>”. It is generally a rectangular monochrome image.</p><p>The first three bytes of the file are the dimensions of the image. The width is one byte and is measured in units of 8 pixels. The next two bytes are the height in pixels. The theoretical maximum dimensions of a photo scrap are therefore 2040 (255*8) * 65535, with the width divisible by 8.</p><p>The bitmap data uses 8 horizontal pixels per byte (the leftmost pixel is bit 7, 1-bits are black). Consecutive bytes describe a pixel line from left to right. These lines are stored row by row starting from the top.</p><p>This bitmap data is stored compressed using a format based on runlength-encoding (RLE). GEOS KERNAL’s “BitmapUp” can decode this format, so applications can just pass the data to the KERNAL’s APIs without having to care about the specific encoding.</p><p>BitmapUp-compressed data is a sequence of packets. Every packet starts with a “count” byte:</p><table><thead><tr><th> <em>count</em> Value </th><th> Description </th></tr></thead><tbody><tr><td> $00 </td><td> Reserved </td></tr><tr><td> $01-$7F </td><td> <strong>Repeat</strong>: Repeat the following byte <em>count</em> times </td></tr><tr><td> $80 </td><td> Reserved </td></tr><tr><td> $81-$DB </td><td> <strong>Unique</strong>: Use the next <em>count</em> – $80 bytes literally </td></tr><tr><td> $DC </td><td> Reserved </td></tr><tr><td> $DD-$FF </td><td> <strong>Bigcount</strong>: Followed by a <em>bigcount</em> byte. Repeat the following <em>count</em> – $DC bytes <em>bigcount</em> times, interpreting the resulting bytes using the <strong>Repeat</strong> and <strong>Unique</strong> rules. </td></tr></tbody></table><p>As an example, let’s look at a 16×16 rectangle:</p><pre><code>**************** * * * * * * * * * * * * * * * * * * * * * * * * * * * * ****************</code></pre><p>It can be compressed into 9 bytes:</p><pre><code>.byte 2,%11111111 .byte $DC+3,14 .byte $80+2,%10000000,%00000001 .byte 2,%11111111</code></pre><ul><li>The first line instructs the decoder to repeat the bit pattern %11111111 <strong>2</strong> times, producing 16 black pixels – the top line of the rectangle.</li><li>The second line will cause the next <strong>3</strong> bytes to be repeated <strong>14</strong> times, once for every line of the rectangle except the first and the last one.</li><li>These next three bytes are again encoded and tell the decoder to take the next <strong>2</strong> bytes verbatim: %10000000 and %0000001 describe one line of the rectangle with the leftmost and the rightmost pixel set.</li><li>The last line is the same as the first one; it creates the bottom row.</li></ul><p>After the monochrome bitmap data, an image scrap can optionally contain data on how to colorize 8×8 pixel squares. geoWrite does not support color and just ignores this part.</p><h3 id="geowrite-implementation">geoWrite Implementation</h3><p>geoWrite can paste photo scraps with heights up to 144 pixels. Images wider than the page’s dimensions will effectively be cropped when rendering.</p><p>In geoWrite documents, image data is not stored inline with the text of the document. Instead, the text contains a 5 byte graphics escape sequence pointing to the image:</p><table><thead><tr><th>Offset</th><th> Type </th><th> Contents </th><th> Description </th></tr></thead><tbody><tr><td> 0 </td><td> Byte </td><td> Escape Code </td><td> Constant $10 (<code>ESC_GRAPHICS</code>) </td></tr><tr><td> 1 </td><td> Byte </td><td> Image Width </td><td> Width of image divided by 8 </td></tr><tr><td> 2-3 </td><td> Word </td><td> Image Height </td><td> Height of image </td></tr><tr><td> 4 </td><td> Byte </td><td> Record Number </td><td> Number of record containing image data </td></tr></tbody></table><p>The data of each image is stored in a separate <a href="https://www.pagetable.com/?p=1425">VLIR</a> record. The format of image records is that of photo scraps, so when pasting an image, all geoWrite has to do is make a copy of the photo scrap file into a new VLIR record in the document.</p><p>Before this can be done, a few checks have to be made though:</p><ul><li>A photo scrap file must exist.</li><li>The file version must not be too new. (There is a bug in geoWrite 2.1: It checks for a maximum version of V2.1, but the highest version of the photo scrap file format at the time geoWrite was written was V1.1 – and still is today. The version checking code was meant for geoWrite documents and text scraps, whose versioning follows the geoWrite version. It should have been special cased for photo scraps.)</li><li>The height must not be more than 144 pixels.</li><li>There must be space in the document. A geoWrite document can hold up to 64 images.</li></ul><h2 id="nomenclature">Nomenclature</h2><p>One last thought about GEOS and naming things. What I called “image” throughout this article, GEOS calls:</p><ul><li><strong>graphics</strong> in the KERNAL API.</li><li><strong>picture</strong> in the geoWrite UI.</li><li><strong>photo</strong> in all references to photo scraps.</li></ul><h2 id="references">References</h2><ul><li>Michael Farr: <a href="https://archive.org/details/The_Official_GEOS_Programmers_Reference_Guide">The Official GEOS Programmer’s Reference Guide</a></li><li>Berkeley Softworks: <a href="https://archive.org/details/The_Hitchhikers_Guide_to_GEOS">The Hitchhiker’s Guide to GEOS</a></li></ul>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1481</wfw:commentRss> <slash:comments>2</slash:comments> </item> <item> <title>Inside geoWrite – 7: File Format and Pagination</title> <link>https://www.pagetable.com/?p=1471</link> <comments>https://www.pagetable.com/?p=1471#respond</comments> <pubDate>Wed, 16 Sep 2020 17:34:59 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Archeology]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[GEOS]]></category> <category><![CDATA[Operating Systems]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1471</guid> <description><![CDATA[In the series about the internals of the geoWrite WYSIWYG text editor for the C64, this article discusses how its file format allows the app to efficiently edit documents hundreds of KB in size. Article Series The Overlay System Screen Recovery Font Management Zero Page Copy Protection Localization File Format and Pagination ← this article ... <a title="Inside geoWrite – 7: File Format and Pagination" class="read-more" href="https://www.pagetable.com/?p=1471">Read more<span class="screen-reader-text">Inside geoWrite – 7: File Format and Pagination</span></a>]]></description> <content:encoded><![CDATA[<p>In the series about the internals of the geoWrite WYSIWYG text editor for the C64, this article discusses how its file format allows the app to efficiently edit documents hundreds of KB in size.</p><p><img src="docs/geowrite/geowrite_7_pagebreak.png" height="400" width="640" alt="" /></p><h2 id="article-series">Article Series</h2><ol><li><a href="https://www.pagetable.com/?p=1425">The Overlay System</a></li><li><a href="https://www.pagetable.com/?p=1428">Screen Recovery</a></li><li><a href="https://www.pagetable.com/?p=1436">Font Management</a></li><li><a href="https://www.pagetable.com/?p=1442">Zero Page</a></li><li><a href="https://www.pagetable.com/?p=1449">Copy Protection</a></li><li><a href="https://www.pagetable.com/?p=1460">Localization</a></li><li><strong>File Format and Pagination</strong> ← this article</li><li><a href="https://www.pagetable.com/?p=1481">Copy & Paste</a></li><li><a href="https://www.pagetable.com/?p=1490">Keyboard Handling</a></li></ol><h2 id="design">Design</h2><p>Writing a word processor, especially a WYSIWYG one, poses two core challenges:</p><ol><li><strong>Memory Management</strong>: The whole document may not fit into memory. A small text file is easily dozens of KB, and a large one hundreds of KB, not counting inline images. The word processor needs a strategy to only keep the parts in memory that are currently needed.</li><li><strong>Pagination</strong>: WYSIWYG mans that the user will always see on which page, and where on that page the text that is currently being edited will appear when printing. This requires the word processor to layout the whole text up to the current position.</li></ol><h3 id="memory-management">Memory Management</h3><p>The natural approach to memory management is to only read a small part of the document into memory for viewing and editing. Once the user jumps to a different part of the document or writes enough text to fill the buffer, the current part has to be written to disk, and a different part has to be loaded into memory.</p><p>This is tricky with regular (“sequential”) files: When writing a part of the document back to disk, the new version is generally a different size than the part that it replaces. This means that the remainder of the document has to be moved. In the worst case, this requires making a complete copy of the document and temporarily taking up twice the space on disk.</p><p>GEOS has the concept of a VLIR file, which is a collection of up to 127 “sub-files”, called records, numbered 0 to 126. The geoWrite application itself consists of several such records for its own code, which are <a href="https://www.pagetable.com/?p=1425">paged in</a> based on which functionality is being used. Similarly, geoWrite documents are VLIR files containing multiple records of no more than 7 KB – this is how much memory is left on a 64 KB RAM system after accounting for the operating system and the geoWrite application.</p><p>In the generic case, the word processor can then just read a single record from disk into memory, have the user edit it, and write the record back to disk. All other records remain unchanged.</p><p>A simple approach for dividing up the document would be to just cut it into 7 KB parts. If text is added to the middle of the document, and the record overflows 7 KB, it will have to be divided into two, and all subsequent records have to be moved up. If two consecutive parts are less than 7 KB together, they can be combined, and subsequent records have to be moved down. Moving records really just means renaming them and is therefore cheap.</p><p>The problem with dividing up the document at fixed limits is that the point where text continues from one record to the next may be anywhere. Therefore, a single sentence on the screen might come from two different records, and moving the mouse across this invisible line will cause slow (and surprising!) disk access. It’s even worse when performing an operation on selected text that spans two records, which may cause swapping in and out of parts multiple times.</p><h3 id="pagination">Pagination</h3><p>The other challenge is pagination. There is no information in the document on how to map a page number to a record, so if the user wants to jump to a specific page, the word processor would have to actively find out what part of the document will end up printed on that page. If the desired page is after the current one, all text from the current position on has to be paginated, i.e. put through the page layout logic until the point in the document is found that will be printed on the specified page. If the desired page is before the current one, the same logic would have to be done starting from the first page of the document.</p><p>To avoid redundant “re-pagination”, the calculated pagination information could be stored as metadata in the file. For every page, this would be the combination of record number and offset within the record to point to the first character of the page. If text is edited anywhere but at the end of the document, the remainder of the document has to be re-paginated, and the table has to be updated – this can be done lazily. Jumping within the document now only requires a table lookup.</p><h3 id="geowrite-strategy">geoWrite Strategy</h3><p>geoWrite uses a combined strategy for memory management and pagination: It maps every page to exactly one record. The app reserves 7000 bytes of RAM for the currently edited page, which corresponds to just about one page fully filled with 9 pt text. Jumping to a different page is as simple as reading a different record – without requiring a separate page-to-record mapping table. And it also solves the other problem from before: Since a whole page is guaranteed to be in RAM, editing text within a page generally does not cause disk access.</p><p>Picking pages as the unit of editing does sound weird at first, because the separation into pages is such a transient property of a text document. After all, the very idea of a word processor (as opposed to a typewriter) is that the user can regard the document as just linear text without worrying about page breaks. When editing text, page boundaries change, and the whole document would have to be changed. This is true, but these re-layouts of the document are necessary when editing, no matter what strategy is used to cut the document into pieces.</p><p>Here is an overview of the properties of the two strategies, with the more desirable ones marked in bold:</p><table><thead><tr><th> </th><th> Max Size Records + Metadata </th><th> One Record per Page </th></tr></thead><tbody><tr><td> Jump to page </td><td> <strong>lookup, read record</strong> </td><td> <strong>read record</strong> </td></tr><tr><td> Add text in the middle </td><td> <strong>re-pagination</strong> </td><td> re-pagination & data copy </td></tr><tr><td> Surprising disk access </td><td> yes </td><td> <strong>no</strong> </td></tr></tbody></table><ul><li>Both strategies allow navigating the document efficiently.</li><li>Adding text to the middle of the document always requires re-pagination of the following pages at some point. With the “one record per page” strategy, this also requires going through all following records and re-combining them according to the new page breaks.</li><li>Generally, no edit operation within a single page will cause disk access with the “one record per page” strategy.</li></ul><p>So it’s basically a tradeoff between repagination speed and editing performance, and geoWrite went for the latter.</p><h2 id="file-format">File Format</h2><p>Before we discuss when and how exactly a document is re-paginated with geoWrite, we have to dive into the exact file format.</p><p>geoWrite files are VLIR files. GEOS specifies a VLIR file as consisting of a 256 byte file header and up to 127 records of arbitrary lengths.</p><p>The file header of any GEOS document contains the file’s icon, type and creator, a comment, and optionally, type-specific metadata.</p><p>geoWrite stores 9 bytes of metadata at offset $89 for document-global properties:</p><table><thead><tr><th> Offset </th><th> Size </th><th> Contents </th><th> Description </th></tr></thead><tbody><tr><td> $89-$8A </td><td> Word </td><td> Start Page Number </td><td> Number of first page, usually 1 </td></tr><tr><td> $8B </td><td> Byte </td><td> Title/NLQ Flags </td><td> $80: has title page, $40: NLQ mode </td></tr><tr><td> $8C-$8D </td><td> Word </td><td> Header Height </td><td> Height of header in dots </td></tr><tr><td> $8E-$8F </td><td> Word </td><td> Footer Height </td><td> Height of footer in dots </td></tr><tr><td> $90-$91 </td><td> Word </td><td> Page Height </td><td> Page height in dots </td></tr></tbody></table><ul><li>The start page number can be set to numbers other than 1, to allow splitting a project into multiple document files with consistent page numbering.</li><li>If the document has a title page, no header or footer will be printed onto the first page.</li><li>In NLQ mode, the document will be printed by sending ASCII characters to the printer, using the printer’s built-in fonts. This changes the metrics calculation.</li><li>Header and footer height are calculated from the header/footer text. These are cached values to allow page layouts without having to measure the height of the header and the footer.</li><li>The page height is generally a property of the printer. The field in the file header specifies what page height was used for paginating the document. If the page height of the current printer is different, the document has to be re-paginated.</li><li>All sizes are specified in dots, which are 1/80 of an inch on paper, and the same as GEOS screen pixels. geoWrite documents are either 480 (6 inches, “regular”) or 640 (8.2 inches, “wide”) dots wide. The default height (i.e. if no printer is installed) is 752 dots (9.4 inches).</li></ul><p>These are the contents of the VLIR records of a geoWrite document:</p><table><thead><tr><th> Records </th><th> Contents </th></tr></thead><tbody><tr><td> 0-60 </td><td> Pages </td></tr><tr><td> 61 </td><td> Header </td></tr><tr><td> 62 </td><td> Footer </td></tr><tr><td> 63 </td><td> Reserved </td></tr><tr><td> 64-126 </td><td> Images </td></tr></tbody></table><ul><li>A document can have up to 61 pages, which are stored in records 0 through 60. Internally, page numbering is zero-based. For the UI, the start page number from the header is added.</li><li>The text for the header and footer are stored in two separate records. They have the same format as pages.</li><li>geoWrite supports up to 63 inline images, each of which is stored in its own record, which is pointed to by the page that contains the image.</li></ul><p>In a properly closed geoWrite document, all page records are consecutive with no empty records in between, all image records are referenced by pages, pagination is consistent with the page height in the header, and the header and footer height values in the header correspond to the text in the header and footer records.</p><h3 id="text-format">Text Format</h3><p>The text is stored in ASCII format, that is, codes $20 through $7F are printable characters, and codes $00 through $1F are control codes. Of these, only the following are defined:</p><table><thead><tr><th> Code </th><th> Description </th></tr></thead><tbody><tr><td> $00 </td><td> No-Op </td></tr><tr><td> $09 </td><td> Tab </td></tr><tr><td> $0C </td><td> Page Break </td></tr><tr><td> $0D </td><td> Line Break </td></tr><tr><td> $10 </td><td> Graphics Escape </td></tr><tr><td> $11 </td><td> Ruler Escape </td></tr><tr><td> $17 </td><td> NewCardSet Escape </td></tr></tbody></table><p>The $00 character code specifies the end of the file. The graphics, ruler and NewCardSet escape codes indicate data structures that need a detailed description.</p><h4 id="newcardset-escape">NewCardSet Escape</h4><p>The NewCardSet structure encodes a change in font and style. It can appear anywhere in the document.</p><table><thead><tr><th>Offset</th><th> Size </th><th> Contents </th><th> Description </th></tr></thead><tbody><tr><td> 0 </td><td> Byte </td><td> Escape Code </td><td> Constant $17 (<code>ESC_NEWCARDSET</code>) </td></tr><tr><td> 1-2 </td><td> Word </td><td> Font ID </td><td> Encoded font and point size identifier </td></tr><tr><td> 3 </td><td> Byte </td><td> Style </td><td> Text style bitfield </td></tr></tbody></table><ul><li><a href="https://www.pagetable.com/?p=1436">GEOS Font IDs</a> are 16 bit values that encode the unique font identifier (0: system font, 1: University, 2: California, 3: Roma, …) in bits 6-15, and the point size in bits 0-5.</li><li>The style bitfield is defined as follows:</li></ul><table><thead><tr><th>Bit</th><th> Description </th></tr></thead><tbody><tr><td> 7 </td><td> Underline </td></tr><tr><td> 6 </td><td> Bold </td></tr><tr><td> 5 </td><td> Reverse </td></tr><tr><td> 4 </td><td> Italics </td></tr><tr><td> 3 </td><td> Outline </td></tr><tr><td> 2 </td><td> Superscript </td></tr><tr><td> 1 </td><td> Subscript </td></tr><tr><td> 0 </td><td> <em>Reserved</em> </td></tr></tbody></table><ul><li>All bits can be combined, except subscript with superscript.</li><li>All zero bits indicate plain text.</li></ul><h4 id="ruler-escape">Ruler Escape</h4><p>The ruler structure encodes a paragraph’s properties. It can appear only at the beginning of a new paragraph.</p><table><thead><tr><th>Offset </th><th> Type </th><th> Contents </th><th> Description </th></tr></thead><tbody><tr><td> 0 </td><td> Byte </td><td> Escape Code </td><td> Constant $11 (<code>ESC_RULER</code>) </td></tr><tr><td> 1-2 </td><td> Word </td><td> Left Margin </td><td> Left margin </td></tr><tr><td> 3-4 </td><td> Word </td><td> Right Margin </td><td> Right margin </td></tr><tr><td> 5-6 </td><td> Word </td><td> Tab Stop 0 </td><td> Position/type of tab stop 0 </td></tr><tr><td> 7-8 </td><td> Word </td><td> Tab Stop 1 </td><td> Position/type of tab stop 1 </td></tr><tr><td> 9-10 </td><td> Word </td><td> Tab Stop 2 </td><td> Position/type of tab stop 2 </td></tr><tr><td> 11-12 </td><td> Word </td><td> Tab Stop 3 </td><td> Position/type of tab stop 3 </td></tr><tr><td> 13-14 </td><td> Word </td><td> Tab Stop 4 </td><td> Position/type of tab stop 4 </td></tr><tr><td> 15-16 </td><td> Word </td><td> Tab Stop 5 </td><td> Position/type of tab stop 5 </td></tr><tr><td> 17-18 </td><td> Word </td><td> Tab Stop 6 </td><td> Position/type of tab stop 6 </td></tr><tr><td> 19-20 </td><td> Word </td><td> Tab Stop 7 </td><td> Position/type of tab stop 7 </td></tr><tr><td> 21-22 </td><td> Word </td><td> Paragraph Margin </td><td> Left margin of first line of paragraph </td></tr><tr><td> 23 </td><td> Byte </td><td> Spacing/Alignment </td><td> Line spacing and text alignment </td></tr><tr><td> 24 </td><td> Byte </td><td> Reserved </td><td> Reserved for text color </td></tr><tr><td> 25 </td><td> Byte </td><td> Reserved </td><td> Reserved </td></tr><tr><td> 26 </td><td> Byte </td><td> Reserved </td><td> Reserved </td></tr></tbody></table><ul><li>All sizes are in dots.</li><li>The left margin is less than the right margin, and the tab stops are in ascending order.</li><li>The most significant bit of each tab stop indicates whether it is a regular or a decimal tab stop. Decimal tab stops align the <a href="https://www.pagetable.com/?p=1460">decimal separator</a> to the tab stop.</li></ul><table><thead><tr><th>Bit 15</th><th> Description </th></tr></thead><tbody><tr><td> 0 </td><td> Regular tab stop </td></tr><tr><td> 1 </td><td> Decimal tab stop </td></tr></tbody></table><ul><li>Line spacing and alignment are encoded into a single byte:</li></ul><table><thead><tr><th>Bits 0-1</th><th> Description </th></tr></thead><tbody><tr><td> 0 </td><td> Left aligned </td></tr><tr><td> 1 </td><td> Centered </td></tr><tr><td> 2 </td><td> Right aligned </td></tr><tr><td> 3 </td><td> Justified </td></tr></tbody></table><table><thead><tr><th>Bits 2-3</th><th> Description </th></tr></thead><tbody><tr><td> 0 </td><td> 1.0 line spacing </td></tr><tr><td> 1 </td><td> 1.5 line spacing </td></tr><tr><td> 2 </td><td> 2.0 line spacing </td></tr></tbody></table><h4 id="graphics-escape">Graphics Escape</h4><p>The graphics escape is used to embed an image into the text. It can appear anywhere in the document, and is regarded as a paragraph of its own.</p><table><thead><tr><th>Offset</th><th> Type </th><th> Contents </th><th> Description </th></tr></thead><tbody><tr><td> 0 </td><td> Byte </td><td> Escape Code </td><td> Constant $10 (<code>ESC_GRAPHICS</code>) </td></tr><tr><td> 1 </td><td> Byte </td><td> Image Width </td><td> Width of image divided by 8 </td></tr><tr><td> 2-3 </td><td> Word </td><td> Image Height </td><td> Height of image </td></tr><tr><td> 4 </td><td> Byte </td><td> Record Number </td><td> Number of record containing image data </td></tr></tbody></table><ul><li>All sizes are in dots.</li><li>The width of the image has to be divisible by 8.</li><li>The record number of the image data is in the range of 64 through 126.</li></ul><h3 id="page-format">Page Format</h3><p>To divide the linear text into pages, it is not enough to just cut the file at the (hard or soft) page breaks. When navigating to a page, it would not be clear what the current font and paragraph style of the first character of the page should be. Therefore, every page starts with a header containing this information, repeating the font/style/ruler state from the end of the previous page:</p><table><thead><tr><th>Offset</th><th> Length </th><th> Contents </th><th> Description </th></tr></thead><tbody><tr><td> 0-26 </td><td> 27 Bytes </td><td> Ruler Data </td><td> Ruler data </td></tr><tr><td> 27-30</td><td> 4 Bytes </td><td> NewCardSet Data </td><td> Font/style data </td></tr><tr><td> 31 </td><td> </td><td> ASCII Text </td><td> Text of the document </td></tr></tbody></table><p>The ruler data and NewCardSet data include their respective escape codes (<code>ESC_RULER</code> = $11, <code>ESC_NEWCARDSET</code> = $17), which makes any page by itself legally formatted geoWrite text.</p><h2 id="memory-representation">Memory Representation</h2><p>The strategy of the editor is to basically keep a single page in RAM and editing there. This way, for most editing work, there is no need to access the disk.</p><p>The buffer in RAM is 7000 bytes in size and in the same format as a page on disk: The first bytes are the header (ruler, NewCardSet), and the remainder is the actual text data, which may include NewCardSet, ruler and graphics escapes.</p><p>When the user jumps to a page, the corresponding record is loaded into the buffer. And when a new page is added to the document, an empty page is created in the buffer.</p><p>But the buffer isn’t always exactly one page. The text in the buffer starts at a known page boundary in the document, and the start of the buffer is associated with a page number in the document on disk.</p><p>But the amount of text in the buffer may be more than fits on the current page: If the user enters some text in the middle of a page, it will be inserted at the corresponding place in the buffer. The text at the end of the buffer may technically belong to the next page, because when laying out the current page, it wouldn’t fit.</p><p>The buffer may also be less than the current page of the document: If the user deletes text from the middle of a page, then the data in the buffer may not fill the current page any more – what should show up at the very bottom of this page is actually stored in the following record.</p><h2 id="streaming">Streaming</h2><p>It is not a problem to have more text than fits the page in the buffer (as long as the data doesn’t overflow the available 7000 bytes – we’ll talk about that later). But if there is less than a page in the buffer, and the bottom of the page needs to be rendered onto the screen, the missing text needs to be loaded from the next record.</p><p>The whole next record is unlikely to fit into the remainder of the current buffer, so the memory management logic loads data from the following records at a block (256 byte) granularity.</p><p>Let’s look at the code that does this. When rendering the page for the screen or for printing, and during re-pagination, all code goes through the <code>getByteFromBuffer</code> function:</p><pre><code>getByteFromBuffer: CmpW pageEndPtr, r15 ; end reached? bcc @end ; yes ldy #0 lda (r15),y ; read byte rts</code></pre><p>The virtual register <code>r15</code> points to the next byte, and <code>pageEndPtr</code> points to the end of the data in the buffer. The interesting case here is reaching the end:</p><pre><code>@end: bit streamingMode bpl @skip [push r0 though r15] jsr streamBlock [pop r0 though r15] bra getByteFromBuffer ; try again @skip: lda #0 rts</code></pre><p>If <code>streamingMode</code> is false, the function just returns NULL bytes, indicating the end of the buffer. But in “streaming mode”, it calls <code>streamBlock</code> (not shown). On its first invocation, this function manually looks up the next record in the filesystem and loads the first block, appending it to the data in the buffer, basically extending the buffer by a single block from the next record. The <code>getByteFromBuffer</code> code now has more data that it can fetch.</p><p>On subsequent invocations, <code>streamBlock</code> will keep reading blocks from the record, and will also skip to the following records. With <code>streamingMode</code> enabled, <code>getByteFromBuffer</code> will effectively read bytes from the whole document linearly.</p><p>The ruler and NewCardSet escapes at the beginning of each record are redundant and not needed when concatenating the pages, so <code>streamBlock</code> skips them. All of this is completely transparent to the caller.</p><p>Let’s look at an example in practice: The document has two pages of text. The user is at the very top of the first page and deletes a few lines. Visually, a few lines from the second page should now show up at the bottom of the first page. But the editor does not care at this point, the buffer only contains the reduced data. And since the cursor is still at the top of the page (and vertically, only about one fifth of a page fits onto the screen), the text renderer for the screen won’t reach the end of the buffer when reading bytes. But once the user moves the cursor down to the end of the page, the text renderer’s calls to <code>getByteFromBuffer</code> will cause one or more blocks of the next record to be loaded into the buffer before the part can be shown that was previously on page 2.</p><p>Reading in blocks from subsequent pages is not just some temporary look-ahead: Even though the read-in blocks still exist on disk as part of the next record, geoWrite now regards the data as part of the buffer in memory and will disregard them when accessing the next record in the future.</p><h2 id="repagination">Repagination</h2><p>When adding text to or deleting text from the middle of a document, the document generally needs re-pagination at some point, that is, the document will be updated so that every record on disk contains exactly the text of the corresponding page. geoWrite does this lazily: As seen before, most editing within a page happens on the buffer in memory. The buffer usually only gets written back to disk when moving away from the current page, at which point the remainder if the document needs to be repaginated.</p><p>The same is true if the buffer overflows the available 7000 bytes: The document has to be repaginated from the current page on. Every record will only be filled with text for exactly one page, so when the record for the current page will be loaded again afterwards, it should be significantly below 7000 bytes.</p><h3 id="triggers">Triggers</h3><p>There are many other actions that trigger a repagination run, like:</p><ul><li>The page height changes because of switching printers or toggling NLQ printing mode.</li><li>The page width is changed from 480 to 640 dots. (geoWrite does not allow switching back.)</li><li>The “title page” setting is toggled. Since this toggles showing the header and footer on the first page, the height of this page that is usable for text changes.</li><li>The header or footer is edited, potentially changing their heights and changing the usable height of pages.</li><li>The search/replace function changes text on arbitrary pages.</li><li>The function <em>update</em> in the <em>file</em> menu explicitly updates the document on disk into a consistent state, which includes repagination.</li><li>The same is done when closing the document or quitting the app.</li></ul><p>In some cases, like writing back a page to disk or closing a document, only repagination of pages following the current one is necessary.</p><h3 id="basic-algorithm">Basic Algorithm</h3><p>The basic repagination algorithm looks like this:</p><ul><li>Read the first page into the buffer and enable <code>streamingMode</code> for <code>getByteFromBuffer</code>. Using this function, the whole (remaining) document can now be read as if it was one linear file.</li><li>Keep reading from the document until the text fills a page.</li><li>Write the current buffer up to this point (including the header) to the record on disk that corresponds to the current page.</li><li>Move the remaining data in the buffer up to the beginning. This data is the start of the next page.</li><li>Copy the current font, style and ruler state into buffer’s page header.</li><li>Repeat all of this until the end of the data is reached.</li></ul><h3 id="measuring-lines">Measuring Lines</h3><p>The core of pagination is the function that measures a line of text. Starting with the current pointer into the buffer, it reads and interprets bytes from the document, and returns the line’s width, height, baseline and a buffer pointer that points to the first character of the next line.</p><p>This function is also used for rendering a line on screen or for the printer: Before a line can be rendered, the baseline has to be calculated, so that different fonts on the same line are printed consistently. And the width of the line is necessary to center it, for example.</p><p>The following screenshot shows an example of mixed fonts in a single line, where it is necessary to gather the lowest baseline before starting to draw the text:</p><p><img src="docs/geowrite/geowrite_7_baseline.png" height="400" width="640" alt="" /></p><p>First, this function calculates the available width by subtracting the left margin from the right margin. For the first line of a paragraph, the “paragraph margin” will be used instead of the left margin. It then reads and interprets the document byte by byte.</p><p>If a graphics escape is encountered, the height of the image is returned as the line height, since images are always in their own paragraphs.</p><p>Otherwise, the function keeps adding up the widths of characters based on the current font, and keeps track of the maximum baseline offset and maximum font height.</p><p>A TAB character in the text requires some additional logic: A TAB will have the cursor jump to the next tab stop. To account for this, the measure line function increases the width of the line to reach the tab stop. In the following example, the two words are separated by a TAB character.</p><pre><code> tab stop |.............*.............. Hello World! /\/\/\/\ added width</code></pre><p>For decimal tab stops, it calculates the widths of all following text until the next decimal separator, and increases the width up to the tab stop minus the width of this text. In the following example, “84” is measured, and enough width is added so that the decimal separator is lined up with the tab stop.</p><pre><code> decimal tab stop |.............*.............. Total 84.25 EUR /\/\/\ added width</code></pre><p>If there is a ruler escape in the text, the ruler data gets copied into the app’s state. All further calculations will use the new margins and tab stops. The same happens for NewCardSet escapes: All further character size calculations will be based on the new font and style.</p><p>During repagination, the metrics of all fonts used in the particular part of the document need to be known to be able to add up character widths. The geoWrite <a href="https://www.pagetable.com/?p=1436">font manager</a> has a font metrics cache that can hold data for up to 8 fonts, which is more than the font data cache, which can only hold an average of 3 font images, depending on their size. The font files have to be loaded at least once in order to extract the metrics, but the images are not necessary for repagination, and it is enough to keep the metrics data.</p><p>The end of a line is reached once the text overflows the available width. The function will then reset the buffer pointer to after the last SPACE character – this is the first character of the new line.</p><p>The end of a line is also reached if there is either an explicit line break or page break in the text. In this case, the pointer will be set to the character after the break.</p><h3 id="measuring-pages">Measuring Pages</h3><p>The function that measures a page first calculates the usable height by subtracting the header and footer heights from the page height – unless this is the title page, in which the full page height is available.</p><p>It then repeatedly calls the function to measure a line and adds up line heights until the sum overflows the usable page height. The buffer pointer is reset to the beginning of the first line that does not fit onto the page. This is the first character of the next page.</p><p>A special case is the page break character: Page measuring is stopped here, and the pointer to the next character is returned.</p><h2 id="conclusion">Conclusion</h2><p>While geoWrite is extremely powerful for an app on a 1 MHz computer with 64 KB of RAM, it is also very slow. Some of the reasons are true for many GEOS applications:</p><ul><li>The 6502 cannot efficiently handle 16 bit data, so dealing with pointers and dot size values requires large and slow code everywhere.</li><li>Because of memory scarcity, code has to repeatedly be <a href="https://www.pagetable.com/?p=1425">paged in</a> for certain functionality.</li><li>Some of the code is especially inefficient, because it had to be optimized for size rather than for speed.</li><li>Even with the GEOS “turboDisk” driver, the 1541 disk drive is still very slow, at a maximum of 4 KB/sec of linear reading.</li></ul><p>In this context, geoWrite picked a document model that allows the user to edit a page at a time practically without any disk access, with the tradeoff of slower repagination. So in practice, repaginating a document that contains dozens of pages can take a minute or more, but on the other hand, geoWrite can usually keep up with the fastest typists when rendering even complicated text layouts in real-time.</p><p>P.S.: The image at the beginning of this article shows the error message caused by a record overflowing 7000 bytes. This happens when using a font that is 9 pt or smaller and filling a page completely with characters. geoWrite will insert a page break character and re-run the pagination code.</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1471</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>Inside geoWrite – 6: Localization</title> <link>https://www.pagetable.com/?p=1460</link> <comments>https://www.pagetable.com/?p=1460#comments</comments> <pubDate>Tue, 08 Sep 2020 22:18:51 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Archeology]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[GEOS]]></category> <category><![CDATA[Operating Systems]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1460</guid> <description><![CDATA[In the series about the internals of the geoWrite WYSIWYG text editor for the C64, this article discusses what was required for the German localization. Article Series The Overlay System Screen Recovery Font Management Zero Page Copy Protection Localization ← this article File Format and Pagination Copy & Paste Keyboard Handling Overview Localizing an app ... <a title="Inside geoWrite – 6: Localization" class="read-more" href="https://www.pagetable.com/?p=1460">Read more<span class="screen-reader-text">Inside geoWrite – 6: Localization</span></a>]]></description> <content:encoded><![CDATA[<p>In the series about the internals of the geoWrite WYSIWYG text editor for the C64, this article discusses what was required for the German localization.</p><p><img src="docs/geowrite/geowrite_6_localizaion.gif" height="400" width="640" alt="" /></p><h2 id="article-series">Article Series</h2><ol><li><a href="https://www.pagetable.com/?p=1425">The Overlay System</a></li><li><a href="https://www.pagetable.com/?p=1428">Screen Recovery</a></li><li><a href="https://www.pagetable.com/?p=1436">Font Management</a></li><li><a href="https://www.pagetable.com/?p=1442">Zero Page</a></li><li><a href="https://www.pagetable.com/?p=1449">Copy Protection</a></li><li><strong>Localization</strong> ← this article</li><li><a href="https://www.pagetable.com/?p=1471">File Format and Pagination</a></li><li><a href="https://www.pagetable.com/?p=1481">Copy & Paste</a></li><li><a href="https://www.pagetable.com/?p=1490">Keyboard Handling</a></li></ol><h2 id="overview">Overview</h2><p>Localizing an app doesn’t mean just translating all text. Language is just one part of it. Here are all concepts that require changes to geoWrite:</p><ul><li>Language</li><li>Date/time format</li><li>Number format</li><li>Character set</li></ul><p>Let’s go through them.</p><h2 id="language">Language</h2><p>Translating the app is not as easy as just translating all strings.</p><ul><li>Some strings must not be translated.</li><li>Not all text is part of the UI.</li><li>Not all text is in string form.</li></ul><h3 id="do-not-translate">Do Not Translate</h3><p>First, let’s look at what <strong>must not</strong> be translated:</p><pre><code>fn_textscrap: .byte "Text Scrap",0 fn_photoscrap: .byte "Photo Scrap",0</code></pre><p>These are magic filenames that contain the current clipboard/pasteboard contents. Translating them would break interoperability between apps in different languages.</p><h3 id="keywords">Keywords</h3><p>Then, there are strings where it is up to debate whether they should be translated: geoWrite supports three keywords that get replaced with dynamic contents when used in a page header or footer:</p><ul><li><code>DATE</code>: inserts the current date</li><li><code>TIME</code>: inserts the current time</li><li><code>PAGE</code>: inserts the current page number</li></ul><p>For the German version, these keywords were in fact translated: <code>DATUM</code>, <code>ZEIT</code>, <code>SEITE</code>.</p><h3 id="strings">Strings</h3><p>From the strings that should be translated, let’s start with the straightforward ones: Here is a table of strings that is used in menus:</p><p><img src="docs/geowrite/geowrite_6_diff0.png" height="189" width="671" alt="" /></p><p>Care has to be taken that the translated version fits the available space: The translations of “edit” and “options” were abbreviated (“Edit”/“Editieren”, “Opt”/“Optionen”), because the whole menu bar would have been too wide otherwise:</p><p><img src="docs/geowrite/geowrite_6_menubar.png" height="60" width="630" alt="" /></p><p>For submenus, GEOS programmers have to explicitly state the location and size in pixels, so the definition of a submenu has to change as well:</p><p><img src="docs/geowrite/geowrite_6_menu_en.png" height="400" width="640" alt="" /><br /><img src="docs/geowrite/geowrite_6_menu_de.png" height="400" width="640" alt="" /></p><p><img src="docs/geowrite/geowrite_6_diff0a.png" height="190" width="697" alt="" /></p><p>The German version is wider, so the value for the right border of the menu was updated.</p><p>Additionally, all menus in the German version are moved up by one pixel. If you look closely, you can see that the English version has a double line between “file” and “close”, while the German version has a single line. The symbol <code>MENU_HEIGHT</code> in the previous code block is 15 for the English version and 14 for the German version. It is unknown what the purpose of this is.</p><p>In the case of dialogs, the translated text might not fit into the same number of lines and might require a re-layout:</p><p><img src="docs/geowrite/geowrite_6_dialog1_en.png" height="400" width="640" alt="" /><br /><img src="docs/geowrite/geowrite_6_dialog1_de.png" height="400" width="640" alt="" /></p><p>So while the English version just consists of one line of text, the German version adds a <code>GOTOXY</code> control code to move the cursor to the second line:</p><p><img src="docs/geowrite/geowrite_6_diff1.png" height="111" width="669" alt="" /></p><p>Because of word order differences, the startup dialog needed a complete redesign…</p><p><img src="docs/geowrite/geowrite_6_dialog2_en.png" height="400" width="640" alt="" /><br /><img src="docs/geowrite/geowrite_6_dialog2_de.png" height="400" width="640" alt="" /></p><p>…which required changing the locations of all text and icons in the dialog’s definition:</p><p><img src="docs/geowrite/geowrite_6_diff2.png" height="399" width="668" alt="" /></p><h3 id="images">Images</h3><p>The startup dialog contains buttons that say “Create”, “Open” and “Quit”. GEOS only provides a limited set of predefined buttons (“OK”, “Cancel”, “Open”, …), so the pixel images of “Create” and “Quit” are supplied by the app and need to be translated as well.</p><p><img src="docs/geowrite/geowrite_6_buttons.png" height="66" width="226" alt="" /></p><p>The translated words are longer, so the buttons have to be bigger as well.</p><h3 id="screen-recovery-rectangles">Screen Recovery Rectangles</h3><p>As discussed in <a href="https://www.pagetable.com/?p=1428">part 1</a> of this series, GEOS uses a custom system to save and recover screen contents that get overwritten by menus and dialogs. Since the sizes and positions of the menus are different, the rectangles that need to be recovered are changed in their table as well:</p><p><img src="docs/geowrite/geowrite_6_diff3.png" height="514" width="653" alt="" /></p><h2 id="date/time-format">Date/Time Format</h2><p>Different cultures/languages use different conventions for the date and time format. The <code>DATE</code> and <code>TIME</code> keywords stamp the current date and time into a page’s header or footer. For the English version, it uses the US format for dates and times:</p><pre><code>December 31, 1999 11:59 PM</code></pre><p>For the German version, it uses the German format, with German month names:</p><pre><code>31. Dezember 1999 23:59</code></pre><p>This is the core function to create the date string:</p><pre><code> ; date LoadW r0, dateString .if DATE_FORMAT=DATE_FORMAT_US jsr getMonthName jsr getDay .elseif DATE_FORMAT=DATE_FORMAT_DE jsr getDay jsr getMonthName .endif jsr getYear</code></pre><p>The month and day are reversed in the two different formats. The “.” vs. the “,” after the day gets handled by the function <code>getDay</code>:</p><pre><code>getDay: MoveB day, r3L LoadB r3H, 0 jsr byteToDecimal ldy #0 .if DATE_FORMAT=DATE_FORMAT_US lda #',' .elseif DATE_FORMAT=DATE_FORMAT_DE lda #'.' .endif sta (r0),y IncW r0 lda #' ' sta (r0),y IncW r0 rts</code></pre><p>The function to create the time string has some extra logic to convert the hour (0-23) to the range (1-12):</p><pre><code> lda hour .if DATE_FORMAT=DATE_FORMAT_US ; AM/PM cmp #12 bcc :+ ; >= 12? sub #12 ; then subtract 12 : cmp #0 bne :+ ; == 0 lda #12 ; then it's 12 :.endif sta r3L LoadB r3H, 0 jsr byteToDecimal ; hours ldy #0 lda #':' sta (r0),y ; ':' IncW r0 lda minutes sta r3L LoadB r3H, 0 lda #1 jsr byteToDecimal ; minutes</code></pre><p>And at the end, there is extra code in the US version to add “AM” or “PM”:</p><pre><code> ldy #0 lda #' ' sta (r0),y ; space IncW r0 .if DATE_FORMAT=DATE_FORMAT_US ; AM/PM lda #'A' ldx hour cpx #12 bcc :+ lda #'P' : sta (r0),y IncW r0 lda #'M' sta (r0),y IncW r0 .endif</code></pre><h2 id="number-format">Number Format</h2><p>The character used for the decimal separator may differ between languages – “3.14” in an English text would be “3,14” in a German text. Since geoWrite supports “decimal” tab stops that align numbers around the decimal separator, it needs to scan for this character: The English version checks for “.”, while the German version checks for “,”.</p><h2 id="character-set-&-encoding">Character Set & Encoding</h2><p>The German language has four extra letters, the umlauts: “ä”/“Ä”, “ö”/“Ö”, “ü”/“Ü” and “ß”.</p><h3 id="geos-character-encoding">GEOS Character Encoding</h3><p>Until the advent of Unicode, operating systems used different character encodings for different languages or scripts.</p><p>The English version of GEOS uses the 7 bit ASCII encoding, which contains the 26 letters A through Z, but no umlauts. The GEOS KERNAL has no context of a character encoding, it just blindly draws glyphs that are stored at an index in a font – as long as the index is between 32 and 127, the 7-bit ASCII printable range. The only difference between the English and the German operating system in terms of character encoding are the fonts: Just like the regular fonts, the fonts that come with the German version have 96 characters, but some characters have been replaced by the extra umlauts and the ‘§’ character (important for legal documents). These are the variants of the system font “BSW/9”:</p><p><img src="docs/geowrite/bsw9.png" height="20" width="954" alt="" /><br /><img src="docs/geowrite/bsw9_de.png" height="20" width="960" alt="" /></p><table><thead><tr><th> ASCII </th><th> German GEOS </th></tr></thead><tbody><tr><td> @ </td><td> § </td></tr><tr><td> [ </td><td> Ä </td></tr><tr><td> \ </td><td> Ö </td></tr><tr><td> ] </td><td> Ü </td></tr><tr><td> { </td><td> ä </td></tr><tr><td> | </td><td> ö </td></tr><tr><td> } </td><td> ü </td></tr><tr><td> ~ </td><td> ß </td></tr></tbody></table><p>geoWrite doesn’t generally have to care about the encoding either: With the German font set, any version of geoWrite will display German umlauts.</p><p>There are two cases where it does have to care though: searching and printing.</p><h3 id="searching">Searching</h3><p>The function to search text has the option of searching for whole words only. For this, geoWrite needs to know which code points are letters or numbers. In English, that’s A through Z and 0 through 9. In German, this must include the umlauts. This is the function that decides on what’s an alphanumeric character:</p><pre><code>isAlphanumeric: cmp #'0' bcc @1 cmp #'9'+1 bcc @yes @1: .if CHAR_ENCODING=CHAR_ENCODING_ASCII cmp #'A' .elseif CHAR_ENCODING=CHAR_ENCODING_DE cmp #'@' .endif bcc @2 .if CHAR_ENCODING=CHAR_ENCODING_ASCII cmp #'Z'+1 .elseif CHAR_ENCODING=CHAR_ENCODING_DE cmp #']'+1 .endif bcc @yes @2: cmp #'a' bcc @3 .if CHAR_ENCODING=CHAR_ENCODING_ASCII cmp #'z'+1 .elseif CHAR_ENCODING=CHAR_ENCODING_DE cmp #'~'+1 .endif bcc @yes @3: cmp #'_' beq @yes clc rts @yes: sec rts</code></pre><p>With the German encoding, it includes the three characters after the uppercase ‘Z’ and the four characters after the lowercase ‘z’ (see image of font above). There is a bug in this code though: The German version considers “§” (“@” in the code above) an alphanumeric character, which it isn’t.</p><h3 id="printing">Printing</h3><p>The default is for geoWrite to print pixel images of the pages of a document. But there is also ASCII mode, which sends the plain text to the printer, so the printer can use its built-in fonts. In this mode, the English GEOS sends ASCII-encoded text, that is, its internal representation without any conversion, to the printer driver. If the printer uses a different encoding, the driver has to do the conversion.</p><p>German GEOS can’t just send the codes for “§ÄÖÜäöüß” – they would print as “@[]{|}~”. It has to convert them, so that printer drivers can be universal and independent of the system’s language.</p><p>This is the code that does the conversion – it is missing from the English version:</p><pre><code>convertToCp437: ldy #8 @loop: cmp @from-1,y beq @found dey bne @loop rts @found: lda @to-1,y rts @from: .byte '@','[','\',']','{','|','}','~' ; source: GEOS_de @to: .byte $EB,$8E,$99,$9A,$84,$94,$81,$E1 ; target: CP437 ; 'δ','Ä','Ö','Ü','ä','ö','ü','ß'</code></pre><p>The eight character codes in German GEOS that differ from ASCII (line <code>@from</code>) are converted to eight codes above 127 (line <code>@to</code>).</p><p>The destination encoding is <a href="https://en.wikipedia.org/wiki/Code_page_437">Codepage 437</a>, the standard (and now obsolete) encoding used by the IBM PC and MS-DOS. That is, except for ‘§’, whose CP437 equivalent would be $15, which is a non-printable character in ASCII-based encodings.</p><p>The authors of GEOS were free to choose any encoding – it’s really just a convention between applications and the printer drivers. But with CP437, drivers for PC printers of the time can just pipe the data through as is.</p><h2 id="discussion">Discussion</h2><p>Modern software usually comes as a single application binary that supports multiple languages, and with support from the operating system can use different conventions for date/time and numbers, and uses Unicode to express and work with any character in any script.</p><p>geoWrite is running on a 64 KB system and doesn’t have the luxury of spending code for any of these features – all localization differences are compile-time options. This means that in a multi-lingual environment, there are many limitations:</p><ul><li>The English version of geoWrite on a German version of GEOS will support umlauts, but can’t correctly search for words with umlauts or print umlauts in ASCII mode. Besides, some buttons in the UI will be in German.</li><li>The German version of geoWrite on an English version of GEOS will not support umlauts, and the characters “@[]{|}~” won’t print correctly in ASCII mode.</li><li>Writing an English document in the German version of geoWrite will use the German date/time format, use German month names, and can’t use decimal tab stops with with a ‘.’ as the decimal point.</li><li>Writing a German document in the English version of geoWrite (on a German GEOS) has the equivalent problems. In addition, searching for words with umlauts won’t work correctly, and neither will printing umlauts.</li><li>Writing a French or Spanish document with any version of geoWrite works, even with accented letters, as long as only fonts are used where the extra letters are added. But the same limitations with date/time, numbers, searching and printing apply.</li><li>Good luck with CJK and RTL!</li><li>Opening a document in a different language version of geoWrite than it was saved in will break either the umlauts or the “@[]{|}~” characters, as well as data, time and page numbers in headers and footers.</li></ul><p>Then again, it would be possible to architect a version of geoWrite with more flexibility:</p><ul><li>The code for date, time, numbers and the encoding only differs minimally between the localizations, so the app could support all variants, based on a system setting.</li><li>The VLIR architecture of GEOS applications allows dividing code and data into an arbitrary number of records, so every VLIR record of the current geoWrite app could be split into two: one with the code, and one with the strings and UI data structures. Which variant of the UI gets loaded depends on the system language.</li></ul><p>The latter point would of course waste space on disk (regular geoWrite is 35 KB, a 1541 disk holds 165 KB) and increase load times of VLIR records.</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1460</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item> <title>Inside geoWrite – 5: Copy Protection</title> <link>https://www.pagetable.com/?p=1449</link> <comments>https://www.pagetable.com/?p=1449#comments</comments> <pubDate>Sun, 06 Sep 2020 09:48:15 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Archeology]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Floppy Disks]]></category> <category><![CDATA[GEOS]]></category> <category><![CDATA[Operating Systems]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1449</guid> <description><![CDATA[In the series about the internals of the geoWrite WYSIWYG text editor for the C64, this article discusses the geoWrite copy protection. Article Series The Overlay System Screen Recovery Font Management Zero Page Copy Protection ← this article Localization File Format and Pagination Copy & Paste Keyboard Handling GEOS Copy Protection Strategy GEOS has one ... <a title="Inside geoWrite – 5: Copy Protection" class="read-more" href="https://www.pagetable.com/?p=1449">Read more<span class="screen-reader-text">Inside geoWrite – 5: Copy Protection</span></a>]]></description> <content:encoded><![CDATA[<p>In the series about the internals of the geoWrite WYSIWYG text editor for the C64, this article discusses the geoWrite copy protection.</p><p><img src="docs/geowrite/geowrite_5_wrong_serial.png" alt="" /></p><h2 id="article-series">Article Series</h2><ol><li><a href="https://www.pagetable.com/?p=1425">The Overlay System</a></li><li><a href="https://www.pagetable.com/?p=1428">Screen Recovery</a></li><li><a href="https://www.pagetable.com/?p=1436">Font Management</a></li><li><a href="https://www.pagetable.com/?p=1442">Zero Page</a></li><li><strong>Copy Protection</strong> ← this article</li><li><a href="https://www.pagetable.com/?p=1460">Localization</a></li><li><a href="https://www.pagetable.com/?p=1471">File Format and Pagination</a></li><li><a href="https://www.pagetable.com/?p=1481">Copy & Paste</a></li><li><a href="https://www.pagetable.com/?p=1490">Keyboard Handling</a></li></ol><h2 id="geos-copy-protection-strategy">GEOS Copy Protection Strategy</h2><p>GEOS has one of the most notorious copy protection systems. The system disk contains bit patterns that are very hard to reproduce on a stock disk drive. These are checked on every boot in obfuscated code that is used to decrypt the core operating system code. This way, copies of the GEOS boot disk will not boot. Therefore, GEOS always has to be booted from the original disk, so these would <a href="https://www.pagetable.com/?p=1118">break frequently</a>, which is why GEOS came with a second boot disk, and there was a program to get broken boot disks replaced once both failed.</p><p>GEOS maker Berkeley Softworks also created several high-profile GEOS applications like geoPublish and geoCalc, which came with a similar copy protection. Even the bundled apps geoWrite, geoSpell and geoMerge have the same protection.</p><p>But with apps, it’s more complicated: On a C64 system with a single disk drive, the app needs to be on the same disk as the document that is being worked on, and since it’s a non-starter to make the user edit all their documents on the original application disk, it needs to be possible to have a copy of the app working on the user’s work disk – and still prevent pirated copies of the app from running.</p><p>The idea is to link the boot disk and the application through a serial number. On the <a href="https://www.pagetable.com/?p=1140#Conclusion">very first boot</a>, the GEOS system picks a random 16 bit serial number (excluding zero) and stores it on the boot disk as well as on the backup disk – this is called “installing” GEOS. On the first start of a copy-protected application, it verifies that it’s running from the original disk, and if yes, it takes the system’s serial number and stores it – this is called “installing” an application. On subsequent boots, it does not check for the original disk any more, but it only runs if its stored serial number matches the system’s.</p><p>As long as the GEOS boot disk cannot be copied, two users (who both bought GEOS) will have different serial numbers, and installed apps from one user won’t work on a different user’s GEOS. And a copy of a not-yet-installed app will refuse to install itself, because it doesn’t run from an original disk.</p><h2 id="code">Code</h2><p>Apart from this basic protection concept, geoWrite obfuscates what’s going on by encrypting parts of the code, to make it hard to crack the protection.</p><p>Let’s walk through the components of the copy protection in the order of what happens on application startup.</p><h3 id="encrypted-record-1">Encrypted Record 1</h3><p>As discussed in <a href="https://www.pagetable.com/?p=1425">part 1</a> of this series, the GEOS “VLIR” binary consists of 9 so-called records, which are basically individual code files. Record 0 is the main program, and records 1 through 8 get swapped in and out of memory based on what functionality is needed.</p><p>When the application gets started, the first thing the record 0 code of geoWrite does is load record 1, which contains initialization code as well as the copy protection.</p><pre><code> lda #BANK_1 jsr loadCode</code></pre><p>All of record 1 is encrypted, so after loading, it decrypts it by XORing every byte with $DE.</p><pre><code> lda #$EB eor #$35 sta @2 LoadW r0, MEM_OVERLAY LoadW r1, -4000 ldy #0 @1: lda (r0),y @2 = * + 1 eor #$00 sta (r0),y IncW r0 IncW r1 bne @1</code></pre><p>The decryption constant of $DE gets constructed using $ED XOR $35, for which there is no good reason other than maybe making it harder to search for the value.</p><p>After decryption, execution is handed to the record 1 code:</p><pre><code> jmp MEM_OVERLAY</code></pre><h3 id="installation">Installation</h3><p>The first few instructions of record 1 do things in a way more complicated way than necessary, probably to deter any hackers from looking further:</p><pre><code>.,3244 A9 32 LDA #$32 .,3246 48 PHA .,3247 A9 54 LDA #$54 .,3249 48 PHA .,324A A9 3B LDA #$3B .,324C 85 21 STA $21 .,324E A9 6F LDA #$6F .,3250 85 20 STA $20 .,3252 6C 20 00 JMP ($0020)</code></pre><p>The source makes it clear what’s going on:</p><pre><code> lda #>(@continue-1) pha lda #<(@continue-1) pha LoadW r15, initApp jmp (r15) @continue:</code></pre><p>It pushes the address of the code following it as a return address (i.e. minus one) on the stack and jumps to <code>initApp</code> using a vector. This is just a convoluted way of calling <code>initApp</code> and continuing with the code below.</p><p><code>initApp</code> does some initialization and calls <code>checkSerialOrInstall</code>. This is the first part of it:</p><pre><code>checkSerialOrInstall: lda serial ora serial+1 ; does app have a serial? beq @install ; no, then install lda #<GetSerialNumber ldx #>GetSerialNumber jsr CallRoutine CmpW serial, r0 ; does the app serial match the system's? beq @rts ; yes, return lda #<txt_serial_mismatch ldy #>txt_serial_mismatch jsr showError ; no, tell the user jsr swap_userzp jmp EnterDeskTop ; and exit @rts: rts</code></pre><p>(For the meaning of <code>swap_userzp</code>, check out <a href="https://www.pagetable.com/?p=1442">part 4</a> of this series.)</p><p><img src="docs/geowrite/geowrite_5_wrong_serial.png" alt="" /></p><p><code>serial</code> is a 16 bit variable that is part of the record 1 code:</p><pre><code>serial: .word 0 ; not installed</code></pre><p>If it is zero, <code>checkSerialOrInstall</code> jumps to the install logic. Otherwise it gets the system’s serial. (It could just call the <code>GetSerialNumber</code> KERNAL API directly, but instead, it calls it by loading its address into registers and calling <code>CallRoutine</code>, so that a reverse engineer has a harder time finding the call.)</p><p>If the system’s serial number is the same, the function returns, and the application can start. If no, it shows an error and exits the app.</p><p>Let’s look at the installer code. First, it calls <code>executeDiskBlock</code>, which loads a block from disk and runs it:</p><pre><code>@install: protExecTrack = * + 1 lda #0 ; protection track (stamped in by build system) sta r1L protExecSector = * + 1 lda #0 ; protection sector (stamped in by build system) sta r1H jsr executeDiskBlock beqx @ok ; no error</code></pre><p>This block contains the code to verify that this is an original disk and not a copy. (We will discuss all of this in detail in the next section.) If <code>executeDiskBlock</code> returns with X != 0, this signals a failure, and and geoWrite exits:</p><pre><code> lda #<txt_copy_protection ; installing a non-original disk? ldy #>txt_copy_protection ; then show a non-informative message bra showErrorAndExit ; and exit to deskTop</code></pre><p><img src="docs/geowrite/geowrite_5_wrong_disk.png" alt="" /></p><p>Otherwise, the installer now knows that it’s an original disk, so it can stamp in the system’s serial into its own code. So after fetching the system’s serial again, it reads the block from disk that is supposed to contain the app’s serial. This block is part of the record 1 file.</p><pre><code>@ok: lda #<GetSerialNumber ldx #>GetSerialNumber jsr CallRoutine ; get OS serial number to put into app MoveW r0, serial LoadW r4, diskBlkBuf protSerialTrack = * + 1 lda #0 ; serial track (stamped in by build system) sta r1L protSerialSector = * + 1 lda #0 ; serial sector (stamped in by build system) sta r1H jsr _GetBlock ; read sector that contains code with serial bnex @ierror</code></pre><p>Note that the track and sector numbers point to the location of this very code on disk. The geoWrite build system creates a disk image with the app on it and stamps track and sector numbers in.</p><p>The serial has to be put at the correct location within the block and encrypted with the same XOR $DE that is used for decrypting all of record 1:</p><pre><code>@offset = (serial-CODE1) .mod 254 + 2 lda serial ; get serial low eor #$DE ; "encrypt" sta diskBlkBuf+@offset lda serial+1 ; get serial high eor #$DE ; "encrypt" sta diskBlkBuf+@offset+1</code></pre><p>The offset can be calculated by the assembler: It’s the offset of the serial in the current (record 1) code, modulus 254 (because blocks on disk are 254 bytes), plus 2 (number of header bytes at the start of each block).</p><pre><code> LoadW r4, diskBlkBuf jsr _PutBlock ; write back block beqx installOk cpx #WR_PR_ON beq @wperr @ierror: lda #<txt_error_installing ldy #>txt_error_installing bra showErrorAndExit @wperr: lda #<txt_install_write_protected ldy #>txt_install_write_protected showErrorAndExit: jsr showError jsr swap_userzp jmp EnterDeskTop</code></pre><p>Finally, the block is written back. If there was an error, a dialog is shown, and the app exits.</p><p>If installation was successful, the following code runs:</p><pre><code>installOk: asl serial ; cycle serial left to obfuscate rol serial+1 ; serial = serial[14..0,15] lda serial adc #0 sta serial jsr swap_userzp jsr GetDirHead ; read BAM block jsr swap_userzp MoveW serial, curDirHead+$BE ; store serial after "GEOS format V1.x" jsr swap_userzp jsr PutDirHead ; write BAM block jsr swap_userzp</code></pre><p>This writes a copy of the serial with the bits rotated into two unused bytes of the disk’s header block, track 18, sector 0.</p><p>The reason for this most probably had to do with ordering broken replacement disks: Once both the system and the backup disks didn’t boot any more, the user was supposed to send in both disks, and would get new disks in return, already installed with the same serial, so that existing apps would continue to function.</p><p>Side B of the system disk contains geoWrite, and side B of the backup disk contains geoMerge, both of which had to be installed – the manual explicitly instructs the user to open each app once. So after this, both boot disks contain the obfuscated but plaintext serial on track 18, sector 0, offset $BE of side B. This could then be used to create proper replacement disks. After all, sides A of both disks were broken.</p><p>Finally, it shows a success dialog and exits.</p><pre><code> lda #<txt_installed ldy #>txt_installed ; show success jsr showError jsr swap_userzp jmp EnterDeskTop ; and exit</code></pre><p><img src="docs/geowrite/geowrite_5_installed.png" alt="" /></p><h3 id="disk-signature-check">Disk Signature Check</h3><p>We skipped over <code>executeDiskBlock</code>, which was called by the installer. First, it initializes the disk:</p><pre><code>executeDiskBlock: PushW r1 jsr swap_userzp jsr NewDisk jsr swap_userzp PopW r1 bnex @rts ; I/O error -> fail</code></pre><p>Then it reads the block whose track and sector was passed in by the caller. It’s the location of the protection check code that was stamped in by the build system.</p><pre><code> LoadW r4, diskBlkBuf ; read block jsr _GetBlock bnex @rts ; I/O error -> fail</code></pre><p>The last byte of the block is a checksum which is the lower 8 bits of the sum of all payload bytes of the sector:</p><pre><code> lda #0 ldy #2 @loop: clc adc diskBlkBuf,y ; checksum bytes $02-$FE iny cpy #$FF bne @loop cmp diskBlkBuf+$FF ; checksum at offset $FF beq @ok ldx #$FF ; fail @rts: rts</code></pre><p>If the checksum matches, the block is run in place in the disk block buffer (<code>diskBlkBuf</code> at $8000):</p><pre><code>@ok: jsr swap_userzp jsr diskBlkBuf+2 ; execute block jsr swap_userzp rts</code></pre><p>The protection check block is not part of the VLIR file and not formally referenced anywhere. The build system just writes it to a random free block when it generates the final disk image. In fact, it writes another 6 unused decoy copies of the block.</p><p>This is the layout of this block:</p><pre><code>00: 00 ff block link pointer 4c 7a 80 jump at entry point ad 0f 18 48 29 df 8d 0f 18 20 16 10: 07 68 8d 0f 18 60 ba 86 49 a9 ee 8d 0c 1c a9 07 20: 85 33 a9 f5 85 32 a5 22 8d f5 07 20 10 f5 a0 02 30: 84 00 20 55 07 a2 10 d0 12 a0 00 20 55 07 a0 45 drive code 40: 20 55 07 20 64 07 a0 0a 20 55 07 20 64 07 ca d0 50: e8 e8 86 00 60 50 fe b8 ad 01 1c 88 d0 f7 60 ad 60: 01 1c b8 60 ac 00 1c 10 f6 50 f9 b8 ad 01 1c c9 70: 55 f0 f1 c9 67 f0 ed 68 68 60 ad e3 c1 85 03 ad 80: e2 c1 85 02 ad e1 c1 c9 4c f0 0c a0 00 b1 02 aa 90: c8 b1 02 85 03 86 02 a2 0a ac 89 84 b9 86 84 29 a0: bf c9 02 90 24 d0 57 a8 88 88 b1 02 c8 c9 20 d0 computer code b0: f9 b1 02 c8 c9 5c d0 f1 b1 02 c8 c9 c2 d0 e9 b1 c0: 02 c8 c9 20 d0 f9 88 d0 11 a0 ff c8 b1 02 c9 85 d0: d0 f9 c8 b1 02 c9 8b d0 f3 c8 a2 00 b1 02 9d f5 e0: 80 c8 e8 e0 06 d0 f5 20 14 c2 20 5c c2 a9 05 85 f0: 8b a2 07 86 8c 00 00 00 00 00 00 20 5f c2 60 d7 checksum</code></pre><p>The second half of the block is GEOS code that executes on the computer side, and the first part is code that runs on the disk drive. The drive code does the actual disk authenticity check. The job of the computer part is to get the disk drive to run the drive code, and receive the result.</p><h4 id="running-the-drive-code">Running the Drive Code</h4><p>GEOS comes with driver code for the 1541 and 1571 disk drives, which contains logic to upload code to the drive, execute it, and send commands, status messages and block data back and forth. The protection code reuses the driver to execute custom code and retrieve the result.</p><p>But the disk drivers don’t export this functionality as an API. Instead of adding this to the disk drivers as a private API, the authors of the protection chose to do some hacky stuff to get to these functions instead. This has the side effect of making it much harder to understand what is going on – which is a plus for protection code.</p><p>The computer part needs to call the private functions <code>sendExecuteWithTrkSec</code> and <code>getDOSError</code> in the driver. This is some code in the 1541 driver that calls both functions in sequence:</p><pre><code>__NewDisk: jsr EnterTurbo bnex NewDsk2 jsr ClearCache jsr InitForIO LoadB errCount, 0 NewDsk0: lda #>Drv_NewDisk sta $8C lda #<Drv_NewDisk sta $8B jsr SendExecuteWithTrkSec ; <------ jsr GetDOSError ; <------ beq NewDsk1</code></pre><p>The protection code scans the <code>__NewDisk</code> function for the <code>STA $8B</code> and steals the following two instructions.</p><p>It gets the pointer to the the function by looking at the GEOS KERNAL’s API jump table entry for the symbol <code>NewDisk</code>:</p><pre><code>start: lda NewDisk+2 ; find the code that is pointed sta r0H ; to by the NewDisk API lda NewDisk+1 ; by reading the operand of the sta r0L ; direct/indirect JMP at the lda NewDisk ; entry point cmp #$4C ; direct or indirect JMP? beq @direct ; direct, then we found the code</code></pre><p>If the KERNAL jumps directly to the driver code (opcode $4C), the two bytes after the API’s address point to the implementation. If it’s an indirect jump, it resolves the indirection:</p><pre><code> ldy #0 ; indirect jump, so lda (r0),y ; we need to read the vector tax iny lda (r0),y sta r0H ; and we have a pointer to the code stx r0L</code></pre><p>The 1541 and 1571 drivers differ slightly, so it checks which type of driver is running:</p><pre><code>@direct: ldx #STRUCT_MISMAT ; default error code: ldy curDrive lda driveType-8,y ; what kind of drive is this? and #$BF ; ignore the shadow bit (drive cache) cmp #$02 ; 2: 1571 bcc @is1541 ; less, then 1541! bne @rts ; not 1571, then return with error (X != 0)</code></pre><p>Let’s look at the 1541 code. (The 1571 is be similar.)</p><pre><code>@is1541: ldy #$FF @loop5: iny @loop6: lda (r0),y ; search for $85 $8B cmp #$85 ; (STA $8B) bne @loop5 ; in NewDisk code iny lda (r0),y cmp #$8B bne @loop6</code></pre><p>This looks for the <code>STA $8B</code> just before the two calls. It then appends the next two calls to the end of its own code:</p><pre><code> iny @cont: ldx #$00 @loop7: lda (r0),y ; extract 6 bytes sta @code,x ; copy into this code iny inx cpx #6 bne @loop7</code></pre><p>Finally, it enables the disk driver, and calls the two functions it extracted the pointers of to have the driver execute code at <code>checkProtection</code> in its own RAM and retrieve the status.</p><pre><code> jsr EnterTurbo jsr InitForIO lda #<checkProtection ; $0705 ptr in 1541 RAM sta $8B ; to execute ldx #>checkProtection ; (this sector is at $0700!) stx $8C @code: .byte 0,0,0 ; jsr SendExecuteWithTrkSec .byte 0,0,0 ; jsr GetDOSError jsr DoneWithIO @rts: rts</code></pre><p><code>checkProtection</code> is actually $0705, and points into the drive’s buffer at $0700-$07FF, which is where the block was read. So the drive code does not have to be uploaded from the computer – it was the last block read by the driver, and it guaranteed to be located at $0700.</p><h4 id="checking-for-the-gap-sequence">Checking for the Gap Sequence</h4><p>Tracks on a 1541-formatted disk contain the following sequence of structures for 17 to 21 sectors, depending on the track.</p><p><img src="docs/geosdiskerrors/1.png" height="64" width="600" alt="" /></p><p>A SYNC mark is followed by a sector header, and after a gap, there is another SYNC mark, followed by the sector’s data and another gap. This is repeated for the next sector.</p><p>The GEOS copy protection relies on the fact that the data in the gap, which is irrelevant for normal operation, cannot be reliably written to by stock drives. GEOS boot and application disks contain the following sequence of bytes there:</p><pre><code>55 55 55 67 55 55 55 67</code></pre><p>The purpose of the drive code is to test that the gap after both the header and the sector data contain only the values 0x55 and 0x67 for 16 consecutive sectors.</p><p>Before we look at the main program, let’s look at its two helpers. This is <code>skipBytes</code>. It just reads a certain number of bytes from disk and ignores them.</p><pre><code>skipBytes: bvc skipBytes ; wait for byte clv lda $1C01 ; read it dey bne skipBytes ; y times rts</code></pre><p>And this is <code>checkSignature</code>, which reads all bytes up to the next sync mark and makes sure that they are all either 0x55 or 0x67:</p><pre><code>checkSignature: ldy $1C00 ; if we found the SYNC mark, bpl @foundSync ; the check is ok and we're done bvc checkSignature ; wait until byte ready clv lda $1C01 ; get byte cmp #$55 beq checkSignature ; has to be either signature byte $55 cmp #$67 beq checkSignature ; or signature byte $67 pla ; magic not found pla ; -> return to main code rts ; (error code remains at "2") @foundSync: lda $1C01 ; read value clv rts</code></pre><p>If this enounters a gap byte other than 0x55 of 0x67, it pops the return address from the stack, which returns to the drive’s main code with an error.</p><p>The main code starts out with waiting until the read head passes the header of sector 0 of the current track and reading the header. It calls a function in the DOS ROM ($F510) for this:</p><pre><code> lda #>(buffer-$8000+$0700) sta $33 lda #<(buffer-$8000+$0700) sta $32 ; set pointer to track/sector for ROM call lda $22 ; current track number sta $07F5 ; (sector is 0) jsr $F510 ; ROM call: find and read block header</code></pre><p>There are two more bytes that are part of the header that haven’t been read yet (the “OFF” bytes), which have to be skipped:</p><pre><code> ldy #2 sty $00 ; set default error code 2: "READ ERROR" jsr skipBytes ; skip 2 bytes</code></pre><p>The next bytes to be read are now the sector header’s gap bytes.</p><p>The remainder of the code now iterates over 16 sectors, always skipping all header bytes and data bytes, and checking for 0x55 and 0x67 values in the gaps:</p><pre><code> ldx #16 bne @1 ; check 16 headers and sectors @loop: ldy #<$100 ; skip a total of jsr skipBytes ; 325 GCR bytes ldy #$45 ; = 260 data bytes jsr skipBytes ; = marker + full block + checksum + filler jsr checkSignature ; check signature after data block ldy #10 jsr skipBytes ; skip full header @1: jsr checkSignature ; check signature after header dex bne @loop ; repeat inx stx $00 ; set error code 1: "OK" rts</code></pre><p>If <code>checkSignature</code> never failed, a status code indicating success will be set, which the computer part of the protection code will fetch.</p><h3 id="encrypted-code-in-record-0">Encrypted Code in Record 0</h3><p>To make cracking the protection harder, there is one more component: Somewhere in the initialization code, record 1 checksums itself, and uses this checksum as a key to decrypt one function in record 0. So if someone was to crack the protection by changing any of the code in record 1, the checksum would be different, the one function in record 0 would be garbled, and the app would sooner or later crash.</p><p>First, the checksum code:</p><pre><code>decryptR00: LoadW r0, MEM_OVERLAY ; checksum code record #1 LoadW r1, CODE1_END-CODE1 LoadB r2L, 0 ldy #0 @loop1: lda (r0),y add r2L sta r2L IncW r0 ldx #r1 jsr Ddec bne @loop1</code></pre><p>It adds all bytes together and keeps the lowest 8 bits.</p><p>There are several bytes within the record 1 code that must not be part of the checksum though: The 2 bytes containing the serial number will change once the app is installed, and the value will be different on every user’s copy. So their values will be subtracted from the checksum again:</p><pre><code> lda r2L ; remove variable bytes from checksum sub serial sub serial+1</code></pre><p>Furthermore, the stamped-in track/sector pointers of the block with the signature check code and the block with the serial have to be excluded. This is because of the necessary order in the build process, which looks something like this:</p><ol><li>assemble the source of each record as well as the drive code block</li><li>encrypt record 1 with a constant of $DE</li><li>encrypt one function in record 0 with the checksum of the record 1 plaintext</li><li>write the whole geoWrite VLIR file to a disk image</li><li>write the drive code block to a free block on the disk image</li><li>stamp the track and sector of the drive code block into record 1 on the disk image</li><li>stamp the track and sector of the block that contains the serial into record 1 on the disk image</li></ol><p>Both track/sector pointers aren’t known until step 6 and 7, but they are part of the checksum in step 3. Therefore, they are also excluded:</p><pre><code> sub protExecTrack sub protExecSector sub protSerialTrack sub protSerialSector</code></pre><p>Now it can decrypt the one function in record 0:</p><pre><code> LoadW r0, r0_encrypted_start ; decrypt some code in record 0 LoadW r1, r0_encrypted_start-r0_encrypted_end ldy #0 @loop2: lda (r0),y eor r2L sta (r0),y IncW r0 IncW r1 bne @loop2 rts</code></pre><h2 id="discussion">Discussion</h2><p>While the geoWrite copy protection isn’t as complicated or quite as <a href="https://www.pagetable.com/?p=865">mean</a> as the one on the GEOS system disks, it is nevertheless effective, and requires quite some effort to be cracked.</p><p>Without disassembling through the geoWrite binary, a cracker could search the whole disk for code that looks like it’s checking for the protection. Any code running on the disk and reading bytes from the head manually is a candidate. This is easy to find by looking for <code>LDA $1C01</code>, which would reveal the block with the gap signature check. But it’s checksummed, and the cracker wouldn’t know the algorithm, the range or the location of the checksum unless they had disassembled record 1. Besides, they might change the wrong block by mistake because of the decoy copies of this block on the disk.</p><p>So any cracking attempt would require disassembling through the geoWrite code. It is quite straightforward to find the code to load and decrypt record 1, and record 1 can either be decrypted with a small script using the key found in the code, or by dumping the memory contents after decryption.</p><p>The first few bytes of record 1 are a simple but clever obfuscation with the chance that the cracker would miss the serial check and installation code. If they do find it, they now know the track and sector of the serial on disk, and the encryption key, so they could change the serial of an installed copy, or deinstall geoWrite on the original disk.</p><p>The holy grail would be a cracked version of geoWrite that didn’t care about the serial, so a cracker could just remove the call to <code>checkSerialOrInstall</code>. But this would alter the checksum of record 1, and break the decryption of the one function in record 0, so the app would sooner or later crash. So removing the call to <code>checkSerialOrInstall</code> would also require patching the decryption to take a fixed key instead.</p><h2 id="references">References</h2><ul><li>ZAK256: <a href="https://www.c64-wiki.de/wiki/GEOS-Kopierschutz">GEOS-Kopierschutz</a> (C64 Wiki)</li><li>Michael Steil: <a href="https://www.pagetable.com/?p=865">Copy Protection Traps in GEOS for C64</a></li><li>Michael Steil: <a href="https://www.pagetable.com/?p=1118">Why Do C64 GEOS Boot Disks Break?</a></li><li>Michael Steil: <a href="https://www.pagetable.com/?p=1140">Reconstructing the GEOS 2.0 (de) Master Images from a Pile of Broken Disks</a></li></ul>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1449</wfw:commentRss> <slash:comments>3</slash:comments> </item> <item> <title>Inside geoWrite – 4: Zero Page</title> <link>https://www.pagetable.com/?p=1442</link> <comments>https://www.pagetable.com/?p=1442#comments</comments> <pubDate>Fri, 04 Sep 2020 20:25:55 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Archeology]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[GEOS]]></category> <category><![CDATA[Operating Systems]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1442</guid> <description><![CDATA[In the series about the internals of the geoWrite WYSIWYG text editor for the C64, this article discusses how it makes maximum use of the scarce zero page space. Article Series The Overlay System Screen Recovery Font Management Zero Page ← this article Copy Protection Localization File Format and Pagination Copy & Paste Keyboard Handling ... <a title="Inside geoWrite – 4: Zero Page" class="read-more" href="https://www.pagetable.com/?p=1442">Read more<span class="screen-reader-text">Inside geoWrite – 4: Zero Page</span></a>]]></description> <content:encoded><![CDATA[<p>In the series about the internals of the geoWrite WYSIWYG text editor for the C64, this article discusses how it makes maximum use of the scarce zero page space.</p><h2 id="article-series">Article Series</h2><ol><li><a href="https://www.pagetable.com/?p=1425">The Overlay System</a></li><li><a href="https://www.pagetable.com/?p=1428">Screen Recovery</a></li><li><a href="https://www.pagetable.com/?p=1436">Font Management</a></li><li><strong>Zero Page</strong> ← this article</li><li><a href="https://www.pagetable.com/?p=1449">Copy Protection</a></li><li><a href="https://www.pagetable.com/?p=1460">Localization</a></li><li><a href="https://www.pagetable.com/?p=1471">File Format and Pagination</a></li><li><a href="https://www.pagetable.com/?p=1481">Copy & Paste</a></li><li><a href="https://www.pagetable.com/?p=1490">Keyboard Handling</a></li></ol><h2 id="geos-zero-page">GEOS Zero Page</h2><p>The MOS 6502 CPU has special encodings for addresses that fit in 8 bits: Instructions that read from or write to addresses $0000 to $00FF in memory are encoded in two instead of three bytes:</p><pre><code>a5 28 lda $28 ad 28 00 lda $0028 </code></pre><p>The two instructions have the same effect, but the first one is one byte shorter, and faster by one clock cycle.</p><p>Zero page space is scare and valuable, so it has to be used wisely. This is the GEOS zero page layout, roughly to scale:</p><pre><code>----------------------------------------- $0000 6510 CPU built-in I/O port ----------------------------------------- $0002 Virtual 16 bit registers r0-r15 ----------------------------------------- $0022 Used by GEOS system ----------------------------------------- $0040 Reserved for GEOS system ----------------------------------------- $0070 GEOS app space <<<<<<<< ----------------------------------------- $0080 Used by GEOS disk driver ----------------------------------------- $0090 Used by Commodore KERNAL ROM ----------------------------------------- $00FB GEOS app space <<<<<<<< -----------------------------------------</code></pre><p>GEOS designates only a total of 21 bytes to the application. 30 bytes are used by the GEOS KERNAL itself, and 48 bytes are reserved for future versions of GEOS, so these areas are off-limits. The biggest part, 107 bytes, is used by the Commodore KERNAL ROM.</p><h2 id="kernal-zero-page">KERNAL Zero Page</h2><p>The C64’s ROM consists of the 9 KB Microsoft BASIC interpreter and a 7 KB operating system: the <a href="https://www.pagetable.com/?p=926">Commodore KERNAL</a>. When the machine is in BASIC mode, the KERNAL ROM takes care of the keyboard, the screen, RS232, tape, disks and printers.</p><p>For the most part, GEOS does not use the KERNAL ROM at all: It comes with its own keyboard, screen and mouse drivers. With disk drives and printers, it’s more complicated.</p><p>Disk drives and printers are daisy-chained on the <a href="https://www.pagetable.com/?p=1135">Commodore Serial Bus</a>. Unfortunately, byte transmission with the original protocol is painfully slow, which is why most applications and games come with their own speeder code which uploads alternative transfer code to the disk drive. GEOS also uses its own disk speeder called diskTurbo.</p><p>diskTurbo only replaces the data transmission protocol though, not the <a href="https://www.pagetable.com/?p=1031">IEEE-488 TALK/LISTEN protocol</a>, which is needed to negotiate which device is talking on the bus at which time. So whenever GEOS switches between disk drives, it calls the original code in KERNAL. And printers don’t allow uploading code to replace the bus protocol at all, so GEOS uses the KERNAL for talking to the printer as well.</p><p>To keep the original KERNAL happy, GEOS doesn’t touch any of its zero page variables – which is quite generous, since the serial code only touches a small part of the $0090-$00FA area.</p><p>In addition, GEOS reserves 16 more bytes for use by the diskTurbo driver at $0080-$008F. The Commodore 1541 driver uses two bytes in this space, for example.</p><p>So effectively, almost the whole upper half of the zero page ($0080-$00FA) is blocked because the code to access disks and printers uses parts of it.</p><h2 id="geowrite">geoWrite</h2><p>Since the $0080+ area is only used by the system during disk and printer accesses, geoWrite can use it whenever it is not using the disk or the printer, as long as it restores its contents whenever it does need to use them.</p><p>It does this by swapping the 128 bytes in the zero page with a dedicated buffer. The area can now have one of two sets of contents: the geoWrite contents and the diskTurbo/KERNAL contents:</p><pre><code>----------------------------------------- $0000 6510 CPU built-in I/O port ----------------------------------------- $0002 Virtual 16 bit registers r0-r15 ----------------------------------------- $0022 Used by GEOS system ----------------------------------------- $0040 Reserved for GEOS system ----------------------------------------- $0070 geoWrite variables <<<<<<<< ----------------------------------------- ----------------------------------------- $0080 geoWrite variables <<<<<<<< $0080 Used by GEOS disk driver <<<<<<<< ----------------------------------------- <<<<<<<< $0090 Used by Commodore KERNAL ROM <<<<<<<< <<<<<<<< <<<<<<<< <<<<<<<< <<<<<<<< <<<<<<<< <-swapped-> <<<<<<<< <<<<<<<< <<<<<<<< <<<<<<<< <<<<<<<< <<<<<<<< <<<<<<<< ----------------------------------------- <<<<<<<< $00FB GEOS app space (unused) ----------------------------------------- -----------------------------------------</code></pre><p>This is the code that swaps the zero page area and the buffer:</p><pre><code>swap_userzp: php ; save all registers and flags pha txa pha tya pha ldx #$7F ; $7F..$00 @loop: ldy userzp,x ; load zp byte lda userzp_copy,x ; load buffer byte sta userzp,x ; store zp byte tya sta userzp_copy,x ; store buffer byte dex bpl @loop pla ; restore all registers and flags tay pla tax pla plp rts</code></pre><p>It saves all registers and flags, so it can easily be called from anywhere in the code without messing up any state. Here is an example of using it:</p><pre><code> LoadW r0, otherFnBuffer ; load argument jsr swap_userzp ; **swap** jsr OpenRecordFile ; call KERNAL disk API jsr swap_userzp ; **swap** lda #2 ; load argument jmp PointRecord ; load KERNAL API that does not access disk</code></pre><p>The <code>OpenRecordFile</code> API call accesses disk, so it’s surrounded by calls to <code>swap_userzp</code>. The geoWrite programmers were very aware of which API calls cause a disk access: The <code>PointRecord</code> API call is about file management as well, but it only updates data structures and does not access disk, so there is no need to swap the zero page.</p><p>For all of this to be correct</p><ul><li><code>swap_userzp</code> has to be called as the very first thing when the application launches.</li><li><code>swap_userzp</code> has to be called before exiting the app.</li><li><code>swap_userzp</code> has to be called for every API that may end up calling the disk driver, as well as all printer APIs.</li><li>calls to <code>swap_userzp</code> always need to be balanced.</li><li>zero page variables at $80+ cannot be accessed between the two <code>swap_userzp</code> invocations.</li></ul><p>Adding the two calls to every disk API call is prone to error, and bloats the code, so there are wrapper functions for the commonly used disk access APIs:</p><pre><code>_ReadFile: lda #ReadFile-GetBlock .byte $2C ; skip next _ReadByte: lda #ReadByte-GetBlock .byte $2C _CloseRecordFile: lda #CloseRecordFile-GetBlock .byte $2C _InsertRecord: lda #InsertRecord-GetBlock .byte $2C _DeleteRecord: lda #DeleteRecord-GetBlock .byte $2C _AppendRecord: lda #AppendRecord-GetBlock .byte $2C _UpdateRecordFile: lda #UpdateRecordFile-GetBlock .byte $2C _OpenDisk: lda #OpenDisk-GetBlock .byte $2C _FindFile: lda #FindFile-GetBlock .byte $2C _GetBlock: lda #GetBlock-GetBlock .byte $2C _PutBlock: lda #PutBlock-GetBlock add #<GetBlock sta @jmp+1 lda #0 adc #>GetBlock sta @jmp+2 jsr swap_userzp @jmp: jsr GetBlock jmp swap_userzp</code></pre><p>Each of the wrappers loads the offset of the specific API entry point from the <code>GetBlock</code> entry point, and the common code adds it to the <code>GetBlock</code> address, and uses self-modification to call the API – of course calling <code>swap_userzp</code> before and after.</p><p>These wrappers are in the record 0 code, so that any <a href="https://www.pagetable.com/?p=1425">overlay code</a> can call it as well.</p><h2 id="discussion">Discussion</h2><p>Like most of geoWrite’s tricks, this is a tradeoff. It gains 123 zero page locations, and its use speeds up the code by maybe a low two-digit percentage and saves maybe 1 KB of code space. On a slow and memory-constrained system like the C64, this is significant. On the other hand, the disk access code gets a bit more complicated (which is countered by the wrappers), and every back-and-forth swap takes about 6000 cycles. But in the context of a disk access, this is negligible.</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1442</wfw:commentRss> <slash:comments>2</slash:comments> </item> <item> <title>Inside geoWrite – 3: Font Management</title> <link>https://www.pagetable.com/?p=1436</link> <comments>https://www.pagetable.com/?p=1436#respond</comments> <pubDate>Thu, 03 Sep 2020 22:25:55 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Archeology]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[GEOS]]></category> <category><![CDATA[Operating Systems]]></category> <category><![CDATA[Uncategorized]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1436</guid> <description><![CDATA[In the series about the internals of the geoWrite WYSIWYG text editor for the C64, this article discusses the font manager’s system of caches for pixel fonts. Article Series The Overlay System Screen Recovery Font Management ← this article Zero Page Copy Protection Localization File Format and Pagination Copy & Paste Keyboard Handling GEOS Fonts ... <a title="Inside geoWrite – 3: Font Management" class="read-more" href="https://www.pagetable.com/?p=1436">Read more<span class="screen-reader-text">Inside geoWrite – 3: Font Management</span></a>]]></description> <content:encoded><![CDATA[<p>In the series about the internals of the geoWrite WYSIWYG text editor for the C64, this article discusses the font manager’s system of caches for pixel fonts.</p><p><img src="docs/geowrite/geowrite_3_fonts.gif" alt="" /></p><h2 id="article-series">Article Series</h2><ol><li><a href="https://www.pagetable.com/?p=1425">The Overlay System</a></li><li><a href="https://www.pagetable.com/?p=1428">Screen Recovery</a></li><li><strong>Font Management</strong> ← this article</li><li><a href="https://www.pagetable.com/?p=1442">Zero Page</a></li><li><a href="https://www.pagetable.com/?p=1449">Copy Protection</a></li><li><a href="https://www.pagetable.com/?p=1460">Localization</a></li><li><a href="https://www.pagetable.com/?p=1471">File Format and Pagination</a></li><li><a href="https://www.pagetable.com/?p=1481">Copy & Paste</a></li><li><a href="https://www.pagetable.com/?p=1490">Keyboard Handling</a></li></ol><h2 id="geos-fonts-overview">GEOS Fonts Overview</h2><p>The GEOS operating system contains a rendering library for pixel fonts of up to 63 pt, using its own font file format.</p><p>Like most GEOS files, fonts are <a href="https://www.pagetable.com/?p=1425#vlir-files">VLIR bundles</a> that contain one “sub-file” for every point size. This is “California”, which is available at 10, 12, 14 and 18 pt:</p><pre><code>California size \--- File Header 256 \--- 10 892 \--- 12 1114 \--- 14 1322 \--- 18 2110</code></pre><p>To use a font, an application has to explicitly load it into its own memory buffer and activate it using the <code>LoadCharSet</code> API:</p><pre><code> LoadW r0, otherFnBuffer jsr OpenRecordFile ; open font file lda #12 jsr PointRecord ; select 12 pt font LoadW r7, FONT_BUFFER LoadW r2, FONT_BUFFER_SIZE jsr ReadRecord ; read pixel font into memory jsr CloseRecordFile ; close font file LoadW r0, FONT_BUFFER jsr LoadCharSet ; activate font</code></pre><p>The 9 pt system font (called “BSW”) is always in memory and can be activated using <code>UseSystemFont</code>:</p><pre><code>jsr UseSystemFont</code></pre><p>As soon as a font is activated, it can be used for drawing text:</p><ul><li><code>Putchar</code> – draw a character</li><li><code>PutString</code> – draw a zero-terminated string of characters</li></ul><p>Font metrics are accessible through:</p><ul><li><code>curHeight</code> (global variable) – font height (in pixels)</li><li><code>baselineOffset</code> (global variable) – baseline offset (in pixels from top)</li><li><code>GetRealSize</code> – query width and height of a given character code</li></ul><p>All this API is very basic. The GEOS KERNAL does not help the application with:</p><ul><li>enumerating available fonts and sizes: the application has to find font files on disk and decode their metadata.</li><li>dynamically caching several fonts in memory: GEOS only knows about a single font at a time.</li><li>getting font metrics without loading the font data: the GEOS API for getting the metrics requires the font to be loaded and active.</li></ul><p>geoWrite implements all this on the application side.</p><h2 id="enumerating-fonts">Enumerating Fonts</h2><p>geoWrite’s “font” menu shows all available fonts and their point sizes:</p><p><img src="docs/geowrite/font_menu.png" alt="" /></p><p>To get this information, applications have to find font files on disk and extract it from their metadata.</p><p>A font file has a file type of <code>FONT</code>, and its file name is also the font’s name, so that’s what the application will show in the UI.</p><p>The API <code>FindFTypes</code> returns an array of file names matching a filename or type, so this is how geoWrite gets the (file) names of the fonts on disk:</p><pre><code> LoadW r6, fontNames LoadB r7L, FONT ; file type LoadB r7H, MAX_FONT_FILES LoadW r10, 0 ; no name filter jsr FindFTypes ; get font files lda #8 sub r7H ; number of files found sta numFontFiles</code></pre><p>(All code has been edited for readability.)</p><p>geoWrite also needs to get the available point sizes for each font, as well as the start track and sector of the data on disk and its size. This way, it can later load the data for a particular point size without having to read any extra metadata again.</p><p>In C notation, the data structure that it builds looks like this:</p><pre><code>struct { uint16_t font_id; uint16_t record_size; uint16_t start_ts; } disk_fonts[16][8];</code></pre><p>For each of the (up to) 8 font files, there are (up to) 16 point sizes, for each of which geoWrite collects the font ID, the record size and the start track and sector.</p><p>A font ID is a GEOS concept that allows applications to use numbers instead of font name strings. It is a 16 bit value that uniquely identifies the font and point size:</p><ul><li>The upper 10 bits are a unique ID assigned by Berkeley Softworks, e.g. 3 is a synonym “California”.</li><li>The lower 6 bits are the point size (0-63).</li></ul><p>This is the main function to extract the metadata of a font:</p><pre><code>;--------------------------------------------------------------- ; extractFontMetadata ;; Function: Read point sizes, track/sector pointers and data ; sizes for a font file from its file header ;; Pass: a font index (0-7) ; r0 font filename ;--------------------------------------------------------------- extractFontMetadata: pha MoveW r0, r6 jsr FindFile ; get file LoadW r9, dirEntryBuf jsr GetFHdrInfo ; read file header MoveW dirEntryBuf+OFF_DE_TR_SC, r1 jsr ldR4DiskBlkBuf jsr GetBlock ; read index block pla ; font index (0-7) asl a asl a asl a asl a ; * 16 tay ldx #0 @loop: jsr extractFontIdTrackSector jsr extractFontRecordSize iny iny inx inx cpx #FONTS_PER_FONTFILE bne @loop rts</code></pre><p>It opens each font file and reads its file header and index block. For every point size, it calls <code>extractFontIdTrackSector</code> and <code>extractFontRecordSize</code>.</p><p>Here is <code>extractFontIdTrackSector</code>:</p><pre><code>;--------------------------------------------------------------- ; extractFontIdTrackSector ;; Function: Copy a point size ID and its track/sector pointer ; from the font file header and the index block ; into the app's data structures. ;; Pass: x font index within font file (0-15) ; y fontfile * 16 + fontindex * 2 ;--------------------------------------------------------------- extractFontIdTrackSector: lda fileHeader+OFF_GHPOINT_SIZES,x sta diskFontIds,y and #FONT_SIZE_MASK sta r6L ; point size lda fileHeader+OFF_GHPOINT_SIZES+1,x sta diskFontIds+1,y ora diskFontIds,y beq @rts ; skip empty records txa pha lda r6L ; point size asl a tax lda diskBlkBuf+2,x ; track sta diskFontRecordTrackSector,y lda diskBlkBuf+3,x ; sector sta diskFontRecordTrackSector+1,y pla tax @rts: rts</code></pre><p>A font’s file header contains 16 words at offset OFF_GHPOINT_SIZES that contain font IDs of the different point sizes, which this code copies into its internal data structure. It takes the start track and sectors for each point size from the VLIR index sector.</p><p>And this is <code>extractFontRecordSize</code>:</p><pre><code>;--------------------------------------------------------------- ; extractFontRecordSize ;; Function: Copy a font's data size from the font file header ; into the app's data structures. ;; Pass: x font index within file (0-15) ; y fontfile * 16 + fontindex * 2 ;--------------------------------------------------------------- extractFontRecordSize: lda fileHeader+OFF_GHSET_LENGTHS,x sta diskFontRecordSize,y sta r2L lda fileHeader+OFF_GHSET_LENGTHS+1,x sta diskFontRecordSize+1,y sta r2H CmpWI r2, MEM_SIZE_FONTS ; data size too big? bcc @rts beq @rts lda #0 sta diskFontRecordTrackSector,y ; then pretend it doesn't exist @rts: rts</code></pre><p>Similarly, it extracts the data size for each point size.</p><h2 id="caching-font-data">Caching Font Data</h2><p>geoWrite can keep up to 8 fonts in memory at the same time and dynamically allocates space for fonts in a 7000 byte buffer.</p><p>Fonts are managed with an LRU strategy, meaning that if a new font is supposed to be loaded that wouldn’t fit, the least recently used font will be removed from memory.</p><p>The font buffer contains one font immediately after the other: If a font is removed, fonts at higher addresses are moved down to fill the hole. This way, the free space is always at the end and there is no fragmentation.</p><p>These are the data structures in C notation:</p><pre><code>uint8_t buffer[7000]; struct { uint16_t font_id; uint16_t data_ptr; uint16_t data_size; uint16_t lru; } loaded_fonts[8];</code></pre><p>For every loaded font, geoWrite keeps track of its font ID, the pointer to the data in the buffer, the size in the buffer, and its LRU ID.</p><p>The main API of the font library is the call <code>setFontFromFile</code>, which allows the application to ask the library to activate a font given its ID. If it’s not already in memory, it will be loaded into the buffer, and if necessary, one or more previously used fonts will be removed from memory.</p><p>This is the first part of the function:</p><pre><code>;--------------------------------------------------------------- ; setFontFromFile ;; Function: Set font. If necessary, load from disk and cache it. ;; Pass: r1 font ID ;; Return: c =0: success ; =1: fail, system font was loaded instead ;--------------------------------------------------------------- setFontFromFile: CmpW r1, curFont bne @find clc rts @find: jsr findLoadedFont ; is it already loaded? bcs @load ; not found jsr updateloadedFontLruId ; mark it as the latest one that was used lda loadedFontPtrsHi,x sta r0H lda loadedFontPtrsLo,x sta r0L jsr LoadCharSet ; switch to it MoveW r1, curFont clc rts</code></pre><p>If the requested font is the currently active font, the function does nothing. Otherwise, it checks whether the font is already loaded into memory, and if yes, it just activates it and returns.</p><p>This is the implementation of <code>findLoadedFont</code>:</p><pre><code>;--------------------------------------------------------------- ; findLoadedFont ;; Function: Search for font in font buffer. ;; Pass: r1 font ID ;; Return: c =0: found ; x index ;--------------------------------------------------------------- findLoadedFont: ldx #0 @loop: cpx loadedFontsCount beq @notfound lda loadedFontIdsLo,x cmp r1L bne @1 lda loadedFontIdsHi,x cmp r1H beq @found @1: inx bra @loop @notfound: sec ; failure rts @found: clc ; success rts</code></pre><p>It scans the array of loaded font IDs. If the ID is found, the index to be used with the data structures is returned in X.</p><p>If the font ID is not currently loaded into memory, <code>setFontFromFile</code> will load it:</p><pre><code>;--------------------------------------------------------------- ; setFontFromFile ; (continued) ;--------------------------------------------------------------- @load: jsr findFontIdOnDisk ; does the font exist on disk? bcs useSystemFont ; no, quietly use system font instead lda diskFontRecordTrackSector,x ; does point size exist? beq useSystemFont ; no, quietly use system font instead txa pha lda diskFontRecordSize,x ; r3 = size of font data sta r3L lda diskFontRecordSize+1,x sta r3H jsr allocateFontBufferSpace ; kick out least recently used font(s) if needed jsr updateloadedFontLruId ; mark it as the latest one that was used lda r1L sta loadedFontIdsLo,x ; save the ID in the table so the font lda r1H ; can be found in RAM again sta loadedFontIdsHi,x lda loadedFontPtrsHi,x ; r7 = allocated location in RAM sta r7H lda loadedFontPtrsLo,x sta r7L pla tax PushW r1 ; save ID PushW r7 ; save RAM location lda diskFontRecordTrackSector,x; location on disk sta r1L lda diskFontRecordTrackSector+1,x sta r1H LoadW r2, MEM_SIZE_FONTS ; maximum file size jsr setDevice jsr ReadFile ; load font data into font buffer PopW r0 ; read RAM location into r0 PopW curFont ; read ID into curFont cpx #0 bne useSystemFont ; read error jsr LoadCharSet clc ; success rts useSystemFont: jsr UseSystemFont LoadW curFont, SYSTEM_FONT_ID sec ; fail: it's not the font we wanted rts</code></pre><p>It calls <code>findFontIdOnDisk</code> (not shown) to check whether the information about the available fonts and point sizes on disk contains the requested font ID.</p><p>If the ID is found, <code>setFontFromFile</code> calls <code>allocateFontBufferSpace</code> with the required data size to make space for the font in the buffer, and loads it using <code>ReadFile</code> and the track and sector pointer. If anything goes wrong, the system font is activated instead.</p><p>This is <code>allocateFontBufferSpace</code>:</p><pre><code>;--------------------------------------------------------------- ; allocateFontBufferSpace ;; Function: Allocate buffer space for a new font. ;; Pass: r3 size of font data ;; Note: This function cannot fail: It will remove fonts ; using an LRU strategy until there is space. ;--------------------------------------------------------------- allocateFontBufferSpace: ldx loadedFontsCount ; no fonts loaded? beq @first ; then load it to start of buffer cpx #MAX_FONTS_LOADED beq @remove ; too many fonts loaded, remove one lda loadedFontPtrsLo-1,x ; check for r3 bytes of spaces in font buffer clc ; (last font pointer + last font size + required size) adc loadedfontDataSizeLo-1,x tay lda loadedFontPtrsHi-1,x adc loadedfontDataSizeHi-1,x tax tya add r3L tay txa adc r3H cmp #>MEM_SCRRECV bne :+ cpy #<MEM_SCRRECV : bcc @add ; it fits beq @add @remove: PushW r1 ; does not fit jsr unloadLruFont ; remove one PopW r1 bra allocateFontBufferSpace ; try again @first: lda #>MEM_FONT ; load first font to start ldy #<MEM_FONT ; of font buffer bra @set @add: ldx loadedFontsCount ; new ptr = last ptr + size lda loadedFontPtrsLo-1,x clc adc loadedfontDataSizeLo-1,x tay lda loadedFontPtrsHi-1,x adc loadedfontDataSizeHi-1,x @set: ldx loadedFontsCount sta loadedFontPtrsHi,x ; store new ptr tya sta loadedFontPtrsLo,x lda r3L sta loadedfontDataSizeLo,x ; new size lda r3H sta loadedfontDataSizeHi,x inc loadedFontsCount ; one font more rts</code></pre><p>If the new font does not fit into the empty space at the end of the buffer, this function keeps calling <code>unloadLruFont</code> until there is enough space. It then fills the data pointer and size fields for the new font and increments the number of currently loaded fonts.</p><p><code>unloadLruFont</code> is used to make space:</p><pre><code>;--------------------------------------------------------------- ; unloadLruFont ;; Function: Unload the least recently used font and compress ; the font buffer. ;--------------------------------------------------------------- unloadLruFont: ; find lowest LRU ID ldy #0 ; candidate for lowest ldx #1 @loop1: cpx loadedFontsCount beq @end1 ; done iterating lda loadedFontLruIdHi,x cmp loadedFontLruIdHi,y bne @1 lda loadedFontLruIdLo,x cmp loadedFontLruIdLo,y @1: bcs @2 txa ; current one is lower tay ; -> update candidate @2: inx bra @loop1 @end1: tya tax ; lowest index to X @loop2: inx cpx loadedFontsCount ; is it the last one? beq @end2 ; then we're done dex lda loadedfontDataSizeHi+1,x; count: size of the one after sta r2H lda loadedfontDataSizeLo+1,x sta r2L lda loadedFontPtrsHi+1,x ; source: address of the one after sta r0H lda loadedFontPtrsLo+1,x sta r0L lda loadedFontPtrsHi,x ; target: address of the current one sta r1H lda loadedFontPtrsLo,x sta r1L txa pha jsr MoveData ; move the next font down pla tax lda loadedFontIdsLo+1,x ; move loadedFontIds sta loadedFontIdsLo,x lda loadedFontIdsHi+1,x sta loadedFontIdsHi,x lda loadedFontLruIdLo+1,x ; move FontLru sta loadedFontLruIdLo,x lda loadedFontLruIdHi+1,x sta loadedFontLruIdHi,x lda loadedfontDataSizeLo+1,x sta loadedfontDataSizeLo,x ; move loadedfontDataSize clc adc loadedFontPtrsLo,x ; update fontPtrs sta loadedFontPtrsLo+1,x lda loadedfontDataSizeHi+1,x sta loadedfontDataSizeHi,x adc loadedFontPtrsHi,x sta loadedFontPtrsHi+1,x inx bra @loop2 ; repeat for all fonts above removed one @end2: dec loadedFontsCount rts</code></pre><p>It finds the lowest LRU ID, i.e. the least recently used font, moves all fonts at higher addresses (and their pointers) down, and decrements the number of loaded fonts.</p><p>To keep track of which font is least recently used, <code>updateLoadedFontLruId</code> is called on load and on every activation of a font:</p><pre><code>;--------------------------------------------------------------- ; updateLoadedFontLruId ;; Function: Mark a given font as most recently used. ;; Pass: x font index ;--------------------------------------------------------------- updateLoadedFontLruId: lda fontLruCounter sta loadedFontLruIdLo,x lda fontLruCounter+1 sta loadedFontLruIdHi,x IncW fontLruCounter bne @rts ; 16 bit overflow: clear LRU ID for all fonts ldy #0 tya @loop: sta loadedFontLruIdLo,y sta loadedFontLruIdHi,y iny cpy loadedFontsCount bne @loop @rts: rts</code></pre><p>It keeps assigning the next number of a sequence to the given font, guaranteeing that it will always be the highest number and therefore the last one to be removed.</p><h2 id="caching-metrics">Caching Metrics</h2><p>When a word processor is dealing with fonts, it does not always need the actual image data for it. Sometimes the fonts metrics are enough, i.e. the height of the font, the baseline offset and the width of the different characters. This is true when selecting text, for example, to know where the character boundaries are, or when reflowing a document.</p><p>Caching font data is expensive; the 7000 bytes of geoWrite can hold five 12pt fonts, but only two 24pt fonts. Caching metrics is cheap: The character widths take up only 96 bytes per point size (for the printable ASCII character codes $20-$7F).</p><p>geoWrite therefore has an independent cache for font metrics that holds information about the last 8 loaded fonts.</p><p>The data structure looks like this:</p><pre><code>struct { uint16_t font_id; uint8_t height; uint8_t baseline_offset; uint8_t widths[96]; } metrics[8];</code></pre><p>So if the application wants to draw characters, it has to call <code>setFontFromFile</code>, which will make sure the pixel data is in memory and activated, but if it only needs the font for measuring, it should call <code>lookupFontMetrics</code> instead:</p><pre><code>;--------------------------------------------------------------- ; lookupFontMetrics ;; Function: Prepare cached font metrics for use. ;; Pass: a3 font ID ;--------------------------------------------------------------- lookupFontMetrics: ldx #0 ; find font id in metricsIds @loop: lda metricsIds,x tay ora metricsIds+8,x beq @nfound cpy a3L bne @no lda metricsIds+8,x cmp a3H beq @found @no: inx cpx #MAX_FONTS_LOADED bne @loop jsr getMod8Index ; not found in metrics cache @nfound: PushB r1H jsr moveA3R1 ; r1 = font id txa pha jsr setFontFromFile ; set font pla tax ; mod8 index PopB r1H lda a3L ; store font id in metricsIds sta metricsIds,x lda a3H sta metricsIds+8,x lda curHeight ; store height in table sta metricsHeights,x lda baselineOffset sta metricsBaselineOffsets,x jsr getCachedFontMetrics jsr calcCharWidths rts @found: jmp getCachedFontMetrics ; ---------------------------------------------------------------------------- getCachedFontMetrics: [...] sta metricsWidths [...] sta metricsWidths+1 lda metricsHeights,x sta curFontHeight lda metricsBaselineOffsets,x sta curBaselineOffset rts</code></pre><p>If the metrics for the requested font and point size are in the cache, they will be copied into <code>curFontHeight</code>, <code>curBaselineOffset</code> and the array <code>metricsWidths</code>. Otherwise, the font’s pixel data is loaded and the metrics are added to the cache using <code>calcCharWidths</code> (not shown).</p><p>To get the width of a character after metrics have been looked up, the app can now call <code>getCharWidth</code>:</p><pre><code>;--------------------------------------------------------------- ; getCharWidth ;; Function: Get the width of a specified char of the currently ; active metrics set (-> lookupFontMetrics). ;; Pass: a character ; x currentMode ;; Return: a width ;--------------------------------------------------------------- getCharWidth: sub #$20 ; ASCII -> table index pha MoveW metricsWidths, r14 pla tay lda (r14),y ; width sta metricsTmp txa ; mode and #SET_BOLD beq :+ inc metricsTmp ; add one : txa and #SET_OUTLINE beq :+ inc metricsTmp ; add 3 inc metricsTmp : lda metricsTmp rts</code></pre><p>This is basically a reimplementation of the GEOS KERNAL’s <code>GetRealSize</code> API: If the current font style is bold or outline, the width is increased by one or three pixels, respectively.</p><h2 id="conclusion">Conclusion</h2><p>One goal of a modern operating system and even of many kinds of libraries is to abstract what is going on underneath it. GEOS is a very constrained operating system with only 64 KB of total RAM at its disposal, so it tries to provide as many useful functions as possible (graphics, text rendering, disk access, mouse, printer, …) that fit into 20 KB of code, but in many parts of the system, it barely abstracts the underlying hardware.</p><p>GEOS applications are seen as as the natural extension of the operating system, and many features that did not fit into the operating system were implemented in the applications, with full awareness of the details of the filesystem or the file formats of system files.</p><p>The GEOS font manager can be regarded as a low-level system library, which deals with the internals of the BAM/VLIR filesystem and the font file format.</p><h2 id="references">References</h2><ul><li>Michael Farr: <a href="https://archive.org/details/The_Official_GEOS_Programmers_Reference_Guide">The Official GEOS Programmer’s Reference Guide</a></li><li>Berkeley Softworks: <a href="https://archive.org/details/The_Hitchhikers_Guide_to_GEOS">The Hitchhiker’s Guide to GEOS</a></li><li>Berkeley Softworks: <a href="https://archive.org/details/GEOProgrammer_Users_Manual">geoProgrammer User’s Manual</a></li><li>Rebecca G. Bettencourt: <a href="https://github.com/kreativekorp/bitsnpicas/wiki/GEOS-Font-Format">GEOS Font Format</a></li><li>Glenn Holmer: <a href="https://www.lyonlabs.org/commodore/onrequest/geos/geos-fonts.html">GEOS Fonts</a></li><li><a href="https://github.com/mist64/geos">GEOS Source Code</a></li></ul>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1436</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>Inside geoWrite – 2: Screen Recovery</title> <link>https://www.pagetable.com/?p=1428</link> <comments>https://www.pagetable.com/?p=1428#comments</comments> <pubDate>Wed, 02 Sep 2020 21:46:43 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Archeology]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[GEOS]]></category> <category><![CDATA[Operating Systems]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1428</guid> <description><![CDATA[In the series about the internals of the geoWrite WYSIWYG text editor for the C64, this article discusses how the app manages to extend its usable RAM by 5 KB using a custom screen recovery solution. Article Series The Overlay System Screen Recovery ← this article Font Management Zero Page Copy Protection Localization File Format ... <a title="Inside geoWrite – 2: Screen Recovery" class="read-more" href="https://www.pagetable.com/?p=1428">Read more<span class="screen-reader-text">Inside geoWrite – 2: Screen Recovery</span></a>]]></description> <content:encoded><![CDATA[<p>In the series about the internals of the geoWrite WYSIWYG text editor for the C64, this article discusses how the app manages to extend its usable RAM by 5 KB using a custom screen recovery solution.</p><p><img src="docs/geowrite/geowrite_2_scrrecovery.gif" alt="" /></p><h2 id="article-series">Article Series</h2><ol><li><a href="https://www.pagetable.com/?p=1425">The Overlay System</a></li><li><strong>Screen Recovery</strong> ← this article</li><li><a href="https://www.pagetable.com/?p=1436">Font Management</a></li><li><a href="https://www.pagetable.com/?p=1442">Zero Page</a></li><li><a href="https://www.pagetable.com/?p=1449">Copy Protection</a></li><li><a href="https://www.pagetable.com/?p=1460">Localization</a></li><li><a href="https://www.pagetable.com/?p=1471">File Format and Pagination</a></li><li><a href="https://www.pagetable.com/?p=1481">Copy & Paste</a></li><li><a href="https://www.pagetable.com/?p=1490">Keyboard Handling</a></li></ol><h2 id="screen-recovery">Screen Recovery</h2><p>Any graphical user interface that allows overlapping items has to deal with the problem of recovery: When dialogs and pull-down menus are shown, they cover parts of the screen, and when they are dismissed, the underlying UI needs to be revealed again.</p><p>There are two basic approaches to this:</p><ol><li><p>When the dialog or menu is dismissed, the system calls the same text or image rendering code again that drew it in the first place.</p></li><li><p>Before the dialog or menu is drawn, the system saves the pixel data that will be overwritten, and after the item is dismissed, the saved pixels get written back onto the screen.</p></li></ol><p>The latter solution requires additional memory, but is a lot faster and doesn’t create a potentially jarring redraw.</p><h2 id="screen-recovery-in-geos">Screen Recovery in GEOS</h2><p>GEOS uses the “restore the pixel data” approach, but with a twist.</p><p>Let’s look at the GEOS memory layout again:</p><pre><code>----------------------------------------- $0000 Zero page, stack, system variables ----------------------------------------- $0400 Application memory ----------------------------------------- $6000 Background bitmap ----------------------------------------- $8000 System buffers and variables ----------------------------------------- $9000 Disk driver ----------------------------------------- $A000 Screen bitmap ----------------------------------------- $C000 GEOS KERNAL -----------------------------------------</code></pre><p>The 8 KB of 320×200 monochrome bitmap data resides at $A000-$BF40. In addition, GEOS statically reserves a whole 8 KB just for screen recovery: The “background bitmap” at $6000-$7F40 allows GEOS to recover the whole screen area.</p><h3 id=" imprint-and-recover"> Imprint and Recover</h3><p>This background bitmap is really just another (invisible) framebuffer with the same layout as the actual screen bitmap. When saving pixels, they get copied from the screen (“foreground”) bitmap to the same offset in the background bitmap and vice versa.</p><p>These two functions are the core of the API:</p><ul><li><code>ImprintRectangle</code> – copy rectangle from fg bitmap to bg bitmap</li><li><code>RecoverRectangle</code> – copy rectangle from bg bitmap to fg bitmap</li></ul><p>While applications are free to use the API this way, the system-suggested way is actually different.</p><h3 id="display-buffering">Display Buffering</h3><p>When using the core GEOS API, it’s not actually necessary to save the pixels (<code>ImprintRectangle</code>) before overwriting them. The background buffer already contains a copy!</p><p>That’s because all graphics code can be configured to either draw to the foreground bitmap, the background bitmap, or both.</p><p>To calculate the offset in the bitmap of a y coordinate, all internal drawing code calls <code>GetScanLine</code>. This function usually returns two pointers in virtual registers r5 and r6:</p><ul><li>r5: pointer to the pixel line in the <em>foreground</em> screen</li><li>r6: pointer to the pixel line in the <em>background</em> screen</li></ul><p>Any code in the GEOS drawing library then stores the pixel data in both the locations pointed to by r5 and r6:</p><pre><code> [...] sta (r5),y sta (r6),y</code></pre><p>For as little as an extra 6 clock cycles for every byte to be stored (which is 8 pixels), the drawing code stores it into both bitmaps, so there is usually no need to copy data from the foreground to the background bitmap.</p><p>Now when the system draws a menu or a dialog, it only draws it into the foreground buffer. That’s because the <code>GetScanLine</code> call can actually return different kinds of pointers depending on the global system variable <code>dispBufferOn</code>:</p><table><thead><tr><th> <code>dispBufferOn</code> </th><th> r5 </th><th> r6 </th></tr></thead><tbody><tr><td> <code>%11000000</code> (default) </td><td> fg screen ptr </td><td> bg screen ptr </td></tr><tr><td> <code>%10000000</code> </td><td> fg screen ptr </td><td> fg screen ptr </td></tr><tr><td> <code>%01000000</code> </td><td> bg screen ptr </td><td> bg screen ptr </td></tr></tbody></table><p>By only setting <em>one</em> of bits 6 and 7, all drawing code can effectively be instructed to only draw to the foreground or the background bitmap. In this case, the two <code>sta</code> instructions will just store the pixel data to the same location twice.</p><p>The system default is to draw everything to both bitmaps – except menus and dialogs, which are only ever drawn to the foreground bitmap. There is therefore no need to call <code>ImprintRectangle</code>: All that the built-in code has to do is call <code>RecoverRectangle</code> on the rectangle that it overwrote.</p><h2 id="screen-recovery-in-geowrite">Screen Recovery in geoWrite</h2><p>geoWrite is a very complex application that is very tight on memory, so it was designed to reclaim as much as possible of the 8 KB normally used for screen recovery. Text rendering is very slow, so redrawing the page as a recovery strategy is out of the question.</p><p>Instead, geoWrite stores the saved pixels more efficiently: The buffer only really needs to be as big as is required for the largest rectangle ever saved while in the app. And for geoWrite, that’s dialogs, which are 200×104 pixels. So that’s 2600 bytes instead of 8000 bytes.</p><p>The code to save a screen rectangle is called with the following arguments in virtual registers:</p><ul><li><code>r1</code>: the pointer to the recovery buffer</li><li><code>r2L</code>: x ÷ 8</li><li><code>r2H</code>: y</li><li><code>r3L</code>: width ÷ 8</li><li><code>r3H</code>: height</li></ul><p>X coordinates have to be divisible by 8, so that the pixels are at byte boundaries.</p><h3 id="the-code">The Code</h3><p>The following is the main code, slightly edited for readability. It iterates over all lines of the rectangle and, on save, appends the bitmap bytes to the array of saved data. On recover, it does the opposite.</p><pre><code>@loop1: ldx r2H ; y coord jsr GetScanLine ; r5 := ptr to bitmap lda r2L ; x coord / 8 asl a asl a asl a ; * 8 bcc :+ inc r5H : tay MoveB r3L, r4L ; copy byte count @loop2: bit r4H ; save or recover? bpl @1 jsr @recv bra @2 @1: jsr @save @2: IncW r1 ; advance buffer pointer add #8 ; account for quirky VIC-II memory layout bcc :+ inc r5H : tay dec r4L ; dec byte counter bne @loop2 ; loop for horizontal bytes inc r2H dec r3H ; dec line counter bne @loop1 ; loop for lines rts</code></pre><p>This is the subroutine for copying a byte from the screen to the buffer…</p><pre><code>@save: lda (r5),y ; read screen byte tax tya pha ; save offset ldy #0 txa sta (r1),y ; write into buffer pla ; restore offset rts</code></pre><p>…and the code for copying a byte from the buffer to the screen:</p><pre><code>@recv: tya ; save offset pha ldy #0 lda (r1),y ; read from buffer tax pla tay ; restore offset txa sta (r5),y ; write onto screen tya rts</code></pre><h3 id="the-tables">The Tables</h3><p>geoWrite uses a table with the buffer pointer, x, y, width and height values for each use case, so only an offset within the table has to be passed:</p><pre><code>; r1L/r1H r2L r2H r3L r3H ; ptr x y wdth hght scrrecvtabs: scrrecvtab_geos: .word MEM_SCRREST .byte 0, 15, 10, 128 scrrecvtab_file: .word MEM_SCRREST .byte 3, 15, 7, 100 [...]</code></pre><p>The first item in the table is for saving and restoring the rectangle under the “geos” menu, and so on.</p><p><code>MEM_SCRREST</code> is the address of the start of the recover buffer. The buffer pointer isn’t always <code>MEM_SCRREST</code> though:</p><pre><code>scrrecvtab_font: .word MEM_SCRREST .byte 17, 15, 10, 114 scrrecvtab_fontsize: .word MEM_SCRREST + 1408 .byte 26, 15, 9, 114</code></pre><p>This is because the font menu has a sub-menu for the point size:</p><p><img src="docs/geowrite/font_menu.png" alt="" /></p><p>When the font menu is open, the rectangle covered by it is already saved in the buffer. The rectangle under the point size menu has to be saved in the area following the already occupied data.</p><h3 id="memory-layout">Memory Layout</h3><p>Conveniently, the RAM area for the background bitmap immediately follows the application’s memory. Apps are free to just not use the background bitmap at all. By setting <code>dispBufferOn</code> to <code>%10000000</code> globally, the system will never touch the $6000-$7FFF area.</p><p>Here’s a mostly to scale overview of the geoWrite memory map compared to the GEOS default:</p><pre><code> GEOS Default geoWrite ------------------------- ------------------------- $0400 $0400 Main Code Application memory ------------------------- Overlay Code $3244 ------------------------- $4310 Page Data ------------------------- ------------------------- $6000 Font Heap $5E68 Background bitmap _________________________ Recovery Data $75D8 ------------------------- -------------------------</code></pre><p>geoWrite puts the recovery buffer at the topmost 2600 bytes of the $0400-$8000 window that is available to the application if it doesn’t use the background screen.</p><p>The reason for this location is because the range $7900-$7F40 is where GEOS requires the printer driver to be loaded once the application wants to print. It overlaps the background screen on purpose: As long as the application is not printing, so no space for the driver is wasted. And once it is printing, it just can’t use the background buffer any more. The same is true in geoWrite’s model.</p><h3 id="triggers">Triggers</h3><p>Aside from setting <code>dispBufferOn</code> to just the foreground, using one’s own save/recover logic requires the app to make sure the save and recover code gets called at the right times.</p><p>For dialogs, this is easy: Apps have to explicitly show them by calling the <code>doDlgBox</code> API, so before calling it, geoWrite saves the respective rectangle, and once the API returns, it recovers it.</p><p>For menus, it’s more tricky. The application has to trigger on the open event of a sub-menu.</p><p>Usually, the data structure of a menu for the <code>doMenu</code> API contains pointers to sub-menu data structures, forming the complete menu tree, like this:</p><pre><code>menu_main: .byte 0, 14, 0, 191 ; pos & size .byte HORIZONTAL | UN_CONSTRAINED | 3 ; #items .word txt_geos ; string "geos" .byte SUB_MENU ; =below is a sub-menu ptr .word menu_geos ; sub-menu data structure .word txt_file .byte SUB_MENU .word menu_file .word txt_edit .byte SUB_MENU .word menu_edit</code></pre><p>This way, an application can describe a complete menu tree with just data structures and no code.</p><p>But instead of a pointer to a sub-menu (code <code>SUB_MENU</code>), the data structure can alternatively contain a pointer to <em>code</em> that returns a sub-menu data structure (code <code>DYN_SUB_MENU</code>):</p><pre><code> .word txt_geos ; string "geos" .byte DYN_SUB_MENU ; =below is a code ptr .word callbackGeos ; code, called on sub-menu open</code></pre><p>In this example, whenever the “geos” item is clicked, the <code>callbackGeos</code> function is called, which saves the rectangle that will be covered by the “geos” sub-menu, and returns a pointer to the sub-menu to be presented (edited for clarity):</p><pre><code>callbackGeos: ldx #scrrecvtab_geos-scrrecvtabs stx a2L jsr screenSave LoadW r0, menu_geos rts</code></pre><p>For the recovery of the rectangle, there is actually a GEOS system variable supporting this use case: If the application sets the <code>RecoverVector</code> pointer to anything but 0, closing a menu will call that code instead of doing its own <code>RecoverRectangle</code>-based recovery.</p><p>This is where it points in geoWrite (again edited for clarity):</p><pre><code>appRecoverVector: ldx a2L jsr screenRecover rts</code></pre><p>The function reuses the previously set offset in the screen recovery table (in virtual register a2L) for buffer location, the origin and size of the rectangle.</p><h2 id="conclusion">Conclusion</h2><p>Berkeley Softworks wrote the GEOS operating system as well as many major applications like geoWrite, geoPaint, geoPublish and geoCalc, yet they implemented two different methods for screen recovery: The system way of doing it wastes space, but is very simple to use. And the way they do it in the applications is very much tied to the specific use case, but very optimized.</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1428</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item> <title>Inside geoWrite – 1: The Overlay System</title> <link>https://www.pagetable.com/?p=1425</link> <comments>https://www.pagetable.com/?p=1425#comments</comments> <pubDate>Tue, 01 Sep 2020 20:42:53 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Archeology]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[GEOS]]></category> <category><![CDATA[Operating Systems]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1425</guid> <description><![CDATA[geoWrite is a WYSIWYG rich text editor for the Commodore 64 GEOS operating system, which runs with a total of just 64 KB of RAM. In the series about the internals of geoWrite, this article discusses how it manages to fit 52 KB of code into the available 23 KB of application RAM. Introduction GEOS ... <a title="Inside geoWrite – 1: The Overlay System" class="read-more" href="https://www.pagetable.com/?p=1425">Read more<span class="screen-reader-text">Inside geoWrite – 1: The Overlay System</span></a>]]></description> <content:encoded><![CDATA[<p>geoWrite is a WYSIWYG rich text editor for the Commodore 64 GEOS operating system, which runs with a total of just 64 KB of RAM. In the series about the internals of geoWrite, this article discusses how it manages to fit 52 KB of code into the available 23 KB of application RAM.</p><p><img src="docs/geowrite/geowrite_1_overlays.png" alt="" /></p><h2 id="introduction">Introduction</h2><p><a href="https://github.com/mist64/geos">GEOS</a> is a disk-based graphical operating system for the Commodore 64 that provides the following features:</p><ul><li>applications, desk accessories</li><li>disk, printer and mouse drivers</li><li>loadable proportional fonts</li><li>menu bars, dialogs, file picker</li><li>multi-fork filesystem API</li><li>misc. library code (math, memory, strings, …)</li></ul><p>But since the OS kernel (called the “GEOS KERNAL”) is only 20 KB in size, some of the APIs are very limited, or cumbersome to use, so applications had to do a lot of work one would expect from the OS these days.</p><p>The GEOS authors “Berkeley Softworks” also wrote several applications – the OS-included deskTop, geoWrite and geoPaint, as well as geoPublish, geoCalc, geoChart, geoFile and geoDex – which all share low-level functionality that is not in fact part of the operating system, but shared code between these apps, like:</p><ul><li>code overlays</li><li>custom screen recovery</li><li>create/open/exit startup dialog</li><li>desk accessory enumeration</li><li>font management</li><li>zero page management</li><li>copy protection</li></ul><p>In this series of articles, we will discuss some of the lower-level features that are implemented on the application side, using the example of geoWrite.</p><ol><li><strong>The Overlay System</strong> ← this article</li><li><a href="https://www.pagetable.com/?p=1428">Screen Recovery</a></li><li><a href="https://www.pagetable.com/?p=1436">Font Management</a></li><li><a href="https://www.pagetable.com/?p=1442">Zero Page</a></li><li><a href="https://www.pagetable.com/?p=1449">Copy Protection</a></li><li><a href="https://www.pagetable.com/?p=1460">Localization</a></li><li><a href="https://www.pagetable.com/?p=1471">File Format and Pagination</a></li><li><a href="https://www.pagetable.com/?p=1481">Copy & Paste</a></li><li><a href="https://www.pagetable.com/?p=1490">Keyboard Handling</a></li></ol><h2 id="geos-memory-map">GEOS Memory Map</h2><p>GEOS and its apps need to fit into the 64 KB of RAM of the C64. Here is a rough overview of the memory map, mostly to scale:</p><pre><code>----------------------------------------- $0000 Zero page, stack, system variables ----------------------------------------- $0400 Application memory ----------------------------------------- $6000 Background bitmap ----------------------------------------- $8000 System buffers and variables ----------------------------------------- $9000 Disk driver ----------------------------------------- $A000 Screen bitmap ----------------------------------------- $C000 GEOS KERNAL -----------------------------------------</code></pre><p>The screen bitmap is an 8 KB RAM area for the 320×200 monochrome screen bitmap. There is a full-size “background” copy used for recovering the main screen contents after closing a menu or a dialog without needing a slow redraw.</p><p>The application has 23 KB of memory that it can use for code and data. geoWrite is 52 KB of code, and it needs 2 KB for variables, 7 KB for the current page of text and 6 KB for bitmap fonts. That would be 67 KB…</p><h2 id="vlir-files">VLIR Files</h2><p>In the UNIX world, a file is a mapping of a filename to a sequence of bytes (and some metadata). Some operating systems extend this concept: On classic MacOS, files consist of two of these sequences (the “resource fork” and the “data fork”). NextSTEP and MacOS X can present folders with a tree of individual files as a single “bundle”.</p><p>GEOS extends the UNIX-like Commodore filesystem with “VLIR” files, which stands for “Variable Length Index Record”. A VLIR file maps a filename to a 256 byte “file header” (for the icon and extra metadata) and up to 127 records, numbered 0-126. A record is a variable-length sequence of bytes, much like a traditional UNIX file.</p><p>You can imagine a VLIR file as a folder with several files in it. The following is a visualization of a typical geoWrite document:</p><pre><code>geoWrite Doc \--- File Header \--- 0 \--- 1 \--- 2 \--- 61 \--- 62 \--- 64</code></pre><p>As you can see, record numbers don’t have to be contiguous. (geoWrite for example stores pages in records 0-60, the header and footer into records 61 and 62, and image data in records 64-126.)</p><p>The file header contains the icon, the file type, and some other generic as well as application-specific metadata.</p><h2 id="vlir-applications">VLIR Applications</h2><p>GEOS applications can be VLIR files as well. When running an app, the system loads record 0 into memory and executes it. It’s entirely up to the application what to do with the other records.</p><p>This is what the geoWrite app looks like:</p><pre><code>GEOWRITE size \--- File Header 256 \--- 0 10335 \--- 1 2552 \--- 2 3999 \--- 3 2328 \--- 4 1965 \--- 5 3870 \--- 6 3998 \--- 7 3897 \--- 8 1194</code></pre><p>The geoWrite main code in record 0 is about 10 KB in size. The operating system loads it to $0400-$2C5E into application RAM.</p><h2 id="code-overlays">Code Overlays</h2><p>This is the memory layout of application RAM for geoWrite:</p><pre><code>----------------------------------------- $0400 Main code (record 0) ----------------------------------------- $2C5F Variables ----------------------------------------- $3244 Overlay code (records 1-7) ----------------------------------------- $41E4 Variables, page data, font data -----------------------------------------</code></pre><p>The record 0 code loaded by the OS always remains in its slot. It contains the core editing functionality, the overlay manager, the font manager and other library code.</p><p>There is a 4 KB slot for “overlay” code, meaning that the record 0 code can swap in any of the records from 1 through 7.</p><ul><li>[0 library code, core text editing]</li><li>1 initialization, copy protection</li><li>2 core text editing</li><li>3 cut, copy, paste</li><li>4 ruler editing</li><li>5 startup/about, create, open, paste text, run desk accessory</li><li>6 navigation, search/replace, header/footer, reflow</li><li>7 printing</li><li>[8 print settings]</li></ul><p>(Record 8 is handled differently and is discussed at the end of this article.)</p><p>Every record is linked to the same address ($3244) and starts with a jump table, like this one:</p><pre><code>CODE5: jmp recover ; 0 jmp showStartupMenu ; 1 jmp renameDocument ; 2 jmp openDocument ; 3 jmp showAboutDialog ; 4 jmp loadDeskAcc ; 5 jmp exitToDesktop ; 6 jmp readReservedRecord ; 7 jmp makeFullPageWide ; 8</code></pre><p>The jump table means that the record 0 code can be assembled independently of the overlays. While the overlays access symbols in the record 0 code, record 0 code only calls through these jump table entries.</p><h2 id="vlir-api">VLIR API</h2><p>The GEOS KERNAL has the following calls for working with VLIR files:</p><ul><li><code>OpenRecordFile</code> – Open an existing VLIR file given its name</li><li><code>UpdateRecordFile</code> – Flush the VLIR’s metadata to disk</li><li><code>CloseRecordFile</code> – Flush and close VLIR file</li><li><code>PointRecord</code> – Set current record</li><li><code>PreviousRecord</code> – Move to previous record</li><li><code>NextRecord</code> – Move to next record</li><li><code>ReadRecord</code> – Read complete record into memory</li><li><code>WriteRecord</code> – Write/overwrite complete record from memory image</li><li><code>DeleteRecord</code> – Delete current record</li></ul><p>Reading overlay code should therefore be as simple as this:</p><pre><code> ; startup LoadW r0, fnBuffer jsr OpenRecordFile ; load overlay code lda #n loadCode: jsr PointRecord LoadW r7, OVERLAY_ADDRESS LoadW r2, OVERLAY_SIZE jsr ReadRecord</code></pre><p>Unfortunately, GEOS can only have one VLIR file open at a time, and a geoWrite document is also a VLIR file. Opening and closing the two files would cause too much disk activity, which is why geoWrite comes with a simple read-only VLIR implementation on the side.</p><h2 id="loading-overlays-manually">Loading Overlays Manually</h2><p>On disk, a VLIR file’s directory entry points to it 256 bytes index table. Here is an example:</p><pre><code>00 FF 06 13 08 10 09 14 0A 01 0A 12 0A 13 0B 00 0C 02 0D 04 00 00 00 00 00 00 00 00 00 00 00 00 [...]</code></pre><p>The <code>00 FF</code> at the beginning is the Commodore DOS sector header and not part of the data. The remaining pairs of bytes point to the track and sector of the start of each record on disk.</p><p>GEOS has an API for loading a file given a track and a sector (<code>ReadFile</code>), so all geoWrite needs to do is read its own index table on startup, and call <code>ReadFile</code> on items of this table when loading an overlay.</p><p>Here’s a shortened version of the code to get a copy of the app’s index table:</p><pre><code> ; find application LoadW r6, fnBuffer lda #APPLICATION sta r7L lda #1 ; find max. 1 file sta r7H LoadW r10, appname jsr FindFTypes LoadW r0, fnBuffer jsr OpenRecordFile jsr i_MoveData ; copy index table .word fileHeader+2 .word appIndexTable .word 2 * NUM_APP_RECORDS LoadB curCodeRecord, $FF rts appname: .byte "geoWrite V2.1",0</code></pre><p><code>OpenRecordFile</code> reads the VLIR file’s index table info <code>fileHeader</code>. geoWrite then copies <code>NUM_APP_RECORDS</code> into its own table <code>appIndexTable</code>, skipping the first two bytes (<code>00 FF</code>).</p><p>And here is a shortened version of the code to read a record:</p><pre><code> ; load overlay code lda #n loadCode: cmp curCodeRecord beq @rts ; already loaded sta curCodeRecord asl a tay lda appIndexTable,y sta r1L lda appIndexTable+1,y sta r1H LoadW r7, OVERLAY_ADDRESS LoadW r2, OVERLAY_SIZE jsr _ReadFile @rts: rts</code></pre><p>You can see that the code keeps track of the currently loaded record, so it does not re-load the same code if it’s already in memory.</p><h2 id="managing-overlays">Managing Overlays</h2><p>All overlay functionality is implemented in the record 0 code, because it always needs to be accessible.</p><p>There is a set of functions for loading the different records:</p><pre><code>loadCode1: lda #1 .byte $2C ; skip next loadCode2: lda #2 .byte $2C ; skip next loadCode3: lda #3 .byte $2C ; skip next loadCode4: lda #4 .byte $2C ; skip next loadCode5: lda #5 .byte $2C ; skip next loadCode6: lda #6 .byte $2C ; skip next loadCode7: lda #7 loadCode: [...]</code></pre><p>The record 0 code can then load an overlay and call a function through its jump table</p><pre><code> jsr loadCode5 jsr J5_showStartupMenu ; OVERLAY_ADDRESS + 3 * 1</code></pre><p>Code inside an overlay can’t call code from a different overlay this way, because the <code>loadCode</code> call would overwrite the caller. For this case, the record 0 code has functions like this one:</p><pre><code>_showCantAddPages: ldy #<J3_showCantAddPages ; OVERLAY_ADDRESS + 3 * 8 .byte $2C _showTooManyPages: ldy #<J3_showTooManyPages ; OVERLAY_ADDRESS + 3 * 7 .byte $2C _splitTooBigPage: ldy #<J3_splitTooBigPage ; OVERLAY_ADDRESS + 3 * 5 ldx #BANK_3 callRestore: lda curCodeRecord pha sty @1 txa jsr loadCode @1 = * + 1 jsr OVERLAY_ADDRESS pla jmp loadCode</code></pre><p>The function <code>showCantAddPages</code> is implemented on overlay 3. Code in overlay 2 can call <code>_showCantAddPages</code> in the record 0 code, which will load overlay 3, call the function, load the original overlay 2 again, and return.</p><h2 id="splitting-the-logic">Splitting the Logic</h2><p>With helper functions in the record 0 code, it is possible to arbitrarily split logic into the different records. But since loading an overlay takes about 2-3 seconds on a 1541 disk drive, this should be minimized.</p><h3 id="central-library-code">Central Library Code</h3><p>The overlay code that we have seen above has to live in the record 0 code, so it’s directly callable by any record.</p><p>While in theory any other library code could live in any other record, keeping the most-used functionality in the record 0 code will reduce disk accesses. Here are some examples:</p><ul><li>generic dialogs</li><li>error dialogs</li><li>drive switching (app vs. document)</li><li>disk full testing</li><li>screen recovery</li><li>font management</li><li>zero page management</li><li>some common text strings</li></ul><h3 id="one-time-logic">One-time logic</h3><p>Furthermore, there is code that is only ever needed once. On startup, the following is done:</p><ul><li>enumerate fonts and desk accessories on disk</li><li>get the page size from the printer</li><li>initialize the menu bar</li><li>draw the ruler and the page indicator</li><li>prepare a file opened for printing only</li><li>do the copy protection dance</li></ul><p>All this code lives in record 1. It is loaded immediately after the app is started. When it returns, it never gets loaded again.</p><h3 id="main-mode-code">Main Mode Code</h3><p>Then, there is code that is needed when the app is in its main mode, like the text renderer and the handlers for navigating on the page, typing text and deleting text.</p><p>The main mode code lives in the remainder of record 0 as well as in record 2: During normal text editing, geoWrite always keeps record 2 loaded.</p><p>Since functions for menu items, keyboard shortcuts and mouse triggers in main mode are called by the GEOS KERNAL directly, which does not know about banking, at least the entry points of these handlers also have to live in record 0 (or, with restrictions, record 2).</p><h3 id="grouped-functionality">Grouped Functionality</h3><p>The remaining records contain further functionality, grouped by topic, so they can use common code inside the same record. Here is the list again:</p><ul><li>3 cut, copy, paste</li><li>4 ruler editing</li><li>5 startup/about, create, open, paste text, run desk accessory</li><li>6 navigation, search/replace, header/footer, reflow</li><li>7 printing</li></ul><p>On app launch, the record 0 entry code immediately loads initialization code in record 1. After its return, the record 0 code runs the startup UI code in record 5, which creates a new file or opens an existing file and returns to the core text editor in the record 0/2 code.</p><h3 id="duplicate-code">Duplicate Code</h3><p>Common code needed by very different functionality groups usually lives in record 0, so that any record can call it without causing swapping in and out overlays. This is true for most common code, but since space in record 0 is at a premium, a different solution was necessary especially for bigger reusable components.</p><p>The startup code for example needs to talk to the printer driver to query the page size, and the print code needs to talk to the printer for printing. They both need to look up and load the printer driver. This common code is too big to fit into record 0, and having the startup code (#1) call out into the printing record (#7) would increase startup time by at least 5 seconds, swapping in #7 and then swapping in #1 again.</p><p>The solution is to just duplicate the common code into different records, e.g. by using <code>.include</code> statements to reuse the same code in multiple places. As long as the individual records don’t overflow their 4 KB maximum, this is a reasonable tradeoff.</p><p>Other examples are the document file version check, the string-to-int conversion code and common “text scrap” (clipboard) code. Parts of the latter are even included in three different records.</p><h2 id="functionality->-4-kb”>Functionality > 4 KB</h2><p>The printing logic is about 5 KB in size, so it doesn’t fit into a 4 KB overlay record. Swapping in and out records during printing is not an option.</p><p>Since printing is a different mode altogether, 1 KB of record 0 code in RAM is overwritten by the additional printing code from record #8. The code in record 0 was arranged in a way that there is a contiguous 1 KB chunk ($0680-$0B29) that does not need to be called by the printing functionality. This is, among other things, the data structures for drawing the main menu. After printing, the record #7 code re-loads all of record 0.</p><h2 id="conclusion">Conclusion</h2><p>The overlay system has been a feature since the very first version of GEOS and is used by all major applications. It is not without its limits though: An application’s main mode should be responsive and do most of its work without swapping overlays, so the core logic (record 0 and one overlay record) has a certain limit in complexity. The individual overlays have a very tight size limit as well.</p><p>For the printing functionality, geoWrite already has to work around the overlay code size, which shows that an app like geoWrite is truly at the limit of what a GEOS application can do on a 64 KB system.</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1425</wfw:commentRss> <slash:comments>6</slash:comments> </item> <item> <title>CMDR-DOS: Commodore DOS on FAT32</title> <link>https://www.pagetable.com/?p=1421</link> <comments>https://www.pagetable.com/?p=1421#comments</comments> <pubDate>Sat, 22 Aug 2020 08:17:36 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Commodore Peripheral Bus]]></category> <category><![CDATA[DOS]]></category> <category><![CDATA[GitHub]]></category> <category><![CDATA[KERNAL]]></category> <category><![CDATA[Operating Systems]]></category> <category><![CDATA[X16]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1421</guid> <description><![CDATA[All disk drives connected to the Serial Bus of a Commodore 64 speak the Commodore DOS protocol, from the popular 1541 5.25″ drive to the modern sd2iec SD card interfaces. CMDR-DOS is a new and open source implementation of the Commodore DOS protocol, using SD cards with the FAT32 filesystem and supporting advances features like ... <a title="CMDR-DOS: Commodore DOS on FAT32" class="read-more" href="https://www.pagetable.com/?p=1421">Read more<span class="screen-reader-text">CMDR-DOS: Commodore DOS on FAT32</span></a>]]></description> <content:encoded><![CDATA[<p>All disk drives connected to the Serial Bus of a Commodore 64 speak the <a href="https://www.pagetable.com/?p=1038">Commodore DOS</a> protocol, from the popular 1541 5.25″ drive to the modern <a href="https://sd2iec.de">sd2iec</a> SD card interfaces. <strong>CMDR-DOS</strong> is a new and open source implementation of the Commodore DOS protocol, using SD cards with the FAT32 filesystem and supporting advances features like partitions, subdirectories and timestamps – and running on a 65c02!</p><h2 id="commander-x16">Commander X16</h2><p>It is the built-in DOS of the <a href="https://www.commanderx16.com">Commander X16</a>, and runs on the main CPU, so the KERNAL API (<code>talk</code>, <code>tksa</code>, <code>untlk</code>, <code>listn</code>, <code>secnd</code>, <code>unlsn</code>, <code>acptr</code>, <code>ciout</code>) calls directly into the DOS implementation. This allows <code>LOAD</code> speeds of about 140 KB/sec on an 8 MHz system.</p><p>Demo:</p><p><img src="docs/cmdr-dos.gif" alt="" /></p><p>Transcript:</p><pre style="overflow:scroll; height:200px;"><code>DOS"$=P":REM THERE ARE TWO PARTITIONS ON THIS SD-CARD 255 "CMDR-DOS SD CARD" MBR 1 "PART1" FAT32 2 "PART2" FAT32 READY. DOS"N1:SYSTEM,1616,FAT32":REM FORMAT PARTITION 1 READY. DOS"N2:DATA,1617,FAT32":REM FORMAT PARTITION 2 READY. DOS"$=P":REM THE NEW NAMES OF THE TWO PARTITIONS 255 "CMDR-DOS SD CARD" MBR 1 "SYSTEM" FAT32 2 "DATA" FAT32 READY. DOS"CP1":REM SWITCH TO PARTITION 1 READY. DOS"$":REM SHOW DIRECTORY 0 "SYSTEM " FAT32 99 MB FREE. READY. OPEN1,8,2,"HELLO,P,W":PRINT#1,"HELLO WORLD!":CLOSE1:REM CREATE FILE READY. DOS"$" 0 "SYSTEM " FAT32 1 "HELLO" PRG 99 MB FREE. READY. DOS"C:WORLD=HELLO":REM DUPLICATE FILE READY. DOS"$" 0 "SYSTEM " FAT32 1 "HELLO" PRG 1 "WORLD" PRG 99 MB FREE. READY. DOS"C:HELLO WORLD=HELLO,WORLD":REM CONCATENATE FILES READY. DOS"$" 0 "SYSTEM " FAT32 1 "HELLO" PRG 1 "WORLD" PRG 1 "HELLO WORLD" PRG 99 MB FREE. READY. DOS"MD:SECRET":REM CREATE SUBDIRECTORY READY. DOS"$" 0 "SYSTEM " FAT32 1 "HELLO" PRG 1 "WORLD" PRG 1 "HELLO WORLD" PRG 0 "SECRET" DIR 99 MB FREE. READY. DOS"$//SECRET/:":REM SHOW SUBDIR CONTENTS 0 "SYSTEM " FAT32 0 "." DIR 0 ".." DIR 99 MB FREE. READY. DOS"CD:SECRET":REM CHANGE TO SUBDIR READY. DOS"$" 0 "SYSTEM " FAT32 0 "." DIR 0 ".." DIR 99 MB FREE. READY. DOS"C:SECRET HELLO=//:HELLO":REM COPY FILE FROM ROOT TO HERE READY. DOS"CD:_":REM CHANGE BACK UP READY. DOS"CP2":REM CHANGE TO PARTITION 2 READY. DOS"$ 0 "DATA " FAT32 98 MB FREE. READY. DOS"C:DATA FILE=1//SECRET/:SECRET HELLO":REM COPY FILE FROM PARTITION 1 READY. DOS"$ 0 "DATA " FAT32 1 "DATA FILE" PRG 98 MB FREE. READY. DOS"$1:":REM SHOW DIRECTORY OF PARTITION 1 1 "SYSTEM " FAT32 1 "HELLO" PRG 1 "WORLD" PRG 1 "HELLO WORLD" PRG 0 "SECRET" DIR 99 MB FREE. READY. DOS"S1:H*":REM DELETE ALL FILES THERE STARTING WITH H READY. DOS:REM THIS WILL SAY THAT "02" FILES WERE DELETED 01, FILES SCRATCHED,02,00 READY. DOS"CP1":REM CHANGE BACK TO PARTITION 1 READY. DOS"$ 0 "SYSTEM " FAT32 1 "WORLD" PRG 0 "SECRET" DIR 99 MB FREE. READY. DOS"S:*":REM DELETE ALL REMAINING FILES READY. DOS:REM THIS WILL SAY THAT "01" FILE WAS DELETED 01, FILES SCRATCHED,01,00 READY. DOS"$":REM THE DIRECTORY IS STILL THERE 0 "SYSTEM " FAT32 0 "SECRET" DIR 99 MB FREE. READY. DOS"RD:SECRET":REM DELETE IT READY. DOS:REM "00" FILES DELETED, BECAUSE DIR WAS NOT EMPTY 01, FILES SCRATCHED,00,00 READY. DOS"S//SECRET/:*":REM DELETE ALL FILES INSIDE READY. DOS:REM "01" FILE DELETED 01, FILES SCRATCHED,01,00 READY. DOS"RD:SECRET":REM NOW TRY DELING THE DIR AGAIN READY. DOS:REM "01" FILES DELETED, IT WORKED THIS TIME 01, FILES SCRATCHED,01,00 READY. DOS"$ 0 "SYSTEM " FAT32 99 MB FREE. READY. REM THAT'S IT. :) READY.</code></pre><h2 id="source">Source</h2><p>The implementation is part of the Commander X16 ROM and available here:</p><p><a href="https://github.com/commanderx16/x16-rom/tree/master/dos">https://github.com/commanderx16/x16-rom/tree/master/dos</a></p><h2 id="future">Future</h2><p>The codebase is very versatile and could be reused for other kinds of projects:</p><h3 id="other-new-retro-machines">Other New Retro Machines</h3><p>CMDR-DOS could be easily ported to other Commodore-like 65c02+ systems like the <a href="https://mega65.org">MEGA65</a> and the <a href="https://www.c256foenix.com">C256 Foenix</a>, providing a DOS interface to FAT32 on those platforms.</p><h3 id="sd2iec-like-device">sd2iec-like Device</h3><p>Functionality-wise, the CMDR-DOS codebase is also very similar to what sd2iec does – minus the Commodore Serial part. It could be ported a device like the <a href="https://www.forum64.de/index.php?thread/102472-1581replica-gotek1581-1581-pc-drive-adapter/">1581replica</a>, with an SD card attached instead of a disk drive, and one would have a 65c02-based sdi2ec-like device.</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1421</wfw:commentRss> <slash:comments>3</slash:comments> </item> <item> <title>FAT32 Filesystem for the 65c02</title> <link>https://www.pagetable.com/?p=1416</link> <comments>https://www.pagetable.com/?p=1416#comments</comments> <pubDate>Fri, 21 Aug 2020 07:55:25 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[DOS]]></category> <category><![CDATA[Floppy Disks]]></category> <category><![CDATA[GitHub]]></category> <category><![CDATA[Operating Systems]]></category> <category><![CDATA[X16]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1416</guid> <description><![CDATA[We are presenting the (to our knowledge) first full-featured open source library for 65c02 CPUs for accessing FAT32 formatted disks. The library supports filesystems from 32 MB to 2 TB, can read and write long filenames, subdirectories and time stamps, and can even create new filesystems. It decodes a Master Boot Record (MBR) partitioning table ... <a title="FAT32 Filesystem for the 65c02" class="read-more" href="https://www.pagetable.com/?p=1416">Read more<span class="screen-reader-text">FAT32 Filesystem for the 65c02</span></a>]]></description> <content:encoded><![CDATA[<p>We are presenting the (to our knowledge) first full-featured open source library for 65c02 CPUs for accessing FAT32 formatted disks.</p><ul><li>The library supports filesystems from 32 MB to 2 TB, can read and write long filenames, subdirectories and time stamps, and can even create new filesystems.</li><li>It decodes a Master Boot Record (MBR) partitioning table and can have multiple partitions mounted at the same time.</li><li>It comes with a driver for the SD card protocol, so you can hook it to your own SD card solution; all you have to do is implement your own byte transmission code. If you want to use a VIA 65c22, you can hook up the <a href="https://bitbucket.org/steckschwein/steckschwein-code/src/master/steckos/libsrc/spi/">65c22 serial port code by the Steckschwein project</a>.</li><li>Converting character encodings and matching names is done using callbacks – you can use the <a href="https://github.com/commanderx16/x16-rom/blob/master/cbdos/match.s">X16 implementation</a> for a template.</li></ul><p>The API looks like this:</p><pre><code> ; allocate context for filesystem #0 ; (first MBR partition, mount if necessary) lda #0 jsr fat32_alloc_context sta context ; open file lda #<filename sta fat32_ptr lda #>filename sta fat32_ptr + 1 jsr fat32_open loop: ; read and print byte jsr fat32_read_byte bcc end jsr print_character jmp loop end: jsr fat32_close lda context jmp fat32_free_context filename: .byte '/path/to/file.txt', 0</code></pre><p>The implementation uses the 65c02 extensions. With the help of <a href="https://github.com/commanderx16/x16-rom/blob/68cec17c700bd9666dc49f801e0853af4e417ebf/cbdos/65c02.inc">65c02.inc</a> and some simple search-and-replace, it can be adapted for the 6502 though.</p><p>The library was written by Frank van den Hoef, with features (LFN, mkfs, …) added by Michael Steil.</p><p>It is the core of the DOS in the Commodore-like <a href="https://www.commanderx16.com">Commander X16</a> retro computer. The source is currently maintained as part of the X16 ROM:</p><p><a href="https://github.com/commanderx16/x16-rom/tree/master/dos/fat32">https://github.com/commanderx16/x16-rom/tree/master/dos/fat32</a></p><p>Contributions welcome!</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1416</wfw:commentRss> <slash:comments>6</slash:comments> </item> <item> <title>Building the Tynemouth Mini PET</title> <link>https://www.pagetable.com/?p=1408</link> <comments>https://www.pagetable.com/?p=1408#comments</comments> <pubDate>Sun, 05 Jul 2020 10:03:41 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Hardware]]></category> <category><![CDATA[PET]]></category> <category><![CDATA[Teardown]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1408</guid> <description><![CDATA[Tynemouth Mini PET at FTW8b.com]]></description> <content:encoded><![CDATA[<p><a href="docs/minipet/minipet.gif"><img width="806" height="400" src="docs/minipet/minipet.gif"></a></p><p><a href="https://www.thefuturewas8bit.com/shop/tynemouth-products/mini-pet.html"> Tynemouth Mini PET at FTW8b.com</a></p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1408</wfw:commentRss> <slash:comments>2</slash:comments> </item> <item> <title>Ultimate Commodore Charset / PETSCII / Keyboard Reference</title> <link>https://www.pagetable.com/?p=1404</link> <comments>https://www.pagetable.com/?p=1404#comments</comments> <pubDate>Tue, 09 Jun 2020 09:29:07 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Archeology]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[KERNAL]]></category> <category><![CDATA[PET]]></category> <category><![CDATA[TED]]></category> <category><![CDATA[VIC-20]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1404</guid> <description><![CDATA[Another addition to the The Ultimate C64 Reference: We’re adding character sets, PETSCII codes and keyboard layouts – supporting eight different Commodore computers. There are three different (related) modes: Character Sets, PETSCII and Keyboard. The controls on the left switch some global settings: Character Set lets you select the Commodore 8×8 charset to be used ... <a title="Ultimate Commodore Charset / PETSCII / Keyboard Reference" class="read-more" href="https://www.pagetable.com/?p=1404">Read more<span class="screen-reader-text">Ultimate Commodore Charset / PETSCII / Keyboard Reference</span></a>]]></description> <content:encoded><![CDATA[<p>Another addition to the <em>The Ultimate C64 Reference</em>: We’re adding <a href="http://www.pagetable.com/c64ref/charset/">character sets, PETSCII codes and keyboard layouts</a> – supporting eight different Commodore computers.</p><p><a href="docs/c64ref_charset/c64ref_charset-1.png"><img src="docs/c64ref_charset/c64ref_charset-1_small.png" height="479" width="600" alt="" /></a></p><p>There are three different (related) modes: Character Sets, PETSCII and Keyboard. The controls on the left switch some global settings:</p><p><a href="docs/c64ref_charset/c64ref_charset-2.png"><img src="docs/c64ref_charset/c64ref_charset-2.png" height="256" width="391" alt="" /></a></p><ul><li><strong>Character Set</strong> lets you select the Commodore 8×8 charset to be used in all modes. The drop-down list contains 84 ROM-extracted charsets.</li></ul><p><img src="docs/c64ref_charset/charsets.gif" height="296" width="300" alt="" /></p><ul><li><strong>Control Codes</strong> specifies which set of PETSCII control codes will be visualized in the PETSCII table.</li></ul><p><img src="docs/c64ref_charset/petscii.gif" height="296" width="300" alt="" /></p><ul><li><strong>Color Scheme</strong> matches the charset to the color scheme of a specific computer, or shows it in black-on-white.</li></ul><p><img src="docs/c64ref_charset/colorscheme.gif" height="296" width="300" alt="" /></p><ul><li><strong>Aspect Ratio</strong> controls the width-to-height ratio of the character set displayed, showing them either with square pixels, or matching one of the computers.</li></ul><p><img src="docs/c64ref_charset/aspectratio.gif" height="296" width="300" alt="" /></p><ul><li>By clicking one of the radio boxes next to the computer names, the four settings above will be set to match a specific computer.</li></ul><p><img src="docs/c64ref_charset/machine.gif" height="296" width="300" alt="" /></p><ul><li>The checkboxes next to the computer names allow viewing the PETSCII control codes, keyboards and keyboard combinations of multiple computers in all other views.</li></ul><h2 id="character-sets">Character Sets</h2><p>The <strong>Character Sets</strong> tab shows all 128 characters of the currently selected charset as well as its inverted form, sorted by screen code. You can click on a character to view its screen code, PETSCII and Unicode values, as well as the keyboard combinations that produce this key on the different machines.</p><p><img src="docs/c64ref_charset/charset-detail.png" height="379" width="411" alt="" /></p><p>Below, there is a table showing all character sets at the same time. It can be filtered to only show upper case or lower case charsets.</p><p><a href="docs/c64ref_charset/charset-table.png"><img src="docs/c64ref_charset/charset-table.png" height="312" width="658" alt="" /></a></p><p>In addition, there is a function that lets you compare two character sets. The middle line shows the XOR of the two charsets. This example shows that several lower case letters were optimized from the C64 to the TED:</p><p><img src="docs/c64ref_charset/charset-compare.png" height="79" width="472" alt="" /></p><h2 id="petscii">PETSCII</h2><p>The <strong>PETSCII</strong> tab visualizes the 256 PETSCII codes. Codes 0x00 to 0x1F (the first two rows) and codes $80 to $9F (rows 9 and 10) are control codes, the others are printable. Clicking on a code will reveal the PETSCII value, the screen code and the keyboard combinations. For control codes, it shows the functions on the different computers, and for printable characters it shows the Unicode equivalent.</p><p><img src="docs/c64ref_charset/petscii-detail-1.png" height="262" width="273" alt="" /><img src="docs/c64ref_charset/petscii-detail-2.png" height="267" width="273" alt="" /></p><p>The table below shows this information for all codes in one place. Here is a part of it comparing some keyboard combinations and control codes between three different computers:</p><p><a href="docs/c64ref_charset/petscii-table.png"><img src="docs/c64ref_charset/petscii-table.png" height="341" width="650" alt="" /></a></p><h2 id="keyboard">Keyboard</h2><p>The <strong>Keyboard</strong> tab shows the keyboard layouts of the different computers and lets you explore which PETSCII codes and characters are generated by which key combinations.</p><p><a href="docs/c64ref_charset/keyboard-1.png"><img src="docs/c64ref_charset/keyboard-1.png" height="356" width="278" alt="" /></a><a href="docs/c64ref_charset/keyboard-2.png"><img src="docs/c64ref_charset/keyboard-2.png" height="285" width="276" alt="" /></a></p><p>In the screenshot above, you can see the three different keyboards of the computers from the TED series: the C16, the C116 and the Plus/4.</p><h2 id="contributing">Contributing</h2><p>Like all web pages of the Ultimate C64 Reference, these view are generated from independent formatted ASCII files. The C64 keyboard file looks like this, for example:</p><p><img src="docs/c64ref_charset/keyboard-file.png" height="416" width="608" alt="" /></p><p>It contains the ASCII-art of the layout, which is converted into SVG graphics by a Python script, the key caps, information about modifiers as well as the scancode-to-PETSCII tables.</p><p>The Ultimate C64 Reference is being developed as an open source project at <a href="https://github.com/mist64/c64ref">github.com/mist64/c64ref</a> – contributions in the form of additions, corrections etc. are welcome!</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1404</wfw:commentRss> <slash:comments>7</slash:comments> </item> <item> <title>Ultimate C64 KERNAL API Reference</title> <link>https://www.pagetable.com/?p=1401</link> <comments>https://www.pagetable.com/?p=1401#comments</comments> <pubDate>Wed, 03 Jun 2020 21:35:41 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Archeology]]></category> <category><![CDATA[BASIC]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[KERNAL]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1401</guid> <description><![CDATA[The Ultimate C64 Reference is growing again: This time, we’re adding the KERNAL API reference – as always, in eleven different versions side-by-side. These are the references that have been adapted for this: Commodore 64 Programmer’s Reference Guide, ISBN 0-672-22056-3 COMPUTE!’s VIC-20 and Commodore 64 Tool Kit: Kernal by Dan Heeb, ISBN 0942386337 Machine Language ... <a title="Ultimate C64 KERNAL API Reference" class="read-more" href="https://www.pagetable.com/?p=1401">Read more<span class="screen-reader-text">Ultimate C64 KERNAL API Reference</span></a>]]></description> <content:encoded><![CDATA[<p>The Ultimate C64 Reference is growing again: This time, we’re adding the <a href="http://www.pagetable.com/c64ref/kernal/">KERNAL API reference</a> – as always, in <strong>eleven</strong> different versions side-by-side.</p><p><a href="docs/c64ref_kernal/c64ref_kernal-1.png"><img src="docs/c64ref_kernal/c64ref_kernal-1.png" height="468" width="796" alt="" /></a></p><p>These are the references that have been adapted for this:</p><ul><li><a href="https://github.com/Project-64/reloaded/blob/master/c64/c64prg/C64PRG11.TXT">Commodore 64 Programmer’s Reference Guide</a>, ISBN 0-672-22056-3</li><li><a href="https://archive.org/details/COMPUTEs_VIC-20_and_Commodore_64_Tool_Kit_Kernal_1985_COMPUTE_Publications_a">COMPUTE!’s VIC-20 and Commodore 64 Tool Kit: Kernal</a> by Dan Heeb, ISBN 0942386337</li><li><a href="https://archive.org/details/Compute_s_Machine_Language_Routines_for_the_Commodore_64_and_128">Machine Language Routines for the Commodore 64 and 128</a> by Todd D Heimarck and Patrick Parrish, ISBN 0874550858</li><li><a href="https://github.com/Project-64/reloaded/blob/master/c64/mapc64/MAPC6412.TXT">Mapping the Commodore 64</a> by Sheldon Leemon, ISBN 0-942386-23-X</li><li><a href="https://www.retrozone.ch/docs/c128/Commodore128Intern.pdf">Commodore 128 intern</a> by Jörg Schieb, Frank Thrun and Heinz Wrobel, ISBN 3-89011-098-3</li><li><a href="https://github.com/Project-64/reloaded/blob/master/c64/firmware/C64LD11.S">The almost completely commented C64 ROM disassembly</a> by Lee Davison</li><li><a href="https://www.atarimagazines.com/compute/issue40/cracking_the_kernal.php">Cracking The Kernal</a> by Peter Marcotty in COMPUTE! #40, September 1983, pp. 268-274</li><li><a href="http://csbruce.com/cbm/hacking/hacking03.txt">Kernal 64 / 128</a> by Craig Taylor in C= Hacking, Volume 1, Issue 3; July 15, 1992</li><li><a href="https://sta.c64.org/cbm64krnfunc.html">Commodore 64 standard KERNAL functions</a> by Joe Forster/STA</li><li><a href="http://www.zimmers.net/anonftp/pub/cbm/c64/programming/documents/c64-kernal.txt">C64 KERNAL jump table</a> by Frank Kontros</li><li><a href="https://www.pagetable.com/?p=1015">Das neue Commodore-64-intern-Buch</a> by Baloui, Brückmann, Englisch, Felt, Gelfand, Gerits and Krsnik, ISBN 3890113079</li></ul><p>You can enable and disable columns by clicking the checkboxes next to the sources, and you can expand/collapse all details with the corresponding button above the table.</p><p>Here are four different expanded explanations of the <code>SCNKEY</code> call ($FF9F):</p><p><a href="docs/c64ref_kernal/c64ref_kernal-2.png"><img src="docs/c64ref_kernal/c64ref_kernal-2.png" height="139" width="747" alt="" /></a></p><p>As you can see, KERNAL API symbols as well as zeropage/variable symbols and addresses are cross-referenced and link to the respective description.</p><p>Like all web pages of the Ultimate C64 Reference, this table is generated from independent formatted ASCII files. In the case of the KERNAL API, these files look like this:</p><p><a href="docs/c64ref_kernal/c64ref_kernal-3.png"><img src="docs/c64ref_kernal/c64ref_kernal-3.png" height="519" width="633" alt="" /></a></p><p>It consists of three columns: the address in hex, the symbol name and the description in MarkDown format.</p><p>The Ultimate C64 Reference is being developed as an open source project at <a href="https://github.com/mist64/c64ref">github.com/mist64/c64ref</a> – contributions in the form of additions, corrections etc. are welcome!</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1401</wfw:commentRss> <slash:comments>3</slash:comments> </item> <item> <title>Ultimate C64 Memory Map</title> <link>https://www.pagetable.com/?p=1397</link> <comments>https://www.pagetable.com/?p=1397#comments</comments> <pubDate>Fri, 15 May 2020 19:26:41 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Archeology]]></category> <category><![CDATA[BASIC]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[GitHub]]></category> <category><![CDATA[KERNAL]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1397</guid> <description><![CDATA[The system software of the Commodore 64 has been extensively reverse-engineered. Next to disassemblies of the ROM, several “memory maps” have been published: tables that document system variables in the first kilobyte of RAM, and how to tweak the system software with PEEK and POKE. Now, I’m presenting the Ultimate C64 Memory Map: A C64 ... <a title="Ultimate C64 Memory Map" class="read-more" href="https://www.pagetable.com/?p=1397">Read more<span class="screen-reader-text">Ultimate C64 Memory Map</span></a>]]></description> <content:encoded><![CDATA[<p>The system software of the Commodore 64 has been extensively reverse-engineered. Next to <a href="https://www.pagetable.com/c64ref/c64disasm/">disassemblies</a> of the ROM, several “memory maps” have been published: tables that document system variables in the first kilobyte of RAM, and how to tweak the system software with <code>PEEK</code> and <code>POKE</code>. Now, I’m presenting the <a href="https://www.pagetable.com/c64ref/c64mem/">Ultimate C64 Memory Map</a>: A C64 memory reference that shows eight sources side-by-side.</p><p><img src="docs/c64mem/c64mem-1.png" height="385" width="708" alt="" /></p><p>These are the references that have been adapted for this:</p><ul><li>Reference from <a href="http://unusedino.de/ec64/technical/project64/mapping_c64.html">Mapping the Commodore 64</a> by Sheldon Leemon, ISBN 0-942386-23-X.</li><li>German-language reference from <a href="https://archive.org/details/64er_sonderheft_1986_07/page/n6/mode/2up">Memory Map mit Wandervorschlägen</a> by Dr. H. Hauck, in 64’er Sonderheft 1986/07.</li><li>German-language reference from <a href="https://www.pagetable.com/?p=1015">Das neue Commodore-64-intern-Buch</a> by Data Becker, ISBN 3890113079.</li><li>Reference by <a href="https://sta.c64.org/cbm64mem.html">Joe Forster/STA</a>, with <a href="http://www.awsm.de/mem64/">awsm’s</a> changes applied.</li><li>Comments from the <a href="https://github.com/mist64/cbmsrc">original M6502 BASIC source by Microsoft and the original C64 KERNAL source by Commodore</a></li><li>Reference from <a href="http://www.zimmers.net/cbmpics/cbm/c64/c64prg.txt">Commodore 64 Programmer’s Reference Guide</a>.</li><li>Reference as found in <a href="http://unusedino.de/ec64/technical/project64/memory_maps.html">Commodore 64 Memory Maps.txt</a> by anonymous.</li><li>Reference by <a href="https://www.atarimagazines.com/compute/issue29/394_1_COMMODORE_64_MEMORY_MAP.php">Jim Butterfield</a> in COMPUTE! #29 (October 1982).</li></ul><p>You can enable and disable columns by clicking the checkboxes next to the sources, and you can expand/collapse all details with the corresponding button above the table. Here are four different expanded explanations of the <code>STATUS</code> byte:</p><p><img src="docs/c64mem/c64mem-2.png" height="213" width="715" alt="" /></p><p>And here is the collapsed version of the range $2B-$48, comparing the comments in the original sources with the Programmer’s Reference Manual:</p><p><img src="docs/c64mem/c64mem-3.png" height="132" width="595" alt="" /></p><p>The symbols (second column) are taken from the original sources. Sometimes, a single memory location has several meanings and thus several symbols. Some descriptions have been adapted to describe the different meanings independently:</p><p><img src="docs/c64mem/c64mem-4.png" height="78" width="500" alt="" /></p><p>KERNAL and BASIC ROM addresses link to the respective spots in the disassembly:</p><p><img src="docs/c64mem/c64mem-5.png" height="123" width="559" alt="" /></p><p>And in the disassembly, zero page addresses (like <code>$CC</code>) and symbols (like <code>BLNSW</code>) link back to the memory map:</p><p><img src="docs/c64mem/c64mem-6.png" height="84" width="483" alt="" /></p><p>The memory map table is generated from independent formatted ASCII files that look like this:</p><p><img src="docs/c64mem/c64mem-7.png" height="286" width="534" alt="" /></p><p>It consists of three columns: the address range in hex, the symbol name and the description in MarkDown format.</p><p>The Ultimate C64 Reference is being developed as an open source project at <a href="https://github.com/mist64/c64ref">github.com/mist64/c64ref</a> – contributions in the form of additions, corrections etc. are welcome!</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1397</wfw:commentRss> <slash:comments>8</slash:comments> </item> <item> <title>Typos in the C64 Programmer’s Reference Guide: C3PO or C3P0?</title> <link>https://www.pagetable.com/?p=1391</link> <comments>https://www.pagetable.com/?p=1391#comments</comments> <pubDate>Sun, 10 May 2020 19:23:36 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Archeology]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[KERNAL]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1391</guid> <description><![CDATA[The Commodore 64 Programmer’s Reference Guide contains a memory map with a complete description of the zeropage and system variables used by KERNAL and BASIC, but now that we have the original source, we know there are three typos in this table. C3P0 The first one is the symbol at address $94. Here is the ... <a title="Typos in the C64 Programmer’s Reference Guide: C3PO or C3P0?" class="read-more" href="https://www.pagetable.com/?p=1391">Read more<span class="screen-reader-text">Typos in the C64 Programmer’s Reference Guide: C3PO or C3P0?</span></a>]]></description> <content:encoded><![CDATA[<p>The <a href="https://archive.org/details/c64-programmer-ref/">Commodore 64 Programmer’s Reference Guide</a> contains a memory map with a complete description of the zeropage and system variables used by KERNAL and BASIC, but now that we have the <a href="https://github.com/mist64/cbmsrc">original source</a>, we know there are three typos in this table.</p><h2 id="c3p0">C3P0</h2><p>The first one is the symbol at address $94. Here is the full page from the Programmer’s Reference Guide:</p><p><img src="docs/prg_typos/prg-04.png" height="726" width="423" alt="" /></p><p>If you look closely, the symbol at $94 is <code>C3PO</code>, with a capital Oh.</p><p><img src="docs/prg_typos/c3p0-prg.png" height="86" width="180" alt="" /></p><p>But it should end in a zero. Here is the original source:</p><p><img src="docs/prg_typos/c3p0-src.png" height="45" width="366" alt="" /></p><p>This is a <a href="https://www.pagetable.com/docs/C64_KERNAL_03_LST.pdf">printout of the original assembly log from 1983</a>:</p><p><img src="docs/prg_typos/c3p0-lst.png" height="30" width="404" alt="" /></p><p>On the kind of printer Commodore was using, there is no way to tell a <code>0</code> from an <code>O</code>. Here is the whole page for context:</p><p><img src="docs/prg_typos/kernal-001.png" height="566" width="400" alt="" /></p><p>The <a href="https://www.pagetable.com/?p=1135">Commodore Serial Bus</a> library uses <code>C3P0</code> to buffer a byte that is supposed to be sent to the bus – similar to the zero page location <code>R2D2</code> located at address $A3. Here is <a href="https://www.pagetable.com/c64disasm/#ED16">some code</a> that uses the two:</p><p><img src="docs/prg_typos/c3p0-r2d2.png" height="205" width="337" alt="" /></p><p>So yes, the two symbol names are references to the Star Wars characters C-3PO and R2-D2. It is unknown why the former is spelled with a zero in the source, but the typo in the Programmer’s Reference Guide is very forgivable.</p><p>Disappointingly, the <code>R2D2</code> symbol is not mentioned in the Programmer’s Reference Guide – $A3 is just part of a “Temp Data Area”:</p><p><img src="docs/prg_typos/a3.png" height="17" width="422" alt="" /></p><h2 id="bufpt">BUFPT</h2><p>The next typo is the symbol at address $A6, the tape buffer pointer:</p><p><img src="docs/prg_typos/bufpt-prg.png" height="18" width="423" alt="" /></p><p>The Reference Guide calls it <code>BUFPNT</code>, but it is in fact called <code>BUFPT</code>.</p><p><img src="docs/prg_typos/bufpt-lst.png" height="14" width="562" alt="" /></p><h2 id="lsxp">LSXP</h2><p>And the final typo is the symbol at $C9:</p><p><img src="docs/prg_typos/lsxp-prg.png" height="32" width="420" alt="" /></p><p>The correct spelling is <code>LSXP</code>:</p><p><img src="docs/prg_typos/lsxp-lst.png" height="29" width="484" alt="" /></p><p>In fact, in the source, the two bytes have individual labels, <code>LSXP</code> and <code>LSTP</code>. <code>LSXP</code> is the cursor line, and <code>LSTP</code> the cursor column in the context of inputting text, shadowing the zero page addresses <code>TBLX</code> (line) and <code>PNTR</code> (column). The following table summarizes this:</p><table><thead><tr><th> </th><th> Generic </th><th> Input </th></tr></thead><tbody><tr><td> Column </td><td> <code>PNTR</code> </td><td> <code>LSTP</code> </td></tr><tr><td> Line </td><td> <code>TBLX</code> </td><td> <code>LSXP</code> </td></tr></tbody></table><p>It is confusing that the symbols for the Y coordinates each contain an <code>X</code>. It is unclear what these symbol names are supposed to mean in the first place – if you have any idea, please share them in the comments!</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1391</wfw:commentRss> <slash:comments>3</slash:comments> </item> <item> <title>Dumping MiniDisc Media</title> <link>https://www.pagetable.com/?p=1384</link> <comments>https://www.pagetable.com/?p=1384#comments</comments> <pubDate>Fri, 27 Mar 2020 06:41:56 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Archeology]]></category> <category><![CDATA[Floppy Disks]]></category> <category><![CDATA[Hacks]]></category> <category><![CDATA[Hardware]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1384</guid> <description><![CDATA[Update 2022: Web MiniDisc Pro can access NetMD devices through the browser and can also download protected files! If you have music on a collection of MiniDisc media and want to finally copy the data off onto modern media (or the cloud!), here are simple instructions for some different solutions: MZ-RH1 and NetMDPython MZ-RH1 and ... <a title="Dumping MiniDisc Media" class="read-more" href="https://www.pagetable.com/?p=1384">Read more<span class="screen-reader-text">Dumping MiniDisc Media</span></a>]]></description> <content:encoded><![CDATA[<p><big><b><font color="red">Update 2022: <a href="https://web.minidisc.wiki/">Web MiniDisc Pro</a> can access NetMD devices through the browser and can also download protected files!</font></b></big></p><hr/><p>If you have music on a collection of MiniDisc media and want to finally copy the data off onto modern media (or the cloud!), here are simple instructions for some different solutions:</p><ul><li>MZ-RH1 and NetMDPython</li><li>MZ-RH1 and SonicStage</li><li>Analog Copy</li><li>Bonus: Recovering Deleted Tracks</li></ul><h2 id="mz-rh1-and-netmdpython">MZ-RH1 and NetMDPython</h2><p>The best device for digitally dumping MiniDiscs is Sony’s last (and best) MiniDisc recorder, the portable MZ-RH1. Unfortunately, this makes it quite pricy on the used market these days – but you can (and should!) always sell it after you’re done dumping your media…</p><h3 id="dumping">Dumping</h3><p>The <a href="https://wiki.physik.fu-berlin.de/linux-minidisc/doku.php?id=netmdpython">NetMDPython</a> set of scripts can copy the original <a href="https://en.wikipedia.org/wiki/Adaptive_Transform_Acoustic_Coding">ATRAC1</a>-encoded bitstreams off MiniDiscs. You can run it on Windows, macOS or Linux. I will describe the Linux steps with Ubuntu – I would advise Windows and Mac users to set up a virtual machine with Ubuntu, since this is the most reliable way.</p><ul><li><p>First, you need to make sure that you have Git, Python 2 (with crypto support) and libusb installed:</p><pre><code> sudo apt-get install git python2 python-crypto libusb-dev</code></pre></li><li><p>Then, get the source from the <em>linux-minidisc</em> project:</p><pre><code> git clone https://github.com/glaubitz/linux-minidisc.git</code></pre></li><li><p>The tools are in <code>linux-minidisc/netmd</code></p><pre><code> cd linux-minidisc/netmd</code></pre></li><li><p>Connect your MZ-RH1 to the (virtual) machine, but do not insert a MiniDisc yet. The Linux <code>usb-storage</code> driver would claim any inserted media, so that the tools wouldn’t be able to access it any more. Therefore, you need to remove the <code>usb-storage</code> driver:</p><pre><code> sudo modprobe -r usb-storage</code></pre></li><li><p>Now make sure that the MZ-RH1 shows up:</p><pre><code> sudo ./lsusb.py [...] Bus 002 Device 006: ID 054c:0286 Sony Net MD/Hi-MD [...]</code></pre></li><li><p>If your device is detected, you can list the contents of the MiniDisc like this:</p><pre><code> sudo ./lsmd.py Disk (writable media) We Are The Night Time used: 01:09:50+032 (87.14%) 14 tracks 000: 00:01:04+027 sp stereo unprotected No Path To Follow 001: 00:06:33+039 sp stereo unprotected We Are The Night [...]</code></pre></li><li><p>You can dump the whole media like this:</p><pre><code> sudo ./upload.py Storing in We Are The Night Uploading ./01 - No Path To Follow.aea Done: 10000/1a51a0 (3.80%) Done: 20000/1a51a0 (7.60%) Done: 30000/1a51a0 (11.40%) [...]</code></pre></li></ul><h3 id="converting-atrac1-files">Converting ATRAC1 Files</h3><p>The resulting files are in <code>.aea</code> format, which is the raw data from the MiniDisc, encoded in the ATRAC1 format.</p><p>You can convert them to any other audio format using <em>ffmpeg</em>:</p><pre><code> ffmpeg -i file.aea file.wav # decompression ffmpeg -i file.aea file.mp3 # lossy recompression ffmpeg -i file.aea file.m4a # lossy recompression</code></pre><h3 id="limitations">Limitations</h3><p><em>NetMDPython</em> can not dump tracks that are marked “protected”. This includes all tracks on pressed MiniDiscs, tracks that have been copied from a digital master, and tracks written with the PC software (<em>SonicStage</em>).</p><h2 id="mz-rh1-and-sonicstage">MZ-RH1 and SonicStage</h2><p>Sony’s <em>SonicStage</em> software is an iTunes-like application for Windows that can, among many many other things, transfer most tracks from MiniDisc to the PC’s hard disk.</p><p>(The last version is 4.3; the screenshots are showing 3.4. I recommend Windows XP; newer versions might work as well.)</p><ul><li>Navigate to the “Transfer” Tab. Your MZ-RH1 should show up in the pane on the right.</li></ul><p><img src="docs/dumping_md/sonicstage1.png" height="384" width="512" alt="" /></p><ul><li>By default, <em>SonicStage</em> will recompress dumped data as ATRAC3+. To make sure you don’t lose any sound quality, press the toolbox icon, select “Advanced…” and “Import Settings”, and set the format for importing non-MDLP tracks to “PCM”:</li></ul><p><img src="docs/dumping_md/sonicstage2.png" height="380" width="516" alt="" /><br /><img src="docs/dumping_md/sonicstage3.png" height="507" width="460" alt="" /></p><ul><li>Now you can drag and drop tracks from the right pane to the left one. Right clicking a track on the left and selecting “Properties…” will reveal the location of the file in the filesystem.</li></ul><h3 id="converting-oma-files">Converting OMA Files</h3><p>The resulting files are in OpenMG Audio (<code>.oma</code>) format, which is Sony’s container format that can contain audio data encoded with one of a number of different codecs. Since we changed the import settings to PCM, they will basically be the same as umcompressed WAV/AIFF files (44.1/2/16), just in a different container.</p><p><em>ffmpeg</em> can also convert <code>.oma</code> files into any other audio format:</p><pre><code> ffmpeg -i file.oma file.wav # lossless container conversion ffmpeg -i file.oma file.mp3 # lossy recompression ffmpeg -i file.oma file.m4a # lossy recompression</code></pre><h3 id="limitations">Limitations</h3><p><em>SonicStage</em> does not allow dumping the raw ATRAC1-encoded data from the MiniDisc, it always decodes it and stores it in a different format. When decoding to PCM, as shown above, there is no quality loss.</p><p>Unlike <em>NetMDPython</em>, <em>SonicStage</em> can dump protected tracks from pressed MiniDiscs, but it also cannot dump tracks that have been copied digitally from a CD, as well as tracks it has written itself – unless it was from the same computer.</p><h2 id="analog-copy">Analog Copy</h2><p>If all else fails, you can always make an analog copy of the audio on a MiniDisc. After all, the kinds of MiniDiscs you care about are probably not digital copies of CDs (you should rather find the original CDs then), but recordings from analog sources anyway – so the extra added noise should be negligible.</p><p>The most basic way to make an anlog copy is to connect any MiniDisc player to a computer and using <a href="Audacity">https://www.audacityteam.org</a> for recording. Since modern computers have many things going on at once, you might get skips while recording, so you need to make sure that there is as little load on the computer as possible.</p><p>If you have an MZ-RH1 and a second MiniDisc player, you could also connect the two and have the MZ-RH1 record the MiniDisc in the second player onto a 1 GB Hi-MD – uncompressed. You can then use <em>SonicStage</em> or the platform-independent <a href="https://wiki.physik.fu-berlin.de/linux-minidisc/doku.php?id=qhimdtransfer">QHiMDTransfer</a> to copy the file(s) over.</p><p>The nicest solution is the <code>dump_md.py</code> script from the <a href="https://wiki.physik.fu-berlin.de/linux-minidisc/doku.php?id=netmdpython">NetMDPython</a> project, which can remote-control any NetMD-compliant MiniDisc player (such as the MZ-RH1) and record the analog output through the sound card. This way, the audio will be copied as individual tracks.</p><h2 id="bonus:-recovering-deleted-tracks">Bonus: Recovering Deleted Tracks</h2><p>MiniDiscs allow arbitrarily deleting tracks, and recording new tracks in their place. This is made possible by the TOC: a global data structure that points to the sections on the media that make up the tracks.</p><p>When deleting a track, or the entire MiniDisc, the audio data is not touched, only the TOC is modified. By hacking the TOC, it is possible to access all raw data on the media.</p><p>Here are the steps: (This is based on the <a href="https://www.minidisc.org/conner/MD-MT15_TOC_cloning.htm">TOC Cloning</a> trick.)</p><ul><li>Locate your recorder’s door detection switch. On the SHARP MD-MT15, it is here:</li></ul><p><img src="docs/dumping_md/recover1.jpg" height="330" width="440" alt="" /></p><ul><li>Find a way to keep the switch constantly depressed. In the case of the MD-MT15, you can use part of a toothpick to keep it down.</li></ul><p><img src="docs/dumping_md/recover2.jpg" height="330" width="440" alt="" /></p><ul><li>Take a <em>spare</em> MiniDisc that is at least the same size (60/74/80) as the one you want to recover.</li><li>Erase the whole <em>spare</em> MiniDisc. (Don’t erase single tracks!)</li><li>Record silence until the whole disk is full.</li><li>Remove the <em>spare</em> MiniDisc and take take the batteries out of the recorder.</li><li>Insert the <em>spare</em> MiniDisc and put the batteries back in. The media should be detected correctly.</li><li>Now replace the <em>spare</em> MiniDisc with the one you want to recover. The recorder should not notice that the door has been opened and will not re-read the TOC.</li><li>Press play. The whole 60/74/80 minutes of raw audio data should now play.</li></ul>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1384</wfw:commentRss> <slash:comments>8</slash:comments> </item> <item> <title>The Ultimate Acorn Archimedes Talk [video]</title> <link>https://www.pagetable.com/?p=1381</link> <comments>https://www.pagetable.com/?p=1381#comments</comments> <pubDate>Mon, 30 Dec 2019 00:09:06 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Archeology]]></category> <category><![CDATA[Presentation]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1381</guid> <description><![CDATA[Matt Evans presented “The Ultimate Acorn Archimedes Talk”, the 8th talk in the “Ultimate Talk” series, at the 36th Chaos Communication Congress (36C3). Here is the video:]]></description> <content:encoded><![CDATA[<p><a href="https://axio.ms">Matt Evans</a> presented “The Ultimate Acorn Archimedes Talk”, the 8th talk in the “Ultimate Talk” series, at the 36th Chaos Communication Congress (36C3).</p><p><img src="docs/ultimate8.png" width="640" height="360"/></p><p>Here is the video:</p><p><iframe width="600" height="338" src="https://www.youtube.com/embed/Hf67JYkUCHQ?feature=oembed" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe></p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1381</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item> <title>Commander X16: Philosophy and Specification</title> <link>https://www.pagetable.com/?p=1373</link> <comments>https://www.pagetable.com/?p=1373#comments</comments> <pubDate>Fri, 18 Oct 2019 11:45:31 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[X16]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1373</guid> <description><![CDATA[I recently got involved in the Commander X16 project. I would like to give an overview of the project and the vision behind it from my perspective. Philosophy The Commander X16 is a new 8 bit computer designed by David Murray of the well-known “The 8-Bit Guy” online video channel. 8 bit computers are great ... <a title="Commander X16: Philosophy and Specification" class="read-more" href="https://www.pagetable.com/?p=1373">Read more<span class="screen-reader-text">Commander X16: Philosophy and Specification</span></a>]]></description> <content:encoded><![CDATA[<p>I recently got involved in the Commander X16 project. I would like to give an overview of the project and the vision behind it from my perspective.</p><h2 id="Philosophy">Philosophy</h2><p>The Commander X16 is a new 8 bit computer designed by David Murray of the well-known <a href="https://www.youtube.com/channel/UC8uT9cgJorJPWu7ITLGo9Ww">“The 8-Bit Guy” online video channel</a>.</p><p>8 bit computers are great for learning about computer architecture, because they are simple enough that they can be fully understood, and they are great for learning to program, because they boot straight into a programming language. But 8 bit computers also have some annoyances like cheap, non-standard keyboards, TV-out and the reliance on floppy disks (or rather expensive SD card adapters).</p><p>Therefore, David is designing a new 8 bit computer in the style of Commodore computers like the VIC-20 and the C64, fixing the annoyances of retro computers by having:</p><ul><li>VGA output (in addition to composite)</li><li>support for standard PS/2 keyboards (instead of a cheap built-in keyboard with a non-standard layout)</li><li>SD card for storage (instead of an additional floppy drive)</li><li>RS232 port for efficient cross-developmment</li><li>efficient modern power supply</li></ul><p>Another problem with retro computers nowadays is the high barrier of entry when developing (semi-)professional software: Since retro computers have been researched for almost 40 years, standards for software are very high. Any credible new game release for the C64 for example will have to come with a fastloader to overcome slow load speeds, and a sprite multiplexer to overcome the 8 sprite limit. The X16 ROM supports fast loading from SD card, and its video chip supports plenty of sprites as well as hardware scrolling of bitmaps. The memory map is kept simple and does not need (or support) complex reconfigurations.</p><p>With a rather modest set of hardware features, the X16 targets a lower price point than most comparable projects.</p><p>These are the original videos on the topic:</p><ul><li><a href="https://www.youtube.com/watch?v=ayh0qebfD2g">The 8-Bit Guy: My dream computer – Part 1</a></li><li><a href="https://www.youtube.com/watch?v=sg-6Cjzzg8s">The 8-Bit Guy: My dream computer – Part 2</a></li></ul><h2 id="Hardware">Hardware</h2><p>These are the hardware specs:</p><ul><li>65C02 CPU at 8 MHz</li><li>40 KB of main RAM</li><li>512 KB (or 2 MB) of banked RAM</li><li>128 KB of banked ROM</li><li>VERA video controller<ul><li>16-bit class</li><li>128 KB of external video RAM</li><li>640×480 (or 320×240) pixels</li><li>256 colors out of 4096</li><li>2 layers supporting tiled and bitmap modes</li><li>128 sprites (limit per line based on memory bandwidth)</li></ul></li><li>sound TBD</li><li>two 6522 VIA I/O controllers</li></ul><p>The computer supports the following connections:</p><ul><li>VGA (480p), or Composite/RGB (480i)</li><li>PS/2 keyboard</li><li>PS/2 mouse</li><li>two NES or SNES controllers</li><li>SD card</li><li>legacy IEC</><li>RS-232</li></ul><p>The X16 is not an FPGA-based solution, but uses real, socketed 65C02 and 6522 chips for the same hackability as a retro computer. The video chip is a new design and comes as an FPGA.</p><h2 id="Software">Software</h2><p>From the software side, the Commander X16 feels like a Commodore computer. Its ROM contains the “KERNAL” operating system derived from the C64 version, as well as an enhanced version of Commodore/Microsoft BASIC based on V2.</p><p><img src="docs/x16/hello_world.gif" alt="" /></p><p>Consequently, the X16 can be considered a sibling of the computers from the Commodore 8 bit family (PET, VIC-20, C64, CBM2, Plus/4, C128 and C65). It is not meant to be fully compatible with any of these machines, but it is as compatible as a Plus/4 is with a C64: BASIC programs without PEEK and POKE as well as machine code programs that only use the documented KERNAL API (e.g. BSOUT $FFD2) will just work, but existing code that accesses hardware would have to be ported.</p><p>The fact that the X16 breaks compatibility with the C64 is what I find particular interesting. Most retro projects try to recreate a classic computer. Users will start their favorite two games and then get bored. The X16 is a new system, with new tricks to discover – but familiar to people who know the C64.</p><h2 id="Development">Development</h2><p>As of October 2019, only a handful of prototype machines exist. If you don’t want to wait for the release hardware, you can use the emulator:</p><p><a href="https://github.com/commanderx16/x16-emulator/">https://github.com/commanderx16/x16-emulator/</a></p><p>There are binary releases for macOS, Windows and Linux on the GitHub releases page, which always include the latest build of the ROM.</p><p>The ROM is being developed as open source:</p><p><a href="https://github.com/commanderx16/x16-rom/">https://github.com/commanderx16/x16-rom/</a></p><p>The reference guide is worked on as an open source project as well:</p><p><a href="https://github.com/commanderx16/x16-docs/">https://github.com/commanderx16/x16-docs/</a></p><p>And here is a collection of demo/example code contributed to by many people:</p><p><a href="https://github.com/commanderx16/x16-demo/">https://github.com/commanderx16/x16-demo/</a></p><p><strike>The <a href="https://www.facebook.com/groups/CommanderX16/">official forum</a> is <a href="https://en.wikipedia.org/wiki/Surveillance_capitalism">unfortunately</a> hosted on Facebook, but there is a lot going on: Users show off programs they have written and discuss programming questions. There is also <a href="https://murray2.com/forums/commander-x16.9/">a forum on David Murray’s website</a>.</strike></p><p>The official forum is at <a href="https://www.commanderx16.com/forum/">commanderx16.com</a>, with people discussing programming questions and showing off new programs.</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1373</wfw:commentRss> <slash:comments>24</slash:comments> </item> <item> <title>NES and SNES Controllers on a 6502 (like the C64)</title> <link>https://www.pagetable.com/?p=1365</link> <comments>https://www.pagetable.com/?p=1365#comments</comments> <pubDate>Sat, 10 Aug 2019 22:52:50 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[GitHub]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1365</guid> <description><![CDATA[NES and SNES controllers support 8 to 12 buttons with only three data pins (plus VCC/GND). Let’s attach them to a C64 – or any 6502-based system! NES Connector The NES controller needs to be connected to +5V, GND and three GPIOs. ---------- | 5 6 7 \ | 4 3 2 1 | ------------ ... <a title="NES and SNES Controllers on a 6502 (like the C64)" class="read-more" href="https://www.pagetable.com/?p=1365">Read more<span class="screen-reader-text">NES and SNES Controllers on a 6502 (like the C64)</span></a>]]></description> <content:encoded><![CDATA[<p>NES and SNES controllers support 8 to 12 buttons with only three data pins (plus VCC/GND). Let’s attach them to a C64 – or any 6502-based system!</p><p><a href="docs/nes_snes_controller_6502/nes_snes_controller_6502.jpg"><img src="docs/nes_snes_controller_6502/nes_snes_controller_6502_small.jpg" alt="" /></a></p><h2 id="NES-Connector">NES Connector</h2><p>The NES controller needs to be connected to +5V, GND and three GPIOs.</p><pre><code> ---------- | 5 6 7 \ | 4 3 2 1 | ------------</code></pre><table><thead><tr><th> Pin </th><th> Description </th></tr></thead><tbody><tr><td> 1 </td><td> GND </td></tr><tr><td> 2 </td><td> CLK </td></tr><tr><td> 3 </td><td> LATCH </td></tr><tr><td> 4 </td><td> DATA </td></tr><tr><td> 5 </td><td> – </td></tr><tr><td> 6 </td><td> – </td></tr><tr><td> 7 </td><td> +5V </td></tr></tbody></table><h2 id="SNES-Connector">SNES Connector</h2><p>The SNES controller’s pins are just like the NES controller’s, but with a different connector.</p><pre><code> /--------------------- | 7 6 5 | 4 3 2 1 | \---------------------</code></pre><table><thead><tr><th> Pin </th><th> Description </th></tr></thead><tbody><tr><td> 1 </td><td> +5V </td></tr><tr><td> 2 </td><td> CLK </td></tr><tr><td> 3 </td><td> LATCH </td></tr><tr><td> 4 </td><td> DATA </td></tr><tr><td> 5 </td><td> – </td></tr><tr><td> 6 </td><td> – </td></tr><tr><td> 7 </td><td> GND </td></tr></tbody></table><h2 id="User-Port">User Port</h2><p>The C64 User Port exposes, among other lines, +5V, GND and 8 GPIOs (CIA#2 Port B):</p><pre><code> 1 | 2 3 4 5 6 7 8 9 10 | 11 12 --- ---------------------------- ------- A | B C D E F H J K L | M N</code></pre><p>(viewed towards the C64 edge connector)</p><table><thead><tr><th> Pin </th><th> Description </th></tr></thead><tbody><tr><td> 1 </td><td> GND </td></tr><tr><td> 2 </td><td> +5V </td></tr><tr><td> C </td><td> PB0 </td></tr><tr><td> D </td><td> PB1 </td></tr><tr><td> E </td><td> PB2 </td></tr><tr><td> F </td><td> PB3 </td></tr><tr><td> H </td><td> PB4 </td></tr><tr><td> J </td><td> PB5 </td></tr><tr><td> K </td><td> PB6 </td></tr><tr><td> L </td><td> PB7 </td></tr></tbody></table><h2 id="Connection">Connection</h2><p>Let’s semi-arbitrarily map the signals like this:</p><table><thead><tr><th> GPIO </th><th> Description </th></tr></thead><tbody><tr><td> PB3 </td><td> LATCH (for both controllers) </td></tr><tr><td> PB4 </td><td> DATA (controller 1) </td></tr><tr><td> PB5 </td><td> CLK (for both controllers) </td></tr><tr><td> PB6 </td><td> DATA (controller 2) </td></tr></tbody></table><p>The latch and clock outputs go to both controllers. There is a data line for each controller.</p><p>So the connection diagram for two NES controllers looks like this:</p><table><thead><tr><th> Description </th><th> User Port Pin </th><th> NES #1 Pin </th><th> NES #2 Pin </th><th> Color </th></tr></thead><tbody><tr><td> GND </td><td> 1 </td><td> 1 </td><td> 1 </td><td> black </td></tr><tr><td> +5V </td><td> 2 </td><td> 7 </td><td> 7 </td><td> red </td></tr><tr><td> LATCH </td><td> F </td><td> 3 </td><td> 3 </td><td> blue </td></tr><tr><td> DATA#1 </td><td> H </td><td> 4 </td><td> – </td><td> green </td></tr><tr><td> CLK </td><td> J </td><td> 2 </td><td> 2 </td><td> white </td></tr><tr><td> DATA#2 </td><td> K </td><td> – </td><td> 4 </td><td> yellow </td></tr></tbody></table><p>And this is the same diagram for two SNES controllers:</p><table><thead><tr><th> Description </th><th> User Port Pin </th><th> NES #1 Pin </th><th> NES #2 Pin </th><th> Color </th></tr></thead><tbody><tr><td> GND </td><td> 1 </td><td> 7 </td><td> 7 </td><td> black </td></tr><tr><td> +5V </td><td> 2 </td><td> 1 </td><td> 1 </td><td> red </td></tr><tr><td> LATCH </td><td> F </td><td> 3 </td><td> 3 </td><td> blue </td></tr><tr><td> DATA#1 </td><td> H </td><td> 4 </td><td> – </td><td> green </td></tr><tr><td> CLK </td><td> J </td><td> 2 </td><td> 2 </td><td> white </td></tr><tr><td> DATA#2 </td><td> K </td><td> – </td><td> 4 </td><td> yellow </td></tr></tbody></table><p>In fact, you can attach an NES and an SNES controller in parallel for each of the two slots, as long as you ever only connect one controller per slot.</p><p>This is the user port connector with wires attached for two controllers, using the color scheme above:</p><p><a href="docs/nes_snes_controller_6502/userport_connector.jpg"><img src="docs/nes_snes_controller_6502/userport_connector_small.jpg" alt="" /></a></p><p>This is an NES connector attached as the first controller (green data line):</p><p><a href="docs/nes_snes_controller_6502/nes_connector.jpg"><img src="docs/nes_snes_controller_6502/nes_connector_small.jpg" alt="" /></a></p><p>And this is an SNES connector attached as the second controller (yellow data line):</p><p><a href="docs/nes_snes_controller_6502/snes_connector.jpg"><img src="docs/nes_snes_controller_6502/snes_connector_small.jpg" alt="" /></a></p><h2 id="The-Code">The Code</h2><p>The code to read both controllers at a time is pretty simple:</p><pre><code>; C64 CIA#2 PB nes_data = $dd01 nes_ddr = $dd03 ;bit_latch = $08 ; PB3 (user port pin F): LATCH (both controllers) bit_data1 = $10 ; PB4 (user port pin H): DATA (controller #1) bit_clk = $20 ; PB5 (user port pin J): CLK (both controllers) bit_data2 = $40 ; PB6 (user port pin K): DATA (controller #2) ; zero page controller1 = $e0 ; 3 bytes controller2 = $f0 ; 3 bytes query_controllers: lda #$ff-bit_data1-bit_data2 sta nes_ddr lda #$00 sta nes_data ; pulse latch lda #bit_latch sta nes_data lda #0 sta nes_data ; read 3x 8 bits ldx #0 l2: ldy #8 l1: lda nes_data cmp #bit_data2 rol controller2,x and #bit_data1 cmp #bit_data1 rol controller1,x lda #bit_clk sta nes_data lda #0 sta nes_data dey bne l1 inx cpx #3 bne l2 rts</code></pre><p>After calling <code>query_controllers</code>, three bytes each at <code>controller1</code> and <code>controller2</code> will contain the state:</p><pre><code>; byte 0: | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ; NES | A | B |SEL|STA|UP |DN |LT |RT | ; SNES | B | Y |SEL|STA|UP |DN |LT |RT | ;; byte 1: | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ; NES | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ; SNES | A | X | L | R | 1 | 1 | 1 | 1 | ; byte 2: ; $00 = controller present ; $FF = controller not present</code></pre><p>A 0 bit means the button is pressed, 1 means it is released.</p><p>The code pulses LATCH once, which makes the controllers sample their button states and transmit the first bit through their respective DATA lines. Pulsing CLK 15 more times will make the controllers send the remaining bits. Since SNES controllers send 16 bits of data, but NES controllers only send 8 bits, the type of controller can be detected through the lowermost nybble of byte 1. Similarly, the presense of a controller is detected by continuing to read bits: If a controller is attached, it will send 0 bits.</p><h2 id="Repository">Repository</h2><p>The driver code, together with demo code for the C64 can be found at <a href="https://github.com/mist64/nes_snes_controller_6502">https://github.com/mist64/nes_snes_controller_6502</a>.</p><p><a href="docs/nes_snes_controller_6502/demo.png"><img src="docs/nes_snes_controller_6502/demo.png" alt="" /></a></p><h2 id="More?">More?</h2><p>For each additional controller, only a single extra GPIO is needed. This way, six controllers would be possible on a single 8 bit I/O port, with only slightly modified code.</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1365</wfw:commentRss> <slash:comments>11</slash:comments> </item> <item> <title>The Apollo Guidance Computer [video + slides]</title> <link>https://www.pagetable.com/?p=1362</link> <comments>https://www.pagetable.com/?p=1362#respond</comments> <pubDate>Sun, 04 Aug 2019 21:28:19 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Archeology]]></category> <category><![CDATA[Presentation]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1362</guid> <description><![CDATA[I re-did an updated version of my part of the Ultimate Apollo Guidance Computer Talk at VCF West 2019. It was followed by Frank O’Brien‘s talk on the role of the AGC in the Apollo missions. Here is the video: And here are my slides in PDF format: AGC_CHM.pdf (43 MB)]]></description> <content:encoded><![CDATA[<p>I re-did an updated version of my part of the <a href="https://www.pagetable.com/?p=922">Ultimate Apollo Guidance Computer Talk</a> at VCF West 2019.</p><p>It was followed by <a href="https://www.amazon.com/Apollo-Guidance-Computer-Architecture-Operation/dp/1441908765">Frank O’Brien</a>‘s talk on the role of the AGC in the Apollo missions.</p><p>Here is the video:</p><p><iframe width="600" height="450" src="https://www.youtube.com/embed/Nidi2p_PAJM?feature=oembed" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe></p><p>And here are my slides in PDF format:</p><p><a href="docs/agc/AGC_CHM.pdf">AGC_CHM.pdf</a> (43 MB)</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1362</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>Visualizing Commodore 1541 Disk Contents – Part 2: Errors</title> <link>https://www.pagetable.com/?p=1356</link> <comments>https://www.pagetable.com/?p=1356#comments</comments> <pubDate>Wed, 29 May 2019 07:17:55 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Archeology]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Floppy Disks]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1356</guid> <description><![CDATA[We have previously visualized the physical layout of C64/1541 disks. In order to understand the encoding and potential read errors, it is more useful to visualize the disks sector-by-sector. This animation shows 12 regular disks. (Click for original size.) Every pack of 17-21 lines is a track, numbered 1-41. Every line within a pack is ... <a title="Visualizing Commodore 1541 Disk Contents – Part 2: Errors" class="read-more" href="https://www.pagetable.com/?p=1356">Read more<span class="screen-reader-text">Visualizing Commodore 1541 Disk Contents – Part 2: Errors</span></a>]]></description> <content:encoded><![CDATA[<p>We have previously <a href="https://www.pagetable.com/?p=1070">visualized the physical layout of C64/1541 disks</a>. In order to understand the encoding and potential read errors, it is more useful to visualize the disks sector-by-sector.</p><p><a href="docs/visualize_1541_2/good_disks.gif"><img src="docs/visualize_1541_2/good_disks.gif" alt="" /></a></p><p>This animation shows 12 regular disks. (Click for original size.)</p><ul><li>Every pack of 17-21 lines is a track, numbered 1-41.</li><li>Every line within a pack is one sector.</li><li>The raw sector contents are drawn from left to right.</li><li>The cyan part is the header, the green part the data.</li><li>Black is 0, cyan/green is 1.</li><li>White represents missing header or sector sections.</li></ul><p>The tool to generate these images from <code>.G64</code> files is available at <a href="https://github.com/mist64/visualize_1541">https://github.com/mist64/visualize_1541</a>.</p><h2 id="Header">Header</h2><p>Let us look at the header first. Here is an animation of the header of tracks 23 to 25 of a few disks:</p><p><a href="docs/visualize_1541_2/headers.gif"><img src="docs/visualize_1541_2/headers.gif" height="264" width="512" alt="" /></a><br /><img src="docs/visualize_1541_2/header.png" height="52" width="512" alt="" /></p><p>The header contains six data bytes encoded using the <a href="https://www.linusakesson.net/programming/gcr-decoding/">4-to-5 GCR scheme</a>:</p><ul><li><strong>H: Header Code</strong>: Every header starts with 0x08 so it can be distinguished from the sector data (0x07). You can see that it is the same bit pattern on all sectors on all tracks.</li><li><strong>T: Track</strong>: This is the track number (1-35). It is the same for all sectors on the same track.</li><li><strong>S: Sector</strong>: This is the sector number (0-16/17/18/20, depending on the track). You can see the same bit patterns on each of the three tracks shown.</li><li><strong>ID: ID</strong>: The two-byte ID should be unique per disk and is used to detect disk changes. It is the same for all sectors on the same disk.</li><li><strong>C: Checksum</strong>: The checksum is the XOR of C, S, T and ID, so you can see it behaves kind of randomly in the animation above.</li><li><strong>GAP</strong>: The gap does not contain usable data, but separates the header from the sector data.</li></ul><h2 id="Data">Data</h2><p><a href="docs/visualize_1541_2/data.gif"><img src="docs/visualize_1541_2/data.gif" height="264" width="512" alt="" /></a></p><p>The first byte of the data section is the code 0x07 to distinguish it from a header. The rest is the 256 data bytes. The Commodore DOS filesystem uses two link bytes (next track, next sector) at the beginning of every sector, which is why the next two bytes in this visualization look more regular between disks.</p><h2 id="Good-Disks">Good Disks</h2><p>First, let’s look at some error-free disks in practice.</p><h3 id="Empty-Disk">Empty Disk</h3><p>An empty disk looks quite uniform: (Click for original size.)</p><p><a href="docs/visualize_1541_2/empty.png"><img src="docs/visualize_1541_2/empty.png" alt="" /></a></p><p>Only sectors 0 and 1 of track 18 look different:</p><p><a href="docs/visualize_1541_2/empty18.png"><img src="docs/visualize_1541_2/empty18.png" height="46" width="600" alt="" /></a></p><p>18/0 contains the block allocation map (BAM) and the name of the disk, and 18/1 contains the first 8 directory entries.</p><h3 id="Illegal-Bits">Illegal Bits</h3><p>The last few bits of the end of the header are also different for sectors 0 and 1. The headers of all sectors directly after formatting the disk end in a pattern of alternating zeros and ones, but as soon as a sector has been written to, this is no longer the case for the last few bits. It gets even more interesting when visualizing these bits across several reads of <strong>the same disk</strong>:</p><p><a href="docs/visualize_1541_2/empty18.gif"><img src="docs/visualize_1541_2/empty18.gif" height="92" width="704" alt="" /></a></p><p>These are unstable illegal bits on disk, bits that sometimes read back as zeros and sometimes as ones.</p><p>When writing a sector, the software in the disk drive waits for the correct sector header to pass by the read head, then waits until the exact end of the header gap area, and starts writing the new data. When switching to write mode, the magnetization written onto the media for the first ~15 µs (4-5 bits) will be analog values between logical 0 and 1. These are technically illegal values, and will be unstable when read.</p><p><a href="docs/visualize_1541_2/illegal_bits.png"><img src="docs/visualize_1541_2/illegal_bits.png" alt="" /></a></p><p>These illegal bits are benign, because they do not encode anything. But it is important to note that two reads of a good disk may not be identical.</p><h2 id="Errors">Errors</h2><p>Now, let’s look at what common errors look like:</p><h3 id="Logical-Errors">Logical Errors</h3><p>Some read errors are caused by buggy software writing to disk: (Click for original size.)</p><p><a href="docs/visualize_1541_2/missing_headers.png"><img src="docs/visualize_1541_2/missing_headers.png" alt="" /></a></p><p>This disk is missing some sector headers:</p><p><a href="docs/visualize_1541_2/missing_headers_detail.png"><img src="docs/visualize_1541_2/missing_headers_detail.png" height="46" width="600" alt="" /></a></p><p>This is one of the <a href="https://www.pagetable.com/?p=1128">faulty GEOS boot disks</a>: Some sectors were written with the wrong speed zone setting, so they spilled into the next header, overwriting it. The sector contents are still there, but the missing header makes them unreadable with the original Commodore DOS. (The visualization tool will guess the sector number in case of a sector with a missing header.)</p><h3 id="Dropouts">Dropouts</h3><p> <!-- sh42b.nbz --></p><p>There is an example of a dropout:</p><p><a href="docs/visualize_1541_2/dirt.png"><img src="docs/visualize_1541_2/dirt.png" height="264" width="512" alt="" /></a></p><p>There is one sector that starts reading back as all 0 bits (black) at some point, and the next sector data is completely missing (white), which is because the SYNC mark of the next sector was not readable.</p><p>This can be caused by demagnetization, or more likely, by dirt on the disk’s surface. Sometimes, the dirt will scrape off if we just read the disk often enough. The following animation shows the result of subsequent reads of the same disk:</p><p><a href="docs/visualize_1541_2/dirt2.gif"><img src="docs/visualize_1541_2/dirt2.gif" height="264" width="512" alt="" /></a></p><p>Here, you can see how the faulty sector on the third track in the picture starts out all-black, with the next sector missing, over unstable data reads, to finally stable and correct reads. You can also see how the previous two sectors are impacted by the same speck of dirt, just not as much.</p><p>(The fact that it is different sector numbers that are impacted on the different tracks is due to the fact that on 1541 disks, there is no sector alignment between tracks, i.e. whether sector 0 on one track touches sector 0..20 on the next track is practically random.)</p><p>If the dropout persists across retries, it might still be dirt, just of the more resilient kind. Just <a href="https://www.pagetable.com/?p=1352">clean the disk</a> and try again.</p><h3 id="Weak-Bit-Data-Errors">Weak Bit Data Errors</h3><p><!-- sh65b.nbz --></p><p>This is a disk with multiple checksum errors in the data section across several tracks. Cleaning the disk did not help, so these are weak bits:</p><p><a href="docs/visualize_1541_2/error5_detail.gif"><img src="docs/visualize_1541_2/error5_detail.gif" height="183" width="600" alt="" /></a></p><p>Weak bits do not result in flipped bits, but in missing or duplicate bits. As you can see in the animation, sections of the data move back and forth between retries. It is clearer when looking at a single sector. This excerpt contains four weak bits:</p><p><a href="docs/visualize_1541_2/error5_detail2.gif"><img src="docs/visualize_1541_2/error5_detail2.gif" height="6" width="600" alt="" /></a><br /><a href="docs/visualize_1541_2/error5_detail2_legend.png"><img src="docs/visualize_1541_2/error5_detail2_legend.png" height="6" width="600" alt="" /></a></p><p>The read logic of Commodore disk drives measures the time between zero-to-one and one-to-zero edges and then decides how many zeros or ones were on disk. Therefore, weak bits lead to duplicate or missing bits.</p><p>A single weak bit can be recovered from by retrying: If it reads back correctly every now and then, it is as easy as retrying until the checksum is correct. But with multiple weak bits in a single sector, this gets exponentially less likely.</p><h2 id="Conclusion">Conclusion</h2><p>All that current tools can do with faulty disks is retry until the checksum is correct. By analyzing the weak bits, it should be possible to create tools for data recovery on a lower level. Multiple reads will reveal where the weak bits are, so a tool could try out different sequences around the weak bits and verify the checksum.</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1356</wfw:commentRss> <slash:comments>5</slash:comments> </item> <item> <title>Commodore “Video Supergame 64” Bundle</title> <link>https://www.pagetable.com/?p=1354</link> <comments>https://www.pagetable.com/?p=1354#comments</comments> <pubDate>Tue, 28 May 2019 11:40:14 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Teardown]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1354</guid> <description><![CDATA[The “Video Supergame 64” is a Commodore 64 bundled with a joystick and three games on a cartridge, sold mainly in Germany in 1988/1989. Here are some pictures. The top and bottom as well as the two sides of the box are identical. They all say: VIDEO SUPERGAME 64 Inhalt: Contents: Commodore 64 Joystick 3 ... <a title="Commodore “Video Supergame 64” Bundle" class="read-more" href="https://www.pagetable.com/?p=1354">Read more<span class="screen-reader-text">Commodore “Video Supergame 64” Bundle</span></a>]]></description> <content:encoded><![CDATA[<p>The “Video Supergame 64” is a Commodore 64 bundled with a joystick and three games on a cartridge, sold mainly in Germany in 1988/1989. Here are some pictures.</p><p><a href="docs/supergame64/side2.jpg"><img src="docs/supergame64/side2_small.jpg" alt="" /></a><br /><a href="docs/supergame64/front.jpg"><img src="docs/supergame64/front_small.jpg" alt="" /></a><br /><a href="docs/supergame64/side1.jpg"><img src="docs/supergame64/side1_small.jpg" alt="" /></a></p><p>The top and bottom as well as the two sides of the box are identical. They all say:</p><blockquote><blockquote><p>VIDEO SUPERGAME 64<br />Inhalt:<br />Contents:<br />Commodore 64<br />Joystick<br />3 Super Games</p></blockquote></blockquote><p>There is a sticker on one side:</p><blockquote><blockquote><p>software<br />by<br />Epyx<br />CDS SOFTWARE<br />COMMODORE</p></blockquote></blockquote><p>There is absolutely no technical information on the box whatsoever.</p><p><a href="docs/supergame64/inside1.jpg"><img src="docs/supergame64/inside1_small.jpg" alt="" /></a></p><p>Inside the cardboard, there is a styrofoam box with the Commodore logo, and another cardboard box.</p><p><a href="docs/supergame64/inside2.jpg"><img src="docs/supergame64/inside2_small.jpg" alt="" /></a></p><p>The C64 and the power supply are inside the styrofoam.</p><p><a href="docs/supergame64/packaging1.jpg"><img src="docs/supergame64/packaging1_small.jpg" alt="" /></a><br /><a href="docs/supergame64/packaging2.jpg"><img src="docs/supergame64/packaging2_small.jpg" alt="" /></a></p><p>These are pictures of the storofoam.</p><p><a href="docs/supergame64/c64_front.jpg"><img src="docs/supergame64/c64_front_small.jpg" alt="" /></a></p><p>The C64 has a red power LED and a light keyboard. These properties varied for the “Supergame” bundle. Note that the packaging shows a brown keyboard.</p><p><a href="docs/supergame64/c64_back.jpg"><img src="docs/supergame64/c64_back_small.jpg" alt="" /></a></p><p>The label on the bottom states that this is a C64G. Two of the screws are covered with warranty stickers.</p><p><a href="docs/supergame64/psu1.jpg"><img src="docs/supergame64/psu1_small.jpg" height="554" width="300" alt="" /></a><a href="docs/supergame64/psu2.jpg"><img src="docs/supergame64/psu2_small.jpg" height="587" width="260" alt="" /></a></p><p>The power supply says “FOR C-64 ONLY”. It outputs 5V DC at 1.7A and 9V AC at 1A. There is a sicker saying “7-88”.</p><p><a href="docs/supergame64/accessories.jpg"><img src="docs/supergame64/accessories_small.jpg" alt="" /></a></p><p>The cardboard box contains the UHF video cable, the cartridge, the joystick and the manuals.</p><p><a href="docs/supergame64/joystick.jpg"><img src="docs/supergame64/joystick_small.jpg" alt="" /></a></p><p>The C-1342 joystick was only sold as part of this bundle.</p><p><a href="docs/supergame64/cart_front.jpg"><img src="docs/supergame64/cart_front_small.jpg" height="386" width="300" alt="" /></a><a href="docs/supergame64/cart_back.jpg"><img src="docs/supergame64/cart_back_small.jpg" height="380" width="300" alt="" /></a></p><p>The “Super Games” cartridge contains Colossus Chess 2.0, Silicon Syborgs (a space-themed “Connect Four” style game), and International Football. Note that the packaging of the bundle says nothing about the types of games included. The art implies it was about space ships, race cars and soccer.</p><p><a href="docs/supergame64/manual.png"><img src="docs/supergame64/manual_small.png" height="438" width="300" alt="" /></a><a href="docs/supergame64/games_manual.png"><img src="docs/supergame64/games_manual_small.png" height="458" width="300" alt="" /></a></p><p>These are the cover pages of the C64 and “Supergames” manuals.</p><p><a href="docs/supergame64/warranty.pdf"><img src="docs/supergame64/warranty_small.png" height="428" width="300" alt="" /></a></p><p>The German warranty sheet has a fixed end date of 1989-06-30 and guarantees repair or replacement within 10 days. It also advertizes some periperals:</p><ul><li>Commodore Diskettenlaufwerk (Floppy) 1541 II (für 5 1/4“ Diskette)</li><li>Commodore Diskettenlaufwerk (Floppy) 1581 (für 3 1/2“ Disketten)</li><li>Commodore Datasette 1530</li><li>Commodore Monochrom-Monitor 1900 M</li><li>Commodore Farbmonitor 1802</li><li>Commodore Drucker MPS 1230</li><li>Commodore RAM-Expansion 1764</li><li>Commodore BTX-Decoder 2</li><li>Commodore Maus 1351</li></ul>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1354</wfw:commentRss> <slash:comments>6</slash:comments> </item> <item> <title>Dumping Commodore 64/1541 Disks with Errors</title> <link>https://www.pagetable.com/?p=1352</link> <comments>https://www.pagetable.com/?p=1352#comments</comments> <pubDate>Mon, 27 May 2019 17:53:53 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Floppy Disks]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1352</guid> <description><![CDATA[Many old Commodore 64/1541 disks have read errors, but this doesn’t mean the data isn’t recoverable – with the right nibtools settings and some cleaning. ZoomFloppy and nibtools The ZoomFloppy adapter is the de-facto standard for connecting Commodore disk drives to modern computers, using a USB connection. There are two ways to read a disk image: ... <a title="Dumping Commodore 64/1541 Disks with Errors" class="read-more" href="https://www.pagetable.com/?p=1352">Read more<span class="screen-reader-text">Dumping Commodore 64/1541 Disks with Errors</span></a>]]></description> <content:encoded><![CDATA[<p>Many old Commodore 64/1541 disks have read errors, but this doesn’t mean the data isn’t recoverable – with the right <em>nibtools</em> settings and some cleaning.</p><h2 id="ZoomFloppy-and-nibtools">ZoomFloppy and nibtools</h2><p>The <a href="http://store.go4retro.com/zoomfloppy/">ZoomFloppy</a> adapter is the de-facto standard for connecting Commodore disk drives to modern computers, using a USB connection.</p><p>There are two ways to read a disk image:</p><ul><li><em>d64copy</em> (<em>opencbm</em>) will read the contents of a disk sector by sector and create a <code>.d64</code> image file. This works with all Commodore drives through the serial cable.</li><li><em>nibread</em> (<em>nibtools</em>) will read the raw bits of each track without any interpretation and create a <code>.nib</code>/<code>.nbz</code> file (which can be converted into a standard <code>.g64</code> file). This requires a 1541 with a <a href="http://sta.c64.org/parport41c.html">parallel port mod</a> or a 1570/1571 with just a serial connection.</li></ul><p>The main use for <code>.g64</code> files is to preserve copy-protected games, which often use custom on-disk structures that would not be or sometimes cannot even be preserved in a <code>.d64</code> image. In the context of reading disks that may have read errors, “nibbling” into <code>.nbz</code>/<code>.g64</code> preserves all the information that could be read, which gives us better insight into what happened, and may allow us to recover more data.</p><p>This article covers reading the raw data using <em>nibread</em>, but most of the information translates to reading the decoded data using <em>d64copy</em>.</p><h2 id="Error-free-Dump">Error-free Dump</h2><p>Let’s first look at the output of <code>nibread</code> for an error-free disk. The command <code>nibread disk123</code> will create <code>disk123.nbz</code> and print this:</p><pre><code> 1.0: (3) 7818 [CBM OK] (weakgcr:3) 2.0: (3) 7819 [CBM OK] (weakgcr:6) 3.0: (3) 7819 [CBM OK] (weakgcr:4) 4.0: (3) 7819 [CBM OK] (weakgcr:9) 5.0: (3) 7819 [CBM OK] (weakgcr:5) 6.0: (3) 7819 [CBM OK] (weakgcr:4) 7.0: (3) 7819 [CBM OK] (weakgcr:3) 8.0: (3) 7819 [CBM OK] (weakgcr:6) 9.0: (3) 7819 [CBM OK] (weakgcr:1) 10.0: (3) 7819 [CBM OK] (weakgcr:3) 11.0: (3) 7819 [CBM OK] (weakgcr:4) 12.0: (3) 7819 [CBM OK] (weakgcr:5) 13.0: (3) 7819 [CBM OK] (weakgcr:3) 14.0: (3) 7819 [CBM OK] (weakgcr:9) 15.0: (3) 7819 [CBM OK] (weakgcr:5) 16.0: (3) 7819 [CBM OK] (weakgcr:3) 17.0: (3) 7819 [CBM OK] (weakgcr:4) 18.0: (2) 7148 [CBM OK] (weakgcr:2) 19.0: (2) 7148 [CBM OK] (weakgcr:8) 20.0: (2) 7148 [CBM OK] (weakgcr:4) 21.0: (2) 7148 [CBM OK] (weakgcr:5) 22.0: (2) 7148 [CBM OK] (weakgcr:2) 23.0: (2) 7149 [CBM OK] (weakgcr:6) 24.0: (2) 7148 [CBM OK] (weakgcr:1) 25.0: (1) 6673 [CBM OK] (weakgcr:4) 26.0: (1) 6673 [CBM OK] (weakgcr:3) 27.0: (1) 6673 [CBM OK] (weakgcr:1) 28.0: (1) 6673 [CBM OK] (weakgcr:6) 29.0: (1) 6673 [CBM OK] (weakgcr:5) 30.0: (1) 6673 [CBM OK] (weakgcr:4) 31.0: (0) 6255 [CBM OK] 32.0: (0) 6255 [CBM OK] 33.0: (0) 6255 [CBM OK] (weakgcr:2) 34.0: (0) 6255 [CBM OK] (weakgcr:4) 35.0: (0) 6255 [CBM OK] (weakgcr:2) 36.0: (1!=2 NOSYNC!) 0 [Unformatted Track] 37.0: (1!=2 NOSYNC!) 0 [Unformatted Track] 38.0: (1!=2 NOSYNC!) 0 [Unformatted Track] 39.0: (1!=2 NOSYNC!) 0 [Unformatted Track] 40.0: (1!=2 NOSYNC!) 0 [Unformatted Track] 41.0: (1!=2 NOSYNC!) 0 [Unformatted Track] </code></pre><p>Tracks 1 to 35 show “CBM OK’, which means that there are no errors. Tracks 36 to 41 are unformatted, which is the usual case for data disks. You can pass <code>-E35</code> to nibread to save a few seconds on each disk if you are certain it doesn’t use the extra tracks.</p><p>“weakgcr” means that there is data on the track that does not consist of legal <a href="https://www.linusakesson.net/programming/gcr-decoding/">GCR-encoded</a> bit combinations. This is normal for the <a href="https://www.pagetable.com/?p=1070">gaps, especially the tail gap</a>, i.e. the unused areas of a track.</p><p>You can then use <code>nibconvert</code> to create a standard <code>.g64</code> image – or, if there are no errors and no copy protection, a <code>.d64</code> image.</p><h2 id="Error-Codes">Error Codes</h2><p>Errors are shown like this:</p><pre><code> 10.0: (3) 7898 [E5S16]</code></pre><p><code>E5S16</code> means there was an error 5 when decoding sector 16. Here is the full list of error codes:</p><table><thead><tr><th> Controller Code </th><th> Description </th><th> DOS Code </th></tr></thead><tbody><tr><td> 2 </td><td> Header not found </td><td> 20 </td></tr><tr><td> 4 </td><td> Data not found </td><td> 22 </td></tr><tr><td> 5 </td><td> Data checksum error </td><td> 23 </td></tr><tr><td> 9 </td><td> Header checkum error </td><td> 27 </td></tr></tbody></table><p>The <em>nibtools</em> error codes are the same as the 1541 “controller” error codes. The DOS codes are the “READ ERROR” codes returned by the 1541 status channel.</p><ul><li>The most common error is number 5: About 90% of a track consists of the actual sector data, and any incorrectly read bit will cause an error 5.</li><li>Tracks with more serious read problems often show an error 2 or 4: This usually means that large chunks of the track were unreadable, so that the header/data markers (“SYNC”) could not be found.</li></ul><p>For a description of the on-disk format of sectors and more information on common errors, have a look at <a href="https://www.pagetable.com/?p=1128">this article</a>.</p><h2 id="Checksums">Checksums</h2><p>The on-disk format of 1541 disks uses 8-bit checksums to protect the integrity of headers and data sections. It is calculcated as an XOR of all data bytes.</p><p><em>nibread</em> will flag an error if any of the checksums is incorrect, and retry reading up to the specified retry count (default 10).</p><p>An 8 bit checksum is not very strong: The probability of an undetected read error is 1:256. In practice, it is good enough that it should be trusted for most cases. But if a disk has dozens of read errors, it is not a solution to set the number of retries to 1000 and leave it running overnight!</p><h2 id="Weak-Sector">Weak Sector</h2><p>The most common case is an error that goes away after a few retries:</p><pre><code> 10.0: (3) 7898 [E5S16] (3) 7898 [E5S16] (3) 7898 [CBM OK] (weakgcr:3) </code></pre><p>In this example, the second retry was successful. The incorrect read was either caused by dirt that rubbed off easily, or by a weak bit.</p><h2 id="Bad-sector">Bad sector</h2><p>But sometimes an error does not go away. Here is an error 2 that persists after 10 retries, the <em>nibread</em> default:</p><pre><code> 1.0: (3) 7692 [E2S9] (3) 7691 [E2S9] (3) 7690 [E2S9] (3) 7691 [E2S9] (3) 7691 [E2S9] (3) 7692 [E2S9] (3) 7692 [E2S9] (3) 7691 [E2S9] (3) 7691 [E2S9] (3) 7692 [E2S9] (3) 7691 [E2S9] (weakgcr:34) </code></pre><p>As always, the error could be caused by weak bits, or by dirt<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup>.</p><p>You could increase the number of retries, which works in some cases, but if the error does not go away after maybe 20 retries, it is best to first <strong>cleaned the disk</strong>.</p><h2 id="Cleaning-the-Disk">Cleaning the Disk</h2><p>The most common reason thirty year old disks have read errors is that some of their surface material became loose and is now a thin layer of dust that interferes with the read head.</p><p>An alcohol-based cleaning wipe is the easiest method to clean the disk. For this, you need to remove the top of the drive’s case. It’s good practice to keep it unscrewed on the device you are using for dumping disks anyway.</p><p>The read head is on the bottom, and there is a spring-loaded counter-weight on the top, which can be easily lifted, so that the cloth can be put between it and the disk’s surface:</p><p><a href="docs/recovering_disks/clean_disk.jpg"><img src="docs/recovering_disks/clean_disk_small.jpg" alt="" /></a></p><p>Note that this always cleans the side of the disk that is opposite of what is expected based on the orientation of the disk on the drive. In other words, to clean side A, you have to put in the disk as if you wanted to read side B.</p><p>A 1571 has a read head on both sides, and the top one cannot be lifted very far, so you have to be careful not to break anything.</p><p>Then, instruct nibread to do one pass across all tracks, ignoring errors:</p><pre><code> nibread -e0 /tmp/x</code></pre><p>You should do this several times, so that the cloth gets rubbed over every track multiple times.</p><p>These cleaning cloths dry out very quickly. Instead of using new cloths every time, you can use an alcohol-based disinfection spray to add moisture to them again.</p><h2 id="Trying-Again">Trying Again</h2><p>Before trying again, you should make sure that the disk’s surface has dried. Otherwise, you will get something like this, possibly on a track that was fine before:</p><pre><code> 12.0: (3) 7882 [E5S0] (3) 7882 [E5S5] (3) 7880 [E5S8] (3) 7881 [E5S0][E5S5][E5S8][E5S11] (3) 7880 [E5S2][E5S5][E5S8][E5S10][E5S12][E5S16] (3) 7882 [E5S1][E5S2][E2S7][E5S11] (3) 7882 [E5S1][E5S8][E5S9][E5S10][E5S12][E5S16] (3) 7882 [E5S2][E5S3][E5S5][E5S10][E5S11][E5S13][E5S15] (3) 7881 [E5S2][E5S10][E5S11][E5S13][E5S14][E2S18] (3) 7882 [E5S4][E5S5][E5S9][E5S10][E5S11][E5S12][E5S13][E5S14][E5S16] (3) 7881 [E5S1][E5S2][E5S4][E5S5][E5S8][E5S10][E5S11][E5S12][E5S13][E5S14][E5S16] (weakgcr:11) </code></pre><p>On every read, there were different errors, which indicates that the errors aren’t caused by the contents of the disk. Let it dry, then try again. (It could also indicate a dirty read head – see below.)</p><p>If you are lucky, the track will read without any errors after cleaning:</p><pre><code> 1.0: (3) 7691 [CBM OK] (weakgcr:37) </code></pre><p>Or maybe it just reads a little better, because it was a combination of dirt and weak bits.</p><p>In any case, now is the time that you can increase the number of retries with the <code>-e</code> argument. Numbers up to 100 are reasonable; in practice, there is rarely a good read after 30 retries.</p><p>And here is an example of a track with multiple errors that, after cleaning, read correctly after 26 retries:</p><pre><code> 28.0: (1) 6638 [E5S5][E2S6] (1) 6639 [E5S5][E2S6] (1) 6638 [E5S5][E2S6] (1) 6639 [E5S5][E2S6] (1) 6638 [E5S5][E9S6] (1) 6638 [E5S5][E9S6] (1) 6638 [E2S6] (1) 6638 [E5S5][E9S6] (1) 6638 [E2S6] (1) 6638 [E5S5][E2S6] (1) 6638 [E5S5][E2S6] (1) 6638 [E5S5][E2S6] (1) 6638 [E2S6] (1) 6638 [E5S5][E2S6] (1) 6638 [E5S5][E2S6] (1) 6638 [E5S5][E2S6] (1) 6638 [E5S5][E2S6] (1) 6638 [E5S5][E2S6] (1) 6638 [E5S5][E2S6] (1) 6638 [E5S5][E2S6] (1) 6638 [E2S6] (1) 6638 [E2S6] (1) 6638 [E5S5][E2S6] (1) 6638 [E5S5][E2S6] (1) 6638 [E5S5][E2S6] (1) 6639 [E5S5][E2S6] (1) 6638 [CBM OK] (weakgcr:5) </code></pre><h2 id="Dirty-Read-Head">Dirty Read Head</h2><p>The dirt on a disk can stick to the read head, which will interfere with all reads. Here is an example of a disk dump with a dirty head:</p><pre><code> 1.0: (3) 7801 [CBM OK] (weakgcr:21) 2.0: (3) 7882 [CBM OK] (weakgcr:2) 3.0: (3) 7882 [CBM OK] (weakgcr:5) 4.0: (3) 7775 [CBM OK] (weakgcr:21) 5.0: (3) 7694 [CBM OK] (weakgcr:29) 6.0: (3) 7693 [CBM OK] (weakgcr:27) 7.0: (3) 7693 [CBM OK] (weakgcr:27) 8.0: (3) 7695 [E5S2][E9S13] (3) 7694 [CBM OK] (weakgcr:23) 9.0: (3) 7696 [E5S3][E9S5][E9S7][E2S10][E5S18][E2S20] (3) 7696 [E9S7][E2S10] (3) 7696 [E9S6][E9S7][E5S8][E2S10][E2S15][E2S20] (3) 7695 [E5S0][E2S2][E9S4][E9S6][E9S7][E9S8][E9S9][E5S10][E9S20] (3) 7696 [E5S2][E5S4][E9S6][E2S7][E9S8][E9S9][E2S10][E2S11][E2S12][E9S18][E5S19][E9S20] (3) 7695 [E9S0][E9S1][E9S2][E9S3][E9S4][E9S5][E9S6][E9S7][E2S8][E9S9][E2S10][E2S11][E5S13][E5S14][E2S15][E2S16][E9S17][E2S18][E5S19][E9S20] (3) 7693 [E9S0][E9S2][E5S3][E2S4][E2S5][E5S6][E9S7][E9S8][E2S9][E2S10][E2S11][E5S12][E9S13][E2S15][E2S16][E2S17][E9S18][E5S19][E9S20] (3) 7694 [E5S1][E9S2][E2S3][E9S4][E2S5][E9S6][E2S7][E2S8][E2S9][E2S10][E9S11][E2S12][E9S14][E5S15][E5S16][E5S17][E5S18][E9S19][E2S20] (3) 7691 [E5S0][E2S1][E2S2][E9S3][E2S4][E2S5][E9S6][E2S7][E2S8][E2S9][E2S10][E2S11][E2S12][E5S13][E9S15][E2S16][E2S17][E9S18][E2S20] (3) 7690 [NDOS] (weakgcr:29) [...]</code></pre><p>Again, if the errors are radically different between retries, it cannot be an issue of the disk’s surface.</p><p>A clean read head looks like this:</p><p><a href="docs/recovering_disks/head_clean.jpg"><img src="docs/recovering_disks/head_clean_small.jpg" alt="" /></a></p><p>And a dirty one like this:</p><p><a href="docs/recovering_disks/head_dirty.jpg"><img src="docs/recovering_disks/head_dirty_small.jpg" alt="" /></a></p><p>You can use the same alcohol-based wipes to clean the read head.</p><h2 id="Conclusion">Conclusion</h2><p>In my experience, more than half of old disks with read errors can be read correctly again after cleaning them.</p><p>If the errors don’t go away, and it is a commercial disk, there is of course usually the possibility of buying another copy, and even if that one has errors as well, the data can be spliced together.</p><p>Otherwise, the tool <a href="https://github.com/markusC64/g64conv">g64conv</a> can help: It converts <code>.g64</code> files into a textual representation, which allows you to inspect what exactly went wrong, and may give you the opportunity to extract some information from sections with errors.</p><div class="footnotes"><hr/><ol><li id="fn:1"><p>Errors can also be cause by <a href="https://www.pagetable.com/?p=1128">incorrectly written on-disk data structures</a>, e.g. because of a buggy driver, or an error when duplicating the disk. We will ignore these kinds of errors in this article.<a href="#fnref:1" rev="footnote">↩</a></p></li></ol></div>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1352</wfw:commentRss> <slash:comments>5</slash:comments> </item> <item> <title>Commodore “Magic Voice” Cartridge for C64</title> <link>https://www.pagetable.com/?p=1348</link> <comments>https://www.pagetable.com/?p=1348#comments</comments> <pubDate>Sun, 26 May 2019 10:02:50 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Teardown]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1348</guid> <description><![CDATA[“Magic Voice” is an expansion cartridge for the Commodore 64 that can speak 235 predefined words. Here are some pictures. Magic Voice does not combine words from phonemes, but contains 235 prerecorded words in a 16 KB ROM. It was meant to be used with tape, disk or cartridge based software that made use of ... <a title="Commodore “Magic Voice” Cartridge for C64" class="read-more" href="https://www.pagetable.com/?p=1348">Read more<span class="screen-reader-text">Commodore “Magic Voice” Cartridge for C64</span></a>]]></description> <content:encoded><![CDATA[<p>“Magic Voice” is an expansion cartridge for the Commodore 64 that can speak 235 predefined words. Here are some pictures.</p><p><a href="docs/magic_voice/magic_voice.jpg"><img src="docs/magic_voice/magic_voice_small.jpg" alt="" /></a></p><p>Magic Voice does not combine words from phonemes, but contains 235 prerecorded words in a 16 KB ROM. It was meant to be used with tape, disk or cartridge based software that made use of the extension, but few titles were released.</p><p>Without any extra software, the speech features are accessible through added BASIC commands.</p><p>The canceled <a href="http://www.zimmers.net/cbmpics/cv364.html">Commodore V364</a> was supposed to ship with the same speech Toshiba T6721A chip and a similar driver ROM.</p><p><a href="docs/magic_voice/top.jpg"><img src="docs/magic_voice/top_small.jpg" alt="" /></a></p><p>The case has a passthrough connector on top, which allows using the speech feature in cartridge-based applications. The label says “Commodore Magic Voice”.</p><p><a href="docs/magic_voice/bottom.jpg"><img src="docs/magic_voice/bottom_small.jpg" alt="" /></a></p><p>There is no label in the designated area on the bottom. A small sticker says “MADE IN HONG HONG”. It also contains the names of the two connectors on the side: “OUT” and “IN”.</p><p><a href="docs/magic_voice/side.jpg"><img src="docs/magic_voice/side_small.jpg" alt="" /></a></p><p>The Audio In (red) and Audio Out (black) RCA connectors are on the side.</p><p><a href="docs/magic_voice/board_front.jpg"><img src="docs/magic_voice/board_front_small.jpg" alt="" /></a></p><p>The board contains</p><ul><li>a MOS 6525A TPI I/O controller (also used in the <a href="https://www.pagetable.com/?p=1303">IEEE-488 cartridge</a>, the <a href="https://www.pagetable.com/?p=1331">1551</a> disk drive, as well as other devices)</li><li>a 16 KB EPROM: This contains the compressed speech data and the C64 code.</li><li>a gate array (address decoding, parallel-serial-conversion)</li><li>the Toshiba <a href="http://www.stefan-uhlmann.de/cbm/MVM/Hardware/T6721A.pdf">T6721A</a> speech chip</li></ul><p><a href="docs/magic_voice/board_back.jpg"><img src="docs/magic_voice/board_back_small.jpg" alt="" /></a></p><h2 id="Emulation">Emulation</h2><p>VICE supports the Magic Voice cartridge by giving it the ROM from <a href="http://www.zimmers.net/anonftp/pub/cbm/schematics/cartridges/c64/magic-voice/index.html">zimmers.net</a>:</p><pre><code> x64 -magicvoiceimage 251476.bin</code></pre><p>Then you can make it speak all words with</p><pre><code> FOR I = 0 TO 255: SAY I: PRINT I: NEXT</code></pre><h2 id="References">References</h2><ul><li><a href="http://www.stefan-uhlmann.de/cbm/MVM/index.html">http://www.stefan-uhlmann.de/cbm/MVM/index.html</a></li><li><a href="http://www.stefan-uhlmann.de/cbm/MVM/Repair/index.html">http://www.stefan-uhlmann.de/cbm/MVM/Repair/index.html</a></li><li><a href="https://binarium.de/commodore_magic_voice_speech_module_c64">https://binarium.de/commodore_magic_voice_speech_module_c64</a></li><li><a href="http://www.floodgap.com/retrobits/ckb/secret/operiph.html">http://www.floodgap.com/retrobits/ckb/secret/operiph.html</a></li><li><a href="http://www.6502.org/users/sjgray/computer/magicvoice/index.html">http://www.6502.org/users/sjgray/computer/magicvoice/index.html</a></li><li><a href="https://www.c64-wiki.de/wiki/Magic_Voice">https://www.c64-wiki.de/wiki/Magic_Voice</a></li><li><a href="http://www.zimmers.net/anonftp/pub/cbm/schematics/cartridges/c64/magic-voice/index.html">http://www.zimmers.net/anonftp/pub/cbm/schematics/cartridges/c64/magic-voice/index.html</a></li><li><a href="http://cbm-hackers.2304266.n4.nabble.com/Magic-Voice-Schematics-td4067465.html">http://cbm-hackers.2304266.n4.nabble.com/Magic-Voice-Schematics-td4067465.html</a></li></ul>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1348</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item> <title>Falk Rehwagen, TopDesk and GEOS</title> <link>https://www.pagetable.com/?p=1344</link> <comments>https://www.pagetable.com/?p=1344#respond</comments> <pubDate>Sat, 25 May 2019 13:22:09 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[C128]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[GEOS]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1344</guid> <description><![CDATA[Here are some of Falk Rehwagen’s thoughts on his involvement with GEOS and TopDesk. It’s not so easy to remember the details after more than 25 years :-) GEOS Back then, I was fascinated by what one could get out of this outdated hardware, many years after its release. As for GEOS, I found it ... <a title="Falk Rehwagen, TopDesk and GEOS" class="read-more" href="https://www.pagetable.com/?p=1344">Read more<span class="screen-reader-text">Falk Rehwagen, TopDesk and GEOS</span></a>]]></description> <content:encoded><![CDATA[<p>Here are some of Falk Rehwagen’s thoughts on his involvement with <a href="https://www.pagetable.com/?p=869">GEOS</a> and <a href="https://www.pagetable.com/?p=1341">TopDesk</a>.</p><blockquote><p>It’s not so easy to remember the details after more than 25 years :-)</p></blockquote><h2 id="GEOS">GEOS</h2><blockquote><p>Back then, I was fascinated by what one could get out of this outdated hardware, many years after its release. As for GEOS, I found it exciting that it was possible to develop a real commercial operating system on such a small machine, with a variety of powerful applications, tools, drivers, and so on. Naturally, I bought GEOS as soon as it was possible, paid with my family’s <a href="https://en.wikipedia.org/wiki/Begr%C3%BC%C3%9Fungsgeld">welcome money</a> in Berlin, 1990. :-)</p></blockquote><h2 id="Programming-&-GEOS-User-Club">Programming & GEOS User Club</h2><blockquote><p>That’s when I got very involved with GEOS (64) and its possibilities on my C128, and it quickly became clear that I wanted to develop applications myself. I a found good and fast entry with the MegaAssembler, which paved the way deep into GEOS development. As part of this learning, I created a diverse set of applications, which, compiled as a “best of” disk, we also offered for sale. In this context, in 1991/92, I got into contact with the Geos User Club, the association of all GEOS users and fans in Germany. The “GUC-Regio-Sachsen” was founded, and in 1992, I participated in the GUC Annual General Meeting for the first time. If I remember correctly, this was also the time when TopDesk was almost ready as a the modern replacement for the “deskTop” built into GEOS. It was absolutely fascinating, because the windowing technology once again showed what can be done with GEOS and the hardware and brought the system closer to the more modern competitors. TopDesk was delayed, but eventually I held it in my hands and used it as my exclusively GEOS control center.</p></blockquote><h2 id="Patch-System-and-GeoCOM">Patch System and GeoCOM</h2><blockquote><p>I was keen to make GEOS better and more flexible. From this thought arose the “Patch System”, which allowed defining and distributing small improvements and extensions in a consisteny way. In order to give more users and developers the opportunity to develop new applications for GEOS, a powerful programming environment called GeoCom was created, based on ECOM from the 64’er Magazine. With an extensive manual, created in co-operation with Denis Döhler, the system was offered commercially as a alternative to programming in assemnly.</p></blockquote><h2 id="TopDesk-Maintainer">TopDesk Maintainer</h2><blockquote><p>Around the same time, the market around PCs and operating systems developed rapidly, many GEOS fans following the technological development towards PC/GEOS or other available alternatives. I think sometime in 1993/94, the GUC had completely switched its focus on PC/GEOS and was looking for maintainers for its GEOS-64-related technologies and products. With my spectrum of projects and experience, I was probably a good candidate for this: After all, I remained faithful to the C64/128 and GEOS 64 as a developer. I don’t remember when and where exactly, but I was given TopDesk maintainership – and the sources. :-) It was convenient that TopDesk had been written by the same people as MegaAssembler, so I was already well-equipped for the development of TopDesk.</p></blockquote><h2 id="Improving-GEOS-and-TopDesk">Improving GEOS and TopDesk</h2><blockquote><p>After “Patch System” and GeoCom, I wanted to develop GEOS in a more profound way, to combine it with the extended TopDesk, and to make the whole system more open to the many hardware enhancements that were available on the market. For this purpose, I completely reverse-engineered the GEOS KERNAL (with all-GEOS tools like GEODISASSEMBLER), so it could be assembled again with MegaAssembler. The idea for GEOS 3.0 was born. Development became much faster after I had gotten a loaner Flash 8 acceleration cartridge (8 MHz) – for which I adapted GEOS. TopDesk got color support, and the GEOS KERNAL was further developed to have a flexible driver model. An early version of the project was presented in Berlin at the GUC Annual General Meeting 1994.</p></blockquote><h2 id="After-GEOS-64">After GEOS 64</h2><blockquote><p>I think I had already decided to take the step towards the PC at that time, to intensively work my way into the PC/GEOS SDK, which had just been published. (However, various sources seem to state that PC/GEOS wasn’t released until April 1995…) At least that’s when I decided to turn my back on GEOS 64 (initially) and to take on new challenges as part of my university studies. For this reason, the current state of development of TopDesk and GEOS 3.0 was cleanly returned to the GUC – to Wolfgang Grimm, I think. This soon resulted in version 3.0 of TopDesk, which was developed further as part of the MegaPatch 3.</p></blockquote>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1344</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>TopDesk 1.3 GEOS64/128 Original Source</title> <link>https://www.pagetable.com/?p=1341</link> <comments>https://www.pagetable.com/?p=1341#comments</comments> <pubDate>Fri, 24 May 2019 10:26:18 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[C128]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[GEOS]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1341</guid> <description><![CDATA[Thanks to Falk Rehwagen and Jürgen Heinisch, the original source of the TopDesk file manager for the GEOS operating system of C64/C128 is available. https://github.com/mist64/TopDesk The source has been converted from GeoWrite format to plain text. These are the original source disks: td64_13_en.d71 td64_13_de.d71 td128_13_de.d71 td128_13_en.d71 Most of the code of the different variants is ... <a title="TopDesk 1.3 GEOS64/128 Original Source" class="read-more" href="https://www.pagetable.com/?p=1341">Read more<span class="screen-reader-text">TopDesk 1.3 GEOS64/128 Original Source</span></a>]]></description> <content:encoded><![CDATA[<p>Thanks to Falk Rehwagen and Jürgen Heinisch, the original source of the TopDesk file manager for the GEOS operating system of C64/C128 is available.</p><p><a href="https://github.com/mist64/TopDesk">https://github.com/mist64/TopDesk</a></p><p><img src="docs/topdesk/topdesk_1.png" alt="" /></p><p>The source has been converted from GeoWrite format to plain text.</p><p>These are the original source disks:</p><ul><li><a href="docs/topdesk/td64_13_en.d71">td64_13_en.d71</a></li><li><a href="docs/topdesk/td64_13_de.d71">td64_13_de.d71</a></li><li><a href="docs/topdesk/td128_13_de.d71">td128_13_de.d71</a></li><li><a href="docs/topdesk/td128_13_en.d71">td128_13_en.d71</a></li></ul><p>Most of the code of the different variants is identical.</p><p>These disks use TopDesk-style subdirectories. Here is a listing of the disk contents:</p><pre><code> NAME TYPE SIZE -------------------------------- Main/ <DIR> DeskWindows.akt WRI 40K DeskTop.main WRI 52K DeskTop.sub WRI 4.7K DeskTop.sub2 WRI 4.2K DeskTop.sub3 WRI 8.6K DeskTop.sub4 WRI 6.2K DeskTop.sub5 WRI 7.3K DeskTop.sub6 WRI 10K DeskTop.sub7 WRI 12K DeskTop.sub8 WRI 1.8K DeskTop.sub9 WRI 7.8K DeskTop.sub10 WRI 7.8K Ende.s WRI 808B Dos.lnk WRI 1.0K Include/ <DIR> DeskMain2 WRI 20K SubDir.src WRI 21K University 6 FNT 1.0K Symbol/ <DIR> TopSym WRI 8.7K TopMac WRI 3.7K Sym128.erg WRI 1.1K CiMac WRI 1.2K CiSym WRI 1.1K DeskInclude/ <DIR> Validate+Undelet WRI 9.0K SizeRectangle WRI 2.3K CopyFile WRI 11K DiskCopy WRI 11K SearchDisk WRI 4.0K EditText WRI 8.7K DosFormat.s WRI 3.0K WinInclude/ <DIR> InvFrame WRI 2.7K SpeedFrame WRI 2.2K InvFrame.old WRI 2.6K GetDrivers.dir/ <DIR> GetDrivers.s WRI 2.8K GetDrivers APP 1.3K SaveDriver.s WRI 1.6K Protect/ <DIR> Desksub0.s WRI 1.2K SetBAM APP 962B ProtectDisk APP 1.3K Sources/ <DIR> SetBAM.s WRI 2.8K ProtectDisk.s WRI 2.8K SetProtection.s WRI 2.4K RemProtection.s WRI 2.4K RemProt.mod.s WRI 2.6K SetProt.mod APP 762B RemProt.mod APP 762B TopMac(a) WRI 4.9K SetProt.mod.s WRI 2.4K Desksub0 APP 9.6K</code></pre><p>There is a <a href="https://www.pagetable.com/?p=1344">follow-up article with with some history by Falk Rehwagen on the “Patch System”, TopDesk, and GEOS 3.0</a>.</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1341</wfw:commentRss> <slash:comments>3</slash:comments> </item> <item> <title>Tynemouth Minstrel ZX80 Clone Kit</title> <link>https://www.pagetable.com/?p=1337</link> <comments>https://www.pagetable.com/?p=1337#comments</comments> <pubDate>Thu, 23 May 2019 09:19:33 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Hardware]]></category> <category><![CDATA[Teardown]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1337</guid> <description><![CDATA[I have previously shown an unassembled Sinclair ZX81 Kit that could be bought in the early 80s. Today, it is possible to buy a clone of the ZX80 from Tynemouth Software. Here are some pictures. The PCB. The ZX80 and the ZX81 are very similar. The basic difference is that the ZX81 had the 74 ... <a title="Tynemouth Minstrel ZX80 Clone Kit" class="read-more" href="https://www.pagetable.com/?p=1337">Read more<span class="screen-reader-text">Tynemouth Minstrel ZX80 Clone Kit</span></a>]]></description> <content:encoded><![CDATA[<p>I have previously shown an unassembled <a href="https://www.pagetable.com/?p=1308">Sinclair ZX81 Kit</a> that could be bought in the early 80s. Today, it is possible to buy a <a href="https://www.tindie.com/products/tynemouthsw/minstrel-zx80-clone/">clone of the ZX80 from Tynemouth Software</a>. Here are some pictures.</p><p><a href="docs/zx80/board_front.jpg"><img src="docs/zx80/board_front_small.jpg" alt="" /></a><br /><a href="docs/zx80/board_back.jpg"><img src="docs/zx80/board_back_small.jpg" alt="" /></a></p><p>The PCB. The ZX80 and the ZX81 are very similar. The basic difference is that the ZX81 had the 74 chips combined into the ULA chip. This clone uses off-the-shelf components, and therefore the old ZX80 design with the individual 74s.</p><p><a href="docs/zx80/chips.jpg"><img src="docs/zx80/chips_small.jpg" height="376" width="300" alt="" /></a><a href="docs/zx80/sockets.jpg"><img src="docs/zx80/sockets_small.jpg" height="329" width="300" alt="" /></a></p><p>The ICs and the sockets. ROM, RAM, CPU, and lots of 74s.</p><p><a href="docs/zx80/board_front_sockets.jpg"><img src="docs/zx80/board_front_sockets_small.jpg" alt="" /></a></p><p>They board comes with the sockets already placed.</p><p><a href="docs/zx80/components.jpg"><img src="docs/zx80/components_small.jpg" height="343" width="300" alt="" /></a><a href="docs/zx80/feet.jpg"><img src="docs/zx80/feet_small.jpg" height="374" width="300" alt="" /></a></p><p>The other components, mounting pillars and feet.</p><p><a href="docs/zx80/plate1.jpg"><img src="docs/zx80/plate1_small.jpg" height="323" width="300" alt="" /></a><a href="docs/zx80/plate2.jpg"><img src="docs/zx80/plate2_small.jpg" height="320" width="300" alt="" /></a></p><p>It doesn’t come with a case, but it can be mounted onto this baseplate instead.</p><p><a href="docs/zx80/keyboard.jpg"><img src="docs/zx80/keyboard_small.jpg" alt="" /></a></p><p>The ZX81-style membrane keyboard. (There is also an option for a keyboard with switches.)</p><p><a href="docs/zx80/keyboard2.jpg"><img src="docs/zx80/keyboard2_small.jpg" alt="" /></a><br /><a href="docs/zx80/keyboard3.jpg"><img src="docs/zx80/keyboard3_small.jpg" alt="" /></a></p><p>And ZX80 style keyboard overlays.</p><p><a href="docs/zx80/psu.jpg"><img src="docs/zx80/psu_small.jpg" height="222" width="300" alt="" /></a><a href="docs/zx80/psu3.jpg"><img src="docs/zx80/psu3_small.jpg" height="475" width="300" alt="" /></a><a href="docs/zx80/cables.jpg"><img src="docs/zx80/cables_small.jpg" height="470" width="300" alt="" /></a></p><p>The power supply and the cables.</p><p><a href="Tynemouth%20Software%20Minstrel%20ZX80%20Clone%20Kit.pdf"><img src="docs/zx80/Tynemouth%20Software%20Minstrel%20ZX80%20Clone%20Kit.png" height="212" width="300" alt="" /></a></p><p>Assembly instructions. Includes schematics. (0.6 MB)</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1337</wfw:commentRss> <slash:comments>2</slash:comments> </item> <item> <title>Converting a Commodore 1541 or 1570 Drive into a 1551</title> <link>https://www.pagetable.com/?p=1331</link> <comments>https://www.pagetable.com/?p=1331#comments</comments> <pubDate>Wed, 22 May 2019 09:09:25 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Commodore]]></category> <category><![CDATA[Floppy Disks]]></category> <category><![CDATA[Hardware]]></category> <category><![CDATA[TED]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1331</guid> <description><![CDATA[The 1551 is the weird outlier in the family of Commodore disk drives: It is the only drive using the “TCBM” bus instead of Serial or IEEE-488. And what’s even weirder? 1541 and 1570 drives converted into 1551s! The first Commodore disk drives for the PET were using the industry-standard parallel IEEE-488 bus. For cost ... <a title="Converting a Commodore 1541 or 1570 Drive into a 1551" class="read-more" href="https://www.pagetable.com/?p=1331">Read more<span class="screen-reader-text">Converting a Commodore 1541 or 1570 Drive into a 1551</span></a>]]></description> <content:encoded><![CDATA[<p>The 1551 is the weird outlier in the family of Commodore disk drives: It is the only drive using the “TCBM” bus instead of Serial or IEEE-488. And what’s even weirder? 1541 and 1570 drives converted into 1551s!</p><p><a href="docs/1551_mod/1541-1570.jpg"><img src="docs/1551_mod/1541-1570.jpg" alt="" /></a></p><p>The first Commodore disk drives for the PET were using the industry-standard parallel <a href="https://www.pagetable.com/?p=1023">IEEE-488</a> bus. For cost reasons, Commodore switched to a custom <a href="https://www.pagetable.com/?p=1135">serial</a> version of the bus with the VIC-20 and the C64. But serial was slow, and IEEE-488 was expensive. <a href="https://www.pagetable.com/?p=1324">TCBM</a> was supposed to be the compromise. There was no connector on the drive side, and the computer side was a cartridge (“paddle”) with the I/O chip – which was shipped with the drive instead of the computer, to keep the cost of the computer low.</p><h2 id="Pictures">Pictures</h2><p><a href="docs/1551_mod/1541_front.jpg"><img src="docs/1551_mod/1541_front_small.jpg" alt="" /></a></p><p>The modded 1541 looks just like a 1541 from the front, except for the device 8/9 switch – but many 1541 drives had that added.</p><p><a href="docs/1551_mod/1570_front.jpg"><img src="docs/1551_mod/1570_front_small.jpg" alt="" /></a></p><p>The 1570 has the power LED converted into a reset button with a power LED, and on the right, there is an added device 8/9 toggle button with an LED indicating the current device number.</p><p><a href="docs/1551_mod/1541_back.jpg"><img src="docs/1551_mod/1541_back_small.jpg" alt="" /></a></p><p>On the back, the 1541 has two holes where the serial ports were, and the added 1551 paddle cable.</p><p><a href="docs/1551_mod/1570_back.jpg"><img src="docs/1551_mod/1570_back_small.jpg" alt="" /></a></p><p>The 1570 also has empty holes, but it uses a DB15 connector for the paddle.</p><p><a href="docs/1551_mod/1541_inside.jpg"><img src="docs/1551_mod/1541_inside_small.jpg" alt="" /></a></p><p>The mechanics of the 1541 are unchanged, but the board has been replaced with a 1551 board.</p><p><a href="docs/1551_mod/1570_inside.jpg"><img src="docs/1551_mod/1570_inside_small.jpg" alt="" /></a></p><p>Same on the 1570.</p><p><a href="docs/1551_mod/1541_board.jpg"><img src="docs/1551_mod/1541_board_small.jpg" alt="" /></a></p><p>Here is a closeup of the 1551 board in the 1541. It contains a MOS 6510T CPU (2 MHz version of the C64’s 6510 CPU) and a MOS 6525 TPI I/O controller.</p><p>The top left connector is power. The four white connectors at the bottom and the black connector at the top lead to the drive mechanics and are just compatible between the 1541 and the 1551. The black cable on the left goes to the paddle.</p><p>A standard 1551 does not have a switch to change the device number. Cutting the trace at JP1 would switch it from 8 to 9. Here, the trace is cut, and the yellow/white wires lead to the switch at the front.</p><p><a href="docs/1551_mod/1570_board.jpg"><img src="docs/1551_mod/1570_board_small.jpg" alt="" /></a></p><p>Things look similar in the 1570. JP1 is cut and connected here as well (blue/green) and goes to the toggle switch on the right of the front panel. But there are two more connectors: the orange/red one at the top right (drive number LED), and the white/gray one at the bottom center (reset button).</p><p><a href="docs/1551_mod/gw1.jpg"><img src="docs/1551_mod/gw1_small.jpg" height="199" width="300" alt="" /></a><a href="docs/1551_mod/gw2.jpg"><img src="docs/1551_mod/gw2_small.jpg" height="199" width="300" alt="" /></a></p><p>These pictures compare the unmodified board with the modified one. The white/gray wires move the capacitor C13 and add a header that leads to the button on the left of the front panel. Pressing the button causes a reset.</p><p><a href="docs/1551_mod/ro1.jpg"><img src="docs/1551_mod/ro1_small.jpg" height="204" width="300" alt="" /></a><a href="docs/1551_mod/ro2.jpg"><img src="docs/1551_mod/ro2_small.jpg" height="204" width="300" alt="" /></a></p><p>The newly added orange/red wires connect to the LED on the right of the front panel. The LED will show whether the device number is 8 or 9.</p><p><a href="docs/1551_mod/paddle_board_front.jpg"><img src="docs/1551_mod/paddle_board_front_small.jpg" alt="" /></a></p><p>The modded 1541 uses a regular 1551 paddle. It contains a 251641-03 PLA and a 6523T TPI I/O controller. The 6323T TPI is a chip that was only ever used in the paddle. It is the DIP-28 version of the DIP-40 6525 TPI (used in the drive), i.e. the same die in a smaller package. The TPI has three times 8 GPIOs (PA, PB, PC), but on the 6523T version, only PA, PB0/1 and PC6/7 are exposed, which is just enough for the 12 wire TCBM protocol. In case the 6523T ever breaks, <a href="http://www.zimmers.net/anonftp/pub/cbm/documents/projects/drives/1551-tia.gif">a full 6525 can be used in its place</a>.</p><p>The PLA is the address decoder to map the TIA to either $FEC0 or $FEE0 in the computer’s address space. In case the PLA breaks, it can be replaced by a <a href="https://www.polyplay.xyz/PLAdvanced-PLA-Replacement_1">PLAdvanced</a> or a <a href="https://icomp.de/shop-icomp/en/shop/product/superpla-v4.html">SuperPLA V4</a>.</p><p><a href="docs/1551_mod/paddle_board_back.jpg"><img src="docs/1551_mod/paddle_board_back_small.jpg" alt="" /></a></p><p>This is the back of the paddle.</p><p><a href="docs/1551_mod/board_front.jpg"><img src="docs/1551_mod/board_front_small.jpg" alt="" /></a></p><p>The modded 1570 came with a hand-built paddle. It uses an original 251641-03 PLA with a date code of 2190. 1990 is very late for a chip that was only used in disk drives dicontinued not long after 1985. Commodore may have been producing it as a replacement part for quite a while<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup>.</p><p>The TPI is the DIP-40 6525 described earlier. The extra pins are just not connected. The 6523T was probably not available as a replacement part from Commodore.</p><p><a href="docs/1551_mod/board_back.jpg"><img src="docs/1551_mod/board_back_small.jpg" alt="" /></a></p><p>And here is the back of the hand-built paddle. The schematics are pretty simple. The <a href="http://www.zimmers.net/anonftp/pub/cbm/schematics/drives/new/1551/paddle-251925.png">original schematics</a> exist, as well as a <a href="http://www.zimmers.net/anonftp/pub/cbm/schematics/drives/new/1551/1551crt.gif">newer reverse-engineered version</a>.</p><p><a href="docs/1551_mod/connector.jpg"><img src="docs/1551_mod/connector_small.jpg" alt="" /></a></p><p>This is the DB15 connector used to connect the paddle to the drive.</p><h2 id="Conclusion">Conclusion</h2><p>The modded 1541 was most likely created by combining a 1551 that had dead mechanics with a 1541 that possibly had a dead board.</p><p>The 1570 was more likely modded from scratch. The 1551 board might have been available as a replacement part that could be ordered from Commodore. The paddle either wasn’t available as a replacement part, or was too expensive, so it was hand-built using Commodore replacement ICs.</p><p>The mechanics and the cases of both the 1541 and the 1570 are compatible with the 1551 electronics, so it is possible to revive a 1551 with dead mechanics, or even build a 1551 from a 1541/1570 and a 1551 board and some extra parts.</p><h2 id="Things-To-Do">Things To Do</h2><p>The 1570’s reset switch in the power LED and the 8/9 switch with an LED indicator are great modifications. It would be interesting to understand how they work using the schematics, and write instructions for modding other 1551-like devices like this.</p><div class="footnotes"><hr/><ol><li id="fn:1"><p>PLA stands for “Programmable Logic Array”, so Commodore could easily create more of these chips at any time.<a href="#fnref:1" rev="footnote">↩</a></p></li></ol></div>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1331</wfw:commentRss> <slash:comments>4</slash:comments> </item> <item> <title>More Original Commodore Source Code</title> <link>https://www.pagetable.com/?p=1333</link> <comments>https://www.pagetable.com/?p=1333#respond</comments> <pubDate>Tue, 21 May 2019 10:56:26 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[6502]]></category> <category><![CDATA[Archeology]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Commodore Peripheral Bus]]></category> <category><![CDATA[Floppy Disks]]></category> <category><![CDATA[GitHub]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1333</guid> <description><![CDATA[There have been a few new interesting additions to the Commodore Source Code repository, including: RAMDOS: An RAM disk implementation of Commodore DOS that runs on the computer side and stores the data in a REU. It supports most of the Commodore DOS API including relative files. 1570: Commodore sold a single-side stripped down 1571-derivative ... <a title="More Original Commodore Source Code" class="read-more" href="https://www.pagetable.com/?p=1333">Read more<span class="screen-reader-text">More Original Commodore Source Code</span></a>]]></description> <content:encoded><![CDATA[<p>There have been a few new interesting additions to the <a href="https://github.com/mist64/cbmsrc">Commodore Source Code</a> repository, including:</p><ul><li>RAMDOS: An RAM disk implementation of <a href="https://www.pagetable.com/?p=1038">Commodore DOS</a> that runs on the computer side and stores the data in a REU. It supports most of the Commodore DOS API including relative files.</li><li>1570: Commodore sold a single-side stripped down 1571-derivative for a while.</li><li>1571CR: The cost-reduced 1571 with the integrated 5710 I/O and FDC controller.</li><li>1551: The odd one, with the one-off <a href="https://www.pagetable.com/?p=1324">TCBM</a> bus. The source is odd too, because all filenames have been renamed to three characters.</li><li>1541: Three original versions of the 1541 DOS source. (This amends my previous reconstructions from the 1540 and 1571 sources.)</li></ul><p>I am planning to add more source. I’m happy for any pointers.</p>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1333</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>Commodore Peripheral Bus: Part 5: TCBM</title> <link>https://www.pagetable.com/?p=1324</link> <comments>https://www.pagetable.com/?p=1324#comments</comments> <pubDate>Mon, 20 May 2019 15:00:17 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Commodore]]></category> <category><![CDATA[Commodore Peripheral Bus]]></category> <category><![CDATA[Floppy Disks]]></category> <category><![CDATA[TED]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1324</guid> <description><![CDATA[In the series about the variants of the Commodore Peripheral Bus family, this article covers the lowest two layers (electrical and byte transfer) of the “TCBM” bus as found on the TED series computers: the C16, C116 and the Plus/4. NOTE: I am releasing one part every week, at which time links will be added ... <a title="Commodore Peripheral Bus: Part 5: TCBM" class="read-more" href="https://www.pagetable.com/?p=1324">Read more<span class="screen-reader-text">Commodore Peripheral Bus: Part 5: TCBM</span></a>]]></description> <content:encoded><![CDATA[<p>In the <a href="https://www.pagetable.com/?p=1018">series about the variants of the Commodore Peripheral Bus family</a>, this article covers the lowest two layers (electrical and byte transfer) of the “TCBM” bus as found on the TED series computers: the C16, C116 and the Plus/4.</p><p><img src="docs/cbmbus/tcbm_layers.png" height="241" width="371" alt="" /></p><hr/><blockquote><p><strong><em>NOTE:</em></strong> I am releasing one part every week, at which time links will be added to the bullet points below. The articles will also be announced on my Twitter account <a href="https://twitter.com/pagetable">@pagetable</a> and my Mastodon account <a href="https://mastodon.social/@pagetable">@pagetable@mastodon.social</a>.</p></blockquote><hr/><ul><li><a href="https://www.pagetable.com/?p=1018">Part 0: Overview and Introduction</a></li><li><a href="https://www.pagetable.com/?p=1023">Part 1: IEEE-488</a> [PET/CBM Series; 1977]</li><li><a href="https://www.pagetable.com/?p=1031">Part 2: The TALK/LISTEN Layer</a></li><li><a href="https://www.pagetable.com/?p=1038">Part 3: The Commodore DOS Layer</a></li><li><a href="https://www.pagetable.com/?p=1135">Part 4: Standard Serial (IEC)</a> [VIC-20, C64; 1981]</li><li><strong>Part 5: TCBM [C16, C116, Plus/4; 1984]</strong> ← <em>this article</em></li><li>Part 6: JiffyDOS [1985] <em>(coming soon)</em></li><li>Part 7: Fast Serial [C128; 1986] <em>(coming soon)</em></li><li>Part 8: CBDOS [C65; 1991] <em>(coming soon)</em></li></ul><h2 id="Naming">Naming</h2><p>The only computers with a TCBM bus are the Commodore C16, C116 and Plus/4. Internally, Commodore called these the TED series, named after the core IC of the system<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup>. This name can be seen in multiple places in the <a href="https://github.com/mist64/cbmsrc">TED KERNAL and BASIC sources</a> as well as <a href="https://www.pagetable.com/?p=541">internal documentation</a>. Even though Commodore never marketed these computers under the name TED, many products around them, like software cartridges, had product codes prefixed with “T”<sup id="fnref:2"><a href="#fn:2" rel="footnote">2</a></sup>.</p><p>The naming for the new peripheral bus of the TED is not completely consistent:</p><ul><li>Comments in the <a href="https://github.com/mist64/cbmsrc/tree/master/KERNAL_TED_05">KERNAL driver code</a> call it the <strong>Kennedy</strong> or <strong>KDY</strong> interface – a reference to <a href="https://en.wikipedia.org/wiki/Ted_Kennedy">the politician</a>. Some places call it <strong>TEDISK</strong>.</li><li>The 1551 power-on message is “CBM DOS 2.6 <strong>TDISK</strong>”, which seems a variant of “TEDISK”.</li><li>The <a href="http://www.zimmers.net/anonftp/pub/cbm/manuals/drives/1551_Disk_Drive_Users_Guide.pdf">users manual</a> and the <a href="http://www.zimmers.net/anonftp/pub/cbm/schematics/drives/new/1551/251860.gif">schematics</a> of the 1551 disk drive call it <strong>TCBM</strong>. “CBM” is the common abbreviation of “Commodore Business Machines”, and the “T”, as always, stands for “TED”.</li></ul><h2 id="History-and-Development">History and Development</h2><p>The Commodore PET (1977) was using the industry-standard 8-bit parallel <a href="https://www.pagetable.com/?p=1023">IEEE-488 bus</a> for disk drives and printers. For the VIC-20 (1981), Commodore changed layers 1 and 2 of the protocol stack (electrical and byte transfer) into a cheaper <a href="https://www.pagetable.com/?p=1135">serial bus</a>, which turned out to have severe speed problems<sup id="fnref:3"><a href="#fn:3" rel="footnote">3</a></sup>.</p><p>For the TED series (1984), Commodore decided to create another variant of the protocol stack, replacing layers 1 and 2 again. The new bus was supposed to combine the speed of the IEEE-488 bus with the low cost of the serial bus.</p><p>While the switch from parallel IEEE-488 to serial allowed the protocol stack to retain all key properties of the original design, TCBM drops some of these features:</p><table><thead><tr><th> Feature </th><th> IEEE-488 </th><th> Serial </th><th> TCBM </th></tr></thead><tbody><tr><td> All participants are <strong>daisy-chained</strong>. </td><td> Yes </td><td> Yes </td><td> <strong>No</strong> </td></tr><tr><td> <strong>One dedicated controller</strong> (the computer) does bus arbitration of <strong>up to 31 devices</strong>. </td><td> Yes </td><td> Yes </td><td> <strong>No</strong> </td></tr><tr><td> <strong>One-to-many</strong>: Any participant can send data to any set of participants. </td><td> Yes </td><td> Yes </td><td> <strong>No</strong> </td></tr><tr><td> A device has <strong>multiple channels</strong> for different functions. </td><td> Yes </td><td> Yes </td><td> Yes </td></tr><tr><td> Data transmission is <strong>byte stream</strong> based. </td><td> Yes </td><td> Yes </td><td> Yes </td></tr></tbody></table><p>A device still has multiple channels, and all data transmission is still byte stream based, because these are properties of the layers 3 and 4, which are retained in TCBM.</p><p>The key difference is that the TCBM bus is point-to-point: The bus is between one controller (the computer) and one device. For connecting multiple devices to one computer, the computer needs one dedicated bus per device.</p><p>With the introduction of Fast Serial with the C128, Commodore gave up the TCBM bus, which had only shipped with the TED series.</p><h2 id="Layer-1:-Electrical">Layer 1: Electrical</h2><h3 id="Connectors-and-Pinout">Connectors and Pinout</h3><p>There are no standardized connectors. Both on the computer and the device side, the 17 wires are connected directly to the board through pin headers. This is the computer side:</p><p><a href="docs/cbmbus/tcbm_connector.jpg"><img src="docs/cbmbus/tcbm_connector_small.jpg" height="311" width="600" alt="" /></a></p><p>And the device side:</p><p><a href="docs/cbmbus/tcbm_connector2.jpg"><img src="docs/cbmbus/tcbm_connector2_small.jpg" height="311" width="600" alt="" /></a></p><p>This is the pinout:</p><table><thead><tr><th> Pin </th><th> Signal </th><th> Description </th></tr></thead><tbody><tr><td> 1 </td><td> GND </td><td> Ground </td></tr><tr><td> 2 </td><td> DEV </td><td> Device 0/1 </td></tr><tr><td> 3 </td><td> DIO1 </td><td> Data I/O </td></tr><tr><td> 4 </td><td> DIO2 </td><td> Data I/O </td></tr><tr><td> 5 </td><td> DIO3 </td><td> Data I/O </td></tr><tr><td> 6 </td><td> DIO4 </td><td> Data I/O </td></tr><tr><td> 7 </td><td> DIO5 </td><td> Data I/O </td></tr><tr><td> 8 </td><td> DIO6 </td><td> Data I/O </td></tr><tr><td> 9 </td><td> DIO7 </td><td> Data I/O </td></tr><tr><td> 10 </td><td> DIO8 </td><td> Data I/O </td></tr><tr><td> 11 </td><td> DAV </td><td> Data Valid </td></tr><tr><td> 12 </td><td> STATUS0 </td><td> Status 0 </td></tr><tr><td> 13 </td><td> ACK </td><td> Acknowledge </td></tr><tr><td> 14 </td><td> STATUS1 </td><td> Status 1 </td></tr><tr><td> 15 </td><td> RESET </td><td> Reset </td></tr><tr><td> 16 </td><td> GND </td><td> Ground </td></tr><tr><td> 17 </td><td> GND </td><td> Ground </td></tr></tbody></table><ul><li>There are 8 data lines, DIO1-8<sup id="fnref:4"><a href="#fn:4" rel="footnote">4</a></sup>.</li><li>The two STATUS lines are used by the device to signal errors.</li><li>The DAV and ACK lines are used for handshaking.</li><li>The RESET line resets the device.</li><li>The DEV line tells the paddle whether to create bus #0 or #1 (see below).</li></ul><h3 id="Open-Collector-Logic">Open Collector Logic</h3><p><!--- this is *similiar* to the text in part 1 --></p><p>The DIO lines are TTL open collector, which means:</p><ul><li>Both participants of the bus can not only read, but also write to the line.</li><li>When <strong>both</strong> participants write 0, the line will read back 0, but if either device writes 1, the bus will read back as 1.</li><li>The logic is inverted: 5V is 0 (false), and 0V is 1 (true).</li></ul><p>In other words: If the line is <em>released</em> by both bus participants, it will be 5V (logically 0), and either participant can <em>pull</em> it to 0V (logically 1).</p><p>This can be visualized with two hands that can pull the line to 1, and a spring that pushes it to 0:</p><p><img src="docs/cbmbus/open_collector.gif" height="162" width="302" alt="" /></p><p>So when a line reads as 0, it is known that it is currently released by all participants, and if a line reads as 1, one or more participants are pulling it, but it is impossible to know who or even how many.</p><h3 id="Paddle">Paddle</h3><p>The TED series spans from the super-low-cost<sup id="fnref:5"><a href="#fn:5" rel="footnote">5</a></sup> C116 (rubber keyboard, 16 KB) to the high-end Plus/4 (pro keyboard, 64 KB, RS232, built-in productivity software). The <a href="https://www.pagetable.com/?p=1135">Standard Serial</a> port only requires 3 GPIO lines and was natively supported by all TED machines. A parallel bus would have required adding an additional I/O controller.</p><p>To save on costs, the I/O controller did not come with the computer. Instead, it shipped with the disk drive, where the costs of the chip were eclipsed by the total cost of the drive (USD 269).</p><p>The 1551 disk drive, the only TCBM device made, came with a fixed cable that ended in the so-called “Paddle”, a cartridge for the TED expansion port. The expansion port on Commodore computers exposes the complete internal bus, allowing the I/O controller in the paddle to map itself into the computer’s address space.</p><p>Each paddle has a pass-through connector to allow using any other cartridge at the same time – or to connect a another paddle.</p><p>A second 1551 required its own paddle on top of the first one. In this setup, there is one I/O controller in each paddle, which is mapped to one of two locations in the computer’s address space. A switch in the disk drive tells the paddle through the DEV line which location and thus which device number the drive should have<sup id="fnref:6"><a href="#fn:6" rel="footnote">6</a></sup>.</p><p><a href="docs/cbmbus/tcbm_paddle.jpg"><img src="docs/cbmbus/tcbm_paddle_small.jpg" height="494" width="300" alt="" /></a><a href="docs/cbmbus/tcbm_paddle_board.jpg"><img src="docs/cbmbus/tcbm_paddle_board_small.jpg" height="408" width="300" alt="" /></a><a href="docs/cbmbus/tcbm_paddle_connected.jpg"><img src="docs/cbmbus/tcbm_paddle_connected_small.jpg" height="247" width="300" alt="" /></a></p><h4 id="Multiple-Busses">Multiple Busses</h4><p>The TED computers support the Standard Serial bus and send all traffic to devices 4-30 to this bus. If a paddle with DEV = 0 is detected, it will direct traffic to drive 8 to this TCBM bus. And if there is a paddle with DEV = 1, all traffic to drive 9 will go to that TCBM bus. This allows a TED to have up to three separate Commodore Peripheral busses. All participants of the Standard Serial bus can talk to each other, but the TCBM busses are point-to-point<sup id="fnref:7"><a href="#fn:7" rel="footnote">7</a></sup>.</p><p>The presence of a TCBM device is detected<sup id="fnref:8"><a href="#fn:8" rel="footnote">8</a></sup> whenever a communication channel is initiated (<a href="https://www.pagetable.com/?p=1031">layer 3</a> TALK or LISTEN) for devices 8 or 9.</p><h2 id="Layer-2:-Byte-Transfer">Layer 2: Byte Transfer</h2><p>The byte transfer layer of TCBM defines the roles of the controller (which is the computer) and the device.</p><p>The controller and the device each own one handshaking line: DAV and ACK, respectively. The names stand for “Data Valid” and “Acklowledge”, but in practice, they are just general handshaking lines with different meanings across the protocol.</p><p>The device also owns the two STATUS lines to communicacte error codes to the controller. The eight DIO lines are shared and used to send data in either direction. The protocol defines at what point which participant owns it.</p><p>All communication is initiated by the controller by telling the device whether data is sent to it or received from it, or whether a layer 3 command is sent to the device.</p><h3 id="Sending-Bytes">Sending Bytes</h3><p>When the controller sends data to the device, it owns the eight DIO lines during the whole process. The basic idea is that the controller sends a TCBM code of 0x83 to indicate a byte send, then sends the byte, and the device returns a two-bit status code.</p><p><img src="docs/cbmbus/tcbm-send.gif" height="577" width="601" alt="" /></p><p>Let’s go through it step by step:</p><h4 id="0:-Initial-State">0: Initial State</h4><p><img src="docs/cbmbus/tcbm-01.png" height="261" width="601" alt="" /><br />In the initial state, the controller is holding the DAV line to indicate that it it is not ready for the next transmission. The device is holding the ACK line, meaning it is not ready either. The DIO and ST lines are all released.</p><h4 id="1:-Controller-puts-code-0x83-on-the-bus">1: Controller puts code 0x83 on the bus</h4><p><img src="docs/cbmbus/tcbm-02.png" height="261" width="601" alt="" /><br />All communication is initiated by the controller by putting a TCBM code byte onto DIO. 0x83 means that the controller intends to send a byte to the device.</p><h4 id="2:-Device-has-accepted-the-code">2: Device has accepted the code</h4><p><img src="docs/cbmbus/tcbm-03.png" height="261" width="601" alt="" /><br />At some point the device is done handling the previous byte it may have received, so it detects that the most significant bit of DIO is set, reads the TCBM code, and signals that it has received the code by releasing ACK.</p><h4 id="3:-Controller-puts-data-on-the-bus">3: Controller puts data on the bus</h4><p><img src="docs/cbmbus/tcbm-04.png" height="261" width="601" alt="" /><br />Triggered by ACK being 0, the controller now puts the byte value onto DIO.</p><h4 id="4:-Data-on-bus-is-now-valid">4: Data on bus is now valid</h4><p><img src="docs/cbmbus/tcbm-05.png" height="261" width="601" alt="" /><br />After that, the controller releases DAV, signaling that the data in DIO is valid.</p><h4 id="5:-Device-puts-status-on-the-bus">5: Device puts status on the bus</h4><p><img src="docs/cbmbus/tcbm-06.png" height="261" width="601" alt="" /><br />Triggered by DAV being 0, the device reads the data from DIO and puts the two status bits onto ST.</p><h4 id="6:-Device-has-accepted-the-data,-status-is-valid">6: Device has accepted the data, status is valid</h4><p><img src="docs/cbmbus/tcbm-07.png" height="261" width="601" alt="" /><br />It then pulls ACK, signaling that it has accepted the data and that the status is valid.</p><h4 id="7:-Controller-clears-data-on-the-bus">7: Controller clears data on the bus</h4><p><img src="docs/cbmbus/tcbm-08.png" height="261" width="601" alt="" /><br />Triggered by ACK being 1, the controller reads the status, and sets the DIO lines back to 0, so they can’t be interpreted as a TCBM code in the next cycle.</p><h4 id="8:-Controller-resets-data-valid">8: Controller resets data valid</h4><p><img src="docs/cbmbus/tcbm-09.png" height="261" width="601" alt="" /><br />In order to return to the initial state, the sender then pulls DAV.</p><h4 id="9:-Device-resets-status">9: Device resets status</h4><p><img src="docs/cbmbus/tcbm-10.png" height="261" width="601" alt="" /><br />Triggered by DAV being 1 (the controller has read the status), the device clears the status. All wires are now in the initial state again. All steps are repeated as long as there is more data to be sent.</p><p><img src="docs/cbmbus/tcbm-send.png" height="275" width="601" alt="" /></p><h3 id="Receiving-Bytes">Receiving Bytes</h3><p>When the controller wants to receive data from the device, ownership of the eight DIO lines is passed to the device and back. The basic idea is that the controller sends a TCBM code of 0x84 to indicate a byte receive, passes DIO to the device, the device returns the byte and a two-bit status code, and DIO is passed back to the controller.</p><p><img src="docs/cbmbus/tcbm-receive.gif" height="577" width="601" alt="" /></p><p>Here it is step by step:</p><h4 id="0:-Initial-State">0: Initial State</h4><p><img src="docs/cbmbus/tcbm-11.png" height="261" width="601" alt="" /><br />The initial state between bytes when receiving is the same as when sending: The controller is holding the DAV line to indicate that it it is not ready for the next transmission and the device is holding the ACK line, meaning it is not ready either. The DIO and ST lines are all released.</p><h4 id="1:-Controller-puts-code-0x84-on-the-bus">1: Controller puts code 0x84 on the bus</h4><p><img src="docs/cbmbus/tcbm-12.png" height="261" width="601" alt="" /><br />For receiving, the controller puts the TCBM code of 0x84 into DIO, indicating that it is now ready to receive a byte.</p><h4 id="2:-Device-has-accepted-the-code">2: Device has accepted the code</h4><p><img src="docs/cbmbus/tcbm-13.png" height="261" width="601" alt="" /><br />As soon as the device is done handling the last transmission, it detects that the most significant bit of DIO is set, reads the TCBM code, and signals that it has received the code by releasing ACK.</p><h4 id="3:-Controller-clears-data-on-the-bus">3: Controller clears data on the bus</h4><p><img src="docs/cbmbus/tcbm-14.png" height="261" width="601" alt="" /><br />For the transmission of the data, the DIO lines will be operated by the device, so triggered by ACK being 0 (the device has received the code), the controller releases all DIO lines.</p><h4 id="4:-Controller-signals-DIO-belongs-to-device">4: Controller signals DIO belongs to device</h4><p><img src="docs/cbmbus/tcbm-15.png" height="261" width="601" alt="" /><br />To signal that the DIO lines now belong to the device, the controller then releases DAV.</p><h4 id="5:-Device-puts-data-on-the-bus">5: Device puts data on the bus</h4><p><img src="docs/cbmbus/tcbm-16.png" height="261" width="601" alt="" /><br />Triggered by DAV being 0, the device puts the data onto DIO.</p><h4 id="6:-Device-puts-status-on-the-bus">6: Device puts status on the bus</h4><p><img src="docs/cbmbus/tcbm-17.png" height="261" width="601" alt="" /><br />It also puts the status bits onto ST.</p><h4 id="7:-Data-on-bus-is-now-valid">7: Data on bus is now valid</h4><p><img src="docs/cbmbus/tcbm-18.png" height="261" width="601" alt="" /><br />After that, the device pulls ACK, signaling that the data in DIO is valid.</p><h4 id="8:-Controller-has-accepted-the-data">8: Controller has accepted the data</h4><p><img src="docs/cbmbus/tcbm-19.png" height="261" width="601" alt="" /><br />Triggered by ACK being 1, the controller reads the data and the status from DIO and pulls DAV, indicating that it has accepted the data.</p><h4 id="9:-Device-clears-data-on-the-bus">9: Device clears data on the bus</h4><p><img src="docs/cbmbus/tcbm-20.png" height="261" width="601" alt="" /><br />Triggered by DAV being 1, the device clears the data from DIO, in order to return ownership of these lines to the controller.</p><h4 id="10:-Device-clears-status">10: Device clears status</h4><p><img src="docs/cbmbus/tcbm-21.png" height="261" width="601" alt="" /><br />It then resets the status lines, so they are in the initial state again.</p><h4 id="11:-Device-signals-it-is-done-with-DIO">11: Device signals it is done with DIO</h4><p><img src="docs/cbmbus/tcbm-22.png" height="261" width="601" alt="" /><br />Finally, it releases ACK to indicate that it is no longer using DIO.</p><h4 id="12:-Controller-signals-it-owns-DIO">12: Controller signals it owns DIO</h4><p><img src="docs/cbmbus/tcbm-23.png" height="261" width="601" alt="" /><br />Triggered by ACK being 0, the controller releases DAV, meaning it now owns the DIO lines again.</p><h4 id="13:-Device-returns-to-initial-state">13: Device returns to initial state</h4><p><img src="docs/cbmbus/tcbm-24.png" height="261" width="601" alt="" /><br />Triggered by DAV being 0, the device pulls ACK, which is the initial state.</p><h4 id="14:-Controller-returns-to-initial-state">14: Controller returns to initial state</h4><p><img src="docs/cbmbus/tcbm-25.png" height="261" width="601" alt="" /><br />Triggered by ACK being 1, the controller pulls DAV. All wires are now in the initial state again. All steps are repeated as long as there is more data to be received.</p><p>Note that the protocol only specifies the triggers: For example, the controller is to read the data from DIO once ACK = 1, so it would be just as legal for the the device to put the status on the bus before the data, or put both the status and the data on the bus and pull ACK at the same time.</p><p><img src="docs/cbmbus/tcbm-receive.png" height="275" width="601" alt="" /></p><h3 id="Sending-Commands">Sending Commands</h3><p><a href="https://www.pagetable.com/">Layer 3</a> of the protocol stack requires the controller to send commands (“TALK”/“LISTEN”) to devices. Layer 2 therefore has a mode for the transmission of command byte streams.</p><p>As shown before, for the transmission of each byte, the controller first sends a TCBM code to the device indicating whether a byte is supposed to be sent (0x83) or received (0x84) by the controller.</p><p>Commands are sent just like data bytes, but with a TCBM code of 0x81 or 0x82.</p><p>Whether the TCBM cde is 0x81 or 0x82 depends on the type of layer 3 command: The commands 0x20/0x3F/0x40/0x5F (LISTEN, UNLISTEN, TALK, UNTALK) are sent with the TCBM code 0x81, and the commands 0x60/0xE0/0xF0 (SECOND, CLOSE, OPEN) are sent with the TCBM code 0x82.</p><p>While the other variants of the Commodore Peripheral Bus protocol family strictly separate the layers, this is one case where details from a higher layer leak into a lower layer.</p><table><thead><tr><th> TCBM code </th><th> Description </th></tr></thead><tbody><tr><td> 0x81 </td><td> Controller sends command byte (state change) </td></tr><tr><td> 0x82 </td><td> Controller sends command byte (secondary address) </td></tr><tr><td> 0x83 </td><td> Controller sends data byte </td></tr><tr><td> 0x84 </td><td> Controller receives data byte </td></tr></tbody></table><h3 id="Status-Codes">Status Codes</h3><p>With the transmission of every byte in either direction, the device sends a two-bit status code to the controller:</p><table><thead><tr><th> Status </th><th> Description </th></tr></thead><tbody><tr><td> 00 </td><td> OK </td></tr><tr><td> 01 </td><td> receive error </td></tr><tr><td> 10 </td><td> send error </td></tr><tr><td> 11 </td><td> EOI </td></tr></tbody></table><p>In the general case, the device sends a status of 00, which means that everything is okay.</p><p>A receive error is returned by the device if the controller was trying to receive a byte from the device, but the device did not have any data. This corresponds to the IEEE-488 “sender timeout” and the Standard Serial “empty stream” case. It signals a <a href="https://www.pagetable.com/?p=1038">Commodore DOS (layer 4)</a> “FILE NOT FOUND” condition.</p><p>A send error is returned by the device if the controller was trying to send a byte to the device, but the device decided not to accept it.</p><p>The “EOI” (“End or Identify”) status is returned if the byte currently received by the controller is the last byte of the stream.</p><h3 id="Timing">Timing</h3><p>The timing of TCBM is completely flexible, there are no timeouts. Both the controller and the device can stall any step in the protocol as long as they wish<sup id="fnref:9"><a href="#fn:9" rel="footnote">9</a></sup>.</p><h3 id="Discussion">Discussion</h3><p>A lot can be criticized about the TCBM bus:</p><h4 id="Paddle">Paddle</h4><p>The paddles are of course awkward and ugly<sup id="fnref:10"><a href="#fn:10" rel="footnote">10</a></sup>, and in the case of two paddles connected at the same time, even to a comical extent.</p><p>If there was no way around the requirement of not shipping the computer with the necessary I/O chip, there could instead have been a cartridge with the chip – like the <a href="https://www.pagetable.com/?p=1312">IEEE-488 cartridge for the C64</a> – supporting any number of daisy-chained devices with cheap DB-25 connectors.</p><h4 id="Protocol-Stack-Issues">Protocol Stack Issues</h4><p>There are two details that divert from the clean original design of the IEEE-488 stack:</p><p>There is no strict separation of layers 2 and 3. The TCBM codes 0x81 and 0x82 on layer 2 depend on the type of command on layer 3. Layer 2 should not have any knowledge of layer 3: It should be possible to add layer 3 commands or even replace all of layer 3 completely, with all layer 2 variants still compatible. This would be true for IEEE-488 and Standard Serial, but not for TCBM.</p><p>Also, with TCBM the communication features are not symmetric any more: While a device can signal the EOI condition by setting the status wires to “11”, there is no way for the controller to signal EOI to the device. For Commodore DOS disk drives, this is not necessary: EOI from the device indicates that the end of a file has been reached, which is necessary and actionable for the controller, but EOI from the controller is not necessary: If the end of a stream sent for writing has been reached, there is nothing actionable for the drive yet. The controller, who knows about the EOI condition, can then send a layer 3 UNTALK or CLOSE command.</p><h4 id="Speed">Speed</h4><p>There are several issues with the protocol, which lead to a much lower speed than what would be expected from a parallel connection:</p><h5 id="Unnecessary-Steps">Unnecessary Steps</h5><p>When the controller receives a byte, releasing DAV in step 4 (“Controller signals DIO belongs to device”) is not necessary. The device can already detect that the TCBM code has been removed from DIO in step 3 (MSB is 0) and use it as a trigger for step 5. In a modified protocol with step 4 removed, DAV would be inverted from this point on. So in step 12, the controller would pull DAV instead of releasing it, which is the initial state, so the additional handshake in step 14 would be unnecessary.</p><h5 id="TCBM-Codes">TCBM Codes</h5><p>The design of the TCBM code being sent with every byte almost halves the trasmission speed because of its two handshakes.</p><p>The complex protocol to hand the DIO wires to the device and pass it back with its extra handshakes will also make receiving slower than sending. But receiving is the common case: Much more data is ever read from disk than written to it.</p><p>Most data transmissions between a computer and a disk drive are the LOAD and SAVE operations, where a full file is transfered in one go. Optimized stream transfer protocols could have been added for these cases – the Fast Serial protocol of the C128 (“Burst”) as well as JiffyDOS do this – doubling the SAVE speed and tripling the LOAD speed.</p><p>A more generic protocol optimization could replace the TCBM code before every byte with an extra wire owned by the controller indicating whether the next byte will be transmitted in the same mode. The common case of transfering multiple bytes would also be sped up by at least a factor of two this way, and even more in the receive case, which would no longer require the DIO handover between bytes.</p><p>This would not even require adding an extra line: It is enough to have one status line going from the device to the computer. “0” would mean OK, and in the rare case of “1”, the controller would transfer DIO to the device, so it can return an 8 bit status code.</p><h5 id="Other-Solutions">Other Solutions</h5><p>It is puzzling why they created a completely custom layer 2 protocol that ended up having so many issues, because they could have started with one of the existing layer 2 protocols and easily adapted it:</p><p>They could have used the exact IEEE-488 protocol on layer 2, even in point-to-point mode with just a single device. IEEE-488 only requires one more data line (13 instead of 12), but if that had been an issue, they could have removed EOI and used a timing sidechannel instead, as done by Standard Serial.</p><p>Another option would have been to just reuse the Standard Serial protocol and add another 8 parallel wires for the transfer of the actual data, for a total of 11 wires (one fewer than TCBM). That’s what third party hardware extensions for the C64/1541 like Speed DOS and Professional DOS did.</p><p>Yet another option would have been to finally implement the original hardware-based serial protocol that was intended for the VIC-20, but scrapped because of hardware bugs. 8 data lines and one handshaking line can be replaced by one data line and a handshaking line, with a dedicated hardware shift register pushing a bit every few cycles. With hardware that has a working shift register, there is nothing wrong with such a protocol.</p><p>A shift register based serial protocol is exactly what replaced TCBM in the C128 as the “Fast Serial” protocol.</p><h4 id="Conclusion">Conclusion</h4><p>While TCBM is faster than Standard Serial, it is a huge compromise and certainly not a clean design. And with more than half the bandwidth eaten up by the TCBM codes, it is still slower than IEEE-488.</p><h3 id="Next-Up">Next Up</h3><p>Part 6 of the series of articles on the Commodore Peripheral Bus family will cover the JiffyDOS protocol on layer 2, which shipped as a third party ROM patch for computers and drives, replacing the byte transmission protocol of Standard Serial by using the clock and data lines in a more efficient way.</p><blockquote><p>This article series is an Open Source project. Corrections, clarifications and additions are <strong>highly</strong> appreciated. I will regularly update the articles from the repository at <a href="https://github.com/mist64/cbmbus_doc">https://github.com/mist64/cbmbus_doc</a>.</p></blockquote><h1 id="References">References</h1><ul><li><a href="http://www.zimmers.net/anonftp/pub/cbm/src/plus4/plus4_rom_disassembly.txt">The Complete ROM dissasembly</a> by Mike Dailly</li><li><a href="http://www.cbmhardware.de/show.php?r=7&id=21">The Complete Commodore 1551 ROM disassembly</a> by Attila Grósz</li><li><a href="https://www.github.com/mist64/cbmsrc">Original source code of various Commodore computers and peripherals</a></li><li><a href="http://www.zimmers.net/anonftp/pub/cbm/schematics/drives/new/1551/index.html">Commodore 1551 schematics</a></li><li><a href="http://www.zimmers.net/anonftp/pub/cbm/documents/projects/drives/1551-tia.gif">Floppy 1551 reparieren – so geht’s</a></li><li><a href="http://www.softwolves.com/arkiv/cbm-hackers/15/15949.html">The strange design of the 1551 floppy drive</a></li><li><a href="https://www.forum64.de/index.php?thread/58413-tcbm-bus-analyse/">TCBM-Bus Analyse</a></li><li><a href="http://www.cbmhardware.de/show.php?r=10&id=15">1551USB</a></li><li><a href="https://hup.hu/node/121506">Retró rovat IV/B: Az 1551-II projekt folytatása</a></li></ul><div class="footnotes"><hr/><ol><li id="fn:1"><p>The VIC-20 was named after the VIC (“Video Interface Controller”), the video chip of the system.<a href="#fnref:1" rev="footnote">↩</a></p></li><li id="fn:2"><p>These computers are also often referenced as the “264 series”, since three machines with the names C232, C264 and C364 were originally planned.<a href="#fnref:2" rev="footnote">↩</a></p></li><li id="fn:3"><p>A hardware defect in the VIC-20 required a significant slowdown of the bus timing. More information in the <a href="https://www.pagetable.com/?p=1135">article about the serial bus</a>.<a href="#fnref:3" rev="footnote">↩</a></p></li><li id="fn:4"><p>The 1551 schematics call these pins PA0-PA7, after port A of the MOS 6523 I/O controller it is connected to.<a href="#fnref:4" rev="footnote">↩</a></p></li><li id="fn:5"><p>The C116 was supposed to compete with the Sinclair ZX81 and had a target price of $49. If ended up being sold only in Europe, for 100 DM or 99 GBP (which was about 75 USD).<a href="#fnref:5" rev="footnote">↩</a></p></li><li id="fn:6"><p>Support for two paddles was added very late in the design process. Early <a href="http://www.zimmers.net/anonftp/pub/cbm/firmware/computers/plus4/264/index.html">TED</a> <a href="http://www.zimmers.net/anonftp/pub/cbm/firmware/computers/plus4/364/index.html">prototype</a> <a href="http://www.zimmers.net/anonftp/pub/cbm/firmware/computers/plus4/PI9/index.html">ROMs</a> only support a single TCBM bus. When support for multiple busses was added, the byte send and receive code had to overflow into the patch area, which can be seen in the release ROM versions. The late addition of DEV can also be seen in the pinout of the cable: Without it, there would be two GND wires at each end.<a href="#fnref:6" rev="footnote">↩</a></p></li><li id="fn:7"><p>Here is a party trick: On a system with IEEE-488 or Standard Serial, the bus is blocked for all communication while one drive is busy with a long-running task, like formatting a disk. On a TED with one 1541 connected to Serial, and two 1551 drives connected to two separate TCBM busses, it is possible for all three drives to format disks at the same time.<a href="#fnref:7" rev="footnote">↩</a></p></li><li id="fn:8"><p>This is done by first testing for the presence of the I/O controller by testing whether the DIO port can retain a test value, and then by checking for STATUS0 being pulled to 0, which a device does when present and idle. (Label <code>tstkdy</code> in the source.)<a href="#fnref:8" rev="footnote">↩</a></p></li><li id="fn:9"><p>This is in contrast to Standard Serial, where the tight timing requirements of the original specification (for the VIC-20) could not be met by the C64, so the specification had to be changed.<a href="#fnref:9" rev="footnote">↩</a></p></li><li id="fn:10"><p>In addition to the I/O chip, the paddles contain a PLA for address decoding, since unlike the C64’s PLA, the TED’s PLA does not generate chip select signals for external devices.<a href="#fnref:10" rev="footnote">↩</a></p></li></ol></div>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1324</wfw:commentRss> <slash:comments>3</slash:comments> </item> <item> <title>Run CP/M on your C64 – using Emulation!</title> <link>https://www.pagetable.com/?p=1315</link> <comments>https://www.pagetable.com/?p=1315#comments</comments> <pubDate>Sun, 19 May 2019 09:24:29 +0000</pubDate> <dc:creator><![CDATA[Michael Steil]]></dc:creator> <category><![CDATA[Archeology]]></category> <category><![CDATA[C64]]></category> <category><![CDATA[Commodore]]></category> <category><![CDATA[Operating Systems]]></category> <guid isPermaLink="false">https://www.pagetable.com/?p=1315</guid> <description><![CDATA[In this episode of computer archeology, we deconstruct a very interesting case of borrowing code from multiple places – but first try this D64 disk image with any Commodore 64 emulator or a real C64: Commodore 64 CP/M Emulator The CP/M operating system was the first home computer OS that ran on machines from many ... <a title="Run CP/M on your C64 – using Emulation!" class="read-more" href="https://www.pagetable.com/?p=1315">Read more<span class="screen-reader-text">Run CP/M on your C64 – using Emulation!</span></a>]]></description> <content:encoded><![CDATA[<p>In this episode of computer archeology, we deconstruct a very interesting case of borrowing code from multiple places – but first try this D64 disk image with any Commodore 64 emulator or a real C64:</p><p><a href="docs/cpm_emu/cpm_emu.d64"><img src="docs/d64.png" height="64" width="64" alt="" /><br />Commodore 64 CP/M Emulator</a></p><p>The CP/M operating system was the first home computer OS that ran on machines from many different vendors, as long as they had an Intel 8080 compatible CPU – which the 8 bit machines from Commodore, Apple, Atari and BBC didn’t: They used the MOS 6502 CPU.</p><h3 id="The-Commodore-64-CPM-Cartridge">The Commodore 64 CPM Cartridge</h3><p>In 1983, Commodore released the the “<a href="https://www.pagetable.com/?p=1312">CP/M Cartridge</a>” for the Commodore 64, which contained a Z80 CPU and came with CP/M 2.2: The OS and its apps would run on the Z80, which would switch over to the computer’s 6502 to call code in the original ROM for screen, keyboard and disk accesses. It wasn’t very good, didn’t sell well, and was quickly discontinued.</p><h3 id="Roßmöller's-CP/M-Emulator">Roßmöller’s CP/M Emulator</h3><p>But it was also possible to run CP/M on a C64 without a hardware extension: All that is necessary is to emulate the Intel 8080 instruction set on the MOS 6502. And the German company Roßmöller did exactly that. In 1988, a little while after releasing their 4 MHz speeder cartridge “<a href="http://www.retroport.de/Hardware_T-U.html">Turbo Process</a>” for the C64, they started selling</p><blockquote><blockquote><p>CP/M Emulator – CP/M 2.2-kompatibler C64 ohne zusätzl. Hardware</p></blockquote></blockquote><p>for 10 DM.</p><p>The product is directly based on Commodore’s adaption of CP/M for the C64 CP/M cartridge. Commodore’s disk contains a small bootloader that loads BIOS and the Z80 bootstrap from the first sectors on disk (as specified by CP/M) – the bootloader of the CP/M Emulator directly contains slightly patched versions of BIOS and the Z80 bootstrap, as well as the 8080 emulator:</p><table border="1"><tbody><tr><th>CP/M Cartridge</th><th>CP/M Emulator</th></tr><tr><td><pre>0 "CP/M DISK " 65 2A 1 "CPM " PRG 0 BLOCKS FREE. </pre></td><td><pre>0 "CP/M EMULATOR " 32 0B 12 "CP/M " PRG 0 BLOCKS FREE. </pre></td></tr></tbody></table><p>The first sectors on disk still contain the original versions of BIOS and the Z80 bootstrap – and curiously, all references on disk to “Digital Research”, the CP/M license holder, have been replaced with “Roßmöller”, hinting towards a very questionable licensing status – not inconsistent with Roßmöller’s reputation at the time.</p><table border="1"><tbody><tr><th>CP/M Cartridge</th><th>CP/M Emulator</th></tr><tr><td><pre> COMMODORE 64 44k CP/M vers 2.2 Copyright (C) 1979, Digital Research Copyright (C) 1982, Commodore A> </pre></td><td><pre> R 03 07 COMMODORE 64 44k CP/M vers 2.2 =============================== Copyright (C) 1988, ROSSMOELLER A> </pre></td></tr></tbody></table><h3 id="Emulator-Performance">Emulator Performance</h3><p>The Roßmöller 8080 emulator contained in the boot program is less than 1.4 KB in size – and it’s super slow: Executing a single 8080 instruction takes between 300 and 800 cycles (485 on average). This makes the CP/M emulator about 100 times slower than a similarly spec’ed 8080-based machine. Even with the 8 MHz speeder, the emulator was still 12 times slower. It was in fact so slow that it failed to register normal keypresses on stock C64 systems unless you held the keys for a second.</p><h3 id="8080-Simulator-for-the-6502">8080 Simulator for the 6502</h3><p>There is a simple reason the emulator is this slow: It wasn’t written for speed. It wasn’t even written as an emulator. As it turns out, the Roßmöller 8080 emulator is a binary-patched version of the <a href="https://www.pagetable.com/?p=824"><em>8080 Simulator for the 6502, KIM-1 Version</em></a> “<em>8080 simulator-debug package</em>” by Dann McCreary, written in 1978.</p><p><em>8080 Simulator for the 6502</em> is an interactive 8080 simulator primarily aimed at teaching 8080 assembly – and optimized for size, since it had to to fit into the 2 KB of RAM of the KIM-1.</p><p>In the following implementation of the memory access instructions STAX/LDAX, you can see that the Roßmöller version just relocated everything by $CA pages:</p><table border="1"><tbody><tr><th>8080 Simulator for the 6502</th><th>Roßmöller CP/M Emulator</th></tr><tr><td><pre>0249 DIRECT PHA ; TEMP SAVE 024A JSR PC/PNT ; PC TO POINTER 024D JSR DBLINC 0250 LDXIM (SCR) 0252 JSR MEM/RP 0255 LDXIM (PNT) 0257 JSR SRC/RP 025A PLA ; RECOVER TEMP 025B LSRA ; LOAD? 025C BCS STORE ; NO, STORE 025E ASLA ; MAKE INDEX 025F TAX 0260 BEQ LDAD ; LOAD A DIRECT? 0262 JMP MEM/RP ; NO, LOAD HL DIRECT </pre></td><td><pre>.,CC49 48 PHA .,CC4A 20 5D CD JSR $CD5D .,CC4D 20 80 CD JSR $CD80 .,CC50 A2 19 LDX #$19 .,CC52 20 A0 CD JSR $CDA0 .,CC55 A2 17 LDX #$17 .,CC57 20 70 CD JSR $CD70 .,CC5A 68 PLA .,CC5B 4A LSR A .,CC5C B0 0E BCS $CC6C .,CC5E 0A ASL A .,CC5F AA TAX .,CC60 F0 03 BEQ $CC65 .,CC62 4C A0 CD JMP $CDA0 </pre></td></tr></tbody></table><h3 id="Roßmöller-Changes">Roßmöller Changes</h3><p>But there are also sections in the emulator that had to be adapted for use in the CP/M context:</p><ul><li>The memory model of the C64 CP/M cartridge made the 8080 CPU see the machine’s RAM moved up by $1000 – so the 8080 RST area and the 6502 zero page would not be at the same spot. The emulator also uses this layout, so every memory access has to go through an expensive 16 bit addidion. (Avoiding this addition would have been the better strategy – and ironically, Dann’s original design document explains why he decided <em>not</em> to shift memory!)</li><li>The interpreter was extended to special case “LD ($CE00),A” (which switches back to the 6502) and to support the “LDIR” instruction (a Z80 extension used by CP/M), but it seems the people patching the emulator didn’t understand the code well enough to work “LDIR” into the instruction decoder or put the address check into the “LD (), A” handler – instead, the interpreter loop checks for these instruction before the normal decode. (Ironically, the emulator already contains a special opcode to switch to 6502 mode, so it would have been easier to patch the code that switches modes.)</li><li><p>The following code increments the 8080 program counter in 45 cycles, while it could also have been done is as little as 6 cycles:</p><pre><code> ldx #pc - registers ldy #const_one - registers clc : lda registers,x adc registers,y sta registers,x iny inx tya and #1 bne :- ; do it twice</code></pre></li></ul><p>Roßmöller did not make these modifications in source, but binary patched the original KIM-1 version: Changing the exact page alignment of the emulator would have required an extensive rework of the extremely optimized instruction decoder.</p><p>But it doesn’t mean the patches are done in an elegant way: They are very wasteful, weird… and just horrible. The following example stores a 16 bit register in memory at the address pointed to by PNT:</p><table border="1"><tbody><tr><th>8080 Simulator for the 6502</th><th>Roßmöller CP/M Emulator</th></tr><tr><td valign="top"><pre>017D RP/MEM LDYIM #$01 ; CLEAR INDEX 017F RPLP LDAZX REGS+1 ; GET NEXT RP DATA 0181 STAIY PNT ; STORE IN MEMORY 0183 DEX 0184 DEY 0185 BEQ RPLP 0187 RTS </pre></td><td><pre>.,CB7D A0 01 LDY #$01 <b>.,CB7F 20 44 CE JSR $CE44 .,CB82 EA NOP</b> .,CB83 CA DEX .,CB84 88 DEY .,CB85 F0 F8 BEQ $CB7F .,CB87 60 RTS <b>.,CE44 20 C0 CE JSR $CEC0 .,CE47 B5 36 LDA $36,X .,CE49 91 C1 STA ($C1),Y .,CE4B 60 RTS .,CEC0 08 PHP .,CEC1 20 20 CE JSR $CE20 .,CEC4 28 PLP .,CEC5 60 RTS .,CE20 A5 4C LDA $4C .,CE22 85 C1 STA $C1 .,CE24 A5 4D LDA $4D .,CE26 18 CLC .,CE27 69 10 ADC #$10 .,CE29 85 C2 STA $C2 .,CE2B 60 RTS</b> </pre></td></tr></tbody></table><p>Since for CP/M, memory is shifted by $1000, the Roßmöller version has to copy PNT into a temporary zero page location, add $1000 and use this one instead of PNT. The patch at $CE44 does the extra work. It calls the common routine $CEC0, which is supposed to make the copy + $1000 – and this function itself is a wrapper around a library function that saves the status bits for no reason. A more optimized version would have replaced all callers to $CB7D by code that does all this in one go. There was no reason to reuse logic; there are kilobytes of unused space!</p><h3 id="Was-the-Emulator-Licensed?">Was the Emulator Licensed?</h3><p>Dann McCreary confirmed that Roßmöller never licensed the emulator from him:</p><blockquote><blockquote><p>I don’t have all the old records, but it seems likely that they bought a KIM-1 version directly from me at some point, or got it from one of my customers.</p></blockquote></blockquote><p>After I commented that he was unlikely to sell any more copies of the KIM-1 version around the time the Roßmöller emulator was written, Dann wrote:</p><blockquote><blockquote><p>I made random sales all around the globe… but you’re probably right, 1987 sounds pretty late… Perhaps one of the Rossmuller principals had bought from me years earlier?</p></blockquote></blockquote><p>Given that all Digital Research copyright messages were also completely removed from the product, it seems unlikely that the CP/M part was licensed.</p><h3 id="Conclusion">Conclusion</h3><p>Dann McCreary:</p><blockquote><blockquote><p>Back in the day, I was asked repeatedly whether the simulator was suitable for running CP/M, and my response invariably was that (in my opinion) it would run unacceptably slow. That is primarily why I never attempted the task myself. Of course, my code was completely optimized for space and not for speed… Those were the days of a 1.2K RAM space (KIM-1), or if you were lucky, 16K (Apple ][).</p></blockquote></blockquote>]]></content:encoded> <wfw:commentRss>https://www.pagetable.com/?feed=rss2&p=1315</wfw:commentRss> <slash:comments>1</slash:comments> </item> </channel></rss> If you would like to create a banner that links to this page (i.e. this validation result), do the following:
Download the "valid RSS" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src attribute if necessary):
If you would like to create a text link instead, here is the URL you can use:
http://www.feedvalidator.org/check.cgi?url=http%3A//www.pagetable.com/%3Ffeed%3Drss2
