vendredi 1 août 2025
Back to basics...
Over a decade ago, I invested time in learning FPGAs. At the time, I thought it was a good idea—and I was probably right. Back then, microcontrollers didn’t have the performance they do today, and replacing all or part of legacy hardware could really only be done this way.
I had bought an Altera DE2-70 development board. FPGAs were all the rage, and although prices had become affordable, they started rising again. Even that wasn’t enough for Altera to survive on its own, as it was acquired by Intel a few years ago. Now, Intel itself isn’t in great shape either. The swan song of American tech?
I considered using FPGAs until 2019...
when I discovered GoWin FPGAs, which were much more affordable than Intel's. But then came 2020 and COVID—and boom, GoWin FPGA prices skyrocketed as well. Once again, I was stuck.
Then came Efinix chips. However, while I found GoWin’s development software somewhat clunky, Efinix’s tools are, in my opinion, a complete disaster—unintuitive, slow, and prone to crashing. Whether it's GoWin’s IDE or Efinix’s, neither is a good tool for development. But then again, that’s just my opinion, and I’m not a professional in the field.
My Big Mistake:
Whether using GoWin or Efinix software, I stubbornly tried to develop entirely within their ecosystems. And, true to my habit of persisting in error, I spent months wrestling with these tools. While I managed to get decent results with GoWin’s IDE—though with far more effort than I’d have liked—my attempts with Efinix’s IDE ended in outright failure.
My approach was simply foolish, and here’s why. The learning curve and overall usability of Quartus (Altera/Intel’s development software) had been, by far, the smoothest for me. I’d built solid experience with it and gained a strong command of VHDL. And here’s the kicker: VHDL works flawlessly with both GoWin and Efinix FPGAs. See where I’m going with this?
Yep—the much less stupid strategy would have been to develop on Altera’s platform first, validate the project there, and then port it to GoWin or Efinix. At worst, I’d only have needed minor adjustments for the target platform’s IP blocks.
Better Late Than Never
That’s exactly what I’ve decided to do: go back to an "easy" development environment to build my projects, then port them to my final platform of choice.
Luckily, Intel still provides the necessary software for the DE2-70 board—version 13SP1—so I’ve reinstalled it on my PC. And compared to my decade-old machine, my current computer should compile much faster, making this "old" board even more practical to use.
Tackling Video Signal Generation Again
This time, I’m revisiting video signal generation. While the DE2-70 has multiple types of RAM, it unfortunately lacks SRAM. And since I want my FPGA projects to be as portable as possible, I need to avoid platform-specific IP blocks—especially those handling dynamic RAM (DRAM).
Luck Is on My Side
Because over the past ten years, static RAM (SRAM) has improved significantly in capacity, price, and access time, interfacing SRAM with an FPGA is straightforward—aside from the high number of electrical connections, but that’s manageable.
Since I only need a modest video interface (limited pixel depth and color range), I can now get by with just a few SRAM chips while still achieving good resolution and enough colors.
And here's the small expansion board I plan to build to provide the DE2-70 with enough SRAM for video interface purposes. I've attempted similar expansions before, but the results weren't satisfactory in terms of access time. I believe I now understand why - this time, I'm taking a different approach.
Here's what the physical implementation should look like:
The GPIO connectors obviously won't be implemented on this side since the board needs to be plugged into the DE2-70's connectors. I've also added a small connector to enable SRAM loading from an external processor board - I remember not including this feature last time and struggling immensely when trying to use a Z80 processor embedded in the FPGA itself.
That approach made real-time debugging impossible, preventing me from running code step-by-step to verify the VHDL video interface behavior. Essentially, I had two potentially buggy systems in the same FPGA code - how could I possibly determine which one was causing issues? This time, I'm not repeating that mistake.
vendredi 27 juin 2025
Drumulator clone with STM32 processors.
There are times, when you truly don’t know which direction to take. At first, I partially replicated the Drumulator's functionality in a GoWin FPGA. Later, I attempted the same adventure with an Efinix FPGA. That’s when I ran into the challenge of completing the machine—specifically, implementing the entire Z80 interrupt system in this Efinix FPGA. I didn’t succeed.
During this process, I realized that developing something "new" in an FPGA isn’t very practical. The reason? Well, there’s no real-time debugger like you’d find on any microcontroller. So, I tried using a processor instead and went with a very interesting RISC-V processor. Unfortunately, as I progressed, I realized I wouldn’t be able to fully achieve my goal this way.
Then, I came across STMicroelectronics' announcement of a new member of the STM32H5xx family. Looking at its specs, I noticed it was very similar to the previous RISC-V processor—but with every feature doubled: RAM, flash memory, and operating frequency. I figured it was worth giving this microcontroller a shot.
Then, after a period where I could no longer get STMicroelectronics' STM32Cube IDE to work properly on my Windows machines (dealing with installation crashes, missing packages, and other issues), I decided to try again with this new processor. I installed CubeIDE and CubeMX - miraculously, it worked perfectly on the first attempt.
So I embarked on this new adventure, building on the various tests I had previously conducted with the RISC-V processor regarding waveform generation. However, I decided to approach this as two separate projects: first developing the analog section for sound generation and processing, and then - if successful - completing the control panel.
After numerous iterations, here's what the analog board should look like.
This is a first draft. I haven't attempted to route this circuit yet. I may need to make some adjustments to the placement of certain component blocks. And even assuming the circuit works as intended, I'll still need to verify the audio quality - particularly how it handles (or fails to handle) the various interference patterns generated by the processor.
I'm not done yet.
The positive aspect is that with this circuit and the tests I conducted while designing my MSX cartridge (which uses the same processor), I should be able to implement waveform switching relatively simply. This approach eliminates the need for larger PCBs containing multiple memory circuits.
Well, having worked on multiple units of the original Drumulator circuit during repairs, I have to admit the final PCB is significantly more compact and uses far fewer components. It's nothing like the board in EMU's machine.
Of course, there's still the control panel to develop. But even that only requires a few additional elements compared to EMU's version - just some LED drivers, two keyboard multiplexing circuits, and that's about it...
UPDATE 08/01/2025
My Experience with EasyEDA Pro:
I tried using EasyEDA Pro to design the analog section of the Drumulator. After spending some time with it, I’ve concluded that this development tool is absolutely not for me—it just doesn’t suit my workflow at all. The limitations and its general behavior ended up frustrating me to no end. As a result, I’m going back to good old KiCad to redesign the board, with a few minor tweaks. The overall concept remains the same, but I’m changing how some components are physically laid out. Normally, I believe that fewer different elements in a system mean easier debugging and better reliability, but this time, I’m doing the opposite—adding more components to simplify things. Surprising, right?
Tech Rant: The State of Software & Forced Bloat :
And speaking of annoyances, I’m getting increasingly fed up with how systems and applications behave these days. The way they push—or rather, force—users to accept commercial nuisances is beyond frustrating. I’ve already stopped using Firefox except for certain sites that require specific resources. Otherwise, I never use Bing, and Opera and Firefox are now limited to just a few websites.
Unfortunately, I’m stuck with Android on my phone for now, but these so-called "updates" are just excuses to bombard users with checkboxes, tricking them into installing bloatware. And even then, some apps can’t be refused upfront—you have to uninstall them afterward. Needless to say, I won’t be switching to Apple. It’s the same nonsense, just worse and more expensive! This trend is spreading to more and more software.
My Solution? Linux + Minimalist Setup:
So, my plan is to set up a small Linux machine and keep my Windows PC strictly for development tasks. On Windows, I even use a portable browser instead of installing one. As for my phone, the only reason I’m still on Android is one essential app. The second I find an alternative, I’m switching back to my trusty Siemens B615!
jeudi 19 juin 2025
MSX FLASH cartridge.
I just received a few prototypes of my new FLASH cartridge for MSX computers.
In the past, I created several prototypes based on the copy/paste file principle under Windows.
This approach caused issues with the low-level connectivity of the USB bus, which meant that after developing the very first cartridge prototype equipped with a processor that handled all the operations, I had to switch to using two processors. That's when I created the second iteration of my cartridge.
With this second prototype, I was able to observe in situ all the transfer issues caused by the asynchronous nature of USB transfers. In particular, it's never possible to know whether a transfer was successful or not. Worse, there's no way to determine if a transfer is complete or not, hence the impossibility of controlling anything.
So, I had to change my approach and opted for a more reliable protocol. I decided to use the Ymodem protocol instead, which allows for full control over the sequence of operations. On Windows, I relied on the Hterm tool, as it provides a stable implementation of the Ymodem protocol.
I also chose a new STM32H5xx-type processor, which has more built-in resources than the RISC-V circuits I used before, greatly simplifying the schematic.
The result of this new design is as follows:
jeudi 5 juin 2025
STM32 processors, in fact...
I mentioned in a previous post that I wasn't about to use the STM32 family of processors again. I had been testing with an STM32H5xx processor, using the STM32CubeIDE development software and its 'friend', STM32CubeMX, since for the first time in a long time, the software suite was working for me.
It's true that the new STM32H5xx processor family is interesting for several reasons. On the one hand, these processors are fast, they can operate at up to 250 MHz and, above all, some models offer 512 KB of flash memory and more than 272 KB of SRAM memory.
I then thought that this could allow me to develop a new version of the MSX cartridge that could be loaded via the USB port.
In my previous cartridge version, I used the principle of external mass storage. To simplify, the MSX cartridge behaves like a USB flash drive. Subsequently, the file recovered on a FAT12 file system type media, was recovered and copied in RAW format to the cartridge second processor.
This is what the cartridge looked like:
In fact the right processor retrieved the file through the USB port connected directly to a PC. Then sent the retrieved file directly in RAW format to the second processor which 'provided' the data directly to the MSX computer.
This system wasn't easy to develop for a number of reasons. Most importantly, file transfer from a PC is unreliable. Not because the data could be corrupted, but simply because it's completely impossible to know if the entire file has been transferred!
And that's not practical at all!!!
Additionally, the processors used were a bit more modest in terms of Flash and SRAM resources.
So, I wondered if it would not be relevant to try the adventure again on one of these STM32H5xx processors.
However, I had two 'problems' to resolve. The first is that I no longer have to use file transfer in the file system sense, but rather a transfer in the sense of direct byte transmission. So I chose to use a serial file transfer using the YMODEM transfer protocol.
The Ymodem protocol allows you to receive the name and size of the file, which can be interesting, but above all the transfer is done in specific blocks with possible CRC correction, which suits me very well.
The second problem for me is not having to use what seems to be something downright overly complicated on the system provided by STmicro (see my previous post) : the USB function of the STM32 processor. So, I decided to go straight for a small external USB/serial converter circuit.
This last point will also allow me to set up good galvanic isolation between the PC and the MSX computer.
In short, this change of direction should allow me to make the operation of my MSX cartridge more reliable. Because although I have never had any operational problems with my own MSX computer, it has happened that it did not work correctly on other MSX, without me being able to determine the reason for these malfunctions.
Here is what the first prototype of this new study looks like, based not on a RISC-V processor but on an ARM processor from the STM32H5xx family :
To summarize, this new version offers a faster processor, a more secure and controllable file transfer system, and better galvanic isolation.
I have already carried out some preliminary tests on a study board, namely transmission with Ymodem and programming of the internal flash of the processor.
Additionally, I should be able to install a more convenient status indicator system than the two original LEDs.
This new cartridge should also allow me to automatically reboot the MSX computer without using an external system. It should also be able to integrate different mappers for a total of 256KB of memory. Finally, my system should also be able to be updated using the same file transfer mechanism. I have already successfully performed code relocation tests on this new processor.
mercredi 14 mai 2025
Sometimes...
We repair electronic machines for people who are often nice but from whom we don't hear anything once the machine is back on.
And then sometimes we receive a little gratitude indirectly:
![]() |
https://www.starwaxmag.com/custom-page-detail/125836-tomska |
The original post is here : Facebook
A thought for Philippe, who looks at my blog from time to time 😉
lundi 28 avril 2025
I love STMicroelectronics :-(
It's been a while since I've looked at this manufacturer's microcontrollers. The reason was simple: over a fairly long period of time, I haven't been able to install their STM32Cube IDE and MX development system without the installation of these tools crashing miserably.
And then recently, I got caught up in an ad promoting the benefits of the STM32H5. It's true: the amount of FLASH and RAM are interesting, as is the maximum operating speed of this circuit.
So, 'for a laugh', I tried installing the IDE and MX. Unbelievably, the installation went smoothly. I was very surprised. But anyway, let's move on...
I wondered if I would be able to produce the classic 'Hello World', namely the flashing of an LED, in less than an hour. To my surprise again, I was able to do so.
At this point you must be wondering where 'the wolf' is hiding?
Well in the USB my friends!
Yes, STMicroelectronics has abandoned the classic USB management, present in the CubeMX graphic configurator, to replace it with the USBx driver.
And what is this thing? Well, a driver that has to do with Microsoft and Azure, and more specifically Azure RTOS. YES!!!
lundi 7 avril 2025
Drumulator : with RISC-V processors.
For now, I'm working on the analog output board of the Drumulator. After testing the feasibility of my concept, with the help of a few off-the-shelf boards, I'm starting to draw up the schematic diagram for the audio section of the Drumulator.
The schematic isn't complete yet, but there are already number of components.
jeudi 27 mars 2025
Drumulator : with RISC-V processors.
And meanwhile, I'm making progress on the subject.
And it doesn't have to be simple! My goal is to make it 'easy' and not too expensive to manufacture. The idea is to design a quality machine that has a good sound.
The options to consider, the best use of available resources, and other considerations mean that it takes a little time to develop. But in the end, I enjoy that moment when, after many development difficulties, I feel that the final solution is taking shape.
lundi 24 mars 2025
The Cody Computer : processor board assembly
As a reminder, the Cody computer is a small machine that is, in absolute terms, could be considered no more interesting than any other project of this kind.
Over the past twenty years, hundreds of projects like this one, and probably even more technically interesting projects, have seen the light of day. To my knowledge, all of these projects quickly fell into oblivion. I'm thinking in particular of Geoff Graham's Colour Maximite II (https://geoffg.net/maximite.html) project because I followed this project for years, and then, nothing...
All information about Project Cody is available at this address: https://www.codycomputer.org
But then why be interested in Cody?
The main point that caught my attention about this project is the excellent documentation that the author has produced on his machine.
Beyond the machine's own characteristics, some of which are unsuitable for me, this documentation makes the assembly, use and programming of the machine completely understandable. All the documentation is in a 'small book' pdf that can be downloaded from the project website: https://www.codycomputer.org/TheCodyComputerBook.pdf
Furthermore, Cody comes in the form of an electronic board that could almost fit inside a ZX81 case. But it is of course more powerful than a ZX81. Equipped with a 6502 processor, it would actually look more like a Commodore C64 with less complex electronics. So, I find that it brings together two interesting aspects, the ease of understanding of the machine, and the power of a Commodore 64. Interesting, right?
So I decided to build this small computer to judge how difficult it was to make. My latest experiment in this area concerns the construction of the Omega computer, type MSX, by Sergey Kiselev : (https://github.com/skiselev/omega/blob/master/Mainboard/images/Omega-Keyboard_and_Mainboard-1.1.jpg)
![]() |
Omega |
![]() |
Cody |
In comparison, the ZX81's board :
Cody therefore looks very much like a ZX81 kit to assemble from the time without more difficulty, but with a more interesting result than the ZX81. So to assemble this little computer, I put myself in the mental conditions that were mine when I was a teenager and I didn't know much about electronics.
I obviously had the printed circuit board made at JLCPCB (that wasn't possible at the time) and bought the four main components, namely the two processors, the RAM and the I/O circuit. I already had the EEPROM. The bus driver, a 541 and the CD4051 were taken from my stock of more or less new components...
I assembled the machine, not with the help of the sheet, but by scrupulously following the instructions and the assembly chronology as indicated in the documentation. It takes barely more than an hour of work to achieve this result:
I almost assembled this board in 'brute force' mode. I didn't have the recommended 3.3V regulator. I put another one in CMS version. The resistors for generating the video signal are also not exactly those recommended. There are a few Ohms of difference. I even created one of the resistors by putting in series two resistors that I had, for a result very close to the original desired value. In short, I tried to make a clean assembly, but with certain tolerances of the type that a beginner could make.
I also didn't buy a original 'Prop Plug' to program the Parallax circuit, I figured the FTDI-style USB/Serial adapter would be enough.
After testing the board's power supply, and initially setting up the Parallax circuit and its EPROM that I programmed using the Parallax tools, the machine did not start correctly, or even did not start at all, and displayed some time parasitic characters on the screen: not a good sign and a slight disappointment. I thought it would start without any problem.
First thing, when programming the Parallax circuit with the Propeller Tool software (https://www.parallax.com/propeller-2/programming-tools/), I had a communication error message telling me that the communication was not going correctly with the processor (/RTS used as RESET signal). In fact, and after several tests, I realized that when acknowledging this error, the application was still programming the processor correctly. I was able to verify with the oscilloscope that I was getting a composite video signal at the CVBS output.
The way Cody is built, assuming the Parallax circuit was programmed correctly, and assuming the 65C02 processor was new and should work, all I had to blame was the 74HC541 bus driver circuit. So I replaced it with another circuit, also from my stockpile, and voila!
As you can see, I went into full DIY mode, with a less than rigorous assembly procedure, but still practicing quality welding, and the machine worked almost the first time. The initial malfunction was only due to a defective component in my stock.
This way of doing things, not entirely according to the rules of the art, allowed me to validate the high feasibility of assembling this small machine, even by a relatively inexperienced person. I expected this result, which is why I 'pushed the vice' to really assemble Cody in beginner mode.
Because there's nothing worse than demotivating someone from the start who doesn't know much but is eager to learn. The possibility of error must be present without it leading to an intellectually catastrophic disaster. This is why I particularly appreciate the approach of the author of this little machine.
And now? Cody doesn't have an operating system but programs itself directly in Basic. It's ideal for getting started in the wonderful world of microcomputing. I haven't written a single line of Basic on this machine yet, and for good reason: I haven't built the keyboard.
Personally, I don't find it very useful to build a specific keyboard for this kind of machine. Obviously, the look loses a bit if you use a standard keyboard but hey, that's my opinion. So I'm going to do what I already did for the Omega, I'm going to create a USB interface allowing you to directly connect a standard USB keyboard to Cody, I find it more practical. The user experience is more comfortable, especially if, as a passionate person, you start spending long hours programming on this little machine...
mercredi 5 mars 2025
Drumulator : with RISC-V processors.
Well here we are...
First in a long series of iterations on building a Drumulator clone. As a reminder: after trying to create a Drumulator using FPGAs, I gave up following the time wasted on the last used circuits from the Efinix brand.
Additionally, real-time debugging is much easier with microprocessor tools than with FPGA tools. Well, basically, for the type of subject in question here, it ultimately seems much more relevant to me to start on a microprocessor basis than on an FPGA basis.
In addition, this should also allow me to offer more capacity for the machine envisaged, while retaining exactly the same characteristics, including the non-linear 8-bit sampling which gives all its charm to the Drumulator.
To begin this series of micro-developments, I will focus on the sound generator since, ultimately, it is this generator which is the heart of the machine.
On the original machine, it is a whole series of logic circuits associated with static RAM which manages this subject. Moreover, EMU calls this sound generator, a 'sound sequencer'. The goal here being to do the same thing but using the minimum number of circuits and the minimum number of electrical connections, I am therefore going with a converter whose digital data will be supplied by the SPI bus.
In the continuation of this development, I will also try the use of an SPI type wave memory, in order, again, to minimize the need for connections. All this will have the effect of reducing the cost and electromagnetic radiation.
So, for now, my very first test is to set up a reliable SPI link to the digital to analog converter.
I'm not going to detail the whole process here, but basically it involves generating an SPI bus with the characteristics expected by the audio converter. That is to say, the number of bits expected, the different polarities of the signals and the frequency acceptable by the converter, here 10Mbits maximum per second.
So I configured the registers of the processor used to match the needs of the converter. I even made the maximum frequency dynamic to always configure the maximum frequency achievable by the processor according to the configuration of its clocks, but while always remaining less than or equal to 10MBits per second.
lundi 3 mars 2025
Drumulator : with RISC-V processors?
When you want to recreate an existing machine, is it better to recreate the hardware to install the original software, or to create new hardware but with the need to also recreate the software system?
After years of various tests, I chose: I recreated absolutely everything.
jeudi 20 février 2025
EMU : STOP!
Since my last post about trying to repair the EMU1, I've done a whole bunch of new tests. I also replaced a few integrated circuits. The result is that I haven't progressed one bit.
I still can't load the loading utility from the floppy disk. Whether it's from the actual floppy drive, or whether it's using the HxC emulator.
I now believe that I have carried out all the tests that I could. The problem in this story is that I absolutely don't know the loading program written in the boot EPROM.
It is not impossible, for example, that the motherboard must be correctly mounted in the machine so that information coming, either from the digital/analog conversion boards, or from the control panel, allows the program to exit a loop in order to actually process the data read from the floppy disk.
From what I have done as tests on the motherboard, I know that all the logic for shaping the signals coming from the floppy drive works. As well as serial reception by the SIO/2. Selection by a few PIO output ports also works. Finally, I know that the RAM does not have defective memory.
So I was finally able to test the signals concerning the triggering of DMA when reading floppy disks. And here too, everything seems correct to me. However, the machine obviously tells me that the data coming from the floppy drive is not reliable. I don't understand the reason.
However, the fact remains that the data bus signals are horrible! I also worked on this aspect, managing to obtain very square signals. However that wasn't enough, I always get into a loop trying to read the data without ever getting out.
So, given the time spent doing all these tests and the results obtained, it is high time to stop wasting it like this.
I reassembled the machine. I'm now opting to throw it into scrap metal because in its current state, it's worth absolutely nothing.
No final decision yet...
Regarding the FPGA of a Drumulator, I'll stop there too.
I twice managed to integrate the Drumulator's processor core into two different brands of FPGA. I have been trying the same thing on TRION type FPGAs from Efinix for months now without achieving anything usable.
In fact, right now I know the heart is starting well. It shows me the message 'bAd.' at startup, but immediately, by displaying anything.
This is all the more strange as the interrupt system works well since the message is displayed correctly. But afterwards, the processor seems to go 'I don't know where'. And this is not very easy to test with a standard logic analyzer due to the difficulties in triggering signal sampling.
In addition, I must add that the development software is a bit 'boring': not flexible and above all really very slow. This thing is a real pain, even with a powerful PC. So as in addition, the development tool tends to annoy me a little, and the pseudo-integrated simulation system is not helping the matter, and given the time I have already spent trying to integrate the heart of the Drumulator into this FPGA, I will stop.
Also, I don't know the intricacies of the system of this machine. In fact, it is extremely difficult to move forward when something goes wrong. Indeed, there is virtually no way to know for sure where the problem is coming from. After a while, this type of situation is simply no longer bearable.
The idea was to build a hardware environment compatible with the Drumulator in order to be able to run the machine system there. It seemed 'easier' to do. Observations made, I now say to myself that it would undoubtedly be less complicated to develop everything using equipment that is more practical to use.
I've been working a lot lately on small RISC-V microcontrollers. The development software, which was not very practical a few years ago, has been superbly improved in recent months. And above all, working in this way allows you to carry out debugging in real time. And that’s super interesting.
And as these small microcontrollers operate internally at 144MHz, this provides quite acceptable processing power for this type of machine. And after all, I did this to recreate a programmable clock whose behavior is identical to that proposed in the Texas Instruments TMS1122 of the time!
So I'm still a little sorry for this situation because these two projects made me consume a lot of time without achieving any result. Not to mention the psychological aspect of it, because it is not easy to persevere when there is no sign of improvement. It's even more difficult to abandon a whole job to start again with another method.
But hey, to move forward, you still have to make choices, at some point...
The positive point of all this was to realize that I have lost a progression methodology that I had when I was very young. I know the reasons of this degradation...
jeudi 13 février 2025
EMU1 : no real progress lately :-(
In fact, I still cannot read the contents of the EMU1 boot disk.
On the other hand, I accumulate the validations of parts that have become or verified functional.
Basically, and following major problems of a really diverse and varied nature, I now know that:
- The SIO/2 serial converter is functional.
- The PIO is also functional on its new circuit support.
- the RAM is free of defects because I can check its operation with the small test program I created.
At this point, I don't know if it's the floppy drive that's the problem. So I put an HXC floppy emulator back into service.
And, good and bad news: the floppy disk still does not read, but, and this is the interesting fact, I obtain exactly the same result as with the 'real' floppy disk drive of the machine.
By chance, and passing through Paris, I obtained two replacement integrated circuits which are used to extract the clock and data from the signal coming from the floppy disk drive.
I have already had the opportunity to talk about this store on my blog. Since then, the window has been somewhat redesigned
The goal is to change these components:
I had already studied the signals provided by these two components a little and found nothing to complain about. This was confirmed. Their replacement by two new circuits did not change anything!
This allowed me to check with the logic analyzer that the signals were correctly recreated, as well as to determine the operating terminals. I placed the value of this potentiometer in the middle of this area. So, from that side, everything seems okay too.
I had already had the opportunity to discuss the Emulator's DMA system. In fact, there are 8 DMA channels that manage the sending of data to the converter boards for sound generation. However there is a particularity, the first DMA channel is 'usurped' on demand by the floppy disk reading system thanks to the SIORDY signal.
vendredi 31 janvier 2025
EMU1 : it's still progressing...
The last time I posted about the EMU1 motherboard refurbishment, I stopped at the detected problem of the system reset. In fact I was able to see that the new SIO/2 put in place of the original SIO/2 did not start and did not allow me to run my monitor program developed to test the onboard RAM.
While the original SIO/2 port #1 works fine, I realized that the 'new' SIO/2s require a bit more initialization time. So, I studied the RESET system of the board and connected the SIO/2 reset pin directly to the main reset system. This did not allow the SIO/2 to work properly. Obviously, if the system developed by EMU did not provide a slight delay at the processor startup, and this is most certainly the case, the new SIO/2 cannot start. And since it is the SIO/2 port #0 that communicates with the floppy drive, obviously, it can't work.
So I opted for a somewhat 'baroque' solution: I took out the reset pin of the processor in order to generate a manual reset whenever I want. This reset does not reset the other circuits on the board. Therefore, I can start the processor once I am sure that the SIO, the CTC and the PIO are correctly initialized.
The reset button is the left switch. I also added another switch to simulate the 'UPPER' loading switch on the EMU 1 control panel.
No more unexpected start-ups of the floppy drive motor. Nothing at all happens!
So I simply continued testing the signal values on the input and output side of the keyboards. And I found something interesting. While the Y9 output of the IC125 circuit is high, 3 inputs on IC121 and IC122 are low. Logically, all the inputs of these two circuits should be high.