May 2016 - vcf-midatlantic - lists.vcfed.org

Robots and Relays and Commodore
by Chris Fala 27 May '16

27 May '16

Would this help? http://www.ebay.com/itm/152084733487

8 22

Evan @ IFIP
by Evan Koblentz 26 May '16

26 May '16

Forgot to mention this. Tomorrow I'll be part of a roundtable discussion at an NYC meeting of the International Federation of Information Processing's history .SIG. I have 15 minutes to talk about early British mobile computers. Going to focus on Husky (which should be famous but isn't) and Psion (which needn't be famous but is).

2 5

semi-OT: downloading vintage computer document
by Dan Roganti 26 May '16

26 May '16

anyone have some tricks up their sleeve to extract the pdf from this link ? it appears to be hiding behind a java servlet a site search falls into the same trap this might interest some of you too http://www.osti.gov/scitech/servlets/purl/5054065

2 2

Good source for eproms?
by Jason Perkins 26 May '16

26 May '16

I'm trying to get a Plus HardCard going again. Like many the ROM has forgotten some of its bits so I want to try installing a freshly flashed one. What's a good source for 7264s? Is it worth trying to get used ones on eBay? While I'm at it I'd like to track down a 2732 for an Apple ProFile formatting rom. Thanks, -- Jason Perkins

9 17

First Hollywood stops using paper tape in the film editing machines...
by Corey Cohen 26 May '16

26 May '16

And now that the pentagon is getting rid of 8" floppy disks by the end of 2017, without the military needing replacements, I bet this is the end of newly manufactured 8" floppies. I better get used to baking my old floppies for reuse. https://www.yahoo.com/news/us-nuclear-force-still-using-floppy-disks-report… Cheers, Corey corey cohen uǝɥoɔ ʎǝɹoɔ

1 0

MOnSter 6502 Project - Microprocessor in Discrete Components
by Todd George 25 May '16

25 May '16

Saw this on Reddit, completely amazed... http://tubetime.us/?p=346 I am familiar with their 555 Timer IC project, and saw that they had a follow up project with the 741. Had no idea they'd take it this far. :) -Todd

6 6

ADTPro help
by Evan Koblentz 25 May '16

25 May '16

I last used ADTPro about a year ago. It worked fine. A few months ago I installed a new mobo/memory/processor in my daily PC (still running Ubuntu). Yesterday I tried ADTPro again and got this error message: "There are no serial ports, or the serial library RXTX is not installed or visible." Paul H. suggested that the adtpro.sh file was looking in the wrong place for RXTX. Made some tweaks but it's still not working. Note also that ADTPro has its own copy of RXTX in a subfolder. Stephen E. also tried to help. Can someone who is experienced at both ADTPro and Linux (and who has the patience to walk me through this) help me, please? Hoping to get some help via telephone or Skype today/tonight if possible.

7 16

Re: [vcf-midatlantic] Good source for eproms?
by Jonathan Gevaryahu 25 May '16

25 May '16

On 5/25/2016 10:29 AM, Bill Sudbrink via vcf-midatlantic wrote: > chrisjpf33 wrote: >> Is "metric assload" am official Department of Weights and Measures unit >> of measurement? > Actually, the proper SI unit is "metric buttload". > > Bill S. > > > Is assload a unit of volume, and fuckton a unit of mass? -- Jonathan Gevaryahu jgevaryahu(a)gmail.com jgevaryahu(a)hotmail.com

2 1

Re: [vcf-midatlantic] Good source for eproms?
by Chris Fala 25 May '16

25 May '16

Thanks for clearing that up. I wasn't sure which was official and which was informal. I thought it was the rated PG vs. rated R. On Wed, May 25, 2016 at 10:29 AM, Bill Sudbrink via vcf-midatlantic < vcf-midatlantic(a)lists.vintagecomputerfederation.org> wrote: > chrisjpf33 wrote: > > Is "metric assload" am official Department of Weights and Measures unit > > of measurement? > > Actually, the proper SI unit is "metric buttload". > > Bill S. > > >

2 1

A more efficient BBS Xfer protocol
by John Heritage 25 May '16

25 May '16

Hi folks! Being a geek and SysOp I spent a lot of time as a teenager looking for the most efficient BBS file transfer protocol - working through XModem CRC, Ymodem-1K, ZModem, ZModem with MobyTurbo, Ymodem-G, etc.. I even ran HS-Link (and BiModem) for a while to help people who actually uploaded to BBSes :). In search of CPS, the fastest I could transmit a compressed file over a 14.4 kbps link (1800 cps theoretical maximum) was using Ymodem-G** with a series of modem settings (AT&K0 - disable compression, and a few others), achieving just over 1730 cps. ZModem* was something in the 1630-1650 range, and DSZ's "mobyturbo" Zmodem would do ~ 1660-1665. Anyway I had an idea at the time to write a protocol that would dedicate 100% of the senders bandwidth to transmitting data while still adding error correction. Here's how it would work: 1. Sender streams data continuously; but calculates a CRC every X bytes (x=1024 initially), and stores to RAM. 2. Receiver receives data continuously; calculates a CRC every 1024 bytes and then sends back to the receiver over the modem back channel***. 3. Sender looks at CRCs received and if there's a match, continues sending. If there is a bad CRC, the Sender would either end the transfer (like Ymodem-G) or initiate some kind of "resume from previous bytes" control sequence TBD. 4. To help the file transfer end with minimum wasted overhead, I'd probably start the protocol with a simple string indicating how many bytes are in the transfer so the receiver knows when to stop recording. I know there's more to it than this -- the control sequence would still cost something unless I went the Ymodem-G route. The receiver would have to be fast enough to write to disk, calculate CRCs, and send CRCs without running out of modem buffer to prevent delays.. Anyway, in my mind this is 100% or as near to 100% efficient for a one-way file transfer as you can get.. Did anyone ever write a protocol like this? Am I a fool? :) Thanks! John ....... If you like reading: * Zmodem of course could resume and recover where Ymodem-G couldn't, but was less efficient due to certain control byte characters needing to be double sent when they appeared in the stream. ** Ymodem-G though rarely failed on "modern" error correcting modems.. *** USRobotics initial 14.4kbps implementation only had a 450 baud back channel which was limiting, but the industry standard (V.32bis?) was capable of 14.4kbps symmetrically.

1 0