My OSI 610 build - Expansion for the OSI 600

[rubber_jonnie]

I was trying with my TL866 Pro, it's 'supposed' to do them but doesn't. Going to try the MQP170 shortly.

I've no idea if it supports those. I mean is DOS stuff mostly, so it should be old enough..

You maybe have to build a adapter and pretend its a larger size and hardwire the extra address lines low.. If the devices have the same number of pins, you could use a 32 as a 16 etc that way..

The MQP is actually writing them, good job I bought it from you :)

[exxos]

The MQP is actually writing them, good job I bought it from you :)

Cool !! :thumbup:

[rubber_jonnie]

The MQP is actually writing them, good job I bought it from you :)

Cool !! :thumbup:

Well, they program, but they don't work properly in the machine. Theoretically they should, however it doesn't mean they will in reality.

They sort of work from time to time, but they could be marginal ICs.

I have a couple more 28C16's on the way, we'll see how they do.

[exxos]

They sort of work from time to time, but they could be marginal ICs.

Always possible.. Though have you scoped the pins in circuit ? might be other factors rather than the ROM itself ?

[rubber_jonnie]

They sort of work from time to time, but they could be marginal ICs.

Always possible.. Though have you scoped the pins in circuit ? might be other factors rather than the ROM itself ?

Not as yet, no.

[stephen_usher]

Yay! It lives! :-)

[rubber_jonnie]

So, I have been chatting on OSIWEB about the ROM corruption I've had and had this rather interesting reply:

"Using an AT28C16 in place of the ROM chips can cause data corruption when the system is powered on/off or when 100nsec spikes can reach the WE pin. Starting with AT28C64 Atmel introduced a write protection mechanism to improve the situation. The AT28C16 does not provide this.

Using an AT28C16 for the system ROM caused sometimes the problem you've described, I had some improvements, when using only a 10k resistor from WE to 5V at the IC buffer capacitor."

As I understand the OSI600 and the UK-101 were supplied with mask ROMs, so this wouldn't be an issue.

I've got various different EPROMs on the way to see what works best. I do have some 27C16's, but I don't think they are in good shape as they are programming OK with my old MQP device, but don't work at all well in the 600.

[exxos]

Its why scoping pins is good to see if something is amiss. But why is WE even connected to something in the first place? Not sure I follow... Unless the pin is floating? WE is normally just wired to 5v? Not sure where the 100ns spike is supposed to be coming from? Shouldn't be a issue is WE is hardwired to vcc.

[rubber_jonnie]

Its why scoping pins is good to see if something is amiss. But why is WE even connected to something in the first place? Not sure I follow... Unless the pin is floating? WE is normally just wired to 5v? Not sure where the 100ns spike is supposed to be coming from? Shouldn't be a issue is WE is hardwired to vcc.

Yeah it's a weird one for sure.

Pin 21 on the 28C16 is /WE, so active low.

The system has 6 ROMs:

1. SYSMON - The system boots from this first before getting to BASIC.
2. BASIC 1-4 - The 4 ROMS that contain BASIC
3. CHARGEN - The ROM that contains all the charaters used by the system

Looking at the schematics though, the BASIC ROMs have pin 21 connected to PHI2 from the CPU, and the CHARGEN ROM has pin 21 pulled high.

SYSMON however has pin 21 connected to GND. This wouldn't be an issue for mask ROMs or something like a 27C16 that requires a much higher programming voltage, but for the 28C16 that requires that pin to be connected to GND for programming, then it is in a permanent state of write enable and could be corrupted quite easily if there were any pulses during power cycles, or at any other time.

That makes sense to me at least. It also explains why the other ROMs are not suffering the same problem - none have pin 21 connected to GND.

[exxos]

Seems like just cutting the WE track and wire to vcc would likely solve the issue then?