
000000 - 0003ff  Vector Table

000400 - 05ffff  SCM implemented RAM and Graphics

600000 - 17ffff Normally un-implemented on Vme10

180000 - Dfffff VmeBus

E00000 - Efffff Pixel Access RAM

F00000 - F0ffff ROM 

F10000 - F1bfff SCM resources

F1c000 - F1dfff I/O Channel

F1e000 - FFffff VmeBus

It is possible to modify this MAP to optimize or Ensure compatability.

RESERVED

You can add memory to the reserved area from 60000 - 17fffff, using a menu selection. However, some programs may fail to work. CPM 68k for the VME10 tests to auto size the RAM DISK. It may fail if RAM is added to the reserved area. The Disk Resident Diagnostic, SCM.SY fails if onboard memory is 0x100000 or above.

Memory can be added or removed via a menu item. 

The area from 180000 to 200000, looks like two 256k memory boards. The area from 200000 to E00000 looks like six 2mb memory boards.

GRAPHICS

Some VME10s had a bit called IG, located in the SCM Control register CR1, bit 7. So does the emulator.


The IG bit, when set, caused graphics funtions to cease. This would speed up the VME 10 a little bit. The emulator also implements the IG bit. When set, IG speeds up the VMe10 emulator significantly, if using the graphics memory areas as regular ram. The IG bit makes the graphics RAM appear as normal RAM. None of the graphics funtions work. Unlike the real VME10, on the emulator, when the IG bit is cleared, the contents of the graphics RAM is NOT consistant with the display. 

When IG is clear and versados uses the display ram as regular ram, the speed drops to around 25 KIPS. with IG set, speed is 295 KIPS (1400mhz celeron)

Two programs to help alleviate the graphics slow down are provided on the WD01:500 disk image.

IG 0|1 can be used to set (1) or reset (0) the IG bit. It takes a few seconds to change the IG bit, as the system must reconfigure the ram.

GSEG G|D is fast. It simply grabs the memory area from $30000 to $60000 and puts it in a Globally Sharable, Permanent segment in Session &4. (due to a bug in VD4.3, the segment is put into session 4 along with the EMH/LDR program. Normally a Globally Sharable, Permanent segment can exist alone in an unused Session, but 4.3 seems to delete)

To implement the graphics system, four local bitmaps are maintained, along with the System Bitmap (SB) used to display graphics on the KEYBOARD/DISPLAY form (plus a second system BM for persistance). There's a Character Display Bitmap (CDB), a character cursor bitmap(CCB), a Graphics Display Bitmap (GDB) and a Graphics Cursor Bitmap (GCB). Everytime a character is to be displayed, its glyph is copied into the CDB, as the glyph's pixels are placed into the CDB, the pixels are merged with the GDB and the results are placed in the SB. Functions such as IVS, CDIS1,2,3 and GRE0,1,2 are handled in the MERGE. Character attributes are handled when putting a character glyph into the CDB. 

SB = (CDB xor CCB) or (GDB xor GCB)

Each write to the Vertical or Horizontal Graphics Cursor registers cause a Vertical or a horizontal line to be placed in the GCB. Each Write to the 6845 Cursor registers cause a cursor to be drawn in the CCB. The old cursors are removed, and new cursors are drawn. 

If all CDIS bits are set, then (CDB xor CCB) is excluded from the merge.
If all GRE bits are clear, then (GDB xor GCB) is excluded from the merge.

If the Graphics Cursor registers contain a 0 then they are not dispalyed.

NOTE - the Graphics cursor does not display unless at least one Graphics Color is enabled.

Graphics are placed in the GDB by accessing the Pixel Access Ram or by accessing the Display RAM directly. Pixel access masks are handled when the Pixel Access ram is accessed and the results are placed in the GDB and into the Display RAM, then the GDB is merged with the CDB. Writing to the graphics display ram causes the pixels to be placed into the GDB (and merged with the CDB) as well as placed into the Graphics Display RAM.

Every new pixel (whether from Characters/Cursor or from Graphics/Cursor) causes a merge of that pixel.

Normally, only pixels that are involved with the display of a character, or a Pixel are merged, however, when a feature such as a change in resolution, or a change in 6845 raster specs, or a change of the IG bit, the entire SB is updated by merging all pixels in the GDB and the CDB. (800x600)

This is SLOW, VERY SLOW.. do not expect speed out of the graphics display. 

During a full screen re-merge, the periodic timer that generates the time slice interrupt for versados is disabled. This is done to help alleviate the tight ASR situation in the graphics server. This, also, causes the versados tally of ms since midnight to be un-reliable. (actually more un-reliable, since other things also affect the periodic interrupt, causing losses.)

NOTE... the graphics display RAM (memory) is NOT the same as the GDB or CDB... Only if the appropriate enables are in effect, will writes to the Character Display Ram or will the Graphics Display Ram be placed in the CDB or GDB. So, sometimes, a desired effect may not occur. 

For instance, if the IG bit is set, and you write a graphics image to the Display Ram, then clear the IG bit, (the Memory image is NOT in the GDB, and will not appear on the screen..This is done for speed..CHANGED THIS). NOW the emulator will redraw (from RAM) the display when any resolution or graphics enable or disable occurs...This is slower than before, but now acts more like a real VME10.. If you do not intend to use graphics, setting the IG bit will speed up the system significantly (if you are using the Graphics ram as regular ram) because no updates of the GDB will occur. However, even if IG is set, whatever is currently in the GDB will be merged with the CDB, and displayed in the SB. But writes to the RAM will not cause a merge. The merge can be cause by other accesses,such as writting a Character to the Character display ram. Or by changing resolution or enabling. 

You may Set or Reset the IG bit in a menu selection. Normally the IG bit would be handled in software. But, by default it is cleared, so any attempt to use the graphics RAm as regular ram will be super slow. All that merging is done. So, if you dont plan on using the display ram for Graphics, set the IG bit. The IG bit must be set or reset after the BSOD ROM does its initialization, because the BSOD Rom clears the IG bit (as does TenBUG). Apparently Versados IOINIT also clears the IG bit. 

It appears that the Versados graphics server checks for the IG bit and sets it as needed. And then restores it when it terminates.

It appears that the Manuals are a bit vague on how the IVS bit works. The manual implies that the IVS only applies to Characters. Since Graphics are OR'ed with Characters, this causes Graphics to not appear due to the white background when merged. Setting the Menu Item AlternateIVS will cause the IVS bit to apply to both Characters and Graphics. This causes graphics to be shown since the inversion happens after the merge. Default is as the manual implies... Inversion occurs only to the CDB.

The 6845, supports the 3 configurations described in the VME10 reference manual. 80x25 and 80x50 in High resolution, and 80x25 in Low resolution. The emulator is simplified. Memory maps for Hi and Low resolution, are selected by the HiRes bit in CR1, bit 4. Actual, hi res or low res Display of graphics and/or characters, is selected by the Graphics Offset register. 0=low, 0x32=high. 25 or 50 lines is selected by the 6845 Vertical Total register. No other 6845 registers are used. 

 HiRes=1, graphoff=32(hi), VT(r4)=$19  is 25x80  (Display  F17000-F17F9F)
 HiRes=1, graphoff=32(hi), VT(r4)=$32  is 50x80  (Display  F17000-F18F3F)
 HiRes=1, graphoff=0(low), VT(r4)=$19  is 25x80  (Display  F17000-F17F9F)
 HiRes=1, graphoff=0(low), VT(r4)=$32  is 50x80  (Display  F17000-F18F3F)
 HiRes=0, graphoff=0(low), VT(r4)=$19  is 25x80  (Display  F17000-F17F9F)
 HiRes=0, graphoff=0(low), VT(r4)=$32  is 50x80  (Display  F17000-F18F3F)

 HiRes=1, graphoff=32(hi) is 800x600 (G-30000-3EA5F, B-40000-4EA5F, R-50000-5EA5F) (P=E00000-EEA5FF)
 HiRes=1, graphoff=0(low) is 800x300 (G-30000-3F25F, B-40000-4F25F, R-50000-5F25F) (P=E00000-E742FF)
 HiRes=0, graphoff=0(low) is 800x300 (G-48000-4F25F, B-50000-5752F, R-58000-5F52F) (P=E00000-E742FF)

No other values work. (note this was changed between versions 1.0.9 and 1.0.10..now supports 80x50 in low res.. the graphics resolutionm is now independent of the character resolution)

ROM

ROM is swapped at Power On Reset (POR) and unswapped by writting to the Unswap bit in CR1. You may swap/unswap ROM at any time by a menu option. This is for convienence while debugging. Normally (and enforced by the SCM implementation), the unswap can only occur once and the swap only occurs only during POR reset.

When ROM is loaded, the contents are loaded into a Rom Array, MOD 64k, and copied to wherever the ROM is currently located by the swap/unswap bit, then the memory is set to be read only.

When swapped, at POR, memory at 0X000000 is copied to 0Xf00000 which is then marked as R/W, and the Rom Array is copied to 0X000000 and marked as R/O. When Unswapped, by the unswap bit, memory at 0Xf00000 is copied to 0x000000 and marked as R/W, and the Rom Array is copied to 0xF000000 and marked R/O.


RAM

Ram is implemented as a 16 megabyte array, organized as 8 mb of 16 bit words. The CPU accesses this array by calling a memory access routine. This routine does the word and byte accesses to the 8 mb word array. The Debugger can access the array(default - URA 1) or access the array via the CPU's access routine. (URA 0) When the CPU access routines are used by the debugger, messages indicating Bus or Address Errors will occur. 


I/O

The only way to access any IO (devices or graphics ram, display ram, etc) is to access via the CPU's Access routines. The CPU accesses using those routines. The debugger can use the RAM array or the CPU's Access routines. URA 0|1 0=Access Routines; 1=Ram Array


MMU

The MMU is always enabled. The default (initial after reset) loads descriptor 0, ASN=0 with a descriptor that translates logical = physical for all address spaces. This makes it look like the MMU is not used, but it is. 

The emulated MMU contains a non-standard (not in real MMU) Cache. The real MMU checks all descriptors simulataneously and returns a matching descriptor with the lowest descriptor number. The emulator's MMU does a sequential search of all descriptors to find a HIT. This means that without non-standard cache  features, every access requires up to 32 checks per memory access. The emulated MMU has a AST Cache. Each translation HIT causes the descriptor's number to be loaded into the ASTC. During translations, the ASTC is checked first. If a miss in the AST cache, then a regular sequential search occurs. Any Load Descriptor, write to Descriptor SR or any write to the AST causes the AST cache to be flushed. 

This causes the MMU to be more efficient when accessing the same segment multiple times, but does add overhead for some MMU functions. Better to optimize translations than MMU operations.
