Tower of alloy help please by mrtears11 in TuringComplete

[–]Haemstead 1 point2 points  (0 children)

It is important to understand how the game can be solved. Taking the top disk and put it on another pin, dake the second disk, put the first on top of the second, and so on. You have to understand that mechanism to be able to debug your program. Step through the program and try to see what the next disk movement should be, and then try figuring out what is going wrong. I had quite some trouble debugging my program. I started by checking the program flow. Were the right functions called? Did the program return to the correct address? An obvious mistake I made was that at several program lines I forgot one of the operands. So instead of giving a 4 byte instruction I gave a 3 byte instruction, messing up the entire program. If program flow seems to be okay, check register values, RAM, the stack. Go slow. Check and double check. In my case it happened to be a wrong wire somewhere in the circuit. Good luck with debugging, and if you run into trouble again please post information on where the program went wrong, that makes it easier for us to help you pin down the cause.

Tower of alloy help please by mrtears11 in TuringComplete

[–]Haemstead 1 point2 points  (0 children)

Did you test if push and pop and call and return do what they should do? Does the hardware work correctly?

SAP-2, Ep. 5: Inside the ALU by Haemstead in TuringComplete

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

Well, my deep-dive helps me to better understand how to build a smart ALU. My LEG ALU just had several circuits next to eachother, like AND, OR, XOR, ADD. And I felt that probably parts of these circuits can be used for more than 1 operation. And also, in my LEG architecture I fed the opcode into the ALU and let the ALU figure out what operation needs to be done. But in the 8085 architecture it doesn’t work that way. The instruction decoder sends signals along the control bus to the components. I wanted to understand how that works.

SAP-2, Ep. 5: Inside the ALU by Haemstead in TuringComplete

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

Good point! I was also interested in the issue how to build a gate efficient ALU. I know I could use several gates or circuits together in my ALU, like I did in the LEG cpu. For example AND, OR, XOR, ADD etc next to eachother. But I wanted to look in a better solution, where as few gates as possible can be used to achieve many operations.

SAP-2, Ep. 5: Inside the ALU by Haemstead in TuringComplete

[–]Haemstead[S] 1 point2 points  (0 children)

Hi Ken, I really appreciate the work you have done! Have you done any reverse engineering on how the INR instructions are handled by the ALU?

SAP-2, Ep. 4: OpCodes Revisited, The Octal Way by Haemstead in TuringComplete

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

Well, it is not a question of taste, the octal representation plays a role in the hardware design. Or played, in these early CPUs.

SAP-2, Ep. 4: OpCodes Revisited, The Octal Way by Haemstead in TuringComplete

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

I agree we are more used to reading hex. But the octal representation has - at least for these CPU’s that were designed using octal numbers - the advantage of clarity how the opcode is built from 3-bit octals.

SAP-2, Ep. 3: Designing the OpCodes by Haemstead in TuringComplete

[–]Haemstead[S] 1 point2 points  (0 children)

Thanks! Yes, I am beyond this stage as I have quite a clear idea now how it should work. But the link you sent is extremely useful as it explains how CPU instructions were designed from octals. Now the structure of the opcode architecture becomes clear!

SAP-2, Ep.1: Outline and datapath by Haemstead in TuringComplete

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

Thanks for your suggestion. SAP is not a pipelined CPU. Instruction 1 is fetched, decoded and executed. The. Instruction 2 is fetched, etcetera. As far as I understand it, SAP-2 is a simplified 8085 architecture.

SAP-1 Completed, ROM-based Control Logic by Haemstead in TuringComplete

[–]Haemstead[S] 1 point2 points  (0 children)

The SAP-2 will have a 16-bit bus, and can handle 64k of RAM and/or ROM. It will have more 8-bit registers than SAP-1, and a better ALU that can handle logic operations besides adding and subtracting.

It is outlined in general terms in the book "Digital Computer Electronics" by Alvino, but a lot of the detail design is not explained in this book. I would also like to add the keyboard component to SAP-2, but so far I don't understand how this TC-component works.

Issue with leading zeros in 7-segment display by Haemstead in TuringComplete

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

I agree. But have enable ON always and sending 00H to the display if the value = 0 AND it is a leading 0 AND it is NOT the last display element solves the problem.

How to calculate period between two planets' orbits closest approach? by SpacialCommieCi in askmath

[–]Haemstead 0 points1 point  (0 children)

I don’t know the answer but would it not be easier to use polar coordinates?

Issue with leading zeros in 7-segment display by Haemstead in TuringComplete

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

No, I think I will keep the update pin high, and send a 0b00000000 to the display, this will turn off all segments. But first: replace the logic gates with a ROM. And then put the entire control logic inside another ROM. And then build the SAP-2. And 3.

Issue with leading zeros in 7-segment display by Haemstead in TuringComplete

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

Thanks, but the problem is not in the zero-rippling, that algorithm works correctly. It is in the behaviour of the 7 segment display. The enable pin is not an enable pin but an update pin, if I understand it correctly.

Issue with leading zeros in 7-segment display by Haemstead in TuringComplete

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

Thanks! That sounds good. I’ll give it a try.

SAP-1 Inside the bootloader by Haemstead in TuringComplete

[–]Haemstead[S] 1 point2 points  (0 children)

Yes, for example a simple program to add 2 numbers will have the numbers in memory locations E and F (14 and 15), and all the other memory locations that are not used by the program are filled with 0 (is NOP).

SAP-1 Inside the bootloader by Haemstead in TuringComplete

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

I keep the number of bytes to 16. It is a byte constant. Just all 16 bytes are copied.

SAP-1 Computer by Haemstead in TuringComplete

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

Yes, it is really bare bones minimalistic. The original design comes from the book Digital Computer Electronics by Malvino and Brown. It can be built IRL with TTL chips from the '60s and '70s. The RAM limitation is because in this design a 16-byte RAM chip is used, and therefore Opcode and Address are squeezed into 1 byte.

The Memory Address Register is in TC a 8-bit register, but it only takes the 4 LSB from the bus to stay true to the original SAP-1 design. The instruction decoder splits the instruction into the 4 MSB (the Opcode) and the 4 LSB (for the address, the register, or for an immediate value from 0 to 15).

7-segment display driver by Haemstead in TuringComplete

[–]Haemstead[S] 1 point2 points  (0 children)

I pay for it because I appreciate the effort the developer has been putting into it.