I suspect the track would be best connected as n segments,with track switches, pcm power and other things like railway crossing signs and misc lights.
Then you could have N engines per segment. Ben.

Throw some switches and the train is Borrow? Stopping or passing an engine easy enough, but generate or annihilate?
Keep in mind coils and lamps perform XOR for least parts. Slower subtraction by going round the bend to solve in serial.
3mm grain of wheat lamps also good for bidirectional snubbing of relay coils. FPGA, what were you thinking!

I was thinking more the classic BYTE.
https://archive.org/details/byte-magazine-1977-07/
Doing it in JAVA or under WINDOWS does not feel the same.

OT. I think the track will be connected as only two separate logical sections. One for the tram line, and another for the rest of the layout. I am planning on eventually using DCC (digital cab control) which allows multiple locos to be running on the same section of track while being independently controlled. DCC is a digital standard for driving model railways. I may make my own DCC controller which is just a digital circuit that connects to the track via an H-bridge. I would be using available decoders though. It depends how much of the standard I can absorb mentally. My current locos are DC only so they would need to be adapted.

For miscellaneous lights I was thinking of using a long shift register with one LED per Q output. If it could be shifted at a high enough frequency there should be only minimal flicker when the lights change. All the lights could be controlled as a serial bitstream and would require only a handful of signals to control.

Crossing lights and track signals are a little trickier. They require knowledge of where the train is.

The BYTE magazine outlines some of the issues but is out of date.

FPGA is a good way of absorbing a lot of digital logic. I could also use it to drive displays. A microcontoller or something like the RaspberryPi may be usable too.

Did some more work on Thor while waiting for a flooded basement to dry. After leaving the core for several weeks, when going back to it, I still think the ISA is fairly decent.

Modified the branch opcodes. Got rid of a few store instructions which were performing both a round operation then a store. It will be necessary to round a register to the desired precision, then store it using an ordinary store instruction. The issue dealt with is exceptions occurring as part of the round operation. By forcing an explicit round operation, the exception can be handled at that point rather than during a store.
Loads and stores are now somewhat asymmetrical as loads may load a lower precision value and expand it into a higher precision. This is okay for loads because exceptions will not occur expanding the precision.

Switched register code 63 which was being used to indicate a constant value to be just an ordinary register code. This gains a register in the register file. Added two postfix opcodes. Postfixes now indicate which operand the postfix is applied to.

There are about 24 free out of 128 opcodes at the root level now.

Modified the branches yet again. This time using the high order nybble of the target address to determine whether the branch is a displacement from the PC (-7 to +6), a branch to register (7), or a branch to a micro-code address (-8). Conditional branches also now multiply the displacement constant by five which is the size of an instruction. This effectively adds a couple of more bits to the displacement. Branches therefore have a range of ±280kB. Multiplying by five should not impact performance as it is a three input addition to the PC instead of two input, and three-input adds can be performed just as fast.

Some work on the assembler updating it to support new branch formats.

Started work on Thor2025. The ISA is much the same as 2024 but the implementation is vastly different. A couple of differences are that vector mask registers have their own register file. Link register also have their own register file.
Thor2024 stores register values in the ROB, effectively using a CAM approach. Thor2025 will use a physical register file (PRF) and register renaming.

Wondering how to reduce the size of the checkpoint register rename history. I currently have it implemented in a brute force fashion using regs with two write ports and many read ports. It is a simple multiple copies of the entire RAT (register alias table). There may be up to two target registers assigned per clock cycle. It uses a simplistic approach, while building the core from the ground up, of having a checkpoint for every instruction queue entry. Whenever an instruction is queued the RAT is copied. That way the map is easily reset from the version associated with the queue entry of the branch miss or exception.

One thing I can see to do, is copy only when a new target register is assigned. There may be times when no target register is assigned so there is no need to update the map.

Also rethinking the separate register files choice. To support a unified register file would require four functional units to be able to update the register file. ALU1, ALU2, FPU, and LOAD. I currently have a 3w register file. If one of the write ports was shared between LOAD and FPU perhaps, a 3w file would work okay.

Got a good chunk of code written for Thor2025. Except for the register file, it is looking like the implementation will be a lot smaller than Thor2024. The register file is massive, 81 block RAMs due to the need for 27 read ports and 3 write ports. All the functional units have access to register read ports rather than values coming from the reorder buffer. A lot of comparators and muxes and busses have been eliminated. It is too soon to get a good idea of the size yet. The number of reorder buffer entries has increased to 16 from 8.

Started a new project called Qupls.