a1200   NEWS   APPS   DOCS   ABOUT
a1200
----
a1200
----
Autodocs
 Other:
 SAD
  --Overview--
  ALLOCATE_MEMORY
  CALL_ADDRESS
  FREE_MEMORY
  GET_CONTEXT_FRAME
  NOP
  READ_ARRAY
  READ_BYTE
  READ_LONG
  READ_WORD
  RESET
  RETURN_TO_SYSTEM
  TURN_OFF_SINGLE
  TURN_ON_SINGLE
  WRITE_ARRAY
  WRITE_BYTE
  WRITE_LONG
  WRITE_WORD
Include
GuruMeditation
Docs » Autodocs » SAD » --Overview--
	Simple Amiga Debugging Kernel, known as "SAD"
It is in EXEC starting in V39
-- General description --
The Simple Amiga Debugging Kernel (SAD) is a set of very simple control
routines stored in the Kickstart ROM that would let debuggers control the
Amiga's development enviroment from the outside. These tools would make
it possible to do remote machine development/debugging via just the
on-board serial port.
This set of control routines is very simple and yet completely flexible,
thus making it possible to control the whole machine.
-- Technical Issues --
SAD will make use of the motherboard serial port that exists in all
Amiga systems. The connection via the serial port lets the system be
able to execute SAD without needing any of the system software up and
running. (SAD will play with the serial port directly)
With some minor changes to the Amiga hardware, an NMI-like line could
be hooked up to a pin on the serial port. This would let external
control of the machine and would let the external controller stop the
machine no matter what state it is in. (NMI is that way)
In order to function correctly, SAD requires the some of the EXEC
CPU control functions work and that ExecBase be valid. Beyond that,
SAD does not require the OS to be running.
-- Command Overview --
The basic commands needed to operate SAD are as follows:
Read and Write memory as byte, word, and longword.
Get the register frame address (contains all registers)
JSR to Address
Return to system operation (return from interrupt)
These basic routines will let the system do whatever is needed.
Since the JSR to address and memory read/write routines can be used
to download small sections of code that could be used to do more
complex things, this basic command set is thus flexible enough
to even replace itself.
Caches will automatically be flushed as needed after each write.
(A call to CacheClearU() will be made after the write and before
the command done sequence)
-- Technical Command Descriptions --
Since the communications with SAD is via a serial port, data formats
have been defined for minimum overhead while still giving reasonable data
reliability. SAD will use the serial port at default 9600 baud but the
external tools can change the serial port's data rate if it wishes. It
would need to make sure that it will be able to reconnect. SAD sets
the baud rate to 9600 each time it is entered. However, while within
SAD, a simple command to write a WORD to the SERPER register would
change the baud rate. This will remain in effect until you exit and
re-enter SAD or until you change the register again. (This can be usefull
if you need to transfer a large amount of data)
All commands have a basic format that they will follow. All commands have
both an ACK and a completion message.
Basic command format is:
SENDER: $AF <command byte> [<data bytes as needed by command>]
Receive:
Command ACK: $00 <command byte>
Command Done: $1F <command byte> [<data if needed>]
Waiting: $53 $41 $44 $BF
Waiting when called from Debug(): $53 $41 $44 $3F
Waiting when in dead-end crash: $53 $41 $44 $21
The data sequence will be that SAD will emit a $BF and then wait for a
command. If no command is received within <2> seconds, it will emit $BF
again and loop back. (This is the "heart beat" of SAD) When called from
Debug() and not the NMI hook, SAD will use $3F as the "heart beat"
If SAD does not get a responce after <10> heartbeats, it will return to
the system. (Execute an RTS or RTE as needed) This is to prevent a full
hang. The debugger at the other end can keep SAD happy by sending a
NO-OP command.
All I/O in SAD times out. During the transmition of a command, if
more than 2 seconds pass between bytes of data SAD will time out
and return to the prompt. This is mainly to help make sure that
SAD can never get into an i-loop situation.
-- Data Structure Issues --
While executing in SAD, you may have full access to machine from the CPU
standpoint. However, this could also be a problem. It is important to
understand that when entered via NMI that many system lists may be in
unstable state. (NMI can happen in the middle of the AllocMem routine
or task switch, etc)
Also, since you are doing debugging, it is up to you to determin what
operations can be done and what can not be done. A good example is
that if you want to write a WORD or LONG that the address will need to
be even on 68000 processors. Also, if you read or write memory that does
not exist, you may get a bus error. Following system structures may
require that you check the pointers at each step.
When entered via Debug(), you are now running as a "task" so you will
be able to assume some things about system structures. This means that
you are in supervisor state and that you can assume that the
system is at least not between states. However, remember that since
you are debugging the system, some bad code could cause data structures
to be invalid. Again, standard debugging issues are in play. SAD just
gives you the hooks to do whatever you need.
Note: When SAD prompts with $BF you will be in full disable/forbid
state. When $3F prompting, SAD will only do a Forbid(). It is possible
for you to then disable interrupts as needed. This is done such that it
is possible to "run" the system from SAD when called with Debug().
-- Data Frames and the Registers --
SAD generates a special data frame that can be used to read what
registers contain and to change the contents of the registers.
See the entry for GET_CONTEXT_FRAME for more details
----------------------------------------------------------------------------
-

BUGS

	In V39 EXEC, the WRITE_BYTE command was not connected and this
caused all of the command numbers to be off-by-one. For example,
the READ_WORD command is listed as command $05 but in V39 is $04.
However, the ACK of the commands are still correct.
Also, in V39 EXEC, the READ_WORD command would return the wrong
data.
To determin if you are in V39 or V40 SAD, you can issue a simple
SAD command at the start of the session. By sending a READ_WORD
command, you may either get a READ_WORD (V40) or a READ_LONG (V39)
ACK'ed back. So the data stream for a safe test would be:
Send: $AF $05 $00 $F8 $00 $00 ; Read start of ROM...
Recv: $00 $05 .... You have V40 SAD
Recv: $00 $06 .... You have V39 SAD
Note that you should be ready to read either 2 or 4 bytes of
result depending on the ACK sent by the system.

Comments

Name:
E-mail: Use this if you want a message if you get a response, will not be shown.
Comment:
Select correct short for:

Future Crew

RZR
AYS
CSL
FC

Comments:

$VER: d0.se 1.14 Copyright © 2011-2024 Tobias Geijersson support at d0 dot se