Any differences between this DCPU16 and the Original one?

[Memnarch]

Hi,
Back in the Days of 0x10c i was one of those providing toolsets for the DCPU-16. Back in those days i had a Pascal-Like compiler, Emulator and IDE. Just found this project, and i wanted to ask if there are any differences between your DCPU16 or the way the last revision of Notchs DCPU-16 worked.

If there are any differences, can you give me a summary? Maybe oneday i'll update my toolset.
Compiler:
https://github.com/Memnarch/D16Pascal
Emulator:
https://github.com/Memnarch/D16Emulator
IDE:
https://github.com/Memnarch/D16IDE

[paultech]

Hello,

Very cool to see. The biggest difference in the TC-DCPU is the hardware we have specifications for.

Some small additional opcodes (LOG&BRK) as you can see here DCPU-TC

But for the most part, a stock 0x10c DCPU will run assembly targeted for the TC-DCPU (So long as TC hardware isn't used.) The LEM/Clock/Keyboard are all compatible.

Thanks and let me know of any additional questions!

[Memnarch]

Thanks. The hardware part is simple, as those are just components for my Emulator. Adding new ones is easy.

Not sure about the Debugfunctions. Since LOG for example sounds a bit like a designsmell. i'd expect a device i can log to. However i can understand the ease of use (despite it not fitting the architecture).

The general problem is that logging is not supposed to stay in finsihed code. So maybe the underlying system should simply give tools to inspect registers and stack when a break occurs?

[paultech]

You are completely correct that LOG is rather lore-breaking, it was a needed requirement during early development. We may end up NO-OPING the LOG opcode when it's ran in the production game, only enabling it for single player and development servers.

Suggestions on tool to inspect registrar and stacks? We have a in-game PDA, we could add a programmer ROM to allow for inspection of other DCPUs? I don't like the idea of having a UI showing registrars/stack out of thin air.

[Memnarch]

If we keep the lore (means the DCPU runs a simple Software and is not as complex as Windows/Mac/Linux), you might want to provide a debugging device. The debugging device connects to the computer and allows things like stepping, or reading from memory/registers.

Modern computers are so complex, that we can Debug per Thread without interfering with other threads/processes. So having another Computer/Device to act as Debuggingmachine sounds plausible for such a simple system.

[paultech]

Well that idea got positive reaction from our side! We'll be adding a in-game debugger device, when attached to a DCPU LOG and BRK will become operational and routed to the in-game debugger while in-lore!

Thank you!

[Memnarch]

With an attached Debuggingdevice, there is no need for Log. (or is it?). The debugging device can inspect the Values when the CPU halts. My Idea was to erase those MNemonics and replace their functionality by an external device.

[andyleap]

I think big thing is HLT and BRK would have different semantics. HLT just pauses till next interrupt, BRK is a "the DCPU is frozen until an external device tells it to start running again" From a debugging point of view, LOG is similar to a debug print kind of thing, and would have uses for that.

[Memnarch]

Okay from that point of view, BRK makes sense (just put into a documentation that BRK is usually placed by an external device to trigger a break, and not by a programmer). That's (kind of) how the INT 3 interrupt on X86 is used. However to trigger Breaks, you could cheat a bit, like i did for my emulator. Behind the scenes, the DebuggingDevice could tell the DCPU-Emulator to break, when/before it hits a specific address.

The LOG has a problem: I can not give a context (like a name, due to the limited options), as it seems (correct me if i am wrong). I get a bunch of logged values but in the end i have no clue. Usable when used at a single place, but falls apart when used on multiple places. I consider the Register/Stack View of the Debuggingdevice to be more helpful.

If an extended logging is required, it is quite simple:
Connect a second screen, write some routines which print to this screen. This gives more usability/flexibility. I'd say this is a task for a tiny framework, like in reallife. Or maybe you already have a device which is more usable for this task instead of a screen. Haven't looked into your list of new devices.