WF FPGA Ideas - Revision history

WF: /* Page Pointers */

2026-09-16T07:51:13Z

Page Pointers

← Older revision		Revision as of 03:51, 16 September 2026
Line 50:		Line 50:
	\|}		\|}
	TODO - I/O space, once it's defined. Would be nice to have hardware page pointers being able to access productivity screen, etc.		TODO - I/O space, once it's defined. Would be nice to have hardware page pointers being able to access productivity screen, etc.

			TODO - how much space to leave to SRAM for future expansion or other platforms?

	== SDCard ==		== SDCard ==

WF at 20:03, 15 September 2026

2026-09-15T20:03:43Z

@@ Line 6: / Line 6: @@
 == Math coprocessor ==
 [[FPU Accumulator]]
 == SDCard ==

WF at 00:38, 26 August 2026

2026-08-26T00:38:32Z

← Older revision		Revision as of 20:38, 25 August 2026
Line 1:		Line 1:
			[[MiSTer Support]]

	== Video enhancements ==		== Video enhancements ==
	[[WF16 Video Architecture]]		[[WF16 Video Architecture]]

WF at 01:32, 13 August 2026

2026-08-13T01:32:59Z

← Older revision		Revision as of 21:32, 12 August 2026
Line 105:		Line 105:
	== Optical Keyboard ==		== Optical Keyboard ==
	Can this be sent as 9 events of 8bits, instead of 8 events of 9 bits (2 bytes)? However the self-describing row number might be useful to keep.		Can this be sent as 9 events of 8bits, instead of 8 events of 9 bits (2 bytes)? However the self-describing row number might be useful to keep.

			== RGB Calculator ==
			Have a 16-bit or 24-bit RGB color register, split out the R/G/B values, as any are written, the other reflects it.

			Have color ops (add, subtract, blend %), where writing R/G/B values performs that op, clamping for add/subtract. Writing the entire color also performs that (easier for 16 bit).

			For 16-bit, if the top bit is a mask bit, then what? Probably it's sticky, so if either input is masked, then the output stays masked?

	== RLE Format(s) ==		== RLE Format(s) ==

WF: /* Memtext Bitmap */

2026-03-03T00:25:07Z

Memtext Bitmap

← Older revision		Revision as of 20:25, 2 March 2026
Line 12:		Line 12:
	== Memtext Bitmap ==		== Memtext Bitmap ==
	Akin to the C64 hi-res bitmap mode, have a 640x480 1bpp bitmap with 8x8 color cells as defined by the existing memtext (or on-FPGA?) color attributes.		Akin to the C64 hi-res bitmap mode, have a 640x480 1bpp bitmap with 8x8 color cells as defined by the existing memtext (or on-FPGA?) color attributes.

			Font currently takes

	Settings:		Settings:

	* Address of bitmap data (same as memtext font pointer)		* Address of bitmap data (same as memtext font pointer)
	* Choose cell-based (C64-like) or linear pixel byte layout		* Choose cell-based (C64-like, follows 8x8 or 8x16 memtext selection) or linear pixel byte layout
	* FPGA color matrix (2x 16-color) or RAM color matrix (2x 256-color)		* FPGA color matrix (2x 16-color) or RAM color matrix (2x 256-color)
			It's annoying that this has its own separate palette, which takes up a lot of space, but I get it that it's a separate parallel pipeline to the "graphics" section. However, I'd rather just have it select which CLUT to use for FG and BG.

	== Bootstrap and Machine Identity ==		== Bootstrap and Machine Identity ==

WF at 23:49, 2 March 2026

2026-03-02T23:49:36Z

← Older revision		Revision as of 19:49, 2 March 2026
Line 9:		Line 9:

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

			== Memtext Bitmap ==
			Akin to the C64 hi-res bitmap mode, have a 640x480 1bpp bitmap with 8x8 color cells as defined by the existing memtext (or on-FPGA?) color attributes.

			Settings:

			* Address of bitmap data (same as memtext font pointer)
			* Choose cell-based (C64-like) or linear pixel byte layout
			* FPGA color matrix (2x 16-color) or RAM color matrix (2x 256-color)

	== Bootstrap and Machine Identity ==		== Bootstrap and Machine Identity ==

WF: /* Bitstream readers/writers */

2026-02-20T06:46:32Z

Bitstream readers/writers

← Older revision		Revision as of 02:46, 20 February 2026
Line 76:		Line 76:

	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.		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.

			Automatically converts between 32-bit bitstream pointer and 24-bit byte pointer + bit offset. When writing to the byte pointer, it automatically zeros out the bit offset, for easier initialization from standard word boundaries. If loading a bit pointer from normal pointer + bit offset, set the bit offset last.

	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.		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.

WF at 01:19, 18 February 2026

2026-02-18T01:19:45Z

← Older revision		Revision as of 21:19, 17 February 2026
Line 61:		Line 61:

	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.		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.

			== 65816 support ==
			Remap page 0 into any 64kB bank, allowing direct page, stack, etc, to have its own swappable space. However, need to consider how this goes for interrupts. An interrupt will probably have to remap to hardware bank 0, but then somehow restore the bank that used to be there. Keeping the upper 256 bytes locked somewhere (flash or bank 0 RAM) would solve that. The 8kB MMU can be used for these purposes already, but I wonder if the full bank swapping might be easier, but likely not really necessary as long as the MMU is around.

	== FPGA-based CPU ==		== FPGA-based CPU ==

WF: /* FPGA-based CPU */

2026-01-19T06:39:13Z

FPGA-based CPU

← Older revision		Revision as of 02:39, 19 January 2026
Line 58:		Line 58:
	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.		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.		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. Some of them do this internally with their voices anyway.

	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.		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 ==		== FPGA-based CPU ==
	65816 but with a genuine 16-bit data bus		65816 but with a genuine 16-bit data bus.

			Keep 6809 in the same core with the 65816 running. Switch between either at any time (bus master), or alternate cycles. At core2x speed, they could each run at 6MHz alternately hitting the SRAM.

			If the bus can be more dynamic, especially during vblank/hblank, the CPUs can run a lot faster there.

	== Bitstream readers/writers ==		== Bitstream readers/writers ==
Line 144:		Line 148:
	Xflip, yflip, maybe 90° rotation, but that means dest dimensions change? Scaling? Full affine transform?		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		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:		Fields:

WF: /* Bitstream readers/writers */

2026-01-13T15:21:19Z

Bitstream readers/writers

← Older revision		Revision as of 11:21, 13 January 2026
Line 74:		Line 74:
	Probably good to support 0-length, for dynamically computed lengths. So with 0-16 supported, that's 17 entry points, kinda messy.		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.		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. Could also just do a 32-bit add on the pointer register.

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