Project Logs

Collapse

• Hardware Flow Control

  Steve Toner • 08/06/2019 at 19:11 • 0 comments

  Hooked one of these up to a Cadetwriter at VCF West and found out a couple of things:  (1) The Cadetwriter doesn't like to operate at 300 baud & (2) the hardware flow control I implemented is incomplete at best.

  I tried it at 300 baud initially because I knew the Cadetwriter only prints at 15cps.  I was not aware that it can run at high baud rates and has quite a bit of output buffering.  Well, it turns out that the processor they use in the Cadetwriter (Teensy 3.5), though it claims to operate at 300 baud, is actually off by something like 200% at that selected rate.  We switched to 9600 and it worked fine.  Except we had to disable hardware flow control on the Cadetwriter because it implements it properly and the Toy BASIC Computer doesn't.

  I had to think back about what I was trying to accomplish when I created this thing...

  Background: When I was developing this originally, I was using HyperTerminal on a laptop as the interface.  This let me write BASIC programs and save them on the hard drive of the laptop and then load them into the Toy BASIC Computer before the flash memory was implemented.  But the Toy BASIC Computer couldn't keep up with the input from the laptop.  This is the result of the compilation process that takes place when you hit Return after entering a line of code.  To save RAM (of which there is very little on the PIC processor) and improve runtime speed, keywords are converted to a byte code and stored in memory that way.  Anyway, this resulted in my having to implement some form of flow control on the inbound side.  I didn't bother with the outbound side.

  Of course, I had forgotten all this when I was configuring the Cadetwriter.  I remembered that I had implemented hardware flow control, so told it to use RTS/CTS flow control.  And it didn't work.  Until we disabled flow control, then everything was happy :)  Oh, and I also found out there are actually two kind of hardware flow control (apparently the standard was changed somewhere along the line), both of which the Cadetwriter implements.  RTS/CTS is the original, now obsolete standard while RTR/CTS is what is in use today.  So it's possible that if I had selected RTR/CTS instead of RTS/CTS when I configured the Cadetwriter it would have worked...

  "The nice thing about standards is that you have so many to choose from." - Andrew Tannenbaum

  
  

  
  

• Demonstration Video

  Steve Toner • 06/21/2017 at 15:55 • 0 comments

  Here's a demonstration video :)

• The Prototype

  Steve Toner • 06/20/2017 at 03:08 • 0 comments

  btw, here are photos of the prototype. It easily fits on a Busboard BR1. The only part that is not available as a thru-hole part is the flash memory chip, which needs an adapter. So if you want to build one but are put off by having to make a PCB for it, this is the simple solution (provided you can read a schematic and know how to solder).

  Wiring is done with wire-wrapping wire. I have some pre-cut lengths that I bought as a package around 1980 (!) - still haven't used them all up. But you can just get a spool and cut them to custom lengths...

  The two empty sockets are for testing the DAC as an audio output. It's easy to generate triangle waves. Passed through a low-pass filter, they don't sound horrible.

View all 3 project logs