Page 1 of 5

microtron

Posted: 22 Jul 2020, 19:16
by steve
I’m sorry for this long post, but I hope that some of you can reach the end of it appreciating the synthesis I did of more than one year of scattered thinking of the various solutions… :)


**Introductory notes**

Everything started more than one year ago when I saw a presentation of a guy (Walter) that with a beer in one hand was talking about a strange microcomputer in an hotel hacker conference… I got immediately interested, and as soon as I've seen the very nice documentation, ideas started gathering to hack it and optimize even more (I'm passionate about minimalistic things)!

For one month I accumulated them, but entering even more in the “build your own processor” community I got into relay based ones that are similarly challenging in terms of design, but easier to build and test with rudimentary electronic skills and instruments, and in some way more fun (the satisfaction of looking and hearing electro-mechanical relays moving is different than looking at static black ICs, and for this blinkenlights were a wonderful idea!).

The relay computer project is still ongoing (together with few others), but again by chance after looking at the fantastic PucMon youtube video I got the call to try at least to put the ideas together and see them with the community, hoping some of you might like to collaborate on them and so motivating myself in going forward, get even more ideas and surely minimizing the errors that will be made in case of implementation.

Some of these changes retain full "retro compatibility", but in general the idea is to simplify even more the design trying to remain compatible at vCPU level, keeping the 70s philosophy and the “software can replace hardware” approach of the project (in fact in few places extending this concept)!

All of them have still to be tested, but personally I think that most of them should work, but even being able to implement just some of them can be an interesting result!

I analyzed each part of the machine trying to find ways to reduce components and logic gates, as well as trying to preserve as much as possible the functionalities, and where possible even extending them (as for VGA). In terms of pure reduction being able to implement all the changes proposed could save around 10 integrated circuits, but even half of them I think would be a great result!

Reducing even more the number of chips should also help more people to be involved in this very interesting area of homebrew CPU design, making it easier to build and hack!

Below a selected set of changes to the original platform:


**Removal 2:1 multiplexers for Y**

Since high byte of RAM address can be 0 or Y, the same effect of the double 2:1 multiplexers can be obtained using a 374 chip for Y register in combination with pull-down resistors, simply routing the multiplexer selection to Y output enable

This change should be fully usable also with the "standard" gigatron, saving 2 chips on the total count.

To optimize current consumption for TTL the Pull Down circuits can be transformed in pull up switching the page o to the page FF. This also depending if pull-down is or not faster than pull-up!


**Removal 2:1 multiplexers for X**

Without the 2:1 multiplexer on X we lose the possibility of a direct memory addressing from ROM, that will require one additional instruction to load X. One instruction more where required but two chip less in general, seems a good tradeoff and fully aligned with gigatron ideas!

The pull-down resistors can be applied also here giving the possibility to address directly the 0 address (might be used for example in horizontal scrolling games for pixel rows displacement).

Note that with the easy addressing, [0,0] can be used as an additional auxiliary register!

The X incrementer is kept to be able to output to VGA at full speed. Having the two chips also allow the separate load of the nibbles if needed.


**Increasing the RAM**

This is a trivial but important one: 64kbytes of ram by default. Self-explanatory and surely missing on the standard gigatron.


**Increasing the clock frequency**

Gigatron has been already reported being able to run at double speed, and current strip down is even decreasing path lengths so helping to improve overclocking possibilities or stability.

Increasing the clock frequency would minimize the effect of some simplification of the hw side that requires some additional instruction on the sw one.

Note that to keep compliance with VGA pixel frequency of 25.175MHz, higher usable clocks (of the 6.29375MHz /4 one) should: 12.5875MHz or 8.3917MHz, (respectively /2 and /3). And surely whatever multiple of 6.29375MHz or the others can also fit.


**Including a keyboard**

Some design decisions are not fully aligned with the main idea of Gigatron, and one is to use the pretty complex serial chip, but, even more, requiring an entire microcontroller to be able to use a keyboard is surely not in line with the original philosophy.

Removing it and using an old-style matrix keyboard (and no external controller) is much more aligned and use much simpler logic. If required joystick can be attached to an expansion port (and again a much simpler one just based on switches).

With a 32 keys (4x8) matrix keyboard, blinker led lines might be used for keyboard row signals and should not interfere much with led blinking. For the columns a specific buffer chip should be used (de facto replacing the current serial chip).


**Minimizing Program Counter**

Design idea: the most significant byte of the register can be incremented at the end of the page with an unconditional fixed jump to the address 0 of the next page. This will allow the use of a standard flip-flop chip instead of the double 161 incrementer. Benefits: one chip less and shorter carry propagation; downside: one/two ROM words per page used to jump, with average even slightly more for the cases which Temp/Flag register need to be saved and/or restored. Note that this limitation applies just to native instructions and not vCPU ones, and just to code that go multipage (very limited if at all existing even in the current implementation).

A a side note the "rollover" feature on the same page might even be used by purpose on some extreme optimizations.


**Minimizing the Control Unit**

Design idea: CU Signal "unrolling", using two ROMs, and putting into the ROMs the “already decoded” instructions signals (24 bits for signals and 8 for data).

Other than removing some chips, CU decoding logic removal (together with ALU described later) is also shortening delay paths increasing the possibility for higher clock frequency compatibility. Another benefit is having the possibility to specify all the parallel activity that might be needed by the instruction since they are stored separately.


**Expansions BUS**

Expansion BUS, this one adds chips instead of removing, but keeping it simple putting on the bus just a dedicated register and a signal to write and one buffer and a signal to read we would have a 20 pin connector (including Vcc and Ground) for any future use.

These chips are optional and can be soldered just if/when needed.


**VGA colors**

VGA chips are already at the bare minimum, but increment the number of VGA colors still maintaining the single register output might be possible using the Digital Composite Sync feature (horizontal and vertical syncs just using hsync) to have 128 colors (ref. https://www.avrfreaks.net/forum/found-h ... ga-feature, https://hackaday.com/2015/12/17/attiny- ... -8-colors/ https://www.avrfreaks.net/forum/impossi ... er-atiny85). The monitor should support the DCS feature, but seems almost all of the monitors do it!

There is an even more daunting version obtainable mixing the sync with the signal (ref. https://www.avrfreaks.net/forum/impossi ... y85?page=3).

Note that via software also more modes can be made available with more resolution as for example 256x192, focusing resources (50k RAM and a lot of CPU) just on picture displaying.

On the contrary, there might be situations when maximum computational power would be needed and no video is required. This could be coded a new vCPU instruction “FAST" (analogous to ZX81 one), leaving a very powerful computer that for example can compute a chess move!


**Minimizing the Arithmetic Logic Unit**

We already removed the CPU, and inside it the CU, the ALU is the last piece remaining... let's remove also it! ;)

This is the last, but surely the most important. The most chip reduction and disruptive.

The proposal is to use loads and lookup tables instead of ALU dedicated chips for operations, but remain efficient (and having even all conditional signals) with a purposefully designed architecture composed of an "expanded" MAU, two "mixing" registers, one temp/"flag" register and one to combine nibbles results. For the comprehensive details and some code examples please have a look at the overall picture later on.

This way of operating might be a bit slower in doing logical and arithmetic operations, but it can cover in the same efficient way whatever operation you would need, and having more registers (and also flags) can be even faster in some operations. And surely is fully in line with the gigatron philosophy of using software instead of hardware!

Regarding RAM utilization, 8bit lookup tables consume 256bytes of RAM. 10 of them that probably are enough for most operations would consume around 2kbytes, leaving still a lot of space for the rest.

Moreover, from my analysis, the logical and arithmetical operations are just a subset of the total, and far to be the majority.

ALU removal together with CU decoding logic removal is also shortening delay paths and increasing the possibility to increase clock frequency (ALU7 is one of the slowest signal in the standard gigatron).


**Final pictures**

Below you can see a picture trying to show all the components and the interactions among them:
newarchitecture.jpg
newarchitecture.jpg (136.75 KiB) Viewed 2221 times
For example, if you need to do the XOR of two operands and you have loaded them in the S and T the instructions would be:

Code: Select all

1. U, V = S x T # pair the nibbles of the two input operands in U and V
2. Y = XorLutPage # point to the look up containing in the low nibbles the XOR of the low and high nibble of the index
3. T = [Y,U] # calculate the XOR of the low nibbles
4. W = T + [Y,V] # calculate the XOR of the high nibbles and join them with low ones to store the result in W 
Another example to add to vAC one byte:

Code: Select all

1. X = address of vAC
2. T = [0,X] # load vAC into T (supposedly vAC is in page 0)
3. U, V = T x bytetoadd # load U and V with the low and high nibbles to be added
4. Y = AddLutTable # the ADD look up table contains the result of adding the two nibbles of the index
5. T = [Y,U] # add the low nibble ("obviously" the carry will be in bit 5)
6. if not T.HalfCarryFlag jump to step 8 # since pipelining this instruction would need to be phisically put one instruction before when coded
7. Y = AddPlus1LutTable # in case of carry use the ADD lookup table with +1 included
8. W = T . [Y,V] # join the result of the high nibble addition with the one saved in T (low nibbles)
9. [0,X] = W # store result back into vAC
The last example for read next vCPU instruction and jumps to it:

Code: Select all

1. X = address of vPC
2. X = [0,X] # load vPC low in X
3. Y = DoubleIncLut # 2 bytes per vInstruction
4. S = [Y,X] # increment vPC
5. X = address of vPC
6. [0,X] = S ; X++ # save incremented vPC low and set X on vPC high (example of parallel execution)
7. Y = [0,X] # load vPC high
8. X = S # saved vPC low
9. Jump to [Y,X] # to execute vInstruction
For fun I did also a rough mockup on how it can appear a final product of it maintaining the simple 2 layer and IC spacing
mockup.jpg
mockup.jpg (67.59 KiB) Viewed 2221 times

**Ending**

I have experience in microprocessor architectures and I've realized various assembler applications, but as for electronics, this would be my first "not trivial" realization! :) Any feedback, suggestion, or further improvement is more than welcome!

I'm glad to know you managed to read till here; hope you found it interesting!

In the meantime, happy hacking!
_Stefano

Re: microtron

Posted: 23 Jul 2020, 18:53
by walter
Hi Steve,

You have interesting thoughts, and it is nice to see them presented in such a concise way. I'm proud that the Gigatron has inspired you, in the same way designs before the Gigatron inspired us.

I like how you have taken the design goals of the Gigatron and applied them, again, to the Gigatron. The system was designed as a simple computer to drive a LED matrix to play tic-tac-toe. The first kits had no BASIC, no keyboard controller. Since we did not want to change the main system (and because we did not consider it a part of the main CPU), we bolted on an ATTiny. As you rightly say, that does not match with the original design goals, but it would have taken a redesign of the whole CPU part to do so. We never came around to it, but now you are proposing such a system.

It is like with writing good software: you have a design specification, you write the code and while writing, you start to understand the design goals better (or adapt them) and in the end, it is best to completely write the code again from scratch, with the knowledge that has been gained writing the first iteration in mind. (Unfortunately, not much software gets this treatment.) If we would have known beforehand some of the things that only became apparent at the end, the design would have been different.

Changing the multiplexers seems to make sense. Same for doubling RAM and increasing clock speed. Some more care should be taken with the PCB layout I think, possibly going to a 4-layer board. I have one board that I am populating with old chips, and I have to include a resistor after the clock booster as the signal otherwise starts ringing and it won't work.

For the inclusion of a keyboard I'm not sure what the best way to go forward is. On first thought, it makes sense to incorporate it in the PCB. But I think it would then become a bit bulky, and it will be hard to make it a good usable keyboard. Maybe use an existing matrix keyboard instead?
A simple controller with buttons would be much simpler than what is used in the kit, but this was the only readily available and affordable controller. I think the keyboard and controller solution also depend on wether or not you want to make this into a kit at some point.

The program counter minimisation is interesting. A nice unconventional idea. The downside is that the working of the systems becomes a bit more obscured/too different from existing designs. But it does minimise chip count. Putting the CU in ROM is the same story. The current CU with the diodes neatly placed on the board make it great for explaining how CPU's work. But your proposal matches better the minimalistic hardware goal. For the ALU, I guess the current way it works is already difficult to grasp for some, so the proposed change would not make it more obscure.

A somewhat slower ALU could be compensated for by a higher clock speed so yes, that change would also reduce chip count.

The VGA sync trick is new to me.. we should have known earlier :) Although we probably would have voted against it as it is an undocumented feature and might not work everywhere. Good enough for enthousiasts, not good enough to make into a kit.

So overall this is great food for thought. I think a Gigatron with these changes would appeal to different people, it would be more 'hard-core', for people who understand well how the hardware works at low-level, less as an educational tool. But I like that it would still be with separate DIP components (and not just an FPGA - that is interesting as well but for yet other reasons). And to take hardware minimalism one step further.

Re: microtron

Posted: 23 Jul 2020, 21:10
by Lerc
It's interesting to compare with modifications I was imagining, While I pretty much want to add a bunch of chips, the minimization effort of the Gigatron has built a base where you can branch out from. A even more minimal approach could potentially give a lower base to work from. I only have this base to work from because of the extreme optimizations

My own thoughts on the multiplexers were to add a Z register to effectively be able to move zero page around. Going either way seems reasonable. A movable zero page might allow an entire class of code tricks but isn't a fundamental part of making the machine work.

The lower byte of addressing worries me more. It's not so much the cost of an extra instruction to load X, but losing the existing contents of X. I would have to think about it a bit to imagine what the flow on implications of having to reload X.

If you were to do changes where you saved a 74HC137 I'd move it to the Display out. provided you could find alternate lines to do the hsync/vsync (I think they could be found) then you could potentially do two pixels with one write. higher res with 16 colours. (see the hires thread for my thoughts on colours)

Re: microtron

Posted: 24 Jul 2020, 16:40
by steve
walter wrote:
23 Jul 2020, 18:53
You have interesting thoughts, and it is nice to see them presented in such a concise way. I'm proud that the Gigatron has inspired you, in the same way designs before the Gigatron inspired us.

I like how you have taken the design goals of the Gigatron and applied them, again, to the Gigatron. The system was designed as a simple computer to drive a LED matrix to play tic-tac-toe. The first kits had no BASIC, no keyboard controller. Since we did not want to change the main system (and because we did not consider it a part of the main CPU), we bolted on an ATTiny. As you rightly say, that does not match with the original design goals, but it would have taken a redesign of the whole CPU part to do so. We never came around to it, but now you are proposing such a system.

...

So overall this is great food for thought. I think a Gigatron with these changes would appeal to different people, it would be more 'hard-core', for people who understand well how the hardware works at low-level, less as an educational tool. But I like that it would still be with separate DIP components (and not just an FPGA - that is interesting as well but for yet other reasons). And to take hardware minimalism one step further.
Thank you Walter, it's an honor to receive your positive opinion!

And you're completely right that "standing on the shoulders of giants" is much easier to reach further, and I'm standing on two more ones! 8-)

Regarding the comments on the various points:
walter wrote:
23 Jul 2020, 18:53
Changing the multiplexers seems to make sense
1) Good!
walter wrote:
23 Jul 2020, 18:53
Same for doubling RAM and increasing clock speed
2) These were trivial :D
walter wrote:
23 Jul 2020, 18:53
Some more care should be taken with the PCB layout I think, possibly going to a 4-layer board. I have one board that I am populating with old chips, and I have to include a resistor after the clock booster as the signal otherwise starts ringing and it won't work
3) Transparently I have no expertise in PCB creation and ... I've ordered my first PCB this year from ready gerber files and I was even scared to solder it since my soldering skills were really basic. But all went good and now I've soldered already three projects, but for the rest I'm still pretty noob and I've just opened KiKad.
This just to say that surely this is an area where I would need a lot of help!
walter wrote:
23 Jul 2020, 18:53
For the inclusion of a keyboard I'm not sure what the best way to go forward is. On first thought, it makes sense to incorporate it in the PCB. But I think it would then become a bit bulky, and it will be hard to make it a good usable keyboard. Maybe use an existing matrix keyboard instead? A simple controller with buttons would be much simpler than what is used in the kit, but this was the only readily available and affordable controller. I think the keyboard and controller solution also depend on wether or not you want to make this into a kit at some point.
4) On the keyboard side I've instead a "pretty big" experience (all three soldering projects were about custom keyboards). It should be fine to have it attached and printed on the same PCB since the total computer size should be just slightly bigger than a ZX80, but anyway interesting the idea to detach it: the PCB might be done in a way that if you want you can cut it and attach a 12 wires extension cable!
On the joystick side it's even easier since the arcade one to use with MAME I've built even without soldering! It can then easily attached to the expansion bus connector.
walter wrote:
23 Jul 2020, 18:53
The program counter minimisation is interesting. A nice unconventional idea. The downside is that the working of the systems becomes a bit more obscured/too different from existing designs. But it does minimise chip count.
5) The good part is that is just related to native instructions and all the ROM I've analyzed was just using "intra page" code (so no impact even on current gigatron). On the bad part is that anyway on microtron the native instructions will be different and, even if we'll surely miss the genius of Marcel in this area, new ways of operation should be found out taking advantage of the new architecture specifics
walter wrote:
23 Jul 2020, 18:53
Putting the CU in ROM is the same story. The current CU with the diodes neatly placed on the board make it great for explaining how CPU's work. But your proposal matches better the minimalistic hardware goal.
6) The deconding part would miss, but all the signals to be explained will remain!
And other than pure component count, I think that this together with ALU is a key on clock improving
walter wrote:
23 Jul 2020, 18:53
For the ALU, I guess the current way it works is already difficult to grasp for some, so the proposed change would not make it more obscure. A somewhat slower ALU could be compensated for by a higher clock speed so yes, that change would also reduce chip count
7) The key part to be understood is the registry architecture designed to be efficient managing LUTs (T, U, V, W)
walter wrote:
23 Jul 2020, 18:53
The VGA sync trick is new to me.. we should have known earlier Although we probably would have voted against it as it is an undocumented feature and might not work everywhere. Good enough for enthousiasts, not good enough to make into a kit
8) Not sure DCS is undocumented. Seems wikipedia list it as one of the possible modes of component video (https://en.wikipedia.org/wiki/Component_video_sync), the real point is how many monitors do not support it, and for this I've no answer unfortunately.

The other solution to combine sync with signal might even be done (wire)"ORing" the color signals to obtain the sync: leaving 255 (in case of composite) or 15x15=225 colors in case of "ORing" the two nibble separately to keep the two syncs separate. The "only" problem with this 8bit solution (if not solved) is that we lose black.

Lerc wrote:
23 Jul 2020, 21:10
It's interesting to compare with modifications I was imagining, While I pretty much want to add a bunch of chips, the minimization effort of the Gigatron has built a base where you can branch out from. A even more minimal approach could potentially give a lower base to work from. I only have this base to work from because of the extreme optimizations

My own thoughts on the multiplexers were to add a Z register to effectively be able to move zero page around. Going either way seems reasonable. A movable zero page might allow an entire class of code tricks but isn't a fundamental part of making the machine work.

The lower byte of addressing worries me more. It's not so much the cost of an extra instruction to load X, but losing the existing contents of X. I would have to think about it a bit to imagine what the flow on implications of having to reload X.
Lerc, first of all thank you too for your comments!

Regarding memory access, with this architecture no multiplexer is required. Getting "Z page" is as simple as adding another 374 register to the Y "mau bus" side of memory addressing. Also to keep the direct memory access would be enough to add a buffer from bus on X side of the "mau bus". No mux/demux or other logic needed.

Regarding Z I'm pretty sure sw would not be very impacted, and agree with you that direct memory access might be more needed. But I also think it would be a good idea trying to see if the ROM can do without it, and simply add just in case. And even in case of PCB realization can be left a hole for the chip to be soldered just in case.

Lerc wrote:
23 Jul 2020, 21:10
If you were to do changes where you saved a 74HC137 I'd move it to the Display out. provided you could find alternate lines to do the hsync/vsync (I think they could be found) then you could potentially do two pixels with one write. higher res with 16 colours. (see the hires thread for my thoughts on colours)
Very interesting idea doubling resolution with the help of the clock phases!
In order to save memory and having proper throughput the best would be anyway to fit the two nibbles in one byte. If possible to mix the two above proposed ideas of combined H+V and combined signal with color (as mentioned in "point 8" just above in this reply) 15 colors will be possible. Just I'm not sure how will be possible to switch from lowres to highres just via software without adding more chips.
As an interesting note, this architecture is designed to manage in various ways nibbles! :)

Re: microtron

Posted: 26 Jul 2020, 01:12
by steve
@Lerc: I've to correct the consideration for the direct memory indexing: other than the buffer on the X side of the "mau bus", it is required also to add back the one from D register to the bus, in order to leave free the bus to get the data to write or read. So 2 chips more (as the original), anyway leaving the "bus" concept on the memory addressing in order to be able to use also U and V. But this is just reinforcing the idea to use the architecture as it is depicted now in the schema.

I did also a little correction on the third code example (X was not loaded before increment), and added a step more on the first one trying to show also the path to the U and V registers.

Load and save programs

Posted: 26 Jul 2020, 13:50
by steve
Also to load and save programs I think that the "old school" way of using audio might be the more adequate to keep the retro original philosophy.

The microtron can be interfaced with a real cassette recorder, but any audio source/recorder would then be usable (e.g. mobile phones mic/headphone jack) as a substitute.

We have already the "audio out". For the "audio in" at the beginning I was thinking to use a dedicated signal, but counting all the ones needed 24 are a lot but better to save if possible.

I'm thinking that the sign bit of the keyboard columns input might be the best, leaving 7 bit for the keyboard reading. This then is requiring more rows than the 4 provided by the blinkenlights, and for this reason I'm also thinking to take the row signals from the color bits of the VGA output (anyway the readings will be during the non-visible part).

In this way we have 6 row signals (or 7 in case of combined syncs). Leaving 5 of them to the keyboard, the sixth one can be used for the joystick interface (with the possibility of 4 contacts for the 2 axis and also 3 buttons), leaving completely free the expansion port for any other use.

What is missing for the "audio in" is then to design the input circuitry. Looking around I've found this circuit:
Image
(cfr ZX81plus34 at https://revspace.nl/ZX81PLUS34_ZX81_clo ... _interface)

Seems working but, since we do not need to be compatible to the ZX81, if anyone has a better circuit or modulation techniques to use for sure would be good to improve! :)

Re: microtron

Posted: 26 Jul 2020, 20:10
by Lerc
OK I've been staring at the diagram and thinking a lot and I understand it a lot more. That makes me think that I need to think a lot more.

Using 32 bit instructions with directly embedded control lines throws the possibilities of instructions completely up in the air. Not only is much more possible but it becomes a bit harder to think about what is an instruction. In some ways it completes the path of the vCPU back to being a standard microcoded CPU.

Are all of the 24 control lines currently accounted for? I'd imaging that running 3 of them out to a 3->8 decoder would be useful downstream considering how many instruction decoders need to do that anyway.

The RAM based ALU gives me mixed feelings. From the perspective of making a computer that they might have had in the late 70's, they would think you insane for using expensive ram to do math by LUT. On the other hand, once again. so much potential for interesting hacking.


Having said that I'd also look at the possibility of ORing the result of the LUT as two 8 bit values (look at me adding chips again) when they go into W. Then you could have effects propagate further than a single bit in the half carry. I bet a clever person could work magic with that.

Re: microtron

Posted: 27 Jul 2020, 17:30
by steve
Lerc wrote:
26 Jul 2020, 20:10
OK I've been staring at the diagram and thinking a lot and I understand it a lot more. That makes me think that I need to think a lot more.
Feel free to ask any clarification!

Lerc wrote:
26 Jul 2020, 20:10
Using 32 bit instructions with directly embedded control lines throws the possibilities of instructions completely up in the air. Not only is much more possible but it becomes a bit harder to think about what is an instruction. In some ways it completes the path of the vCPU back to being a standard microcoded CPU.
Are all of the 24 control lines currently accounted for? I'd imaging that running 3 of them out to a 3->8 decoder would be useful downstream considering how many instruction decoders need to do that anyway.
Yes, for now I've put all of them in use, and in fact I even miss one in case of utilization of the optional expansion BUS, and some more reasoning/optimization should be done for this.

Below I tryed to list all the signal and categorizing them.

What to put on data BUS (just one of them can be active each time):
- D enable
- S enable
- RAM read
- W enable
- Aux (KeybCols/Audio) read
- Expansion read (optional)

What to load from data BUS (any of them can be active, meaning parallel loads can occur):
- RAM write
- S load
- T load
- X load
- Y load
- U/V load (mixing BUS nibbles with T nibbles)
- W load (low nibble BUS will go into high nibble W and T low nibble value in low nibble W)
- Audio/Leds write
- VGA write
- PC Low address in case of unconditional long jump (PC high will be loaded from T with the same signal)
- PC Low address in case of T half carry bit conditional Jump
- PC Low address in case of T equal zero conditional Jump
- PC Low address in case of T sign bit conditional Jump
- Expansion write (optional)
Note that the all the PC Low signals should be (wire)"ORed" (or ANDed in this case since negative active).

What to put on MAU low address (maximum one of them can be specified, 0 or $FF default if none specified):
- U enable
- V enable
- X enable

What to put on MAU high address (maximum one of them can be specified, 0 or $FF default if none specified):
- Y enable

Other signals:
- X increment

Many of them could be combined, but I'm trying to avoid it since if put decoders before the IR registers they would even require one more of them. So the optimal solution would be to put them after the IR registers (they might even allow to save one IR chip, I think saving two would be difficult but if possible we can even have back the single ROM design), but in this case they will introduce also delays (as in the current gigatron implementation anyway).

As a side note: when I was writing the instructions in the examples I've used the ";" to separate on the same line the parallel executed ones, and I've used the "simple" equal sign for load that I think is more clear than the LD or MOV usual assembly used instruction (eg when switching architectures I've always to think back if is the left or the right being assigned, and sometime is even not written clearly since is implicit).

Lerc wrote:
26 Jul 2020, 20:10
The RAM based ALU gives me mixed feelings. From the perspective of making a computer that they might have had in the late 70's, they would think you insane for using expensive ram to do math by LUT. On the other hand, once again. so much potential for interesting hacking.
In 1K we have 4 LUT tables, and probably 2K can be used to perform all operations. With 4k we can probably have more efficiency. I think is not so much out of the 64K, and in reality the real big chunk of available RAM is "eaten" by the video image (that is unfortunately also fragmenting the memory available).

Personally anyway I think that, without CPU, people at the time they would very probably have chosen the 74181 way! ;) (and I think that it would have been also much simpler in terms of number of transistor/gates count if you consider all the 10 chips of the current ALU, and probably even just the 4 that I use for nibble management)

Lerc wrote:
26 Jul 2020, 20:10
Having said that I'd also look at the possibility of ORing the result of the LUT as two 8 bit values (look at me adding chips again) when they go into W. Then you could have effects propagate further than a single bit in the half carry. I bet a clever person could work magic with that.
I'm not sure I got this point (what exactly to OR and for what reason), but let me say that I would probably prefer suggestions to remove chips than to add if possible! :D

Re: microtron

Posted: 27 Jul 2020, 19:58
by walter
steve wrote:
27 Jul 2020, 17:30
Lerc wrote:
26 Jul 2020, 20:10
The RAM based ALU gives me mixed feelings. From the perspective of making a computer that they might have had in the late 70's, they would think you insane for using expensive ram to do math by LUT. On the other hand, once again. so much potential for interesting hacking.
In 1K we have 4 LUT tables, and probably 2K can be used to perform all operations. With 4k we can probably have more efficiency. I think is not so much out of the 64K, and in reality the real big chunk of available RAM is "eaten" by the video image (that is unfortunately also fragmenting the memory available).
Even though the RAM requirements are not that big, it would not have crossed the minds of people in the late 70s to do it that way I think. And 64k was out of the question. The 32kB SRAM was available in the 80s in the speed that is required, but was *very* expensive of course. In a real system from that time, it would not have been used.

So the question is what you want to achieve, do you want to stay true to 1970s technology, or do you want to make it the most minimalistic usable system that uses components that existed, conceptually, in that period?

We wanted something that could have existed, at least in the 1980s, for as far as the CPU is concerned. The rest can be of newer technology if that makes the Gigatron more useful. Hence Pluggy McPlugface and the first steps to build an SDcard interface (and not a cassette interface). I think a cassette interface is a fun project (let's port BASICODE!) but it will not be very practical for everyday use. It's nice to be able to say it works, but after using it once you'd probably want SDcards. It's a bit like toggling in code on a PiDP-8. :-)

Re: microtron

Posted: 27 Jul 2020, 20:40
by steve
walter wrote:
27 Jul 2020, 19:58
Even though the RAM requirements are not that big, it would not have crossed the minds of people in the late 70s to do it that way I think. And 64k was out of the question. The 32kB SRAM was available in the 80s in the speed that is required, but was *very* expensive of course. In a real system from that time, it would not have been used.
So the question is what you want to achieve, do you want to stay true to 1970s technology, or do you want to make it the most minimalistic usable system that uses components that existed, conceptually, in that period?
I was trying to push even further the gigatron philosophy!

As for limits I always thought gigatron as a "concurrent" of the first home computers (e.g. Commodore), not really a '70 machine (as for this probably also the original ROM would not be really adequate).

walter wrote:
27 Jul 2020, 19:58
We wanted something that could have existed, at least in the 1980s, for as far as the CPU is concerned. The rest can be of newer technology if that makes the Gigatron more useful. Hence Pluggy McPlugface and the first steps to build an SDcard interface (and not a cassette interface). I think a cassette interface is a fun project (let's port BASICODE!) but it will not be very practical for everyday use. It's nice to be able to say it works, but after using it once you'd probably want SDcards. It's a bit like toggling in code on a PiDP-8. :-)
For me the point on peripheral was just on the keyboard. And cassette was to give a proper retro interface that I remember from my youth and I still experience with my old PCs.

Coming back on the ALU, challenging the Dieter Mueller design proven to be the most difficult part, and the LUT was the way I found, and then I optimized it with the TUVW registers. Since the number of chips involved I hope we can find and use an alternative solution, even if not the one proposed.