7800 Software Guide - Revision history

MSaarna at 15:27, 13 July 2026

2026-07-13T15:27:52Z

Show changes

MSaarna at 17:54, 12 July 2026

2026-07-12T17:54:22Z

MSaarna at 17:51, 12 July 2026

2026-07-12T17:51:05Z

Show changes

MSaarna at 15:38, 12 July 2026

2026-07-12T15:38:18Z

MSaarna at 15:07, 12 July 2026

2026-07-12T15:07:35Z

MSaarna at 14:47, 12 July 2026

2026-07-12T14:47:12Z

MSaarna at 14:40, 12 July 2026

2026-07-12T14:40:57Z

MSaarna at 14:24, 12 July 2026

2026-07-12T14:24:43Z

MSaarna at 14:22, 12 July 2026

2026-07-12T14:22:11Z

MSaarna at 13:18, 12 July 2026

2026-07-12T13:18:56Z

@@ Line 30: / Line 30: @@
 The CTRL register is arranged as follows:
-{| class="wikitable" style="table-layout: fixed; width: 90%; max-width: 640px;"
+{| class="wikitable" style="table-layout: fixed; width: 90%; max-width: 1000px;"
 |+'''Color Register Layout'''
 |- style="vertical-align:top;"
@@ Line 196: / Line 196: @@
 These addresses write data into the audio frequency divider registers.
-{| class="wikitable" style="table-layout: fixed; width: 80%; max-width: 640px;"
+{| class="wikitable" style="table-layout: fixed; width: 80%; max-width: 1000px;"
 |+'''AUDF# Effect On Frequency'''
 |- style="vertical-align:top;"
@@ Line 219: / Line 219: @@
 These addresses write data into the audio control registers which control the noise content and additional division of the audio output.
-{| class="wikitable" style="table-layout: fixed; width: 80%; max-width: 640px;"
+{| class="wikitable" style="table-layout: fixed; width: 80%; max-width: 1000px;"
 |+'''AUDC# Effect On Sound Content'''
 |- style="vertical-align:top;"
@@ Line 261: / Line 261: @@
 These addresses write data into the audio volume registers which set the pull down impedance driving the audio output pads.
-{| class="wikitable" style="table-layout: fixed; width: 80%; max-width: 640px;"
+{| class="wikitable" style="table-layout: fixed; width: 80%; max-width: 1000px;"
 |+'''AUDV# Effect On Sound Content'''
 |- style="vertical-align:top;"
@@ Line 291: / Line 291: @@
 Port B is read by addressing SWCHB (HEX 282) to determine the status of all the console switches according to the following table:
-{| class="wikitable" style="table-layout: fixed; width: 80%; max-width: 640px;"
+{| class="wikitable" style="table-layout: fixed; width: 80%; max-width: 1000px;"
 |+'''SWCHB Register Bits'''
 |-
@@ Line 479: / Line 479: @@
 All times listed below refer to 7.16 MHz cycles.
-{| class="wikitable" style="width: 80%; max-width: 640px;"
+{| class="wikitable" style="width: 80%; max-width: 1000px;"
 |+'''DMA Timing'''
 ! Event !! MARIA Cycle Cost !! Comments

← Older revision		Revision as of 15:38, 12 July 2026
Line 85:		Line 85:

	Display Lists must be stored in console RAM (or a device capable of similar performance) due to Maria reading Display List bytes with a short 2-cycle window, rather than the 3-cycle window used for reading graphical data.		Display Lists must be stored in console RAM (or a device capable of similar performance) due to Maria reading Display List bytes with a short 2-cycle window, rather than the 3-cycle window used for reading graphical data.
		+
		+	It's an atypical use-case, but it should be noted that Maria is also able to correctly deal with graphic objects that straddle a page boundary.

@@ Line 89: / Line 89: @@
 ====Display List List====
-MARIA locates the Display Lists by reading a Display List List (referred to as DLL from now on). This list is a series of 3 byte entries. Each entry points to a Display List. Included in each entry is a value called OFFSET, which indicates how many rasters should use the specified Display List. OFFSET is decremented at the end of each raster until it becomes negative, which indicates that the next DLL entry should now be read and used. Each time graphics data is to be fetched OFFSET is added to the specified High address byte, to determine the actual address where the data should be found. This allows one display list to specify many rasters of graphics. Without OFFSET the only approach to graphics is to have a Display List for each raster, and a DLL for each Display List. Not only would this use a lot of RAM, but it would also take quite a bit of processing time to manipulate these Display Lists when objects move. Because OFFSET is added to HIGH address byte, each raster of graphics for an object must be separated by x'100' bytes, or one page.
+MARIA locates the Display Lists by reading a Display List List (referred to as DLL from now on). This list is a series of 3 byte entries. Each DLL entry points to a Display List. Included in each entry is a value called OFFSET, which indicates how many rasters should use the specified Display List. OFFSET is decremented at the end of each raster until it becomes negative, which indicates that the next DLL entry should now be read and used.
-The group of rasters specified by one DLL entry is called a "zone." Again, the number of rasters in a zone equals OFFSET+1. Larger zones mean less RAM is needed for DLLs, Display Lists and Character Maps (see DMA MODES below). But upon consideration of how to use zones, you will realize that to achieve smooth vertical motion each stamp must be padded at top and bottom with zeros. For example, if the top raster of an object is to appear on the last line of a 16 high zone, it must have 15
+Each time graphics data is to be fetched OFFSET is added to the specified High address byte, to determine the actual address where the data should be found. This allows one Display List to specify a set of raster graphics. Because OFFSET is added to HIGH address byte, each raster of graphics for an object must be separated by x'100' bytes, or one page.
 lines of zeros above it. If that object is 8 pixels (2 bytes) wide, and its top line of data is located at x'CF04', then you will need two bytes of zeros at x'D004', x'D104', x'D304',..., and x'DE04' (remember that OFFSET decrements). As this can add up to many pages of zeros, you can specify that MARIA should interpret certain data as zeros, even if it isn't. This is called "Holey DMA" because DMA will see "holes" in the data that aren't really there. This can be enabled and disabled on a zone by zone basis via a DLL entry. Holey DMA has been aimed at 8 or 16 raster zones, but will have the same effect for other zone sizes. MARIA can be told to interpret odd 4K blocks as zeros, for 16 high zones, or odd 2K blocks as zeros for 8 high zones. This will only work for addresses above x '8000'. This means that these blocks can hold meaningful code, or tables, or graphics data used in a zone where Holey DMA is not on.
 One of the bits of a DLL entry tells MARIA to generate a Display List Interrupt (DLI) for that zone. The interrupt will actually occur following DMA on the last line of the PREVIOUS zone. This interrupt is non-maskable, and causes the processor to go to the address specified by the NMI vector at x 'FFFA' and x 'FFFB'. This interrupt in no way affects DMA, so processing will still be suspended at the beginning of the next raster.
 The format of a 3 byte DLL entry is as follows:

← Older revision		Revision as of 14:47, 12 July 2026
Line 84:		Line 84:
	Display List data can be located anywhere in address space, and crossing of page boundaries is handled correctly. It should be noted that Maria can't read bytes fast enough during DMA to cross more than one page in any given Display List.		Display List data can be located anywhere in address space, and crossing of page boundaries is handled correctly. It should be noted that Maria can't read bytes fast enough during DMA to cross more than one page in any given Display List.

−	Display Lists must be stored in console RAM (or a device capable of similar performance) due to Maria reading Display List bytes with a short 2-cycle window, rather than the 3-~~cycles~~ used for reading ~~graphics~~.	+	Display Lists must be stored in console RAM (or a device capable of similar performance) due to Maria reading Display List bytes with a short 2-cycle window, rather than the 3-cycle window used for reading graphical data.

@@ Line 82: / Line 82: @@
 Each header is concerned with one graphics item, which can be any width. If ten objects should appear on a scan line, the Display List for that scan line would be ten (10) headers long, followed by two (2) bytes, the first of which is ignored, and the second of which should be zero to end DMA.
-Due to limits of access speed and available DMA time, Display List data can cross only one page boundary. Additionally, Display Lists must be in RAM (or a device capable of similar performance), due to Maria's quick 2-cycle access of Display List bytes.
+Display List data can be located anywhere in address space, and crossing of page boundaries is handled correctly. It should be noted that Maria can't read bytes fast enough during DMA to cross more than one page in any given Display List.
 ====Display List List====

@@ Line 109: / Line 109: @@
   |- style="vertical-align:top;"
   ! byte 1
-  | colspan="8" | High DL Address: DLLs can cross as many page boundaries as desired. A DLL must be stored in RAM, due to required access time.
+  | colspan="8" | High DL Address: DLL data can cross as many page boundaries as desired. A DLL must be stored in RAM, due to required access time.
   |- style="vertical-align:top;"
   ! byte 2