Jump to content

kgallen

Members
 View Profile  See their activity

  • Posts

    1,130

  • Joined

  • Last visited

  • Days Won

    4

 Content Type 

Everything posted by kgallen

  1. kgallen
    On the 640 it's next to the rear panel Control-A1(II) connector. This picture is flipped. For you with the lid off, looking from the rear and down it will be to the right just above the rear panel just down from the power supply section (big black capacitors)/just across from the S-shaped heatsink.
  2. kgallen
    Zero-ohm link. Commonly used to option in and out circuit elements within a product range. See them all over the place. Could be a wire link but more usually these (and those) days a chip "resistor", 0R.
  3. kgallen
    Sorry for the cut-and-shut picture: I wonder if you chaps have a 4-pin or 6-pin connector for CN820 on your 640 main board. Then if R826 and R822 are fitted on your KB board (probably). If so, then I think you could rightly label your KB connector as "Keyboard (PC-Link)" with no changes...
  4. kgallen
    I2C spec - used to be quite hard to come by, but easily found on't web these days here. There are three traditional modes, standard-mode @100kbps, fast-mode @400kpbs and Hs-mode @3.4Mbps (not really ever termed baud on I2C).
  5. kgallen
    Sorry, my bad. Here I go again... :-(
  6. kgallen
    Well I guess we could argue details, but I2C is "Inter-IC" so not really designed/intended for off-board driving over a traditional cable - you'd use a spec like RS232 and it's brethren for that.
  7. kgallen
    It probably would work but not be robust. The uC I2C ports are not designed to drive a cable. Having a read of the datasheet for that I2C buffer gives the background of why that chip is required in such I2C topologies wrt capacitive load and current drive etc. If the USB interface inside the MN10 thing were mounted inside the 640 and wired directly in, I suspect the buffer chip would not be necessary.
  8. kgallen
    Which is a crazy case in point. Several of us were most impressed by this piece of work - and one of the first truly inspirational posts I found when I joined this forum. And we would still like more details! Myself, I got as far as breadboarding the photodiode and transimpedance amp circuit, but got overwhelmed by the mechanical challenge of getting it inside an MD case - something you had achieved with grace. I have the Sanwa LP-1. And whilst this is a small device, using it on my 440 is still a clumsy affair, getting the head near to the OP. I would still be wary using this with my other "more valuable" machines. So your own solution is still a desirable project.... We can but ask nicely and hope you overcome your shyness :-)
  9. kgallen
    I truly understand not wanting to open a prized machine - I still hold that for my 520 which is in truth nothing special in this world, but held dear to me for no tangible reason other than sentiment. However @NGY it sounds that, much to your emoted chagrin earlier, you are in the ideal place to acquire such an experimental beast since your eBay world seems to be much more tempered than our own!
  10. kgallen
    There is collective nous here that I like to share my ramblings, since one of you fine chaps will either spot the error of my ways, bring some extra wisdom, or promote a new idea by the mechanism of "cardboard engineer" - that of just writing down one's own thoughts bringing clarity or a new insight into a problem. And long may it continue, fellow MD-ers!
  11. kgallen
    Hardware wise I would expect the 640 MB populated with the I2C buffer associated SMD resistors and DIN socket would be the hardware solution, because I2C can work like this (maybe also need to check for a single pullup resistor on each of SCL and SDA). The uC and firmware support is a harder question to answer and possibly only answerable by "just trying it" and the 640 seems the only viable candidate. My 440 is open to experimentation but it is at least two steps away from where we want to get to since it has neither KB nor PC-Link interface. If we did come up with an answer, I'm not sure Stephen's 50W plumbing iron is up to reflowing 0803 SMD resistors or TSOP ICs :-P How can I help answer your "last remaining step"? (The link took me to an earlier post in our conversation).
  12. kgallen
    Is there a machine with KB and PC-Link? I'd like to look at the schematic...
  13. kgallen
    Great news! I still don't understand the cause of the issue as first reported (recording issues with AA cell). Maybe I should have asked what a "Duracell AA8" battery is though. I know what a "Duracell AA" is!
  14. kgallen
    Related from the MDS-PC3 SM, captured for future reference...
  15. kgallen
    I think one of the comments to the video sums it up nicely: "Two minutes in, I desperately wanted one. Four minutes in, I didn't want one anymore."...
  16. kgallen
    LMAO! Looking at the schematics I would summarise as: - the JE640 keyboard interface is input only for the data. The buffer stage they've implemented here works keyboard -> uC only for data (the clock, SCL, is bidirectional since it's driven out to the keyboard but in the I2C protocol the slave (the keyboard) can hold the clock low as a flow control mechanism). - the S50 PC-Link interface is pure birectional I2C. I suspect the deck uC is the bus master but data can flow in either direction. The implementation uses a specific I2C buffer chip (listed above) to buffer the I2C bus from the uC to be able to drive out on a "long" cable to the slave device (this MN10 thing that is mentioned). So it's perfectly possible that on the JP model, they've hung both of these buffer circuits from the uC-side I2C bus (since I2C is specifically designed to work like that). Indeed if I look more closely at the S50 vs 640 schematics, maybe if both sets of components are populated on the PCB, then given the firmware support within the uC this support may indeed be possible on the 640 (subject to uC equivalence flagged by @NGY earlier). Indeed looking more closely at the 640 schematic, the discrete buffer stage is between the true I2C bus, which does appear on the KB connector *on the main PCB not necessarily on the deck connector* and a separate set of "KB" I/O on the uC. It looks like the PC-Link also uses this (non-standard I2C) "IIC-BUSY" signal which is not brought out on the 640 KB interface. More investigation needed, leave it with me...
  17. kgallen
    Yea... @Richard is suggesting he's bad with Forum software but he's got nothing on my incompetence with software in general (or more specifically Operating Systems and "Apps" as we seem to call everything these days). Computers are a work tool for me but 'cos I use them all day long people (inc family) think I'm "in IT" and can fix any computer malady they can throw at me! < string of emoticon's required here! > (In a Tarzan guise) "Me Hardware, You Software" :-D
  18. kgallen
    Thanks! I will persevere with this Unread option a little more. At this point I don't have any "unread" in MD->Tech so I will need to try this when there is some new content. Good shout though, thanks!
  19. kgallen
    Absolutely not! Your diligence is impressive and greatly appreciated - nothing worse than reading a thread and all the links/images broken. I didn't intend to knock this work in the slightest, more as a means to illustrate the issue I've seen. This usage issue I see both with this new "shiny" forum installed Mar/Apr 21 and with the previous version. Also Emoji's would be good! (Stephen is now groaning...!) Carry on McDuff, sterling work!
  20. kgallen
    How do people get on with the Forum on a smartphone? I have an iPhone SE (2020) with iOS 14.4.2 (latest as of last night), but saw similar behaviour with iPhone 7 on various iOS probably from iOS 12. Although I don't think the iOS version is directly relevant. I've tried Chrome, Safari and Firefox browsers. What I see is that various sections of the main Forum threads pane gets overwritten by what seem to be the side banners - Popular Contributors, Top Downloads. I see the Topics pane which has the currently active last 5 threads, but then the main Forum pane is blapsed over by these side panes and is thus inaccessible. With @Richard's studious work recently to recover all of the images on old posts the top-5 topics are generally old posts he's working on. With this issue reading the Forum on the phone, the main Minidisc->Technical forum I access becomes inaccessible (ok I can get around this by finding a URL elsewhere and jumping to that). Does anyone else see this and do they know how to drive the page properly to avoid this, as it seems I'm incapable! Thanks!
  21. kgallen
    There seem to be conflicting usage of the I2C bus from the uC. On the 640 this bus is used to implement the keyboard interface. On the S50 it's used via an I2C buffer chip to implement the PC-Link. So from what I can see keyboard vs PC-Link are mutually exclusive and there is likely different firmware in the uC for each variant to account for this. FWIW the I2C buffer chip, IC800 is a standard NXP part, P82B715TD .
  22. kgallen
    Careful otherwise you're going to become some intermediary seller for us in the UK!
  23. kgallen
    It's perfectly possible this comes down to cost and device availability. If Sony have a number of population options in their products they can go with the flow and choose the cheapest option at the time of build, or are more robust against yield issues on a particular part. Silicon memory faults are the most likely cause of device yield dropoff, particularly on-chip flash which will require different processing steps and different silicon implants in the wafer fab compared to SRAM and random logic which are more "standard". Mixed-process devices are more problematic (and it's very impressive that the Sony CXD chips have on-chip DRAM mixed with "normal" VLSI digital logic, SRAM and probably even some analogue interface circuitry - very impressive for the year, and Sony are "fabless", so they don't have the luxury of in-house processing they can tune and tweak like Intel). If all machines of a given model have the same device population then that would indicate an engineering requirement. Where there is population variability it probably is a decision made on BOM cost at the time.
  24. kgallen
    The external Flash chip, IC2, is padded out but is is populated? In my 440 the chip is not populated, but IC2 is shown on both 440 and 640 schematics. I see similar in my two MDS-E10's - one has the external Flash chip populated the other doesn't. I wondered why this is. Is it CYA for when the firmware grows too large for the flash inside the uC? Or maybe a cost option, external flash might have been cheaper at some point than the next uC up the scale with larger internal Flash? What I'm saying, is the population of this Flash chip really feature dependent or just an evolutionary precaution or an option for BOM cost tradeoffs? i.e. having the flash or not, is not necessarily an indicator of functional capability. In the S50 SM, page 40, the schematic outlines a few components in blue, and some not. The external Flash, IC2, is not outlined. The footnote says "There are a few cases that the part isn't mounted in model is printed on diagrams" (sic). In fact on p42 of the S50 SM, which is the uC sheet, the external flash is not drawn. S50 uC=M30805MG-211GP [144 pin QFP], 440/640=M30805SGP [144 pin QFP]. I'd need to investigate the uC datasheet to see if there is enough information in these part codes to indicate a different variant of the part is selected. S50 timeline suggests it came out a few months after 440/640 so it's possible Mitsubishi revised their uC family slightly and Sony started to order using the new part code - when under the hood they had the same requirements on the uC for internal RAM and flash etc.
  25. kgallen
    It is, so what the heck are you doing up on the Forum - get some shut-eye! :-P
×
×
  • Create New...