List of possible Gigatron mods

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
Sugarplum
Posts: 93
Joined: 30 Sep 2020, 22:19

List of possible Gigatron mods

Post by Sugarplum »

Here is a list of as many possible Gigatron modifications I can see. Keep in mind that this list is only to give ideas and inspire creativity. Nothing said here is to be taken as a criticism of the platform. The Gigatron is already beautiful as it is.

Opcode Mods

Add more memory addressing modes -- Most would love to have more addressing modes to simplify coding.

Increment Y as a carry of X -- Of course, this should not be the only option here. There is beauty in X rolling over without incrementing Y since that facilitates video scrolling. The 96 bytes past the 160-pixel limit means that you can have extra graphics data for a row. However, if you need the pointers to act in a "far" fashion, an upper byte counter would be nice. Or add a new register that does this and give it flexible address mode options.

Modify the Ac=Ac+Ac instruction to be a full left-shift instruction -- One could make SHL 0 the same as SHL 1 to maintain compatibility. This would make unsigned multiplication easier. The immediate field could be used to specify the shift distance.

Add a Shift Right instruction -- This will make programming life easier and allow some of the most common division operations from a single instruction.

Add additional ISAs -- One could use a redundant instruction to page between instruction sets. So if you need more memory access modes than what can fit in the standard design, you could place them on another page. So you could fit 510 or more instructions in an 8-bit space. It would likely be good to have the port instructions on every page and keep the paging instruction in the same place on every page. An idea from the forum proposes converting the control unit into a module and inserting different control units.

Use the immediate field for instructions in instructions with no operands. -- Instructions with no operands waste the immediate space, so it would be nice to do work in those. However, jumps and things that need the main bus would be out of the question. It would be interesting to generate sound or toggle lights while slinging pixels, for instance. Alternatively, use that space to drive a port directly or even use that area for program storage, much like steganography. So it is possible to store additional vCPU programs in this space.

Use the Instruction field for a block copy opcode -- For storage of tables and images, one could have an opcode that specifies a block ROM to RAM copy command with an argument to specify the number of words. So up to 512 bytes or 680 packed bytes could be stored in a single block. That would mainly affect density, not speed, depending on how this is implemented. Halting may be needed as it copies, though you could implement interleaved RAM channels that are 8-bit addressed but can be made to act as 16-bits (though that would not give enough time if you store packed bytes). Or some sort of concurrent DMA could be used with very fast SRAM.


Port Mods

Add a port status/command register with supporting instructions -- This could be a command port for changing video modes, multiplexing the ports, and more. Or at least add a line to reset an external frame buffer if you use one. Then you'd have a known state. This idea might work even better if one adds a vCPU coprocessor. Then it could have 16-bit port instructions and send commands and data together. So a Harvard-like port. One bit of a higher port could be used to provide 9-bit graphics. That is something I know of no platform ever using. One could use the high bit to choose between using a 15-bit video mode or using the upper 8 bits for commands. If you want to use the port for 16-bit data transfers, one possibility would be to add an "appointment" command so the mode bit could be used for data for a specified number of cycles.

Use different port strategies -- The Gigatron lets the port hold onto a byte, so you can run other code as long as the byte doesn't need to change. There may be times when a single-shot signal is more appropriate. For instance, if you use a ported frame buffer for video, you don't want to overwrite what is in there with what is in the port if you don't want to send anything. Another possibility would be to have the port tied to a more autonomous memory unit. So when you are using only the ROM, you could have built-in DMA capabilities to send data to the port from RAM.


General Performance Mods

Use a carry-select adder arrangement in the ALU -- This involves adding a 3rd adder chip and a multiplexer. It is faster to switch which high nybble is on the bus than waiting for the high nybble adder to add the carry. One high nybble adder would get the carry signal from the ground plane, and the other would get it from Vcc. The carry-out line from the low nybble would determine which result goes on the bus. Doing this could help achieve faster clock rates.

Rework the control unit to avoid using Ac on non-port Moves -- This would prevent clobbering the Accumulator during moves and create less work for the programmer in some cases. An unfortunate side-effect is that X-Out will likely stop working. One could add instructions to give another port or at least change how the Out port is multiplexed. Besides simplifying some code, another benefit could be more stability at higher clock rates since the ALU would be utilized less, reducing the critical path for some instructions and possibly reducing heat issues. It would need to use the ALU (or at least Ac) on port-related moves to ensure that the ports can still use logic ops.

Decentralize the ALU -- One could probably do some of the ALU ops faster using dedicated chips for specific functions. That could even get past the previous item's problems since the port could have its own logic unit. After all, the X-register has its own adder. So the port could have its own AND and OR gates. This would be better to attempt in FPGA.

Add another pipeline stage -- This could increase the clock rate since the execution stage is the longest. So this could entail using registers to split decoding from the ALU. That might push things closer to 25 Mhz. Some quick calculations say at least 18 Mhz. If a 6502 designed in TTL can do 20 Mhz, I'm sure the Gigatron could be boosted to that. A side-effect here might mean a second delay slot after branches. That would require a new ROM to support that since that would alter how trampoline code and branches work.


Video Mods

Hardware-generated syncs -- In and of itself, this can give modest gains with bit-banging since there would be fewer port instructions. You'd still need to count cycles. It doesn't particularly matter if this is clocked at 25 Mhz since the Gigatron' could use quadruple the pixels in both directions. Just make sure the syncs are in phase with the Gigatron. One way to do that would be to derive the Gigatron clock from the video clock. If you had 2 more registers, it would be easier to alternate between vCPU and bit-banged video since it would be easier to interleave the 2.

Do line quadrupling in hardware --- This would give slightly better performance than skipping 3 lines (due to ROM changes) and would allow sending all the lines.

Compress 4 pixels into 3 bytes in hardware --- This would allow four 64-color pixels to be sent in the time of 3. So you save a clock cycle every 4 pixels. This would be more useful with a frame buffer (and hardware syncs) since you can make all the free time contiguous.

Add a frame buffer -- This could improve performance in various ways. This would mean video persistence, so you can send a frame and use entire frames for data processing. (Actually, we already have a frame buffer, though I imagine a remote one would have some advantages. You could probably ask it to do things to free up memory accesses on the local one.)

Create a text mode -- There are many ways to do this. The simplest way would be to create a monochrome text mode and send at least 6 pixels at once (8 if you do hardware syncs). This approach would free up memory and use fewer instructions. If you want colors, add color registers or an attribute map. If you use an attribute map (one entry per character), you wouldn't want to attempt graphics while in that mode, or you'd get color-smear. If one is making a video controller, you could send it only ASCII when it is in text mode. The video circuitry could do a ROM lookup and plot the pixels according to the ASCII code.

Add higher res modes -- For instance, 320 x 240 is not far out of reach. If memory is a concern, use 4 bits for the pixels, 2 for the color, and 2 for the syncs (unless other mods are applied). Without the syncs, you could send 4 pixels, 4 colors each. To do a full 64 colors or more, you'd likely need a frame buffer with 75K RAM.

Add hardware sprites -- If you are making a video card and using a frame buffer, you could do sprites in hardware, especially if using programmable logic. What would be nice would be if there were a sprite "chase" mode. Like what if one sprite could use the frame buffer as a map to only travel in reachable transparent/background areas to travel to another sprite (with non-colliding behavior regarding other sprites in the same layer) and somehow report its position to code? I wonder what that could do with PacMan if the ghosts were managed in hardware?

Use hardware scrolling -- With a frame buffer, this could be a matter of virtualizing the video RAM addresses. Just change the wrapping points. One would need a protocol for filling the missing/corrupted pixels after scrolling. Vertical scrolling is mostly a prerequisite for text mode, and virtualizing the frame buffer might be the most efficient way to "scroll" the screen. Maybe have an adder that works during syncs.

Add a command port -- This would allow for changing video modes in software, changing palettes, and more. This could even be used for sound, lights, and storage, assuming you have a frame buffer and hardware syncs. This idea would work better on a 16-bit design.

Add a .GIF/.PNG decompressor -- This would be more for advanced FPGA designs. If you build a port controller that includes hardware graphics, sound, and storage, you could tell the hardware CODEC to read from storage, convert, and send its data to the frame buffer. One might want to stick to the GIF87 format since it is simpler. GIF89 includes animation.

Add "weird" video modes -- What if we clock the Gigatron at 8.3 Mhz and have 213 X 160? That means that the virtual rows would be 3 actual lines rather than 4. Or, if one uses a frame buffer, one could do it like the Atari 800 and have a mode where you have a graphics window and a text box. The reason to do it that way is to save some buffer memory since it takes less RAM to store references to characters than individual pixels. While it would be good for hi-res games (put the stats, title, score, etc., in the box), it could have some technical or scientific uses. One could have a bitmapped diagram and an item key or text description in the text area.


Coprocessors

Add a math coprocessor -- At the least, add a hardware multiplier. You can easily do the first ten multipliers for unsigned values in a single cycle. You can simultaneously fill registers with all the shifted values you need and then add or subtract. For instance, if you want to multiply by 5, you have the original multiplicand with it shifted already by 1, by 2, by 3, etc. Then you'd take the SHL 2 and add to the original, then put that on the bus. Multiplying by 7 is a tad trickier, and subtracting seems to be the easiest strategy. So take the SHL 3 value and subtract the original. Really, going this far, one might want to build a binary multiplier. It works like long multiplication, though no actual multiplication is needed. Then add all the shifted intermediates together. This might be doable in 4 cycles, depending on how you implement it. This is much like the previous method, but without lookup tables or matrices.

Another multiplier idea could be a LUT and addition hybrid. You could have 4 nybble tables and use a total of 1k. Then you could look up and add the nybbles in parallel. That might save a cycle from the shift-add idea. This would be much like the FOIL method in algebra.

Add a vCPU coprocessor -- One way to speed up vCPU would be to make it an actual core. It should have a way to access RAM directly. So you'd need a memory unit or an arbiter of some kind that ties into the Gigatron's memory unit. One way to do this could be to give the Gigatron priority to the memory and only run vCPU when the RAM is not used. Another way could be to have a time-slicing memory controller that operates at a much higher speed. Thus the memory unit would have different channels. Or do a combination of both to make it more overclocking friendly. On the ROM side of things, the emulator could be replaced with some "listener" code to determine when the Gigatron core needs to do something. In FPGA, you might be able to have a BRAM table to tell the vCPU how long to halt before a valid result. Of course, you could simply have the system calls done on the vCPU core.


Sound

Hardware PSG -- While it is neat that the Gigatron can do everything in software, a hardware PSG would have some advantages. Like a dedicated video controller, it can manage the timings itself. So you save cycles of the precious sync timings. The sound could be cleaner since it would be working during the entire frame. You must admit that the "gritty" sound has an endearing quality. If you want to keep the roughness, that could be a sound controller mode. The PSG could add additional waveforms and noise. An FPGA version could be more flexible, but one could find a way to wire in the TI sound chip (used in the TI994A, also the Sega Genesis in addition to the Yamaha chip).

A better idea might be to implement the Gigatron's method as a PSG in FPGA. So it uses all the same memory. In that case, it could be a part of the video controller and let the syncs do arbitration as they do now. That would avoid hardware races.

Music mode -- I've never seen a PSG with a music mode. It could have a table of count values for every note. The 440 Hz "even-temperament scale" would be the most useful, but it could be tuned to other scales. At one point in time, the A above middle C was tuned to 434 Hz before it was standardized worldwide around WWII. It could even have added features such as buffering, looping, tempo adjustment, different note lengths, etc.

Add hardware .MP3/.OGG support -- An integrated I/O controller could contain a CODEC for this.


Blinkenlights

Add an autonomous light controller -- The Blinkenlights are fun, but removing them could offer a slight performance boost. A compromise would be to add a light sequencer. To stay within the spirit of the design, such a controller could have at least 3 modes. It could have a learn mode, a replay mode, and a manual mode. It could also have an off mode (or enable line) and a default mode. So you can set it and forget it if you want, use it the old way, or program the sequence and run that.


Peripherals and Storage

USB -- At the least, if one uses FPGA, one could have a USB slave port with at least UART capabilities. That would allow for installing, running, or transferring programs.


Different Platform Ideas

vCPU as a platform -- If one were to make dedicated controllers for everything such as video, sound, lights, I/O, etc., and if vCPU were an actual core, then would the Gigatron core be needed at all? Yes, that defeats the whole purpose of this project. The I/O controller might need to initialize the RAM with what the ROM puts there now.

Use 2 Gigatrons -- There are various ways to do this. Marcel gave possible plans for merging 2 Gigatrons. That plan was to let one handle the input and user code, and the other handle the lights, sound, and video. Another way to do this could be to multiplex the memory between them.

Build a Gigatron-like machine around Monosonite's Suite-16 ISA -- Since the Suite-16 is designed to use 16-bit RAM, it can do 8-bit operations in a single cycle. But it could do 16-bit (or even 24-bit) operations in 2 cycles.

Use a Gigatron with a Propeller chip -- The Propeller is a 32-bit microcontroller that has 8 "cogs." It was designed using FPGA and converted to an ASIC. You can use different cogs to provide support for different peripherals. So you could use 1-2 cogs for video, 1-2 cogs for sound, 1 cog for keyboard support, 1 cog for mouse support, etc. One might be able to use it as a math coprocessor too. It has built-in video support with yes, 6 bits, and 2 syncs. Someone even used the Propeller to emulate the Commodore SID chip.
Last edited by Sugarplum on 05 Sep 2021, 17:52, edited 12 times in total.
cde
Posts: 11
Joined: 13 Sep 2020, 08:37

Re: List of possible Gigatron mods

Post by cde »

Wow! That's a very comprehensive list. Thanks for taking the time to write it :-) I don't have much to add, all these seem like interesting ideas!
Sugarplum
Posts: 93
Joined: 30 Sep 2020, 22:19

Re: List of possible Gigatron mods

Post by Sugarplum »

Thanks! I added to it over several days. I don't know how many I will implement once I get ready to implement it in FPGA. It seems that I'm thinking of making it more as an Asymmetric Multiprocessor (AMP as opposed to SMP) APU and mostly a SOC design.

I could see someone like David Murray ("The 8-bit Guy") getting behind something like this a bit more than he would the C-256 Foenix, though he isn't the fondest of FPGAs. Stefany Allaire's Foenix is quite an impressive system, just that it wasn't quite what David had in mind. I think he envisions something more affordable and accessible, with locked standards and limitations.

Platform limitations inspire creativity. Just look at the quality to power/resources ratio of the various platforms that have existed over time. A lot of creativity went into games designed around the MOS 6507 (a cut-down 6502). Today's PC games tend to take up lots of space and have considerable lag and load times, even though hundreds to thousands of times the processing power and resources are available.

So I guess it is important to keep this in mind when trying to use the Gigatron as a base for building other machines. Too much feature creep can make a platform less fun, less entertaining, and perhaps less of a learning experience.
at67
Site Admin
Posts: 647
Joined: 14 May 2018, 08:29

Re: List of possible Gigatron mods

Post by at67 »

Sugarplum wrote: 19 Nov 2020, 12:10 So I guess it is important to keep this in mind when trying to use the Gigatron as a base for building other machines. Too much feature creep can make a platform less fun, less entertaining, and perhaps less of a learning experience.
Personally I find a retro system's quirks, limitations and hidden/obscure features the reason and motivation to code for an architecture; there's always that challenge of pushing hardware and firmware beyond what it was intended to do and not only surprising others at what you create, but surprising yourself.

I can quickly lose interest in a system that tries to do too much or is too modern. I have always been fascinated with the blank piece of paper approach, where nothing or very little exists and you bootstrap the system into existence and allow it to grow in a non structured organic way.

Sure the final product will generally have limitations, quirks and oddities, but this in the end is what keeps me sticking around.
Sugarplum
Posts: 93
Joined: 30 Sep 2020, 22:19

Re: List of possible Gigatron mods

Post by Sugarplum »

Yes, finding ways to hack older hardware is fun. The 6502 had "illegal opcodes" that many coders would use.

It's neat what add-ons folks are making for the Atari machines. Someone had made a driver for running a parallel printer on an Atari 800 using the joystick ports. Someone even managed to write a BASIC for the Atari 2600, and someone else made a system monitor cartridge.

The cartridge approach was nice in that the base machine could be kept pure to its design. If others needed more features, they'd add additional chips to the cartridge. One of the later Atari consoles didn't use the POKEY chip and used a TIA chip for sound. Game designers who wanted to use a POKEY added one in their cartridge. Also on the early gaming systems, the entire ROM was in the cartridge. So each manufacturer came up with their own ROM for the machine that was tailored to what they were trying to accomplish.

Some of this type of hacking existed in the early PCs, at both the hardware and software level. The IBM PC really wasn't designed for sound. It did send a bit to the speaker and used a spare system timer (I think that chip has 3 timers) channel to toggle that bit. More-inclined programmers used arpeggiation to emulate more sound channels. The Gigatron has that beat in that it has 4 bits for sound. The Tandy 1000 had 3-4 sound channels. Of course, their focus was more toward education and a younger audience while IBM focused on the business market.

There used to be no CPU-ID function in the PCs, so programmers would test for the quirks that were unique to each CPU that might attempt to run their code. That would be used to limit certain features for reasons related to speed or crashes or to provide multiple code paths. I used such code in a program that drew various designs on the screen and flashed the keyboard lights (think Blinkenlights, but only 3). That way, it would not crash an XT machine due to the port addresses being different and mapping to something critical such as DRAM refresh.

Self-modifying code is another "old school" technique. That cannot be done in native Gigatron code, and that's one of the security benefits of a Harvard machine. PC programmers often ran into trouble there due to cache and pipeline differences. A program I wrote using self-modifying code would work on all x86 CPUs but a 486. You had to flush the pipeline if you wanted that to work, since if you overwrite code, you may be running a stale cached copy.
Last edited by Sugarplum on 14 Sep 2021, 18:58, edited 2 times in total.
monsonite
Posts: 101
Joined: 17 May 2018, 07:17

Re: List of possible Gigatron mods

Post by monsonite »

Here's my take on it.

As a non-games player, the colour graphics, blinkenlights and sound don't really interest me.

Imagine the Gigatron as a general purpose CPU. It's capable of emulating 6502, Z80 and any other cpu.

Remove the overheads of VGA video generation and it becomes a powerful cpu (by 1980 standards).

SPI has become a ubiquitous interface standard for modern peripherals - so we already have the 74HCT595 as the serial input.

By adding a single 74HC165 to the ALU result bus - we get a high speed serial output device. We can use the XOUT latch as a means of selecting several SPI peripherals.

With the addition of a single shift register, the Gigatron becomes an SPI master allowing a wide variety of SPI peripherals to be added.

We already rely on "Pluggy" to communicate with the Gigatron, so we just enhance Pluggy to become a high speed serial communications device - so we can continue to talk to the Gigatron and get a text based output.

Without having to maintain the video generation, Gigatron will become a powerful 8-bit cpu, with the ability to access a load of modern peripherals.

Just my 2 cents.

Ken
alastair
Posts: 68
Joined: 10 Oct 2019, 14:28

Re: List of possible Gigatron mods

Post by alastair »

Sugarplum wrote: 18 Nov 2020, 19:36 Add more memory addressing modes -- Most would love to have more addressing modes to simplify coding.
This got me thinking. Who else has written (native) code for the Gigatron? Obviously Marcel and there is one other project I'm aware of - https://hackaday.io/project/168293-gigatron-forth

Working directly with the op-codes is a significant undertaking and it looks like the Gigatron Forth project might have stalled because of this. I'm assuming that adding or changing op-codes would be of limited use. Does anyone have plans to work directly with these op-codes?
walter
Site Admin
Posts: 160
Joined: 13 May 2018, 08:00

Re: List of possible Gigatron mods

Post by walter »

One of the first customers is a chess enthusiast who has built several special purpose computers for this task. He was planning on changing some opcodes to facilitate his chess program, but I believe he hasn't come around to doing this yet.
at67
Site Admin
Posts: 647
Joined: 14 May 2018, 08:29

Re: List of possible Gigatron mods

Post by at67 »

alastair wrote: 01 Dec 2020, 20:06 This got me thinking. Who else has written (native) code for the Gigatron? Obviously Marcel and there is one other project I'm aware of - https://hackaday.io/project/168293-gigatron-forth
My Assembler and Emulator let you write native code and test it seamlessly; the initial sprite routines I came up with over 2 years ago were all produced in this native code environment.

https://github.com/kervinck/gigatron-ro ... sm/sprites

There is huge scope for native code production and firmware modification, eventually I want to build a cartridge port for my Gigatron that supports completely different firmware ecosystems.
at67
Site Admin
Posts: 647
Joined: 14 May 2018, 08:29

Re: List of possible Gigatron mods

Post by at67 »

Sugarplum wrote: 18 Nov 2020, 19:36 Here is a list of as many possible Gigatron modifications I can see. Keep in mind that this list is only to give ideas and inspire creativity. Nothing said here is to be taken as a criticism of the platform. The Gigatron is already beautiful as it is.
There is a lot of good ideas here and a lot of them have been discussed in detail in other threads, I personally find it best to narrow down my objective to a specific task with reasonable and achievable goals and concentrate on one thing at a time. I am not trying to dampen your enthusiasm, I just find that sweeping architectural change threads never really mention the reality or scope of the real re-engineering required. It's not just the hardware that changes, but the firmware as well and it is almost always the firmware that is the non-trivial of the two. Of course this doesn't even cover the fact that most of these ideas will lose or require a re-write of the entire application level software eco-system, which can be fine for some projects, I just think it needs to be considered.

I'm not going to respond to all of them, just the ones that stood out for me:
Sugarplum wrote: 18 Nov 2020, 19:36 Add another pipeline stage -- This could increase the clock rate since the execution stage is the longest. So this could entail splitting decoding from the ALU. That might push things closer to 25 Mhz. Some quick calculations say at least 18 Mhz. If a 6502 designed in TTL can do 20 Mhz, I am sure the Gigatron could be boosted to that. A side-effect here might mean a second delay slot after branches. That may require a new ROM to support that since that would alter how trampoline code works.
It's not just the trampolines that would need to be re-written, (the trampoline code is mostly only used by the LUP instruction to provide random access to the ROM from vCPU), it's pretty much the entire firmware that would need to be re-written. Marcel uses the branch delay slot in practically every facet and sub-system of the Gigatron's firmware, for performance, efficiency and sometimes because of no choice. It would be a non trivial exercise changing from 1 branch delay slot to 2.
Sugarplum wrote: 18 Nov 2020, 19:36 Add a framebuffer -- This could improve performance in various ways. This would mean video persistence, so you can send a frame and use entire frames for data processing.
There already is a frame-buffer of 160*120*bytes allocated and scanned by the firmware for video display in the Gigatron's RAM, it's why there is only around 12KBytes free for applications after a reboot. *Note* the majority of this 12KBytes free RAM is separated into non contiguous chunks of 96 bytes each, (i.e. the 96 off-screen pixels per scan-line).
Sugarplum wrote: 18 Nov 2020, 19:36 Create a text mode -- There are many ways to do this. The simplest way would be to create a monochrome text mode and send at least 6 pixels at once (8 if you do hardware syncs). This approach would free up memory and use fewer instructions. If you want colors, add color registers or an attribute map. If you use an attribute map (one entry per character), you wouldn't want to attempt graphics while in that mode, or you'd get color-smear. If one is making a video controller, you could send it only ASCII when it is in text mode. The video circuitry could do a ROM lookup and plot the pixels according to the ASCII code.
A text mode to save RAM and provide text mode features like fast updates, pattern/attribute modification, etc is a great idea; but if all you want is fast update, (the Gigatron's firmware text routines are not particularly efficient), you could have a native code text blitter embedded within the actual text fonts in ROM in the same way that I coded native code sprites. This would allow for blazing fast text routines, (around 20-50 times faster than current routines).
Sugarplum wrote: 18 Nov 2020, 19:36 Add hardware sprites -- If you are making a video card and using a framebuffer, you could do sprites in hardware, especially if using programmable logic. What would be nice would be if there were a sprite "chase" mode. Like what if one sprite could use the framebuffer as a map to only travel in reachable transparent/background areas to travel to another sprite (with non-colliding behavior regarding other sprites in the same layer) and somehow report its position to code? I wonder what that could do with PacMan?
Hardware sprites, (depending on your definition and feature set of course), can be non trivial to implement, (and usually are). I implemented hardware sprites using CPLD's and PGA's back in the day for a TMS34020 system I designed and in the end they caused more trouble than they were actually worth, (especially as the TMS34020 had such a good and flexible blitting system in it's micro-code). Basic functionality for hardware sprites would be automatic regeneration of background and colour key transparency, anything less than this is usually just easier to implement in software, (especially on the Gigatron as it has a wickedly fast native mode that is perfect for fast memory movement).

Regeneration of background usually implies either dedicated RAM for the sprites and some sort of sprite DMA architecture that is multiplexed/interleaved with the video/display DMA, or buffer RAM to save and restore the background, (more like a hardware blitter). Colour key transparency requires per pixel multiplexing logic that can switch between multiple sources, (background, sprite, other sprites, etc). Both of these are non trivial to implement especially if you're going to be sticking to the Gigatron design ethos of 70's TTL logic.
Sugarplum wrote: 18 Nov 2020, 19:36 Use hardware scrolling -- With a framebuffer, this could be a matter of virtualizing the video RAM addresses. Just change the wrapping points. One would need a protocol for filling the missing/corrupted pixels after scrolling. Vertical scrolling is mostly a prerequisite for text mode, and virtualizing the framebuffer might be the most efficient way to "scroll" the screen. Maybe have an adder that works during syncs.
There already is hardware scrolling built into the Gigatron, (hardware as in it is built into the firmware just like the video generator), there is a video indirection table that stores pointers and relative offsets per scan-line, that enable quite flexible horizontal and vertical scrolling; you can even set up multiple layers of parallax scrolled regions being scrolled at different rates.
Sugarplum wrote: 18 Nov 2020, 19:36 Add a .GIF/.PNG decompressor -- This would be more for advanced FPGA designs. If you build a port controller that includes hardware graphics, sound, and storage, you could tell the hardware CODEC to read from storage, convert, and send its data to the framebuffer. One might want to stick to the GIF87 format since it is simpler. GIF89 includes animation.
This is a good idea, but would require copious amounts of hardware support to run at anything approaching usable speeds; something I think would be more useful is a DXT decoder. DXT is a 16bit per pixel lossy format that is trivial to implement in hardware and low level languages, (I have implemented bespoke DXT formats for height-map representation in both FPGA and DirectX/OpenGL Pixel shaders for a simulation client). Baseline DXT will give you 1/8 the storage requirement of the corresponding 24/32bit colour image on both disk and in RAM, on the Gigatron this would mean 1/2 the storage requirements for any image stored in RAM. Once again this could be implemented in native code firmware as a simple decoder/blitter and whilst being nowhere near as fast as the Gigatron's 1 byte per pixel format, (probably an order of magnitude slower), the savings in RAM for background static images or even small/slow moving dynamic images could be well worth it.
Sugarplum wrote: 18 Nov 2020, 19:36 Add a math coprocessor -- At the least, add a hardware multiplier. You can easily do the first ten multipliers for unsigned values in a single cycle. You can simultaneously fill registers with all the shifted values you need and then add or subtract. For instance, if you want to multiply by 5, you have the original multiplicand with it shifted already by 1, by 2, by 3, etc. Then you'd take the SHL 2 and add to the original, then put that on the bus. Multiplying by 7 is a tad trickier, and subtracting seems to be the easiest strategy. So take the SHL 3 value and subtract the original.
Adding native code for 15bit signed arithmetic multiply and divide/mod routines to the firmware is on my TODO list, currently vCPU multiply takes around 6000 clock cycles worst case and divide/mod take around 9000 clocks worst case. Multiply can be done using two 1024 byte look up tables in native code in around 50 clock cycles and divide in native code in around 500 clock cycles. So 2 orders of magnitude faster for multiply and roughly 1 order of magnitude faster for divide. This is without any change to the hardware or the firmware, (you would need a new ROM though as the new multiply/divide routines would be added to unused portions of the firmware as SYS routines).
Sugarplum wrote: 18 Nov 2020, 19:36 Hardware PSG -- While it is neat that the Gigatron can do everything in software, a hardware PSG would have some advantages. Like a dedicated video controller, it can manage the timings itself. So you save cycles of the precious sync timings. The sound could be cleaner since it would be working during the entire frame. You must admit that the "gritty" sound has an endearing quality. If you want to keep the roughness, that could be a sound controller mode. The PSG could add additional waveforms and noise. An FPGA version could be more flexible, but one could find a way to wire in the TI sound chip (used in the TI994A, also the Sega Genesis in addition to the Yamaha chip).
The Gigatron's audio is conceptually performed in a very similar way to the Amiga's hardware DMA audio channels, just at a much lower fidelity, sample size and sample pool size. It is amazingly well featured for such a simple implementation, (in terms of number of native code instructions to implement it). We have 4 channels of 64byte 6 bit samples with XOR modulation and volume control, all being real-time mixed down to a 4bit output. But I also wish we had ye-ole PSG/SID/etc as an extra chip and we almost did, if you read Marcel's blogs you'll see he was on the verge of integrating a PSG, but then realised he could produce decent audio in firmware only.
Sugarplum wrote: 18 Nov 2020, 19:36 Music mode -- I've never seen a PSG with a music mode. It could have a table of count values for every note. The 440 Hz "even-temperament scale" would be the most useful, but it could be tuned to other scales. At one point in time, the A above middle C was tuned to 334 Hz before it was standardized worldwide around WWII. It could even have added features such as buffering, looping, tempo adjustment, different note lengths, etc.
We have MIDI playback now of a Gigatron specific MIDI format and I have started work on a MOD Tracker format which will allow for similar, (but more limited), effects as produced by the Amiga, i.e. 4 channels of 64byte 6bit samples, (number of samples limited by RAM), with looping, repeating, slides, volume and modulation FX, etc.
Post Reply