chessdoger wrote:
... yes in the end if you are using a ttl to USB module ..that will probably have to be inverted...
Bummer! I was hoping to avoid adding another chip.
Quote:
... But as I replied before .. you could probably modify the supermon code to invert the signals.. however I think it be bit hard if you are not understanding how the whole I/o for CRT works ..I sort of looked at it at one point .. and said naghh ..best leave alone...
I was hoping you knew how to modify the SUPERMON code. No worry! I'll take a look at it.
Quote:
... In a similar way I looked at using pics to control etc and be part of the old micro system ... you end up in timing issues...
I haven't experienced any timing issues or anomalies but I spent a great deal of time doing research and performing experiments to verify system and bus timing. I'm using a 64-MHz PIC (Tcy = 62.5-ns) which is approximately the same performance level as a 16-MHz AVR.
Quote:
... Gals(PLD's) are almost at logic gate speed in execution(again depending on number of functions to perform ) and some of them can do it in 50ns or less.. I think you be pushing a micro controller to execute software and issue I/O signals that fast...
GALs in DIP packages are great and I would use them if it weren't for; (1) the dwindling availability of high speed parts, (2) the cost, (3) the power consumption, and (4) the lack of a good DIY programmer design.
Please don't dismiss the capabilities of the PIC in an SBC design. Could I take a moment to explain its operation, please?
Since the PIC is generating the 1-MHz clock, it knows exactly when the address lines become valid during each 65C02 clock cycle. The PIC has plenty of time to look up the chip select pattern for the page being addressed and to update the chip select outputs 187.5-nsecs before the PHI0 rising edge. In fact, the PIC only uses three instruction cycles for the "soft decoder" function out of every sixteen instruction cycles that make up each 65C02 clock cycle.
Using a PIC in an SBC design isn't for everyone. In my case, I use it to provide reset, clock, and address decoder functions and to provide "blind loader" and "blind monitor" functions (including single-step capability) that run outside of 6502 address space. The capability of the "soft decoder" is pretty remarkable, too. Uploading a new 256 byte "decoder map" file into PIC flash memory over the serial port is all that's needed to map memory and resources to recreate an Apple-I, a KIM-1, an Elector Junior, etc., or to experiment with zero page I/O.
More later. Cheerful regards, Mike