Quarterhorse Addressing Guide

QuarterHorse Command Set (does not include v1.6 updates!) From Moates.net

DescriptionSendReceiveNotes
Request version.'V'+'V'x+y+'Q' (ex. 01+03+'Q')x is typically 1 for QH. Y will vary with firmware revision. A will be an alphanumeric, and will be Q for QuarterHorse. Remember, everything is at 921,600 bps.
    
Write to a QH memory area.'W'+n+MMSB+MSB+LSB+B1+..+Bn+CS'O'MMSB:MSB:LSB is the 3-byte starting address to which the write is to take place, and n is the number of bytes to write (for 256 bytes, n=0). The CS is a checksum (no-carry addition of all preceding bytes). See rules at bottom of this sheet for memory structure, conventions, etc that are QH-specific.
Read from a QH memory area.'R'+n+MMSB+MSB+LSB+CSB1+..+Bn+CSIn the case of the Ostrich, this reads from the bank area that is selected for R/W (think of as the MMSB). In all cases, it returns 'n' bytes B1…Bn starting at emulation address MSB:LSB. For 256 bytes, use n=0.
    
Legacy 'J'+'W' for write'J'+'W'+n+MMSB+MSB+LSB+B1+..+Bn+CS'O'Writes n bytes to location MMSB:MSB:LSB + 40000.
Legacy 'J'+'R' for read'J'+'R'+n+MMSB+MSB+LSB+CSB1+..+Bn+CSReads n bytes from location MMSB:MSB:LSB + 40000.
    
Set up data query formatQ'+x+y(1)+MMSB(1)+MSB(1)+LSB(1)+…+y(x)+MMSB(x)+MSB(x)+LSB(x)+CS'O'This will define the structure of the datalogging/response packet. It must be initiated each time a command other than 'q' is executed or power to the QH is cycled. However, it is persistent through repeated use of 'q'. In this structure:
x=number of memory locations to return values from (max = 126, typically around 10-20 or so)
y(i)=number of bytes to return from location (i). (max = 0 = 256, typically y(i)=1 or 2))
MMSBi:MSBi:LSBi=address for element (i) of packet structure.
Return data using'q'B(1,1)+…+B(x,y(x))+CSThe response to 'q' contains the structured data from the memory locations defined in the most recent 'Q' command.
    
Not yet implemented: Read info back from the EEC-V computer through QH.'J'+'S'+n+MMSB+MSB+LSB+CSB1+..+Bn+CSReads block of data from area of onboard EEC-IV ROM. Valid values of n are 0 to 3.
Not yet implemented: Read info back from the EEC-IV computer through QH.'J'+'4'+CSB1+..+B(256)+CSReads blocks of data 256 bytes at a time from area of onboard EEC-IV ROM. Values will be rendered starting at 2000 (internal offset) and will march forward when you send the BURN1 a 'C' for continuing. When you're done and have 56k worth of info, send a 'Q' to quit.
Not yet implemented: Trace'T'+x1+x2+x3+y1+y2+sMMSB+sMSB+sLSB+eMMSB+eMSB+eLSB+CS'O'+MMSB1+MSB1+LSB+…+MMSBy+MSBy+LSBy+'O' for nonstreaming, repeating 1…y pattern for streamingx1 = subcommand byte
For x1, it is a bitmask.
B0: 0=streaming, 1=not streaming
B1: 0=report all, 1=report only windowed hits
B2: 0=report all, 1=report only nonredundant hits
B3: 0=normal reporting, 1=use the sMMSB:sMSB:sLSB as a trigger address (should have B1=0,B2=1) and report subsequent hits
B4: 0=normal reporting, 1=use the eMMSB:eMSB:eLSB as a trigger for ending address reporting (automated trigger stop)
B5: 0=report addresses as absolute, 1=report addresses relative to start address offset (zero base)
B6-B7: 0=report addresses using all three bytes, 1=use only LSB, 2=use only MSB:LSB, 3=same as 0 (default)
x2,x3 = reserved option bytes for later use
y1 = number of hits to buffer in packet prior to PC side report
y2 = number of packets to report before returning to 'command prompt'
sMMSB:sMSB:sLSB,eMMSB:eMSB:eLSB = inclusive window for selective reporting

Note 1: If any byte is sent from the PC during address hit reporting, a 'hard' interrupt will occur. The present address hit report (if in progress) will be completed, and an 'O' will be reported to the PC to indicate acknowledgement and a return to the ready state.
Note 2: If a 'soft stop' is desired, send a 't' and the in-progress packet report (size defined by y1) will be completed. An accompanying 'O' will also be reported back to the PC to acknowledge the stop execution.

Definitions:
Streaming: Address hits are reported without stopping unless otherwise interrupted as described in Note 1 and Note 2.
Windowed: An area of memory can be specified via start and end addresses within the command structure. If the option bit is set to report only windowed hits, then only memory address hits within the specified range will be reported.
Redundant: If you keep getting the same hit at the same memory location over and over, then that is redundant. If you hit the same spot after hitting other spots, then it is not redundant since it wouldn't be 'sequentially redundant'.
Trigger: When a particular address has been defined as a trigger, then if it is hit, certain actions can be taken. These can include the start or stop of hit reporting.
Buffer Packet: Defined by y1 in terms of size with respect to number of addresses, this is the size of the 'hit collection' that will be gathered on the Ostrich prior to bursting it back to the PC. This enhances the bandwidth so that you can rapidly gather the hits in packet form without being constrained by the bandwidth going back to the PC.
    
    
Memory Structure and Usage   
The QH is structured with two distinct RAMs, RAM1 and RAM2.   

They are set up in parallel so that incremental changes to one can be made while the other is presented to the EEC.

   

Once you've written to one, then you can swap and update the other one so it is available with the fresh info during the next update.

   
Each RAM is 512kbytes in size, addressable from 00000-7FFFF.   

The upper nibble of the highest address byte (MMSB) will determine which memory is being referenced.

   

If upper nibble is 2 (ex. 200000) then RAM2 will be referenced. If upper nibble is 1 (ex. 100000) then RAM1 is accessed.

   

When one RAM is being accessed, the other is used to present information to the target device. This persists until power cycle (default=RAM1 presentation) or access to the other RAM.

   

If upper nibble of 0 is used during writes, then both RAM1 and RAM2 will be written (in that order). If upper nibble of 0 is used during a read, then RAM2 info will be rendered.

   

The lower half of RAM2 is used to shadow a copy of J3-port RAM write events. The upper half is for the alternate/backup ROM info.

   

If RAM1 is being accessed for R/W, then RAM2 will not be available for this (being used for emulation presentation) and no shadowing will occur.

   
    

The switching modes (see below) complicate things, but for Mode 4 position 1, the following holds true and is recommended:

   

- Primary 256k emulation ROM to be placed at 140000-17FFFF, upper half of RAM1, 56k EEC-IV placed at top of that (172000-17FFFF).

   

- Backup/alternate ROM to be placed at 240000-27FFFF, upper half of RAM2.

   

- RAM shadowing will occur from 200000-23FFFF, lower half of RAM2, according to native EEC activity and/or patchcode.

   

- When using the 'J' command, the extra 40000 adder is automatically added, so writes would be specified from 00000-3FFFF and occur from 40000-7FFFF. This is mostly just to support legacy SW to treat QH like a chip.

   
- Switchmode specification is held at 200000-200002 (see below).   

- Some areas can be used as scratchpad memory, but it is important to understand the layout and structure to avoid conflicts.

   
    
Switching Modes and Pseudo-SW Switching   
In memory position 200000, you specify the case (default is 4).   

In memory position 200001 you specify the selection (action depends on selected case, default is 1).

   

If the byte at 200002 is NOT equal to AA then the module will default to case 4 position 1.

   
    
Case 0:   
Turn QH off in terms of ROM presentation   

Essentially returns to stock, but keeps RAM monitoring active over full 4 bank range lower half.

   
    
Case 1:   

EEC-IV, 64k single bank, use BS0/BS3 input as budget 4-position switcher.

   

Banks are rendered based on switch position input from BS0/BS3 consistent with passthrough control.

   

4 banks possible. Upper RAM masking in upper banks is freed up to avoid position-2 issues.

   

Datalogging is kept active only in the 230000-231FFF area, BS0/3 don't affect this.

   
    
Case 2:   
EEC-IV with 8-positions via software.   
In this mode, BS0/BS3 lines are ignored.   

Memory locations follow second byte in QH RAM at location 200001, use R/W commands to manage state (works with case also).

   

Changing the position number will only affect the rendered bank. R/W relative addressing etc remains the same.

   

RAM will remain consistently at the 230000-231FFF area, not shifted with switch position.

   
    
Case 3:   
EEC-V with 2-bank 112/128k, 4-positions via software.   
Cannot use BS0/3 lines as input, they are needed for operation.   

No need to mask out upper RAM of BANK9 of course, still mask upper BANK1.

   

SW selected positions 0,1,2,3 will go to 00-01,02-03,04-05,06-07 MMSB pairings for banks 1,8 respectively

   
RAM access will stay in 200000-21FFFF.   
    
Case 4 (default full presentation):   

EEC-V with 4-bank 0189 across A18=0 and A18=1 (lower and upper) via MMSB selection.

   
Options are 0 or 1.   
RAM access will stay in lower half of RAM2.   
MMSB will have upper bit 2 as the controlling 0 or 1.   

Case 4 with position 1 selected is the same as our base case prior to switching introduction.

   
    
Case 5:   

EEC-IV with 4-position on switch (same as case 1), but default to software-selected location when switch is in position zero (BS03="11) (case 2).

   
    
Notes on emulation:   

Case modes affect presentation of RAM2. It will be presented similarly to that of RAM1 based on options, except the lower half is 'reserved' for RAM scratchpad.

   
Mirroring management done via software.   

Emulation in lower halves of selections for Case2-4 could be problematic. If lower half of RAM1 is selected via selection byte,

   

and emulation occurs and RAM writes have occurred to pseudo-ROM space, then the ROM code in RAM2 could become corrupted.

   

upper Memory will be referenced in the upper RAM2 as in the Case for RAM1. However, It is done with the risk of having corrupted pseudo-ROM space when used in overlap.