Added docs and verilog stuff and data sheets

.gitignore

@@ -2,3 +2,4 @@
 **/*~
 **/*.vvp
 
+/verilog/_old/

README.md

@@ -346,7 +346,7 @@ DEC <come register>
 
 ## Save a control line 
 
-? Memory map the Display device?
+?Memory map the Display device?
 
 The display register steals a control line. In principal this could just be mapped to a specific memory location which would free up the control line
 for something useful, for instance doubling the number if Input or Output devices on the bus. This might for instance allow me to implement Branch on Equals.
@@ -360,6 +360,8 @@ Though to be fair I have two selector lines going into the ALU and use only one
 
 This is a biggie.
 
+See also the ongoing [design of the ALU](docs/alu_with_carry_in.md).
+
 Having no logical operations at all is far from ideal.
 
 But this would mean feeding at least three selector lines into it, which could give me 8 potential operations rather than the two I have currently implemented. 
@@ -375,10 +377,10 @@ Or perhaps the variable length instruction idea could yield benefits by giving m
 
 Obviously, being able to simulate all this before building is fantastic.
 
-Considering basing the future ALU on a similar set to that used by [CrazySmallCpu](https://minnie.tuhs.org/Programs/CrazySmallCPU/description.html) ...
+I am considering basing the future ALU on a similar set to that used by [CrazySmallCpu](https://minnie.tuhs.org/Programs/CrazySmallCPU/description.html) ...
 
 ```
-The ALU can perform sixteen operations based on the A and B inputs:
+Currently the ALU can perform sixteen operations based on the A and B inputs:
 A + B decimal
 A - B decimal
 A & B

docs/alu_with_carry_in.md

@@ -2,9 +2,45 @@
 
 This ALU design is based on [Warren Toomey's CSCvon8 ALU](https://github.com/DoctorWkt/CSCvon8/blob/master/Docs/CSCvon8_design.md) but with a few small changes to incorporate a carry-in for a few of the ops. CSCvon8n does this switch in software/microcode. 
 
-Like CSCvon8 the design relies on the [M27C322 2Mx16 EPROM](http://pdf.datasheetcatalog.com/datasheet/stmicroelectronics/6184.pdf). This 2M x 16bit device is great for an 8 bit ALU as it allows 21 bits of addressing which is enough for 2 lots of 8 bits of data-in, plus 5 bits for ALU function selection. The 16 bits out allows for a full 8 bit result, with the remaining 8 bits of data output providing a full complement of status flags. More details can be found in the [CSCvon8 documentation](https://github.com/DoctorWkt/CSCvon8/blob/master/Docs/CSCvon8_design.md) 
+Like CSCvon8 the design relies on the [M27C322 2Mx16 EPROM](http://pdf.datasheetcatalog.com/datasheet/stmicroelectronics/6184.pdf). This 2M x 16bit device is great for an 8 bit ALU as it allows 21 bits of addressing which is enough for 2 lots of 8 bits data-in, plus 5 bits for ALU function selection. The 16 bits out allows for a full 8 bit result, with the remaining 8 bits of data output providing a full complement of status flags. More details can be found in the [CSCvon8 documentation](https://github.com/DoctorWkt/CSCvon8/blob/master/Docs/CSCvon8_design.md) 
 
-The SPAM-1 ALU  ROM functions are ...
+Inputs
+----
+
+- 8 bit : A
+- 8 bit : B
+- 5 bit : Operation selection - see carry logic below
+
+Flags and Jumps
+----
+
+ALU operation result flags:
+- D : div by zero
+- N : negative result 
+- Z : zero result
+- V : signed overflow
+- C : carry
+
+CSCvon8 synthesises comparator results EQ/NE/GT/LT/LE/GE by selecting appropriate an ALU operation and selecting particular output flags, and using these flag for the jumps. For example with the operation _A-B_ then the _C_ out flag set can be used to trigger a jump for _A<B_ 
+
+With 3 remaining output bits from the ROM one could possibly also provide  comparator outputs for each combination of inputs:
+- GT : A > B
+- LT : A < B
+which could be externally combined to produce
+- EQ : /GT AND /LT
+
+or just two :
+- GE : A >= B
+- LE : A <= B
+which could be externally combined to produce
+- EQ = GE AND LE
+
+Leaving 1 bit for something.
+
+ALU Functions
+----
+
+The SPAM-1 ALU ROM functions are ...
 
 | 0-7 ALU Ops | 8-15 ALU Ops      | 16-23 ALU Ops     | 24-31 ALU Ops |
 |-------------|-------------------|-------------------|---------------|
@@ -17,6 +53,8 @@ The SPAM-1 ALU  ROM functions are ...
 | B+1         | __A-B-Cin (1)__   | A >> B logical    | A+B (BCD)     |
 | A-1         | __B-A-Cin (1)__   | A ROL B           | A-B (BCD)     |
 
+Re "A-B (special)" above, see [CSCVon8 ALU design](https://github.com/DoctorWkt/CSCvon8/blob/2b362a9e793238ebd150855a6dd6c5987674c7c6/Docs/CSCvon8_design.md) for an explanation of "Special"
+
 Where this ALU differs to CSCvon8 is that I wanted the SPAM-1 arithmetic for A and B to take the carry bit into account in the hardware. So in column 2 where I have 3 such operations at 9/10/11 and at 13/14/15.
 
 For these 6 addition/subtraction functions the value of the second address line into the ROM will be derived from the carry bit rather from the raw bit 2 coming from the control logic. To achieve this there will be an additional bit of multplexing logic external to the ROM. (If we could find a 4Mx8 DIP EPROM, with an additional address line then this external logic could have been avoided). In any case the additional logic selected either the carry-flag or the original address line and looks like this ...

docs/components.md

@@ -33,14 +33,18 @@ Also https://youtu.be/lO_9Zz5jzAA?t=3841
 
 Quest: Where is the 8 bit register with +ve edge, /WE and tristate!! The 4 bit [74LS173](http://www.ti.com/lit/ds/symlink/sn54173.pdf), has clock, OE, WE = but only 4 bits (16 pin package)  
 
-
 |Chip|Org|Trig|Input Enable|Tristate|Pinout|Other|Desc|
 |--|----|--|--|--|--|--|--|
 |[74HC574](https://assets.nexperia.com/documents/data-sheet/74HC_HCT574.pdf)|8|+ve||/OE|bus||8 bit reg - edge triggered - tristate|
 |[74HC273](https://assets.nexperia.com/documents/data-sheet/74HC_HCT273.pdf)|8|+ve|||bus|/RESET|8 bit reg - convenient pin out at sides 
 |[74HC377](https://assets.nexperia.com/documents/data-sheet/74HC_HCT377.pdf)|8|+ve|/E||pairs|| 8 bit reg - convenient pin out at sides - includes write enable 
-|[74HC646](https://assets.nexperia.com/documents/data-sheet/74HC_HCT646_CNV.pdf)|8 bi-dir|+ve|no - see note|/OE|wrap|direction|interestng chip but this [other datasheet](http://noel.feld.cvut.cz/hw/motorola/books/dl129/pdf/mc74hc646rev6.pdf) carries an important caveat.. "_The user should note that because the clocks are not gated with the Direction and Output Enable pins, data at the A and B ports may be clocked into the storage flip–flops at any time"_ - so no Write enable facility.|
-|[74HC652](http://www.ti.com/lit/ds/symlink/sn74hc652.pdf)|8|+ve multifunction bi-dir||yes|bus|latching/reflecting|high feature but no way to disable clocking in of data
+
+**Other 8 Bit Curiosities**
+
+|Chip|Org|Trig|Input Enable|Tristate|Pinout|Other|Desc|
+|--|----|--|--|--|--|--|--|
+|[74HC646](https://assets.nexperia.com/documents/data-sheet/74HC_HCT646_CNV.pdf)|8 bi-dir|+ve|no - see note|/OE|wrap|direction|same internals as 74HC652 but fewer input options as uses a "direction" pattern on pins - interestng chip but this [other datasheet](http://noel.feld.cvut.cz/hw/motorola/books/dl129/pdf/mc74hc646rev6.pdf) carries an important caveat.. "_The user should note that because the clocks are not gated with the Direction and Output Enable pins, data at the A and B ports may be clocked into the storage flip–flops at any time"_ - so no Write enable facility.|
+|[74HC652](http://www.ti.com/lit/ds/symlink/sn74hc652.pdf)|8|+ve multifunction bi-dir||yes|bus|latching/reflecting|same internals as 74HC647 but more flexible input options - but high feature but no way to disable clocking in of data
 
 **4BIT** 
 
@@ -63,7 +67,7 @@ Quest: Where is the 8 bit register with +ve edge, /WE and tristate!! The 4 bit [
 
 Also ...
 
-- [74fct2573](https://www.ti.com/lit/ds/symlink/cy74fct2573t.pdf) - fast version (10ns slowest transition) of 74HCT573 (30ns slowest transition)
+- [74FCT2573](https://www.ti.com/lit/ds/symlink/cy74fct2573t.pdf) - fast version (10ns slowest transition) of 74HCT573 (30ns slowest transition)
 
 Read back latch ...
 

docs/digital-simulators.md

@@ -123,7 +123,7 @@ I particularly like the claimed 80% test coverage. I understand Logism also lack
 
 Again probably worth a look.
 
-Given Digital's connection back to Logism it's a pity there's no way to import a Logism circuit :(
+Given Digital's connection back to Logism it's a pity ther/e's no way to import a Logism circuit :(
 
 UPDATE: 11 Aug 2019 - went back and had a play with Digital. I found it difficult to work with. Specifically there is no convenient way to paste contents into the ROM component (unlike Logism Evo) so you have to edit each byte in turn or use a file. I was able to entry multibyte values despite it being an 8 bit wide EEPROM. Eventually the program errored with a null pointer exception (I have reported stack trace). So I don't think I'll be going back again for now. 
 

docs/instruction-set.txt

@@ -1,24 +1,19 @@
 RAM addressing modes
 
 		HI	LO
-Zero page	0	ROM	Zero by pull down 
+Zero page	0	ROM		H/W uses Zero by pull down 
 Zero page	0	ANYREG	
-Zero page	0	ALUOUT	??
 
-Reg paged	REG	ROM	ANY REG or specific gp reg OR sp reg ??
-Reg paged	REG	ANYREG	
-Reg paged	REG	ALUOUT	??
+Reg paged	ANYREG	ROM	
+Reg paged	ANYREG	ANYREG	
+Reg paged	RAMVAUE	ANYREG	
+Reg paged	RAMVAUE	ROM	
 
 Counter registers - specific one or two??
 
 
-ROM
 
-
-LD PCTEMP, IMMED      SPECIAL PURPOSE REG?? OR USE GP REG?
-LD PCTEMP, REG
-LD PCTEMP, ALU
-LD PCTEMP, ROM
+LD PCTEMP, ALU 		
 
 LD PCLO, IMMED
 LD PCLO, REG

inst.txt

@@ -0,0 +1,110 @@
+RAMVAL is one of 
+	[00,#KK]
+	[00,LO]
+	[HI,#KK]
+	[HI, LO]
+
+
+Load Register
+=============
+
+Assembler needs logic per ALU op to determine valid syntax
+Some ALU ops only have one postfix arg of either Left or Right eg ++/+1 or --/-1 or "NOT" 
+What apbout prefix ops like -R0 does alu support?
+
+
+Do I want the right side of infix ops to allow RAM or ROM?
+My guess is RAM would be on left to as shft size or add/minus would be a constant?
+ALU and its bus wiring will probably force is to be one way or the other.
+
+Destinations = OUTPUT|R0|MARLO|MARHI|PCLO|PCTEMPHI|PCLO+PCHI => 7 therefore 3 bits
+Bus Access = INPUT|ALU|MARHI|MARLO << 1 bit vs 2 so perhaps better to dedicate second bit to more GP registers eg 8 instead of 4?
+
+RAMVAL is one of 
+	[00,#KK]	Immediate Zero page 
+	[00,LO]		Registered Zero page
+	[HI,#KK]	Immediate paged
+	[HI, LO]	Registered
+
+AddrMode = 2 bits as above
+
+
+Direct ...
+
+SET [R0|LO|HI|PCLO|PCTEMPHI] = INPUT
+
+Via ALU to Reg ...
+
+SET [OUTPUT|R0|MARLO|MARHI|PCLO|PCTEMPHI|PCLO+PCHI] = [R1|RAMVAL] INFIX_OP [R2|#KK]     
+SET [OUTPUT|R0|MARLO|MARHI|PCLO|PCTEMPHI|PCLO+PCHI] = [R1|#KK] {optional POSTFIX_OP eg "R1 + 1" if alu supports that, or prefix op "NOT R1" }
+SET [OUTPUT|R0|MARLO|MARHI|PCLO|PCTEMPHI|PCLO+PCHI] = [R1|RAMVAL] {optional POSTFIX_OP eg "R1 + 1" if alu supports that, or prefix op "NOT R1" }
+
+SET [OUTPUT|R0|MARLO|MARHI|PCLO|PCTEMPHI|PCLO+PCHI] = INPUT     // OUTPUT is illegal target spotted by assembler
+
+ALU does not need +/-1 ops as it can do R+/-#KK from assembler
+
+R1|RAMVAL 	= 0-6 + 1RAM = 3 bits     7 addressable registers + RAM immediate
+R2|KK		= 0-6 + 1ROM = 3 bits
+
+
+SET=b=1     OP=4bit          TARG=3       L=3BITS 	R=3BITS    K=8bits      TOTAL=15+8=23  3x8
+            OP=0 special     TARG=3       SOURCE=INPUT IMPLIED                  TOTAL=8
+
+
+SET [OUTPUT|R0|PCLO|PCTEMPHI|PCLO+PCHI] = [MARHI|MARLO]   // ?????
+
+
+
+Load UART ...
+
+SET [R0|MARLO|MARHI|PCLO|PCTEMPHI|PCLO+PCHI] = INPUT
+
+
+Via ALU to RAM
+
+SET RAMVAL = [R1|#KK] INFIX_OP R2  	
+SET RAMVAL = [R1|#KK] {optional POSTFIX_OP eg +1}
+
+
+
+Direct to RAM
+
+SET RAMVAL = INPUT		
+
+
+
+
+==== JUMPS ====
+
+Do we let jumps to labels only and let assembler work out if its a local or long jump?
+What about return from call?
+
+I think gigatron allows only constants in jump/branch instructions - this would seem necessary for the local jump to avoid illegal values that would wrap around the ROM page
+
+JMP 		XX		same as SET PCLO=XX above - jumps absolute within current ROM page, PCHITEMP is NOT loaded into PCHI 
+				- assembler should ideally prevent jump off page but we can't do that if we allow a variable (RAM/REG) as the jump address??
+				- so presumably jumps with vars will always be 16bit including RET statements (RETURN is synthesised by assembler as is CALL)
+LONGJMP 	XX		jumps absolute by triggering PCHI=PCHITEMP as well as PCLO=XX
+
+Assembler macros:
+
+LONGJMP #KK, #kk	assembler shortcut for :
+	SET PCHITEMP=#KK
+	LONGJMP #kk		
+
+LONGJMP #KKKK	assembler shortcut for :
+	SET PCHITEMP=high(#KKKK)
+	LONGJMP low(#KKKK)		
+
+LONGJMP :label	assembler shortcut for :
+	SET PCHITEMP=high(:label)
+	LONGJMP low(:label)		
+
+Assembler can also provide macros like 	high(:label) and low(:label) for example if wanting to somewhat usefully mess with label addresses for storing in RAM or jumps etc
+
+CALL	same as JMP/LONGJMP but puts current PC onto the stack in RAM first
+
+PUSH 	[R0|#KK|INPUT]     	copy source to stack and then decrement SP (ram locn) - synthesised by assembler
+POP 	[R0|#KK|OUTPUT] 	increment SP (ram locn) and copy from stack to target - synthesised by assembler
+
+RETURN - this needs to be able to load PCHI and PCLO from RAM on stack - load PCHITEMP first then load using PCLO+PCHI

inst1.txt

@@ -0,0 +1,121 @@
+RAMVAL is one of 
+	[00,#KK]
+	[00,LO]
+	[HI,#KK]
+	[HI, LO]
+
+
+Load Register
+=============
+
+Assembler needs logic per ALU op to determine valid syntax
+Some ALU ops only have one postfix arg of either Left or Right eg ++/+1 or --/-1 or "NOT" 
+What apbout prefix ops like -R0 does alu support?
+
+
+Do I want the right side of infix ops to allow RAM or ROM?
+My guess is RAM would be on left to as shft size or add/minus would be a constant?
+ALU and its bus wiring will probably force is to be one way or the other.
+
+Destinations = OUTPUT|R0|MARLO|MARHI|PCLO|PCTEMPHI|PCLO+PCHI => 7 therefore 3 bits
+Bus Access = INPUT|ALU|MARHI|MARLO << 1 bit vs 2 so perhaps better to dedicate second bit to more GP registers eg 8 instead of 4?
+
+RAMVAL is one of 
+	[00,#KK]	Immediate Zero page 
+	[00,LO]		Registered Zero page
+	[HI,#KK]	Immediate paged
+	[HI, LO]	Registered
+
+AddrMode = 2 bits as above
+
+
+Direct ...
+
+SET [R0|LO|HI|PCLO|PCTEMPHI] = INPUT
+
+Via ALU to Reg ...
+
+SET [OUTPUT|R0|MARLO|MARHI|PCLO|PCTEMPHI|PCLO+PCHI] = [R1|RAMVAL] INFIX_OP [R2|#KK]     
+SET [OUTPUT|R0|MARLO|MARHI|PCLO|PCTEMPHI|PCLO+PCHI] = [R1|#KK] {optional POSTFIX_OP eg "R1 + 1" if alu supports that, or prefix op "NOT R1" }
+SET [OUTPUT|R0|MARLO|MARHI|PCLO|PCTEMPHI|PCLO+PCHI] = [R1|RAMVAL] {optional POSTFIX_OP eg "R1 + 1" if alu supports that, or prefix op "NOT R1" }
+
+SET [OUTPUT|R0|MARLO|MARHI|PCLO|PCTEMPHI|PCLO+PCHI] = INPUT     // OUTPUT is illegal target spotted by assembler
+
+ALU does not need +/-1 ops as it can do R+/-#KK from assembler
+
+
+Can't use Immediate Ram addressing and Immediate Rom Operand at same time if #KK differs.
+Assembler just bans multiple appearances of #KK unless same const
+But being able to do 
+	"R$ = RAM[OO,LO] + #KK" is useful
+	"R$ = RAM[OO,#KK]" is useful
+	"RAM[HI,#KK] = R$" is useful
+	"RAM[HI,LO] = #KK" is useful
+
+
+R1|RAMVAL 	= 0-6 + 1RAM = 3 bits     7 addressable registers + RAM immediate
+R2|KK		= 0-6 + 1ROM = 3 bits
+
+
+
+SET=b=1     OP=4bit          TARG=3       L=3BITS 	R=3BITS    K=8bits      TOTAL=15+8=23  3x8
+            OP=0 special     TARG=3       SOURCE=INPUT IMPLIED                  TOTAL=8
+
+
+SET [OUTPUT|R0|PCLO|PCTEMPHI|PCLO+PCHI] = [MARHI|MARLO]   // ?????
+
+
+
+Load UART ...
+
+SET [R0|MARLO|MARHI|PCLO|PCTEMPHI|PCLO+PCHI] = INPUT
+
+
+Via ALU to RAM
+
+SET RAMVAL = [R1|#KK] INFIX_OP R2  	
+SET RAMVAL = [R1|#KK] {optional POSTFIX_OP eg +1}
+
+
+
+Direct to RAM
+
+SET RAMVAL = INPUT		
+
+
+
+
+==== JUMPS ====
+
+Do we let jumps to labels only and let assembler work out if its a local or long jump?
+What about return from call?
+
+I think gigatron allows only constants in jump/branch instructions - this would seem necessary for the local jump to avoid illegal values that would wrap around the ROM page
+
+JMP 		XX		same as SET PCLO=XX above - jumps absolute within current ROM page, PCHITEMP is NOT loaded into PCHI 
+				- assembler should ideally prevent jump off page but we can't do that if we allow a variable (RAM/REG) as the jump address??
+				- so presumably jumps with vars will always be 16bit including RET statements (RETURN is synthesised by assembler as is CALL)
+LONGJMP 	XX		jumps absolute by triggering PCHI=PCHITEMP as well as PCLO=XX
+
+Assembler macros:
+
+LONGJMP #KK, #kk	assembler shortcut for :
+	SET PCHITEMP=#KK
+	LONGJMP #kk		
+
+LONGJMP #KKKK	assembler shortcut for :
+	SET PCHITEMP=high(#KKKK)
+	LONGJMP low(#KKKK)		
+
+LONGJMP :label	assembler shortcut for :
+	SET PCHITEMP=high(:label)
+	LONGJMP low(:label)		
+
+Assembler can also provide macros like 	high(:label) and low(:label) for example if wanting to somewhat usefully mess with label addresses for storing in RAM or jumps etc
+
+CALL	same as JMP/LONGJMP but puts current PC onto the stack in RAM first
+
+PUSH 	[R0|#KK|INPUT]     	copy source to stack and then decrement SP (ram locn) - synthesised by assembler
+POP 	[R0|#KK|OUTPUT] 	increment SP (ram locn) and copy from stack to target - synthesised by assembler
+
+RETURN - this needs to be able to load PCHI and PCLO from RAM on stack - load PCHITEMP first then load using PCLO+PCHI