"Vpp is below Vpp"? Not sure what you meant there? And "And chip pin 27 pulled to VCC"? ; Since you're talking about Vpp in this post I think you're confusing /PGM (27) with Vpp.(1)?
We're not programming, so Vpp should indeed be at Vcc and normally /PGM should indeed be pulled high. To enable the data outputs to read, /CE and /OE should be low, and /PGM high, which is what you want. /OE *high* and /PGM low turns the data lines into inputs, i.e. disables output.. I'm just curious what happens when /OE is *low* and /PGM is also low, which we want to disable the outputs. I expect /OE will enable the outputs regardless of /PGM, but if by chance /PGM also turns the data line into inputs then that'd be what you want (i.e. /PGM = active-high CE) Just wasting bandwidth with idle speculation... ;-) m On Mon, Nov 14, 2022 at 9:12 AM Brian White <[email protected]> wrote: > The datasheet says to rest vpp at vcc. Most do, even if elsewhere they > also say that writing is disabled as long as vpp is below vpp and the only > low limit is pretty much the same as for any other pin, like 0.5 or 0.7 > below vcc. > > I never saw a reason why, but it's definitely a consistent suggestion in > datasheets to hold vpp at vcc rather than gnd. > > Maybe holding it at gnd wastes a little power or stresses a gate somewhere > through reverse leakage and vcc is closer to where that gate is when > running. So, it may still be true that any voltage from gnd to vcc is legal > and functional, yet one is still better than the other. > > > bkw > > On Mon, Nov 14, 2022, 12:19 AM Mike Stein <[email protected]> wrote: > >> Too bad I don't have a 200; you're probably right but since it's not >> clearly defined in the data sheet I'll have to dig out one of my other >> systems using a 2764 and check it for myself ;-) >> >> But I have to ask: why pull pin 27 to Vcc? What happens if you pull it >> low? >> >> On Sun, Nov 13, 2022 at 9:06 PM Brian K. White <[email protected]> >> wrote: >> >>> 27C64 can't be used as-is. >>> pin 27 is A15 and needs to needs to go to a non-existing 2nd OE or CE. >>> >>> You'd need an adapter board that combines pin 27 (A15) from the socket, >>> with pin 22 /CE0 (/BANK#1) from the socket, to produce a single /CE to >>> pin 22 of the chip. >>> >>> You could do that with a single 2-gate NAND part the same as in this >>> model 200 RAM >>> https://github.com/bkw777/TANDY_200_RAM#single-bank---sop >>> >>> https://raw.githubusercontent.com/bkw777/TANDY_200_RAM/main/TANDY_200_RAM.svg >>> >>> That is using one nand gate just to invert /CS1 to CS1, >>> then ANDing those to make a single CS, and inverting that to make a >>> single /CS output to the chip's /CE >>> >>> The point is getting the job done with only 2 gates of the same type so >>> it's all from a single part. >>> They even make little 8-leg parts with just the 2 needed gates. >>> >>> For 27C64 you'd need to do that with /CE0 from bus pin 22 and CE1 from >>> bus pin 27, to produce a single /OE to chip pin 22. And chip pin 27 >>> pulled to VCC by anything from 100k to a plain trace. All other pins >>> including /CS would go 1:1 socket to chip. >>> >>> >>> On 11/13/22 19:38, Mike Stein wrote: >>> > Duh; shoulda looked more carefully; it really IS A15 (not A13) and it >>> > goes to /CE1 (or CE1); double duh! Thanks, Brian. >>> > >>> > So it looks like the only non-standard pin is pin 27, since 26 is not >>> > used. Has anyone actually tried a JEDEC standard 27C64? >>> > >>> > Pin 27 is the Program pin which looks like it might effectively be an >>> > active high OE (since there is no program voltage. >>> > >>> > m >>> > >>> > >>> > >>> > On Sun, Nov 13, 2022 at 5:27 PM Brian White <[email protected] >>> > <mailto:[email protected]>> wrote: >>> > >>> > 8k. >>> > >>> > HN61364 = 8k >>> > A15 is connected to a chip select to enable/disable the whole chip >>> > (really just output enable not chip enable despite the /CEx >>> labels), >>> > and the actual address lines are only A0-A12 >>> > >>> > It's mostly like 27C64 but with 3 OE lines, customer programmable >>> to >>> > be either active high or low as part of the mask programming. >>> > Although the schematic labels them as /CE0 /CE1 /CE2, really they >>> > are all OE not CE, and it appears that /CE1 should be shown as >>> > active-high, so really: /OE0, OE1, /OE2 , and /CS is a normal >>> actual >>> > whole chip enable, active low. >>> > >>> > I was just now in the middle of drawing up an adapter for that chip >>> > like FlexROM_102 but for that chip, to facilitate using the main >>> rom >>> > replacement feature of REX Classic in a 200 the way I have already >>> > for 100 and 102. >>> > >>> > But it may be simpler to make a different kind of adapter that >>> > replaces both chips with a single larger chip on a single adapter >>> in >>> > the main rom socket and simply remove the 8k chip. The /BANK1 line >>> > goes to both chips the same, and A15 ends up activating one or the >>> > other exclusively at any given moment. >>> > >>> > bkw >>> > >>> > On Sun, Nov 13, 2022, 4:48 PM Mike Stein <[email protected] >>> > <mailto:[email protected]>> wrote: >>> > >>> > Looking at the schematic, are you sure it's 8K and not 16 >>> (27x128)? >>> > >>> > Looks standard except for pins 26 & 27 >>> > >>> > On Sun, Nov 13, 2022 at 4:23 PM Stephen Adolph >>> > <[email protected] <mailto:[email protected]>> wrote: >>> > >>> > Georg, >>> > What type of ROM chips did you use, when you replaced your >>> > ROMs with patched versions? >>> > I've been pondering what the simplest way to do that is. >>> > The 8K M13 socket is wired oddly, and doesnt seem >>> compatible >>> > with a 27C64. >>> > thx >>> > Steve >>> > >>> > On Sun, Nov 13, 2022 at 12:30 PM Georg Käter >>> > <[email protected] >>> > <mailto:[email protected]>> wrote: >>> > >>> > Hello together, >>> > >>> > I own a M200 "German/EU Version" (Art.Nr. 26-3860H) >>> > w/modem, for German market it was delivered with set of >>> > keyboard >>> > >>> > caps and a data tape including driver for keyboard and >>> > printer. I tried this in VirtualT and it seems to work >>> > so far. To run REX >>> > >>> > on my M200 I replaced original ROM by ROM from VirtualT >>> > patched to serve german keyboard mapping. >>> > >>> > For your reference I´ve added original ROM files and >>> > files from tape for your reference. >>> > >>> > Regards >>> > >>> > Georg >>> > >>> > >>> > Georg Käter >>> > Gangolfsweg 44 >>> > D-52076 Aachen >>> > Tel. : +49 2408 7194987 >>> > Fax. : +49 2408 7196758 >>> > Mobil : +49 171 4839954 >>> > E-Mail : >>> > >>> > [email protected] >>> > <mailto:[email protected]> >>> > >>> > ========== Ihre Nachricht >>> > ========================================== >>> > >>> > *von* : Cedric Amand <[email protected] >>> > <mailto:[email protected]>> >>> > *gesendet* : Sonntag, 13. November 2022, 15:37 >>> > *an* : [email protected] >>> > <mailto:[email protected]> >>> > *Betreff* : [M100] custom key mapping generator for >>> > Tandy 200 >>> > >>> > __________ Originalnachricht >>> > _______________________________________ >>> > >>> > My point exactly Brian ! >>> > How did they come up with that idea ? It makes no >>> > sense. It really prevents you from using the option >>> > rom socket. >>> > The docs does not talk about removing it. >>> > And even if you could remove it ; the installation >>> > procedure of that ROM is not easy at all, requires >>> > to type two "calls" with the freaking keyboard >>> inverted. >>> > OK - us nerds 40 years later can do it easily, just >>> > type "CQLL", but imagine explaining that to a >>> random >>> > journalist in 1984 ?! >>> > Especially as the french doc (which I happen to >>> > have) says to type "CALL" not CQLL. >>> > I also wonder if other markets are affected by this >>> > plague, >>> > If anyone here lives in germany and owns a qwertz >>> > (or other keyboard variant) of the M200 : do you >>> > have a "stock option ROM" as well ? >>> > I also wish to thank Stephen publicly for the time >>> > he invested into helping me, as indeed, you can't >>> > use an option ROM (and even less a REX#) in those >>> > non-qwerty M200s, and I think this research might >>> > help some other people at some stage (this hobby is >>> > booming right ? :) ) >>> > We're (and I am) in the process of replacing the >>> > main rom + 8KB rom with a 27C512 flashed with a >>> > custom "native Azerty" firmware >>> > Which should free up to option socket, for a REX# >>> > I also plan to make other modifications to that >>> > custom ROM, but we'll see if I get there. >>> > I've also been experimenting in the past with >>> custom >>> > firmware for the my M102 for different reasons. >>> > I'm a "modem" nerd and I have all the equipment >>> > (PABX, etc) to make voice calls between my vintage >>> > laptops - so it's important for me to have my >>> modems >>> > work. This required a custom firmware to make my >>> > M102 work, with modem, with a REX#. ( OK I think >>> > this kind of stuff is only relevant to me this time >>> > :) :) >>> > Le 2022-11-13 14:53, Brian White >>> > <[email protected] <mailto:[email protected] >>> >> >>> > a écrit : >>> > >>> > Nice. >>> > So the point would be to make the main rom >>> > natively azerty to match the hardware, free up >>> > the option rom slot for normal use, without >>> > otherwise changing the main rom so that it >>> > becomes incompatible with application software? >>> > I guess you might even be able to make a dvorak >>> > version and move the keycaps around? >>> > I'm just trying to imagine the sales pitch for >>> > that azerty 200 that needs the option rom, thus >>> > preventing the use of any other option rom (or >>> > at least making it pretty inconvenient by >>> having >>> > to swap them on every reset I guess?) >>> > "Here's your new model 200. It's only half as >>> > useful as others with no modem and no option >>> rom >>> > but you can still pay full price please." >>> > -- >>> > bkw >>> > >>> > On Sun, Nov 13, 2022, 8:28 AM Stephen Adolph >>> > <[email protected] >>> > <mailto:[email protected]>> wrote: >>> > >>> > hi folks, >>> > Thought I would share this work. It is a >>> > spreadsheet for computing the keyboard >>> table >>> > in the T200 so you can make native custom >>> > keyboards for T200. >>> > Why? >>> > The AZERTY keyboard in Europe was >>> > accommodated using an option ROM that kinda >>> > hacked the keyboard. Keystrokes get >>> > intercepted and corrected to be AZERTY even >>> > though the main ROM is set up for QWERTY. >>> > An alternative is to have the main rom >>> > directly support AZERTY. >>> > To do this, there are 6 keyboard mapping >>> > tables that start at 9763h. Each table are >>> > 44 bytes long. >>> > This spreadsheet lets you assign the ascii >>> > codes for each of the 44 affected keys, for >>> > all 6 tables. (unshifted, shifted, GRAPH, >>> > shift GRAPH, CODE, Shift CODE). >>> > It is an excel spreadsheet that included >>> the >>> > analysis add it so that certain needed >>> > functions are present. >>> > Once you make the correct keyboard mapping, >>> > the spreadsheet provides the 6x44 bytes in >>> > assembly compatible form, so you can >>> compile >>> > and patch the tables with a hex editor. >>> > This approach could be used for other >>> > machines also. >>> > Note - the AZERTY keyboard did NOT modify >>> > the actual character set, so that is out of >>> > scope. Of course it is possible to patch >>> > the main ROM to change the bitmaps as >>> well. >>> > Not handled by this spreadsheet. >>> > Comments welcome. >>> > Steve >>> > >>> > >>> > >>> > __________ Ende Originalnachricht >>> > __________________________________ >>> > >>> > *Vertraulichkeitsinformation: >>> > *Diese Nachricht ist vertraulich. Die Informationen >>> > dieser Nachricht sind ausschließlich für die >>> persönliche >>> > und vertrauliche Verwendung durch den/die oben >>> genannten >>> > Empfänger bestimmt. Wenn Sie kein beabsichtigter >>> > Empfänger sind, bitte lesen, kopieren und verwenden Sie >>> > die Nachricht nicht. Machen Sie sie nicht anderen >>> > zugänglich. Bitte informieren Sie uns umgehend über den >>> > Zustellfehler und senden Sie die Originalnachricht >>> > per E-Mail an uns zurück. >>> > >>> > *Confidentiality Notice: >>> > *This message is confidential. The information >>> contained >>> > in this message is intended only for the personal >>> > and confidential use of the recipient(s) named above. >>> If >>> > you are not the intended recipient, please do not >>> > read, copy, or use it and do not disclose it to others. >>> > Please inform us immediately of the delivery error >>> > and return the original message to us via e-mail. >>> > >>> >>> -- >>> bkw >>> >>>
