Now that I successfully built my Gigatron TTL computer, I would love to get started with learning how to program it.
Also, I want to get a deep understanding how things work in the first place - which is actually the reason why I built the Gigatron.
So... given that there are opcodes such as mov, add, etc. and that it is possible to address memory and move values back and forth... how exactly does this work at all? In what way does assembly code get compiled and how does it find its way into the computer? When the computer is booted, how is this code being executed and while it is being executed, what exactly happens so that things... happen...?
So theres shift registers, memory, logic units, etc. pp.... but how does everything come together so that the computer does what I program it to do?
What I would love to work with, is some sort of course that explains everything from start to finish in a series of videos for instance... or blog articles maybe.
However. Looking through available resources, I don't quite find a starting point.
Maybe I am looking into the wrong direction?
Having a hard time to get started
Forum rules
Be nice. No drama.
Be nice. No drama.
Re: Having a hard time to get started
Hey! I will try to answer some of the questions.
The assembly part is done on a PC and is burned into a ROM.
The ROM in this case, while it is used for storage for a few user applications, is not what is exposed to the user. The machine is a Harvard-based machine as opposed to the more common Von Neumann style. So the core software/firmware in ROM has its own bus from RAM. On a Von Neumann system, fetching program opcodes and reading or writing data under the direction of the program take turns. So having 2 buses makes things faster and allows the Gigatron to run native instructions in a single cycle at 6.25 MHz.
The 6.25 MHz part and the single cycle thing are needed because the VGA pixel clock is around 25.1 MHz. So clocking around 1/4 the pixel clock results in pixels that are 4 times as wide. As long as the sync pulses are close enough to the specs, the monitor doesn't care what the pixel clock used really is.
Anyway, while using the Harvard architecture improves performance, it also introduces a handicap. When users load programs, they are loading them into RAM. A Harvard machine cannot run programs that are in RAM. So, to do that, you have to use software in the core ROM to create an instruction set and an interpreter/emulator to run it. That is where vCPU and .GT1 files come in. The vCPU interpreter lets you run programs out of RAM. It has its own opcodes. For efficiency, it uses a jumplist system. So instead of many polling instructions which is impractical, and we don't have the time to do it that way, the vCPU code uses jumplists. So there are not many equality checks in the code (compare to If...Then...Goto in BASIC). Instead, the opcodes are the addresses of their handlers. So the underlying native code jumps to the code to make the instruction.
What happens in the ROM to make the computer come together is a lot of bit-banging and multitasking. About 80% of the time, the CPU (most of the Gigatron) is drawing to the screen. It uses a specialized native instruction for that. That instruction reads the framebuffer (as determined by the indirection table) which is in RAM, ORs it (with 192 in this case which is 11000000b to ignore those bits in memory and set the sync bits high), sends the result to the Out port, and increments the X register. That instruction does 4 different things. Since it advances the X register, no separate instructions are needed, and every instruction during the active display time writes to the screen. Then during the 40 cycles after the active scanline, it handles the sound/lights, runs vCPU, and sets up for the next scanline. Alternating scanlines handle different sound channels. There are really 480 lines, but since we only have 160 pixels across, 4 native scanlines make the virtual scanlines we work with. So in the screen modes that skip lines, only a single video drawing opcode is used, saving the rest of the time to run vCPU. Then things get to the 200 cycles at the bottom of the screen which is the vertical porch time, there, the ROM does things like read the keyboard, look in memory for a random number, and run vCPU.
***
On the hardware side of things, here is roughly how things work. When you turn on the machine, the power supervisor (looks like a transistor as it is black and has 3 wires) holds the program counter in reset until the power is sufficient. So the program counter starts at address 0. The program counter addresses the ROM and reads that into to 2 octal D flip-flips that are used as registers. One is the instruction register, and the other is the "data" (or immediate) register. The instruction register (IR) is what fetches the instructions from the ROM. The data register is not always used, but it is for the immediate argument of IR if one is needed. IR and DR being separate is another reason why the Gigatron can run 1 instruction per clock cycle. That would normally take 2 cycles in older CPUs; one to read the main part of the instruction and the next to read the argument needed by the instruction.
Now, these 2 registers (IR/DR) also split the operations into 2 stages. The ROM is kinda "slow" (though actually fast for the era we're trying to go for) at 70 ns, and there would not be enough time to reach 6.25 MHz unless we split things into a pipeline like this. Registers accept new data while giving off the data from the last clock cycle. So the next instruction is going into the IR/DR registers, but the current one is coming out. That also creates an interesting side-effect where jumps are delayed by a cycle and the talk about trampolines where you can use this delay to trick the machine into giving you what is stored in the ROM as data. So the ROM goes to the IR/DR registers and the outputs of those registers that came from the previous cycle go to the rest of the machine.
Then the instruction coming from the IR register is broken into 3 parts. You have what input goes in (2-bits), what comes out and the "mode" (3-bits), and what ALU operation (3-bits). To break out the groups of bits into their functionality, line decoder chips are used. Those convert binary lines into separate unary lines. So 2-bits represent 4 choices and 3-bit represent 8 choices. What some of the decoders do is connect to diodes used as ROMs.
Diode ROMs work a bit like this.
https://www.eeeguide.com/rom-memory/
In the picture on that site, each diode represents a 0 and the resistors tie things high. The selection of the decoder and what line drops in voltage is what selects which row of logic. This is roughly how the old ROMs worked internally, though they used transistors in place of diodes. Actually, for "mask ROMs" which are ROMs that are made with their intended data already in them, the transistors are incomplete and the final layer called a mask completed the transistors where 0's needed to be. So the chips were all made the same except for the last stage.
I don't quite understand the jump detection thing, but jumps are a matter of overwriting the program counter. Due to the pipelining I mentioned, jumps are a cycle late, producing what is known as a delay slot. So when writing the native ROM, you have to realize that the instruction after a branch will run during the jump. So you have to structure any native code to take that into account.
Eventually, we get to the ALU. There are diodes to select what it does. The 8 multiplexers in that area are used for doing the logic, while the 2 adder chips do the math. I don't quite get how the Gigatron in specific does subtraction, but here is how subtraction works. You invert the B argument that goes into the adder. By inverting, you flip all the bits. You'd be off by 1 in the result, so you set the Carry-In line on the lowest adder chip. In other words, A-B = A + (!B + 1). That provokes a carry and what is left is the difference.
Sound and video go through passive DACs which are resistors and resistor packs in our case. They convert the digital outputs into more analog ranges so that the sound and video work.
I hope this is understandable and helps. I also hope that others can point you to the resources you need for coding. Most of it has been said here in the forum, but it is all scattered. Some places to look would be the schematics and the ROM listing. Marcel did write a few specification pages. Most of the rest is scattered all over the place.
The assembly part is done on a PC and is burned into a ROM.
The ROM in this case, while it is used for storage for a few user applications, is not what is exposed to the user. The machine is a Harvard-based machine as opposed to the more common Von Neumann style. So the core software/firmware in ROM has its own bus from RAM. On a Von Neumann system, fetching program opcodes and reading or writing data under the direction of the program take turns. So having 2 buses makes things faster and allows the Gigatron to run native instructions in a single cycle at 6.25 MHz.
The 6.25 MHz part and the single cycle thing are needed because the VGA pixel clock is around 25.1 MHz. So clocking around 1/4 the pixel clock results in pixels that are 4 times as wide. As long as the sync pulses are close enough to the specs, the monitor doesn't care what the pixel clock used really is.
Anyway, while using the Harvard architecture improves performance, it also introduces a handicap. When users load programs, they are loading them into RAM. A Harvard machine cannot run programs that are in RAM. So, to do that, you have to use software in the core ROM to create an instruction set and an interpreter/emulator to run it. That is where vCPU and .GT1 files come in. The vCPU interpreter lets you run programs out of RAM. It has its own opcodes. For efficiency, it uses a jumplist system. So instead of many polling instructions which is impractical, and we don't have the time to do it that way, the vCPU code uses jumplists. So there are not many equality checks in the code (compare to If...Then...Goto in BASIC). Instead, the opcodes are the addresses of their handlers. So the underlying native code jumps to the code to make the instruction.
What happens in the ROM to make the computer come together is a lot of bit-banging and multitasking. About 80% of the time, the CPU (most of the Gigatron) is drawing to the screen. It uses a specialized native instruction for that. That instruction reads the framebuffer (as determined by the indirection table) which is in RAM, ORs it (with 192 in this case which is 11000000b to ignore those bits in memory and set the sync bits high), sends the result to the Out port, and increments the X register. That instruction does 4 different things. Since it advances the X register, no separate instructions are needed, and every instruction during the active display time writes to the screen. Then during the 40 cycles after the active scanline, it handles the sound/lights, runs vCPU, and sets up for the next scanline. Alternating scanlines handle different sound channels. There are really 480 lines, but since we only have 160 pixels across, 4 native scanlines make the virtual scanlines we work with. So in the screen modes that skip lines, only a single video drawing opcode is used, saving the rest of the time to run vCPU. Then things get to the 200 cycles at the bottom of the screen which is the vertical porch time, there, the ROM does things like read the keyboard, look in memory for a random number, and run vCPU.
***
On the hardware side of things, here is roughly how things work. When you turn on the machine, the power supervisor (looks like a transistor as it is black and has 3 wires) holds the program counter in reset until the power is sufficient. So the program counter starts at address 0. The program counter addresses the ROM and reads that into to 2 octal D flip-flips that are used as registers. One is the instruction register, and the other is the "data" (or immediate) register. The instruction register (IR) is what fetches the instructions from the ROM. The data register is not always used, but it is for the immediate argument of IR if one is needed. IR and DR being separate is another reason why the Gigatron can run 1 instruction per clock cycle. That would normally take 2 cycles in older CPUs; one to read the main part of the instruction and the next to read the argument needed by the instruction.
Now, these 2 registers (IR/DR) also split the operations into 2 stages. The ROM is kinda "slow" (though actually fast for the era we're trying to go for) at 70 ns, and there would not be enough time to reach 6.25 MHz unless we split things into a pipeline like this. Registers accept new data while giving off the data from the last clock cycle. So the next instruction is going into the IR/DR registers, but the current one is coming out. That also creates an interesting side-effect where jumps are delayed by a cycle and the talk about trampolines where you can use this delay to trick the machine into giving you what is stored in the ROM as data. So the ROM goes to the IR/DR registers and the outputs of those registers that came from the previous cycle go to the rest of the machine.
Then the instruction coming from the IR register is broken into 3 parts. You have what input goes in (2-bits), what comes out and the "mode" (3-bits), and what ALU operation (3-bits). To break out the groups of bits into their functionality, line decoder chips are used. Those convert binary lines into separate unary lines. So 2-bits represent 4 choices and 3-bit represent 8 choices. What some of the decoders do is connect to diodes used as ROMs.
Diode ROMs work a bit like this.
https://www.eeeguide.com/rom-memory/
In the picture on that site, each diode represents a 0 and the resistors tie things high. The selection of the decoder and what line drops in voltage is what selects which row of logic. This is roughly how the old ROMs worked internally, though they used transistors in place of diodes. Actually, for "mask ROMs" which are ROMs that are made with their intended data already in them, the transistors are incomplete and the final layer called a mask completed the transistors where 0's needed to be. So the chips were all made the same except for the last stage.
I don't quite understand the jump detection thing, but jumps are a matter of overwriting the program counter. Due to the pipelining I mentioned, jumps are a cycle late, producing what is known as a delay slot. So when writing the native ROM, you have to realize that the instruction after a branch will run during the jump. So you have to structure any native code to take that into account.
Eventually, we get to the ALU. There are diodes to select what it does. The 8 multiplexers in that area are used for doing the logic, while the 2 adder chips do the math. I don't quite get how the Gigatron in specific does subtraction, but here is how subtraction works. You invert the B argument that goes into the adder. By inverting, you flip all the bits. You'd be off by 1 in the result, so you set the Carry-In line on the lowest adder chip. In other words, A-B = A + (!B + 1). That provokes a carry and what is left is the difference.
Sound and video go through passive DACs which are resistors and resistor packs in our case. They convert the digital outputs into more analog ranges so that the sound and video work.
I hope this is understandable and helps. I also hope that others can point you to the resources you need for coding. Most of it has been said here in the forum, but it is all scattered. Some places to look would be the schematics and the ROM listing. Marcel did write a few specification pages. Most of the rest is scattered all over the place.
Last edited by Sugarplum on 29 Jun 2023, 08:48, edited 1 time in total.
Re: Having a hard time to get started
Hi.
I am also new to Gigatron (not to Retro Computing
).
After 2-3 days googling around, I compiled the attached first overview for me. Maybe it helps others as well to get a first overview.
(Some german language inside )
So for programming, gtbasic seems to be the way to go for me.
And gtbasic within the excellent gtemuAT67 emulator (and gtbasic compiler and more..).
I am working under Mac OS Ventura.
Besides gtbasic see the attached document with what else is out there (gasm, glcc, ..).
On the hardware side, my next upgrades planned are:
Ram double with 628128 ram chip (see here in the forum).
Pluggy Reloaded (because it combines Pluggy original + Arduino + PS/2 + SD Card).
Best regards,
Peter
I am also new to Gigatron (not to Retro Computing
).After 2-3 days googling around, I compiled the attached first overview for me. Maybe it helps others as well to get a first overview.
(Some german language inside
)So for programming, gtbasic seems to be the way to go for me.
And gtbasic within the excellent gtemuAT67 emulator (and gtbasic compiler and more..).
I am working under Mac OS Ventura.
Besides gtbasic see the attached document with what else is out there (gasm, glcc, ..).
On the hardware side, my next upgrades planned are:
Ram double with 628128 ram chip (see here in the forum).
Pluggy Reloaded (because it combines Pluggy original + Arduino + PS/2 + SD Card).
Best regards,
Peter
- Attachments
-
- Programming Gigatron.txt
- (4.05 KiB) Downloaded 60 times