[cctalk] Re: Any working Datapoint 2200 systems?
On 11/13/22 15:45, Steve Lewis via cctalk wrote: True, I'd have to assume actual usage degrades the longevity of some electronics (and number of hot/cold cycles). But there is still some natural shelf-life decay (maybe moisture in the air can find its way, even in what should be sealed components). Yup, I have a ~ year 2000 pick and place machine. It was last used in about 2006 and then abandoned in Austin, TX. I bought it at auction in 2020, so it had been sitting for about 14 years, likely in unconditioned air space. It fired right up the first time I tried, and I cloned the hard drive. Then, 2 days later it would not come out of E-stop. Lots of boards went bad over time, and are still going out. Nothing I have replaced has failed, and all repair parts must be about the same vintage. So, yes, sitting in warm, humid conditions for a long time apparently is NOT good for electronics. Funny, the man-machine interface computer is a consumer-grade PC, I think it is original, and is still chugging along. VME boards and industrial servo drives have gone out. Jon
[cctalk] Re: Any working Datapoint 2200 systems?
True, I'd have to assume actual usage degrades the longevity of some electronics (and number of hot/cold cycles). But there is still some natural shelf-life decay (maybe moisture in the air can find its way, even in what should be sealed components). > I am completely ignorant to the operation of the 5100 but can't you just > dump that memory when the system is on? Or is there some Jon Titor type > reason behind it? Some of it, yes. Enough that a viable 5110 emulator was made (5100 emulator still in work). But there is some code in the PALM processor itself (about a dozen "tin cans" on there, related to how it actually executed instructions), the Base IO card, display card, comm. cards. Like for the display card, and how its character set is generated (there should be similar code like was shown for the DP). So there are some limits to the emulator, such as MARKing a tape/disk and doing both a read/write of tape/disk images (there is some limited read capability). So, true, baring some of the I/O features and some precise timing of the processor, a reasonable replica could be made (a good replica of the font is in Corti's X11 parts of the emulator - one of the sets at least). But that's an emulation, not a replica :D On Sun, Nov 13, 2022 at 3:00 PM Sellam Abraham via cctalk < cctalk@classiccmp.org> wrote: > Steve said: > > > I recall a talk from one of the early 1980s Commodore engineer, where he > was amazed ANY C64 was still > > running since the components were truly not designed to last more than a > few years. > > Me too, to be honest. But then, they seem to just randomly die at any > moment, so maybe the C64 components are only good for so many hours of use, > like a light bulb. The fact that so many of them were made (upwards of 25 > million) is probably why some can still be found working. Those are still > somewhere on the vertical of the bathtub curve on the backend, where their > useful life is fast coming to an end. We will all probably witness the > last working Commodore 64's in our lifetimes :D > > > But, in extracting the data on those TTLs, it seems like a modern replica > of a DP2200 would be possible. > > Can't say the same for the 5100 because apparently nobody left on the > planet understands those MOSFET > > silver cans (and how to extract the 6KB of content from them). > > I am completely ignorant to the operation of the 5100 but can't you just > dump that memory when the system is on? Or is there some Jon Titor type > reason behind it? > > Sellam > > > On Sun, Nov 13, 2022 at 12:15 PM Steve Lewis via cctalk < > cctalk@classiccmp.org> wrote: > > > Thanks Jos, I hadn't realized how similar the DP1100 is. > > > > This brochure has a great image of the font right on the front page > (80x12 > > text): > > > http://www.bitsavers.org/pdf/datapoint/1100/Dataform_1100_Brochure_1974.pdf > > > > And it's probably a safe bet that it's the same font as in the 1972 > > models. Would be neat to see the entire character set. In the photo, > the > > screen looks fairly inset -- like maybe an inch? That's good for keeping > > glare off the screen. > > > > I see there was a Cassette 1100 and Disk 1100 (by '75): > > http://www.bitsavers.org/pdf/datapoint/1100/60259_1100_Brochure_1975.pdf > > > > Then I came across a DP2200 emulator, except -- it was apparently made in > > 1973 and ran on a DP2200! (ACM link, but click the PDF, it's freely > > available) > > https://dl.acm.org/doi/10.1145/800192.805722 > > > > > > What a neat system. In an old IBM 5110, I replaced its power supply > with > > modern components. From the DP2200 manual, it looks like it needs -5 > > -12 +5 +12 and +24V? There is a "trick" in the modern buck-boost voltage > > converters to get negative voltage (the IBM PSU needs -5 -12 +5 +12 > > and +8.5V). I put notes about it here: > > https://voidstar.blog/ibm-5100-power-supply/ > > > > Maybe something similar can be done for the old DP's? I understand for > > authentic/historical perspective all original components is prefered, but > > using a substitute PSU is reasonable for checking out the rest of the > > system. > > > > Were there any contemporary complaints about the DP PSU in the mid-1970s? > > Like was it noisy, ran hot, cause any fires? I recall a talk from one > of > > the early 1980s Commodore engineer, where he was amazed ANY C64 was still > > running since the components were truly not designed to last more than a > > few years. > > > > > > What an amazing system those Datapoints were, for their time. The > > chicken-farm story in the DP2200 book is really fun - these farmers being > > savvy enough to code up what they needed, and the systems compact enough > to > > fit in the farms and using modems even to sync up data (pre-1975). > > > > The IBM 5100: 64x16 screen (instead of 80x12 used in DP), and a > > slightlyBut, in extracting the data on those TTLs, it seems like a modern > > replica > > of a DP2200 would be possible.
[cctalk] Re: Any working Datapoint 2200 systems?
Steve said: > I recall a talk from one of the early 1980s Commodore engineer, where he was amazed ANY C64 was still > running since the components were truly not designed to last more than a few years. Me too, to be honest. But then, they seem to just randomly die at any moment, so maybe the C64 components are only good for so many hours of use, like a light bulb. The fact that so many of them were made (upwards of 25 million) is probably why some can still be found working. Those are still somewhere on the vertical of the bathtub curve on the backend, where their useful life is fast coming to an end. We will all probably witness the last working Commodore 64's in our lifetimes :D > But, in extracting the data on those TTLs, it seems like a modern replica of a DP2200 would be possible. > Can't say the same for the 5100 because apparently nobody left on the planet understands those MOSFET > silver cans (and how to extract the 6KB of content from them). I am completely ignorant to the operation of the 5100 but can't you just dump that memory when the system is on? Or is there some Jon Titor type reason behind it? Sellam On Sun, Nov 13, 2022 at 12:15 PM Steve Lewis via cctalk < cctalk@classiccmp.org> wrote: > Thanks Jos, I hadn't realized how similar the DP1100 is. > > This brochure has a great image of the font right on the front page (80x12 > text): > http://www.bitsavers.org/pdf/datapoint/1100/Dataform_1100_Brochure_1974.pdf > > And it's probably a safe bet that it's the same font as in the 1972 > models. Would be neat to see the entire character set. In the photo, the > screen looks fairly inset -- like maybe an inch? That's good for keeping > glare off the screen. > > I see there was a Cassette 1100 and Disk 1100 (by '75): > http://www.bitsavers.org/pdf/datapoint/1100/60259_1100_Brochure_1975.pdf > > Then I came across a DP2200 emulator, except -- it was apparently made in > 1973 and ran on a DP2200! (ACM link, but click the PDF, it's freely > available) > https://dl.acm.org/doi/10.1145/800192.805722 > > > What a neat system. In an old IBM 5110, I replaced its power supply with > modern components. From the DP2200 manual, it looks like it needs -5 > -12 +5 +12 and +24V? There is a "trick" in the modern buck-boost voltage > converters to get negative voltage (the IBM PSU needs -5 -12 +5 +12 > and +8.5V). I put notes about it here: > https://voidstar.blog/ibm-5100-power-supply/ > > Maybe something similar can be done for the old DP's? I understand for > authentic/historical perspective all original components is prefered, but > using a substitute PSU is reasonable for checking out the rest of the > system. > > Were there any contemporary complaints about the DP PSU in the mid-1970s? > Like was it noisy, ran hot, cause any fires? I recall a talk from one of > the early 1980s Commodore engineer, where he was amazed ANY C64 was still > running since the components were truly not designed to last more than a > few years. > > > What an amazing system those Datapoints were, for their time. The > chicken-farm story in the DP2200 book is really fun - these farmers being > savvy enough to code up what they needed, and the systems compact enough to > fit in the farms and using modems even to sync up data (pre-1975). > > The IBM 5100: 64x16 screen (instead of 80x12 used in DP), and a > slightlyBut, in extracting the data on those TTLs, it seems like a modern > replica > of a DP2200 would be possible. Can't say the same for the 5100 because > apparently nobody left on the planet understands those MOSFET silver cans > (and how to extract the 6KB of content from them). > larger "box"(case) that had a "horn" inside for better airflow over all the > components (not an audible horn, but a thing that channel air from the PSU > fan to distribute over all the electronic cards and display circuits). > Plus the 5100 supported the external BNC video (I'm not sure if any of the > DP systems had an external video connector? I didn't see it mentioned in > the DP2200 manual) - I've put 3x extra CRT's chained up to the IBM 5100, in > the manual I think it says it can go up to 16 (not sure what the limiting > factor of that signal is). I'm not sure if quality-wise the IBM PSU was > "better" (it takes about 3/4th of the back half of the case, the other > 1/4th for the fan) - other than to say quite a few 5100's are still running > in the world. Maybe all that altogether makes it (the 5100) a more > "portable" system (construction sites, forward edge battlespace, etc -- > i.e. being more robust to handle outside heat). Also it had a minimum of > 8K. The APL stuff made the 5100 expensive, but the base BASIC model was > ~$9K (I think even with the single QIC tape for 207KB storage; but that > price didn't include async/comm cards). Weren't base DPs $5K-$7K (all > throughout 72-75) ? > > > But, in extracting the data on those TTLs, it seems like a modern replica > of a DP2200 would be possible. Can't
[cctalk] Re: Modern Replacement for H7140 in PDP 11/24
On Sun, 13 Nov 2022 18:36:24 - Rob Jarratt via cctalk wrote: > Given all the troubles I have had with the H7140 in my PDP 11/24 I am > considering whether to replace it with modern equivalents, installed > inside the H7140 enclosure. I am a bit puzzled by the specs listed in > the PDP 11/24 Maintenance Card, it suggests the PSU outputs +12V and > -12V from the memory inverter/memory regulator, but the specs for the > cards don't mention 12V so I don't know if I need 12V from the PSU. > My memory board is an M8722-BC (MS11-MB). I can't find a manual or > printset for this memory, so I am not sure what voltages it will > need, although I suspect it only needs +5V, +15V and -15V. Is that > right? The MS11-MB printset is here: http://wwcm.synology.me/pdf/MP00742%20MS11-M%20Field%20Maintenance%20Print%20Set.pdf
[cctalk] Re: Any working Datapoint 2200 systems?
Thanks Jos, I hadn't realized how similar the DP1100 is. This brochure has a great image of the font right on the front page (80x12 text): http://www.bitsavers.org/pdf/datapoint/1100/Dataform_1100_Brochure_1974.pdf And it's probably a safe bet that it's the same font as in the 1972 models. Would be neat to see the entire character set. In the photo, the screen looks fairly inset -- like maybe an inch? That's good for keeping glare off the screen. I see there was a Cassette 1100 and Disk 1100 (by '75): http://www.bitsavers.org/pdf/datapoint/1100/60259_1100_Brochure_1975.pdf Then I came across a DP2200 emulator, except -- it was apparently made in 1973 and ran on a DP2200! (ACM link, but click the PDF, it's freely available) https://dl.acm.org/doi/10.1145/800192.805722 What a neat system. In an old IBM 5110, I replaced its power supply with modern components. From the DP2200 manual, it looks like it needs -5 -12 +5 +12 and +24V? There is a "trick" in the modern buck-boost voltage converters to get negative voltage (the IBM PSU needs -5 -12 +5 +12 and +8.5V). I put notes about it here: https://voidstar.blog/ibm-5100-power-supply/ Maybe something similar can be done for the old DP's? I understand for authentic/historical perspective all original components is prefered, but using a substitute PSU is reasonable for checking out the rest of the system. Were there any contemporary complaints about the DP PSU in the mid-1970s? Like was it noisy, ran hot, cause any fires? I recall a talk from one of the early 1980s Commodore engineer, where he was amazed ANY C64 was still running since the components were truly not designed to last more than a few years. What an amazing system those Datapoints were, for their time. The chicken-farm story in the DP2200 book is really fun - these farmers being savvy enough to code up what they needed, and the systems compact enough to fit in the farms and using modems even to sync up data (pre-1975). The IBM 5100: 64x16 screen (instead of 80x12 used in DP), and a slightly larger "box"(case) that had a "horn" inside for better airflow over all the components (not an audible horn, but a thing that channel air from the PSU fan to distribute over all the electronic cards and display circuits). Plus the 5100 supported the external BNC video (I'm not sure if any of the DP systems had an external video connector? I didn't see it mentioned in the DP2200 manual) - I've put 3x extra CRT's chained up to the IBM 5100, in the manual I think it says it can go up to 16 (not sure what the limiting factor of that signal is). I'm not sure if quality-wise the IBM PSU was "better" (it takes about 3/4th of the back half of the case, the other 1/4th for the fan) - other than to say quite a few 5100's are still running in the world. Maybe all that altogether makes it (the 5100) a more "portable" system (construction sites, forward edge battlespace, etc -- i.e. being more robust to handle outside heat). Also it had a minimum of 8K. The APL stuff made the 5100 expensive, but the base BASIC model was ~$9K (I think even with the single QIC tape for 207KB storage; but that price didn't include async/comm cards). Weren't base DPs $5K-$7K (all throughout 72-75) ? But, in extracting the data on those TTLs, it seems like a modern replica of a DP2200 would be possible. Can't say the same for the 5100 because apparently nobody left on the planet understands those MOSFET silver cans (and how to extract the 6KB of content from them). Sorry for the tangent:) I really was just curious about the DP2200 font, and possibly seeing where it came from (just based on its style). The DP has a better "0" (zero) font than the 5100 :) (IMO) -Steve On Sun, Nov 13, 2022 at 3:45 AM jos via cctalk wrote: > On 13.11.22 07:13, Steve Lewis via cctalk wrote: > > I've been looking for a video or image that shows what font the original > > Datapoint 2200 used. > > > > It's not shown in the manual. There is one vintage image with the > office > > lady and the DP2200 on the desk- but the font isn't very clear in that. > > > > In any modern video about the DP2200, none of them seem to power it on -- > > which is certainly understandable. From what I've read, the power > supply > > of that system is prone to failure. Also, the system is hard-coded to > load > > from Tape 1 -- which means both the tape drive, and tape media, still > needs > > to be in good working order (which would be pretty rare after this time). > > > > In "the" DP2200 book, it only briefly mentions that the original tape > > software was developed "on an HP system" (without any elaboration that I > > could tell on which HP system that was). > > > > Nothing in the manual suggests the original DP2200 could "program itself" > > (i.e. no built in machine code monitor -- those TTL chips had one strict > > boot up sequence: load from tape 1). If there was a read error or no > tape > > available, I'm curious if any message showed
[cctalk] Re: Inline Serial Device?
> On Nov 13, 2022, at 9:09 AM, Paul Koning via cctalk > wrote: > > [EXTERNAL EMAIL] > > > >> On Nov 12, 2022, at 1:08 PM, Anders Nelson via cctalk >> wrote: >> >> I bet NN/AI would be helpful with data recovery - if we can model certain >> common failure modes with those old drive heads we could infer what the >> data should have been... > > NN maybe, I need to understand those better. I see they are now a building > block for OCR. > > AI, not so clear. In my view, AI is a catch-all term for "software whose > properties are unknown and probably unknowable". A computer, including one > that executes AI softwware, is a math processing engine, so in principle its > behavior is fully defined by its design and by the software in it. But when > you do AI in which "learning" is part of the scheme, the resulting behavior > is in fact unknown and undefined. > > For some applications that may be ok. OCR doesn't suffer materially from > occasional random errors, since it has errors anyway from the nature of its > input. But, for example, I shudder at the notion of AI in safety-critical > applications (like autopilots for aircraft, or worse yet for cars). A safety > critical application implemented in a manner that precludes the existence of > a specification is a fundanmentally insane notion. > > paul > Paul, not a fan of AI myself. But, I feel constrained to point out that the alterative to "AI in safety-critical applications” often is “a minimum-wage employee in a safety-critical application” which may or may not be an improvement. Agreed that AI is fundamentally not absolutely predictable - but neither are people. For problems complex enough to require either in a safety-critical decision-making loop, it may resolve down to a question of either 1) trusting the statistics (AI driving is maybe already *statistically* safer than human driving), 2) desiging the whole system in such a manner as to be tolerant of decision-making faults, or 3) Not doing the dangerous activity because it’s not monitorable. I would say our current road and automobile system doesn’t satisfy any of those criteria, FWIW. For problems simple enough to write closed-form, formally-verifiable software to handle, I *definitely* agree that is the way to go. - Mark
[cctalk] Re: Inline Serial Device?
> On Nov 13, 2022, at 2:31 PM, Cameron Kaiser via cctalk > wrote: > >> AI, not so clear. In my view, AI is a catch-all term for "software whose >> properties are unknown and probably unknowable". > > Someone recently on Hacker News talked about the possibility of neural net > models to translate code for other architectures. The best response to this > idea described it as a "turbo SIGILL generator." That's a good description. > The mental image of a CPU ramming into a silicon brick wall, reversing and > doing it again, over and over, possibly infinitely (the halting problem) comes > irresistibly to mind. I see all too many "inventions" that can be summarized as "use prior art solution X to well known problem Y by executing X in an AI (or "machine learning") system." Sigh. paul
[cctalk] Re: Inline Serial Device?
> AI, not so clear. In my view, AI is a catch-all term for "software whose > properties are unknown and probably unknowable". Someone recently on Hacker News talked about the possibility of neural net models to translate code for other architectures. The best response to this idea described it as a "turbo SIGILL generator." The mental image of a CPU ramming into a silicon brick wall, reversing and doing it again, over and over, possibly infinitely (the halting problem) comes irresistibly to mind. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- The earth is like a tiny grain of sand, only a lot heavier and bigger. -
[cctalk] Modern Replacement for H7140 in PDP 11/24
Given all the troubles I have had with the H7140 in my PDP 11/24 I am considering whether to replace it with modern equivalents, installed inside the H7140 enclosure. I am a bit puzzled by the specs listed in the PDP 11/24 Maintenance Card, it suggests the PSU outputs +12V and -12V from the memory inverter/memory regulator, but the specs for the cards don't mention 12V so I don't know if I need 12V from the PSU. My memory board is an M8722-BC (MS11-MB). I can't find a manual or printset for this memory, so I am not sure what voltages it will need, although I suspect it only needs +5V, +15V and -15V. Is that right? I know I will also have to replace the fans, because the ones in the machine are AC and need 35V. Thanks Rob
[cctalk] Re: Inline Serial Device?
IMHO, AI is bull Martin -Original Message- From: Paul Koning via cctalk [mailto:cctalk@classiccmp.org] Sent: 13 November 2022 15:10 To: cctalk@classiccmp.org Cc: Paul Koning Subject: [cctalk] Re: Inline Serial Device? > On Nov 12, 2022, at 1:08 PM, Anders Nelson via cctalk > wrote: > > I bet NN/AI would be helpful with data recovery - if we can model > certain common failure modes with those old drive heads we could infer > what the data should have been... NN maybe, I need to understand those better. I see they are now a building block for OCR. AI, not so clear. In my view, AI is a catch-all term for "software whose properties are unknown and probably unknowable". A computer, including one that executes AI softwware, is a math processing engine, so in principle its behavior is fully defined by its design and by the software in it. But when you do AI in which "learning" is part of the scheme, the resulting behavior is in fact unknown and undefined. For some applications that may be ok. OCR doesn't suffer materially from occasional random errors, since it has errors anyway from the nature of its input. But, for example, I shudder at the notion of AI in safety-critical applications (like autopilots for aircraft, or worse yet for cars). A safety critical application implemented in a manner that precludes the existence of a specification is a fundanmentally insane notion. paul
[cctalk] Re: Inline Serial Device?
> On Nov 12, 2022, at 1:08 PM, Anders Nelson via cctalk > wrote: > > I bet NN/AI would be helpful with data recovery - if we can model certain > common failure modes with those old drive heads we could infer what the > data should have been... NN maybe, I need to understand those better. I see they are now a building block for OCR. AI, not so clear. In my view, AI is a catch-all term for "software whose properties are unknown and probably unknowable". A computer, including one that executes AI softwware, is a math processing engine, so in principle its behavior is fully defined by its design and by the software in it. But when you do AI in which "learning" is part of the scheme, the resulting behavior is in fact unknown and undefined. For some applications that may be ok. OCR doesn't suffer materially from occasional random errors, since it has errors anyway from the nature of its input. But, for example, I shudder at the notion of AI in safety-critical applications (like autopilots for aircraft, or worse yet for cars). A safety critical application implemented in a manner that precludes the existence of a specification is a fundanmentally insane notion. paul
[cctalk] Re: Any working Datapoint 2200 systems?
I assume the Datapoint 3300 terminal's electronics beam characters to the crt differently. If they're the same, or close enough from the font perspective, I have a 3300 that works that could be used. Same goes for power supply, I have a spare of one of the 3300"s power supplies should it be used to modified to be used in a 2200. I.assume it's a long shot.. I did not look it up to see for sure. Anyone have a 3300 that needs a power supply? The 3300 has multiple power supplies, I have a working spare of the supply that attaches to the back behind the.crt. Bill On Sun, Nov 13, 2022, 4:45 AM jos via cctalk wrote: > On 13.11.22 07:13, Steve Lewis via cctalk wrote: > > I've been looking for a video or image that shows what font the original > > Datapoint 2200 used. > > > > It's not shown in the manual. There is one vintage image with the > office > > lady and the DP2200 on the desk- but the font isn't very clear in that. > > > > In any modern video about the DP2200, none of them seem to power it on -- > > which is certainly understandable. From what I've read, the power > supply > > of that system is prone to failure. Also, the system is hard-coded to > load > > from Tape 1 -- which means both the tape drive, and tape media, still > needs > > to be in good working order (which would be pretty rare after this time). > > > > In "the" DP2200 book, it only briefly mentions that the original tape > > software was developed "on an HP system" (without any elaboration that I > > could tell on which HP system that was). > > > > Nothing in the manual suggests the original DP2200 could "program itself" > > (i.e. no built in machine code monitor -- those TTL chips had one strict > > boot up sequence: load from tape 1). If there was a read error or no > tape > > available, I'm curious if any message showed on the CRT. > > > > So, I was just wondering if there was any known pre-1973 Datapoint 2200's > > that are still working? (and/or if any HD video of them powered on and > > legible font can be seen) Or any other more current system that we know > > for sure used the same font? > > > > Thanks! > > -Steve > > > Not only is the powersupply prone to failure, it is also the most > dangerous I have ever seen, and I am hesitant on working it. Primary and > secondary sides not separated, isolation between the two almost > nonexistant, many primary nodes exposed. Would never pass modern safety > checks. > > But here is a picture of my DP1100, a DP2200 derivative, while it was > running a memory selftest, for a short time in 2021, before the powersupply > blew again : > > > https://forum.vcfed.org/index.php?threads/its-alive-my-datapoint-2200-1100.1222197/#post-1222197 > > While the DP2200 is hardcoded to start from tape, the DP1100, otherwise > identical, boots from a ROM. This ROM also contains a minimal machinecode > monitor. I recovered & disasembled the ROM and Gordon Peterson, from > Datapoint, commented it out : > http://www.bitsavers.org/pdf/datapoint/1100/DisketteBootDisassemblyGEP2.txt > > Note that there are multiple videoboard options : the later DP2200, my > DP1100, and the DP5500 share the same videoboard. This relies on a > programmable characterset. In the disassembly mentioned above above, > starting at line 3660 you will see a load of gobldecook, these are actually > fondsets to be loaded into the machine. > > The fontset has a very particular "look" to it. How much is due to > fontdefinition, and how much is due to the diddlescan, that I dont know. > Diddlescan is where they scan each character in full, before proceding to > the next. > > Note that a ROM based bootboard for a DP2200 would be a trivial > undertaking, and only involve changing the cassette reader board for the > ROM board. > > > Jos > > >
[cctalk] NEC APC I / III available USA Massachusetts
I am downsizing. These have been in storage for quite some time. I am about 25 miles N of Boston, MA and S of Nashua NH. These are both extremely heavy so no interest in shipping. Unfortunately I do not have any software for either system. The I is fairly clean and the kb is effectively new-old-stock with the box. Possibly unused. Powers on, green mono, single drive. The III powers on but I can't get a cursor on video (there is a flash at power cycle). It has seen more use than the I (yellowing, case screws missing). Photos here: https://photos.app.goo.gl/6vbMnVZsZEkrpFGc8 e-mail if interested rich.bramante+cct...@gmail.com. Thank you.
[cctalk] Re: Inline Serial Device?
On Sun, Nov 13, 2022 at 9:54 AM Robin Downs via cctalk wrote: > > Hi, > Actually, I built exactly this many years ago (1990s) to operate a cash draw > for dumb terminals on Unix systems, used on counters as point of sale > devices... > > The existing solution used a processor, ram, rom, double sided board etc and > was too expensive, so I designed a replacement with a real UART and a finite > state machine consisting of a EPROM and 8 bit latch that simply monitored the > RS232 data passively and when the appropriate character sequence was matched, > it triggered the solenoid to open the cash draw. I am now thinking of totally crazy ways to detect a serial character. OK, a Model 33 Teletype with the right option in the stunt box is trivial. One odd idea is to detect the start bit and then generate the chracter bit-serially at the right baud rate. XOR that with the bitstream. Start with a flag ff set, at the middle of each bit-time, clear the flag if the bitstream and generated bit differ. At the end of the character time if the flag is still set, it's a match, Has the advantage of only needing a single-bit comparison not 7 or 8. > > It decoded a long 14 character code sequence easily and reliably and used 5 > chips in total on a smaller single sided board. > > Nowadays, a small microcontroller is the obvious way to go for cost and ease > of development. Cost, probably. Ease of development, it depends on who you are. I reckon I could solder up a suitable circuit using TTL only (i.e. not using a dumb UART which would simplify things a lot) in less time that it would take me to write the firmware. I am not a programmer. I tried the Arduino boards once and got fed up with a lack of proper printable documentation, no formal language specification, etc. -tony
[cctalk] Re: Inline Serial Device?
Hi, Actually, I built exactly this many years ago (1990s) to operate a cash draw for dumb terminals on Unix systems, used on counters as point of sale devices... The existing solution used a processor, ram, rom, double sided board etc and was too expensive, so I designed a replacement with a real UART and a finite state machine consisting of a EPROM and 8 bit latch that simply monitored the RS232 data passively and when the appropriate character sequence was matched, it triggered the solenoid to open the cash draw. It decoded a long 14 character code sequence easily and reliably and used 5 chips in total on a smaller single sided board. Nowadays, a small microcontroller is the obvious way to go for cost and ease of development. An easy way to implements is to use a small box to contain the two DB25 connectors and simply tap into the receive data line and run a short cable to the monitor circuit, probably built in and powered off what you want to operate... Regards, Robin Downs -Original Message- From: W2HX via cctalk Sent: 11 November 2022 21:16 To: General Discussion: On-Topic and Off-Topic Posts Cc: W2HX Subject: [cctalk] Inline Serial Device? Hello all, I am looking for a device that sits transparently in an RS-232 serial line and upon seeing a particular code go over the serial line ((or sequence of codes) will actual a relay (or a transistor). Something with two DB25s or DE9s and is configurable to what code will trigger the output? Some kind of box? Does anyone know of such a thing? I guess it could be cobbled up with a microcontroller, but hoping to just get something "off the shelf." Thank you 73 Eugene W2HX Subscribe to my Youtube Channel: https://www.youtube.com/@w2hx
[cctalk] Re: Inline Serial Device?
On Sat, 12 Nov 2022, Peter Corlett wrote: Farnell Nederland is quoting me ?1.06 (+21% VAT) for the cheapest brand of A quick search reveals that a single NE555 costs 0.25 Euros at Reichelt, *including* VAT. I'm sure they can be had much much cheaper in quantities. Christian
[cctalk] Re: Any working Datapoint 2200 systems?
On 13.11.22 07:13, Steve Lewis via cctalk wrote: I've been looking for a video or image that shows what font the original Datapoint 2200 used. It's not shown in the manual. There is one vintage image with the office lady and the DP2200 on the desk- but the font isn't very clear in that. In any modern video about the DP2200, none of them seem to power it on -- which is certainly understandable. From what I've read, the power supply of that system is prone to failure. Also, the system is hard-coded to load from Tape 1 -- which means both the tape drive, and tape media, still needs to be in good working order (which would be pretty rare after this time). In "the" DP2200 book, it only briefly mentions that the original tape software was developed "on an HP system" (without any elaboration that I could tell on which HP system that was). Nothing in the manual suggests the original DP2200 could "program itself" (i.e. no built in machine code monitor -- those TTL chips had one strict boot up sequence: load from tape 1). If there was a read error or no tape available, I'm curious if any message showed on the CRT. So, I was just wondering if there was any known pre-1973 Datapoint 2200's that are still working? (and/or if any HD video of them powered on and legible font can be seen) Or any other more current system that we know for sure used the same font? Thanks! -Steve Not only is the powersupply prone to failure, it is also the most dangerous I have ever seen, and I am hesitant on working it. Primary and secondary sides not separated, isolation between the two almost nonexistant, many primary nodes exposed. Would never pass modern safety checks. But here is a picture of my DP1100, a DP2200 derivative, while it was running a memory selftest, for a short time in 2021, before the powersupply blew again : https://forum.vcfed.org/index.php?threads/its-alive-my-datapoint-2200-1100.1222197/#post-1222197 While the DP2200 is hardcoded to start from tape, the DP1100, otherwise identical, boots from a ROM. This ROM also contains a minimal machinecode monitor. I recovered & disasembled the ROM and Gordon Peterson, from Datapoint, commented it out : http://www.bitsavers.org/pdf/datapoint/1100/DisketteBootDisassemblyGEP2.txt Note that there are multiple videoboard options : the later DP2200, my DP1100, and the DP5500 share the same videoboard. This relies on a programmable characterset. In the disassembly mentioned above above, starting at line 3660 you will see a load of gobldecook, these are actually fondsets to be loaded into the machine. The fontset has a very particular "look" to it. How much is due to fontdefinition, and how much is due to the diddlescan, that I dont know. Diddlescan is where they scan each character in full, before proceding to the next. Note that a ROM based bootboard for a DP2200 would be a trivial undertaking, and only involve changing the cassette reader board for the ROM board. Jos
