My plan is to have both a serial port for connection to a PC/Terminal
and an I2C output to a multi line display.
Thanks for the suggestion.
On 9/22/2023 4:45 PM, ben via cctalk wrote:
On 2023-09-22 3:16 p.m., Mike Katz via cctalk wrote:
Martin,
The debug board will need to have the following functionality:
1. Read and write to/from memory when the CPU is running using one
cycle data break (DEC's version of DMA for the PDP-8). Single Cycle
DMA requires some interesting signaling, including putting the
priority on the data bus during part of the cycle.
2. Read and write to/from memory when the CPU is halted using front
panel emulation (something totally different than one cycle data
break unfortunately)
3. Handle 4 breakpoints (based on address, data, R/W and count) and
signal the cpu to stop. I don't know, yet, if there will be enough
time in the CPU's instruction cycle to top the CPU before the fetch
of the next instruction. If this cannot be done in hardware than a
much more crude break point system can be done in software.
4. There are 96 active signals on the PDP-8/E's Omnibus. I expect to
need most or all of them for this project.
5. The Omnibus is an open drain, active low bus where +2.7V to +4.5V is
a zero and -0.5 to +0.4V is a one. I don't necessarily need a 5V
tolerant gate array but what ever I use to interface to the bus will
need to be.
A full description of the Omnibus can be found here:
https://bitsavers.org/pdf/dec/standards/EL-00157_00_A_DEC_STD_157_OMNIBUS_Specification_Aug76.pdf
Coding the break point system in some kind of parallel C like
language seems way easier to me than to write this in gates. I don't
have a clue how to design the count registers.
I need to get #'s 1 and 2 working first and then I can dive into #3.
Thanks.
Hexadecimal displays til311, (pulled DIS1417's) can be found on ebay
for about $5 not counting shipping. This way you have easy to read hex
or octal numbers.
