The Discrete YASEP enables a lot of explorations. The YASEP architecture is rather well defined and understood but there are other aspects that need innovation. In particular the breakpoints and trace systems, which have been essentially software-driven in the last decades. It's exciting to play and find new ways to do things, that our predecessors could only dream of !
The design of the breakpoints started with the log Dear SN74HC688 where a classic system was described. Then @esot.eric gave me an even better idea (in the comments of Programming systems) that totally fits in the spirit of the Discrete YASEP project : use cheap, widely avalable parts to do all the work, in ways that break with the tradition of scarcity of the previous generations. The Discrete YASEP is the celebration of dirt cheap parts ;-)
Instead of using a 574 and a 688 for each individual breakpoint, a single 64K SRAM chip will use less room but provide 8 breakpoints, not just on one data point but on a whole range or even totally unrelated points. Alternatively, the breakpoints can be also used for code/data coverage and sent to a host for analysis.
The more I think about, the more possibilities appear so I'll use this log to gather current and future ideas. Comments about it are piling up on an unrelated log so I'll move things here :-)
Update: In the comments, @K.C. Lee suggested to feed the BP signals to a set of counters for performance monitoring. This project is getting better and better thanks to your input, guys :-D
So now we have 4 counters made of 74HC4040, 36 bits long. An overflow bit is needed too. The 4040 are easy to clear and increment but it gets tough to manage this quantity of data: each stage of 4×4040 requires 6×HC253, 24 of them overall just to select one 36-bits counter out of 4. Then individual bytes must be selected for output/display...
The trace & breakpoint boards are amazing features, and like some other boards, they make this project a comfortable development environment. But it appears to get out of hand and the complex RAM-based breakpoints may drag the whole project's development. They are now "optional" and I'm considering the return of a basic 688-based breakpoint for the "base configuration". I want things to get done ASAP, they can be extended later :-)