Version Notes
(Ver. 2.21.231 - July 19, 2019)
Version 2.21.230 withdrawn from the site
Subversion 2.21.230 (July 17, 2019), showed in the menu, by mistake, a component not yet completed. Such component will be included in the next release and will operate as a rotary potentiometer (see figures below).
Version 2.21.230 (July 17, 2019) has been withdrawn from the site; we recommend to de-install it and install the current release instead.
Microcomputer Project Assembling and Loading
Now, a few changes in the user interface speed up the process of assembling and loading an updated version of the program into the DMC8 (Basic or Enhanced) Microcomputer components (see the Load DMC8 Project command, highlighted in the figure):
Regarding the loading of a project in the microcomputer component, the warning dialog box has been eliminated since not so useful (the dialog warned the user that the microcomputer ROM was not empty, when a .MC8 project was loaded, see below).
We deleted the warning dialog which informed the user that the new project had been correctly assembled and loaded into the microcomputer (see the following).
In its place, a small temporary window is now displayed (see the next figure). It automatically disappears after about two seconds.
The dialog appears, instead, only if an error has occurred (see the following example).
The automatic display of the Program Source Code Windows has been suppressed too, after the loading of a new project. However, it is always possible to open it voluntarily, using the debugger commands available through the microcomputer component context menu (see the next figure).
The Program Source Code Window will appear as shown in the figure below. Remember that, in this window, the code is read-only. To edit the source code, it is necessary to open it in the Deeds-McE tool.
View All command (bug fix)
Fixed a bug of the View All command. A crash occurred when using this command if a large size worksheet was set (A2 size). Moreover, a protection has been added on reading circuit files ('.pbs' and '.cbe'). Now, corrupted files (because saved after the crash) are automatically fixed (thanks to Andrea Bivi for reporting the bug).
ROM Editor/Programmer Dialog (bug fix)
Exporting the contents of a 256x16 ROM, in a '.drs' file in HEX code, the numbers were poorly formatted, depending on the settings made in the editing grid screen (the format did not have to depend on those settings), as visible in the following example:
000000000000000C000 0000000000000008000 0000000000000000000 0000000000000000000
000000000000000C018 000000000000000C01A 000000000000000C01C 000000000000000C01E
000000000000000C038 000000000000000C03A 000000000000000C03C 000000000000000C03E
In any case, the file was correctly readable (only some non-significant zeros were there). Now the bug has been fixed and the HEX numbers are generated with the correct number of digits, evaluated on the basis of the size of the number format (4,8,16 ... bit), as shown in the following example:
C000 8000 0000 0000 C418 C41A C41C C41E
C438 C43A C43C C43E C458 C45A C45C C45E
C478 C47A C47C C47E C498 FFFF FFFF FFFF
'Ready to Test On FPGA' dialog (bug fix)
Rarely, and just for some users, the Ready to Test on FPGA dialog remained behind the main Test on FPGA Expert, despite being launched as a modal dialog. The Deeds-DcS appeared blocked. Following the current changes, this should no longer occur.
Clock Animation Sliding Bar
The sliding bar functionality of the clock animation frequency has been enhanced (thanks to the suggestions of Francisco Gonzalez). The frequencies are now discretized in a better way, and it is possible to choose more reasonable values. As an example, the past version did not allow to set 100 Hz (only 96 Hz and 103 Hz). Now it is possible to do so.
Moreover, two fine regulation controls had been added on the right side of the sliding bar (the little buttons [ - ], [ + ] see the figure below). They are useful just to move the bar itself in an easier way (instead of dragging with the mouse the slide cursor).
The animation clock frequency range is always 0.5 Hz..25 KHz.
Apparently 'frozen' Input/Output Values (bug fix)
Beyond a certain frequency of the animation clock, the clock component and the output components could seem not working, because their update suffered a stroboscopic effect. If the frequency of the animation clock was set about to 50 Hz, or at an integer multiple, the image of the component could always be updated with the same value, appearing frozen, as long as the redrawing frequency is just nominally 50 Hz.
Now, the Clock and the simple Output Components, like the single LED, and the Single Bit Output, no longer suffer this effect because, beyond a certain number of variations per second, the updating of the value of the component is no longer the actual one, but is represented symbolically by flashing it at a frequency of about 12.5 Hz.
Initial Value dialogs (bug fix)
In the Timing Diagram Window it is possible to define the initial value of the input tracks signal, using a dialogs specific for each of the different type of input component.
The initial value can be defined before starting the simulation, while it should be read-only after simulation has started. Due to a bug, the dialog's internal fields allowed the modification of this value, even if at the time of pressing the button this value was not really saved. This anomaly generated confusion. Now, after simulation has started, each dialog presents the editing fields correctly disabled (grayed).
Moreover, most of the dialog captions have been updated, in order to make them more readable.
Track Editing (bug fix)
Trying to delete or edit an input track, a 'Range Check Error' occurred, if the zoom scale was high and the next logical transition at a considerable distance. Now, this error has been fixed.
Code Breakpoints and Instruction Highlighting.
In the Object Code pane, a narrow column has been added in first position, to mark code breakpoints. Breakpoints, if set, are shown with a red square dot. Moreover, color highlighting has been modified, to improve comprehensibility. When a breakpoint is set, the line background is colored in light transparent red, so that the line could be easily read (see the figure below).
The line corresponding to the current instruction is always displayed in light sky-blue, even if a breakpoint has been reached (see the example below).
In this case, the breakpoint is always marked in first column by the red square dot and, in addition, the message 'User Breakpoint encountered', is shown in the Info pane.
Switching from the Debugger to the Editor and vice versa
The way in which you could switch from the debugger to the editor, and vice versa, has been changed a little (thanks to Giancarlo Perlo for the suggestion).
It was annoying to stop a simulation in the debugger and return to the editor window, because the program signaled with a message dialog that the simulation would have been stopped (the user needed to accept with a mouse click all the times, see the figure below).
This message dialog has been eliminated because it makes little sense to ask the user for approval. Now, at the time of the switch from the debugger to the editor, this message dialog no longer appears. Instead, a small temporary window is now displayed (see the next figure) and automatically disappears in a short time.
Similarly, the message dialog warning that the source would be compiled before entering the debugger was tedious (also in this case, it was necessary to click the OK button to go on, see below).
Now a message window appears (see the example below), and quickly closes in a short time, immediately after completion of the compilation, without to generate bips or to have to press buttons.
Reading an uninitialized RAM location
Following the suggestion of several users (including Luis Claudio Gamboa Lopez and Giancarlo Perlo), stopping the execution when an uninitialized memory location is read, seemed a bit excessive. It would have been better to give a warning, and then continue. This is the behavior of the current version.
This change has led to an important revision of the messaging mechanism generated by the debugger. Now, the possibility of reading many times an uninitialized location has forced us to limit to the maximum number of warning messages, beyond which the execution is stopped. The change also involved adjustments in the messaging section relating to the Deeds-DcS.
An example of D8080 code follows. Each instruction produces two reading, the Low and the High bytes.
Since now the execution is no longer stopped when an uninitialized memory location is read, the instruction is regularly completed, as expected. Previously, it was terminated at the first reading of the memory and, if the instruction included a second reading, this was not carried out.
Note: the same criterion was not extended to the reading of the ports, because the reading of a port is conceptually different from the reading of an uninitialized location.
Code Editor: drag-and-drop of selected text (bug fix)
The text drag-and-drop in the code editor was not supported by the UNDO/REDO system, so a mess happened after an attempt to use the UNDO after. Now this dangerous bug has been fixed and the drag-and-drop is regularly supported by UNDO/REDO.
Row-numbers column (bug fix)
The left-side column, the one that reports the text row numbers, unexpectedly allowed you to select the numbers, as text. It was possible, accidentally, to drag and drop that selected text in the editor (operation not supported by the UNDO/REDO system). This bug has been fixed.
HALT instruction (bug fix)
Now the HALT (DMCE) and HLT (D8080) instructions work correctly. When an interrupt occurs and then returns, the emulator goes regularly to the instruction immediately after.
D8080 Instruction Set (bug fix)
The D8080 emulator presented a few bugs regarding the flag P (Parity), and the flag N (Negative), that is a feature of the Z80, but not of the original 8080. Moreover, now, when the reset of the D8080 is activated, the bit in position 1 of the flag register is set to high, even if it is not used anywhere, according to the original 8080 documentation.
Parity flag handling has been fixed for the following D8080 instructions:
ADD, ADI, ADC, ACI, SUB, SUI, SBB, SBI, CMP, CPI, INR, DCR
The Negative flag does not exist in D8080, so the following instructions do not control anymore the bit in position 1 of the flag register:
ADD, ADI, ADC, ACI, SUB, SUI, SBB, SBI, CMP, CPI,
ANA,ANI, ORA, ORI, XRA, XRI, INR, DCR, CMA, CMC, STC,
DAD B, DAD D, DAD H, DAD SP, RAL, RLC, RAR, RRC
The 8080 version of the DAA instruction do not support the Negative flag, as the Z80 version does, so the DAA of the D8080 has been fixed according to the original 8080 behavior.
The Half Carry is handled differently in 8080 and Z80. So the emulation of the following D8080 instructions does not modify the Half Carry anymore:
ADD, ADI, ADC, ACI, SUB, SUI, SBB, SBI, CMP, CPI,
DAD B, DAD D, DAD H, DAD SP,
ANA, ANI, ORA, ORI, XRA, XRI,
RAL, RLC, RAR, RRC,
CMA, CMC, STC.
DMC8 Instruction Set (bug fix)
The Half Carry flag was handled erroneously in the following DMC8 instruction:
AND, OR, XOR
Now, the CCF instruction inverts the Half Carry flag too (not only the Carry flag). Classic Z80 documentation asserts that the Half Carry flag is ‘unknown’ after CCF execution.
Instruction tables
The instruction tables of the DMC8 and D8080 have been revised and integrated, in relation to the control of the Parity, Overflow, Negative and Half Carry flags. Moreover, the following instructions (added in a previous version), have been included into the tables of the DMC8 processor:
DAA, EX DE,HL, EX (SP),HL
and, for the D8080, the corresponding instructions:
DAA, XCHG, XTHL
Interrupt Request Lines
In the documentation figures, the IRQ_n inputs were erroneously called IRQ1, IRQ2 and IRQ3, while they should be IRQ0, IRQ1 and IRQ2, as in the VHDL code of the processor core. This mistake has been corrected (see the figure below).
DMC8 and D8080 Programming Model figures
For sake of simplicity, the figures of the programming model of the DMC8 and D8080 processors have been further simplified, with the elimination of the Temporary Register from the left input of the ALU. So, the figures result as follow:
Note that the aim of these figures is not to be exaustive regarding all the possible architectural elements and paths that are present into the processor. Simply, they want to show the main elements that programmers will use during their work.
No correction in this release
File compatibility
The internal file format is the same of the previous version (2.20.190).
Tested under Windows 10
This version of Deeds had been tested under Windows 10 (32 and 64 bit). We recommend that you do not install it in previous versions of Windows.
File Names on Title Bar
Now the name of the opened file precedes the name of the application, both on the title of the main window, when opened, and in its iconized form on the bottom bar.
Splash Form (bug fix)
The initial splash form was displayed in every case, even if there were already open instances of the Deeds tools, if these were minimized (iconized) or maximized. It now correctly recognizes the presence of a previous open instance, even if minimized or maximized. The splash form is then displayed only once, when the first instance is launched.