Re: [M100] Serial over Console in CP/M

[Philip Avery]

Yes, 19200 (98N1D) as stated in 'Initialising RS-232" 
http://bitchin100.com/wiki/index.php?title=M100_CP/M


however, maybe one can initialise in TELCOM to a different baud rate...

Philip

On 21/03/2024 3:26 pm, Will Senn wrote:

What is the default baud rate? Are the other settings - 8n1?

On 3/20/24 20:53, Philip Avery wrote:
Yes, the IO byte is fully implemented in M100 CP/M. Use 'stat 
con:=uc1:'for serial port input. Currently no way of altering baud 
rate, on the to-do list.


Search out this old thread:
[M100] Re-directing CP/M console to serial port in REXCPM

Philip

On 21/03/2024 12:02 pm, Will Senn wrote:
over on Vcf, I asked about whether serial over console was possible 
and they said:



CP/M is basically indifferent about the details of the console,
that being contained within the BIOS created by the vendor for
the platform you're running on. I'm not familiar with the M100
platform, but if it has a serial port, *AND* the vendor
implemented CP/M "I/O redirection" in their BIOS, then you can
use STAT to re-assign the console to a serial port. You have to
determine which of the devices is the serial port, but then
you'd issue a command like "STAT CON:=TTY:" after which you
should see the "A>" prompt on the serial port. Note that if you
reassign the console to the wrong device, you won't be able to
issue the command to return to the original console device (e.g.
"STAT CON:=CRT:"), and will probably have to RESET and reboot.
Read up on the STAT command, as it can show you the available
device assignments, current assignments, etc.

Which kinda makes sense, but what is the serial port called? CON is 
already TTY, so that's not it. Also, how do I set the baud rate and 
suchlike in CP/M... anyway, " it has a serial port, *AND* the vendor 
implemented CP/M "I/O redirection" in their BIOS"... does anyone 
know if this is the case?


Thanks,

Will

Re: [M100] Serial over Console in CP/M

[Philip Avery]

Yes, the IO byte is fully implemented in M100 CP/M. Use 'stat 
con:=uc1:'for serial port input. Currently no way of altering baud rate, 
on the to-do list.


Search out this old thread:
[M100] Re-directing CP/M console to serial port in REXCPM

Philip

On 21/03/2024 12:02 pm, Will Senn wrote:
over on Vcf, I asked about whether serial over console was possible 
and they said:



CP/M is basically indifferent about the details of the console,
that being contained within the BIOS created by the vendor for the
platform you're running on. I'm not familiar with the M100
platform, but if it has a serial port, *AND* the vendor
implemented CP/M "I/O redirection" in their BIOS, then you can use
STAT to re-assign the console to a serial port. You have to
determine which of the devices is the serial port, but then you'd
issue a command like "STAT CON:=TTY:" after which you should see
the "A>" prompt on the serial port. Note that if you reassign the
console to the wrong device, you won't be able to issue the
command to return to the original console device (e.g. "STAT
CON:=CRT:"), and will probably have to RESET and reboot. Read up
on the STAT command, as it can show you the available device
assignments, current assignments, etc.

Which kinda makes sense, but what is the serial port called? CON is 
already TTY, so that's not it. Also, how do I set the baud rate and 
suchlike in CP/M... anyway, " it has a serial port, *AND* the vendor 
implemented CP/M "I/O redirection" in their BIOS"... does anyone know 
if this is the case?


Thanks,

Will

Re: [M100] CP/M and stuff like the LCD screen

[Philip Avery]

Will

As writer of M100 CP/M I can say there currently isn't any user-friendly 
way of calling M100 ROM routines from CP/M. However Steve may have 
discovered a sneaky access in the BIOS with his extensive experience of 
hacking about with the M100.


It's on my to-do list, along with other improvements, so I vow to get on 
to this when our winter arrives, which in New Zealand is June.


Glad you're finding M100 CP/M useful

Philip Avery

On 18/03/2024 6:50 pm, Stephen Adolph wrote:

Will,
The M100 main rom supports CP/M, i suppose that is obvious.
Cpm memory space is totally separate from the M100 memory. Both the 
upper and lower 33k banks are RAM for cpm.  In m100 mode, you have the 
standard main rom in the lower 32k, and different ram in the upper 32k.


To get full control of the m100 in cpm you need to access the main rom 
routines.  Well, you could rewrite all the routines but why when the 
main rom is there.  ;)



As John mentioned since the main rom isn't directly available in cpm 
you need trampoline code to switch it into view so you can call routines.


I'm not near all my info so I can't recall the exact details but 
certainly there is a trampoline included in m100 cpm.



So the trick is to call the trampoline with a pointer to your target 
routine, along with register data to feed the routine.


If I can figure out the trampoline I will send a note.

Steve

On Sunday, March 17, 2024, Will Senn  wrote:

Hi All,

I've been digging into assembly language programming on the M100
and the documentation is fragmented, to say the least and so
progress is stilted a bit. I've made significant progress on the
programming toolchain - CP/M is great for this. It gives a
rational file system, ed, asm, load, ddt, a way to run the app, a
way to display the source, listings, etc. VEDIT is available as a
visual editor, but editing on a host and running on CP/M is
workable and fast. I've also gotten MAC, RMAC, and LINK working
which is nice.

CP/M provides functions that are callable in assembly code and
I've made good progress on how to make CP/M work for simple I/O
and File I/O. But, the M100 has features, like the LCD, the serial
and parallel ports, etc. that make it unique. Is the assembly
language CP/M programmer left on their own to interface with these
devices or are they given access to something akin to BIOS (maybe
the ROM functions) to make it easier?

Say that I want to place a pixel, or draw a line, or whatnot. Does
CP/M have any machine level routines to call, or what? Can I call
the ROM routines from CP/M? I saw some trampoline code on the
wiki, some language saying that it was tricky to do, a pointer to
some old docs, etc. Is that the way forward - call the main rom
from CP/M as described in

https://bitchin100.com/wiki/index.php?title=Calling_the_Main_ROM_from_Option_ROM

<https://bitchin100.com/wiki/index.php?title=Calling_the_Main_ROM_from_Option_ROM>,
or, is it a matter of programming the ports?

On the one hand, my questions are simple - how do I put a pixel on
the screen at a give location and erase it when I want to? With
minimal fuss. On the other hand, I'm curious about how CP/M and
the M100 coexist and what overlap exists between the two when CP/M
is active.

Thanks,

Will

Re: [M100] Text Sweeper 2.7.3

[Philip Avery]

Hi George

Regarding VT issues on W10: Sometimes I've got VT in a pickle and have 
to delete the Roaming file to reset it.


Delete: Windows (C:)/Users/(name)/AppData/Roaming virtualt

Regards
Philip


On 25/11/2023 8:42 am, grima...@gmail.com wrote:

Hi all,

Happy Thanksgiving to all those who may be located in the US and 
celebrated!


I just wanted to share that since last year, I have done a bit more 
work on Text Sweeper (Model 100 Minesweeper Clone), and have published 
a new release to GitHub.


https://github.com/Grimakis/TextSweeper/releases/tag/2.7.3

I have added a few changes since I last posted to the list, but the 
major ones are:
1. Using an ML subroutine to switch between the game screen and help 
screen. (way faster than the prior version)
2. Requiring less memory to run(approx 1KB less), by using ALTLCD as 
my stack space for the search algorithm, switching to LIFO, and 
changing the XY coordinate data structure from 4 bytes to 2 bytes.


As a reminder, the game is compatible with the M100, T102, T200, and 
the DVI in both 40 and 80 col mode.


-George

P.S. Has anyone had issues with Virtual T on Windows 10? the Memory 
Viewer window no longer appears for me. It's made a little harder to 
debug whilst coding. If anyone has any ideas, let me know.

Re: [M100] Switchable clock doubler schematic

[Philip Avery]

Phew, ChatGPT - sounds like a challenge! Well, with REXCPM offering 4MB 
of RAM...  we could have 4MB of optimized 8085 code! Would that do it :-)


In all seriousness Steve, no nothing specifically in mind, just 
interested. I guess the std keyboard polling & auto-repeat speed on M100 
is quite leisurely, so double speed wouldn't be too fast.


Philip

On 15/05/2023 3:39 pm, Kenneth Pettit wrote:

On 5/14/23 6:09 PM, Stephen Adolph wrote:

Hi Philip,
It does work with both REX flavors, yes.
Yes the keyboard is polled more frequently, but I have not seen a 
problem with that.  Did you have something in mind?


Probably ChatGPT on the M100 or something.  :-)

Ken

Re: [M100] Switchable clock doubler schematic

[Philip Avery]

Sounds great Steve. Will it work fine with Rex # & REXCPM? Also, the 
keyboard would be accessed faster would it not? Does that cause a problem?


Philip

On 14/05/2023 1:51 am, Stephen Adolph wrote:
I continue to hack away at making an easy to install clock doubler 
board for Model T computers. I realize that modifying hardware is not 
of interest to most, but I spend a lot of time on it myself.


The point of the activity is to allow the user to switch from nominal 
2.5MHz operation to 2x or 5MHz operation using a BASIC command.  In 
M100/T102/NEC/M10/KC-85, all these variants have a very slow screen 
response time, and so doubling the clock rate makes the machine more 
responsive.  Tandy 200 isn't as slow, but it is still nice to run fast.


5MHz operation is way outside of specifications, true. None of the 
parts in an M100 say they can run that fast.  So far though, I have 
been making extensive use of it and have had no problems.  The only 
issues that show up are when there is a timing loop in software that 
does not like being sped up.  In situations like that, the user can 
downgrade to 2.5MHz mode.  I think switchability is a must for this 
reason.


So far I have successfully upgraded
Model 100 (several!  both older and newer)
Tandy 102 (a few)
Tandy 200 (one)

Generally, when speeding up, the computer needs to run both the main 
ROM and the system RAM at 2x speed, and the power increases a bit.


Main ROM speed:
I have found that in the M100, for early production models, one needs 
to replace the main ROM for a faster one.  Some later production use 
ROMs that are already fast enough.  Tandy 102 and 200 ROMs seem fast 
enough.


RAM speed:
When the computer uses RAM that is 250nsec rated, these are often too 
slow.  This can occur in M100, T102 and T200.  In T200, I have no work 
around.  The T200 needs 200nsec or faster RAM.  In M100/T102, I have a 
work around that involves a simple cut/strap.


Power:
Consumption generally increases.  For M100, with a nominal current of 
56mA for the stock computer, a modified computer in 2.5MHz mode will 
see an increase to about 60mA.  This is the "tax" paid for speed up 
capability.  When operating in 5MHz mode, the current jumps to about 
75mA or so.


I'm attaching my current schematic for anyone interested in how the 
little board is designed.  The board mounts on top of the 80C85, and 
steals the signals it needs directly from the CPU.  There are 5 key 
circuits.


1) oscillator:  generates 9.8304MHz

2) clock divider:  generates 2.45MHz for the computer system 
components.  Replaces the CLK output of the CPU, so that the 
downstream elements always run based on 2.45MHz.


3) State:  a circuit that captures the user command to operate in 
either 1x or 2x clock speed.  User command is OUT 85, 0 or OUT 85, 1.  
(80"85").  In T200, the real time clock RP5C01 is too slow for 5MHz 
operation, so the CL input is the chip select line for that part.  The 
CL input forces the clock to 2.5MHz whenever the RC5C01 is accessed.


4) Clock select:  This circuit uses 2 flip flops to generate either 
9.8MHz or 4.9MHz depending on state.  This circuit feeds clock to the 
80C85.  The original on-board crystal can be overdriven, no problem.


5) Astar signal:  In M100/T102 (and likely M10 and  8201) the A* 
signal is used to gate the SRAM chip selects.  What this signal does 
is it limits the "on" time of the SRAM, to limit power consumption. I 
was previously unaware of this trick.   In 2x mode, the stock A* 
signal limits the access cycle time to the SRAM, and only fast SRAM 
(200nsec or less) can tolerate this.  The solution for older machines 
with slower SRAM is to trigger A* earlier.  This circuit generates 
"early A*" to resolve this problem.


This implementation is now current and is being used in M100, T102 and 
T200.  I'm  planning to extend to M10 and NEC shortly, and if I 
encounter more changes I will update the design.


My ultimate goal is to have a board that is as easy as possible to 
build and install, using SOIC parts (which I think are ok to hand 
solder) and through hole parts for the remainder.

Currently the boar has 6 SOICs, 4 resistors, 4 caps and a crystal.

The schematic is attached as a PNG for now, for the curious.

Comments and questions welcome!
If anyone is interested in the EAGLE board file, I'm happy to share it.

Steve

Re: [M100] M100 LCD repair video and alternative use for unused screen RAM

[Philip Avery]

Correct Mike, a 1950 Land Rover. This one:



Philip

On 26/02/2023 8:07 am, MikeS wrote:


Knowing Philip, more likely a Land Rover or a Jeep ;-)

- Original Message -
*From:* B 9 <mailto:hacke...@gmail.com>
*To:* m...@bitchin100.com
*Sent:* Saturday, February 25, 2023 4:01 AM
*Subject:* Re: [M100] M100 LCD repair video and alternative use
for unused screen RAM


On Fri, Feb 24, 2023 at 1:21 PM Philip Avery 
wrote:

My excuse is I was commissioned to
do a vintage vehicle restoration which has soaked up all my
spare time
for the last 2-years. 



Vintage vehicles are fun, too. This wouldn't happen to have been a
Model T, would it?

The good news is I'm almost complete & I expect
within a few months to get my vintage computing time back & be
able to
resolve any M100 CP/M issues & add new features...


Yay!

—b9

Re: [M100] M100 LCD repair video and alternative use for unused screen RAM

[Philip Avery]

Yes, I have a list of jobs to do on M100 CP/M. Rest assured I'm still 
committed to all-things M100 CP/M.  My excuse is I was commissioned to 
do a vintage vehicle restoration which has soaked up all my spare time 
for the last 2-years. The good news is I'm almost complete & I expect 
within a few months to get my vintage computing time back & be able to 
resolve any M100 CP/M issues & add new features...


Philip

On 25/02/2023 6:59 am, Jim Anderson wrote:

-Original Message-

Did you ever finish whatever it was you still needed to do for rexcpm?

I don't remember what the problem was supposed to be by now, but I
remember to keep watching for some update to either cpmupd or to the
disk image every time I reload my rexcpm, and I only know that the files
haven't changed.

I guess for that matter the question should be "What was that problem
supposed to be again?"

Another chime in from someone who is still around but lurking :)

I didn't want to bring this up because I have my own unfinished project I feel 
guilty about, but I will answer the question.  (My unfinished thing is that I 
started on a project to improve the font used on the MVT100 board, and I made a 
minor improvement to readability of a few characters (6, 9, and Q, I believe) 
which Stephen started distributing with new boards, and then I embarked on a 
project to dramatically improve the rendering of the 80x24 mode font and also 
reproduce the original DVI font, and then I got stalled out partway through the 
character set when Life Happened :( but I do mean to get back to it, I promise)

The thing that I think you're remembering is that there isn't enough directory 
entries in the CP/M image for the 4MB REXCPM.  I discovered this because I was 
filling mine up and I'm only able to use a little more than half the capacity 
IIRC (it might have been more approaching 2/3 capacity).  Philip said he would 
need to re-make the image for 4MB with a greater number of directory entries, 
and that anyone who wanted to use it would of course have to export their 
files, load the new disk image, and re-import their files back.  (A pain to be 
sure, if you've filled it up like I have, but a pain I'm quite willing to 
undergo.)

Two other things I've been hoping for for quite some time, and I'm not sure how 
much of this was Philip's thing and how much was Stephen's thing and/or someone 
else's thing, but there was talk of new versions of import/export which would 
support 8.3 filenames instead of just 6.2 when used with a compatible TPDD 
emulator...

The second thing was 76800bps support when used with a compatible TPDD 
emulator.  I know there's a private version of this floating around somewhere 
because the REX backup/restore utility supports it, and I've been aching to 
make use of it.

Maybe if I get my project moving and released?  My internal guilt makes me not 
want to ask for these things because I have failed so far to deliver on my 
thing... :P







 jim

Re: [M100] M100 LCD repair video and alternative use for unused screen RAM

[Philip Avery]

Yes, I'm still around. I've uploaded to the Personal Library on 
Club100.org the source for Sudoku display - SUDISP.DO. I don't know how 
much use this would be for you as all I was doing was displaying a 9x9 
grid on the M100/T102 8-line display. I just rolled my own font for 
digits 1-9.


I've also uploaded the source for HW scroll demo - scroll.asm

Philip

On 24/02/2023 8:40 pm, B 9 wrote:

On Sun, Feb 19, 2023 at 4:06 PM Mike Stein  wrote:

You might also get inspired by Philip Avery's Sudoku program in
his Club100 upload folder.


Unfortunately, it doesn't work at all on my Tandy 200. (I tried both 
version 3.1 and 4.1).


Maybe he'll publish the source...


That'd be nice. Is he still around? It looks like he has a few nifty 
utilities (like the HW scrolling demo) which are worth archiving 
somewhere, if he's willing to release the source.


—b9

Re: [M100] RexCPM install

[Philip Avery]

Robert

Are you sure you're using the same TPDD emulator & any usb-serial cable 
as previously? LaddieAlpha is rock solid in my experience and CPMUPD 
will work, presuming REXCPM is operating normally.


Philip

On 17/10/2022 7:17 am, Stephen Adolph wrote:

Hi Robert, couple of comments.

1) test your REXCPM.  you can always test it yourself and see if you 
have a hardware problem

https://bitchin100.com/wiki/index.php?title=REXCPM
read up on how to load and run REXCPM.
I would not do this if you are happy with the REX# part of the 
install.  In fact if that is working, likely no hardware problem.

There is only one memory chip and it is used for both REX# and CPM.

2)  Philip's routines more or less rely on LaddieAlpha to operate.  I 
would recommend you use LaddieAlpha as the TPDD client.

This is because the files are binary files with a .BK extension.
Also, make sure you load and run CPMUPD.CO  after 
you power off, power on.  This is to ensure you are in the default RAM 
config.



cheers
Steve



On Sat, Oct 15, 2022 at 5:24 PM Robert Hutchins 
 wrote:


Hi all,

Having trouble installing CPM into my Model 100 with the RexCPM
ROM kit.

I get the REX part installed, but am unable to get CPMUPD to do
its job…

It either just hangs, doing nothing or sometimes it will work, but
then, when it

prompts for the CPM file (CPM210.bk) it refuses to load this. Just
sits there hung…

Any ideas would be welcome.

At one point in the past,  I did have it working, but it expired
(batteries all died) .

Is there any chance the memory in the RexCPM device is failing…

Thank you

Robert J. Hutchins

Re: [M100] hardware scrolling patch

[Philip Avery]

Good work Steve, and reducing it to 65 bytes - cool bananas.

I agree, M100 CP/M uses rst 4 to output text so this should work fine 
with the Page Register in hi RAM zeroed out.


Philip

On 24/02/2022 5:29 pm, Stephen Adolph wrote:

Hi Tom,

I was thinking about that.  It may well work with CP/m or if not 
exactly this patch then maybe a minor variant.  The m100 main rom 
provides all of these routines for cp/m.


Cp/m always powers up as an M100 but the upper ram image would need to 
have the one location that stores page state to be zeroed out.


That upper ram image is bundled into the cpm image that is loaded from 
disk.  So i think what is needed is to just poke a 0 into that spot in 
the file on disk, or run a little utility on start of cp/m.


Steve


On Wednesday, February 23, 2022, Tom Hoppe  wrote:

Could this work with CP/M?

On Wed, Feb 23, 2022 at 7:48 AM Joshua O'Keefe
 wrote:

> On Feb 23, 2022, at 7:17 AM, Stephen Adolph
 wrote:
> I did a write up on the two patches that are needed.

Steve, I remember seeing you mention this a while back and I'm
glad you were able to get back to it.  Your write-up was
clear, informative and interesting.  Thanks for sharing it.

I wonder why this controller feature was never exploited.  Was
there perhaps a similar, earlier part lacking the feature that
was swapped out late in the design cycle?  Simple time
constraints like every engineer in history has faced?  I can
imagine all kinds of scenarios and it's a shame we'll never
know the real story of why the ROM is the way it is.

Re: [M100] CP/M console switching with REXCPM

[Philip Avery]

Thanks Ron for your feedback using M100 CP/M. I'd forgotten about the 
'returning to User 0' problem, so that's on my To Fix list.


Also intended for a future release is retaining Function key settings 
for subsequent cold boots, so Scroll lock/std, Cursor full time/std, 
RS-232 baud rate, etc will be retained.


Philip

On 19/11/2021 12:10 pm, Ron Klein wrote:


So last year I  played with using a Linux or Windows computer as a 
terminal using REXCPM.  I found that doing a 'stat con:=uc1:’ does 
indeed redirect the CP/M console I/O to the serial port and was 
somewhat successful using it that way.  Doing 'stat con:=crt:’ sets 
only the output to the RS232port.  ‘Stat con:=tty:’  sets I/O back to 
the M100 keyboard and screen.  I did have to configure a terminal type 
for some screen oriented software and usually chose VT52 ( H19) or 
VT100 if available, then used a terminal program such as minicom 
(VT100) or,  on a DOS machine I tried Procomm+ which had older 
terminal types  available like H19, VT52, ADM and Televideo.  I used 
9600 baud , no parity, no flow control to setup the serial port using 
the PC terminal program and the M100 Telcom program (88N1D) .  I think 
I also tried 19200 baud with no problem.


Only problems I found were:

 1. Need to use the F1 to toggle Sc L to Sc S to keep the screen from
halting after every 8 lines. Some programs also work better if F2
is used to changed to Cu S.
 2. Needed to re-adjust the CPM software to expect 24 lines/80 col
instead of 8lines/40col ( if your Model 100 CPM SW had been
adjusted to 8 screen lines.
 3. Some Software ( Infocom games?)  needed to see one  from the
model 100 keyboard before it switched to the full sized keyboard
attached to the PC. Weird.

Also I noticed that whenever a warm boot occurs, via CTRL-C or by a 
program,  the user number reverts to user 0 regardless of the user you 
are logged into.  This makes it less convenient to run programs from 
any user other than user 0.  I don’t “think” a warm-boot I supposed to 
change the user number back to 0.  I know it doesn’t  do that on any 
8- bit CP/M machine I own (Kaypro 2/4/10, Osborn I , NEC PC8801A, 
Televideo TPC-1).   I think this may have been discussed a while back 
on this mailing list….


I really enjoyed trying my old CP/M software on the M100.  Brings back 
my late 70’s early 80’s memories of personal computer development.   
We’ve come a long way since then.


Hope you all have a great holiday season.

Ron Klein

Sent from Mail  for 
Windows

Re: [M100] Re-directing CP/M console to serial port in REXCPM

[Philip Avery]

Nice, Tom, you've found a bug. What's happening here is Zork III is 
using a BIOS routine that waits until a key is pressed. With that 
routine I neglected to implement IO byte checking (which is set by 
STAT), so that's why you have to press something on the M100 keyboard. 
I'll fix it in my next release.


Philip

On 18/11/2021 4:05 am, Stephen Adolph wrote:
ah!  I understand now. that makes sense.  if CP/M still thinks it 
needs to throttle the screen then that stays in effect even when the 
screen is redirected.
I guess ZorkIII is implementing its own check .. IE it is a problem 
with Zork III not CP/M.


On Wed, Nov 17, 2021 at 9:50 AM tjhoppe  wrote:

Well, good news. If you set M100 CPM to 'Sc S' and 'Cu S' it works
much better. I still found an issue playing Zork III where it says
"-more-" then stopped responding, requiring me to press
enter on the M100.

stat con:=uc1:   <-- Redirect CP/M output to serial port
stat con:=tty:     <-- Change it back to M100 native display (type
this from terminal program on PC)

I am using Minicom 2.7.1 on Linux (VT102 emulator with 19200 N81).
I left it on overnight and it is still working this morning.

Tom


On Tue, Nov 16, 2021 at 2:55 PM Tom Hoppe  wrote:

Correct, VT100 emulation.

On Tue, Nov 16, 2021 at 2:15 PM Stephen Adolph
 wrote:

there will be escape characters flowing over serial in
this case, so you need to ensure that does not mess with
things.
If I understand what is happening

M100 >   PC  (video terminal character flow)
M100 <  PC  (input keyboard strokes)

When you say the terminal works reliably using F3, you are
using the PC as a display for CP/M, right?  And in this
case, you selected VT100 emulation?




On Tue, Nov 16, 2021 at 5:05 PM Tom Hoppe
 wrote:

I left minicom set to 19200 8N1 and it worked (until
it didn't). The Sc L vs Sc S is a good point! I will
try changing this tonight and see if it helps. My
ultimate goal is to ssh into my home PC from work so I
can play with CP/M during lunch :).

Tom


On Tue, Nov 16, 2021 at 11:21 AM Jim Anderson
 wrote:

First thought that comes to mind: it may be
stopping because of the feature which pauses the
screen output after 8 lines of consecutive output
– try Label-F1-Label to toggle ‘Sc L’ to ‘Sc S’ to
disable this before redirecting the console?

I’m glad to see this post because I honestly had
been thinking a while back that “I wish there was
a way to use a ps/2 keyboard with my MVT100 board
as a full-blown terminal” but didn’t try anything
because I’m not familiar enough with CP/M to know
how to redirect the console like that.  What baud
rate does it end up using when you do this?

    jim

*From:* M100 
*On Behalf Of *Tom Hoppe
*Sent:* Tuesday, November 16, 2021 10:50
*To:* m...@bitchin100.com
*Subject:* [M100] Re-directing CP/M console to
serial port in REXCPM

*CAUTION External Sender:*Do not click links or
open attachments unless you recognize the sender
and know the content is safe.

I am trying to re-direct the REXCPM console to the
M100 serial port but only having limited success.
I am using 'stat con:=uc1:' to do the re-direct.
It seems to work for a minute, then stops. I am
using minicom in Linux and it works reliably using
the REXCPM 'F3 toggle' feature to re-direct only
the screen output (19200 8N1). Has anyone else
tried doing this successfully?

Tom Hoppe

Re: [M100] oh, and Hello again

[Philip Avery]

Jim, by coincidence in the last few days I decided to get back onto M100 
CP/M. I hadn't forgotten about 4MB directory size & beefed up 
Import/Export. The 4MB directory size should be quick to fix, but is it 
any use to you without Import *.*? That Import/Export feature will take 
a little longer, but if you want to manually Export/Import each file 
manually, I can send you a new 4MB image soon.


Same time factor as my previous post, it's been awhile since I've been 
on the tools...


Philip

On 17/11/2021 8:31 am, Jim Anderson wrote:

Sorry I vanished for most of this year - depression is not a good place to be.

I am hoping to get rolling and finish off the font redesign for the MVT100 
board I was working on last winter.  I think Stephen had started sharing the 
interim firmware I made which had initial M100 graphic characters added and 
some minor readability improvements to some of the characters (particularly the 
numbers 6 and 9).

I haven't been keeping up with this list, just filing the messages in the hope 
I'd pull myself up and start reading them - it's quite the backlog so I don't 
know if I will get there or not, so I don't know if I've missed any big 
developments in the REX or REXCPM worlds - I think the big one I was hoping for 
was a new 4mb CP/M image with more file handles/descriptors... and of course, 
the first message I read in a long time this morning stirred some hope of using 
the M100 CP/M with an external keyboard when stationary!

Glad to see you all again, and hope I can stay on top of things for a while.







 jim

Re: [M100] Re-directing CP/M console to serial port in REXCPM

[Philip Avery]

I thought I had this I/O configuration working using my XP box when 
testing the code, but I can't be certain. It's been almost a year since 
I've 'been on the tools' (8085 assembly & M100 CP/M), so it may take a 
few days to get back into this, but I will.


Philip

On 17/11/2021 11:55 am, Tom Hoppe wrote:

Correct, VT100 emulation.

On Tue, Nov 16, 2021 at 2:15 PM Stephen Adolph  
wrote:


there will be escape characters flowing over serial in this case,
so you need to ensure that does not mess with things.
If I understand what is happening

M100 >   PC  (video terminal character flow)
M100 <  PC  (input keyboard strokes)

When you say the terminal works reliably using F3, you are using
the PC as a display for CP/M, right?  And in this case, you
selected VT100 emulation?




On Tue, Nov 16, 2021 at 5:05 PM Tom Hoppe  wrote:

I left minicom set to 19200 8N1 and it worked (until it
didn't). The Sc L vs Sc S is a good point! I will try changing
this tonight and see if it helps. My ultimate goal is to ssh
into my home PC from work so I can play with CP/M during lunch
:).

Tom


On Tue, Nov 16, 2021 at 11:21 AM Jim Anderson
 wrote:

First thought that comes to mind: it may be stopping
because of the feature which pauses the screen output
after 8 lines of consecutive output – try Label-F1-Label
to toggle ‘Sc L’ to ‘Sc S’ to disable this before
redirecting the console?

I’m glad to see this post because I honestly had been
thinking a while back that “I wish there was a way to use
a ps/2 keyboard with my MVT100 board as a full-blown
terminal” but didn’t try anything because I’m not familiar
enough with CP/M to know how to redirect the console like
that.  What baud rate does it end up using when you do this?

    jim

*From:* M100  *On
Behalf Of *Tom Hoppe
*Sent:* Tuesday, November 16, 2021 10:50
*To:* m...@bitchin100.com
*Subject:* [M100] Re-directing CP/M console to serial port
in REXCPM

*CAUTION External Sender:*Do not click links or open
attachments unless you recognize the sender and know the
content is safe.

I am trying to re-direct the REXCPM console to the M100
serial port but only having limited success. I am using
'stat con:=uc1:' to do the re-direct. It seems to work for
a minute, then stops. I am using minicom in Linux and it
works reliably using the REXCPM 'F3 toggle' feature to
re-direct only the screen output (19200 8N1). Has anyone
else tried doing this successfully?

Tom Hoppe

Re: [M100] Dungeon Warrior - Game...

[Philip Avery]

Pretty amazing for 10-lines, I say. Perhaps that's the secret - by 
limiting decisions & branching, the game-play is remarkably fast. I was 
also impressed by the precision required to successfully jump, not too 
soon, not too late.


Thanks Ken, that was enlightening.

Philip

On 1/08/2021 10:18 am, Ken Pettit wrote:

Hey Scott,

While I didn't mention the M100, it was *definitely* written for the 
M100.  I just found the working copy and it is attached in both 
tokenized .BA and .DO formats.  Press the space bar to jump. I also 
have a screenshot of the "moon buggy" mid jump over a crater.  :)


Philip, the "scrolling" is somewhat decent speed in BASIC.  But it 
doesn't actually scroll anything ... the "moon craters" are created in 
a BASIC string variable that just get's printed over and over on line 
7 of the LCD.  The location of the moon craters in the string is what 
is changing.



Ken

On 7/31/21 3:09 PM, Scott McDonnell wrote:


I didn’t assume Ken was talking about the Model 100 because he did 
not specifically mention that. Sounded like one of those 10-liner 
competitions.


But yeah, if this was on the Model 100, I am definitely interested, too!

Release it! Release it!

*From: *Philip Avery <mailto:pav...@xtra.co.nz>
*Sent: *Saturday, July 31, 2021 5:56 PM
*To: *m...@bitchin100.com <mailto:m...@bitchin100.com>
*Subject: *Re: [M100] Dungeon Warrior - Game...

Ken, in BASIC did the graphics really have the necessary speed? I 
would have thought you'd need the scrolling to be in assembly 
language and then maybe direct lcd-driver programming.


I'd sure be interested in seeing Moon Buggy.

Philip

On 1/08/2021 5:22 am, Ken Pettit wrote:

I actually wrote a BASIC 10-liner game similar to this in 2018
that I never released.  It is called Moon Buggy, and you
basically have a mood buggy that says in one place while the
"moon terrain" scrolls underneath.  The goal is to jump as many
moon craters as possible.  If expanded to be more than 10 lines,
it could even be extended to add moon rocks that need to be shot
with the forward lasers.

The only thing really missing from the game is every so often it
should pop up one of those annoying commercials you have to watch
with web based games.  Guess I could add that and then release it :)

Ken

Re: [M100] Dungeon Warrior - Game...

[Philip Avery]

Ken, in BASIC did the graphics really have the necessary speed? I would 
have thought you'd need the scrolling to be in assembly language and 
then maybe direct lcd-driver programming.


I'd sure be interested in seeing Moon Buggy.

Philip

On 1/08/2021 5:22 am, Ken Pettit wrote:
I actually wrote a BASIC 10-liner game similar to this in 2018 that I 
never released.  It is called Moon Buggy, and you basically have a 
mood buggy that says in one place while the "moon terrain" scrolls 
underneath.  The goal is to jump as many moon craters as possible.  If 
expanded to be more than 10 lines, it could even be extended to add 
moon rocks that need to be shot with the forward lasers.


The only thing really missing from the game is every so often it 
should pop up one of those annoying commercials you have to watch with 
web based games.  Guess I could add that and then release it :)


Ken

On 7/30/21 8:10 AM, Scott McDonnell wrote:


For a side scroller, a good place to start would probably be the 
simple game that google had made (need to find a link) that ran in a 
web browser. Your character is just running and you jump over 
hurdles. Technically your character is just in one place while the 
hurdles scroll right to left. That would get some of the mechanics 
down and only needs a couple of keys to operate and only a jump key 
while playing. Once the mechanics are nailed down, lots of things 
could be derived from it.


For an adventure game, I was thinking about the function keys working 
as the verbs that could maybe change from room to room, or maybe even 
context to context. Like you choose Open and then the menu changes to 
things that can be opened in the scene. It would need to be designed 
carefully to make good use of the limited screen. The screen would 
lend itself well to a panoramic type scene (but very simple, of 
course.) I haven’t really worked this out yet beyond my imagination. 
One day!


Only 240x64 of screen real estate, so it would need require a lot of 
creativity.


*From: *lloydel...@comcast.net 
*Sent: *Friday, July 30, 2021 8:23 AM
*To: *m...@bitchin100.com 
*Subject: *Re: [M100] Dungeon Warrior - Game...

There was an interesting article on writing adventure games written 
by Greg Hassett for Creative Computing.    I did a search and found 
it at 
http://archive.retro.co.za/archive/adventure/CreativeComputing-HowToWriteAnAdventure.pdf 
.


The text adventure games by him, Scott Adams and later Infocom are a 
game category by themselves. I always looked upon these more as a 
puzzle then as a game per se in that once you solve them they are 
solved and there is  not much point of playing them anymore.  That 
has never been much of a problem for me since I was not that 
successful at solving the darn things.   I still enjoyed playing 
them.   I have yet to attempt writing one.


The games I worked with tended to be more strategy games where a 
random number generator algorithm replaces the dice toss of similar 
board games.


It is fun to get back into BASIC programming again.   An adventure 
game with some animation sounds like fun.  I’m having trouble 
envisioning the side scroller.   I’d be interested in how that would 
be implemented.   It’s given me an idea or two that I might 
investigate further.


Lloyd

*From:* M100  *On Behalf Of *Scott 
McDonnell

*Sent:* Thursday, July 29, 2021 8:27 PM
*To:* m...@bitchin100.com
*Subject:* Re: [M100] Dungeon Warrior - Game...

I am definitely interested in checking this out. I have been wanting 
to understand game programming on the M100.


Unfortunately I have not had the time to try it yet so I had no 
comments to give except thank you for sharing it with us!


Someday, I want to attempt an adventure game with some animation for 
the small screen of the M100. A side scroller would also fit well 
with the screen layout.


 Original message 

From: lloydel...@comcast.net 

Date: 7/29/21 4:56 PM (GMT-05:00)

To: m...@bitchin100.com 

Subject: [M100] Dungeon Warrior - Game...

I had tried sending this out last week but there was no comments.   I 
shared it separately with another member of this group and he said he 
did not receive it.   So, maybe it did not go out.  Here it is again 
but without the screenshot.


I rehosted another game to the TRS-80 Model 100 and NEC
PC-8201.   This is another game I had written some 40 years
ago.   It is called Dungeon Warrior.

I spent some time documenting this game, its history and it’s
features in the pdf file.    Even if you don’t play the game, you
might find the pdf document interesting in that it references
another game (Wizard War)  I developed with Fred Saberhagen (a
prolific science fiction/fantasy writer).

The files can be found at

Re: [M100] Dot matrix printer ribbons

[Philip Avery]

Thanks Brian for the great info.

Philip

On 9/06/2021 1:57 am, Brian K. White wrote:

On 6/8/21 3:54 AM, Philip Avery wrote:
So Brian, where do you apply the drops of ink? Just to sponge inside 
the card, or directly onto the spooled-up ribbon in there as well?


Wherever makes the most sense for a given cartridge. They're all a 
little different. Some just have a big cavity with bunched up ribbon. 
That ends up being the messiest because you end up putting a lot of 
ink in just to get it to even out. But even that style evens out after 
a while from the bunched up ribbon rubbing on itself. Some have a felt 
or sponge wiper block somewhere. And if there is a sponge roller 
that's obviously the best. Definitely if there is a sponge roller just 
add drops right to that and let it ink the ribbon. Main thing is don't 
expect it to happen fast and add more and more. It happens but slowly.


It's messy stuff and travels everywhere. If you over do it, it will 
seep out of all the seams in the cartridge case too. Being oil, it 
clings to surfaces and kind of spreads itself and the whole cartridge 
becomes an oily inky mess. It's easy to over-do it because you add a 
few drops and it doesn't do anything except make one tiny spot black, 
so you add more. But time and printing (winding the ribbon) evens it 
out because of that same oil property.


For a DMP-105 cartridge specifically I don't know. Don't have one of 
those.


But usually the case can be cracked open without destroying it. 
Carefully, while keeping it flat on a table, to avoid having the 
bunched up ribbon fall out. It's recoverable even if that happens, 
just tedious and messy packing the ribbon back in one inch fold at a 
time with tweezers. Probably want to do this on newspaper on a cut 
open garbage bag and wearing gloves.




Philip

On 8/06/2021 5:23 pm, Brian K. White wrote:

On 6/7/21 7:37 PM, Jerry Davis wrote:
Something Charles Hudson mentioned about his DMP105 yesterday led 
me to ask this question:


Has anyone had any good experiences with non-OEM or re-inked 
printer ribbons from companies like ribbonsunlimited.com 
<http://ribbonsunlimited.com>?


I've cleaned and repaired a DMP110 that came with some old Radio 
Shack ribbons.  The old ribbons still worked and print evenly, but 
they are dry and print very light.  The 3rd party ribbons I've 
tried print very unevenly.  A band of dark followed by light 
followed by dark.  And the print quality from these ribbons seems 
rough, even by dot matrix standards.


Until the ribbon physically wears out from the pounding, or the 
sponge inside the card degrades, you can use oil-based stamp pad ink 
to re-ink them properly.


Stamp pad ink comes in two main varieties, water/glycerine based and 
oil based. The oil based can be either mineral oil or silicone 
sometimes, but the important thing is just make sure you don't get 
the water or glycerine type. Not just because it dries out 
obviously, but because the oil is how the impact pins get lubricated.


Other than that, stamp pad ink is the right consistency and 
oil-based etc and you can actually get it readily, while, you used 
to be able to buy matrix ribbon ink from the same kinds of places 
that sold ink jet and toner refill kits, but not any more. You can 
get it even locally without waiting not just on-line. Both office 
and art supply places have it.


A few drops goes a long way. Small bottles like for eye drops (like 
what Staples etc will have) are plenty.


You get the light/dark evened out by just waiting, or by a few 
cycles of winding the ribbon, wait a day, wind some more, etc. I've 
never seen a new ribbon have dry patches like that, but when you 
first re-ink an old ribbon it will of course. The ink soaks and 
travels around and evens out by itself over time, but only among all 
the parts that are bunched up touching each other. The part that's 
out in the loop not packet in the case can get light patches. But 
just wind the ribbon to cycle the dry part into the case and leave 
it like that a while.


Probably in normal for-real use like if it was 1995 and you were 
actually printing things at work all day, any light spots like that 
would have evened out naturally within a day or so just from the 
natural cycling of the ribbon. Especially for cartridges that 
include a sponge roller inside. Some have that, some don't.

Re: [M100] Dot matrix printer ribbons

[Philip Avery]

So Brian, where do you apply the drops of ink? Just to sponge inside the 
card, or directly onto the spooled-up ribbon in there as well?


Philip

On 8/06/2021 5:23 pm, Brian K. White wrote:

On 6/7/21 7:37 PM, Jerry Davis wrote:
Something Charles Hudson mentioned about his DMP105 yesterday led me 
to ask this question:


Has anyone had any good experiences with non-OEM or re-inked printer 
ribbons from companies like ribbonsunlimited.com 
?


I've cleaned and repaired a DMP110 that came with some old Radio 
Shack ribbons.  The old ribbons still worked and print evenly, but 
they are dry and print very light.  The 3rd party ribbons I've tried 
print very unevenly.  A band of dark followed by light followed by 
dark.  And the print quality from these ribbons seems rough, even by 
dot matrix standards.


Until the ribbon physically wears out from the pounding, or the sponge 
inside the card degrades, you can use oil-based stamp pad ink to 
re-ink them properly.


Stamp pad ink comes in two main varieties, water/glycerine based and 
oil based. The oil based can be either mineral oil or silicone 
sometimes, but the important thing is just make sure you don't get the 
water or glycerine type. Not just because it dries out obviously, but 
because the oil is how the impact pins get lubricated.


Other than that, stamp pad ink is the right consistency and oil-based 
etc and you can actually get it readily, while, you used to be able to 
buy matrix ribbon ink from the same kinds of places that sold ink jet 
and toner refill kits, but not any more. You can get it even locally 
without waiting not just on-line. Both office and art supply places 
have it.


A few drops goes a long way. Small bottles like for eye drops (like 
what Staples etc will have) are plenty.


You get the light/dark evened out by just waiting, or by a few cycles 
of winding the ribbon, wait a day, wind some more, etc. I've never 
seen a new ribbon have dry patches like that, but when you first 
re-ink an old ribbon it will of course. The ink soaks and travels 
around and evens out by itself over time, but only among all the parts 
that are bunched up touching each other. The part that's out in the 
loop not packet in the case can get light patches. But just wind the 
ribbon to cycle the dry part into the case and leave it like that a 
while.


Probably in normal for-real use like if it was 1995 and you were 
actually printing things at work all day, any light spots like that 
would have evened out naturally within a day or so just from the 
natural cycling of the ribbon. Especially for cartridges that include 
a sponge roller inside. Some have that, some don't.

Re: [M100] internal disk

[Philip Avery]

Hmm, not sure I follow. I don't see value in transferring from CP/M disk 
to M100 disk. But I do see value in having a REXCPM machine able to do 
CP/M *and* do your internal disk in M100 mode.


Philip

On 2/03/2021 11:55 am, Stephen Adolph wrote:

Hi Philip,
So, my goal here is a common function for both flash and ram versions.
Maybe as a adjunct we could add transfer to and from the cpm disk.
..steve

On Monday, March 1, 2021, Philip Avery <mailto:pav...@xtra.co.nz>> wrote:


This sounds interesting Steve. I'm sure I could put enough smarts
into M100 CP/M so that it could co-exist with a M100 "disk drive".
Particularly if your disk is at the end of CP/M disk, ie the upper
REX blocks. I could set the end-point of CP/M disk to be below
M100 Disk.

Philip

On 2/03/2021 7:33 am, Stephen Adolph wrote:

Quick note just to say that I have got a plan now, and have
started coding, for how to implement an internal "disk drive"
using both REX# and REXCPM.  This is the last major hurdle
that I have wanted to overcome for a long time.

Basically, the user can identify some of the 32k blocks to be
allocated to form a disk.  There will be an upper limit of 16
blocks in the disk, for a total of 512kB.  There will be
support for up to 31 directories (nested) and thinking 256
files total.  Organization will be based on 128 byte sectors.

Anyhow that is the plan.  Not sure when I will get it done but
I'm on the way now.  Looking forward to seeing this through to
fruition.

Steve

Re: [M100] internal disk

[Philip Avery]

This sounds interesting Steve. I'm sure I could put enough smarts into 
M100 CP/M so that it could co-exist with a M100 "disk drive". 
Particularly if your disk is at the end of CP/M disk, ie the upper REX 
blocks. I could set the end-point of CP/M disk to be below M100 Disk.


Philip

On 2/03/2021 7:33 am, Stephen Adolph wrote:
Quick note just to say that I have got a plan now, and have started 
coding, for how to implement an internal "disk drive" using both REX# 
and REXCPM.  This is the last major hurdle that I have wanted to 
overcome for a long time.


Basically, the user can identify some of the 32k blocks to be 
allocated to form a disk.  There will be an upper limit of 16 blocks 
in the disk, for a total of 512kB.  There will be support for up to 31 
directories (nested) and thinking 256 files total.  Organization will 
be based on 128 byte sectors.


Anyhow that is the plan.  Not sure when I will get it done but I'm on 
the way now.  Looking forward to seeing this through to fruition.


Steve

Re: [M100] REXCPM 2M vs 4M

[Philip Avery]

Correct Jim, it hasn't been fixed yet. After Easter I can get back to it.

Philip

On 26/02/2021 11:56 am, Jim Anderson wrote:

-Original Message-
For the record, I did end up successfully upgrading a 2M REXCPM to 4M
using the RMLV3216AGSA linked below.

This reminds me... did I miss an announcement, or is the release of a CP/M 
image for the 4MB REX with increased directory entries still pending?  The 
current image linked on http://bitchin100.com/wiki/index.php?title=M100_CP/M is 
CPM410.BK which is the same filename as I have, so unless it's posted somewhere 
else I guess it hasn't been fixed yet.







 jim

Re: [M100] Fast graphics?

[Philip Avery]

I make use of direct-LCD driver programming in my Solitaire port to 
M100. It's a Basic program that has a partnered .CO program which 
displays the cards. You can find it here:

http://club100.org/memfiles/index.php?=0==Philip%20Avery

Bear in mind this is a mostly Basic program, but when the card starts to 
be drawn, it is pretty much instant. This was a huge improvement over 
using the ROM Set routine which does a single pixel at a time.


I presume you're conversant in 8085 assembly language as there are 
considerations in moving a sprite anywhere on the screen. I can provide 
the source to SOLCR3.CO if you so desire.


Philip

On 30/12/2020 1:33 pm, Hiraghm wrote:


Awhile back, someone in the list was talking about fast display 
routines for the Model T.


I know the LCD is slow in displaying graphics, but I was wondering if 
anyone could share some assembly language examples of fast display 
writes. The Model T doesn't have a bitmap mode, and even if it did, 
screen writes would still be slow.


I was watching this video by the 8-bit guy concerning his new "Attack 
of the PETSCII Robots" game, where he explained redefining characters 
to make the graphics for the PET, Vic-20 and C64.


Attack of the PETSCII Robots part 2 



I'm pretty sure you can't do that with the Model T unless you have a 
REX, and maybe not even then.
Now, the Model T does have graphics characters, but to move a "sprite" 
on the screen smoothly would involve, I believe, a lot of calculation 
as to what graphics characters to use and when.


I've limited my game ambitions thus far to text or strategy (Oregon 
Trail rewritten to "Organ Trail"; a port of a C64 Master of Orion type 
game, "Reach for the Stars", which used * for stars). Still working on 
both).


But that game of his makes me want to do more graphical games without 
substituting ascii characters a la rogue.
Even a 4 character sprite rather than the 9 characters he uses would 
be good if it could be written fast enough.


Being able to create a condense font as view80 does would also be very 
handy.


So I'm hoping someone out there has learned some tricks for quick 
graphics?


I'm reading the Hidden Powers book, but am still scratching my head a 
bit about writing to the display.


Thanks for any info or advice.

Re: [M100] using option roms with "VT100"

[Philip Avery]

Good going with this, Steve. Are you debugging all this on real hardware 
or have you hacked VT to do 80x24, ie emulate MVT100?


Also, does MVT100 work with all the OptROMS that work with a DVI? Or are 
you attempting to do more OptROMS?


Your interrupt dilemma... sounds like an early REX function would be 
useful here. Swap out the the System ROM when activating VT100 to a 
hacked System ROM with VT100-friendly interrupt routines.


Philip

On 27/12/2020 1:21 pm, Stephen Adolph wrote:
My deep dive on VT100 driver integration into REX has been tiresome 
but interesting.  Many bumps on the road, and learnings.  Actually 
pretty painful to be honest.


I have been able to explore a few ROMs, and figure out if they work or 
don't work with "VT100".  (which really is a modified "Disk Basic" 
from Microsoft, and derives from the work others have done to 
disassemble Disk Basic).


Interestingly, ROM2 Cleuseau seems to work very well with VT100!. 
Should not be a surprise as it seems to use the LCD in a simple way.


TS-DOS ***almost*** works.  You can imagine that with a few tweaks it 
could work on an 80x24 screen, but  then again, perhaps not usefully.  
"just look at the small screen!"


Haven't tried any other ROMs yet.  An 80x24 spreadsheet and word 
processor would be great!  Time to try Super ROM.


Anyhow, with a bit of knowledge gained, it seems like it might just be 
possible to modify ROM programs to use 80x24. Especially if they use 
the "stock calls" for printing to the screen.


I have implemented an "expert mode" and a "safe mode".  The safe mode 
renders option ROMs unusable in REX, whereas the "expert mode" means 
..have at it.    So, if you wanted to use R2C100 on an 80x24 screen, 
switch to expert mode and off you go.


The most painful learning for me is just how complex it can become 
when you are trying to debug the combination of memory bank switching 
and interrupts.


I had originally wanted to move the VT100 driver into the REX ROM.  
This would mean that 6 software hook programs would be serviced by 
running software in an option ROM. So, in active use there would be 
(1) the main ROM (2) the REX ROM and (3) a traditional OPTION ROM.


But what happens when the "system" is running, at the time of an 
interupt, on a separate OPTION ROM, and not either the main ROM or the 
REXROM?    This was not anticipated by Mr. Mo Budlong, or if he did 
think about it, it is a "secret".


Well I can tell you that I gave up after quite a bit of time sunk into 
debug! OMG.


What seems to be most reliable, is to run the "VT100" software hook 
programs in upper RAM, which is how it was meant to work all along.  
So, for VT100 support you kinda have to live with some memory being 
taken up by that code, which reduces the usable RAM space somewhat.


"Typical" REXMGR.BA  takes about 0x200 bytes or so 
without VT100, and including VT100 it takes about 0x04B5 bytes. That 
is more than 1k of RAM consumed with enabling both REX and VT100.


My prototype shows 28432 bytes free, whereas stock M100 (no REX) shows 
29638 bytes.  A tradeoff I am personally happy with, for the advantages.


I appreciate that many users may not want an LCD plugged into their 
M100, but I personally really like it.  I think large-screen Text, and 
also programming, make it interesting, and still quite compact.


Anyhow, happy holidays 2020 to everyone and let us all hope for an 
improved 2021.


regards
Steve

Re: [M100] Virtual T pays off yet again

[Philip Avery]

Nice *DI*gression, Steve. So is that the fix for you - DI on the REX 
side whenever you're writing a hook?


Philip

On 13/12/2020 1:22 am, Stephen Adolph wrote:
I've been on a deep dive lately, integrating my early VT100 video 
driver into REX# and REXCPM.  It has been a marathon of reverse 
engineering, troubleshooting and testing. All good, coming together well.


The purpose of this note is to highlight the value of Virtual T, for me.

REX generally gets quite tightly tied into the M100 OS, especially in 
2 ways.
1) REX takes over the timer hook and drives autoconfig of the OPTROM 
switching function that way.
2) REX also grabs a hold of and used 2 Software hooks - CHGET and 
CHPUT.  These two hooks are grabbed /dynamically as needed.  
W/ith VT100 AKA  Disk Video Interface software,  now 6 or more 
software hooks are needed, also dynamically switched


With all this interrupt driven interaction, the effects on the M100 
can be... confusing.   VirtualT to the rescue on that one!  No way I 
could deduce what is happening without it!


Some bugs however can be very well hidden, as they can be 
statistical.  Since the TIMER HOOK occurs randomly, if there is a bug 
relating to WHEN the timer hook occurs relative to what the M100 is 
doing, it can be quite hard to find.


Yesterday I discovered a unique bug that I really just wanted to write 
about.  This bug is so well hidden that it has affected every REX 
device ever.  Finally discovered and resolved!


Here's the scenario.  When I use TIMER hook to dynamically switch a 
software hook,  I have discovered that the RST 7 routine at 7FD6H 
actually is not robust.


Here is the nasty piece of code:
This is the part of 7FD6 RST 7 routine that reads the software hook value.




7FE2H   (21H)   LXI H,FADAH; Start of RST 38H vector table  
7FE5H   (3AH)   LDA FAC9H  ; Offset of last RST 38H call
7FE8H   (4FH)   MOV C,A 
7FE9H   (06H)   MVI B,00H   
7FEBH   (09H)   DAD B   
*7FECH* 	*(7EH)* 	*MOV A,M* 	*!! Can't take an interrupt here, if we 
change the hook itself!!!*

*7FEDH* *(23H)* *INX H* *
*
*7FEEH* *(66H)* *MOV H,M*   *
*
*7FEFH* *(6FH)* *MOV L,A*   

7FF0H   (F1H)   POP PSW 
7FF1H   (C1H)   POP B   
7FF2H   (E3H)   XTHL
7FF3H   (C9H)   RET 


At 7FEC, the software hook data is read not as a single 16bit value 
(like LHLD), but instead it is read in 2 separate 8 bit reads!  OUCH!
This means that, when REX is re-configuring a software hook at the 
VERY instant that M100 OS is actually READING and USING that software 
hook, there is a chance that the hook value would be corrupted.


If it had been read as a single 16bit address, such corruption would 
not be possible.


This is clearly hard to see occur in real time since the TIMER has to 
hook at exactly the worst time for the system to crash.


With VT, I can change the speed of the M100 to such a high rate that 
these events actually become probable in a limited time.


So,  I have noticed over the years that sometimes REX would crash in 
VT when running at a high speed.  I always attributed it to a VirtualT 
problem.  I know better now!


...but I *DI*gress.

Steve

Re: [M100] STRUGGLING to get REXCPM loaded

[Philip Avery]

Bob, I believe you need to rename your TSD101 file to be TSD101.BX

Philip

On 18/11/2020 9:25 am, Bert Put wrote:

Bob, I definitely second Steve's NADSBox suggestion, that worked very
well for me.

Cheers,Bert


On 11/17/20 1:29 PM, Stephen Adolph wrote:

Bob, I recommend you use, if you can, laddiealpha on your working
windows box?
Nadsbox should work, works for me.
You do need to be sure that the visible directory has the correct file
name visible.

TSD100.BX is the correct image file name for TS-DOS.

Steve


On Tue, Nov 17, 2020 at 1:48 PM mailto:b...@pigford.org>> wrote:

 Steve et al,

 __ __

 I was successful in getting RXCINI.DO into my M100 using mComm on a
 Win XP laptop with a real serial port.

 Ran RXCINI just fine and got RXCMGR installed.  The problem all
 along was the Dell “legacy port replicator”.  Clearly the Dell
 implementation of a serial port emulation was flawed.

 __ __

 Now using RXCMGR, I am trying to load OptROM images (*.BR) from the
 root directory of my NADSBox.  For example, I chose F2 to LOAD an
 OptROM image, type in the filename (ex: TSD100) and NADSBox is
 connected, but I always get the same error “File name error”.  I
 know the .BR files for various OptROMs are there on the NADSBox SD
 card, so I appear to be stumped again.

 __ __

 Are there differently named OptROM images intended for use with
 RXCMGR?

 __ __

 __ __

 *From:* M100 mailto:m100-boun...@lists.bitchin100.com>> *On Behalf Of
 *b...@pigford.org 
 *Sent:* Saturday, November 14, 2020 8:27 PM
 *To:* m...@bitchin100.com 
 *Subject:* Re: [M100] STRUGGLING to get REXCPM loaded

 __ __

 Steve,

 I’ve had enough for today.  I’ll go at it again in a day or two.  No
 need to fret over this.  I am sure I will get it one of these days.

     Cheers,

     Bob

 __ __

 *From:* M100 mailto:m100-boun...@lists.bitchin100.com>> *On Behalf Of *Stephen
 Adolph
 *Sent:* Saturday, November 14, 2020 7:37 PM
 *To:* m...@bitchin100.com 
 *Subject:* Re: [M100] STRUGGLING to get REXCPM loaded

 __ __

 If you continue to struggle, try this:

 __ __

 
http://bitchin100.com/wiki/index.php?title=REXCPM#Test_your_REXCPM_Installation

 __ __

 On Sat, Nov 14, 2020 at 7:35 PM Stephen Adolph mailto:twospru...@gmail.com>> wrote:

 Hi Bob,

 my guess is that there are one of 2 things wrong.

 1) the socket has some loose connections or

 2) the 8 bit transfer didn't go as planned and there is
 something amiss with RXCINI.DO

 __ __

 I must say, I need to make my utilities more bulletproof.  I
 think I will adopt the Ron Weisen encoding...7 bit.

 __ __

 Steve

 __ __

 On Sat, Nov 14, 2020 at 4:06 PM mailto:b...@pigford.org>> wrote:

 Hello all!

  

 Today I finally tried to install REXCPM in my M100.  I have
 not yet succeeded.  Any suggestions would sure be
 appreciated.  Here is the scenario:

  

 Using a Null Modem cable, I transferred the RXCINI.DO file
 carefully to the M100.  I used 1200baud with TeraTerm on my
 Dell Win10 laptop, 8 bits, etc.  My Dell Win10 machine came
 with a Dell external device that provides supports legacy
 ports via USB cable to an external box with physical serial,
 parallel, Ethernet, and USB connections.  

  

 The transfer was successful and I looked at the lines of
 code in the  .DO file and compared to a screen listing of
 RXCINI (used Notepad).  All good.

  

 I connect my NADSbox with RXC_11.BR  AND
 RXCINI.DO In the root directory and using the cable that I
 have always used with my NADSbox.  Then I start through the
 steps found onthe Bitchin100 page:

 http://bitchin100.com/wiki/index.php?title=REXCPM

  

 I at step 4, I select Yes to both options, and Y to proceed.

 I see a line on my screen that shows dots appearing:

    Loading at: 62000 <.

    ..

 Note that I see only two dots on the last line then the
 screen goes off with the M100 powered off.  When I turn it
 back on, it is apparent that a cold start has occurred.

  

 I have repeated all the steps carefully at least 4 times
 (Cold started M100, transfer RXCINI.DO, RUN”RXCINI”.  I
  

Re: [M100] wordstar 4 wants a z80

[Philip Avery]

Exactly, altering the drive tables of the Linux emulator should enable 
execution of an M100 CP/M image I would think. Conversely, massaging the 
image to suit what the emulator expects might be the way to go. You'd 
need to be conversant with "CP/M Alteration Guide" - it contains all 
info regarding Disk Partition Table, etc.


Philip

On 13/11/2020 3:22 am, Stephen Adolph wrote:

Perhaps Philip can comment when he sees this.
The tool I wrote to do backups, isn't purely a binary dump of the disk 
contents.

It could be, though.

What RXCUTL does (by memory here... ;) ) is there is a first byte 
providing the block #, followed by 16k of block data.   (or 32k, not 
sure now).

point is, it is not a straight binary dump.

Said another way, if there is an agreed format for making an M100 CP/M 
A: disk dump accessible on simulated CP/M, lets look at that for next 
drop of RXCUTL.



On Thu, Nov 12, 2020 at 9:10 AM Jim Anderson > wrote:


> -Original Message-
> I wonder if you changed the drive geometry info in CP/M to match the
> M100 definition, if it would work?

Probably - the readme says A: and B: emulate the 'ST-506 5Mb 5"
5Mb drive' and any other drives (C: and down) emulate 'traditional
8" 256k drives'.

I have no idea how to do that, though.  :(  I never got that deep
into CP/M.







        jim

Re: [M100] Epson HX-20 Technical Manual

[Philip Avery]

Good stuff, much appreciated Birt.

Philip

On 12/11/2020 7:24 am, Jeffrey Birt wrote:


I recently acquired an HX-20 from a friend who also located a factory 
service manual on eBay. I tried, for about 15milliseconds, to resist 
but snapped it up and scanned it in (also did OCR so it can be 
searched). It just finished uploading to Archive.org


Epson HX-20 Technical Manual: 
https://archive.org/details/epson-hx-20-tech-manual-ocr_202011 



Jeff Birt

Re: [M100] REXCPM playing and observations

[Philip Avery]

Good news is it's going to rain for a few days here, so I can spend time 
inside & improve M100 CP/M by:


- increase Directory size from 256 entries to 512.
- make Import/Export "user" friendly. ie for user area to remain 
constant before & after.


Thought I'd let CP/Mers know this so they can delay any mega-installs 
until I complete the above.


Philip

On 7/11/2020 3:36 am, Bert Put wrote:

Hi Philip,

On 10/29/20 3:53 PM, Philip Avery wrote:

Hi Jim

Fear not, we can increase the size of the Directory making full use of
4MB. This will require BIOS changes & an OS update. That means... at
present you'll have to re-import all your user files.

I'll vote for an expanded directory as well please, thank you!

Cheers,Bert

Re: [M100] M100 overclock

[Philip Avery]

Could Turbo mode be software selectable? Just curious as if you were to 
enter MVT100 (or VT-100 output with CP/M), you wouldn't be constrained 
by internal M100 LCD.


Philip

On 2/11/2020 12:44 am, Stephen Adolph wrote:

Final story on 8MHz (well final for now!).

Actually, the processor/ram/keyboard all work at 8MHz. Only one thing 
I can see, and it is pretty important, doesn't.  The LCD.
The driver chips have to communicate with the CPU, and they are just 
too slow to get their data on the bus in time.
So, I think that's the end of the story; no clear way to improve on 
the Driver response time.


6.144MHz is exactly 2.5x nominal clock rate.  That seems to be achievable.


On Sat, Oct 31, 2020 at 7:12 PM Stephen Adolph > wrote:


On Sat, Oct 31, 2020 at 5:52 PM Joe Grubbs mailto:jsgru...@hotmail.com>> wrote:

Aww yeah! I'm liking where this is going. Will the sluggish
original ROM handle 8Mhz+?


No, for sure not.  Right now I have a 120nsec EEPROM in the socket
and it supports 6.2 MHz.
If I simply place the original ROM back in - no go.
But the Main ROM is the easiest thing to replace. It is already
socketed!  There are many ways to address it.

So far here are the changes to run 6.2 MHz (my current setup)
1) you need a faster CPU + crystal.  I'm making a board for that. 
Which CPU - TBD.  There are a few choices.  (I really should try
the stock CPU and see how fast it really is.  I am currently using
the 8MHz Tundra 80C85 CPU)
2) you need faster RAM.  You could use REXCPM to solve that
problem.  Otherwise... a lot of soldering work!
3) faster main ROM.  Teeprom would be a good solution here.
4) improved M2.  stock = TC40H245 (good to 5MHz). I have
piggybacked 74HC245 (6MHz)

I'm puzzled by what is failing to work at 8.2 MHz. Everything so
far looks ok.  I'll keep poking around

Re: [M100] REXCPM playing and observations

[Philip Avery]

 forgot to count the number of 
files I had in all user areas at the time (I've since made a backup and deleted 
a bunch of cruft) but I did note that there was still 1430kb free.

Okay, the above statements about large files etc. may not be so valid - doing a 
little late-night googling right now, I'm finding some info which indicates 
that the file system allocates a directory entry for every 16kb of a file (as a 
workaround for the fact that each directory entry can only keep track of 16 1kb 
blocks)... this means that even if you load it up with large files you're going 
to run out of directory space as a 160kb file would consume ten directory 
entries.  It also seems that the directory can be different sizes on different 
systems and disk formats... so:

I guess this is a question for Philip Avery - how big is the directory 
structure in the 2mb and 4mb REXCPM images?  Can it be made bigger in the 4mb 
image?  If so, is this something one could do oneself (not being an expert on 
filesystems, but being adventurous and willing to play with a hex editor), or 
best left to the professionals?  :)







 jim

Re: [M100] CP/M keyboard

[Philip Avery]

I see your point, Steve. What I could do is have a function key to 
select between say STD, VT100, USER key maps. USER could be 
user-definable as we may encounter software which isn't configurable.


Similarly with the video output for the M100 LCD. I was envisaging STD, 
ADM3a, USER. (ADM3a was an early cursor-controlled screen popular with 
CP/M).  This will allow much more software to run on the M100 LCD, 
albeit 40 col, not 80.


One improvement I'll make (and I'm surprised no one has mentioned) is 
for M100 CP/M to boot-up in its previous configuration, eg if video is 
directed to RS-232 or CASS, it will do that for subsequent boots. Same 
with cursor flash & scroll lock settings.


Lastly, with the above in place it wouldn't be too much of a stretch to 
patch programs so on start-up they configure M100 CP/M appropriately.


Philip

On 29/10/2020 2:13 am, Stephen Adolph wrote:
I would vote for not modifying the base keyboard routine of the M100 
to align with VT100 in CP/M.

Most CP/M applications seems to support customizable keyboard.

For myself, any progress now made in setting up the M100 keyboard in 
CP/M would suddenly become invalid, and need to be redone to align 
with VT100.


So, I don't see the point.

For each application, just set up the application according to the 
M100 control codes.  If there is any confusion, we can post the list 
of control codes.


The only keys that won't work, as far as I know, are the special keys 
- F1 to F8, Label, Paste etc.  M100 does not report them as ascii codes.

Re: [M100] rexcpm and mvt100 success

[Philip Avery]

Correct, the arrow keys send M100 codes. It's on the To Do list to 
translate these to VT-100 codes...


Philip

On 27/10/2020 9:25 pm, Jonathan Yuen wrote:

Hello,

I can probably wait for the upgrade of 'import.com'.  But when it comes to 
moving around the screen, I assume that the m100 arrow keys send the 'usual' 
code out (i.e. 1C, 1D, 1E, and 1F in hex?) and not the codes that a Vt100 
terminal would send, which depends on the mode, but in VT52 mode it is ESC and 
A,B,C,or D.  Noticed the arrow keys on the m100 were not working as 
expected.

Jonathan

jonathan.y...@mykopat.slu.se

Från: M100 [m100-boun...@lists.bitchin100.com] för Philip Avery 
[pav...@xtra.co.nz]
Skickat: den 27 oktober 2020 08:15
Till: m...@bitchin100.com
Ämne: Re: [M100] rexcpm and mvt100 success

Hi Jonathan

IMPORT.COM is in line for upgrade, though it'll be into next year before
I get to it. By then we may have 8.3 filename support from the TPDD
emulators. I intend to upgrade IMPORT to:
- support wildcard filenames
- 8.3 filenames
- subdirectories

Happy cp/m-ing.

Philip

On 27/10/2020 5:14 am, Jonathan Yuen wrote:

Hello All,

My rexcpm and mvt100 kit arrived last week.  There were some hiccups getting 
the software installed on the rexcpm, and I suspect part of the problem was 
himem issues with the teeny.com that mcomm sends over.  After a number of 
super-helpful emails with Stephen, he suggested a serial transfer, which I used 
for the rxcini.do file. This worked quite well. I used minicom on a linux 
machine to send at 300 baud so I could watch it go into telecom with the 
download feature.  After that it was smooth sailing using mcomm on my phone, 
and I had enough time to get out the soldering iron over the weekend, and with 
the hints posted by Bert, got the MVT100 kit assembled in a morning, and in the 
afternoon had a vt100 terminal emulation for CPM 2.2.Even had an ancient flat 
screen vga monitor and the characters don't look that bad.

I found a copy wordstar I had configured for a vt100 (actually an xterm on an 
aix machine that was running a z80/cpm emulator written in C) and got that 
over, and just uploaded supercalc, and each of them has sent with 'pip' its own 
user space, along with one for classic adventure.

I'll have to try and remember what the key combinations are for moving around 
in wordstar and supercalc, but having this hardware is terrific.

I guess one question is whether I should move on to something else than mcomm 
to emulate the TPDD.  I like to group files together in subdirectories, but the 
import.com in cpm wants to go the the root (ie the TPDD directory on my phone). 
 I've been mass moving files to the TPDD directory when I want to import them, 
and then moving them back to a subdirectory when I'm done, but I was wondering 
if one of the other TPDD emulators might allow me to select the directory 
before starting the emulation.  I'd prefer something small like my phone if 
possible, maybe build something around one of the Raspberry Pi's sitting around?

Having this new environment has led me to use the M100 a lot more in the last 
week.  My thanks to Stephen Adolph for making the rexcpm and Philip Avery for 
porting cpm to the rex environment.

Jonathan

jonathan.y...@mykopat.slu.se
---
När du skickar e-post till SLU så innebär detta att SLU behandlar dina 
personuppgifter. För att läsa mer om hur detta går till, klicka här 
<https://www.slu.se/om-slu/kontakta-slu/personuppgifter/>
E-mailing SLU will result in SLU processing your personal data. For more information 
on how this is done, click here 
<https://www.slu.se/en/about-slu/contact-slu/personal-data/>

---
När du skickar e-post till SLU så innebär detta att SLU behandlar dina 
personuppgifter. För att läsa mer om hur detta går till, klicka här 
<https://www.slu.se/om-slu/kontakta-slu/personuppgifter/>
E-mailing SLU will result in SLU processing your personal data. For more information 
on how this is done, click here 
<https://www.slu.se/en/about-slu/contact-slu/personal-data/>

Re: [M100] rexcpm and mvt100 success

[Philip Avery]

Hi Jonathan

IMPORT.COM is in line for upgrade, though it'll be into next year before 
I get to it. By then we may have 8.3 filename support from the TPDD 
emulators. I intend to upgrade IMPORT to:

- support wildcard filenames
- 8.3 filenames
- subdirectories

Happy cp/m-ing.

Philip

On 27/10/2020 5:14 am, Jonathan Yuen wrote:

Hello All,

My rexcpm and mvt100 kit arrived last week.  There were some hiccups getting 
the software installed on the rexcpm, and I suspect part of the problem was 
himem issues with the teeny.com that mcomm sends over.  After a number of 
super-helpful emails with Stephen, he suggested a serial transfer, which I used 
for the rxcini.do file. This worked quite well. I used minicom on a linux 
machine to send at 300 baud so I could watch it go into telecom with the 
download feature.  After that it was smooth sailing using mcomm on my phone, 
and I had enough time to get out the soldering iron over the weekend, and with 
the hints posted by Bert, got the MVT100 kit assembled in a morning, and in the 
afternoon had a vt100 terminal emulation for CPM 2.2.Even had an ancient flat 
screen vga monitor and the characters don't look that bad.

I found a copy wordstar I had configured for a vt100 (actually an xterm on an 
aix machine that was running a z80/cpm emulator written in C) and got that 
over, and just uploaded supercalc, and each of them has sent with 'pip' its own 
user space, along with one for classic adventure.

I'll have to try and remember what the key combinations are for moving around 
in wordstar and supercalc, but having this hardware is terrific.

I guess one question is whether I should move on to something else than mcomm 
to emulate the TPDD.  I like to group files together in subdirectories, but the 
import.com in cpm wants to go the the root (ie the TPDD directory on my phone). 
 I've been mass moving files to the TPDD directory when I want to import them, 
and then moving them back to a subdirectory when I'm done, but I was wondering 
if one of the other TPDD emulators might allow me to select the directory 
before starting the emulation.  I'd prefer something small like my phone if 
possible, maybe build something around one of the Raspberry Pi's sitting around?

Having this new environment has led me to use the M100 a lot more in the last 
week.  My thanks to Stephen Adolph for making the rexcpm and Philip Avery for 
porting cpm to the rex environment.

Jonathan

jonathan.y...@mykopat.slu.se
---
När du skickar e-post till SLU så innebär detta att SLU behandlar dina 
personuppgifter. För att läsa mer om hur detta går till, klicka här 
<https://www.slu.se/om-slu/kontakta-slu/personuppgifter/>
E-mailing SLU will result in SLU processing your personal data. For more information 
on how this is done, click here 
<https://www.slu.se/en/about-slu/contact-slu/personal-data/>

Re: [M100] Wordstar 3.3 for MVT100 and CP/M on M-100

[Philip Avery]

Hi Jim

Yes, M100 CP/M prints to the M100 parallel port. Try LPRINT in MBASIC to 
get your setup working - it does definitely work. I don't know for sure 
with WordStar, but it could be necessary to do STAT LST:=LPT:   before 
firing up WordStar.


Philip

On 21/10/2020 5:02 am, Jim Anderson wrote:

-Original Message-
I finally got some time to assemble my MVT100 and get it going, and now
I have a good console for CP/M on my M-100!  I can get my copy of
WordStar running on it but it is configured for my Kaypro and the
control codes are not the same.  Has anyone configured WordStar for
MVT100 and if so, is it available?  I can do it but I want to be sure
it's OK to post before I do that.  Thanks.

I've done it, but it's quite easy to do yourself - if you go to 
http://www.classiccmp.org/cpmarchives/cpm/Software/rlee/M/MICROPRO/WORDSTAR/V3-3/8080/
 and download WINSTALL.COM, WS.INS, and WSU.COM (assuming you don't already 
have them), you can then run WINSTALL and generate a new WS.COM containing your 
own customized parameters (there's a lot more you can customize beyond just the 
terminal type).  VT100 is a standard terminal type (I think it is selection F 
on the first screen of terminals).

I'm still trying to figure out how to edit the terminal control codes for 
SPELSTAR.OVR because the version on that site is configured for some other 
terminal type, there isn't an installer for it, and aside from that there's 
something wrong with their copy of SPELSTAR.DCT because I only seem to have 
less than 50% success spell-checking files - it often aborts saying that 
there's an invalid dictionary entry.

As an aside, a general question for anyone familiar with CP/M (or maybe this is a 
question specifically for Phil Avery): is there printing support from within M100 CP/M to 
the M100 parallel port?  If so, what would I select as my printer output device in 
WordStar to make this happen?  I tried setting it to the "Standard List Device 
(LST:)" and when I try printing the machine seems to lock up, which may just be 
because I didn't have a printer hooked up at the time.  I do have a parallel cable, and 
my trusty old LaserJet 4000N has a parallel port, I guess I just have to get going and 
move the MVT100 and monitor closer to the printer so I can actually try it...







jim

Re: [M100] User number in CP/M for M-100?

[Philip Avery]

Hi Bert

I used standard CP/M 2.2 for M100 CP/M, so only standard User features 
apply. I believe 2.2G & 2.2H are examples of Kaypro numbering for their 
CP/M versions.


There is a 'drop-in replacement for the CCP', it's called ZCPR. I 
believe it will do what you're looking for:

https://en.wikipedia.org/wiki/CP/M#ZCPR

I haven't tried it, but it would be interesting to see how it goes.

Philip

On 7/10/2020 4:42 pm, Tim Russell wrote:
The "user number in prompt" and "execute from user 0" thing are BDOS 
extensions from a given manufacturer and not part of standard CP/M 
2.2, if I recall correctly.


It may have become standard in CP/M 3.0, but that's not really germane 
here.


On Tue, Oct 6, 2020, 17:26 Bert Put > wrote:


Hello,

I was wondering which version of CP/M that this was based on?
I'm specifically looking for support for "user numbers" since CP/M
does
not support directories.  My Kaypro runs CP/M 2.2G and 2.2H.  In those
versions, the user number is part of the prompt, such as A0> or A1>.
Also, if you navigate to user area 1 with "USER 1", you can call any
executable in user area 0 in case it does not exist in user area 1.
There are 16 such user areas available, 0 to 15.

Re: [M100] Model 100 converted to NSC800 (aka Z80) part 2

[Philip Avery]

Well done Steve with this development.

I recall you toyed with the idea of dual processors, ie existing 80C85 
for M100 mode & NSC800 for Z80 CP/M mode.  What was the outcome of that 
& why have you gone solely NSC800 please?


Philip

On 5/10/2020 7:24 am, Stephen Adolph wrote:
The processor adapter board is low profile, having pins short enough 
to allow the PCB itself to rest on the socket, on the main board.

Then there is enough room for the CPU socket for the NSC800.

The main rom, being closer to the front, has less room.  In that case, 
no socket for the option rom.  The 27C256 is soldered to the pcb, with 
the pcb flush mounted to the main rom socket.


A Z80 isn't a good natural fit as the M100 is designed around the 
multiplexed address/data bus with the ALE signal to latch.
That's why the NSC800 exists; it was National Semiconductor taking 
advantage of Z80 improvements, while leveraging the chip sets for the 
8085.


I haven't posted the design info yet.  The PCB and schematic, in the 
end, are very simple.  I'll start documenting it at the wiki.


Now, I am trying to think of a quick way to compile TS-DOS from Ken's 
disassembly, for CP/M.  Not sure I want to re-write it in Turbo Pascal 
or C.


Steve



On Sun, Oct 4, 2020 at 12:48 PM RETRO Innovations 
mailto:go4re...@go4retro.com>> wrote:


How is the fit, with the socket and adapter?  Is there room?

Has anyone tried to support a Z80 in the same way?

Are your design plans available anywhere?

JIm

Re: [M100] REXCPM in M-100 - Success!

[Philip Avery]

Great going Burt.

To make programs available to others, add them to the wiki: (You may 
have to get a login from John H).

http://bitchin100.com/wiki/index.php?title=M100_CP/M_Application_Software

Otherwise email myself or Steve directly with a link & description of 
your program(s).


Thanks
Philip

On 4/10/2020 4:36 am, Bert Put wrote:

Success!

Thanks to the excellent work of Steven Adolph and Philip Avery I now
have the Model 100 running natively as a M-100 with the UR-II in REXCPM
in one of the ROM slots, and can switch to CPM at the press of a Ctl-C
at any time.  It reports the full 4Mb available.

I started with a M-100 that had an actual UR-II ROM in it.  Then:

1. Removed the UR-II ROM.
2. Took apart the machine to install a new memory backup battery.
3. Reassembled machine, Verified operation: good.
4. Installed REXCPM per the website instructions.
5. Used NADSBox to transfer required files to the M-100.
   - I remembered that NADSBox has a command line interface which worked
well.
6. Followed the instructions on bitchin100.com carefully, and it looks
like it worked.

I also transferred some executables from my Kaypro to this machine and
they work as well:
- D.COM (A better directory lister)
- SWEEP.COM (also known as New Sweep, file operations program)
- Wordstar 3.3, which runs but as we discussed, will not fit on an 8x40
char screen, and being configured for the Kaypro, likes to write a *lot*
of control characters to the screen.

I'm looking through my CPM catalog for other programs to copy over.  I
already know that the Z-80 specific programs are currently not usable,
such as Turbo Pascal and VDE.  So far, the programs that I've got are
working so I'm pleased.  I will definitely look into other full-screen
programs that don't need Z80, such as VEDIT40 :-)

What is the best way to make these programs available to others?

Cheers,Bert

Re: [M100] RS ZBGASM question

[Philip Avery]

Perhaps instead of single-byte RST 7 it inserts a JMP 'to debugger' at 
the breakpoint. Then when the breakpoint is reached it reinstates the 
original 3-bytes there.


Philip

On 16/09/2020 3:51 pm, Stephen Adolph wrote:
So, I am trying to understand how the Radio Shack  debugger / 
Assembler manages to set breakpoints.

Anyone familiar with how to do that?

In CP/M, the debuggers use RST7.  RST7 opcode is placed into the 
program to trigger the debugger.


In M100, such a trick can't work. So, how does the debugger 
interrupt the program?


Also, ZBG.BA , ZBG.CO  and the manual 
seem to be missing from net.  Can't find them anywhere but via the 
archive:


https://web.archive.org/web/2017155020/http://www.xibalba.com/website100/software.html

maybe we need to post these up at club100.

Steve

[M100] NEC PC-8201a charging

[Philip Avery]

Hi All

As there was interest in the modification I did to my NEC PC-8201a's 
charging circuit for NiMH batteries, here are the charge times vs run times:


15 hours charge = 15 hours run
10 hours              = 16 hours
7 hours                =  6.25 hours
20 hours          = 15 hours

So it appears the 2000mAh Eneloops are fully charged within 10 hours. 
The mod I did was add an 80 ohm resistor across R2. This effectively 
makes R2 about 56 ohms.  This PC-8201a has 2 banks of RAM, ie 64KB.


Philip

Re: [M100] CP/M install issue

[Philip Avery]

Sorry about that. Have fixed the wiki page. Should be CLEAR 0,6

Philip

On 25/07/2020 11:45 am, Tom Hoppe wrote:
I just received my REXCPM module last Wednesday and got it installed. 
I was able to get it working with the REX functionality and that works 
great, but I'm having an issue when trying to run the CLEAR command 
before running CPMUPD.CO  to install CP/M. Even if I 
start from a clean state with nothing in RAM (29638 Bytes free) when I 
run CLEAR I get the following error:


CLEAR 6
?OV Error
Ok

I'm trying to determine where to go from here. Thanks.

Tom Hoppe

Re: [M100] NEC rechargeable battery

[Philip Avery]

A-ha! Thanks Gary. Studying Brian's photos I see that wasn't originally 
a rechargeable pack. My (8201a) pack has the 70K ohm resistor on the 
"set" lines & Ni is bridged to positive. They could have easily used the 
NEC charging method as it presents 8.4V to pin 5 of the connector (8201a).


Slow charging Ni-MH is a black art so I figured I'll do some experiments 
to see how long it takes to fully recharge. I'll write a program which 
saves elapsed time & leave the machine on continuously until it turns 
off from low-power. By adjusting charging times, I'll figure out optimum 
charge-time.


Philip

On 24/07/2020 5:37 pm, Gary Weber wrote:

They didn't.  That tiny little battery pack with the external charging
jack was an "aftermarket" thing.  I think it was installed by a
company that did VAR resales of 8300s into industrial label printing
applications.

By the way the 5-cell NiMH solution works really nice.  Keeps the
voltage way up in the acceptable range throughout the discharge cycle.
I definitely recommend the solution Brian highlighted.

On Thu, Jul 23, 2020 at 10:32 PM Philip Avery  wrote:

Why did NEC go with such a small battery for the PC-8300?

I've just rebuilt my PC-8201a pack and it had 4 x AA Ni-Cd's originally. I replaced 
these with 4 x Eneloop AA's (2000mAh) & lowered the charging resistor value so 
it will charge them in a reasonable time-frame, ie overnight.

Philip

On 24/07/2020 3:40 pm, Gary Weber wrote:

Brian,

Those are precisely the same batteries I've been using to build up refurbished 
5-cell rechargeable packs for my machines also.  They've been working very well.
I got my battery sets off of eBay and they arrived within 10 days or so.  They 
still sell them there so you'll be able to find 'em.

Gary




On Thu, Jul 23, 2020 at 8:34 PM Brian K. White  wrote:

My PC-8300 came with a rechargeable battery pack that had a tiny 60mah
battery originally, a 5 button cell nicd hot-glued in the middle, with a
couple diodes & a resistor and it's own barrel jack to charge the pack.
All corroded and dead of course.

I determined that you could fit 5 x 1/2AA nimh cells in the same case,
same voltage, same charger, and get 800mah instead of 60.

1/2AA is a size that exists, but is pretty hard to find.

I found this on Amazon, welded tabs already, and even sold in sets of 5,
exactly the number needed, perfect.
http://amazon.com/gp/product/B07ZNZ535F/

Not so perfect, it took over 4 months to arrive (March 17 to July 21).

But they did finally arrive, and the size worked out.

Everything fits, and it's easy to replicate the original wiring just
moved around.

https://photos.app.goo.gl/JRVp71Govw49PXaM6

--
bkw

Re: [M100] NEC rechargeable battery

[Philip Avery]

Why did NEC go with such a small battery for the PC-8300?

I've just rebuilt my PC-8201a pack and it had 4 x AA Ni-Cd's originally. 
I replaced these with 4 x Eneloop AA's (2000mAh) & lowered the charging 
resistor value so it will charge them in a reasonable time-frame, ie 
overnight.


Philip

On 24/07/2020 3:40 pm, Gary Weber wrote:

Brian,

Those are precisely the same batteries I've been using to build up 
refurbished 5-cell rechargeable packs for my machines also.  They've 
been working very well.
I got my battery sets off of eBay and they arrived within 10 days or 
so.  They still sell them there so you'll be able to find 'em.


Gary




On Thu, Jul 23, 2020 at 8:34 PM Brian K. White > wrote:


My PC-8300 came with a rechargeable battery pack that had a tiny
60mah
battery originally, a 5 button cell nicd hot-glued in the middle,
with a
couple diodes & a resistor and it's own barrel jack to charge the
pack.
All corroded and dead of course.

I determined that you could fit 5 x 1/2AA nimh cells in the same
case,
same voltage, same charger, and get 800mah instead of 60.

1/2AA is a size that exists, but is pretty hard to find.

I found this on Amazon, welded tabs already, and even sold in sets
of 5,
exactly the number needed, perfect.
http://amazon.com/gp/product/B07ZNZ535F/

Not so perfect, it took over 4 months to arrive (March 17 to July 21).

But they did finally arrive, and the size worked out.

Everything fits, and it's easy to replicate the original wiring just
moved around.

https://photos.app.goo.gl/JRVp71Govw49PXaM6

-- 
bkw

Re: [M100] LaddieAlpha and STARTDISK.COM

[Philip Avery]

Padding with spaces to 8-characters for the base name (the part before 
extension), right?

Correct.


Every client I've seen so far pads it out. Not sure why. Well, with 
STARDISK I understand why. With a '.' the padding is not really necessary.


But because all the clients do, LaddieAlpha presents filenames as 
padded to the client to avoid triggering dependency bugs based on 
assuming base names come back padded.


If I get VT going to where I can test I can finish it. I'll test the 
high speed stuff with Steve's image utility, but you'll need to add it 
too to IMPORT/EXPORT since LaddieAlpha will be started in one mode for 
CP/M operation and generally stay in that mode. Wouldn't want to have 
to exit and start back up with different options.
Sure thing. I'll need three versions of IMPORT/EXPORT to cover all 
cases: 6.2, 8.3, 8.3 high speed. That's fine.


Philip


-- John.

Re: [M100] LaddieAlpha and STARTDISK.COM

[Philip Avery]

As to the current 8.3 handling, it may or not be helpful with 
REXCPM depending on how it would format an 8.3 filename. I really don't 
like the fact that STARDISK.COM  leaves out the '.' 
but at this point the question is do we do it the way it does it or do 
we handle both ways. Either 83 or 8.3.


-- John.
I think you're referring to M100 CP/M as REXCPM is the hardware (the RAM 
disk). I'd certainly prefer 8.3 (as opposed to 83) as I've done my end 
for it and Kurt has almost done mComm for it too.


Philip

[M100] M100 CP/M is alive

[Philip Avery]

Those who have signed up for a REXCPM board may like to check out this 
wiki page on M100 CP/M:

http://bitchin100.com/wiki/index.php?title=M100_CP/M

It has all the info for installing CP/M, special features, importing 
software, etc.


I look forward to seeing what CP/M applications become popular with the 
M100.


Philip

Re: [M100] Undocumented hardware

[Philip Avery]

No, though I was reminded of that by the recent Hardware Scroll post. 
Decided to leverage ROM code, so eventually M100 CP/M gets down to "rst 4".


Philip

On 26/05/2020 10:34 am, John R. Hogerhuis wrote:

Is the hardware scroll being used in REX CP/M?

Sounds like that was the plan at some point.

-- John.

Re: [M100] CP/M mailing list, REXCPM

[Philip Avery]

Yeah, I think keep it on this list. Then it covers the REX part of REXCPM.

Philip

On 12/05/2020 3:52 pm, Stephen Adolph wrote:
After I wrote the note, I wondered if using the other list really made 
sense; it would divide the discussions.


On Mon, May 11, 2020 at 10:57 PM David Rogers > wrote:


What Kevin said, except I just happen to still have the 100, 102,
200 and NEC units from the days when they were the latest thing.
But I used CP/M in those days and found it to be easy to use and
effective for the relative simplicity of the computers of the day.
CP/M over, e.g., WordPerfect any day.  But I like one mailing list
to cover them all.

David

*/C’est la vie, c’est la guerre,  viva la salade de pommes de terre./*

On May 11, 2020, at 7:49 PM, Kevin Becker mailto:ke...@kevinbecker.org>> wrote:


I'd prefer one list for all M100 stuff but I suppose it doesn't
matter
much either way. I'm not likely to be much of a contributor but I'm
very interested in trying out CP/M and even bought a (okay several)
M100 just for this purpose.


On Mon, 2020-05-11 at 22:40 -0400, Stephen Adolph wrote:

Hi folks,

I have started to update the REX wiki for my new projects:
REXCPM
and
REX# aka REXsharp

a work in progress.

Anyhow, we have a mailing list for CP/M use on Model 100 called
MTCPM.  I wonder if we should revive that for CP/M discussions now,
or should we keep CP/M here on this list?

thoughts?

Steve

Re: [M100] CCR-82

[Philip Avery]

Wow - you guys actually use cassette regularly? I haven't used it since 
the 80s for my TRS-80 Model 1 clone. I thought I am hard-core by 
regularly using floppy disks on my Model III...


Cassettes - holy cow.

Philip

On 26/04/2020 10:54 am, Peter Noeth wrote:
I get my short length cassettes from: http://www.tapes.com/ 
Unfortunately you do have to order in blocks of 25, but they have 
plastic cases, case insert cards, cassette labels that you can print 
on your printer, and other tape related supplies available if you are 
going for a professional look.


I buy the C-20 audio normal bias tapes, which work great in my CCR-81 
with my T102. I have a library of all my programs on tape as a backup 
to the copies on my PC. When you want a real retro-computing 
experience, work from cassette tape for a day. I haven't had any 
trouble with them, but the tapes come WITH LEADER, as opposed to the 
Radio Shack "Certified Computer Cassettes", which were leaderless.


Maybe a group order could be arranged if you don't want all 25.

Regards,

Peter

--

Message: 1
Date: Fri, 24 Apr 2020 15:32:32 -0700
From: "me" mailto:m...@scifidan.com>>
To: m100@lists.bitchin100.com 
Subject: [M100] CCR-82
Message-ID: <8b8dbdfb-02dc-df81-9a7a-5a996bb26...@scifidan.com
>
Content-Type: text/plain; charset=utf-8; format=flowed


I just ordered this

https://www.ebay.com/itm/143565229494

Also ordered a bag of 80 or so tape belts of various sizes.

I'll replace the belts but I'm also sure the caps will be replacing.
Anyone sell cap kits for it? I'm going to look for the service manual.

If I can't get it working, it'll be used for parts. He had a cheaper
shipping method available so I took the plunge.



--

Re: [M100] Video adapter.

[Philip Avery]

Good going, Steve. This will be so cool in native M100 mode, we've been 
waiting decades for a low cost & low footprint solution to give us 
80x24. Have you got TEXT working yet?


Philip

On 15/04/2020 2:44 am, Stephen Adolph wrote:

update:
Towards the goal of a next-generation video solution for M100, I have 
some progress to share.
Recall this thread where I suggest that the "Geoff VT100 adapter" as 
the hardware to focus on.


First, I have a "beta" VT100 driver solution, which is closely based 
on Microsoft Disk-Basic (minus the disk stuff).
While still buggy, I can now drive the VT100 board, and attached VGA 
monitor from BASIC.


Secondly, in order to really support M100, the software component in 
the VT100 emulator board needs to be extended. I'm working on that.  
This does imply that the "Geoff VT100" board, as it was originally 
designed, won't work perfectly for M100.   But, I'll post the updated 
software image so anyone with this board already can update their board.


I'll keep posting updates as this progresses.

Steve


On Sun, Apr 5, 2020 at 8:41 AM Stephen Adolph > wrote:


As some of you may recall, it is fairly straightforward to access
an 80x24 screen in CP/M through the use of the M100 serial port,
and an external VT100 emulator.

This device:
http://geoffg.net/terminal.html

is a great example of how to connect a modern VGA flat screen
display to the M100.  However, this exact design isn't really
convenient, as the serial data has to be connected with a custom
cable.  (see the little white 4 pin header).

I've decided to make a variant of this design that has a DB-9
connector on it, for serial data, so that it can be easily
connected to the M100.

I'll be making kits available for this design, and the price will
be 30$ US.  Hopefully by making this affordable and easier to
connect, this can become the defacto solution to 80x24 display!

This solution will work with CP/M right away, but the next task
will be - how to use this solution with Model T natively.  This
will take some software work.  A port of the "DVI software" to
leverage serial communication to the VT100 adapter is one way to
do this.

This solution is also compatible with the "BCR serial port"
modification which allows for serial data transmission at up to
120kbits/sec.   A nice solution to exernal video that frees up the
real RS-232 port of the laptop for comms.

I'll be updating the REX wiki with some information on this.  Kits
aren't ready just yet.  I'm waiting for my boards to arrive.

cheers
Steve

Re: [M100] Warning: Not a(n) M100 but a PC-2 question.

[Philip Avery]

Thanks Ron, that's good to know.

Philip

On 1/04/2020 8:07 am, Ron Lauzon wrote:
The batteries only give the extra "oomph" to run the solenoids when 
printing.


But it's possible that the printer is reporting batteries too low.

Note that you can use a more powerful AC adapter to power the 
printer/PC-2.  I have a 2A one for my set up.  Then you don't need the 
batteries at all.


--
Weblog: http://ronsapartment.blogspot.com/

TRS-80 Pocket Computer 2 - TRS-80 Pocket Computer 4 - TRS-80 Model 
100/102 - Tandy 1100FD - Commodore 64 - TRS-80 Model 4P
RC2014 (Mini and Pro) - Altair-Duino with TI Silent 700 - VT320 
terminal/Raspberry Pi 0
Some people like to work on old cars.  But old computers are cheaper 
and don't require a big garage.




Mar 31, 2020, 14:58 by pav...@xtra.co.nz:

I have one of those. The printer needs the batteries to function.
They provide current sinking beyond what the wall wart does.

Philip

On 1/04/2020 5:04 am, Jesse Huyett wrote:

Hello All,
Asking here having seen some other handhelds come up, and this
seems to be a welcoming group for all things Tandy. Feel free
to point me elsewhere, tell me otherwise, or state where I can
stick this thing.

Pocet Computer 2 with the Printer/ Cassette Interface.
I passed the first "CHECK 6" error having realized no power
was getting through due to a bad Cadmium battery.
Removed and now getting the pleasant sound of a printer going
through the self check...
https://www.youtube.com/watch?v=oncEeFjXthA
Still ends up on CHECK 6 though.
Definitely getting power, doesn't seem jammed, ...  Is anyone
familiar with the startup process and know what I should look
for next?

Regards,
Jesse

Re: [M100] Warning: Not a(n) M100 but a PC-2 question.

[Philip Avery]

I have one of those. The printer needs the batteries to function. They 
provide current sinking beyond what the wall wart does.


Philip

On 1/04/2020 5:04 am, Jesse Huyett wrote:

Hello All,
Asking here having seen some other handhelds come up, and this seems 
to be a welcoming group for all things Tandy. Feel free to point me 
elsewhere, tell me otherwise, or state where I can stick this thing.


Pocet Computer 2 with the Printer/ Cassette Interface.
I passed the first "CHECK 6" error having realized no power was 
getting through due to a bad Cadmium battery.
Removed and now getting the pleasant sound of a printer going through 
the self check...

https://www.youtube.com/watch?v=oncEeFjXthA
Still ends up on CHECK 6 though.
Definitely getting power, doesn't seem jammed, ...  Is anyone familiar 
with the startup process and know what I should look for next?


Regards,
Jesse

[M100] REXCPM and TPDD

[Philip Avery]

A call to TPDD-emulator authors. I understand these are currently Ken, 
John & Kurt. Please correct me if there are any more.


CP/M filenames are 8.3 format and for REXCPM we import & export files 
from the net using an emulated-TPDD. (No provision is made to use a real 
TPDD).  Currently emulated-TPDD wont accept 8.3 format, so the procedure 
is renaming files down to 6.2, then importing, then once in REXCPM 
renaming back to 8.3 format - quite a pain. Once in REXCPM, we have 
RAM-disk, we don't use TPDD as a disk, merely to access the net via 
another device.


So authors, can we use this time before REXCPM is "in the shops" to 
implement 8.3? If there needs to some flag to indicate 8.3, then that's 
fine by me. This is only intended to be used by REXCPM, so we're in full 
control of TPDD routines on both sides. In fact we could spin our own, 
faster protocol, but that can wait until after REXCPM's initial release. 
I'd be quite content to be able to do just 8.3 for initial release.


Philip

Re: [M100] REXCPM/REX status and questions

[Philip Avery]

Actually, M100 ROM routines will be available to CP/M apps. I propose a 
memory address in BIOS where you poke a desired ROM address, then call a 
bios address. This will work from Basic, assembly, or other apps eg: C, 
Forth, or w.h.y. The desired ROM address will remain there for 
subsequent 'calls' until changed.


The BIOS makes extensive use of M100 ROM routines to bring CP/M to the 
M100, so takes care of switching to M100 ROM, Interrupts... and getting 
back.


REXCPM is taking time, we ask for patience. If it was easy, it would 
have been done decades ago.


Thanks
Philip

On 13/03/2020 9:14 am, John R. Hogerhuis wrote:



On Thu, Mar 12, 2020 at 12:59 PM Abraham Moller > wrote:


Good to know! DX-Forth then is much better given its access to the
CP/M filesystem.

Any chance the 80x10 or 60x10 display enhancements will work with
REXCPM?



Zero chance unless someone takes the time to port them. And it would 
be a job because as far as I know CP/M mode applications do not have 
easy access to the main ROM. These screen applications are tightly 
integrated with the Model 100 BASIC ROM.


It would probably be easier to start over and create something CP/M 
specific since the job of generating a software driven character 
display is probably easier under CP/M.


From what I understand the current plan is to use an external hardware 
device to generate a full-screen display.


On the T unassisted, 40x8.

-- John.

Re: [M100] REXCPM/REX status and questions

[Philip Avery]

I believe so as it's 8080-compatiable. What's more its built-in editor 
(SED) is fully configurable with documentation & source, so we should be 
fine with that too.


Philiop

On 20/02/2020 11:55 am, Abraham Moller wrote:

Good to know! How about DX-Forth?

Jon

On Wed, Feb 19, 2020, 5:44 PM Philip Avery <mailto:pav...@xtra.co.nz>> wrote:


Yes, standard 8080 CP/M software works, which is most of it. However
Z80-specific software wont, VDE & Turbo Pascal come to mind.
Instead of
VDE (a full-screen editor), I'm using Word Master as a full -screen
editor on 80x24 external VGA screen and I'll configure RED editor for
40x8 for M100 LCD.

Philip

On 20/02/2020 4:27 am, Abraham Moller wrote:
> Hi all,
>
> Just curious about the state of this new REXCPM! It sounds
incredible!
> Does it offer CP/M plus 4MB Flash RAM for storage? Does it
change the
> number of lines/columns on the display by using a smaller font
(like
> NC100 ZCN)? Could the regular REX also be configured to run CP/M?
>
> Also, I assume standard CP/M software (qterm, DX-Forth, vde, zork,
> rogue, and so on) works with it?
>
> Thanks!!
> Jon

Re: [M100] REXCPM/REX status and questions

[Philip Avery]

Well, that would be possible as there are 60-column and 80-column 
utilities for the M100, but they are difficult to read. I think the 
uptake on this would be small as the alternative of external 80 x 24 
(36) VGA wins hands down.


We do have loads of RAM, so a virtual 40 x 66 (or say 256) lines for the 
M100 LCD would be doable & beneficial. This would allow 'scrolling 
back', making the 40x8 display more useful. I've had this in mind for a 
future addition.


Philip

On 20/02/2020 7:03 am, Abraham Moller wrote:
Also, is there any chance of resizing the font or making a virtual 
80x24 window? I think I saw a NEC PC-8300 with an Option ROM giving 
60x8 or 60x10 on the display.


Jon

On Wed, Feb 19, 2020, 1:01 PM Abraham Moller <mailto:molle...@gmail.com>> wrote:


Oh wow! This already sounds so much better than klutzy (well,
slow, individual) xmodem transfers in ZCN on the NC100.

As far as full screen CP/M, this would be over the serial port? Is
there a parallel port alternative? It would be nice to keep the
serial port for dumb terminal usage.

Jon

On Wed, Feb 19, 2020, 12:58 PM Stephen Adolph
mailto:twospru...@gmail.com>> wrote:

Yes there will be a process to push out and reload the ram
disk to an external device, like LaddieAlpha or mComm.

There are also utilities with CP/M to allow loading individual
files from/to TPDD to/from the CP/M disk.


On Wed, Feb 19, 2020 at 12:43 PM Abraham Moller
mailto:molle...@gmail.com>> wrote:

Hi Steve,

Thanks for sharing the info! Since the REXCPM has SRAM,
will I be able to back everything up with VirtualT or mComm?

Thanks again,
Jon

On Wed, Feb 19, 2020, 11:03 AM Stephen Adolph
mailto:twospru...@gmail.com>> wrote:

REXCPM itself plugs into the option rom socket.

In M100 and T102, you need an additional board
1) in M100, the adapter plugs into the system bus and
connects via a 3 wire cable to REXCPM.  No soldering,
plug and play.
2) in T102, the adapter plugs into the adjacent 8kRAM
socket, and connects via a 3 wire cable to REXCPM. An
additional wire needs to run to M37 Pin 11.  I'm
currently evaluating if a clip can be used or if it
needs to be soldered.

So, plug and play in M100.   Still evaluating if it
can be "solder free" in T102 using a clip.  Both
solutions need the adapter board.

..Steve

On Wed, Feb 19, 2020 at 10:45 AM Dan Higdon
mailto:therealh...@gmail.com>>
wrote:

For REXCPM, how much hardware modification is
required? Does it need any wires soldered to the
motherboard?
I have a Model102, if there is a difference
between 100 and 102 in this regard.

On Wed, Feb 19, 2020 at 9:35 AM Stephen Adolph
mailto:twospru...@gmail.com>> wrote:

I can comment on the hardware side of things. 
Standard REX does not support CP/M as it is
FLASH only.

REXCPM is different hardware.  It uses Static
RAM (either 2MB or 4MB) as opposed to FLASH. 
 In order to run CPM you need 64k of
addressable RAM. REXCPM does a few things to
make that happen
1) it takes over the OPTROM memory space
(-7FFF)
2) it takes over the internal RAM memory space
(8000-)
3) it provides bank switching for up to 4MB of
SRAM into those spaces.

It relies on the internal nicad battery to
keep the Static RAM alive.

REXCPM reserves a large portion of the 2MB or
4MB SRAM as a ram disk for use by CPM.  Some
additional 32k blocks are usable as OPTROM
images for traditional REX applications.

WRT the display, the LCD is always 40x8. 
However it is relatively easy to use an
external monitor with this solution,
enabling the full CP/M screen dimensions.

Philip Avery owns the CP/M operating system
port for M100, and can comment on the rest.

cheers
Steve


On Wed, Feb 19, 2020 at 10:27 A

Re: [M100] REXCPM/REX status and questions

[Philip Avery]

Yes, standard 8080 CP/M software works, which is most of it. However 
Z80-specific software wont, VDE & Turbo Pascal come to mind. Instead of 
VDE (a full-screen editor), I'm using Word Master as a full -screen 
editor on 80x24 external VGA screen and I'll configure RED editor for 
40x8 for M100 LCD.


Philip

On 20/02/2020 4:27 am, Abraham Moller wrote:

Hi all,

Just curious about the state of this new REXCPM! It sounds incredible! 
Does it offer CP/M plus 4MB Flash RAM for storage? Does it change the 
number of lines/columns on the display by using a smaller font (like 
NC100 ZCN)? Could the regular REX also be configured to run CP/M?


Also, I assume standard CP/M software (qterm, DX-Forth, vde, zork, 
rogue, and so on) works with it?


Thanks!!
Jon

Re: [M100] sending fast data using modified cassette port

[Philip Avery]

Very cool Steve. For M100 CP/M we can use this for external 80x24 video 
keeping the RS-232 port free for TPDD which is used for migrating files 
from the net.


Philip

On 6/02/2020 1:58 am, Stephen Adolph wrote:
I've been toying with using the cassette port to send serial data, for 
use with an external device that only takes input data.  Kinda the 
opposite of the BCR port.


The point being - to save the RS-232 port for bidirectional comms.

After some experiments, I think it is quite useful. I have been able 
to demonstrate an absolute maximum speed of ~100kbits/sec (which isn't 
all that useful given the typical serial port speeds) and a more 
useful 57600 kbits/sec.


Quite respectable!

To use this routine, you need to make a small change to the hardware.  
There are two unused pins on the cassette port (suggest using pin 7).
Install a single lead from pin 7 to pin 12 of M34.  This wire bypasses 
the analog filter used by the cassette circuit, and allows the direct 
output of high speed signals.
Connection to an external device needs only 2 wires from the cassette 
port - ground and Tx data.


cassette hack.png

A demonstration routine is attached that just loops and sends the same 
character out the cassette port is attached. At the core it is a very 
short routine.

Comments welcome.  cheers Steve

Re: [M100] REXCPM & M100 CP/M

[Philip Avery]

Yes, either a real VT-100 or perhaps more common today an serial-VGA 
board that accepts VT-100 codes.


Philip

On 27/01/2020 2:44 pm, r cs wrote:
Will the output be like something that could have been fed to 
something like a VT-100?


Thanks,
rcs

On Sun, Jan 26, 2020 at 4:01 PM Philip Avery <mailto:pav...@xtra.co.nz>> wrote:


Short answer is no, at this stage.

Philip

On 27/01/2020 9:20 am, Fugu ME100 wrote:
> Will it be able to use a DVI for screen output?
>
> On 25/1/20, 8:39 PM, "M100 on behalf of Philip Avery"
> mailto:m100-boun...@lists.bitchin100.com> on behalf of
pav...@xtra.co.nz <mailto:pav...@xtra.co.nz>> wrote:
>
>> That will work with M100 CP/M. Same CP/M command (Stat) will
redirect
>> 'screen' output to the printer port if you like.
>> In fact you can redirect keyboard input from the serial as
well, so you
>> can just use the M100 as a processor if you want.
>>
>> Philip
>>
>> 
>>>
>



--
/Níl aon tinteán mar do thinteán féin. /[Irish Gaelic]
(There is no fireside like your own fireside.)

Re: [M100] REXCPM & M100 CP/M

[Philip Avery]

Short answer is no, at this stage.

Philip

On 27/01/2020 9:20 am, Fugu ME100 wrote:

Will it be able to use a DVI for screen output?

On 25/1/20, 8:39 PM, "M100 on behalf of Philip Avery"
 wrote:


That will work with M100 CP/M. Same CP/M command (Stat) will redirect
'screen' output to the printer port if you like.
In fact you can redirect keyboard input from the serial as well, so you
can just use the M100 as a processor if you want.

Philip

Re: [M100] REXCPM & M100 CP/M

[Philip Avery]

I promise to do a video when I get my serial-VGA board going. It will 
give a clean 80 x 24 display whereas XP Hyperterm gives some clutter.


Philip

On 26/01/2020 6:34 pm, Chris Fezzler wrote:

Video please!

On Saturday, January 25, 2020, 10:46:20 PM EST, Philip Avery 
 wrote:



It's about time I chimed in here with my side of deal - which is 
producing a CP/M operating system for M100. This works with Steve's 
REXCPM board and is a RAM-based system instead of floppy disks, so no 
DVI necessary, just a REXCPM board. We have CP/M fully up & running on 
real M100s and have been enjoying testing by playing Zork! The 
software side is almost done, I'm currently  doing documentation. 
Steve & I have chatted and we're aiming for hardware & software to be 
available for everyone within 2-months.


What CP/M brings to the M100 world, apart from languages (C, Pascal, 
Forth, compiled Basics, etc) and masses of application software is 
"easy 80 x 24 display". It is trivial in CP/M to direct output to the 
M100 RS-232 connector, and connect a terminal (or terminal emulator) 
to get 80 x 24. (Note: this *only* applies to CP/M mode, it wont allow 
your native M100 software to display 80 x 24!) So the idea is if 
you're going to do some M100 CP/M work at a desk, then plug in a VGA 
LCD screen that has a serial-VGA conversion board attached and enjoy 
80 x 24. All low cost/energy/resource & small footprint stuff these 
days. A M100 with 80 x 24 display & megabytes of fast disk is a joy to 
use. Then, when you want to go mobile, you can still use M100 CP/M, 
just with the M100 40 x 8 display.


Will keep you all updated closer to the time.

Philip
/Making CP/M great again/

Re: [M100] REXCPM & M100 CP/M

[Philip Avery]

That will work with M100 CP/M. Same CP/M command (Stat) will redirect 
'screen' output to the printer port if you like.
In fact you can redirect keyboard input from the serial as well, so you 
can just use the M100 as a processor if you want.


Philip

On 26/01/2020 5:05 pm, John R. Hogerhuis wrote:
Another possibility for display redirection is using the printer port. 
I've connected my printer port to a parallel to serial converter and 
then that can go to a PC or something else running a serial terminal.


Then you keep the serial port free for bidirectional communication.

But you need a converter.

-- John.

Re: [M100] REXCPM & M100 CP/M

[Philip Avery]

Mike Stein pointed me to this device: http://geoffg.net/terminal.html
which I have bought, but have yet to assemble & use. Up to now I have 
just been using a XP box with Hyperterm to give 80 x 24.


Philip

On 26/01/2020 4:52 pm, Kevin Becker wrote:
I've been eagerly awaiting the REXCPM just for something to tinker 
with. I've never really used CPM before and thought this would be a 
good opportunity. But I wasn't aware of the serial terminal 
possibilties. This sounds amazing.


I also had never realized there were simple serial to VGA options out 
there. I can't think of a lot of uses for a device like that and I'm 
off to research them now.


On Sun, 2020-01-26 at 16:46 +1300, Philip Avery wrote:
It's about time I chimed in here with my side of deal - which is 
producing a CP/M operating system for M100. This works with Steve's 
REXCPM board and is a RAM-based system instead of floppy disks, so no 
DVI necessary, just a REXCPM board. We have CP/M fully up & running 
on real M100s and have been enjoying testing by playing Zork! The 
software side is almost done, I'm currently  doing documentation. 
Steve & I have chatted and we're aiming for hardware & software to be 
available for everyone within 2-months.


What CP/M brings to the M100 world, apart from languages (C, Pascal, 
Forth, compiled Basics, etc) and masses of application software is 
"easy 80 x 24 display". It is trivial in CP/M to direct output to the 
M100 RS-232 connector, and connect a terminal (or terminal emulator) 
to get 80 x 24. (Note: this *only* applies to CP/M mode, it wont 
allow your native M100 software to display 80 x 24!) So the idea is 
if you're going to do some M100 CP/M work at a desk, then plug in a 
VGA LCD screen that has a serial-VGA conversion board attached and 
enjoy 80 x 24. All low cost/energy/resource & small footprint stuff 
these days. A M100 with 80 x 24 display & megabytes of fast disk is a 
joy to use. Then, when you want to go mobile, you can still use M100 
CP/M, just with the M100 40 x 8 display.


Will keep you all updated closer to the time.

Philip
/Making CP/M great again/

[M100] REXCPM & M100 CP/M

[Philip Avery]

It's about time I chimed in here with my side of deal - which is 
producing a CP/M operating system for M100. This works with Steve's 
REXCPM board and is a RAM-based system instead of floppy disks, so no 
DVI necessary, just a REXCPM board. We have CP/M fully up & running on 
real M100s and have been enjoying testing by playing Zork! The software 
side is almost done, I'm currently  doing documentation. Steve & I have 
chatted and we're aiming for hardware & software to be available for 
everyone within 2-months.


What CP/M brings to the M100 world, apart from languages (C, Pascal, 
Forth, compiled Basics, etc) and masses of application software is "easy 
80 x 24 display". It is trivial in CP/M to direct output to the M100 
RS-232 connector, and connect a terminal (or terminal emulator) to get 
80 x 24. (Note: this *only* applies to CP/M mode, it wont allow your 
native M100 software to display 80 x 24!) So the idea is if you're going 
to do some M100 CP/M work at a desk, then plug in a VGA LCD screen that 
has a serial-VGA conversion board attached and enjoy 80 x 24. All low 
cost/energy/resource & small footprint stuff these days. A M100 with 80 
x 24 display & megabytes of fast disk is a joy to use. Then, when you 
want to go mobile, you can still use M100 CP/M, just with the M100 40 x 
8 display.


Will keep you all updated closer to the time.

Philip
/Making CP/M great again/

Re: [M100] M100 stuck on the menu with weird date :o(

[Philip Avery]

I too had this problem of random date data & unresponsive keyboard, 
albeit with a T102. It usually came right after being on 10mins, but 
eventually didn't.  I found there was no Timing Pulse (TP) from the RTC. 
This lead me to Chip Select (CS) which was open. It is fed by /RESET so 
should have been hi. I had another T102 open at the time so checked 
this. Tied CS to /RESET elsewhere & all good ever since.


Philip

On 7/01/2019 5:01 AM, Fugu ME100 wrote:
If fixing the board voltages does not remove the problem the next 
issue could be dry joints near the clock chip,  at least on two 
machines I repaired that was the problem.   It looks like the clock 
chip was placed as a second op when the boards were made and the 
soldering was not very good.  In one case it was a cracked joint near 
the clock chip and the other was just a really bad joint that had 
failed over time – there was a hole without any solder.    Simply 
pressing down on the clock chip area allowed the board to work properly.


The fact, in this case, the keyboard does not work seems to indicate 
that the area near the keyboard connector has problems.  The clock 
chip happens to be in that section of the board too.  When the unit is 
closed the keyboard cables press down quite hard on the board and it 
does flex very slightly.  So an open unit might work and the close 
unit does not – that’s how I found the issue the first time :)


From: M100 > on behalf of Stephen 
Adolph mailto:twospru...@gmail.com>>

Reply-To: mailto:m...@bitchin100.com>>
Date: Sunday, January 6, 2019 at 7:44 AM
To: "m...@bitchin100.com " 
mailto:m...@bitchin100.com>>

Subject: [M100] M100 stuck on the menu with weird date :o(

I have at least one machine with this type of error. Would be
great to figure out what has to break for that to occur.


On Sun, Jan 6, 2019 at 8:37 AM Eric LK mailto:tr...@lefauve.org>> wrote:

Hi,

I'm still waiting for my replacement Ni-Cad battery but I've been
continuing using my M100 without any other issue... until tonight.

When I turned it on, the "low battery" light was on, and the date
displayed on the first line was wrong: ◥5ÿ 00,1919 Sun 00:00:00
I switched it off and on again, and it stayed this way. That's
when I
noticed the keyboard wasn't responsive. Also the first 3
characters
flash every now and then (here is a 11 seconds video:
https://www.youtube.com/watch?v=jjUw2XpB0Gw


; it happens around 00:03)

I verified the voltage of the AA batteries and found 5.9V.
Should be
OK but I still changed them.
Now the first line displays something like this: ros ??,1920
ñ)s ??:??:??
...and the keyboard is still non-responsive

I tried the reset button, which had no effect (the computer
restarts
in the same state), and the whole reset (Ctrl+Break+Reset), which
removed all files from the ram filesystem but it's still stuck.

After a quick look inside, the Ni-Cad battery didn't seem to have
started to leak, and I measured about 4.9V to its pins; I also
noted a
faint buzzing sound coming from the LCD area while it was open.

I also tried to switch the "memory power" switch off, remove the
batteries, replace the batteries, switch everything on
again... same
result.

At this point, I'm out of ideas... Any suggestion about how to
diagnose and fix this problem?

Eric

PS: There is a kind of battery leak damage around a screw on the
motherboard, but it's nowhere near any battery (it's located
on the
left of the power switch). I noticed it when I first opened it
a few
days ago, and I planned to give it a clean with isopropyl
Alcohol when
I'll change the Ni-Cad but I didn't touch it yet. Could it be
related
to today issue? Here is a picture :
http://pics.lefauve.org/20-32-45.jpg

Re: [M100] TRS-80/Tandy Pocket Computer

[Philip Avery]

Wow - all this Pocket Computer activity.

One thing I encountered when replacing the Ni-Cd batteries in the 
cassette/printer for my PC-2, was the printer requires these batteries 
to be present even if the unit is operated on mains power. It uses the 
batteries as a current sink, the mains unit can't provide peak requirements.


Reminds me to get my PC-2 and printer out for its yearly run-up. I 
always marvel at the small-print these things are capable of.


Philip

On 9/08/2018 7:41 AM, Jim Toth wrote:
My PC-2 and CGP-115 do deserve medical grade printer pens.  Nothing 
but the best.


- Original Message -
*From:* Brian White 
*To:* m...@bitchin100.com 
*Sent:* Wednesday, August 08, 2018 12:57 PM
*Subject:* Re: [M100] TRS-80/Tandy Pocket Computer

You can get new pens, as in actually new, not new old stock, from
a german medical supplies company, and you can get new motor
pinion gears by 3d printing believe it or not. I have also found
the gear in brass, from a r/c helicopter company, but those appear
to be no longer manufactured, just existing stock.

The pens and gears are the same as for the CGP-115 and a bunch of
other plotters that all used the same engine. The paper size is
different though.

http://tandy.wiki/CGP-115



On Tue, Aug 7, 2018 at 10:08 PM Jim Toth mailto:jt...@localnet.com>> wrote:

You can still purchase PC-2 printer pens?  Excellent.  Where?


- Original Message -
From: "Ron Lauzon" mailto:rlau...@gmail.com>>
To: mailto:m...@bitchin100.com>>
Sent: Tuesday, August 07, 2018 9:46 PM
Subject: Re: [M100] TRS-80/Tandy Pocket Computer


My PC-4 was my constant companion through college and into my
first
job.  I picked up a PC-2 at the Tandy Corporate auction and
got bit by
the pocket computer bug.

What I've put together is this:
+ PC-1 - usually had bad screens over time.
+ PC-2 - frequently people left the AA batteries in them when they
stopped using them.  The batteries leaked.  So always check the
battery compartment before buying one.  Leaky batteries can
cause a
great deal of damage.
The printer/cassette interface is where the flaws are.  The
printer
gears tended to wear out.  Also the rechargeable battery packs are
shot by now and are leaking.
There are some people who refurbish the printers (new
batteries and
new gears), but they will be more expensive.  Surprisingly,
you can
still purchase the pens.
+ PC-3 - Not much that I know of.  I only have 1 in my
collection and
it has no problems.  The printer even works.
+ PC-4 - No problems with the pocket computer itself that I
know of.
The printer batteries are shot by now.  Usually they don't
leak, but
the batteries are not meant to be replaced. But with some
work, the
printers can be made to work with an AC-adapter.

On Tue, Aug 7, 2018 at 8:01 PM megarat mailto:mega...@yahoo.com>> wrote:
>
> Hey folks, a recent thread here highlighted my interest in
the old
> TRS-80/Tandy Pocket Computers (rebadged from existing Casio
and Sharp
> models).  I always had a fascination with these things as a
kid, and I was
> lucky enough to own one of them for a while (a PC-5), so I'm
entertaining
> the possibility of hunting some of them down.
>
> I'm concerned, however, with how well these models age. 
Specifically the
> electrolytics (and how easy are they to replace?), the LCD
display (do
> they have a tendency to fade/bleed?), and the keypad (do
those little
> chicklet keyboards still hold up years later?).
>
> Are there any PC collectors on this list that can offer me some
> advice/guidance?  Thanks.
>
> /CAM



-- 
Ron Lauzon - rlauzon at acm dot org

   Homepage: http://webpages.charter.net/rlauzon/
   Weblog: http://ronsapartment.blogspot.com/

TRS-80 Pocket Computer 2 - TRS-80 Pocket Computer 4 - TRS-80
Model 100/102
Some people like to work on old cars.  But old computers are
cheaper
and don't require a big garage.



-- 
bkw

Re: [M100] CP/M Laptop

[Philip Avery]

Not for me Bob, but a nice offer all the same. I don't think there'd be 
much value in inspecting the ROM code as it is probably just a 
boot-strap to boot CP/M off floppy. This, and its bios, would be 
machine-specific as all CP/M bios is.


Interesting machine all the same, I was previously unaware of this CP/M 
laptop.


Philip

On 13/12/2017 8:56 AM, Bob Pigford wrote:

Looks like a useable machine for those interested in CP/M.  I will offer to 
fund up to $50 for someone in the club to purchase this thing on the condition 
that it be used by the CP/M gurus on the list.  I do not want it myself.
Bob Pigford

-Original Message-
From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of Jim Williams
Sent: Tuesday, December 12, 2017 12:00 PM
To: m100@lists.bitchin100.com
Subject: [M100] CP/M Laptop

Some people in the list have been interested in CP/M for the M100.

When I saw this CP/M laptop on ebay, I thought they might be interested in 
knowing about it, in case it could prove useful in adapting CP/M to the M100.

https://www.ebay.com/itm/Bondwell-Model-2-CP-M-CPM-Laptop-Wordstar-Supercalc-Z80-Z80L-1985/282767589338?hash=item41d642ffda:g:wF4AAOSwEEBaLX5G

I've never seen a CP/M clamshell laptop before, and this is a Bondwell, which at the time 
was a "mainstream" brand.

The keyboard layout made me think of the NEC 8201 version of the M100. I think 
it's got CP/M in ROM, so maybe if you do a ROM dump it might give some info 
that can be use in the M100 port...?

At the moment it's cheap, and while I have no use for it, I couldn't let it 
pass w/o letting folks know about it.

Re: [M100] REXCPM update.

[Philip Avery]

Thanks John, I got it working. I just check for EOF (3F) from Return 
Command. I imported Zork1.dat, that's 83KB. Zork1 boots up - yay.


Philip

On 23/11/2017 1:22 PM, John R. Hogerhuis wrote:
You can put two more bytes somewhere else in the packet, is my 
recollection.


You could take a look at LaddieAlpha source.

— John.

On Wed, Nov 22, 2017 at 4:20 PM Philip Avery <pav...@xtra.co.nz 
<mailto:pav...@xtra.co.nz>> wrote:


Well, the doc
http://bitchin100.com/wiki/index.php?title=TPDD_Base_Protocol says so
and the Directory size field is 2-bytes, but... I think you're
right as
I've read past 64KB to an apparent end of file. I've just got to study
the Return Command details more closely. Working on it.

Philip

On 23/11/2017 12:12 PM, John R. Hogerhuis wrote:
> I don’t think there’s a 64k file size limit.
>
> — John.

Re: [M100] REXCPM update.

[Philip Avery]

Well, the doc 
http://bitchin100.com/wiki/index.php?title=TPDD_Base_Protocol says so 
and the Directory size field is 2-bytes, but... I think you're right as 
I've read past 64KB to an apparent end of file. I've just got to study 
the Return Command details more closely. Working on it.


Philip

On 23/11/2017 12:12 PM, John R. Hogerhuis wrote:

I don’t think there’s a 64k file size limit.

— John.

Re: [M100] REXCPM update.

[Philip Avery]

Marvellous. Will make a great Christmas present for me :-)

I'm still at it on the CP/M software front, currently overcoming TPDD's 
64KB file size...


Philip

On 23/11/2017 10:00 AM, Stephen Adolph wrote:
Just a short note to say I have finished verification of my REXCPM 
board.  It provides up to 2MB of battery backed up SRAM in the OPTROM 
socket, and it is good for providing the needed full 64KB of SRAM for 
CP/M operation, plus provides ample space for RAM based disks.
It needs only 2 wires - one connected to the /WR signal, and one 
connected nicad juice.


In M100, you get /WR and RAMRST (which supplies nicad juice) on the 
system bus connector.

In T102, you solder wires to the adjacent RAM chip to get /WR and Vb.

..Steve

Re: [M100] TPDD protocol with CP/M

[Philip Avery]

Thanks John & Ken. No worries, I'll stick to 19,200 at this stage.

Philip

On 31/10/2017 5:08 PM, Ken Pettit wrote:

Hi Philip,

Depending on the version of NADSBox firmware you have, you can already 
tell it to switch to 76,800 baud rate.  This can be done either from a 
command line or via an extended TPDD protocol packet (version 1.16).  
From the command line, you would type one of the following:


   baud 9600
   baud 19200
   baud 38400
   baud 57600
   baud 76800
   baud 115200
   baud 153600
   baud 230400

The only catch is that if you are running this from a script, you have 
to add a small (maybe 0.5s) delay after the initial 'b' in the word 
"baud".  This is because I have a hidden command that also starts with 
'b' that I use during programming & testing of the NADSBox.  Following 
the letter 'b' too quickly by any other character causes the echo to 
be disabled until the CR is received so that my automated programming 
script doesn't receive it's command echoed back.


I would have to check the code for the TPDD protocol packet format 
version.


Ken

On 10/30/17 8:40 PM, Philip Avery wrote:
Right, I need to go over to the dark side & use command line 
interface ;-)  I shall attempt that.


What would be ultimately cool is use TBACK technology, ie a baud rate 
of 78,000 approx. As file sizes could be large (100KB or even full 
REX/Remem Ram of 2MB), this would be useful. How feasible would it be 
to add an additional command to set baud rate to this, or will the 
existing Laddiecon/mComm accept this baud setting? I presume NADSBox 
can't operate at such lofty rates? This might be something I could 
include in Import 2.0


Philip

On 30/10/2017 8:25 PM, John R. Hogerhuis wrote:
Like I said LaddieAlpha already handles 8.3 you just have to supply 
a command like option.


I think I must have added 8.3 support to DLPlus as well since it 
supports wp2.


Come to think of it NADSBox must support it? I thought I helped Ken 
test it with WP-2


— John.

Re: [M100] TPDD protocol with CP/M

[Philip Avery]

Right, I need to go over to the dark side & use command line interface 
;-)  I shall attempt that.


What would be ultimately cool is use TBACK technology, ie a baud rate of 
78,000 approx. As file sizes could be large (100KB or even full 
REX/Remem Ram of 2MB), this would be useful. How feasible would it be to 
add an additional command to set baud rate to this, or will the existing 
Laddiecon/mComm accept this baud setting? I presume NADSBox can't 
operate at such lofty rates? This might be something I could include in 
Import 2.0


Philip

On 30/10/2017 8:25 PM, John R. Hogerhuis wrote:
Like I said LaddieAlpha already handles 8.3 you just have to supply a 
command like option.


I think I must have added 8.3 support to DLPlus as well since it 
supports wp2.


Come to think of it NADSBox must support it? I thought I helped Ken 
test it with WP-2


— John.

Re: [M100] TPDD protocol with CP/M

[Philip Avery]

Thanks John & Willard. My aim is for M100 CP/M to import/export using 
common TPDD emulators of today, namely NADSBox, Laddiecon, mComm. 
Perhaps if CP/M finds traction in the M100 community, Laddiecon & mComm 
could be changed to handle 8.3 format as well. Probably a bit late to 
change the NADSBoxes out there.


Philip

On 29/10/2017 6:17 PM, Willard Goosey wrote:

On Sun, 29 Oct 2017 16:53:12 +1300
Philip Avery <pav...@xtra.co.nz> wrote:


My question: Is the TPDD protocol absolutely fixed for 6.2 filename
structure? It does have 24 spaces for the filename and CP/M uses 8.3
format, however I can't get 8.3 to work through TPDD emulation.

I've done 1 single program that does a little TPDD, so I'm hardly an
authority. For what it's worth, I suspect a real TPDD drive would be
fine with 8.3 filenames. As you said, it gives 24 spaces for the
filename and I don't think it cares much what the filename is.

The emulators, OTOH, have to map the given filenames into whatever the
local OS expects, and are going to be fussier. :-(

Willard

[M100] TPDD protocol with CP/M

[Philip Avery]

Thanks to Steve Adolph for supplying TPDD code, I can now import CP/M 
files from the outside world into M100 via TPDD emulation.


My question: Is the TPDD protocol absolutely fixed for 6.2 filename 
structure? It does have 24 spaces for the filename and CP/M uses 8.3 
format, however I can't get 8.3 to work through TPDD emulation. As I'm 
not going near the M100 directory structure, 8.3 format won't corrupt 
anything, however I expect the TPDD firmware is stuck on 6.2.


Many thanks
Philip

Re: [M100] Inaugural Tandy Assembly in Chillicothe, Ohio 7-8 October 2017 -- who is going?

[Philip Avery]

Me, me! I'm making the trip from New Zealand. But I won't be the 
furthest travelled, one is coming from Australia.
If all goes well between now & then in my development dept, I'll be 
bringing my remem-powered T102 to demonstrate CP/M on a real machine.
I'm also into Model III & 4, so look forward to meeting the podcasters & 
other guys I've met online.


Philip

On 9/09/2017 6:19 AM, John W. Linville wrote:

Who is excited about Tandy Assembly? It will be here in less than 30
days? All Tandy-branded (and related) machines are welcome!

http://www.tandyassembly.com/

See you in Chillicothe!

John

[M100] Virtual T angst in Windows 10

[Philip Avery]

Hi All

I've managed to corrupt VT on my Windows 10 machine & despite my 
attempts to remove & install it, it remains corrupted.


I was trying to be smart & have two Memory Editors open at the same time 
& now I can't get Memory Editor up at all. So I removed the VT folder 
(and all sub folders), pasted back a good VT folder (from my Vista 
machine which it works fine on) and the problem is still there, even 
after a Windows restart.


What do I have to do to delete all trace of VT, so I can paste a good 
folder down?


Thanks
Philip

Re: [M100] YouTube Upload: Selling the Model 100

[Philip Avery]

Very retro cool. I learnt a few things too.

Bought this RadioShack in-store training VHS on eBay back in April but 
finally got it cleaned up and uploaded.


Enjoy: https://youtu.be/l2TiKFBS3LY

The awkward "small package" cut at the very end is in the original video.

Re: [M100] CP/M Expander

[Philip Avery]

Gary

What I can do is send you the BIOS source & you could look at adapting that for 
NEC. In theory with Woolly taking care of the disk side of CP/M, only the 
keyboard/screen I/O, RS-232 & printer I/O will need adapting for all the 
different models. As Woolly gets developed for the various models, I do pledge 
to provide a CP/M variant for them as well.

If you'd like, *you* could tweak the BIOS and get keyboard/screen I/O going on 
the NEC, that would help development, but it won't give you CP/M yet.

PM me if you'd like to go further.

Philip

  - Original Message - 
  From: Gary Weber 
  To: m...@bitchin100.com 
  Sent: Thursday, July 27, 2017 10:35 AM
  Subject: Re: [M100] CP/M Expander


  Ken,


  While the NEC "All Ram" mode is as easy as copying whatever contents you want 
into "Bank2 RAM" and flipping a few bits on an OUT port to MAP bank #2 into ROM 
#0 address space, it seems your planned solution for the M100 may indeed also 
be very interesting for the NEC in spite of that convenience.   The reason is 
the Wifi/Flash/REX functionality.  I don't suppose you would consider a slight 
tweak to the design to support the NEC eventually?  I know the lack of the ALE 
signal on the NEC's socket led to some tricky logic that Steve had to do in 
REX3, and I was hoping that might be possible here too.


  I'm definitely interested in experimenting with CP/M on the NEC and will 
explore that with just the regular all RAM mode of course, but having a 
dedicated hardware solution that could provide main system RAM as well as full 
option ROM capability (like REX) would kind of revolutionize things a bit.


  Speaking of CP/M:  @Philip, might you be able to pass me the source image to 
which I can make the necessary tweaks for the NEC PC-8201A & 8300?


  Gary Weber
  www.web8201.net
  (and soon to be www.web8201.com!)








  On Mon, Jul 24, 2017 at 10:10 AM, Mark J. Blair  wrote:



  On Jul 24, 2017, at 10:03, Ken Pettit  wrote:


  I was looking at using the ATWINC1500 module.  This is WiFi only and no 
Bluetooth.  The module is *just* small enough that it can fit on a PCB within 
the OptROM socket, provided it is a stacked PCB on top of the main Woolly PCB.


Wow, that little guy is even smaller than the ESP-WROOM-32 module!


-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

[M100] CP/M Expander

[Philip Avery]

Great Ken.

Changing thread to "CP/M Expander"

Is it really possible to fit all that on OptROM form factor? Would it 
need a heap of wires soldered to motherboard?


Philip

On 12/07/2017 7:14 AM, Ken Pettit wrote:
Downloaded the remem.bin file and ran CP/M under VT 1.7 on Linux. 
Works great!


Now I just need to get my super-cool OptROM form-factor FPGA + 
Microcontroller + SRAM + WiFi + Flash board I want to build done. So 
much to do ... so little time.


Ken

On 7/8/17 8:28 PM, John R. Hogerhuis wrote:

Files are hosted.

http://bitchin100.com/files/m10x/mtcpm/remem.bin
http://bitchin100.com/files/m10x/mtcpm/Instructions%20for%20M100%20CPM%20v1.0.pdf

I just need to make a page for it or replace the contents of the 
MTCPM wiki page.


-- John.

Re: [M100] CP/M has arrived for the M100

[Philip Avery]

Hi Roger

Well there's really only the serial & printer ports remaining. All other 
I/O is done. I thought I'd wait until any hardware is developed to do 
those. I've fully implemented interrupts, while CP/M doesn't use them - 
we can, & make use of the system ROM routines for I/O. After Import & 
Export utilities, I'm pretty keen to get it working on my real M100 with 
Remem.


This is all my code, I started afresh from the mtcpm effort. However I 
will release it after any hardware is developed & it is a fully working 
system.


Philip

On 11/07/2017 5:18 PM, roger wrote:

Phil,

I was thinking more of the bios calls. The drivers for hardware.

Also, will the source code be released?

Roger



Skickat från min Samsung Galaxy-smartphone.

 Originalmeddelande ----
Från: Philip Avery <pav...@xtra.co.nz>
Datum: 2017-07-09 22:54 (GMT+01:00)
Till: m...@bitchin100.com
Rubrik: Re: [M100] CP/M has arrived for the M100

Hi Roger

I did those as part of the installation. Starting off with the 
assembly listing of CP/M 2.2, I was able to build it up one step at a 
time. That's different than the traditional Regeneration process of 
pulling the binary down from a floppy disk.


Philip

On 9/07/2017 10:45 PM, roger wrote:
Have you got all the cbios calls working or do you want help writing 
then?


Roger


Skickat från min Samsung Galaxy-smartphone.

 Originalmeddelande ----
Från: Philip Avery <pav...@xtra.co.nz>
Datum: 2017-07-09 01:33 (GMT+01:00)
Till: m100 <m100@lists.bitchin100.com>
Rubrik: [M100] CP/M has arrived for the M100

Well, it's arrived as far as Virtual T. It will need a new hardware
device developed to use on a real M100.

Over a decade in the making (started in 2006), I present 64K CP/M 2.2
running in VT with Remem enabled. The Remem is used as RAMdisk, to
emulate two disk drives of about 241KB each.

To share this with the group, it would be easiest to share my VT
remem.bin (6MB). Together with my instructions in pdf, you'll be on the
air very quickly.
John Hogerhuis: May I send this to you to host on the bitchin.com site?
Ken Pettit: Will my windows variant of remem.bin work with all the other
variants of VT 1.7?

While in theory it will work on a real M100 with Remem, and with
additional software could use a NADSBox to talk to the modern world (SD
card) - I think as these two items aren't readily available, it would
best if a new hardware solution is developed. Now that it's working in
the M100 environment, it's relatively straightforward to modify the BIOS
to work with any RAMdisk, other storage device or even a wireless 
solution.


Thanks to Mike Stein for some beta testing.

Philip

Re: [M100] Alternative he for cpm

[Philip Avery]

Any of those would solve the 64K RAM issue, even REX2 as it stands I 
believe. What about RAMdisk/Disk & transferring to the outside world?


Mike Stein pointed me to some micro SD adaptions out there, such as 
this:  https://www.4dsystems.com.au/product/uVGA_III/


Could an OptROM sized board accommodate something like that?

Philip
/Dinosaur IT: Back where modern IT fears to tread!/

On 10/07/2017 12:24 AM, Stephen Adolph wrote:

Building on Philip's success i could suggest

We can revive an old hw design for external ram based storage...the 
rampac ... which plugs into the system bus.  Easy to make.  Works on 
m100 t102 t200.


Or A variant of quad could provide ram for both memory banks plus ram 
disk.  M100 only.


Lastly rather than switch  ram from an m100 bank to a cpm bank  one 
could copy away the m100 ram image to a holding spot in lower memory.  
That would allow only bank switching in the lower 32k.  The upper 32k 
would always be the internal m100 ram.  This is an improvement since 
it makes the memory handling simpler.

Re: [M100] CP/M has arrived for the M100

[Philip Avery]

Thanks Gary

Are you meaning to use CP/M on a real NEC? That would depend on whether 
any new hardware developed will apply to the NEC. Once it works on a 
real M100, then the BIOS changes required for NEC would be relatively 
minor I should think.


I'm curious as to what sort of CP/M programs you found useful on your NEC?

Philip
/Dinosaur IT: Back where modern IT fears to tread!/

On 10/07/2017 5:21 AM, Gary Weber wrote:

Philip,

It is an amazing thing you have done.

I used to have an 8201A with the PIC-Disk system that provided a full 
blown CP/M operating system.   After losing that original computer and 
disk system to theft, I was left without access to 20 disks of CP/M 
files and programs and back-ups of my 8201A memory images for quite a 
while.  I did end up resolving the situation by the use of some 
software called 22Disk, which let me gain access to the disks on an 
MS-DOS machine.


But, I still had all these CP/M programs that were unusable to me.  
And now, I am wondering, would it be a relatively easy operation to 
take your M100 + CP/M solution  and port it over to the NEC 
PC-8201A/8300 platform?  Hoping it may just be a few differences in 
BIOS calls and I/O port mappings.  This is definitely something I'd 
want to try to achieve.


THanks for your work on this!
Gary


On Sun, Jul 9, 2017 at 3:45 AM, roger <ro...@ammeberg.com 
<mailto:ro...@ammeberg.com>> wrote:


Have you got all the cbios calls working or do you want help
writing then?

Roger


Skickat från min Samsung Galaxy-smartphone.

 Originalmeddelande ----
Från: Philip Avery <pav...@xtra.co.nz <mailto:pav...@xtra.co.nz>>
Datum: 2017-07-09 01:33 (GMT+01:00)
Till: m100 <m100@lists.bitchin100.com
<mailto:m100@lists.bitchin100.com>>
Rubrik: [M100] CP/M has arrived for the M100

Well, it's arrived as far as Virtual T. It will need a new hardware
device developed to use on a real M100.

Over a decade in the making (started in 2006), I present 64K CP/M 2.2
running in VT with Remem enabled. The Remem is used as RAMdisk, to
emulate two disk drives of about 241KB each.

To share this with the group, it would be easiest to share my VT
remem.bin (6MB). Together with my instructions in pdf, you'll be
on the
air very quickly.
John Hogerhuis: May I send this to you to host on the bitchin.com
<http://bitchin.com> site?
Ken Pettit: Will my windows variant of remem.bin work with all the
other
variants of VT 1.7?

While in theory it will work on a real M100 with Remem, and with
additional software could use a NADSBox to talk to the modern
world (SD
card) - I think as these two items aren't readily available, it would
best if a new hardware solution is developed. Now that it's
working in
the M100 environment, it's relatively straightforward to modify
the BIOS
to work with any RAMdisk, other storage device or even a wireless
solution.

Thanks to Mike Stein for some beta testing.

Philip

Re: [M100] CP/M has arrived for the M100

[Philip Avery]

Hi Roger

I did those as part of the installation. Starting off with the assembly 
listing of CP/M 2.2, I was able to build it up one step at a time. 
That's different than the traditional Regeneration process of pulling 
the binary down from a floppy disk.


Philip

On 9/07/2017 10:45 PM, roger wrote:

Have you got all the cbios calls working or do you want help writing then?

Roger


Skickat från min Samsung Galaxy-smartphone.

 Originalmeddelande 
Från: Philip Avery <pav...@xtra.co.nz>
Datum: 2017-07-09 01:33 (GMT+01:00)
Till: m100 <m100@lists.bitchin100.com>
Rubrik: [M100] CP/M has arrived for the M100

Well, it's arrived as far as Virtual T. It will need a new hardware
device developed to use on a real M100.

Over a decade in the making (started in 2006), I present 64K CP/M 2.2
running in VT with Remem enabled. The Remem is used as RAMdisk, to
emulate two disk drives of about 241KB each.

To share this with the group, it would be easiest to share my VT
remem.bin (6MB). Together with my instructions in pdf, you'll be on the
air very quickly.
John Hogerhuis: May I send this to you to host on the bitchin.com site?
Ken Pettit: Will my windows variant of remem.bin work with all the other
variants of VT 1.7?

While in theory it will work on a real M100 with Remem, and with
additional software could use a NADSBox to talk to the modern world (SD
card) - I think as these two items aren't readily available, it would
best if a new hardware solution is developed. Now that it's working in
the M100 environment, it's relatively straightforward to modify the BIOS
to work with any RAMdisk, other storage device or even a wireless 
solution.


Thanks to Mike Stein for some beta testing.

Philip

Re: [M100] CP/M has arrived for the M100

[Philip Avery]

After I posted that comment on Small C, I realised there's undoubtedly a 
CP/M version of Small-C. An advantage of doing it in CP/M instead of 
native M100 mode is you have about 55KB in CP/M to host the compiler, 
source & output files, whereas in M100 mode, less than 32KB. Unless of 
course you went the Optrom route, but that would need a rewrite of Small-C.


In fact you can have more than 55KB, you can clobber the CCP (which 
programs like DDT.COM and MBASIC do to give them max RAM), this would 
give you 57KB. But wait... there's even more! You could even clobber the 
BDOS and access BIOS directly. This way you can still do screen/keyboard 
IO, plus disk sector-level editing. This would free up 61KB! What you 
could do with all that? ;-)


These RAM sizes should stay the same with CP/M on a real M100 - I've 
kept some space for extra hardware routines.


Philip

On 9/07/2017 5:20 PM, Willard Goosey wrote:

On Sun, 9 Jul 2017 16:37:10 +1200
Philip Avery <pav...@xtra.co.nz> wrote:


Not to detract from Willard's Small-C efforts, but whose is going to
be first to get BDS-C (or any C) running on M100 CP/M?


I dunno man. I've done all my CP/M C stuff under C/80. I was *planning*
on converting to BDS-C... But that never actually seemed to
happen. :-( C/80 is a dreadful hack, but it works, and I do like that
it talks to m80... What should have been a brief exercise with
TDL-link turned into a nightmare that's left me suspicious of any
linker except Microsoft's.  Which is a very VERY weird feeling...

Willard

Re: [M100] CP/M has arrived for the M100

[Philip Avery]

Thanks for the congrats, guys.

Once I've got some decent Import/Export routines done, I'll make up some 
disk images featuring languages, adventures (Zork for example), games 
(if there are many out there). These could be also be hosted on 
Bitchin100.com as separate remem.bin files, so to be swapped into VT.


Not to detract from Willard's Small-C efforts, but whose is going to be 
first to get BDS-C (or any C) running on M100 CP/M?


Philip

On 9/07/2017 4:25 PM, John R. Hogerhuis wrote:

I can't say what all will work, but for inspiration:

http://www.retroarchive.org/cpm/

-- John.

Re: [M100] CP/M has arrived for the M100

[Philip Avery]

You understand correctly Steve.

Map 2 is the same as Map 1 except that it brings in 1KB of Remem at a 
time which looks like a disk Track to CP/M. I know where my disk 
read/write routines are and I know where the 1KB block appears, so it's 
quite safe.


I've tailored the BIOS to suit Remem in this case. CP/M works with 
128-byte sectors, so I have 8 sectors per track and 256 tracks per disk, 
giving 256KB disks. However it's common to block & de-block sectors in 
the BIOS to suit any hardware requirement.


Philip

On 9/07/2017 2:54 PM, Stephen Adolph wrote:

Thanks Philip.

So if I understand
. Lower 32k space has either m100 Rom or ram.
. Upper 32k space has a single ram block.

I guess you access the disks using the fine grained ram access?  1kb 
at a time?



On Saturday, July 8, 2017, Philip Avery <pav...@xtra.co.nz 
<mailto:pav...@xtra.co.nz>> wrote:


Thanks Steve

Yes, bank switching to std ROM for interrupts. Also means ROM
calls from Basic, C or any language can easily be made as long as
it's finally despatched from himem (above 8000H).

A memory map should answer your queries:
0- 7FFFH  M100 ROM
 8000H  -  H  CPM RAM (0-32KB)
1H  -  17FFFH  CPM RAM (32KB - 64KB)
18000H  -  57FFFH  Disk A
58000H  -  97FFFH  Disk B

Philip



On 9/07/2017 11:53 AM, Stephen Adolph wrote:

Wow!  Phil you've been busy!

I'll have to think about what you're doing with the memory banks.
I assume you are also in all ram mode?  Are you bank switching to
std Rom?

In terms of hardware... not easy to map to rex. Rex2 maybe.

But one could imagine a hybrid that uses the rex technique for
writing to a read only socket to enable  at least 3 banks of ram.



On Saturday, July 8, 2017, Philip Avery <pav...@xtra.co.nz
<javascript:_e(%7B%7D,'cvml','pav...@xtra.co.nz');>> wrote:

Well, it's arrived as far as Virtual T. It will need a new
hardware device developed to use on a real M100.

Over a decade in the making (started in 2006), I present 64K
CP/M 2.2 running in VT with Remem enabled. The Remem is used
as RAMdisk, to emulate two disk drives of about 241KB each.

To share this with the group, it would be easiest to share my
VT remem.bin (6MB). Together with my instructions in pdf,
you'll be on the air very quickly.
John Hogerhuis: May I send this to you to host on the
bitchin.com <http://bitchin.com> site?
Ken Pettit: Will my windows variant of remem.bin work with
all the other variants of VT 1.7?

While in theory it will work on a real M100 with Remem, and
with additional software could use a NADSBox to talk to the
modern world (SD card) - I think as these two items aren't
readily available, it would best if a new hardware solution
is developed. Now that it's working in the M100 environment,
it's relatively straightforward to modify the BIOS to work
with any RAMdisk, other storage device or even a wireless
solution.

Thanks to Mike Stein for some beta testing.

Philip

Re: [M100] CP/M has arrived for the M100

[Philip Avery]

Thanks Ken. Only possible because of Virtual T - I wouldn't have a 
chance in hell without it.


Hardware: I'm thinking a 64KB of RAM for CP/M and 512KB say for a 
RAMdisk. 64KB would make it easy to switch in & out CP/M & return to 
M100 mode, but it could be done like REX2 and just switch in 32KB RAM 
into OptROM space. It would also be fine if the 64KB was part of the 
512KB, just a little less disk space. RAMDisk is seriously good. M100 
CP/M boots up MBASIC way faster than my Model 4 with hard disk. It will 
make for a very nice CP/M system as far as file access speed.


Wireless would be very convenient to transfer files to the outside world 
and essentially change disk images by.  If all this was achieved on a 
REX-type board (OptROM) & be contained within the M100 case, I would say 
that would make for a very elegant solution.


/See - that's why it's taken 10 years to do CP/M - had to wait for the 
hardware technology to catch up!//;-)

/
Philip



On 9/07/2017 11:53 AM, Ken Pettit wrote:

Hi Philip,

First of all, WOW!  Excellent work!  I wasn't aware you had been 
working on this silently in the background.


Yes, the remem.bin binary should work with any variant of VT 1.7. The 
only real compile differences between platforms is the GUI, and most 
of that is hidden by the FLTK libraries.


Funny you mention we need a new hardware solution.  Over the past two 
weeks, I actually resurrected my old PADS layout tool based NADSBox 
design and started porting it over to Allegro.  My PADS license has 
long since expired but I have an up-to-date Cadence Allegro license.  
The thought was to do another run of NADSBoxes. The only real change 
needed is to select a new / better SD card socket.


I also have and idea for a project that would replace REX (sorry 
Steve), and would allow 64K All-RAM mode in a real M100 without ANY 
hardware changes using the OptROM socket only.  It would also provide 
REX functionality.  The only real concern I have is the amount of 
juice it would consume from the battery.  It would also have 
integrated WiFi.  I already selected parts and even started an Orcad 
schematic for it.


Ken

On 7/8/17 4:33 PM, Philip Avery wrote:
Well, it's arrived as far as Virtual T. It will need a new hardware 
device developed to use on a real M100.


Over a decade in the making (started in 2006), I present 64K CP/M 2.2 
running in VT with Remem enabled. The Remem is used as RAMdisk, to 
emulate two disk drives of about 241KB each.


To share this with the group, it would be easiest to share my VT 
remem.bin (6MB). Together with my instructions in pdf, you'll be on 
the air very quickly.

John Hogerhuis: May I send this to you to host on the bitchin.com site?
Ken Pettit: Will my windows variant of remem.bin work with all the 
other variants of VT 1.7?


While in theory it will work on a real M100 with Remem, and with 
additional software could use a NADSBox to talk to the modern world 
(SD card) - I think as these two items aren't readily available, it 
would best if a new hardware solution is developed. Now that it's 
working in the M100 environment, it's relatively straightforward to 
modify the BIOS to work with any RAMdisk, other storage device or 
even a wireless solution.


Thanks to Mike Stein for some beta testing.

Philip

Re: [M100] CP/M has arrived for the M100

[Philip Avery]

Thanks Steve

Yes, bank switching to std ROM for interrupts. Also means ROM calls from 
Basic, C or any language can easily be made as long as it's finally 
despatched from himem (above 8000H).


A memory map should answer your queries:
0- 7FFFH  M100 ROM
 8000H  -  H  CPM RAM (0-32KB)
1H  -  17FFFH  CPM RAM (32KB - 64KB)
18000H  -  57FFFH  Disk A
58000H  -  97FFFH  Disk B

Philip



On 9/07/2017 11:53 AM, Stephen Adolph wrote:

Wow! Phil you've been busy!

I'll have to think about what you're doing with the memory banks.
I assume you are also in all ram mode?  Are you bank switching to std Rom?

In terms of hardware... not easy to map to rex. Rex2 maybe.

But one could imagine a hybrid that uses the rex technique for writing 
to a read only socket to enable  at least 3 banks of ram.




On Saturday, July 8, 2017, Philip Avery <pav...@xtra.co.nz 
<mailto:pav...@xtra.co.nz>> wrote:


Well, it's arrived as far as Virtual T. It will need a new
hardware device developed to use on a real M100.

Over a decade in the making (started in 2006), I present 64K CP/M
2.2 running in VT with Remem enabled. The Remem is used as
RAMdisk, to emulate two disk drives of about 241KB each.

To share this with the group, it would be easiest to share my VT
remem.bin (6MB). Together with my instructions in pdf, you'll be
on the air very quickly.
John Hogerhuis: May I send this to you to host on the bitchin.com
<http://bitchin.com> site?
Ken Pettit: Will my windows variant of remem.bin work with all the
other variants of VT 1.7?

While in theory it will work on a real M100 with Remem, and with
additional software could use a NADSBox to talk to the modern
world (SD card) - I think as these two items aren't readily
available, it would best if a new hardware solution is developed.
Now that it's working in the M100 environment, it's relatively
straightforward to modify the BIOS to work with any RAMdisk, other
storage device or even a wireless solution.

Thanks to Mike Stein for some beta testing.

Philip

[M100] CP/M has arrived for the M100

[Philip Avery]

Well, it's arrived as far as Virtual T. It will need a new hardware 
device developed to use on a real M100.


Over a decade in the making (started in 2006), I present 64K CP/M 2.2 
running in VT with Remem enabled. The Remem is used as RAMdisk, to 
emulate two disk drives of about 241KB each.


To share this with the group, it would be easiest to share my VT 
remem.bin (6MB). Together with my instructions in pdf, you'll be on the 
air very quickly.

John Hogerhuis: May I send this to you to host on the bitchin.com site?
Ken Pettit: Will my windows variant of remem.bin work with all the other 
variants of VT 1.7?


While in theory it will work on a real M100 with Remem, and with 
additional software could use a NADSBox to talk to the modern world (SD 
card) - I think as these two items aren't readily available, it would 
best if a new hardware solution is developed. Now that it's working in 
the M100 environment, it's relatively straightforward to modify the BIOS 
to work with any RAMdisk, other storage device or even a wireless solution.


Thanks to Mike Stein for some beta testing.

Philip