WF FPGA Ideas

Video enhancements

WF16 Video Architecture

Math coprocessor

FPU Accumulator

SDCard

Auto-tx on read. Could supersede this with auto-reading a 16-bit length to a storage pointer, running in the background, flag or interrupt when done. Loading straight into DDR3 would be good once audio/video can read from there.

Stream MP3 or MIDI file from disk (or ddr3?) straight to chips

Bootstrap and Machine Identity

Access to the cores SDCard. Name something better than the current hardcoded names.

Soft-boot into one of the other cores, instead of relying on jumpers to select the core. Have an extended PGZ header or new file format that can request such things. Note that PGZ should say how many and which 8k blocks or 64k banks it's hardcoded for. Should be another load format for "play nice" system tools that can be simultaneously loaded.

Identify cores by an 8 character ASCII string, instead of bit fields. Maybe have a version number (16 bit) per release of any named platform.

Have different ROM loads for different cores? Or boot from RAM if some magic bytes occur there instead of ROM., though that would be part of the ROM boot that can do that, what ISA would the code be?

Easy Jiffy Timer

Good for simple direct BASIC or ML time anchoring.

Either a 60Hz timer, or a frame counter?

32-bit, why not. Reading the low byte re-latches the entire field so that reads are always consistent.

Wavetable Audio

Some form of wavetable audio is sorely missing for Amiga, TG16, SNES, Soundblaster era audio, especially sound effects. Basic multiple channels of stereo or panned mono, uncompressed samples, support some simple compression formats.

Pull small buffers of audio into the FPGA from RAM, keep 2 live at a time, one playing, one buffered. At 25MHz with a 48KHz sample rate, 1 sample lasts 520 cycles (20µsec), could be fast enough to fetch while the last sample is playing and just single-buffer it? Or even a rolling window Should also support just-in-time software generation of each buffer, with IRQ notifications.

Stretch samples to whatever the output sampling rate is. Linear interpolation would be neat, but probably optional. Same with the decay-to-zero that many old synth chips had.

Sound Chip Instances

Instead of duplicating hardware instances of sound chips, multiplex all their registers and internal variables. Access would select 1 of them, and the hardware would run with that multiplexer active on all its values. Compare the size taken, depends on how complex the chip is.

Since sound chips don't need to be that fast, serially looping through and executing a cycle, accumulating their output, for the final audio sample would be fine.

Register to select which instance(s) to use, so programs can be agnostic to what sound context exists with other things. Probably expose 2 chips at a time through the IO registers, with a separate one to select which bank of 2 to use. At least for mono chips, or those which are commonly in pairs. Stereo chips could just have 1 register set exposed.

FPGA-based CPU

65816 but with a genuine 16-bit data bus

Bitstream readers/writers

Write a byte or word to a FPGA location, it takes a CPU cycle to write it, and bumps its pointer.

For a bit stream, a 32-bit bitpointer covers 4Gb = 512MB. A write would need to know the width to write. Maybe 16 registers, write a value to one of those to declare how many bits from the written value to write. This actually allows the index register to determine width dynamically, which is nice. Both read & write interfaces should use this. A complete hack but easier to use would be to have 18 regs. For any width >8 bits, a 2nd access to the next register would grab the high byte, even though it's technically the trigger for the next higher. But this would get confusing in 65816 16-bit mode, accessing lower lengths.

Separate read & write context, so copies, decompression, etc, can be done. Bit pointers can be directly read/written as well. Direction is always in the positive direction, though, at least for now.

Probably good to support 0-length, for dynamically computed lengths. So with 0-16 supported, that's 17 entry points, kinda messy.

Also, skip forward N bits without a read or write. Technically this could just be a read N bits and ignore the value, but this should be 0-65535 bits skipped.

8bit interface: 2 bitpointers, then 8 byte locs for pointer 0, and 8 byte locs for pointer 1.

16bit interface: 2 bitpointers, then 16 word locs for pointer 0, 16 word locs for pointer 1. Writes triggered on high byte write. Reads trigger on low byte read, which readies the high byte.

This is a CPU-blocking interface for reads, buffered for writes.

RLE Format(s)

RLE layers, DMA, and potentially sprites can use RLE encoding.

Span-based RLE formats

bpp	Layout	length	Max compression	Breakeven
1	clllllll	1-128	16:1 byte	8px
2	cc111111	1-64	16:1 byte	4 pixels
4	ccccllll	1-16	4:1 byte	2 pixels
4	ccccCCCC llllllll llllllll	1-256	170:1 byte (512:3)	3+3 pixels
8	cccccccc llllllll	1-256	128:1 byte	2 pixels

However, it would be useful to have spans of literal pixels as well, instead of just solid color span fills.

0lllllll cccccccc = span length L of color C, 0 = transparent

1lllllll cccccccc...= L count of individual pixels

For a bpp less than 8, probably require them to fill an even byte or word count

For now, RLE layers should be simple length + 8bpp aligned words. RLE bitmaps would be something different, maybe it's too flexible so we should just leave that to the CPU. It would save a lot of bandwidth for bitmap overlay layers with large transparent windows, though.

DMA/Blitter

Maybe separate out 2d mode into its own blitter?

Flag to mask out the 'fill/mask' color (default 0)

Clip to output screen dimensions.

Xflip, yflip, maybe 90° rotation, but that means dest dimensions change? Scaling? Full affine transform?

Unpack RLE graphics, for better memory usage.Could still do x/y flip because this isn't raster-dependent. Must know the total x/y though if clipping is supported

Fields:

• bpp (could expand from src to dest given an offset?)
• src w/h/stride
• dest w/h/stride

TODO - V2

Clipping? Or should the src/dest be handled in software?

Ideally, there'd be a clip bounds defined at the dest address, w, h, stride, bpp. The source address is defined, and it's blitted into an x/y in the dest screen, automatically clipped. This could also be used as a pixel/stamp plotter.

If there end up being a large number of parameters for a src or dest, it would be nice to have multiple profiles. Either read src/dest profiles from ram, or have say 4 src & 4 dests saved, and blit from src N to dest M.

RLE graphics should probably save their w/h and mode implicitly as the first 2 words, as they are their own free-form shapes.

Since DMA currently only takes place during VBLANK, could be more efficient to have a DMA list to run when VSYNC hits, blasting those out as fast as possible.

For 1bpp (or maybe others, too?) and/or/nor/nand/xor modes would be necessary.