Brian,
Excellent. What a great and clear explanation. As a result, I went and I
got starblaze-100 running on the system - never, ever, ever thought I'd
see that again. Dang, that big alien's hard to kill. Great, fun!
Regards,
Will
On 9/30/22 11:03 PM, Brian K. White wrote:
On 9/30/22 17:24, Will Senn wrote:
Brian et al.,
Interestingly, I can save a memory file from the TRS-80 M100 out to
my mac, running dl, but I can't seem to load:
on m100 in BASIC:
10 CLS
SAVE "TEST.DO",A
F8
Run TEENY.CO (after doing some HIMEM shenanigans)
> C FFFFFF.XX (C=KLSQ)
> S TEST.DO
> C FFFFFF.XX (C=KLSQ)
on mac:
cat TEST.DO
10 CLS
cp TEST.DO TEST2.DO
for a file to upload and after messing around for a bit, turned on
verbose in dl:
dl -v /dev/cu.usbserial-FD310
DeskLink+ v2.0.000-6-g6065601
Serial Device: /dev/cu.usbserial-FD310
Working Dir : /Users/wsenn/t
Opening "/dev/cu.usbserial-FD310" ... OK
-------------------------------------------------------------------------------
"TEST .DO" TEST.DO
"TEST2 .DO" TEST2.DO
-------------------------------------------------------------------------------
on m100, reentered TEENY.CO
> C FFFFFF.XX (C=KLSQ)
> L TEST2.DO
FF Err
This is one of the many ways teeny is teeny at the expense of
user-friendly and forgiving.
The "FFFFFF.XX" in the prompt is there to remind you of the file
pattern. You have to fill all spaces, space-pad any names that are
shorter than 6 characters.
So to load the file is
L TEST2 .DO
one space after the 2
This is a limitation of teeny.
Feel free to skip the rest of this, but here's why that is...
It's kind of a long story what's going on and why.
A real TPDD (re-badged Brother FB-100) drive is very simple and has a
24 byte field for the filename on the disk, and it doesn't care what's
in that field at all other than null in the first byte means no file.
But other than that anything goes, even nulls in other positions than
the first byte, the field isn't even null-terminated, it's 24 bytes
and any bytes at all.
The Tandy version of the drive shipped with a tpdd client called
"floppy" on a disk with the drive, and THAT program, when it saves
files to disk, the actual bytes written to the disk are fixed-length
6.2. "TEST.DO" gets written to disk as "TEST" 2 spaces ".DO" 15
spaces. This is not something you can normally see directly. Normally
you only see what some tpdd client chooses to show you. Most of them
display filenames the same way as the M100 main menu. But with
github.com/bkw777/pdd.sh (and a real drive) you can see the real
on-disk filenames.
Since any other tpdd clients that came later need to be compatible
with Floppy, teeny and ts-dos and everything else also writes
filenames to disk like that.
And because of that, they all also expect to find them like that when
they read disks too.
That means that all disks have filenames like that, and all tpdd
clients expect them, and because all clients expect them, drive
emulators have to fake them.
So dlplus collapses the spaces when it gets a filename from a client,
and inserts the spaces when it gives a filename to a client, so the
filename on your pc is more convenient "TEST.DO" but it says "TEST
.DO" to the client.
For most clients, you never know that this convert-unconvert is
happening behind the scenes for every filename. Both the clients and
the servers are doing something sort of pointless, but they are
matched up and both doing the same thing and so you never see that
behind the scenes your filename was converted at each end of the
transaction and was actually a different name while in flight. You
saved TEST.DO, and you got TEST.DO back out, and you never knew it was
TEST .DO while stored.
And finally the last bit is that in the case of teeny, it's so minimal
that it doesn't do the kind of reformatting for user convenience that
ts-dos and everything else does. Teeny just takes whatever you enter,
and plugs that in to the tpdd protocol command it sends to the drive
verbatim. And that means, since the filename on the "disk" is actually
"TEST space space .DO"(*) you have to type that into teeny.
I keep saying "it's TEST .OD on-disk" but really that's just on a
real disk. On YOUR disk, it actually is "TEST.DO" because dlplus is
converting back again on the fly.
I did warn you you could skip that ;)
Help :)
Will
On 9/30/22 3:32 PM, Will Senn wrote:
Progress! I changed usb ports and ran:
dl -vb TEENY.100 /dev/cu.usbserial-FD310
then on m100:
RUN "COM:98N1ENN"
to which it apparently sent, cuz eventually, m100 displayed:
12 Seconds...
(ENTER for just below HIMEM)
End Address for TEENY.CO
Loaded TEENY.CO
OK
Yay. Meanwhile back on the mac:
"dl -b" will now exit.
Re-run "dl" (without -b this time) to run the TPDD server.
(base) nebula:~ wsenn$ dl /dev/cu.usbserial-FD310
DeskLink+ v2.0.000-6-g6065601
Serial Device: /dev/cu.usbserial-FD310
Working Dir : /Users/wsenn
Opening "/dev/cu.usbserial-FD310" ... OK
More Yay. Now what? Off to figuring out how to actually use the
newfangled setup to send / receive files :). BTW, don't set POWER
off to 2 minutes when you're trying new stuff - really annoying!
Will
On 9/30/22 3:13 PM, Will Senn wrote:
Brian et al.,
I got the cable and plugged it into my serial usb adapter. I then:
git clone https://github.com/bkw777/dlplus.git
cd dlplus/
make clean all && sudo make install
no errors, so I ran it and figured out how to tweak:
dl -bTEENY.100 /dev/cu.usbserial-3A20
it told me what to type on the m100, so i did and after pressing
enter, the m100 said:
?DS ERROR
On the dl side, it merrily went on its way without complaint.
Thoughts as to what the problem might be or how to troubleshoot?
I'm pulling out my linux laptop and dusting off a windows laptop
just in case that helps...
Thanks,
Will
On 9/27/22 3:31 PM, Brian K. White wrote:
On 9/27/22 14:48, Will Senn wrote:
Hi Brian,
Thanks for the details, it'll take me a while to work through this,
Things have been figured out and added to by by countless people
for 40 years, so by now there is just a lot of answer for every
question.
but
it sounds believable and achievable. I have purchased one of the
ideal cables you mention. If I understand correctly, the ideal
cable should work fine hooked up between my dell and the m100
because the dell has a db-9 serial port. My mac on the other hand
doesn't so I require a USB-Serial adapter to make like the Mac
has a DB-9 serial port? Then, I should be able to start talking
to the m100 via the ideal cable and USB-Serial connector plus any
gender changer needed between cable and USB-Serial adapter, right?
No gender changer needed, because that is one of the items that
defines "ideal" in this case. The M100 has a
mostly-normal-but-one-thing-backwards serial port, and the one
backwards thing is the connector is female. So, it's an uncommon
combination to have a 9-25 null-modem cable with a male db25, but
they are made and so it's just a matter of hunting down specific
models.
Almost any pc that has a 9-pin com port conforms to a standard
that eventually became standard. Exceptions are very exceptional,
like the Cambridge Z88. Anything else can be counted on.
usb-serial adapters come in both male & female, and you can find
special units with weird wiring, but generally any usb-serial
adapter with a male plug is designed to essentially take the place
of the legacy com ports built into old motherboards.
So, you can consider the 9-pin side the same whether it's a pc
with real com ports of a usb adapter. The only detail left to
consider is a less-important one of the screws vs nuts. By rights
any male 9-pin should have nuts and the cable should have screws,
but on this detail a lot of usb adapters are pretty random. So if
you wanty everything nice you have to actually check the pictures
and make sure the adapter you're looking at has nuts or screws. On
that wiki page I listed some choice usb adapters with everything
ideal.
So yes the same serial cable works the same way either to an older
pc with a real com port or a newer pc that needs a usb adapter,
which is again one of the things that defines "ideal" to me.
There are actually bespoke cables you can buy that are usb on one
end and db25 male DCE on the other end which would go right from a
pc to a m100 in one piece, but that cable would be so non-standard
that it's no good for anything else. I prefer keeping the usb part
separate, and bog standard, so it can be replaced later with any
other, used for other things, etc, and the serial cable likewise,
even though it is a little bit special, at least it can be used
equally with a usb adapter or directly to a pc that doesn't need a
usb adapter.
If you want to add a 3rd piece, you can get even more bog-standard
by using an ordinary modem cable, which has the right plugs on
both ends but just isn't null-modem wired inside. You can add the
null-modem part in the form of a little 9-pin mini-null-modem.
They are no longer as dirt common as they used to be, but you can
still get them. The advantage to this idea is a 9-25 modem cable
is hands down the most common ubiquitous kind of cable. Not
special at all. This places the extra part in the middle of the
cable instead of hanging off the back of the 100, and is
physically pretty small. If you're not using a usb adapter then it
IS hanging off the back of the pc, but at least it's small and
doesn't cause too much stick-out leverage from something hanging
off the port. It's just a little harder finding one that's
male-female instead of male-male or female-female. But they exist
and I think I have link for that arrangement on that page too in
the initial description at the top.
As for the TPDD stuff, once I get the cables sorted out, I will
work on bootstrapping and getting the client on the M100 and a
server for my mac.
You'll use the same serial connection for anything/everything
regardless of tpdd, so at least you know you're not wasting any
time/effort.
