Judging from how old the last post on this page is, it could be that this project has died... however...

I was reading about the problem you encountered with the video needing access to the RAM (and ROM) at the same time as the CPU. Not a problem on the real hardware as they were separate because the RAM chips were so small. A solution used long past for such problems was dual ported RAM, but I don't know if that is still a thing.

An alternate approach might be to "dual port" standard RAM by running it at double speed big problem back then, not a problem now). First cycle is access by the CPU, second cycle is access by video generator, repeat. All handled through the CPLD/FPGA (it may just need to handle chip selects and not the full A & D bus). I really think you should upgrade the chip to the 100qfp though, you said already that the 44 pinner was too small for what you had and there was no room for tape IO etc. You don't want to go budget on such a cool design!

Great project. I'd like to see it live.

It was a slight problem on the actual hardware:  it caused visible artifacts on the screen while you were actively doing video I/O.  The CPU took access to the static memory bus away from the rasterizer, leaving random sections of raster lines blanked while the CPU was reading or writing to the video RAM.  The effect was mostly a slight annoyance (and jealousy of other branded machines which did not exhibit this defect).
Your 'ddr interleaved access' idea is an interesting work around.

Back in the day I did write some machine (assembly) programs for the model 1 (it got me into computers!). I faintly recall some mode where you could tell the unit to either allow the CPU priority access to the video RAM (which would leave quite significant blank streaks on the display), or let the video have priority (in which case there were no streaks). The most obvious case where this happened was the game "cosmic fighter". Maybe it was not the case at all and something else did it? Too long ago!

But besides that, I assume this project is still ticking along, even if just slowly? There seems to be a surprising growth in communities of TRS-80 enthusiasts restoring old machines. I think that people are now retiring and getting a lot more spare time, so interest is rebuilding. Emulators are nice and all, but not quite the same as "genuine" hardware - whether that be the real deal, or a hardware emulator using modern electronics as you are doing. For example, getting a genuine (and working) TRS-80 monitor is not easy, but a flat panel VGA screen is so common people throw them out.

People are also so used to instant access now, even me, and loading stuff from disk (or cassette!!) takes so long in comparison. The FreHD is a really cool gadget! Shame the Catweasle is no longer a product - getting a second hand one is proving to be difficult, and expensive! I have a lot of old floppies to transcribe.

There were some more or less simple mods to stop the Z80s on conflicting access to the video RAM but the speed penalty was noticeable most where it did hurt most: Fast games.

Occasional video glitches while coding were no topic and so I never added such a modification to my TRS-80 Model 1 clone.

I don't remember ways to achieve this without hardware mods on a Model 1 (or on an EG3003). Maybe later versions could do this?

@sitehounder: 'catweasle' -- now that's a name that I've not heard in a long time.  w.r.t. floppies:  I think the guys that run the TRS-80 sites (e.g. Ira Goldklang and others) really want old floppies/cassettes to image to disk images, so they might be able to help with that.
Also, be aware that I am not affiliated with this particular project -- I just replied because your post showed up in my feed.
@yeti I can't imagine how to do it on a Model I without some hardware mod:  e.g. using the BUSRQ to suspend the processor.  Seems like it would be a lot of work with little payoff, but you know how we liked to take the soldering iron to our boxes back in the day...

I've only started getting interested in TRS-80 stuff again recently - after giving my old, virtually dead, model 1 to a collector & electronics enthusiast. After seeing his progress, I am now all enthused again!

I saw Iras' offer to receive old disks & tapes, but I'm not real keen sending my floppies halfway around the world, and I now have absolutely no doubt that my assumed 'dead' machine will live another day. It is likely I will be able to borrow it back for a couple of weeks to do some transcribing... yet to see.

As a matter of interest, check out https://www.eevblog.com/forum/projects/cloning-a-tandy-trs-80-model-1/ discovered about an hour ago...

I get it with respect to sending your floppies.  It will be interesting to hear if you manage to recover data from them.  There's a huge archive of software (somewhat ironically on a site billed as a 'humongous CP/M archive') which might be useful if your software is damaged, though that won't help for your personal data, of course.
Fascinating find on the eev blog.

yes, an these access artefacts were very noticeable with rapid ASM access to screen RAM on the original.

I love how you ended your comment. It's a bit ironic that it wasn't the project that died but instead it was me. Well almost - they can re-start a heart but unfortunately by that stage I had suffered multiple organ failure so I have spent the last 6 years combatting health issues including extensive neural damage and other partially functioning organs and less one lung and a number of smaller dead parts now removed.

I hope to get bach to this project one day which is rather optimistic at this stage. My health is like a yo-yo and I have very little mobility and my cognitive function is still a bit away from something of this complexity.

But for now I started a retro-computer kit Southern-Cross (like a TEC-1) in an effort to stimulate and try and reactivate the old neural paths.

So no promises for now. On any given day my SPO2 can drop from 94 to 70 so there is still  a battle ahead of me. (70% SPO2 is really bad!)

Ironically, I came here looking for my own code! I have to program an EEPROM for the Souther Cross SBC and I used to use an ATMEG Arduino. I have found the programming adaptor but I don't have the code.

And from memory I was going to time divide the access to SRAM, so not really duel porting. And EPM570 would be better because I like to put everything though the CPLD and then the rest is code. But probably doable with a EPM240 - the TRS 80 wasn't a complex machine - I wasn't planning on building an expansion ports and FDDs. Just maybe some DOM Disk On Module IDE device or a CF card using a uC to emulate it back to cassette in some way.

Well it was more me that died lol. Cancer and then a long time in hospital and I have a reprieve for a while now but very poor mobility and respiratory function and I suffered multiple organ failure eventually including my heart in ICU so now I can't do much else. I have spent 2 years trying to put the workshop back together (everything is slow now as I have very poor fine motor skills on the left side - it's a challenge to type now) and it appears that I may be moving again soon.

But I came back here (I haven't been an active member for about 7 years) and I came back looking for pinout I made of the EPM CPLD board. I have the original in this project right in front of me now. I just ordered 20 boards for wire wrap and I want to see how to work with the dual rows of pins on the CPLD board and I see I designed for both SRAM and FLASH to work on the inner pins - terrific - that problem was solved and I probably have a stripboard for it here some where - I should just add the largest 32 pin SRAM I can find and a 512kB FLASH as that would cover most projects and save me worrying about the second row of pins. I am going to make some changes so that the EPM240 and EPM570 are interchangeable. I have another project of adding VGA to a Southern Cross SBC - I don't know how far I will go with this one. At most VGA out, PS/2 keyboard and cassette emulation to the existing FLASH or MP3 recorder (in .wav format) or CF Card. I wont be adding the expansion port or floppy controllers a I may nor even fit the above into a CPLD - I would have to go to a Cyclone FPGA and all 3v3 which is a whole lot of voltage buffers for the Z80.

So no promises, I can't promises anymore but we will see what happens. I have lost all the original code.

As for dual porting well I will just do time division access as the VGA access is regular and fast so I will just add a address and read/write buffer for the Z80. If the VGA is running ate 50/25/12.5MHz then that is plenty of opportunities for a slower Z80 to access SRAM/FLASH. It's easy to get 10ns SRAM but FLASH doesn't go below about 55ns without spending money. I'll have to split both between VGA and CPU if the characters are in FLASH or just get a second 512kB Flash for 2kB of character ROM lol.

god bless you in your recovery. Coincidentally, my own trs-80 related project was to keep me busy while convalescing from some cancer surgery of my own back in the day.
"I have lost all the original code." -- there's this thing called 'github'; you should check it out, lol ;) and the price is right
"As for dual porting..." -- somewhat interesting (or maybe not) was in my MCU based emulator, the hardware output was super solid because it was hardware driven (timer INTs triggering DMA feeding SPI). What was challenging for me was to "feed the beast" in a timely manner where it counted. Later someone piqued my interest in emulating the HRG mod, and I had to do some compute in software of the pixel stream. A straightforward implementation was not possible, but I wound up buffering the raster lines, and then doing partial computations during the blanking interval to get at least the front part of the line ready for DMA, and then incrementally compute the other parts before the DMA caught up to needing them in the buffer.
OK that tale is probably not so interesting to others to hear, but I did get a rush out of getting it working and stabilized. It opened up some nifty capabilities, like 'porting' FS1 to HRG. (a bit less impressive to play than one might imagine, but the lines are much crisper in HRG)
Anyway, best wishes in your recovery/acclimation, and may your projects keep you sane!

 RE: The NMOS and CMOS versions handle OUT(port), register differently -
The Model I did use the ports mapped to an 8 bit address space. The Z80 documentation specifies only A0 to A7 during an Input or Output cycle, leaving A8 to A15 undefined.

If you need more technical info on the TRS-80 range or Z80 have a look at what we have on our user group website's on-line library (www.sydtrug.org)

The Z80 has both 16 bit and 8 bit IO. The OUT (c),n OUT(c),r instruction places the 'b' register on the other 8 address bits. 

From memory most of the other port instructions are only 8 bits and the difference between NMOS and CMOS is that one put '00000000' on the other 8 bits of the address bus and the other outputs '11111111'. 

This becomes a problem because by convention IO is gennerally mapped to the FFxx range and some programmers have assumed that they can use an 8 bit IO because (on one version) the default for the other 8-bits is 'FF'

Thanks for the heads up on the 8-bit only TRS-80 IO. I was not aware of that.

Your project is titled "TRS-80 Compatible Clone", so I provided details that are specific to the TRS-80 Model I operation. It use the D3 opcode for OUT functions and DB opcode for IN functions ( OUT n, A and IN A, n ). In both cases - from the Zilog Z80 Technical manual - " the I/O device address n appears in the lower half of the address bus (A O -A 7 ) while the accumulator content (the A register) is transferred in the upper half of the address bus".

While the  Z80 does support 16 bit I/O (using register Indirect mode), the TRS-80 Model I does not use this feature.

The only I/O used in a standard Model I is the control of the 32/64 character mode and Cassette read/write

@Errol Rosser: and UART (ports 0xe8-0xeb).  I believe hard disk used (0xc0-cf (I never had one)).  And of course sundry non-RS add-ons used various ports.  Sorry, pedantic, I know.  Couldn't resist since I am in the midst of serial port emulation, so those are fresh in my memory.

(why does this site only all two replies deep? formatting?  technical limitation?)

@ziggurat29: Being VERY pedantic, the standard Model I did not have a serial port (with UART) OR an Expansion Interface to put it in. Nor did it have a hard disk interface. See the picture at the top of the page.

Anyway, a quick disassembly of the LDOS RS232 and RSHard drivers indicate that I/O to those devices was done using 8 Bit I/O (OUT n, A and IN A, n )

Haha yes touche -- quite right of course considering the keyboard unit only, that only the one IO port is used (I tend to assume that "of course you would want the EI, too"; but yes in a hardware reconstruction project like this it makes sense to just emulate the keyboard unit since you could use, say, the FreHD to provide the other stuff).

Re the 16-bit IO on the Z80 -- I had always assumed that behaviour was undocumented, but I find myself right now staring at a User Manual from Zilog that clearly documents it.  Huh.  Well, it is "Copyright ©2016 Zilog, Inc.", so maybe they simply got around to documenting it eventually.  But it's a bit hard to take the 16-bit IO addressing seriously, though.  First, the instruction mnemonic is e.g. "OUT (C), r".  Wouldn't that more sensibly be "OUT (BC), r" if that was how God -- er, Faggin -- intended it?  And then "OUT (n), A", puts... A! on the high bits of the address bus, instead of 'B' as with the others.  Lastly, the block IO I can only imagine would be quite 'amusing' in a hardware system designed around 16-bit IO addressing, since B is used as the counter variable, and each access would be 256 ports apart, haha.  Because of these things, I always presumed the 16-bit behaviour was more just an artifact of silicon implementation convenience, rather than conscientious design intent, and that other silicon vendors preserved it out of fear of some incompatibility issue.  Word-on-the-streets is that the Amstrad used the 16-bit IO, but I never actually had one of those.

Anyway, "whatever", but now I do wish I had a 70s-era Zilog datasheet to see what was actually documented back in the day.  I have a copy of Zaks from that era, but I can't consider that normative (and anyway, I think it's boxed up right now.  It used to be in the bathroom which I re-floored earlier in the year, but it's clearly not there now.)

I Just had a look at Zaks and it documents putting B on A8-15 with a OTDR. 

The OUT (n),A is that way because the other half of 'A' is 'F' ... AF BC DE HL SP PC IX IY IM/R - last being interrupt mode and refresh register but most of that wasn't documented. 

Back in the day I didn't have a assembler so I printed out tables that went from mnemonic to hex. There were 4 sheets of 16x16 tables and they made it obvious why in some cases you get the 16 bit address space. They also made it obvious what all the undocumented instructions were. Sheet 1) was all the 8 bit mnemonics except CB DD FD and they were the three other sheets. 

There were also lots of undocumented 16 Bit IO instructions and that's probably what you are remembering. As for why - well it simply was easier to let the 16 bit IO work the way it does as there is already a 16 bit bus from register pairs to the address bus for instructions like LD (HL),n. The exception is the Flag register because of timing issues as it is set last as the result of the preceding instruction. 

There was also some fully weird stuff. The CB DD FD instructions made prior changes and then the following bit in some cases was the 8 bit instruction like with offsets. It was possible to use them in unintended ways to make several pre-changes by linking them together but I never fully worked that out. some of the results were uninterpretable.

Hi,

I just looked at the site you mentioned. I am too far away to be a member (QLD) but I spent about 8-10 years working for a hosting provider as a web developer (mostly server side). 

I had a look at the forum because I am too far away to be an actual member and thought I could join in that way. 

Perhaps my other skills may be useful. The forum is using file based data storage and I assume that because there is no MySQL or similar database facility?? Hosting is dirt cheap now even with all the bells and whistles. 

It took me back to see that most of the HTML is hand written. That must have been a huge effort. I cheat - takes me about 20 minutes to install a pre-made module like a cms or forum.

Maybe you have an old version of the Membership web page in your browser cache - we have recently updated the membership to allow "Online Only" members at a reduced membership rate.

Yes, the pages are hand crafted, then implemented with a scripted page writer. I can write HTML a lot faster than the learning curve on the "fancy" web page design programs, plus I don't get the huge amount of overhead in the web page code.

In case you didn't look at the online library page, here is the current summary of the 70+ GB already up there

Magazines - 1,945 from 46 series - 236,556 pages (47.5 GB)
Exchange Newsletters - 5,965 from 126 clubs - 90,107 pages (12.4 GB)
Hardware - 642 manuals, 330 pictures (drives, TRS-80s, printers) - 33,790 pages (2.6 GB)
Books - 488 (Programming techniques, BASIC programs, ROM info) - 94,166 pages (7.5 GB)
Software - 1,026 manuals, 784 images (Business, Games, Utilities) - 79,500+ pages (4.5 GB)

The Model I runs on 1.774 Mhz where the Model III runs on 2.03 Mhz. The speed increase is about 13% which is no problem for most applications but games and sound might suffer a bit. For me no problem.

The odd descenders on the lowercase character set are correct. These were used on the first releases of the Model 1. The Model 3 and later had true descenders. 

I see you are in Australia; you could ask Ian (from the FreHD) to do the programming of the 27xxx eprom, he has the equipment.

I found this Character ROM on the net. It said it' for a TRS-80 but doesn't say which model. 

Is it the right one? I have rendered it in the same scale as the screen. 

Is there one with proper decenders on the lower case?

It largely looks good in the 0x20-0x7f range.  0x00-0x1f are not correct, they should be a repeat of 0x40-5f.  And of course you don't show the graphics chars 0x80-0xbf (and 0xc0-0xff repeats them), but maybe you're going to do them in logic, like the original hardware, rather than CG ROM.  All this of course assuming you have full 8-bits of video memory.

OK, descenders.  The ones depicted are correct for the MCM6670, which came in the original units before the lower-case mod.  (I think there was also a buggy earlier one where the 'a' was up one line.)  The mod also replaced that part with the MCM6673, which was a little bit more pleasing (one pixel of descender).  Later units (like mine), came with the '73 installed oob even without the lower case mod, so upgrading it myself simply consisted of buying a piece of static ram with minor surgery (a $USD 98 savings).

(I'd post a bitmap of the '73 CG ROM results, but I can't see how.)

HELP!!!

WTF is a 10.6445 MHz crystal for. CPU runs at 10.6645 / 6 => 1.77408333... MHz

Pin headers sound like a great idea, as the card edge connectors are indeed very unreliable. It would be great to be able to connect to the Expansion Interface or the FreHD Harddisk emulator. 

VGA is great, together with composite. What about a small add-on board with the DIN-connectors for those who want to use an old M1 shell? The main PCB is smaller, cheaper and for many it doesn't really matter. 

I'll send a picture of the keyboard connector, and the schematics of the keyboard PCB (it has some chips on it). 

I'll also send a description of the character set, and the wat graphics are represented in the character rom. Compatibility on that level will be appreciated! I'll also upload a ROM-image which supports autoboot for a harddisk. It's 100% compatible with the M1 but enables booting from HD, thus no Expansion Interface of floppy disk is needed.

I see you have found most of the important information already, maybe a detailed memory map wil help in the process. 

Just need to find out how to upload these items, or how to send them!

(NB: cheap and small is good! A maxed out M1 is perfect, waisting 16K is no problem as it keeps the costs down)

I haven't printed out the schematics yet. I will do that today. I looks like there are some PCB traces cut according to the schematics. They're in the area of RAM / ROM addressing. 

There are 2 dip switch / jumper blocks. It looks like they're for RAM / ROM size / config. I would really like to do away with these because using 16 pins for dip switches is a waist of pins on the CPLD. I was thinking to use just  the maximum config - 48k RAM and 12k ROM, implemented in lager single chips ie 64k SRAM and waist the extra 16k that way I can keep the chip count down making the actual PCB cheaper to make. 

About CPLD, it's just all the extra chips that aren't RAM/ROM/CPU/OP-Amps that are crammed into one chip but they're not all connected, the connections are done with a program instead of traces on a circuit board.

There are two problems with CPLDs:

1) There not 5 Volt (but some will work with 5 Volt) ... 

2) They're in square packages with pins close together so they are hard to solder. 

... I can put the CPLD on an adaptor board if need be, that way if soldering it is stuffed up then you throw it in the bin and start over without having to worry about the rest of the circuit / parts. 

I had two CPLD candidates in mind:

1) Xilinx XC9572XL, about $10 - $15, 44 pin package with pins 0.8mm apart (72 Macrocells) but the programmer is $30 to $50. I may not be able to fit a VGA out in 72 Macro's but I can try. (I have a programmers for both Xilinx and Altera). 

2) Altera EMP240, about $5, 100 pin package with pins 0.5mm apart (180 Macrocells), the programmer is only about $5

0.8mm and 0.5mm might not sound like much difference but it is significantly harder to solder 0.5mm

I can program a small number of CPLD's to post out just for members here but I don't want it to be something that is ongoing.

Connectors:

I want to replace the IDC edge connector(s) with Pin Headers. You can still get IDC pin header connectors so there is not much difference. Edge connectors were incredibly unreliable.

DIN is fine for the final version, perhaps dual footprint so either can be used ... 

For Proto:

VGA - DB15HD Female

Power - Barrel connector

Composite Video - RCA connector

Tape - RCA or 3.5mm

Keyboard - unsure 2x8 Pin header?

About keyboard - I don't have one so I will use a standard PC keyboard and take the electronics out leaving the moving parts and matrix membrain. I don't know how well the resistive membrain will work with the CPLD (or even if at all). I can remove the extra keys and blank them off with a cover but I don't know yet what to do with the 'clear' key. 

Generally I am thinking - minimum component count - small - cheap. Cheap is important for me as I am disabled and have no income.

PS: These are all just ideas, I would like to know what others think.