Re: [M100] tranch #2 of REXCPM is off the docks!
Greg,
I just finished writing this up, there are likely typos but I wanted to get
it to you before I get sidetracked again. Things are very busy around
here. E-mail me if you have any questions. I will try and improve them this
week.
Linux instructions (rough draft)
-
Minicom is the "standard" in Linux terminal programs. You need a program
that will alllow for the binary transfer of data without a transfer
protocol. Minicom can be configured for thie. To configure Minicom,
install it with apt get minicom and you will also need PV, so install it
also. TO actually configure Minicom for binary transfers you need to create
a small script sendbin.sh:
-
#!/bin/sh
INFILE=/dev/null
OUTFILE=/dev/null
while [ $# -gt 0 ]; do
case "$1" in
-i)
shift
INFILE="$1"
;;
-o)
shift
OUTFILE="$1"
;;
-h|--help)
echo "$0 -i infile -o outfile"
;;
*)
INFILE="$1"
esac
shift
done
cat << EOF
binary-xfer utility for minicom
Sending file ${INFILE} to ${OUTFILE}
EOF
/usr/bin/pv --force -i 0.25 -B 128 ${INFILE} 2>&1 > ${OUTFILE}
# Use the line below if you don't have pv!
# /bin/cat ${INFILE} > ${OUTFILE}
cat << EOF
File transfer complete
EOF
sleep 10
-
Open Minicon and user -A, O to open the options menu. From there
select "File Transfer Protcols", we are going to all a new selection.
Slots A through I are used so select J and enter the following values
bin/home/kimberley/scripts/sendbin.sh -o %l YUY N
N
This will create a new protocol for transferring data directly, while
passing binary values without change.
Use this new option to send your file. Connect using Telecom and press F2
for Download, enter the filename "rxcini.do" and press -A, S to send
a file in Minicom. Select the protocol, the new one, "bin", that was just
added. User the left/right arrow keys and "Enter" to select "Goto" in
Minicom and enter the directory to which you unzipped "rxcini.DO" to. Used
the same keys to select "show" to filter the files, enter "rxcini.DO" Use
the up/down arrow to move the pointer to the file and then the left/right
arrows to select "tag" to actually select the file to send. Finally, press
"enter" to actually send the file. When the transfer is complete, press
"F2" on the M100/T102 again to stop the transfer.
RXCINI.DO loads a file from the TPDD or emulator. Under Linux the best
option is Laddie Alpha under Mono. You need to install Mono and download
Laddie Alphe. Laddie Alpha can be downloaded from the Bitchin100 site at
http://bitchin100.com/wiki/index.php?title=LaddieCon#LaddieAlpha . Now you
need to install Mono, Debian based systems run "sudo apt install
mono-complete". You also need the file RXC_11.zip. Make a directory and
unzip RXC_11.zip into the directory. Change directories to the new
directory and run "mono LaddieAlpha.exe /dev/ttyUSB0", replacing ttyUSB0
with the device you are using. Now follow the instructions to running
RXCINI.DO in the official documentation.
Classic REX functionality should now be working.
You can put Option ROM images into the same directory and use Laddie Alpha
to load these onto the REX also.
Grab the CP/M initialization files and the image for your sized REXCPM and
place these in the same directory.
Install the TS-DOS option ROM to copy the CPM.CO and CPMUPD.CO files to the
M100/T102 from Laddie Alpha. These are the files to install the CP/M
functionality. Leave the *.BK file in the directory, CPMUPD.CO will
transfer this to the REX.
Follow the instructions for CP/M on the M100/T102 found here:
http://bitchin100.com/wiki/index.php?title=M100_CP/M
-
--Jim
On Thu, Jul 23, 2020 at 10:54 PM Greg Swallow wrote:
> Jim,
>
> I could use your Linux help/step-by/information. Just converted my last
> Windows PC to elementaryOS. Am also running openSuse Tumbleweed, but am
> consolidating to one/two system(s).
>
> Dropped an PCI 2-port RS232 in and am working on getting it working for
> the M100.
>
> Thanks,
>
> GregS <><
>
> Jul 23, 2020 7:32:22 PM Jim Hart :
>
> > I received mine yesterday, and after some trouble getting it initialized
> (all on the Linux host), it is working great. If anyone is having trouble
> with installing the software from Linux, let me know and I can offer my
> solutions.
> >
> > I have the basic REX functionality and the CPM both working in the
> REXCPM.
> >
> > Thanks again Stephen for a great device.
> >
> > --Jim
> >
> > On Thu, Jul 23, 2020 at 8:30 PM Kevin Slater
> wrote:
> >
> >> I also want to let you know I received my as well. I was on vacation so
> didn't get held mail until Wednesday. Looks great, haven't installed it yet
> but will get to it soon as I'm looking forward to it!
> >>
> >> Kevin
> >>
> >>> On 07/22/2020 8:51 PM Stephen Adolph wrote:
> >>>
> >>> Great stuff Brian. Glad it arrived and is working for you. REXCPM
>
Re: [M100] Listserv Search
ALERT: Beginner asking question. Reminder: Upon hard reset the LCD initializes perfectly and displays the main Menu screen perfectly. However, once in BASIC or TEXT the bottom four lines do not display correctly. (See attached.) (Planned to test LCD in M102 but it has a different connector. I don't have a second M100 right now to test it in, but I am 99.99% positive the LCD is fine) So I purchased a logic prob (Elenco LP-900) to test chip select lines on the LCD connector (Pins 14, 12, 10, 8, 7, 16,15,13,11, 9, and CS1=Pin? - schematics blurry).As I unboxed it I remembered I never used one before. :) - Where do I place the pos and neg alligator clips? - Do I set the logic prob to 400PPS or 00.5PPS? - In checking the chip select lines, am I looking for HI, LO, or PULSE? I see no broken or corroded lines on the board. Thanks in advance. On Wednesday, July 22, 2020, 02:29:39 PM EDT, Jeffrey Birt wrote: This loss of an entire block is the symptom of a missing chip select. When the LCD driver chips are powered/reset they will drive every pixel on/black. When they receive the proper initialization, they will drive every pixel off/clear. It seems the rest and initialization steps are being done so commands are getting through (and the machine is booting so the LCD has to be initializing and responding). Each driver chip on the LCD controls one block of pixels. If an entire block is missing, it is a good sign the chip select is not getting through. It could be a bad trace on the M100, a bad LCD cable or a bad LCD itself. If you have a scope of logic probe you can check to see if all the chip select lines are toggling. Jeff BIrt From: M100 On Behalf Of Chris Fezzler Sent: Wednesday, July 22, 2020 11:26 AM To: m...@bitchin100.com Subject: Re: [M100] Listserv Search Here you go. On Wednesday, July 22, 2020, 11:52:23 AM EDT, Stephen Adolph wrote: a pic of the garbled screen would be great if you can do it.. thanks On Wed, Jul 22, 2020 at 11:37 AM Chris Fezzler wrote: Sorry - typing too fast. Top four lines of the screen. Yes, mostly garbage all of the time. Except a hard rest will generate a proper menu screen. Yes, in BASIC the same. But if I type in a test program and hit RUN the program will indeed run. So the computer is getting the commands/keystrokes. Just not displaying bottom four lines. I think it is a component issue. On Wednesday, July 22, 2020, 09:20:53 AM EDT, Stephen Adolph wrote: Hi Chris, What do you mean by "the top 4". Do you mean top 4 lines on the screen? I think so. So is it correct to say that the LCD bottom 4 lines display garbage at certain times * not after a (hard) reset - you get a correct MENU display (not just a RESET but a HARD RESET?) * when you enter BASIC and/or run any software, the LCD bottom half shows garbage? I would suggest that you run a memory test. I doubt that you have a fundamental problem with the LCD system, nor the keyboard system. good problem! On Wed, Jul 22, 2020 at 9:02 AM Chris Fezzler wrote: I'm trying to troubleshoot what components on the circuit board process keystrokes and send them to the screen. The screen and keyboard on my Model 100 are in perfect working order. But only the top four are processing correctly. The bottom four are displaying gibberish. But if I type commands in BASIC, they work. So again, not the keyboard or screen but components that process the bottom half. A hard rest will present a perfect menu screen. But upon entering an app, the bottom four lines are not getting proper signal. Sorry, I'm not an electronics or computer engineer. Just a hobbyist with a soldering iron and a willingness to learn. Plan to look at Technical Reference Manual to see if I can troubleshoot. On Wednesday, July 22, 2020, 01:15:25 AM EDT, John R. Hogerhuis wrote: On Tue, Jul 21, 2020 at 5:08 PM Chris Fezzler wrote: Is there a way to search old Listserv messages so I can research before embarrass...err...I mean ask a dumb question. Seriously, would like to research. How old are we talking? Gmane was our archive until it went down for a long time. Then it was back up recently but only accessible through nntp readers. Not sure the status of that. Our GNU Mailman list itself has an archive which goes back to 2011 when I took over running the list. http://lists.bitchin100.com/private.cgi/m100-bitchin100.com/ Or just ask. We Are The Archive. -- John.
Re: [M100] NDC800 conversion was Re: dual CPU project
Hi Stephen, A good challenge, indeed.. Not 100% certain I'm up for it but I'll give it a look! Send me those mods if you would. Probably the best approach would be to make the same optimization to the display code that you did for the M100. My prior attempts at clearing 200 bytes in the NEC's ROM in order to fit LINE() into NEC BASIC ultimately turned out to be a failure. But your display patch sounds encouraging. A full 170 bytes? That's huge. What the heck was Gates thinking when he coded this thing up. ;-) Gary On Fri, Jul 24, 2020 at 12:59 PM Stephen Adolph wrote: > > yah I think so. It is only slightly larger than the 40 pin socket. should > drop it place. > > I can share the mods I made to the M100 ROM. You might have a hard time to > get a working ROM for NEC. > The reason why is that, on the M100 ROM, I have a patch that creates a BIG > HOLE. I found an optimization in how the video code worked, and my patch > makes something like 170 bytes free in the ROM. > I use that hole to embed code to work around the various changes to back out > / change the calls that use SIM and RIM. > > (The M100 rom does not make use of the undocumented commands of the 8085. > > So it is a good challenge for you Gary- Modify the NEC ROM to work with > NSC800. > > ..Steve > > > On Fri, Jul 24, 2020 at 3:40 PM Gary Weber wrote: >> >> Great news! >> >> Question for you: I know the dual-CPU board doesn't physically fit >> into the socket space in the NEC machines, but would your single >> NSC800 adapter fit just fine? >> >> Gary >> >> On Thu, Jul 23, 2020 at 7:38 PM Stephen Adolph wrote: >> > >> > Update. >> > I have refined my NSC800 aka Z80 conversion for M100 somewhat. >> > >> > I now have a very simple adapter board that converts the 80c85 socket to >> > accept NSC800. Small and simple. Plug and play. >> > >> > The main rom needs to change to a patched version that I have. To do so, >> > you need to use one of the various means to convert the strange M100 main >> > rom socket to something more standard. >> > >> > Why? >> > >> > Well I am still pushing towards a nice Z80 solution for CP/M. >> > >> > Besides.. the solution is so clean it is really cool. Hard to resist! >> > The M100 could have easily been designed with this processor to begin with. >> > >> > So why not ;) >> > >> > My thinking is to offer this as a simple kit or maybe even just release >> > the board. The BOM is really small. Processor is easy to get off ebay. >> > >> > One thing that would be nice, is a new version of tsdos that avoids all >> > the special 80c85 opcodescompatible with 8080. Then it could run on >> > z80 as well. >> > >> > Even a patched teeny would be fine I suppose. >> > >> > >> > >> > >> > On Thursday, July 11, 2019, Stephen Adolph wrote: >> >> >> >> Motivated by 2 things >> >> 1) discovery of the NSC800 Z80 processor that is 80C85 like >> >> 2) continuing to work in the direcition of CP/M >> >> 3) and recalling that there are 5MHz 80C85 parts out there.. >> >> >> >> I started to work on a dual CPU card for M100 that enables a couple of >> >> things; >> >> - standard 2.5MHz 80C85 operation (default) >> >> - switchable clock for 80C85, supporting 5MHz >> >> - switchable CPU enabling NSC800 at 2.5 MHz. >> >> >> >> Board is done and heading to the fab. VHDL is mostly done. >> >> >> >> I don't expect this board will be wildly popular but maybe it has some >> >> interest Double speed M100 seems interesting on it's own, let alone >> >> being able to support Z80 CP/M applications. >> >> >> >> >> >> Any interest? >> >> >> >> I have purchased material to make 5 of these. >> >> >> >> A few more comments. >> >> - to install this board you need to remove the 80C85. that's some effort >> >> to do >> >> - to run at 5MHz you need to upgrade the 81C55 to a 5MHz version. That's >> >> also some effort. >> >> - NSC800 runs about 5$ on ebay. >> >> - fast 80C85 can be had for under 5$. >> >> - fast 81C55 can be had for under 5$. >> >> - to run at 5MHz you might also find you need a faster main ROM, and >> >> faster RAM. TBD on that; will advise after I do some testing. >> >> >> >> >> >>
