Over the weekend I finished porting all DC2N5-LC drivers from the Blue Pill to the Black Pill. In particular I was missing the key handling driver, which is now in good working order.
I think I might actually port the DC2N5-LC main firmware to the Black Pill before Spring as that’s definitely an achievable target. What sets me back is the fact I am really close to having it finished, which is usually an anticlimax 😀
Here’s the finished development circuit for the Black Pill that I have been using for porting code.
I have been having a look at custom V-MAX! sectors in NIB and G64 files recently. Today I added a sector ID decoder to CBM Flux Studio.
The interesting thing that I was able to appreciate on the back of such change is that a G64 of “After Burner” side 0 produced by KryoFlux’s DTC shows that all tracks (but tracks 1, 17, and 18, which use CBM sectors) have the write splice set shortly before V-MAX! sector 0 (for tracks 1, 17, and 18 the write splice is set before CBM sector 0). This suggests DTC is handling the conversion to G64 in a sensible way, adding padding outside of data sectors.
I plan to add a whole block decoder next, along with an option to align V-MAX! tracks and possibly shorten them as done by LordCrass’s tool Revolution-V. Shortening a track means being able to write it to disk without having to slow the drive’s motor from 300 rpm to 297.5 rpm.
I always wanted to make myself a nixie tube clock, but the cost of the tubes, the availability of specialized drivers, and the voltage involved have put me off when I was going to shop for components.
Therefore, I came up with my own emulated implementation of a nixie tube clock 😀
Of course, this is just something I made in order to spend the evening doing something different than usual, just like I did for the TFT supercomputer I designed and built a few weeks ago. I shall soon publish an update on that too.
In the last few days I was revisiting the code that takes care of converting NIB files to G64 files in CBM Flux Studio. I noticed that the general approach I had followed made a number of assumptions that I can’t always rely on, as I can now think of edge cases that would certainly throw a spanner in the works 😀
Therefore, this morning I set out to redesign and rewrite the approach for converting Vorpal (later) disk images from NIB to G64. The intermediate result of such effort was a new Jupyter Notebook that I can use for plugging in track data from a NIB file and generating the single-revolution, byte-oriented track data for a G64 file.
Here’s the very start of the Notebook, with NIB track data taken from track #2 of a NIB file for “California Games”:
And here’s the final output:
As expected, G64 track data is also aligned so that the so-called write splice is at the very beginning of the data itself, which is ideal for when a G64 is written back to a physical disk.
I also started converting the new approach to C code for CBM Flux Studio: I might soon provide an update post about it too.
Having finished most of the work around porting the DC2N5-LC firmware to an STM32F411 Black Pill, I thought to adapt its PCB design to use either the STM32F401/STM32F411 version of the Black Pill.
At around 3 GBP cheaper than an STM32F411 based one, the STM32F401 version is perfect for a DC2N5-LC+ and viable for new builds in the foreseeable future, due to the fact Blue Pills are plagued with so many fake versions for sale.
In the process I also had to adapt the library component for the STM32 board itself. Here’s a quick preview of the new schematics design:
This evening I was checking whether there’s an option in STM32CubeMX to change the hardware timer used by HAL. Forum posts suggest this is possible, but I couldn’t find such option. My guess is that, at least for the project I am working on, HAL might not use TIM2 as I previously thought: It seems to use the SysTick itself. In fact, the call to HAL_IncTick() occurs from within SysTick_Handler().
What I also found out is that that almost all peripheral driver initializations can be generated using LL alone, which means I can easily get rid of HAL completely in my STM32F103 project!
Not so fast though. I would have to substitute the call to the following functions with equivalent ones that only rely on LL:
The first one is the simplest one to deal with, as I can replace it with LL_GPIO_TogglePin, which I already use elsewhere.
Obviously I also have to avoid using the data structures, defines, etc. used by the above functions. I might do that in the longer run.
Unfortunately, the USB_DEVICE driver is only provided for HAL, which means I won’t really be able to move away from HAL in my STM32F4 and STM32H7 implementations.
Today after work I was able to quickly put together the test code I needed to measure the transfer speed of my “stdio redirection to USB” implementation for the STM32F411 board I am developing with.
I haven’t got a baseline to compare against for my setup, but using a nearly 10 year old Laptop running Windows 10 64-bit, I measured a modest:
Total bytes read in 10 seconds: 2473855
Speed: 241.59 kilobytes/s
The test is not perfect and I’d like to repeat it using my RPi 3 as the USB host device. I expect things might pan out to be better with that setup, however for what I need, even just nearly 240 KiB/s is more than adequate for data exchange and control commands in Retroverse.
Another likely overhead is the use of HAL in ST’s USB_Device implementation: that’s something I am not going to be able to optimize in any reasonable amount of time, so I will have to put up with it.
I will also have to check that data is not altered, by checking that the sequence transmitted by the MCU is not altered when received by the host.