combinator computer MK2

[siggboy]

It is a little discouraging because when you are challenging me this way

I'm not challenging you in any way. I'm just pointing out that your challenge was a bit besides the point, because this thread is not concerned at all with solving practical Factorio problems. It's about making a general CPU.

I hope you ever tried to make read and write in 60 IPS! Because at the moment I can not (I can do it in 20 IPS). And I assume you cant either

Combinators update each tick, so it's certainly possible to update a register each tick => 60 writes per second. If your register takes longer, then it's due to some other mechanism that goes beyond (re)writing, or it's an inferior register implementation.

But I know what you're talking about, nothing of this is straightforward. Many operations involve several combinators, so they happen at a delay, and then those delays need to be taken into account which makes things really complicated really quickly.

I hope discouragement is not intended because I do know a thing or two about what you are talking about, I just happend to be interested in actual use of the things we are doing, not just some proof of concept.

This is a universal CPU. You can write any program that you need on it, and then use that. I don't understand what you mean by "proof of concept". It's an actual CPU, it works, and it's reasonably fast at 20 IPS, probably fast enough to implement solutions for most problems a factory poses.

And I know this challenge has nothing to do with piriforms fantastic concepts 1-4, I am just trying to ask some people if they are interested in such a challenge.

Again, these are more than concepts, it's a programmable computer. You can write a program for it that "solves" your challenge.

Probably you should make a separate thread for your scenario.

[piriform]

I've updated the original post with a link to video and a sheet with source etc.
Blueprint string will have to wait until the mod is updated for 14.xx

[siggboy]

I've updated the original post with a link to video and a sheet with source etc.
Blueprint string will have to wait until the mod is updated for 14.xx

I think I might try and play around with this. I'd need to write an assembler in LUA and maybe also a simulator to debug the programs. The goal would be to re-implement my train scheduler for the MK2, could be fun -- and I don't really have another project right now anymore in Factorio.

Blueprint String should work fine in 0.14, just update the version tag manually.

I haven't updated to 0.14, I don't see the point in having mods breaking for no reason and then having to update manually. The devs need to find a solution for this non-issue ASAP. Why should we waste our time?

[matjojo]

I haven't updated to 0.14, I don't see the point in having mods breaking for no reason and then having to update manually. The devs need to find a solution for this non-issue ASAP. Why should we waste our time?

I don't think so: a mayor update is most of the time an upgrade that breaks all mods, it wasn't this time as multiplayer apperantly did not change too much, but the tag is there to prevent the players from seeying the problems as the modders are still working on an update. Plus .14 is still in development phase, and not yet stable, it's not meant for player use without causion (though stable means different things for different cases). when .14 is stable excpect updates to the mods very quick, as modders have been using the experimental updates to make sure the mods have a fix ready when .14 gets declared stable.

[siggboy]

The problem is that even if the modder has found the mod to be safe in 0.14, it's impossible to convey that information. You cannot declare the mod to be compatible with 0.13 and 0.14. You have to release two separate mods just to cover this triviality, and it's quite silly.

Versioning and dependency declaration is not rocket science, much more complicated systems are in use, for example in Linux distributions. The current system in Factorio is just too limited and simplistic.

It's also possible to structure your versioning in a way that makes it possible to declare mods to be forward compatible. It has been called "semantic versioning". The 0.14 release was a case where proper semantic versioning would have allowed for mod upgrades without the hassles, and it still gives the devs the possibility to declare major upgrades which possibly break mods.

In any case it needs to be possible to release a mod which explicitely states that it's compatible with multiple versions of Factorio.

[piriform]

I've updated Dave's mod to load in 14. GUI does not appear however, and that is worrying. Could it be related to the God's mode? If so does anybody know the latest incantation to descend into the mortal plane?
------------------------------------------------------------------------
EDIT
It wasn't God's mode. Was able to create a character by typing in the obvious
game.player.create_character() ( well, Duh!) but still no bp gui. I'll pm DaveMcW and ask for help, so maybe.

[cid0rz]

The CPU looks amazing. I'm willing to get the blueprints and see how it works better. With videos I get lost, xD Thank you for the time to share and explain all this

[piriform]

Thanks to Foreman I have added a blueprint string to the original post. The only bad thing about posting the string is now everyone can see some of the quick and dirties I resorted to in order to get it up and reasonably bug free.

I think I might try and play around with this. I'd need to write an assembler in LUA and maybe also a simulator to debug the programs. The goal would be to re-implement my train scheduler for the MK2, could be fun

That'd be great! Please show it off if you decide to do it.

The CPU looks amazing. I'm willing to get the blueprints and see how it works better. With videos I get lost, xD Thank you for the time to share and explain all this

By all means. The blueprint string is there, so dig into it.

[piriform]

I'm attaching a blueprint string and instructions for an interrupt handling circuit you can add to M4 CPU.

Code: Select all

H4sIAAAAAAAA/8VXYW+bMBD9KxEfN5iALOmqyvu+/YVqQi4cyUlgI2OyZoj/PkNoBokBQ6n2qUrtO5v37r07R3yT8JAmm4CUwCRKhJyUJaMpECuCECMQTsjT
F2RUcmHZGc/VJs5I+Uoc78vOPqs/lR2hgLD5/94OOZOCJ8ELHOkJuSBlmyhQK1ETrc6IUeQyyPHAaEJKec7UgSghtezL4YL+dmLMj1Zl51AHjuxVuYCK1Enp
gf5BBipG3Tmjor4zsb5bNi9kVhgeF/LsrK5aMBnEgqcBMhVKYprkUNWrjF0+VX3Es+VZv0gpIFKgNfidA4zIzg5RhAXK+oengg4CgPW2eN0tfmV3lvz+kgp/
tnzdMf7MY9SWOlvLLhUojylIDCcJ9rsE+xqC/+WaxTFNEJhDhcSYhtKE6Q5NPAPFb30j65MBwfc1YkimZ0rH15uNq9PhauS2IhtaFbFcUiaJ57quCeInFLKg
yVvKy6LzYxDse4huURyE+2EYyynjcjVlvZZvaVCcrOoED0epdJCqi863Li1v77Uwg2J+WCQMb9TrNMds17CwyRa1UDO9ttFqpSeUz7N6zxJL6gPquaas7IeT
PC6XVou3+8EjQQfsrlzIXFsaUIoUxaJer6/g/XCvH9TQRJbV+HLXpWsMaC1jQwanTwQnEGd5RHZYg7rtMC+P06x+G2VrxPNGiOyrt8/kG4CDVHq3PqebDWJM
JIh6xjcnTiGsdF1PAMgieG3ubBL98xq9u8b6d7FjjbCO9drIrfkM8Y7RoPWvyYn3Y/xrnhr+k38tGsmMx9vJoWxGpx4ryznNejDPsoocg/D26dhgiGGTfUQ4
mrKuBtXae4Jpeamuaq3afciUbYgiU6+0JwGyEGwTPAGL/gK+F9TeQRAAAA==

Picture of a possible installation:

interrupt.gif (256.15 KiB) Viewed 8320 times

Note the red wires to instruction address(input) bus, instruction signal (output) bus, and the green wire (top arithmetic combinator input.
Green wire carries interrupt request (alien artifact). In this case it was generated by the IRQ Monostable .
Once the interrupt circuit and the interrupt generator have been installed, sacrifice one program ROM cell by changing its address to 500 ( i.e. I=500), and inserting J=isr (where "isr" is address of the interrupt service routine) in the constant combinator.

How to use it:
Add "ammo" signal right at the program start. This will disable interrupts.
Once the stack pointer (i.e. S register) has been set, enable interrupts by adding "fish" signal to one of the instructions.
Enter Interrupt service routine (ISR) at some convenient (i.e. J=isr) memory location.
ISR is called that because it "services" interrupts and could look something like this:

Code: Select all

isr: disable    ; ammo//disable further interrupts 
      push,A    ; tr.stop,st.axe,r.belt,c,water// save registers if necessary- good thing S has been set!
      push,X    ; tr.stop,w.chest,axe,r.belt,c,water
      push,Y    ; tr.stop,st.chest,axe,r.belt,c,water
      push,Z    ; tr.stop,st.tank,axe,r.belt,c,water
      ..........;                                                         // do some real work
     pop,Z      ; -tr.stop,gr.sci,rock.launch,p.insrt,water //restore the registers
     pop, Y     ; -tr.stop,gr.sci,c.s.gun,b.insrt,water
     pop,X      ; -tr.stop,gr.sci,subm.gun,y.insrt,water
     pop,A      ; -tr.stop,gr.sci,h.gun,1,water
     enable     ;  fish  //return control back to the main program, and permit further interrupts

Some notes about this implementation
a) Interrupts can not be nested - Sorry!
b) There is only one priority- see a)
c) Interrupt Request ( alien artifact signal) should be fairly short. If IRQ duration exceeds ISR duration, one may end up processing the same interrupt several times. Ideally, ISR should be able to reset IRQ generator.


Finally, I've tested the hardware and software and everything seems to work. Interrupts can be tricky however, and it's quite (very) possible that there are situations I've not anticipated or tested. If you do find any, please let me know.

[Megatron]

1.move to a single tick execution cycle

I tried that. I ran into massive problems with caching (I wasn't able to store a value in 1 tick) and register dependecies and pipeline stalls.
In the end with a superpipeline with about 13 stages I managed to get it to 2 ticks per instruction (assuming no register dependencies or stalls due to branches). some instructions like memory access always use 4 ticks so I didn't even manage 30 operations per second consistently.

[piriform]

I tried that. I ran into massive problems with caching (I wasn't able to store a value in 1 tick) and register dependecies and pipeline stalls.
In the end with a superpipeline with about 13 stages

Yep. I feel the same way about caching,register dependencies and stalls.
13 stage pipeline?

Right now I'm thinking that chasing ticks is a bit of a mug's game. 20-30 IPS may be sufficient if some instructions can do a Lot (eg. 100+ compares or adds).

[Megatron]

I tried that. I ran into massive problems with caching (I wasn't able to store a value in 1 tick) and register dependecies and pipeline stalls.
In the end with a superpipeline with about 13 stages

13 stage pipeline?

3 ticks fetch, 2 ticks decode, 1 tick flush (if necessary), 2 ticks checking for dependecies, 1 tick read register, 4 ticks execution, 1 tick writeback.

So 14 steps actually. Each step has to be a stage because if I want it to be fast then that's the clockrate to use hence more like a superpipeline.
I made a very dense main memory (840 bytes per 45 tiles / 21 combinators) which unfortunately needs 3 ticks to read from and 4 ticks to write to.
Execution times may actually vary but I forced them to be 4 ticks long to simplify the dependency check and inserting bubbles into the pipeline.
Every 4 ticks I fetch one doubleword which can contain 1 or 2 instructions. This makes checking for dependencies easier and allows me to write to memory during execution (my memory design doesn't allow simultaneous reads and writes)
Furthermore I can implement DMA because there are ticks where memory operations can be inserted.

I'm redesigning my main memory now so I can fetch way more 8 instructions at once, which might be unavoidable to execute one instruction each tick.

A lot can has to be done in parallel. Even when fetching 1 instruction per tick, the pipeline would have to be even longer to check for everything in time, which makes flushing it crazy expensive.

Or maybe it is possible somehow. I didn't come up with anything clever so far.

[piriform]

3 ticks fetch, 2 ticks decode, 1 tick flush (if necessary), 2 ticks checking for dependecies, 1 tick read register, 4 ticks execution, 1 tick writeback.

hmm. having trouble understanding implications of placing dependency check (branches etc.?). ahead of execution. I do the opposite as it seems more natural

cudos for getting it to work. Have you, or do you plan on publishing it?

[Megatron]

3 ticks fetch, 2 ticks decode, 1 tick flush (if necessary), 2 ticks checking for dependecies, 1 tick read register, 4 ticks execution, 1 tick writeback.

hmm. having trouble understanding implications of placing dependency check (branches etc.?). ahead of execution. I do the opposite as it seems more natural

cudos for getting it to work. Have you, or do you plan on publishing it?

With a fixed execution time and fetching two (or one) instructions every 4 ticks each instruction is only dependent of the last 2 ones (the third last will have written back it's result by then). Therefore it's simple to check if a result will be used in an upcoming operation.
I can delay both instructions for a specific time, drop the following 2 (or one) instructions that arrive and adjust the program counter to refetch the following instruction, all within 2 ticks after decoding.
The following instruction then arrives exactly 2 ticks after the delayed ones finish, under some circumstances unfortunately 4 ticks later.

Well, implementing everything by just making it huge is not a problem, but I'm too picky when it comes to design. I have many instructions (memory operations, branches or register writes with immediate values) that take 4 ticks. I have not sorted out how branching should work (checking for flags and therefore previous results and flushing the pipeline will be awfully slow).
Meanwhile im still fighting with trying to get it to work with 1 tick per instruction.
But yes, I'm going to post it here once it works.

[gms0012]

sry guys that i use this old thread..

but some links in this thread are dead...

i am very interested in building a computer like this..

but how it the input (assembler file) done? how can factorio read a (assembler) textfile?

any advices/hints would be great

thanks

[Gertibrumm]

Probably mods.. ?
I never considered this as an option, as I am a purist in all game related things
By the way, programs running in a game should never be too long anyway.
Assembly is easy enough to go manual.

How are the midi file importers doing it?

[ohAitch]

I just put "machine code" into a bunch of constant combinators manually yeah, though I remember setting up RAM by blueprinting a block of identical cells, using the lua console to renumber them sequentially, and building the blueprint. There's probably something similar you could do with setting built combinators' values directly.