DTR is also used to tell TS-DOS when it's ok to talk, but you can get
away without it by just shorting it in the connector. Well, in the case
of using the serial port. Not sure what you'd do inside the M100 that
would allow you to assert it when you're using the uart and not when you
go hands-off to let the serial port have it.
Basically, TS-DOS looks at it, and it's better, safer for your ram
contents, if it's being set correctly so that the TS-DOS does not try to
read or write when the tpdd is not going to actually respond properly.
But it's not super harmful, it usually just hangs ts-dos, and usually
you can break out without a hard reset or a crash where you lose ram.
And that's just if you go in to ts-dos and try to make it read the
directory or read or write a file while there is no actual tpdd
responding. It's pretty easy to just "don't do that".
But with the lines hooked up and the firmware asserting them right, it's
a safer more user-friendly experience with fewer unpleasant surprises.
It's not used for normal flow control, just graceful "drive-not-ready".
In the other direction, asserting to the tpdd, it's only used to detect
the bootstrap conditions. Actually I don't remember, once I had the pins
wired up and working maybe I did also add graceful "host-not-ready" just
for the heck of it, but it wouldn't actually matter. Even if it's in
there, you can ignore it. The drive never initiates anything so there is
really almost no need for the drive to check if the host is ready. The
drive just spins waiting for commands and reacts to them. If you get a
command, you are pretty much always ok to go ahead and perform that
command. If someone yanks a cable out in the middle of some action, they
already expect that transaction to be junk.
Put it this way, for quite a while the first versions didn't even have
any dsr or dtr at all. Just shorted in the connector to pacify ts-dos
and nothing on the arduino side at all.
But a real tpdd has it, and TS-DOS (and I think the official FLOPPY that
came with the drive) use it.
--
bkw
On 12/19/20 10:31 PM, Scott McDonnell wrote:
I’ve used these before in other projects and they worked great. One use
was to replace a serial printer on one of our very old test stations at
work. I was going to make my own boards to do it and then stumbled on
this. Cheaper than the parts I would have had to buy. That’s why when I
seen PDDuino, I thought about these.
My plan is to install inside the M100, however I won’t totally get away
without additional hardware. I would probably add a buffer so that the
serial port can still be used. I would need a level shifter (from 5V and
3.3V) anyway, which is basically a buffer. That should also protect the
M100 from any nonsense the Arduino might cause.
I had not considered the DTR signal, but you do actually have more I/O.
You could use the MOSI or MISO pins at startup. It would do nothing to
the SD card because it wouldn’t be chip-selected yet. Or, it is a bit of
a hack, but you could tap into one of the two LEDs since it would be
inside the M100 and you wouldn’t see the LEDs anyway. And of course, you
could break one of the two ground pins and jumper to any other IO pin on
the ATMega chip and bring it to that pin.
I haven’t studied the code in detail yet, but do you need the DTS/DTR
signal for the initial bootstrap process only?
Scott M.
*From: *Brian K. White <mailto:b.kenyo...@gmail.com>
*Sent: *Saturday, December 19, 2020 10:12 PM
*To: *m...@bitchin100.com <mailto:m...@bitchin100.com>
*Subject: *Re: [M100] Model 100 Repair - Keyboard not responding,LCD
missing a column
I started to try that too a while back, but I think I might have gotten
some bad units. I only barely got them to work even just with basic
hello-world code or using the pre-installed serial-logging firmware.
Maybe I killed the i/o with 5v?
One problem with these is you still need to add a rs232 level-shifter,
unless you're talking about wiring up directly to the uart, but then
it's a very different kind of project, not a plug & play
damage-free-towing kind of thing any more. Then again, arduino dev
boards need that too, which is what MounT is.
Then there is the bootstrap, you'd need to come up with some other way
to trigger the bootstrap, or just not have that. There's no other io
lines available to use as dsr/dtr.
Probably the simplest is just have the tpdd server code recognize a
special command that could be sent more or less any time, with no
special power up sequence of events and setting up of conditions. The
downside is it makes the BASIC code you have to manually enter a bit longer.
dlplus originally had something like that, except do something a bit
better than exactly what dlplus did, like instead of "XX means do
bootstrap" more like "XX means alternate commands prefix" and the
command to invoke bootstrap would be XX-something- just like how all
TPDD commands are ZZ-something-
(I think the original subdirectory extensions made by TS-DOS should have
been done that way too instead of using ZZ-previously-unused-number.
ZZ-everything- should have been considered off limits and owned by
someone else.)
I think mComm has something like the original dlplus mechanism too.
I do think the microcontroller is up to the task. It's normal
off-the-shelf job is already to do exactly the same work,
rs232<->sdcard. TPDD is nothing else unless you count the packet checksums.
--
bkw
>
https://www.amazon.com/gp/product/B07T6HBMTZ/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
>
<https://www.amazon.com/gp/product/B07T6HBMTZ/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1>
>
> Looks fairly straight-forward so far.
>
> Looks small enough that one could mount right inside the M100 in the
> option ROM area. There is also a bit of room just above the barcode
> reader port. It may fit there, exposing the microSD card.
--
bkw
--
bkw
