Re: [M100] I killed my M100s

[Stephen Adolph]

For the one that beeps, and has led flicker...
If beep then 5V is probably up.
If no lcd then check -5v.

I suspect a problem with -5v because no LCD and the low voltage led might
suggest that -5v is struggling and pulling a lot of current.

If you are lucky when swapping caps, the pcb connections stay intact.  If
unlucky, you can break connections when you pull the original cap.

I rely on my microscope to really see what is going on.

Good luck.

Steve



On Sunday, May 19, 2024, Jim Williams  wrote:

> I recapped my two M100s.
>
> The first one required some flux-cleaning and then worked fine. So I put
> it on its shelf, and recapped the second one.
> After, the second one was completely dead; no battery light, no sign of
> life whatsoever.
> I took it apart again and thoroughly cleaned it with alcohol because I'd
> been told that excessive flux could be an issue.
> I also checked all the capacitors and the battery to ensure that they were
> all soldered properly. They all appear to be so.
>
> After reassembly, it was still just as dead.
> So I returned to my first M100, intending to install a RexCPM into it.
> Before doing so, I flipped it on, and the low battery light came on... and
> nothing else.
> I replaced the batteries with new ones... and all that happened was the
> low battery light flickered as I turned it off.
> I adjusted the contast knob, just in case it was something that simple,
> but to no avail.
>
> So I put it back on its shelf to deal with another day, saddened that I
> now have no functioning M100s; that I killed them.
> A few hours later I took it off the shelf... still the battery light
> flicker, but, I accidentally pressed several of the keys.
> Whenever I press a key, I get a beep.
>
> Can anyone with more experience advise me on how to further investigate
> what could be wrong with my machines? At this point, I'll settle for one
> working.
>
>

Re: [M100] LaddieAlpha update

[Stephen Adolph]

Thanks John for the continued support!  Much appreciated!!!

On Tuesday, April 30, 2024, Will Senn  wrote:

> John,
>
> Awesome. It'll be a while before I spin my environment back up (weeks),
> but when I do, I'll be glad for the changes.
>
> Will
>
> On 4/30/24 6:13 PM, John R. Hogerhuis wrote:
>
>> I deployed a new version of LaddieAlpha based on work I did with Steve to
>> include a CP/M support mode. In this special mode, LaddieAlpha will serve
>> up 8.3 filenames as expected by Model T CP/M tools.
>>
>> I updated the documentation as well with current options. Including a
>> link to information on the TPDD over TCP mode useful with Wimodem type
>> devices.
>>
>> https://bitchin100.com/wiki/index.php?title=LaddieCon#LaddieAlpha
>>
>> Thanks to Steve for testing and analysis.
>>
>> Let me know if you have any trouble with the new version.
>>
>> -- John.
>>
>
>

Re: [M100] How to re-enable rexsharp after cold restart

[Stephen Adolph]

Wayne you should just power off, power on again, and then do the call.

Steve

On Sunday, April 21, 2024, Wayne Venables  wrote:

> Hey everyone,
>
> I had to cold restart my M102 due to a hard crash.  I have rexsharp
> installed and I have a few ROMs.  But I don't know to re-enable rex manager
> now.  Doing CALL63012 just re-enabled the last selected ROM (TS-DOS).
>
> I looked on the site but I couldn't find any info on what to do next.
>
> Thanks,
>
>
>

Re: [M100] Windows 98 solution for TPDD emulation

[Stephen Adolph]

Kurt,
I was able to download Python 2.5.3 which did install in Windows 98.
But as you suggest, serial port did not seem to be available.
I'll look around.
Steve

On Sun, Apr 21, 2024 at 10:36 AM Kurt McCullum  wrote:

> Steve,
>
> It's a long shot, but if you can get get Python running on Win98 WITH the
> serial port support, then the Python version of mComm might work. Lot's of
> unknows in that suggestion though.
>
> Kurt
>
> On Sun, Apr 21, 2024, at 6:54 AM, Stephen Adolph wrote:
>
> hi everyone,
> I recently went through an activity to build a Pentium 4 based system to
> act as a "tweener", giving me a machine that can straddle both ethernet/IP
> based remote file storage, and legacy floppy support (5.25, 3.5 floppies).
> In addition it runs old programs like Laplink.  This machine uses Windows
> 98.
>
> Question is - what would be a good way to emulate a TPDD with this
> hardware?
>
> I don't think Desklink will work; the processor is too fast.
> I don't think I can run LaddieAlpha since Mono does not install on Windows
> 98.
>
> I realize I could dual boot and run a somewhat modern linux, and that
> would give me Mono/LaddieAlpha.
>
> But, is there a way to get something running on Windows 98?
>
> thanks.
> Steve
>
>
>

Re: [M100] Windows 98 solution for TPDD emulation

[Stephen Adolph]

So, yes, desklink did work and seems ok.  So that's good.  works for TS-DOS.
thanks for that reminder!

Ideally, for CP/M use as well, ability to work with 8.3 file names is
useful.
Desklink definitely doesn not like 8.3.

LaddieCon supports 8.2; I have it installed now.  LaddieCon does respond to
TPDD protocol, but it crashes after it provides directory information.
Some security complaint, did not record the error messages, but I can do.

NADSbox is ok with 8.3 file names.
Not sure about Backpack.


Perhaps a python approach would be good, since I could edit the python code
to be 8.3 and 6.2 format tolerant if not already.

I'll give that a try.

[M100] Windows 98 solution for TPDD emulation

[Stephen Adolph]

hi everyone,
I recently went through an activity to build a Pentium 4 based system to
act as a "tweener", giving me a machine that can straddle both ethernet/IP
based remote file storage, and legacy floppy support (5.25, 3.5 floppies).
In addition it runs old programs like Laplink.  This machine uses Windows
98.

Question is - what would be a good way to emulate a TPDD with this hardware?

I don't think Desklink will work; the processor is too fast.
I don't think I can run LaddieAlpha since Mono does not install on Windows
98.

I realize I could dual boot and run a somewhat modern linux, and that would
give me Mono/LaddieAlpha.

But, is there a way to get something running on Windows 98?

thanks.
Steve

Re: [M100] mvt100 and the pc terminal

[Stephen Adolph]

It works like the DVI works.

Menu in the LCD.
Apps on the "screen" as defined by the basic command.

Option roms are probably incompatible.

So the utility is really maximized around cpm.  And Turbo Pascal but as you
know that is yet more churn.

Thx
Steve


On Monday, March 18, 2024, Will Senn  wrote:

> Cool, so I can put my m100 in front of my monitor and use my monitor
> running windows in a vm running vt 52 and treat it like a giant 80x25
> display - I'm in. I'd sure like to use my fancy keyboard and leave my M100
> "over there", but this will work, too.
>
> If I'm understanding things, though, I can't do TPDD stuff while the
> monitor's displaying unless I work out the cassette-serial half-duplex
> thing...
>
> It seems like I can only do this in BASIC? cuz that's where I typed SCREEN
> 1. If I press F8, it prints MENU and takes me to the menu, but...
>
> [insert short rant here]
> oh, wait, I was going to test it but "Updates are underway..." in Windows
> how can y'all stand it?! The good news is, "You're 96% there..." still...
> ok, finally, windoze finished whatever it was doing..
> [/done ranting 3 minutes or so later]
>
> then, when I run TEXT, I see the < character and I can type, but I don't
> see any echo. Then, back in basic, I can load what I wrote in TEXT and it's
> there and I can see it...
>
> Later,
>
> Will
>
> On 3/18/24 9:05 PM, Brian K. White wrote:
>
>> MVT100 the hardware is the serial-to-video part of an ordinary serial
>> terminal, used as a display output only, no keyboard, one-way communication
>> from host to screen, no keyboard to host. And just the electronics, ie
>> instead of having a screen, it has a vga out.
>> https://bitchin100.com/wiki/index.php?title=VT100
>>
>> It's a subset of an ordinary serial terminal, so you could do the same
>> thing with any serial terminal or terminal emulator, except what's special
>> about it is it renders the M100-specific terminal codes and maybe uses the
>> font from the Disk/Video Interface (I don't remember).
>>
>> And in addition to regular rs-232 it also supports a special serial
>> interface using a hardware mod to the barcode port on a M100 which can
>> output ttl serial at higher baud rates, and doesn't occupy the regular
>> serial port uart or the physical port, so the regular serial port on the
>> 100 can be used at the same time as the serial display.
>> https://bitchin100.com/wiki/index.php?title=BCR_TTL_SERIAL_HACK
>>
>>
>> The desktop application is a terminal emulator where the terminal it's
>> emulating is the MVT100 that's all. But since it's display-only, you still
>> have to use the keyboard on the 100 itself. Like the mvt100, it's 1/2 of a
>> terminal just used as a display.
>>
>>
>> On the 100, it needs the driver software Steve provides, which works the
>> same way the Disk/Video Interface does, using the CRT: hooks in the main
>> rom.
>> https://bitchin100.com/wiki/index.php?title=Integrated_VT100_driver
>>
>> I can't find where the rom hooks are documented.
>> The hand-wavy no-actual-details explanation is the main rom has some
>> special hook addresses that it will read or jump to at various times, and
>> those addresses normally just contain a no-op or a return instruction so
>> they do nothing. The addresses are in ram space, so you can write to them.
>> So you install some code somewhere in ram, and write the address to your
>> code into the hook address. Now when the main rom reads or jumps to that
>> hook, it runs your code instead of doing nothing.
>>
>> One of those is the CRT: output. The Disk/Video Interface installs some
>> driver code that makes the CRT: interface actually do something (sends data
>> over the system bus to the DVI), and adds some functions to BASIC to use it.
>>
>>
>

Re: [M100] mvt100 and the pc terminal

[Stephen Adolph]

One way only.
Mvt100 either as the hardware adapter or the pc app is for display only.
Does not solve the issue of cpm over serial.

Having said that, doesn't m100cpm support console over serial?  I thought
it did same as any cpm.

Steve

On Monday, March 18, 2024, Will Senn  wrote:

> Well, that's an exercise in wild. I'm not sure if I track with the
> discussion, but here's what I did:
>
> in Windoze:
>
> Downloaded the MVT100 app for the desktop (doesn't work in wine after
> all). Ran it from my Win 11 VM, captured the serial port, prolific maps it
> to COM3, fine. Then I started up the terminal and it was blank screen, but
> looked fine. I hit F6 and entered COM3, no errors, great.
>
> In M100:
> used TEENY to bring over VT100.CO and loaded it. Looks just like before.
> Read here, read there, and then:
> SCREEN 1
> on the M100, this means no LCD changes... eventually figured out to look
> over to my desktop, sure enough, lots of output on the terminal. Great. So,
> if I type on the M100, I get output on my giant 32 inch display, yay.
>
> How to type on the terminal? I tried stuff with F5, but haven't gotten the
> magic sauce right yet. Is it one way only?
>
> Thanks,
>
> Will
>
> On 3/18/24 8:21 PM, Stephen Adolph wrote:
>
> So does rexcpm.
> Connect rs232 to pc port and display 80x24 like a dvi.
> Cntl V at menu to configure!
>
>
> On Monday, March 18, 2024, John R. Hogerhuis  wrote:
>
>> Rex supports it. Or I think you need the vt100 driver software  from this
>> page:
>>
>>
>> https://bitchin100.com/wiki/index.php?title=VT100
>>
>> The point of this is to give you a bigger more readable display.
>>
>> A subset of the DVI's functionality.
>>
>> -- John.
>>
>> On Mon, Mar 18, 2024, 5:07 PM Will Senn  wrote:
>>
>>> I'm a little confused about the MVT100...
>>>
>>> on this page:
>>>
>>> https://bitchin100.com/wiki/index.php?title=MVT100_Desktop_Application
>>>
>>> It sounds like it's a terminal emulator for connecting to the M100 over
>>> serial. But somewhere else I saw it as some kind of adapter to talk to VGA.
>>> I'm guessing it's both - adapter gadget provides the VGA out thing and
>>> provides a server for the pc terminal app? I downloaded the software and it
>>> runs fine on linux under wine (to the degree that it appears to start up
>>> and not crash. I couldn't figure out how to get it to talk to my m100... so
>>> I'm guessing I need the hardware gadget in addition to my rexcpm to get it
>>> working?
>>>
>>> Thanks,
>>>
>>> Will
>>>
>>
>

Re: [M100] mvt100 and the pc terminal

[Stephen Adolph]

So does rexcpm.
Connect rs232 to pc port and display 80x24 like a dvi.
Cntl V at menu to configure!


On Monday, March 18, 2024, John R. Hogerhuis  wrote:

> Rex supports it. Or I think you need the vt100 driver software  from this
> page:
>
>
> https://bitchin100.com/wiki/index.php?title=VT100
>
> The point of this is to give you a bigger more readable display.
>
> A subset of the DVI's functionality.
>
> -- John.
>
> On Mon, Mar 18, 2024, 5:07 PM Will Senn  wrote:
>
>> I'm a little confused about the MVT100...
>>
>> on this page:
>>
>> https://bitchin100.com/wiki/index.php?title=MVT100_Desktop_Application
>>
>> It sounds like it's a terminal emulator for connecting to the M100 over
>> serial. But somewhere else I saw it as some kind of adapter to talk to VGA.
>> I'm guessing it's both - adapter gadget provides the VGA out thing and
>> provides a server for the pc terminal app? I downloaded the software and it
>> runs fine on linux under wine (to the degree that it appears to start up
>> and not crash. I couldn't figure out how to get it to talk to my m100... so
>> I'm guessing I need the hardware gadget in addition to my rexcpm to get it
>> working?
>>
>> Thanks,
>>
>> Will
>>
>

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

[Stephen Adolph]

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, 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] retroprinter and the m100

[Stephen Adolph]

Bit 2 shorted to bit 3?

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

> I tried every config setting... twice or more :).
>
> It's super consistent in that bits 2, and 3, counting from zero, from the
> least significant bits, are having some kind of issue (they aren't always,
> zero, or one, but they are always the bits that are wrong and they are
> consistently wrong (of the 40 chars or so I tested):
>
> <0x7f> vs w
> 0111
> 01110111
> 1000 (b3 1->0)
>
> \ vs T
> 01011100
> 01010100
> 1000 (b3 1->0)
>
> 4 vs <
> 00110100
> 0000
> 1000 (b3 0->1)
>
> 5 vs =
> 00110101
> 0001
> 1000 (b3 0->1)
> 6 vs >
> 00110110
> 0010
> 1000 (b3 0->1)
>
> 7 vs ?
> 00110111
> 0011
> 1000 (b3 0->1)
>
> 8 vs <
> 00111000
> 0000
> 0100 (b3 0->1)
>
> 9 vs =
> 00111001 (b3 0->1)
> 0001
> 0100
>
> Weird, huh? Anybody seen anything like it? Can I troubleshoot it with a
> multimeter?
>
> Will
>
>
>
>
> On 3/17/24 2:13 PM, Will Senn wrote:
>
> Yep, it's consistent. It took me a while to make some progress on this. I
> tried redoing the Centronics side of the cable, and here's my source vs
> what the pi sees:
>
> 10 PRINT "Hello, world!"
> 20 GOTO 10
>
> 10 PRMN\ "Lmllo, orll!"
> 20 OO\O 10
>
> I'm not sure how to troubleshoot...
>
> I found this in the retroprinter handbook:
>
> Missing Characters or Repeated Characters:
> This is generally because the equipment sending the printout is using
> a specific timing mechanism and not necessarily adopting the correct
> Centronics signal methods for acknowledgement of data.
> We have added the following configuration options to help address
> this:
> /root/config/handshaking
> This allows you to specify how the handshaking is handled between
> the computer and the Retro-Printer. This can help overcome issues
> with lost characters or repeated characters when the equipment
> misses the busy / acknowledge signals.
> The parameter takes a value between 0 and 4.
> 0 = Busy On (for 5ms), Busy Off, Ack On (for signal time), Ack Off
> 1 = Ack On (for signal time), Busy On, Ack Off, Busy Off
> 2 = Busy On (for 5ms), Ack On (for signal time), Busy Off, Ack Off
> 3 = Ack On (for signal time), Ack Off, Busy On (for 5ms), Busy Off
> 4 = Busy On and Ack On (for signal time), Ack Off and Busy Off
> Default is 0
>
> Any idea how the M100 handshakes?
>
> Will
>
>
> On 3/17/24 7:18 AM, Mike Stein wrote:
>
> Is it consistent, i.e. do you always get the same garbled output for a
> given file?
>
> At a fast glance it looks like bits 2 and/or 3 are being dropped; have you
> checked the computer to Pi cable and connectors?
>
> m
>
> On Sun, Mar 17, 2024 at 2:14 AM Will Senn  wrote:
>
>> I am finally coming back around to this. I bought a retroprinter a year
>> and half ago or so and shelved it out of frustration. Now, I know a lot
>> more about this sorta stuff and so I pulled it out, updated the software to
>> latest and tried to get it working.
>>
>> The PI prints a test page fine, but it won't print anything I send it
>> from the M100. After hours of troubleshooting, it appears that whatever
>> codes the pi is sending aren't DMP-15, EPSON ESC/P or Plain Text codes...
>> When I do llist, I see the data coming across to the retroprinter and have
>> set up a file to capture, but I can't find anything that will make sense of
>> the data.
>>
>> Here's a sample:
>>
>> 10 PRMN\ "lmllo"
>> 1= RMS\ORM =0>NORM=0\O1>RMALR,M-,Q,,M-,C,,M,0-,C,,M,1->CL,M-=0>NM\\M
>> 20 M=0
>> 2= O=0>OOS]B<0
>> 30 OOS]B<=
>>
>> It looks like reasonably valid data and not complete gibberish, but who
>> am I to judge. Is it one of:
>>
>> Epson ESC/P 9 Pin - didn't work, when I tried it
>> Epson ESC/P 24/48 Pin
>> HP Printer (PCL3 or PCL5)
>> HP Plotter (HP-GL)
>> IBM ProPrinter
>> Plain Text - didn't work, when I tried it
>> Postscript
>> Printronix-P Series
>> Printronix-S Series
>> Seiko QT-2100P
>> Siemens PT-88
>> Apple Image Writer II
>> Seiko STP
>> Star Micronics SP700
>> Tandy DMP-105 - didn't work, when I tried it
>>
>> Help and thank you.
>>
>>
>
>

Re: [M100] Using CP/M for assembly work

[Stephen Adolph]

Not a rexcpm function.  It is handled by import and export written by
Philip.

I can say that I believe import and export use tpdd routines that mirror
the rex routines and are based on Code built by Wilson van alst.

I'd have to do some work to understand how the name is structured.  I think
it is fixed length.

Steve



On Saturday, March 16, 2024, Brian K. White  wrote:

> On 3/16/24 13:48, Stephen Adolph wrote:
>
>> regarding file transfer, use
>> IMPORT
>> or
>> EXPORT
>> in CP/M.  Included in package.
>> These programs access a "TPDD".  Filenames are 8.3 format,
>>
>> cheers
>> Steve
>>
>
> What is the ATTR byte? Presumably F ?
>
> And is that fixed-length space-filled like what Floppy or WP-2 do or not?
> "a___.txt" or "a.txt___"?
>
> And do you know if what REXCPM does matches what other CP/M systems that
> use a TPDD do?
>
> I think there is something that can use a tpdd from a NEC PC-8401 and
> PC-8500 but I never used it yet and don't know what it exactly writes to
> the drive, or expects to find on a drive.
>
> I have a REXCPM and both a 8401 and 8500 so I can test and answer all
> those myself some time. I'm not asking for real unless you do just happen
> to know.
>
> The reason I ask is I would add a CP/M compatibility mode to both dl2 and
> pdd.sh if I knew what it should be.
>
> And, if REXCPM and PC-8401/8500 don't currently match each other, I
> suggest REXCPM should change to match NEC, so that you can move files and
> disks between the two.
>
> There are settings in both dl2 and pdd.sh to manually configure every
> detail, so already right now neither program is actually limited to the
> baked-in convenience modes, but it's not as convenient.
>
> For instance to use dl2 in this case I'm guessing you probably want
> "dl -0 -a F"
>
> "-0" sets a "raw" mode where dl2 doesn't care about spaces or dots or
> anything in the filename, doesn't re-write filenames to different formats,
> and sets the ATTR field to ' ' (0x20, space). In other words acts like a
> real drive, which also doesn't have opinions on any of that.
>
> And "-a F" sets ATTR to F, overriding that -0 set it to space.
> (I should clean that up to make a more consistent interface but that's the
> way it works currently)
>
> And attr only matters for new files created on the pc or from the internet.
>
> A real drive never fabricates an attr value, or cares what it is, it just
> saves whatever a client supplies when creating a file, and then reads it
> later when accessing files. The byte can be anything, and must match from
> one operation to the next only for the same reason a byte in the filename
> must match. And on a real drive, ALL files had to have been created by a
> client saving them initially. There are no files that come directly from
> the internet to the disk and need some attr value fabricated.
>
> A couple months ago I added xattr support so that dl2 now acts even more
> like a real drive. When creating a file (when a client saves a file,
> meaning dl2 has to create a new local file on the pc side), instead of
> ignoring the attr field from the client dirent() request, dl2 now saves it
> in a xattr metadata field attached to the file. And when listing or
> accessing existing files, instead of fabricating attr=F for all files, it
> gets a real attr value from xattr, and only fabricates the default value if
> there is no xattr.
>
> So in one sense dl2 already works fully (should anyway), at least to the
> extent of matching a real drive.
>
> --
> bkw
>
>
>> On Sat, Mar 16, 2024 at 1:36 PM Will Senn > will.s...@gmail.com>> wrote:
>>
>> __
>> I broke down and started reading the manuals (REXCPM, CP/M 2.2,
>> etc). It's starting to come together (again?)... I've inlined the
>> answers I figured out for posterity or the next clueless newb who
>> comes along.
>>
>> On 3/16/24 11:00 AM, Will Senn wrote:
>>
>>> 2. CP/M works from RexCPM, which is great, cuz CP/M recognizes
>>> more memory:
>>>
>>> 64K CP/M 2.2 M100 CP/M + REXCPM 2MB 1.0
>>>
>>> Yes, it does recognize more memory and it serves up an A: drive
>> that's a big chunk of that 2MBs. Solid. Talked about here:
>> http://bitchin100.com/wiki/index.php?title=M100_CP/M
>> <http://bitchin100.com/wiki/index.php?title=M100_CP/M>
>>
>> My questions are as follows:
>>>
>>> 4. In CP/M, how do I get back to MENU?
>>>
>>> Duh, F8 :).
>>
>> 5. When I start CP/M, is

Re: [M100] Using CP/M for assembly work

[Stephen Adolph]

regarding file transfer, use
IMPORT
or
EXPORT
in CP/M.  Included in package.
These programs access a "TPDD".  Filenames are 8.3 format,

cheers
Steve

On Sat, Mar 16, 2024 at 1:36 PM Will Senn  wrote:

> I broke down and started reading the manuals (REXCPM, CP/M 2.2, etc). It's
> starting to come together (again?)... I've inlined the answers I figured
> out for posterity or the next clueless newb who comes along.
>
> On 3/16/24 11:00 AM, Will Senn wrote:
>
> 2. CP/M works from RexCPM, which is great, cuz CP/M recognizes more memory:
>
> 64K CP/M 2.2 M100 CP/M + REXCPM 2MB 1.0
>
> Yes, it does recognize more memory and it serves up an A: drive that's a
> big chunk of that 2MBs. Solid. Talked about here:
> http://bitchin100.com/wiki/index.php?title=M100_CP/M
>
> My questions are as follows:
>
> 4. In CP/M, how do I get back to MENU?
>
> Duh, F8 :).
>
> 5. When I start CP/M, is it just running CP/M against the M100's memory or
> am I in some special whizbang virtual environment where I have additional
> disks available somehow?
>
> It's a whizbang environment for sure - 64K ram and a nearly 2MB A: drive.
>
> As for my broken ASM, another duh, thanks John for the tip - I need to
> write a CP/M friendly program that call it's routines and not the ROM calls.
>
> CP/M seems the way to go, though. It kinda reminds me of RT11, but with
> ASM instead of MACRO11.  ed... well, after you figure out that you need to
> retrieve the file contents into the buffer, it kinda makes sense - nice
> video - I love ED:
> https://www.youtube.com/watch?v=7pqaj050X7g
>
> Still need to figure out how to get files into and out of cp/m though...
>
> Off to read some more.
>
> -will
>

Re: [M100] Is there a superoptimizer for the Intel 8085 (or maybe the Z80)?

[Stephen Adolph]

I think it is called "Ken"  ;)

On Friday, March 15, 2024, Douglas Quagliana  wrote:

> Does anyone know if there is a superoptimizer for the Intel 8085 (or maybe
> for the Z80)?
>
> A superoptimizer in this context is a program that takes as its input an
> assembly language source code file and then it tries a brute force search
> of all possible machine language instructions (up to a certain length) for
> any shorter/faster sequences of machine language instructions that would do
> the same thing as the original sequence of instructions.
>
> There's a GNU superoptimizer for 8086 and 68020, but I'm looking for one
> for the 8085 (or Z80) so I can use the superoptimized results on a Model
> 100.
>
> Regards,
> Douglas
>
>

Re: [M100] Cap kit in Canada and Hello!

[Stephen Adolph]

Duh

On Tuesday, March 12, 2024, Stephen Adolph  wrote:

> Jason, where are you in Canada?  Ottawa area by chance?
>
> On Tuesday, March 12, 2024, Jason Jorgenson  wrote:
>
>> Hi everyone!  Can anyone recommend a place for me to get a cap kit and
>> battery for my model 100 here in Alberta, Canada? I am looking to get mine
>> working again, and then see what I can do with it. I'm interested in that
>> REX but am still learning what can be done with it. It's pretty cool that
>> this group exists to bring enthusiasts together!
>>
>> Jason
>>
>>
>> On Mon, Mar 11, 2024, 10:15 a.m. John R. Hogerhuis 
>> wrote:
>>
>>> Thanks Daryl.
>>>
>>> So nntp is up and working.
>>>
>>> I wonder if there is any way to get nntp indexed / searchable.
>>>
>>> Either way, at least we have access to the old messages again.
>>>
>>> -- John..
>>>
>>

Re: [M100] Cap kit in Canada and Hello!

[Stephen Adolph]

Jason, where are you in Canada?  Ottawa area by chance?

On Tuesday, March 12, 2024, Jason Jorgenson  wrote:

> Hi everyone!  Can anyone recommend a place for me to get a cap kit and
> battery for my model 100 here in Alberta, Canada? I am looking to get mine
> working again, and then see what I can do with it. I'm interested in that
> REX but am still learning what can be done with it. It's pretty cool that
> this group exists to bring enthusiasts together!
>
> Jason
>
>
> On Mon, Mar 11, 2024, 10:15 a.m. John R. Hogerhuis 
> wrote:
>
>> Thanks Daryl.
>>
>> So nntp is up and working.
>>
>> I wonder if there is any way to get nntp indexed / searchable.
>>
>> Either way, at least we have access to the old messages again.
>>
>> -- John..
>>
>

[M100] selling some laptops

[Stephen Adolph]

hi everyone,
I'm selling some computers.  I simply have too many!

What I have for sale is listed here.
https://bitchin100.com/wiki/index.php?title=Ordering_Information

 - computers are re-capped and tested
 - new NiMH RAM backup battery installed
 - boards are repaired if needed (either from leaking caps, batteries etc.)
 - for M100, serial port resistors swapped to 330 ohms if needed
 - LCD contrast pot replaced if needed
 - RAM memory is maxed out
 - keyboard is tested
 - serial port and printer port are tested


You can add on things like a REX# or REXCPM, clock doubler etc.
Otherwise it will be a stock machine with full RAM.

Just email me if you are interested.

thanks,

Steve

[M100] next project!

[Stephen Adolph]

I have so many Model T around here-- too many!  One of the reasons is for
testing, but another reason is because I have different computers for
different use cases.

For example, I have an M100 set up for CP/M using an NSC800 CPU using
REXCPM, and of course I have a normal M100 with 80C85 CPU again with REXCPM.

So, I've decided my next widget is going to be a dual CPU card for M100, so
I can have Z80-based CP/M and normal M100 in the same box!

Here is my proto board. It uses a great big CPLD to interface and manage
the switching between the two processors.  It also will support dual clock
rates because... why not.

I'll post updates as this progresses... Steve

[image: image.png]

Re: [M100] Clock Doubler Video

[Stephen Adolph]

no, I don't think that is a valid explanation.
The modification indeed drives the display twice as fast and works for text.

Perhaps it is time to read the LCD driver chip datasheets again.
Steve

On Wed, Feb 21, 2024 at 6:57 PM Ken St. Cyr  wrote:

> Re Starblaze, someone left the following comment on the video:
>
> "I suspect the game display doesn't work because it's already driving the
> LCD controller at close to its maximum bandwidth at 2.5MHz."
>
> Does anyone know if this is indeed the case? I would've thought other
> things would've broken as well, but everything else I've tried runs
> normally. Unless Starblaze is doing something to refresh the display more
> quickly than other games/apps?
>
> //Ken S.
>
>
> --
> *From:* M100  on behalf of
> bir...@soigeneris.com 
> *Sent:* Friday, February 16, 2024 6:23 PM
> *To:* m...@bitchin100.com 
> *Subject:* Re: [M100] Clock Doubler Video
>
>
> Even at the normal clock rates the TS-DOS timing issues can cause lock
> ups. In normal use one might only stumble on this occasionally. I noticed
> this testing Backpack drives when I’m doing a lot of the same operations
> over and over again.
>
> It seems to stem around pressing the next button you want before it is
> down drawing the screen. If I don’t get in a hurry and wait for a second
> after each screen is drawn it never locks up. I suspect that the faster
> clock exacerbates this latent bug.
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *Stephen
> Adolph
> *Sent:* Friday, February 16, 2024 2:16 PM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] Clock Doubler Video
>
>
>
> Ken ,
>
> What a great job you've done!  Thank you sir.
>
> You really did a nice job with the assembly and commentary on how to
> install it.
>
> At some point I have to find out why Starblaze video is broken
>
> I'm adding the upgrade to all my machines to try and get as much
> experience with it as possible.
>
>
>
> I have noticed that TSDOS sometimes does not work in 5MHz mode, whereas
> Teeny does.  So that has to be a software and timing issue to sort out.
>
>
>
> Thanks again Ken!  Cheers Steve
>
>
>
>

Re: [M100] Clock Doubler Video

[Stephen Adolph]

Ken ,
What a great job you've done!  Thank you sir.
You really did a nice job with the assembly and commentary on how to
install it.
At some point I have to find out why Starblaze video is broken
I'm adding the upgrade to all my machines to try and get as much experience
with it as possible.

I have noticed that TSDOS sometimes does not work in 5MHz mode, whereas
Teeny does.  So that has to be a software and timing issue to sort out.

Thanks again Ken!  Cheers Steve

On Friday, February 16, 2024, Ken St. Cyr  wrote:

> Hi folks -
>
> Just wanted to share that I released a video today detailing my journey in
> building and installing Steve Adolph's clock doubler mod:
>
> Adding TURBO MODE to the Tandy Model 100 (youtube.com)
> 
>
> I really enjoyed this one, and am super appreciative of Steve for
> patiently answering all of my questions and helping me understand how it
> all worked so I could explain it (hopefully) semi-adequately in the video.
> I've been using the mod daily for the past couple of weeks now, and while
> there are some quirks, once you have that speed boost, it's hard to live
> without it!
>
> I know Steve's not planning on selling any kits, but I do have a couple of
> boards and parts left over. If you're interested in one, please feel free
> to reach out to me directly and we can arrange something -
>
> Thanks -
> //Ken S.
>

Re: [M100] LCD Troubleshooting Advice

[Stephen Adolph]

Pin 17 is high?  Ie /Reset?

On Tuesday, January 30, 2024, Ken St. Cyr  wrote:

> Yes, I probed the LCD signals with my scope, and didn't notice anything
> out of the ordinary. I suppose I could hook up a logic analyzer to the LCD
> data pins and see if anything is getting garbled...
>
> //Ken S
> --
> *From:* M100  on behalf of Stephen
> Adolph 
> *Sent:* Tuesday, January 30, 2024 9:30 PM
> *To:* m...@bitchin100.com 
> *Subject:* Re: [M100] LCD Troubleshooting Advice
>
> Ken do you have a scope?
> We are looking for a fault that kills the lcd and drives the current up.
> I would probe the signals and see if there is a clue there.
>
> ..steve
>
>
> On Tuesday, January 30, 2024, Ken St. Cyr  wrote:
>
> The beep test does work, so I know the machine is operating. I checked all
> the LCD signals again, and they all look normal.  I also checked the pot,
> and the voltage was a little high compared to a working unit (+/- 3v on the
> broken one ... the working unit was around +/- 2.6v).  One thing that I did
> notice is that when I run it from my power supply, it's drawing 80mA (LCD
> disconnected), whereas the working one is only drawing like 50-something
> mA. Makes me wonder if there's another short somewhere (I already found and
> repaired one on this unit). But since the system seems to be running basic
> code, I'm wondering if the short is on one of the LCD data lines. I looked
> pretty closely with my microscope for quite a while and didn't find
> anything, and my meter isn't showing a short anywhere, either 
>
> I appreciate the pointers so far... Any other thoughts?
>
> //Ken S
> --
> *From:* M100  on behalf of
> bir...@soigeneris.com 
> *Sent:* Tuesday, January 30, 2024 6:20 PM
> *To:* m...@bitchin100.com 
> *Subject:* Re: [M100] LCD Troubleshooting Advice
>
>
> When the LCD first powers up it will turn on every pixel. When the
> computer boots it will send a reset command to the LCD drivers which turns
> off al pixels. If the LCD does this quick dark/light flash at power on you
> know the computer is starting to boot up.
>
> Check what the LCD bias voltage is at the ribbon cable connector. Make
> sure it is getting there. I have had one machine with a break in that line.
>
> Given that you know the LCD works, if you have the correct bias voltage
> and all other signals it would follow that the computer it failing to boot
> all the way up. The most likely cause would be a bad RAM module in position
> zero.
>
> You can do the ‘BEEP’ test before pulling the RAM module out. Turn on
> computer, press B to start BASIC (I think, going off top of my head here)
> and then type BEEP and hit ENTER. If it beeps the computer is running but
> something is wrong with the signals to the LCD.
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *Ken St.
> Cyr
> *Sent:* Tuesday, January 30, 2024 2:50 PM
> *To:* m...@bitchin100.com
> *Subject:* [M100] LCD Troubleshooting Advice
>
>
>
> Hey folks -
>
>
>
> I'm working on an M100 and having some challenges with the LCD. Here are
> the symptoms:
>
>- No image at all on the LCD
>
>
>- Contrast dial does nothing
>
>
>- Beep test passes (boot > enter > beep > enter produces an audible
>tone), so it seems the system itself is working
>
>
>- The LCD works fine in a different M100
>
>
>- VDD is reading +5v, and VEE is reading -5V
>
>
>- Checked the data pins on the LCD with my scope; they all look fine -
>looks like both data and addresses are making it to the LCD connector
>
>
>
> At this point, I'm baffled. Can anyone offer up some advice on what else
> to check?
>
>
>
> Thanks!
>
> //Ken S.
>
>

Re: [M100] LCD Troubleshooting Advice

[Stephen Adolph]

Ken do you have a scope?
We are looking for a fault that kills the lcd and drives the current up.
I would probe the signals and see if there is a clue there.

..steve


On Tuesday, January 30, 2024, Ken St. Cyr  wrote:

> The beep test does work, so I know the machine is operating. I checked all
> the LCD signals again, and they all look normal.  I also checked the pot,
> and the voltage was a little high compared to a working unit (+/- 3v on the
> broken one ... the working unit was around +/- 2.6v).  One thing that I did
> notice is that when I run it from my power supply, it's drawing 80mA (LCD
> disconnected), whereas the working one is only drawing like 50-something
> mA. Makes me wonder if there's another short somewhere (I already found and
> repaired one on this unit). But since the system seems to be running basic
> code, I'm wondering if the short is on one of the LCD data lines. I looked
> pretty closely with my microscope for quite a while and didn't find
> anything, and my meter isn't showing a short anywhere, either 
>
> I appreciate the pointers so far... Any other thoughts?
>
> //Ken S
> --
> *From:* M100  on behalf of
> bir...@soigeneris.com 
> *Sent:* Tuesday, January 30, 2024 6:20 PM
> *To:* m...@bitchin100.com 
> *Subject:* Re: [M100] LCD Troubleshooting Advice
>
>
> When the LCD first powers up it will turn on every pixel. When the
> computer boots it will send a reset command to the LCD drivers which turns
> off al pixels. If the LCD does this quick dark/light flash at power on you
> know the computer is starting to boot up.
>
> Check what the LCD bias voltage is at the ribbon cable connector. Make
> sure it is getting there. I have had one machine with a break in that line.
>
> Given that you know the LCD works, if you have the correct bias voltage
> and all other signals it would follow that the computer it failing to boot
> all the way up. The most likely cause would be a bad RAM module in position
> zero.
>
> You can do the ‘BEEP’ test before pulling the RAM module out. Turn on
> computer, press B to start BASIC (I think, going off top of my head here)
> and then type BEEP and hit ENTER. If it beeps the computer is running but
> something is wrong with the signals to the LCD.
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *Ken St.
> Cyr
> *Sent:* Tuesday, January 30, 2024 2:50 PM
> *To:* m...@bitchin100.com
> *Subject:* [M100] LCD Troubleshooting Advice
>
>
>
> Hey folks -
>
>
>
> I'm working on an M100 and having some challenges with the LCD. Here are
> the symptoms:
>
>- No image at all on the LCD
>
>
>- Contrast dial does nothing
>
>
>- Beep test passes (boot > enter > beep > enter produces an audible
>tone), so it seems the system itself is working
>
>
>- The LCD works fine in a different M100
>
>
>- VDD is reading +5v, and VEE is reading -5V
>
>
>- Checked the data pins on the LCD with my scope; they all look fine -
>looks like both data and addresses are making it to the LCD connector
>
>
>
> At this point, I'm baffled. Can anyone offer up some advice on what else
> to check?
>
>
>
> Thanks!
>
> //Ken S.
>

Re: [M100] LCD Troubleshooting Advice

[Stephen Adolph]

I would check the wiper voltage on the pot.  Maybe it is putting out either
a very low or very high voltage and biasing the lcd poorly?

On Tuesday, January 30, 2024, Ken St. Cyr  wrote:

> Hey folks -
>
> I'm working on an M100 and having some challenges with the LCD. Here are
> the symptoms:
>
>- No image at all on the LCD
>- Contrast dial does nothing
>- Beep test passes (boot > enter > beep > enter produces an audible
>tone), so it seems the system itself is working
>- The LCD works fine in a different M100
>- VDD is reading +5v, and VEE is reading -5V
>- Checked the data pins on the LCD with my scope; they all look fine -
>looks like both data and addresses are making it to the LCD connector
>
>
> At this point, I'm baffled. Can anyone offer up some advice on what else
> to check?
>
> Thanks!
> //Ken S.
>

Re: [M100] Tandy Portable Disk Drive 2 - firmware dumping and reverse engineering

[Stephen Adolph]

I'll add some info from your nicely documented code.

* A13 value is tested at 0xF1FE, and controls a branch to 0xF1EB; seems to
change the way serial data is transmitted. hardware default is to branch.
* A12 value is tested at 0xF071, not sure what it does yet.  hardware
default is to branch.
* A11 value is tested at 0xFF48, seems to change hardware interrupt
handling. hardware default is to branch.

On Sun, Jan 28, 2024 at 8:31 AM Stephen Adolph  wrote:

> Darren, another question,
> There are some inputs on pins 30,31,32 (called A13, A12, A11) that
> correspond to P45, P44, P43 on the HD6301.
>
> Port 4 of the HD6301 is hooked up to pins 73.36,35,32,32,30,29,28 for
> P40-P47.
>
> I'll go look at the code, but these 3 inputs are configurable.   I wonder
> what they do?
>
> Steve
>
>
>
>
>
> On Sun, Jan 28, 2024 at 8:21 AM Stephen Adolph 
> wrote:
>
>> Thanks Darren.
>>
>> Now that we have the real tpdd firmware I wonder what we can do with it.
>> Some of those variables look tempting, like side and # of tracks.
>>
>> Another question.. it looks like was there a second unpopulated serial
>> port on the drive?  Anything in the code on that?
>> P7 is unpopulated and not in the schematic, but it is there.
>>
>> Steve
>>
>>
>>
>>
>>
>>

Re: [M100] Tandy Portable Disk Drive 2 - firmware dumping and reverse engineering

[Stephen Adolph]

Darren, another question,
There are some inputs on pins 30,31,32 (called A13, A12, A11) that
correspond to P45, P44, P43 on the HD6301.

Port 4 of the HD6301 is hooked up to pins 73.36,35,32,32,30,29,28 for
P40-P47.

I'll go look at the code, but these 3 inputs are configurable.   I wonder
what they do?

Steve





On Sun, Jan 28, 2024 at 8:21 AM Stephen Adolph  wrote:

> Thanks Darren.
>
> Now that we have the real tpdd firmware I wonder what we can do with it.
> Some of those variables look tempting, like side and # of tracks.
>
> Another question.. it looks like was there a second unpopulated serial
> port on the drive?  Anything in the code on that?
> P7 is unpopulated and not in the schematic, but it is there.
>
> Steve
>
>
>
>
>
>
> On Sunday, January 28, 2024, Darren Clark  wrote:
>
>> Spent some time digging through the source of the TPDD2 firmware, adding
>> comments, labels, and variable names.
>>
>> It's documented (as far as I got so far) here:
>> https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD2.ASM
>>
>> Doesn't look like any hidden commands exist in the firmware. This is the
>> list from the command table at 0xFFB9:
>>
>> code0xF230 Command_FMT00_CreateDirectory
>> code0xF4D0Command_FMT01_FileOpen
>> code0xF495Command_FMT02_FileClose
>> code0xF69DCommand_FMT03_FileRead
>> code0xF63DCommand_FMT04_File_Write
>> code0xF425Command_FMT05_FileDelete
>> code0xF212Command_FMT06_DiskFormat
>> code0xF6F3Command_FMT07_DriveStatus
>> code0xF137Command_FMT_Invalid
>> code0xF75FCommand_FMT23_DriveVersionInfo
>> code0xF746Command_FMT0C_DriveCondition
>> code0xF365Command_FMT0D_FileNameChange
>> code0xF801Command_FMT30_SectorModeReadWrite
>> code0xF76BCommand_FMT31_DriveMemorySet
>> code0xF78ECommand_FMT32_DriveMemoryGet
>> code0xF757Command_FMT33_SystemVersionInfo
>> code0xF7DCCommand_FMT34_ExecuteProgram
>>
>> Some other interesting tables are at 0xFF67 and 0xFF6D
>>
>> [FF67][80 ][] Table_SysInfo:DB0x80;Hard
>> sector data port address MSB
>> [FF68][13 ][]DB0x13;Hard sector data
>> port address LSB
>> [FF69][05 ][]DB0x05;Buffer size MSB
>> [FF6A][00 ][]DB0x00;Buffer size LSB
>> [FF6B][10 ][]DB0x10;CPU type. 0x10 =
>> HD6301
>> [FF6C][E1 ][]DB0xE1;Model code
>>
>> [FF6D][41 ][A   ]Table_Version:DB 0x41;System
>> Version Number MSB
>> [FF6E][10 ][]DB0x10;System Version
>> Number LSB
>> [FF6F][01 ][]DB0x01;Number of sides
>> [FF70][00 ][]DB0x00;Number of tracks
>> MSB
>> [FF71][50 ][P   ]DB0x50;Number of tracks
>> LSB
>> [FF72][05 ][]DB0x05;Sector length MSB
>> [FF73][00 ][]DB0x00;Sector length LSB
>> [FF74][02 ][]DB0x02;Sectors per track
>> [FF75][00 ][]DB0x00 ;Directory Entries MSB
>> [FF76][28 ][(   ]DB0x28 ;Directory Entries LSB
>> [FF77][00 ][]DB0x00;Max files
>> [FF78][E1 ][]DB0xE1;Model code
>>
>> There is also a BAUD rate table at 0xFF85, I see logic for reading the
>> dip switch setting from the CPLD at the program initialization. 2 switches
>> for the BAUD rate and the other 2 for some other mode settings. Just a
>> w.a.g. it almost looks like the programming on the CPLD could be the same
>> on the TPPD2 as the TPPD1. It might be possible to set 9600 and 38400 BAUD,
>> just guessing though as I don't have any TPDD2 hardware to play with.
>>
>> Overall an amazing amount of work went into this firmware. From what I
>> can see, it's all hand coded and has a lot of space saving optimizations in
>> it. Out of 4K of available space, there is only 15 bytes of unused space,
>> and the author put his name into it (with one byte filled with a 0xFF):
>>
>> [FFDF][***][] DB'(C) M.FUTAMURA',0xFF;Author
>>
>>
>>
>> Darren Clark
>>
>>
>>
>>
>>
>>

Re: [M100] Tandy Portable Disk Drive 2 - firmware dumping and reverse engineering

[Stephen Adolph]

Thanks Darren.

Now that we have the real tpdd firmware I wonder what we can do with it.
Some of those variables look tempting, like side and # of tracks.

Another question.. it looks like was there a second unpopulated serial port
on the drive?  Anything in the code on that?
P7 is unpopulated and not in the schematic, but it is there.

Steve






On Sunday, January 28, 2024, Darren Clark  wrote:

> Spent some time digging through the source of the TPDD2 firmware, adding
> comments, labels, and variable names.
>
> It's documented (as far as I got so far) here:
> https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD2.ASM
>
> Doesn't look like any hidden commands exist in the firmware. This is the
> list from the command table at 0xFFB9:
>
> code0xF230 Command_FMT00_CreateDirectory
> code0xF4D0Command_FMT01_FileOpen
> code0xF495Command_FMT02_FileClose
> code0xF69DCommand_FMT03_FileRead
> code0xF63DCommand_FMT04_File_Write
> code0xF425Command_FMT05_FileDelete
> code0xF212Command_FMT06_DiskFormat
> code0xF6F3Command_FMT07_DriveStatus
> code0xF137Command_FMT_Invalid
> code0xF75FCommand_FMT23_DriveVersionInfo
> code0xF746Command_FMT0C_DriveCondition
> code0xF365Command_FMT0D_FileNameChange
> code0xF801Command_FMT30_SectorModeReadWrite
> code0xF76BCommand_FMT31_DriveMemorySet
> code0xF78ECommand_FMT32_DriveMemoryGet
> code0xF757Command_FMT33_SystemVersionInfo
> code0xF7DCCommand_FMT34_ExecuteProgram
>
> Some other interesting tables are at 0xFF67 and 0xFF6D
>
> [FF67][80 ][] Table_SysInfo:DB0x80;Hard
> sector data port address MSB
> [FF68][13 ][]DB0x13;Hard sector data
> port address LSB
> [FF69][05 ][]DB0x05;Buffer size MSB
> [FF6A][00 ][]DB0x00;Buffer size LSB
> [FF6B][10 ][]DB0x10;CPU type. 0x10 =
> HD6301
> [FF6C][E1 ][]DB0xE1;Model code
>
> [FF6D][41 ][A   ]Table_Version:DB 0x41;System
> Version Number MSB
> [FF6E][10 ][]DB0x10;System Version
> Number LSB
> [FF6F][01 ][]DB0x01;Number of sides
> [FF70][00 ][]DB0x00;Number of tracks
> MSB
> [FF71][50 ][P   ]DB0x50;Number of tracks
> LSB
> [FF72][05 ][]DB0x05;Sector length MSB
> [FF73][00 ][]DB0x00;Sector length LSB
> [FF74][02 ][]DB0x02;Sectors per track
> [FF75][00 ][]DB0x00 ;Directory Entries MSB
> [FF76][28 ][(   ]DB0x28 ;Directory Entries LSB
> [FF77][00 ][]DB0x00;Max files
> [FF78][E1 ][]DB0xE1;Model code
>
> There is also a BAUD rate table at 0xFF85, I see logic for reading the dip
> switch setting from the CPLD at the program initialization. 2 switches for
> the BAUD rate and the other 2 for some other mode settings. Just a w.a.g.
> it almost looks like the programming on the CPLD could be the same on the
> TPPD2 as the TPPD1. It might be possible to set 9600 and 38400 BAUD, just
> guessing though as I don't have any TPDD2 hardware to play with.
>
> Overall an amazing amount of work went into this firmware. From what I can
> see, it's all hand coded and has a lot of space saving optimizations in it.
> Out of 4K of available space, there is only 15 bytes of unused space, and
> the author put his name into it (with one byte filled with a 0xFF):
>
> [FFDF][***][] DB'(C) M.FUTAMURA',0xFF;Author
>
>
>
> Darren Clark
>
>
>
>
>
>

Re: [M100] Tandy Portable Disk Drive 2 - firmware dumping and reverse engineering

[Stephen Adolph]

128 more bytes ;)

On Tue, Jan 23, 2024 at 3:28 PM Stephen Adolph  wrote:

> It was a first pass attempt.  I captured it as 128 blocks of 32 bytes.
> Was it
>
> On Tuesday, January 23, 2024, Darren Clark  wrote:
>
>> Hello Steve,
>>
>>  Looks awesome so far! I've started to manually decompile it and some
>> things are not making sense.
>>
>> The first 3 bytes 0x8e, 0x87, 0xFF do make sense this puts the stack
>> pointer at address 0x87FF, the top of the external RAM. This is good.
>>
>> Normally there is some other housekeeping at the entry point 0xF000,
>> something like disabling interrupts so the start of the program can
>> initialize the CPU without interruptions. With the TPDD1 the SEI
>> instruction was at 0xF000, then the stack pointer is set at 0x87FF. This
>> may be fine though, I need to do a deeper dive and see if the address
>> alignments all work out.
>>
>> What I do notice is missing is the last 128 bytes of the ROM image,
>> 0xFF80 to 0x.  0xFFEE to 0x is the vector table for interrupts, and
>> resets. The ROM image should be 4096 bytes in total.
>>
>> When I get home this evening I'll run the binary through my decomplier
>> and check the address alignments, that should prove whether the start byte
>> is correct or not too.
>>
>> Either way, we're 95% there. Thanks for working on this!
>>
>> Darren Clark
>>
>>
>> On 1/22/24 23:21, Stephen Adolph wrote:
>>
>> these look like 6301 opcodes.  Maybe this worked.
>> take a look please when you can. thanks. Steve
>>
>>
>> On Tue, Jan 9, 2024 at 6:55 PM Darren Clark  wrote:
>>
>>> TPDD2 firmware dumping - breaking this into a new thread.
>>>
>>> It would be interesting to see if we can use the command 'Request Block'
>>> from page 89 to read the ROM of the CPU...
>>>
>>> I dumped the ROM of the TPDD1 and got a good start at reverse
>>> engineering it and documenting it here
>>> https://github.com/BiggRanger/Tandy_PDD/tree/master can't believe that
>>> was over 7 years ago!
>>>
>>> Looking at the schematic in the PDF, the HD6301V1 starts up in mode 6
>>> just like with TPDD1, that places the firmware/ROM between 0xF000 and
>>> 0x in memory.
>>>
>>> Is there anybody with a TPDD2 willing to try and dump 4K of data from
>>> 0xF000 to 0x and send it to me so I can start reverse engineering
>>> and documenting it? It should look somewhat similar to this
>>> https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD1.HEX if it is
>>> outputting good data.
>>>
>>>  From page 89 GET THE DATA FROM THE DRIVE'S MEMORY
>>>
>>> Request Block - 5A5A 32 04 01 F000 40 (checksum) and see what block of
>>> 64 bytes comes out.
>>>
>>>
>>> Darren Clark
>>>
>>>
>>> Here is a memory map of the TPDD1 from my reverse engineering earlier:
>>>
>>> ;--
>>> ;Memory Map of PDD (using mode 6):
>>> ;--
>>> ;-001FInternal Registers (see below)
>>> ;0080-00FFInternal RAM
>>> ;4000-4003CPLD (Glue Logic + Hardware IO Control)
>>> ;8000-87FFExternal RAM (2K)
>>> ;F000-Internal ROM (4K)
>>> ;--
>>> ;I/O ports
>>> ;Port.BitI/OPin#IDFunction
>>> ;--
>>> ;Port1.B0InputPin18P10CTS
>>> ;Port1.B1InputPin19P11DSR
>>> ;Port1.B2OutputPin20P12RTS
>>> ;Port1.B3OutputPin22P13DTR
>>> ;Port1.B4OutputPin23P14PS Alarm (Low Battery LED)
>>> ;Port1.B5OutputPin24P15LED101 (Drive Access LED)
>>> ;Port1.B6OutputPin25P16To MA7340
>>> ;Port1.B7OutputPin26P17SCAN
>>>
>>> ;Port2.B0InputPin11P20Mode (pulled Low)
>>> ;Port2.B1InputPin12P21Mode (pulled Hi)
>>> ;Port2.B2InputPin13P22(SCI) CLKOUT from CPLD for BAUD
>>> rate
>>> ;Port2.B3InputPin14P23(SCI) /RXD
>>> ;Port2.B4OutputPin15P24(SCI) /TXD
>>> ;--
>>>
>>>
>>>
>>>
<>

Re: [M100] Tandy Portable Disk Drive 2 - firmware dumping and reverse engineering

[Stephen Adolph]

It was a first pass attempt.  I captured it as 128 blocks of 32 bytes.  Was
it

On Tuesday, January 23, 2024, Darren Clark  wrote:

> Hello Steve,
>
>  Looks awesome so far! I've started to manually decompile it and some
> things are not making sense.
>
> The first 3 bytes 0x8e, 0x87, 0xFF do make sense this puts the stack
> pointer at address 0x87FF, the top of the external RAM. This is good.
>
> Normally there is some other housekeeping at the entry point 0xF000,
> something like disabling interrupts so the start of the program can
> initialize the CPU without interruptions. With the TPDD1 the SEI
> instruction was at 0xF000, then the stack pointer is set at 0x87FF. This
> may be fine though, I need to do a deeper dive and see if the address
> alignments all work out.
>
> What I do notice is missing is the last 128 bytes of the ROM image, 0xFF80
> to 0x.  0xFFEE to 0x is the vector table for interrupts, and
> resets. The ROM image should be 4096 bytes in total.
>
> When I get home this evening I'll run the binary through my decomplier and
> check the address alignments, that should prove whether the start byte is
> correct or not too.
>
> Either way, we're 95% there. Thanks for working on this!
>
> Darren Clark
>
>
> On 1/22/24 23:21, Stephen Adolph wrote:
>
> these look like 6301 opcodes.  Maybe this worked.
> take a look please when you can. thanks. Steve
>
>
> On Tue, Jan 9, 2024 at 6:55 PM Darren Clark  wrote:
>
>> TPDD2 firmware dumping - breaking this into a new thread.
>>
>> It would be interesting to see if we can use the command 'Request Block'
>> from page 89 to read the ROM of the CPU...
>>
>> I dumped the ROM of the TPDD1 and got a good start at reverse
>> engineering it and documenting it here
>> https://github.com/BiggRanger/Tandy_PDD/tree/master can't believe that
>> was over 7 years ago!
>>
>> Looking at the schematic in the PDF, the HD6301V1 starts up in mode 6
>> just like with TPDD1, that places the firmware/ROM between 0xF000 and
>> 0x in memory.
>>
>> Is there anybody with a TPDD2 willing to try and dump 4K of data from
>> 0xF000 to 0x and send it to me so I can start reverse engineering
>> and documenting it? It should look somewhat similar to this
>> https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD1.HEX if it is
>> outputting good data.
>>
>>  From page 89 GET THE DATA FROM THE DRIVE'S MEMORY
>>
>> Request Block - 5A5A 32 04 01 F000 40 (checksum) and see what block of
>> 64 bytes comes out.
>>
>>
>> Darren Clark
>>
>>
>> Here is a memory map of the TPDD1 from my reverse engineering earlier:
>>
>> ;--
>> ;Memory Map of PDD (using mode 6):
>> ;--
>> ;-001FInternal Registers (see below)
>> ;0080-00FFInternal RAM
>> ;4000-4003CPLD (Glue Logic + Hardware IO Control)
>> ;8000-87FFExternal RAM (2K)
>> ;F000-Internal ROM (4K)
>> ;--
>> ;I/O ports
>> ;Port.BitI/OPin#IDFunction
>> ;--
>> ;Port1.B0InputPin18P10CTS
>> ;Port1.B1InputPin19P11DSR
>> ;Port1.B2OutputPin20P12RTS
>> ;Port1.B3OutputPin22P13DTR
>> ;Port1.B4OutputPin23P14PS Alarm (Low Battery LED)
>> ;Port1.B5OutputPin24P15LED101 (Drive Access LED)
>> ;Port1.B6OutputPin25P16To MA7340
>> ;Port1.B7OutputPin26P17SCAN
>>
>> ;Port2.B0InputPin11P20Mode (pulled Low)
>> ;Port2.B1InputPin12P21Mode (pulled Hi)
>> ;Port2.B2InputPin13P22(SCI) CLKOUT from CPLD for BAUD rate
>> ;Port2.B3InputPin14P23(SCI) /RXD
>> ;Port2.B4OutputPin15P24(SCI) /TXD
>> ;--
>>
>>
>>
>>

Re: [M100] Tandy Portable Disk Drive 2 - firmware dumping and reverse engineering

[Stephen Adolph]

It was a first pass attempt.  I captured it as 128 blocks of 32 bytes.
I'll check that I didn't cut off the file by accident.


On Tuesday, January 23, 2024, Darren Clark  wrote:

> Hello Steve,
>
>  Looks awesome so far! I've started to manually decompile it and some
> things are not making sense.
>
> The first 3 bytes 0x8e, 0x87, 0xFF do make sense this puts the stack
> pointer at address 0x87FF, the top of the external RAM. This is good.
>
> Normally there is some other housekeeping at the entry point 0xF000,
> something like disabling interrupts so the start of the program can
> initialize the CPU without interruptions. With the TPDD1 the SEI
> instruction was at 0xF000, then the stack pointer is set at 0x87FF. This
> may be fine though, I need to do a deeper dive and see if the address
> alignments all work out.
>
> What I do notice is missing is the last 128 bytes of the ROM image, 0xFF80
> to 0x.  0xFFEE to 0x is the vector table for interrupts, and
> resets. The ROM image should be 4096 bytes in total.
>
> When I get home this evening I'll run the binary through my decomplier and
> check the address alignments, that should prove whether the start byte is
> correct or not too.
>
> Either way, we're 95% there. Thanks for working on this!
>
> Darren Clark
>
>
> On 1/22/24 23:21, Stephen Adolph wrote:
>
> these look like 6301 opcodes.  Maybe this worked.
> take a look please when you can. thanks. Steve
>
>
> On Tue, Jan 9, 2024 at 6:55 PM Darren Clark  wrote:
>
>> TPDD2 firmware dumping - breaking this into a new thread.
>>
>> It would be interesting to see if we can use the command 'Request Block'
>> from page 89 to read the ROM of the CPU...
>>
>> I dumped the ROM of the TPDD1 and got a good start at reverse
>> engineering it and documenting it here
>> https://github.com/BiggRanger/Tandy_PDD/tree/master can't believe that
>> was over 7 years ago!
>>
>> Looking at the schematic in the PDF, the HD6301V1 starts up in mode 6
>> just like with TPDD1, that places the firmware/ROM between 0xF000 and
>> 0x in memory.
>>
>> Is there anybody with a TPDD2 willing to try and dump 4K of data from
>> 0xF000 to 0x and send it to me so I can start reverse engineering
>> and documenting it? It should look somewhat similar to this
>> https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD1.HEX if it is
>> outputting good data.
>>
>>  From page 89 GET THE DATA FROM THE DRIVE'S MEMORY
>>
>> Request Block - 5A5A 32 04 01 F000 40 (checksum) and see what block of
>> 64 bytes comes out.
>>
>>
>> Darren Clark
>>
>>
>> Here is a memory map of the TPDD1 from my reverse engineering earlier:
>>
>> ;--
>> ;Memory Map of PDD (using mode 6):
>> ;--
>> ;-001FInternal Registers (see below)
>> ;0080-00FFInternal RAM
>> ;4000-4003CPLD (Glue Logic + Hardware IO Control)
>> ;8000-87FFExternal RAM (2K)
>> ;F000-Internal ROM (4K)
>> ;--
>> ;I/O ports
>> ;Port.BitI/OPin#IDFunction
>> ;--
>> ;Port1.B0InputPin18P10CTS
>> ;Port1.B1InputPin19P11DSR
>> ;Port1.B2OutputPin20P12RTS
>> ;Port1.B3OutputPin22P13DTR
>> ;Port1.B4OutputPin23P14PS Alarm (Low Battery LED)
>> ;Port1.B5OutputPin24P15LED101 (Drive Access LED)
>> ;Port1.B6OutputPin25P16To MA7340
>> ;Port1.B7OutputPin26P17SCAN
>>
>> ;Port2.B0InputPin11P20Mode (pulled Low)
>> ;Port2.B1InputPin12P21Mode (pulled Hi)
>> ;Port2.B2InputPin13P22(SCI) CLKOUT from CPLD for BAUD rate
>> ;Port2.B3InputPin14P23(SCI) /RXD
>> ;Port2.B4OutputPin15P24(SCI) /TXD
>> ;--
>>
>>
>>
>>

Re: [M100] Tandy Portable Disk Drive 2 - firmware dumping and reverse engineering

[Stephen Adolph]

these look like 6301 opcodes.  Maybe this worked.
take a look please when you can. thanks. Steve


On Tue, Jan 9, 2024 at 6:55 PM Darren Clark  wrote:

> TPDD2 firmware dumping - breaking this into a new thread.
>
> It would be interesting to see if we can use the command 'Request Block'
> from page 89 to read the ROM of the CPU...
>
> I dumped the ROM of the TPDD1 and got a good start at reverse
> engineering it and documenting it here
> https://github.com/BiggRanger/Tandy_PDD/tree/master can't believe that
> was over 7 years ago!
>
> Looking at the schematic in the PDF, the HD6301V1 starts up in mode 6
> just like with TPDD1, that places the firmware/ROM between 0xF000 and
> 0x in memory.
>
> Is there anybody with a TPDD2 willing to try and dump 4K of data from
> 0xF000 to 0x and send it to me so I can start reverse engineering
> and documenting it? It should look somewhat similar to this
> https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD1.HEX if it is
> outputting good data.
>
>  From page 89 GET THE DATA FROM THE DRIVE'S MEMORY
>
> Request Block - 5A5A 32 04 01 F000 40 (checksum) and see what block of
> 64 bytes comes out.
>
>
> Darren Clark
>
>
> Here is a memory map of the TPDD1 from my reverse engineering earlier:
>
> ;--
> ;Memory Map of PDD (using mode 6):
> ;--
> ;-001FInternal Registers (see below)
> ;0080-00FFInternal RAM
> ;4000-4003CPLD (Glue Logic + Hardware IO Control)
> ;8000-87FFExternal RAM (2K)
> ;F000-Internal ROM (4K)
> ;--
> ;I/O ports
> ;Port.BitI/OPin#IDFunction
> ;--
> ;Port1.B0InputPin18P10CTS
> ;Port1.B1InputPin19P11DSR
> ;Port1.B2OutputPin20P12RTS
> ;Port1.B3OutputPin22P13DTR
> ;Port1.B4OutputPin23P14PS Alarm (Low Battery LED)
> ;Port1.B5OutputPin24P15LED101 (Drive Access LED)
> ;Port1.B6OutputPin25P16To MA7340
> ;Port1.B7OutputPin26P17SCAN
>
> ;Port2.B0InputPin11P20Mode (pulled Low)
> ;Port2.B1InputPin12P21Mode (pulled Hi)
> ;Port2.B2InputPin13P22(SCI) CLKOUT from CPLD for BAUD rate
> ;Port2.B3InputPin14P23(SCI) /RXD
> ;Port2.B4OutputPin15P24(SCI) /TXD
> ;--
>
>
>
>
<>

Re: [M100] Tandy Portable Disk Drive 2 - firmware dumping and reverse engineering

[Stephen Adolph]

Oh yeah and we know who wrote it:
M.FUTAMURA

On Mon, Jan 22, 2024 at 11:21 PM Stephen Adolph 
wrote:

> these look like 6301 opcodes.  Maybe this worked.
> take a look please when you can. thanks. Steve
>
>
> On Tue, Jan 9, 2024 at 6:55 PM Darren Clark  wrote:
>
>> TPDD2 firmware dumping - breaking this into a new thread.
>>
>> It would be interesting to see if we can use the command 'Request Block'
>> from page 89 to read the ROM of the CPU...
>>
>> I dumped the ROM of the TPDD1 and got a good start at reverse
>> engineering it and documenting it here
>> https://github.com/BiggRanger/Tandy_PDD/tree/master can't believe that
>> was over 7 years ago!
>>
>> Looking at the schematic in the PDF, the HD6301V1 starts up in mode 6
>> just like with TPDD1, that places the firmware/ROM between 0xF000 and
>> 0x in memory.
>>
>> Is there anybody with a TPDD2 willing to try and dump 4K of data from
>> 0xF000 to 0x and send it to me so I can start reverse engineering
>> and documenting it? It should look somewhat similar to this
>> https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD1.HEX if it is
>> outputting good data.
>>
>>  From page 89 GET THE DATA FROM THE DRIVE'S MEMORY
>>
>> Request Block - 5A5A 32 04 01 F000 40 (checksum) and see what block of
>> 64 bytes comes out.
>>
>>
>> Darren Clark
>>
>>
>> Here is a memory map of the TPDD1 from my reverse engineering earlier:
>>
>> ;--
>> ;Memory Map of PDD (using mode 6):
>> ;--
>> ;-001FInternal Registers (see below)
>> ;0080-00FFInternal RAM
>> ;4000-4003CPLD (Glue Logic + Hardware IO Control)
>> ;8000-87FFExternal RAM (2K)
>> ;F000-Internal ROM (4K)
>> ;--
>> ;I/O ports
>> ;Port.BitI/OPin#IDFunction
>> ;--
>> ;Port1.B0InputPin18P10CTS
>> ;Port1.B1InputPin19P11DSR
>> ;Port1.B2OutputPin20P12RTS
>> ;Port1.B3OutputPin22P13DTR
>> ;Port1.B4OutputPin23P14PS Alarm (Low Battery LED)
>> ;Port1.B5OutputPin24P15LED101 (Drive Access LED)
>> ;Port1.B6OutputPin25P16To MA7340
>> ;Port1.B7OutputPin26P17SCAN
>>
>> ;Port2.B0InputPin11P20Mode (pulled Low)
>> ;Port2.B1InputPin12P21Mode (pulled Hi)
>> ;Port2.B2InputPin13P22(SCI) CLKOUT from CPLD for BAUD rate
>> ;Port2.B3InputPin14P23(SCI) /RXD
>> ;Port2.B4OutputPin15P24(SCI) /TXD
>> ;--
>>
>>
>>
>>

Re: [M100] Z80 conversion kit

[Stephen Adolph]

The NSC800 conversion is mostly compatible stand alone with M100 software.

There are a couple of things it can't do, like use the cassette port or
importantly it cannot run REXMGR.

(The latter is because all of REX leverages undocumented opcodes.  I don't
want to rewrite REX# or REXCPM software for this. )

But you do need REXCPM  hardware to support CPM.

That's why for the most part it only makes sense to drop in a Z80 if you
want to run CPM.  Then you get access totally the software out there.

Without the REXCPM hardware you get .. an M100 work alike.  Well it can run
Z80 opcodes too in case you want to write machine code.

Cheers
Steve



On Friday, January 19, 2024, r cs  wrote:

> I am interested.  What upgrade path would you recommend for someone with
> half a dozen first gen REX and first gen non-REX CPMs?
>
> Thanks,
> rcs
>
> On Fri, Jan 19, 2024 at 6:09 PM Stephen Adolph 
> wrote:
>
>> Hi folks,
>> Before the break I built an NSC800 conversion kit for someone who I guess
>> changed their mind.
>>
>> So, this kit is here and available if anyone is interested.  Ideally
>> you'd use this with a REXCPM and use it for actual CPM stuff.
>>
>> Let me know if you feel the urge to swap the brain of your M100!
>>
>> Steve
>>
>
>
> --
> *Níl aon tinteán mar do thinteán féin. *[Irish Gaelic]
> (There is no fireside like your own fireside.)
>
>
>

Re: [M100] Z80 conversion kit

[Stephen Adolph]

I should mention that thr hard thing in this upgrade is to desolder the
80C85 and to solder instead a socket into which you plug an adapter board
plus NSC800.

Ao, that part would be on the user to sort out ;).

Steve


On Friday, January 19, 2024, Stephen Adolph  wrote:

> Hi folks,
> Before the break I built an NSC800 conversion kit for someone who I guess
> changed their mind.
>
> So, this kit is here and available if anyone is interested.  Ideally you'd
> use this with a REXCPM and use it for actual CPM stuff.
>
> Let me know if you feel the urge to swap the brain of your M100!
>
> Steve
>

[M100] Z80 conversion kit

[Stephen Adolph]

Hi folks,
Before the break I built an NSC800 conversion kit for someone who I guess
changed their mind.

So, this kit is here and available if anyone is interested.  Ideally you'd
use this with a REXCPM and use it for actual CPM stuff.

Let me know if you feel the urge to swap the brain of your M100!

Steve

Re: [M100] CPLD discontinuation

[Stephen Adolph]

Bummer!
They are unique CPLDs; very low power, perfect for Model T.
Thankfully I bought 300pcs recently of the '32 flavor.
Steve

On Mon, Jan 15, 2024 at 2:47 PM Josh Malone  wrote:

> Looks like our favorite CPLD for making tiny ROM boards has been
> discontinued officially. I kinda thought it had gone EOL a long time ago,
> but this official announcement is dated Jan. 1
>
> https://docs.xilinx.com/v/u/en-US/XCN23009
>
> -Josh
>

Re: [M100] Tandy Portable Disk Drive 2 - firmware dumping and reverse engineering

[Stephen Adolph]

I happen to have a TPDD2 controller board from a dead drive.  Maybe I could
figure this out.
Steve

On Tue, Jan 9, 2024 at 6:55 PM Darren Clark  wrote:

> TPDD2 firmware dumping - breaking this into a new thread.
>
> It would be interesting to see if we can use the command 'Request Block'
> from page 89 to read the ROM of the CPU...
>
> I dumped the ROM of the TPDD1 and got a good start at reverse
> engineering it and documenting it here
> https://github.com/BiggRanger/Tandy_PDD/tree/master can't believe that
> was over 7 years ago!
>
> Looking at the schematic in the PDF, the HD6301V1 starts up in mode 6
> just like with TPDD1, that places the firmware/ROM between 0xF000 and
> 0x in memory.
>
> Is there anybody with a TPDD2 willing to try and dump 4K of data from
> 0xF000 to 0x and send it to me so I can start reverse engineering
> and documenting it? It should look somewhat similar to this
> https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD1.HEX if it is
> outputting good data.
>
>  From page 89 GET THE DATA FROM THE DRIVE'S MEMORY
>
> Request Block - 5A5A 32 04 01 F000 40 (checksum) and see what block of
> 64 bytes comes out.
>
>
> Darren Clark
>
>
> Here is a memory map of the TPDD1 from my reverse engineering earlier:
>
> ;--
> ;Memory Map of PDD (using mode 6):
> ;--
> ;-001FInternal Registers (see below)
> ;0080-00FFInternal RAM
> ;4000-4003CPLD (Glue Logic + Hardware IO Control)
> ;8000-87FFExternal RAM (2K)
> ;F000-Internal ROM (4K)
> ;--
> ;I/O ports
> ;Port.BitI/OPin#IDFunction
> ;--
> ;Port1.B0InputPin18P10CTS
> ;Port1.B1InputPin19P11DSR
> ;Port1.B2OutputPin20P12RTS
> ;Port1.B3OutputPin22P13DTR
> ;Port1.B4OutputPin23P14PS Alarm (Low Battery LED)
> ;Port1.B5OutputPin24P15LED101 (Drive Access LED)
> ;Port1.B6OutputPin25P16To MA7340
> ;Port1.B7OutputPin26P17SCAN
>
> ;Port2.B0InputPin11P20Mode (pulled Low)
> ;Port2.B1InputPin12P21Mode (pulled Hi)
> ;Port2.B2InputPin13P22(SCI) CLKOUT from CPLD for BAUD rate
> ;Port2.B3InputPin14P23(SCI) /RXD
> ;Port2.B4OutputPin15P24(SCI) /TXD
> ;--
>
>
>
>

Re: [M100] Model 100 - LCD Shows Pixels Only

[Stephen Adolph]

One thing about the LCD;  if the lcd driver write acknowledge signal is
broken, the cpu will be caught in an endless loop waiting for thr drivers
to write successfully.
In this state the cpu would be running but in a software loop polling the
driver write ack signal.

Sounds like a possibility here.





On Thursday, December 28, 2023, Josh Malone  wrote:

> On Thu, Dec 28, 2023 at 10:35 AM  wrote:
>
>> When LCDs with these types of LCD driers first power up they turn on all
>> the pixels. You will see this even in brand new ‘modern’ dot matrix LCD
>> module  (on the new LCDs the multiline modules tend to only make the first
>> row black on power up.) Only after the computer sends a rest command to the
>> LCD drivers they will clear the screen.
>>
>
> Ah! Okay, I misunderstood that process then. If the driver ICs themselves
> set every pixel then I agree it sounds like the machine is not running code
> then. Thanks for clarifying this, Jeff. I appreciate it.
>
> -Josh
>
>

Re: [M100] Model T clock doubler

[Stephen Adolph]

Hi all,
Just a quick note to say I've uploaded a set of information to enable
building and installation in M100 of the 1x2x clock doubler board Version
4.6.
Gerbers, images, schematic, Eagle design files, BOM, how-tos.
https://bitchin100.com/wiki/index.php?title=5MHZ_upgrade_for_Model_T
Interested folks can give it a try and let me know what needs improvement.
Next up - Olivetti M10, Tandy 200, Tandy 102, PC-8201  in more or less that
order.

cheers
Steve



On Sat, Nov 18, 2023 at 10:54 AM Stephen Adolph 
wrote:

> Hi everyone,
>
> I've been working towards finishing off my project for increasing the
> speed of the Model T laptops.  The idea is to create a (relatively) easy to
> make and install solution that allows the user to switch the clock rate
> from 2.5 MHz to 5 MHz.
> This is really nice on the 40x8 LCD machines.
>
> The universal software command to switch clock rate is
> OUT 85,1 for 2x mode and
> OUT 85,0 for 1x mode.
>
> Of course the Model T is not designed for this, but in my experience so
> far, it seems reliable.  I really like the upgrade and plan to install in
> all my laptops. Being able to operate in nominal clock mode is of course
> very useful because you may find some software to be incompatible.
>
> Models I have upgraded to date:
> * M100 (NA, early variant, not UK)
> * T102
> * T200
> * NEC PC-8201/8201a
> * Olivetti M10
>
> I am publishing all the information needed to DIY this upgrade. I don't
> have any plans to make these upgrades.  Consider this upgrade only if you
> are comfortable with soldering surface mount parts, and with making minor
> modifications to your laptop.
>
> Upgrades that are done and in the process of documentation are M100, T200,
> NEC.  Upgrades that need a new PCB design still are T102 and M10.  All
> information will be at this site:
>
> https://bitchin100.com/wiki/index.php?title=5MHZ_upgrade_for_Model_T
>
> I am publishing
> * PCB designs for the clock doubler board (there are a few variants)
> * schematic
> * bill of materials for parts you need
> * documentation for building the clock doubler
> * installation documentation per laptop
>
> Things I have discovered while developing this;
> 1.  Power consumption goes up by about 20% when you run at 2x clock.
> 2.  Depending on the speed of your SRAM,  you may need to implement a
> modification to speed that up.  Each model has a specific mod you need.
> 3.  In M100 with the custom socket pinout, in most cases you need to
> upgrade your Main ROM to something faster.  This usually involves an
> adapter board and an EPROM.
> 4.  In the Tandy 200, one must slow down the machine temporarily to access
> the RTC.  There is a specific change for that.
>
> Anyhow, as I complete a particular laptop, I'll post the needed files.
>
> Hopefully this will be of some interest for those inclined to play around
> with hardware.  I have no problem if anyone wants to take the design and
> improve it or change it.
>
> Feel free to contact me directly with questions.
>
> cheers
> Steve
>
>
>
>
>

Re: [M100] Important artifact?

[Stephen Adolph]

Very generous of you Jeff!  Thank you!

On Friday, December 8, 2023,  wrote:

> Ha! Offer accepted! Will scan and upload ASAP.
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *
> bir...@soigeneris.com
> *Sent:* Friday, December 8, 2023 2:30 PM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] Important artifact?
>
>
>
> If by chance he accepts my $30 offer I will scan it and upload to Internet
> Archive. I won’t hold my breath though on him accepting the offer. 
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *r cs
> *Sent:* Friday, December 8, 2023 2:17 PM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] Important artifact?
>
>
>
> The PDD 26-3808 (not PDD2) is here for free (thank you Internet Archive!):
>
> https://archive.org/details/tandyportablediskdriveservicemanual263808stext
>
>
>

[M100] Important artifact?

[Stephen Adolph]

https://www.ebay.ca/itm/235269304214?mkcid=16=1=711-127632-2357-0=l4JfPCDtSvG=4429486=UdOsFOYySKy=_ver=artemis=COPY

A bit pricey

Re: [M100] Model T clock doubler

[Stephen Adolph]

Yes one new part to add. I will update.
Steve

On Wednesday, November 29, 2023, Ken St. Cyr  wrote:

> Thanks - I'm going to order a set of prototypes boards as soon as you're
> ready to share. Will anything in the parts list change?
>
>
> //Ken S.
> --
> *From:* M100  on behalf of Stephen
> Adolph 
> *Sent:* Wednesday, November 29, 2023 1:13 PM
> *To:* m...@bitchin100.com 
> *Subject:* Re: [M100] Model T clock doubler
>
> Had to do a minor responsibility!  Will post in a week.
>
> On Wednesday, November 29, 2023, Ken St. Cyr  wrote:
>
> Hey Steve -
>
> I went to grab the gerbers from the upgrade page in the wiki, and the
> links aren't working. Would you mind sharing the file for the M100 board?
>
> Thanks!
> //Ken S.
> --
> *From:* M100  on behalf of Stephen
> Adolph 
> *Sent:* Saturday, November 18, 2023 10:54 AM
> *To:* m...@bitchin100.com 
> *Subject:* [M100] Model T clock doubler
>
> Hi everyone,
>
> I've been working towards finishing off my project for increasing the
> speed of the Model T laptops.  The idea is to create a (relatively) easy to
> make and install solution that allows the user to switch the clock rate
> from 2.5 MHz to 5 MHz.
> This is really nice on the 40x8 LCD machines.
>
> The universal software command to switch clock rate is
> OUT 85,1 for 2x mode and
> OUT 85,0 for 1x mode.
>
> Of course the Model T is not designed for this, but in my experience so
> far, it seems reliable.  I really like the upgrade and plan to install in
> all my laptops. Being able to operate in nominal clock mode is of course
> very useful because you may find some software to be incompatible.
>
> Models I have upgraded to date:
> * M100 (NA, early variant, not UK)
> * T102
> * T200
> * NEC PC-8201/8201a
> * Olivetti M10
>
> I am publishing all the information needed to DIY this upgrade. I don't
> have any plans to make these upgrades.  Consider this upgrade only if you
> are comfortable with soldering surface mount parts, and with making minor
> modifications to your laptop.
>
> Upgrades that are done and in the process of documentation are M100, T200,
> NEC.  Upgrades that need a new PCB design still are T102 and M10.  All
> information will be at this site:
>
> https://bitchin100.com/wiki/index.php?title=5MHZ_upgrade_for_Model_T
>
> I am publishing
> * PCB designs for the clock doubler board (there are a few variants)
> * schematic
> * bill of materials for parts you need
> * documentation for building the clock doubler
> * installation documentation per laptop
>
> Things I have discovered while developing this;
> 1.  Power consumption goes up by about 20% when you run at 2x clock.
> 2.  Depending on the speed of your SRAM,  you may need to implement a
> modification to speed that up.  Each model has a specific mod you need.
> 3.  In M100 with the custom socket pinout, in most cases you need to
> upgrade your Main ROM to something faster.  This usually involves an
> adapter board and an EPROM.
> 4.  In the Tandy 200, one must slow down the machine temporarily to access
> the RTC.  There is a specific change for that.
>
> Anyhow, as I complete a particular laptop, I'll post the needed files.
>
> Hopefully this will be of some interest for those inclined to play around
> with hardware.  I have no problem if anyone wants to take the design and
> improve it or change it.
>
> Feel free to contact me directly with questions.
>
> cheers
> Steve
>
>
>
>
>

Re: [M100] Model T clock doubler

[Stephen Adolph]

Had to do a minor responsibility!  Will post in a week.

On Wednesday, November 29, 2023, Ken St. Cyr  wrote:

> Hey Steve -
>
> I went to grab the gerbers from the upgrade page in the wiki, and the
> links aren't working. Would you mind sharing the file for the M100 board?
>
> Thanks!
> //Ken S.
> --
> *From:* M100  on behalf of Stephen
> Adolph 
> *Sent:* Saturday, November 18, 2023 10:54 AM
> *To:* m...@bitchin100.com 
> *Subject:* [M100] Model T clock doubler
>
> Hi everyone,
>
> I've been working towards finishing off my project for increasing the
> speed of the Model T laptops.  The idea is to create a (relatively) easy to
> make and install solution that allows the user to switch the clock rate
> from 2.5 MHz to 5 MHz.
> This is really nice on the 40x8 LCD machines.
>
> The universal software command to switch clock rate is
> OUT 85,1 for 2x mode and
> OUT 85,0 for 1x mode.
>
> Of course the Model T is not designed for this, but in my experience so
> far, it seems reliable.  I really like the upgrade and plan to install in
> all my laptops. Being able to operate in nominal clock mode is of course
> very useful because you may find some software to be incompatible.
>
> Models I have upgraded to date:
> * M100 (NA, early variant, not UK)
> * T102
> * T200
> * NEC PC-8201/8201a
> * Olivetti M10
>
> I am publishing all the information needed to DIY this upgrade. I don't
> have any plans to make these upgrades.  Consider this upgrade only if you
> are comfortable with soldering surface mount parts, and with making minor
> modifications to your laptop.
>
> Upgrades that are done and in the process of documentation are M100, T200,
> NEC.  Upgrades that need a new PCB design still are T102 and M10.  All
> information will be at this site:
>
> https://bitchin100.com/wiki/index.php?title=5MHZ_upgrade_for_Model_T
>
> I am publishing
> * PCB designs for the clock doubler board (there are a few variants)
> * schematic
> * bill of materials for parts you need
> * documentation for building the clock doubler
> * installation documentation per laptop
>
> Things I have discovered while developing this;
> 1.  Power consumption goes up by about 20% when you run at 2x clock.
> 2.  Depending on the speed of your SRAM,  you may need to implement a
> modification to speed that up.  Each model has a specific mod you need.
> 3.  In M100 with the custom socket pinout, in most cases you need to
> upgrade your Main ROM to something faster.  This usually involves an
> adapter board and an EPROM.
> 4.  In the Tandy 200, one must slow down the machine temporarily to access
> the RTC.  There is a specific change for that.
>
> Anyhow, as I complete a particular laptop, I'll post the needed files.
>
> Hopefully this will be of some interest for those inclined to play around
> with hardware.  I have no problem if anyone wants to take the design and
> improve it or change it.
>
> Feel free to contact me directly with questions.
>
> cheers
> Steve
>
>
>
>
>

Re: [M100] Alternate keymaps on the M100 (and a question about caps lock)

[Stephen Adolph]

Actually there was a good chunk of space left over.

Attaching the hardware scroll binary and the patch ASM.
I think there is space from 7603 to 763F.

If you were interested to try out the rom, you can edit this binary with
your mods.

On Mon, Nov 27, 2023 at 12:27 AM runrin  wrote:

> Ack! It was a silly mistake. I needed JZ not RZ. Everything is working
> perfectly now.
>
> Stephen, off hand, do you know if there is any extra space left over
> after your hardware scrolling patch? I'd like to use it, but I'm not
> sure if it will fit anymore with the extra 11 bytes I added in the space
> the base patch freed up.
>
> Thanks again for your help with this!
>
> On Sun, Nov 26, 2023 at 05:09:21AM -0500, Stephen Adolph wrote:
> >Both tests should modify carry flag?
> >
> >On Sunday, November 26, 2023, runrin  wrote:
> >
> >  Here's the patch I wrote after applying your base patch. I must be
> >  making a silly mistake here, since it doesn't seem to work correcly.
> >  Semi-colon is no longer shifted as expected, but it's not catching
> >  the
> >  `o' for some reason.
> >
> >  .org0722CH
> >  MOV A,C ; unchanged
> >  JMP extra   ; go to patch   [C3 AB 75]
> >  back(7230): MVI E,2CH   ; unchanged
> >  RET ; unchanged
> >
> >  .org075ABH
> >  extra:  CPI 1BH ; check for `o' [FE 1B]
> >  RZ  ;   [C8]
> >  CPI 19H ; > 25 ?[FE 19]
> >  RNC     ;   [D0]
> >  JMP back;   [C3 30 72]
> >
> >  On Sat, Nov 25, 2023 at 04:48:40PM -0500, Stephen Adolph wrote:
> >  >here is a file "base_patch" that describes 4 changes to the
> >  Main ROM to
> >  >create a hole from
> >  >75AB to 7640
> >  >which is free to use.
> >  >
> >  >"... Base patch, which provides about 150 free bytes to use for
> >  >modifications to the M100 ROM.  The basis of this patch is the
> >  >observation that the PIO data table could be reduced from 240
> >  bytes to
> >  >80 bytes.  This change forces a rewrite of a short section of a
> >  >routine."
> >  >
> >  >Good luck with it; I used it to implement the hardware scroll
> >  patch for
> >  >the M100.
> >  >The hardware scroll patch document has a section that details
> >  how the
> >  >base patch works.
> >  >cheers
> >  >Steve
> >  >
> >  >On Sat, Nov 25, 2023 at 1:05 PM runrin 
> wrote:
> >  >
> >  >  Wow, Stephen! Of course you know exactly where it is!
> >  >
> >  >  Thanks so much! If you could share your character printing
> >  patch I'd
> >  >  appreciate it.
> >  >
> >  >  Looks like the simplest way to get `o' to work with caps lock
> >  would
> >  >  be
> >  >  to just accept that `;' and `[' will also be shifted, and
> >  change the
> >  >  27
> >  >  to a 29.
> >  >
> >  >  It'll be fun to rewrite the routine though. It looks like
> >  there are
> >  >  5 or
> >  >  6 bytes free at the end of the ROM, so being able to squeeze
> >  the
> >  >  patch
> >  >  in there would be pretty nice.
> >  >
> >  >  On Sat, Nov 25, 2023 at 08:34:30AM -0500, Stephen Adolph
> >  wrote:
> >  >  >Since you are modifying the ROM, you may find to get
> >  what you
> >  >  want you
> >  >  >need more space.
> >  >  >
> >  >  >I have a patch that rewrites some routines for character
> >  >  printing that
> >  >  >frees up about 180 bytes if I recall correctly.  I've
> >  used this
> >  >  to fix
> >  >  >things I don't like in the Main ROM.
> >  >  >
> >  >  >I'm happy to share that patch, should your hacking
> >  require some
> >  >  bytes.
> >  >  >
> >  

Re: [M100] Alternate keymaps on the M100 (and a question about caps lock)

[Stephen Adolph]

Not sure there was any space left.

What I have found is that some programs directly write to the video driver
chips assuming they are all in the default scroll state.  This messes up
the display sometimes.  I'm not sure hardware scroll is good for that
reason.  The fix is to reset the machine when it becomes a problem which is
a pain.

On Monday, November 27, 2023, runrin  wrote:

> Ack! It was a silly mistake. I needed JZ not RZ. Everything is working
> perfectly now.
>
> Stephen, off hand, do you know if there is any extra space left over
> after your hardware scrolling patch? I'd like to use it, but I'm not
> sure if it will fit anymore with the extra 11 bytes I added in the space
> the base patch freed up.
>
> Thanks again for your help with this!
>
> On Sun, Nov 26, 2023 at 05:09:21AM -0500, Stephen Adolph wrote:
> >Both tests should modify carry flag?
> >
> >On Sunday, November 26, 2023, runrin  wrote:
> >
> >  Here's the patch I wrote after applying your base patch. I must be
> >  making a silly mistake here, since it doesn't seem to work correcly.
> >  Semi-colon is no longer shifted as expected, but it's not catching
> >  the
> >  `o' for some reason.
> >
> >  .org0722CH
> >  MOV A,C ; unchanged
> >  JMP extra   ; go to patch   [C3 AB 75]
> >  back(7230): MVI E,2CH   ; unchanged
> >  RET ; unchanged
> >
> >  .org075ABH
> >  extra:  CPI 1BH ; check for `o' [FE 1B]
> >  RZ  ;   [C8]
> >  CPI 19H ; > 25 ?[FE 19]
> >  RNC     ;   [D0]
> >  JMP back;   [C3 30 72]
> >
> >  On Sat, Nov 25, 2023 at 04:48:40PM -0500, Stephen Adolph wrote:
> >  >here is a file "base_patch" that describes 4 changes to the
> >  Main ROM to
> >  >create a hole from
> >  >75AB to 7640
> >  >which is free to use.
> >  >
> >  >"... Base patch, which provides about 150 free bytes to use for
> >  >modifications to the M100 ROM.  The basis of this patch is the
> >  >observation that the PIO data table could be reduced from 240
> >  bytes to
> >  >80 bytes.  This change forces a rewrite of a short section of a
> >  >routine."
> >  >
> >  >Good luck with it; I used it to implement the hardware scroll
> >  patch for
> >  >the M100.
> >  >The hardware scroll patch document has a section that details
> >  how the
> >  >base patch works.
> >  >cheers
> >  >Steve
> >  >
> >  >On Sat, Nov 25, 2023 at 1:05 PM runrin 
> wrote:
> >  >
> >  >  Wow, Stephen! Of course you know exactly where it is!
> >  >
> >  >  Thanks so much! If you could share your character printing
> >  patch I'd
> >  >  appreciate it.
> >  >
> >  >  Looks like the simplest way to get `o' to work with caps lock
> >  would
> >  >  be
> >  >  to just accept that `;' and `[' will also be shifted, and
> >  change the
> >  >  27
> >  >  to a 29.
> >  >
> >  >  It'll be fun to rewrite the routine though. It looks like
> >  there are
> >  >  5 or
> >  >  6 bytes free at the end of the ROM, so being able to squeeze
> >  the
> >  >  patch
> >  >  in there would be pretty nice.
> >  >
> >  >  On Sat, Nov 25, 2023 at 08:34:30AM -0500, Stephen Adolph
> >  wrote:
> >  >  >Since you are modifying the ROM, you may find to get
> >  what you
> >  >  want you
> >  >  >need more space.
> >  >  >
> >  >  >I have a patch that rewrites some routines for character
> >  >  printing that
> >  >  >frees up about 180 bytes if I recall correctly.  I've
> >  used this
> >  >  to fix
> >  >  >things I don't like in the Main ROM.
> >  >  >
> >  >  >I'm happy to share that 

Re: [M100] VT100 Emulation and DVi

[Stephen Adolph]

There are a couple of hard ones John.
Didn't we go through them and conclude certain m100 sequences could not be
done on VT100?
Having said that I don't recall which ones for sure.



On Sunday, November 26, 2023, John R. Hogerhuis  wrote:

> How different is vt100 from the m100's native terminal emulation (mostly
> vt52). What's missing that you need...
>
> I could map necessary codes in HTERM.  It already does a lot of processing
> to map utf8 characters and xterm escapes. In fact that's most of what HTERM
> does aside fromn hardware flow control.
>
> -- John.
>
>>

Re: [M100] Alternate keymaps on the M100 (and a question about caps lock)

[Stephen Adolph]

If the patch gets too challenging, you could always intercept the key
processing and transpose the 'o' key back into the first 26 characters.



On Sunday, November 26, 2023, Stephen Adolph  wrote:

> Both tests should modify carry flag?
>
> On Sunday, November 26, 2023, runrin  wrote:
>
>> Here's the patch I wrote after applying your base patch. I must be
>> making a silly mistake here, since it doesn't seem to work correcly.
>> Semi-colon is no longer shifted as expected, but it's not catching the
>> `o' for some reason.
>>
>> .org0722CH
>> MOV A,C ; unchanged
>> JMP extra   ; go to patch   [C3 AB 75]
>> back(7230): MVI E,2CH   ; unchanged
>> RET ; unchanged
>>
>> .org075ABH
>> extra:  CPI 1BH ; check for `o' [FE 1B]
>> RZ  ;   [C8]
>> CPI 19H ; > 25 ?[FE 19]
>> RNC ;   [D0]
>> JMP back;   [C3 30 72]
>>
>> On Sat, Nov 25, 2023 at 04:48:40PM -0500, Stephen Adolph wrote:
>> >here is a file "base_patch" that describes 4 changes to the Main ROM
>> to
>> >create a hole from
>> >75AB to 7640
>> >which is free to use.
>> >
>> >"... Base patch, which provides about 150 free bytes to use for
>> >modifications to the M100 ROM.  The basis of this patch is the
>> >observation that the PIO data table could be reduced from 240 bytes
>> to
>> >80 bytes.  This change forces a rewrite of a short section of a
>> >routine."
>> >
>> >Good luck with it; I used it to implement the hardware scroll patch
>> for
>> >the M100.
>> >The hardware scroll patch document has a section that details how the
>> >base patch works.
>> >cheers
>> >Steve
>> >
>> >On Sat, Nov 25, 2023 at 1:05 PM runrin  wrote:
>> >
>> >  Wow, Stephen! Of course you know exactly where it is!
>> >
>> >  Thanks so much! If you could share your character printing patch
>> I'd
>> >  appreciate it.
>> >
>> >  Looks like the simplest way to get `o' to work with caps lock would
>> >  be
>> >  to just accept that `;' and `[' will also be shifted, and change
>> the
>> >  27
>> >  to a 29.
>> >
>> >  It'll be fun to rewrite the routine though. It looks like there are
>> >  5 or
>> >  6 bytes free at the end of the ROM, so being able to squeeze the
>> >  patch
>> >  in there would be pretty nice.
>> >
>> >  On Sat, Nov 25, 2023 at 08:34:30AM -0500, Stephen Adolph wrote:
>> >  >Since you are modifying the ROM, you may find to get what you
>> >  want you
>> >  >need more space.
>> >  >
>> >  >I have a patch that rewrites some routines for character
>> >  printing that
>> >  >frees up about 180 bytes if I recall correctly.  I've used
>> this
>> >  to fix
>> >  >things I don't like in the Main ROM.
>> >  >
>> >  >I'm happy to share that patch, should your hacking require
>> some
>> >  bytes.
>> >  >
>> >  >to your question.
>> >  >
>> >  >722CH (79H) MOV A,C   Handle CAPS LOCK key during key decoding
>> >  >722DH (FEH) CPI 1AH
>> >  >722FH (D0H) RNC
>> >  >7230H (1EH) MVI E,2CH
>> >  >7232H (C9H) RET
>> >  >
>> >  >if the "regular key" is > 26 the key is not modified.
>> >  >because the key # for o is 27, no upper case.
>> >  >
>> >  >So you need a more complicated routine at 722Ch
>> >  >
>> >  >On Sat, Nov 25, 2023 at 1:08 AM runrin 
>> wrote:
>> >  >
>> >  >  Hey all!
>> >  >
>> >  >  I just finished building my FlexROM and patching the system
>> >  rom for
>> >  >  my
>> >  >  keyboard layout of choice (colemak). I'm super excited about
>> >  it
>> >  >  because
>> >  >  it will mak

Re: [M100] Alternate keymaps on the M100 (and a question about caps lock)

[Stephen Adolph]

Both tests should modify carry flag?

On Sunday, November 26, 2023, runrin  wrote:

> Here's the patch I wrote after applying your base patch. I must be
> making a silly mistake here, since it doesn't seem to work correcly.
> Semi-colon is no longer shifted as expected, but it's not catching the
> `o' for some reason.
>
> .org0722CH
> MOV A,C ; unchanged
> JMP extra   ; go to patch   [C3 AB 75]
> back(7230): MVI E,2CH   ; unchanged
> RET ; unchanged
>
> .org075ABH
> extra:  CPI 1BH ; check for `o' [FE 1B]
> RZ  ;   [C8]
> CPI 19H ; > 25 ?[FE 19]
> RNC ;   [D0]
> JMP back;   [C3 30 72]
>
> On Sat, Nov 25, 2023 at 04:48:40PM -0500, Stephen Adolph wrote:
> >here is a file "base_patch" that describes 4 changes to the Main ROM
> to
> >create a hole from
> >75AB to 7640
> >which is free to use.
> >
> >"... Base patch, which provides about 150 free bytes to use for
> >modifications to the M100 ROM.  The basis of this patch is the
> >observation that the PIO data table could be reduced from 240 bytes to
> >80 bytes.  This change forces a rewrite of a short section of a
> >routine."
> >
> >Good luck with it; I used it to implement the hardware scroll patch
> for
> >the M100.
> >The hardware scroll patch document has a section that details how the
> >base patch works.
> >cheers
> >Steve
> >
> >On Sat, Nov 25, 2023 at 1:05 PM runrin  wrote:
> >
> >  Wow, Stephen! Of course you know exactly where it is!
> >
> >  Thanks so much! If you could share your character printing patch I'd
> >  appreciate it.
> >
> >  Looks like the simplest way to get `o' to work with caps lock would
> >  be
> >  to just accept that `;' and `[' will also be shifted, and change the
> >  27
> >  to a 29.
> >
> >  It'll be fun to rewrite the routine though. It looks like there are
> >  5 or
> >  6 bytes free at the end of the ROM, so being able to squeeze the
> >  patch
> >  in there would be pretty nice.
> >
> >  On Sat, Nov 25, 2023 at 08:34:30AM -0500, Stephen Adolph wrote:
> >  >Since you are modifying the ROM, you may find to get what you
> >  want you
> >  >need more space.
> >  >
> >  >I have a patch that rewrites some routines for character
> >  printing that
> >  >frees up about 180 bytes if I recall correctly.  I've used this
> >  to fix
> >  >things I don't like in the Main ROM.
> >  >
> >  >I'm happy to share that patch, should your hacking require some
> >  bytes.
> >  >
> >  >to your question.
> >  >
> >  >722CH (79H) MOV A,C   Handle CAPS LOCK key during key decoding
> >  >722DH (FEH) CPI 1AH
> >  >722FH (D0H) RNC
> >  >7230H (1EH) MVI E,2CH
> >  >7232H (C9H) RET
> >  >
> >  >if the "regular key" is > 26 the key is not modified.
> >  >because the key # for o is 27, no upper case.
> >  >
> >  >So you need a more complicated routine at 722Ch
> >  >
> >  >On Sat, Nov 25, 2023 at 1:08 AM runrin 
> wrote:
> >  >
> >  >  Hey all!
> >  >
> >  >  I just finished building my FlexROM and patching the system
> >  rom for
> >  >  my
> >  >  keyboard layout of choice (colemak). I'm super excited about
> >  it
> >  >  because
> >  >  it will make my m100 much more usable for me.
> >  >
> >  >  Here are the relevant lines of the rom that were patched if
> >  anyone
> >  >  is
> >  >  interested:
> >  >
> >  >  7BF0   AA 7A 78 63  76 62 6B 6D  69 61 72 73  74 64 68 6E
> >  >  .zxcvbkmiarstdhn
> >  >  7C00   65 71 77 66  70 67 6A 6C  75 79 3B 5B  6F 27 2C 2E
> >  >  eqwfpgjluy;[o',.
> >  >  7C10   2F 31 32 33  34 35 36 37  38 39 30 2D  3D 5A 58 43
> >  >  /1234567890-=ZXC
> >  

[M100] Alternate keymaps on the M100 (and a question about caps lock)

[Stephen Adolph]

 I use the Telemark TASM32.  I think you can find it online, not sure.

On Saturday, November 25, 2023, runrin  wrote:

> What assembler are you using Stephen? There are a large number of
> assemblers available in my package manager on linux, but they all seem
> to use different syntax than your patch (or they just don't support
> things like .org at all for some reason.) I actually came close to
> trying ZBUG on the m100 :P
>
> Thanks
>
> On Sat, Nov 25, 2023 at 04:48:40PM -0500, Stephen Adolph wrote:
> >here is a file "base_patch" that describes 4 changes to the Main ROM
> to
> >create a hole from
> >75AB to 7640
> >which is free to use.
> >
> >"... Base patch, which provides about 150 free bytes to use for
> >modifications to the M100 ROM.  The basis of this patch is the
> >observation that the PIO data table could be reduced from 240 bytes to
> >80 bytes.  This change forces a rewrite of a short section of a
> >routine."
> >
> >Good luck with it; I used it to implement the hardware scroll patch
> for
> >the M100.
> >The hardware scroll patch document has a section that details how the
> >base patch works.
> >cheers
> >Steve
> >
> >On Sat, Nov 25, 2023 at 1:05 PM runrin  wrote:
> >
> >  Wow, Stephen! Of course you know exactly where it is!
> >
> >  Thanks so much! If you could share your character printing patch I'd
> >  appreciate it.
> >
> >  Looks like the simplest way to get `o' to work with caps lock would
> >  be
> >  to just accept that `;' and `[' will also be shifted, and change the
> >  27
> >  to a 29.
> >
> >  It'll be fun to rewrite the routine though. It looks like there are
> >  5 or
> >  6 bytes free at the end of the ROM, so being able to squeeze the
> >  patch
> >  in there would be pretty nice.
> >
> >  On Sat, Nov 25, 2023 at 08:34:30AM -0500, Stephen Adolph wrote:
> >  >Since you are modifying the ROM, you may find to get what you
> >  want you
> >  >need more space.
> >  >
> >  >I have a patch that rewrites some routines for character
> >  printing that
> >  >frees up about 180 bytes if I recall correctly.  I've used this
> >  to fix
> >  >things I don't like in the Main ROM.
> >  >
> >  >I'm happy to share that patch, should your hacking require some
> >  bytes.
> >  >
> >  >to your question.
> >  >
> >  >722CH (79H) MOV A,C   Handle CAPS LOCK key during key decoding
> >  >722DH (FEH) CPI 1AH
> >  >722FH (D0H) RNC
> >  >7230H (1EH) MVI E,2CH
> >  >7232H (C9H) RET
> >  >
> >  >if the "regular key" is > 26 the key is not modified.
> >  >because the key # for o is 27, no upper case.
> >  >
> >  >So you need a more complicated routine at 722Ch
> >  >
> >  >On Sat, Nov 25, 2023 at 1:08 AM runrin 
> wrote:
> >  >
> >  >  Hey all!
> >  >
> >  >  I just finished building my FlexROM and patching the system
> >  rom for
> >  >  my
> >  >  keyboard layout of choice (colemak). I'm super excited about
> >  it
> >  >  because
> >  >  it will make my m100 much more usable for me.
> >  >
> >  >  Here are the relevant lines of the rom that were patched if
> >  anyone
> >  >  is
> >  >  interested:
> >  >
> >  >  7BF0   AA 7A 78 63  76 62 6B 6D  69 61 72 73  74 64 68 6E
> >  >  .zxcvbkmiarstdhn
> >  >  7C00   65 71 77 66  70 67 6A 6C  75 79 3B 5B  6F 27 2C 2E
> >  >  eqwfpgjluy;[o',.
> >  >  7C10   2F 31 32 33  34 35 36 37  38 39 30 2D  3D 5A 58 43
> >  >  /1234567890-=ZXC
> >  >  7C20   56 42 4B 4D  49 41 52 53  54 44 48 4E  45 51 57 46
> >  >  VBKMIARSTDHNEQWF
> >  >  7C30   50 47 4A 4C  55 59 3A 5D  4F 22 3C 3E  3F 21 40 23
> >  >  PGJLUY:]O"<>?!@#
> >  >  ...
> >  >  7CF0   00 00 00 D4  D2 D3 A6 A7  A8 6D 30 6E  31 65 32 69
> >  >  .m0n1e2i
> >  >  

Re: [M100] Alternate keymaps on the M100 (and a question about caps lock)

[Stephen Adolph]

Since you are modifying the ROM, you may find to get what you want you need
more space.

I have a patch that rewrites some routines for character printing that
frees up about 180 bytes if I recall correctly.  I've used this to fix
things I don't like in the Main ROM.

I'm happy to share that patch, should your hacking require some bytes.


to your question.

722CH (79H) MOV A,C Handle CAPS LOCK key during key decoding
722DH (FEH) CPI 1AH
722FH (D0H) RNC
7230H (1EH) MVI E,2CH
7232H (C9H) RET

if the "regular key" is > 26 the key is not modified.
because the key # for o is 27, no upper case.

So you need a more complicated routine at 722Ch



On Sat, Nov 25, 2023 at 1:08 AM runrin  wrote:

> Hey all!
>
> I just finished building my FlexROM and patching the system rom for my
> keyboard layout of choice (colemak). I'm super excited about it because
> it will make my m100 much more usable for me.
>
> Here are the relevant lines of the rom that were patched if anyone is
> interested:
>
> 7BF0   AA 7A 78 63  76 62 6B 6D  69 61 72 73  74 64 68 6E
> .zxcvbkmiarstdhn
> 7C00   65 71 77 66  70 67 6A 6C  75 79 3B 5B  6F 27 2C 2E
> eqwfpgjluy;[o',.
> 7C10   2F 31 32 33  34 35 36 37  38 39 30 2D  3D 5A 58 43
> /1234567890-=ZXC
> 7C20   56 42 4B 4D  49 41 52 53  54 44 48 4E  45 51 57 46
> VBKMIARSTDHNEQWF
> 7C30   50 47 4A 4C  55 59 3A 5D  4F 22 3C 3E  3F 21 40 23
> PGJLUY:]O"<>?!@#
> ...
> 7CF0   00 00 00 D4  D2 D3 A6 A7  A8 6D 30 6E  31 65 32 69
> .m0n1e2i
> 7D00   33 6C 34 75  35 79 36 01  06 14 02 20  7F 09 1B 8B  3l4u5y6
> 
>
> The last two lines makes the number pad work correctly (an extremely
> easy fix!)
>
> There is just one small bug with my patch, and that is caps lock not
> working correctly. When caps lock is enabled, `o' remains lowercase and
> `;' types a `:'. I presume this is due to the way caps lock works with
> the keyboard matrix. The letter `o' has been moved out of the letter
> rows of the keyboard matrix, and is now in one of the symbol
> rows. The opposite is true of the semi-colon, now being part of the
> letter matrix replacing `p'.
>
>
> Does anyone know if caps lock is done in software, or if it's modifying
> which characters are being selected by pulling a bit high or something?
>
> This is a really small issue, but I would like to get it working
> correctly. I'll dive into the schematic when I have some time and see if
> I can find a hint about how caps lock works. If not I'll start messing
> around with Virtual-T and see what I can find there.
>
> If I dig anything interesting up, I'll update this thread with what I
> learn.
>

[M100] MVT100 desktop application

[Stephen Adolph]

I've posted the initial version of the Windows 10 application and the
Visual Studio source code at

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


cheers
Steve

Re: [M100] Model T clock doubler

[Stephen Adolph]

I will definitely post the source code at bitchin100 later today.


On Thursday, November 23, 2023, Joshua O'Keefe 
wrote:

> > On Nov 23, 2023, at 8:13 AM, Stephen Adolph 
> wrote:
> >
> > If it adds value, getting a linux version would be nice too I think.
> > I'm happy to share the files I compiled.
>
> Hey Steve,
>
> I'd love access to the source code to make an attempt at building a Linux
> version.  I'm far from a .Net guy but I suspect the differences on the
> serial port side won't be all that large, and everything else should
> hopefully be "close enough."

Re: [M100] Model T clock doubler

[Stephen Adolph]

Joshua, it seems to be working fine to be honest.
As I left it, it runs on windows 10, but probably works on other windows
versions too.
If it adds value, getting a linux version would be nice too I think.
I'm happy to share the files I compiled.
Steve


On Thu, Nov 23, 2023 at 10:27 AM Joshua O'Keefe 
wrote:

> > On Nov 23, 2023, at 5:27 AM, Stephen Adolph 
> wrote:
> >
> > So now my windows machine has a terminal that obeys M100 screen codes,
> and character set.
>
> Since you're continuing to use the program, I'm curious how well it's been
> serving you.  Has this version mostly held up when you reach for it?  Your
> humble disclaimer about bugs aside, it sounds like the program has been a
> useful addition to your workflow.
>
> As you might recall, I'm a REXCPM owner, but I've been slow to pull the
> trigger so far on installation -- too many projects on the backlog! -- but
> if the terminal program has been fairly solid day to day that's an
> enticement to start my installation... And to work on trying to fire up the
> terminal program on the other platforms I use.

Re: [M100] Model T clock doubler

[Stephen Adolph]

Thanks Joshua, that's the one.
I was switching my monitor between regular use and modelT use, and having
the Geoff serial terminal as the intermediary was frustrating a bit.

So now my windows machine has a terminal that obeys M100 screen codes, and
character set.

..steve


On Thursday, November 23, 2023, Joshua O'Keefe 
wrote:

> On Nov 22, 2023, at 9:01 PM, MikeS  wrote:
>
> MVT100 Windows application???
>
>
> I think that's referring to this program:
> Club100 Member Upload Library
> 
> club100.org
> 
>
> 
> 
>
> To quote Steve: "This is a Windows program that is serial-fed terminal
> emulator specifically modified to match the M100 screen output. It enables
> an 80x24 terminal screen. Compiled on Windows 10 using Visual Studio, based
> on .NET 4.8. Program is very early and possibly quite buggy"
>
>

[M100] minor update to REX#/REXCPM

[Stephen Adolph]

hi all,
Turns out I made a typo with month display in REXMGR - I displayed October
as Ont instead of Oct.
I've posted build 41 to address.
regards,
Steve

Re: [M100] Model T clock doubler

[Stephen Adolph]

Ken I will try to complete a package of info for m100 in time!

You could consider the BCR hack for serial comms over BCR port.  The VT100
driver on M100 plus my MVT100 windows application would allow you to demo
using the PC as an 80x25  monitor for M100.  No other hardware needed.

Cheers Steve

On Tuesday, November 21, 2023, Ken St. Cyr  wrote:

> Amazing work, Steve! I've been thinking about doing an M100 mod
> extravaganza video, so this is one mod that I definitely want to do for
> that project. I'll likely be checking it out over Christmas break in a few
> weeks.
>
> //Ken S
> --
> *From:* M100  on behalf of Brian White
> 
> *Sent:* Monday, November 20, 2023 12:46:06 PM
> *To:* m...@bitchin100.com 
> *Subject:* Re: [M100] Model T clock doubler
>
> Hah, all of my own boards get to about v 12 before I'm mostly happy, and
> then continue polishing for several more. It's almost like software, never
> really done.
>
> bkw
>
> On Sun, Nov 19, 2023, 7:56 PM Stephen Adolph  wrote:
>
> I jumped the gun a bit, needed to redo the boards and change the circuit.
>
> On Sunday, November 19, 2023, Brian K. White  wrote:
>
> None of the file links work, but I'm sure it *will* be awesome.
> Sounds super.
>
> On 11/18/23 10:54, Stephen Adolph wrote:
>
> Hi everyone,
>
> I've been working towards finishing off my project for increasing the
> speed of the Model T laptops.  The idea is to create a (relatively) easy to
> make and install solution that allows the user to switch the clock rate
> from 2.5 MHz to 5 MHz.
> This is really nice on the 40x8 LCD machines.
>
> The universal software command to switch clock rate is
> OUT 85,1 for 2x mode and
> OUT 85,0 for 1x mode.
>
> Of course the Model T is not designed for this, but in my experience so
> far, it seems reliable.  I really like the upgrade and plan to install in
> all my laptops. Being able to operate in nominal clock mode is of course
> very useful because you may find some software to be incompatible.
>
> Models I have upgraded to date:
> * M100 (NA, early variant, not UK)
> * T102
> * T200
> * NEC PC-8201/8201a
> * Olivetti M10
>
> I am publishing all the information needed to DIY this upgrade. I don't
> have any plans to make these upgrades.  Consider this upgrade only if you
> are comfortable with soldering surface mount parts, and with making minor
> modifications to your laptop.
>
> Upgrades that are done and in the process of documentation are M100, T200,
> NEC.  Upgrades that need a new PCB design still are T102 and M10.  All
> information will be at this site:
>
> https://bitchin100.com/wiki/index.php?title=5MHZ_upgrade_for_Model_T <
> https://bitchin100.com/wiki/index.php?title=5MHZ_upgrade_for_Model_T>
>
> I am publishing
> * PCB designs for the clock doubler board (there are a few variants)
> * schematic
> * bill of materials for parts you need
> * documentation for building the clock doubler
> * installation documentation per laptop
>
> Things I have discovered while developing this;
> 1.  Power consumption goes up by about 20% when you run at 2x clock.
> 2.  Depending on the speed of your SRAM,  you may need to implement a
> modification to speed that up.  Each model has a specific mod you need.
> 3.  In M100 with the custom socket pinout, in most cases you need to
> upgrade your Main ROM to something faster.  This usually involves an
> adapter board and an EPROM.
> 4.  In the Tandy 200, one must slow down the machine temporarily to access
> the RTC.  There is a specific change for that.
>
> Anyhow, as I complete a particular laptop, I'll post the needed files.
>
> Hopefully this will be of some interest for those inclined to play around
> with hardware.  I have no problem if anyone wants to take the design and
> improve it or change it.
>
> Feel free to contact me directly with questions.
>
> cheers
> Steve
>
>
>
>
>
> --
> bkw
>
>

Re: [M100] Model T clock doubler

[Stephen Adolph]

I jumped the gun a bit, needed to redo the boards and change the circuit.

On Sunday, November 19, 2023, Brian K. White  wrote:

> None of the file links work, but I'm sure it *will* be awesome.
> Sounds super.
>
> On 11/18/23 10:54, Stephen Adolph wrote:
>
>> Hi everyone,
>>
>> I've been working towards finishing off my project for increasing the
>> speed of the Model T laptops.  The idea is to create a (relatively) easy to
>> make and install solution that allows the user to switch the clock rate
>> from 2.5 MHz to 5 MHz.
>> This is really nice on the 40x8 LCD machines.
>>
>> The universal software command to switch clock rate is
>> OUT 85,1 for 2x mode and
>> OUT 85,0 for 1x mode.
>>
>> Of course the Model T is not designed for this, but in my experience so
>> far, it seems reliable.  I really like the upgrade and plan to install in
>> all my laptops. Being able to operate in nominal clock mode is of course
>> very useful because you may find some software to be incompatible.
>>
>> Models I have upgraded to date:
>> * M100 (NA, early variant, not UK)
>> * T102
>> * T200
>> * NEC PC-8201/8201a
>> * Olivetti M10
>>
>> I am publishing all the information needed to DIY this upgrade. I don't
>> have any plans to make these upgrades.  Consider this upgrade only if you
>> are comfortable with soldering surface mount parts, and with making minor
>> modifications to your laptop.
>>
>> Upgrades that are done and in the process of documentation are M100,
>> T200, NEC.  Upgrades that need a new PCB design still are T102 and M10.
>> All information will be at this site:
>>
>> https://bitchin100.com/wiki/index.php?title=5MHZ_upgrade_for_Model_T <
>> https://bitchin100.com/wiki/index.php?title=5MHZ_upgrade_for_Model_T>
>>
>> I am publishing
>> * PCB designs for the clock doubler board (there are a few variants)
>> * schematic
>> * bill of materials for parts you need
>> * documentation for building the clock doubler
>> * installation documentation per laptop
>>
>> Things I have discovered while developing this;
>> 1.  Power consumption goes up by about 20% when you run at 2x clock.
>> 2.  Depending on the speed of your SRAM,  you may need to implement a
>> modification to speed that up.  Each model has a specific mod you need.
>> 3.  In M100 with the custom socket pinout, in most cases you need to
>> upgrade your Main ROM to something faster.  This usually involves an
>> adapter board and an EPROM.
>> 4.  In the Tandy 200, one must slow down the machine temporarily to
>> access the RTC.  There is a specific change for that.
>>
>> Anyhow, as I complete a particular laptop, I'll post the needed files.
>>
>> Hopefully this will be of some interest for those inclined to play around
>> with hardware.  I have no problem if anyone wants to take the design and
>> improve it or change it.
>>
>> Feel free to contact me directly with questions.
>>
>> cheers
>> Steve
>>
>>
>>
>>
>>
> --
> bkw
>
>

[M100] Model T clock doubler

[Stephen Adolph]

Hi everyone,

I've been working towards finishing off my project for increasing the speed
of the Model T laptops.  The idea is to create a (relatively) easy to make
and install solution that allows the user to switch the clock rate from 2.5
MHz to 5 MHz.
This is really nice on the 40x8 LCD machines.

The universal software command to switch clock rate is
OUT 85,1 for 2x mode and
OUT 85,0 for 1x mode.

Of course the Model T is not designed for this, but in my experience so
far, it seems reliable.  I really like the upgrade and plan to install in
all my laptops. Being able to operate in nominal clock mode is of course
very useful because you may find some software to be incompatible.

Models I have upgraded to date:
* M100 (NA, early variant, not UK)
* T102
* T200
* NEC PC-8201/8201a
* Olivetti M10

I am publishing all the information needed to DIY this upgrade. I don't
have any plans to make these upgrades.  Consider this upgrade only if you
are comfortable with soldering surface mount parts, and with making minor
modifications to your laptop.

Upgrades that are done and in the process of documentation are M100, T200,
NEC.  Upgrades that need a new PCB design still are T102 and M10.  All
information will be at this site:

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

I am publishing
* PCB designs for the clock doubler board (there are a few variants)
* schematic
* bill of materials for parts you need
* documentation for building the clock doubler
* installation documentation per laptop

Things I have discovered while developing this;
1.  Power consumption goes up by about 20% when you run at 2x clock.
2.  Depending on the speed of your SRAM,  you may need to implement a
modification to speed that up.  Each model has a specific mod you need.
3.  In M100 with the custom socket pinout, in most cases you need to
upgrade your Main ROM to something faster.  This usually involves an
adapter board and an EPROM.
4.  In the Tandy 200, one must slow down the machine temporarily to access
the RTC.  There is a specific change for that.

Anyhow, as I complete a particular laptop, I'll post the needed files.

Hopefully this will be of some interest for those inclined to play around
with hardware.  I have no problem if anyone wants to take the design and
improve it or change it.

Feel free to contact me directly with questions.

cheers
Steve

Re: [M100] FlexROM with REX#

[Stephen Adolph]

Sorry, no REX# does not include the function to replace the main ROM.
How I would tackle a custom ROM in the M100
* develop in inside Virtual T
* get a socket adapter PCB for a 27C256 EPROM, or better still use an EEPROM
* once you have a prototype in VT, burn it and install in the M100

Maybe FlexROM helps? is it a better way to get the ROM swapped?  I don't
know much about it.
...Steve

On Sun, Nov 12, 2023 at 5:10 PM runrin  wrote:

> Hi all,
>
> I've got a REX# in my m100 and was wondering if it was compatible with
> the FlexROM, which I see uses some jumper cables to interface with the
> original REX. The REX# doesn't seem to have the pins to connect those
> jumpers.
>
> My priority is changing the keymap for the m100 since I don't use
> QWERTY, but being able to hack the ROM right from the machine with the
> REX seems like a nice feature. I will likely order a FlexROM board
> anyway, since it seems like the best option to swap my LH535618 system
> rom.
>
> Has anyone had any success getting the FlexROM working with the REX#?
> Any tips would be appreciated. I don't mind hacking the REX# with bodge
> wires if that's what I have to do.
>
> If anyone has other suggestions for the best way to swap the rom, it's
> unlikely I will be doing it regularly once I have my keymap working the
> way I want, so I'd be open for suggestions there too.
>
> Thanks!
>

Re: [M100] Bitchin100 down?

[Stephen Adolph]

it seems like if I do something illegal editing a wikitable, the reaction
is to deny access from the specific IP.
I say this because I see the same behaviour while editing the wiki from 2
different IP addresses.

I think the wiki is still up for other IPs, just not mine.

interesting.


On Sun, Nov 5, 2023 at 2:48 PM John R. Hogerhuis  wrote:

>
>
> On Sun, Nov 5, 2023, 11:13 AM Stephen Adolph  wrote:
>
>> its ok, working now.  I think I was doing something illegal in editing
>>
>>
> Ok cool
>
> -- John.
>

Re: [M100] Bitchin100 down?

[Stephen Adolph]

its ok, working now.  I think I was doing something illegal in editing

On Sun, Nov 5, 2023 at 2:05 PM John R. Hogerhuis  wrote:

> I'll check editing later.
>
> I went through a bunch of work months ago to get on a newer version of PHP
> but everything seemed to be working then.
>
>
> -- John.
>
> On Sun, Nov 5, 2023, 10:42 AM Stephen Adolph  wrote:
>
>> seems my firewall is misbehaving.  it is singling out bitchin100.
>> strange.
>>
>> On Sun, Nov 5, 2023 at 1:30 PM r cs  wrote:
>>
>>> Hi Steve.  It's up for me at 1328 eastern.
>>>
>>> On Sun, Nov 5, 2023 at 11:11 AM Stephen Adolph 
>>> wrote:
>>>
>>>> hi folks, is anyone else having trouble with bitchin100.com?
>>>> Seems like the site might be down.
>>>> thanks, Steve
>>>>
>>>
>>>
>>> --
>>> *Níl aon tinteán mar do thinteán féin. *[Irish Gaelic]
>>> (There is no fireside like your own fireside.)
>>>
>>>
>>>

Re: [M100] Bitchin100 down?

[Stephen Adolph]

seems my firewall is misbehaving.  it is singling out bitchin100.  strange.

On Sun, Nov 5, 2023 at 1:30 PM r cs  wrote:

> Hi Steve.  It's up for me at 1328 eastern.
>
> On Sun, Nov 5, 2023 at 11:11 AM Stephen Adolph 
> wrote:
>
>> hi folks, is anyone else having trouble with bitchin100.com?
>> Seems like the site might be down.
>> thanks, Steve
>>
>
>
> --
> *Níl aon tinteán mar do thinteán féin. *[Irish Gaelic]
> (There is no fireside like your own fireside.)
>
>
>

Re: [M100] Bitchin100 down?

[Stephen Adolph]

Seems like editing the wiki is crashing my access to the site.  Strange.
I have access.
I edit the wiki.
I attempt a SAVE.
access crashes, regardless of what machine I use to access bitchin100.com



On Sun, Nov 5, 2023 at 11:15 AM Kenneth Pettit  wrote:

> Hey Steve,
>
> It is working for me.
>
> Ken
>
> On 11/5/23 8:11 AM, Stephen Adolph wrote:
>
> hi folks, is anyone else having trouble with bitchin100.com?
> Seems like the site might be down.
> thanks, Steve
>
>
>

[M100] Bitchin100 down?

[Stephen Adolph]

hi folks, is anyone else having trouble with bitchin100.com?
Seems like the site might be down.
thanks, Steve

Re: [M100] REX#/REXCPM release 2.2 is on the wiki

[Stephen Adolph]

Hi Pawel,

I included a note in the instructions.

'x' is a variable: 1,2 or N - depending on your model

hope that addresses the concern.
Thanks Steve


On Sunday, November 5, 2023, Pawel Radomychelski | ExPLIT <
exp...@mailbox.org> wrote:

> Hello Steve!
>
> Thank you for the bugfix relese of REX# 22
>
> Upde went with one small issue:
>
> When i use your Instructions here:
>
> Instructions
>   
>   1.  Make sure REX# is in default state, meaning
>   a. REX# Manager is not running (use CNTL-X to remove hooks, or F7 from 
> REXMGR)
>   b. Power cycle once, to ensure the default memory blocks are selected
>   c. Optionally, cold-rebooting the laptop after a power cycle ensures a 
> clean state.
>   2.  Load RX#Ux.DO via serial transfer, or TPDD transfer.
>   3.  RUN RX#Ux.DO in BASIC.
>   RX#Ux.DO allows you to choose to LOAD a REX# application (24kB file)
>   4.  Configure RX#Ux.DO to do the following:
>   a.  indicate YES to "Load REX code:" using space bar/enter
>   b.  execute these choices by pressing Y.
>   5.  The loader will load up the machine language routine, and begin to 
> execute
>   6.  To LOAD a fresh REX# Manager application, RX#Ux.DO accesses a remote 
> TPDD server to get the binary 24k file.
>   RX#Ux.DO contains it's own TPDD access routines, and does not need a 
> DOS.
>   a. Ensure a TPDD server is ready to go with the source file as needed. 
> ex. RX#_12.BR
>   b. When asked for a NAME, Supply the correct file name (6 characters, 
> no extension, case sensitive) ex RX#_12
>   File extension is automatically set to .BR
>   7.  Let the program run
>   You should see a counter counting up from zero to 24,576 bytes
>   When complete, REX# should have a fresh software load installed.
>   The directory should be unchanged, and the saved images should be 
> intact.
>
>
>
> In the Step 6. its not clear, which file should be loaded: RX#_12.BR, 
> RX#_22.BR or RX#_N2.BR.
>
> First i choosed RX#_22.BR because i was confused with Version 22. After REX 
> was not accesable anymore, i updated it again with RX#_N2.BR
>
> Maybe the instructions should be updated to clarify on which machines, which 
> file should be used.
>
>
> Thanks!
>
>
> --
>
> Kind regards /
> Mit freundlichen Grüßen
>
> ExPLIT IT Solutions
> Pawel Radomychelski
>
>
>
> -Original Message-
> *From*: Stephen Adolph  >
> *Reply-To*: m...@bitchin100.com
> *To*: m...@bitchin100.com
> *Subject*: [M100] REX#/REXCPM release 2.2 is on the wiki
> *Date*: 11/05/23 04:23:32
>
> Sorry for the huge delay.
> I've updated the REX# wiki to post the Release 2.2 file sets for REXCPM
> and REX#.
> Let me know if anyone has any trouble.
>
> cheers
> Steve
>
> https://bitchin100.com/wiki/index.php?title=REXCPM#Software
> https://bitchin100.com/wiki/index.php?title=REXsharp#Software
>
>
>

[M100] REX#/REXCPM release 2.2 is on the wiki

[Stephen Adolph]

Sorry for the huge delay.
I've updated the REX# wiki to post the Release 2.2 file sets for REXCPM and
REX#.
Let me know if anyone has any trouble.

cheers
Steve

https://bitchin100.com/wiki/index.php?title=REXCPM#Software
https://bitchin100.com/wiki/index.php?title=REXsharp#Software

Re: [M100] rexcpm battery

[Stephen Adolph]

Hi,
I only want to comment that I think this is very clever and useful!  Looks
like great work indeed!

A point of clarification though.  Brian, rexcpm is not usable in Tandy
200.

Cheers  Steve

On Wednesday, September 20, 2023, Ken St. Cyr  wrote:

> It turned out nice and looks pretty solid (at least in the pictures). I
> ordered boards and parts the other day, so I'm just waiting for those to
> arrive now. I'll report back and share my experience after getting one
> together -
>
> //Ken
> --
> *From:* M100  on behalf of Brian K.
> White 
> *Sent:* Tuesday, September 19, 2023 10:18 PM
> *To:* m100@lists.bitchin100.com 
> *Subject:* Re: [M100] rexcpm battery
>
> I have repaired my REXCPM and now the github readme includes pics that
> show a good way to mount a qwiic connector and where to connect bodge
> wires if you want to take on the challenge of such small loose wires
> going to such small places. All 4 solder points are at least a
> reasonable chip leg, no soldering directly to delicate traces. So the
> wires are reasonably robust in the end. You can install & remove the
> rexcpm module without straining the wires. I will probably further
> secure them with glue sometime later but haven't yet.
>
> I don't think it's worth it just to get the connector if your original
> pins are still intact, even though the connector is more convenient in
> the end, but since my original pins rotated and broke their traces
> anyway, I had to do a bodge wire repair anyway. And mounting the
> connector seems to be solid enough by super-glueing it to the top of a
> chip, and by using one of the black versions of the connector which I
> think is a material that the glue can stick to easier. The natural
> colored ones look like they might be something no glue will stick to.
> The black ones feel like they have some glass filler, and can be scuffed
> to a rough texture. Seems to be pretty solid so far though I'm not
> testing-to-destruction just to find out. :)
> single https://www.sparkfun.com/products/14417
> 10 pack https://www.adafruit.com/product/4208
>
> My rexcpm is running and working so I can resume testing battery life.
>
> I think it's safe to order pcbs if you want now. The dupont breakout
> cable is a good solution for keeping the REXCPM side of things simple
> and stock, and adding the single wire for gnd is easy, reasonably safe
> against blunders, and leaves the REXCPM still compatible with it's
> original bus board and cable.  So the bus board can keep the qwiic
> connector.
>
> I have tested the 102/200 board now too. good to go. I don't have a
> pcbway or gerbers up for that yet but will shortly.
>
> --
> bkw
>
>
> On 9/19/23 04:29, Brian K. White wrote:
> > My boards came in and at least the model 100 one works fine.
> >
> > There's room, but no good way to solder the qwiic connector to the
> > REXCPM, so the most practical way to handle the REXCPM side is just
> > use the pre-made adapter cable that has female dupont sockets, and
> > stick them right onto the original pins.
> >
> > For the GND wire, you can treat it as optional and leave that wire
> > unconnected, or add a single solid-core wire to the big cap for the
> > gnd connection. If you use 23 gauge solid core wire, or maybe a size
> > or so thicker, the wire is stiff enough to hold it's shape and thick
> > enough for a female dupont socket to stick onto it and not fall off. I
> > used 23 gauge wire from some solid core ethernet cable and that was
> > about perfect. Other common sources, thermostat wire, doorbell wire.
> >
> > Take a 25mm piece of wire, strip 3mm on one end and bend it sharp 90
> > degrees, strip 6mm on the other end, poke the wire in between the cap
> > and the 3 pins and solder the short bent end to the cap.
> >
> > Then the 4 female dupont wires go like this:
> >
> > black  (GND) ->  wire on cap
> > red(/WR) ->  closest pin to cap
> > blue   (RAM) ->  middle pin
> > yellow (RAM_RST) ->  furthest pin from cap
> >
> >
> >
> > It turns out you have to be very careful not to strain the original
> > pins on the REXCPM.. They rotate pretty easily and break the via free
> > inside the pcb, and then the traces break.
> >
> > At one point I was stuffing the gnd wire down from the top in between
> > the pin and the cap, and that put sideways strain on the pin.
> >
> > My REXCPM doesn't work now unless I hold the pins a certain way to
> > cause them to make contact.
> >
> > I have to desolder a few parts to figure out where two of the traces
> > go so I can find where to run bodge wires. Fixing the original traces
> > right where they broke at the base of the pins is probably too fragile
> > now that the vias are moving like that.
> >
> > Maybe I'll just remove the pins, fix the existing traces where they
> > broke, and solder flexible wires instead of pins where the pins used
> > to go, and secure the solder joints with glue or epoxy. Hopefully the
> > combination of the glue and the 

Re: [M100] Bitchin100 Wiki upgrades complete

[Stephen Adolph]

Thank you John!

On Wednesday, June 14, 2023, John R. Hogerhuis  wrote:

> The upgrades are completed, and it's working on PHP 8.1 now.
>
> Seems to be all good... let me know if you encounter any issues.
>
> https://bitchin100.com/wiki
>
> -- John.
>

Re: [M100] Rex# Crash on an M102

[Stephen Adolph]

Charlie,
Hard to say what's wrong.
In an ideal situation, I'd like to get it back and root cause the problem.

So, yoo could send it back and I send you a replacement.

Short of that,  a rebuild would be what is needed.

Release 2.1 to do a rebuild are posted on the wiki, along with
instructions.

Option 1.  Refresh the rom.  This puts a freshness copy of rex manager in
the flash.  It preserves your saved images and directory.

If that does not work..

Option 2.  Rebuild.  This is a complete wipe and reset to original, erasing
the contents.

Your rom images are likely there and still fine.  I've never written tools
tor ecover them.  If you need those images I could probably recover them
for you if you send me the rex#.

..steve


On Thursday, May 25, 2023, Charlie Hoey  wrote:

> Hello there!
>
> I had my first crash on a Rex# that I can't get myself out of, curious if
> anybody has any tips.
>
> I was in the process of creating a clean bank for a new project, and it
> failed somewhere near the end. I RESET and then ran `CALL 63012` to reload
> REX, but now whenever I start REXMGR, it attempts to load/write something
> and hangs. I've done a cold reset, pulled batteries etc, so I think it's in
> eeprom/flash somewhere. Here's a shot of what I'm seeing:
>
> [image: Screen Shot 2023-05-25 at 9.13.23 PM.jpg]
> If images don't work here, launching REXMGR shows the standard top line
> with "REX #2.1" in the top left, and the bottom right is the progress bar,
> which fills up most of the way and then hangs.
>
> Any way I might peek/poke my way back to a usable state? I don't care
> about the in progress job that failed, so if I could clear a flag or get it
> to just abandon it that would be fine.
>
> Thanks as always!
> -Charlie
>

[M100] interesting

[Stephen Adolph]

https://www.aliexpress.com/item/1005005534146618.html

Concept is neat but I think the execution was bad.  Apparently the BIOS was
modified and used without following the author's license.  (FYI BIOS author
requesting that no one purchase this until the license issue is resolved)

Made me think of a 2nd generation M100 work alike.

Re: [M100] teeny (or any tpdd client) for German Olivetti M10?

[Stephen Adolph]

Good news.
Well a port of teeny should be possible.

On Thursday, May 18, 2023, Brian K. White  wrote:

> It probably is the same EU rom as others, but that is still different from
> the US rom, and code for the US rom doesn't run on the EU rom without
> porting.
>
> Maybe Germen specifically doesn't break anything if there were at least a
> version that ran on the EU rom.
>
> We do have rom images of both the US and EU main roms,
> http://tandy.wiki/Model_T_Y2K
>
> So it should be possible to build a translation table, assuming we had one
> from 100 to US m10, and I believe we have that, somewhere...
>
> Aha, there is one that crosses all 3 100 to m10-us to m10-eu!
> https://github.com/LivingM100SIG/Living_M100SIG/blob/main/
> M100SIG/Lib-12-NEC-OLIVETTI/M10ROM.DIF
>
>
> --
> bkw
>
> On 5/18/23 16:50, Ben Wiley Sittler wrote:
>
>> Is the German ROM different? I had thought the various European versions
>> used the same ROM just with different jumper settings
>>
>> On Thu, May 18, 2023, 13:48 John R. Hogerhuis > jho...@pobox.com>> wrote:
>>
>>
>>
>> On Thu, May 18, 2023 at 11:53 AM Brian K. White > > wrote:
>>
>> Has anyone ever heard of any teeny or ts-dos or anything that
>> would run
>> on a German Olivetti M10?
>>
>> A dlplus user is out of luck I think.
>> https://github.com/bkw777/dlplus/issues/7
>> 
>>
>> I have never seen anything, not just teeny but anything.
>>
>>
>> I don't know either. Are you asking about German specifically? No
>> how idea how much difference between M10 ROMs.
>>
>> If there's a M10 cross reference I expect TEENY would not be hard to
>> port.
>>
>> Ultimately users may be better off moving to a T102 based ported
>> ROM. Maybe with an M10 font to maintain the feel of the machine.
>>
>> -- John.
>>
>>
> --
> bkw
>
>

Re: [M100] Switchable clock doubler schematic

[Stephen Adolph]

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?



On Sun, May 14, 2023 at 3:34 PM Philip Avery  wrote:

> 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
> >
>
>

[M100] Switchable clock doubler schematic

[Stephen Adolph]

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] Any further info on TDock?

[Stephen Adolph]

System bus on T102 is hamstrung compared to M100.  T102 can only support IO
read write whereas m100 exposes both memory and io.
The bus runs at full speed.  Every cpu cycle on M100 could run on the
expansion bus.  For IO only as in the T102, your ability to read or write
is limited by the software design, but the peak rate could be as high as
about 800Kbytes per sec?  3 clock cycles needed to execute an OUT opcode.
So 1.2 nsec.



On Tuesday, May 9, 2023, mark audacity romberg 
wrote:

> What do you want it to do?
>
> MVT100 exists. https://bitchin100.com/wiki/index.php?title=VT100
>
>
> I'm aware of MVT, neat little project, but not really what I'm looking for.
>
> I am mainly interested in non-volatile storage and network connectivity,
> whether that's the host machine backing up the M100's files or the M100
> being presented with a modem emulator. TRS-Box type functionality would be
> ideal. A bigger display would be nice, but is somewhat secondary for me.
>
> I don't see a reason to mess with the cassette port, BCR port, or serial
> port when the computer has the system bus exposed...and for exactly this
> purpose. In fact, I'm a little surprised that nobody has built any projects
> (that I'm aware of) that use the system bus. Seems ripe for
> experimentation, since it gives direct access to the CPU.z
>
> Side question: what kind of bandwidth is the system bus capable of? I
> can't find any information on that specifically.
>
>
> *mark audacity rombergmark.romb...@gmail.com *
>

Re: [M100] Lack of info on DIY RAM upgrades

[Stephen Adolph]

Not much to say really. I decided it would be a fun challenge to carefully
measure out the M100 sockets and NEC sockets to see if I could have a
single card that spans all 3 (or 4 in the case of NEC) ram slots with a
single ram chip.
It works, and it saves a bit of money if you need a bunch of 8k rams.  Bit
of a pain to make though.  I have to pick apart pin headers to get the
pins, and then hand place 40 pins in a jig, and then wiggle the board into
place and solder.

I have enough M100's that have only 8k, and several NEC with no bank 2 RAM,
I decided to finish the project off,  and flood my machines with ram.
Since then I decided I would offer it if there was interest.
Never was intended to be DIY.
regards.
Steve

On Tue, Apr 25, 2023 at 9:45 PM Mike Stein  wrote:

> I didn't know there was a 24K RAM card for the M100; any details on that?
>
> m
>
>
> On Tue, Apr 25, 2023 at 9:17 PM Stephen Adolph 
> wrote:
>
>>
>> http://bitchin100.com/wiki/index.php?title=Ordering_Information
>>
>> Mark, those 2 items are things you can order from me.
>>
>> Steve
>>
>>
>> On Tuesday, April 25, 2023, mark audacity romberg 
>> wrote:
>>
>>> Say y’all, I don’t have a login on the Bitchin 100 Wiki to comment
>>> there, but both the 8k and 24k DIY RAM board articles have no actual
>>> actionable information—no schematics, no links, no PCB art, nothing but a
>>> photo of the 8k, and a photo of the prototype installed for the 24k.
>>>
>>> Needless to say…these are not useful. Could we either get the folks who
>>> created those projects to post the rest of the information/files, or remove
>>> the articles, since they essentially are stories, not projects?
>>>
>>> —m.a
>>
>>

Re: [M100] Lack of info on DIY RAM upgrades

[Stephen Adolph]

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

Mark, those 2 items are things you can order from me.

Steve


On Tuesday, April 25, 2023, mark audacity romberg 
wrote:

> Say y’all, I don’t have a login on the Bitchin 100 Wiki to comment there,
> but both the 8k and 24k DIY RAM board articles have no actual actionable
> information—no schematics, no links, no PCB art, nothing but a photo of the
> 8k, and a photo of the prototype installed for the 24k.
>
> Needless to say…these are not useful. Could we either get the folks who
> created those projects to post the rest of the information/files, or remove
> the articles, since they essentially are stories, not projects?
>
> —m.a

Re: [M100] Tpdd1 sector access example code?

[Stephen Adolph]

Actually I figured it out.  .Deb is an archive. I have the python code
now.  Cheers.

On Friday, April 21, 2023, Kurt McCullum  wrote:

> I'll send it your way when I get home tonight. It's in the Python code too
> so if you need it right away you can download that one. It's just the
> responses to read requests, but it will give you the general idea.
>
> Kurt
>
> On Fri, Apr 21, 2023, at 11:18 AM, Stephen Adolph wrote:
>
> Thanks for the offer Kurt.
> I'm specifically after TPDD1 stuff, so that might mean mcomm sardine code?
>
> I could also just start writing code to see what works.
>
> ..steve
>
> On Friday, April 21, 2023, Kurt McCullum  wrote:
>
>
> Steve,
>
> The Sardine code in mComm has code for responding to the TPDD1 sectors. I
> also have some old C# code for a TPDD client that I used to make copies of
> some disks. At the time I wrote it I only had a TPDD2 (now sold) so it
> probably isn't what you are looking for, but I could send it your way.
>
> Kurt
>
> On Fri, Apr 21, 2023, at 6:50 AM, Stephen Adolph wrote:
>
> Hi,
> Does anyone know of an example of tpdd1 sector access code?
> Thw software manual is ok but actual working code is better.
>
> Thanks
> Steve
>
>
>
>

Re: [M100] Tpdd1 sector access example code?

[Stephen Adolph]

I can't find a python source, only a python executable.  Is there a link to
the python source?  Thanks!

On Friday, April 21, 2023, Kurt McCullum  wrote:

> I'll send it your way when I get home tonight. It's in the Python code too
> so if you need it right away you can download that one. It's just the
> responses to read requests, but it will give you the general idea.
>
> Kurt
>
> On Fri, Apr 21, 2023, at 11:18 AM, Stephen Adolph wrote:
>
> Thanks for the offer Kurt.
> I'm specifically after TPDD1 stuff, so that might mean mcomm sardine code?
>
> I could also just start writing code to see what works.
>
> ..steve
>
> On Friday, April 21, 2023, Kurt McCullum  wrote:
>
>
> Steve,
>
> The Sardine code in mComm has code for responding to the TPDD1 sectors. I
> also have some old C# code for a TPDD client that I used to make copies of
> some disks. At the time I wrote it I only had a TPDD2 (now sold) so it
> probably isn't what you are looking for, but I could send it your way.
>
> Kurt
>
> On Fri, Apr 21, 2023, at 6:50 AM, Stephen Adolph wrote:
>
> Hi,
> Does anyone know of an example of tpdd1 sector access code?
> Thw software manual is ok but actual working code is better.
>
> Thanks
> Steve
>
>
>
>

Re: [M100] Tpdd1 sector access example code?

[Stephen Adolph]

Thanks for the reminder and info Brian, I had forgotten that you had done
this.

I can take a look, thanks.

Steve

On Friday, April 21, 2023, Brian K. White  wrote:

> On 4/21/23 09:50, Stephen Adolph wrote:
>
>> Hi,
>> Does anyone know of an example of tpdd1 sector access code?
>> Thw software manual is ok but actual working code is better.
>>
>> Thanks
>> Steve
>>
>
> The software manual actually lays it all out.
>
> pdd.sh does client-side sector access for both tpdd1 and 2
> https://github.com/bkw777/pdd.sh
>
> dlplus does server-side sector access for both tpdd1 and 2
> https://github.com/bkw777/dlplus
>
> The bash code in pdd.sh is probably hard to read, so I am willing to
> explain it in some other posts or off-list.
>
> Or better yet, write up stuff in the discussions or wiki feature on github.
> like
> https://github.com/bkw777/dlplus/wiki
> or
> https://github.com/bkw777/dlplus/discussions
> That way the documentation that gets written up is still there for others
> later.
>
> enabling debug to higher levels essentially prints the bytes that go over
> the wire so you could then figure out your own way to do the same thing.
> But some of it is timing dependant and some of it involves rules where just
> looking a the traffic doesn't necessarily show what makes some things valid
> vs invalid.
>
> The real drive is a strict and crude state machine with practically no
> give or self-recovery. Once you do almost anything unexpected or illegal,
> it generally just locks up and the only fix is to power-cycle the drive, so
> it means that writing a reliable client involves being super careful to
> never go outside the lines in the first place, since there's no sort of
> reset or retrain command you can send from the client in a lot of cases.
>
> I'll send a separate post with an example and explaination of the sequence
> of a transaction.
>
> --
> bkw
>
>

Re: [M100] Tpdd1 sector access example code?

[Stephen Adolph]

Thank you.  The python is probably good.  I'll take a look!

On Friday, April 21, 2023, Kurt McCullum  wrote:

> I'll send it your way when I get home tonight. It's in the Python code too
> so if you need it right away you can download that one. It's just the
> responses to read requests, but it will give you the general idea.
>
> Kurt
>
> On Fri, Apr 21, 2023, at 11:18 AM, Stephen Adolph wrote:
>
> Thanks for the offer Kurt.
> I'm specifically after TPDD1 stuff, so that might mean mcomm sardine code?
>
> I could also just start writing code to see what works.
>
> ..steve
>
> On Friday, April 21, 2023, Kurt McCullum  wrote:
>
>
> Steve,
>
> The Sardine code in mComm has code for responding to the TPDD1 sectors. I
> also have some old C# code for a TPDD client that I used to make copies of
> some disks. At the time I wrote it I only had a TPDD2 (now sold) so it
> probably isn't what you are looking for, but I could send it your way.
>
> Kurt
>
> On Fri, Apr 21, 2023, at 6:50 AM, Stephen Adolph wrote:
>
> Hi,
> Does anyone know of an example of tpdd1 sector access code?
> Thw software manual is ok but actual working code is better.
>
> Thanks
> Steve
>
>
>
>

Re: [M100] Tpdd1 sector access example code?

[Stephen Adolph]

Thanks for the offer Kurt.
I'm specifically after TPDD1 stuff, so that might mean mcomm sardine code?

I could also just start writing code to see what works.

..steve

On Friday, April 21, 2023, Kurt McCullum  wrote:

> Steve,
>
> The Sardine code in mComm has code for responding to the TPDD1 sectors. I
> also have some old C# code for a TPDD client that I used to make copies of
> some disks. At the time I wrote it I only had a TPDD2 (now sold) so it
> probably isn't what you are looking for, but I could send it your way.
>
> Kurt
>
> On Fri, Apr 21, 2023, at 6:50 AM, Stephen Adolph wrote:
>
> Hi,
> Does anyone know of an example of tpdd1 sector access code?
> Thw software manual is ok but actual working code is better.
>
> Thanks
> Steve
>
>
>

[M100] Tpdd1 sector access example code?

[Stephen Adolph]

Hi,
Does anyone know of an example of tpdd1 sector access code?
Thw software manual is ok but actual working code is better.

Thanks
Steve

Re: [M100] View-80 and escape codes

[Stephen Adolph]

I'll have to experiment again and see why I had an issue.  Might be the
mvt100 driver specifically.

On Wednesday, April 5, 2023, John R. Hogerhuis  wrote:

> On Wed, Apr 5, 2023 at 11:42 AM Stephen Adolph 
> wrote:
>
>> That won't work. You can try but basic filters them out.
>>
>>>
>>>>
> Printing escape codes in BASIC works for me.
> This code does an escape to clear the screen and uses an escape to
> position the cursor before printing each character
>
> 10 E$=CHR$(27)
> 15 PRINTE$;"E";
> 20 FOR Y=2TO5:FORX=2TO5:GOSUB1000:PRINTCHR$(31+Y*5+X);:NEXT X:NEXT Y
> 999 END
> 1000 'P@X,Y
> 1010 PRINTE$;"Y";CHR$(Y+31);CHR$(X+31);
> 1020 RETURN
>
> As far as I know other codes should work too.
>
> Maybe we're talking about different things?
>
> [image: image.png]
>
> -- John.
>
>
>>>>
>>>>

Re: [M100] View-80 and escape codes

[Stephen Adolph]

That won't work. You can try but basic filters them out.

On Wednesday, April 5, 2023, John R. Hogerhuis  wrote:

> Huh. How about just print chr$ escapes in BASIC?
>
> -- John.
>
> On Wed, Apr 5, 2023, 6:32 AM Wayne Lorentz  wrote:
>
>> I have my termcap file on my remote machine set to send certain escape
>> codes for clearing the screen and such when I'm logged in.
>>
>> It works fine in plain vanilla Telcom — Lynx, Nano, and other programs
>> display as expected.
>>
>> Switch to View-80, and it doesn't work.  No cursor movements.  No screen
>> clearing.  No delete-to-end-of-line.
>>
>> Enable View-80's Snoopy mode, and I can see that the escape codes are
>> coming in, as View-80 helpfully displays the escape codes as custom
>> combination characters like "Ec/K" and "Ec/n"  But View-80 just doesn't
>> handle them at all.
>>
>>
>> On Apr 4, 2023, at 3:04 PM, m100-requ...@lists.bitchin100.com wrote:
>>
>> Are you sure Wayne? How did you test that?
>>
>>
>>

Re: [M100] View-80 and escape codes

[Stephen Adolph]

Iirc M100 basic traps attempts to directly send escape codes.  Hard to
test.  For MVT100 testing I opened a serial port and printed to serial.
That worked.

On Tuesday, April 4, 2023, John R. Hogerhuis  wrote:

> Are you sure Wayne? How did you test that?
>
> I don't use View-80 but if it doesn't implement the vt52 style codes then
> nothing in the model t would work. For example, the label line. Does the
> label line work? Does print@ work?
>
> There is also one called ultrascreen.
>
> -- John.
>
> On Tue, Apr 4, 2023, 9:25 AM Wayne Lorentz  wrote:
>
>> I've done some testing, and examined the data with View-80's Snoopy mode,
>> and it turns out that View-80 doesn't handle escape codes.
>>
>> Anything that's not bog-standard ASCII gets thrown out.  No screen clear
>> codes, no cursor movement codes, etc…
>>
>> Does anyone know of a Model 100 terminal program that displays more than
>> 40 columns, and also handles standard M100 escape codes?
>
>

Re: [M100] Model 102 keyboard cable sourced!

[Stephen Adolph]

Yah that is great!  I need one.  On my next purchase list...

On Sunday, April 2, 2023, Gregory McGill  wrote:

> nice!
>
> On Sun, Apr 2, 2023 at 2:21 PM David Plass  wrote:
>
>> Like many others, the cable for my 102 keyboard has seen better days.
>> When I got the unit, a swath of keys didn't work, so I re-seated the
>> connector, also while trying to reverse the snow-plowing that had occurred
>> previously. I got it to work and it worked for a few months, but recently
>> it failed again. I tried re-seating it but then the plastic backing fell
>> off and the wires seemed even worse.
>>
>> After MUCH searching I found a (mostly) drop-in replacement: Mouser has
>> an 18-pin 1.25mm pitch FFC cable, "D-style" (a.k.a. "opposite")
>> orientation: https://www.mouser.com/ProductDetail/Molex/15168-0250?qs=
>> N2VrfF4LzQfZl7gQv3Ba6g%3D%3D=US=USD
>>
>> I installed the cable and it worked okay, but I found it was loose on
>> both sides, so I used a playing card as a shim and now all the keys work
>> again. Yay!
>>
>> Unfortunately I could only get it in the 229 mm length (9 inches) instead
>> of the stock 150 mm (6 inches) that comes on the M102. That's OK, since
>> it's the "ultra flexible" variety I was able to just sort of stuff it under
>> the keyboard.
>>
>> Hope this helps someone save their 102 too!
>> -David
>>
>

Re: [M100] Customizing main menu?

[Stephen Adolph]

There is a guy in the UK, Sarah Libman, who has published his modified M100
main rom to take out ADDRS and SCHED, and include an expanded Teeny.

The documented assembly is a good start for further changes, or use as is!

Steve

On Tuesday, March 21, 2023, mark audacity romberg 
wrote:

> Has anyone played with modifying the system ROM to remove/change menu
> entries or add other programs? ADDRSS and SCHEDL are totally useless to me,
> and I’d rather have HTERM than TELCOM since I’m never going to even see a
> functional RJ-11 jack again.
>
> Might be nice to have the launchers for TS-DOS/Ultimate ROM/whatever other
> Option ROMs ‘burned in’ to the default menu so they stay resident on a cold
> boot.
>
> —mark

Re: [M100] CloudT - select M100 ROM

[Stephen Adolph]

Nice  change!  Thanks.

On Monday, March 20, 2023, John R. Hogerhuis  wrote:

> Since it came up that PCSG Analyst Option ROM has a M100 dependency, I
> added a drop down to CloudT to allow selection of the M100 ROM as the main
> ROM, instead of the T102 ROM which is the default.
>
> Generally I recommend leaving it as the T102 unless you have a reason to
> switch. The T102 ROM has a few bugfixes and a slightly better character set.
>
> [image: image.png]
>
> -- John.
>

Re: [M100] PCSG Business Analyst FC ERROR in 1938

[Stephen Adolph]

There are a set of changes to the T102 ROM that make it, in small ways,
different from M100.

One of those changes must be getting used incorrectly.

Analyst appears to use the main ROM at
0x4994 (USING function)
just before it crashes out.
I can't really see the problem though.






On Sat, Mar 18, 2023 at 8:22 AM Justin Poirier  wrote:

> Interesting. I only have CloudT and T102 findings to report. It sounds
> like VirtualT emulates a M100, and I do have an M100, but the option ROM
> socket was *MANGLED* by its previous owner. Since I have a real ROM burned,
> I might try to fix the socket (or hardwire it in if it comes to it) and see
> how it performs on M100 hardware. Are the M100 and T102 fully
> ROM-compatible? As in they have the exact same libraries at the exact same
> memory locations, or are they different in some ways. I believe I remember
> some rumblings about how the ROM socket may have had a slightly different
> pin-out allowing for auto-start ROMs or something, but I'm not sure how far
> the other differences go. Maybe this really is an M100-only ROM? That would
> be a bummer.
>
> —Justin
>
> On Mar 18, 2023, at 12:45 AM, John R. Hogerhuis  wrote:
>
>
>
> On Fri, Mar 17, 2023 at 9:25 PM Stephen Adolph 
> wrote:
>
>> additionally, earlier tonight I DID get the same error message, using the
>> real ROM on real T102 hardware.
>>
>> AHAH!
>> Business Analyst ROM works on M100 only!
>>
>> Isn't that odd, wonder why.  But, this appears to be confirmed in
>> VirtualT as well as on real hardware.
>>
>> Steve
>>
>>
>>
> First theory would be some m100 ROM dependency on the opt-rom installation
> code which differs by model.
>
> -- John.
>
>
>

Re: [M100] PCSG Business Analyst FC ERROR in 1938

[Stephen Adolph]

additionally, earlier tonight I DID get the same error message, using the
real ROM on real T102 hardware.

AHAH!
Business Analyst ROM works on M100 only!

Isn't that odd, wonder why.  But, this appears to be confirmed in VirtualT
as well as on real hardware.

Steve



On Sat, Mar 18, 2023 at 12:14 AM Stephen Adolph 
wrote:

> this is really confusing.  I just re-captured the binary from the original
> option ROM, and it is identical as far as I can tell as the one at
> bitchin100.
> Furthermore, it works in my real hardware and VirtualT, with and without
> REX#.
>
> So, I am stumped.
>
> ..Steve
>
> On Mon, Mar 6, 2023 at 9:10 PM Justin Poirier 
> wrote:
>
>> I agree that CloudT is working just fine, and is vindicated by the fact
>> that Business Analyst blows up exactly the same way on real hardware. I
>> have had zero luck finding a manual for the software, so I can only guess
>> that the CALL I'm using is correct. I'm assuming it is since it loads to
>> the splash screen, but can't verify that for sure.
>>
>> I got the ROM from the REX# repository, but can't know if it's good for
>> sure. Anyone with a REX have it working?
>>
>> Does anyone have a manual or any pointers? This package interests me for
>> some unknown reason. Maybe just because it seems like so much of a mystery!
>>
>> --Justin
>>
>> On Sun, 2023-03-05 at 17:56 -0800, John R. Hogerhuis wrote:
>>
>>
>>
>> On Sun, Mar 5, 2023 at 4:47 PM Justin Poirier 
>> wrote:
>>
>> That's the line number, not some new quirk of the Y2K bug. ;-)
>>
>> I saw PCSG's Business Analyst as an option ROM in Cloud T and thought
>> I'd try it. CALL 63012, and it gives the splash screen while it loads,
>> shows some preliminary numbers on the screen, looking promising, and
>> then give an "FC Error in 1938."
>>
>> There is no program listing upon doing a LIST, so this is a pretty
>> typical machine code crash in my book.
>>
>> I thought I'd try it on real hardware, just to be sure, so I burned a
>> ROM and put it in my 102. It blows up the exact same way. I manually
>> did a full cold restart on it, and the result is the same. It does
>> leave it's mark in the menu so I can load it without the CALL, but it's
>> dead software unless there's some trick to making it load. Any ideas on
>> what I'm doing wrong?
>>
>> Thanks a lot!
>>
>> --Justin
>>
>>
>> It doesn't sound like you're doing anything wrong. Some ROMs have a
>> different install CALL but I doubt that's the issue.
>>
>> For my part, I've never really used this opt rom. I just dropped it into
>> CloudT since it is available. Might have checked to see it launch... which
>> it does, shows a banner, but if you hit enter you get the crash.
>>
>> I'd like to hear if anyone else uses it with whatever version of the Opt
>> ROM they have... maybe I have a corrupted file.
>>
>> -- John.
>>
>>

Re: [M100] PCSG Business Analyst FC ERROR in 1938

[Stephen Adolph]

this is really confusing.  I just re-captured the binary from the original
option ROM, and it is identical as far as I can tell as the one at
bitchin100.
Furthermore, it works in my real hardware and VirtualT, with and without
REX#.

So, I am stumped.

..Steve

On Mon, Mar 6, 2023 at 9:10 PM Justin Poirier  wrote:

> I agree that CloudT is working just fine, and is vindicated by the fact
> that Business Analyst blows up exactly the same way on real hardware. I
> have had zero luck finding a manual for the software, so I can only guess
> that the CALL I'm using is correct. I'm assuming it is since it loads to
> the splash screen, but can't verify that for sure.
>
> I got the ROM from the REX# repository, but can't know if it's good for
> sure. Anyone with a REX have it working?
>
> Does anyone have a manual or any pointers? This package interests me for
> some unknown reason. Maybe just because it seems like so much of a mystery!
>
> --Justin
>
> On Sun, 2023-03-05 at 17:56 -0800, John R. Hogerhuis wrote:
>
>
>
> On Sun, Mar 5, 2023 at 4:47 PM Justin Poirier 
> wrote:
>
> That's the line number, not some new quirk of the Y2K bug. ;-)
>
> I saw PCSG's Business Analyst as an option ROM in Cloud T and thought
> I'd try it. CALL 63012, and it gives the splash screen while it loads,
> shows some preliminary numbers on the screen, looking promising, and
> then give an "FC Error in 1938."
>
> There is no program listing upon doing a LIST, so this is a pretty
> typical machine code crash in my book.
>
> I thought I'd try it on real hardware, just to be sure, so I burned a
> ROM and put it in my 102. It blows up the exact same way. I manually
> did a full cold restart on it, and the result is the same. It does
> leave it's mark in the menu so I can load it without the CALL, but it's
> dead software unless there's some trick to making it load. Any ideas on
> what I'm doing wrong?
>
> Thanks a lot!
>
> --Justin
>
>
> It doesn't sound like you're doing anything wrong. Some ROMs have a
> different install CALL but I doubt that's the issue.
>
> For my part, I've never really used this opt rom. I just dropped it into
> CloudT since it is available. Might have checked to see it launch... which
> it does, shows a banner, but if you hit enter you get the crash.
>
> I'd like to hear if anyone else uses it with whatever version of the Opt
> ROM they have... maybe I have a corrupted file.
>
> -- John.
>
>

Re: [M100] Olivetti M10

[Stephen Adolph]

Hi Dan,
I don't know of a single rom for M10.

I think the best bet is actually to use the M100 ROM in thr M10.  That way
you get all M100 roms in the M10.

I have posted a modified M100 rom at the bitchin100 wiki that runs in a
Qwerty M10.

Steve

On Saturday, March 4, 2023, Dan Eicher  wrote:

> With the advent of the Dial-A-ROM (TM) -
>Was wondering if optional ROMs for the M100 are compatible - or are
> there pin and/or address location challenges?
>

[M100] unused M100 hooks table entries

[Stephen Adolph]

Looking tonight at the hooks table for the M100.
I see in my references that the last named hook in the hook table is

H.MLOAD  005E .EQU FB38

So, the hook H.MLOAD is offset by 5E bytes (5E = 94d, which means the 48th
hook in the table).  The jump location is at FB38.

However,
It appears that there are a range of unused additional hook table locations
possible.
>From FB3A to FB61.  that's 40 more bytes.
It seems like therefore we could "create" 20 more software hooks to  use.
OR!! there are 40 spare unused RAM bytes!

It seems actually plausible that there could be spares in the hooks table.

Any thoughts?

Steve

Re: [M100] - Text Sweet 2.3 Release

[Stephen Adolph]

hey works great!!!
thanks George. I'm using my (updated!) MVT100 Desktop terminal emulator to
play Tsweep!

steve

On Sun, Feb 26, 2023 at 6:02 PM grima...@gmail.com 
wrote:

> Hi Steve,
>
> I updated it again. I think I accidentally uploaded the wrong file
> initially.
>
> https://github.com/Grimakis/TextSweeper/releases/tag/2.5.1-beta.2
>
> https://imgur.com/a/JyLsAdX
>
> I’ve linked photos of how it renders on a real DVI. The above is how I
> have intended it to look.
>
> Let me know if you’re getting the same results with your program.
>
> Re: ASCII not loading cleanly. I’ve been experiencing issues when loading
> the ASCII as .BA in Virtual T. However, if I load it as .DO first and then
> use BASIC to tokenize it (either in Virtual T or real hardware), it works
> fine.
>
> Not sure if perhaps there is a bug in Virtual T or not.
>
> -George
>
> On Sun, Feb 26, 2023 at 5:08 PM Stephen Adolph 
> wrote:
>
>> thanks George.
>> I loaded it (.BA version, the .DO version won't load clean.
>>
>> Runs, but the controls are on top of the bottom half of the board.
>> but I can see it coming together!
>> cheers and thanks
>> Steve
>>
>> On Sun, Feb 26, 2023 at 4:41 PM grima...@gmail.com 
>> wrote:
>>
>>> Hi Steve,
>>>
>>> https://github.com/Grimakis/TextSweeper/releases/tag/2.5.1-beta.1
>>>
>>> I just put together a pre-release of 2.5.1, which I have tested against
>>> the original DVI hardware and it works now in both 40 col and 80 col mode.
>>> Feel free to check it out with your DVI Work Alike solution, and let me
>>> know what you think.
>>>
>>> Best,
>>> George
>>>
>>> On Sun, Feb 26, 2023 at 3:10 PM Stephen Adolph 
>>> wrote:
>>>
>>>> [image: ResizerImage574X765.jpg]
>>>> yes,
>>>> I have done a lot of work on making an external 80column video solution
>>>> that is a  "DVI work alike" accessible without actually having a DVI.
>>>>
>>>> First you need some driver software on the M100.
>>>> 1) VT100 driver - found here -->
>>>> https://bitchin100.com/wiki/index.php?title=VT100
>>>> or
>>>> 2) via REX#/REXCPM.
>>>>
>>>> To actually show video on an external monitor, the driver software
>>>> treats Screen1 as RS-232 and Screen2 as serial via a hardware hack to the
>>>> BCR port.   So, an external serial terminal can be used to show the video
>>>> info.
>>>>
>>>> Then you need a solution for serial terminal.
>>>> There are 2
>>>> 1)  MVT100 video adapter, based on the Geoff VT100 serial terminal
>>>> board --> https://bitchin100.com/wiki/index.php?title=VT100
>>>> or
>>>> 2) the MVT100 windows application found here -->
>>>> http://club100.org/memfiles/index.php?direction===Steve%20Adolph/MVT100%20for%20PC;
>>>>
>>>> Anyhow, I find external video quite nice to have but I never
>>>> appreciated the DVI much myself.  Had 2, sold them both.
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Feb 26, 2023 at 2:50 PM grima...@gmail.com 
>>>> wrote:
>>>>
>>>>> I see, when you say your DVI software do you mean the software that
>>>>> emulates the DVI itself?
>>>>>
>>>>> Modifying the print statements is definitely doable, and I can add
>>>>> that to my TODOs.
>>>>>
>>>>> However, as someone who uses the DVI, I personally do like the 40
>>>>> column mode. Being able to switch between 40 and 80 col on demand is 
>>>>> useful
>>>>> in my opinion. Very similar to how the Apple II works: 40col is just more
>>>>> legible in a lot of situations.
>>>>>
>>>>> -George
>>>>>
>>>>> On Sun, Feb 26, 2023 at 2:42 PM Stephen Adolph 
>>>>> wrote:
>>>>>
>>>>>> my stuff doesn't support 40 columns.  that's why I was asking!
>>>>>> To me, 40 column mode on the DVI seems silly, but that's just me.
>>>>>>
>>>>>> Anyways, if you don't want to adapt the print@ statements, I get it.
>>>>>> thanks anyways.
>>>>>>
>>>>>>
>>>>>> On Sun, Feb 26, 2023 at 2:40 PM grima...@gmail.com <
>>>>>> grima...@gmail.com> wrote:
>>>>>>
>>>>>>>

Re: [M100] - Text Sweet 2.3 Release

[Stephen Adolph]

Thank you!  Can't test until later tonight.

When I transfer the .do file to my m100 it has some strange line
terminators.

I use mComm to transfer.  I'll check it out more closely later.

Steve

On Sunday, February 26, 2023, grima...@gmail.com  wrote:

> Hi Steve,
>
> I updated it again. I think I accidentally uploaded the wrong file
> initially.
>
> https://github.com/Grimakis/TextSweeper/releases/tag/2.5.1-beta.2
>
> https://imgur.com/a/JyLsAdX
>
> I’ve linked photos of how it renders on a real DVI. The above is how I
> have intended it to look.
>
> Let me know if you’re getting the same results with your program.
>
> Re: ASCII not loading cleanly. I’ve been experiencing issues when loading
> the ASCII as .BA in Virtual T. However, if I load it as .DO first and then
> use BASIC to tokenize it (either in Virtual T or real hardware), it works
> fine.
>
> Not sure if perhaps there is a bug in Virtual T or not.
>
> -George
>
> On Sun, Feb 26, 2023 at 5:08 PM Stephen Adolph 
> wrote:
>
>> thanks George.
>> I loaded it (.BA version, the .DO version won't load clean.
>>
>> Runs, but the controls are on top of the bottom half of the board.
>> but I can see it coming together!
>> cheers and thanks
>> Steve
>>
>> On Sun, Feb 26, 2023 at 4:41 PM grima...@gmail.com 
>> wrote:
>>
>>> Hi Steve,
>>>
>>> https://github.com/Grimakis/TextSweeper/releases/tag/2.5.1-beta.1
>>>
>>> I just put together a pre-release of 2.5.1, which I have tested against
>>> the original DVI hardware and it works now in both 40 col and 80 col mode.
>>> Feel free to check it out with your DVI Work Alike solution, and let me
>>> know what you think.
>>>
>>> Best,
>>> George
>>>
>>> On Sun, Feb 26, 2023 at 3:10 PM Stephen Adolph 
>>> wrote:
>>>
>>>> [image: ResizerImage574X765.jpg]
>>>> yes,
>>>> I have done a lot of work on making an external 80column video solution
>>>> that is a  "DVI work alike" accessible without actually having a DVI.
>>>>
>>>> First you need some driver software on the M100.
>>>> 1) VT100 driver - found here --> https://bitchin100.com/wiki/
>>>> index.php?title=VT100
>>>> or
>>>> 2) via REX#/REXCPM.
>>>>
>>>> To actually show video on an external monitor, the driver software
>>>> treats Screen1 as RS-232 and Screen2 as serial via a hardware hack to the
>>>> BCR port.   So, an external serial terminal can be used to show the video
>>>> info.
>>>>
>>>> Then you need a solution for serial terminal.
>>>> There are 2
>>>> 1)  MVT100 video adapter, based on the Geoff VT100 serial terminal
>>>> board --> https://bitchin100.com/wiki/index.php?title=VT100
>>>> or
>>>> 2) the MVT100 windows application found here -->
>>>> http://club100.org/memfiles/index.php?direction==;
>>>> directory=Steve%20Adolph/MVT100%20for%20PC&
>>>>
>>>> Anyhow, I find external video quite nice to have but I never
>>>> appreciated the DVI much myself.  Had 2, sold them both.
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Feb 26, 2023 at 2:50 PM grima...@gmail.com 
>>>> wrote:
>>>>
>>>>> I see, when you say your DVI software do you mean the software that
>>>>> emulates the DVI itself?
>>>>>
>>>>> Modifying the print statements is definitely doable, and I can add
>>>>> that to my TODOs.
>>>>>
>>>>> However, as someone who uses the DVI, I personally do like the 40
>>>>> column mode. Being able to switch between 40 and 80 col on demand is 
>>>>> useful
>>>>> in my opinion. Very similar to how the Apple II works: 40col is just more
>>>>> legible in a lot of situations.
>>>>>
>>>>> -George
>>>>>
>>>>> On Sun, Feb 26, 2023 at 2:42 PM Stephen Adolph 
>>>>> wrote:
>>>>>
>>>>>> my stuff doesn't support 40 columns.  that's why I was asking!
>>>>>> To me, 40 column mode on the DVI seems silly, but that's just me.
>>>>>>
>>>>>> Anyways, if you don't want to adapt the print@ statements, I get it.
>>>>>> thanks anyways.
>>>>>>
>>>>>>
>>>>>> On Sun, Feb 26, 2023 at 2:40 PM grima...@gmail.com <

Re: [M100] - Text Sweet 2.3 Release

[Stephen Adolph]

thanks George.
I loaded it (.BA version, the .DO version won't load clean.

Runs, but the controls are on top of the bottom half of the board.
but I can see it coming together!
cheers and thanks
Steve

On Sun, Feb 26, 2023 at 4:41 PM grima...@gmail.com 
wrote:

> Hi Steve,
>
> https://github.com/Grimakis/TextSweeper/releases/tag/2.5.1-beta.1
>
> I just put together a pre-release of 2.5.1, which I have tested against
> the original DVI hardware and it works now in both 40 col and 80 col mode.
> Feel free to check it out with your DVI Work Alike solution, and let me
> know what you think.
>
> Best,
> George
>
> On Sun, Feb 26, 2023 at 3:10 PM Stephen Adolph 
> wrote:
>
>> [image: ResizerImage574X765.jpg]
>> yes,
>> I have done a lot of work on making an external 80column video solution
>> that is a  "DVI work alike" accessible without actually having a DVI.
>>
>> First you need some driver software on the M100.
>> 1) VT100 driver - found here -->
>> https://bitchin100.com/wiki/index.php?title=VT100
>> or
>> 2) via REX#/REXCPM.
>>
>> To actually show video on an external monitor, the driver software treats
>> Screen1 as RS-232 and Screen2 as serial via a hardware hack to the BCR
>> port.   So, an external serial terminal can be used to show the video info.
>>
>> Then you need a solution for serial terminal.
>> There are 2
>> 1)  MVT100 video adapter, based on the Geoff VT100 serial terminal board
>> --> https://bitchin100.com/wiki/index.php?title=VT100
>> or
>> 2) the MVT100 windows application found here -->
>> http://club100.org/memfiles/index.php?direction===Steve%20Adolph/MVT100%20for%20PC;
>>
>> Anyhow, I find external video quite nice to have but I never appreciated
>> the DVI much myself.  Had 2, sold them both.
>>
>>
>>
>>
>> On Sun, Feb 26, 2023 at 2:50 PM grima...@gmail.com 
>> wrote:
>>
>>> I see, when you say your DVI software do you mean the software that
>>> emulates the DVI itself?
>>>
>>> Modifying the print statements is definitely doable, and I can add that
>>> to my TODOs.
>>>
>>> However, as someone who uses the DVI, I personally do like the 40 column
>>> mode. Being able to switch between 40 and 80 col on demand is useful in my
>>> opinion. Very similar to how the Apple II works: 40col is just more legible
>>> in a lot of situations.
>>>
>>> -George
>>>
>>> On Sun, Feb 26, 2023 at 2:42 PM Stephen Adolph 
>>> wrote:
>>>
>>>> my stuff doesn't support 40 columns.  that's why I was asking!
>>>> To me, 40 column mode on the DVI seems silly, but that's just me.
>>>>
>>>> Anyways, if you don't want to adapt the print@ statements, I get it.
>>>> thanks anyways.
>>>>
>>>>
>>>> On Sun, Feb 26, 2023 at 2:40 PM grima...@gmail.com 
>>>> wrote:
>>>>
>>>>> I think the way I would prefer to handle it would be to check the
>>>>> initial setting of 40/80 when the program starts, switch the screen to 40,
>>>>> and then switch back on exit.
>>>>>
>>>>> Do you know is there a way to switch to 40 columns mode without
>>>>> calling WIDTH? I assume if I use any keywords exclusive to Disk Basic it
>>>>> will break compatibility with regular Basic.
>>>>>
>>>>> Best,
>>>>> George
>>>>>
>>>>> On Sun, Feb 26, 2023 at 2:17 PM Stephen Adolph 
>>>>> wrote:
>>>>>
>>>>>> George,
>>>>>> I think it would be fine to use only 40 columns.
>>>>>> just make it tolerate 80 cols wide.
>>>>>> (all of my DVI software assumes 80 columns).
>>>>>> thoughts?
>>>>>> Steve
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Feb 26, 2023 at 2:09 PM grima...@gmail.com <
>>>>>> grima...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Steve,
>>>>>>>
>>>>>>> As of right now, it’s supporting only 40col mode.
>>>>>>>
>>>>>>> Currently, the way I am taking advantage of the DVI and T200 larger
>>>>>>> displays are to have the Controls/Help screen displayed below the game
>>>>>>> screen (preventing the need to switch between the two)
>>>>>>>
>>>>>>&

Re: [M100] - Text Sweet 2.3 Release

[Stephen Adolph]

[image: ResizerImage574X765.jpg]
yes,
I have done a lot of work on making an external 80column video solution
that is a  "DVI work alike" accessible without actually having a DVI.

First you need some driver software on the M100.
1) VT100 driver - found here -->
https://bitchin100.com/wiki/index.php?title=VT100
or
2) via REX#/REXCPM.

To actually show video on an external monitor, the driver software treats
Screen1 as RS-232 and Screen2 as serial via a hardware hack to the BCR
port.   So, an external serial terminal can be used to show the video info.

Then you need a solution for serial terminal.
There are 2
1)  MVT100 video adapter, based on the Geoff VT100 serial terminal board
--> https://bitchin100.com/wiki/index.php?title=VT100
or
2) the MVT100 windows application found here -->
http://club100.org/memfiles/index.php?direction===Steve%20Adolph/MVT100%20for%20PC;

Anyhow, I find external video quite nice to have but I never appreciated
the DVI much myself.  Had 2, sold them both.




On Sun, Feb 26, 2023 at 2:50 PM grima...@gmail.com 
wrote:

> I see, when you say your DVI software do you mean the software that
> emulates the DVI itself?
>
> Modifying the print statements is definitely doable, and I can add that to
> my TODOs.
>
> However, as someone who uses the DVI, I personally do like the 40 column
> mode. Being able to switch between 40 and 80 col on demand is useful in my
> opinion. Very similar to how the Apple II works: 40col is just more legible
> in a lot of situations.
>
> -George
>
> On Sun, Feb 26, 2023 at 2:42 PM Stephen Adolph 
> wrote:
>
>> my stuff doesn't support 40 columns.  that's why I was asking!
>> To me, 40 column mode on the DVI seems silly, but that's just me.
>>
>> Anyways, if you don't want to adapt the print@ statements, I get it.
>> thanks anyways.
>>
>>
>> On Sun, Feb 26, 2023 at 2:40 PM grima...@gmail.com 
>> wrote:
>>
>>> I think the way I would prefer to handle it would be to check the
>>> initial setting of 40/80 when the program starts, switch the screen to 40,
>>> and then switch back on exit.
>>>
>>> Do you know is there a way to switch to 40 columns mode without calling
>>> WIDTH? I assume if I use any keywords exclusive to Disk Basic it will break
>>> compatibility with regular Basic.
>>>
>>> Best,
>>> George
>>>
>>> On Sun, Feb 26, 2023 at 2:17 PM Stephen Adolph 
>>> wrote:
>>>
>>>> George,
>>>> I think it would be fine to use only 40 columns.
>>>> just make it tolerate 80 cols wide.
>>>> (all of my DVI software assumes 80 columns).
>>>> thoughts?
>>>> Steve
>>>>
>>>>
>>>>
>>>> On Sun, Feb 26, 2023 at 2:09 PM grima...@gmail.com 
>>>> wrote:
>>>>
>>>>> Hi Steve,
>>>>>
>>>>> As of right now, it’s supporting only 40col mode.
>>>>>
>>>>> Currently, the way I am taking advantage of the DVI and T200 larger
>>>>> displays are to have the Controls/Help screen displayed below the game
>>>>> screen (preventing the need to switch between the two)
>>>>>
>>>>> As others have mentioned, I could allow for an actual larger
>>>>> minefield. However, at this time, I don’t have plans for that.
>>>>>
>>>>> My primary goals in the short terms are to improve the base game
>>>>> experience, which in my mind is oriented around the M100, as well as to
>>>>> ensure that same experience is achieved on the T200 and DVI.
>>>>>
>>>>> If I were to support 80-col mode at this time, I would basically just
>>>>> end up leaving the right hand 40 columns empty.
>>>>>
>>>>> The next few things I’m working on:
>>>>> 1. Reduce size of TSWEEP.BA in memory
>>>>> 2. Compact some of the array vars I’m using to require less RAM.
>>>>> 3. Add a few different pre-canned difficulty level aside from the
>>>>> Standard/Custom I have today.
>>>>> 4. Increase performance of the screen redrawing routine.
>>>>> 5. Increase overall performance of the DFS algorithm when revealing
>>>>> mines.
>>>>>
>>>>> Best,
>>>>> George
>>>>>
>>>>> On Sun, Feb 26, 2023 at 1:56 PM Stephen Adolph 
>>>>> wrote:
>>>>>
>>>>>> George,
>>>>>> for DVI use, is that intended for 40 columns?
>>>>>> Is there

Re: [M100] - Text Sweet 2.3 Release

[Stephen Adolph]

Textsweeper was going to be my fun to use test case to make sure my DVI
emulator code for windows was working well.

Since the only drivers that send video data over serial are my own 2
programs (1 = VT100 driver for M100 or 2 = REX#/REXCPM) and since those
adaptations of the Disk Video Interface driver code ignores the 40 column
mode, there is no matching need on the "terminal" end of the serial link to
support 40 column mode either.

On Sun, Feb 26, 2023 at 2:42 PM Stephen Adolph  wrote:

> my stuff doesn't support 40 columns.  that's why I was asking!
> To me, 40 column mode on the DVI seems silly, but that's just me.
>
> Anyways, if you don't want to adapt the print@ statements, I get it.
> thanks anyways.
>
>
> On Sun, Feb 26, 2023 at 2:40 PM grima...@gmail.com 
> wrote:
>
>> I think the way I would prefer to handle it would be to check the initial
>> setting of 40/80 when the program starts, switch the screen to 40, and then
>> switch back on exit.
>>
>> Do you know is there a way to switch to 40 columns mode without calling
>> WIDTH? I assume if I use any keywords exclusive to Disk Basic it will break
>> compatibility with regular Basic.
>>
>> Best,
>> George
>>
>> On Sun, Feb 26, 2023 at 2:17 PM Stephen Adolph 
>> wrote:
>>
>>> George,
>>> I think it would be fine to use only 40 columns.
>>> just make it tolerate 80 cols wide.
>>> (all of my DVI software assumes 80 columns).
>>> thoughts?
>>> Steve
>>>
>>>
>>>
>>> On Sun, Feb 26, 2023 at 2:09 PM grima...@gmail.com 
>>> wrote:
>>>
>>>> Hi Steve,
>>>>
>>>> As of right now, it’s supporting only 40col mode.
>>>>
>>>> Currently, the way I am taking advantage of the DVI and T200 larger
>>>> displays are to have the Controls/Help screen displayed below the game
>>>> screen (preventing the need to switch between the two)
>>>>
>>>> As others have mentioned, I could allow for an actual larger minefield.
>>>> However, at this time, I don’t have plans for that.
>>>>
>>>> My primary goals in the short terms are to improve the base game
>>>> experience, which in my mind is oriented around the M100, as well as to
>>>> ensure that same experience is achieved on the T200 and DVI.
>>>>
>>>> If I were to support 80-col mode at this time, I would basically just
>>>> end up leaving the right hand 40 columns empty.
>>>>
>>>> The next few things I’m working on:
>>>> 1. Reduce size of TSWEEP.BA in memory
>>>> 2. Compact some of the array vars I’m using to require less RAM.
>>>> 3. Add a few different pre-canned difficulty level aside from the
>>>> Standard/Custom I have today.
>>>> 4. Increase performance of the screen redrawing routine.
>>>> 5. Increase overall performance of the DFS algorithm when revealing
>>>> mines.
>>>>
>>>> Best,
>>>> George
>>>>
>>>> On Sun, Feb 26, 2023 at 1:56 PM Stephen Adolph 
>>>> wrote:
>>>>
>>>>> George,
>>>>> for DVI use, is that intended for 40 columns?
>>>>> Is there a way you could put in a switch to enable 80 column mode?
>>>>>
>>>>> thx
>>>>> steve
>>>>>
>>>>> On Sat, Feb 11, 2023 at 8:15 PM grima...@gmail.com 
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> As previously mentioned, I have been working on Text Sweeper again.
>>>>>> I've made a bunch of changed behind the scenes, but the things that will 
>>>>>> be
>>>>>> noticeable to you:
>>>>>>
>>>>>>
>>>>>>- Slight graphical changes.
>>>>>>- Better mine generation for denser minefield.
>>>>>>- Controls can be seen by pressing H
>>>>>>- WASD is supported as an alternative to the arrow keys.
>>>>>>- You cannot accidentally click a flagged cell.
>>>>>>- If you click a cell with a Number. If the flags surrounding
>>>>>>that cell equal the number, it will open the non flagged cells (Be 
>>>>>> careful
>>>>>>:D )
>>>>>>- If you accidentally press LABEL, the screen will fix itself
>>>>>>
>>>>>> Everything is on github.
>>>>>> https://github.com/Grimakis/TextSweeper
>>>>>>
>>>>>> There are probably still a ton of bugs I didn't find, so let me know
>>>>>> if you find any.
>>>>>>
>>>>>> Enjoy,
>>>>>> George
>>>>>>
>>>>>

Re: [M100] - Text Sweet 2.3 Release

[Stephen Adolph]

my stuff doesn't support 40 columns.  that's why I was asking!
To me, 40 column mode on the DVI seems silly, but that's just me.

Anyways, if you don't want to adapt the print@ statements, I get it.
thanks anyways.


On Sun, Feb 26, 2023 at 2:40 PM grima...@gmail.com 
wrote:

> I think the way I would prefer to handle it would be to check the initial
> setting of 40/80 when the program starts, switch the screen to 40, and then
> switch back on exit.
>
> Do you know is there a way to switch to 40 columns mode without calling
> WIDTH? I assume if I use any keywords exclusive to Disk Basic it will break
> compatibility with regular Basic.
>
> Best,
> George
>
> On Sun, Feb 26, 2023 at 2:17 PM Stephen Adolph 
> wrote:
>
>> George,
>> I think it would be fine to use only 40 columns.
>> just make it tolerate 80 cols wide.
>> (all of my DVI software assumes 80 columns).
>> thoughts?
>> Steve
>>
>>
>>
>> On Sun, Feb 26, 2023 at 2:09 PM grima...@gmail.com 
>> wrote:
>>
>>> Hi Steve,
>>>
>>> As of right now, it’s supporting only 40col mode.
>>>
>>> Currently, the way I am taking advantage of the DVI and T200 larger
>>> displays are to have the Controls/Help screen displayed below the game
>>> screen (preventing the need to switch between the two)
>>>
>>> As others have mentioned, I could allow for an actual larger minefield.
>>> However, at this time, I don’t have plans for that.
>>>
>>> My primary goals in the short terms are to improve the base game
>>> experience, which in my mind is oriented around the M100, as well as to
>>> ensure that same experience is achieved on the T200 and DVI.
>>>
>>> If I were to support 80-col mode at this time, I would basically just
>>> end up leaving the right hand 40 columns empty.
>>>
>>> The next few things I’m working on:
>>> 1. Reduce size of TSWEEP.BA in memory
>>> 2. Compact some of the array vars I’m using to require less RAM.
>>> 3. Add a few different pre-canned difficulty level aside from the
>>> Standard/Custom I have today.
>>> 4. Increase performance of the screen redrawing routine.
>>> 5. Increase overall performance of the DFS algorithm when revealing
>>> mines.
>>>
>>> Best,
>>> George
>>>
>>> On Sun, Feb 26, 2023 at 1:56 PM Stephen Adolph 
>>> wrote:
>>>
>>>> George,
>>>> for DVI use, is that intended for 40 columns?
>>>> Is there a way you could put in a switch to enable 80 column mode?
>>>>
>>>> thx
>>>> steve
>>>>
>>>> On Sat, Feb 11, 2023 at 8:15 PM grima...@gmail.com 
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> As previously mentioned, I have been working on Text Sweeper again.
>>>>> I've made a bunch of changed behind the scenes, but the things that will 
>>>>> be
>>>>> noticeable to you:
>>>>>
>>>>>
>>>>>- Slight graphical changes.
>>>>>- Better mine generation for denser minefield.
>>>>>- Controls can be seen by pressing H
>>>>>- WASD is supported as an alternative to the arrow keys.
>>>>>- You cannot accidentally click a flagged cell.
>>>>>- If you click a cell with a Number. If the flags surrounding that
>>>>>cell equal the number, it will open the non flagged cells (Be careful 
>>>>> :D )
>>>>>- If you accidentally press LABEL, the screen will fix itself
>>>>>
>>>>> Everything is on github.
>>>>> https://github.com/Grimakis/TextSweeper
>>>>>
>>>>> There are probably still a ton of bugs I didn't find, so let me know
>>>>> if you find any.
>>>>>
>>>>> Enjoy,
>>>>> George
>>>>>
>>>>

Re: [M100] - Text Sweet 2.3 Release

[Stephen Adolph]

George,
I think it would be fine to use only 40 columns.
just make it tolerate 80 cols wide.
(all of my DVI software assumes 80 columns).
thoughts?
Steve



On Sun, Feb 26, 2023 at 2:09 PM grima...@gmail.com 
wrote:

> Hi Steve,
>
> As of right now, it’s supporting only 40col mode.
>
> Currently, the way I am taking advantage of the DVI and T200 larger
> displays are to have the Controls/Help screen displayed below the game
> screen (preventing the need to switch between the two)
>
> As others have mentioned, I could allow for an actual larger minefield.
> However, at this time, I don’t have plans for that.
>
> My primary goals in the short terms are to improve the base game
> experience, which in my mind is oriented around the M100, as well as to
> ensure that same experience is achieved on the T200 and DVI.
>
> If I were to support 80-col mode at this time, I would basically just end
> up leaving the right hand 40 columns empty.
>
> The next few things I’m working on:
> 1. Reduce size of TSWEEP.BA in memory
> 2. Compact some of the array vars I’m using to require less RAM.
> 3. Add a few different pre-canned difficulty level aside from the
> Standard/Custom I have today.
> 4. Increase performance of the screen redrawing routine.
> 5. Increase overall performance of the DFS algorithm when revealing mines.
>
> Best,
> George
>
> On Sun, Feb 26, 2023 at 1:56 PM Stephen Adolph 
> wrote:
>
>> George,
>> for DVI use, is that intended for 40 columns?
>> Is there a way you could put in a switch to enable 80 column mode?
>>
>> thx
>> steve
>>
>> On Sat, Feb 11, 2023 at 8:15 PM grima...@gmail.com 
>> wrote:
>>
>>> Hi all,
>>>
>>> As previously mentioned, I have been working on Text Sweeper again. I've
>>> made a bunch of changed behind the scenes, but the things that will be
>>> noticeable to you:
>>>
>>>
>>>- Slight graphical changes.
>>>- Better mine generation for denser minefield.
>>>- Controls can be seen by pressing H
>>>- WASD is supported as an alternative to the arrow keys.
>>>- You cannot accidentally click a flagged cell.
>>>- If you click a cell with a Number. If the flags surrounding that
>>>cell equal the number, it will open the non flagged cells (Be careful :D 
>>> )
>>>- If you accidentally press LABEL, the screen will fix itself
>>>
>>> Everything is on github.
>>> https://github.com/Grimakis/TextSweeper
>>>
>>> There are probably still a ton of bugs I didn't find, so let me know if
>>> you find any.
>>>
>>> Enjoy,
>>> George
>>>
>>

Re: [M100] - Text Sweet 2.3 Release

[Stephen Adolph]

George,
for DVI use, is that intended for 40 columns?
Is there a way you could put in a switch to enable 80 column mode?

thx
steve

On Sat, Feb 11, 2023 at 8:15 PM grima...@gmail.com 
wrote:

> Hi all,
>
> As previously mentioned, I have been working on Text Sweeper again. I've
> made a bunch of changed behind the scenes, but the things that will be
> noticeable to you:
>
>
>- Slight graphical changes.
>- Better mine generation for denser minefield.
>- Controls can be seen by pressing H
>- WASD is supported as an alternative to the arrow keys.
>- You cannot accidentally click a flagged cell.
>- If you click a cell with a Number. If the flags surrounding that
>cell equal the number, it will open the non flagged cells (Be careful :D )
>- If you accidentally press LABEL, the screen will fix itself
>
> Everything is on github.
> https://github.com/Grimakis/TextSweeper
>
> There are probably still a ton of bugs I didn't find, so let me know if
> you find any.
>
> Enjoy,
> George
>