Add new (very rough) notes
This commit is contained in:
n loewen
parent
6d112b6e79
commit
4b35057f78
|
|
@ -0,0 +1,149 @@
|
|||
# 2023-09-07 — Dev notes
|
||||
|
||||
## card 7 sept
|
||||
|
||||
XXIIVV — varvara
|
||||
|
||||
- i like their standardized IO…
|
||||
|
||||
- what IO do i have/want…?
|
||||
- bitmapped display
|
||||
- keypad
|
||||
- ? printer
|
||||
- ? paper tape / card reader
|
||||
|
||||
- other standard choices are…
|
||||
- GPIO
|
||||
- ascii keyboard
|
||||
- serial terminal
|
||||
- audio
|
||||
|
||||
- how about re-imagining it as a game system?
|
||||
- just because that would help to explain the lack of standard IO
|
||||
- but also it would ruin the whole idea of it being a model computer lol
|
||||
|
||||
- ok so cardiograph shouldn’t have Keyboard, etc, because like a microprocessor trainer wouldn’t
|
||||
- (but a mainframe would… hmm)
|
||||
- but at any rate, it would be nice if the CPU _did_ support those possibilities
|
||||
|
||||
- todo: look at uxntal runes and see how they compare to mine
|
||||
|
||||
|
||||
|
||||
https://github.com/DeltaF1/uxn-impl-guide/blob/main/devices.md
|
||||
|
||||
> The Varvara specification asserts that the Uxn CPU core is non-interruptible. That is, the CPU is left to run on its current task until it hits a BRK instruction, even if some event happens in the host system ( such as the mouse moving ) Once the CPU stops executing, the next event can be serviced.
|
||||
> Each device specification outlines the conditions under which the device vector will be triggered. Execution begins at the device's "vector" address. If this address is equal to 0x0000, then no code is executed. By convention, the first 2 bytes of each device store the device's vector address as a short.
|
||||
> The initial vector that gets run by the emulator at startup is hardcoded to be address 0x0100.
|
||||
|
||||
- my understanding: this is similar to what i have… these “vectors” are memory-mapped inputs that are constantly kept up to date, but only read when a BRK instruction is encountered. when that happens, whatever routine you have pre-registered as an event handler gets called.
|
||||
- Q: is that right?
|
||||
- Q: is this a standard design?
|
||||
- Q: let’s see some examples?
|
||||
|
||||
|
||||
|
||||
[Scamp CPU: A homebrew 16-bit CPU with a homebrew Unix-like-ish operating system | Hacker News](https://news.ycombinator.com/item?id=29408046)
|
||||
|
||||
> I think the most surprising thing to me is the lack of interrupts. If you read this, jstanley: did you struggle much with that decision? I think of interrupts as nearly universally available on 8-bit micros, much less 16, but I have also wondered before how important they really were for what those machines ended up being used for. The (S)NES polled their controllers' shift registers in a really inefficient way, but it turned out fine. On the other hand, though, the vertical blank interrupt was pretty critical to their software and, of course, it became extremely common for NES cartridges to add extra chips to raise interrupts on particular horizontal scanlines. But, aside from neat graphical tricks, maybe interrupts just weren't all that important?
|
||||
|
||||
…
|
||||
|
||||
> You don't need to implement a nested vectored interrupt controller. Even just a timer/counter with overflow interrupt would solve your current issues with lockup by allowing you to implement preemptive multitasking. Once you do that it would be easy-ish to extend to the serial controller.
|
||||
> Basically, on interrupt flag = 1, 1. Disable further interrupts (no nesting). This makes things easier to implement. 2. Save register state. For speed a special set of shadow registers can be used, or you can put register state on the stack. 3. Jump to interrupt routine code start. 4. Let interrupt handler run, clear interrupt flag, then return.
|
||||
> In the simplest case an input flag simply causes a CALL (push pc, jump to address). In that case the interrupt handler needs to know to save state. You can test flags between instructions to see if you need to inject the push/jump.
|
||||
|
||||
…
|
||||
|
||||
> CP/M is really incredibly simple. You have some "kernel" type stuff towards the top of memory, with routines for reading/writing files on disk, and interacting with the console and a paper tape "reader + punch". When you type a command, the named program is loaded from disk into memory starting at 0x100 and then execution starts at 0x100. To interact with hardware, the program calls the kernel's routines (analogous to system calls). And that's basically all there is to it.
|
||||
|
||||
…
|
||||
|
||||
|
||||
> 6502 is a very simple CPU and you can learn all of its instructions in several hours. But as it uses 1- address instructions, the code gets pretty verbose. For example, to add 10 to a variable you will have to write:
|
||||
>
|
||||
> ```
|
||||
> LDA var
|
||||
> CLC
|
||||
> ADC #10
|
||||
> STA var
|
||||
>```
|
||||
> That's 4 lines and many keypresses for a single addition! You might want to invent slightly more high-level language that would compile into assembly, like this:
|
||||
>
|
||||
> ```
|
||||
> var, var2 = variables (2)
|
||||
> var t=10
|
||||
> var2 << 5 # Assign 5 to var2
|
||||
>```
|
||||
> By the way, you can use Python and operator overloading so that the lines above written in Python will generate assembly code when executed. I have used << instead of = in assignment because Python doesn't allow to
|
||||
overload it.
|
||||
|
||||
•••
|
||||
|
||||
!! [Keyboard interaction on the Apple II is entirely CPU-dependent, memory-mapped, a... | Hacker News](https://news.ycombinator.com/item?id=20404825)
|
||||
|
||||
|
||||
[How the C64 Keyboard Works | C64 OS](https://c64os.com/post/?p=45)
|
||||
|
||||
|
||||
•••
|
||||
|
||||
[jes/scamp-cpu: A homebrew 16-bit CPU with a homebrew Unix-like-ish operating system.](https://github.com/jes/scamp-cpu)
|
||||
|
||||
•••
|
||||
|
||||
i still want to understand the uxn approach better, and see if there’s prior art
|
||||
|
||||
•••
|
||||
|
||||
it seems like not having interrupts is fine
|
||||
|
||||
you just gotta do polling, but that’s ok (and what some 8-bit micros did anyway)
|
||||
|
||||
and this should really help with the goal of making the simplest CPU possible
|
||||
|
||||
another thing that will help is leaving DMA to some other chip… and having a pin that pauses the CPU (like 1802/6502) should make that easy
|
||||
|
||||
which means I think the CPU pinout can just be:
|
||||
|
||||
- power
|
||||
- ground
|
||||
- address x8
|
||||
- data x8
|
||||
- “dma okay”
|
||||
- pause
|
||||
- reset
|
||||
|
||||
(for later thought: bank-switching requires a memory controller… and how do we want to interface with that?)
|
||||
|
||||
|
||||
•••
|
||||
|
||||
Todo: make index for dev notes
|
||||
|
||||
|
||||
•••
|
||||
|
||||
1802 clear + wait: load, reset, pause, run
|
||||
|
||||
•••
|
||||
|
||||
[game boy - How does the Gameboy's memory bank switching work? - Retrocomputing Stack Exchange](https://retrocomputing.stackexchange.com/questions/11732/how-does-the-gameboys-memory-bank-switching-work)
|
||||
|
||||
[Bank Switching - C64-Wiki](https://www.c64-wiki.com/wiki/Bank_Switching)
|
||||
|
||||
•••
|
||||
|
||||
consider an ISA with multiple operands?
|
||||
|
||||
good article: https://en.wikipedia.org/wiki/Orthogonal_instruction_set
|
||||
|
||||
## Platforms to think about writing simulators for:
|
||||
|
||||
- Web
|
||||
- Meowbit
|
||||
- Microbit
|
||||
- C64
|
||||
- Gameboy
|
||||
- Gameboy Advance
|
||||
- Nintendo DS
|
||||
|
|
@ -0,0 +1,133 @@
|
|||
## 2023-09-08 — Dev notes
|
||||
|
||||
- what changes are required to address more memory?
|
||||
|
||||
•••
|
||||
|
||||
- drop the Overflow flag?
|
||||
- … what flags does uxn have?
|
||||
|
||||
•••
|
||||
|
||||
-
|
||||
|
||||
- what do we do if we want to ask the tape reader (etc.) to read in some data?
|
||||
- is it enough to have that device do polling??
|
||||
- what does uxn do?
|
||||
- networking???
|
||||
- how does the gameboy link cable work?
|
||||
- [emulation - How does the Gameboy Link Cable work? - Retrocomputing Stack Exchange](https://retrocomputing.stackexchange.com/questions/12549/how-does-the-gameboy-link-cable-work)
|
||||
|
||||
[Serial Data Transfer (Link Cable) - GbdevWiki](https://gbdev.gg8.se/wiki/articles/Serial_Data_Transfer_(Link_Cable))
|
||||
|
||||
|
||||
gb link cable has 1 gb clocking the other, for synchronization
|
||||
|
||||
program ideas:
|
||||
- machine monitor w output to graph display
|
||||
|
||||
•••
|
||||
|
||||
- reconsider flags… i think i want to drop the overflow flag…
|
||||
|
||||
•••
|
||||
|
||||
https://en.wikipedia.org/wiki/MIX
|
||||
|
||||
https://en.wikipedia.org/wiki/DLX
|
||||
- good info on instruction cycle!
|
||||
|
||||
https://en.wikipedia.org/wiki/MicroBlaze
|
||||
|
||||
https://en.wikipedia.org/wiki/Little_Computer_3
|
||||
|
||||
[Let's build an LC-3 Virtual Machine :: Rodrigo Araujo — Computer Scientist and Software Engineer](https://www.rodrigoaraujo.me/posts/lets-build-an-lc-3-virtual-machine/)
|
||||
|
||||
- nb: section on TRAP
|
||||
- get char
|
||||
- write char
|
||||
- puts
|
||||
- prompt…
|
||||
- putsp
|
||||
- KBSR & KBDR mem mapped regusters
|
||||
|
||||
[great piece on building an LC-3 VM](https://justinmeiners.github.io/lc3-vm/)
|
||||
|
||||
enum
|
||||
{
|
||||
OP_BR = 0, /* branch */
|
||||
OP_ADD, /* add */
|
||||
OP_LD, /* load */
|
||||
OP_ST, /* store */
|
||||
OP_JSR, /* jump register */
|
||||
OP_AND, /* bitwise and */
|
||||
OP_LDR, /* load register */
|
||||
OP_STR, /* store register */
|
||||
OP_RTI, /* unused */
|
||||
OP_NOT, /* bitwise not */
|
||||
OP_LDI, /* load indirect */
|
||||
OP_STI, /* store indirect */
|
||||
OP_JMP, /* jump */
|
||||
OP_RES, /* reserved (unused) */
|
||||
OP_LEA, /* load effective address */
|
||||
OP_TRAP /* execute trap */
|
||||
};
|
||||
|
||||
|
||||
LC-3 just has flags for pos, zero, neg
|
||||
|
||||
> You may be wondering why the trap codes are not included in the instructions. This is because they do not actually introduce any new functionality to the LC-3, they just provide a convenient way to perform a task (similar to OS system calls). In the official LC-3 simulator, trap routines are written in assembly. When a trap code is called, the PC is moved to that code’s address. The CPU executes the procedure’s instructions, and when it is complete, the PC is reset to the location following the initial call.
|
||||
> Note: This is why programs start at address 0x3000 instead of 0x0. The lower addresses are left empty to leave space for the trap routine code.
|
||||
|
||||
…
|
||||
|
||||
> Note: Getting input from the keyboard is one specific example of this. The assembly version uses a loop to continuously check the keyboard for input.
|
||||
|
||||
KBSR = keyboard status
|
||||
KBDR = keyboard data
|
||||
|
||||
and those seem to just have regular memory addresses
|
||||
|
||||
https://www.jmeiners.com/lc3-vm/supplies/lc3-ref-card.png
|
||||

|
||||
|
||||
•••
|
||||
|
||||
! https://en.wikipedia.org/wiki/MikroSim
|
||||
|
||||
•••
|
||||
|
||||
these educational machines seem to never cover actually loading a program into memory / bootstrapping ….
|
||||
|
||||
|
||||
•••
|
||||
|
||||
- should i rename IP to PC since that’s what everyone else calls it?
|
||||
|
||||
•••
|
||||
|
||||
[history - Which computers did Donald Knuth "mix" together to get MIX? - Retrocomputing Stack Exchange](https://retrocomputing.stackexchange.com/questions/18117/which-computers-did-donald-knuth-mix-together-to-get-mix)
|
||||
|
||||
•••
|
||||
|
||||
[PDP-10 Arith-Tests](http://pdp10.nocrew.org/docs/instruction-set/Arith-Tests.html)
|
||||
|
||||
•••
|
||||
|
||||
[Learn PDP-11 Assembly Coding Lesson 1 - For absolute beginners! - YouTube](https://www.youtube.com/watch?v=sk5Y26Qb1Ow)
|
||||
|
||||
•••
|
||||
|
||||
[freedosproject/toycpu: A simulation of a Minimal instruction set computer](https://github.com/freedosproject/toycpu)
|
||||
|
||||
- great readme opcode reference
|
||||
- this has a front panel! loading!
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
[How a CPU works: Bare metal C on my RISC-V toy CPU · Florian Noeding's blog](https://florian.noeding.com/posts/risc-v-toy-cpu/cpu-from-scratch/)
|
||||
|
||||
|
||||
https://edaplayground.com/
|
||||
|
|
@ -0,0 +1,45 @@
|
|||
# Dev notes — 2023-09-10
|
||||
|
||||
Links to organize:
|
||||
|
||||
- https://www.youtube.com/watch?v=21bQBCfMDb8
|
||||
- https://www.masswerk.at/google60/
|
||||
- https://www.masswerk.at/nowgobang/2021/nerdy-reading
|
||||
- https://www.masswerk.at/misc/card-punch-typography/
|
||||
- https://www.masswerk.at/6502/
|
||||
- https://en.wikipedia.org/wiki/Charactron
|
||||
- https://dsinecos.github.io/blog/Using-Bitmasks
|
||||
- https://www.youtube.com/watch?app=desktop&v=eA3TtCCNmKo
|
||||
- ? mail robots
|
||||
- https://www.atlasobscura.com/articles/mailmobiles-mail-robots-technology-retirement
|
||||
- https://www.cbc.ca/radio/day6/episode-357-little-rock-nine-historians-vs-neo-nazis-tabatha-southey-fired-robots-yuval-harari-and-more-1.4309188/so-long-and-thanks-for-all-the-mail-cbc-retires-its-fleet-of-mailbots-1.4309201
|
||||
- https://news.ycombinator.com/item?id=37155752
|
||||
|
||||
- Weisbecker archive
|
||||
- https://digital.hagley.org/AVD_246409_040_06#page/6/mode/2up
|
||||
|
||||
|
||||
- https://socks-studio.com/2013/06/29/computer-graphics-archaeology-the-hp-9845c-demo/
|
||||
- http://wiscasset.net/artcraft/antheil.htm
|
||||
- http://wiscasset.net/artcraft/pleyel6.htm
|
||||
|
||||
|
||||
|
||||
- popular press:
|
||||
- https://www.npr.org/sections/alltechconsidered/2014/10/06/345799830/the-forgotten-female-programmers-who-created-modern-tech
|
||||
- https://www.nytimes.com/2019/02/13/magazine/women-coding-computer-programming.html
|
||||
|
||||
- artwork reference:
|
||||
- https://www.pinterest.ca/pin/322851867052077355/
|
||||
- https://en.wikipedia.org/wiki/Deltar
|
||||
- https://damprojects.org/wp-content/uploads/2018/08/PressReleaseCODE_POETRY_EN.pdf
|
||||
- http://digital-abstraction.net/catalog/flicker/index.html
|
||||
- https://en.wikipedia.org/wiki/Arnulf_Rainer_(film)
|
||||
- https://www.youtube.com/watch?v=JC0o2Msvdpg
|
||||
- https://bethany.remingtonjohnson.com/work/field-notes/
|
||||
- https://bethany.remingtonjohnson.com/work/woven-landscapes/
|
||||
|
||||
- MANY DAM PROJECTS
|
||||
- https://damprojects.org/computergrafik1984/
|
||||
- https://damprojects.org/codepoetry/
|
||||
- & look at others
|
||||
Loading…
Reference in New Issue