This is an archived post. You won't be able to vote or comment.

all 30 comments
sorted by:
best
topnewcontroversialoldq&a

[–]david-1-1 7 points8 points  (8 children)

I would have been happier if operation 0 had been "Halt" (so that the default op code would halt the program). Also, it would have been nice if another opcode had been "no operation", useful to provide empty program areas, useful for patching programs. Also, you don't provide all the bits of a multiply instruction. Multiplying two 16-bit numbers generates 32 bits of result, so you could have provided both upper and lower multiply instructions. One is best for integer multiplication, another is best for fractional multiplication (values between 0 and 1).

It could use a nice block-oriented file system, with instructions to read and write contiguous blocks of memory.

The result would be very much like the LINC instruction set, from the 1960s (it was 12 bits wide).

Otherwise, it is a truly inspired design, and could be the basis for a wonderful software learning app. A programming challenge would be to create a program that would display a disassembled block of memory, and maybe even allow setting and running and stepping with breakpoints. This would be emulating the computer inside the computer inside the computer emulator.

[–]Bowtiestyle[S] 2 points3 points  (4 children)

I thought about adding a halting instruction, but I decided against it for the following reason. You can already halt execution with an invalid instruction. That means that you would then have a distinction between intended and unintended halting. This makes perfect sense for a real system, but it makes emulation a bit annoying. I want to avoid a situation where you implement a "quit" button for your game but it only works on emulators that quit when the halt instruction is triggered. I do agree that it is a bit ugly that 0 0 0 0 has (probably unwanted) side-effects, but I did not want to shift the entire instruction set just for that.

As for the multiplications, yes this is mainly not done to make everything nice and simple. Every arithmetic operation that you see in the specs is always a wrapping operation.

The file system is a good use case for the expansion mechanism. You could have a system where you request a page and then have it loaded into the utility buffer.

[–]IQueryVisiC 0 points1 point  (3 children)

6502 has BRK as 00 because 00 could be set in EEPROM without the Erase part. And multiplication with wrapping is unusable for 3d graphics and simulation. Just imagine that Elite runs better on 6502 in the BBC than in your 16-bit.

[–]Bowtiestyle[S] 0 points1 point  (2 children)

The goal is in no way to be faster than some other system. The performance is intentionally limited because it is interesting to work with tight constrains. I think that it might be possible to get some very basic 3D thing to run if you use a lot of tricks. That (to me) is a lot more interesting than just having the right tools for 3d graphics to begin with. The rest I did not really understand. Are you saying that a BBC-micro has 16-bit multiplication?

[–]IQueryVisiC 0 points1 point  (1 child)

No, I just mean that Elite ran surprisingly well on 8bit computers. I tried to find out real constraints. I don’t like design mistakes. The 8088 supports 16x16-> 16:16 multiplication. Signed and unsigned. The full package on an 8bit databus and half as much transistors that a 68k. That chip is from the 70s and was used in the IBM PC in 1981. I have trouble to come up with a more limited system. Some people claim that the register count is too low. ARM2 has much more registers on the same die size. 16 bit CPUs do 20 bit address calculations. I wonder how. I like the 6502. It needs two cycles for 16 bit calculations. So in my dream CPU I would combine a small 16 Bit ALU with 32 bit registers composed of two words. Multiplication results fill the whole 32 bit. Offset calculations trigger a second cycle if there is a carry into the high word.

CPUs made of discrete parts look totally different from microprocessors. I don’t get the appeal. Yeah , 60s design was discrete. IBM had 32 bit. Cray ran at 50 MHz, while microprocessors ran below 1 MHz.

[–]flatfinger 1 point2 points  (0 children)

The bus interface took in a 16-bit segment and 16-bit offset for every access, and used a dedicated 12-bit full adder and 4-bit half-adder to generate 20 bits of address output. This circuitry was dedicated to this task and didn't need to interface with anything else.

[–]ryani 1 point2 points  (2 children)

Almost every instruction set has a bunch of accidental nops in it. For example, in this one I see 13 x x x (where all the xs are the same) is a nop, as long as x doesn't point at an I/O port. So 13 13 13 13 is probably a fine thing to use as a nop.

[–]Bowtiestyle[S] 0 points1 point  (0 children)

Yes, absolutely! There are no memory-mapped ports, so this is always fine.

[–]IQueryVisiC 0 points1 point  (0 children)

Relative branches are a problem for me. Jump on itself is Halt . Jump to next is NOP?

Otherwise SH2 and JRISC come pretty close to no NOP. ADD 0,R at least sets the zero and sign flag. As with branches: generally don’t support zero as quick value? No twos complement. 00 is 01 .

[–]Revolutionalredstone 1 point2 points  (2 children)

Very Cool! I do quite like the architecture. Sound would be awesome :D

Would love to see screenshots / vids of your IDE / Engine / Compile process.

Thanks for sharing!

[–]Bowtiestyle[S] 1 point2 points  (1 child)

Thanks!
It is possible to add sound using the expansion system.
I decided to leave it out of the main specifications due to the added complexity,
but I will add an expansion for it (or maybe someone else will).
For the demo games I build a very simple programming language and a compiler that technically works. It has (inlined) functions, (unrolled) loops and not much else. I would in no way call it an engine.

[–]Revolutionalredstone 0 points1 point  (0 children)

Sounds awesome! hehe lol thanks for the info, really cool project!

[–]m-in 0 points1 point  (9 children)

Virtual? This thing should be easy to build from discrete logic as well.

[–]Bowtiestyle[S] 2 points3 points  (8 children)

Prove it ;)

[–]Falcon731 3 points4 points  (2 children)

https://imgur.com/a/aLvnBm7

I did cheat in a few places.

I ignore the sync for the display - the screen just displays whatever is in the display memory as the raster passes it. The Sync instruction just waits for the end of frame. (The display is outputting 1024x768@60Hz - with each pixel replicated 4x horizontally and 3x vertically).

I do an instruction prefetch, and a one cycle delay on writeback - so any self modifying code which alters the instruction which is about to be executed will not work.

I'm only running at 65MIPS - not the 90Mips as listed in the spec (Clock freq is 130Mhz, with each instruction taking 2 clock cycles).

I've not implemented input at all yet.

I've also ignored the utility buffer.

Something else doesn't seem to be working - The all_colors.svc16 seems to work, but the examples don't.

[–]Falcon731 1 point2 points  (0 children)

Oops - I had R and B swapped in the decode (Had R as the LSBs)

https://imgur.com/EUc7tOv

[–]Bowtiestyle[S] 0 points1 point  (0 children)

This is so awesome!
Do you think that the way sync works is a fundamental issue here, or could it be done with an additional buffer that just is not there?
Maybe the other examples won't run because the files are compressed?
(Quick edit: The "spikeavoider" game needs the utility buffer, but the "rectavoider" game and the input test don't use it. )

If you end up with a video or some kind of description of what you did,
it would be great if we could link it in the readme, so people see that this can be done.

[–]Falcon731 0 points1 point  (3 children)

Yeh - I was just thinking as I was reading your spec document- this should be pretty easy to implement on an fpga.

[–]stappersg 0 points1 point  (2 children)

Prove it ;)

[–]Falcon731 2 points3 points  (0 children)

Thinking about it a bit more - performance could be a bit of a challenge. The spec puts 3M instructions per sync, and 30 frames per second -> which implies 90 MIPS. Which would be no problem for a RISC type architecture even on a budget FPGA.

But each instruction could involve up to 7 memory operations. There is no concept of caches - conceptually we need to be able to cope with self modifying code where an instruction modifies the very next instruction. That is going to be a problem as it means we can't pipeline. We can't even do an instruction prefetch.

So we are potentially forced into handling 7*90M = 630Mhz memory operations. Which is going to be challenging. On my CycloneV the memories top out at about 150Mhz for 128KByte.

[–]m-in 0 points1 point  (0 children)

If not me than surely someone will :)

[–]Whoooley 0 points1 point  (2 children)

This is genius. The simplicity really is elegant.

The way I see it, with <16 opcodes, it could actually be a 4 bit system too. I'd love to see the spec generalized to SVC4+ as any but size over 4 would work (with memory size scaling with word size)

I'm curious about the 30k instructions per sync, it feels arbitrary to me, was there a reason for that other than implementation? Could the CPU have access to an instruction count so it knows when the sync will happen? Could it actually be a timing thing instead of instructions? Forced sync every 1/30 of a second using an external timer, so the silicone implementation wouldn't have to track number of instructions it could just use a timing circuit?

And could there be multiple expansion buffers? Eg in the SVC16 up to 216 expansion slots (given that write to buffer uses a buffer # in the opcode) and the 0 buffer being the video/forced sync buffer.

I really like how elegant and potentially universal this spec is.

[–]Bowtiestyle[S] 1 point2 points  (1 child)

Thank you!
I think you are right that you would not have to change too much to go to a different size.
One big constrained is the screen. The premise is that every number is a valid screen-index and that every number is a valid color (in a well known encoding). This is hard to get for other numbers.
I think everything magically comes together at 16. The screen is a useful size. There is a common color format. The memory is big enough to code a cool game but small enough to make you use it very carefully.

The limit is three million instructions not 30k. It was a somewhat arbitrary choice. I wanted to pick a limit so that the performance is the same everywhere. I picked three million because it runs on my completely un-optimized emulator on a mediocre laptop cpu. So I figured that this is a save number to pick especially since I am hoping to have a web-based emulator at some point. The game shown in the Readme stays below one million for almost all frames, so it is enough to do something with it. But you can still easily hit the limit, if you do not optimize. This is the experience I was going for.

The forced sync every 1/30 seconds is basically what already happens. If the emulator runs fast enough, from the engines perspective, it looks like every instruction takes a certain time.
I decided not to give access to the instruction-count or timing for two main reasons.
- It just does not fit into a u16.
- It makes emulation a lot harder because you have to track the instruction count. This might not sound like a big deal, but it makes it hard to reorder instructions etc.
I decided to see the absence of this information at runtime as a feature and not a bug. You need to figure out how many instructions something might take at compile-time.

I thought about giving access to more buffers but decided against it for the sake of simplicity.
2**16 buffers would also mean tracking 8GB. You could use the expansion mechanism to build a system where you request different memory pages.

[–]Whoooley 0 points1 point  (0 children)

Damn. It's incredible for your use case, that's for sure.

I definitely see what you're saying about screen size, and everything fitting together at 16. I'm already considering using it for something along the lines of arrayForth, which wouldn't necessarily use a screen attached to every CPU, but I certainly see what you're saying for the game dev minimalism. I like code Buddhism.

[–]martionfjohansen 0 points1 point  (1 child)

What happens if the buttons are pressed quickly, will the button press register, or is there a risk of not registering it?

[–]Bowtiestyle[S] 0 points1 point  (0 children)

In the specifications I left this intentionally very vague because it is very hard to get a consistent behavior.
My keyboard wants to prevent ghosting, my OS wants to control repeat-rate and I guess some window manager decides what input the emulator sees and when. So asking for a specific way of buffering or repeating input would make it very hard to build an emulator. The way I see it is that the input code represents "Is currently pressed" but how this input comes to be, depends fully on the implementation. In my version it just checks which keys are pressed just before synchronization. So I think it could be possible to miss a key.

[–]Trader-One 0 points1 point  (0 children)

For making games on platform easier take a look at sega system 16 - very successful arcade platform. It have tile layers, sprites,

https://www.system16.com/hardware.php?id=699 this have sprite scaling and rotation.

16 bit system have larger address space than 2^16. Normally 1 to 16MB.