Page 1 of 1

On the shoulders of Giants

Posted: 24 Sep 2019, 15:42
by monsonite
Hi All,

Many of us will now have had our Gigatron for a year or more, and will have witnessed the wonderful progress that the project has made since it's inception in March 2017. Who would have thought that we would be able to emulate the 6502, or access an SD-Card.

Inspired by Marcel's Gigatron design, I pursued the desire to increase the clock frequency, and with some help from Marcel, we now have machines that run twice as fast.

One of the things I'd like to do is to extend the Gigatron architecture to that of 16-bits. This would mean that the vCPU would be a real 16-bit cpu implemented in hardware, and that operations that currently take 28 clock cycles - would complete in a single cycle.

My aim is to develop a TTL coprocessor which plugs into the SRAM socket - picks up the address and data buses and provides a many-fold boost to performance, in a similar way to the BBC Micro tube interface and its various coprocessors.

This is a project in its infancy, but if anyone would like to contribute with ideas and discussion - please contribute to this thread.

Re: On the shoulders of Giants

Posted: 24 Sep 2019, 21:36
by marcelk
monsonite wrote: My aim is to develop a TTL coprocessor which plugs into the SRAM socket - picks up the address and data buses and provides a many-fold boost to performance, in a similar way to the BBC Micro tube interface and its various coprocessors.
You already told me about your plans in Cambridge. I'm glad you're giving it a go! It sounds like an ambitious project and it will be extremely interesting to follow! Writing about it always helps push the design in the right direction (even if from time to time the audience can seem absent). The logging feature of HaD helped me a lot when shaping what later became the Gigatron. Good luck!

Re: On the shoulders of Giants

Posted: 25 Sep 2019, 07:12
by walter
It's really great to see that the system we designed is inspiring others! Indeed: best of luck!

Re: On the shoulders of Giants

Posted: 18 Oct 2019, 21:50
by monsonite
Hi Marcel,

As you know, I took your advice, and decided this week to start a project and begin writing a series of logs - which not only document the project, but help focus the mind - as you have to describe the various aspects of the project in a way that are clear to the Reader.

I decided that the best way to describe the architecture is like a PDP-8 that has had all its buses stretched from 12-bits to 16-bits and had a whole bunch of 16-bit registers added.

I now have 4 bits for the opcode rather than 3 - this means I can devote 8 opcodes to Load, Store and other Memory/Register operations, and have 8 opcodes for the Register/ALU operations - so I can add INC, DEC and INV to the usual ADD, SUB, AND, OR, XOR.

The advantage of a 16-bit Instruction word, means that the lower 8-bits can be used for data, or for holding a zeropage address.

I have written a basic simulator - that runs on an Arduino and simulates my cpu in under 100 lines of code.

This afternoon I have also hacked together a tool that allows me to write assembly language in a very concise syntax and have the program generate the object code for me. This also runs on an Arduino in less than 200 lines of code. I won't call it an Assembler, it is merely a tool that aids Assembly.

This weekend I hope to experiment with the Instruction Set on the simulator, fix any bugs or fatal misunderstandings and write a few test routines.

My Hackaday project and project logs can be found here

Re: On the shoulders of Giants

Posted: 20 Oct 2019, 20:50
by PurpleGirl
I notice that you sort of planned to address 24-bits of memory by combining the payload with a register, I also read that your jumps and calls are 16-bits. I got to thinking that you could use the payload byte along with the next 2 bytes and do 24-bit jumps and calls. But then I read that you might use the payload as page selectors. That reminds me of the segmented architecture of x86 real mode, or even PAE on modern machines. In addition to the 32 address lines of Pentium class CPUs, there are 4 selector lines. I asked around about why they were not part of the address lines, and I was told that there's be no way to program for that since there are no 36-bit registers. Now with x64, that is no problem. On the Suite-16, if you planned on addressing up to 24-bits of memory, then it would make sense to do 24-bit calls and jumps (or at least do a paging or segmenting scheme). Otherwise, they can only be done in the first 64k of addresses (128k total RAM if using 16-bit RAM). So having a total of 32 megs would be a lot of memory.

Also, what if you need a NOP? Will you include one, or does the assembler have to do a branch always (set to the next instruction) or maybe a useless compare op to make up for a lack of NOP? However, it will likely be needed less with your architecture, since everything is 16-bits (32-bits for calls and jumps) and does not need to worry about alignment. On a 286, the assembler would throw in some NOPs to keep jump addresses and memory tables on a 16-bit boundary to help the CPU operate more efficiently and not introduce a bottleneck. But since this will be a true 16-bit machine and not have to run the same code as 8-16 hybrids (eg., 8088), and since instructions are all multiples of 16 in length, alignment shouldn't be an issue. The x86 real mode instruction set uses variable-length opcodes and can get out of alignment.

I also got to thinking about how this could be combined with other architectures. When used as part of a Gigatron, I could see how this could improve bit-banging the video. You could then either double the line length or use 16,384 colors at the existing resolution. The display bits could be done as RRRRRGGGGBBBBBHV or as RRRRRGGGGGBBBBHV for standard resolution or RRGGBBHV X 2 for double-width since you have twice as many bits to work with. And of course, other mods such as DDR schemes could increase the throughput even more. Or for a more complex 3rd possibility, with some sort of multiplexing and video circuitry cooperation (like a hardware counter and latches), you could theoretically send 2 pixels at a time and use some sort of multiplexer and hardware to keep the timings cycle-exact, and halve the video load on the CPU and keep Gigatron's color and resolution as it is.

I also got to thinking about how such a processor could be used with a homebrew Atari board. You could have a 6502 emulator in ROM, but this would likely require the lines that more complex CPUs had (though if you had ports that could be read, these extra signals could be emulated in software). The Atari home computers used 5 main chips. They had the "Sally 6502" (a modified 6502-B with a /Halt line to pause the CPU), the ANTIC chip (a coprocessor that interpreted display lists and provided DMA access), a GTIA chip (graphics interface that provided NTSC or PAL output), the POKEY (sound and peripherals), and the PIA (also for peripherals). However, the 6502 has an interrupt pin that would be needed for the peripherals, and the Atari used interrupt routines. So a custom CPU like this could be used with a 6502 emulator where 6502 software is required, but the ROM routines could likely be written in native code to take advantage of the memory and 16-bit functions. To get VGA, there are 2 possible paths. One is to use a modified VBXE (ANTIC replacement board with its own ROM) if your VGA monitor can work with composite syncs, or piggyback the latest Sophia board to the GTIA and have DVI output.

So you can see that you have me thinking a bit.

Re: On the shoulders of Giants

Posted: 21 Oct 2019, 00:01
by PurpleGirl
I've been thinking more about a Suite-16 being used as a Gigatron. Obviously, you'd need at least 1 IN port and 2 OUT ports, and ROM.

If you had a 16-bit X-Out, I could think of various ways to use those bits. For instance, if you wanted blinkenlights, that leaves 12 bits, and you could have 2 6-bit sound channels for true stereo or have 12-bit mono. Or have 2 8-bit sound channels without lights. Or have 2 4-bit channels for sound and either lights or stereo and have the upper 8 bits free to control an external device.

I already mentioned in the previous post how to handle video through a 16-bit OUT. If you want to keep to a Gigatron's methods, the extra bits could either be used to add more colors (up to 16k if you keep the top 2 bits for syncs), double the resolution (with the right latches and signaling) or keep colors and resolution the same with improved processing performance (by finding a way to send 2 regular signals at once and having hardware delay to send the 2nd half in a bit-exact manner and process every other pixel).

The emulators would get the most boost due to both the additional ALU commands and eliminating thunking. Native programs would benefit most from the additional opcodes. Native code would not benefit as much from the extra bits other than having more memory and being able to send 16-bits to peripherals. But if more byte instructions were added or even MMX-style instructions (like doing 2 8-bit adds in a single 16-bit register), that would boost certain computations, but would likely add to complexity assuming it is feasible.

A bidirectional port for an I/O device would be a nice addition if feasible. If nothing else, if the ports are all 16-bit, you could use the upper 8 bits of the new IN (separate from the UART) and X-Out (through whatever necessary multiplexer) to communicate with an 8-bit I/O device. That would allow keeping the keyboard and the lights/sound as they are and adding an I/O port without adding additional HW.

Re: On the shoulders of Giants

Posted: 02 Nov 2019, 03:29
by PurpleGirl
Since I see you now have ports planned, I'd like to make a suggestion. I think you should use the 8 bits at the end of the instruction to specify a port address. That way, you could support up to 256 ports. And whoever makes peripherals could use simple address decoder logic to see if it is the device being addressed and to read or write based on that.