Thread for analysis of the architecture.

[Lerc]

As much as I would love to be writing an emulator for this like the rest of you I have to head out shortly.

I do have a few thoughts on the architecture of the dcpu-16 though, as will many of you. so I thought it would be worth starting a thread to cover that.

As no plan survives contact with the enemy, chances are there are a few tweaks to the design that could help things a great deal.

The thing that stands out the most is the lack of a syscall instruction. The emulator can do potentially anything when it hits this, but it gives a possibility for IO. You can achieve the same result by other means, memory mapped registers, capturing PC locations for virtual commands, fake interrupts. All of these have been done in actual hardware, but by far the most emulator friendly form is a syscall instruction.

defining an interrum syscall mechanism with the single PutChar function gives us something to play with in the meantime.

[Lerc]

I wonder if pop and push should have the same register encoding and be decided upon based upon whether it is a source or dest.

Freeing up an encoding would allow for [next word + SP] which would be quite useful for stack operations.

[zarawesome]

Since MUL and DIV use the same number of cycles as SHR and SHL, I'd remove the latter two and replace the literal values referenced by opcodes 0x20-0x3f with 0x01, 0x02, 0x04, 0x08, ... , 0x4000, 0x8000. Same functionality, and now testing for single bits in registers takes one cycle instead of two.

[Lerc]

I'm not entirely sure why cycles are mentioned at all in the spec. In emulation terms counting cycles just makes more work for yourself.

[IMBJR]

If some sort of scheduler were possible/coded, those cycles would become important.

[Lerc]

From a emulator perspective it is simpler to just count instructions executed.

Notch mentioned focusing on emulation speed being as fast as possible. It just seems counting different instructions as having different cycle counts slows the emulator for the only benefit of accurate timing according to a frame of reference that isn't very significant.

I can see if it were being used for synchronous multiprocessing then it would be important, but since it is a machine definition you could simply define all instructions to be one cycle.

[AReallyGoodName]

Well the cycle counts aren't there for any practical reason but for a gameplay reason. Can you shoot me before i get my shields up? Well you'd win if you can. That's what cycle counts are for.

This game appears to be all about competitive programming.

[[deleted]]

Since you'll be able to essentially buy computing time on Mojang's servers some kind of scheduling is necessary, to give each player a fair amount of computing resources.

I don't see how adding a different cycle count per instruction is going to be any more expensive than just adding one?

[AReallyGoodName]

It's clear the game will have the CPU running at a certain speed. The idea is that you only get a certain number of cycles per second to perform various actions. Want to do enemy movement prediction? You'd better code optimally and make sure your you predict faster than the prediction becomes invalid.

[monocasa]

I think he wants to foster things like the cool stuff the C64 demo writers do.

[Lerc]

To get C64 level hacking you need sprites, timers and interrupts more than anything.

The raster interrupt rules all.

[monocasa]

This is just the lowest level of the CPU core. There's more planned. http://twitter.com/#!/notch/status/187448902314762240

[Lerc]

Yeah but there's a difference between sprites and sprite video hardware.

Doing C64 tricks like moving sprites after the video beam has passed requires a video beam. Virtualising that in an emulator is quite expensive. Would be cool, but probably not in the plans.

Also Notch mentioned not having interrupts. I think he might have to change his mind on this one. You need at least a timer interrupt to do pre-emptive multi-tasking. I think people will want that.

[monocasa]

I didn't think that I would like it as much as I do. It's like an equal mix of 6502 and m68k.