diff --git a/2023-09-24.md b/2023-09-24.md index 6a36bd2..9cd06f2 100644 --- a/2023-09-24.md +++ b/2023-09-24.md @@ -1,5 +1,7 @@ # 2023-08-23 — Dev notes +# Morning + ## Architecture changes ### IO @@ -39,4 +41,194 @@ From the [Wikipedia article on booting](https://en.m.wikipedia.org/wiki/Booting) … -> The disk, tape or card deck must contain a special program to load the actual operating system or standalone utility into main storage, and for this specific purpose "IPL Text" is placed on the disk by the stand-alone DASDI (Direct Access Storage Device Initialization) program or an equivalent program running under an operating system, e.g., ICKDSF, but IPL-able tapes and card decks are usually distributed with this "IPL Text" already present. \ No newline at end of file +> The disk, tape or card deck must contain a special program to load the actual operating system or standalone utility into main storage, and for this specific purpose "IPL Text" is placed on the disk by the stand-alone DASDI (Direct Access Storage Device Initialization) program or an equivalent program running under an operating system, e.g., ICKDSF, but IPL-able tapes and card decks are usually distributed with this "IPL Text" already present. + +# Evening + +## THIS WAS WRONG: Sense switches + Status register brainstorm + +change status register format to: +```ss dd ffff``` + +- ss - sense switches +- dd - io devices +- ffff - flags + +then you are limited to + +- 4 switches +- 4 io devices +- 4 flags + +## Mainframe peripherals — new thoughts + +_this was written in response to the previous section, which i have abandoned… but i think the ideas here are still good_ + +~you could have an external switch that toggles between input from terminal vs punch~ + +~or i guess~ you make an all-in-one console that has a few modes + +1. keypunch +2. teletypewriter +3. card reader + line printer +4. card reader + computer-controlled + +ie, you can choose to connect… + +- no input devices +- card reader +- typewriter + +…and likewise for outputs (none / punch / printer). + +Now from the computer’s perspective the devices are: + +1. 8 sense switches +2. card reader / typewriter +3. card punch / line printer +4. display + +and this works fine because the card and tty interfaces are the same + +…and the sense switches get read as a binary number, + +- [ ] TODO: commit current readme, then… +- [ ] TODO: update readme with this design + +## Mainframe peripherals: give them their own bus? + +Should the DEV (IO device select) operation work over the address and data buses, or should it have its own? + +…I guess I need a better understanding of what DEV really does. + +OK I think that “DEV xx”: + +- copies xx to the Device ID register + +and then “OUT addr” + +- copies the Device ID to the data bus +- copies addr to the address bus +- disconnects the data bus from memory, and connects the data bus to … ? + - some multiplexer? decoder? thing? + - (“disconnects” just means doesn’t send memory its chip-enable signal i guess) +- disconnects data bus from mem / connects it to IO device +- sends IO device its chip-enable signal +- ?? … IO device writes directly to memory + +OR there’s a new register, IO buffer, and CPU handles the write to memory… + +but then how does card input work? + +perhaps: + +- when card reader receives a read signal, it feeds in a card, then reads it into an internal buffer… + +OK this is too complicated, let’s give up and redesign based on the IBM 701 + +## Mainframe peripherals: new new interface + +now we’ve got + +- registers: + - “DID” device id + - ~“BUF” io buffer~ +- operations: + - DEV did — io start + - INP # — read 1 byte into memory + - INP ind + - OUT # — write 1 byte from memory + - OUT ind + - FED — feed / end of record / newline + +it works like this + +- “DEV” selects the IO device + - loads device id into DID register +- “INP addr” … + - cpu sends io device an input request + - io device checks its internal buffer… if it’s empty, it reads the next unit (card / line) into the buffer + - io device shifts a byte from the buffer to the data(?) bus + - cpu copies addr to the address bus + - cpu sends memory-write signal +- “OUT addr” + - cpu copies byte from addr to data bus + - cpu signals io device + - io device reads from data bus + - … io device does output + - … if io device is at end of line/card/etc, if does a line/card feed +- “FED” + - cpu signals io device to feed + - io device feeds + +_! what i don’t understand is how the 701 signals the end of a record/card/line — or how I should do that_ + +→ ok it seems like the 701 has a control line that the card reader uses to signal the end of a card + +→ also it halts the computer when it runs out of cards… is that good? + +(the timing might be tricky here. it might be better to have the io device buffer the data as soon as it is selected. or maybe it’s even more complicated than that.) + +## CPU connections + +- [ ] TODO: need pins for memory access — RW (signal which you want) and ME(?) (when this is high, memory performs the r/w on the rising edge of the next clock… or sth like that) + +Some relevant parts of the 8086 pinout: + +- M/IO — O — distinguish between memory and IO operations: IO is high, M is low +- /WR — O — write signal — write to memory or to output device, depending on state of M/IO +- /RD — O — indicates that the processor is performing a memory or IO read cycle, depending on state of M/IO +- READY — I — acknowledgement from memory/IO that it will complete the data transfer + +## Architecture idea: core + extensions + +it might make sense to think in terms of something like the RISC V standards, where you the architecture is split into a mandatory core + optional extensions + +1. core computational operations — ie, the original set of 16 operations +2. additional arithmetic operations — mul, div, rotates +3. additional IO operations — dev, inp, out (ie the mainframe-style IO that i’m working on today) + +then + +- the basic microprocessor trainer would implement just the core computational ops +- (an extended microprocessor trainer could implement the core ops + the arithmetic extension) +- the mainframe would implement core + arithmetic extension + IO extension + +(i _think_ that a system with the core ops + arithmetic & bitwise extensions could implement all of the mainframe IO in software, so an extended microprocessor trainer could be source compatible with the mainframe…) + +the extensions could also be broken down differently: + +1. core computational ops +2. arithmetic extension: multiplication and division +3. control flow extension: jump less than / greater than +4. bitwise arithmetic extension: asl, asr, rrl, rrr… plus maybe AND, OR, XOR, NOT + - [ ] TODO: i think these all only work on the accumulator? + +? would that make the ISA feel tidier? + +- [ ] TODO: try that + +- [ ] ? TODO: in readme, rename “arl” and “arr” to “asl” and “asr” + +## Sense switches + status register — oops, this still needs rethinking + +give the device number its own register + +then change the status register layout to +```ssss ffff``` — 4 sense switches, 4 flags + +the switches can be read like flags (ie with JFL) + +``` +s4 s3 s2 s1 o n z c +80 40 20 10 08 04 02 01 +``` + +(just remember that you can’t use FTG on the switches…) + + +## IBM 701 + +https://mrochkind.com/new/701/Programming-the-IBM-701-2.pdf + +> The emulator doesn’t have a reader that can read real cards, so, instead, binary cards are in a file with a “.deck” suffix that contains a sequence of binary words, each corresponding to a word on the card. One card follows another in the file, so the first 24 words are card 1, the next 24 are card 2, and so on. \ No newline at end of file