WF FPGA Ideas - Revision history

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.

WF: /* Optical Keyboard */

2026-01-13T10:05:38Z

Optical Keyboard

← Older revision		Revision as of 06:05, 13 January 2026
Line 83:		Line 83:

	== Optical Keyboard ==		== Optical Keyboard ==
	Can this be sent as 9 events of 8bits, instead of 8 events of 9 bits (2 bytes)?		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.

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

WF at 09:53, 13 January 2026

2026-01-13T09:53:35Z

← Older revision		Revision as of 05:53, 13 January 2026
Line 81:		Line 81:

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

			== Optical Keyboard ==
			Can this be sent as 9 events of 8bits, instead of 8 events of 9 bits (2 bytes)?

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

WF: /* Tentatively Proposed RP2040 Startup */

2026-01-13T09:03:19Z

Tentatively Proposed RP2040 Startup

← Older revision		Revision as of 05:03, 13 January 2026
Line 35:		Line 35:
	=== Tentatively Proposed RP2040 Startup ===		=== Tentatively Proposed RP2040 Startup ===

	* Read SD Card for magic <code>/MYCORE</code> file containing the full path of the core filename to boot.		* Read SD Card for magic <code>/MYCORE.TXT</code> file containing the full path of the core filename to boot.
	** If this exists, DIP switches can be some form of override. Need to be able to break in if something messes up. On configuring MYCORE, always tell the user to set their DIP switches to 00.		** If this exists, DIP switches can be some form of override. Need to be able to break in if something messes up. On configuring MYCORE, always tell the user to set their DIP switches to 00.
	** If this doesn't exist, oldsk00l DIP switches determine the core to boot.		** If this doesn't exist, oldsk00l DIP switches determine the core to boot.

WF: /* Tentatively Proposed RP2040 Startup */

2026-01-13T02:53:52Z

Tentatively Proposed RP2040 Startup

← Older revision		Revision as of 22:53, 12 January 2026
Line 35:		Line 35:
	=== Tentatively Proposed RP2040 Startup ===		=== Tentatively Proposed RP2040 Startup ===

	* Read SD Card for magic <code>/MYCORE</code> ~~1-byte~~ file ~~to know which~~ core to boot.		* Read SD Card for magic <code>/MYCORE</code> file containing the full path of the core filename to boot.
	** If this exists, DIP switches can override ~~in one of the settings?~~ Need to be able to break in if something messes up. On configuring MYCORE, always tell the user to set their DIP switches to 00.		** If this exists, DIP switches can be some form of override. Need to be able to break in if something messes up. On configuring MYCORE, always tell the user to set their DIP switches to 00.
	** If this doesn't exist, DIP switches determine the core to boot.		** If this doesn't exist, oldsk00l DIP switches determine the core to boot.
	* Load compressed core file from card and get the FPGA going.		* Load compressed core file from card and get the FPGA going.
	** Set the FPGA comm handshake pins to 0 before releasing the init/reset command to the FPGA.		** Set the FPGA comm handshake pins to 0 before releasing the init/reset command to the FPGA.
	* Load <code>/RPLIB</code> library and jump into it, if exists (else infinite loop). This runs whatever library functionality can talk to the FPGA, and is upgradable as a file through the loaded utilities.		* Load <code>/RPLIB</code> library and jump into it, if exists (else infinite loop). This runs whatever library functionality can talk to the FPGA, and is upgradable as a file through the loaded utilities.
			The library should have functions to browse the cores sdcard, and select which file to boot with.

			TODO - do the core selection DIP pins also hit the FPGA for flash banking? If so, then we might not be able to escape them.

	== Timers ==		== Timers ==