Awesome Jim! I can't wait until mine gets here
________________________________
From: M100 <m100-boun...@lists.bitchin100.com> on behalf of Jim Anderson
<jim.ander...@kpu.ca>
Sent: Friday, October 16, 2020 12:00 PM
To: m...@bitchin100.com <m...@bitchin100.com>
Subject: [M100] having fun with MVT100
On a more uplifting note, I received my MVT100 in the mail last week and I've
been having a blast with it! I thought I'd share a few things which others
might find helpful:
I added the jumper for the BCR TTL serial hack to the machine I've been using
for my REXCPM (the old SOD hack, because I'm unlikely to go the Z80 route and
didn't want to be bothered patching things). While I was in there I also ran a
jumper to supply VDD (which I picked off from a nearby via which supplies pin 9
in the BCR port) to pin 22 on the RS-232 port - this is the Ring Indicate
signal from a modem and isn't connected to anything in the M100, but more
importantly, it maps to pin 9 when you use a DE-9 adapter. I was inspired by
Stephen's post about adding a jumper to the MVT100 to power it off pin 9 (which
I have also done) and which reminded me that my old Bluetooth serial adapter
also is capable of drawing power from pin 9. This way, I can run the MVT100
off either the BCR or the RS-232 port and it'll receive power.
If there's a future need to revise the MVT100 board design, it might be useful
to add a trace and a jumper to allow the user to easily enable/disable power
draw from pin 9 - the way it is now, I'm not sure whether Bad Things would
happen if I tried using the board as a USB serial adapter while it was
connected to my M100, since that would common the M100's VDD with the USB power
supplied by the PC...
A note on screen resolutions: I had not even thought about this until I got it
and started playing around with it, but the text font the MVT100 uses can look
absolutely hideous when it's being scaled poorly by an LCD monitor. This isn't
specifically an MVT100 issue - LCD monitors often wreak havoc on text when they
are scaling from a non-native resolution, and it's something I'd just forgotten
about because it's been so long since I had to drive an LCD at its non-native
resolution. My original plan for my MVT100 was to use it with an older NEC 15"
LCD I had which is native 1024x768 - too low to be useful for a PC, but I
thought the compact size and 4:3 aspect ratio would make it a perfect terminal
display. Alas, it's actually almost the worst thing to use, because the MVT100
output is 640x480 and that means there aren't enough pixels to do an acceptable
job of scaling, giving characters that alternate from skinny to fat as you read
down a line of text...
I also tried with a 1280x1024 LCD on the theory that I might be able to tweak
the pixel clock settings in the monitor and get it to map at least the
horizontal pixels 2:1 but this monitor doesn't let you tweak very much (it
mostly relies on the auto-adjust routine). I got it looking better than the
small LCD but I still wasn't very happy with it (and it still didn't look as
good as sending it into a bit 1920x1080 LCD).
Of course, it looks the best by a long shot when you send it into a good old
VGA CRT, which arguably is the most retro-looking solution of all, and lucky
for me I never did throw away that little paper-white monochrome VGA monitor I
got back in the 90s (yes, I said monochrome VGA!). It's kind of perfect for
this - it doesn't even pretend to represent all colours, it only uses the green
signal (which is all the MVT100 is jumpered to output as I received it) so it
all works out almost as if it was meant to!
One other thing: I don't know what is limiting the display output speed, but
when I started using the BCR at 57600bps I was expecting the display to update
faster and it seems like it actually is the exact same speed as it was on the
serial port at 19200bps. From past experience using dumb terminals I had been
feeling like even the 19200 output was displaying a bit slower than it could
(it felt like 9600) and I'm wondering if this is just a result of the processor
having to take turns between executing program instructions and bit-banging
each output byte. Please don't take this as a complaint about it being slow -
the speed is fully in keeping with my expectations for the platform, and it's
lightning-fast compared with the internal LCD :) I just wonder what is limiting
it because I know the M100 is capable of faster data transfer... (speaking of
which, I'm still dying to have access to the high-speed large-packet data
transfer capability for backing up and restoring REXCPM)
Anyway, it all works great and I couldn't be happier with this solution! Many
thanks to Stephen for sharing your genius ideas with us!
jim
