{"id":1140,"date":"2019-04-29T22:55:59","date_gmt":"2019-04-30T05:55:59","guid":{"rendered":"https:\/\/www.pagetable.com\/?p=1140"},"modified":"2019-04-29T22:55:59","modified_gmt":"2019-04-30T05:55:59","slug":"reconstructing-the-geos-2-0-de-master-images-from-a-pile-of-broken-disks","status":"publish","type":"post","link":"https:\/\/www.pagetable.com\/?p=1140","title":{"rendered":"Reconstructing the GEOS 2.0 (de) Master Images from a Pile of Broken Disks"},"content":{"rendered":"<p>I have this pile of broken GEOS disks that were sent in for replacements. In two previous articles (<a href=\"https:\/\/www.pagetable.com\/?p=1118\">1<\/a>, <a href=\"https:\/\/www.pagetable.com\/?p=1128\">2<\/a>), I explored the reasons why the disks broke. Now let&rsquo;s be constructive: Can we reconstruct the original bits by combining the correct parts? This article shows how it is possible with the help of a small tool that combines the good parts of several broken disk images.<\/p>\n<h2 id=\"Overview\">Overview<\/h2>\n<p>The original disk set consisted of four double-sided disks. Of my 50 disks, this is the distribution:<\/p>\n<ul>\n<li>21x <strong>Disk 1\/4: System<\/strong><\/li>\n<li>18x <strong>Disk 2\/4: Backup<\/strong><\/li>\n<li>7x <strong>Disk 3\/4: GeoSpell<\/strong><\/li>\n<li>4x <strong>Disk 4\/4: Drivers<\/strong><\/li>\n<\/ul>\n<p>I have created a command line tool to help analyze images of multiple copies of commercial disks:<\/p>\n<p><a href=\"https:\/\/github.com\/mist64\/combine_d64\">https:\/\/github.com\/mist64\/combine_d64<\/a><\/p>\n<p>Let&rsquo;s use it to reconstruct the original bits! The remaining sections are sorted according the complexity of the reconstruction of the despective disk side:<\/p>\n<h2 id=\"Disk-1B:-Applications\">Disk 1B: Applications<\/h2>\n<p>Running the tool on all images of the B side of the first disk (&ldquo;Applications&rdquo;) will find two identical copies:<\/p>\n<pre><code>$ combine_d64.py *.d64\n\nThe following images are identical:\n05b.d64 14b.d64\n<\/code><\/pre>\n<p>And indeed, the reverse sides conain the original unchanged data.<\/p>\n<p>GEOS disks 1 and 2 are specially mastered for <a href=\"https:\/\/www.pagetable.com\/?p=1118\">copy protection<\/a> purposes: When looking at the raw bits on disk, the gaps between sector headers and the sector data contain a signature that cannot be reproduced by an unmodified 1541 drive, and that will be destroyed whenever writing a sector.<\/p>\n<p>The tool <a href=\"https:\/\/github.com\/markusC64\/g64conv\">g64conv<\/a> converts <code>.G64<\/code> files into a textual representation that is easy to analyze. This is what a sector with its header and data section looks like in g64conv&rsquo;s text format:<\/p>\n<pre><code>   sync 18\n   ; header\n   gcr 08\n   begin-checksum\n      checksum 0f\n      ; sector\n      gcr 00\n      ; track\n      gcr 01\n      ; id2\n      gcr 44\n      ; id1\n      gcr 4a\n   end-checksum\n   gcr 0f\n   gcr 0f\n   ; Trk 1 Sec 0\n   bytes 55 55 55 67 55 55 55 67\n   bits 111111\n\n   sync 18\n   ; data\n   gcr 07\n   begin-checksum\n      gcr 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 02 0e 00 ff 02 04 00 ff 11 0b 00 ff 00 ff 00 ff 11 12 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff\n      checksum 13\n   end-checksum\n   gcr 00\n   gcr 00\n   bytes 55 55 55 67 55 55 55 67\n   bits 111111\n<\/code><\/pre>\n<p>The <code>55 55 55 67 55 55 55 67<\/code> bytes after the header and after the data are the copy protection signature. The following small shell script will count the number of sectors that don&rsquo;t have the signature and have therefore been written to:<\/p>\n<pre><code>perl g64conv 15b.g64 15b.txt\ncat 15b.txt |\n  grep Trk -A 1 | tr '\\n' 'X' |\n  sed -e \"s\/X   bytes\/;   bytes\/g\" |\n  tr 'X' '\\n' |\n  grep Trk |\n  grep -v \"55 67$\" |\n  cut -d \";\" -f 2 |\n  wc -l\n<\/code><\/pre>\n<p>Disks 05b and 14b carry the original bits, so we&rsquo;re done with these. Note that even though we ran the tool on the <code>.D64<\/code> image, we have to take the low-level <code>.G64<\/code> image with all the original bits for the copy protection to work.<\/p>\n<h2 id=\"Disk-3B:-GeoSpell-(English)\">Disk 3B: GeoSpell (English)<\/h2>\n<p>Running the tool on all copies of the B side of the third disk will tell us that it found identical copies &#8211; but two sets of them!<\/p>\n<pre><code>$ combine_d64.py *.d64\n\nThe following sets of images are identical:\n0 : 42b.d64 45b.d64\n1 : 44b.d64 46b.d64\n<\/code><\/pre>\n<p>The tool cannot decide which of the two sets \u2013 if any \u2013\u00a0carries the original data. Let&rsquo;s look at a diff:<\/p>\n<pre>\n323c323\n< 00014f0 c6 20 d0 f1 a4 21 c8 <font color=\"red\"><b>a9 00 91 00 60 ac 89 84 b9<\/b><\/font>\n---\n> 00014f0 c6 20 d0 f1 a4 21 c8 <font color=\"green\"><b>01 01 01 01 01 01 01 01 01<\/b><\/font>\n659c659\n< 00029f0 d0 07 a2 80 2c 03 82 <font color=\"red\"><b>30 1b 20 12 39 a5 15 f0 06<\/b><\/font>\n---\n> 00029f0 d0 07 a2 80 2c 03 82 <font color=\"green\"><b>01 01 01 01 01 01 01 01 01<\/b><\/font>\n995c995\n< 0003ef0 18 65 08 85 08 90 02 <font color=\"red\"><b>e6 09 a5 09 85 19 a5 08 85<\/b><\/font>\n---\n> 0003ef0 18 65 08 85 08 90 02 <font color=\"green\"><b>01 01 01 01 01 01 01 01 01<\/b><\/font>\n[...]\n<\/pre>\n<p>The second set has the last bytes of the last sector of each track replaced by a series of 0x01 characters. Also, all these sectors have checksum errors.<\/p>\n<p>Looking at the g64conv textual representation shows what&rsquo;s going on:<\/p>\n<pre><code>[...]\n   sync 16\n   ; data\n   gcr 07\n   begin-checksum\n      gcr 01 07 04 [...] a4 21 c8\n   bits 11111\n;   block aborted2\n   bits 111\n\nend-track\n<\/code><\/pre>\n<p>The last sector of each track is aborted. And we have two physical disks with the exact same issue \u2013 this was a problem in commercial disk duplication! The motor of the copying machine was probably spinning too slowly, so when a full rotation was complete, it stopped writing before it was done with all the bits of the track. This was probably the reason the disk was sent in for a replacement!<\/p>\n<p>So we know that the B sides of disks 44 and 46 are broken. Except for the truncated sectors, the data was the same as on the two identical disks 42b and 45b, which gives us high confidence that these contain the correct data.<\/p>\n<h2 id=\"Disk-4B:-More-Drivers\">Disk 4B: More Drivers<\/h2>\n<p>For the copies of the B side of the fourth disk we don&rsquo;t have two identical images:<\/p>\n<pre><code>$ combine_d64.py *.d64\n\nAll blocks had at least 3 copies.\nEvery block of the following images is also contained in at least one other file:\n48b.d64\n<\/code><\/pre>\n<p>But there is one image, 48b, where for every block, there are at least two other images that have the same data at this position. This gives us high confidence that the data in 48b is correct.<\/p>\n<h2 id=\"Disk-4A:-Drivers\">Disk 4A: Drivers<\/h2>\n<p>It is a little more tricky with the A side of the fourth disk:<\/p>\n<pre><code>$ combine_d64.py *.d64\n\nThe following blocks only had a limited number of copies:\n2 copies of block 125 (Trk 6 Sec 20) in 48a.d64 51a.d64\n2 copies of block 357 (Trk 18 Sec 0) in 48a.d64 50a.d64\n2 copies of block 358 (Trk 18 Sec 1) in 48a.d64 50a.d64\nEvery block of the following images is also contained in at least one other file:\n48a.d64\n<\/code><\/pre>\n<p>48a is a candidate, but there are three blocks for which only two other copies have been found.<\/p>\n<p>As it turns out, disk 50a has the same duplication error as 44b and 46b, the last sector of every track is truncated. If we fill the broken bytes, disk 50a is actually identical with 48a, so we can be very confident that 48a is correct.<\/p>\n<h2 id=\"Disk-3A:-GeoSpell-(German)\">Disk 3A: GeoSpell (German)<\/h2>\n<p>But there are also some cases where none of the images seems to be completely correct:<\/p>\n<pre><code>$ combine_d64.py *.d64\n\nAll blocks had at least 3 copies.\nThe result was combined from the following images:\n41a.d64 (667 blocks)\n42a.d64 (16 blocks)\n<\/code><\/pre>\n<p>In this case, the likely result had to be combined from two images.<\/p>\n<p>If we look at the images closely, we can see that 41a, 43a, 44a and 46a all have the duplication error. Nevertheless, it could source most of the correct sectors from 41a. That&rsquo;s because it&rsquo;s the first argument we gave it. If we changed the order of the arguments so that 41a is last, we get this:<\/p>\n<pre><code>All blocks had at least 3 copies.\nThe result was combined from the following images:\n42a.d64 (682 blocks)\n43a.d64 (1 blocks)\n<\/code><\/pre>\n<p>All blocks except one come from 42a. That&rsquo;s the single block of 42s with a read error. <strong>All<\/strong> other images contain the the correct copy of it, so we can be very confident that by fixing the sector, we get a correct image.<\/p>\n<h2 id=\"Disk-2B:-Write-Utilities\">Disk 2B: Write Utilities<\/h2>\n<p>For the next disk, we tool doesn&rsquo;t give us as much confidence:<\/p>\n<pre><code>$ combine_d64.py *.d64\n\nThe following blocks only had a limited number of copies:\n2 copies of block 297 (Trk 15 Sec 3) in 28b.d64 36b.d64\nThe result was combined from the following images:\n22b.d64 (675 blocks)\n23b.d64 (6 blocks)\n24b.d64 (1 blocks)\n28b.d64 (1 blocks)\n<\/code><\/pre>\n<p>Again, the resulting had to be combined from several images. This time, it had to use 4 images in order to combine them to the resulting image, which looks suspicious. But that is just be a side effect of the ordering of the files as we passed it to the tool. By putting 36 and 37 first, we get this printout:<\/p>\n<pre><code>The following blocks only had a limited number of copies:\n2 copies of block 297 (Trk 15 Sec 3) in 36b.d64 28b.d64\nThe result was combined from the following images:\n36b.d64 (679 blocks)\n37b.d64 (4 blocks)\n<\/code><\/pre>\n<p>Note that the resulting image is of course the same. Experimenting with the ordering is useful though, because we can now have a look at the diff between 36b and the result to see whether things look sane.<\/p>\n<p>But this example teaches us that the majority is not always right. All sectors of 36b carry the &ldquo;55 67&rdquo; signature and are unmodified. The app GeoMerge on this disk has never been started \u2013\u00a0on the other images, it has, which didn&rsquo;t only stamp in the system&rsquo;s serial number (track 15 sector 3), but also change 3 other sectors deterministically.<\/p>\n<p>So the answer is: 36b.<\/p>\n<h2 id=\"Disk-1A:-System\">Disk 1A: System<\/h2>\n<p>We have lots of copies of the boot disk, but two blocks that only have two identical copies:<\/p>\n<pre><code>$ combine_d64.py *.d64\n\nThe following blocks only had a limited number of copies:\n2 copies of block 358 (Trk 18 Sec 1) in 05a.d64 14a.d64\n2 copies of block 400 (Trk 20 Sec 5) in 14a.d64 17a.d64\nThe result was combined from the following images:\n01a.d64 (638 blocks)\n03a.d64 (38 blocks)\n04a.d64 (1 blocks)\n05a.d64 (4 blocks)\n12a.d64 (1 blocks)\n14a.d64 (1 blocks)\n<\/code><\/pre>\n<p>Track 20 sector 5 is where the GEOS serial number is stored on the boot disk. Similarly to apps, the serial number is 0 on a new system disk, and a random one will be picked on first boot \u2013\u00a0and also copied to the backup boot disk. Again, the serial numbers are different on all disks.<\/p>\n<pre>\n$ for i in *.d64; do hexdump $i | grep 00190c0; done\n00190c0 b8 50 bf aa 60 <b>1d 06 ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>2f c5 ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>23 8d ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>cd ea ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>27 69 ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>3e 35 ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>86 a1 ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>05 3f ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>d7 31 ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>6d dd 00<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>22 f8 ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <font color=\"red\"><b>00 00 00<\/b><\/font> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>fa 27 ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>57 ff ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <font color=\"red\"><b>00 00 00<\/b><\/font> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>4e c9 ff<\/b> a0 93 d0 0a a0 90 d0 06\n<\/pre>\n<p>Disk 14a is one of the two with a serial number of 0. Since this is a GEOS boot disk, we can look for the &ldquo;55 67&rdquo; signature to check which sectors have ever been written. And we&rsquo;re lucky: Disk 14a has all original sectors intact, so we&rsquo;re done!<\/p>\n<h2 id=\"Disk-2A:-Backup\">Disk 2A: Backup<\/h2>\n<p>The serial number is also an issue on the set of backup disks:<\/p>\n<pre><code>$ combine_d64.py *.d64\n\nFor the following blocks, no duplicates exist:\n400 (Trk 20 Sec 5)\n<\/code><\/pre>\n<p>Every image has a different serial number \u2013\u00a0but this time, none has a 0.<\/p>\n<pre>\n$ for i in *.d64; do hexdump $i | grep 00190c0; done\n00190c0 b8 50 bf aa 60 <b>82 d2 ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>1a 35 ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>86 a1 ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>9a 50 ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>07 bd ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>dd 21 ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>95 0c ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>2f c5 ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>aa af ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>1d 06 ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>9a 27 ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>fa 27 ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>dd f0 ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>bd 2b ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>cd ea ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>23 8d ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>19 c0 ff<\/b> a0 93 d0 0a a0 90 d0 06\n00190c0 b8 50 bf aa 60 <b>e7 04 ff<\/b> a0 93 d0 0a a0 90 d0 06\n<\/pre>\n<p>Again, we can use the &ldquo;55 67&rdquo; signature to check which image has the fewest changed sectors: Disks 22a, 35a and 36a all only have a single changed sector: the one with the serial number. So we can manually reconstruct the correct image by changing the serial number and the flag following it to &ldquo;00 00 ff&rdquo;. This is best done in the g64conv <code>.TXT<\/code> file, where we can also patch the signature back in.<\/p>\n<h2 id=\"Conclusion\">Conclusion<\/h2>\n<p>It was possible to recreate the original masters. The GEOS serial number system made things more complicated than it should have been, but the copy protection signature then made things a lot easier again!<\/p>\n<p>Here are the GEOS 2.0 German master disk images:<\/p>\n<p><a href=\"docs\/geos20de_master\/geos20de_master.zip\">geos20de_master.zip<\/a> (902 KB)<\/p>\n<p><strong>GEOS 64 2.0<\/strong><br \/>\nSeite A: <strong>Systemdiskette<\/strong> \/ Seite B: <strong>Applikationen<\/strong><br \/>\nSeriennummer: <em>nnnnnnnnn<\/em><br \/>\n<strong>Copyright by Berkeley Softworks 1988<\/strong><br \/>\nBestell-Nr. 51677 &#8211; Diskette 1 von 4 \/ <em>nnnnnnnnxx<\/em><\/p>\n<p><strong>GEOS 64 2.0<\/strong><br \/>\nSeite A:<strong>Sicherungssystem<\/strong> \/ Seite B:<strong>Write Utilities<\/strong><br \/>\n<strong>Copyright by Berkeley Softworks 1988<\/strong><br \/>\nFloppy 1541\/1570\/1571 &#8211; Diskette 2 von 4<br \/>\nBestell-Nr. 51677 \/ <em>nnnnnnnnxx<\/em><\/p>\n<p><strong>GEOS 64 2.0<\/strong><br \/>\nSeite A:<strong>GeoSpell (deutsch)<\/strong> \/ Seite B:<strong>GeoSpell (engl)<\/strong><br \/>\n<strong>Copyright by Berkeley Softworks 1988<\/strong><br \/>\nFloppy 1541\/1570\/1571 &#8211; Diskette 3 von 4<br \/>\nBestell-Nr. 51677 \/ <em>nnnnnnnnxx<\/em><\/p>\n<p><strong>GEOS 64 2.0<\/strong><br \/>\nSeite A: <strong>Treiber<\/strong> \/ Seite B: <strong>Weitere Treiber<\/strong><br \/>\n<strong>Copyright by Berkeley Softworks 1988<\/strong><br \/>\nFloppy 1541\/1570\/1571 &#8211; Diskette 4 von 4<br \/>\nBestell-Nr. 51677 \/ <em>nnnnnnnnxx<\/em><\/p>\n<p>When first using them, you will have to go through the regular installation process, pictured below:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" src=\"docs\/geos20de_master\/geos_install_1.png\" height=\"272\" width=\"384\" alt=\"\" \/><img loading=\"lazy\" decoding=\"async\" src=\"docs\/geos20de_master\/geos_install_2.png\" height=\"272\" width=\"384\" alt=\"\" \/><img loading=\"lazy\" decoding=\"async\" src=\"docs\/geos20de_master\/geos_install_3.png\" height=\"272\" width=\"384\" alt=\"\" \/><img loading=\"lazy\" decoding=\"async\" src=\"docs\/geos20de_master\/geos_install_4.png\" height=\"272\" width=\"384\" alt=\"\" \/><img loading=\"lazy\" decoding=\"async\" src=\"docs\/geos20de_master\/geos_install_5.png\" height=\"272\" width=\"384\" alt=\"\" \/><img loading=\"lazy\" decoding=\"async\" src=\"docs\/geos20de_master\/geos_install_6.png\" height=\"272\" width=\"384\" alt=\"\" \/><img loading=\"lazy\" decoding=\"async\" src=\"docs\/geos20de_master\/geos_install_7.png\" height=\"272\" width=\"384\" alt=\"\" \/><img loading=\"lazy\" decoding=\"async\" src=\"docs\/geos20de_master\/geos_install_8.png\" height=\"272\" width=\"384\" alt=\"\" \/><img loading=\"lazy\" decoding=\"async\" src=\"docs\/geos20de_master\/geos_install_9.png\" height=\"272\" width=\"384\" alt=\"\" \/><img loading=\"lazy\" decoding=\"async\" src=\"docs\/geos20de_master\/geos_install_10.png\" height=\"272\" width=\"384\" alt=\"\" \/><\/p>\n<p>And here is a video of the install process:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" src=\"docs\/geos20de_master\/geos_install.gif\" height=\"272\" width=\"384\" alt=\"\" \/><\/p>\n","protected":false},"excerpt":{"rendered":"<p>I have this pile of broken GEOS disks that were sent in for replacements. In two previous articles (1, 2), I explored the reasons why the disks broke. Now let&rsquo;s be constructive: Can we reconstruct the original bits by combining the correct parts? This article shows how it is possible with the help of a &#8230; <a title=\"Reconstructing the GEOS 2.0 (de) Master Images from a Pile of Broken Disks\" class=\"read-more\" href=\"https:\/\/www.pagetable.com\/?p=1140\" aria-label=\"Read more about Reconstructing the GEOS 2.0 (de) Master Images from a Pile of Broken Disks\">Read more<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,41,8,13,15],"tags":[],"class_list":["post-1140","post","type-post","status-publish","format-standard","hentry","category-archeology","category-c64","category-commodore","category-floppy-disks","category-geos"],"_links":{"self":[{"href":"https:\/\/www.pagetable.com\/index.php?rest_route=\/wp\/v2\/posts\/1140","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.pagetable.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.pagetable.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.pagetable.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.pagetable.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1140"}],"version-history":[{"count":0,"href":"https:\/\/www.pagetable.com\/index.php?rest_route=\/wp\/v2\/posts\/1140\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.pagetable.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1140"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.pagetable.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1140"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.pagetable.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1140"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}