Bank switching prototype

[Ryan Crosby]

I'm considering doing some hacking on the "main" PIC microcontroller firmware in order to add bank switching to the relay computer. Essentially, the idea would be to keep the lower 128 words static as they are now, but make the upper 128 bytes "switchable" by writing the bank number to a magic bank switching register at address 0xFF (or perhaps not a memory address at all, but instead a magic instruction, similar to out or outc). In this way, the relay computer could access more than 256 words, by dynamically switching between banks at runtime.

This question is more for Joe, but before I go down this path of getting a build environment set up for the firmware, does the PIC24FV32KA301 have enough RAM to feasibly implement this? I know it has 2kbytes available, and 1024 bytes are taken up by the 256 words of program space already, but do you have an idea (or is there an easy method to tell from the source) how much RAM is currently used on the PIC and how much is spare? I think even a single extra bank (+512 bytes) could allow for some good flexibility. I can see that stripping out the assembler would allow the removal of the symbol table (-256 bytes), so only an additional 256 bytes would be needed to fit an extra page.

Unfortunately the PIC24 series appears to top out at 2K RAM and I can't find a pin-compatible list of more "well endowed" uCs, so not sure if upgrading the PIC is an option or not.

Cheers,

Ryan.

[Joe Allen]

Well here is the map file:

There are 420 bytes free, but they are used by the stack. I don't really know the maximum stack depth.

I wish the MCU had more EEPROM space for retaining the program memory when the power is off, though I guess the main flash memory could also be used for this... hmm..

You could add a SPI-RAM chip pretty easily, if you don't mind added wires on the board.

BTW, I discovered that optimization is now enabled by default in MPLABX. In MPLAB, the optimizing compiler was not free so I did not use it. This affects a timing loop and makes the relay clock too fast. Anyway, so if you recompile, disable optimization.

"program" Memory  [Origin = 0x200, Length = 0x5600]

section                    address   length (PC units)   length (bytes) (dec)
-------                    -------   -----------------   --------------------
.text                        0x200               0x214           0x31e  (798)
.const                       0x414               0x96c           0xe22  (3618)
.text                        0xd80              0x25dc          0x38ca  (14538)
.dinit                      0x335c                0x42            0x63  (99)

                 Total "program" memory used (bytes):         0x4a6d  (19053) 57%


"data" Memory  [Origin = 0x800, Length = 0x800]

section                    address      alignment gaps    total length  (dec)
-------                    -------      --------------    -------------------
.nbss                        0x800                   0           0x632  (1586)
.ndata                       0xe32                   0            0x28  (40)
.nbss                        0xe5a                   0             0x2  (2)

                 Total "data" memory used (bytes):          0x65c  (1628) 79%


Dynamic Memory Usage

region                     address                      maximum length  (dec)
------                     -------                      ---------------------
heap                             0                                   0  (0)
stack                        0xe5c                               0x1a4  (420)


                 Maximum dynamic memory (bytes):          0x1a4  (420)

[Ryan Crosby]

Thanks Joe, this is exactly what I was looking for.

With 420 bytes currently free for stack, if I remove (or dynamically disable/reclaim) the assembler symbol table, I'd get up to 420 + 256 = 676 bytes. With a single additional 128 word/512 bytes page, that'd leave 676 - 512 = 164 bytes for stack. I have a hunch that 164 bytes of stack will be enough, so a mod to add a single extra bank of memory might actually work.

An SPI-RAM chip could be a cool addon and allow for lots of banks. I'd probably want to make a little daughter board that shimmed between the IC socket and the PIC, with the extra SPI-RAM there on the side. Could also add external EEPROM to save the entire state of memory too. It would basically be a little supercharged main module. I'll have to learn Altium CircuitMaker a little better first though 😅

Anyway, I'll let you know how I go. Cheers.

[David Cary]

Ryan,
Today the PIC24 series available in-stock in through-hole packages appears to top out at 48 kBytes of SRAM, which seems to be far more than enough.
The PIC24EP512GP202-I/SP and the PIC24EP512MC202-I/SP are SPDIP-28 devices with 48 kBytes of SRAM and 512 kB of program Flash.

They're obviously not perfectly drop-in pin-compatible replacements for the PIC24FV32KA301-I/P used in the Relay Trainer, because that is a PDIP-20 device.
So perhaps an SPI-SRAM or SPI-EERAM or SPI-EPROM or SPI-FRAM or SPI-Flash chip might be easier to quickly hack into the Relay Trainer. (See the WM-2A memory module from http://wilsonminesco.com/ ).

[Ryan Crosby]

Thanks David, the PIC24 would certainly do the trick. It'd need to be on a daughter board to be pin compatible as you say. I also like the way those Wilson Mines Co modules connect vertically. Using that style it'd be possible to maybe make a shim board that still uses the PIC24FV32KA301-I/P to add extra SRAM.

I've also been looking at the RP2040 (Raspberry Pico) as a candidate for the microcontroller, since I already have a development "stamp" board and some Thumby tiny game consoles that use them. The chip is cheap ($1), extremely tiny, and includes a 133Mhz dual core ARM processor with 264kb flash and a full micropython environment, as well as a programmable PIO interface for more than enough realtime IO capabilities. I could feasibly re-implement the relay computer PIC code in micropython, which would make for an easily hackable and extensible firmware. The RP2040 could easily handle a full code assembler, on-board CPU emulator, test functions, memory mapped displays, or almost anything else one could ever want. Downsides is that it'd require a complete port of the firmware to micropython, and also custom boards with tiny SMD components to make it compact since the Raspi Pico stand alone boards are quite large... but there's nothing like a good project and my KiCad skills are improving...