• Please review our updated Terms and Rules here

Powertran Cortex

tms9995 said:
I have the original WINDOW code somewhere. As you say, it was setup to work with a VT100. I will try to dig it out...
Click to expand...

I think that disk may already be in the disk image set on your Cortex site. Isn't it "MDEX Window Screen Editor Release.dsk"?

Paul
 
Many thanks, I've got the schematic.
I use these cables at work at lot http://uk.farnell.com/ftdi/ttl-232r-5v-we/cable-usb-ttl-ser-conv-5v-wire/dp/1740364
But on my project I was going to add the MAX232 (or modern equivalent) to convert to true RS232 and then you can either connect to an existing serial port or a easily obtainable RS232 to USB cable.
This gives you the option of using the serial port with old hardware (terminal, serial printer, serial mouse etc) as well as a PC interface.

Jim
 
pnr said:
I think that disk may already be in the disk image set on your Cortex site. Isn't it "MDEX Window Screen Editor Release.dsk"?

Paul
Click to expand...

Yep, looks like it's all there. Some nice person even wrote a README to describe how to build it for different terminals ;)

Dave.
 
Anyone know if the MPE Cortex version of MDEX that we have access to uses any 9995-specific instructions or features? Should it run on a 9900 (the docs say it should run on 99xx(x), but not sure how literally to take that)? What does it need in terms of minimum hardware? RAM from >0000 upwards? Serial port at CRU >0080? Disk system?

Stuart.
 
The Marinchip version it is derived from was intended to run on a TMS9900, Stuart, so unless MPE made some internal changes that incorporated some 9995-specific code, I'd say that it should still run on a vanilla 9900 system.
 
Stuart said:
What does it need in terms of minimum hardware? RAM from >0000 upwards? Serial port at CRU >0080? Disk system?
Click to expand...

RAM Yes, it needs RAM from >0000 upwards. Not sure how much it needs, I think at least 32KB. The first >100 bytes contain int/xop vectors and a jump table.
Programs normally load at base address >100, and for the existing software packages I didn't see an easy way to change that. The MDEX kernel is about 7KB plus the size of the drivers, my build is just shy of 9KB including drivers. It is configured to load at >C000, this is a system generation parameter.

Serial Serial is really defined by the console terminal driver, it need not be a UART (and the Cortex driver is an example of that). If you use a 9902 chip it need not be at >0080: the CRU location is a parameter in the driver. In my build it is indeed at >0080.

Disk Yes, MDEX is really built around the concept of a disk. This too is only defined in terms of an interface to a driver: any device that can pretend to be a disk with 128 byte sectors will work.

Printer MDEX also assumes the existence of a printer, but does not require it to actually work. Out of laziness I have linked in a Centronics driver, which will surely hang if I would try to access the printer. The more elegant solution would be to use a "null" driver that simply discards any data sent to it.
 
CF Card interface

CF Card interface

I'm experiencing a strange instability when accessing the CF Card.

When reading a sector occasionally a byte is missed from the sequence. It is not entirely reproducible, but also not entirely random: I cannot recall that this has happened during the initial boot load and when manually testing sector reads with the "DU" disk utility some sectors always read okay, other sectors miss a byte once every 7 tries or so. During manual testing it is always the first byte that is skipped, but the "FDIAG" utility also reports a byte missing further in a sector on some runs.

My hypothesis is that I have some sort of noise or timing issue, causing the CF Card data counter to occasionally advance in error. I have an old 2 channel scope, but no logic analyzer. Haven't wheeled out the scope yet.

Any suggestions for setting up test cases to narrow down what might be causing this? All input welcome.

Paul
 
Earlier you posted a link to <http://searle.hostei.com/grant/cpm/>. Did you see the section "IMPORTANT CONSTRUCTION NOTES" about a 1/4 of the way down the page? Copied below. I know that with the TI-99/4A C/F adaptor device, some CF cards work and some don't. Have you tried different cards - in particular an older, lower capacity card?

COMPACT FLASH
1. For reliable operation, the leads to the CF card must be short.
2. Some cards are more sensitive to noise on the lines. FujiFilm cards work very well, SanDisk cards work but need short wires. To get one card working I needed to connect a very small capacitor (15-22pF) between the address lines and Gnd. Ferrite beads on the lines also help.
3. If the results are intermittent, ensure you follow the above guidelines.
4. The CF specification says that the logic levels should be "CMOS" values. However, from ALL cards that I have tried, although this is specified, the TTL levels work perfectly. If in doubt, you could replace the Z80 with a CMOS device and replace the 74LS138 with a 74HCT138 and replace the 74LS32 with 74HCT32. This way, all lines to the CF will be CMOS levels. However, this should not be necessary.
5. Cards larger than 128MB can be used (use the 128MB BIOS and formatter) but only the first 128MB will be recognised by CP/M - this should be more than ample, though. Avoid new high speed cards as these are very sensitive to noise (due to the high speed) and will require short leads.
6. Route leads as directly to the Z80 and to U5 and U8 as possible. On my picture, the address lines were taken from the end of a chain of connections which works perfectly for my FujiFilm cards. However, the SanDisk card was not reliable with this, but worked perfectly when I took the address lines straight to the Z80 CPU.
 
pnr said:
I'm experiencing a strange instability when accessing the CF Card.

When reading a sector occasionally a byte is missed from the sequence. It is not entirely reproducible, but also not entirely random: I cannot recall that this has happened during the initial boot load and when manually testing sector reads with the "DU" disk utility some sectors always read okay, other sectors miss a byte once every 7 tries or so. During manual testing it is always the first byte that is skipped, but the "FDIAG" utility also reports a byte missing further in a sector on some runs.

My hypothesis is that I have some sort of noise or timing issue, causing the CF Card data counter to occasionally advance in error. I have an old 2 channel scope, but no logic analyzer. Haven't wheeled out the scope yet.

Any suggestions for setting up test cases to narrow down what might be causing this? All input welcome.

Paul
Click to expand...


Hi Paul,

The MPE FD/WD E-Bus card is used to connect to the Western Digital WD1002 hard and floppy drive interface board, this in turn connects to MFM hard drives.
The interface to the WD1002 board is essentially what developed into IDE when miniaturised WD1002 electronics were incorporated onto the drive itself.
It's a different pinout but pretty much the same signals.
And of course the CF interface is just IDE on a different connector.
On the MPE card the pcb has been hacked to included a delay on both the _WE and _RE (_DBIN) signals.
You can see it on the schematics in the manual which is on my web site.
http://www.quantums.info/cortex/MPE documentation/MPE FD-WD-E user manual and schematics.pdf
I assume the _WE and _RE were becoming active too soon without the delay.

Just a thought.

Jim
 
Last edited:
Jim Hearne said:
I assume the _WE and _RE were becoming active too soon without the delay.
Click to expand...

That sounds familiar. On the IDE card for my TM990 system, the /READ signal to the interface is delayed through three OR gates to "give a falling edge on /READ after /CS0 becomes active". l would have seen the need for that before somewhere (probably a Z80 CF interface) as I wouldn't have done it myself.

Stuart.
 
I read up on the WD1002 and it is amazing how little has changed in 30 years. Thanks for that insight.

It could well be DBIN/OE timing. The CF card spec says that the address lines should be stable 40ns before the negative flank of OE. If I read the 9995 data sheet correctly, at 3 MHz DBIN has its negative transition worst case ~40ns after addresses stabilize, although ~80ns is more likely. In IDE mode addresses should be stable 70ns before the negative flank of IORD. I would not be surprised if many CF cards use IDE mode timing for memory mode as well.

When I have a chance I'll experiment with delaying DBIN to OE by 20..30ns and see if it makes a difference.
 
pnr said:
When I have a chance I'll experiment with delaying DBIN to OE by 20..30ns and see if it makes a difference.
Click to expand...

It only made things worse. However, I did finally notice that the missing byte was always an >FF byte and that made me think that power or grounding might be iffy. Indeed, routing a direct link from CPU ground to CF card ground made the problem go away.
 
Anyone interested in a TMS99110 for $20 plus postage, from a Chinese vendor, if we can get some sort of money-back guarantee that they work? There are some available apparently.

Stuart.
 
I'd be interested in a few of them, Stuart. I'm hoping that I can get my hands on the plans used to build an accelerated TI-99/4A that used a 99110. . .so having a couple of them for the experimentation would be very useful.
 
Count me in for one. At 15 euros it is a bearable risk, although I see the point about the money back guarantee if they're all duds.

Paul
 
Well it was through the same Chinese contact supplying the bits to the chap putting the 9900/9995 kits together who has been passing me some of his spares. But despite him (the Chinese contact) initially saying yes he could get them and his supplier guarantees quality, it has ended up that no he can't get them in either package type, the ceramic or the plastic.

[My TMX9909 from eBay arrived in the post a while ago and seems to work fine. No Chinese supplier involved. ;-) ]

Stuart.
 
Hi.

Does anyone know where I can find a good quality set of Powertran Cortex schematics... someone may have already posted a link to them ?? I'm looking at reverse engineering some of the circuit.. It would be great if someone had already put some of the schematics into Eagle or some CAD system ? I can source the ICs reasonable cheap so it shouldn't cost too much .. ideally making a 'New' TMS9995 system for less than £100. This is still obviously in the 'Feasability' Stage.. but there's no reason why it should not be possible ?

Best Regards
Lez
 
You must log in or register to reply here.
Back
Top