I really like AI.

After a few weeks of practicing with AI to help me with coding, whether in VHDL or for developing Windows utilities, I must say that its contribution is very positive.

Of course, you have to adapt to its way of doing things. That means asking the right questions, and above all, structuring your own thinking in order to guide the AI engine towards the right options from the start. This allows the iterative process to proceed as efficiently as possible afterwards. 

That's how I was first able to create a small Windows application to convert binary files to the format required by the Efinix memory initialization tool. And without it really taking up much of my time, I integrated into this utility the ability to first run the 'make.bat' file for compiling the embedded Efinix project, before starting the conversion to the Efinix format :

Obviously, it doesn't have the aesthetics of modern applications. It only uses microsoft's basic API. But hey, it suits me perfectly and fully meets my needs.

I also developed another small application for working with serial connections. When I remember how much time it took me to achieve roughly the same result back in the early 2000s...

Another subject. I've been using Notepad++ for writing code for my embedded projects for years now. I did try Visual Studio, the interface that 'everyone' has been using for years. Sorry, but I can't stand this style of interface, which wastes a huge amount of intellectual 'bandwidth' while pretending to be a great help to developers, and which I consider to be a fantastic mind-jammer.

And then I just discovered ZED. The perfect thing. Simple, with the directory tree displayed on the left. The dark theme easy to configure: everything I like. However, I wanted an icon somewhere on some toolbar, capable of launching make.bat directly without having to go through the DOS command line. Impossible! Hmm... Hence the integration of this option directly into my conversion utility. And there you have it, in two clicks of the 'mouse' I save and directly generate the file ready to be integrated into the Efinix tool. 

So I end up with extremely simple and practical tools to carry out my experiments. So obviously, as I'm currently working on creating the SIO Z80 in VHDL to be interfaced with a Z80 core also in VHDL, I'm not able to perform real-time debugging, but I have the logic analyzer integrated into the Efinix tool to carry out the initial tests. Once the RX/TX part of the SIO is validated, I'll be able to use it to output debugging information to the screen.

This leads me to a few reflections on AI and, first of all, Microsoft. You might think I see evil everywhere, but I've always believed that Microsoft spends so much on research and development not for what they claim—that is, 'making the developer's life easier'—but quite the opposite, to overcomplicate it. While indeed giving the impression of working towards that goal. To do this, Microsoft 'cultivates' perpetual instability. That of applications, that of the associated documentation, and of course that of development tools. One of the tactics used to maintain its pseudo-technological lead.

When you really look at it, what's new since the release of the Macintosh? Huh? Tell me!
Since the late 80s, this way of doing things at Microsoft has fostered in me a deep disgust for the entire 'Microsoftian' ecosystem. Even though I mostly use development tools that run on Windows.

AI allows me to bypass part of these obstructionist strategies put in place by Microsoft. So, we're not yet at the 'all visual' stage, but it's true that recovering functional code from sentences in French, in my case, closely resembles what I mistakenly imagined Visual Studio would be when Microsoft released that IDE. I thought the development methodology would indeed be visual, meaning with less basic (and unnecessary) code to enter, but spending more time entering code with higher added value. Well no, it was just the development interface that switched to windowed mode. Right....

Hence the succession of development frameworks that have come and gone, except perhaps QT. In short, gigabytes to download, two years of training to use the tools, and undrinkable documentation. The quite useless and very low-quality work transferred to French universities in computer science departments, or what was in France School 42, affectionately nicknamed 'the pool'.

As a result, this 'French excellence' no longer makes sense either. And it's part of the university model that is going to, or rather already is, sinking into the abyss of obsolescence. Honestly, where are we going, if any old 'peasant' can train themselves and produce as well as our master's degree graduates!

A layered reflection: the French system is based on a caste system where anyone not from the lower or middle bourgeoisie is excluded from 'potential' success (other than financial success, which is reserved for the upper bourgeoisie) thanks to the watchdog that is the French education system. So then, if this 'no way' can be circumvented thanks to AI, what will happen? Well, actually it's very simple and it has always existed in France but is increasingly taking over from the educational exclusion system that is gradually becoming inefficient, simply through increasingly tight filtering of entrepreneurial initiative, and increasingly effective administrative violence towards those who shouldn't be there. Hence a seemingly quite probable vision of the road France is taking...

It's really time to look elsewhere... 

 

Develop with AI.

A few months ago, I tried to code a ZILOG CTC in VHDL. Indeed, I have a long-term project to implement the Drumulator rhythm box from EMU into an FPGA. Why, you might ask? Well, I really appreciate this machine for its simplicity. Plus, I consider it a good project for this kind of development. I've been coding the core of the machine for a few years. That's not really difficult since it just involves using the code of the Z80 processor called T80, which is directly available as open source. A few lines of combinatorial logic in the FPGA, and the Drumulator boots up. At least, its processor part.

The problem with the story is that all the real-time operation of the machine is managed by a Z80 CTC. During my tests, I simulated the operation of this CTC. Simulating means I ensure the CTC behaves the way I know it should respond. The only problem is that this virtual CTC is not programmable, and in fact, I only use the channel managing the display multiplexing. But anyway, the proof of concept was validated.

Indeed, after testing the analog part of this Drumulator, I decided to tackle this CTC anyway. I did find some VHDL 'codes' for a Z80 CTC on Internet, but I was never able to use them correctly for this Drumulator project. The reason is that these codes were designed to react according to the very specific needs of the people who coded them. In fact, they are not complete Z80 CTC codes.

So, a few months ago, I tried again to create this CTC. But in vain. I did manage to get something working with the display board I specifically developed for the Efinix development board, which features a Trion FPGA, but it was impossible to achieve stable operation of the Drumulator's keyboard/display interface. I ended up abandoning the subject because, on top of that, I lacked the proper tools for debugging the VHDL code.

Since then, I have reused the TRION development system for my MSX cartridge. The goal of this new cartridge implementation was to incorporate a processor directly inside the FPGA to handle file transfers from a PC. So, having used the internal processor provided by Efinix to debug the download process step by step, I thought I could use this internal processor to send stimuli to my CTC VHDL code, while also being able to retrieve the state of this CTC, again through the internal processor, and send the result to a text console. 

If needed, a few lines of VHDL code 'would be' added to allow the visualization of certain signals directly on the development board's LEDs. This therefore seemed like a very compelling possibility for developing and testing VHDL code. However, as I am not a VHDL coding expert, and having spent a considerable amount of time trying to code the CTC in VHDL, I had realized what could be called a mistake, not in analysis, but in the structure of the VHDL code. This made it harder to understand and very complicated to test without the proper tools. And that's where AI comes in.

I then posed what seemed like relevant questions to an AI and refined the subsequent questions to steer this AI in the direction that suited me best. After a few iterations, I realized that the essence of the CTC was there. Furthermore, the code structure was different from what I had personally developed, but this posed no problem for me in understanding its 'intended' functionality at first glance, and also in immediately identifying potential points of failure, and most importantly, for what reasons.

So, I began systematically testing the VHDL code provided by the AI with the help of the internal processor implemented within the FPGA. And, little by little, I first validated the writing to all the CTC registers, then the various selected modes of the CTC's 4 counting channels, and the reading of the registers. And then, inevitably, the time came to test the interrupt system. This is the stage, I believe, where I failed to validate my personal VHDL code developed a few months earlier. And this interrupt management aspect is crucial for the Drumulator, and obviously for all Z80 systems that use vectored interrupts.

I tested all aspects of vectored interrupt generation: the management of the IRQ pin, the interrupt vector, the daisy-chaining of interrupts, the IEI and IEO signals, and, most importantly, the handling of interrupt ACK from the Z80. It's the same as always—nothing is complicated once you understand how the CTC works, but coding everything correctly in VHDL is not that simple, at least for me.

As a result, I was able to start from the source code provided by the AI, modify it, adapt it, and test its functionality step by step as features were implemented. The outcome is that I managed to test 100% of the CTC's VHDL code functionality. However, I must note that I am not using this CTC with a "real" Z80 but with a Z80 simulated externally via the input/output ports of the embedded processor.

Obviously, I coded the I/O behavior of the embedded processor to react exactly as a real Z80 would. Therefore, I cannot say this CTC is 100% validated as being identical to the original CTC, but from a functional standpoint, it is. And I have a strong presumption that it will work with a VHDL Z80 implemented in this same FPGA. However, one should anticipate that there will be some 'edge effects' during the concrete implementation and use of this CTC.

So, what was the contribution of AI in all this? Well, the generated code served as a framework to follow for developing and testing the VHDL code. Paradoxically, the code produced by the AI seems quite clean and, above all, easy to follow. Obviously, where I thought it wouldn't work, it didn't. But I already knew the reason, so I only had to correct it. In fact, the AI doesn't handle different timing domains at all, but that's not a problem when you know how it's supposed to work.

Finally, I have a functional and tested Z80 CTC VHDL code, ready to be used for real with a Z80 also coded in VHDL inside a TRION FPGA. In terms of time spent, I would say the benefit is total. Of course, I have some knowledge of VHDL, as well as logic, programming, electronics, etc., so I wasn't starting from scratch. But in fact, the time spent on this project corresponded to 30% development and 70% testing, which is a very satisfying ratio for me.

Next step in this subject: attempting to get the Drumulator's processor section running, this time with the help of a "real" Z80 CTC.