Logic Cortex -Programmable Microprocessor (WIP)

[Trekkerjoe]

I have resumed work on the program cartridge. The wireless would get stuck on because of instant pulses from the decoder, which meant that multiple cells would output at a time. I intend of fixing this by having the decoder on the computer, using 128 memory cells to filter out the signals. Hopefully this will allow it to function normally.

 

[walle_222]

I have resumed work on the program cartridge. The wireless would get stuck on because of instant pulses from the decoder, which meant that multiple cells would output at a time. I intend of fixing this by having the decoder on the computer, using 128 memory cells to filter out the signals. Hopefully this will allow it to function normally.

Sounds like your over building a bit, unless your processor is executing more than one instruction per clock cycle, you dont need that much io, you can always just use a bus to the memory, and then use a memory buffer with a pulse generator on It which stores the memory on the falling edge of the clock, then you can access it on the next cycle. If you need to write on every cycle, then you can use a double FF register design as a buffer that saves the result from the current cycle and feeds the data produced by the last cycle at the same time. The trickiest thing here is timing everything perfectly and making use of the rising edge and the falling edge of the clock pulse. Of course this produces a delay of 2 cycles before you can read the data, but when properly timed it works quite well. I used the same dual FF register design as the memory buffer between cycles of my program counter, and that thing can be overclocked with alterintel's clock. The only downside to his overclocker is that you have to hook up the output of it to a flip flop to cut the clock cycle in half and make it stable.

 

[Trekkerjoe]

The memory is bused. One output, one input. The problem is that I want it to run (at least in SP) at 4hz, making reads in two steps, effectively giving it the speed of 2hz. The problem I am facing was that even though I buffered the binary, the decoder on the cartridge was giving off instant pulses, which glitched out the I/O of the individual memory cells. I was planning to filter the output of the decoder itself to fix this.

I agree, there is probably a much better way of going about it. I had forgotten a method I could have used to stabilize the decoder. In addition, what you suggest makes a lot of sense. I think I may want to work out how I want to implement it. Problem is that I have no idea on how I am going to pipeline it, so maybe I should make the pipeline first, and then figure out how to speed it up.
[doublepost=1473006764,1473004078][/doublepost]And I fixed the problem with a minimum of rewiring. Thanks!

 

[Trekkerjoe]

Having fixed the problem with wireless and decoders, the memory cell was ready to be attached to a computer. With that out of the way, I have finally begun work on the computer itself:

I have the I/O pins, complete with interrupts that I hope to be able to configure through software as well as through the trainer. You probably noticed the square of logic. That is my ALU. I am not certain if it will stay where I put it, once I prototype the pipeline I will know the perfect place for it.

 

[Trekkerjoe]

It's been a while, hasn't it? By now you already are aware of my habits. Of course, that's not the reason I am posting here. My logic brain has rebooted once again and I think it's time to show off what I was doing.

I had conducted my first test of the pipeline system. It is a 2hz system, so twice as fast as my predecessor, and stable. It uses the conditional memory I have grown to love. Here's a GIF and an explanation behind it.

Spoiler: GIF

The memory cells come in pairs. The first one enacts an execute stage, and the second one stores the result and passes it along to the first stage of the next memory cell. Thus the cycle repeats. I will put the processing logic in between the execute and store stages.

Aside from this advancement in technology, I have also finished wiring up the I/O of the B Cortex. It comes complete with interrupts, which will be interesting to implement. In addition, I have put down the program counter and the very first stage of my pipeline. Still debating in my head if I should be moving the ALU or not. I probably will.

As always, advice is welcome.

 

[Xtremesonicboom]

I can't wait to see how you make this work with the new display systems. This computer using that system will be epic.

 

[Trekkerjoe]

Yes, now is a great time to make computers. I am already thinking that at the very least, I can get it programmable using the displays.

Writing to the displays is going to be simple. It will either have a writable display system built-in, or I may make it a separate module. to save space on the computer itself. Only problem I can see is the fact that it will take up quite a bit of space. Space I had not previously planned out for this.

 

[Lone_Puppy]

The new Display module features definitely open up a lot of possibilities!

 

[NeonSturm]

Please add support for:

1. Entering Binary data (as pairs of hexadecimals) into display blocks and reading them into RAM.
2. Use Display Modules as Very tight storage.
   1. [ADD]Hexadecimal
   2. Storage
   3. Storage copy
   4. Search with regex in the storage copy and delete first character.

 

[Jaaskinal]

With what NeonSturm said, this might be of some help. Display information storage

 

[Thalanor]

Yeah the awesome part about display blocks is that essentially, they store as much data as a hall full of 1bit RAM elements previously did. One can easily encode the state of 32 activation blocks into a single 32-bit integer, store it in a display module, and then convert it back from display block. Not only is this a 32 times more space efficient way already - but with some wiring it even supports polymorphism (you can work with data that is either an n-bit integer, or text. I might use this one day to create a system that, while only handling 8bit integers for calculations, can also work with text of up to 255 characters length - the entire station restaurant menu could fit into a single memory cell, haha)

 

[NeonSturm]

I haven't seen someone already building a parser - nice thing Jaaskinal !
But I disagree and say it's 256/512 times more space efficient!

The parser needs 20 display blocks to read/store 4 bits per second or half-second.
But the database only needs enough circuitry to store/receive text from one display block for that 255 characters long text.

 

[Thalanor]

With 255 unicode characters, technically one display block can store 4 kB. It is most likely not practical to make use of that full potential for starmade ingame purposes, though (especially since you really don't want to use all of unicode).

 

[NeonSturm]

For importing files it is great to use unicode.
But not for a database.

 

[Byamarro]

For importing files it is great to use unicode.
But not for a database.

Of course, technically it's just a workaround. Still, new display block mechanics allows us to make huge technological jump in SM logic.

 

[Trekkerjoe]

Of course, it may be a little while before I harness this new system. I started work on my computer well before this existed. I will try to have a parsing system, though. You should be able to simply type into the displays to program it.

 

[Byamarro]

Of course, it may be a little while before I harness this new system. I started work on my computer well before this existed. I will try to have a parsing system, though. You should be able to simply type into the displays to program it.

Parsing system is already built in. You can use Java regular expressions in new display modules.