More DC2N5-LC development for the Black Pill

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.

Retroverse development board for DC2N5-LC

Stay tuned for more!

V-MAX! sector ID decoder added to CBM Flux Studio

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.

CBM Flux Studio: V-MAX! sector ID decoder

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.

Stay tuned for more!

Emulated nixie tube clock

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.

Stay tuned!

Update on the NIB to G64 conversion in CBM Flux Studio for Vorpal (later)

The new conversion mechanism is now ready 🙂

Revisiting the NIB to G64 conversion in CBM Flux Studio for Vorpal (later)

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”:

Jupyter Notebook: NIB to G64 data conversion for Vorpal (later) tracks

And here’s the final output:

Jupyter Notebook: NIB to G64 data conversion for Vorpal (later) tracks

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.

Stay tuned for more!

DC2N5-LC PCB modified for use with a Black Pill

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:

DC2N5-LC adapted for use with an STM32f4xx Black Pill

Stay tuned for more!

Development board for Retroverse

I finally got some time to power up the development board I plan to use to develop Retroverse:

Development board for Retroverse, based on STM32H7

It’s based on an STM32H7 MCU that can be pushed to 480 MHz. Porting DC2N functionality to it should be simple enough, but I guess I might try to port IECHost functionality first.

Stay tuned for more!

Tape handling driver for Black Pill ready

The porting of my tape handling driver to the Black Pill is done! The Black Pill is now dumping tapes and playing back TAP files (version 0, 1, and 2) too 🙂

Black Pill: tape handling driver testing

Being the Blue Pill plagued with so many fakes flooding the market, the Black Pill is now also viable for future builds of the DC2N5-LC, although the PCB of the latter will need some adjustments.

Stay tuned for more!

Moving away from HAL in my STM32CubeMX projects

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:

• HAL_GPIO_TogglePin
• HAL_Delay
• HAL_RTC_GetTime
• HAL_RTC_GetDate
• HAL_RTC_SetTime
• HAL_RTC_SetDate

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.

Stay tuned for more!

Benchmark testing for my USB serial code

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.

Stay tuned for more!