{"id":321,"date":"2017-04-30T21:48:38","date_gmt":"2017-05-01T02:48:38","guid":{"rendered":"https:\/\/knm.org.uk\/blog\/?p=321"},"modified":"2019-05-29T07:59:36","modified_gmt":"2019-05-29T12:59:36","slug":"retrochallenge-roundup-and-a-quick-jvc-update","status":"publish","type":"post","link":"https:\/\/knm.org.uk\/blog\/2017\/04\/retrochallenge-roundup-and-a-quick-jvc-update\/","title":{"rendered":"Retrochallenge Roundup (and a quick JVC update)"},"content":{"rendered":"<p>Well, it's the final night of RetroChallenge, so it's time for a closing post. As I'd expected, I didn't get anywhere close completing my goals, with lack of time being the age-old excuse. However, it was still a very productive project and I plan to keep pressing on and making semi-regular posts. Hopefully I can keep the momentum going even through RC is over for another 6 months. Although I didn't get a wiki up and running to store the information I was gathering, it's all up on this blog - so that's a start as far as making it available is concerned.<\/p>\n<p>Other key milestones:<\/p>\n<ul>\n<li>I hacked together a working PSU for the V86P - learning a lot about switch-mode PSUs in the process<\/li>\n<li>I reverse engineered the output stage of the original PSU, using photos and some measurements being taken remotely, and captured the result as a kicad schematic<\/li>\n<li>I'm most of the way through a PCB layout for the charging section of the PSU, which will provide all the necessary voltages to the V86P to run and charge the NiCd pack given only a sufficiently beefy 8.5V PSU. The missing piece is finding a case I like, then I need to tweak the board dimensions to fit<\/li>\n<li>II got the V86P running with both its internal HDD and FDD<\/li>\n<li>I found datasheets for most of the key ICs in the system<\/li>\n<li>I'm about half-way through mapping out the pinout of the hard disk controller to motherboard interface pinout<\/li>\n<li>I confirmed the pinout of the 26-pin JVC interface<\/li>\n<li>I identified the SHIP_READY and SERVO_GATE lines as signal that the heads were parked and a sector index respectively<\/li>\n<li>I identified that DOS sees a 4 head disk with 512 byte sectors, but the disk itself only has one head select line - possibly there's some logic for splitting 1k sectors into two logical heads - developing some basic C routines to call BIOS int13h<\/li>\n<li>I've confirmed I can read the ECC blocks from the data block via DOS int 13h calls, which should make reverse engineering the polynomial used by the controller relatively straightforward<\/li>\n<li>And lastly, which I'm going to cover below - I think I've finally confirmed the disk is storing 2,7 RLL encoded data<\/li>\n<\/ul>\n<p><!--more--><\/p>\n<p>I was able to borrow a DSO from a friend (thanks Daniel!) This allowed me to take a look at the signal on the \/READ and \/WRITE lines of the controller, with the hope of confirming what my little USB analyzer was showing. The result is as follows:<\/p>\n<div style=\"width: 410px\" class=\"wp-caption alignnone\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone\" src=\"\/blog\/wp-content\/uploads\/2017\/04\/_d_improd_\/read_f_improf_400x300.png\" data-mce-height=\"300\" data-mce-width=\"400\" height=\"300\" width=\"400\"><p class=\"wp-caption-text\">Read<\/p><\/div>\n<div style=\"width: 410px\" class=\"wp-caption alignnone\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone\" src=\"\/blog\/wp-content\/uploads\/2017\/04\/_d_improd_\/write_f_improf_400x300.png\" data-mce-height=\"300\" data-mce-width=\"400\" height=\"300\" width=\"400\"><p class=\"wp-caption-text\">Write<\/p><\/div>\n<p>Looking at the traces, this looks like the read and write pulses are about the same width, with read being slightly shorter, and on closer examination, not quite so square. I suspected the issue might be the cable length between the logic analyzer and the break-out board. I shortened the cable as much as possible and ran another read test. This yielded the following result:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" style=\"max-width: none;\" src=\"\/blog\/wp-content\/uploads\/2017\/04\/_d_improd_\/sector-preamble_f_improf_600x150.png\" data-mce-height=\"150\" data-mce-width=\"600\" height=\"150\" width=\"600\"><\/p>\n<p>This looks a lot better, and has the regular pulse chain I was originally expecting to see.<\/p>\n<p>The datasheets for the OMTI 5055 and 5027 recommend using a value 0x33 for the inter-sector gap (and pre-index and post-index gaps) on RLL encoded drives. When you encode 0x33 using the 2,7 RLL code OMTI (and most other disk vendors of the time) used, you get 00010000 - which gives a repeating pattern of one pulse, then seven periods of nothing, then another pulse. That's exactly what that trace appears to be.<\/p>\n<p>Following the inter-sector gap, we get an ID pre-amble of 0xFF, repeated several times (the exact count is up to the controller programming). 0xFF encodes as 10001000, so you get a pulse then three periods of nothing, followed by another pulse. Following that is an ID sync byte of 0x62 (which is 0010000001000100), then a marker byte of 0xfe (1000100010000100), then finally the sector data.<\/p>\n<p>So as my parting image, here's what I saw when I looked at a trace, starting at the beginning of a sector - just compare it to what I described above:<\/p>\n<p><a href=\"\/blog\/wp-content\/uploads\/2017\/04\/sector-preamble2.png\" target=\"_blank\" rel=\"noopener noreferrer\"><img loading=\"lazy\" decoding=\"async\" style=\"max-width: none;\" src=\"\/blog\/wp-content\/uploads\/2017\/04\/_d_improd_\/sector-preamble2_f_improf_493x67.png\" data-mce-height=\"67\" data-mce-width=\"493\" height=\"67\" width=\"493\"><\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Well, it&#8217;s the final night of RetroChallenge, so it&#8217;s time for a closing post. As I&#8217;d expected, I didn&#8217;t get anywhere close completing my goals, with lack of time being the age-old excuse. However, it was still a very productive project and I plan to keep pressing on and making semi-regular posts. Hopefully I can [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[4,1],"tags":[8],"class_list":["post-321","post","type-post","status-publish","format-standard","hentry","category-retrocomputing","category-uncategorized","tag-v86p"],"_links":{"self":[{"href":"https:\/\/knm.org.uk\/blog\/wp-json\/wp\/v2\/posts\/321","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/knm.org.uk\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/knm.org.uk\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/knm.org.uk\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/knm.org.uk\/blog\/wp-json\/wp\/v2\/comments?post=321"}],"version-history":[{"count":2,"href":"https:\/\/knm.org.uk\/blog\/wp-json\/wp\/v2\/posts\/321\/revisions"}],"predecessor-version":[{"id":327,"href":"https:\/\/knm.org.uk\/blog\/wp-json\/wp\/v2\/posts\/321\/revisions\/327"}],"wp:attachment":[{"href":"https:\/\/knm.org.uk\/blog\/wp-json\/wp\/v2\/media?parent=321"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/knm.org.uk\/blog\/wp-json\/wp\/v2\/categories?post=321"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/knm.org.uk\/blog\/wp-json\/wp\/v2\/tags?post=321"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}