Cloning a Tandy TRS-80 Model 1 - Page 1
Forum section: electronics / projects

author: GK
author_rank: Super Contributor
timestamp: January 02, 2019, 09:15:12 am
content: Now that myCommodore Pet 2001 cloneis done and dusted, it's on to the next computer clone project, so here is a new thread......Like the PET clone, this is going to be a functional recreation entirely in current production parts, eschewing any TTL. Due to public holidays, Digikey aren't going to ship my Z84C00 until Wednesday the 3rd and I won't be seeing it this week, but that will give me time to complete the PCB layout for the video generation circuitry.So far I've completed the breadboard verification of the video generation circuitry - the schematic is attached. The only things not currently shown/included in this schematic are the '244 !RW/!WR buffer pair which will isolate the video circuitry data bus from the MPU system data bus, a jumper to select either a 50 Hz or 60 Hz field frequency, and the switchableElectric Pencil lower case modification. All chips are 74HC(T) CMOS. Any device with an input driven from a data output pin of the AT28C256 (the character ROM) and the AS7C256 (the video RAM) is a HCT device, all else are 74HC.In the original TRS-80 the designers skimped on memory, providing only seven 1-bit static RAM chips for the video memory. Bit-7 controlled whether a memory location defined either a graphics character or a ROM-generated "text" character. Bit-6 was the missing memory chip, leaving only six bits (bits 0 through 5) for selecting the character. So, that gave 64 ROM-defined "text" characters and 64 graphics/block characters (the latter giving chunky, pseudo bit-mapping). Only 64 text characters didn't leave enough room for lower case letters of the alphabet. Lower case letters, in addition to several other characters, were actually defined in the second 64 character page of the TRS-80's character ROM, but the original hardware just couldn't access them without bit-6.The breadboard photo shows the compete video generator. For testing purposes only, I temporarily have a PIC16F874 plugged into the (currently) mostly vacant breadboard on the lower left. In lieu of the, currently absent, Z80 MPU system, this PIC is wired to the video circuitry address/data and control lines and programmed to load a test screen and character-set dump into the video memory.The 64 "text" characters are sequentially dumped onto the very top character row, and the 64 "graphics" characters on the next. The remaining video memory locations are filled with #. I made a single byte of error in both ROM characters 1 and N. Also the left justification of 1 and perhaps : and ; probably doesn't look 100% right either. The ROM chip is currently kinda buried beneath wire links at the moment, so I think I'll put off re-flashing it just for the time beingIn the low-resolution video mode, every second (odd) video memory location becomes redundant and the even characters are doubled in width by a halving of the pixel serial-shifting clock frequency. The vertical resolution remains the same.High resolution mode:Low resolution modeThis schematic is shrunk to fit your screen by the forum software. Save and load it into something else to view full size.

author: wilfred
author_rank: Super Contributor
timestamp: January 02, 2019, 11:30:06 am
content: I don't know what character set the original TRS-80 used but the 2513 character chip had the "narrow" characters centered in the matrix. You have the "1" ";" ":" and so on over on the left. It is hard to see the eventual effect from the screen shown but the "1" is abutting the "0" a little too close. Also the 2513 had the blank row of dots above the character. That doesn't mean the TRS-80 did, or had to mimic that, but are you sure you have it right?

author: GK
author_rank: Super Contributor
timestamp: January 02, 2019, 12:23:52 pm
content: Quote from: wilfred on January 02, 2019, 11:30:06 amYes, as I mentioned in my opening post. The revision of the ROM binary file won't have these characters left-justified.Quote from: wilfred on January 02, 2019, 11:30:06 amYes, I have this right. TRS-80 used 12 lines and six horizontal pixels for each character. The four bottom lines were always blanked, as was the left-most pixel of each horizontal row. This was hardwired. This left a ROM-definable grid of 5x8 pixels for each character. Most characters only used 7 of those horizontal lines - the upper ones, giving a total of five blank lines at the bottom of each character.The mask-programmable Motorola ROM used in the TRS-80 was called a "5x7 character generator", even so the actual definable character field was 5x8. It was called such because in use you would typically always leave either the very top or the very bottom horizontal row of pixels blank so as to leave a single vertical pixel of space between character lines. In the TRS-80, the usage was different as four permanently blank lines were added to the bottom of each character. Some characters (punctuation and lower-case letters) in the TRS-80's set therefore actually made use of the 8th row (despite the technical literature actually being ambiguous in this regard, erroneously stating that there are 5 hardware-blanked lines at the bottom of each character instead of the actual 4).

author: LaserSteve
author_rank: Super Contributor
timestamp: January 02, 2019, 04:21:32 pm
content: A friend has a complete TRS80 model 100 Service Manual with full schematics. You want to go portable next?Steve

author: Tomorokoshi
author_rank: Super Contributor
timestamp: January 02, 2019, 05:53:05 pm
content: Quote from: LaserSteve on January 02, 2019, 04:21:32 pmHey! I have that too! Along with the DVI!

author: PA0PBZ
author_rank: Super Contributor
timestamp: January 02, 2019, 07:38:51 pm
content: Tandy sold a lower case upgrade kit (26-1104) for the model 1 which had the missing ram and an updated character generator. You probably want to implement that in your design.

author: firehopper
author_rank: Frequent Contributor
timestamp: January 02, 2019, 10:08:18 pm
content: Quote from: LaserSteve on January 02, 2019, 04:21:32 pmthat I'd like to see, I actually have a model 100 with only 24 k ram. should try and find a upgrade I guess.

author: EEVblog
author_rank: Unknown
timestamp: January 02, 2019, 11:02:39 pm
content: Quote from: PA0PBZ on January 02, 2019, 07:38:51 pmYeah, I believe that was pretty standard in the end, everyone had it.Nice work!

author: MrAl
author_rank: Super Contributor
timestamp: January 02, 2019, 11:13:24 pm
content: Hi,This is quite interesting. I have a TRS80 the portable model. I got it back in the 1980's and ended up making mods to the operating system because the file dates would not go above 1987 :-) The unit still works as tested about 2 years ago, but i dont use it anymore.I loved that thing though and used it for several years before moving to the more standard PC.Brings back many memories.

author: nick_d
author_rank: Regular Contributor
timestamp: January 03, 2019, 01:08:07 am
content: I love it.I bought some Atmel 5V CPLDs for this kind of purpose. Might be easier?cheers, Nick

author: GK
author_rank: Super Contributor
timestamp: January 03, 2019, 07:28:05 am
content: Quote from: nick_d on January 03, 2019, 01:08:07 amKizmit99 mentioned that he/she might start a thread on his/her FPGA TRS-80 Model 1 clone here:https://www.eevblog.com/forum/projects/otp-eprom-programmer/msg2083648/#msg2083648As per my PET clone, I am doing a traditional traditional hardware construction again with this one. Like the PET, the TRS-80 Model 1 keyboard unit didn't use any propriety/custom CRT controller chips and a plug-in equivalent for its original microprocessor is still being produced. I think this would not apply to and rule out cloning a model 100 similarly. I am seriously contemplating an Apple II next though.

author: GK
author_rank: Super Contributor
timestamp: January 03, 2019, 07:45:24 am
content: Quote from: PA0PBZ on January 02, 2019, 07:38:51 pmYes, I mentioned the Electric Pencil modification in my opening post, which was similar. My clone will include the lower case function - it is just a matter of providing a switch to toggle the MS address line of the character ROM between D6 of the video SRAM and the faux bit-6.One thing about the Electric Pencil lower case mod is that it didn't come with a ROM upgrade, as the ROM originally had a lower case set programmed into it, even so it wasn't accessible with the standard hardware. The Tandy lower case upgrade kit, as you mentioned, actually updated the ROM as well. I am not sure at the moment in what way the upgraded lower case set differed from the original, but I intend to find out eventually as I am adding a manual ROM page select to my design so that you can choose to run either the original lower case set or the upgraded one.Anyway, I have already programmed my ROM with a lower case set which I found on the net. It is an additional 32 characters. I just took a break from my PCB layout and changed a few jumper wires on my breadboard. Here is the lower case set dumped to the screen in addition to the upper case set.Yes, I made a data-entry boo-boo on another ROM character - "g".

author: kizmit99
author_rank: Regular Contributor
timestamp: January 03, 2019, 04:21:00 pm
content: I've noticed quite a few differences between the font your using and the one I have... I'm pretty sure mine is an accurate recreation of the font rom used in the "official" lowercase mod (with one line descenders). Although I have to say that I've found conflicting info on the net for a few of the character positions (0x60 and 0x7E specifically).I've seen 0x60 with the pound-symbol, and 0x7e with a yen-symbol on this site:https://www.kreativekorp.com/software/fonts/trs80.shtmlbut those symbols seem far too modern for the TRS-80, so I went with the original ROM glyphs (open-tic and tilda) for those two positions.I've attached a hex file of the ROM I'm using in case you're interested...(Note -- the 'graphics' characters are not in this rom-image, I'm generating them dynamically as in the original design)

author: German_EE
author_rank: Super Contributor
timestamp: January 03, 2019, 06:47:34 pm
content: My first computer was a Tandy TRS-80 Model 1. I thought I could save money by buying a 4K machine then getting a friend to upgrade it to 16K and install the lower-case mod. He did this but a couple of months later the machine died and he couldn't fix it. Tandy computers used to come with a warranty sticker on the bottom and if that was broken the repair cost was a minimum of four hours labor. Tandy fixed my machine and I got another three years of life from it before the Apple //e came along.Other happy memories include building my own high-speed cassette interface that loaded and saved about eight times faster and playing my first adventure game through the night. Good times!

author: GK
author_rank: Super Contributor
timestamp: January 04, 2019, 02:03:29 am
content: QuoteThanks for the ROM file and yeah, the issue I am also having is with conflicting info. Last night I watched Dave's TRS-80 tear down blog video from 2014 and noticed that the ROM was originally socketed. It's amazing that no one seems to have just wired one to a 27XX footprint and read the bloody thing. When I have time I might go over to the Tandy/RS section of the VCF forum and see if anyone with an original machine might be kind enough to dump the character set to the screen and make a high-res. photo.I am also generating the 64 graphics block characters with discrete logic rather than with the ROM, but now that you bring this up I have to smack myself on the head. Doh! WTF am I doing that? By shifting this function to the ROM (which has way more space than I actually need) I can wipe four chips off the schematic. Going back to the breadboard now........

author: GK
author_rank: Super Contributor
timestamp: January 04, 2019, 04:47:58 am
content: OK, now that I've had my light bulb moment, here is how I am now going to define all of the characters in the ROM. Each character is mapped to an 8x16 grid and will thus take 16 bytes of memory. 64 characters will therefore take 1kbyte of memory.The 0-11 line counter, bits L1, L2, L4 and L8 will directly address the least significant address bits of the ROM. This makes the last 4 bytes of each character redundant as there are only 12 lines per character. Also bits 6 and 7 are redundant as there are only 6 horizontal pixels per character.So far I've manually entered the first kilobyte of the ROM which contains all of the (64) graphics characters. Now I just have to finish transferring the "text" characters to the new format. All in all, this will allow me to simplify the video generation circuitry quite significantly. But first I am going to go eat something.

author: GK
author_rank: Super Contributor
timestamp: January 04, 2019, 09:07:39 am
content: OK, I've just finished rewiring my breadboard and successfully testing the revised circuit with all of the modifications required to generate all of the characters with the ROM. I ended up simplifying the design by five logic IC'sAll 8 bits from the video ram now address the character ROM and thus all 256 possible character positions are entirely defined in the character ROM.Yay, now I can get back to the schematic entry and PCB layout.

author: GK
author_rank: Super Contributor
timestamp: January 04, 2019, 11:20:05 am
content: Quote from: kizmit99 on January 03, 2019, 04:21:00 pmBTW, thanks for posting this image as I can now see the correct sequential order of the individual characters. I had to edit a couple of my previous posts, including the opening post, as I incorrectly believed that data bit D7 needed to be set high to select a ROM "text" character. The technical manual states:"Delay bit 7* is sourced from latch Z27............... when this input is high, data in Z63 is low, which defies and alphanumeric character"On my first reading I glossed over the *, which means inverted. Sure enough, checking the schematics, there is an inverter (Z42F) that changes the sign of D7. So in my ROM I currently have my graphics and alphanumeric characters sequenced the wrong way around. Also the two chunks of 32 alphanumeric characters from "@" to "_" and from "SPACE" to "?" appear to be back to front. Funny enough this is the opposite way that they are put in sequence in the ASCII tables and the character set glyph table that I was using as my reference. I also did not know that the lower case page contained a duplicate of "@" through "_" in the first 32 locations, but now that I have the sign of D7 correct it is obvious why this needs to be so. Without the lower case mod., the original hardware addressed the character ROM with a fake bit 6 generated from NORing bits 5 and 7. Bit 7 is low to select a "text" character, so bit 6 simply becomes the inverse of bit 5. This means characters "@" through "_" will be access from locations 64 through 95. With the lower case mod. applied characters "@" through "_" will be accessed from locations 0 through 31.Now have a look at not-so-helpful reference, for example. It gives the correct binary values for the characters but plots the "@" to "_" and "SPACE" to "?" chunks in the reverse order and completely omits the duplicate block. Argh:

author: biff
author_rank: Contributor
timestamp: January 04, 2019, 12:44:43 pm
content: Quote from: GK on January 04, 2019, 02:03:29 amI actually found out about this topic over on the VCF Forum (someone posted a link to here) and since I'm interested in adding lower case with true descenders to my Model 1s, I came over to here looking for a hex dump of a char gen with descenders. (I saw one was posted upstream - and I'll definitely be looking at it)Anyhow - Ian Maverick over on the VCF Forums, is actually selling a plug in char gen upgrade that consists of a small PCB which converts the char gen pinout to a 27XX footprint (I assume). His solution is nice, except that who ever came up with the ROM data substituted a small graphics block for the underscore - i.e. cursor.I'm hoping to wire up the adapter board so I can read it using my TL866 - and then modify the graphic block to a proper underscore - and write it to a 27XX and swap out the masked ROM.Assuming the TL866 supports reading it - I'd be happy to read my original chargen from my Model 1. Probably wouldn't happen till Sunday though.Jim

author: davefiddes
author_rank: Newbie
timestamp: January 04, 2019, 01:05:10 pm
content: If you are looking for official character generator ROM dumps the xtrs emulator has the best collection I'm aware off:https://github.com/TimothyPMann/xtrs/blob/master/trs_chars.cThere is quite a storied history behind these roms.A recent(ish) find on the VCF board was two character generator EPROM replacements which can be used as an improved lower-case mod. They offer 1-line or 3-line decenders depending on how much you are willing to mod the video generation circuit from the Tandy original. The thread with ROM dump links can be found here:http://www.vcfed.org/forum/showthread.php?58665-GENDON3-improved-character-generator-for-the-Model-I-DiscussionIf I'm following your schematic it seems that you are preserving the delay-base mechanism for horizontal sync generation. A recent article in the TRS8BIT newsletter discusses the issues with the original circuit and offers some suggestions on how to fix the resulting character wobble which can develop with the original chips: Page 48 ofhttp://www.fabsitesuk.com/tandy/trs8bit1202.pdfHope this helps. Looks to be a fascinating project. I always figured my TRS-80 will keep going long after any of the other computers I've used because it used such basic logic building blocks. This promises to keep things going for even longer!

author: biff
author_rank: Contributor
timestamp: January 04, 2019, 01:10:19 pm
content: Quote from: davefiddes on January 04, 2019, 01:05:10 pmYup - this is the mod being sold by Ian which I mentioned earlier.The 1 line descender mod (which I installed) has the underscore replaced with a funky graphic block, and the 3 line version - while it has a true underscore, looked too different from what I was used to on my Model 1.Jim

author: MrAl
author_rank: Super Contributor
timestamp: January 04, 2019, 01:13:57 pm
content: Hi,Not sure what you guys are going for and it does sound very interesting, but just to note the TRS80 was based around the Z80 CPU. I would think you would want to use that unless you plan to emulate that too. Z80's were cheap 20 years ago, not sure anymore though.Planning to expand the memory too? That would be cool.What kind of disk drive, if any?USB stick capability?

author: GK
author_rank: Super Contributor
timestamp: January 04, 2019, 01:33:17 pm
content: Quote from: davefiddes on January 04, 2019, 01:05:10 pmThanks a lot for the links, I'll check them out. For the sync generation delays I am using proper monostable chips (74HC4538) which are rock stable, unlike the original design which looked a bit dodgy to me as it used some funky combination of 74C04 inverters and RC networks.

author: GK
author_rank: Super Contributor
timestamp: January 04, 2019, 01:38:50 pm
content: Quote from: biff on January 04, 2019, 12:44:43 pmThat would be awesome. I don't see a problem with wiring either your adapter unit or the original MCM6670 masked ROM to a 27XX footprint and reading it with your TL866. I use the same programmer.Here is how you'd wire it. I'd use a machined-pin IC socket in place of the 2716, and plug that directly into the TL866. It's easy to solder wires to the pins from the top.EDIT: oops, don't connect anything to A10.

author: davefiddes
author_rank: Newbie
timestamp: January 04, 2019, 01:48:04 pm
content: Quote from: biff on January 04, 2019, 01:10:19 pmSorry. Our posts crossed mid-flight.Quote from: GK on January 04, 2019, 01:33:17 pmThe original circuit is definitely a bit dodgy. After 38 years my TRS-80 needs fixing as the 74C04 has probably "gone off". The approach in the TRS8BIT article is to use a 74HC164 to derive the required timing from the main clock signal. Your approach seems simpler to be honest.

author: GK
author_rank: Super Contributor
timestamp: January 04, 2019, 01:52:01 pm
content: Quote from: MrAl on January 04, 2019, 01:13:57 pmThe Z84C00XXPEG is the current production, 40-pin DIP, Z80 substitute. Less than $8 AUD. I have 2 in transit:https://www.digikey.com.au/product-detail/en/zilog/Z84C0008PEG/269-3895-ND/929205The full 48kNo disk drive at the moment. Recreating the Expansion Unit will be a separate project.

author: kizmit99
author_rank: Regular Contributor
timestamp: January 04, 2019, 04:05:27 pm
content: Quote from: GK on January 04, 2019, 04:47:58 amYep, I was going to point out that once you move to having the graphics characters generated by the font rom you might as well let it generate the "blank" lines between rows as well. This allows you to use a font that has "true" descenders. Although personally I'm not a fan of that "look" as it doesn't ring true to the original machines (at least to me).Lots of interesting links added by other folks too! Thanks for those! I had no idea there was quite that much of an active TRS80 community out there.

author: German_EE
author_rank: Super Contributor
timestamp: January 04, 2019, 04:28:50 pm
content: Quote from: kizmit99 on January 04, 2019, 04:05:27 pmIt's like the first kiss, memories kinda linger

author: biff
author_rank: Contributor
timestamp: January 06, 2019, 07:57:28 pm
content: Quote from: GK on January 04, 2019, 01:38:50 pmOK - this is how I'm going to try wiring it up:Code:Chargen 2716 (TL866 ZIF)1 (A6) -> 22 (A9)2 (A5) -> 23 (A8)3 (A4) -> 1 (A7)4 (A3) -> 2 (A6)5 (A2) -> 3 (A5)6 (A1) -> 4 (A4)7 (A0) -> 5 (A3)8 (RS3) -> 6 (A2)9 (Grnd) -> 12 (Vss) Grnd10 (RS2) -> 7 (A1)11 (RS1) -> 8 (A0)12 (D0) -> 9 (Q0)13 (D1) -> 10 (Q1)14 (D2) -> 11 (Q2)15 (D3) -> 13 (Q3)16 (D4) -> 14 (Q4)17 (CS) Grnd18 (Vcc) -> 24 (Vcc)15, 16, 17 Grnd18, 19, 20, 21 N/C

author: exrbc
author_rank: Newbie
timestamp: January 06, 2019, 10:04:57 pm
content: back in the early 80's I could not afford a trs80 mo1 so made my own from the cct diagrams and remember working out chr gen and hand coding it into an eprom using one of the early eprom programmer, also added the serial port, high speed tape interface and floppy disk interface and additional re written roms . then added switching to allow it to become a NASCOM 1 used bank switching to swap out the ram and roms so could switch back and forth between them.The video section was the problem as the chr set was different as well as the chr's per line ect. still have the original cct diagrams but the hardware has long gone.

author: biff
author_rank: Contributor
timestamp: January 07, 2019, 01:05:32 am
content: Quote from: GK on January 04, 2019, 01:38:50 pmWell,I tried using every 2716 configuration available in the TL866 database, and every one of them resulted in nothing but 255's after a read.See attached picture how I rigged it up.At worst, I was expected jumbled data, not nothing at all.Jim

author: GK
author_rank: Super Contributor
timestamp: January 08, 2019, 01:30:07 am
content: Quote from: biff on January 07, 2019, 01:05:32 amThat a bit disappointing. Other than double checking the wiring, which I'm sure you've done already, I'm not sure what else to suggest. When I get some time I'll have a play with my own TL866 and the 2716 configurations.

author: GK
author_rank: Super Contributor
timestamp: January 08, 2019, 01:56:46 am
content: Well, my Z84C0006 arrived yesterday afternoon, and holy crap, after some hours of frustration it is now actually alive, although I'm a bit paranoid about even breathing over the breadboard at this stageBasic Level I just boots up with a blank screen and a "READY >" prompt. Basic Level II boots up with the question: "MEMORY SIZE?" - not sure ATM what kind of entry it is waiting for. I currently only have the basics of the keyboard matrix interface operating. I can assert any keyboard character by jumpering/poking between the keyboard scan output and scan input matrix lines on the breadboard, but that's not very usable at the moment as trying not to get multiple instances of the wire-poked character is next to impossible. Next up I'll have to adapt the PS2 keyboard interface design that I developed for my PET-2001 clone for the TRS-80.I also had to add another 74HC74 IC to the video generation circuitry because I originally did not fully emulate the original video blanking function when the CPU takes control of the video memory. When the CPU relinquishes control of the video memory the reactivation of the CRT electron beam needs to be delayed by two parallel-input load cycles of the serial-output shift register to ensure that when the beam turns back on it won't initially scribe several erroneous pixels. This prevents snow-like artifacts being produced on the screen when intensively updating the video memory.Aside from the data cassette serial interface, which I have not yet implemented, this then pretty much verifies the CMOS clone design.

author: oPossum
author_rank: Super Contributor
timestamp: January 08, 2019, 02:14:47 am
content: Quote from: GK on January 08, 2019, 01:56:46 am'Enter' for default. It will then ask "CASS?", 'Enter' for default again. Then you will get "READY>".

author: kizmit99
author_rank: Regular Contributor
timestamp: January 08, 2019, 02:16:34 am
content: Looking goodAll the "Memory Size" prompt is looking for is where YOU want the top of memory to be (assuming it's not at the top of physical memory) in decimal of course. So you can reserve some room for non-Basic stuff.You can just hit enter and it will set it to the top of physical memory.

author: kizmit99
author_rank: Regular Contributor
timestamp: January 08, 2019, 02:19:06 am
content: Quote from: oPossum on January 08, 2019, 02:14:47 amHuh??? I've never seen one do that?I suspect you may be thinking about a Model-III or possibly Model-4 boot sequence?

author: oPossum
author_rank: Super Contributor
timestamp: January 08, 2019, 02:23:11 am
content: Yep, got it confused with Model III/4. Thanks for the correction.Had to run my emulator to refresh my memory.

author: kizmit99
author_rank: Regular Contributor
timestamp: January 08, 2019, 02:16:27 pm
content: Oooo... I notice your Model-1 emulator is running the "upgraded" ROMs (I think they may be called "version 3"?). The ones where "RadioShack" was abbreviated "R/S" to reduce space and allow the upgraded basic to fit in the 12K.I've been looking up and down for that ROM image and can't seem to find it anywhere on the 'net. (I obviously must not be looking in the right places).Any chance you could either share that rom image, or point me in the direction of where I can find it?Thanks in advance!

author: rrinker
author_rank: Super Contributor
timestamp: January 08, 2019, 03:59:46 pm
content: I believe Dave is correct, and the lower case mod became standard equipment on later Model 1's. Subsequent systems, Model 3 and Model 4, had it all designed in to the system, no bodge board needed.Note that the Model 100 uses an 80C85 CPU and it a completely different animal from what is being discussed in regards to cloning a model 1.Now a clone of my old Model 4P - which was NOT just a Model 4 repackaged, there were a few differences in the design.....

author: oPossum
author_rank: Super Contributor
timestamp: January 08, 2019, 06:25:13 pm
content: Quote from: kizmit99 on January 08, 2019, 02:16:27 pmAlready posted in the PET threadhttps://www.eevblog.com/forum/projects/otp-eprom-programmer/msg1605259/#msg1605259This stuff was easy to find 20 years ago when I wrote that emulator!

author: kizmit99
author_rank: Regular Contributor
timestamp: January 09, 2019, 12:45:16 am
content: Quote from: oPossum on January 08, 2019, 06:25:13 pmThank you!Yeah, it seems like everyone who used to host stuff like that got copyright scared, because a lot of what seems like it used to be out there isn't anymore... Thanks for the pointer - exactly what I needed.

author: GK
author_rank: Super Contributor
timestamp: January 10, 2019, 05:45:02 am
content: Okay, thanks. I have a copies of both "Level 1 Users Manual" and "Level II BASIC Reference Manual" but have yet to sit down and have a read through.I just finished laying out the video generator PCB. The hardware configuration will be similar to my PET clone - a separate motherboard and a video generator board. What do you guys think of the crosshatched ground plane as opposed to a solid pour? Gives it that vintage-ish look/feel?Along the lines of the vintage look/feel theme, on the motherboard, like in the original TRS-80, I've decided to base the +5V rail regulator on a 723 rather than a three-terminal 7805 or equivalent. The pass transistor will be a TO3-packaged 2N3055 PCB-mounted on one of those rectangular, finned heatsinks. It's a pity that the MC3423 OVP/crowbar has gone obsolete. Anyone know of an alternative? Alternatively I can just use a small signal PNP switch and a zener diode to trigger an SCR.

author: wilfred
author_rank: Super Contributor
timestamp: January 10, 2019, 06:10:57 am
content: The crosshatched ground plane does look good. Since you're not reproducing the PCB I don't think it is critical. But, I also don't see a need to change it.You can get the MC3423 from Rockby.

author: GK
author_rank: Super Contributor
timestamp: January 10, 2019, 08:31:17 am
content: Quote from: wilfred on January 10, 2019, 06:10:57 amYes, but NOS only. I'm not going to use anything that isn't a current production part. I was mostly thinking of the MC3423 from a nostalgic point of view. I don't recall ever seeing a second source for it or any kind of (equally popular) substitute. There are lots of different brown-out/MPU-reset power supply supervisory ICs currently available, but an over voltage protection chip with an output drive intended to fire an SCR not so much. Anyway, I can make a crowbar trigger circuit easy enough with just a few discrete parts. The original TRS80 PSU didn't have any kind of OVP at all by the way. Slip with your DMM probes around the feedback pins of one of the two 723s and you can then go and joyfully tally up all of your fried logic chips.

author: GK
author_rank: Super Contributor
timestamp: January 11, 2019, 02:29:01 pm
content: Not terribly exciting, but the preliminary first page of the motherboard schematic. The RAM of the original TRS-80 keyboard unit was expandable to was 16k max. If you had an expansion unit, that could hold an additional 32k for 48k in total. I'm going to put the full 48k onto my motherboard. My clone design will be theoretically compatible with an original expansion unit, so long as the 32k of RAM inside the original expansion unit is disabled to prevent it from conflicting with my clones upper 32k RAM block. The easiest way to disable the expansion unit RAM would be to lift the output enable pin on the RAM's read output data bus buffer and wire it to be fixed HI-Z.It for this reason that I am not recreating the hardware to generate two specific drive signals originally present at the expansion port connector; these signals being MUX and !CAS, which were originally present exclusively for the purpose of addressing and refreshing the MK4116 dynamic RAM ICs used in the original expansion unit. All of the expansion interface control logic is shown in this schematic.Page 2 will contain the RAM, ROM and address decoding, the header for connecting to the video generator board and bugger all else. Once you strip from the original design all of the logic for refreshing and multiplexing the addressing of the original DRAMs, simply the address decoding logic to a single AT27C256 programmed with a lookup table, use a single SRAM chip for the full complement of RAM and and a single AT27C256 for the ROM, there's not an awful lot to it any more.Kinda boring, in a way

author: nick_d
author_rank: Regular Contributor
timestamp: January 12, 2019, 11:37:57 am
content: Not boringTo avoid damaging the expansion unit by lifting pins, could you just allow the expansion unit RAM to do its job and your RAM to do its job in parallel? It won't matter if two devices drive the data bus, providing they're driving the same thing to it. There might be issues with output-enable timing if it's driving the bus before the data has been read, though.cheers, Nick

author: GK
author_rank: Super Contributor
timestamp: January 12, 2019, 03:04:55 pm
content: Quote from: nick_d on January 12, 2019, 11:37:57 amThanks for the interestProblem with the old DRAM is that it was really slow. I think there would be nasty current spikes and EMI as the RAMs fight each other before they are outputting the same values.

author: German_EE
author_rank: Super Contributor
timestamp: January 12, 2019, 05:44:11 pm
content: I remember the old TRS-80 keyboard where each key was mapped to an address in memory, your scheme using an EPROM and a PIC is very elegant!Looking forward to the day you run SCRIPSIT.

author: GK
author_rank: Super Contributor
timestamp: January 12, 2019, 11:35:03 pm
content: ThanksI'm currently laying out a little board for the PS/2 keyboard interface. This will be a universal design compatible with any TRS-80, not just my clone.SCRIPSIT - know where I can download an audio file? I've been so engrossed with other aspects of this design that I haven't even started looking for software yet. I am about to nip out in 5 to get the paper and another breadboard from Jaycar. The next and final section to get breadboarded is the data cassette interface. Amazingly, despite the rats nest assembly on crappy cheapo breadboard, I seem to be getting the computer reasonably stable now. If it turns out to be stable enough to load and run a game or too, that would make for a cool initial Youtube video, I would think.EDIT: found in ~30s :https://www.classic-computers.org.nz/system-80/software_cassette_archive.htm

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 13, 2019, 12:24:08 am
content: Quote from: GK on January 12, 2019, 03:07:11 pmIs that what we could call "spaghetti hardware"?Impressive breadboarding job though. Not sure I would have the patience to do that anymore...

author: oPossum
author_rank: Super Contributor
timestamp: January 13, 2019, 06:58:43 am
content: Archive of TRS-80 Model 1 software here:http://www.classiccmp.org/cpmarchives/trs80/Software/Model%201/There are several versions of Scripsit.Software to make audio files:http://www.trs-80.com/wordpress/disk-and-tape-conversion-utilities/One of my favorite Model I programs was 'Dancing Demon'. It is in the archive. Manual is here:https://archive.org/details/Dancing_Demon_1980_Tandy

author: kizmit99
author_rank: Regular Contributor
timestamp: January 14, 2019, 06:21:45 pm
content: I was thinking about your approach to the keyboard. I'm making assumptions about what's going on inside the PIC, but I suspect they're correct...If correct, it doesn't look like you'll be able to express multiple keys down at the same time (exclusive of shift)? Not sure if you care, but that was something used in at least the 'mini-dos' feature of NEWDOS/80... If that's not correct, I'd be curious how you're handling that case with only the 6 lines coming out of the PIC to choose-a-character.I only noticed this because I recently had to redo a bit of my keyboard interface to deal with more of the oddness surrounding the mapping of an event driven keyboard (the PS2) to the very-simple (yet basically instantaneous) nature of the TRS80 approach.If you get a chance, try the following on your keyboard and see what the results are:<Press Shift><Press :|;><Release Shift><Release :|;> -- I suspect the TRS80 code will see ":", followed by ";".From what I can discern, the original keyboard scan routines deal with the fact the user may release shift out-of-order, but the fake-"shift"ing/Un"Shift"ing that we need to do when doing the mapping, generally (unless cared for), results in the shift signal changing state in a way that causes the TRS80 code to see both keys being typed. I've found similar issues with the "+|=", "'|"" (single/double quote key), and issues with "@". Basically any keys where the PS2 keys map to two separate TRS80 keys.I was able to correct that behavior on my design by only allowing my "ForceShift" and "ForceNoShift" signals to change at the beginning of each PS2 keypress. I realize that doesn't "mean anything" without having the internals of my design, but I suspect you're doing something very similar in your PIC code - so perhaps it will make senseInterestingly enough (to me at least) the TRS32 emulator suffers from exactly the same symptoms I was seeing. (So I at least take solace in the fact I'm not the only one who missed it)

author: GK
author_rank: Super Contributor
timestamp: January 15, 2019, 07:19:48 am
content: Quote from: oPossum on January 13, 2019, 06:58:43 amThat's a nice resource, thanks. I looked up Dancing Demon on Youtube - that was probably some high-end computer animation back in the day!

author: GK
author_rank: Super Contributor
timestamp: January 15, 2019, 08:14:16 am
content: Quote from: kizmit99 on January 14, 2019, 06:21:45 pmCorrect. As currently breadboarded, aside from the shift key which is handled separately, two or more keys cannot be applied simultaneously. It didn't occur to me that this might be a desired or necessary feature; thanks for raising it. Minus the shift keys there are only 51 keys to encode, hence the six (1-of-64) key character-select lines to the LUT ROM only. One additional location needs to be reserved for an unasserted keyboard, but that leaves me 12 remaining addressable locations any/each of which can be programmed to assert any single key again or any possible combination of multiple keys. However the multiple-key combinations would have to be specifically recognized by the PIC. If there is, for example, some odd-ball program which requires you to press A and L together, such, with the current implementation, could be accommodated this way. I still have two ROM address lines currently unused, so I could theoretically increase the number of programmable special key-combinations to 204, but this might become tedious.Would NEWDOS/80 be unduly crippled without the ability to simultaneously assert keys?Alternatively a matrix array of individual AND gates (one for each key), with the outputs ORed in banks for each data output line, individually addressed by the PIC, would completely obliviate any hardware limitations to multiple key presses. However this is now a non-LUT solution fit for a small CPLD rather than an EPROM, which isn't what I had immediately at hand on the weekend when I decided to get some keyboard input happening. I think this is the approach that I am going to take now. Time to get Quartus installed onto my new PC.Quote from: kizmit99 on January 14, 2019, 06:21:45 pmYes, I just tried and my clone does respond this way. To be honest, this isn't something which would bother me personally, but is is easily rectified in firmware by delaying the release of shift as you describe.

author: PA0PBZ
author_rank: Super Contributor
timestamp: January 15, 2019, 08:48:33 am
content: Quote from: GK on January 15, 2019, 08:14:16 amThere are (from memory) 3 3-key commands:123 - debuggerDFG - mini-dosJKL - screen print

author: biff
author_rank: Contributor
timestamp: January 15, 2019, 12:04:35 pm
content: Quote from: GK on January 15, 2019, 08:14:16 amWhile NewDOS80 is the most obvious consumer of multiple simultaneous keypresses, it isn't the only one by far.I dimly recall Big 5 games allowing the game to be aborted by pressing "Break"+"Clear" - but it might have been "Shift"+"Clear" - which you probably handle.I do know that one of my all time favorite games "Armor Patrol" AKA "Tankzone 2000" a battlezone clone, requires pressing multiple keys together for movement.For example, "A"+";" to move forward, "Z" + "." to move backward and combinations of those to turn. (I may be misremembering the exact keys - but you get the idea). And of course, while doing those keyboard gyrations, you're also hitting SPACE to fire.And then in BASIC, there is the ability to press and hold the "Down Arrow" key and press another key such as "C" to generate a Ctrl-C and other control codes.And some terminal programs would use "@" as a command key - expecting you to press that along with another key for a function.

author: kizmit99
author_rank: Regular Contributor
timestamp: January 15, 2019, 11:30:02 pm
content: Quote from: GK on January 15, 2019, 08:14:16 amI would have thought the same thing, but I've discovered in the (what seems like) many thousands of times trying to boot LDOSthat when I type "1:00:00" to enter the time, I instead manage to get "1:;00:;"... Which, of course, isn't liked by LDOS and I get to try again at a slower, more precise pace... Hence my even being aware of the issue, and why I went ahead and dealt with it.Just another point about the ROM approach to the keyboard scan-array - I suspect you've got this covered already, but in case not... While the "normal" case was to assert only one of the address lines at a time when trying to determine "which" key was pressed, a lot of code would assert multiple (possibly all) address lines at the same time in order to determine whether "any" key was pressed in a single read-cycle. Your ROM approach should easily deal with that/those cases, but of course it depends on the ROM being programmed appropriately.

author: GK
author_rank: Super Contributor
timestamp: January 16, 2019, 06:59:02 am
content: Quote from: kizmit99 on January 15, 2019, 11:30:02 pmYep, my EPROM is programmed to handle this. In fact the keyboard interface wouldn't work at all if it wasn't. The TRS-80 doesn't periodically scan the entire keyboard. What it does initially is assert all of the address lines high and then checks the data bus for anything other than 0x00. If there is activity on the data bus (indicating a pressed key or keys) it then scans the full keyboard by sequentially asserting the address lines; otherwise it goes onto other things.My EPROM LUT hack could be expanded to handle simultaneous keys - for each additional key just add an another identically programmed EPROM in parallel. The data output lines of course would need to be paralleled by ORing and the six LS (key/character select) address lines independently controlled by the PIC.However a basic AND/OR matrix array (for the full 2^51 combinations) in a CPDL is my preference now. To simply the microcontroller interface I'll add a serial-in shift register for handling the single-bit status of all 51 keys.I cut my teeth on Altera (now Intel) MAX 7000 devices and they are still my default resort for 5V-tollerant glue logic. These parts are still going strong with a decent selection still in active production, but Microchip offers a family of device-compatible parts with claimed benefits :https://www.microchip.com/design-centers/programmable-logic/spld-cpldHas anyone here used these? Worth switching sides?

author: nick_d
author_rank: Regular Contributor
timestamp: January 16, 2019, 09:46:02 pm
content: I use the Atmel ATF1500 series CPLDs for retro projects because they are a 5V family that's still available, at least they were available on Digikey a year ago when I last bought them.On the other hand, this is for a Z180 processor that has ordinary CMOS inputs with 2.5V threshold, whereas I think the TRS-80 would be mostly using the TTL compatible parts such as the Z84C00 that has the 1.2V threshold, hence the 3.3V CPLD with 5V tolerant inputs would be fine. The only thing that's a bit of a pain about this is having to provide an extra 3.3V supply, another reason I prefer the ATF1500s.Nick

author: GK
author_rank: Super Contributor
timestamp: January 17, 2019, 01:07:00 pm
content: What software are you using? I've used up my monthly data quota and am stuck to dial-up-level internet speeds for several days still, so downloading anything and having a play is off the cards for the time being. However for VHDL synthesis and schematic entry I need a Mentor Graphics license and have to integrate with Protel/Altium respectively? GUPL? Pass, I think.

author: GK
author_rank: Super Contributor
timestamp: January 19, 2019, 11:20:34 am
content: This afternoon I got the data cassette interface built up and operational, so I can now save and load programs. Here is my first to be saved, at a blistering 250 bits per second:https://www.eevblog.com/forum/projects/cloning-a-tandy-trs-80-model-1/?action=dlattach;attach=627973I've attached a schematic of the cassette interface portion. Note that this is only a quickly devised prototype circuit using parts immediately at hand, and not the final design. Since there aren't any other I/O devices (floppy disk controller, printer, etc) besides the data cassette interface that are currently part of the system, I didn't even have to decode the address for the cassette port to make it work.I would like to load and run a famous commercial program for my first demonstration video, but at the moment I am stuck to running BASIC level 1 only. Although the computer is now running really stably in BASIC Level 1, it has decided to refuse to boot at all in BASIC level 2. I dunno exactly why, though I suspect that may have corrupted my ROM by accidentally disturbing the wire to the !WR pin while powered up (as this is only a prototype I am currently using a flash ROM rather than an OTP one). The ROM is a 32kb AT28C256. I have BASIC Level 1 occupying the first 4kb of the lower 16kb page and BASIC Level II occupying the first 12kb of the upper 16kb page. The ROM is really buried beneath wires and I'm not sure I want to risk getting it outAll of the programs that I've downloaded from the net so far have turned out to be 500 baud, BASIC Level II only, annoyingly.Oops, the polarity of the signal at the output of the rectifier is drawn opposite of actual.

author: GK
author_rank: Super Contributor
timestamp: January 19, 2019, 02:00:45 pm
content: Okay........ finally found a 250 baud Level 1 game with fast moving screen graphics. This is the first piece of commercial software loaded and run by my prototype. Unfortunately this one doesn't have any sound effects though. I'd really like some zaps, beeps and buzzes in my first Youtube video. Does anyone have a game-with-sound suggestion?

author: kizmit99
author_rank: Regular Contributor
timestamp: January 19, 2019, 03:33:37 pm
content: Looking greatA couple of good audio games are Defense Command (Space Invaders clone) and Robot Attack (Robotron clone). I believe both generate 'speech' via the incredibly rudimentary cassout signal... Both are cmd files though, and as far as I know are only available for level-2.I know (from your Pet clone) that you're comfortable doing the cassette input signal conditioning all in analog (like the original), but I have found that taking the crappy input signal and using a one-shot to turn it into a digital signal as soon as practical makes for a much more forgiving (and therefor more pleasant) CLOAD experience. I had done this with my original back in the day, so I consider it a period-correct upgradeWhat are your plans for the cassette motor? The original used an relay to switch the motor power (provided by the cassette desk) on the aux-input. Since this would only work with the specially modified TRS80 cassette decks, I decided to just drop the motor on feature altogether...EDIT---A few more random thoughts on the cassette - just thrown out as things you may wish to consider...* Connectors? I decided to ditch the original DIN-6 as they were so proprietary and I don't plan on using a real TRS80 cassette deck (those are reserved for the real TRS80 machines!). But even if I wanted to use a real deck, making up new cables to connect it shouldn't be a problem. So I devolved the cassette connectors to two mini-audio jacks - one for input, one for out. It makes for an easy hookup to the digital voice recorder I'm using as the substitute cassette deck.*Audio Out? I like hearing the primitive audio from the early games, but I don't like hearing the data loading or using the cassette deck as the audio amp. So I've decided to add a separate audio amp driving a separate audio-out jack to feed a small speaker directly. I may use the motorOn control from the cpu to disable this output when loading/saving data. Probably would have an option for leaving it on to help debug CLOAD/CSAVE issues.*Audio quality - I tried using the cassout signal to drive a piezo speaker... bad idea, doesn't sound anything like the same signal driving a small "standard" speaker.

author: GK
author_rank: Super Contributor
timestamp: January 20, 2019, 01:04:35 am
content: ThanksI'm not overly enamored with the cassette analogue circuitry as it is currently implemented. One thing I definitely won't be modifying though is the input signal conditioning (2-pole high/low-pass filtering). My lab PC for example makes for a lousy audio source with gobs of HF rubbish superimposed. Then there are ground loops/main hum and other potential sources of HF interference too, especially when the signal source is on the other side of the lab connected via a 5m cable.One thing with the TRS-80 cassette interface that will never match the performance that I managed to design into my 8-bit Commodore one, is the tolerance for a large dynamic range of signal input level. The PET uses essentially a continuous FSK squarewave. All you have to do to clean this signal up is amplify and limit it. The TRS-80 though uses a pulsed, return-to-zero signal. Amplify this signal excessively and all you do is raise the noise floor and narrow the detection window. One saving grace of the TRS-80 system though as opposed to that of the PET is that it isn't signal-polarity sensitive.For the audio side of thing I'm going to do pretty much what I did with the PET clone (internal speaker and an LM386). Personally, I find it useful as a diagnostic aid to be able to listen in if required to either the cassette out or in signal. I was just going to have three positions to my audio source select switch - Off, CASS in and CASS out, but I like your idea of using the motor control signal to mute the audio, so perhaps a fourth position called "CASS out auto mute" or something.

author: GK
author_rank: Super Contributor
timestamp: January 20, 2019, 03:12:12 am
content: Oh, is there anyone out there who can tell me how to enable the "low resolution" 32 column display mode? I can't find any Level 1 info on this anywhere. Is it even possible in BASIC Level 1? This is an I/O operation and you have to toggle data bit 3 at address FF.

author: biff
author_rank: Contributor
timestamp: January 20, 2019, 03:31:55 am
content: Quote from: GK on January 20, 2019, 03:12:12 amI believe this is strictly a Level II feature.

author: MustardMan
author_rank: Contributor
timestamp: January 20, 2019, 09:27:29 am
content: I love your work! And you've made significant progress in such a short time - no got kids one assumes!Anyway, reading about the 'expanded' memory that you intend to put on this PCB and the likely conflict with a genuine EI (if connected)... would it not be better rather than modifying the EI that you put a jumper on your PCB to restrict it to 16K? Then the EI can work without any changes, and it increases the ability for your board to be a true hardware clone...Reading the discussion about the keyboard... that is a tough one. It could be that a CPLD/FPGA might be the only way to create a 100% true 'clone' - turning a PS2 keyboard into a close-as-can-be memory mapped one.A project that intended something similar is on Hackaday.io, but it stalled and never seemed to progress. Shame. It might be interesting (or it might not) :https://hackaday.io/project/5565-trs-80-compatible-cloneI for one will be wanting to buy one of your PCBs! Any thoughts on creating a BOM, or if you'll do a kit of parts?MM.

author: GK
author_rank: Super Contributor
timestamp: January 21, 2019, 11:36:16 am
content: Quote from: biff on January 20, 2019, 03:31:55 amOK, thanks, I thought so. You'd still be able to toggle low res mode in machine code though I'm sure, but I'm not that adept a TRS-80 user/programmer just yet.

author: GK
author_rank: Super Contributor
timestamp: January 21, 2019, 11:47:57 am
content: Quote from: MustardMan on January 20, 2019, 09:27:29 amThanks for the interestI probably will be making the RAM size switchable between 16k and 48k because it appears that BASIC Level 1 doesn't properly recognize more than 16k, or at least doesn't accurately test it. For example I have my EPROM LUT address decoder coded to address either 16, 32 or 48k of RAM. I currently have a 256kbit (32kbyte) SRAM chip wired in. When I rewire the address decoder from 16k to 32k and type "PRINT MEM" to report on the free memory the computer responds with "-16897", which is actually (ignoring the negative sign) 32kbytes minus the actual free RAM in 16kbyte mode (512 bytes are reserved for BASIC).I won't be proving any kind of kit but intend to complete and publish the design to the same extent as the PET-2001 clone.

author: GK
author_rank: Super Contributor
timestamp: January 21, 2019, 12:19:46 pm
content: Well, here is a video. Powering on, checking the free memory and then loading Radio Shack Flying Saucers via the cassette interface from my crappy Digitech digital audio recorder. Quite possibly the very first TRS-80 ever up and running on breadboardhttp://youtu.be/dClOHNcpnVw

author: MustardMan
author_rank: Contributor
timestamp: January 22, 2019, 05:48:40 am
content: That is certainly one hella rats nest you have there!I do have one level 1 cassette in my collection (a real one from Tandy!). Chess. According to "WAV2CAS" it has decodable Level 1 content on the tape. A couple of recognised SYSTEM files (with a valid checksum), and some other stuff that appears OK with recognisable ASCII in it, but WAV2CAS says it is bad. I never played/ran it because I had a L2 machine, and the L2 version was on the reverse side of the tape. I can send you a WAV (or compressed in some format), but as far as I know the game has no sound - which is one of the things you wanted. I could send a CAS, but that would be assuming that WAV2CAS got the decode right, and from my experience, that is not always the case.Edit: By the way, what sort of keyboard interface did you decide to go with?

author: GK
author_rank: Super Contributor
timestamp: January 23, 2019, 12:19:15 pm
content: Oh that's OK, I just went ahead and did the video without sound effects so it doesn't matter anymore. The next video will be of the completed machine running Level II Basic and probably some derivative of Space Invaders....to continue with the theme started with my PET clone. I have a *.cas file of "Micro-Chess" for 250 baud, which might be the same Chess game you've got (from here:http://www.classiccmp.org/cpmarchives/trs80/mirrors/pilot.ucdavis.edu/davidk/trs80/software/cassette.htm). I still have the PIC+EPROM on the breadboard for interfacing the keyboard. I've designed the proper interface with an MAX 7000 CPLD.

author: GK
author_rank: Super Contributor
timestamp: January 24, 2019, 12:21:23 pm
content: I've had a cool idea for another home brew computer peripheral - a PS/2 interface/converter for a standard Atari joystick port. I'm thinking a PIC micro interfaced to a bunch of buttons and a standard 2x16 LCD display for the user interface.With the Atari port you have 5 discrete switch/sense inputs:1) Fire2) Up3) Down4) left5) Right.....plus four additional states (combinations):6) up+right7) down+right8) down+left9) up+leftMy idea is that you can scroll through these nine switch states and assign to each any possible PS/2 key character make/break code to be sent when true/false. A complete set can then be saved as a unique preset (with an x-digit name that you can enter for easy identification later). Lets say I choose a PIC micro with enough internal EEPROM memory to store 100 "presets". Maybe (actually definitely) add auto-repeat as a selectable enabled/disabled option for each state with a programmable repetition rate.Now you can play all of your retro 8-bit keyboard games with a joystick, provided that you have already upgraded your vintage machine or clone with a PS/2 keyboard interface. Such a device might also appeal to enthusiasts of vintage PCs which use the PS/2 protocol natively. Maybe add AT functionality as well?The thing could be built into a not very large box with PS/2 in/out through ports and perhaps even auto-switching so that you can just plug everything in and not have to swap out your keyboard every time you want to use the joystick.Thoughts?

author: kizmit99
author_rank: Regular Contributor
timestamp: January 25, 2019, 10:34:01 pm
content: I think it's an interesting idea... certainly (on the surface) seems like a doable approach.I would think you'd pretty-much *have* to be able to use both the keyboard and the joystick at the same time though. Otherwise I suspect most games wouldn't be playable. I know I die quick enough that I'm having to choose "one or two player mode" quite often(and that usually involves typing keyboard keys). Others may have issues when it's time for them to enter their initials for the high-score page...I know for the PS/2 keyboards I've looked at closely, neither of them required any kind of setup from the host to get them talking, but I feel like I've read somewhere that some doWith that, using the PIC to merge the two PS/2 streams shouldn't be difficult.To be honest though - while an interesting exercise I probably wouldn't use one. Part of the 'thrill' of the retro machines is their sometimes awkward primitiveness...Just my thoughts...

author: GK
author_rank: Super Contributor
timestamp: January 26, 2019, 08:21:01 am
content: Quote from: kizmit99 on January 25, 2019, 10:34:01 pmThat will be easy enough to implement.QuoteWell, I for one dislike playing any kind of game on the keyboard, except perhaps for a text adventure. Another issue I have run up against, with some of my PET games is that the keys used aren't always in convenient or even even usable locations on the PS/2 format.I'm going to build this interface, but with two Atari-standard joystick ports (with Genesis/MegaDrive controller compatibility) to support two player games.

author: GK
author_rank: Super Contributor
timestamp: January 26, 2019, 08:42:39 am
content: Well I figured out why BASIC Level II wasn't booting. I probed the address decoder to see what was up and noticed that the CPU was stuck in a loop, doing nothing aside from continuously polling the keyboard at ~1 second intervals with address line A6 asserted only. Keys tied to A6 are "Enter", "Clear", "Break", the four cursor keys and "Space". As it therefore appeared as though the CPU was waiting for input in the from of one of these keys being pressed, I started to hit them in sequence...... bingo - holding down (as it is only polled every ~second) the break key boots the system and "MEMORY SIZE" pops up on the screen. Each subsequent press of the break key causes "MEMORY SIZE" to be printed again on a new line.This isn't mentioned in the manual I have. Anyone know what is going on here? It's as though (guessing that) the computer is initially trying to boot from an external device, until you "break" out of it. There might be some aspect of my incomplete hardware that is causing it to initially boot this way?As an aside, I can now load and run 500 baud software and have access to the full 48k of RAM (yippee):

author: GK
author_rank: Super Contributor
timestamp: January 26, 2019, 09:00:20 am
content: OK, I googled and found a hint:"With an Expansion Interface connected, but without boot disk, the Model 1 will not start and show a screen of garbage chararacters. If BREAK is pressed during power up or reset the MEMORY SIZE? message is displayed. The reset button is at the left back side, next to the expansion connector. "https://fjkraan.home.xs4all.nl/comp/trs80/basicDescription.htmlSo for some reason my breadboard machine when running Level II BASIC seems to think it has an expansion interface plugged in and is initially looking for a "boot disk"..........

author: biff
author_rank: Contributor
timestamp: January 26, 2019, 01:47:57 pm
content: Quote from: GK on January 26, 2019, 09:00:20 amThe ROM attempts to determine the presence of the Expansion Interface by querying the FDC status register at memory location 37EC. What does your implementation return when that location is queried?Without an EI connected, that memory location doesn't decode - so the Z80 normally just sees 0 and ROM uses that as a flag to indicate there is no EI and skips the routine where it would attempt to read the boot sector of drive 0.I'm betting your implementation is returning something else there.Holding down the Break key at startup bypasses the 37EC check, so you always end up in Level II with or w/out an EI.Just to be clear, w/out an EI - there is no need to hold down the Break key to enter Level II.For a really good illustration of this boot procedure, download the George Phillips emulator here:http://48k.ca/trs80gp.htmlIt runs under Windows - but works great under Linux or MacOS via Wine.Start it via:trs80gp.exe -m1 -dx -b 068BAnd that will set a break point right in area of ROM where it performs the check - and shows a nice disassembly of what it is doing.(The -dx tells the emulator to not emulate an expansion interface - so the FDC detection check will fail)

author: GK
author_rank: Super Contributor
timestamp: January 26, 2019, 03:30:33 pm
content: Quote from: biff on January 26, 2019, 01:47:57 pmMy address decoder doesn't select anything in that location, which is located almost at the very top of an "unused" two kilobyte block located directly above the level II ROM space.If that address is read the Z80 will just be reading random bytes (not necessarily - in fact highly unlikely - zero) as all of the data bus lines will be floating.Just a random brain fart / stab in the dark here - I wonder if the memory devices used in the original TRS-80, paralleled up on the data bus, still weakly pulled down their data I/O pins when de-selected?

author: kizmit99
author_rank: Regular Contributor
timestamp: January 26, 2019, 03:46:38 pm
content: I'm pretty sure the boot code will treat either 0x00 or 0xFF (on a read of the FDC Status register) as no FDC present.The original chips used in the design would pretty consistently read a floating databus as all ones.Your CMOS chips likely aren't quite as predictable.

author: GK
author_rank: Super Contributor
timestamp: January 26, 2019, 03:48:36 pm
content: Quote from: GK on January 26, 2019, 03:30:33 pmBINGO!I just bunged a 4k7 pull-down resistor on each line of the data bus and voila! Boots without BREAK every time!

author: GK
author_rank: Super Contributor
timestamp: January 26, 2019, 03:51:51 pm
content: Quote from: kizmit99 on January 26, 2019, 03:46:38 pmWell, I can confirm 0x00

author: kizmit99
author_rank: Regular Contributor
timestamp: January 26, 2019, 03:59:58 pm
content: I'm using 0xff and that also works... Plus, I was walking through the boot code several weeks back, and remember that code, as it was reading the register, then adding 1, then comparing to 2. Seemed like an odd thing to do until I realized 0xff was -1, so +1 and now your checking for 0 or 1 (instead of -1 and 0). Just an odd bit of hoops to reduce the code size (typical assembly level trickery)...

author: GK
author_rank: Super Contributor
timestamp: January 27, 2019, 12:06:10 am
content: I think passively pulling up to 0xFF will be the preferable way to go in the final design, simply to minimize loading on the bus. For example the 74LS367 line drivers used in the original expansion unit could sink 24mA, but only source 2.4mA while complying with TTL threshold levels.

author: MustardMan
author_rank: Contributor
timestamp: January 27, 2019, 09:43:56 pm
content: Bit late on the "hanging while booting Level II" (already solved), but something that may be interesting...The book "The Custom TRS-80 and Other Mysteries" (1982 - Dennis Bathory Kitsz) on page 26 talks about the "hanging" and why (including disassembed code). Page 22 also mentions the "jumpers" that select level I or II. The book is a fairly good read, and I would havelovedto have known of it back in the day. Ahhh, the world without internet!I think it was the 'hackaday' project (??) that talked about the differences in how different chips (eg: LS, C, HCT etc) let their outputs idle. Some high, some low. Hence, using a modern replacement that has an almost identical part number can lead to some rather unexpected problems (eg: replacing a 2764 ROM with a 27C64 ROM).MM.

author: nick_d
author_rank: Regular Contributor
timestamp: January 29, 2019, 06:03:19 am
content: I believe that TTL and LS-TTL inputs do not "float" as such but act as if pulled up, unless explicitly pulled down by a device on the bus. This is probably a point of incompatibility which would make the Z84C00 (CMOS Z80) not an exact drop in replacement for the Z8400 (NMOS Z80), despite that the input thresholds of the CMOS part have been set to approx 1.2V for NMOS compatibility (that is, the external interface is constructed with 74HCT-like gates).cheers, Nick

author: GK
author_rank: Super Contributor
timestamp: February 03, 2019, 05:00:00 am
content: Yes of course, in the original TRS-80 the data I/O pins of the Z80 were buffered to the data bus by a pair of 'LS244s, which will always read 0xFF when the bus is floating.Good tip on "The Custom TRS-80 and Other Mysteries"! Complete PDF of the book available here:https://archive.org/details/Custom_TRS-80_and_Other_Mysteries_1982_Dennis_Bathory_Kitsz_aBTW, can anyone out there elaborate upon what the lower-case modification incompatibility is supposed to be with Level II BASIC? :Quote

author: jeffheath
author_rank: Regular Contributor
timestamp: February 03, 2019, 11:10:48 pm
content: Just found out you actually have the gerber files and schematics uploaded for the commodore pet... looks like I've got something to keep me busy for a looong timeCan't wait to see how this one turns out!

author: kizmit99
author_rank: Regular Contributor
timestamp: February 03, 2019, 11:29:07 pm
content: Quote from: GK on February 03, 2019, 05:00:00 amPlease note - the following is from very old memories, not from taking a look at the schema/ROMS... I *could* be miss-remembering this, but I think it's basically correct:I didn't do the Electric Pencil mod, but I *think* the issue was actually with the font ROM having "giberish" in the first 32 positions. I believe BASIC actually stores values of 0 through 32 for the alphabet, and relies on the original "missing bit" circuitry to "push" those characters up into positions 64 through 96 in the font ROM. When the font ROM has the alphabet in positions 0 through 32, this alleviates that issue (which is why you don't see it).

author: nick_d
author_rank: Regular Contributor
timestamp: February 06, 2019, 04:25:51 am
content: Is it Microsoft BASIC? There is a disassembled source code around for NASCOM Z80 BASIC, probably a similar version to what was used in the TRS-80 (single precision only, lacks commands such as RENUM). It would be relatively straightforward to compare this with Level II BASIC and disassemble only the missing parts. Then patch it for lower case. Some day I plan to disassemble the the most modern CP/M version like this, since the extra is not all that much.cheers, Nick

author: kizmit99
author_rank: Regular Contributor
timestamp: February 06, 2019, 04:30:00 am
content: Yep, TRS80 Basic was licensed from Microsoft... Seem to recall some BS story about Bill G. writing it over one weekend or some crap like that...

author: oPossum
author_rank: Super Contributor
timestamp: February 06, 2019, 04:44:33 am
content: I think it was the first version of the Altair 8800 BASIC that was written in a short amount of time and tested on an emulator running on some model of DEC PDP.

author: netdudeuk
author_rank: Frequent Contributor
timestamp: February 06, 2019, 10:32:58 am
content: Quote from: oPossum on February 06, 2019, 04:44:33 amAt least this is true. They created a punched tape which Bill took to demo.

author: BartH
author_rank: Newbie
timestamp: February 08, 2019, 03:28:04 pm
content: Quote from: nick_d on February 06, 2019, 04:25:51 amNo need for disassembling the ROM, this has already been done. The Model 1 did have lower case in its character ROM but was not able to display it, due to the 6 bit memory. When the need for Word Processing came (the next big thing in 1979 or so) Tandy came up with a lower case kit. It included the memory chip, a new character ROM and a cassette with a driver. As disk drives became cheaper and DOS'ses more common the drivers became part of the operating system.So for reasons of compatibility with old software I would suggest to focus on adding (emulated) hard drives like the FreHD and using LDOS or NewDos/80 for lowercase drivers. The autoboot Model 1 rom's are also readily available (back in the day you booted initially from floppy before loading a HD-driver).If you really want to use the Model 1 with lowercase and no floppy or HD you should change 1 byte in ROM: address 0x0473h contains 0x38h (JR,C) and should be changed to 0x18h (JR). This mod bypasses some code that essentially changes lower case back to upper case.BTW later Model 1's contained the character rom in a socket so it didn't need desoldering when updating with the RS Lowercase kit. The later 'Japanese' Model 1's already contained the missing 7th bit and had a better character ROM. You still needed a driver or DOS to display the lower case characters.Bart

author: nick_d
author_rank: Regular Contributor
timestamp: February 09, 2019, 06:18:15 am
content: That's good to hear (about the lowercase support being much improved in later versions of the system). And, also, yes the disassembly has already been done, even if it isn't needed for this purpose. I was looking into it the other day and I discovered the book "Microsoft BASIC decoded and other mysteries" which I think you are referring to. Since Level II BASIC includes the double precision (though incomplete as cut down to fit in 12K) and other goodies, I think this disassembly may be a useful supplement to the NASCOM 8K BASIC disassembly for my purpose of analyzing the extended CP/M BASIC.cheers, Nick

author: b1ackmai1er
author_rank: Newbie
timestamp: March 10, 2019, 05:27:30 am
content: Hi GK,I came across your TRS-80 Model I development post in my search for a graphics font. Impressive work indeed.I was wondering if you would be able to share a copy of the graphics character "rom". I saw you posted a hex file of the standard character set but you advised that the graphics character set is "generated". Would you still be able to do a dump of this character set and share it? Alternatively, if thise is generated by Z80 code, would you mind sharing the code?I have found heaps of trs-80 font resources on the net but they are all font conversions to ttf or similiar. It's seems nearly impossible to get these back to a bit map rom.Thanks for your time.I'm chasing these to add a graphics character set for 128 to 256 character modification:https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:vdu:starthttps://www.retrobrewcomputers.org/doku.php?id=boards:ecb:vdu:fontsRegards Phillip

author: rambobrite
author_rank: Newbie
timestamp: March 23, 2019, 12:20:50 am
content: Regarding sound - the Model I was notorious for spewing RF interference.If memory serves, Softside magazine had a program that would play "Don't it Make My Brown Eyes Blue" through for-next loops and the like. Just placing a radio near the computer would pick up the noise. (I won a free game from my Radio Shack on a bet, the manager being certain the Model I couldn't make sound.)Some early games leveraged this "capability", until sound generation through the audio jack became a thing. I'll see if I can track any down.

author: DDunfield
author_rank: Regular Contributor
timestamp: March 23, 2019, 12:46:18 am
content: Hey.. just noticed this thread. Good job on the TRS-80 M1 clone!I've got a couple homebuilt TRS-80 Model IIIs on S-100 cards in my collection, I didn't build them, they were donated by the guy who built them.http://www.classiccmp.org/dunfield/t80s/index.htmDave

author: Rick-S
author_rank: Newbie
timestamp: April 02, 2019, 11:50:27 am
content: GK, This is an amazing project. I'm in awe of your reverse engineering skills. I can't wait until you get it complete to see the final outcome.

author: Rick-S
author_rank: Newbie
timestamp: May 21, 2019, 06:00:58 pm
content: GK,Any updates on this project or did it get put on the back burner for now? I'm just curious.

author: GK
author_rank: Super Contributor
timestamp: June 10, 2019, 12:35:06 am
content: Sorry for the lack of updates - I've just been too busy with too many other things or not particularly motivated & only just got back onto the electronics bench again the other day. I have the breadboard prototype disassembled now and a couple of boards are out for production. Maybe some proper progress again in a week or two.Quote from: b1ackmai1er on March 10, 2019, 05:27:30 amNot sure if you're still tuning in, or if the file is really of much use to you, but attached is the graphics character section of the character ROM binary file, as described way back in reply #15. It's a .bin file but I had to relabel it .txt so that the forum would let me upload it.

author: Rick-S
author_rank: Newbie
timestamp: June 10, 2019, 05:39:00 pm
content: Quote from: GK on June 10, 2019, 12:35:06 amNo problem, I fully understand how interest shifts from one thing to another. Will you make the boards or board files available once you have them proven out? Thank you for the update, and looking forward to seeing your production boards up and running.

author: GK
author_rank: Super Contributor
timestamp: June 11, 2019, 12:38:31 pm
content: The intent is to publish the project and all of the Gerber files, ROM images, etc, on my website as I did with my PET2001 clone. That alone is for the most part a thankless enough endeavor and I'm not going to be supplying actual boards or any form of kit.

author: Rick-S
author_rank: Newbie
timestamp: June 11, 2019, 04:53:27 pm
content: That is great. I am excited to know you will make the files available. Thank you so much for all your endeavors to promote this hobby and to revive these old machines with a modern build.

author: GK
author_rank: Super Contributor
timestamp: June 30, 2019, 02:56:49 am
content: I've made a start on the video generator board. The rest of the parts required are scheduled to arrive tomorrow. Now that I have the board in front of me it's apparent that the ground plane cross hatching would have needed to be a few times coarser to give the board that kind of vague retro feel that I was seeking.The two 90 degree potentiometers on the left hand side of the board are the vertical and horizontal raster positioning controls. Annoying, although limited stock is still available, the pot model I selected has since gone obsolete. I'll have to modify the layout for new pots before providing the Gerber files.

author: GK
author_rank: Super Contributor
timestamp: June 30, 2019, 03:14:04 am
content: Here is the completed CPLD matrix decoder logic for the PS/2 keyboard interface. Did it in the graphical entry method instead of AHDL just for kicks. I have both Quartus II and the old Baseline 10.2 software (as shown), but for simple CPLD logic design and simulation I much prefer to still use the latter - it's just so much nicer to use than the bloated Quartus suite with all of its stupid million warning messages on every compile for a whole host of crap I don't need and am not interest in, the comparatively crappy pin assignment editor, etc, etc.Anyway, the whole thing *just* fits into 64 macro cells, so I can put it into a relatively small and budget part; namely an EPM7064AETC44.https://au.mouser.com/ProductDetail/Intel-Altera/EPM7064AETC44-10N?qs=sGAEpiMZZMuJNuO2s1hGZPESq8W5eU3HqWG75xdVK0Q%3DStepping over to the dark side here as this is a 2.5V - 3.3V part, but the options are limited here because the old 5V variants of these CPLDs are rapidly becoming unobtainable now. Fortunately EPM7064AE inputs are always 5V tolerant, regardless of the core and VCCIO supply voltage and the output levels are TTL-compatible on a 3V3 VCCIO.Each of the 52 bits of the shift register represents the status of one keyboard key, so this completely solves the problem of supporting multiple simultaneous key presses, as discussed earlier in the thread. There are logically only 52 out of the 53 actual keys because two of those 53 are the left and right shift keys, which were just wired in parallel and not differentiated. The serial data output pin is provided as a diagnostic aid only.

author: kizmit99
author_rank: Regular Contributor
timestamp: June 30, 2019, 04:03:23 pm
content: It makes me happy to see you back on thisUnless I'm missing something, isn't your keyboard decoder going to suffer from a storm of glitches as the PIC changes the keys pressed?I think you need another set of registers (following the shift-register outputs) that will present the new keyboard state to the decoder array as one atomic change.Question for you -- have you tried generating a <shift>+@ with your keyboard design? I've discovered that I have an issue with that style of key combination and I'm curious whether yours has the same problem.The basic issue is when I try to type a shifted version of a key that on the original keyboard was not shifted, but on the PS/2 keyboard is shifted.The "@" key on the original keyboard was its own key, on the PS/2 keyboard you have to type <shift>-2 to get "@" (so the shift key is overridden back to off in this case), but on the original keyboard I could type <SHIFT>+@ and both keys are asserted. With my approach (and I suspect yours) it becomes an unachievable combination.I was considering implementing something along the lines of: If BOTH shift keys are held down this is an indication that <SHIFT> should be asserted even if the key-mapping indicates it should be overridden to not-asserted (but continue to assert the key that the mapping otherwise expressed). I haven't tried this approach yet, and I'm not sure it would be very intuitive even if I did implement it. I'm hoping a simpler cleaner approach surfaces eventually...

author: GK
author_rank: Super Contributor
timestamp: July 01, 2019, 11:24:45 am
content: Quote from: kizmit99 on June 30, 2019, 04:03:23 pmIt's nice to see that someone is paying attention to the finer details :)The current scheme is to quickly load the shift register after being triggered by the rising edge of !KEYBOARD, before the next polling interval, so to avoid any shift register activity while the keyboard is being scanned. If I could fit an additional 52 DFFs into the CPLD I'd much prefer to do it that way, but a barely have enough room for even a few more basic gates.I can't remember the finer details off the top of my head right now, but I'm pretty sure my keyboard interface code can handle the situation you describe. In my PET clone both shift and the key mapped to @ have to be asserted simultaneously to give one of the graphics characters.The video generator is now up and running - just giving a random garble of screen characters from the random RAM contents at the moment as there is no processing system connected. The next step is to get back to the breadboard with a Z80 plugged into it and have the system back up and running again, but with much, much less rats nest and, hopefully, rock-solid stability. I still want to do a little more circuit design verification/testing with something more manageable before committing to the final motherboard PCB layout.

author: wilfred
author_rank: Super Contributor
timestamp: July 01, 2019, 12:35:52 pm
content: If you use a cpld that's fine. But it will limit access to people who want to go to the effort of programming them. An Arduino would be accessible to more people.Still an interesting project.

author: kizmit99
author_rank: Regular Contributor
timestamp: July 01, 2019, 02:50:27 pm
content: Quote from: GK on July 01, 2019, 11:24:45 amAh - tricky... I assume you've done the calcs to verify the PIC (I think that's what you were using for the PS/2 interface) can detect the rising edge and perform the 52 shifts before the Z80 can get back around to checking the keyboard again? That just seems like it would require a lot of cycles, and I've found that the Z80 (even at 1MHz) can execute quite a few instructions in the time it takes a small microcontroller to respond to an interrupt and start bit-banging.Quote from: GK on July 01, 2019, 11:24:45 amOnce you get this all hooked up again, I'd really appreciate if you would take a quick look. Thanks in advance!

author: GK
author_rank: Super Contributor
timestamp: July 03, 2019, 12:57:45 pm
content: Quote from: kizmit99 on July 01, 2019, 02:50:27 pmYes, that is true, but there is heaps of time between keyboard polls, so it isn't an issue. Anyway, there is another alternative that will (should) fit into the CPLD. I can delete the entire shift register and replace it with a parallel-input register/latch. I have enough I/O pins left over to delete the serial interface and replace it with an 8-bit, addressable interface for programming. Not as elegant as a simple serial uC interface, but it does away with having to monitor & sync to !KEYBOARD. I'm busy with the breadboard right now, but I think I'll give this a whirl after.

author: GK
author_rank: Super Contributor
timestamp: July 04, 2019, 12:51:31 pm
content: Just, finally, plugged in the last wire not more than 20 minutes ago. Double checked, crossed fingers, plugged in power lead................... So satisfying to see the screen go blank momentarily and the READY prompt appear.Running bare bones ATM with no I/O, apart from the video display. Next up is get my prototype keyboard interface soldered up on perfboard. I have a bunch of old 5V EPM7064 CPLDs here in the 44 pin PLCC package, which are easy to prototype-build with. It's bedtime again now though.

author: GK
author_rank: Super Contributor
timestamp: July 04, 2019, 02:20:08 pm
content: The video board schematic.

author: GK
author_rank: Super Contributor
timestamp: July 06, 2019, 08:11:21 am
content: Quote from: GK on July 03, 2019, 12:57:45 pmOkay, I managed to get the parallel register version to fit into 64 macro cells, but, again, only just and the uC programming interface is a little more primitive as I couldn't fit in any address decoding. The 52-bit "key status" register is programmed in 8-bit chunks (from inputs D[7..0]) with individual strobe/latch input pins (STROBE[6..0]) for each chunk. That gives a 15-line uC interface for programming. A 3-to-7 line decoder for strobe addressing just takes up too much additional logic.In AHDL this time:Code:TITLE"Keyboard matrix decoder";%Tandy TRS-80 Model 1%SUBDESIGN MATRIX(D[7..0]: INPUT;-- Key status register data inputsSTROBE[6..0]: INPUT;-- Key status register latch control inputsADDRESS[7..0]: INPUT;-- Address bus inputsDATA[7..0]: OUTPUT; -- Data bus outputsKEYBOARD: INPUT;-- Output enable for data bus outputs (active low; Hi-Z when high))VARIABLEKEY[51..0]: LATCH;-- 52-bit key-status registerQ[7..0]: NODE;-- Working node for data bus outputsTRIBUS[7..0]: TRI_STATE_NODE;-- Tri-state node for data bus outputsBEGIN% Connect tri-state data bus outputs to !KEYBOARD %TRIBUS=TRI(Q, !KEYBOARD);TRIBUS=TRI(Q, !KEYBOARD);TRIBUS=TRI(Q, !KEYBOARD);TRIBUS=TRI(Q, !KEYBOARD);TRIBUS=TRI(Q, !KEYBOARD);TRIBUS=TRI(Q, !KEYBOARD);TRIBUS=TRI(Q, !KEYBOARD);TRIBUS=TRI(Q, !KEYBOARD);DATA[7..0]=TRIBUS[7..0];% Key matrix %Q=ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY;Q=ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY;Q=ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY;Q=ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY# ADDRESS & KEY # ADDRESS & KEY;Q=ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY;Q=ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY #ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY;Q=ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY;Q=ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY # ADDRESS & KEY# ADDRESS & KEY # ADDRESS & KEY;% 52-bit key status latch strobe and data input connections %KEY[7..0].D= D[7..0];KEY[7..0].ENA= STROBE;KEY[15..8].D= D[7..0];KEY[15..8].ENA= STROBE;KEY[23..16].D= D[7..0];KEY[23..16].ENA= STROBE;KEY[31..24].D= D[7..0];KEY[31..24].ENA= STROBE;KEY[39..32].D= D[7..0];KEY[39..32].ENA= STROBE;KEY[47..40].D= D[7..0];KEY[47..40].ENA= STROBE;KEY[51..48].D= D[3..0];KEY[51..48].ENA= STROBE;END;

author: kizmit99
author_rank: Regular Contributor
timestamp: July 06, 2019, 11:20:01 pm
content: Parallel loading of the state registers should prevent you from getting spurious key-presses at the Z80 side, even if you happen to change just as the Z80 is scanning, since from it's perspective it would just be the same as the person typing (which is obviously async to the scanning).To me, it seems an almost perfect interface from the PIC would be 6 'address' lines, a single state line, then a strobe to load the state of a single register at a time. It would only be 8 lines, and in most cases the PIC would only need to modify a single key-state bit at a time anyway (sometimes 2 or 3, but mostly just one key going up or down). I'm not familiar with your CPLD, but since you couldn't fit an extra 3:8 decoder into it, I suspect it would support the ability to individually address each state-bit either (effectively a 128bit LUT in front of each register).

author: GK
author_rank: Super Contributor
timestamp: July 07, 2019, 01:55:56 am
content: Quote from: kizmit99 on July 06, 2019, 11:20:01 pmNot even close unfortunately. The 3-7 line decode alone bumped the compile from 64 macro cells to 69. These CPLDs are just really inefficient at LUTs. Anyway, the design is now complete and I think I'm happy with it. Like I did with my PET clone, I've designed the keyboard interface as a stand-alone PCB which could interface a PS/2 keyboard to any TRS-80 model 1, not just my clone and the motherboard itself will be compatible with an original keyboard (not that I have an original keyboard).The fitter didn't give me the luxury of assigning my own pinout to a useful degree due to the fact that the whole thing is such a tight fit, so the CPLD "wiring" is a bit of a jumbled mess with a more or less random pin assignment. Who said you cant have power planes with just 2 layers?

author: German_EE
author_rank: Super Contributor
timestamp: July 07, 2019, 08:41:11 am
content: I guess that this will be a US layout PS2 to Tandy interface?

author: GK
author_rank: Super Contributor
timestamp: July 08, 2019, 11:46:12 am
content: Quote from: German_EE on July 07, 2019, 08:41:11 amI don't think that it should make any difference as far as the PS/2 serial protocol is concerned

author: German_EE
author_rank: Super Contributor
timestamp: July 08, 2019, 04:04:25 pm
content: Well, just as an example, shift-9 produces a ) and shift-3 gets me a § on my German keyboard but on the International US layout shift-9 produces ( and shift-3 is #.This could get confusing.

author: GK
author_rank: Super Contributor
timestamp: July 09, 2019, 12:18:54 pm
content: Quote from: German_EE on July 08, 2019, 04:04:25 pmAFAIK the make and break codes sent by the keyboard are standardized to the characters, not the character positions on the keys.

author: GK
author_rank: Super Contributor
timestamp: July 21, 2019, 01:19:42 pm
content: Phew! One marathon weekend session and the motherboard is done (pending checking/tweaking).

author: GK
author_rank: Super Contributor
timestamp: July 21, 2019, 02:30:41 pm
content: Schematics...........

author: Rick-S
author_rank: Newbie
timestamp: July 22, 2019, 05:10:56 pm
content: Wow, beautiful. Thank you so much for all you do for the community. You have an amazing amount of patience to do what you do. I'm in awe

author: GK
author_rank: Super Contributor
timestamp: July 23, 2019, 08:10:56 am
content: No worriesSat back to review the final design and made a few tweaks and error corrections. That PNP in the power supply labeled 2N3055 should be MJ2955. The TO-3 pass transistor / hybrid regulator for the +5V rail is just a homage to an old-school computer regulator. Aavid-brand TO-3 heatsink part #506007B00000G looks just like the heatsink originally used in the TRS-80 too.I also deleted the two 74HCT00 NAND gate ICs on page 2, which multiplex the chip-select lines from the address decoder ROM for user-selection of BASIC Level 1 or Level 2 and 16k or 48k of RAM. I can instead achieve the same function just by page addressing the address decoder ROM from the switch inputs instead.Also added a TVS diode across the contacts of the tape drive motor switching relay.

author: eshazen
author_rank: Newbie
timestamp: July 13, 2020, 02:49:25 pm
content: Just stumbled on this. What a great piece of work! I've been dreaming for a while about a TRS-80 clone. My original still collects dust in a friend's attic half way across the country, but I would expect it would need some work to get running again. One thing which stopped me was that I would really like to run a DOS (NEWDOS-80 was my favorite) on physical floppy disks, but (re-)designing a floppy controller seems like a lot of work, and probably most of my old floppies wouldn't be readable in any case.Not sure if you're still checking the forum, but if you don't mind I have a few questions:If I wanted to build one are the gerber files on your website the latest and greatest?Any issues with the PS-2 keyboard for compatibility? I recall a few games which used multiple keys pressed at once which might give trouble.Did you ever think about floppy emulation?Just FYI my old TRS-80 had a long and happy life. Started off with a 4K level 2 machine and upgraded it to 16k myself. Then added the RS expansion interface which never worked reliably until I added a percom "doubler" which improved the floppy system quite a bit. For a few years I ran TRS-DOS, then NEWDOS-80. At some point the expansion interface got cooked (probably a power supply failure burned something) so I ditched it and replaced the 16K RAMs in the main unit with 64K ones with an I/O port controlled bit to rearrange the address space, disabling the ROM and putting the keyboard and video at the top of the Z80 space. Then I added an "ICOM frugal floppy" controller with dual 8-inch disks and ran stock CP/M. By this point I had added so many extra chips that I switched to a big rack-mount external power supply! Probably the most amusing part of this was that to boot it you would start it in normal TRS-80 mode and load a small boot loader from cassette tape, which would boot CP/M! At the end I think I added a small EPROM in one of the holes in the address space to automate the process.