[M100] zbug on archive.org
hi all! forgive me for not replying to the relevant thread as i just joined the mailing list a few days ago. i recently spent a ton of time trying to track down an archived version of Radio Shack's Assembler/Debugger (23-3823). i got lucky that it was being discussed here on the mailing list right when i joined, and i was able to get a copy from the link joshua provided. i was wondering if it would be okay with joshua if i (or someone else) uploaded the zbug manual and binary to archive.org so it is easier for others to find. because it's known as zbug to many people, that doesn't make it easy to track it down with only the original title. an archive named "Radio Shack Assembler/Debugger - 23-3823 (ZBUG)" would help a lot of people find what they are looking for. i'm sure it's fine, but i figured i'd ask first since it's on joshua's site and i don't really want to upload it without permission. -runrin On October 21, 2022 1:03:40 PM PDT, m100-requ...@lists.bitchin100.com wrote: >Send M100 mailing list submissions to > m100@lists.bitchin100.com > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.bitchin100.com/listinfo.cgi/m100-bitchin100.com >or, via email, send a message with subject or body 'help' to > m100-requ...@lists.bitchin100.com > >You can reach the person managing the list at > m100-ow...@lists.bitchin100.com > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of M100 digest..." > > >Today's Topics: > > 1. Re: Planning out some weekend projects. (ZBUG) (Peter Noeth) > 2. Re: zbug (Will Senn) > 3. Re: zbug (John R. Hogerhuis) > 4. Re: zbug (Will Senn) > > >-- > >Message: 1 >Date: Thu, 20 Oct 2022 15:57:02 -0700 >From: Peter Noeth >To: Model 100 Discussion >Subject: Re: [M100] Planning out some weekend projects. (ZBUG) >Message-ID: > >Content-Type: text/plain; charset="utf-8" > >Joshua, > > Thanks for the link, I will check it out. But yes, I also want the >physical package for the full retro experience > > >> If you're just hoping to use the software I have the Tandy >> editor/assembler debugger in my bucket[1], along with the manual. I >> believe it has been labeled variously "ZBG" or "EDTASM" (as other Tandy >> assemblers) as well. The underlying assembler and debugger are the >> Microsoft package, I believe. >> > > > >Randy, > > I know you have one, as I saw it at Tandy Assembly in 2019 when I was >sharing your display table. I didn't know it before I arrived, but we were >both in competition on that eBay auction. Haven't seen another one since. > >I have the physical package with manual, cassette and hard cover/holder. >> Didn't know it was rare. I don't want to give it up though. :). Sounds >> like it has been archived. >> > > > >Regards, > >Peter >-- next part -- >An HTML attachment was scrubbed... >URL: ><http://lists.bitchin100.com/private.cgi/m100-bitchin100.com/attachments/20221020/a56e39aa/attachment-0001.htm> > >-- > >Message: 2 >Date: Thu, 20 Oct 2022 19:11:56 -0500 >From: Will Senn >To: m100@lists.bitchin100.com >Subject: Re: [M100] zbug >Message-ID: <7c20fd8d-0005-4f86-d21d-e41b64c05...@gmail.com> >Content-Type: text/plain; charset="utf-8"; Format="flowed" > >It was definitely an issue with my failure to clear memory. By way of >confirmation, I did the following: > >I cold started the M100 and used DL to get TEENY on the M100. I then >used TEENY to transfer ZBG.BA and ZBG.CO onto the M100. I also >transferred the test prog S.DO from the Assembler/Debugger Manual: > > ?? ?ORG??? 0CC00H >HOME:??? CALL??? 422DH >SCREEN:??? MVI??? A,0FFH > ?? ?CALL??? 4B44H >ROW:??? LDA??? 0F639H > ?? ?CPI??? 8H > ?? ?JNZ??? SCREEN >COL:??? LDA??? 0F63AH > ?? ?CPI??? 28H > ?? ?JNZ??? SCREEN >WAIT:??? CALL??? 12CBH >EXIT:??? CALL??? 5797H > ?? ?END??? HOME > >Then I entered basic and typed: > >RUN"ZBG" > >ZBG.BA clears memory sufficiently to run ZBG and runs it... > >at the # prompt, I typed: > >ASM S.DO S.CO /WE > >and watched it do it's magic with no errors. Then I ran the S.CO file >from the Menu and marveled at the speed with which it filled the screen >with pixels :). > >Yay! It's just a bunch of calls to ROM functions, still, it's assembly >language and it works! > >Wow, is it a me
[M100] machine language monitor
hi all! i was wondering if anyone had recommendations for a machine language monitor similar to supermon on commodore 64. all i'm really looking for is the ability to view memory in hex, disassemble memory, and assemble directly into ram. i know there are full assemblers/debuggers, but i'm just looking for something super simple to poke around, experiment, and familiarize myself with the system. maybe even a type-in would be fine. (supermon was actually available as a 6-page type-in of nothing but data statements in a few of jim butterfield's books. yikes!) i grep'd through the archives for the past few years and didn't see anyone suggesting any in particular. unfortunately the search feature isn't working, so i couldn't do a comprehensive search. --- also, i uploaded zbug to archive.org. you can find it here: https://archive.org/details/trs-80-model-100-zbug-assembler-debugger if anyone has any suggestions for changes to the description, or additional files to add, i'd be happy to hear them. otherwise this may be a useful location to send folks looking for zbug in the future. thanks, runrin
Re: [M100] zbug on archive.org
you got me, you are an absolute hero. thanks so much. the pdf scan is much clearer and the .WAV will be easier for most people to get onto their m100s. thank's so much. the archive can be found here: https://archive.org/details/trs-80-model-100-zbug-assembler-debugger
[M100] disk video interface manual
hi all! i was poking around for dvi information and i saw a twitter user (@yesterbits) had uploaded some very high quality scans of their copy of the disk/video interface manual. i hadn't seen it anywhere online so i figured i'd throw it up on archive.org. not sure if anyone was looking for it, but here it is! https://archive.org/details/trs-80-model-100-disk-video-interface runrin
Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated
this seemed fun so i gave it a quick try. here's what i came up with. it's a shame you can't do bitshift operations because i suspect ``((V AND 240) >> 4)'' would be faster than using integer division. i'm a total neophyte when it comes to basic so i don't think this code is actually very fast. at least it's faster than the screen scrolls :P. in both examples i'm just peeking 0-59 since it's what fits on the screen nicely. that's also the reason for the " ". i like this version because it makes the print statement easy to read, it takes a lot more memory to store each character as it's own string though. 10 DATA "0","1","2","3","4","5","6","7","8","9","A","B","C","D","E","F" 20 DIM H$(15) 30 FOR I = 0 TO 15 40 READ H$(I) 50 NEXT 60 FOR I = 0 to 59 70 V = PEEK(I) 80 PRINT H$(V \ 16); H$(V AND 15); " "; 90 NEXT --- i made another version that uses string pointers because i felt bad using 16 strings. the PEEKS seem to be pretty expensive though, so i think it's actually slower than the previous version, but the code is a bit clearer. using MID$ is probably faster, but i mostly just did this for fun. this is more along the lines of how i would do something like this in C, which is the language i'm most familiar with. string pointers are weird in basic. the pointer returned by VARPTR(S$) points to the following: ptr + 0 = string length ptr + 1 = low byte of pointer to string ptr + 2 = high byte of pointer to string i had to look in the basic language lab (pp. 182) to find that information. it's not even listed on https://help.ayra.ch/trs80-reference . i think i would have preferred if it just returned the string pointer with null terminator lol. not sure why they did it this way. anyway, here's the code: 10 H$ = "0123456789ABCDEF" 20 P = VARPTR(H$) 30 SP = PEEK(P + 1) + PEEK(P + 2) * 256 40 FOR I = 0 TO 59 50 V = PEEK(I) 60 PRINT CHR$(PEEK(SP + (V \ 16))); CHR$(PEEK(SP + (V AND 15))); " "; 70 NEXT i know those extra spaces make my code slower, i'm just formatting it that way here so its actually legible. -runrin
[M100] FlexROM with REX#
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] FlexROM with REX#
FlexROM is just an adapter. It has two headers that you can connect to jumper wires and route them to the option rom compartment. To write a new rom to the system, you don't have to open the whole system, you just pop open the option rom compartment, hook the jumpers to the REX and then somehow write to the system rom. It's pretty confusing, but seems like a neat feature. There's more info here: http://tandy.wiki/FlexROM_100 Like you suggested, I'll probably just use that board as an adapter and test the rom in Virtual T. On Sun, Nov 12, 2023 at 06:16:02PM -0500, Stephen Adolph wrote: >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] FlexROM with REX#
Thanks for the info Brian, I really appreciate it. My plan is just to pop the ROM out when I need to reprogram it. I'm actually more comfortable unscrewing the back from the system than popping out the option ROM cover anyway, since the brass inserts are probably more robust that the tight plastic snap on the back panel. It freaks me out every time I pop that thing open :P A few Qs: 1. It seems like pin 27 (/CS) on the system ROM is normally pulled low by a CPU read. /CS on the EEPROM should be fine if I just jumper /CS_IC to /CS_BUS and skip the R2 pullup, right? I'll obviously still use the R1 pullup for /WE on the EEPROM. I was considering using a DIP switch as a jumper for /WE to ALE instead of a jumper if it fits in the case. That way I don't have to dig around for a jumper every time I want to program the EEPROM. 2. More of a technical question about the m100 architecture: I'm curious if you know how ALE is normally being used by the CPU/system ROM? It looks like it's being used by M1 and M25 as well. I haven't encountered an address latch before, coming from mostly 6502 and Z80, and I'm interested to understand its purpose. Thanks again! On Sun, Nov 12, 2023 at 10:05:44PM -0500, Brian K. White wrote: > REX# does not provide any software main rom feature, only REX Classic does. > > You can use a FlexROM as just an ordinary re-writable rom to replace the > stock one, but you would need to open up the machine to re-write the eeprom > (or flash, there is also a flash version). You just install a jumper on the > /CS pins which has the effect of just connecting the /cs pin from the bus > directly to the /cs pin on the eeprom like normal. > > To get a software main rom, you need a REX Classic. > > You write a normal main rom to the chip and install it like normal, but you > connect two wires to the /CS pins instead of a jumper. Run the two wires out > to the option rom compartment, just fish them both through one of the little > holes where the compartment door tabs go. Keep track of which wire is the > /CS_OUT one. Label it REX TP1 on the end in the compartment. That is the one > that connects to the bus, and that is the one that needs to be connected to > the TP1 pin on the REX, but don't connect it initially. Leave the other wire > disconnected. Don't put it on the TP2 pin. > > Close up the machine. You don't need to go inside again. > > Initially, connect the two wires to each other in the option rom > compartment. IE with a short male-male dupont wire, or just any plain solid > wire that has a thick enough guage to stick in the female dupont wire ends. > This causes the machine to boot from the main rom on the flexrom inside the > machine. > > Boot the machine and activate the REX by the usual CALL 63012 > > Find the y2k T102 main rom image from the flexrom wiki page, and like > described there, make 2 copies of the Y2K fixed T102 main rom image, and hex > edit them to change the text displayed in the copyright banner in BASIC, > just so that later you have a way to see which rom you are actually running. > > In REXMGR, hit tab until you get to the SYS screen, and load the priimary > and secondary main rom images via TPDD the same as loading option rom images > or ram backup images. > > Now shut the machine off and connect the /CS_OUT wire to the REX TP1. > Leave the other wire disconnected. Don't put it on the TP2 pin. > > Now boot the machine and go into BASIC and see the altered banner. > > Going forward, you can keep reloading hacked versions of main rom images > into either the primary or secondary slots, or both, since the flexrom wire > ends up acting as a 3rd ultimate fallback so you can always boot even if you > totally screw up both primary and secondary slots. You Can't break the > internal main rom no matter what you do with the rex. The only way to edit > the internal main rom is to open the machine back up and connect it to a > programmer. > > It's actually super convenient once it's set up. REX makes it a breeze to > load the images, and having 2 slots means you can keep one slot sacrosanct > and only hack on the other slot, so you can recover from borked hacks > without even having to open the option rom compartment and switch the wires. > > Without a REX Classic, you can still re-write the rom, but only by > connecting it to a programmer, so it needs the machine to be opened up. > > The pics show using a SOIC test clip, but there is also a programming > adapter pcb you can make instead. > https://github.com/bkw777/aDIPters#flexrom_100 > https://github.com/bkw777/aDIPters#flexrom_100-programming-adapter > > Or for the flash version, because the 28C256 eeprom is getting ridiculous > expensive these d
Re: [M100] Printing from RS232 port?
I don't have an EP44, but I do see a blog post where someone uses the EP44 as a serial terminal for DOS: https://darrengoossens.wordpress.com/2019/03/21/the-brother-ep44-as-a-serial-terminal-for-dos/ It seems like you should just be able to connect to it using the TELCOM program and send characters to it by typing. If you get that working, sending a file by using the `Up' option with F3 and typing the name of your document should print it out. I've copied a lot of files to my linux machine this way using `ed'. Just gotta figure out the settings for TELCOM. You'll probably need a NULL modem cable as well, since it looks like the EP44 isn't just a printer and probably doesn't have TX/RX switched like a normal printer might. Hope that helps. On Wed, Nov 15, 2023 at 10:12:33PM +, Lee Osborne wrote: >Hey everyone... > >Is it possible to print from the serial port on a Model 100? If so, how >is it done? > >I have a Brother EP44 typewriter with built in RS232 port, and a double >ended 25 pin cable which I hope is suitable, but I'm scratching my head >getting it to do anything. > >Pointers appreciated. > >Lee
Re: [M100] FlexROM with REX#
Thanks Brian, I ordered both boards from oshpark and will build them soon. I appreciate the response and your work on the adapters. On Thu, Nov 16, 2023 at 01:15:17AM -0500, Brian K. White wrote: > On 11/15/23 16:29, runrin wrote: > > Thanks for the info Brian, I really appreciate it. > > > > My plan is just to pop the ROM out when I need to reprogram it. I'm > > actually more comfortable unscrewing the back from the system than > > popping out the option ROM cover anyway, since the brass inserts are > > probably more robust that the tight plastic snap on the back panel. It > > freaks me out every time I pop that thing open :P > > > > A few Qs: > > > > 1. It seems like pin 27 (/CS) on the system ROM is normally pulled low by a > > CPU read. /CS on the EEPROM should be fine if I just jumper /CS_IC to > > /CS_BUS and skip the R2 pullup, right? > > R2 disables the chip when REX is connected. > > With a jumper installed, the bus overrides R2 and the chip works like a > normal rom. > > With the REX wires installed, and the two wires connected to each other in > the option rom compartment, that's just another form of jumper. The bus > overrides R2 and the chip works like a normal rom. > > With the REX wires installed, and /CS_BUS wire connected to REX TP1 and > /CS_IC wire unconnected, R2 keeps the flexrom chip always disabled so as to > never conflict with the REX. When the bus tries to enable the main rom, the > REX responds instead. > > If you want to hard-code everything and save a few cents, you can omit R2 > and solder bridge /CS_BUS to /CS_IC, and the result is like an ordinary rom. > > R1 still allows you to write to the chip by being a pullup instead of a hard > trace. If you build the board normally with the /CS pins and R2 populated, > you have to install a jumper on those pins for programming anyway, so a > solder blob is the same. It just means you can't use the REX software main > rom feature. > > To program, if you have a SOIC test clip, then you can just use that and JP2 > doesn't matter. If you don't have a SOIC test clip, then build the matching > programming adapter and install a jumper onto JP2. Remove the jumper when > not programming. > > The ALE pin is just a pin in this case. It's not really ALE, just a pin that > the programming adapter uses to route pin 27 from the programmer ultimately > back to pin 27 on the eeprom, but using pin 23 along the way because of > having to work around the non-standard main rom pinout. > > The wikipedia page for the 8085 has a reasonable high level explanation: > "The 8085 is supplied in a 40-pin DIP package. To maximise the functions on > the available pins, the 8085 uses a multiplexed address/data (AD0-AD7) bus. > However, an 8085 circuit requires an 8-bit address latch, so Intel > manufactured several support chips with an address latch built in. These > include the 8755, with an address latch, 2 KB of EPROM and 16 I/O pins, and > the 8155 with 256 bytes of RAM, 22 I/O pins and a 14-bit programmable > timer/counter. The multiplexed address/data bus reduced the number of PCB > tracks between the 8085 and such memory and I/O chips." > > Basically A0-A7 and D0-D7 both use the same 8 physical pins, at different > times. When ALE is high, those pins are address, when ALE is low, those pins > are data. > > Basically the low 8 bits of the bus to be used for both address and data at > different times. When ALE is high, AD0-AD7 are A0-A7. When ALE is low, > AD0-AD7 are D0-D7. > > Why they bothered to route that line to the main rom and to the optrom > sockets when those sockets have full normal separate non-conflicting address > and data pins I don't know. You can use a bog standard 27C256 in both places > (with the pinout rearranged) and totally ignore the ALE pin. Other logic > supplies the correct /CE /OE signals at least for those sockets. > > -- > bkw > > > > > > > I'll obviously still use the R1 pullup for /WE on the EEPROM. I was > > considering using a DIP switch as a jumper for /WE to ALE instead of a > > jumper if it fits in the case. That way I don't have to dig around for a > > jumper every time I want to program the EEPROM. > > > > 2. More of a technical question about the m100 architecture: > > > > I'm curious if you know how ALE is normally being used by the CPU/system > > ROM? It looks like it's being used by M1 and M25 as well. I haven't > > encountered an address latch before, coming from mostly 6502 and Z80, > > and I'm interested to understand its purpose. > > > > Thanks again! > > > &
Re: [M100] Possible M100 prototype.
I'd also be interested in a dump of the ROM. It'd be good to archive it if possible. On Tue, Oct 24, 2023 at 10:20:12PM +, Ken St. Cyr wrote: >I don't think you're wrong - all of my M100s are 110CH1X. 1010 >certainly seems to be an earlier revision of the board. Just curious - >what's the date code on the CPU? I can't make it out with the cap in >the way. Also, if you're up for dumping the ROM, it would be >interesting to compare it to a 'released' version. > >//Ken S. > __ > >From: M100 on behalf of Josh Malone > >Sent: Tuesday, October 24, 2023 12:07 PM >To: m...@bitchin100.com >Subject: Re: [M100] Possible M100 prototype. > >Off the top of my head, I don't recognize that artwork number: PLX >1010H1X. Am I wrong here? > >And, wow, this thing is bodge city. Almost like the Tandy 1400FD that I >have. (that I still don't know the story behind the bodges) > >-Josh > >On Tue, Oct 24, 2023 at 11:38 AM <[1]bir...@soigeneris.com> wrote: > >All, > > >I recently attended Tandy Assembly 2023 and Eric Dittman asked me to >recap an M100 that had belonged to Frank Durda an engineer at Tandy. I >did not pay much attention to it at the time but when I took it apart >last night, I was not sure what I was looking at. The PCB is a US type >but has dozens of modifications and is a bit different than any other >one I have seen. > >I then noticed it was missing the TRS-80 Model 100 badge, the FCC label >and it had no serial number. Now I’m thinking this might be a prototype >machine. I took a few quick pictures, link below. I plan to take some >higher quality images and document the modifications as well as I can. >The goal it to get it working but not alter it more than required. The >only caps that look like they are leaking at the 10uf (which are >normally the worst ones), so I will start with those and the memory >battery and see if it springs to life. > >[2]https://1drv.ms/u/s!AtH4vpaZnzX7mKBV07xl8qlMDuc6QA?e=UfFBVx > >Thoughts? > >Jeff BIrt > > References > >1. mailto:bir...@soigeneris.com >2. https://1drv.ms/u/s!AtH4vpaZnzX7mKBV07xl8qlMDuc6QA?e=UfFBVx
[M100] Alternate keymaps on the M100 (and a question about caps lock)
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.
Re: [M100] Alternate keymaps on the M100 (and a question about caps lock)
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 > 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.
Re: [M100] Alternate keymaps on the M100 (and a question about caps lock)
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 > > 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 >
Re: [M100] Alternate keymaps on the M100 (and a question about caps lock)
Thanks Joshua and Stephen! For now I'll run TASM with wine, but I will definitely give bergen a try. I did some digging around on the wayback machine and see that there was at one time an ANSI C source release of TASM which would be really neat to find and archive. I tried sending an email to the one listed on the site, but I have a feeling that they can no longer be tracked down. On Sat, Nov 25, 2023 at 06:27:21PM -0800, Joshua O'Keefe wrote: > > On Nov 25, 2023, at 4:54 PM, Stephen Adolph wrote: > > > > I use the Telemark TASM32. I think you can find it online, not sure. > > bergen is a modern open source reimplementation of Telemark TASM, intended as > a drop-in replacement that runs on modern platforms. I haven't tested it but > it looks like a pretty nice project: > > https://github.com/kyleedwardsny/bergen > kyleedwardsny/bergen: Free and open-source replacement for the Telemark > Assembler. > github.com
Re: [M100] Alternate keymaps on the M100 (and a question about caps lock)
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 > > 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 > > > > Th
Re: [M100] Alternate keymaps on the M100 (and a question about caps lock)
I tried uz80as ( https://github.com/jorgicor/uz80as ) tonight which also claims to be compatible with TASM and I got the same results as with the TASM 3.2 shareware executable. Pretty easy to get up and running and worth a try. If I give bergen a try I'll let everyone know how it went. On Sat, Nov 25, 2023 at 06:27:21PM -0800, Joshua O'Keefe wrote: > > On Nov 25, 2023, at 4:54 PM, Stephen Adolph wrote: > > > > I use the Telemark TASM32. I think you can find it online, not sure. > > bergen is a modern open source reimplementation of Telemark TASM, intended as > a drop-in replacement that runs on modern platforms. I haven't tested it but > it looks like a pretty nice project: > > https://github.com/kyleedwardsny/bergen > kyleedwardsny/bergen: Free and open-source replacement for the Telemark > Assembler. > github.com
Re: [M100] Alternate keymaps on the M100 (and a question about caps lock)
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. > > > > > >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, N
Re: [M100] MiniNDP 512 (was Re: FlexROM with REX#)
Brian, Do you know if it's possible to dump the original ROM using the programming adapter for the FlexROM 100? Thanks! On Fri, Nov 17, 2023 at 07:14:24AM -0500, Brian K. White wrote: > On 11/16/23 01:15, Brian K. White wrote: > > > > Basically A0-A7 and D0-D7 both use the same 8 physical pins, at > > different times. When ALE is high, those pins are address, when ALE is > > low, those pins are data. > > > > Basically the low 8 bits of the bus to be used for both address and data > > at different times. When ALE is high, AD0-AD7 are A0-A7. When ALE is > > low, AD0-AD7 are D0-D7. > > > > guess I was too tired while writing. > > I was up all night playing with a whopping 32 channel logic analyzer trying > to reverse engineer how a 512k RAMPAC is supposed to work and it's right at > my limits of ability to figure stuff out. > > -- wall of text warning -- > > I don't have and have never seen a 512k RAMPAC, I just know they existed, > and we have the RAM100/RAM200 software that supports it. > > A few months ago I got a 128k/256k Node DATAPAC and reverse engineered the > hardware and produced a modern version of it the MiniNDP 256, and that works > with RAM100.CO and RAM200.CO. > > The way the hardware works is among other things, it uses 2 address bits A8 > and A9 on the bus to select between two functions: set a block number, or > read or write a byte of data. > A8 is high for both of those, so you can consider the 3 pins (A), /YO, and > A8 to together be the selector for the device as a whole. all 3 of those > need to be in the right states or the device is not selected and none of the > other pins matters at all. > > That just leaves A9 which selects whether you are doing a BLOCK op or a BYTE > op. > > A BLOCK op latches in an 8-bit block number from AD0-AD7 and resets the byte > counter to 0, so that the next BYTE op gets byte 0 of the just-selected > block. > > A BYTE op reads or writes a byte of data from/to AD0-AD7 and then increments > then byte counter by 1. > > There are 10 bits in the byte counter so the interface to the device allows > for a maximum of 256 possible block numbers to choose from, and you can read > or write up to 1024 bytes in a block before the byte counter rolls over and > you'll just get byte 0 again. > > The way BUS_A8 and BUS_A9 are read are they are fed into a 3:8 decoder that > translates 3 input bits into one of 8 possible single output pins. There are > 3 bits of input but only 2 are used, bit 2 is simply grounded, and the only > output pins that are used are bits 1 and 3. Output bit 1 (which you get when > the input was just A8 high) means to do a BLOCK op. Output bit 3 (which you > get when the input was A8 and A9 high) , means do a BYTE op. > > So far, this all only allows for 256k. There are no other bits like, you > can't just add a 9th bit to the block number or an 11th bit to the byte > counter etc. (well you could do that last but the original software would > not know how to use it). > > So the hardware interface is fully used up by 256k. > > Yet there were later versions of the device that had 384k and 512k. I've > never seen one but they are in magazine ads, and the software has a "Bank" > button which does nothing on my 256k units. > > So the 512k units somehow implemented a 2nd 256k bank, but otherwise worked > the same as a 256k unit. > > I don't have a 512k RAMPAC to examine, but I do have software that supports > it, and I have this superdeduper 32 channel logic analyzer, so I thought it > would be fun to hook that up and just see what happens when I hit the bank > button in the software. I also found this neat little pi gpio 1-to-2 adapter > that makes a perfect neat little tap for the 102 bus connector to make the > hookup pretty neat. > https://www.amazon.com/dp/B07MCW4KCM/ > You just plug the long pins into the T102 with the other pins pointing up > and the female connector pointing straight out just like the 102's connector > is, plug the external device onto that just the same as plugging directly > into the 102, and connect all the logic analyzer wires to the pins pointing > up. The logic analyzer wires already end in female sockets. > https://photos.app.goo.gl/F6GdTjUG5gu4vkqf7 > https://photos.app.goo.gl/VzwWCf8wB3aBhYJBA > > > Looking at the schematic > https://raw.githubusercontent.com/bkw777/NODE_DATAPAC/main/PCB/out/MiniNDP_256.svg > > There is an unused address input bit on U4 (top-left), so it seems natural > that the bank function might somehow be based on adding A10 to the 3rd input > of that chip, and then one of the other output pins becomes a BANK signal. > > So I hooked everything up, captured a short session where all I did was turn > the machine on, run RAM100.CO, press the Bank button once, exit RAM100.CO, > turn the machine off. > I had the logic analyzer external trigger connected to the bus CLK pin. > Searched the capture for any instances where A8 is high, (A) is high, /YO is > low, and the rest don't care
Re: [M100] Alternate keymaps on the M100 (and a question about caps lock)
Thanks for letting me know. It's a shame that its not compatible with everything. It's strange to me that hardware scrolling wasn't part of the original design. On Mon, Nov 27, 2023 at 02:56:16AM -0500, Stephen Adolph wrote: >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,
Re: [M100] TPDD/TPDD2 Floppy Drive Belts and TPDD2 Boot Floppy
I've actually had my eye on both of these listings for a while, but I've held off due to the high prices of TPDD2s. I will likely get an FB100 eventually, since that seems like the cheapest option. I assume there is a similar utility floppy for the TPDD1. You don't have any of those do you? On Sun, Nov 26, 2023 at 08:18:28AM -0700, Ken Gregg wrote: >Happy Holidays, all! > >On ebay, I still have a small supply of brand new floppy drive belts >for Tandy Portable Disk Drive (TPDD) and Tandy Portable Disk Drive 2 >(TPDD2) drives, and a smaller supply of tested Utility floppy diskettes >for the TPDD2 (created on new old stock SSDD diskettes). > >I decided today that, once this small stock is depleted, I will no >longer be offering these again. > >So, now's your chance to stock up. Discounts up to are applied when you >purchase more than one of each. > >Floppy Drive Belt for Tandy Portable Disk Drive TPDD1 26-3808 or TPDD2 >26-3814: [1]https://www.ebay.com/itm/304695833943 > >Tandy Portable Disk Drive 2 Utility Floppy 26-3814, tested on two TPDD2 >drives: [2]https://www.ebay.com/itm/305217850778 > > References > >1. https://www.ebay.com/itm/304695833943 >2. https://www.ebay.com/itm/305217850778
Re: [M100] MiniNDP 512 (was Re: FlexROM with REX#)
Thanks Brian. I have a test clip that will work i think I'll just use that. On Tue, Nov 28, 2023 at 09:49:48AM -0500, Brian K. White wrote: > On 11/27/23 11:48, runrin wrote: > > Do you know if it's possible to dump the original ROM using the > > programming adapter for the FlexROM 100? > > Maybe. > > There are two things to worry about and I'll just think out loud right here. > > 1 > The programming adapter presents a pinout for a 28C256, not a 27C256 or mask > rom. Those are only a couple wires different, but then again, since it's > just for reading, and the read cycle is the same, you could just tell the > programmer that it's reading a 28C256 (force it, override chip id > detection), and that won't hurt the rom. > > 2 > Pin 23. The programming adapter routes pin 27 from the programmer (/WE if a > 28C256 were in the programmer) to pin 23 of the DIP socket, which is ALE on > the LH535618 rom, but the flexrom board connects it to the /WE pin on the > actual 28C256 on the board. > > I *think* what you want to do is take a DIP-28 socket and bend out pin 23, > connect the bent-out pin 23 to pin 27, put the modified socket into the > programming adapter and then the old rom into the modified socket. Then tell > the programmer to read a 28C256 and ignore chip id. The socket is just to > avoid bending the leg on the old chip. > > IE, feed /CE from the programmer to both /CE and ALE on the chip, and don't > connect anything to /WE at the programmer. > > But, at that point it's almost simpler to just make the entire adapter > manually with two dip sockets and wires. Especially since it's a one-off. In > that case, use a 27C256 pinout and tell the programmer to read a 27C256 > instead of 28C256. > > But if your chip has any of these part numbers, then it's already been > dumped. > https://bitchin100.com/wiki/index.php?title=Model_and_ROM_information > > -- > bkw >
Re: [M100] MiniNDP 512 (was Re: FlexROM with REX#)
This is a good idea, but I've already got my new EEPROM in there and every time I remove it and put it back in, I get worried I'll break off one of the legs and have to resolder it. The leadframes used to make DIP pins on Brian's FlexROM adapter board work well, but I really don't want to have to replace them when I inevitably break one off. Would you use a BASIC script to do this Mike? Just a loop to PRINT each byte to the COM port? On Tue, Nov 28, 2023 at 11:45:10AM -0500, Mike Stein wrote: > Why not just dump it out of the M100 directly? > > On Tue, Nov 28, 2023 at 9:50 AM Brian K. White wrote: > > > > On 11/27/23 11:48, runrin wrote: > > > Do you know if it's possible to dump the original ROM using the > > > programming adapter for the FlexROM 100? > > > > Maybe. > > > > There are two things to worry about and I'll just think out loud right here. > > > > 1 > > The programming adapter presents a pinout for a 28C256, not a 27C256 or > > mask rom. Those are only a couple wires different, but then again, since > > it's just for reading, and the read cycle is the same, you could just > > tell the programmer that it's reading a 28C256 (force it, override chip > > id detection), and that won't hurt the rom. > > > > 2 > > Pin 23. The programming adapter routes pin 27 from the programmer (/WE > > if a 28C256 were in the programmer) to pin 23 of the DIP socket, which > > is ALE on the LH535618 rom, but the flexrom board connects it to the /WE > > pin on the actual 28C256 on the board. > > > > I *think* what you want to do is take a DIP-28 socket and bend out pin > > 23, connect the bent-out pin 23 to pin 27, put the modified socket into > > the programming adapter and then the old rom into the modified socket. > > Then tell the programmer to read a 28C256 and ignore chip id. The socket > > is just to avoid bending the leg on the old chip. > > > > IE, feed /CE from the programmer to both /CE and ALE on the chip, and > > don't connect anything to /WE at the programmer. > > > > But, at that point it's almost simpler to just make the entire adapter > > manually with two dip sockets and wires. Especially since it's a > > one-off. In that case, use a 27C256 pinout and tell the programmer to > > read a 27C256 instead of 28C256. > > > > But if your chip has any of these part numbers, then it's already been > > dumped. > > https://bitchin100.com/wiki/index.php?title=Model_and_ROM_information > > > > -- > > bkw > >
[M100] m100 maximum baud rate without flow control
hey all, i was wondering if anyone has done any work determining the maximum baud rate the m100 supports without xon/xoff flow control? i assumed it was 9600 because thats what most of my machines from that era support (usually with a 8250 uart). i've been working on a homebrew computer for some time now, and even with a dead stable serial clock at 9600 hz i'm dropping characters on the m100. i thought it was a software issue, but it works perfectly with my heathkit terminal, so i'm thinking its an m100 problem. 300 baud worked fine, but even as slow as 2600 seemed to be an issue. thanks!
Re: [M100] Important artifact?
you're doing god's work. thank you! On Fri, Dec 08, 2023 at 04:07:27PM -0600, bir...@soigeneris.com 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 <[1]m100-boun...@lists.bitchin100.com> On Behalf Of r cs >Sent: Friday, December 8, 2023 2:17 PM >To: [2]m...@bitchin100.com >Subject: Re: [M100] Important artifact? > > >The PDD 26-3808 (not PDD2) is here for free (thank you Internet >Archive!): > >[3]https://archive.org/details/tandyportablediskdriveservicemanual26380 >8stext > > References > >1. mailto:m100-boun...@lists.bitchin100.com >2. mailto:m...@bitchin100.com >3. > https://archive.org/details/tandyportablediskdriveservicemanual263808stext
[M100] M100 ergonomics
Hey all! I was wondering if people would be willing to share how they typically use their Model Ts. I've found that it's pretty difficult for me to find a comfortable position to use my Model 100 for any length of time. I'm always bending forward to get a better view when I sit at a table or desk, and when it's on my lap the lack of palmrest causes the keyboard to slide too close to my body making it hard to type. Do you typically only use them on desks? Do you use yours on your lap? Do you use a lap desk? Any tips for how you comfortably use a Model T for longer stretches (30+ minutes) would be appreciated. Thanks!
Re: [M100] M100 ergonomics
Brian- Could you share the terminfo file you use on your raspberry pi to get your M100 working? I regularly use a Heathkit terminal with my OpenBSD machine, and that works extremely well with `crtscts' in stty at 19200 baud, even though the terminal itself can only handle 9600 baud without flow control. I've got everything tuned nicely to avoid any issues with color codes/etc on that machine and I really enjoy using it. Despite that, I've struggled a lot to get my linux machines to play nice with the small screen of the M100. I've tried out 3 or 4 different terminfos I've seen floating around the net, but haven't gotten consistent enough results to actually want to use the M100 as a terminal for any length of time. I've also tried multiple different USB serial adapters, and have had issues at speeds greater than 300 baud, even with `ixon ixoff' in stty and flow control enabled on the M100. I am able to start and stop incoming data manually with `^S' and `^Q', so I'm sure that is working, but I still get garbage whenever the M100 has to slow down drawing to the screen. Tips to getting the M100 working better with linux would be greatly appreciated. Thanks! On Mon, Dec 11, 2023 at 07:08:05AM -0500, Brian Brindle wrote: >I've got several and they get used often. Daily task is usually note >taking with IDEA! or journaling with the built in text editor. I do use >the Ultimate ROM II and View80 a LOT. I also use it pretty extensively >for Amateur radio, primarily logging and satellite tracking. I also >spend quite a bit of time messing around in CP/M mode doing weird stuff >with DDT. > >I have a raspberry-pi connected that I've dubbed the "Tan-PI". It's got >several programs on it to do file sharing / TPDD emulation and I have a >hacked together perl script that sends each key press from the Tandy to >the X-windows system as keyboard input allowing me to use the M100 as >the keyboard to the Raspberry Pi system. I will often remote the >Raspberry Pi with VNC on my phone when I need a "real desktop" to send >an e-mail or go to a web stie the tandy can't handle from the Linux >CLI. > >These are my two go-to addons. I use a small USB power bank and this >for power: >[1]https://www.amazon.com/gp/product/B0BJDSG28P > >I also have a bunch of these Laptop "Foot" devices. Just drop one at >the back, middle of the Model-T and it greatly improves the ergonomix. >They are cheap so I keep one in my bag and one on my desk. >[2]https://www.amazon.com/SUPBEE-Universal-Computer-Anti-Slip-Ventilate >d/dp/B085QL2QXS > >On Mon, Dec 11, 2023 at 6:30 AM Gary Wilkinson ><[3]gpwilkin...@hotmail.com> wrote: > > My T102 is connected as a terminal to my VAX4000. I have a DVI > connected to an LCD screen with composite video, so I get 80 column > full screen text. Very useable. > > Sent from my iPhone > > > On 11 Dec 2023, at 10:25, Lee Osborne > <[4]leeosbo...@fastmail.co.uk> wrote: > > > > > > I use mine quite a lot for journalling and writing articles, > mainly because it has the best keyboard of any device I own. I find > that a desk or table is fine as long as the light is reasonably > good. I can type faster on it than most other computers or > keyboards. > > > > Lee > > > >> On Mon, 11 Dec 2023, at 00:47, runrin wrote: > >> Hey all! > >> > >> I was wondering if people would be willing to share how they > typically > >> use their Model Ts. > >> > >> I've found that it's pretty difficult for me to find a > comfortable > >> position to use my Model 100 for any length of time. I'm always > bending > >> forward to get a better view when I sit at a table or desk, and > when > >> it's on my lap the lack of palmrest causes the keyboard to slide > too > >> close to my body making it hard to type. > >> > >> Do you typically only use them on desks? Do you use yours on your > lap? > >> Do you use a lap desk? Any tips for how you comfortably use a > Model T > >> for longer stretches (30+ minutes) would be appreciated. > >> > >> Thanks! > >> > > > > Lee Osborne > > West Lothian, Scotland > > 07960 096282 > > [5]leeosbo...@fastmail.co.uk > > www.journeyman.online/services > > References > >1. https://www.amazon.com/gp/product/B0BJDSG28P >2. > https://www.amazon.com/SUPBEE-Universal-Computer-Anti-Slip-Ventilated/dp/B085QL2QXS >3. mailto:gpwilkin...@hotmail.com >4. mailto:leeosbo...@fastmail.co.uk >5. mailto:leeosbo...@fastmail.co.uk
Re: [M100] M100 ergonomics
lol! I figured that's what you meant. I'll look thru the links you posted. thanks very much! On Mon, Dec 11, 2023 at 05:04:34PM -0500, Brian Brindle wrote: >Correction on my last e-mail - muscle memory took over and I typed >98N1D - this should 98N1E with the E to enable XON/XOFF. Classic case >of target fixation right there. Don't type D, don't type D.. Typed D. > >John, I have had some issues with how enabling flow control is done. >The method I settled on was to enable it with stty after logging in >through a sourced .bashrc script. I abandoned trying to get it to work >natively in getty, even eventually swapped out getty for the more >supported agetty set in "old" mode. > >While I may be connecting at 19200 the speed is dependent on the screen >unfortunately. That can get downright frustrating. Hackerb9 explains >several other fixes for keys and stuff way better than I ever could in >that git hub link I put up earlier. I recommend just about everything >he talks about except I can't condone the use of emacs or nano. Real >men use VI. > >One other possibility would be the serial adapter you are using. I have >had issues with the voltage levels being just off enough on cheap USB >to serial adapters that the M100 had troubles. > >Brian > >On Mon, Dec 11, 2023 at 4:45 PM John R. Hogerhuis <[1]jho...@pobox.com> >wrote: > >Interesting... I could never go that fast without h/w flow control... >Linux wouldn't drop characters, but it would overrun the T's receive >buffer because it didn't react immediately to xoff. I don't know why... >my theory was maybe the driver doesn't see the xoff until it popped out >of the stream. Maybe screen in the middle processes the xoff sooner. >All I had in the loop was getty or equivalent. > >Between that and ANSI escapes from xterm and utf8 and whatnot full >screen console stuff was always messed up without HTERM to filter and >flow control. > >-- John. > > References > >1. mailto:jho...@pobox.com
Re: [M100] 19.2Kbps on the Tandy 102
Wow Brian! This setup with the Pi attached to the back looks amazing. It's attached so cleanly as well. I appreciate you doing the `stty' at the end, hopefully mirroring your setup will help me get things working better on my end. I do wonder if the fact that you are using the Pi's GPIO pins to do serial instead of a USB adapter is part of why your system is working so well. If you have a USB adapter floating around, I'd be really curious if you got the same results with that connected to the PI instead of connecting it directly. Thanks again for sharing your experience getting this working. On Tue, Dec 12, 2023 at 05:42:28PM -0500, Brian Brindle wrote: >This has come up in discussion a few times so I wanted to show that >19.2Kbps on the Tandy 100 is possible with only software flow control. > >Here is a video of me creating a 500 line 40 col file that is 20KB, >transferring it to the M102 and back again using the 19.2Kbps serial >connection. It gets slowed down due to the screen being so slow making >it absolutely of no value to be running at those speeds but does >demonstrate that flow control can be used on a Linux device in this >situation. > >Hardware flow control would work best and is what I would recommend but >I wanted a device that would work on a stock M100/102 and on a M200 >where the flow control lines do not work properly. > >It's apparently really hard to film, type and remember what to say so I >apologize for that.. > >[1]https://youtu.be/BGxx__Zr1O4 > >Brian > > References > >1. https://youtu.be/BGxx__Zr1O4
[M100] Question about TPDD/FB100
Hey all I acquired an FB100 recently, popped it open and checked the belt, and it looks brand new. I spent a few hours building some of bwk's TPDD cables tonight and testing it out, but I'm struggling to get the drive working. When I connect the drive to my M100 and use the TS-DOS rom, the drive access light pops up, and then it tells me my disk isn't formatted (it's not). Then when I press "Y" to format, there is no activity on the access light. I tried hooking it up to my Linux box with the WP-2/PC cable and pdd.sh, and I get no response at all from the drive. No access light at all even with an `ls' or `ready' command. I checked the jumpers on the bottom and one was bridged, so I tried desoldering that (since the TPDD manual suggests setting the DIP switches to all off), and it didn't make any difference. Any thoughts what might be going on? Thanks!!
Re: [M100] Question about TPDD/FB100
're looking at: > > > tpdd_write(5A 5A 23 00 DC) > ocmd_read_ret(100) > ocmd_read_ret: reading 2 bytes (fmt & len) > tpdd_read(2 100) > tpdd_wait(100) > tpdd_check() > tpdd_check() > Detected TPDD1 > > > This looks like we aren't displaying something because we sent 5A 5A 23 00 > DC to the drive, and then just declared "detected tpdd1" without seeing the > response from the drive. In this case, that is actually how we detect tpdd1 > is by the lack of response to that command. > > > ocmd_ready() > ocmd_send_req(07) > calc_cksum(07 00):F8 > ocmd_send_req: fmt="07" len="00" dat="" chk="F8" > tpdd_write(5A 5A 07 00 F8) > > Send the "ready" command, > which ultimately means send 5A 5A 07 00 F8 to the drive > > ocmd_read_ret() > ocmd_read_ret: reading 2 bytes (fmt & len) > tpdd_read(2) > tpdd_wait() > tpdd_check() > tpdd_wait: :0 > tpdd_read: l=2 12 01 > > Read a standard response packet from the drive, > which ultimately means to start by reading 2 bytes and interpret them to > tell how many more bytes to read for the rest of the response packet. > > And we did get 2 bytes back from the drive, and they were 12 01 > > And then it goes on to interpret that as packet type 12 payload length 1, > which means read one more byte for the payload and one more after that for > the checksum, which gave us the payload error code 71 which was looked up > from a table of error codes to give us the human readable message for code > 71. > > > > > Some basic physical stuff to check just so you have some baseline to know > what is normal. A lot of the drives normal correct behavior seems kind of > dead if you didn't know what to expect. Like how when you turn it on, > nothing happens. Two lights on the front and neither one lights, the motor > doesn't spin, etc. > > Holding the drive in your hand, you should feel the motor nudge just a bit > every time you flip the power switch on. It doesn't spin even one rotation, > just a short vibration for 1/2 second or less. It doesn't matter if the door > is open or closed. It doesn't matter if there is a disk inserted or not. The > access light never comes on. > > The battery light stays off at all times except it blinks on for a split > second every time you turn the power off. > > > > Checking some electrical basics right at the drive itself without the cable > in the equation: > > Looking at the rear of the drive, pin 1 is top-right, and pin 2 is bottom > right. > > You should get continuity from pin 1 to the center pin of the power jack. > > With the power ON, and a dmm in dc volts mode, black on pin 1, you should > get 5v on pin 3 and 0v on all other pins. > > > -- > > verifying the cable (probably should have started with this) > > Looking into the drive-end of the cable, with the polarity key up, and > ignoring the two positions that form the polarity key, > pin 1 is top-left, pin 2 is bottom-left. > > > Looking into the pc end of the cable, with the long side up, the plug should > be 9-pin female, pin 1 is top-right, pin 6 is bottom-right. > > (Regardless how the cable is constructed between those two ends, whether a > custom one-piece cable like you made using the WP-2/PC cable directions, or > using the cable meant for the 100 and adding the special 25f-9f adapter > linked in the hardware document in the pdd.sh readme. Point being I'm > testing the end-to-end connection with nothing that might change the pinout > left out. The only other "adapter" is just the usb-serial adapter which you > can consider as not an adapter but just a 9-pin male com port.) > > https://raw.githubusercontent.com/bkw777/TPDD_Cable/master/DE9F_to_PC.jpg > > > With a dmm in continuity mode, you should get beeps with these, direction of > black vs red doesn't matter: > > drive pin 1 to pc pin 5 > drive pin 2 to pc pin 7 > drive pin 5 to pc pin 4 > drive pin 7 to pc pin 3 > > With a dmm in diode mode: > > black on drive pin 3 to red on pc pin 6: 1.7v (reversed: ol) > black on drive pin 4 to red on pc pin 8: 1.7v (reversed: ol) > black on drive pin 6 to red on pc pin 2: 1.7v (reversed: ol) > > > There are no pin-to-pin shorts within the cable at either end. In a normal > serial cable it's not wrong to have DCD connected to DSR right at the end in > the plug, which would be pin 1 to pin 6 both on the pc end here, but in this > case pin 1 on the pc end is not connected to anything and there are no other > things like that either. Just 7 individual 1:1 connections. > > > > > I just performed all of these with my own working FB100 and cable. > > I have used a variety of usb-serial adapters and I think every one I've used > has worked, but bad usb-serial adapters are definitely a thing, and I used a > good FTDI cable just now. Gearmo GM-FTDI2-LED-C for the record. > > -- > bkw > > > > > > > > > > > > > > > On 12/13/23 01:17, runrin wrote: > > Hey all > > > > I acquired an FB100 recently, popped it open and checked the belt, and > > it looks brand new. > > > > I spent a few hours building some of bwk's TPDD cables tonight and > > testing it out, but I'm struggling to get the drive working. > > > > When I connect the drive to my M100 and use the TS-DOS rom, the drive > > access light pops up, and then it tells me my disk isn't formatted (it's > > not). Then when I press "Y" to format, there is no activity on the > > access light. > > > > I tried hooking it up to my Linux box with the WP-2/PC cable and pdd.sh, > > and I get no response at all from the drive. No access light at all even > > with an `ls' or `ready' command. > > > > I checked the jumpers on the bottom and one was bridged, so I tried > > desoldering that (since the TPDD manual suggests setting the DIP > > switches to all off), and it didn't make any difference. > > > > Any thoughts what might be going on? > > > > Thanks!! > > -- > bkw >
Re: [M100] Question about TPDD/FB100
unfortunately format fails with the same error. i'll try tearing the thing open later and see if i can find anything obviously wrong with it. here's what i got: % VERBOSE=9 ./pdd.sh format get_tpdd_port() Using port "/dev/ttyUSB0" open_com() set_stty() speed 19200 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 1; -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc do_cmd(format) _init() fonzie_smack() tpdd_drain() tpdd_check() tpdd_write(4D 31 0D) tpdd_drain() tpdd_check() pdd2_unk23() ocmd_send_req(23) calc_cksum(23 00):DC ocmd_send_req: fmt="23" len="00" dat="" chk="DC" tpdd_write(5A 5A 23 00 DC) ocmd_read_ret(100) ocmd_read_ret: reading 2 bytes (fmt & len) tpdd_read(2 100) tpdd_wait(100) tpdd_check() tpdd_check() Detected TPDD1 ocmd_format() Formatting Disk, TPDD1 filesystem : Are you sure? (y/N) y ocmd_send_req(06) calc_cksum(06 00):F9 ocmd_send_req: fmt="06" len="00" dat="" chk="F9" tpdd_write(5A 5A 06 00 F9) ocmd_read_ret(105000 2) ocmd_read_ret: reading 2 bytes (fmt & len) tpdd_read(2 105000 2) tpdd_wait(105000 2) tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_check() tpdd_wait: 105000 2:2500 tpdd_read: l=2 12 01 ocmd_read_ret: reading 2 bytes (data & checksum) tpdd_read(2) tpdd_wait() tpdd_check() tpdd_wait: :0 tpdd_read: l=2 80 6C ocmd_read_ret: fmt=12 len=01 dat=(80) chk=6C verify_checksum(12 01 80 6C) calc_cksum(12 01 80):6C verify_checksum: given:6C calc:6C ocmd_check_err() ocmd_check_err: ret_fmt=12 ret_len=01 ret_dat=(80) read_err="0" ocmd_check_err: 80:Hardware Fault 0 format: Hardware Fault 0 On Wed, Dec 13, 2023 at 04:23:11PM -0500, Brian K. White wrote: > Communication all looks good actually. Cabling and serial port are solid. > The problem is only when it issues the initial dirent() as part of the > directory listing process, and gets a hardware fault error code from the > drive. > > The drive firmware tried to run the disk and read the media, and failed, and > said so. > > It may possibly just be that the disk is not formatted. The disk needs to be > formatted by the drive, it can not use the normal PC formatting the disk > already has. > > So verify: > * The drive has a good belt. > * The disk is DD not HD, aka 720K not 1.4M, aka has only one hole in one > corner. > * The write-protect door in that one hole is closed (open=write-protect). > * The disk contains no data you care about. > > Then in pdd.sh issue the "format" command. > Wait approximately one solar flare cycle. > > Ok 100 seconds but feels like 11 years because there is no data on the wire > all during that time and no way to monitor progress. Even in verbose mode > the percent-done animation is just counting down the expected time which is > known. And you can't do any better. You can not send any data to the drive > during this time or it will just crash it. The client must just sit and wait > for data from the drive, or abort if no data comes after some max possible > time. > > Maybe your drive has the same problem my Purple Computing drive has. > Everything works except actually accessing the media. > So like, something wrong with the drive head or it's signal amplifier maybe? > I have not figured out what's actually wrong with mine yet. That level of > problem may be just a bit beyond me, figuring out how the head read circuit > actaully works and where to probe with a scope and what to expect there etc. > Though, I have a scope and haven't actually tried yet so who knows. > > -- > bkw > > > On 12/13/23 15:22, runrin wrote: > > OK! I think there might be a problem with my PC cable. > > > > With a standard 25 pin to 9 pin adapter and a gender changer on my M100 > > cable, I'm getting some output, but there may be some other issues with > > the drive or cable. > > > > I will paste my results below. > > > > > > `ready' wi
Re: [M100] Question about TPDD/FB100
it's also very possible that i made a mistake when i initially reassembled the thing. it was very fiddly to get everything back together. i'll let you know if i find anything interesting. On Wed, Dec 13, 2023 at 02:36:18PM -0800, runrin wrote: > unfortunately format fails with the same error. i'll try tearing the > thing open later and see if i can find anything obviously wrong with it. > > here's what i got: > > % VERBOSE=9 ./pdd.sh format > get_tpdd_port() > Using port "/dev/ttyUSB0" > open_com() > set_stty() > speed 19200 baud; rows 0; columns 0; line = 0; > intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; > eol2 = ; swtch = ; start = ^Q; stop = ^S; > susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; > time = 1; > -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal crtscts > -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl > -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 > -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 > vt0 ff0 > -isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop > -echoprt echoctl echoke -flusho -extproc > do_cmd(format) > _init() > fonzie_smack() > tpdd_drain() > tpdd_check() > tpdd_write(4D 31 0D) > tpdd_drain() > tpdd_check() > pdd2_unk23() > ocmd_send_req(23) > calc_cksum(23 00):DC > ocmd_send_req: fmt="23" len="00" dat="" chk="DC" > tpdd_write(5A 5A 23 00 DC) > ocmd_read_ret(100) > ocmd_read_ret: reading 2 bytes (fmt & len) > tpdd_read(2 100) > tpdd_wait(100) > tpdd_check() > tpdd_check() > Detected TPDD1 > ocmd_format() > Formatting Disk, TPDD1 filesystem > : Are you sure? (y/N) y > ocmd_send_req(06) > calc_cksum(06 00):F9 > ocmd_send_req: fmt="06" len="00" dat="" chk="F9" > tpdd_write(5A 5A 06 00 F9) > ocmd_read_ret(105000 2) > ocmd_read_ret: reading 2 bytes (fmt & len) > tpdd_read(2 105000 2) > tpdd_wait(105000 2) > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > tpdd_check() > > tpdd_wait: 105000 2:2500 > tpdd_read: l=2 12 01 > ocmd_read_ret: reading 2 bytes (data & checksum) > tpdd_read(2) > tpdd_wait() > tpdd_check() > tpdd_wait: :0 > tpdd_read: l=2 80 6C > ocmd_read_ret: fmt=12 len=01 dat=(80) chk=6C > verify_checksum(12 01 80 6C) > calc_cksum(12 01 80):6C > verify_checksum: given:6C calc:6C > ocmd_check_err() > ocmd_check_err: ret_fmt=12 ret_len=01 ret_dat=(80) read_err="0" > ocmd_check_err: 80:Hardware Fault 0 > > format: Hardware Fault 0 > > On Wed, Dec 13, 2023 at 04:23:11PM -0500, Brian K. White wrote: > > Communication all looks good actually. Cabling and serial port are solid. > > The problem is only when it issues the initial dirent() as part of the > > directory listing process, and gets a hardware fault error code from the > > drive. > > > > The drive firmware tried to run the disk and read the media, and failed, and > > said so. > > > > It may possibly just be that the disk is not formatted. The disk needs to be > > formatted by the drive, it can not use the normal PC formatting the disk > > already has. > > > > So verify: > > * The drive has a good belt. > > * The disk is DD not HD, aka 720K not 1.4M, aka has only one hole in one > > corner. > > * The write-protect door in that one hole is closed (open=write-protect). > > * The disk contains no data you care about. > > > > Then in pdd.sh issue the "format" command. > > Wait approximately one solar flare cycle. > > > > Ok 100 seconds but feels like 11 years because there is no data on the wire > > all during that time and no way to monitor progress. Even in verbose mode > > the percent-done animation is just counting down the expected time which is > > known. And you can't do any better. You can not send any data to the drive > > during this time or it will just crash it. The client must just sit and wait > > for data from the drive, or abort if no data comes after some max possible > > time. > > > > Maybe your drive has the same problem my Purple Computing drive has. > > Everything works except actually accessing the media. > > So like, something
Re: [M100] Question about TPDD/FB100
I got it working! Thank you again for your help with this. When I took the thing apart the first time, I was able to see that the belt looked good, and I stopped taking it apart, because it was kind of a huge pain. I spent the time to fully tear it down last night (it was an even bigger pain), and the belt was trashed lol. Shouldn't have trusted my eyes. I wish I could help with the Purple Computing drive. It sounds like a fun problem to try to diagnose. To anyone disassembling these things. Definitely read the service manual and follow the steps there. On Wed, Dec 13, 2023 at 04:23:11PM -0500, Brian K. White wrote: > Communication all looks good actually. Cabling and serial port are solid. > The problem is only when it issues the initial dirent() as part of the > directory listing process, and gets a hardware fault error code from the > drive. > > The drive firmware tried to run the disk and read the media, and failed, and > said so. > > It may possibly just be that the disk is not formatted. The disk needs to be > formatted by the drive, it can not use the normal PC formatting the disk > already has. > > So verify: > * The drive has a good belt. > * The disk is DD not HD, aka 720K not 1.4M, aka has only one hole in one > corner. > * The write-protect door in that one hole is closed (open=write-protect). > * The disk contains no data you care about. > > Then in pdd.sh issue the "format" command. > Wait approximately one solar flare cycle. > > Ok 100 seconds but feels like 11 years because there is no data on the wire > all during that time and no way to monitor progress. Even in verbose mode > the percent-done animation is just counting down the expected time which is > known. And you can't do any better. You can not send any data to the drive > during this time or it will just crash it. The client must just sit and wait > for data from the drive, or abort if no data comes after some max possible > time. > > Maybe your drive has the same problem my Purple Computing drive has. > Everything works except actually accessing the media. > So like, something wrong with the drive head or it's signal amplifier maybe? > I have not figured out what's actually wrong with mine yet. That level of > problem may be just a bit beyond me, figuring out how the head read circuit > actaully works and where to probe with a scope and what to expect there etc. > Though, I have a scope and haven't actually tried yet so who knows. > > -- > bkw > > > On 12/13/23 15:22, runrin wrote: > > OK! I think there might be a problem with my PC cable. > > > > With a standard 25 pin to 9 pin adapter and a gender changer on my M100 > > cable, I'm getting some output, but there may be some other issues with > > the drive or cable. > > > > I will paste my results below. > > > > > > `ready' without a disk: > > > > > > % VERBOSE=9 ./pdd.sh ready > > get_tpdd_port() > > Using port "/dev/ttyUSB0" > > open_com() > > set_stty() > > speed 19200 baud; rows 0; columns 0; line = 0; > > intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; > > eol2 = ; swtch = ; start = ^Q; stop = ^S; > > susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; > > time = 1; > > -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal crtscts > > -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl > > -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 > > -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 > > vt0 ff0 > > -isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop > > -echoprt echoctl echoke -flusho -extproc > > do_cmd(ready) > > _init() > > fonzie_smack() > > tpdd_drain() > > tpdd_check() > > tpdd_write(4D 31 0D) > > tpdd_drain() > > tpdd_check() > > pdd2_unk23() > > ocmd_send_req(23) > > calc_cksum(23 00):DC > > ocmd_send_req: fmt="23" len="00" dat="" chk="DC" > > tpdd_write(5A 5A 23 00 DC) > > ocmd_read_ret(100) > > ocmd_read_ret: reading 2 bytes (fmt & len) > > tpdd_read(2 100) > > tpdd_wait(100) > > tpdd_check() > > tpdd_check() > > Detected TPDD1 > > ocmd_ready() > > ocmd_send_req(07) > > calc_cksum(07 00):F8 > > ocmd_send_req: fmt="07" len="00" dat="" chk="F8" > > tpdd_write(5A 5A 07 00 F8) > > ocmd_read_ret() > > ocmd_
