65C02 computer with composite video generation

[DPax92]

Hello everyone!

A couple of days ago I started this thread viewtopic.php?f=12&t=5470 regarding the use of a 74166 shift register to generate a composite video signal. To better explain how the signal was generated, I have layed down the rest of the schematics of the system as I have envisioned it. I would like to ask your help to make sure that what I have come up with is actually going to work! This is the first time I draw an electronic circuit schematic so there may be many errors, please forgive me! I've also tried to make a simple timing diagram to better understand the system operation, which you find attached.

The system operates as follows:
The system clock is 8MHz. However, the processor and memory run at 1MHz, so that 1 byte of video data can be generated every PHI0 cycle. Each video character is 8x8 pixels, therefore each character is 1uS "long". A composite video line signal is 64uS long, or exactly 64 characters (albeit some of those character will be used for the horizontal sync and front porch part of the signal).
Each video screen is 312 lines tall, or 39 characters (with some characters required for the vertical sync signal). Therefore, the screen has an height of 39 "rows" and a width of 64 "columns", and each row is divided in 8 lines.

The clock signal is generated by U23, an 8MHz can oscillator. It is connected to a 74163 counter, which is preset to binary value 1000, so that it will reach Terminal Counter after 8 clock periods. The TC signal is inverted an fed as /PL to the 74166 shift register to load the new byte of video data every 8 shifts. The sync signal is controlled by a charachter code of $FF and is generated by the comparator U13.

The video data is provided by U11, the character ROM. The input address for U11 is obtained by combining a "line" counter, which cycles from 0 to 7, and the actual character address. That address is stored in RAM, in a 64x39 = 2496 byte memory section.

The ROM does not directly read from the RAM, buth rather a flip-flop register (U10) is used to hold the character address. The register is loaded from RAM when PHI2 is low, using circuitry described below.

A set of 3 counters is used:
- a column counter (U14 and U15), which counts down from 63 to 0;
- a line counter (U18) which counts up from 0 to 7;
- a row counter (U16 and U17), which counts down from 38 to 0;

The PHI1 signal is fed in the column counter, which generates the first 6 bits of the character RAM address. The other 6 bits are provided by the row counter. Each time the column counter reaches 0, the line counter is increased. This way, all the 8 lines of each character are drawn sequentially. When the line counter reaches 7, the row counter is decreased to draw the next row of characters. When the row counter reaches 0, the screen has been fully drawn.

Memory access is controlled by two buffers, one for the CPU and one for the video counters. The CPU buffer is enabled when PHI1 is low, while the video buffer is enabled when PHI2 is low. The character register U10 is updated by the RE signal shown in the timing diagram, obtained as the OR result of PHI2 and output Q1 of the counter U9. I've used this approach so that the RAM /CS input is high when the control of the RAM itselft goes from the VIDEO circuit to the CPU, in an attempt to avoid spurious RAM writes.

The rest of the circuitry is quite standard, as it uses the glue logic explaned in the primer to also connect a ROM and one or multiple 6522 VIAs (only one shown in the scheme), the only difference beying in the RAM enable system to allow video memory output. Additional circuitry could be added to allow to change the character set (up to 16 different sets could be used) or to change the video memory location (maybe to allow fast screen changes or to read from ROM for static images).



Do you believe that the hereby described system may actually work? I am really inexperienced when it comes to timings, delays, setup times etc. In particular, I'm not sure if the register U20 would actually get loaded correctly, as its clock input goes high while the RAM is disabled.

Thank you in advance for your kind help!

Regards,
Davide

[GaBuZoMeu]

Hello Davide,

I am a little lazy . I didn't want to check the timing details, just a few comments to your circuitry to verify:

- placing D1 parallel to C1 should ensure proper power on reset after power loss
- using PHI0,1,2 should work for older CMOS CPUs from Rockwell or GTE. At 1 MHz WDCs may work as well, but WDC did reference all signals to PHI2in (=PHI0, pin37) and do not specify how much PHI1, PHI2out lag. You should check this if you are going to use a WDC 65C02.
- the video counters (address generators) counting downwards? If this is true a character in your memory at address X is displayed right from the one at address X+1 - wanted ?
- an 8 input NAND gate instead of U13 (look for 74HC30) is cheaper (BTW. using character codes as sync is a nice idea!)
- perhaps you can use the 688 for selecting/separating I/O from ROM space - just a little narrower (one page).
- elsewhere in the forum there is a suggestion using 2 HC85 to separate RAM - I/O (onpe page) - ROM
- I would consider a way (using e.g. a handshake pin of your 6522) to route /WE (together with an OR gate) to the EEPROM - this would allow you to program it in circuit.

Regards,
Arne

[DPax92]

GaBuZoMeu wrote:

Hello Davide,
I am a little lazy . I didn't want to check the timing details.

I am super grateful someone is willing to spend his free time to help me with this, so definitely don't worry!

GaBuZoMeu wrote:

- placing D1 parallel to C1 should ensure proper power on reset after power loss

To be honest, I copied the reset circuitry from here: http://wilsonminesco.com/6502primer/potpourri.html I will consider your modification, thank you!

GaBuZoMeu wrote:

- using PHI0,1,2 should work for older CMOS CPUs from Rockwell or GTE. At 1 MHz WDCs may work as well, but WDC did reference all signals to PHI2in (=PHI0, pin37) and do not specify how much PHI1, PHI2out lag. You should check this if you are going to use a WDC 65C02.

I am going to use WDC's 6502 indeed. The way I understand it, the only component in which I "mix" PHI0 and PHI1/2 is U20 by performing PHI1|Q1. This should cause no issue however, because PHI1 is high and stable at this point, right?

GaBuZoMeu wrote:

- the video counters (address generators) counting downwards? If this is true a character in your memory at address X is displayed right from the one at address X+1 - wanted ?

By trying to find a way to explain why I chose this approach, I realised that it actually makes no sense I was thrown off by the fact that the terminal count can be reached, in this arrangement, only when the counter goes to 0 or to 255 (or so I understand). However, I can have the column counter count UP from 192 to 255, and the row counter count UP from 217 to 255, and get the same result.

GaBuZoMeu wrote:

- an 8 input NAND gate instead of U13 (look for 74HC30) is cheaper (BTW. using character codes as sync is a nice idea!)

I will do so, I wanted to use the '688 to have the ability to change the sync char, but to be honest I can't really think of a reason why that would happen.

GaBuZoMeu wrote:

- perhaps you can use the 688 for selecting/separating I/O from ROM space - just a little narrower (one page).
- elsewhere in the forum there is a suggestion using 2 HC85 to separate RAM - I/O (onpe page) - ROM
- I would consider a way (using e.g. a handshake pin of your 6522) to route /WE (together with an OR gate) to the EEPROM - this would allow you to program it in circuit.

I will definitely consider this. To be honest, I was trying to avoid "putting too much meat on the fire", as we say in Italy, in the sense that I was trying to minimize complexity as much as possible keeping some margin for growth.


Regarding the timing issue, the most pressing point to me is the RE signal transition from low to high which sets the U10 register, as it happens together with the disabling of the RAM output. The signal that goes to the RAM, however, goes through 3 logic gates before reaching /CE of U2. May this be enough to ensure that U10 is properly set?

King regards,

Davide

[GaBuZoMeu]

DPax92 wrote:

GaBuZoMeu wrote:

- placing D1 parallel to C1 should ensure proper power on reset after power loss

To be honest, I copied the reset circuitry from here: http://wilsonminesco.com/6502primer/potpourri.html I will consider your modification, thank you!

Stop considering my suggestion! It is wrong. The way the diode is used is fully correct!

GaBuZoMeu wrote:

- elsewhere in the forum there is a suggestion using 2 HC85 to separate RAM - I/O (onpe page) - ROM

FOUND: viewtopic.php?f=4&t=5180&p=60823&hilit= ... tor#p60823

Quote:

I will definitely consider this. To be honest, I was trying to avoid "putting too much meat on the fire", as we say in Italy, in the sense that I was trying to minimize complexity as much as possible keeping some margin for growth.

This is definitely a good approach - otherwise you might end up in a never ending design-redesign loop.

Quote:

Regarding the timing issue, the most pressing point to me is the RE signal transition from low to high which sets the U10 register, as it happens together with the disabling of the RAM output. The signal that goes to the RAM, however, goes through 3 logic gates before reaching /CE of U2. May this be enough to ensure that U10 is properly set?

My time is a little short now. I have to look into the specs to search for possible timing pitfalls later this evening.


So far.
Arne

[DPax92]

GaBuZoMeu wrote:

DPax92 wrote:

GaBuZoMeu wrote:

- placing D1 parallel to C1 should ensure proper power on reset after power loss

To be honest, I copied the reset circuitry from here: http://wilsonminesco.com/6502primer/potpourri.html I will consider your modification, thank you!

Stop considering my suggestion! It is wrong. The way the diode is used is fully correct!

Ah! Was that a trick question? I was not sure why you would suggest that but I assumed I was missing something and decided to study it later.

GaBuZoMeu wrote:

GaBuZoMeu wrote:

- elsewhere in the forum there is a suggestion using 2 HC85 to separate RAM - I/O (onpe page) - ROM

FOUND: viewtopic.php?f=4&t=5180&p=60823&hilit= ... tor#p60823

Thanks again!

GaBuZoMeu wrote:

Quote:

Regarding the timing issue, the most pressing point to me is the RE signal transition from low to high which sets the U10 register, as it happens together with the disabling of the RAM output. The signal that goes to the RAM, however, goes through 3 logic gates before reaching /CE of U2. May this be enough to ensure that U10 is properly set?

My time is a little short now. I have to look into the specs to search for possible timing pitfalls later this evening.

I was wandering, maybe delaying the signal that goes to U19 from U20 by means of a series capacitor and resistor to ground may solve the issue? I believe that the time needed to go LOW for RE is not a problem in any way.

Thanks again for your help!

Cheers,

Davide

[GaBuZoMeu]

Hello Davide,

it took me a while to went through your design. I think there are a couple of glitches that would prevent proper operation.
Let's start with the OR gate that drives CP of U10. It is connected to Q1(U9) and to PHI1. As PHI1 is nearly /PHI0 there is a chance to get a false trigger when Q1 went low causing PHI0 to go low (your timing diagram, second rising edge of CLK). As PHI1 always lags a little the OR gate may briefly get 0 and then 1 again. This would happen before the video addresses and proper data from video RAM is valid, instead you may latch the vanishing data from the previous CPU cycle.

I don't understand what you attempt to do with ORing /IRQ with the inverted clock of U10 (center, bottom) ???

The (WDC) VIA require RS0..3, CSx, and R/W to be valid some 10 ns before the rising edge of its PHI2. Using A0..3 from the multiplexed bus would always latch the wrong (graphic!) address into the VIA. And this is a reason, why using one or two magnitude comparators (HC85) as I suggested won't work the easy way as well: to select correctly RAM or RAM that part of the address decoder must use the multiplexed addresses, while the VIA select must be stable during the switchover from graphic address to CPU address!

Here is my suggestion: !! EDITED !! the 688 P=Q output is active low !!
You attach the 688 to CPUs A8..15 to select one page (out of the ROM area $8000..$FFFF) for your VIA (=> /CS2VIA).
You use a NAND gate (HC32 or HC00) to NAND muxA15 with /CS2VIA to get /CSROM.
You use muxA15 to get /CSRAM.
You use the typical circuit for generating a PHI0 qualified /WE for your RAM.
I would use an inverted Q2 for RAM and ROM /OE. This /OE becomes false when the CPU is going to latch the databus. The hold time should be fulfilled by the stray capacitances (there is now no driver for 1/4 of the cycle).

Instead of using HC244 buffer I would use HC257 multiplexer (with /E always low). There is only one signal to switch from graphic addresses to CPU addresses, and that signal is PHI0 (when using a WDC CPU, otherwise PHI2).

When PHI0 transits from 1 to 0 the CPU cycle is over and the graphic address appears on the mux bus. One quarter cycle later the /OE becomes valid (but /WE is gated with PHI0 so its always 1). The RAM drives the databus and when PHI0 turns to 1 this triggers U10 to capture the databus. Then the CPU posseses the bus...

PHI0 can still be used to clock the graphic address counters. The progress occurs when the address is not used.

One more suggestion:
If I understand your graphic address generator correctly U14, U15 generate the lower part (column) of the address and U16, U17 generate the upper (row) part. That would mean a certain address in your memory is always fixed associated with a character position on screen.

If you going to write a text editor and have to scroll up one line, you need to copy all characters from row 2 to end one row upward. That will take some time when running with 1 MHz.

If you insert an adder between U16, U17 and the address mux and use your via to feed the other inputs of the adder you can scroll up (and down) with a single instruction.


Regards,
Arne

EDIT(1): HC688 has active low P=Q output

[DPax92]

Dear Arne

GaBuZoMeu wrote:

Hello Davide,
As PHI1 always lags a little the OR gate may briefly get 0 and then 1 again.

That would have been bad!

GaBuZoMeu wrote:

I don't understand what you attempt to do with ORing /IRQ with the inverted clock of U10 (center, bottom) ???

That is a drawing mistake, U20 should perform an OR of PHI2 and the output of U19! That is to select RAM both during CPU and VIDEO time.

GaBuZoMeu wrote:

The (WDC) VIA require RS0..3, CSx, and R/W to be valid some 10 ns before the rising edge of its PHI2.

I did not know this, thank you very much.

GaBuZoMeu wrote:

Here is my suggestion: !! EDITED !! the 688 P=Q output is active low !!
You attach the 688 to CPUs A8..15 to select one page (out of the ROM area $8000..$FFFF) for your VIA (=> /CS2VIA).
You use a NAND gate (HC32 or HC00) to NAND muxA15 with /CS2VIA to get /CSROM.
You use muxA15 to get /CSRAM.
You use the typical circuit for generating a PHI0 qualified /WE for your RAM.
I would use an inverted Q2 for RAM and ROM /OE. This /OE becomes false when the CPU is going to latch the databus. The hold time should be fulfilled by the stray capacitances (there is now no driver for 1/4 of the cycle).

I like this idea a lot! Just to make sure, this will provide me a single page for I/O, and I will need to use additional glue logic to select multiple VIAs, should I decide to do so in the future?

GaBuZoMeu wrote:

Instead of using HC244 buffer I would use HC257 multiplexer (with /E always low). There is only one signal to switch from graphic addresses to CPU addresses, and that signal is PHI0 (when using a WDC CPU, otherwise PHI2).

Thanks!

GaBuZoMeu wrote:

If you insert an adder between U16, U17 and the address mux and use your via to feed the other inputs of the adder you can scroll up (and down) with a single instruction.

You understand the address generator correctly! However, with my approach, the vertical sync signal is provided by using a set of characters saved in RAM. By implementing your solution, I would mess up the vertical sync. I would need additional circuitry to generate the vertical sync in a different way, so that is it is independent from RAM.


There is one thing I do not understand regarding the VIA timing issue: should I simply connect the VIA to the non-multiplexed addresses?

Thank you for your kind help!!!

Davide

[GaBuZoMeu]

DPax92 wrote:

I like this idea a lot! Just to make sure, this will provide me a single page for I/O, and I will need to use additional glue logic to select multiple VIAs, should I decide to do so in the future?

Thank you. You may increase the I/O space by simply put some of the comparator inputs to static signal instead of Ax. But one page should be sufficient for many I/O devices (16 VIAs e.g.). And if you add I/O say on a piggyback board you only need 8 address lines routed to that board. And yes, you have to use additional decoders to implement more I/O.

One way of starting simple but still being able to expand is using a pullup resistor to tie CS1VIA to Vcc and to provide a connector with A0..A7, D0..D7, R/W, CS1VIA, /CS2VIA, GND, and VCC. There /CS2VIA is used to act as a sort of page flag that enables more decoders (like HC138). As most I/O devices have an (active low) /CS you can use that /CS to select the new device and deselect the onboard VIA - through a schottky diode that pulls down CS1VIA . Having no extension the on board VIA would appear 16x in the I/O page. With add-on the VIA is deselected one or several times.

Please: If you pick my decode suggestion for RAM and ROM do verify that! I didn't use paper and pencil to check that

DPax92 wrote:

GaBuZoMeu wrote:

If you insert an adder between U16, U17 and the address mux and use your via to feed the other inputs of the adder you can scroll up (and down) with a single instruction.

You understand the address generator correctly! However, with my approach, the vertical sync signal is provided by using a set of characters saved in RAM. By implementing your solution, I would mess up the vertical sync. I would need additional circuitry to generate the vertical sync in a different way, so that is it is independent from RAM.

Yepp, you are right. I miss your special way to create the sync signals. Your way is somehow smart and unconventional at least to me. So you need to shift the contents when scrolling is required. Or more logic to generate the syncs. I would give your way preference. Just to get it faster up & running

DPax92 wrote:

There is one thing I do not understand regarding the VIA timing issue: should I simply connect the VIA to the non-multiplexed addresses?

YES. It is necessary due to the timing requirements of the VIA itself. And in case of additional I/O use the non muxed bus as well.


Arne

[DPax92]

Dear Arne,

thank you again for you help! I like the fact that my approach is somewhat unconventional! I am now a bit in a hurry and I can't answer about your suggestions properly, sorry about that.

I have however a question because there is one thing I do not understand:

Quote:

I would use an inverted Q2 for RAM and ROM /OE

How is video data going to be available to be loaded on the register if /OE is high during the video cycle?

Kind regards,

Davide

[GaBuZoMeu]

yet another typo .. try Q1 (inverted)

(Q1 is high during the second half of each half cycle. With 1µs cycle this is 250ns, plenty for todays RAMs and ROMs.)

You may even consider to boost your system to run with 2 MHz! Then you have still more than 125ns access time. May be a little narrow for a typical 150ns EEPROM but worth a risk . If you work with flash type ROMs 4 MHz should be possible as well. Ha! then you could squeeze 256 characters (incl. syncs) into one row . Perhaps a bit too much, and then there wouldn't much RAM left for work


Have fun!
Arne

[DPax92]

GaBuZoMeu wrote:

You may even consider to boost your system to run with 2 MHz! Then you have still more than 125ns access time. May be a little narrow for a typical 150ns EEPROM but worth a risk . If you work with flash type ROMs 4 MHz should be possible as well. Ha! then you could squeeze 256 characters (incl. syncs) into one row . Perhaps a bit too much, and then there wouldn't much RAM left for work

That would be very interesting! However since the number of lines can not be increased (or so I understand), said characters would be very narrow! I think that with my setup I should be able to get about 48x38 visible characters on screen, which appears to be quite reasonable to me. ~250x38 would be quite strange!

In any case, I have updated my design to revision 2, implementing your suggestions.

I use the 688 to select page $FE for IO, which is right at the end of the EEPROM space without messing with the reset, irq and nmi vectors.
The rest of the circuit is quite similar to before, I simply changed the graphic visualization of the counters (which now count UP) and moved stuff around a bit.

The system therefore operates as follows (I am going to repeat most of the stuff you said, so to make sure that everything is correct and that I understood what you mean ):
The video address is generated as before, with the column counter going from 192 to 255 and the row counter going from 217 to 255. The column counter produces v(ideo)A0 to vA5, while the row counter produces vA6 to vA11. The row counter increases when the line counter U15 counts 8 lines (one row).
The 4 final bits of the video address are preset to 0111 so that the video memory is mapped in $7640-$7FFFF, at the very end of the RAM memory space.
The four multiplexers are controlled by PHI0 to generate the multiplexed address mA0-15, therefore when PHI0 is low the video address is active, and when PHI0 is high the cpu address is active.

As you suggested, the NON-multiplexed CPU address is used to select IO by means of the comparator. On the other hand, mA15 is used to select RAM, and the NAND of /CS2VIA and /CSRAM is used to select ROM. As of now, CS1 of the VIA is directly tied to +5V but I will add a second VIA very soon, then I will probably implement your expansion suggestion.

The R/W signal for the RAM and via is obtained by NANd gating the inverted CPU R/W signal with PHI0.

The /OE of the RAM and ROM is obtained by using inverted Q1, so that the output is enabled in the second half of each half cycle.

The buffer U14 is triggered by PHI0, while the contents of the video ROM are loaded on the shift register when U22 reaches the terminal count, i.e. when PHI0 goes low.

Do you guys believe I am ready to go?

P.s. do you think that the schematic is clear? I have considered drawing the scheme as shown in Daryl's SBC page http://sbc.rictor.org/sch2.html, so that there is less of a mess of wires, but drawing them with all the required connections also gives me more of an idea of a possible physical layout of the board.

Thank you, again, for all your kind help!!!


Davide

[Dr Jefyll]

I only glanced at this schematic, but I notice you're using more than one of the three clock pins on the 65C02 -- PHI0, PHI1 and PHI2.

Using two or three of the clock pins is how things are done with older 65C02's and with 6502's. The signal from the oscillator/whatever drives PHI0, and the other two pins drive the system. In other words, PHI2 is the same PHI2 used by the system; PHI1 is also available if needed.

This same arrangement is usually alright for modern WDC 65C02's, but it's not what WDC recommends. They recommend that only one pin be used. They say the signal from the oscillator/whatever should be used directly as PHI2 for the system, and also be connected to the pin formerly called PHI0. And it's recommended the pins formerly called PHI1 and PHI2 not be used (because their timing specification is no longer defined).

Yes, formerly called. WDC has different names for the pins:

• PHI0 (an input) is renamed PHI2
• PHI1 (an output) is renamed PH1O
• PHI2 (an output) is renamed PHI2O

.

If you plan on using a 65C02 that's made by WDC then it may be best to revise your schematic as noted, so only the PHI2 (formerly PHI0) pin is used.

Plan B would be to ignore WDC's suggestion.

Plan C would be this: have the osc. always attach to PHI2 (formerly PHI0). As for the PHI2 used by the system, provide a jumper to select between two options -- the osc. or the PHI2O (formerly PHI2) pin.

-- Jeff

[GaBuZoMeu]

Hello Davide,

First, you should strongly consider Jeff's remarks!

I scanned the schematic and found so far:
1) U4.PE should be tied to +5V
2) I would suggest a pull up R for /NMI - just an option
3) Using PHI1 appears to me as no good choice to clock the vAddress counter, PHI2 or U22.Q2 seems better to me.
4) You use the qualified /WE for the 65C22. I think it is better to use R/W out of the CPU directly (the 65C22 is designed to work with that CPU and has a direct connection to PHI2 (and in case of a WDC this should be U22.Q2)).
5) If you ever want to expand your IO you should insert a jumper in your /CS2VIA line.

Some further ideas:
a) If you haven't used all VIA port pins, you may consider using one or more to select various pages from your character ROM.
b) If you provide two traces (perhaps with jumpers) from U5./PE to VIA.CA1 and U7./PE to VIA.CB1 (or CA2) you could generate line and frame interrupts.
a+b) Counting lines and switching code pages might allow some funny "graphic" gimmicks.
c) Perhaps it may help to connect all /MR of your vAddress counters to either a VIA port (or handshake) pin or perhaps to /RST to have a "known" reset condition. (If you use the VIA to enable the counters you could prepare your video RAM before running the counters.)


Regards,
Arne

[DPax92]

Hello you all!


Sorry for my late answer, I have been very busy at work!

Dr Jefyll wrote:

If you plan on using a 65C02 that's made by WDC then it may be best to revise your schematic as noted, so only the PHI2 (formerly PHI0) pin is used.

That is definitely going to be my route here, thank you very much for your suggestions! To be fair, GaBuZoMeu introduced some of these issues to me but I assumed that since the timing of PHI0 should not be super critical, I could get away with it!

GaBuZoMeu wrote:

First, you should strongly consider Jeff's remarks!

I scanned the schematic and found so far:
1) U4.PE should be tied to +5V
2) I would suggest a pull up R for /NMI - just an option
3) Using PHI1 appears to me as no good choice to clock the vAddress counter, PHI2 or U22.Q2 seems better to me.
4) You use the qualified /WE for the 65C22. I think it is better to use R/W out of the CPU directly (the 65C22 is designed to work with that CPU and has a direct connection to PHI2 (and in case of a WDC this should be U22.Q2)).
5) If you ever want to expand your IO you should insert a jumper in your /CS2VIA line.

Some further ideas:
a) If you haven't used all VIA port pins, you may consider using one or more to select various pages from your character ROM.
b) If you provide two traces (perhaps with jumpers) from U5./PE to VIA.CA1 and U7./PE to VIA.CB1 (or CA2) you could generate line and frame interrupts.
a+b) Counting lines and switching code pages might allow some funny "graphic" gimmicks.
c) Perhaps it may help to connect all /MR of your vAddress counters to either a VIA port (or handshake) pin or perhaps to /RST to have a "known" reset condition. (If you use the VIA to enable the counters you could prepare your video RAM before running the counters.)


Regards,
Arne

Thank you for your suggestions! I already considered using 1 port of the VIA to control the char ROM and to jump video memory pages, e.g. to show static pictures from ROM or to allow for very fast screen changes. Also thanks for spotting my errors!
I will definitely add a line and a frame interrupt, however I tried to keep it as simple as possible to remove as many failure points as possible. Regarding traces and jumpers, I am currently planning to build the circuit using wire wrapping, so I believe all changes of this kind should be pretty easy.

Changing subject a bit, I would like to make a building log of the circuit, do you believe I can do it under this post or is there a more appropriate section?

Thank you again for your kind help!

Regards,

Davide

[BigEd]

A build log is a great idea, and I think it be fine as a continuation of this thread. It's nice if, when you have particular questions, you start a well-focussed thread on each question.