microtron

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
Lerc
Posts: 15
Joined: 21 May 2020, 19:38

Re: microtron

Post by Lerc »

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., :-)
steve
Posts: 40
Joined: 08 Jul 2019, 19:40

Re: microtron

Post by steve »

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)

Fortunately this problem seems not there for the 590 if a "decoupled" VGA card design could be found: https://www.mouser.it/ProductDetail/Tex ... 32gA%3D%3D

Regarding sourcing don't really know the providers/stores. For the few ones I've seen I like very much mouser for its site usability.
Last edited by steve on 30 Aug 2020, 21:57, edited 2 times in total.
steve
Posts: 40
Joined: 08 Jul 2019, 19:40

Re: microtron

Post by steve »

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.
steve
Posts: 40
Joined: 08 Jul 2019, 19:40

Re: microtron

Post by steve »

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
monsonite
Posts: 101
Joined: 17 May 2018, 07:17

Re: microtron

Post by monsonite »

Steve,

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.

Perhaps you know a way around this?


Ken
steve
Posts: 40
Joined: 08 Jul 2019, 19:40

Re: microtron

Post by steve »

Ciao Ken!

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?
monsonite
Posts: 101
Joined: 17 May 2018, 07:17

Re: microtron

Post by monsonite »

Steve,

Thanks for the reply.

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.
steve
Posts: 40
Joined: 08 Jul 2019, 19:40

Re: microtron

Post by steve »

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)! :)
steve
Posts: 40
Joined: 08 Jul 2019, 19:40

Re: microtron

Post by steve »

For information, I've found a place where the ROM code page change happens:

Code: Select all

              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):

Code: Select all

              02fc 0200  nop
              02fd 0200  nop
ENTER:        02fe 0200  ld   $03,y
              02ff e003  jmp  y,.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
steve
Posts: 40
Joined: 08 Jul 2019, 19:40

Pull to a register

Post by steve »

Willing just to have a confirmation from the electronics savvy of you regarding the possibility to pull to a register and not just up or down.


This is the standard pull-up and pull-down:
ELECPullUpResistor.jpg
ELECPullUpResistor.jpg (55.12 KiB) Viewed 5008 times

I would just rotate one picture to make more clear the configuration I want to comment:
ELECPullUpResistor2.jpg
ELECPullUpResistor2.jpg (58.47 KiB) Viewed 5008 times

Now, instead of having ground or Vcc I would connect the output of a register:
ELECPullUpResistor3.jpg
ELECPullUpResistor3.jpg (60.69 KiB) Viewed 5008 times

In this configuration when the bus is three state (switch open) the output is the register value, else is the bus value, correct?

If this is possible as it seems other optimizations are available! 8-)
Post Reply