RLV12 V2.0 Firmware Update 2024
Update to the RLV12 Emulator Version 2.0 for the Q-Bus
The pandemic and other circumstances delayed many of my projects. Real work was much more demanding. Hobby projects were only some small scale projects. One of them was to get familiar with the new AVR128 microcontroller family of Microchip released in 2020. I had some very intersting discussions in microcontroller forums about the AVR128 and it has some very interesting features, was still close to the MCUs I was familiar with but at the same time the differences kept me busy for quite some time until I really understood all the details.
Then I started to build a new project called the Disk Emulator for my PDP‑11/Hack. This project will later be described in a different post. However, this project had a side effect in that I was going back to my RLV12 Emulator Version 2.0 for the Q-Bus. Initially I had plans to create some adapter to use an AVR128 processor as a replacement to the Atmega1284P used, but this project was not successful, for some strange reasons the SPI interface was malfunctioning with the existing environmnet and I had no clue why. Trying to fix this, I recognised that it was a project that required work on many directions and as such would require much more effort and time than expected. But still I thought it was a pitty to not incorporate the learnings from the AVR128. So instead of pursuing the AVR128 replacement project I started to redesign the Q-Bus RLV12 Emulator firmware for the existing ATmega1284P controller.
The ultimate goal was to keep the hardware. That is not even a modification or ECO wire was allowed, except for the one already included for the activity LED. At the same time I also decided to no longer maintain various RLV12 Emulator versions and abandon all previous RLV12 Emulator versions. The above mentioned Disk Emulator based on the AVR128 MCU had already made enough progress to emulate an RLV12 for my PDP‑11/Hack. As a result this ended in a heavy redesign of the interface between the CPLD and the MCU and an extensive clean-up of the existing MCU firmware.
So here I’m going to present the new firmware of the RLV12 Emulator Version 2.0 for the Q-Bus. The description of the previous MCU firmware and CPLD design files is still available and can be found here.
At the moment the new firmware has reached the status that is at least as good as the existing one and inlcudes even some bugfixes. The code clean-up still is work in progress but the code itself has reached maturity and is stable. As the previous source code was not very nice and made use of different register conventions for individual modules the clean-up is still ongoing and will take some time until I will be fully satisfied. But I will continuously update the firmware repository. The goal is to use the same modules in both projects, the RLV12 Emulator V2.0 and the Disk Emulator, in order to keep the differences as little as possible.
The following gives an overview of changes in firmware
- I found out that many trickes used to minimize the execution time, especially the interrupts that respond to the Q-Bus cycles, are not required and many tweaks I used, like permanently allocating registers to ISR, or using a CPLD interface optimized to minimize MCU cycles, were not really necessary so I gradually removed some of these constraints which made the code much more readable
- All references and conditionals that refere to other RLV12 Emulators, specifically references to the RLV12 Emulator V1.0 for the Q-Bus and RLV12 Emulators for the PDP‑11/Hack, have been removed and ATmega1284p and V2.0 Q-Bus specific parts are kept in dedicated modules only used for the RLV12 Emulator V2.0 for the Q-Bus
- The calling conventions for many routines have been changed to AVR ABI. This will then also allow to re-use the same modules in both projects
- I have also fixed some bugs, none of them were fatal, but they had some curious side effects
- The logic to execute the SEEK function was overly complicated. There is no need to have a dedicated logic in the ISR only because overlapped SEEKs are possible on a real RLV12. This is now all processed in the normal RLV12 emulation module outside the ISR as it most likely is also done on the real RLV12 as seek requires the controller to send a control word via the serial interface from the RLV12 to the disks. I doubt the RLV12 delays the IO to send this control work but rather does this after the seek command has been written to the CSR and when finished will make the controller ready again and eventually initiate an interrupt. At least RT‑11 and RSX‑11Mplus are happy with it
- Looking at the engineering drawings of the RLV12 controller it was clear that when the controller is busy, not only CRDY is de-asserted but any read to any register will just return zero. This is now also emulated by the CPLD with the side effect that the busy/ready handling in the firmware was much simpler
- The DMA statemachine was a bit too agressive and there were cases where I had issues on the Q-Bus. Mainly because the statemachine had only 5 bits made the decoding unncessarily complicated. The new Q-Bus state machine has now 6 status bits and is now fully compliant with the Q-Bus timing. I have more states per cycle and therefore the decoding got simpler and at the end required even less CPLD resources, a real win-win situation
- I have seen that some 3rd party disk controllers implemented auto-boot
features, e.g. the Plessey RLV12 Emulator that connected to a SASI disk
implemented an extended status and an auto-boot feature using the unused device
registers at address
17774414and17774416so I have added my own auto-boot solution. Now you can boot from the first unit by just entering174414Gin ODT. - Another option I have added is that the controller responds to the Boot ROM
addresses in IO Page, i.e. responds to
173000 .. 173776. At the moment I have just copied the boot ROM from the Plessey Multi-Function board I have, but in the future the boot ROM provided will be configurable, with this you can now configure your CPU to boot with address173000and then have it execute whatever you want.