CF7+ problems / question

[+hloberg]

FYI: got some info from the CF7 guy. I asked if the parallel port is bidirectional. This is what he sent.

 

 

All access is through CRU.

PBASE EQU >1300

PDIRIN EQU >1302

;0 = output, 1 = input (affects PDATA only)

PSTROB EQU >1304

;strobe (output)

 

PBUSY EQU >1306
;busy (input)

 

PDATA EQU >1308

;data port (8 bits - bidirectional)

Edited April 27, 2014 by hloberg

[matthew180]

The F18A has to load its configuration at power-on, and this loading takes more time than a dedicated IC takes to reset at power on. The 9918A is ready about 10us after power is applied, the F18A needs about 50ms or so. I typically say 100ms to be on the safe side. Note that this is ONLY a power-on delay. Once the F18A is operational it can respond to a system warm-reset (using the reset logic and reset input pin) in 20ns.

 

The ColecoVision and MSX systems are known to have really short power-on-reset (PoR) circuits, about 20ms or so which is right on the edge of the F18A's requirement. The 99/4A has a slightly longer RC time constant so power-on problems are less typical on the 99/4A.

 

The only way the F18A would interfere with CF7 operation is if the CF7 is trying to access VRAM before the F18A is configured. However any VRAM access by the CF7 should not happen prior to the whole system coming out of PoR, if it does that is a critical error. The system reset signal is available on the side connector and the CF7 should be watching it (I don't know if it does or not).

 

The only thing I can imagine the CF7 "F18A Patch" could be is a short delay (100ms max) at power-on, but this should almost be satisfied if the CF7 uses/watches the system's reset line.

[+hloberg]

Whatever way he is taking care of the problem now seems to work perfectly.

I can see though were he would have not bothered to check the reset line before. When he made it he probably knew it took X-ms for his stuff to initialize and the TI99 took Y-ms and he was within that framework so why add extra code if he didn't have to. I hate to admit, I have had the same thing too when coding, taking a shortcut then being bit by it later.

Edited April 28, 2014 by hloberg

[+arcadeshopper]

One thing to think about is that the CF7+ uses current technology while the PEB uses old tech. Maybe the memory initializes faster on the CF7 while the PEB memory may internalized slower. F18a delay may not throw the sequence off on the PEB, but the CF7 the extended memory is ready too fast and the delay throws off the whole sequence of events.

of course, just a theory.

Oh ya, it is nice that he so quickly fix the problem. Proves he wants a quality product.

 

The issue is entirely that the F18A initalizes VDP ram slower than a 9918.. The CF7+ & Nano were designed with the stock console/9918 in mind and access VDP ram almost instantly at power up. The delay was added to this to give the F18A time to finish it's boot.

 

from the F18A website:

KNOWN QUIRKS

Due to the technology used to make the F18A, it is not possible for the F18A to power-on as quickly as the original 9918A/9928/9929 VDP. In some instances when a system is turned on and comes out of power-on reset before the F18A is ready, the system may hang or not start correctly. Usually a simple power-off / power-on will correct the problem, or if your system has a real reset button, that should also remedy the problem. The F18A needs about 100 milliseconds to come ready after power is applied, compared to the original VDP's power-on requirement of only a few microseconds.

Most systems use an resistor and capacitor as an RC-time constant to control the power-on reset time, and in systems with known fast power-on reset times, a simple modification to make the resistor or capacitor lager will extend the reset time and make a more reliable power-on for the F18A enabled system.

Information will be available soon for systems where the power-on reset time might need to be extended.

 

Greg