steve wrote: ↑24 Aug 2020, 11:37
Despite not reducing logic gates, replacing the four X and PC incrementers with two 867 might reduce even further chip count also in "standard gigatron" (as a "type 1" change with full hw/sw compatibility). And without external carry ripple might be even marginally faster.
The 590 instead seems to me a viable option to explore for the design of the separate VGA card.
You're aiming for the Microtron to be mostly SMD right? My preference would be to go for things in the JCLPCB(or similar) parts list so people could get something with all the fiddly bits done.
I'm guessing you're against the idea of doing a layout with 161 chips really close together and then sticking a piece of black tape over the pair with 74HC867 written on it.,
Lerc wrote: ↑24 Aug 2020, 21:09
You're aiming for the Microtron to be mostly SMD right? My preference would be to go for things in the JCLPCB(or similar) parts list so people could get something with all the fiddly bits done.
I'm guessing you're against the idea of doing a layout with 161 chips really close together and then sticking a piece of black tape over the pair with 74HC867 written on it.,
My current skills are far away from SMDs, and even if I really like the artistic vision of the black tape onto the chips pair, I was thinking more something like this: https://it.aliexpress.com/item/4000115922318.html. But I got the point: the circuit in itself seems still produced even by TI, but not packaged in the PDIP format, that seems just chinese manufacturers are now providing (more than 50000 available just from the seller I was pointing out). PS: I've found out that TI is still producing a "54" version of it SN54AS867JT also in CDIP format! (cfr https://www.ti.com/lit/ds/symlink/sn74als867a.pdf)
PS I was by chance reading trough the very interesting post on high resolution and seems that the 7 bits per color change was already been spot and took into consideration by Marcel for various use:
marcelk wrote: ↑20 Apr 2019, 22:18
But we don't have enough bits for two independent 4-bit RGBI pixels. So we need a trick. Many monitors appear to accept a combined (XOR'red) vSync/hSync signal on the hSync line (for support of composite sync). If this is true, we can modify the software and have 7 bits for the color info. This is the first step.
This then opens up the possibility to assign, for example, 3 bits of RGB to each of the two pixels, and 1 shared bit for intensity. That gives many gradients. But it's not a too great choice, because contrast is important and in this arrangement we can't have black and white in the same pixel pair.
Sharing the blue component in pixel pairs might work better instead. The eye is least sensitive to blue after all. We still can't have black and white together, but blue and white come closer than grey and white.
PPS another thing I've found reading old posts is this one: https://hackaday.io/project/160506-4-bi ... of-the-alu
Is a 10 chip "mammoth" and so still not really fitting into the microtron, but if it would be fast enough in case of gigatron this version would at least diminish the gate counts, replacing two full adder chips with two quad XOR ones
Not sure how throwing away the full-adders helps at all.
Remember that the Roelh design uses 7 ICs to make a 4-bit ALU. The Gigatron achieves an 8 bit ALU in 10 ICs. Moving to the 74xx151 8 input multiplexer may offer some reduction in package count.
Remember that the Gigatron can also generate a zero flag used during jump instructions - by inverting A and using the output carry to indicate that A is zero.
Regarding the Roelh ALU I was referring to the one depicted on the page I was pointing out that was seemingly using 8x 74153 and 2x 7486. My worry was about the ripple carry delay. But you're right, this version is not suitable since it's also missing the required subtraction.
monsonite wrote: ↑30 Aug 2020, 14:16
The Gigatron achieves an 8 bit ALU in 10 ICs. Moving to the 74xx151 8 input multiplexer may offer some reduction in package count.
Everything that can optimize chips count and/or logic gates count is interesting. There is a way?
When I first saw the Roelh alu - I was concerned how the ADD function could be achieved from just multiplexers and XOR gates, but after some consideration, a full adder is essentially just two XOR gates and an AND or NAND to provide the final carry out.
The problem with using multiple stages of full adders ( 8-bit or 16-bit) is the propagation delay of the final carry out - and this problem is partially resolved by using the 74HCT283 4-bit full adder which has internal fast carry logic. Excluding the internal buffers the 74xx283 has an internal gate count of some 32 gates.
To me this inexpensive part looks the ideal building block for a bit-slice ALU, done as a series of 4-bit slices. This is effectively what the alu Marcel designed, (adapted from Dieter Muller's design) - as a package count of only 5 parts for each 4-bit slice - which is somewhat of an improvement on Roelh's 7 IC design.
Each slice is self contained, with only carry out passing to the next stage, and for larger word lengths - say 16-bits, the design is compact and easily replicated across the pcb.
It is only in Marcel's pcb layout where the ALU looks like a 10 chip Mammoth - this was done for ease of maintaining broad track separation, plus the fact that the accumulator, bus buffer and extended output are included down the centre of the ALU - making it look even larger. If laid out using a more rigorous bit-slice approach - the board area could be considerably reduced, but it has to be appreciated that the ALU alone consumes almost 40% of all the TTL chip count.
Having been inspired by the Gigatron, and experimented with a version overclocked to 12.5MHz - I have started to look at my own 16-bit variant, using a register file, rather than a single accumulator. The dseign follows a strict bit-slice approach (as was common in early TTL computers) with each identical slice containing between 10 and 12 packages - which includes the ALU with left and right shifter, the register file, the program counter and some miscellaneous X, Y, Xout registers. Added to this would be the control unit, the ROM and the RAM. Total package would be about 60 to 64 packages.
I have simulated the 4-bit slice and hope to continue with the detailed design this autumn.
Regarding size, I was not referring to physical board space (and by chance I've seen back your very nice replacement to which I've given my star a long time ago), but chips count.
10 chips out of 38 is a relevant percentage in gigatron, but in the case of microtron I'm trying to stay around the 20 chips in total, and the only way I've found so far to optimize the current ALU design is to remove it and do the processing via software, as gigatron project itself taught me from the beginning (I remember it on every second slide of the presentation)!
And good luck also with your project (and hope you might able to gather some idea from microtron anyway)!
02fc 0200 nop
02fd 0200 nop
02fe 0200 nop
ENTER: 02ff fc03 bra .next2 1465 bra('.next2') #0 Enter at '.next2' (so no startup overhead)
NEXTY: 0300 1517 ld [$17],y 1469 ld([vPC+1],Y) #1
NEXT: 0301 8115 adda [$15] 1474 adda([vTicks]) #0 Track elapsed ticks (actually counting down: AC<0)
0302 e80b blt EXIT 1475 blt('EXIT') #1 Escape near time out
.next2: 0303 c215 st [$15] 1477 st([vTicks]) #2
0304 0116 ld [$16] 1478 ld([vPC]) #3 Advance vPC
0305 8002 adda $02 1479 adda(2) #4
0306 d216 st [$16],x 1480 st([vPC],X) #5
0307 0d00 ld [y,x] 1481 ld([Y,X]) #6 Fetch opcode (actually a branch target)
0308 de00 st [y,x++] 1482 st([Y,Xpp]) #7 Just X++
0309 fe00 bra ac 1483 bra(AC) #8 Dispatch
030a 0d00 ld [y,x] 1484 ld([Y,X]) #9 Prefetch operand
It has been done like this to squeeze one more byte for the interpreter loop. To make it working when the autoincrement for the PCH is removed the change should be as simple as loading Y before the branch instruction and then do a long jump instead of the short one (addresses 2fe-2ff):