It's a good idea. But to be honest I'm not that fussy. And not being fussy increases the risk of a problem, as Garth explained.

Nice to see this project coming along. I particulary like the schnazzy paint job!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

That looks awesome. I see old DirectTV boxes and other crap at thrift stores all the time. That and old 5-port switches, etc. I've wondered what junk like that would make good enclosures.

I think the next time I go thrifting, I will be looking at that junk differently.

_________________
Cat; the other white meat.

Hello everyone!

I'm glad you like the design! the front panel is temporary, I will put something to cover the unused screw holes on the side.

In the mean time, some progress to report. I have complete the wiring of the video signal generation circuit and I'm testing it! I've found some issues with my original design which I will correct in the schematics: the /PE signal of the cascading counters should not me /TC of the second counter but the NAND of the TCs of both counters.

To test the video circuit, I have hooked up the Arduino to the circuit to use it as a very simple logic analyser. I've also written an Octave script to visualize how the video addresses are generated. I've encountered some issues which I will investigate this evening.

Kind regards,

Davide

Hello everyone!



I've got some progress to report, but also I really need your help.



I've tested the video address generator and after some modifications, it now works correctly. I've obtained a nice graph with Octave to show how video memory is accessed which I will soon post.

Now, however, I appear to have issues with memory writing. What happens is that the memory fails to write randomly (at non repeatable locations). I tested it by writing 2KB of memory to an equal and known value, and what I see is that around 5-10 random locations in each page are not correctly written and have random values. Reading, on the other hand, is absolutely fine.

Initially, I assumed the issue may be caused by high frequency, so I switched back to the Arduino generated clock which worked absolutely fine up to now, but the problem keeps appearing. I know that ringing and ground bouncing depend on rise and fall times and not by frequency itself, however, until I added the video generation circuit, I did not encounter any issue.

What I did next was to disable the memory address multiplexer, forcing it to always give access to the CPU and no access to the video circuit. All the issues disappeared and now I write to memory with no errors.



I tried to understand what the problem may be, but before doing that, I will describe the circuit (theoretical) operation to you so that you do not need to scroll back to the beginning of the post:



I divide the 8MHz input clock (used to clock the serial video generator) by using a 4 bit adder. I obtain PHI2 from the 3rd bit of the adder (a 1MHz wave). I also use the output of the 2nd bit, which I call Q1 (a 2MHz wave, see below).

I'm using the typical memory sharing approach to use RAM both for the CPU (when PHI2 is high) and for video memory (when PHI2 is low). PHI2 is used to select the output of an array of 4 74HCT257 multiplexers which provide the necessary address switching between CPU and video. R/W is inverted and gated with PHI2 to ensure that R/W is forced HIGH when the video circuit is accessing memory.

/CS of the RAM is bit 15 of the multiplexed memory address. During a typical RAM access cycle, /CS will be LOW for the entire duration of PHI2, because the video memory is in RAM.

RAM /OE, on the other hand, is obtained from the aforementioned Q1 signal (inverted), thus it is LOW during the second half of each PHI2 phase (so, during the second and fourth quarters of PHI2).

What I believe may be the issue here is that both R/W and the address multiplexers are gated with PHI2. It is my understanding that the 6502 sets R/W LOW at some point during the first half of PHI2 (hence the need to gate it with PHI2). From the 62256 SRAM datasheet, I understand that the address setup time tAS is 0. However, the propagation delay of the 74HCT00 NAND gate I use to obtain \WE is 7ns, while the propagation delay of the multiplexers is 17ns.

Therefore, what MAY be happening is that the /WE signal goes LOW BEFORE a valid address is setup, causing a wrong address to be latched. However, I don't know when the memory address is actually latched (I believe that happens when \WE goes LOW?), and what role \OE plays in this.



Should this be the issue, my workaround would be to also gate R/W with Q1, so that \WE goes LOW only during the 4th quarter of PHI2. This period would still be 250ns long, therefore I believe that I should still be able to comply with other timing requirements.



Do you think I am on the right path? May this be my issue, and would my solution work? I really have no experience with timing constraints and really need your help!



Thank you all!



Kind regards,

Davide

I think you may be on the right track. A diagram would be a big help, I think. As you note, every gate and every multiplexor has a delay, so if you need one thing to happen before another, you do need to add up a collection of maximum delays and a collection of minimum delays and compare the two totals. An easy and reliable way to ensure one thing happens after another is to gate with a timing signal, which is what you describe.

There are two hazards with writing: on the leading edge of a write enable, you need to be sure all the addresses are correct and stable. And on the trailing edge of a write enable, you need to be sure all the addresses and the data remain stable for some short delta of time. Which might be zero nanoseconds, depending on the chips you're using. And those requirements are as measured at the RAM, which means taking into account the glue logic propagation delays.

(On a pedantic note: it's conventional to use Phi2 to gate control signals, on the grounds that half way though the cycle is usually late enough to be sure the MPU's outputs are stable and early enough to leave time for the RAM or peripheral to operate before the end of the cycle. However, Phi2 is not defined to be the right time to act, it's merely convenient. There are computer designs which subdivide the clock cycle more finely and use other timing references which are not half-way through the cycle. So, be aware that Phi2 is merely the usual solution: it may not be right for you, especially if you're pursuing a high clock speed. It probably will be right for you. But when someone says "It is my understanding that the 6502 sets R/W LOW at some point during the first half of PHI2..." I find I need to write a pedantic note!)

Thank you very much for your help, and sorry for the lack of a diagram, I wrote the post during my train commute to work with my phone

I am absolutely ignorant, so please be as pedantic as you like, those things that are obvious for many of you are all valuable lessons for me!

I will test the solution as soon as I get home then, thank you!

Kind regards,
Davide

Hello everyone!



Very important progress to report! Finally, success! After 1 week of failure, I've obtained a beautiful...black screen! However, this means that the horizontal sync signal is correct, because I am using a composite to vga converter box that shows a blue screen if no input is available.



But let's go in order. I implemented the solution mentioned a couple of posts ago, and I went from having random writing issues to having...no writing at all That is because, as I said, I used inverted Q1 as /OE of the RAM, meaning that I had /WE and /OE go low at the same time, which I understand is no good.

So, I tied /OE to ground and finally I could write with no errors. Success? No, because the video circuit could no longer read data from RAM. I believe that is because che CP signal used to load data from RAM to the video register is PHI2. Before, /OE would go high when the address was multiplexed back to the CPU, meaning that, as GaBuZoMeu said, stray capacitances allowed the data to remain valid even if there was no driver (or so is my understanding).

With /OE tied to ground, there would always be a driver, causing the data to change while it was loaded to the register. No good.



I went back to the drawing board, and rewired the entire glue logic. Now, I have R/W gated with PHI2 and Q1, as described above. /OE is tied to ground, but the video register is loaded after the first quarter of PHI2, when the data is nice and stable, and now everything works as expected. Naturally, I had to write a couple of simple routines to write the horizontal and vertical signal characters on RAM.

I imagine this is all quite confusing, so I will post a timing diagram and a schematic with all the modifications .



Now that almost all the basic components are properly operational, it is time to get some characters on the screen. I'm designing the font with pen and paper and getting the hex chars to put in the video ROM. Before I do that, however, I must still test the serial shift register I use to generate the actual video signal. I will therefore add a temporary char ROM with some basic test characters and see how it works.



Thanks for all you help.



Kind regards,



Davide

Hello everyone!

Finally, success! After some more fiddling (I realized that my vertical sync circuit was flawed but I corrected it relatively easily) and after finding out that my darn composite to vga converter box only works with interlaced video ( ) I finally have a working monochrome composite output! The screen is about 48 columns x 38 rows (I still have to measure them appropriately).

I am still in the process of writing the necessary routines for proper scrolling, printing, etcetera. I am also designing the character set (the one you see in the picture was put together quickly for testing purposes).

I will soon add the revised circuit with additional explanations.

As the picture says, thank you all!

Davide

Congratulations!

I'm happy that you get your baby up and running! Interesting font - reminds me a little to Asterix at Olympia

Keep us informed!


Arne

Finally!

Grats on your success!