This file contains an overview of the Atari runtime system as it comes with the cc65 C compiler. It describes the memory layout, Atari specific header files, available drivers, and any pitfalls specific to that platform.
The Atari runtime support comes in two flavors: atari
and atarixl
.
The atari
target supports all Atari 8-bit computers, the atarixl
only
supports XL type or newer machines (excluding the 600XL).
The atarixl
runtime makes the whole 64K of memory available, with the
exception of the I/O area at $D000 - $D7FF. Since the
atarixl
runtime has some
limitations, it is
recommended to use the atari
target unless lack of memory dictates the
use of the atarixl
target.
Please note that Atari specific functions are just mentioned here, they are described in detail in the separate function reference. Even functions marked as "platform dependent" may be available on more than one platform. Please see the function reference for more information.
The Atari DOS executable file format supports more than one load block (chunk).
The default binary output format generated by the linker for the
Atari target is a machine language program with a standard executable
header (FF FF <load chunk #1> ... <load chunk #n>).
A load chunk has the format [<2 byte start address> <2 bytes end address>
<chunk data>].
A run vector is added to the end of the
file ($02E0 $02E1 <run vector>) and is calculated using
the start
label in crt0.s. (Technically the run vector is also a load chunk,
but is not regarded as such here.)
An atari
program has two load chunks, an atarixl
program has three load
chunks. The load chunks are defined in the linker configuration files. For more
detailed information about the load chunks see the chapter
Technical details. For the discussion here it's
sufficient to know that the first load chunk(s) do preparation work and the
main part of the program is in the last load chunk.
The values determining the size of the main part of the program (the second load
chunk for atari
, the third load chunk for atarixl
) are calculated in
the crt0.s file from the __STARTUP_LOAD__ and __BSS_LOAD__ values.
Be aware of that if you create a custom linker config file and start moving segments around (see section
Reserving a memory area inside the program).
atari
target
The default linker config file assumes that the BASIC ROM is disabled (or the BASIC cartridge unplugged). This gives a usable memory range of [$2000-$BC1F]. The library startup code examines the current memory configuration, which depends on the size of the installed memory and cartridges. It does so by using the value in the MEMTOP ($2E5) variable as highest memory address the program can use. The initial stack pointer, which is the upper bound of memory used by the program, is set to this value, minus an optionally defined __RESERVED_MEMORY__ value.
The default load address of $2000 can be changed by creating a custom linker config file or by using the "--start-addr" cl65 command line argument or the "--start-addr" or "-S" ld65 command line arguments.
Please note that the first load chunk (which checks the available memory) will always be loaded at $2E00, regardless of the specified start address. This address can only be changed by a custom linker config file.
Special locations:
The text screen depends on the installed memory size and cartridges and can be obtained from the SAVMSC variable ($58).
The C runtime stack is located at MEMTOP and grows downwards, regardless of how your linker config file is setup. This accommodates the different memory configurations of the Atari machines, as well as having a cartridge installed. You can override this behaviour by writing your own crt0.s file and linking it to your program (see also Final note).
The C heap is located at the end of the program and grows towards the C runtime stack.
atarixl
target
The startup code rearranges the memory as follows:
atarixl.cfg
file) at the same address as
where it is in ROM ($E000, it can be changed, see
atarixl chargen location). With the character generator at $E000, there are two upper memory
areas available, [$D800-$DFFF] and [$E400-$FFF9].With the default load address of $2400 this gives a usable memory range of [$2400-$CFFF].
Please note that the first load chunk (which checks the system compatibilty and available memory) will always be loaded at $2E00, regardless of the specified start address. This address can only be changed by a custom linker config file.
Special locations:
The text screen depends on the selected load address ($2400 by default), and resides directly before that address, rounded to the next lower page boundary. The screen memory's start address can be obtained from the SAVMSC variable ($58).
The C runtime stack is located at end of the MAIN memory area ($CFFF) and grows downwards.
The C heap is located at the end of the program (end of BSS segment) and grows towards the C runtime stack.
The ld65 linker comes with default config files for the Atari. There
are two targets for the Atari, atari
and atarixl
.
The default config file for atari
is selected with
-t atari
, and the default config file for atarixl
is selected with
-t atarixl
.
The Atari package comes with additional secondary linker config files which
can be used via -t atari -C <configfile>
(for atari
target) or
-t atarixl -C <configfile>
(for atarixl
target).
atari
config files
atari.cfg
)The default configuration is tailored to C programs. It creates files which have a default load address of $2000.
The files generated by this config file include the "system check" load chunk. It can optionally be left out, see Getting rid of the "system check" load chunk.
atari-asm.cfg
This config file aims to give the assembler programmer maximum
flexibility. All program segments (CODE
, DATA
, etc.) are
optional.
By default it creates regular DOS executable files, which have a default
load address of $2E00. It's also possible to generate an image of
just the program data without EXE header, load address, or (auto-)start address.
To you so, you have to define the symbols __AUTOSTART__
and __EXEHDR__
when linking the program. Therefore, to generate a "plain" binary file, pass the
options "-D__AUTOSTART__=1 -D__EXEHDR__=1
" to the linker.
It's also possible to create a non auto-starting program file, by defining
only the __AUTOSTART__
symbol. Such a program has to be run manually
after being loaded by DOS (for example by using the "M" option of DOS 2.5).
Defining only the __EXEHDR__
symbol will create a (useless) file which
doesn't conform to the DOS executable file format (like a "plain" binary file)
but still has the "autostart" load chunk appended.
The sections of the file which the defines refer to (__AUTOSTART__
for
the autostart trailer, __EXEHDR__
for the EXE header and load address)
is left out, keep this in mind.
The values you assign to the two symbols __AUTOSTART__
and __EXEHDR__
don't matter.
atari-asm-xex.cfg
This config file allows writing multi segment binaries easily, without having to write the header explicitly on each segment.
It is similar to the atari-asm.cfg
above, but uses the ATARI (xex) file
format support on LD65 instead of the standard binary output, so it does not
have the __AUTOSTART
nor the __EXEHDR__
symbols.
Note that each MEMORY
area in the configuration file will have it's own
segment in the output file with the correct headers, and you can specify and
init address INITAD) for each memory area.
atari-cart.cfg
This config file can be used to create 8K or 16K cartridges. It's suited both for C and assembly language programs.
By default, an 8K cartridge is generated. To create a 16K cartridge, pass the
size of the cartridge to the linker, like "-D__CARTSIZE__=0x4000
".
The only valid values for __CARTSIZE__
are 0x2000 and 0x4000.
The option byte of the cartridge can be set with the __CARTFLAGS__
value, passed to the linker. The default value is $01, which means
that the cartridge doesn't prevent the booting of DOS.
The option byte will be located at address $BFFD. For more information about its use, see e.g. "Mapping the Atari".
atari-cassette.cfg
This config file can be used to create cassette boot files. It's suited both for C and assembly language programs.
The size of a cassette boot file is restricted to 32K. Larger programs would need to be split in more parts and the parts to be loaded manually.
To write the generated file to a cassette, a utility (w2cas.com
) to run
on an Atari is provided in the util
directory of atari
target dir.
atari-xex.cfg
This config file shows how to write a binary using the ATARI (xex) file format support on LD65, this simplifies the memory areas and allows to add new memory areas easily without writing new headers and trailers.
Note that the default C library includes the system-check chunk, so in this linker configuration we suppress the importing of the header and trailer for this chunk by defining the standard import symbols to a 0 value. For the initialization address of the system-check chunk, the INITAD is set directly in the configuration.
atarixl
config files
atarixl.cfg
)The default configuration is tailored to C programs. It creates files which have a default load address of $2400.
The files generated by this config file include the "system check" load chunk. It can optionally be left out, see Getting rid of the "system check" load chunk.
atarixl-largehimem.cfg
This is the same as the default config file, but it rearranges the
high memory beneath the ROM into one large block. In order for this
config file to work, the runtime library has to be recompiled with a
special define. See the file libsrc/atari/Makefile.inc
in the
source distribution.
The files generated by this config file include the "system check" load chunk. It can optionally be left out, see Getting rid of the "system check" load chunk.
atarixl-xex.cfg
Similar to the atari-xex.cfg
above, this config file shows how to write a
binary using the ATARI (xex) file format support on LD65.
In addition to the suppressing of the system-check headers and trailers, this also suppresses the shadow-ram-preparation headers and trailers, but does this by defining an "UNUSED" memory area that is not written to the output file.
Programs containing Atari specific code may use the atari.h
header file.
This also includes access to operating system locations (e.g. hardware shadow registers) by a structure called
"OS
".
The names are the usual ones you can find in system reference manuals. Example:
...
OS.savmsc = ScreenMemory;
OS.color4 = 14; // white frame
if (OS.stick0 != 15 || OS.ch != 255) // key or stick input?
...
Please note that memory location 762/$2FA is called "char_
" while the orignal name "char
" conflicts with the C keyword.
If you like to use the OS names and locations for the original Atari 800 operating system, please "#define OSA
" before including the
atari.h
header file.
If you like to target the floating point register model of revision 2 machines, put a "#define OS_REV2
" before including atari.h
.
Access to the Basic programming language zero page variables is established by the structure "BASIC
".
The functions and global variable listed below are special for the Atari. See the function reference for declaration and usage.
The following pseudo variables declared in the atari.h
header
file do allow access to hardware located in the address space. Some
variables are structures, accessing the struct fields will access the
chip registers.
GTIA_READ
and GTIA_WRITE
The GTIA_READ
structure allows read access to the GTIA. The
GTIA_WRITE
structure allows write access to the GTIA.
See the _gtia.h
header file located in the include directory
for the declaration of the structure.
POKEY_READ
and POKEY_WRITE
The POKEY_READ
structure allows read access to the POKEY. The
POKEY_WRITE
structure allows write access to the POKEY.
See the _pokey.h
header file located in the include directory
for the declaration of the structure.
ANTIC
The ANTIC
structure allows read access to the ANTIC.
See the _antic.h
header file located in the include directory
for the declaration of the structure.
PIA
The PIA
structure allows read access to the PIA 6520.
See the _pia.h
header file located in the include directory
for the declaration of the structure.
A major feature of the Atari graphics chip "ANTIC" is to process instructions for the display generation. cc65 supports constructing these display lists by offering defines for the instructions. In conjunction with the "void"-variable extension of cc65, display lists can be created quite comfortable:
...
unsigned char ScreenMemory[100];
void DisplayList =
{
DL_BLK8,
DL_BLK8,
DL_BLK8,
DL_LMS(DL_CHR20x8x2),
ScreenMemory,
DL_CHR20x8x2,
DL_CHR20x8x2,
DL_CHR20x8x2,
DL_BLK4,
DL_CHR20x8x2,
DL_JVB,
&DisplayList
};
...
OS.sdlst = &DisplayList;
...
Please inspect the _antic.h
header file to detemine the supported
instruction names. Modifiers on instructions can be nested without need
for an order:
DL_LMS(DL_HSCROL(DL_VSCROL(DL_DLI(DL_MAP80x4x2))))
Please mind that ANTIC has memory alignment requirements for "player
missile graphics"-data, font data, display lists and screen memory. Creation
of a special linker configuration with appropriate aligned segments and
switching to that segment in the c-code is usually neccessary. A more memory
hungry solution consists in using the "posix_memalign()
" function in
conjunction with copying your data to the allocated memory.
The Atari has two representations for characters:
For direct memory access (simplicity and speed) enabling the internal
mapping can be useful. This can be achieved by including the
"atari_screen_charmap.h
" header.
A word of caution: Since the 0x00
character has to be mapped in an
incompatible way to the C-standard, the usage of string functions in
conjunction with internal character mapped strings delivers unexpected
results regarding the string length. The end of strings are detected where
you may not expect them (too early or (much) too late). Internal mapped
strings typically support the "mem...()
" functions.
For assembler sources the macro "scrcode
" from the "atari.mac
"
package delivers the same feature.
You can switch back to the ATASCII mapping by including
"atari_atascii_charmap.h
".
A final note: Since cc65 has currently some difficulties with string merging under different mappings, defining remapped strings works only flawlessly with static array initialization:
#include <atari_screen_charmap.h>
char pcScreenMappingString[] = "Hello Atari!";
#include <atari_atascii_charmap.h>
char pcAtasciiMappingString[] = "Hello Atari!";
delivers correct results, while
#include <atari_screen_charmap.h>
char* pcScreenMappingString = "Hello Atari!";
#include <atari_atascii_charmap.h>
char* pcAtasciiMappingString = "Hello Atari!";
does not.
For direct keyboard scanning in conjunction with e.g. the OS location "CH" (764/$2FC), all keyboard codes are available as defined values on C and assembler side.
Example:
...
while (!kbhit());
switch (OS.ch)
{
case KEY_RETURN:
...
case KEY_SPACE:
...
case KEY_1:
...
}
...
You can find the C defines in the file "atari.h
" or "atari.inc
" for the assembler variant.
The names in the parentheses denote the symbols to be used for static linking of the drivers.
atari | atarixl | screen resolution | display pages |
atr3.tgi (atr3_tgi) | atrx3.tgi (atrx3_tgi) | 40x24x4 (CIO mode 3, ANTIC mode 8) | 1 |
atr4.tgi (atr4_tgi) | atrx4.tgi (atrx4_tgi) | 80x48x2 (CIO mode 4, ANTIC mode 9) | 1 |
atr5.tgi (atr5_tgi) | atrx5.tgi (atrx5_tgi) | 80x48x4 (CIO mode 5, ANTIC mode A) | 1 |
atr6.tgi (atr6_tgi) | atrx6.tgi (atrx6_tgi) | 160x96x2 (CIO mode 6, ANTIC mode B) | 1 |
atr7.tgi (atr7_tgi) | atrx7.tgi (atrx7_tgi) | 160x96x4 (CIO mode 7, ANTIC mode D) | 1 |
atr8.tgi (atr8_tgi) | atrx8.tgi (atrx8_tgi) | 320x192x2 (CIO mode 8, ANTIC mode F) | 1 |
atr8p2.tgi (atr8p2_tgi) | atrx8p2.tgi (atrx8p2_tgi) | 320x192x2 (CIO mode 8, ANTIC mode F) | 2 |
atr9.tgi (atr9_tgi) | atrx9.tgi (atrx9_tgi) | 80x192x16b (CIO mode 9, ANTIC mode F, GTIA mode $40) | 1 |
atr9p2.tgi (atr9p2_tgi) | atrx9p2.tgi (atrx9p2_tgi) | 80x192x16b (CIO mode 9, ANTIC mode F, GTIA mode $40) | 2 |
atr10.tgi (atr10_tgi) | atrx10.tgi (atrx10_tgi) | 80x192x9 (CIO mode 10, ANTIC mode F, GTIA mode $80) | 1 |
atr10p2.tgi (atr10p2_tgi) | atrx10p2.tgi (atrx10p2_tgi) | 80x192x9 (CIO mode 10, ANTIC mode F, GTIA mode $80) | 2 |
atr11.tgi (atr11_tgi) | atrx11.tgi (atrx11_tgi) | 80x192x16h (CIO mode 11, ANTIC mode F, GTIA mode $C0) | 1 |
atr14.tgi (atr14_tgi) | atrx14.tgi (atrx14_tgi) | 160x192x2 (CIO mode 14, ANTIC mode C) | 1 |
atr15.tgi (atr15_tgi) | atrx15.tgi (atrx15_tgi) | 160x192x4 (CIO mode 15, ANTIC mode E) | 1 |
atr15p2.tgi (atr15p2_tgi) | atrx15p2.tgi (atrx15p2_tgi) | 160x192x4 (CIO mode 15, ANTIC mode E) | 2 |
Many graphics modes require more memory than the text screen which is in effect when the program starts up. Therefore the programmer has to tell the program beforehand the memory requirements of the graphics modes the program intends to use.
On the atari
target his can be done by using the __RESERVED_MEMORY__
linker config variable. The number specified there describes the number
of bytes to subtract from the top of available memory as seen from the
runtime library. This memory is then used by the screen buffer.
On the atarixl
target the screen memory resides below the program
load address. In order to reserve memory for a graphics mode, one
simply uses a higher program load address. There are restrictions on
selectable load addresses,
see
Selecting a good program load address.
The numbers for the different graphics modes presented below should only be seen as a rule of thumb. Since the screen buffer memory needs to start at specific boundaries, the numbers depend on the current top of available memory. The following numbers were determined by a BASIC program.
| graphics mode | reserved memory |
| 0 | 1 |
| 1 | 1 |
| 2 | 1 |
| 3 | 1 |
| 4 | 1 |
| 5 | 182 |
| 6 | 1182 |
| 7 | 3198 |
| 8 | 7120 |
| 9 | 7146 |
| 10 | 7146 |
| 11 | 7146 |
| 12 | 162 |
| 13 | 1 |
| 14 | 3278 |
| 15 | 7120 |
| 16 | 1 |
| 17 | 1 |
| 18 | 1 |
| 19 | 1 |
| 20 | 1 |
| 21 | 184 |
| 22 | 1192 |
| 23 | 3208 |
| 24 | 7146 |
| 25 | 7146 |
| 26 | 7146 |
| 27 | 7146 |
| 28 | 162 |
| 29 | 1 |
| 30 | 3304 |
| 31 | 7146 |
The values of "1" are needed because the graphics command crashes if it doesn't have at least one byte available. This seems to be a bug of the Atari ROM code.
Default drivers: atr8.tgi (atr8_tgi)
and atrx8.tgi (atrx8_tgi)
.
Currently there is only one extended memory driver. It manages the second 64K of a 130XE.
atari | atarixl |
atr130.emd (atr130_emd) | atrx130.emd (atrx130_emd)
|
Currently there are two joystick drivers available:
atari | atarixl | description |
atrstd.joy (atrstd_joy) | atrxstd.joy (atrxstd_joy) | Supports up to two/four standard joysticks connected to the joystick ports of the Atari. (Four on the pre-XL systems, two on XL or newer.) |
atrmj8.joy (atrmj8_joy) | atrxmj8.joy (atrxmj8_joy) | Supports up to eight standard joysticks connected to a MultiJoy adapter. |
Default drivers: atrstd.joy (atrstd_joy)
and atrxstd.joy (atrxstd_joy)
.
Currently there are five mouse drivers available:
atari | atarixl | description |
atrjoy.mou (atrjoy_mou) | atrxjoy.mou (atrxjoy_mou) | Supports a mouse emulated by a standard joystick. |
atrst.mou (atrst_mou) | atrxst.mou (atrxst_mou) | Supports an Atari ST mouse. |
atrami.mou (atrami_mou) | atrxami.mou (atrxami_mou) | Supports an Amiga mouse. |
atrtrk.mou (atrtrk_mou) | atrxtrk.mou (atrxtrk_mou) | Supports an Atari trakball. |
atrtt.mou (atrtt_mou) | atrxtt.mou (atrxtt_mou) | Supports an Atari touch tablet. |
All mouse devices connect to joystick port #0.
Default drivers: atrst.mou (atrst_mou)
and atrxst.mou (atrxst_mou)
.
There are two mouse callbacks available.
The "text mode" callbacks (mouse_txt_callbacks
) display the mouse cursor as a "diamond" character
on the standard "GRAPHICS 0" text mode screen. The mouse cursor character can be changed by an
assembly file defining the character by exporting the zeropage symbol mouse_txt_char
.
The default file looks like this:
.export mouse_txt_char : zp = 96 ; 'diamond' screen code
The "P/M" callbacks (mouse_pm_callbacks
) use Player-Missile graphics for the mouse cursor.
The cursor shape can be changed, too, by an assembly file. Here's the default shape definition:
.export mouse_pm_bits
.export mouse_pm_height : zeropage
.export mouse_pm_hotspot_x : zeropage
.export mouse_pm_hotspot_y : zeropage
.rodata
mouse_pm_bits:
.byte %11110000
.byte %11000000
.byte %10100000
.byte %10010000
.byte %10001000
.byte %00000100
.byte %00000010
mouse_pm_height = * - mouse_pm_bits
; hot spot is upper left corner
mouse_pm_hotspot_x = 0
mouse_pm_hotspot_y = 0
mouse_pm_bits
defines the shape of the cursor, mouse_pm_height
defines the number of
bytes in mouse_pm_bits
. mouse_pm_hotspot_x
and mouse_pm_hotspot_y
define the
position in the shape where "the mouse points to". When using this callback page #6 ($600
- $6FF) is used for the P/M graphics data and no P/M graphics can otherwise be used
by the program. The height of the shape (mouse_pm_height
)
must not exceed 32 lines since the callback routines cannot handle more than 32 lines.
The default callbacks definition (mouse_def_callbacks
) is an alias for the "P/M" callbacks.
Currently there is one RS232 driver. It supports up to 9600 baud, requires hardware flow control (RTS/CTS) and uses the R: device (therefore an R: driver needs to be installed). It was tested with the 850 interface module.
atari | atarixl |
atrrdev.ser (atrrdev_ser) | atrxrdev.ser (atrxrdev_ser)
|
Realtime clock
Access to the realtime clock is supported only when running on SpartaDOS-X.
There needs to be a realtime clock driver installed. This is normally the case
in the default installation (CONFIG.SYS) of SpartaDOS-X.
A missing realtime clock driver in SpartaDOS-X is not supported, and the program
may crash when calling the clock_settime()
or clock_gettime()
functions.
The resolution of the realtime clock driver is 1 second.
atarixl target
_sys()
function is not supported.The Atari supports disk drives with either 128 or 256 byte sectors. The first three sectors of any disk are always 128 bytes long though. This is because the system can only boot from 128 bytes sectors.
Therefore the DIO read and write functions transfer only 128 bytes for sectors 1 to 3, regardless of the type of diskette.
The console I/O is speed optimized therefore support for XEP80 hardware or f80.com software is missing. Of course you may use stdio.h functions.
atari
An atari
program contains two load chunks.
atarixl
The atarixl
target banks out the ROM while the program is running in
order to make more memory available to the program.
The screen memory is by default located at the top of available memory, $BFFF if BASIC is not enabled, $9FFF if BASIC is enabled. Therefore, in order to create a largest possible continuous memory area, the screen memory is moved below the program load address. This gives a memory area from <program load addr> to $CFFF.
The startup code installs wrappers for interrupt handlers and ROM routines. When an interrupt or call to a ROM routine happens, the wrappers enable the ROM, call the handler or routine, and disable the ROM again.
The "wrapping" of the ROM routines is done by changing the ROM entry
point symbols in atari.inc
to point to the wrapper functions.
For ROM functions which require input or output buffers, the wrappers copy the data as required to buffers in low memory.
An atarixl
program contains three load chunks.
When setting a graphics mode, the ROM looks at the RAMTOP location. RAMTOP describes the amount of installed memory in pages (RAMTOP is only one byte). The screen memory and display list are placed immediately below RAMTOP.
Now in order to relocate the screen memory to lower memory, the startup code puts a value into RAMTOP which causes the ROM routines to allocate the display memory below the program start address and then it issues a ROM call to setup the regular text mode.
Due to the movement of the screen memory below the program start, there are some load addresses which are sub-optimal because they waste memory or prevent a higher resolution graphics mode from being enabled.
There are restrictions at which addresses screen memory (display buffer and display list) can be placed. The display buffer cannot cross a 4K boundary and a display list cannot cross a 1K boundary.
The startup code takes this into account when moving the screen memory down.
If the program start address (aligned to the next lower page boundary) minus
the screen buffer size would result in a screen buffer which spans a 4K
boundary, the startup code lowers RAMTOP to this 4K boundary.
The size of the screen buffer in text mode is 960 ($3C0) bytes. So, for
example, a selected start address of $2300 would span the 4K boundary
at $2000. The startup code would adjust the RAMTOP value in such way that
the screen memory would be located just below this boundary (at $1C40).
This results in the area [$2000-$22FF] being wasted.
Additionally, the program might fail to load since the lowest address used
by the screen memory could be below MEMLO. (The lowest address used in this
example would be at $1C20, where the display list would allocated.)
These calculations are performed by the startup code (in the first two load chunks), but the startup code only takes the default 40x24 text mode into account. If the program later wants to load TGI drivers which set a more memory consuming graphics mode, the user has to pick a higher load address. Using higher resolution modes there is a restriction in the ROM that it doesn't expect RAMTOP to be at arbitrary values. The Atari memory modules came only in 8K or 16K sizes, so the ROM expects RAMTOP to only have values in 8K steps. Therefore, when using the highest resolution modes the program start address must be at an 8K boundary.
The default atarixl
linker config file (atarixl.cfg
) leaves the
character generator location at the same address where it is in ROM
($E000). This has the disadvatage to split the upper memory into
two parts ([$D800-$DFFF] and
[$E400-$FFF9]). For applications which
require a large continuous upper memory area, an alternative linker
config file (atarixl-largehimem.cfg
) is provided. It relocates the
character generator to $D800, providing a single big upper
memory area at [$DC00-$FFF9].
With the character generator at a different address than in ROM, the routines
which enable and disable the ROM also have to update the chargen pointer.
This code is not enabled by default. In order to enable it,
uncomment the line which sets CHARGEN_RELOC in libsrc/atari/Makefile.inc
and recompile the atarixl
runtime library.
Function keys are mapped to Atari + number key.
Command line arguments can be passed to main()
when the used DOS supports it.
main
is the program name.The runtime for the Atari uses routines marked as .INTERRUPTOR
for
interrupt handlers. Such routines must be written as simple machine language
subroutines and will be called automatically by the VBI handler code
when they are linked into a program. See the discussion of the .CONDES
feature in the
assembler manual.
Please note that on the Atari targets the .INTERRUPTOR
s are being
run in NMI context. The other targets run them in IRQ context.
(This section is primarily applicable to the atari
target, but the
principles apply to atatixl
as well.)
The Atari 130XE maps its additional memory into CPU memory in 16K chunks at address $4000 to $7FFF. One might want to prevent this memory area from being used by cc65. Other reasons to prevent the use of some memory area could be to reserve space for the buffers for display lists and screen memory.
The Atari executable format allows holes inside a program, e.g. one part loads into $2E00 to $3FFF, going below the reserved memory area (assuming a reserved area from $4000 to $7FFF), and another part loads into $8000 to $BC1F.
Each load chunk of the executable starts with a 4 byte header which defines its load address and size. In the following linker config files these headers are named HEADER and SECHDR (for the MEMORY layout), and accordingly NEXEHDR and CHKHDR (for the SEGMENTS layout).
Goal: Create an executable with 2 load chunks which doesn't use the memory area from $4000 to $7FFF. The CODE segment of the program should go below $4000 and the DATA and RODATA segments should go above $7FFF.
The main problem is that the EXE header generated by the cc65 runtime lib is wrong. It defines a single load chunk with the sizes/addresses of the STARTUP, LOWCODE, ONCE, CODE, RODATA, and DATA segments, in fact, the whole user program (we're disregarding the "system check" load chunk here).
The contents of the EXE header come from the EXEHDR and MAINHDR segments.
The EXEHDR segment just contains the $FFFF value which is required
to be the first bytes of the EXE file.
The MAINHDR are defined in in crt0.s. This cannot be changed without
modifying and recompiling the cc65 atari runtime library. Therefore
the original contents of this segment must be discarded and be
replaced by a user created one. This discarding is done by assigning the
MAINHDR segment to the (new introduced) DISCARD memory area. The DISCARD memory area is
thrown away in the new linker config file (written to file "").
We add a new FSTHDR segment for the chunk header of the first chunk.
The user needs to create a customized linker config file which adds new memory areas and segments to hold the new header data for the first load chunk and the header data for the second load chunk. Also an assembly source file needs to be created which defines the contents of the new header data for the two load chunks.
This is an example of a modified cc65 Atari linker configuration file (split.cfg):
SYMBOLS {
__STACKSIZE__: value = $800 type = weak; # 2K stack
__RESERVED_MEMORY__: value = $0000, type = weak;
}
FEATURES {
STARTADDRESS: default = $2E00;
}
MEMORY {
ZP: start = $82, size = $7E, type = rw, define = yes;
HEADER: start = $0000, size = $2, file = %O; # first load chunk
FSTHDR: start = $0000, size = $4, file = %O; # second load chunk
RAMLO: start = %S, size = $4000 - %S, file = %O;
DISCARD: start = $4000, size = $4000, file = "";
SECHDR: start = $0000, size = $4, file = %O; # second load chunk
RAM: start = $8000, size = $3C20, file = %O; # $3C20: matches upper bound $BC1F
}
SEGMENTS {
EXEHDR: load = HEADER, type = ro;
MAINHDR: load = DISCARD, type = ro;
NEXEHDR: load = FSTHDR, type = ro; # first load chunk
STARTUP: load = RAMLO, type = ro, define = yes;
LOWCODE: load = RAMLO, type = ro, define = yes, optional = yes;
ONCE: load = RAMLO, type = ro, optional = yes;
CODE: load = RAMLO, type = ro, define = yes;
CHKHDR: load = SECHDR, type = ro; # second load chunk
RODATA: load = RAM, type = ro, define = yes;
DATA: load = RAM, type = rw, define = yes;
BSS: load = RAM, type = bss, define = yes;
ZEROPAGE: load = ZP, type = zp;
AUTOSTRT: load = RAM, type = ro; # defines program entry point
}
FEATURES {
CONDES: segment = ONCE,
type = constructor,
label = __CONSTRUCTOR_TABLE__,
count = __CONSTRUCTOR_COUNT__;
CONDES: segment = RODATA,
type = destructor,
label = __DESTRUCTOR_TABLE__,
count = __DESTRUCTOR_COUNT__;
}
A new memory area DISCARD was added. It gets loaded with the contents of the (now unused) MAINHDR segment. But the memory area isn't written to the output file. This way the contents of the MAINHDR segment get discarded.
The newly added NEXEHDR segment defines the correct chunk header for the first intended load chunk. It puts the STARTUP, LOWCODE, ONCE, and CODE segments, which are the segments containing only code, into load chunk #1 (RAMLO memory area).
The header for the second load chunk comes from the new CHKHDR segment. It puts the RODATA, DATA, BSS, and ZPSAVE segments into load chunk #2 (RAM memory area).
The contents of the new NEXEHDR and CHKHDR segments come from this file (split.s):
.import __CODE_LOAD__, __BSS_LOAD__, __CODE_SIZE__
.import __DATA_LOAD__, __RODATA_LOAD__, __STARTUP_LOAD__
.segment "NEXEHDR"
.word __STARTUP_LOAD__
.word __CODE_LOAD__ + __CODE_SIZE__ - 1
.segment "CHKHDR"
.word __RODATA_LOAD__
.word __BSS_LOAD__ - 1
Compile with
cl65 -t atari -C split.cfg -o prog.com prog.c split.s
Goal: Put RODATA and DATA into low memory and STARTUP, LOWCODE, ONCE, CODE, BSS, ZPSAVE into high memory (split2.cfg):
SYMBOLS {
__STACKSIZE__: value = $800 type = weak; # 2K stack
__RESERVED_MEMORY__: value = $0000, type = weak;
}
FEATURES {
STARTADDRESS: default = $2E00;
}
MEMORY {
ZP: start = $82, size = $7E, type = rw, define = yes;
HEADER: start = $0000, size = $2, file = %O; # first load chunk
FSTHDR: start = $0000, size = $4, file = %O; # second load chunk
RAMLO: start = %S, size = $4000 - %S, file = %O;
DISCARD: start = $4000, size = $4000, file = "";
SECHDR: start = $0000, size = $4, file = %O; # second load chunk
RAM: start = $8000, size = $3C20, file = %O; # $3C20: matches upper bound $BC1F
}
SEGMENTS {
EXEHDR: load = HEADER, type = ro; # discarded old EXE header
MAINHDR: load = DISCARD, type = ro;
NEXEHDR: load = FSTHDR, type = ro; # first load chunk
RODATA: load = RAMLO, type = ro, define = yes;
DATA: load = RAMLO, type = rw, define = yes;
CHKHDR: load = SECHDR, type = ro; # second load chunk
STARTUP: load = RAM, type = ro, define = yes;
ONCE: load = RAM, type = ro, optional = yes;
CODE: load = RAM, type = ro, define = yes;
BSS: load = RAM, type = bss, define = yes;
ZEROPAGE: load = ZP, type = zp;
AUTOSTRT: load = RAM, type = ro; # defines program entry point
}
FEATURES {
CONDES: segment = ONCE,
type = constructor,
label = __CONSTRUCTOR_TABLE__,
count = __CONSTRUCTOR_COUNT__;
CONDES: segment = RODATA,
type = destructor,
label = __DESTRUCTOR_TABLE__,
count = __DESTRUCTOR_COUNT__;
}
New contents for NEXEHDR and CHKHDR are needed (split2.s):
.import __STARTUP_LOAD__, __BSS_LOAD__, __DATA_SIZE__
.import __DATA_LOAD__, __RODATA_LOAD__
.segment "NEXEHDR"
.word __RODATA_LOAD__
.word __DATA_LOAD__ + __DATA_SIZE__ - 1
.segment "CHKHDR"
.word __STARTUP_LOAD__
.word __BSS_LOAD__ - 1
Compile with
cl65 -t atari -C split2.cfg -o prog.com prog.c split2.s
There are two other memory areas which don't appear directly in the linker config file. They are the stack and the heap.
The cc65 runtime lib places the stack location at the end of available memory. This is dynamically set from the MEMTOP system variable at startup. The heap is located in the area between the end of the BSS segment and the top of the stack as defined by __STACKSIZE__.
If BSS and/or the stack shouldn't stay at the end of the program, some parts of the cc65 runtime lib need to be replaced/modified.
common/_heap.s defines the location of the heap and atari/crt0.s defines the location of the stack by initializing sp.
If you are using a customized linker config file you might get some errors regarding the MAINHDR segment. Like this:
ld65: Error: Missing memory area assignment for segment 'MAINHDR'
The old "HEADER" memory description contained six bytes: $FFFF
and the first and last memory addess of the program. For the "system
check" load chunk this had to be split into two memory assigments. The
"HEADER" now only contains the $FFFF. The main program's first
and last memory address were moved to a new segment, called "MAINHDR",
which in the new linker config file goes into its own memory area (also
called "MAINHDR").
A simple way to adapt your old linker config file is to add the
following line to the "SEGMENTS" section:
MAINHDR: load = HEADER, type = ro;
If, for some reason, you don't want to include the "system check" load
chunk, you can do so by defining the symbol __SYSTEM_CHECK__
when linking the
program. The "system check" chunk doesn't include vital parts of the
program. So if you don't want the system checks, it is save to leave them out.
This is probably mostly interesting for debugging.
When using cl65, you can leave it out with this command line:
cl65 -Wl -D__SYSTEM_CHECK__=1 <arguments>
The value you assign to __SYSTEM_CHECK__
doesn't matter. If the
__SYSTEM_CHECK__
symbol is defined, the load chunk won't be included.
This software is provided 'as-is', without any expressed or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.
Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:


public class DirectedOrderedDfsVertex extends DirectedSimpleColoredVertex implements OrderedDfsVertex
| Modifier and Type | Class and Description |
|---|---|
static class |
DirectedOrderedDfsVertex.Factory |
DEFAULT_DISCOVERY_TIME, DEFAULT_FINISH_TIME, FIRST_DISCOVERY_TIME
DEFAULT_SEARCH_ORDER_VALUE
DEFAULT_COMPONENT, FIRST_COMPONENT_NUMBER
| Constructor and Description |
|---|
DirectedOrderedDfsVertex() |
| Modifier and Type | Method and Description |
|---|---|
int |
getComponent()
Get the number of the component to which the vertex belongs
|
int |
getDiscoveryTime()
Get the vertex's discovery time
|
int |
getFinishTime()
Get the vertex's finish time
|
int |
getSearchOrder()
Get the value of the searchOrder field
|
void |
setComponent(int componentNumber)
Set the number of the component to which the vertex belongs
|
void |
setDiscoveryTime(int discoveryTime)
Set the time at which the vertex was discovered
|
void |
setFinishTime(int finishTime)
Set the time at which the vertex visit was finished
|
void |
setSearchOrder(int searchOrder)
Set the value of the searchOrder field
|
getColor, setColor
addAdjacency, adjacencyCount, clearAdjacencies, containsAdjacency, getAdjacencies, hasAdjacencies, removeAdjacency
equals, getGraph, setGraph
clone, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
getColor, setColor
addAdjacency, adjacencyCount, clearAdjacencies, containsAdjacency, getAdjacencies, getGraph, hasAdjacencies, removeAdjacency, setGraph
public void setDiscoveryTime(int discoveryTime)
VisitedVertex
setDiscoveryTime
in interface VisitedVertex
discoveryTime
- value to which to set the discovery timepublic void setFinishTime(int finishTime)
VisitedVertex
setFinishTime
in interface VisitedVertex
finishTime
- value to which to set the finish timepublic int getDiscoveryTime()
VisitedVertex
getDiscoveryTime
in interface VisitedVertex
public int getFinishTime()
VisitedVertex
getFinishTime
in interface VisitedVertex
public void setSearchOrder(int searchOrder)
OrderedSearchVertex
setSearchOrder
in interface OrderedSearchVertex
searchOrder
- value to which to set the searchOrder fieldpublic int getSearchOrder()
OrderedSearchVertex
getSearchOrder
in interface OrderedSearchVertex
public void setComponent(int componentNumber)
ComponentVertex
setComponent
in interface ComponentVertex
componentNumber
- value to which to set the component numberpublic int getComponent()
ComponentVertex
getComponent
in interface ComponentVertex


preparing-data.Rmd
Examples in the rstickleback
documentation rely on the
load_lunges()
helper function to provide data in a
processed format. Though convenient, load_lunges()
doesn’t
help users understand how to prepare their own data. This vignette
demonstrates the steps necessary to convert files in a directory to
rstickleback
-friendly objects. Your data won’t be in the
same directory structure or follow the same naming conventions as these
sample data, but hopefully this vignette gets you started in the right
direction.
# Start by loading a few packages, including rstickleback
library(fs)
library(lubridate)
library(rstickleback)
library(tidyverse)
#> Warning: package 'readr' was built under R version 4.0.5
The bluewhaledata
repository on GitHub has a zipped archive with the same sample data as
this package, only in CSV form. The archive contains two directories,
sensors and events, with CSV files containing bio-logging sensor data
and behavioral event timestamps, respectively. For more details about
how the data were collected and what they represent, see
load_lunges()
.
You can download the data directly in R.
# Create a temporary directory
temp_dir <- tempdir()
# Download file and unzip data
url <- "https://github.com/FlukeAndFeather/bluewhaledata/raw/master/bluewhaledata.zip"
download.file(url, file.path(temp_dir, "bluewhaledata.zip"))
unzip(file.path(temp_dir, "bluewhaledata.zip"), exdir = temp_dir)
Each CSV file is named according to the deployment identifier and data type (event or sensor).
data_dir <- file.path(temp_dir, "data")
# Note: your root folder won't match exactly. It's a random path, generated by
# tempdir().
dir_tree(data_dir)
#> /var/folders/x2/pd2b41ls033f6_p4h4h37k880000gn/T//Rtmpc8BTUv/data
#> ├── events
#> │ ├── bw180904-44_events.csv
#> │ ├── bw180904-48_events.csv
#> │ ├── bw180904-52_events.csv
#> │ ├── bw180905-42_events.csv
#> │ ├── bw180905-49_events.csv
#> │ └── bw180905-53_events.csv
#> └── sensors
#> ├── bw180904-44_sensors.csv
#> ├── bw180904-48_sensors.csv
#> ├── bw180904-52_sensors.csv
#> ├── bw180905-42_sensors.csv
#> ├── bw180905-49_sensors.csv
#> └── bw180905-53_sensors.csv
Inspecting the event and sensor data for the first deployment
(identifier bw180904-44), we see that event CSV files have one datetime
column, lunge
, and sensor CSV files have five columns. In
the sensor data, the timestamp_utc
datetime column is the
time and the other four columns (depth
, pitch
,
roll
, and speed
) describe the animal’s
movement.
sample_events <- read_csv(file.path(data_dir, "events", "bw180904-44_events.csv"))
#> Rows: 40 Columns: 1
#> ── Column specification ────────────────────────────────────────────────────────
#> Delimiter: ","
#> dttm (1): lunge
#>
#> ℹ Use `spec()` to retrieve the full column specification for this data.
#> ℹ Specify the column types or set `show_col_types = FALSE` to quiet this message.
glimpse(sample_events)
#> Rows: 40
#> Columns: 1
#> $ lunge <dttm> 2018-09-04 10:52:19, 2018-09-04 10:54:15, 2018-09-04 10:56:08, …
sample_sensors <- read_csv(file.path(data_dir, "sensors", "bw180904-44_sensors.csv"))
#> Rows: 72000 Columns: 5
#> ── Column specification ────────────────────────────────────────────────────────
#> Delimiter: ","
#> dbl (4): depth, pitch, roll, speed
#> dttm (1): timestamp_utc
#>
#> ℹ Use `spec()` to retrieve the full column specification for this data.
#> ℹ Specify the column types or set `show_col_types = FALSE` to quiet this message.
glimpse(sample_sensors)
#> Rows: 72,000
#> Columns: 5
#> $ timestamp_utc <dttm> 2018-09-04 10:47:16, 2018-09-04 10:47:16, 2018-09-04 10…
#> $ depth <dbl> 0.3480302, 0.3534735, 0.3587432, 0.3638423, 0.3683940, 0…
#> $ pitch <dbl> -0.276757371, -0.253706385, -0.232672562, -0.212183548, …
#> $ roll <dbl> 0.34689666, 0.29694713, 0.24615438, 0.19446428, 0.141366…
#> $ speed <dbl> 6.297395, 6.110192, 5.890096, 5.673690, 5.456957, 5.2420…
To prepare these data for use in rstickleback
, we have
to combine all the CSVs into two data frames; one each for events and
sensors. Here is one way of doing that using a for-loop, which is likely
familiar to most readers. I demonstrate a more elegant solution
later.
# A list of the deployment ids
deployids = c("bw180904-44",
"bw180904-48",
"bw180904-52",
"bw180905-42",
"bw180905-49",
"bw180905-53")
# Create empty data frames to hold the results
bw_events_df <- data.frame()
bw_sensors_df <- data.frame()
# Iterate through the deployment ids, read the data, and append to the results
for (id in deployids) {
# Event data first...
event_path <- dir(file.path(data_dir, "events"),
pattern = id,
full.names = TRUE)
events <- read_csv(event_path, col_types = "T") %>%
# I happen to know dates are in UTC. Metadata are important!
mutate(lunge = force_tz(lunge, "UTC"),
deployid = id)
bw_events_df <- rbind(bw_events_df, events)
# ...then sensor data
sensor_path <- dir(file.path(data_dir, "sensors"),
pattern = id,
full.names = TRUE)
# Specifying the column types with the `col_types` parameter suppresses a lot
# of extraneous messages about column parsing.
sensors <- read_csv(sensor_path, col_types = "Tdddd") %>%
mutate(timestamp_utc = force_tz(timestamp_utc, "UTC"),
deployid = id)
bw_sensors_df <- rbind(bw_sensors_df, sensors)
}
# The results
glimpse(bw_events_df)
#> Rows: 218
#> Columns: 2
#> $ lunge <dttm> 2018-09-04 10:52:19, 2018-09-04 10:54:15, 2018-09-04 10:56:0…
#> $ deployid <chr> "bw180904-44", "bw180904-44", "bw180904-44", "bw180904-44", "…
glimpse(bw_sensors_df)
#> Rows: 416,046
#> Columns: 6
#> $ timestamp_utc <dttm> 2018-09-04 10:47:16, 2018-09-04 10:47:16, 2018-09-04 10…
#> $ depth <dbl> 0.3480302, 0.3534735, 0.3587432, 0.3638423, 0.3683940, 0…
#> $ pitch <dbl> -0.276757371, -0.253706385, -0.232672562, -0.212183548, …
#> $ roll <dbl> 0.34689666, 0.29694713, 0.24615438, 0.19446428, 0.141366…
#> $ speed <dbl> 6.297395, 6.110192, 5.890096, 5.673690, 5.456957, 5.2420…
#> $ deployid <chr> "bw180904-44", "bw180904-44", "bw180904-44", "bw180904-4…
rstickleback
-friendly objects
We now have two data frames containing all the event and sensor data
for these six deployments, which we can use to create Event
and Sensor
objects for use with
rstickleback
.
bw_events <- Events(bw_events_df,
deployid_col = "deployid",
datetime_col = "lunge")
bw_sensors <- Sensors(bw_sensors_df,
deployid_col = "deployid",
datetime_col = "timestamp_utc",
sensor_cols = c("depth", "pitch", "roll", "speed"))
bw_events
#> Events
#> 6 deployments.
#> With 218 events.
bw_sensors
#> Sensors
#> 6 deployments.
#> With column(s): depth, pitch, roll, speed
These data are now ready to use with rstickleback
functions. For example, you can visualize the event and sensor data with
sb_plot_data()
and train a model using
sb_fit()
.
As a final note, here’s the more elegant way to read an entire
directory of CSVs using regular expressions to extract the deployment
identifier from the file name. Note: this only works if your version of
readr
is at least 2.0.0.
event_csvs <- dir(file.path(data_dir, "events"), full.names = TRUE)
bw_events_df2 <- read_csv(event_csvs, col_types = "T", id = "file_name") %>%
mutate(deployid = str_extract(file_name, "bw[0-9]{6}-[0-9]{2}"))
sensor_csvs <- dir(file.path(data_dir, "sensors"), full.names = TRUE)
bw_sensors_df2 <- read_csv(sensor_csvs, col_types = "T", id = "file_name") %>%
mutate(deployid = str_extract(file_name, "bw[0-9]{6}-[0-9]{2}"))
These data frames are functionally equivalent to those made with the
for-loop, and work just as well with rstickleback
functions.
bw_events2 <- Events(bw_events_df2,
deployid_col = "deployid",
datetime_col = "lunge")
bw_sensors2 <- Sensors(bw_sensors_df2,
deployid_col = "deployid",
datetime_col = "timestamp_utc",
sensor_cols = c("depth", "pitch", "roll", "speed"))
bw_events2
#> Events
#> 6 deployments.
#> With 218 events.
bw_sensors2
#> Sensors
#> 6 deployments.
#> With column(s): depth, pitch, roll, speed


Im a programmer based in Viborg, Denmark. Who loves innovative, creative and unique game projects.
I also enjoy create mobile apps, work with web development, data mining and teaching.
 I am always up for Age of Empires 2! But right now I'm into finishing The Last of Us remastered edition and Call of Duty WWII.
To an English person, it will seem like simplified English,told me what
To an English person, it will seem like simplified English,told me what
To an English person, it will seem like simplified English,told me what
To an English person, it will seem like simplified English,told me what
To an English person, it will seem like simplified English,told me what
My Portfolio
GET IN TOUCH
- Sct. Moges Gade 39A 1st.
- Viborg, 8800
- Denmark
- +45 50 17 48 52
- fefragoso@gmail.com


{{ serviceName }}
Prototypes
Consent & Data Sharing
Mid-ESA applicationAsking for consent to get the patients sick note directly from the NHS in the middle of the existing digital ESA claim form. |
|
Consent managementExploring a management service showing user consents for sharing data across Govt departments. Launch prototype |
|
Ongoing consentSimple flow offering an "ongoing consent" question at the end allowing us to test users reactions to and understanding of this. |
|
Your doctor's notes - NHSFirst attempt at a NHS-centric experience. Allowing users to see all their sick notes and allowing them to share them with DWP individually. |
Send your doctor’s note to DWP - v3Opposite to V1. Asking for a lot of extra information to test what people's reaction is to having to give this as part of the process. The Yes/No questions around NHS number and NI number in particular are focussed on gathering users reactions rather than representing a realistic experience. |
Send your doctor’s note to DWP - v2Introduces Verify as an identity step and shows the user their sick note for them to confirm it's correct before "sending". |
|
Send your doctor’s note to DWP - v1A deliberately unrealistically simple version to test our assumption that users expect us to share data with almost no interaction or oversight from them. |
Send your fit note
Prototype versions of a service allowing users to send their fit note to DWP using a phone, tablet or computer.
Send your fit note: demoA demo version that reflects the live service |
Send your fit note: beta 7Changes to this version (to test in user research):
User research:To follow |
Send your fit note: beta 6Changes in this version:
User research:Lab research findings 19 Mar 2018 |
Send your fit note: beta 5Changes in this version:
User research:Lab research findings 27 Feb 2018 |
Send your fit note: beta 4Changes in this version:
User research:Lab research findings 13 Feb 2018 |
Send your fit note: beta 3Changes in this version:
User research:Research findings Dec 2017 |
Send your fit note: beta 2Changes in this version:
User research:Research findings 29 Nov 2017 |
Send your fit note: beta 1Added first design of a journey for desktop or laptop users. |
Send your sick noteA prototype of a service allowing users to send their sick note to DWP by which ever method they like. |
Send a photo of your sick noteA prototype of the service allowing users to send their sick note to DWP by taking a picture of it on their phone. |
Edit these files on GitHub.


Analysis
{% include "console/pages/analysis/analyses_table.html" %}
{% include "console/pages/instruments/instruments_table.html" %}
{% extends "console/console.html" %}
{% block console_body %}
{% comment %} Analysis
{% endcomment %}
{% include "console/pages/analysis/extractions_table.html" %}
{% include "console/pages/analysis/calculations_table.html" %}
{% include "console/pages/analysis/analyses_table.html" %}
{% include "console/pages/instruments/instruments_table.html" %}


< return to staff Education
|
|
| Biography | |
|
Brandi Ransom, from Spring, Texas, is pursuing a PhD in
materials science and engineering at Stanford School of
Engineering. Prior to Grad School, at Rice University, she
earned bachelor’s degrees in materials science and
nanoengineering and German studies while competing as a NCAA
Division I Track & Field athlete. Needless to say, she has
exceptional time-management. She was originally trained as an
experimentalist specifically in 2D material growth and solar
cell assembly, however, the hype of hard drives and softwares
enticed her over to the ergonomically unfavorable computation
side of materials engineering. It started off small, an
optimization of polymer extrusion based in excel, then
a python package she adapted to predict tumor growth, and she
was knee deep when she reached her senior project on
data-driven development of a new super alloy. Because of these
exceptional experiences that have trained her to be a master
in synergizing machine learning and modeling with general
science, she aids the Reed group in identifying new materials
for solid Lithium electrolytes. Outside of her main work, her
subsequent acceptance into the pioneer cohort of the
Knight-Henessey Scholars will also allow her to pursue her
passion of optimizing fiber manufacturing processes.
She also enjoys baking the best darn-tootin' cookies you will ever taste and eat, and hydrating.
Brandi decided to be a Materials Scientist when she was 11 years old, and that 11 year old is very proud of the woman she has grown into.
|


Qpid Proton 0.14.0 Release Notes
Proton is a high-performance, lightweight messaging library. More
about Qpid Proton.
For more information about this release, including download links and
documentation, see the release overview.
New features and improvements
- PROTON-1164 - Update handlers to align with current proposal
- PROTON-1179 - [C++ binding] Rework condition class
- PROTON-1205 - c++: Replace default arguments with multiple overloads in container API
- PROTON-1214 - Implement a common machinery for caching property maps.
- PROTON-1215 - Move codec::data class to internal namespace
- PROTON-1229 - Document and test virtual_host option
- PROTON-1232 - Improve implementation of default_container
- PROTON-1237 - C connection_engine interface and libuv example driver.
- PROTON-1244 - Add user & password connection_options
- PROTON-1252 - Improve the error reporting for errors generated by Cyrus SASL
- PROTON-1263 - c++ add proton::to_string for value and scalar types
- PROTON-1267 - Service Bus example
- PROTON-1269 - Add remaining handlers
- PROTON-1270 - Add extra convenience overloads for container::open_sender & container::open_receiver
Bugs fixed
- PROTON-1165 - qpid proton cpp binding posix/io.cpp tests wrong error condition
- PROTON-1199 - A soft link within the Go subdirectory causes fatal sandbox errors
- PROTON-1220 - C examples builds without enabling warnings
- PROTON-1221 - c++: new container interface lacks scheduled timer events
- PROTON-1222 - Some bugs spotted by coverity
- PROTON-1223 - Windows connection errors are cryptic.
- PROTON-1230 - cpp_container_example_test fails due to /etc/sasl2/proton-server.conf configuration
- PROTON-1231 - python: proton.utils.BlockingConnection hides disconnect error info
- PROTON-1239 - There is no way to query proton::connection for user
- PROTON-1240 - proton::connection::virtual_host not filled in on server side.
- PROTON-1241 - proton::messaging_handler is not copyable (because it contains a pn_unique_ptr)
- PROTON-1243 - Calling proton::container::stop() from within event handler causes infinite recursion
- PROTON-1246 - Compile without warnings under clang++ 3.8
- PROTON-1256 - Proton-c is very lax about allowing amqp and ssl protocol layers
- PROTON-1257 - c++ cached_map core dump on assignment
- PROTON-1258 - No transport_close event is generated on the listening side of the connection
- PROTON-1265 - Testing with python 3 is broken
- PROTON-1268 - When running tox tests directly, there are unnecessary failures
- PROTON-1272 - C++ examples test won't run on Python 2.6
- PROTON-1279 - Build of C++ binding fails on FreeBSD because of unreachable code warning
- PROTON-1280 - Messenger python tests fail on FreeBSD because of bad assumption
- PROTON-1281 - Odd link error when optimisation level is -O2 or -O3 when compiling with libc++ (clang C++ library)
Apache Qpid, Messaging built on AMQP; Copyright © 2015
The Apache Software Foundation; Licensed under
the Apache
License, Version 2.0; Apache Qpid, Qpid, Qpid Proton,
Proton, Apache, the Apache feather logo, and the Apache Qpid
project logo are trademarks of The Apache Software
Foundation; All other marks mentioned may be trademarks or
registered trademarks of their respective owners


DataMed is a proof-of-concept project that improves upon simple keyword search for medical documents.
To search, simply start typing a medical concept of interest into the search box.
In order to achieve our results, we normalized case presentation data found in published case studies from the Journal of Medical Case Reports. This allows a user searching for "heart attack", "myocardial infarction", and "MI" to all get the same results.
In addition, we have clustered the document concepts by category and offered these as further concepts to enhance your search.
DataMed was produced as a part of Prebacked's MedHack SF Summer 2014.
Team
Paul Alexander
Prag Batra
Nicole Lim
Manuel Salvadores


ARCH(1) User Commands ARCH(1) NAME arch - print machine hardware name (same as uname -m) SYNOPSIS arch [OPTION]... DESCRIPTION Print machine architecture. --help display this help and exit --version output version information and exit AUTHOR Written by David MacKenzie and Karel Zak. REPORTING BUGS Report arch bugs to<EMAIL_ADDRESS>GNU coreutils home page: <http://www.gnu.org/software/coreutils/> General help using GNU software: <http://www.gnu.org/gethelp/> Report arch translation bugs to <http://translationproject.org/team/> COPYRIGHT Copyright © 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. SEE ALSO uname(1), uname(2) The full documentation for arch is maintained as a Texinfo manual. If the info and arch programs are properly installed at your site, the com‐ mand info coreutils 'arch invocation' should give you access to the complete manual. GNU coreutils 8.13 September 2011 ARCH(1)


Page maintained by Ke-Sen Huang.
If you have additions or changes, send an e-mail.
Information here is provided with the permission of the ACM.
Note that when possible I link to the page containing the link to the actual PDF or PS of the preprint.
I prefer this as it gives some context to the paper and avoids possible copyright problems with direct linking.
Thus you may need to search on the page to find the actual document.
ACM Digital Library: Proceedings of the 2012 ACM SIGGRAPH/Eurographics Symposium on Computer Animation
Eurographics Digital Library: Proceedings of the 2012 ACM SIGGRAPH/Eurographics Symposium on Computer Animation
the ACM Digital Library (DOI) Link for the paper
the Eurographics Digital Library Link for the paper
Paper Abstract
Author Preprint
Paper Video
Paper Presentation
Paper Images
Paper Data
Demo Program or Source Code
Related Links
Changelog
Deformation
- Efficient Simulation of Example-Based Materials
-
Christian Schuhmacher,
Bernhard Thomaszewski,
Stelian Coros,
Martin Sebastian,
Robert Sumner,
Markus Gross
- Enriching Virtual Elastic Objects with High-Resolution Data-Driven Deformations
-
Martin Seiler,
Jonas Spillmann,
Matthias Harders
- Energy Conservation for the Simulation of Deformable Bodies (TVCG Paper)
IEEE TVCG Link
-
Jonathan Su,
Rahul Sheth,
Ron Fedkiw
- Energetically Consistent Invertible Elasticity
-
Alexey Stomakhin,
Joseph Teran,
Craig Schroeder,
Russell Howes
Hands, Performance, and Cameras
- Combining Marker-based Mocap and RGB-D Camera for Acquiring High Quality Hand Motion Data
-
Jinxiang Chai,
Wenping Zhao,
Ying-Qing Xu
- Finger Walking: Motion Editing with Contact-Based Hand Performance
-
Noah Lockwood,
Karan Singh
- Interactive Steering of Mesh Animations (short presentation)
-
Anna Vogele,
Max Hermann,
Bjorn Kruger,
Reinhard Klein
Fluid Simulation
- Smoke Sheets for Graph-Structured Vortex Filaments
-
Alfred Barnat,
Nancy Pollard
- Linear-Time Smoke Animation with Vortex Sheet Meshes
-
Tyson Brochu,
Todd Keeler,
Robert Bridson
- Multiphase flow of immiscible fluids on unstructured moving meshes
-
Marek Krzysztof Misztal,
Kenny Erleben,
Adam Bargteil,
Jens Fursund,
Brian Bunch Christensen,
Andreas Baerentzen,
Robert Bridson
- Simulating Free Surface Flow with Very Large Time Steps
-
Michael Lentine,
Matthew Cong,
Saket Patkar,
Ron Fedkiw
Character Animation
- Tiling Motion Patches
-
Manmyung Kim,
Youngseok Hwang,
Kyunglyul Hyun,
Jehee Lee
- Contact-Invariant Optimization for Hand Manipulation
-
Igor Mordatch,
Zoran Popovic,
Emanuel Todorov
- Learning Motion Controllers with Adaptive Depth Perception
-
Wan-Yen Lo,
Matthias Zwicker
- Task-driven Posture Optimization for Virtual Characters
-
Mingxing Liu,
Alain Micaelli,
Paul Evrard,
Adrien Escande
Characters and Crowds
- Component-based Locomotion Composition
-
Yejin Kim,
Michael Neff
- Evaluating the Plausibility of Edited Throwing Animations
-
Michele Vicovaro,
Ludovic Hoyet,
Luigi Burigana,
Carol O'Sullivan
- Quaternion Space Spare Decomposition for Motion Compression and Retrieval
-
Zhigang Deng,
Mingyang Zhu,
Huaijiang Sun
- Environment-aware Real-Time Crowd Control
()
(
)
-
Joseph Henry,
Hubert P. H. Shum,
Taku Komura
- Cloning Crowd Motions
-
Yi Li,
Marc Christie,
Orianne Siret,
Richard Kulpa,
Julien Pettre
Physics-Based Characters
- Simple Data-Driven Control for Simulated Bipeds
-
Thomas Geijtenbeek,
Nicolas Pronost,
A. F. van der Stappen
- Physically Plausible Simulation for Character Animation
-
Sergey Levine,
Jovan Popovic
- Principal Geodesic Dynamics
-
Maxime Tournier,
Lionel Reveret
Sound, Speech, and Fluids
- Mass-Conserving Eulerian Liquid Simulation
-
Nuttapong Chentanez,
Matthias Mueller
- Controlling Liquids Using Meshes
-
Karthik Raveendran,
Chris Wojtan,
Nils Thuerey,
Greg Turk
- Faster Acceleration Noise for Multibody Animations using Precomputed Soundbanks
-
Jeffrey Chadwick,
Changxi Zheng,
Doug L. James
- Dynamic Units of Visual Speech
-
Sarah Taylor,
Moshe Mahler,
Iain Matthews,
Barry-John Theobald
Cloth, Hair, and Collision
- Efficient Collision Detection for Brittle Fracture
-
Loeiz Glondu,
Sara C. Schvartzman,
Maud Marchal,
Georges Dumont,
Miguel A. Otaduy
- Multi-linear Data-Driven Dynamic Hair Model with Efficient Hair-Body Collision Handling
-
Peng Guan,
Leonid Sigal,
Valeria Reznitskaya,
Jessica Hodgins
- Long Range Attachments - A Method to Simulate Inextensible Clothing in Computer Games (short presentation)
-
Tae-Yong Kim,
Matthias Mueller,
Nuttapong Chentanez
- Animating Wrinkles by Example on Non-Skinned Cloth (TVCG Paper)
IEEE TVCG Link
-
Javier S. Zurdo,
Juan P. Brito,
Miguel A. Otaduy
kesen.huang@gmail.com


Background
Given present circumstances in in the world, I thought it might be nice to write a post on a lighter subject.
Recently, I came across an interesting Kaggle dataset that features the power levels of Dragon Ball characters at different points in the franchise. Whilst the dataset itself is quite simple with only four columns (Character
, Power_Level
, Saga_or_Movie
, Dragon_Ball_Series
), I noticed that you do need to do a fair amount of data and string manipulation before you can perform any meaningful data analysis with it. Therefore, if you’re a fan of Dragon Ball and interested in learning about string manipulation in R, this post is definitely for you!
For those who aren’t as interested in Dragon Ball but still interested in general R tricks, please do read ahead anyway - you won’t need to understand the references to know what’s going on with the code. But you have been warned for spoilers! 😂
Functions or techniques that are covered in this post:
- Basic regular expression (regex) matching
stringr::str_detect()
stringr::str_remove_all()
orstringr::str_remove()
dplyr::anti_join()
- Example of ‘dark mode’ ggplot in themes
Getting started
You can download the dataset from Kaggle, which you’ll need to register an account in order to do so. I would highly recommend doing so if you still haven’t, since they’ve got tons of datasets available on the website which you can practise on.
The next thing I’ll do is to set up my R working directory in this style, and ensure that the dataset is saved in the datasets subfolder. I’ll use the {here} workflow for this example, which is generally good practice as here::here
implicitly sets the path root to the path to the top-level of they current project.
Let’s load our packages and explore the data using glimpse()
:
library(tidyverse)
library(here)
dball_data <- read_csv(here("datasets", "Dragon_Ball_Data_Set.csv"))
dball_data %>% glimpse()
## Observations: 1,244
## Variables: 4
## $ Character <chr> "Goku", "Bulma", "Bear Thief", "Master Roshi", "...
## $ Power_Level <chr> "10", "1.5", "7", "30", "5", "8.5", "4", "8", "2...
## $ Saga_or_Movie <chr> "Emperor Pilaf Saga", "Emperor Pilaf Saga", "Emp...
## $ Dragon_Ball_Series <chr> "Dragon Ball", "Dragon Ball", "Dragon Ball", "Dr...
…and also tail()
to view the last five rows of the data, just so we get a more comprehensive picture of what some of the other observations in the data look like:
## # A tibble: 6 x 4
## Character Power_Level Saga_or_Movie Dragon_Ball_Seri~
## <chr> <chr> <chr> <chr>
## 1 Goku (base with SSJG ~ 448,000,000,000 Movie 14: Battle o~ Dragon Ball Z
## 2 Goku (MSSJ with SSJG'~ 22,400,000,000,0~ Movie 14: Battle o~ Dragon Ball Z
## 3 Goku (SSJG) 224,000,000,000,~ Movie 14: Battle o~ Dragon Ball Z
## 4 Goku 44,800,000,000 Movie 14: Battle o~ Dragon Ball Z
## 5 Beerus (full power, n~ 896,000,000,000,~ Movie 14: Battle o~ Dragon Ball Z
## 6 Whis (full power, nev~ 4,480,000,000,00~ Movie 14: Battle o~ Dragon Ball Z
Who does the strongest Kamehameha? 🔥
In the Dragon Ball series, there is an energy attack called Kamehameha, which is a signature (and perhaps the most well recognised) move by the main character Goku. This move is however not unique to him, and has also been used by other characters in the series, including his son Gohan and his master Muten Roshi.
As you’ll see, this dataset includes observations which detail the power level of the notable occasions when this attack was used. Our task here is get some understanding about this attack move from the data, and see if we can figure out whose kamehameha is actually the strongest out of all the characters.
Data cleaning
Here, we use regex (regular expression) string matching to filter on the Character
column. The str_detect()
function from the {stringr} package detects whether a pattern or expression exists in a string, and returns a logical value of either TRUE
or FALSE
(which is what dplyr::filter()
takes in the second argument). I also used the stringr::regex()
function and set the ignore_case
argument to TRUE
, which makes the filter case-insensitive, such that cases of ‘Kame’ and ‘kAMe’ are also picked up if they do exist.
dball_data %>%
filter(str_detect(Character, regex("kameha", ignore_case = TRUE))) -> dball_data_1
dball_data_1 %>% head()
## # A tibble: 6 x 4
## Character Power_Level Saga_or_Movie Dragon_Ball_Seri~
## <chr> <chr> <chr> <chr>
## 1 Master Roshi's Max Power Kam~ 180 Emperor Pilaf Saga Dragon Ball
## 2 Goku's Kamehameha 12 Emperor Pilaf Saga Dragon Ball
## 3 Jackie Chun's Max power Kame~ 330 Tournament Saga Dragon Ball
## 4 Goku's Kamehameha 90 Red Ribbon Army S~ Dragon Ball
## 5 Goku's Kamehameha 90 Red Ribbon Army S~ Dragon Ball
## 6 Goku's Super Kamehameha 740 Piccolo Jr. Saga Dragon Ball
If this filter feels convoluted, it’s for a good reason. There is a variation of cases and spellings used in this dataset, which a ‘straightforward’ filter wouldn’t have picked up. So there are two of these:
dball_data %>%
filter(str_detect(Character, "Kamehameha")) -> dball_data_1b
## Show the rows which do not appears on BOTH datasets
dball_data_1 %>%
dplyr::anti_join(dball_data_1b, by = "Character")
## # A tibble: 2 x 4
## Character Power_Level Saga_or_Movie Dragon_Ball_Seri~
## <chr> <chr> <chr> <chr>
## 1 Jackie Chun's Max power Kameham~ 330 Tournament Saga Dragon Ball
## 2 Android 19 (Goku's kamehameha a~ 230,000,000 Android Saga Dragon Ball Z
Before we go any further with any analysis, we’ll also need to do something about Power_Level
, as it is currently in the form of character / text, which means we can’t do any meaningful analysis until we convert it to numeric. To do this, we can start with removing the comma separators with stringr::str_remove_all()
, and then run as.numeric()
.
In ‘real life’, you often get data saved with k and m suffixes for thousands and millions, which will require a bit more cleaning to do - so here, I’m just thankful that all I have to do is to remove some comma separators.
dball_data_1 %>%
mutate_at("Power_Level", ~str_remove_all(., ",")) %>%
mutate_at("Power_Level", ~as.numeric(.)) -> dball_data_2
dball_data_2 %>% tail()
## # A tibble: 6 x 4
## Character Power_Level Saga_or_Movie Dragon_Ball_Seri~
## <chr> <dbl> <chr> <chr>
## 1 Goku's Super Kame~<PHONE_NUMBER>0 OVA: Plan to Eradicate the ~ Dragon Ball Z
## 2 Family Kamehameha<PHONE_NUMBER>00 Movie 10: Broly- The Second~ Dragon Ball Z
## 3 Krillin's Kameham~ 8000000 Movie 11: Bio-Broly Dragon Ball Z
## 4 Goten's Kamehameha 950000000 Movie 11: Bio-Broly Dragon Ball Z
## 5 Trunk's Kamehameha 980000000 Movie 11: Bio-Broly Dragon Ball Z
## 6 Goten's Super Kam~<PHONE_NUMBER> Movie 11: Bio-Broly Dragon Ball Z
Now that we’ve fixed the Power_Level
column, the next step is to isolate the information about the characters from the Character
column. The reason why we have to do this is because, inconveniently, the column provides information for both the character and the occasion of when the kamehameha is used, which means we won’t be able to easily filter or group the dataset by the characters only.
One way to overcome this problem is to use the apostrophe (or single quote) as a delimiter to extract the characters from the column. Before I do this, I will take another manual step to remove the rows corresponding to absorbed kamehamehas, e.g. Android 19 (Goku’s kamehameha absorbed), as it refers to the character’s power level after absorbing the attack, rather than the attack itself. (Yes, some characters are able to absorb kamehameha attacks and make themselves stronger..!)
After applying the filter, I use mutate()
to create a new column called Character_Single
, and then str_remove_all()
to remove all the characters that appear after the apostrophe:
dball_data_2 %>%
filter(!str_detect(Character, "absorbed")) %>% # Remove 2 rows unrelated to kamehameha attacks
mutate(Character_Single = str_remove_all(Character, "\\'.+")) %>% # Remove everything after apostrophe
select(Character_Single, everything()) -> dball_data_3
## # A tibble: 10 x 5
## Character_Single Character Power_Level Saga_or_Movie Dragon_Ball_Ser~
## <chr> <chr> <dbl> <chr> <chr>
## 1 Master Roshi Master Roshi's~ 180 Emperor Pilaf ~ Dragon Ball
## 2 Goku Goku's Kameham~ 12 Emperor Pilaf ~ Dragon Ball
## 3 Jackie Chun Jackie Chun's ~ 330 Tournament Saga Dragon Ball
## 4 Goku Goku's Kameham~ 90 Red Ribbon Arm~ Dragon Ball
## 5 Goku Goku's Kameham~ 90 Red Ribbon Arm~ Dragon Ball
## 6 Goku Goku's Super K~ 740 Piccolo Jr. Sa~ Dragon Ball
## 7 Goku Goku's Kameham~ 950 Saiyan Saga Dragon Ball Z
## 8 Goku Goku's Kameham~ 36000 Saiyan Saga Dragon Ball Z
## 9 Goku Goku's Kameham~ 44000 Saiyan Saga Dragon Ball Z
## 10 Goku Goku's Angry K~ 180000000 Frieza Saga Dragon Ball Z
Note that the apostrophe is a special character, and therefore it needs to be escaped by adding two forward slashes before it. The dot (.
) matches all characters, and +
tells R to match the preceding dot to match one or more times. Regex is a very useful thing to learn, and I would highly recommend just reading through the linked references below if you’ve never used regular expressions before.1
Analysis
Now that we’ve got a clean dataset, what can we find out about the Kamehamehas?
My approach is start with calculating the average power levels of Kamehamehas in R, grouped by Character_Single
. The resulting table tells us that on average, Goku’s Kamehameha is the most powerful, followed by Gohan:
dball_data_3 %>%
group_by(Character_Single) %>%
summarise_at(vars(Power_Level), ~mean(.)) %>%
arrange(desc(Power_Level)) -> kame_data_grouped # Sort by descending
kame_data_grouped
## # A tibble: 11 x 2
## Character_Single Power_Level
## <chr> <dbl>
## 1 Goku 3.46e14
## 2 Gohan 1.82e12
## 3 Family Kamehameha 3.00e11
## 4 Super Perfect Cell 8.00e10
## 5 Perfect Cell 3.02e10
## 6 Goten 1.98e 9
## 7 Trunk 9.80e 8
## 8 Krillin 8.00e 6
## 9 Student-Teacher Kamehameha 1.70e 4
## 10 Jackie Chun 3.30e 2
## 11 Master Roshi 1.80e 2
However, it’s not helpful to directly visualise this on a bar chart, as the Power Level of the strongest Kamehameha is 175,433 times greater than the median!
## Min. 1st Qu. Median Mean 3rd Qu. Max.
## 1.800e+02 4.008e+06 1.975e+09 3.170e+13 1.900e+11 3.465e+14
A way around this is to log transform the Power_Level
variable prior to visualising it, which I’ve saved the data into a new column called Power_Index
. Then, we can pipe the data directly into a ggplot chain, and set a dark mode using theme()
:
kame_data_grouped %>%
mutate(Power_Index = log(Power_Level)) %>% # Log transform Power Levels
ggplot(aes(x = reorder(Character_Single, Power_Level),
y = Power_Index,
fill = Character_Single)) +
geom_col() +
coord_flip() +
scale_fill_brewer(palette = "Spectral") +
theme_minimal() +
geom_text(aes(y = Power_Index,
label = round(Power_Index, 1),
hjust = -.2),
colour = "#FFFFFF") +
ggtitle("Power Levels of Kamehamehas", subtitle = "By Dragon Ball characters") +
theme(plot.background = element_rect(fill = "grey20"),
text = element_text(colour = "#FFFFFF"),
panel.grid = element_blank(),
plot.title = element_text(colour="#FFFFFF", face="bold", size=20),
axis.line = element_line(colour = "#FFFFFF"),
legend.position = "none",
axis.title = element_text(colour = "#FFFFFF", size = 12),
axis.text = element_text(colour = "#FFFFFF", size = 12)) +
ylab("Power Levels (log transformed)") +
xlab(" ")
So as it turns out, the results aren’t too surprising. Goku’s Kamehameha is the strongest of all the characters on average, although it has been referenced several times in the series that his son Gohan’s latent powers are beyond Goku’s.
Also, it is perhaps unsurprising that Master Roshi’s Kamehameha is the least powerful, given a highly powered comparison set of characters. Interestingly, Roshi’s Kamehameha is stronger as ‘Jackie Chun’ than as himself.
We can also see the extent to which Goku’s Kamehameha has grown more powerful across the series. This is available in the column Saga_or_Movie
. In the same approach as above, we can do this by grouping the data by Saga_or_Movie
, and pipe this into a ggplot bar chart:
dball_data_3 %>%
filter(Character_Single == "Goku") %>%
mutate(Power_Index = log(Power_Level)) %>% # Log transform Power Levels
group_by(Saga_or_Movie) %>%
summarise(Power_Index = mean(Power_Index)) %>%
ggplot(aes(x = reorder(Saga_or_Movie, Power_Index),
y = Power_Index)) +
geom_col(fill = "#F85B1A") +
theme_minimal() +
geom_text(aes(y = Power_Index,
label = round(Power_Index, 1),
vjust = -.5),
colour = "#FFFFFF") +
ggtitle("Power Levels of Goku's Kamehamehas", subtitle = "By Saga/Movie") +
scale_y_continuous(limits = c(0, 40)) +
theme(plot.background = element_rect(fill = "grey20"),
text = element_text(colour = "#FFFFFF"),
panel.grid = element_blank(),
plot.title = element_text(colour="#FFFFFF", face="bold", size=20),
plot.subtitle = element_text(colour="#FFFFFF", face="bold", size=12),
axis.line = element_line(colour = "#FFFFFF"),
legend.position = "none",
axis.title = element_text(colour = "#FFFFFF", size = 10),
axis.text.y = element_text(colour = "#FFFFFF", size = 8),
axis.text.x = element_text(colour = "#FFFFFF", size = 8, angle = 45, hjust = 1)) +
ylab("Power Levels (log transformed)") +
xlab(" ")
I don’t have full knowledge of the chronology of the franchise, but I do know that Emperor Pilaf Saga, Red Ribbon Army Saga, and Piccolo Jr. Saga are the earliest story arcs where Goku’s martial arts abilities are still developing. It also appears that if I’d like to witness Goku’s most powerful Kamehameha attack, I should find this in the Baby Saga!
Notes
Hope this was an interesting read for you, and that this tells you something new about R or Dragon Ball.
There is certainly more you can do with this dataset, especially once it is processed into a usable, tidy format.
If you have any related datasets that will help make this analysis more interesting, please let me know!
In the mean time, please stay safe and take care all!


Reports octal escapes, which are easily confused with back references. Use hexadecimal escapes to avoid confusion.
Example:
\07
After the quick-fix is applied:
\x07
New in 2017.1


SLC PUNK! (Sony Pictures Classics) Starring: Matthew Lillard, Michael Goorjian, Annabeth Gish, Jennifer Lien, Til Schweiger. Screenplay: James Merendino. Producers: Sam Maydew and Peter Ward. Director: James Merendino. MPAA Rating: R (profanity, drug use, violence) Running Time: 97 minutes. Reviewed by Scott Renshaw.
James Merendino's SLC PUNK! has something deep and insightful to say about the nature of youthful rebellion. Sort of. Maybe. I think. It's sort of hard to tell through all the bombast of Merendino's hyperactive period piece, which tries to be a sort of nostalgic BREAKFAST CLUB for the Dead Kennedys set but misses the point entirely. It's one thing to make a film about teens grousing over the sell-outs of adulthood and the trials of coping with societal expectations, and target it at the teens themselves; it's quite another to make such a film and target it at those who've already been through that melodramatic wringer. The simple enjoyment that might have come from the time and the tunes instead turns into a 90 minute wait for the characters to get a clue.
Our tour guide through SLC PUNK! is Stevo (Matthew Lillard), who -- along with his best friend Heroin Bob (Michael Goorjian) -- is one of the few true punks in the capital of conservative Utah during the conservative Reagan era circa 1985. The tour consists largely of an anthropological dig through Stevo and Bob's twisted clique, which includes an independently wealthy and extremely paranoid drug dealer (Til Schweiger), the lads' respective ladyfriends (Jennifer Lien and Annabeth Gish), and an acid casualty (Devon Sawa). Along the way we learn about the various sub-categories of Salt Lake City youth, the influence of Stevo's 60s radical-turned-yuppie father (Christopher McDonald), and where to go for real beer when you need it.
Like many an independent comedy, SLC PUNK! has enough frantic energy to guarantee at least a few belly laughs -- notably during Stevo's spin through a party describing the various sub-plots in action, and a scene showing our protagonists as pre-punk, "Dungeons and Dragons"-obsessed middle-schoolers. Also like many an independent comedy, it often has nothing _but_ frantic energy. For every decent gag or clever insight, you can count on at least two or three self-indulgent uses of direct address to the camera in which Stevo rails about religious oppression or the plague of poseurs (i.e., those who son the garb without walking the walk). Scenes which I'm assuming should come off as either amusing or wise-beyond-his-years instead come off as merely damp; if spittle were diamonds, Matthew Lillard's performance would surely be a piece of comic jewelry fit for a princess. Once again, a film-maker's attempt to connect with the audience through narration becomes a lazy failure.
SLC PUNK! tries to score its major profundity points when Stevo is hit by the bombshell that rebellious youth are just conformists of a different kind. Well, you can file that one under "d" for "duh;" Stevo's revelation is one with which any audience member over the age of 25 will already be quite familiar. It's that kind of pseudo-wisdom that makes SLC PUNK! far more tiresome than a film built around devotion to the Ramones should have been. When tragedy strikes one of the film's significant characters late in the film, and Merendino tries to play it as a genuine tragedy, you realize he hasn't remotely earned an emotional response. SLC PUNK! blasts through its set pieces with little film-making prowess, then expects to tie it all together by having Stevo blubber away at misspent youth. Poseurs, indeed.
On the Renshaw scale of 0 to 10 bunk rockers: 4.
Visit Scott Renshaw's Screening Room http://www.inconnect.com/~renshaw/ *** Subscribe to receive new reviews directly by email! See the Screening Room for details, or reply to this message with subject "Subscribe".
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


The GreenUp-VT app available for iOS, Android, and mobile web browsers, is a not-for-profit project developed by XenonApps.com for the Green Up Vermont organization, meant to make the annual Green-Up day more efficient and better organized, while providing valuable data to help coordinate future Green-Up days.
Green Up Vermont is a nonprofit organization with 501(c)(3) status. Green Up's mission is to promote the stewardship of our state's natural landscape and waterways and the livability of our communities by involving people in Green Up Day and raising public awareness about the benefits of a litter-free environment.
The app anonymously gathers GPS data from your mobile device while you work, which, when compiled with the data of other participants, is plotted as a heat map, providing all participants with a comprehensive overview of the areas that have already been cleaned and the areas that require more attention. Furthermore, the app allows participants to comment on the needs of specific locations with geocoded messages aggregated in our comments section.


{% extends "base.html"%} {% load static %} {% block title %} Dataflow Level Modelling {% endblock %} {% block content%}
As mentioned in one of the previous articles on Types of Modelling , Dataflow Modelling is a higher level of abstraction than Gate Level Modelling .
It resembles a description in form of equations consisting of operands and operators for modelling digital circuits.
Since you are already aware of the concept of Dataflow Modelling and its requirements, we can straight away turn towards the details of Dataflow Modelling.
A continuous assignment is the most basic statement in dataflow modelling , used to drive the value on a net.The assign statement replaces the gates in the actual circuit and describes the circuit at a higher level of abstraction.
Syntax ---
assign (net_expression) = [drive_strength] [delay](expression of different signals and operators or constant values)
The drive strength is optional but can be specified in terms of strength level of signals. Strength Levels are already discussed in Verilog Basics-1.
Default value for drive strength is strong1 and strong0.The delay value is also optional and can be used to specify gate delays.
Rules--
1) The left hand side of an assignment must be a net (scalar or vector) or a concatenation of either or both types of nets. It cannot be a scalar or vector register.
2) Continuous Assignments are always active i.e. the assignment is evaluated as soon as right hand side operands changes and the value is assigned to the left hand side net.Since, the left hand side quantity is evaluated continuously , hence it cannot store a value i.e. cannot be a reg.
3) The operands on the right hand side can be registers or nets or function calls. Registers/Nets can be scalars or vectors.
4) Delay values can be specified in certain time units. It resembles the delay in assigning the evaluated value. It is very useful in modelling timing behaviour in real circuits.
5) Operators are used in the assignments for denoting any kind of operation.
/* Continuous assignment, exor_op is a net . in1 and in2 can be net or register */
assign exor_op = in1 ^ in2;
// Concatenation of Scalar and Vector Net in LHS.
assign {c_out , sum [3:0]} = a [3:0] + b [3:0] + c_in ;
// Continuous assignment for vector nets
assign and_op[15:0] = in1_vector[15:0] & in2_vector[15:0];
Implicit Continuous Assignment :
Instead of declaring a net and then writing a continuous assignment , we are provided with a shortcut by which a continuous assignment can be done when it is declared.
However, only one implicit continuous assignment can be done as the variable is declared only once.
wire in1,in2 ;
//Regular Continuous Assignment
wire exor_op ;
assign exor_op = in1 ^ in2;
// Implicit Continuous Assignment
wire exor_op_implicit = in1 ^ in2;
Implicit Net Declaration :
If any signal is used in the left side of the continuous assignment, implicitly a net declaration is inferred for the signal name.
wire in1,in2 ;
assign exor_op = in1 ^ in2;
/* exor_op was not declared as wire but an implicit wire declaration is done by Simulator */
Regular Assignment Delay :
This method is for assigning the delay value after the keyword assign.
Any change in values of in1 and in2 will result in a delay of specified time units before recomputation of the value of in1^in2 , and the result will be assigned to exor_op.
The delay is termed as inertial delay as an input pulse shorter than the delay of assignment statement does not propagate to the output.
Hence , the state of input should be constant for at least the delay in the assignment statement to be propagated to output.
wire in1,in2;
wire exor_op;
assign #10 exor_op = in1^in2; // Delay in Continuous Assignment
Implicit Continuous Assignment Delay :
The name itself suggests that implicit continuous assignment is used here to specify both delay and assignment on the net.
wire in1,in2 ;
//Regular Continuous Assignment Delay
wire exor_op ;
assign #10 exor_op = in1 ^ in2;
// Implicit Continuous Assignment Delay
wire #10 exor_op_implicit = in1 ^ in2;
Net Declaration Delay :
A delay can be specified on the net during declaration without putting any continuous assignment on the net.
The delay effect remains the same as regular assignment delay . This type of declaration can also be used in gate level modelling.
wire in1,in2 ;
//Net Declaration Delay
wire #10 exor_op ;
assign exor_op = in1 ^ in2;
Expressions :
Expressions are constructed out of operators and operands to produce results.
//Expressions
a + b;
in1 ^ in2;
busin1[8:5] | busin2[8:5];
Operands :
Operands can be of any data types defined in Verilog Basics-1 .
Sometimes, there can be limitations for the data types that can be used for certain expressions.
Operands can be nets,registers,constants,integers,real numbers,times, etc.
//value_1 and value_2 are integer operands
integer value_1 , value_2 ;
value1 = ~ value2;
//bitval_1 and bitval_2 are register operands
reg [7:0]bitval_1,bitval_2 ;
reg [2:0]out_val ;
out_val = bit_val[2:0] + bit_val[2:0];
Operators :
Operators act on Operands to produce various results.
a + b; // ‘+’ is an operator on operands a and b
in1 ^ in2; // ‘^’ is an operator on operands in1 and in2
busin1[8:5] | busin2[8:5];
// ‘|’ is an operator on operands busin1[8:5] and busin2[8:5]
There are various types of operators provided in Verilog :
| Operator Type | Operator Symbol | Operation Performed | Number of Operands |
|---|---|---|---|
| Arithmetic | + | Add | Two |
| - | Subtract | Two | |
| * | Multiply | Two | |
| / | Divide | Two | |
| % | Modulus | Two | |
| ** | Power(Exponent) | Two | |
| Relational | > | Greater than | Two |
| < | Less than | Two | |
| >= | Greater than or equal to | Two | |
| <= | Less than or equal to | Two | |
| Logical | ! | Logical Negation | One |
| && | Logical AND | Two | |
| || | Logical OR | Two | |
| Equality | == | Equality | Two |
| != | Inequality | Two | |
| === | Equality (Considering Unknown and High Impedance) | Two | |
| !== | Inequality (Considering Unknown and High Impedance) | Two | |
| Reduction | & | Reduction AND | One |
| ~& | Reduction NAND | One | |
| | | Reduction OR | One | |
| ~| | Reduction NOR | One | |
| ^ | Reduction XOR | One | |
| ^~ or ~^ | Reduction XNOR | One | |
| Bitwise | ~ | Bitwise Negation | One |
| & | Bitwise AND | Two | |
| | | Bitwise OR | Two | |
| ^ | Bitwise XOR | Two | |
| ^~ or ~^ | Bitwise XNOR | Two | |
| Shift | >> | Right Shift | Two |
| << | Left Shift | Two | |
| >>> | Arithmetic Right Shift | Two | |
| <<< | Arithmetic Left Shift | Two | |
| Concatenation | { } | Concatenate Numbers | Any number |
| Replication | { { } } | Replicate Numbers | Any number |
| Conditional | ?: | Decision Taking | Three |
Operator Precedence is important in our discussion for the cases where parentheses are not used to separate two operations in an expression .
The precedence decides which operation needs to be done at the earliest or late.
The following table gives the precedence from the highest to the lowest.
However , it is recommended to use parentheses to remove ambiguity in the expression except in case of unary operation.
Since we have discussed all the syntax and other things related to Dataflow Modelling ,we can move forward to write some code in this level of abstraction and describe any simple digital design.
This would be a great exercise as this would combine various concepts you’ve learned till now to realize something much simpler and powerful.
2-to-1 Multiplexer :
Boolean Equation : -> out = ( NOT(s) AND i0 ) OR (s AND i1)
Since , we are already familiar with the boolean equation for the given multiplexer , so we can write a continuous assignment for describing this design.
// 2-to-1 Multiplexer , Dataflow Modelling , Logic Equation
module mux_2_to_1 ( out, i0, i1, s);
// Port declaration for the given diagram
output out;
input i0, i1, s;
// Logic Equation using Expression
assign out = ( ~s & i0 )| ( s & i1 );
endmodule
There is also a more concise way of specifying the multiplexer using the conditional operator ( ? : ).
The code can be written as follows :
//2-to-1 Multiplexer , Dataflow Modelling , Conditional Operator
module mux_2_to_1 ( out, i0, i1, s);
// Port declaration for the given diagram
output out;
input i0, i1, s;
//Conditional Operator Usage
assign out = (s ? i1 : i0) ;
/*This signifies that when ‘s’ is logical-1 , ‘i1’ is assigned to ‘out’ , otherwise ‘i0’ is assigned to ‘out’ */
endmodule
1-bit Full Adder :
Boolean Equation :->
sum = (a XOR b )XOR cin ;
cout = cin AND (a XOR b) OR (a AND b);
Since , we are already familiar with the boolean equation for the given full adder, so we can write a continuous assignment for describing this design.
//1-bit Full Adder , Dataflow Modelling , Logic Equation
module fulladd ( a, b, cin, sum, cout);
// Port declaration for the given diagram
output sum, cout;
input a, b, cin;
// Logic Equation using Expression
assign sum = (a ^ b)^cin ;
assign cout = ( cin & (a ^ b) ) | (a & b) ;
endmodule
There is another concise way of specifying 1-bit full adder using arithmetic operator and concatenation operator.
//1-bit Full Adder , Dataflow Modelling , Arithmetic Operator
module fulladd ( a, b, cin, sum, cout);
// Port declaration for the given diagram
output sum, cout;
input a, b, cin;
// Concatenation for Sum and Carry variable
// Specify Function directly using Arithmetic Operator
assign { cout, sum } = a + b + cin ;
endmodule


-20%
Japan on a Shaestring
$1400
$399
-30%
Discover Carribean Islands
$1400
$555
Last
Minute
offers
We have picked some amazing last minute holiday offers for you to choose from. These offers won’t last too long so hurry and book yours today!


11,518 Result(s)
within English Computer Science Article 2008
-
Article
Low Complexity Soft Decision Technique for Gray Mapping Modulation
High order Gray mapping modulation has been widely used in wireless communications, but the traditional soft decision technique via the log-sum approximation is of high computational complexity. In this paper,...
Dengsheng Lin, Yue Xiao, Shaoqian Li in Wireless Personal Communications (2008)
-
Article
Equivalence theorem, consistency and axiomatizations of a multi-choice value
This paper is devoted to the study of solutions for multi-choice games which admit a potential, such as the potential associated with the extended Shapley value proposed by Hsiao and Raghavan (Int J Game Theor...
Yan-An Hwang, Yu-Hsien Liao in Journal of Global Optimization (2008)
-
Open Access This content is freely available online to anyone, anywhere at any time.
Article
SoC Design Approach Using Convertibility Verification
Compositional design of systems on chip from preverified components helps to achieve shorter design cycles and time to market. However, the design process is affected by the issue of protocol mismatches, where...
Roopak Sinha, Partha S Roop, Samik Basu in EURASIP Journal on Embedded Systems (2008)
-
Open Access This content is freely available online to anyone, anywhere at any time.
Article
Accuracy of drug advertisements in medical journals under new law regulating the marketing of pharmaceutical products in Switzerland
New legal regulations for the marketing of pharmaceutical products were introduced in 2002 in Switzerland. We investigated whether claims in drug advertisements citing published scientific studies were justifi...
Macarena Gonzalez Santiago, Heiner C Bucher… in BMC Medical Informatics and Decision Making (2008)
-
Article
Bandwidth-based routing protocols in mobile ad hoc networks
In this paper, we propose a high performance routing protocol and a long lifetime routing protocol by considering the fact that the bandwidth between two mobile nodes should be different when distances are dif...
Ching-Wen Chen, Chuan-Chi Weng in The Journal of Supercomputing (2008)
-
Article
Documentary ethics, ontology, and politics
Recent years have seen a sharp rise of attention to the importance of documentation in various disciplines in the social sciences. Many thinkers have found the concept of assemblages, which emphasizes complexi...
Bernd Frohmann in Archival Science (2008)
-
Open Access This content is freely available online to anyone, anywhere at any time.
Article
A Selective Downlink Scheduling Algorithm to Enhance Quality of VOD Services for WAVE Networks
Providing quality-of-service- (QoS-) guaranteed video on demand (VOD) services over wireless access in vehicular environments (WAVEs) is a challenge as WAVE adopts enhanced distributive channel access (EDCA), ...
Shumao Ou, Kun Yang, Hsiao-Hwa Chen… in EURASIP Journal on Wireless Communications… (2008)
-
Open Access This content is freely available online to anyone, anywhere at any time.
Article
SPRINT: A new parallel framework for R
Microarray analysis allows the simultaneous measurement of thousands to millions of genes or sequences across tens to thousands of different samples. The analysis of the resulting data tests the limits of exis...
Jon Hill, Matthew Hambley, Thorsten Forster, Muriel Mewissen… in BMC Bioinformatics (2008)
-
Open Access This content is freely available online to anyone, anywhere at any time.
Article
WGCNA: an R package for weighted correlation network analysis
Correlation networks are increasingly being used in bioinformatics applications. For example, weighted gene co-expression network analysis is a systems biology method for describing the correlation patterns am...
Peter Langfelder, Steve Horvath in BMC Bioinformatics (2008)
-
Open Access This content is freely available online to anyone, anywhere at any time.
Article
Overview on Selective Encryption of Image and Video: Challenges and Perspectives
In traditional image and video content protection schemes, called fully layered, the whole content is first compressed. Then, the compressed bitstream is entirely encrypted using a standard cipher (DES, AES, I...
A. Massoudi, F. Lefebvre, C. De Vleeschouwer… in EURASIP Journal on Information Security (2008)
-
Article
Asymptotic convergence of an inertial proximal method for unconstrained quasiconvex minimization
This paper deals with the convergence analysis of a second order proximal method for approaching critical points of a smooth and quasiconvex objective function defined on a real Hilbert space. The considered m...
-
Article
Incorporating message weights in UML-based analysis of behavioral dependencies in distributed systems
Behavioral dependency analysis (BDA) and the visualization of dependency information have been identified as a high priority in industrial software systems (in specific, distributed systems). BDA determines th...
Vahid Garousi in Software & Systems Modeling (2008)
-
Article
Modeling light propagation in liquid crystal devices with a 3-D full-vector finite-element beam propagation method
A full-vector finite-element beam propagation method in 3-D is introduced for the simulation of light propagation in liquid crystal (LC) devices. The three electric field components are expressed in terms of m...
Giannis D. Ziogos, Emmanouil E. Kriezis in Optical and Quantum Electronics (2008)
-
Article
State-Constrained Optimal Control Governed by Elliptic Differential Equations in Unbounded Domains
This work concerns the maximum principle for optimal control problems governed by elliptic differential equations in unbounded domains. Some state constraints are considered.
L. Wang in Journal of Optimization Theory and Applications (2008)
-
Open Access This content is freely available online to anyone, anywhere at any time.
Article
SimHap GUI: An intuitive graphical user interface for genetic association analysis
Researchers wishing to conduct genetic association analysis involving single nucleotide polymorphisms (SNPs) or haplotypes are often confronted with the lack of user-friendly graphical analysis tools, requirin...
Kim W Carter, Pamela A McCaskie, Lyle J Palmer in BMC Bioinformatics (2008)
-
Article
Stability of semi-infinite vector optimization problems under functional perturbations
This paper is devoted to the study of continuity properties of Pareto solution maps for parametric semi-infinite vector optimization problems (PSVO). We establish new necessary conditions for lower and upper s...
T. D. Chuong, N. Q. Huy, J. C. Yao in Journal of Global Optimization (2008)
-
Article
Securing the Communication in Private Heterogeneous Mobile Ad hoc Networks
Mobile ad hoc networking has been a hot research topic for a decade or so, and many paradigms have been making use of it. One of these paradigms is the Personal Networks (PN). It is an emerging concept where t...
Luis Sánchez, Jorge Lanza, Luis Muñoz, Kimmo Ahola… in Wireless Personal Communications (2008)
-
Article
Set containment characterization for quasiconvex programming
Dual characterizations of containment of a convex set, defined by quasiconvex constraints, in a convex set, and in a reverse convex set, defined by a quasiconvex constraint, are provided. Notions of quasiconju...
Satoshi Suzuki, Daishi Kuroiwa in Journal of Global Optimization (2008)
-
Open Access This content is freely available online to anyone, anywhere at any time.
Article
Design of a Real-Time Face Detection Parallel Architecture Using High-Level Synthesis
We describe a High-Level Synthesis implementation of a parallel architecture for face detection. The chosen face detection method is the well-known Convolutional Face Finder (CFF) algorithm, which consists of ...
Nicolas Farrugia, Franck Mamalet, Sébastien Roux… in EURASIP Journal on Embedded Systems (2008)
-
Open Access This content is freely available online to anyone, anywhere at any time.
Article
The cancer translational research informatics platform
Despite the pressing need for the creation of applications that facilitate the aggregation of clinical and molecular data, most current applications are proprietary and lack the necessary compliance with stand...
Patrick McConnell, Rajesh C Dash… in BMC Medical Informatics and Decision Making (2008)