And epop and epush as pop32 and push32

Consider adding a kernel-like panic page on an unrecoverable error, either as a DD-DOS feature (I highly doubt MS-DOS had that) or interpreter feature (have to check action on illegal instruction).

Verbose level set via -v[=n]

Relates to Issue #2 and #3, continue to remove D runtime features usage to move to a -betterC future.

See https://dlang.org/spec/betterc.html for more details

• dd-dos
• Loader
• ddcon
• Logger
• Utilities
• cpuid
• Interpreter
• InterpreterUtils
• main

A basic full-range screen test with dub test -b screen.

- [ ] Move MEMORY pointer to CPU structure: ubyte *Mem;

• Bad idea
• Move functions with this signature: func(CPU_t *cpu, ...)

Check the D source and complete the SLEEP function

I'm fairly certain my sleep timing procedure kind of suck. Either I calculate, somewhat like bogomips, what I need and sleeping at those exactly intervals or I do it dynamically timed-based like everything out there.

Features such as final switch and string comparison in switches very useful, but are not allowed in -betterC.

The -D option would indicate dd-dos to not load any setting whatsoever and use defaults (must be defined in reference manual later). Think of a "safe mode".

For compile settings, it would be nicer to have a single file for all of that.

Thinking of compile_config.d -- which would include cpu timing/sleeping strategies, memory configurations, etc.

Implement a verbosity level. Default should be 0 and maximum for debug build.

Possible model:

0. Silence
1. Critical -- non-recoverable crashes
2. Error
3. Warning
4. Informal
5. Debug

A function where we pass the result of an operation would ease development.

Ideally, have byte/word/dword versions.

v16_AE is not a good name, something like v16_scasw or i_scasw would be much better (es. in debugging).

• v16_mov_rm16_im16 if we continue with the array functions for different operating modes
• i_mov_rm16_im16 if we are going to incorporate more global-ish functions where memory fetching functions have CPU context (even better?)

With a stopwatch and a 1M iteration loop to test screen_draw should be decent enough.

The getopt module is fantastic.

However, it uses some D Runtime features, like the Structured Exception Handler (try/catch) for GetOptException.

Best case scenario would be making an optimized CLI by hand, not as a module.

Reason

Though rare, while MS-DOS had its own error codes, DD-DOS (not vDOS) COULD have its own "halt codes", whenever it panics. These codes can also be used and returned within the CLI, even for files not found.

Format

SHOULD be a 2-byte number.

Either plain or reserve a few bits (4?) for categorize things around.

Source Code

To void confusion with the vDOS codes, DD-DOS halt codes COULD take the DD_E_ prefix. Messages appends the _M suffix.

Example (CLI): DD_E_FILE_NOT_FOUND = 5 and DD_E_FILE_NOT_FOUND_M = "File was not found."

panic

panic SHOULD stay with the string+number signature.

It's easier to add an error code then add the panic line at one place than add the panic line + extra code in panic code.

While great and simple, it's still a function, therefore still having the penalty of calling a function, whatever the calling convention is.

One idea would be moving registers to a struct for two reasons:

1. vCPU.* clearly states that we use the virtual CPU.
2. Members can be pointers and be used as regular members (vCPU.AX = 2 is possible)
3. Manually casting (on-demand) is only a syntax-wise issue.
4. State of vCPU can be saved as a whole (if we need that later on (likely in DOS)).
5. Struct may be more properly aligned compared to global memory, which MAY improve cache performance.

Change function name from exec to exec16 since it solely executions instructions in real-mode

Once major compilers (DMD, GDC, LDC) support string comparison in switch statements in betterC code (2.082.0), consider switching to the feature.

Checklist

A lot of things should be considered and checked:

• Can char* be used in those switches, if not, can it be cast?
• If the feature depends on a library (e.g. C stdlib)
• How is the feature assembled (check with DMD, GDC, and LDC)
• In terms of performance and size, is the string-switch feature better than using strcmp?

Why I consider it

• Better-looking code
• Being part of D, perhaps compilers could use this feature to better optimize string comparison
  • Unless it's the same story in non-betterC code
  • Otherwise, could be possible the feature uses the same optimization techniques used in popular standard C libraries (GNU's, Microsoft's, etc.)

Example

Current implementation:

if (strcmp(*argv, "time") == 0) {
	vCPU.AH = 0x2C;
	Raise(0x21);
	printf("It is currently %02d:%02d:%02d.%02d\n",
		vCPU.CH, vCPU.CL, vCPU.DH, vCPU.DL);
	goto SHELL_SHART;
}

New implementation:

switch (*argv) {
case "time":
	vCPU.AH = 0x2C;
	Raise(0x21);
	printf("It is currently %02d:%02d:%02d.%02d\n",
		vCPU.CH, vCPU.CL, vCPU.DH, vCPU.DL);
	goto SHELL_SHART;
}

Allowing formatting will increase logging possibilities.

Hint: va_list

https://dlang.org/phobos/core_stdc_stdarg.html

http://www.cplusplus.com/reference/cstdarg/va_start/

Oddly enough, DUB on my Windows machine acts weirdly when using x86_mscoff/x86_64:

• _stdin missing reference
• __D4core4stdc5stdio7putcharFNbNiNeiZi missing reference

Because this is nothing like a language specification, it's simply a project.

Likely a relocation thing.

Pre-incrementing, in this case, incrementing the EIP register before doing stuff, could save us some extra later calculations, instead of incrementing it afterwards.

However, this would require us to re-pass the entire interpreter code.