179 lines
7.2 KiB
Markdown
179 lines
7.2 KiB
Markdown
# Dev notes — 2023-09-04
|
||
|
||
## To do
|
||
|
||
- [x] move recent sketch to its own branch
|
||
- [x] make a list of visual-research ideas
|
||
- [x] put “cpu datasheet” on it
|
||
- [ ] Implement keypad-based memory read/write (like ELF/KIM); see earlier notes for my design
|
||
- [ ] Maybe implement one IO pin, as described [below](#screen-memory-as-a-more-general-purpose-dmaio-area)
|
||
|
||
## Afternoon 2
|
||
|
||
- Interrupts and CPU-pin-based general-purpose IO are too far from being relevant to the real goal of this project — forget about 'em
|
||
|
||
### Screen memory as DMA area (general-purpose)
|
||
|
||
- ...but: it be cool to be able to print a copy of the screen...
|
||
- You would have a pin for 'DMA request'. When you're ready to write she screen out to the printer, you pull that high, signalling the printer to read from the screen memory, and then pull the pin low again.
|
||
- The same pin could presumably be used in the other direction, as an input...
|
||
|
||
## Afternoon 1
|
||
|
||
### Reflection on recent research
|
||
|
||
I have been trying to work out my answers to a few questions about the cpu design, mainly with the goal of deciding how programs should be loaded into the Cardiograph.
|
||
|
||
This has meant learning more about the details of cpu architecture — I’ve read some general reference material, as well as more specific material on the 1802 and 6502.
|
||
|
||
I’ve also made an incomplete (but instructive) sketch of a lower-level cpu simulation in Javascript.
|
||
|
||
This is all work that I will need to do eventually, since I hope to make a logic-level simulator of the system (in logisim), and maybe an FPGA implementation, etc.
|
||
|
||
(Those are things that I want to learn to do — but they also have good graphic potential. Logic and circuit schematics; timing diagrams (drawn or embroidered); …)
|
||
|
||
But for now I think I should put this line of inquiry on pause.
|
||
|
||
I think the answer to my “how are programs loaded” is (at least for now): through a keypad-entry system like the Cosmac Elf or the KIM-1. I’m now content that something like that can be made, and so I think for now the low-level implementation details aren’t critical.
|
||
|
||
Or, that’s a partial answer — another answer might be: from paper tape or punched cards. But I think that’s not fundamentally too different… (It could also be done by DMA while the cpu is held idle. Or it could be done through a short loader-routine, if the cpu has some general-purpose IO…)
|
||
|
||
And it’s the keypad entry that interests me for now, because that’s what I want to be able to implement on the simulator. (I already have something close enough to loading from tape, I think? For now, anyway.)
|
||
|
||
#### But wait, maybe there _is_ more…
|
||
|
||
Ah, but I had also wanted to work out:
|
||
|
||
1. what it would look like to have some general-purpose I/O
|
||
2. whether I need some interrupts
|
||
|
||
For I/O, I’m interested in something that might run a LOGO turtle, and maybe a printer.
|
||
|
||
For interrupts, I’m wondering if they’re needed for good keypad handling.
|
||
|
||
For both of those, the real Q is: Do I need new registers, and/or do I need new instructions?
|
||
|
||
(Can I service interrupts without a stack? Is that too weird?)
|
||
|
||
#### What next…?
|
||
|
||
- Implement keypad-based memory read/write (like ELF/KIM); see earlier notes for my design
|
||
- ~~Learn more about how interrupts were used with the ELF and KIM~~
|
||
- (maybe think about I/O for turtles and printers)
|
||
|
||
The ISA will probably have to change (as outlined in an earlier note), but I think not yet. Since the instructions should be staying the same, just getting re-numbered, that should be easy enough to do later, when creating a lower-level simulator makes it a necessity.
|
||
|
||
### Reading notes — re: ‘decode’ step of instruction cycle, plus other relevant bits of processor design
|
||
|
||
[The central processing unit (CPU): Its components and functionality | Enable Sysadmin](https://www.redhat.com/sysadmin/cpu-components-functionality)
|
||
|
||
> For example, when adding two numbers, one number is placed in the A register and the other in the B register. The ALU performs the addition and puts the result in the accumulator. If the operation is a logical one, the data to be compared is placed into the input registers. The result of the comparison, a 1 or 0, is put in the accumulator. Whether this is a logical or arithmetic operation, the accumulator content is then placed into the cache location reserved by the program for the result.
|
||
>
|
||
> There is another type of operation performed by the ALU. The result is an address in memory, and it is used to calculate a new location in memory to begin loading instructions. The result is placed into the instruction pointer register.
|
||
|
||
|
||
[1.4 Instruction Cycles - Engineering LibreTexts](https://eng.libretexts.org/Courses/Delta_College/Operating_System%3A_The_Basics/01%3A_The_Basics_-_An_Overview/1.4_Instruction_Cycles)
|
||
|
||
- fetch
|
||
- pc → mar
|
||
- pc++
|
||
- mem(mar) → mdr
|
||
- mdr → cir (current instruction register)
|
||
- decode
|
||
- [control unit decodes, signals to ALU et al.]
|
||
- indirect address
|
||
- read from memory
|
||
- direct address
|
||
- do nothing this pulse
|
||
- i/o or register instruction
|
||
- execute that
|
||
- execute
|
||
- [control unit passes decoded info as series of signals…]
|
||
- [if involved, ALU sends a condition signal back to CU]
|
||
- write out data to memory or i/o
|
||
- update PC if appropriate
|
||
|
||
[1.5 Interrupts - Engineering LibreTexts](https://eng.libretexts.org/Courses/Delta_College/Operating_System%3A_The_Basics/01%3A_The_Basics_-_An_Overview/1.5_Interrupts)
|
||
|
||
[1.8 Direct Memory Access - Engineering LibreTexts](https://eng.libretexts.org/Courses/Delta_College/Operating_System%3A_The_Basics/01%3A_The_Basics_-_An_Overview/1.8_Direct_Memory_Access)
|
||
|
||
- Bus Request and Bus Grant signals/pins
|
||
|
||
|
||
[Instruction Cycle in CPU: How Fetch, Decode and Execute work | ITIGIC](https://itigic.com/instruction-cycle-in-cpu-how-fetch-decode-and-execute-work/)
|
||
|
||
**[https://www.cl.cam.ac.uk/teaching/2021/DigElec/slides/Micro_20.pdf](https://www.cl.cam.ac.uk/teaching/2021/DigElec/slides/Micro_20.pdf)**
|
||
- see p. 5
|
||
|
||
- there are 2 internal registers holding inputs (eg numbers to add)
|
||
- arithmetic: CU sends to ALU:
|
||
- src_r1 - num 1
|
||
- src_r2 - num 2
|
||
- [destination reg]
|
||
- op
|
||
- memory load:
|
||
- CU sets
|
||
- src_r1 - address
|
||
- src_r2 - null
|
||
- [destination reg]
|
||
- a flag indicates whether to send those to the ALU or to memory
|
||
- memory stores data to destination reg
|
||
|
||
***
|
||
|
||
- maybe break CPU into classes for each control unit?
|
||
|
||
|
||
## Morning
|
||
|
||
### Keypad musings
|
||
|
||
This is the current layout:
|
||
|
||
```
|
||
1 2 3 C 1 2 3 4
|
||
4 5 6 D Q W E R
|
||
7 8 9 E A S D F
|
||
A 0 B F Z X C V
|
||
```
|
||
|
||
But the KIM-1 layout makes more sense...
|
||
|
||
```
|
||
on go st rs
|
||
ad da pc +
|
||
|
||
c d e f
|
||
8 9 a b
|
||
4 5 6 7
|
||
0 1 2 3
|
||
```
|
||
|
||
From [2023-08-31](2023-08-31.md):
|
||
|
||
> I'm thinking the system needs:
|
||
>
|
||
> 1. on/off switch
|
||
> 2. 'shift' key
|
||
> 3. hex keypad
|
||
>
|
||
> The 'shift' key allows each of the keypad keys to have two functions:
|
||
>
|
||
> `1 / + ` `2 ` `3 ` `C / ST`
|
||
> `4 ` `5 ` `6 ` `D `
|
||
> `7 / DA` `8 ` `9 ` `E / G1`
|
||
> `A / AD` `0 ` `B ` `F / GO`
|
||
|
||
A new idea:
|
||
|
||
```
|
||
AD DA . +
|
||
. . . .
|
||
. . . .
|
||
ST . G1 GO
|
||
```
|
||
|
||
### ISA
|
||
|
||
- mode for 'END' and 'NOP' can be called 'implied'
|
||
- http://www.emulator101.com/6502-addressing-modes.html |