Not one, but two vintage desktop calculators rolled into a single FPGA!This VHDL implementation encapsulates both TI Datamath and Sinclair Scientific - a single input signal 'virtual pin' switches the mode.The 'chip' is hosted within glue logic that provides interface to the Mercury baseboard hardware (switches, buttons, 4 digit LED, VGA). The keyboard is hex PMOD, the keys change meaning if in TI or Sinclair mode. All of this is (somewhat) documented here or in the source code.The core of the implementation is 256 deep. 52 bit wide microcode routine. In a single clock cycle, a single 4-bit digit is processed, and to execute a single TMS0800 instruction, usually 12+ cycles are needed.Both modes are operational, but with some bugs. Time permitting I may continue fixing them and improving.
I hope somebody finds this project interesting, it was tons of fun and learning, and truly fascinating journey into retro-computing! There are plenty of great implementations of different and historically important CPUs available on various FPGA-based platforms, but to my knowledge very few trying to implement calculator CPUs. Old calculators where one of the first examples of 'microcontrollers' because on the same chip they contained CPU, RAM, ROM and I/O (interface with keyboard and displays).
Given that they are a bit different, I thought it would be useful and interesting to describe the design path I took.The original patent ( ) explains the guts of the calculator CPU in a very detailed and accurate manner (albeit in a bit of a specific “patentesque” language intellectual property lawyers may be familiar with). However, there are few challenges of using this patent for direct implementation in VHDL:- 1970s is heavy on latches, which doesn’t align too well with FPGAs which are all about clocked registers- The design had to expanded to include both TI and Sinclair (the originals are distinct and separate chips, each with own mask and ROM contents)- The original is not microcode drivenEven so, the end result still somewhat resembles the main components of the original CPU. This project log describes the internals of calculator, as they come together is the main CPU entity implementation file -DisplayunitThe main source of info driving the display unit is the A register. Latest bit file to try out if you have Mercury FPGA + baseboard + PMOD KYPD + any VGA monitor with analog connector.Put all switches to 'off', and press BTN3 to start the calculator in TI mode.
SW7 = on puts it in Sinclair mode, and SW0 allows tracing on VGA.-146.12 kB - at 06:49Components. 1 ×board. 1 ×with PMOD, display, switches etc. 1 ×(no longer supported!) FPGA development system from Xilinx. 1 ×button PMOD keyboard for inputProject Logs.
at 18:02. Few annoying bugs I was unable to track down and fix so far. Note that none of them affect the calculations due to workarounds or fixes applies.1. Ghost digits on 7-seg ledsThese appear on any CPU frequency higher that 50kHz or so, but only in the calculator display path, not when displaying the internal debug content of macro and microprogram counters. The display strobing goes from higher digits to lower (this is necessary because only this way the leading zero surpression can work) and it appears the segments 'race ahead' of the digit strobes.This bug renders 7 seg display unusable for normal calculator operations.
The workaround is to use VGA only to display entry and results, which is no great loss as 4 digit 7-seg can only display half of the digits at a time, one has to press BTN0 to switch to upper half, making it very impractical to begin with.2. Not all digits of internal registers displayed on VGA debug screenTMS0800 registers are either 11 BCD digits long (A, B, C), or 11 bits long (AF, BF). There is a timing problem in VGA debug component or its driver which 'prints' only:9 last digits at 12.5MHz10 last digits at 6.25MHzAt lower frequencies (57.6kHz and 1kHz) all digits are printed on the screen. None of this impacts operation of the calculator core, except makes first 1-2 digits (containing sign etc.) invisible in debug mode.3. Stray code executionThere is no unconditional jump in TMS0800 - those are modeled by 'knowing' the state of CF flag and executing 'jump on condition set/reset' instructions accordingly. However due to probably another unknown bug, in Sinclair mode at the end of ROM (part of AntiLog evaluation routine) CF is sometimes not the expected '1'. This has been 'fixed' with a hack explained in the code, but the real fix should be in some underlying issue (perhaps microcode implementation):progsinclair: rom512x12generic map(- HACKHACK: Why is this 'random instruction' being passed in to intitialize the ROM???- Last instruction in Sinclair ROM as 0x13F is 'BINE ALOGDIV' - however in some cases- CF is 0 which means it will not be executed and execution will continue at 0x140, which- will bring it back to the right place, instead of executing bad opcodes, or NOPs which- would wrap up to reset location 0.
This is indication of another bug but for now this- 'works'.fillvalue = BIEALOGDIV,sinclairmode = true, - hint to show correct disassembled listing (Sinclair mode)asmfilename = './sourceCodesinclair.asm',lstfilename = './tms0800/output/sourceCodesinclair.lst')port map(address = pc,data = instructionsinclair);4. Numeric digit keyboard off by oneEach TMS0800 instruction 'pulls' the next right keyboard scan line down.
There are various well known and documented patterns and best practices to create FSM (finite state machine) designs that work well on FPGAs. However from what I have seen, not much in terms of how to have a simple, good microcode pattern. One could of course adapt the methodology (and even tooling) popular in the bit-slice era when microcoding was the most popular way to create custom processors and logic (which I have done too for the ), but that approach is not very streamlined either.My first attempt was to write a which would 'spit out' file in a format that could directly be used to prime read-only memory (microcode or mapping ROM) in the VDHL. Starting work on that I realized that may be too heavy-weight for my needs, and also has the disadvantage of adding another proprietary tool to the toolchain and extra step in the journey towards the.bit file.Better alternative seemed to be to do this right in VHDL, 'synthesizing' the contents of the microcode ROM as VHDL code is being compiled. Eventually, I settled on the approach described below, which I used in this project both for the calculator core and for the VGA tracer components.That simpler solution turned out to be just a combination of few tricks in VHDL. I was able to verify few operations on basic arguments and compare them to real Sinclair Scientific for match.
Following problems remain:- LED blurs at higher frequency. Calculation can be done at 12.5MHz but LED is blurry above 40kHz or so- breakpoint and single step logic needs to be laid out more logically on the switches, and dual clock unit avoided- VGA tracer still drops some character from display.Note that none of the above impacts calculation. I also briefly tested TI mode, seems no regression was introduced there.Build Instructions. Connect the hardware as depicted on second image2. Download the sys0800.bit file3.
Set all switches on the baseboard to 'off' ( closer to the edge of the board)4. Use to upload the.bit file to Mercury board- at this point you should see 'logo' at the bottom of VGA screen, and red 0 at random location in the black band above -5. Press BTN3 to start calculator in TI mode. Keys are mapped as:+ = A- = B. = C/ = D= = E. = FBTN3 = single step nextBTN2 = ClearBTN1 = ClearEntryBTN0 = show upper 4 digits on baseboard 7-seg LEDs6.
Set SW7 to on to switch to Sinclair Scientific mode7. Press RESET (button on mercury board) to reset, otherwise registers will contain garbage from TI mode8. Press BTN3 to start in Sinclair mode. Keys are mapped as:log/antilog = Atan/arctan = Bsin/arcsin = Ccos/arccos = DE EDown = FBTN3 = single step nextBTN2 = ClearBTN1 = UpBTN0 = show upper 4 digits on baseboard 7-set LEDsHappy calculations, and please report all the bugs! No promises about fixing them though.:-)PS.
Gforce vst bundle crack. MacOS 10.15 Catalina Apple's forthcoming operating system. April 2019 we updated M-Tron Pro to Version 3 - this being a free download to existing,. Http //i1.wp.com/i78.fastpic.ru/ gforce software m tron pro v2.1.0 incl.keygen r2r. It can be used. Starplugs vst plugins v.1.0 1.1 bundle screenshot. Noise makers.
If you want to see some of the internal workings, play with the switches and buttons.