I’ve always found Phil at Retroleum to be quick, if he has an item in stock.
Maybe he had an extended bank holiday weekend...
Mark
Resurrecting an MTX500.
Re: Resurrecting an MTX500.


“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb

Autumn is here. Bye bye summer 2024...
Not as many MTXs as Dave!

-
- Posts: 341
- Joined: 27 Nov 2016 19:58
Re: Resurrecting an MTX500.
Excellent! The GALs have arrived a couple of days early.
Re: Resurrecting an MTX500.
I don't know if these will help - its a set of WinCUPL files for a replacement MTX500 (or maybe 512) PAL using the ATF16V8
-
- Posts: 341
- Joined: 27 Nov 2016 19:58
Re: Resurrecting an MTX500.
Thanks. There are .eqn and .jed files on Any Key's web site for all the GALs as well, not that I know what to do with them. 
P.S. The files in your ZIP file look to be for a two ROM MTX500. I'm going to have to get the settings for a three ROM MTX512 now as I've upgraded the memory and change LK6 (or is it LK7?) from C->H to C->4

P.S. The files in your ZIP file look to be for a two ROM MTX500. I'm going to have to get the settings for a three ROM MTX512 now as I've upgraded the memory and change LK6 (or is it LK7?) from C->H to C->4
-
- Posts: 341
- Joined: 27 Nov 2016 19:58
Re: Resurrecting an MTX500.
I'm home now. I've programmed a GAL with the 3 ROM & 64K RAM JEB file from Andy's site, fitted it and the ROM select line is still constantly high.
The address lines are active as is the _RD line but no ROM select.
What's the logic used to generate the ROM select for ROM A? Maybe I'm missing something.
The address lines are active as is the _RD line but no ROM select.
What's the logic used to generate the ROM select for ROM A? Maybe I'm missing something.
Re: Resurrecting an MTX500.
One of my Z80 hardware books recommends a test / debug method called "static stimulus testing".
The idea is you remove the Z80 and replace it with switches and resistors. Then you can put any state you like on the buses and control lines, and check all the decoding logic. Much easier than trying to follow the dynamic signals of a running system.
My book suggests building a complete unit which could be connected to the Z80 socket by a ribbon cable hand header. However, since you are really only interested in a few high order addresses and control signals you could perhaps do something just using a plug board and some solid core wire.
The idea is you remove the Z80 and replace it with switches and resistors. Then you can put any state you like on the buses and control lines, and check all the decoding logic. Much easier than trying to follow the dynamic signals of a running system.
My book suggests building a complete unit which could be connected to the Z80 socket by a ribbon cable hand header. However, since you are really only interested in a few high order addresses and control signals you could perhaps do something just using a plug board and some solid core wire.
Re: Resurrecting an MTX500.
"Z80 Applications", James W. Coffron. A good book in general. Taught me most of what I know about microprocessor interfacing.
I tried to upload a scan of the chapter but the file is too big
Edit: Found a Google link to a similar description here
I tried to upload a scan of the chapter but the file is too big

Edit: Found a Google link to a similar description here
Re: Resurrecting an MTX500.
You mean this book...
Mark
Mark


“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb

Autumn is here. Bye bye summer 2024...
Not as many MTXs as Dave!

Re: Resurrecting an MTX500.
The 3 rom 4000-05 MTX is only covered in the original manual, it looks like /CEA is the chip select for the A rom, and /CE64B is B and C rom select that goes to 10J to be separated.stephen_usher wrote: ↑10 May 2019 20:16 I'm home now. I've programmed a GAL with the 3 ROM & 64K RAM JEB file from Andy's site, fitted it and the ROM select line is still constantly high.
The address lines are active as is the _RD line but no ROM select.
What's the logic used to generate the ROM select for ROM A? Maybe I'm missing something.